做好迭代管理，给团队一颗糖
编者按：本文来自微信公众号“人人都是产品经理”（ID:woshipm），作者：林壮壮，36氪经授权发布。
在团队工作中，产品经理需要身兼多职、兼顾多方意见。而产品版本迭代管理往往需要牵扯项目的多方面。那么，当产品经理着手版本迭代管理工作时，应当如何协调团队工作、做好过程控制、进而凝聚团队力量？本文作者便结合其自身经验向我们做出了清晰展示。
自春节到现在，我陷入一种困境里：突然间，我好像成了“夹心饼干”？
事情是这样的：
由于业务变动，最近我开始负责一个核心产品的版本迭代管理。我敞开心扉拥抱变化，但两个月下来，事情比我想象中得更棘手。
先交代下背景：
在我之前的工作经历里，我和前线的团队交涉比较多，销售、售前架构师、产品架构师、服务商、ISV，都相对比较熟稔。熟稔到什么地步呢，就是他们跟我说声hi，我都几乎能料到他下一句话想问什么、想要什么，我可以怎么推杯换盏地应对他们。
和他们站在同一条船上久了，我深谙支持项目有多不易。
我理解客户对产品的诉求有多急切，也愿意尽最大努力去争取产品研发的资源投入。
但是，一切开始不一样了。
自打我接手产品研发工作，开始负责产品整体规划和版本迭代管理后，我多了一重身份。
随着我深入了解产品的细节，了解看似简单实则不易的需求背后沉淀了这么多研发、测试的人力后，我不得不站出来为产品研发团队说说话了。
这也就导致：我清楚客户需求的合理性和迫切性，但我也在警惕产品研发资源的不合理占用。
于项目团队而言，作为产品接口人的我开始谨慎承诺，小心防守；
于研发团队而言，作为项目经理的我抱着一揽子需求回来，生怕我狮子大开口。
里外不是人了不是？
我反思过：是不是该去学一学怎么端水？
把情绪放一放，我给自己一个版本的试炼机会，也趁此摸清楚了项目支持和产品管理的平衡之术。
我和其他团队的产品经理聊了下，有些同学一开始就是走产品策划路线，始终站在产研的角度，专心琢磨如何让产品做得更好；有些同学一直都是在客户现场，或是出差去现场的路上，他懂行懂客户，能根据客户需求拟制解决方案。
其中不乏有产品经理负责版本迭代管理，但总会遇到各种各样的问题：怎么去权衡各大项目反馈的需求优先级？怎么应对空降的需求带来的资源占用？怎么让前线团队放心、让研发团队齐心呢？
不少团队都倾向于将产品研发管理专门交给项目经理去负责，由项目经理协调产品、设计、研发、测试的资源，并跟进整体版本迭代的进展。
这的确权责分明，产品做需求，开发写代码，各司其职，何乐而不为？
可事实上，版本管理的重点不在于由产品研发团队中的哪个角色来承担，关键在于如何去管理这个版本。
既然团队内暂时没有这样的角色来支撑，那么我大可以利用自己的多重身份“夹带私货”，不是吗？
不仅是规划版本
规划版本前，请先规划产品roadmap。
为什么前线项目组总是源源不断地投递需求？
——我要斩断不重要不紧急的客户需求。
为什么研发同学总是下意识拒绝需求？
——我要调动产研资源实现优先级最高的产品能力。
从客户需求到产品能力之间是有Gap的，我要搭桥造梁，就需要一个支撑。
那么，怎么规划产品的阶段性里程碑？
1. 从团队KPI入手
今年团队的考核目标是什么，是产品收入？用户活跃度？标杆案例数？项目的复制情况？
2. 制定个人OKR
基于团队的目标，落实到个人所负责的产品目标，去看在该目标下你要输出的关键结果是什么。
比如你们考核的是要在全国范围内树立至少2个国家级标杆项目，那么对应的这类型项目最关注的需求场景是什么？为了满足这样的需求场景，产品要实现哪些能力、配套提供哪些服务支持？
3. KANO模型
这是东京理工大学教授狩野纪昭（Noriaki Kano）发明的对用户需求分类和优先排序的工具，需求分五类：基本型需求、期望型需求、兴奋型需求、无差异型需求、反向型需求。
① 基本型需求（必备型需求）
客户认为必须有，没有的话这个功能就不具有交付意义的需求。
针对这类需求，一旦你没满足客户，客户的满意度将一落千丈，你可能马上就要被踢出局。比如顾客买一个保温杯，它能正常装热水，顾客不会为此感到满意；但如果这杯子有裂缝，杯盖拧不紧，或是保温效果差，那么顾客对这个杯子的满意度就会明显下降，投诉接踵而至。
② 期望型需求
客户期望你可以实现的需求，一旦你实现了，客户满意度会显著提升，你提供的产品超出客户期望越多，客户就越满意。
但相应的，如果你拒绝满足客户需求或是表现不好的话，客户也会立马提出不满。
比如客户期望贵司提供的问题响应机制可以更快捷、故障处理可以更高效，那么一旦你优化了问题处理流程，提高对客户的响应效率，客户就越满意。
③ 兴奋型需求（魅力型需求）
客户既不会过分期望，又不会明显不满的需求，即，有更好，没有也能接受。
比如早期海底捞向客户推出生日当天全体员工向顾客唱生日歌，这种服务的确会让顾客惊喜，但如果不提供这个服务，顾客也不会不满。
这类需求通常能在某些时机打动客户，赢得客户决策人更多的关注。
④ 无差异型需求
这类需求对客户没有影响，有或没有都无所谓。
这种需求怎么会被人提出来呢？
可能是客户对标了不同的产品，或是灵光乍现想到的，这样的需求在应对的时候需要甄别，不必过分投入在这类需求上。
⑤ 反向型需求
该需求会引起大部分人的强烈不满，你实现该需求反而会降低客户的满意度。
比如客户管理层提出一些强管理的需求，乍一听很合理，但深究下来，这需求对员工不友好。即便你短暂地满足了客户高层的需求，但长远来看一定会收到客户的投诉，毕竟客户采购软件并不仅限于在管理层使用，更多时候还是为了服务于全体员工。
针对这类需求，你且缓缓，先冷静旁观，做好充分的客户需求调研后，再决定是否要做。
根据上述三方面，在实际规划产品蓝图时，可以从以下两方面去考虑：
一方面根据团队OKR划定产品方向，圈定几个需要冲刺的功能模块，分月度、季度去迭代功能、做项目验证，再炮制到其他项目中落地；
另一方面摆正心态，正视客户反馈的需求，全力以赴满足基本型需求，重视产品义务范畴内的事项，确保在市场竞争中不丢分。同时，尽力去满足客户的期望型需求，提供大多数客户关注的额外服务和产品，引导客户的决策链对本产品有更多的倾向性；最后才是争取实现客户的兴奋型需求，提高客户用户的粘性和复购率。
你看，通过层层过滤，你会发现有不少客户需求其实没那么重要，它并不能为产品的销售有什么催化作用，甚至在占用产研资源后还讨不到一点好处。
不仅是管理版本
前文提到如何在规划版本前规划好产品阶段性的里程碑，围绕里程碑去规划每个月的版本内容和版本节奏。
但实际上在管理版本中最大的问题不在于做哪些需求，而是什么需求要先做。
每一位架构师都认为自己负责的客户提的需求最靠谱、最重要、最紧急，动辄就是“这是某位CTO提的”、“这个需求已经上升到我司的某位高管”之类的……
通往产品发布的管道就这么宽，全堵在这段路上，谁也动不了，谁也不想让。
这时候除了根据KANO模型对需求做一层初步的分类之后，每个类目下依然存在不少需求，怎么排优先级？
向外看，竞争对手相比你的优势在哪？它推崇的关键控标点有什么？
研究竞品并不可耻，市场就这么大，池子里的鱼就这么多，为了捕获更多的猎物，取长补短也是顺理成章的。
向内看，你不必把这份责任全部放在自己身上，建立版本评审委员会，邀请领导、产品和研发负责人、前线反馈需求的架构师，共同来评审这些需求的优先级；通过责任公摊和事务公开，形成一个集体公认的版本需求池。
在需求池初具雏形后，你要及时组织产品研发团队开版本启动会，宣导需求池里的所有需求，请产品和研发初步给出工作量的预估。
一个版本迭代的周期就这么长的时间，对于比较复杂的需求，适时地拉长阵线去细化产品方案，才能确保不浪费研发的资源。
记住：排优先级时，不可只关注客户需求而忽视了去建设能满足更多客户的核心优势。
在明确版本需求和需求的优先级后，我们再来看下如何调动资源投入到版本迭代。
1. 资源投入情况
项目经理：负责整体版本规划和需求管理，跟进版本迭代进程，对版本的整体发布负责；
产品经理：负责产品需求的方案设计和评审，负责与设计、研发、测试协作开展需求的建设，对需求的实现情况负责；
研发：负责产品需求的技术方案设计和实现，把控需求的研发进度；
设计：完成需求UI设计和视觉设计，输出设计切图；
测试：输出测试用例，把控需求的质量。
这些角色在参与版本迭代时都有各自的期望，在不同的环节里都需要换位思考下。
比如研发，最怕产品方案没考虑完全就火急火燎地找上来要技术实现，前期方案的不周全大概率会引发后期需求的变更，这对研发而言就是资源的浪费。
那么站在研发的角度，产品经理对待需求就不能只是在讲一个简单的用户故事，客户需求和产品能力之间的gap有多大，取决于你如何去理解需求、如何去细化需求场景、如何打磨好你的产品。
相应的，在版本迭代的过程中，项目经理预留给产品经理思考方案的时间要充分，不能为了满足更多的需求而忽视了产品的细节。产品不可只看细节，也不可全然不顾细节。
不注重各个方面的细节，终究会连累到之前积累的口碑；当所有人都盯着你缺的那一筐土的时候，没有人会关心已经堆好的九仞土山。
2. 团队机制与过程控制
既然是一个长期工程，那么何不如从一开始就下功夫定流程，定机制，把涉及到的角色的工作地图画出来？
前面提到，我给自己一个版本的时间窗，去印证这个团队机制的可行性。
具体流程是什么样呢？
1）明确版本节奏
一个半月2个小版本1个大版本（ab为小版本，c为大版本），小版本内部测试体验，大版本对外正式发布。
2）规范迭代流程
① 建立版本评审委员会，从版本规划开始，做好向上汇报和对内同步，保证信息公开透明。没错，你是版本总体负责人，但你没必要把很多责任往自己身上揽，尤其涉及到需要上升决策的事情，分摊责任也同样是在分摊风险。
② 版本需求确定后，预留充分的时间给到产品经理调研需求、设计产品方案，并树立一个标杆性事件：开展版本启动会。由各产品经理大体宣讲需求，明确需求的研发负责人，全员投票评估需求的合理性和可行性。
③ 需求进一步得到产品和研发的评估后，产品和研发负责人各自组成feature team，启动对需求的实现之路，再配合设计、测试的资源，让需求在版本发布计划的时间窗内有序地推进，并适时地同步进展和风险，确保需求相关人对需求的理解是一致的。
3）加强过程控制
流程是有了，但流程里涉及到的环节比较多，需要抓住最关键的部分加强管控。
一个是需求评审环节，这决定了这个需求后续的实现路径，绝不能轻视。
对于相对复杂且重要的需求，对于空降的高优先级需求，能不能插队也不是研发或产品或架构师说了算，都必须严格上升到版本评审委员会共同决议。
一个是研发排期环节，版本的发布时间窗是基本固定的，研发排期的评估除了根据需求的优先级、实现的工作量之外，还要根据发布计划的时间点看能赶上哪一个发布计划，以确保给客户承诺的交付时间是相对可靠的。
一个是产品体验环节，不少团队在前期需求设计上严防死守，可一旦步入研发阶段，产品经理除了间或响应研发的问题咨询外，对需求本身的实现过程和实现结果是有点轻视的。
这里需要尤其重视需求研发完成后的产品体验环节，产品经理必须完整地按测试用例走查一遍功能，确保最终的功能与最初需求的设计是契合的。
若有偏差，是否要变更或追加需求，则同样需要引入版本评审委员会（与该需求相关的人员）一起来评估。
不仅是一颗糖
产品如期发布了，这时候我对前线的架构师是否就有了交代？不够。
回想下，架构师对产品的能力是清晰的吗？他们提的客户需求为什么在不少产品研发同学看来不太合理呢？
归根结底是因为：项目支持和产品建设脱节了。
两拨人，一拨人忙着做项目，一拨人忙着做需求，各自作战，各自为政。
你可能会说：产品做出来不就是为了更好地在项目里售卖和交付吗？
没错，但在实际运作的过程中确实存在这样的问题。
于是你会发现：前线团队对产品一知半解，产研团队对项目一穷二白。
这是常态，但可以被改变。
回过头来看整个版本迭代流程，你会发现有很多环节完全可以借助前线架构师的力量。
在版本规划初期，项目经理可以请架构师给出有力的项目背景佐证需求的合理性；
在需求调研时，产品经理与架构师的深入访谈，可以更充分地了解需求场景和目标，如有必要也可以跟架构师一起拜访客户；
在需求研发完成转产品体验时，产品经理邀请架构师一起体验功能，确保功能的效果与架构师的预期一致；
在产品发布后，产品经理可以请架构师一同编制功能故事，描述功能的操作路径、实现效果和价值，以便客户更好地使用功能。
整个过程里，前线架构师与产研团队有了更多的互动和融合，这是我们给到架构师的一颗糖，它不仅提升了架构师对产品的理解力，也加深了产研团队对客户的认识。
同样的，产品发布后交付给到客户后，这时候我对产研团队是否就有了交代？
不够。
很多时候一个新版本从规划到发布，一个多月过去了。
这一个月期间，客户也许还在追着要这个能力，也许早已不在意这个需求。
但是产研资源也确确实实地投入进来了，他们需要一颗糖，可能不够甜，但总比交付出去下落不明要好得多。
因此我们会要求，前线实施团队交付新版本给客户后，需要主动了解客户的使用情况：有没有用？用得怎么样？有全面推广起来吗？还有其他反馈吗？
这些都要定期追踪，了解客户不同层级的用户对新版本发布的新功能的想法，正向反馈负向反馈都好，都要有个交代。
通过这样的交代，一个更加完备的产品故事应运而生，产品经理有更多的实践素材去佐证功能的价值，架构师有更充分的底稿去应对客户的挑战。
我相信不少成熟的团队必定有自己一套完善的版本管理方法，对于客户需求和产品能力的转化也是运筹帷幄，对此我要恭喜你。
的确，同一个问题会有很多解题的思路，我从这次的事件中也想通一个道理，那就是如何去克制把问题简单化处理的冲动，避免陷入对观点做取舍的二元偏误里。
在对外和前线团队的持续沟通中，我清楚了项目的百种不易；在对内和研发团队的共同作战中，我理解了产品的所思所想。如何去平衡项目和产品，让项目驱动产品的提升，让产品更好地服务于项目，让原本若即若离的两拨人汇聚成一股更强劲的力量，这是我从中体会最深的。
我想，捋完一遍思路后，我大概不需要去学怎么成为端水大师了。
该文观点仅代表作者本人，36氪系信息发布平台，36氪仅提供信息存储空间服务。