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

#本文由人人都是产品经理的“原创激励计划”出品。

在团队工作中，产品经理需要身兼数职，兼顾各种意见。迭代产品版本管理通常涉及项目的许多方面。那么，产品经理在启动版本迭代管理时，应该如何协调团队工作，做好流程控制，进而凝聚团队力量？在本文中，作者结合自己的经历向我们清晰地展示了。

从春节开始，我就陷入了两难的境地:突然，我好像成了“夹心饼干”？

事情是这样的，由于业务变化，我最近开始负责一个核心产品的迭代管理。我敞开心扉去拥抱改变，但两个月后，事情比我想象的还要困难。

先说明背景。

在我之前的工作经历中，和一线团队有过很多谈判，销售、售前架构师、产品架构师、服务商、ISV都相对熟悉。当他们跟我打招呼的时候，我几乎能预测到他想问什么，下一句话想说什么，我推杯换盏怎么回应他们。和他们长期站在同一条船上，我知道支持这个项目有多难。我理解客户对产品有多渴望，我也愿意尽力去获取产品研发的资源。

然而，一切都开始不同了。自从接手产品研发工作，开始负责整体产品规划和版本迭代管理，我获得了一份沉甸甸的认同感。随着我对产品细节的深入了解，以及看似简单的需求背后有如此多的RD和测试人力，我不得不站出来为产品RD团队说话。

因此，我意识到客户需求的合理性和紧迫性，但我也警惕产品RD资源的不合理占用。就项目组而言，作为一个产品接口人，我开始小心翼翼的承诺，小心翼翼的辩解；就RD团队而言，作为项目经理，我带着一包需求回来，生怕自己是狮子开口。

里面不是一个人吧？我想过了。我应该学习如何端水吗？

抛开情绪，我给了自己一个版本的试用机会，也借此机会找出项目支持和产品管理的平衡点。

我和其他团队的产品经理聊过，有同学一开始就走产品策划路线，总是站在产研的角度，专心于如何把产品做得更好；有些同学总是在客户的现场，或者出差去现场的路上。他非常了解客户，能够根据客户的需求拟定解决方案。

负责版本迭代管理的产品经理很多，但总有各种各样的问题:如何平衡重大项目反馈的需求优先级？如何处理空需求减少导致的资源占用？如何让一线团队安心，团结RD团队？

很多团队倾向于将产品研发管理委托给项目经理，由项目经理统筹产品、设计、RD、测试的资源，跟进整体版本迭代的进度。权责分明是真的。产品符合要求，代码的开发和编写都是各司其职。为什么不呢？

事实上，版本管理的重点不是产品RD团队中的哪个角色负责，而是如何管理这个版本。既然队里暂时没有这样的角色来支撑，那我就可以用我的多重身份来“私货”了，不是吗？

第一，不仅要规划版本，还要在规划版本之前规划好产品路线图。

为什么一线项目组总是持续不断地交付需求——我要把不重要的或者紧急的客户需求砍掉。

为什么RD学生总是下意识地拒绝需求-我想调动生产和研究资源来实现最高优先级的产品能力。

客户需求和产品能力之间存在差距。如果我想建一座桥，我需要一个支架。

那么，如何规划产品的里程碑呢？

1.从团队KPI开始。今年团队的考核目标是什么？是产品收入吗？用户活跃度？基准案例的数量？项目的复制是什么？

2.制定个人的OKR团队目标，落实到个人负责的产品目标中，看看在这个目标下你想要输出的关键结果是什么。

比如你的评估是在全国范围内设立至少两个国家级标杆项目，这类项目最关注的需求场景是什么？为了满足这个需求场景，产品要达到什么能力，要提供什么服务支持。

3.KANO model这是东京工业大学教授Noriaki Kano发明的一种工具，用于对用户需求进行分类和优先排序。需求分为五类:基本需求、预期需求、兴奋需求、无差别需求、逆向需求。

①基本需求(基本需求)

客户认为有必要，否则这个功能就不具备交付意义的需求。

对于这种需求，一旦你没有让客户满意，客户的满意度就会一落千丈，你可能会马上被踢出局。比如客户买了一个保温杯，正常情况下可以装热水，客户就不会满意；但是，如果杯子有裂纹，盖子没有拧紧，或者保温效果差，那么客户对杯子的满意度就会明显下降，投诉也就随之而来。

②预期需求

客户期望你实现的，你一旦实现了，客户满意度就会显著提高。你提供的超出顾客期望的产品越多，顾客就越满意。

但相应的，如果你拒绝满足客户的需求，或者表现很差，客户马上就会投诉。例如，客户期望贵公司提供的问题响应机制能够更快，故障处理能够更高效。一旦你优化了问题处理流程，提高了对客户的响应效率，客户就会更满意。

③激发需求(有吸引力的需求)

客户不会期望过高，也不会对需求有明显的不满意，就是更好，没有可以接受的。

比如早期海底捞给顾客推出生日歌的时候，都是员工给顾客唱生日歌。这种服务确实会给顾客带来惊喜，但如果不提供这种服务，顾客也不会不满意。这种需求通常能在某些时候打动客户，赢得客户决策者更多的关注。

