在大多数IT项目中,一开始怀着雄心勃勃,到项目中后期遇到问题,客户满意度下降,甚至收不到钱,都是时常发生的事情。当然,如果要去找理由,项目成败的原因可以非常的多。从项目质量的角度看,一个极其重要的原因,便是缺少一个既懂业务又懂技术的系统分析师。
许多国内的IT项目团队,都有这两种典型的情况:
A团队: 由一个极具项目经验的项目经理带领,该项目经理A先生,对行业有着广泛了解,对业务流程也有着深刻的认识。整个项目由项目经理负责与客户沟通需求以及跟进项目进度,项目成员负责实施,开发,培训等工作。
B团队:由一个资深技术经理带领,B先生,在多个技术领域有着深入的研究,领队开发过很多应用系统,能够处理各种复杂的技术难题。整个项目主要由客户提出需求,技术经理带队去完成客户的需求,项目成员负责需求调研,开发,实施,培训。
A团队的问题:
需求设计的主观性
该团队的需求调研是由项目经理(或者顾问)完成。顾问花大量的时间出具调研文档,这些文档大多是文字描述,十分笼统。当一个专注于技术而不了解业务的技术成员用这些文档做系统设计的时候,他只专注于功能的实现,难以全面的考虑到客户最终的业务管理目标,从而导致设计出来的功能太过局限,同时,业务顾问和技术人员有很高的沟通成本,在内耗中并没有使项目境况有所改善,反而使得客户满意度降低。
急功近利,缺少架构和扩展性的前瞻性
项目经理A的目标是“以最短的时间和人力成本”完成项目。由于A经理在行业内经验丰富,他的意见非常有说服力,特别在需求的把控上非常得力,对于客户的需求,一压再压,一档再挡,使得工期安排上得以保证。A经理的策略是,不管用什么技术,只要把客户的功能得以实现,按时完成项目进度,便万事大吉。 但随着项目的推进,A经理发现客户在了解我们系统具体实现的情况下,走一步看一步,问题越来越多,开始不断的提出改进的需求,项目工期因此一拖再拖,甚至做到最后,必须要推翻以前所做的系统设计。
B团队的问题:
强大的技术,没有方向的指引
在需求洽谈时,也许A团队不能解决的技术问题,B团队都能解决。从而提高客户的期望值和满意度。随着客户对系统有更深的认识,需求也是不断增加,当项目到达一定程度后,忽然客户要求说,“以前做的功能都不对,我们要这样做”,技术经理顿时傻眼。。。究其原因,还是在系统设计之初,一开始并没有一个能考量到系统设计对业务的合理性问题,忙于解决细节问题,导致整个架构设计都有问题。
疲于应付需求变动,项目有始无终
一个技术能力强的人,遇到什么技术问题都能解决。客户说修改,便修改。客户需要调整,便调整。客户就像一个喂不饱的狮子,不断的在要求进食,而项目成员疲于加班,怨声载道。到最后改来改去客户始终不满意。
如果A,B团队都加入一个系统设计师,情况就不一样了。
调研时由业务顾问和系统分析师共同参与,在需求调研的过程中,需求实现的方式,可以从系统分析师处快速获得技术解决方案,需求的难易程度和工期,系统分析师也能更加准确的评估。业务需求也随着调研的完成,转化为“技术语言”。同时,系统分析师还能考虑到具体的IT环境,包括该项目和其他系统之间的数据交互,以及系统管理上的规划。
由于系统分析师参加了企业的全面调研,如果说最了解企业业务运作情况的人,恐怕就是他了。因此在设计系统架构时,系统分析师是掌握信息全面,理解最透彻的人,从而设计出相适应的系统结构和功能。
在项目进行的过程中,系统分析师,既可以和客户交流业务,也可以把业务需求转换为技术语言与技术人员沟通,这中间的桥梁作用可以使得两者的关系得到缓和,对需求的理解也是更加准确,在谈谈判的过程中,可以使客户更加清楚的了解项目的处境,以及平衡二者的关系。