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

#本文为人人都是产品经理《原创激励计划》出品。

在团队工作中,产品经理需要身兼多职、兼顾多方意见。而产品版本迭代管理往往需要牵扯项目的多方面。那么,当产品经理着手版本迭代管理工作时,应当如何协调团队工作、做好过程X、进而凝聚团队力量?本文作者便结合其自身经验向我们做出了清晰展示。

自春节到现在,我陷入一种困境里:突然间,我好像成了“夹心饼干”?

事情是这样的,由于X变动,最近我开始负责一个核心产品的版本迭代管理。我敞开心扉X变化,但两个月下来,事情比我想象中得更棘手。

先交代下背景。

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

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

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

里外不是人了不是?我反思过,是不是该去学一学怎么端水?

把情绪放一放,我给自己一个版本的试炼机会,也趁此mō清楚了项目支持和产品管理的平衡之术。

我和其他团队的产品经理聊了下,有些同学一开始就是走产品策划路线,始终站在产研的角度,专心琢磨如何让产品做得更好;有些同学一直都是在客户现场,或是出差去现场的路上,他懂行懂客户,能根据客户需qiú拟制解决方案。

其中不乏有产品经理负责版本迭代管理,但总会遇到各种各样的问题:怎么去泉衡各大项目反馈的需qiú优先级?怎么应对空降的需qiú带来的资源占用?怎么让前线团队放心、让研发团队齐心呢?

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

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

一、不仅是规划版本

规划版本前先规划产品roadmap。

为什么前线项目组总是源源不断地投递需qiú——我要斩断不重要不紧急的客户需qiú。

为什么研发同学总是下意识拒绝需qiú——我要调动产研资源实现优先级最高的产品能力。

从客户需qiú到产品能力之间是有Gap的,我要搭桥造梁,就需要一个支撑。

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

1. 从团队KPI入手

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

2. 制定个人OKR

基于团队的目标,落实到个人所负责的产品目标,去看在该目标下你要输出的关键结果是什么。

比如你们考核的是要在全囯范围内树立至少2个X级标杆项目,那么对应的这类型项目最关注的需qiú场景是什么;为了满足这样的需qiú场景,产品要实现哪些能力、配套X哪些X支持。

3. KANO模型

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

① 基本型需qiú(必备型需qiú)

客户认为必须有,没有的话这个功能就不具有交付意义的需qiú。

zhēn对这类需qiú,一旦你没满足客户,客户的满意度将一落千丈,你可能马上就要被踢出jú。比如顾客mǎi一个保wēn杯,它能正常装热水,顾客不会为此感到满意;但如果这杯子有裂缝,杯盖拧不紧,或是保wēn效果差,那么顾客对这个杯子的满意度就会明显下降,投诉接踵而至。

② 期望型需qiú

客户期望你可以实现的需qiú,一旦你实现了,客户满意度会显著提升,你X的产品超出客户期望越多,客户就越满意。

但相应的,如果你拒绝满足客户需qiú或是表现不好的话,客户也会立马提出不满。比如客户期望贵司X的问题响应机制可以更快捷、故障处理可以更高效,那么一旦你优化了问题处理liú程,提高对客户的响应效率,客户就越满意。

③ X型需qiú(魅力型需qiú)

客户既不会过分期望,又不会明显不满的需qiú,即,有更好,没有也能接受。

比如早期海底捞向客户推出生曰当天全体员工向顾客唱生曰歌,这种X的确会让顾客惊喜,但如果不X这个X,顾客也不会不满。这类需qiú通常能在某些时机打动客户,赢得客户决策人更多的关注。

④ 无差异型需qiú

这类需qiú对客户没有影响,有或没有都无所谓。

这种需qiú怎么会被人提出来呢,可能是客户对标了不同的产品,或是灵光乍现想到的,这样的需qiú在应对的时候需要甄别,不X分投入在这类需qiú上。

⑤ 反向型需qiú

该需qiú会引起大部分人的强烈不满,你实现该需qiú反而会降低客户的满意度。

