一份B端产品上线的深刻总结，不要再走弯路！思维导图

任务拆解后，个人负责自己模块，但在开发细节和测试上因人而异，个人判断全面性有限，受制于对需求背景、目的、系统定位、用户等的理解，容易出现逻辑漏洞、功能偏差、或不利于生产核对，造成特殊场景发生问题、运维核对的困难耗时增加。

测试程序爱你的部分偶发性问题，容易被认为是随机事件（网络不好、测试环境不稳定、手机问题等、很偶尔出现），在时间要求下可能直接跳过。

可能的心态：自己看了没问题，测试没问题，那生产应该不会有问题，有问题了再解决，如果能集思广益一开始就尽量理清楚也许能避免一些问题。

生产就是生产，生产的本质就是尽量不要发生问题，要么问题不致命、要么有快速替换方案，更不应该习惯性生产有问题再解决，为什么一开始没发现？

生产数据也应当有所敬畏，为了试点问题的解决要求修改打卡时间和范围（为什么不用测试环境？可能因为不顺畅导致生产验证更便捷更快），生产验证脏数据也一直暂未处理。

合理的做法是修改数据前，评估修改影响面及时间是否合适，验证完后最快速度恢复原状，测试环境至少有一套能快速配置和验证问题。

任务拆解后，重要的开发细节逻辑设计，个人可能部分判断不全，测试组也尽量看到表面结果，难以深入看到背后数据变化判断是否正常。不像之前做合同监控，有会议评审流程，共同指出漏考虑的情况，其他人也能熟悉锻炼思维，而不是自己决定所有细节逻辑后测试没问题就上线，导致生产未考虑的问题发生、缺少部分运维核对数据、跨系统运维复杂度提升等。

一种更好的方法，较重要较复杂的逻辑设计，最好公示出来，由大家共同判断，提出疑问，设计由个人做，但要理清楚逻辑细节，避免漏洞（离散型需求的逻辑思考方式可参考我的《从考勤管理需求说起，聊聊场景的思维“工具”》）。

邮件内容是美好的，都不愿意暴露问题。但背后看不见的是问题的临时性处理、次数写死，测试的偶发问题，有人提醒却没得到重视，好像1人要说服其他人一样困难，于是只能放弃，缺乏影响范围和致命性分析。

于是生产发生了“偶发性问题”，再吭哧吭哧的回头排查原因和修改，确实很辛苦也很尽心，但，也许一开始就引起重视，或者先记录后续主动跟进优化，也不至于被动响应用户，每天小心翼翼的担心别出问题。

到目前为止10多天，暂未听说有上线前或者上线后的主要优化计划，部分优化措施也是有意思，之前考勤定位采用的百度插件，结果新APP上线出现偶尔异常，找不到原因就换成了高德，那旧APP用百度同样的插件为什么就没问题，是否有足够的评估和理由？换了第三方就100%一定行？是否完整评估过？

另外切换成新的第三方插件包后，为什么没做详细测试？百度与高德由于坐标基础体系的参照不同，在定位获取上存在经纬度偏差问题就没有人想到过？想当然参数对就不会有错，先上线再说的心态是否属于侥幸心理？

再者，打卡性能优化、新APP切换优化、提示语优化可能还有待安排计划，不然只能通过强制的方式要求用户使用新APP，这可能不太符合互联网式思维，也可能降低用户动力、增加心理负担。新APP本身设计美观、快捷、更人性化（也许以后会有），就应该打出自己的特色来吸引用户。聆听用户声音，优化可能是常态。

由于战略需要，目前是按照职能划分小组而非项目产品线。开发人员在一块、需求人员坐一起、测试人员围一圈，运维人员独立开，按职能割裂，导致开发人员需要的信息在需求和运维处，开发只能根据文档制作，最终效果可能并不是客户所想要，测试只能根据文档测试出明显界面和功能异常，难以理解背后数据的变化和流转异常，运维在背负用户催促压力的同时也无从下手，最终导致所有人都在催开发人员的进度、问题处理进度、质量不够好等，用户嫌运维处理不够快，客户嫌需求太慢，测试回复开发有问题后就可以不管，缺少了整体联动性。

这种组织下，谁也不愿意多考虑一步，也不方便插手别的小组工作，划分职责界限的后果就是，任何事情分清责任后，只负责各自模块，其余的流程推进、问题排查、整体性优化都难以提升效率。

即使由产品经理逐步开始牵头整体流程，但由于权限、跨组、岗位要求难以真正牵头，现象仍然存在。这种割裂组织在沟通和理解上容易产生偏差并扩大，因此协调处理时效性下降，用户体验下降，虽然专注力得到提升，但容易造成职能割裂，很简单快捷的小事也被流转拖延。

口碑维护不光是运维的工作，还有需求、开发、业务同事的共同支持。但这次试点仍然是问题答疑式思路，并没有看到口碑的维护。

试点的目的也许除了确保新APP功能的可用和顺畅，让用户来验证发现问题外，还应当与试点用户形成良性互动，成为新产品的间接代言人，辅助口碑宣传和推广，而不是完全依赖自上而下的强制性要求使用。就像家长与青春期的孩子，没有孩子喜欢总是被强迫、被管理，哪怕为他们好，尤其是自由业务员，激发、鼓励、理解、共同参与感也许更有效。

