还剩3页未读,继续阅读
文本内容:
⑶沟通机制建立了月例会、例会制度,每次例会后以会议纪要的形式发出会议上达成的共识,作为后续衡量和评估相关确定有没有去贯彻和落实的依据之前工程团队也会开例会,但是会议达成的须要去解决的问题往往会上说说的好好的,但是会后没有制度工程团队之前特殊不重视系统应用的推广,真正去做,会议成了一种形式⑷系统运营报告往往功能上线之后就算完成了,不会去关注这个功能原委有没有被用起来,也不清晰整个系统的应用状况在工程期间,我们建立了系统运营状况每月报告制度,将系统重要应用的运用状况以月报的方式发送给领程合同的把控缺乏,给后续管理工作带来隐患导及相关人员
二、工程缺乏之处、对工1于公司系统的合同由其它部门负责管理,我们部门主要it负责具体系统的建立,因此在本工程中对工程的合同关注不够,对工程的合同内容把控缺乏主要表达在以下几个方面⑴合同中的工程的建立内容与当时汇报的建立方案中的内容两者没有细致地核对,有一些我方盼望纳入的建立内容结果在合同中没有表达,最终导致我方与软件开放商之间的扯皮,软件开放商会拿合同来说事,这是很致命的一个问题,说原委关于工程合同是两个部门之间的连接出现了问题⑵工程团队成员没有细致核实,虽然在看合同时也发觉了这个问题,但是由于对方是我公司的刻看来这种原那么性的问题还是不能无视⑶在长期合作伙伴,这些小问题没有太多的在意,此时此签订工程合同是,我们公司通常要求包含工程的考核规那么文档,在做本期工程时没有细致地考虑好如何进展考核,结果把特殊通用的一个考核规那么文档放入了合同中,但这个通用的考核规那么很多地方并不适合本工程,导致在后续实际考核工作中,有些问题由于没有在考核规那么中具体的描述清晰,导致具体的开发模式由于本工程的需求相比照较分散,因此在实施工程时接受的是新业务的开发模式,即一个个功能模块依次开发,每个功能模块都要阅历需求分析、设计、开发、上线等阶段,有点类似迭代的开发模式但是这种模式存在一些问题一是每次迭代划分的太细,导致几乎每个月都要阅历需求、设计、上线这些工作;二是这种开发模式导致对系统的整体把控实力缺乏,可能由于原来相关的一些功能模块,原来应当统一考虑需求和设计的,但是由于人为地把他们分割成多个阶段来实现,导致出现顾了当前没有考虑到将来及对原有功能模块的影响;三是这种开发模执行起来没有依据,简洁出现扯皮、新业务2式使得工程经理不清晰整个工程的工作重点应当放能再接受这种方式了、建立方案设计及汇报3在哪里;这种开发模式在下一期的工程中须要改良,不实力缺乏本期工程的建立方案主要由主管来完成的,志向的状况是方案由我来写,主管供应一些指导和看法,这样我这个角色才算是称职的方案完成之后,向领导的汇报工作不是很成功,前后汇报的三次才、需求文档和设计文档的标准性需求文档和设4算通过,这算是一次很深刻的教训,须要吸取计文档的标准性这个问题始终困扰着我,不仅仅是这个工程,其它工程也存在一样的问题,就当前我所参与过的工程来讲,需求和设计能够做的好的很少需求文档和设计文档应当表达哪些内容,这些内容如何以比拟好的方式来表达,才能清晰地描述清晰需求和系统的设计?、应用推广重视度不够建立一5个系统的目的是什么?目的是盼望系统能够为公司带来价值那么如何表达价值系统通过为公司的业务开展供应支撑实力,从而实现公司收入的增长的方式来表达价值那么系统只有真正被业务部门运用起来才能够发挥出价值而在本工程的建立过程中,虽然意识到了应用推广的重要性,但是具体的应用推广工作还是做的特殊不够,感觉是在为建立系统而建系统,感觉最求的是完成建立任务,至于用不用就不关我事了。
个人认证
优秀文档
获得点赞 0