做好版本迭代管理,给团队一颗糖

健壮的大姐姐

共 6016字,需浏览 13分钟

 ·

2021-05-13 09:43

作者 | 林壮壮

来源 | 健壮的大姐姐(ID: is_strong)

本文5500字左右,阅读时间12min.


自春节到现在,我陷入一种困境里:突然间,我好像成了“夹心饼干”?
事情是这样的,由于业务变动,最近我开始负责一个核心产品的版本迭代管理。我敞开心扉拥抱变化,但两个月下来,事情比我想象中更棘手。

先交代下背景,在我之前的工作经历里,我和前线的团队交涉比较多,销售、售前架构师、产品架构师、服务商、ISV,都相对比较熟稔。熟稔到什么地步呢,就是他们跟我说声hi,我都几乎能料到他下一句话想问什么、想要什么,我可以怎么推杯换盏地应对他们。
和他们在一条船上久了,我深谙支持项目有多不易,我理解客户对产品的诉求有多急切,也愿意尽最大努力去争取产品研发的资源投入。

但是,一切开始不一样了。自打我接手产品研发工作,开始负责产品整体规划和版本迭代管理后,我多了一重身份。随着我深入了解产品的细节,了解看似简单实则不易的需求背后沉淀了这么多研发、测试的人力后,我不得不站出来为产品研发团队说说话了。

这也就导致,我清楚客户需求的合理性和迫切性,但我也在警惕产品研发资源的不合理占用。于项目团队而言,作为产品接口人的我开始谨慎承诺,小心防守;于研发团队而言,作为项目经理的我抱着一揽子需求回来,生怕我狮子大开口。

里外不是人了不是?我反思过,是不是该去学一学怎么端水?
把情绪放一放,我给自己一个版本的试炼机会,也趁此摸清楚了项目支持和产品管理的平衡之术。

我和其他团队的产品经理聊了下,有些同学一开始就是走产品策划路线,始终站在产研的角度,专心琢磨如何让产品做得更好;有些同学一直都是在客户现场,或是出差去现场的路上,他懂行懂客户,能根据客户需求拟制解决方案。
其中不乏有产品经理负责版本迭代管理,但总会遇到各种各样的问题,怎么去权衡各大项目反馈的需求优先级?怎么应对空降的需求带来的资源占用?怎么让前线团队放心、让研发团队齐心呢?

不少团队都倾向于将产品研发管理专门交给项目经理去负责,由项目经理协调产品、设计、研发、测试的资源,并跟进整体版本迭代的进展。这的确权责分明,产品做需求,开发写代码,各司其职,何乐而不为?

可事实上,版本管理的重点不在于由产品研发团队中的哪个角色来承担,关键在于如何去管理这个版本。既然团队内暂时没有这样的角色来支撑,那么我大可以利用自己的多重身份“夹带私货”,不是吗?
 


一、不仅是规划版本
规划版本前先规划产品roadmap。
为什么前线项目组总是源源不断地投递需求?——我要斩断不重要不紧急的客户需求;
为什么研发同学总是下意识拒绝需求?——我要调动产研资源实现优先级最高的产品能力。
从客户需求到产品能力之间是有Gap的,我要搭桥造梁,就需要一个支撑。

那么,怎么规划产品的阶段性里程碑?

1、从团队KPI入手:今年团队的考核目标是什么,是产品收入?用户活跃度?标杆案例数?项目的复制情况?

2、制定个人OKR:基于团队的目标,落实到个人所负责的产品目标,去看在该目标下你要输出的关键结果是什么。比如你们考核的是要在全国范围内树立至少2个国家级标杆项目,那么对应的这类型项目最关注的需求场景是什么,为了满足这样的需求场景,产品要实现哪些能力,配套提供哪些服务支持;

3、KANO模型:这是东京理工大学教授狩野纪昭(Noriaki Kano)发明的对用户需求分类和优先排序的工具,需求分五类:基本型需求、期望型需求、兴奋型需求、无差异型需求、反向型需求。


