投诉判责拆分小需求总结
投诉判责拆分小需求总结
需求评估
对于一个小需求的评估很容易只从FRD里面的描述来拆分功能点，然后评估一个大概的时间。这样评估出来的时间很难准确，我总结了一些，接到一个小需求评估首先考虑三点：
第一，这个需求影响的产品线有哪些？后续可能需要和哪些相关方沟通。这点非常重要，如果对于外部影响到了后期才考虑到，会使得后续整个开发陷入被动之中。
?
第二，这个需求列出的改动点是否会对现有业务有影响，包括流程上的，数据上的影响。如果是流程上的，需要考虑修改已有代码的时间，如果是数据上的，需要考虑数据库变更以及数据订正所花费的时间。
?
第三，需要考虑这个小需求的最终开发人员的配置，开发人员是否是100%投入到开发中，开发人员是否对于以前的业务非常熟悉，如果评估的的时候无法确定，在实际开发的时候需要review一次。
?
最后考虑的才是这个FRD里面描述的新增功能点，对新增功能点的评估，应该把自测时间和沟通时间考虑进去，自测时间最好单独放在在所有功能点评估时间之后，并在开发计划中体现出来，这样能让开发在潜意思里面有单独的自测时间做测试，而不是在每个独立的功能点完成之后做测试，这样的自测质量更高。
?
设计
对于小需求的设计和新项目设计最大的区别是：小需求需要考虑对已有流程的兼顾和评估，有时候为了平衡开发成本，需要做一些妥善，前提 是不做猥琐的事情。比如在这次小需求中，把工单状态“处理中”拆分成“处理中未结案”和“处理中已结案”，从技术设计角度要完美一些，但是从对这个小需求的影响满来说成本非常大，直接导致了外部系统CRM也需要修改，对于流程状态这种变更前期要非常谨慎，设计的时候必须做好评估，设计的时候时刻记住每次新增或修改一种状态对于原有的系统是否有影响。
?
开发
在修改已有代码的时候，不要盲目自信，一定要搜索所有代码，防止有遗漏的地方。
?
需求变更
一旦在开发或测试阶段发生有需求问题前期没有考虑，一定要冷静，三思而后行。考虑清楚对于是否是业务上出现没有漏洞。如果有必要，最好立即找PD,QA,开发一起开发讨论，开会讨论之后的结果一定要记录下来发邮件通知大家，避免后续出现理解不一致的情况。
?
测试
在提交aone之前记得通知一下团队中的开发提交代码。
对于aone上合并了新的分支之后最好通知一下团队中的开发，避免出现部分开发同学在老的分支下开发。
?
发布
对于小需求来讲，这里发布点主要是考虑数据变更和数据订正的问题。在数据订正之前，首先要考虑，数据订正的量有多大，最好线上查一下数据。其次是数据订正的应用PV量有多大，如果非常高，需要和DBA沟通好，最后是做数据订正的时间点，是做一次数据订正还是做多次数据订正。第一次做需要数据变更和数据订正的小需求最好请有经验PLA和开发review一下。
最后一个小需求完成之后一定做好文档归档工作，小需求有什么遇到什么教训和收获可以多和大家分享一下?
?
?
?
?
