以下是我对2016年的反省

　　一、对需要整理的一些“想当然”

　　整理需求的阶段，对需求的描述需要清晰明了。但往往会“想当然”的觉得这个需求本来规则就有，开发应该知道怎么做。从而需求描述个大概，没有细节描述。

　　合同改版的时候，我觉得合同就是我们能拿到什么数据就显示什么数据。但测试阶段我们发现，因为添加了查看步骤就要参考合同签约方式。合约签订日期以及每个阶段显示什么数据，都有时间性的规则。这是改版之前没有的规则。因为所谓的“想当然”就应该这样，导致测试阶段开发的修改任务加重。

　　二、对需求流程管理的一些“想当然”

　　需求流程管理上我“想当然”的认为，迭代评审会上，我们把需求讲清楚就可以开发了。事实上我一直是这么做的。但是下半年产品部独立，开始放手让新人自己去整理需求和设计、特别是有交互设计师和产品经理的配合组合。迭代评审会上测试和开发对需求和设计本身提出了不少建议和缺失点。后续就要去做一些修改，然后再次评审。一定程度上会拖延开发时间。

　　接下来我们需要重新定义评审会，在产品需求阶段，先有需求评审会，需求评审会必须在上个迭代结束之前开启。上个迭代结束后开始迭代评审会，使每个迭代衔接更顺畅。

　　三、对团队管理的一些“想当然”

　　团队管理可能对我来说是一个新课题。因为我们互联网行业讲究的是团队协作和扁平化管理。在产品部里面我们所有同事其实就是对一个大项目（红天桃）细分成各个小板块，用迭代流程去完成里面的各个组成部分。所以在我的概念里，只要有迭代流程，大家各自就可以运作。

　　但事实上，计划的变更要及时掌握；流程的合理性要去跟踪，临时任务需要分配。部门还需要核查机制，迭代文档核查，任务计划执行情况核查。

　　所以我们除了需要一个工作流程，还要有很多配套的机制去管理这个流程是否顺利推进。这是一个课题要去研究，而不是我想象的流程是这样他们去做应该就没有问题了。