一个月前，被领导委派成为一个小特性的负责人，在我司的术语叫做 Feature Owner (FO) 的，给我平平无奇的人生又增加了一点毫不出彩的经历。

由于是第一次做这么一个脚色，又托大并未去参考什么前辈经验，在前期实在是连滚带爬了好一阵子，很是狼狈。回顾所来，还是有一点心得体会要写的，不过我写在这里，不管对与不对，总还是会有许多如我一般丝毫不去找前人经验的新人FO在，故这些文字，大约并不为多少人所读到，多是仅供自娱而已。

1 起手式：版本

特性负责人，其实就是除了开发工作之外，还要负责起整个特性的前期计划、进度跟踪、后期联调和最终交付的角色。不同特性要求负责人在各个环节的投入比重差异实在很大，难以有一个普适的套路。

就我负责的特性而言，我所要做的开发工作很少，主要是整合周边组件提供的功能；然而由于周边组件很多，就要求我要投入多数的时间用于总体计划的协商对齐上。开发岗位的惯性使我一开始忽略了计划的对齐，导致前期拟定的计划不断地出现缺漏——甚至于我自己的开发工作完成后，还是没有跟周边组件定下一个稳定可行的联调计划——整个特性前中期每天都处于一个高风险的状态，我的心绪也一直无法安宁下来，深受其害。

由此我得到的经验是，特性负责人所要确定的第一个问题就是版本问题——确定双方版本、我们负责的新特性要在哪个周边版本联调、周边特性打算在哪个版本交付、最终要在我们的哪个版本集成。

• 我们当前用的是周边的什么版本、周边当前又已演进到什么版本。这是一个首要的问题。不认识这一点，就不能明白对方的开发基础和我们现有的基础之间的差异。假如对方的版本和我方的版本一致，那就可以轻松实现对接；假如对方的版本领先于我方版本，那就需要考虑兼容的问题，即对方新开发的功能，并不一定能直接迁移到我们现有的版本上。

  

  

• 我们的新特性要在哪个版本联调。当我们确定了当前使用的周边版本之后，要进一步确定联调版本。最舒适的做法是让周边组件基于我们当前使用的版本拉出一个新的代码分支，并将他们新开发的功能合入这个联调分支上，提供联调版本。这样的联调版本我们基本没有适配压力，可以开箱即用，是最佳选择。

  

  不过，很容易由于双方版本差距过大，以至于对方提出无法将功能合入老版本的代码上；这个时候，最好表现出我们作为特性负责人的强势，要求对面克服困难提供联调版本。尽量不要随便答应使用对方的新版本联调，因为对于我方来说，将周边版本升级是一个更加复杂的过程，涉及的方面远不只限于我们的特性本身，最终还是有很大概率不断地回到起点去重新制定联调计划，反而不如一开始就让对方基于我们现有的版本去合入新特性。

  我的这个小特性，正是由于联调计划迟迟无法对齐，导致开发完成之后无法立即启动联调。周边组件为了免除将新特性及其依赖功能合入旧版本的额外工作，提出了各种基于他们最新版本的联调方案，我方也花费了很多精力去开展这种本就风险很大的联调，最终将各组件拆的七零八落，也只能勉强地调一小部分功能，一直苟延残喘到我方正式对周边的新版本进行了适配，才做出一个比较完整的联调版本来。

  

• 周边特性打算在哪个版本交付、最终要在我们的哪个版本集成。各方都完成功能开发后，随着版本演进，自然会有一个版本集成了全部的功能，但问题在于一个特性的交付是有DDL的，我们要确保在DDL之前能够完整集成所有功能，就要确定双方的版本计划。

  以我的这个小特性来说，原先要求在 3-30 交付，由于早期没有对好版本计划，有一个组件交付在他们的 3-25 的版本上，而我们对这个版本的集成计划已经排到了 四月份之后！

  

  这样的问题在后期一出现，基本宣告特性延期交付。合理的做法是前期对好计划之后，就要告知周边尽快将特性交付到当前的版本上，才有可能在我方发布版本时集成所有功能。

2 进阶式：求助

打好版本这套起手式，就足够装作老师傅了，此时整体特性的交付风险就将相当可控。不过，作为一个特性负责人，自己包办一切是不现实的，有非常多的东西在我们知识及能力范围之外，这时及时求助就会非常重要。按我的经历说来，下面几个角色是不可不打交道的。

• 周边特性负责人。通常在跨部门的特性中，周边组件也会有特性负责人，不管是版本计划、周边进展、合作联调，都可以找这个负责人商议，即使TA搞不定这些问题，也会帮我们找到具体能解决问题的人物。

• 我方 +1 +2 。特性不大的情况下，找上级或上上级就基本能摆平我们遇到的多数问题，他们会用丰富的经验帮我们把控当前的风险，以及在大佬比较多、问题比较复杂的会议上帮我们稳住节奏和心态。

• 我方版本角色。玩版本的人都是狠人，我们的起手式里其实有相当多环节都可以请我方版本角色帮忙搞定，例如确定我方和周边的版本配套关系、商定联调版本的计划、确定我们的正式交付计划等等。这种问题，很大概率 +1 +2 也并不特别了解，如果在我们的求助列表中缺失了版本角色，就容易带着他们一起在版本问题上翻车（你猜猜这个教训从何而来）。

我做这个小特性，既没把版本玩明白，又没在前期找准求助的对象，导致积重难返，延期交付，真是悲剧。

3 终式：厚脸皮

对我来说，这个终式不算是什么经验，而应该算是我所悟到的优秀的特性负责人必须有的品质。我至今不能二话不说就打别人的电话，而总是寄望于对方看到我的留言后帮我解决问题。实际上，办事时脸皮一厚，就会让效率提高百倍。关注的重点不能放在对方是否被我们打扰，而应该放在我们是否需要对方快速响应这个问题好让工作继续推进下去。

在我的认知里，这个终式简直是本文所有其他经验的基石，无论是最开始找周边的一帮素不相识的人商定计划，还是遇事不决就找领导们进行求助，都非脸皮厚如城墙不可。诚然有人认为这种东西实在稀松平常，就是日常工作所必须的部分，并没有我所说的这样夸张，但我必须指出，不同个体之性格天然迥异，正是也有一些较木讷内向的人阴错阳差地成为FO，且因为较木讷内向的性格导致了所谓“日常的”工作正在艰难地推进，我的这一小节的经验，就专为这些人而写，其中自然也包括我自己。