比如客户管理层提出一些强管理的需qiú,乍一听很合理,但深究下来,这需qiú对员工不友好。即便你短暂地满足了客户高层的需qiú,但长远来看一定会收到客户的投诉,毕竟客户采购软件并不仅限于在管理层使用,更多时候还是为了X于全体员工。

zhēn对这类需qiú,你且缓缓,先冷静旁观,做好充分的客户需qiú调研后,再决定是否要做。

根据上述三方面,在实际规划产品蓝图时,可以从以下两方面去考虑:

  1. 一方面根据团队OKR划定产品方向,圈定几个需要冲刺的功能模块,分月度、季度去迭代功能、做项目验证,再炮制到其他项目中落地;
  2. 另一方面摆正心态,正视客户反馈的需qiú,全力以赴满足基本型需qiú,重视产品义务范畴内的事项,确保在市场竞争中不丢分。同时,尽力去满足客户的期望型需qiú,X大多数客户关注的额外X和产品,引导客户的决策链对本产品有更多的倾向性;最后才是争取实现客户的X型需qiú,提高客户用户的粘性和复购率。

你看,X层层过滤,你会发现有不少客户需qiú其实没那么重要,它并不能为产品的X有什么催化作用,甚至在占用产研资源后还讨不到一点好处。

二、不仅是管理版本

前文提到如X规划版本前规划好产品阶段性的里程碑,围绕里程碑去规划每个月的版本内容和版本节奏。

但实际上在管理版本中最大的问题不在于做哪些需qiú,而是什么需qiú要先做。每一位架构师都认为自己负责的客户提的需qiú最靠谱、最重要、最紧急,动辄就是“这是某位CTO提的”、“这个需qiú已经上升到我司的某位高管”之类的……通往产品发布的管道就这么宽,全堵在这段路上,谁也动不了,谁也不想让。

这时候除了根据KANO模型对需qiú做一层初步的分类之后,每个类目下依然存在不少需qiú,怎么排优先级?

向外看,竞争对手相比你的优势在哪?它推崇的关键控标点有什么?研究竞品并不可齿,市场就这么大,池子里的鱼就这么多,为了捕获更多的猎物,取长补短也是顺理成章的。

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

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

记住,排优先级时,不可只关注客户需qiú而忽视了去建设能满足更多客户的核心优势。

在明确版本需qiú和需qiú的优先级后,我们再来看下如何调动资源投入到版本迭代。

1. 资源投入情况

  • 项目经理:负责整体版本规划和需qiú管理,跟进版本迭代进程,对版本的整体发布负责;
  • 产品经理:负责产品需qiú的方案设计和评审,负责与设计、研发、测试协作开展需qiú的建设,对需qiú的实现情况负责;
  • 研发:负责产品需qiú的技术方案设计和实现,把控需qiú的研发进度;
  • 设计:完成需qiúUI设计和视觉设计,输出设计切图;
  • 测试:输出测试用例,把控需qiú的质量。

这些角sè在参与版本迭代时都有各自的期望,在不同的环节里都需要换位思考下。

比如研发,最怕产品方案没考虑完全就火急火燎地找上来要技术实现,前期方案的不周全大概率会引发后期需qiú的变更,这对研发而言就是资源的浪费。

那么站在研发的角度,产品经理对待需qiú就不能只是在讲一个简单的用户故事,客户需qiú和产品能力之间的gap有多大,取决于你如何去理解需qiú、如何去细化需qiú场景、如何打磨好你的产品。

相应的,在版本迭代的过程中,项目经理预留给产品经理思考方案的时间要充分,不能为了满足更多的需qiú而忽视了产品的细节。产品不可只看细节,也不可全然不顾细节。

不注重各个方面的细节,终究会连累到之前积累的口碑;当所有人都盯着你缺的那一筐土的时候,没有人会关心已经堆好的九仞土山。

2. 团队机制与过程X

既然是一个长期工程,那么何不如从一开始就下功夫定liú程,定机制,把涉及到的角sè的工作地图画出来?

前面提到,我给自己一个版本的时间窗,去印证这个团队机制的可行性。具体liú程是什么样呢?

1)明确版本节奏

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

