店员任务项目总结

    10月29号，店员任务一期在匆忙中上线了，这个项目起始于8月24号开始（写系分），到10月29号（上线），前后2个月多月，目前算是告一段落。因为项目功能比较多，状况也多，所以专门开一篇文章来总结下。

业务背景

    因为涉及公司业务细节，这里就不描述了，一句话，客户需要提高店员的工作效率，产生了这个业务需求。

需求分析

    产品经理列的需求大而全，但许多细节没讲，我和一个同事A参与了需求评审，但我们俩因同时在参与其他项目，所以没有花很多时间投入到需求分析中，对需求中的一些细节问题没有及时发现或提出，这也直接给后面的系分和开发埋下了坑。另外要提的一点是这个项目的上线时间是倒排的，所以在需求功能不变的情况下，只能压缩研发时间。

系分设计

    系分直接由同事A负责，我只花了一部分时间参与问题的讨论，所以系分设计的整体情况我不是很清楚，也对后面的开发人天评估有一些影响。

开发

    考虑到有的研发同事在忙其他项目，这个项目当时安排3个人参与（包括我，但我只负责里面的一部分小功能），后期需求变更，又加入了另外的2个同事参与开发。总体上是按系分的设计来开发的，但开发过程中遇到很多问题，与产品经理讨论后，当场或第二天订方案，导致实际要做的需求比之前的需求评审要复杂很多。

测试

   转测后，测试出来的问题很多，包括需求里不明确的地方，测试反馈给产品经理后，又是当场或第二天订方案，然后接着开发接着测，所以过程很累。另外说一下测试情况，参与测试的人员只有一个，而且在十几天的测试过程中，并没有在前期把大部分问题测出来，导致后期还是有很多问题测出，测试人员和开发人员都很累。

上线

   本来按照预定的日期上线，结果当天晚上还测出好几个问题，和项目经理沟通后，决定第二天上午上线。上线后，在线上环境也出现了一些小状况（比如测试环境数据少，线上环境数据多，导致个别接口耗时长），但总体还算顺利。

总结

   1、需求大而全，虽然开发后期砍掉了一些需求，但开发已经在系分设计和开发阶段花了很多时间在所有需求中。改善方法：基于需求，我应该组织列出每个功能点的开发人天，然后比较实际参与人数和转测日期，向项目经理和产品经理强烈反馈要删减次要功能，而不是到后期实在做不完了才提，这时开发人员比较疲惫。

   2、需求细节一定要让产品经理列清楚，不能直接按流程图、原型图讲完基本算事，需求文档列的太粗糙。在需求分析阶段一定要让产品经理列出所有细节，不然开发人员不介入。

标签：总结,需求,上线,参与,任务,开发,系分,测试,店员
来源： https://www.cnblogs.com/atai/p/15490795.html