1)基本型需求(必备型需求):客户认为必须有,没有的话这个功能就不具有交付意义的需求。针对这类需求,一旦你没满足客户,客户的满意度将一落千丈,你可能马上就要被踢出局。比如顾客买一个保温杯,它能正常装热水,顾客不会为此感到满意,但如果这杯子有裂缝,杯盖拧不紧,或是保温效果差,那么顾客对这个杯子的满意度就会明显下降,投诉接踵而至。

2)期望型需求:客户期望你可以实现的需求,一旦你实现了,客户满意度会显著提升,你提供的产品超出客户期望越多,客户就越满意。但相应的,如果你拒绝满足客户需求或是表现不好的话,客户也会立马提出不满。比如客户期望贵司提供的问题响应机制可以更快捷,故障处理可以更高效,那么一旦你优化了问题处理流程,提高对客户的响应效率,客户就越满意。

3)兴奋型需求(魅力型需求):客户既不会过分期望,又不会明显不满的需求,即,有更好,没有也能接受。比如早期海底捞向客户推出生日当天全体员工向顾客唱生日歌,这种服务的确会让顾客惊喜,但如果不提供这个服务,顾客也不会不满。这类需求通常能在某些时机打动客户,赢得客户决策人更多的关注。

4)无差异型需求:这类需求对客户没有影响,有或没有都无所谓。这种需求怎么会被人提出来呢,可能是客户对标了不同的产品,或是灵光乍现想到的,这样的需求在应对的时候需要甄别,不必过分投入在这类需求上;

5)反向型需求:该需求会引起大部分人的强烈不满,你实现该需求反而会降低客户的满意度。比如客户管理层提出一些强管理的需求,乍一听很合理,但深究下来,这需求对员工不友好。即便你短暂地满足了客户高层的需求,但长远来看一定会收到客户的投诉,毕竟客户采购软件并不仅限于在管理层使用,更多时候还是为了服务于全体员工。针对这类需求,你且缓缓,先冷静旁观,做好充分的客户需求调研后,再决定是否要做。
 
根据上述三方面,在实际规划产品蓝图时,可以从以下两方面去考虑:
一方面根据团队OKR划定产品方向,圈定几个需要冲刺的功能模块,分月度、季度去迭代功能、做项目验证,再炮制到其他项目中落地;

另一方面摆正心态,正视客户反馈的需求,全力以赴满足基本型需求,重视产品义务范畴内的事项,确保在市场竞争中不丢分。同时,尽力去满足客户的期望型需求,提供大多数客户关注的额外服务和产品,引导客户的决策链对本产品有更多的倾向性;最后才是争取实现客户的兴奋型需求,提高客户用户的粘性和复购率。
 
你看,通过层层过滤,你会发现有不少客户需求其实没那么重要,它并不能为产品的销售有什么催化作用,甚至在占用产研资源后还讨不到一点好处。

 
二、不仅是管理版本
前文提到如何在规划版本前规划好产品阶段性的里程碑,围绕里程碑去规划每个月的版本内容和版本节奏。
但实际上在管理版本中最大的问题不在于做哪些需求,而是什么需求要先做。每一位架构师都认为自己负责的客户提的需求最靠谱,最重要,最紧急,动辄就是“这是某位CTO提的”,“这个需求已经上升到我司的某位高管”之类的……通往产品发布的管道就这么宽,全堵在这段路上,谁也动不了,谁也不想让。
这时候除了根据KANO模型对需求做一层初步的分类之后,每个类目下依然存在不少需求,怎么排优先级?
 
向外看,竞争对手相比你的优势在哪?它推崇的关键标点有什么?研究竞品并不可耻,市场就这么大,池子里的鱼就这么多,为了捕获更多的猎物,取长补短也是顺理成章的。

