最近在翻看《程序员》杂志的时候看到的一篇文章：被《偷走的童话结局-对营销和研发分工的考核》。中间反应的问题感觉和现在的工作息息相关，整理下来供思考。

   一、如何进行职责的划分？

   产品经理和研发经理是一个研发团队的重要组成部分，大体的分工均会这样：研发经理负责技术核心，按照需求进行开发。产品经理作为研发部门的边界部门，与市场对接并提炼需求，以缓冲外部环境的不确定性对核心技术的直接影响。如此一来研发经理可以更加专注于项目管理与技术，产品经理则可以更加专注于产品管理与市场。

   二、如何进行正确的考核？

   如果能将组织中每一岗位的工作无歧义的描述，整个组织必然会想程序中的逻辑处理一样，可以高效的完成任务。这样产品经理和研发经理也会各尽其职。事实是没有人可以拥有足够的信息把组织内所有成员的行为当作机器一样的程序化。也没有谁预知到未来会发生的所有问题，并安排好对策。于是，我们就看到更多的组织将不同领域的决策下放给部门或个人，让部门或者个人在其专业领域享有自主决策权，这样就有产品经理与研发经理各司其职、各行其权的局面。

   假设其他条件不变的前提下，项目的产出是产品经理与研发经理努力程度的函数。无论是产品经理还是研发经理的进一步努力，都会提高项目的产出。比如，产品经理更努力地关注市场、整理需求，研发经理更努力地追踪项目风 险、及时处理项目中的问题等，这些努力都会或多或少地增加项目的产出。有些情况我们无可否认：一个愚蠢的产品理念足以让研发经理的努力付诸东流、一个糟糕的研发团队也足以使 产品经理空守着一个好点子望洋兴叹。但这仍无损我们的命题：任何一方的努力与项目产出都是正相关的。

   由于项目产出与产品经理和研发经理的努力息息相关，那么对于管理者而言，如何更好地激励产品经理与研发经理努力工作便是一项很重要的任务。最常见激励方式为经济激励。其主要分类为按岗位考核和按项目考核。

   在使用岗位考核制的企业里，管理层通常用及时交付率、软件缺陷率、文档规范度等来考核研发经理，用规格的详尽度、产品工具的规范度等来考核产品经理。显然，我们都知道这些并不是产品经理与研发经理工作的全部， 这些标准的完成并不表示项目的成功，有时还会由于对这些可见标准的过分重视导致被考核者产生机会主义心理，甚至导致项目的畸形发展。但管理者为什么还将其作为考核标准呢？这背后的假设是：雇员的工作努力程度是可观察、可量化并可独立考核的。显然，这并非亊实。 一方面，随着企业中专业化程度的不断加深，要理解其他专业人的工作越来越难，尤其是对于专业的知识工作者，很难对其工作进行客观的量化评估；另一方面，独立考核的标准极有可能与组织的整体利益相冲突。一个按时完成的项目不一定是成功的项目，一个实现了所有需求的产品不一定是好产品。  在今天，我们批判这类对研发经理与产品经理的岗位考核，不是它所定标准不全面，而是它企图将不可量化的事物强行量化。不是因为它不完美，而是因为这本身就是荒谬。

   按项目考核比岗位考核好一 些，至少它不再坚持努力程度可观察、可量化的错误假设，而是直接考核可见的结果，同时用结果说话，避免独立考核时引发的机会主义心理对整体利益的损害。考虑一个简化的例子：产品经理A与研发经理B的境况。 我们假设他们一起负责一个项目，在项目完成 后，企业将对他们进行整体考核：如果双方都努力工作，项目会取得最高产出，并因此得到最高 奖励10万元；而在一方努力、另一方卸责的情况 下，项目产出则大大降低，奖励4万元；如果都不努力的话，则两人什么都得不到。

   第一，如果双方都努力工作的话，各人都可获得最高的报酬。第二，每个人的努力与自己的收益是正相关的。第三，每个人所 获得的报酬都会因另一方更努力的工作而得到提高。这也是团队工作的明确特征。似乎会得出这样的推论：个人会倾向于努力，因为只要努力就会有回报(2万元)，而且总是正相关的。当然，另一个人也必然受此激励，最终双方一起得到了最好的结果(5万元)。上面这个例子描述了一个美好的前景，但事实是否如此呢？让我们在报酬矩阵中加人努力成本这一因素，这是现实的，因为我们完全可以在一定程度上假设每一个人努力工作的同时必然伴随着更多的精神成本。现在我们假设努力工作所付出的精神成本相当于货币3万元，也就是说当产品经理或研发经理在确认努力工作能换来3万元奖励时才认为努力是值得的，那么更新矩阵如表2所示。

   这样，在更贴近现实的同时我们之前的结论随之而不再成立：因为加入努力成本后，个人的努力与收益不再是正相关的了。虽然双方一起努力的话，大家仍然都会更好(每人2万元净收益)， 但单方面卸责却变得更有吸引力，因为这一策略可以依靠他人的努力仍然保持2万元的净收益，同时还能避免他人单方面卸责伤害的可能(-1万 元)。这样一来，在投机与猜疑的作用下，共同努力的局面将很难维持。双方都不再(也不敢)对共同努力抱有希望，因为每一个人都不认为自己的努力必然会使自己的处境更好。

   当然，“普遍卸责”这一极端的结论并不为事实证据所支持，至少通过经验观察并没有发现在企业中存在普遍明显卸责的行为。但企业中普遍 存在的“松懈”却是显而易见的，这在一定程度上吻合了我们的推论。这种普遍存在于组织中的松懈、卸责，实际上都可以归结为经济学理论中的“外部性”，即每个人努力的好处会平等分K，但成本对各人却不同，从而使 人们倾向于“搭便车”。在软件企业里，无论是产品经理，还是研发经理，每个人都可以在各自的职责范围内作出损害项目利益的决策却让整个团队分摊相应后果。研发经理可以为了冒险褚神、盲目引 入新技术而不顾项目风险；产品经理也可以对需求不加过滤、任由产品臃肿不堪而到最后什么都不是。这难道不正是我们平时观察到的典型现象？如果每个个体都渐渐明白：自己的努力在整体绩效面前是如此渺小、面对背叛时又是如此脆弱，谁还愿用努力工作去赌那不堪一击的团队精神呢？

   于是我们陷入一种两难境界：一方面，我们无法按岗位考核来分开激劻产品经理和研发经理；另一 方面，我们又无奈地发现，将双方命运绑在一起也并不能必然激励他们共同努力。分工只是开始， 但分工并不暗示着某种必然的美好结果。我们常听说王子与公主最后一起过上了幸福的生活，但幸福不是必然。王子与公主是知道的，如果一起 力的话，他们会从此过上幸福的生活。但他们也知道，没有谁能保证另一半也是这样想。

   三、看不见的较量

   有种情形非常见：作为下游，研发经理常抱怨产品经理的工作很糟糕，指责他们的需求含糊不清且相当易变；而产品经理则认为在给定的材料下他已经做得最好了。同样，产品经理也会经常抱怨，不明白一个简单的修改为什么会这么难；而研发经理则认为，作为上游的产品经理根本没有意识到相关修改的技术难度与附加成本等。假如在一 个信息透明的世界里，这一切都不会发生，就像如果每个人都知道某种商品买卖双方的底线，那 么讨价还价将没有任何意义。但可惜的是，产品经理并不具备研发经理所掌握的信息与技能，研发经理也同样不具备产品经理所掌握的信息与技 术，这种信息的不对称使得双方都会乐于耗费时间虚报自己的偏好并试图看穿对方的底细。因为通过自己手中独一无二的信息，可以使他在各种讨价还价的战争中有利地保护自己的利益。

   有时，我们会发现产品经理与研发经理之间的交涉与小贩们并无本质差别。当客户需要得到某个功能并指定了某个期望时间时，产品经理往往不会把真实的需求时间告知研发经理，而是倾向于报一个更短的时间，因为他假设对方的估算总是 有水分或者预期会“还价”；而在研发经理给出时间估算时，我们自然也不能阻止他猜疑期望时间的真实性，从而报出一个更安全的时间。也许这个经研发经理“深思熟虑”的时间甚至都超过了客户的预期，这样一来，一个可为产品增值的机会就在这愚蠢的讨价还价中与我们失之交臂。 又或者，研发经理接受一个据说“紧急”的需求， 这个需求原本是可以在真实的需求时间里做好的，但由于时间紧急，研发经理被迫采取一些临时手段来达到产品经理的目标，这样结果可想而知。一种可能是，这个需求被匆忙地实现，最终因为技术债务越来越多反而超过真实时间；另一种可能是，产品经理最终如愿以偿，只不过得到的是一个埋下一堆潜在风险的版本。

   讨价还价总是有成本的，而这些成本往往又是如此触目惊心。在商业世界里，我们可以因价格不满意而寻找其他卖家。在商业世界里，没有效率的供应商会被竞争无情地淘汰。但这些在企业部 门之间的交易中却不存在。研发经理不能因为产品经理无能而选择与其他产品经理合作；而产品经理也往往没有权力淘汰研发团队。随着过程越来越专业化，这种存在于组织中的部门垄断力置也就越大。其必然结果就是，研发经理与产品经理都没有改进自己效率，也都没有改进合作的过程，讨价还价的成本会一直存在。

   四、不理性的理性决策

   企业的内部分工使得每个人各尽其能成为可能， 也使决策可以充分专业化。产品经理是营销领域的专家，可以作出有关营销方面的决策：而研发经理是技术领域的专家，可以对技术决策负责。最终决策必须由熟知这些情况的人来作出，他们直接了解相关的变化以及可立即用来应对变化的资源。我们不能指望先把所有这些信息传达给中央委员会，再由委员会综合所有信息颁发命令来解决问题。我们必须用某种形式的 权力下放来解决问题。那么我们由此可以继续推论：出于理性考虑，如果一个决策既包含营销因素又涉及技术因素，那么这个决策应该由产品经理和研发经理共同决策。这是必然的，因为在这种情况下，无论是产品经理还是研发经理都不具备有决策所需的全部信息和技能。

   现在，考虑一个我们专门设计但在日常工作中很常见的例子，同样是产品经理A与研发经理B的故事。假如两人一起为下个软件版本安排计划，两人需要在两个功能和两种技术上作出选择(因为没有足够的时间实现全部功能)，如表3所示。

   这两种功能和两种技术最终交织形成了4种不同的方案：a、b、c、d。现在我们假设在产品经理看来a>d>b>c，而在研发经理的偏好则是 b>c>a>d。如表4所示。

   接下来，我们来看这种情况下的最终决策。根据分权设计，产品经理可以决定要开发的功能，研发经理决定要使用的技术。那么情况可能如下： 产品经理根据自己的最优偏好a, “理性地”选择功能I，而轮到研发经理的选择时，方案被限定为 a与c，那么研发经理根据自己的偏好排序(c>a)

   将会同样“理性地”选择c。这样一来，团队最终得到的是一个低效率的非帕累托最优决策~因为相对于最终决策c，存在一个更好的方案b，这 个方案完全可以让双方的情况都变得更好。但现 实却是，双方都从自己的专业理性地考虑，却最终得出了一个不理性的决策。

   这就是1998年诺贝尔经济学奖得主Amartya Sen 提出的著名的Sen Paradox理论。Sen Paradox雄辩地表明：只要组织中有专门处理组织决策的不同方面的两个子团队，就会要么蒙受行为不一致之苦，要么导致一些低效率的个人偏好组合。这无疑是一个让人难以接受但却无可奈何的亊实。 上面所举的例子也许不过是真实世界中的一个缩影。在现实生活中，我们总会看到一些优秀的、有创意的产品，它们有如皇冠上的宝石一样熠熠生辉。而这些并不是全部，因为我们还看不到， 究竟有多少同样优秀的创意，它们原本也应该成为宝石，但经过内部层层传递后，最终只能悲哀地在角落里顾影自怜。

   五、愤怒的针线

   我们无奈地看到，创造了数百倍产出提升率的分工理论，在我们的行业里却似乎失去了它应有的光芒：曾经我们寄予厚望、期盼能双剑合壁的产品经理与研发经理的组合，也似乎难逃在各种的外部性、不对称的信息以及偏好冲突的困扰下风雨飘摇的命运。所谈一切，无不让人倍感灰心与痛惜。

   成功地应用专业化手段来提高效率，意味着在整个任务的各个专业部分之间不需要进行协调，或者运用现有的 人际协调技巧就可以实现专业化分工部门之间的协调。如果这两个条件都不满足，就必领放弃专业化分工，继续使用人脑作为协调机制。就像一个人拿针，一个人拿线，穿针引线也不是件简单的事一样。而两人之间的协调配合，远不如人类神经系统对两只手的协调那么成功。

   专业化是现代企业的重要支柱，甚至可以说是企 业之本。但正如前文所述：它只是开始，并不暗示着某种必然的美好结果。专业化在组织中所遭遇的种种弊端，并不是某种设计精妙的制度就能一劳永逸地克服的，就像我们前面所提到的种种失效的激励。也许在产品经理与研发经理之上设 置一个共同的领导，或者将两者设计成上下级关系，确实可以通过制度手段来规避问题的一部分(比如偏好冲突)，但仍不能解决全部问题。专业化的关键在于人与人之 间的协调配合，这中间的种种并不是制度那刻板的条框所能概括的。至少从目前看来，制度对于解决产品经理与研发经理的协作问题上仍让人失望。

   或者我们可以这样认为：如果我们继续将希望寄托在某种设计精妙的制度上的话，我们就永远也无法真正跳出这针与线的迷局。要有所突破，我们就必须彻底放弃那些缘木求鱼的尝试，彻底摆脱对科层制度这只看得见的手的盲目信赖：我们必须回归到精神家园来，重新对组织中人的因素给予充分关注。去用心培育信任、认同与协作的精神种子，让产品经理与研发经理这两柄无所适从的利剑，重新镀上效率的光芒。

   六、希望

   谨以此与所有仍然在寻求答案的企业管理者们互勉：“只是因为有了那些不抱希望的人，希望才赐予了我们。”

建议继续学习：

1. 为什么现在那么多人应聘产品经理岗位？    (阅读：6898)
2. 给想转行做产品经理的同学    (阅读：5846)
3. 让我们来谈谈分工    (阅读：5441)
4. 互联网产品经理必读书目    (阅读：4726)
5. 行进在产品经理的路上    (阅读：4018)
6. 成长的财富，我做产品经理社区组织的这3年。    (阅读：3961)
7. 互联网产品经理，全方位入门，图书推荐    (阅读：3868)
8. 产品经理怎么和程序员打交道    (阅读：3794)
9. 产品经理3年沉淀和总结    (阅读：3627)
10. 如何做一个干货且装逼的产品经理演讲？    (阅读：3546)