上周我们团队的一款产品可以说是在历经困难之后发布了V1.0版本。版本上线之后，我们进行了一次review，希望发现问题，总结教训，避免下次再踩坑。
出现的问题
通过梳理，我们发现问题集中出现体现在：
1、在上线之前还有需求变更。
2、开发周期估计不足，出现前松后紧的情况。
问题分析
为什么上线之前需求还在变更？
1、异常流程考虑不足
这次负责项目的是一个年轻的产品经理，因为经验欠缺确实存在原型和文档的撰写不够细致和完整，颗粒度不够细。最重要的就是对异常流程考虑不充分，缺乏对异常流程场景的详细描述。开发同学不得不在开发进程中经常停下来询问产品经理，产品经理这时才去考虑异常流程，此前的需求便可能因此不得不进行调整和更改。虽然调整的幅度不大，但是对开发过程的流畅性和效率却造成了一定的影响。
2、需求收集没有找对人
这款产品是一款TO B的产品，为集团内部员工提供的效率提升工具。我们在需求收集中重点收集的对象是集团中上层管理者，一线实际使用者的真正需求被忽视了。虽然大方向没有偏差，但在一些使用细节上却和一线员工的实际场景不一致。这些情况在开发过程中被逐渐暴露出来，也导致了需求变更的频繁。
为什么开发周期估计不足，前松后紧？
1、需求评估是单一和断裂的
在需求评审中，部分开发人员只关心自己这一块业务，没有全面了解整体需求情况。不了解整个项目的完整逻辑和流程。这样的结果是我们对开发难度和工作量的评估出现了偏差，前期比较乐观，随着开发的深入才发现有的节点比较复杂，不得不加班加点开发。
2、对外包把控的失败
前期我们是准备让外包主要负责项目的开发，我们自有人员只投入1.5人力。实际过程中，外包方更多的是考虑尽快完成项目，而没有去考虑项目的整个流程和扩展性，采取的一些开发方法虽然可以完成整个项目的开发，但是会对我们后续开发和维护带来更大的问题。同时沟通的效率无法保证，因此我们最终只好自己投入开发，前期外包写的内容基本被重构，前期的开发周期相当于浪费了。
如何改进
1、产品经理文档要更细致，不能只考虑正常流程，也要考虑异常流程。每个功能不仅要考虑顺利的情况，还要考虑各种异常分支，并进行相应的提示说明或跳转等操作。
2、需求收集必须针对实际使用者。谁是真正的使用者，我们必须了解他们的工作、生活和学习的相关场景。不仅仅要了解管理层对于宏观业务的需求，也需要实地了解一线使用者的个体（或群体）要求。
3、需求评审所有开发人员都要参加。每个人不仅要了解自己所负责的开发模块，也要对整个项目的逻辑和模块都了解清楚。这样开发周期的评估才是全面和立体的，提高整体开发效率。
4、外包的正确打开方式，自主开发人员确定开发方法和规则，外包人员按照规定开发代码并提交我们验收。
反思还在继续：
这是我们团队第一次和传统实体行业合作，过程确实存在诸多困难甚至是痛苦。我们以往坚持的MVP原则似乎在传统行业面前碰了壁。我们计划先切入A功能，以后再逐步迭代到完善版本。可是线下工作人员这一块却更倾向直接用一个完整的全功能版本，对于不完善的版本他们兴趣很低。一个MVP的版本虽然可能部分解决了某些问题，但是短期内他们却可能因此在两个系统内工作，对于他们的效率可能短期内反而是降低的。
这一点困扰我很久了，除了双方对彼此工作方式的不了解以外，还有什么原因？如何找到两者之间的平衡？也希望各位看官给支支招。
