一份B端产品上线的深刻总结,不要再走弯路!

1 评论 6161 浏览 31 收藏 20 分钟

编辑导读:复盘是每一个优秀的职场人都应该具备的一项技能,产品经理也不例外。本文作者以一份B端产品上线为例,从流程和心态观念两方面进行复盘,希望对你有帮助。

今年6月由于公司需要,作为B端产品经理人,参与设计并上线了一款B端新APP产品,用于给公司业务部门及销售人员提供销售及管理服务,并采用了试点方式进行优化和减少问题影响面,目前仍在试点中。

这两天想了下,还是有必要思考下由新APP产品试点引申的一些流程上和心态观念问题,也算对未来的一个警戒,争取逐步优化。因此总结分享给大家,无论是B端产品经理,还是前、后端产品经理或项目经理、牵头方等,供个人参考吧。

目前虽然新APP作为IT部门来说算上线成功,业务线领导同事也认可了大家的艰辛,但实际用户口碑、使用效果可能并不是十分理想,如果业务部门就是投资的客户,我们就是促进客户成功的合作方,而不单单是IT系统的上线成功,也许能总结些经验,下次避免并做得更好。

一、好的经验

  1. 上线1个多月前大家便完成了任务细化分工、责任到人、细化都操作步骤,以及发布、验证计划、权限收集、范围、验证账户、业务方支持人员等梳理,充分的准备使得当天晚上升级十分顺利,没有临时性的重大问题。提前准备、细化、思考清楚确实十分重要。
  2. 提前做好了试点期间安排,包括风险措施、问题处理优先级、骨干人员上线当晚与第二天的主备替换等其他资源协调及风控,十分成功,职责清晰明了,负责对应模块的人也能立马跟进并优先处理核查问题。对IT项目来说十分成功。

二、潜在问题——系统方面

1. 部分侥幸心理与判断不全

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

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

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

2. 生产环境的敬畏心不够

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

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

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

3. 个人决定面较大

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

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

4. 邮件美好的表面下是暗流涌动

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

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

5. 暂缺进一步优化节奏

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

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

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

6. 割裂型组织的弊端开始出现

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

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

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

三、潜在问题——用户方面

1. 试点用户口碑未有效维护

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

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

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

2. 缺乏关怀与温度的用户运营

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

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

3. 准备的紧急措施未充分使用的总结

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

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

4. 缺乏数据跟踪分析与策略调整

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

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

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

每天打卡失败的人,是以前一直失败的,还是第1次出现的?是否获取了账号和原因

除了打卡,其他功能使用情况如何?邀约入司、信息查询等是否有其他问题

目前看打卡和IOS安装问题已暴露和优化(IOS企业证书签字及APPStore审核是通病),因此接下来需要更多人来试探压力、并发、时效性等能力,才能进行全国推广。

四、参考建议(初步,暂不展开)

1. 设计逻辑公开

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

2. 传达理解需求目的目标

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

3. 用户体验的可行性

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

五、关于B端产品的用户理解

1. B端产品的相关方

  • 客户:业务部门或甲方,投资以满足他们的目的,即通过对销售渠道、人员管理以及采用任何能促进收入的工具方案,最终提升渠道收入和利润。有的依赖业务员,有的依靠中介机构,有的直接线上销售。
  • 用户:使用产品服务的人,包括业务员(移动端)、顾客(移动端)、机构内勤(PC端为主)、客户自己(PC端为主)。业务员的目的是能出更多单来赚钱,顾客的目的分人群较复杂(见另一篇产品经理的能力方向思考),机构内勤的目的是提升工作效率减少工作量,客户目的就是业绩收入和利润。
  • IT:接受投资,以客户最终目的来拆解阶段目标、结合不同用户的目的和习性,从整体方案设计、确认、实施、测试上线、售后运维等提供一站式打包服务。如何帮助客户,激励用户、促进客户收入。

2. 促进客户成功

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

3. 促进用户转化

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

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

4. 促进IT方案本质化

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

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

5. 3方共赢的良性闭环

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

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

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

仔细想想,是否大家也有这类问题现象?有任何疑问欢迎留言。

 

本文由 @潇杰 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自 Unsplash ,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 作为负责全流程的产品经理,大部分问题我都遇到过,但是当时经验不足,以为是组织流程和管理的缺陷。无意中看到作者的总结,觉得问题的归类和分析还是很有道理的。

    来自广东 回复