芜湖项目现场需求调研阶段,工作效率高,工作成果的质量也很好,现在总结如下:
- 需求分析团队人员要尽量少,减少沟通成本。尽量只允许业务核心人员参与,这样能够以最快速度对业务流程进行确认。
反观现在大平台的项目,需求分析阶段有30多个人参加,包括了国家局的人员和各省市的人员。分成了6个分析小组。诸多问题无法现场进行确认,因为参加的人多,因此大家都不作结论,只能会后通过EMAIL来回来去。由于分组很多,因此涉及到很多跨小组的问题进一步增加了沟通成本。
- 需求讨论会议现场形成文档,由于文档形式上是共同创作完成,因此可以省略客户确认文档的过程。
反观现在大平台的项目,会议之后,需求分析人员晚上加班形成需求访谈报告,需要客户确认,然后再形成需求规格说明书,再要求客户确认,这样效率非常差。 - 关于需求分析的团队构成,建议如下:
- 客户业务人员
- 客户IT人员
- 主力业务分析人员:主要负责需求分析工作,引导大家使用正确的方式和正确的方向进行需求分析工作。
- 业务分析助理:主要使用合适的工具,现场进行文档撰写工作。也可以提出自己的建议。因此该人员也需要有一定的需求分析能力和文档撰写经验。
- 项目助理:负责对会议中的各种未定事项以及决议进行跟踪,并且进行其他的一些辅助性工作。
- 解决方案顾问团队:辅助角色,可以离线支持。主要对相关业务领域或者IT技术领域进行咨询工作。
- 开发组组长以及主要设计人员
- 系统实施负责人 - 使用的工具建议如下:
- 业务流程分析工具,以便团队成员能够在早期对业务流程有全貌的认识,如BPMN, EPC图等等
- 快速互动原型工具,以便快速形成可以进行互动的动态系统原型,给客户良好的感受。推荐serena prototype composer或者axure rp等。
- Sparx Enterprise architect,全面的项目模型管理,在此阶段主要使用到:用例分析,领域模型,需求条目管理等等。(在用例中需要填写senario条目,并且需要与需求条目进行关联)
- Balsamiq Mockups,对操作页面进行设计。 - 对目前的大平台,现在能想到的建议如下:
- 分组尽量少,1~2各组,人员尽量少,减少沟通成本。
- 现场形成文档。
- 在早期需要有总体业务流程分析过程,然后在进入细节系统需求分析过程。
- 使用上述的工具
- 使用上述的团队组织结构
综上,发现上述经验并不太符合敏捷过程,反而与《人月神话》中的理论非常相似。起码,可以总结出来两点:
1.架构(需求分析)是贵族专有的工作内容。
2.需要组成外科手术型的团队结构。