④非差异化需求

这种需求对客户没有影响，有没有也无所谓。

这种需求怎么提？可能是客户标注了不同的产品，也可能是顿悟了。这样的需求在处理的时候是需要识别的，不需要对这种需求投入太多。

⑤反向需求

这种需求会引起大多数人的强烈不满，你实现这种需求会降低客户满意度。

比如客户管理层提出一些强势管理的诉求，乍一看似乎合理，但进一步调查，这种诉求对员工是不友好的。即使短时间内满足了客户高层的需求，长期来看也一定会收到客户的投诉。毕竟客户的采购软件并不局限于管理层的使用，更多的时候是服务于全体员工。

对于这种需求，你要冷静观望，做好客户需求调研，再决定是否做。

根据以上三个方面，在实际规划产品蓝图时，可以考虑以下两个方面:

一方面，根据团队OKR明确产品方向，圈定几个需要冲刺的功能模块，每月、每季度进行功能迭代，做项目验证，然后加工成其他项目；另一方面，要摆正心态，正视客户反馈的需求，全力以赴满足基本需求，注意产品义务范围内的事项，确保在市场竞争中不丢分。同时，尽力满足客户的期望，提供大多数客户关注的额外服务和产品，引导客户的决策链对该产品有更多的倾斜；最后，要努力实现客户的刺激需求，提高客户和用户的粘性和复购率。你看，通过层层筛选，你会发现很多客户需求其实没那么重要。它不能催化产品的销售，甚至占用了产研资源后得不到任何收益。

第二，不仅仅是管理层的版本。上一篇文章提到了如何在规划版本之前规划产品各阶段的里程碑，围绕里程碑规划每个月的版本内容和节奏。

但其实管理版最大的问题不是需要做什么，而是需要先做什么。每个架构师都认为自己负责的客户提出的需求是最可靠、最重要、最紧急的，比如“是一个CTO提出的”或者“这个需求已经上升到我们公司的一个高管了”...通往产品发布的管道太宽了，堵在这条路上，谁也挪不开，谁也不想让。

此时，除了根据KANO模型对需求进行初步分类之外，每个类别下还有很多需求。如何对它们进行优先排序？

向外看，竞争对手比你有什么优势？它提倡的关键标点符号是什么？研究竞品没什么丢人的。市场那么大，池子里的鱼那么多。为了捕捉更多的猎物，取长补短也就顺理成章了。

向内看，不必把这一切责任都推给自己，成立版本评审委员会，邀请领导、产品和RD领导、一线架构师一起评审这些需求的优先级。通过责任的分担和事务的公开，形成了一个共同认可的版本需求池。

需求池成型后，你要及时组织产品RD团队召开发布动员会，公示需求池中的所有需求，请产品和RD对工作量进行初步估算。一个版本的迭代周期这么长。对于复杂的需求，要及时拉长战线细化产品方案，确保RD的资源不被浪费。

请记住，在进行优先排序时，您不能只关注客户需求，也不能忽视建立能够满足更多客户的核心优势。

在定义了版本需求和需求优先级之后，我们来看看如何调动资源进行版本迭代。

1.资源投入项目经理:负责整体版本规划和需求管理，跟进版本的迭代过程，负责版本的整体发布；产品经理:负责产品需求的方案设计和评审，配合设计、RD、测试负责需求的构建，负责需求的实现；RD:负责产品需求技术方案的设计和实现，控制需求的RD进度；设计:完成UI设计和视觉设计，输出设计剪影；测试:输出测试用例来控制需求的质量。这些角色在参与版本迭代时都有自己的期望，在不同的环节都需要共情。

比如在RD，最怕产品方案考虑不充分，就被发现匆忙实现技术。前期计划的不完整会导致后期需求的变化，这对RD来说是一种资源浪费..

那么，从RD的角度来看，产品经理在处理需求时，不能只讲一个简单的用户故事。客户需求和产品能力差距有多大，取决于你如何理解需求，提炼需求场景，打磨你的产品。

相应的，在版本迭代的过程中，项目经理要预留足够的时间给产品经理思考计划，不能为了满足更多的需求而忽略产品的细节。产品不仅要看细节，也不能完全忽略。

如果不注重各方面的细节，最终会陷入积累的口碑中；当所有人都在盯着你丢的那筐土的时候，没有人会在意那堆起来的九座小山。

2.既然团队机制和流程控制是一个长期的工程，为什么不从一开始就努力定义流程和机制，并画出所涉及角色的工作图呢？

如前所述，我给自己一个版本的时间窗来证明这种团队机制的可行性。具体流程是怎样的？

1)定义版本节奏。

一个半月，两个小版本一个大版本(ab为小版本，C为大版本)，小版本内测体验，大版本正式发布。

2)标准化迭代过程

①成立版本审核委员会，从版本规划开始，做好向上汇报和内部同步，保证信息公开透明。是的，你是版本的总体负责人，但你不必承担太多责任，尤其是在需要决定的事情上。分担责任也是分担风险。

