编辑导读：复盘是每一个优秀的职场人都应该具备的一项技术，产物司理也不破例。本文作者以一份B端产物上线为例，从流程和心态见识两方面举办复盘，但愿对你有辅佐。

本年6月由于公司需要，作为B端产物司理人，参加设计并上线了一款B端新APP产物，用于给公司业务部分及销售人员提供销售及打点处事，并回收了试点 *** 举办优化和淘汰问题影响面，今朝仍在试点中。

这两天想了下，照旧有须要思考下由新APP产物试点引申的一些流程上和心态见识问题，也算对将来的一个警戒，争取慢慢优化。因此总结分享给各人，无论是B端产物司理，照旧前、后端产物司理或项目司理、牵头方等，供小我私家参考吧。

今朝固然新APP作为IT部分来说算上线乐成，业务线率领同事也承认了各人的艰苦，但实际用户口碑、利用结果大概并不是十分抱负，假如业务部分就是投资的客户，我们就是促进客户乐成的相助方，而不光单是IT系统的上线乐成，也许能总结些履历，下次制止并做得更好。

一、好的履历

上线1个多月前各人便完成了任务细化分工、责任到人、细化都操纵步调，以及宣布、验证打算、权限收集、范畴、验证账户、业务方支持人员等梳理，充实的筹备使恰当天晚上进级十分顺利，没有姑且性的重大问题。提前筹备、细化、思考清楚确实十分重要。

提前做好了试点期间布置，包罗风险法子、问题处理惩罚优先级、主干人员上线当晚与第二天的主备替换等其他资源协调及风控，十分乐成，职责清晰明白，认真对应模块的人也能立马跟进并优先处理惩罚核盘查题。对IT项目来说十分乐成。

二、潜在问题——系统方面 1. 部门荣幸心理与判定不全

任务拆解后，小我私家认真本身模块，但在开拓细节和测试上因人而异，小我私家判定全面性有限，受制于对需求配景、目标、系统定位、用户等的领略，容易呈现逻辑裂痕、成果毛病、或倒霉于出产查对，造成非凡场景产生问题、运维查对的坚苦耗时增加。

测试措施爱你的部门偶发性问题，容易被认为是随机事件（ *** 欠好、测试情况不不变、手机问题等、很偶然呈现），在时间要求下大概直接跳过。

大概的心态：本身看了没问题，测试没问题，那出产应该不会有问题，有问题了再办理，假如能群策群力一开始就只管理清楚也许能制止一些问题。

2. 出产情况的敬畏心不足

出产就是出产，出产的本质就是只管不要产生问题，要么问题不致命、要么有快速替换方案，更不该该习惯性出产有问题再办理，为什么一开始没发明？

出产数据也该当有所敬畏，为了试点问题的办理要求修改打卡时间和范畴（为什么不消测试情况？大概因为不顺畅导致出产验证更便捷更快），出产验证脏数据也一直暂未处理惩罚。

公道的做法是修改数据前，评估修改影响面实时间是否符合，验证完后最快速度恢复兴状，测试情况至少有一套能快速设置和验证问题。

3. 小我私家抉择面较大

任务拆解后，重要的开拓细节逻辑设计，小我私家大概部门判定不全，测试组也只管看到外貌功效，难以深入看到背后数据变革判定是否正常。不像之前做条约监控，有 *** 会议评审流程，配合指出漏思量的环境，其他人也能熟悉熬炼思维，而不是本身抉择所有细节逻辑后测试没问题就上线，导致出产未思量的问题产生、缺少部门运维查对数据、跨系统运维巨大度晋升等。

一种更好的要领，较重要较巨大的逻辑设计，更好公示出来，由各人配合判定，提出疑问，设计由小我私家做，但要理清楚逻辑细节，制止裂痕（离散型需求的逻辑思考 *** 可参考我的《从考勤打点需求说起，聊聊场景的思维“东西”》）。

4. 邮件优美的外貌下是暗流涌动

邮件内容是优美的，都不肯意袒露问题。但背后看不见的是问题的姑且性处理惩罚、次数写死，测试的偶发问题，有人提醒却没获得重视，仿佛1人要说服其他人一样坚苦，于是只能放弃，缺乏影响范畴和致命性阐明。

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

5. 暂缺进一步优化节拍

到今朝为止10多天，暂未传闻有上线前可能上线后的主要优化打算，部门优化法子也是有意思，之前考勤定位回收的百度插件，功效新APP上线呈现偶然异常，找不到原因就换成了高德，那旧APP用百度同样的插件为什么就没问题，是否有足够的评估和来由？换了第三方就100%必然行？是否完整评估过？