目前试点群更多同其他微信问题群一样，群里官方式解答，问题在群里被放大，没有影响面解释、现象解释、协助内勤主动登记补打卡、切换旧APP等临时性措施，导致业务领导认为新APP稳定性极差，群里天天是问题，用户以为自己是使用顺利的个例，原来系统问题这么多，就更没有用户口碑、用户鼓励、对新APP的认可、界面的美观、对付出结果的肯定了。

用户情绪未有效照顾到，试点用户是协助我们发现解决问题以及试用反馈，他们最担心因为试点问题导致打卡失败工资扣款，所以8点半是个敏感时间（8点半是上班打卡时间，迟到、打卡失败影响出勤率），情绪容易波动、抱怨，除了标准式解答外，缺少交流、沟通、安抚，理解感受，让用户放心有补打卡，并解释互相理解后重拾信心，共同参与解决问题，聆听建议，反馈操作习惯，才能提升更高的参与感和信息收集。

问题处理后也可以第一时间告知指定用户，有反馈、有聆听并采纳，才被尊重，才有意愿提其他建议和问题，反馈很重要。

紧急打不上卡时可切换回旧APP打卡措施未启用，而只是上报给内勤，试点内勤的压力可想而知，比原来增加更多工作量，以及业务员可能骗补卡给内勤带来的压力（上报原则？证据？要求？都没有，业务可不一定想这么细致，出了钱就希望我们能帮忙解决问题）。

以及下载、安装等紧急措施是否执行顺利，有机会做个回顾总结能避免下次的手足无措，紧急措施也许更符合实际需要。

（由于数据敏感，不方便放上来，实际根据数据趋势需要做细化分析）

例如截止7月15日，试点范围的半月累计打卡人数N万，至少有一次打卡成功的有N/3万人，而在试点实施前的近两个月内，半月累计打卡人数基本为2N万人左右。于是发现了自从试点后，试点范围的打卡人数远低于试点前的打卡量。

7月2日到7月3日锐减，是因为业务工作安排原因？还是业务员利用试点期间的异常补打卡规则或其他原因而不出勤？补打卡规则应该有要求：只能登记当天结果，以照片或当面方式证明人在现场，避免规则漏洞。

由产品经理牵头开发与需求人员做需求设计，个人可以设计细节逻辑，但需要邮件发到同组人一同查阅，或组织会议说明思路，避免个人盲点，发挥不同人的理解与经验，吉意保这块逻辑我可以协助分析，排查开发漏考虑的潜在场景。

产品经理牵头，需要需求人员传达文档时，介绍需求背景和业务大致目的，理解后的设计才是符合业务心里需要的设计。以共同的需求目的结合文档来开发、测试、运维（一点发散状），比仅以文档为标准和理解的开发流程更不容易走偏。

无论开发、需求、测试、运维等人提的优化建议，都应当有合理的分析，并能说服大多数人认可（得到用户认可更佳）。

抓住需求背后的目的，并以最终收入和利润（降成本）为价值衡量标尺，为客户提供合适综合方案和长期规划供选择。开发过程随时确保相关人员理解需求背后的目的再行动，再设计，避免走偏、重做、不合需要等（客户花钱买服务和产品，是为了渠道能收入更多）。

业务员永远是来赚钱的，业务员的产品服务需要更简洁直观、收入清晰、帮助促进销售等理念（如获客工具、打消顾客疑虑等所有能促进成交收入的服务）。顾客因人群而异，但公司的目的是促进顾客转化成交更多业绩收入。

机构内勤是想尽量减轻工作量、提升效率、满足领导和制度管理要求。客户则是想了解更多信息以知道该如何调整策略，促进更多收入。用户体验的提升也是为了间接让用户爽，从而激励、促进转化等间接提升业绩收入（培训学习、出勤早会、考试的目的、佣金利益直观反馈等都是）。

针对需求的用户不同，设计的原则理念也不同。业务员用户，满足快捷简单、与我有关、动力促进、付出反馈激励、能帮助促进投保的需要，顾客用户需要分群分析。

机构内勤，满足人工计算替换为系统计算人工核对、无纸化、简单快捷获得想要的结果、问题能快速解决等。客户，满足促进渠道业绩收入的各种工具和产品服务、支持管理需要从而间接提升业绩收入、快速获取信息及方案进展等需要。而不再单单实现提出的文字类需求，考虑更本质。

商业的本质是赚钱，是促进公司业绩收入和利润，所以IT的产品服务直接间接的本质也是为了促进公司收入，只有促进客户、用户、IT 达到3方共赢，客户有收入，用户赚到钱或提升自动化效率或解答了顾客疑虑，客户才更愿意投资，用户才更愿意使用，IT才更能发挥专业价值并获取更多请求，形成闭环。

所以，像大家经常提到的单纯的业务员留存率、人均销售量、人均业绩这类宏而大的统计意义不太大，大而空的用户体验也意义不大，就好比全国人均收入一样，对个人并没有什么价值，并不能发现问题并想出办法解决，反而小组内销售排名、出勤排名、活动排名、销售精英留存率、新人3个月内二次销售率（排除自己购买单）显然更能发现人员健康问题和趋势。

精细化方向可能会越来越明确，基于企业收入本质和相关方共赢的设计理念可能越来越需要。