最近与咨询公司合作做一个项目，我们团队为大项目中的子项目。
在项目管理上学习收获颇多，有经验教训，也有优秀的处理方式。复盘一下这个项目中需求管理的小事情。
项目涉及的相关方多，各方的需求不一定一致，因此在项目的计划阶段，需求一直在不断的增加与变更。在项目需求确认时，大家由于对于自己的需求还很模糊，有众多的需求有模棱两可的情况。只说需要一个功能，但是功能具体呈现出来和操作细节都不清楚。
需求如洪水，大坝保平安。
需求往往最直接的体现就是成为了项目范围，多数的项目失败则是由于项目范围失控了。
在项目的前期阶段，需求方一直在加需求，希望一次把所有的东西都做到完美。
在已经开始画系统原型界面时还在增加与变更需求。团队提出了确定需求的要求。
咨询公司的项目经理快速响应，与需求方进行了沟通，达成共识确认本期会做的需求并形成需求文档。并将截止日期之后的需求都进行记录，作为二期的需求。并且将需求的文件发送给整个项目组与需求方进行公告。
至此，我们本期的项目范围进行了控制，并且至此没有出现失控。
需求确认要尽早，当明确要做，就杜绝说出“这个后面再说”。
我们在做原型设计与确认时，与原型相关的功能点对外部分展现方式与实现方式，做了逐一的明确确认。这一部分达到了需求清晰，呈现明确。
但是原型中后台系统部分的由于是给团队内部使用的没有做清晰确认，以及原型没有覆盖到的技术实现没有明确确认，这就为后面的实现上埋下了隐患。
到了实现阶段，与另一团队需要集成的一个方案由于前期没有明确确认，在实现时发现方案两边期望的方案不一致，导致来回沟通2周，任务延期1周才完成。
任何一个有多种可能性的事件，出现的结果都可能和你设想的不一致。
另一面，后台部分的原型细节由于我们没做细节讨论。
一个十分简单的展示页面，带一个筛选功能与查询功能。我在画原型时没有将可能涉及的所有搜索情况都一一呈现出来。
当开发同学做完第一个发版时，我十分简单的功能测试就有3个场景不符合设想的场景。
在团队合作与沟通的过程中，我们不能想当然觉得别人知道我们的想法。
这个道理多数人都懂，但是却需要经常的提醒自己，因为一不小心就会想当然。
成功的项目实属难得，失败的项目大把大把。
不断学习优秀的经验优化团队的工作，且行且珍惜。