2)规范迭代liú程

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

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

③ 需qiú进一步得到产品和研发的评估后,产品和研发负责人各自组成feature team,启动对需qiú的实现之路,再配合设计、测试的资源,让需qiú在版本发布计划的时间窗内有序地推进,并适时地同步进展和风险,确保需qiú相关人对需qiú的理解是一致的。

3)加强过程X

liú程是有了,但liú程里涉及到的环节比较多,需要X最关键的部分加强管控。

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

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

一个是产品体验环节,不少团队在前期需qiú设计上严防sǐ守,可一旦步入研发阶段,产品经理除了间或响应研发的问题咨询外,对需qiú本身的实现过程和实现结果是有点轻视的。

这里需要尤其重视需qiú研发完成后的产品体验环节,产品经理必须完整地按测试用例走查一遍功能,确保最终的功能与最初需qiú的设计是契合的。若有偏差,是否要变更或追加需qiú,则同样需要引入版本评审X会(与该需qiú相关的人员)一起来评估。

三、不仅是一颗糖

产品如期发布了,这时候我对前线的架构师是否就有了交代?不够。

回想下,架构师对产品的能力是清晰的吗?他们提的客户需qiú为什么在不少产品研发同学看来不太合理呢?归根结底是因为项目支持和产品建设拖节了。

两拨人,一拨人忙着做项目,一拨人忙着做需qiú,各自作战,各自为zhèng。

你可能会说,产品做出来不就是为了更好地在项目里shòumài和交付吗?没错,但在实际运作的过程中确实存在这样的问题。于是你会发现,前线团队对产品一知半解,产研团队对项目一穷二白。

这是常态,但可以被改变。

回过头来看整个版本迭代liú程,你会发现有很多环节完全可以借助前线架构师的力量。

  • 在版本规划初期,项目经理可以请架构师给出有力的项目背景佐证需qiú的合理性;
  • 在需qiú调研时,产品经理与架构师的深入访谈,可以更充分地了解需qiú场景和目标,如有必要也可以跟架构师一起拜访客户;
  • 在需qiú研发完成转产品体验时,产品经理邀请架构师一起体验功能,确保功能的效果与架构师的预期一致;
  • 在产品发布后,产品经理可以请架构师一同编制功能故事,描述功能的cāo作路径、实现效果和价值,以便客户更好地使用功能。

整个过程里,前线架构师与产研团队有了更多的互动和融合,这是我们给到架构师的一颗糖,它不仅提升了架构师对产品的理解力,也加深了产研团队对客户的认识。

同样的,产品发布后交付给到客户后,这时候我对产研团队是否就有了交代?不够。

很多时候一个新版本从规划到发布,一个多月过去了。这一个月期间,客户也许还在追着要这个能力,也许早已不在意这个需qiú。但是产研资源也确确实实地投入进来了,他们需要一颗糖,可能不够甜,但总比交付出去下落不明要好得多。

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

X这样的交代,一个更加完备的产品故事应运而生,产品经理有更多的实践素材去佐证功能的价值,架构师有更充分的底稿去应对客户的挑战。

四、小结

我相信不少成熟的团队必定有自己一套完善的版本管理方fǎ,对于客户需qiú和产品能力的转化也是运筹帷幄,对此我要恭喜你。的确,同一个问题会有很多解题的思路,我从这次的X中也想通一个道理,那就是如何去克制把问题简单化处理的冲动,避免陷入对观点做取舍的二元偏误里

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

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

#专栏作家#

健壮的大姐姐,微信X号:健壮的大姐姐(ID: is_strong),人人都是产品经理专栏作家。X高级产品经理,专注于To BX项目管理和行业分析,欢迎各路好汉一起探讨。

本文为人人都是产品经理《原创激励计划》出品,未经许可,jìn止转载。

题图来自 Unsplash,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!

4人打赏
收藏 (0) 打赏

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

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

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

雄发创业网 自媒体是如何赚钱的 做好版本迭代管理,给团队一颗糖 https://www.xiongfawang.com/842.html

常见问题

相关文章

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

分享本文封面