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