上周我们团队的一款产品可以说是在历经困难之后发布了V1.0版本。版本上线之后，我们进行了一次review，希望发现问题，总结教训，避免下次再踩坑。
      出现的问题

      通过梳理，我们发现问题集中出现体现在：

      在上线之前还有需求变更。

      开发周期估计不足，出现前松后紧的情况。

      问题分析

      为什么上线之前需求还在变更?

      1、异常流程考虑不足

      这次负责项目的是一个年轻的产品经理，因为经验欠缺确实存在原型和文档的撰写不够细致和完整，颗粒度不够细。最重要的就是对异常流程考虑不充分，缺乏对异常流程场景的详细描述。开发同学不得不在开发进程中经常停下来询问产品经理，产品经理这时才去考虑异常流程，此前的需求便可能因此不得不进行调整和更改。虽然调整的幅度不大，但是对开发过程的流畅性和效率却造成了一定的影响。

      2、需求收集没有找对人

      这款产品是一款TO B的产品，为集团内部员工提供的效率提升工具。我们在需求收集中重点收集的对象是集团中上层管理者，一线实际使用者的真正需求被忽视了。虽然大方向没有偏差，但在一些使用细节上却和一线员工的实际场景不一致。这些情况在开发过程中被逐渐暴露出来，也导致了需求变更的频繁。

      为什么开发周期估计不足，前松后紧?

      1、需求评估是单一和断裂的

      在需求评审中，部分开发人员只关心自己这一块业务，没有全面了解整体需求情况。不了解整个项目的完整逻辑和流程。这样的结果是我们对开发难度和工作量的评估出现了偏差，前期比较乐观，随着开发的深入才发现有的节点比较复杂，不得不加班加点开发

      2、对外包把控的失败
      前期我们是准备让外包主要负责项目的开发，我们自有人员只投入1.5人力。实际过程中，外包方更多的是考虑尽快完成项目，而没有去考虑项目的整个流程和扩展性，采取的一些开发方法虽然可以完成整个项目的开发，但是会对我们后续开发和维护带来更大的问题。同时沟通的效率无法保证，因此我们最终只好自己投入开发，前期外包写的内容基本被重构，前期的开发周期相当于浪费了。

      如何改进

      1、产品经理文档要更细致，不能只考虑正常流程，也要考虑异常流程。每个功能不仅要考虑顺利的情况，还要考虑各种异常分支，并进行相应的提示说明或跳转等操作。

      2、需求收集必须针对实际使用者。谁是真正的使用者，我们必须了解他们的工作、生活和学习的相关场景。不仅仅要了解管理层对于宏观业务的需求，也需要实地了解一线使用者的个体(或群体)要求。

      3、需求评审所有开发人员都要参加。每个人不仅要了解自己所负责的开发模块，也要对整个项目的逻辑和模块都了解清楚。这样开发周期的评估才是全面和立体的，提高整体开发效率。

      4、外包的正确打开方式，自主开发人员确定开发方法和规则，外包人员按照规定开发代码并提交我们验收。

      反思还在继续：

      这是我们团队第一次和传统实体行业合作，过程确实存在诸多困难甚至是痛苦。我们以往坚持的MVP原则似乎在传统行业面前碰了壁。我们计划先切入A功能，以后再逐步迭代到完善版本。可是线下工作人员这一块却更倾向直接用一个完整的全功能版本，对于不完善的版本他们兴趣很低。一个MVP的版本虽然可能部分解决了某些问题，但是短期内他们却可能因此在两个系统内工作，对于他们的效率可能短期内反而是降低的。