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

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

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

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

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

一、好的经验

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

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

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

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

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

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

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

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

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

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

3. 个人决定面较大

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

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

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

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

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

5. 暂缺进一步优化节奏

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

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

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

6. gē裂型X的弊端开始出现

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

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

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

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

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

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

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

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

2. 缺乏关怀与wēn度的用户运营

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 设计逻辑公开

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

2. 传达理解需qiú目的目标

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

3. 用户体验的可行性

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

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

1. B端产品的相关方

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

2. 促进客户成功

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

3. 促进用户转化

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

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

4. 促进IT方案本质化

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

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

5. 3方共赢的良性闭环

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

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

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

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

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 一份B端产品上线的深刻总结,不要再走弯路! https://www.xiongfawang.com/1972.html

常见问题

相关文章

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

分享本文封面