向内看,你不必把这份责任全部放在自己身上,建立版本评审委员会,邀请领导、产品和研发负责人、前线反馈需求的架构师,共同来评审这些需求的优先级。通过责任公摊和事务公开,形成一个集体公认的版本需求池。

在需求池初具雏形后,你要及时组织产品研发团队开版本启动会,宣导需求池里的所有需求,请产品和研发初步给出工作量的预估。一个版本迭代的周期就这么长的时间,对于比较复杂的需求,适时地拉长阵线去细化产品方案,才能确保不浪费研发的资源。

记住,排优先级时,不可只关注客户需求而忽视了去建设能满足更多客户的核心优势。
 
在明确版本需求和需求的优先级后,我们再来看下如何调动资源投入到版本迭代。

1、资源投入情况
  • 项目经理:负责整体版本规划和需求管理,跟进版本迭代进程,对版本的整体发布负责;

  • 产品经理:负责产品需求的方案设计和评审,负责与设计、研发、测试协作开展需求的建设,对需求的实现情况负责;

  • 研发:负责产品需求的技术方案设计和实现,把控需求的研发进度;

  • 设计:完成需求UI设计和视觉设计,输出设计切图;

  • 测试:输出测试用例,把控需求的质量。       


这些角色在参与版本迭代时都有各自的期望,在不同的环节里都需要换位思考下。
比如研发,最怕产品方案没考虑完全就火急火燎地找上来要技术实现,前期方案的不周全大概率会引发后期需求的变更,这对研发而言就是资源的浪费。
那么站在研发的角度,产品经理对待需求就不能只是在讲一个简单的用户故事,客户需求和产品能力之间的gap有多大,取决于你如何去理解需求,如何去细化需求场景,如何打磨好你的产品。
 
相应的,在版本迭代的过程中,项目经理预留给产品经理思考方案的时间要充分,不能为了满足更多的需求而忽视了产品的细节。产品不可只看细节,也不可全然不顾细节。
不注重各个方面的细节,终究会连累到之前积累的口碑;当所有人都盯着你缺的那一筐土的时候,没有人会关心已经堆好的九仞土山。
 
2、团队机制与过程控制
既然是一个长期工程,那么何不如从一开始就下功夫定流程,定机制,把涉及到的角色的工作地图画出来?
前面提到,我给自己一个版本的时间窗,去印证这个团队机制的可行性。具体流程是什么样呢?


1)明确版本节奏:
一个半月2个小版本1个大版本(ab为小版本,c为大版本),小版本内部测试体验,大版本对外正式发布;

2)规范迭代流程:
a. 建立版本评审委员会,从版本规划开始,做好向上汇报和对内同步,保证信息公开透明。没错,你是版本总体负责人,但你没必要把很多责任往自己身上揽,尤其涉及到需要上升决策的事情,分摊责任也同样是在分摊风险;

b. 版本需求确定后,预留充分的时间给到产品经理调研需求、设计产品方案,并树立一个标杆性事件:开展版本启动会。由各产品经理大体宣讲需求,明确需求的研发负责人,全员投票评估需求的合理性和可行性;

c. 需求进一步得到产品和研发的评估后,产品和研发负责人各自组成feature team,启动对需求的实现之路,再配合设计、测试的资源,让需求在版本发布计划的时间窗内有序地推进,并适时地同步进展和风险,确保需求相关人对需求的理解是一致的。
 
3、加强过程控制
流程是有了,但流程里涉及到的环节比较多,需要抓住最关键的部分加强管控。

一个是需求评审环节这决定了这个需求后续的实现路径,绝不能轻视。对于相对复杂且重要的需求,对于空降的高优先级需求,能不能插队也不是研发或产品或架构师说了算,都必须严格上升到版本评审委员会共同决议;

一个是研发排期环节,版本的发布时间窗是基本固定的,研发排期的评估除了根据需求的优先级、实现的工作量之外,还要根据发布计划的时间点看能赶上哪一个发布计划,以确保给客户承诺的交付时间是相对可靠的;

