项目总结-重大客情

重大客情项目利用了较少资源解决了高频的客户投诉问题，这是该项目不别于其他项目的主要特点。 需求方是大领导，用户较特殊，这个功能的上线竟然出现一波三折，第一次上线是周五晚上，第二天被领导指出不能用，被迫下线。
当接到这个消息的瞬间，我是多么的惊讶，同时也是头一次遇到功能上线后第二天就下线掉了，产品经理对功能的可用性和需求方的要求匹配性预估上出现了偏差。可事实是只有真正的用户才能衡量出到底可用不可用。为了以后方便回顾项目，吸取经验，复盘下整个项目的目标，问题，及如何及时止损。

一、需求分析
1，需求背景与等级
专业客服人员处理客户投诉问题，该类投诉问题不同于一般的客服问题。对该需求我们专门定制了一个重大客情的功能。
要处理该客服问题，接待人员的素质要求至少包含如下

素质模型.png

从影响范围来看，投诉的客户是公司批量的高净值客户，投诉客户数量相对有一定规模，如果处理不好会影响客户跟公司之间的关系，对公司品牌形象造成一定影响。因此该需求等级高于其他需求；

角色模型.png
2，需求目标
要解决的问题：
减少客服人员搜集客户信息及产品信息的麻烦，用系统代替在微信来回发信息的方式，实现客情操作的电子化系统化。
整个项目都是围绕能尽早让需求方使用上能用、好用的系统为目标。

二、项目实现
1，项目时间
从技术人员给到的时间，加上个人评估，第一次上线时间锁定在周五，从上线质量来看效果并不很理想。
之后的迭代基本按照开发人员给到的时间按时保质保量去执行。
2，版本迭代
小版本快跑，第一版上线后跌跌撞撞，紧接着的周一重新迭代后基本完成了提交工单的功能；之后的迭代围绕工单的预约，编辑，拒绝等考虑了更多的情况。
3，出现的问题
1）上线了，需求方反馈不能用。
2）第一版项目时间前松后紧，后几个版本吸取教训按照技术人员给的时间来实现，其中有一原因是后面的迭代多是优化，不像第一版时间要求高；
3）需求与实现的匹配性的把关，上线后有些小bug遗留；
4）需求描述的颗粒度不够详细，有些在需求宣讲的时候能指出，有些到了实现阶段才发现，比如预约时间中的未来两周时间的解释
解释一 很类似购买火车票，未来一定的时间内时段占满了，那么当前时间点就不能预定了。要换个时间点试试，查询是否有余票。
解释二 未来的可预约时间是无限的，也就是任何一个理财师过来预约时间，接待人都有时间接待，接待人的排期表可能会无限长。期限无限长是一种极端情况，但满足理财师预订上两者并无多大区别，在现实情境中让一个理财师能预约上哪怕时间安排在两周后也是能解决些许问题的。
4，项目组协调
项目组人员能动性极强，加上项目人员少，协调快速方便

三、项目总结
系统功能好与坏的评判标准是需求现状与功能的匹配性高，扩展性强。完美的功能如果不与现状匹配，只会让操作更繁琐。在使用中持续优化。
本次需求对接时有几次是产品技术直接与需求方谈，对需求、要求、细节都提出了自己的疑惑，这样在需求阶段项目成员对需求的理解很快达成一致，即使有不明确的细节，沟通之后进行了再次确认 。为了让彼此更精进，也为了对项目合作进行一次写照，特写此次项目总结。
马云爸爸曾经说过，“一个小孩生下来长得都一样，谁要是说长得像他妈像他爸，那纯粹是放屁。后期喂养细心照料，孩子长得越来越漂亮讨人喜欢”。
嘿嘿，迭代持续进行中......欢迎小伙伴们补充交流
2018.10.22