这里我不想做需求分析,而是对问题的本质做一个分析,同时对如何实施提出建议。
　　信息负责人:
　　表面上,信息负责人既懂业务又懂技术,还了解企业现状,对软件供应商与企业方起着良好的推动作用。但是实际过程中,由于业务部门的专业程度,信息部门很难提出建设性的意见。在业务解决方案这条路走不通的时候,往往就只剩下技术解决这条路了口同时,信息部门也喜欢在企业中显示自己的技术见解,主动用技术方案去承担管理问题(国企性质还存在屁股决定脑袋的问题),这就为日后的重复开发、模糊焦点埋下了巨大隐患。而最后出了问题就指责软件实施团队技术水平不够,要求增加人力。
　　业务部门及操作人员:
　　业务部门及操作人员喜欢钻研各种操作并尽可能地找出漏洞,以达到破坏管理系统、使自己脱离领导管控的目的。通常,他们喜欢从业务、技术、操作等多个角度将问题不断抛出,并且尽可能地将需求以及描述复杂化。最后被追责的时候一本正经地说道:业务说了几次也不懂,他们的软件问题太多,无法使用。
　　公司领导:
　　公司领导将管理问题归结于技术问题,因为你不了解他的价值观。最后他可以作为领导通过大家的质疑来使你在这一块无法推动最后停滞。
　　那么项目经理该怎么做呢?
　　首先,我们要了解领导的价值观。比如,领导说:在一切管理目标发生冲突的时候,以进度为第一。这句话就表明了管理目标的优先级别。了解了领导的价值观之后,我们就会介绍可以按标准分类以上传的方式完成工程文档维护,并给予相应业务部门的权限方便查阅。反过来,如果领导说:我们要对管理的一些盲区进行挖掘,不留一处死角。那么就表明要将所有过程全部体现在系统中,这个时候如果你说附件上传,领导显然会不满意,因为达不到他的管理目标。
　　对于信息部门,由于他们往往是“采集流程对IT的需求”,软件实施商可以尽量不去“打扰”他们。既然问题的源头是业务,那么一切中心就围绕着业务部门。
　　最后,对于业务部门,我们可以与业务部门的领导沟通,明确管理目标。在目标不明确的情况下讨论任何管理方法和实现细节都是毫无意义的。注意,所有的事件中项目经理只做引导,业务领导来推动,这就是借力打力,而不是软件实施团队冲在前面承受暴风雨的洗礼。