②版本需求确定后，给产品经理预留足够的时间进行需求调研和产品方案设计，并设立一个标杆事件:启动版本启动会。每个产品经理一般会宣讲需求，定义需求的RD领导者，所有成员投票评估需求的合理性和可行性。

③需求经过产品和RD的进一步评估后，产品和RD领导将组成一个特性团队，开始需求的实现，然后配合设计和测试的资源，使需求在发布计划的时间窗口内有序推进，在合适的时间同步进度和风险，确保需求相关人员对需求有相同的理解。

3)加强过程控制。

有一个过程，但是过程中涉及的环节很多，需要抓住最关键的部分加强控制。

一个是需求评审环节，决定了这个需求的后续实现路径，不可小觑。对于相对复杂和重要的需求，对于空 reduction的高优先级需求，插队与否不是由RD或产品或架构师决定的，必须严格提升到版本评审委员会的联合决议。

一个是RD调度环节，版本的发布时间窗口基本固定。对RD排产的评价不仅要看需求的优先级和要实现的工作量，还要看发布计划的时间点，看能抓住哪个发布计划，以保证承诺给客户的交货期相对可靠。

一个是产品体验环节。很多团队在前期对需求的设计严加防范，但一旦步入RD阶段，产品经理除了偶尔回复RD问题咨询外，对需求本身的实现过程和结果略有鄙夷。

这里需要特别注意需求研发完成后的产品体验环节。产品经理必须根据测试用例完整地检查功能，以确保最终的功能符合初始需求的设计。如果有偏差，是否更改或添加需求，也需要引入版本评审委员会(与需求相关的人员)进行评估。

第三，不仅如期发布了一款糖品，这个时候我对一线架构师有没有一个交代？不够。

回想起来，架构师的产品能力是否清晰？为什么他们的客户需求在很多产品研发的同学看来是不合理的？归根结底是因为项目支持和产品建设脱节。

两个人，一组忙着做项目，另一组忙着做需求，各自为战，独立做事。

你可能会说，产品在项目中不就是为了更好的销售和交付而制造的吗？可以，但是实际操作中存在这样的问题。结果你会发现一线团队对产品知之甚少，而产研团队对项目知之甚少。

这是常态，但可以改变。

回顾整个版本迭代过程，你会发现有很多环节可以完全依靠一线架构师的力量。

在版本规划的前期，项目经理可以要求架构师给出强大的项目背景来证明需求的合理性；在需求调研期间，产品经理和架构师之间的深度访谈可以帮助你全面了解需求场景和目标，如果有必要，你还可以和架构师一起拜访客户。当需求研发完成，产品体验完成后，产品经理邀请架构师一起体验功能，确保功能的效果与架构师的预期一致；产品发布后，产品经理可以请架构师一起编写一个功能故事，描述功能的运行路径、实现效果和价值，让客户更好地使用功能。在整个过程中，一线架构师与产研团队有更多的互动和融合。这是我们给建筑师的糖果。不仅提高了架构师对产品的理解，也加深了生产研发团队对客户的理解。

同样的，产品发布交付给客户后，我这个时候对生产研发团队有没有一个交代？不够。

很多时候，一个新版本从策划到发布，一个多月过去了。在这一个月的时间里，客户可能还在追逐这个能力，可能已经忽略了这个需求。但是生产和研究的资源是真正投入的。他们需要一颗糖，可能不够甜，但总比送了又错过好得多。

所以我们会要求一线实施团队在将新版本交付给客户后，主动了解客户的使用情况:有用吗？最近怎么样？全面推广了吗？还有其他反馈吗？所有这些都应该定期跟踪，以了解不同级别的用户对新版本中发布的新功能的想法。正反馈和负反馈都好，应该有个交代。

通过这个账号，更完整的产品故事应运而生，产品经理有更实用的材料证明功能的价值，架构师有更充分的论文迎接客户的挑战。

四。总结我相信很多成熟的团队一定有自己的一套完善的版本管理方法，也在为客户需求和产品能力的转化运筹帷幄。我要为此向你表示祝贺。的确，解决同一个问题会有很多思路。我也从这件事里想通了一个道理，就是如何克制把问题简单化的冲动，避免陷入选择观点的二元偏向。

在与外部和一线团队的不断沟通中，我知道了项目的难度。在内部和RD团队的联合作战中，我明白了产品在想什么。如何平衡项目和产品，让项目带动产品的改进，让产品更好地服务于项目，让原本若即若离的两群人汇聚成更强大的力量，这是我最了解的。

我想我梳理好思路之后大概就不需要学习如何成为送水高手了。

#专栏作家#强大姐，微信微信官方账号:强大姐(ID: is_strong)，人人都是产品经理专栏作家。腾讯高级产品经理，专注于To B服务项目管理和行业分析，欢迎各路英雄共同探讨。

本文由人人都是产品经理的“原创激励计划”出品。未经许可，禁止转载。

来自Unsplash的图像，基于CC0协议。