10月29号，店员任务一期在匆忙中上线了，这个项目起始于8月24号开始（写系分），到10月29号（上线），前后2个月多月，目前算是告一段落。因为项目功能比较多，状况也多，所以专门开一篇文章来总结下。
业务背景
因为涉及公司业务细节，这里就不描述了，一句话，客户需要提高店员的工作效率，产生了这个业务需求。
需求分析
产品经理列的需求大而全，但许多细节没讲，我和一个同事A参与了需求评审，但我们俩因同时在参与其他项目，所以没有花很多时间投入到需求分析中，对需求中的一些细节问题没有及时发现或提出，这也直接给后面的系分和开发埋下了坑。另外要提的一点是这个项目的上线时间是倒排的，所以在需求功能不变的情况下，只能压缩研发时间。
系分设计
系分直接由同事A负责，我只花了一部分时间参与问题的讨论，所以系分设计的整体情况我不是很清楚，也对后面的开发人天评估有一些影响。
开发
考虑到有的研发同事在忙其他项目，这个项目当时安排3个人参与（包括我，但我只负责里面的一部分小功能），后期需求变更，又加入了另外的2个同事参与开发。总体上是按系分的设计来开发的，但开发过程中遇到很多问题，与产品经理讨论后，当场或第二天订方案，导致实际要做的需求比之前的需求评审要复杂很多。
测试
转测后，测试出来的问题很多，包括需求里不明确的地方，测试反馈给产品经理后，又是当场或第二天订方案，然后接着开发接着测，所以过程很累。另外说一下测试情况，参与测试的人员只有一个，而且在十几天的测试过程中，并没有在前期把大部分问题测出来，导致后期还是有很多问题测出，测试人员和开发人员都很累。
上线
本来按照预定的日期上线，结果当天晚上还测出好几个问题，和项目经理沟通后，决定第二天上午上线。上线后，在线上环境也出现了一些小状况（比如测试环境数据少，线上环境数据多，导致个别接口耗时长），但总体还算顺利。
总结
1、需求大而全，细节不清晰（虽然开发后期砍掉了一些需求，但开发已经在系分设计和开发阶段花了很多时间在所有需求中）。改善方法：基于需求，一定要让产品经理列出所有细节，我应该组织列出每个功能点的开发人天，然后比较实际参与人数和转测日期，向项目经理和产品经理强烈反馈要删减次要功能，而不是到后期实在做不完了才提，这时开发人员比较疲惫。 2、需求细节一定要让产品经理列清楚，不能直接按流程图、原型图讲完基本算事，需求文档列的太粗糙。在需求分析阶段一定要让产品经理列出所有细节，不然开发人员不介入。
2、需求后期多次变更：因产品经理（新来的同事，业务不熟）根据实际业务场景的理解后变更一次，外部团队推荐一种方案后对需求再次变更，导致开发逻辑多次变更。改善方法：需求评审时及时说清楚，如果需求有变更，要加研发时间。
3、上线日期倒排，导致研发时间受限。改善方法：一定要根据自己掌握的研发资源建议需求分期完成，而不是妥协或频繁加班。