一个是产品体验环节,不少团队在前期需求设计上严防死守,可一旦步入研发阶段,产品经理除了间或响应研发的问题咨询外,对需求本身的实现过程和实现结果是有点轻视的。
这里需要尤其重视需求研发完成后的产品体验环节,产品经理必须完整地按测试用例走查一遍功能,确保最终的功能与最初需求的设计是契合的。若有偏差,是否要变更或追加需求,则同样的需要引入版本评审委员会(与该需求相关的人员)一起来评估。
 

三、不仅是一颗糖
产品如期发布了,这时候我对前线的架构师是否就有了交代?不够。
回想下,架构师对产品的能力是清晰的吗?他们提的客户需求为什么在不少产品研发同学看来不太合理呢?归根结底是因为项目支持和产品建设脱节了。

两拨人,一拨人忙着做项目,一拨人忙着做需求,各自作战,各自为政。
 
你可能会说,产品做出来不就是为了更好地在项目里售卖和交付吗?没错,但在实际运作的过程中确实存在这样的问题。于是你会发现,前线团队对产品一知半解,产研团队对项目一穷二白。
这是常态,但可以被改变。

回过头来看整个版本迭代流程,你会发现有很多环节完全可以借助前线架构师的力量。
  • 在版本规划初期,项目经理可以请架构师给出有力的项目背景佐证需求的合理性;

  • 在需求调研时,产品经理与架构师的深入访谈,可以更充分地了解需求场景和目标,如有必要也可以跟架构师一起拜访客户;

  • 在需求研发完成转产品体验时,产品经理邀请架构师一起体验功能,确保功能的效果与架构师的预期一致;

  • 在产品发布后,产品经理可以请架构师一同编制功能故事,描述功能的操作路径、实现效果和价值,以便客户更好地使用功能。


整个过程里,前线架构师与产研团队有了更多的互动和融合,这是我们给到架构师的一颗糖,它不仅提升了架构师对产品的理解力,也加深了产研团队对客户的认识。
 
同样的,产品发布后交付给到客户后,这时候我对产研团队是否就有了交代?不够。
很多时候一个新版本从规划到发布,一个多月过去了。这一个月期间,客户也许还在追着要这个能力,也许早已不在意这个需求。但是产研资源也确确实实地投入进来了,他们需要一颗糖,可能不够甜,但总比交付出去下落不明要好得多。

因此我们会要求,前线实施团队交付新版本给客户后,需要主动了解客户的使用情况:有没有用?用得怎么样?有全面推广起来吗?还有其他反馈吗?这些都要定期追踪,了解客户不同层级的用户对新版本发布的新功能的想法,正向反馈负向反馈都好,都要有个交代。

通过这样的交代,一个更加完备的产品故事应运而生,产品经理有更多的实践素材去佐证功能的价值,架构师有更充分的底稿去应对客户的挑战。
 
四、小结
我相信不少成熟的团队必定有自己一套完善的版本管理方法,对于客户需求和产品能力的转化也是运筹帷幄,对此我要恭喜你。
的确,同一个问题会有很多解题的思路,我从这次的事件中也想通一个道理,那就是如何去克制把问题简单化处理的冲动,避免陷入对观点做取舍的二元偏误里。

在对外和前线团队的持续沟通中,我清楚了项目的百种不易;在对内和研发团队的共同作战中,我理解了产品的所思所想。如何去平衡项目和产品,让项目驱动产品的提升,让产品更好地服务于项目,让原本若即若离的两拨人汇聚成一股更强劲的力量,这是我从中体会最深的。

我想,捋完一遍思路后,我大概不需要去学怎么成为水大师了。


 本文由『人人都是产品经理原创激励计划』出品,转载请联系“人人都是产品经理”公众号


 推荐阅读:

欢迎长按二维码关注“健壮的大姐姐”,如果你有一点点共鸣的话欢迎点赞、“在看”或是分享给更多的朋友。
感谢阅读,鞠躬。

浏览 37
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报