|
最近在翻看《程序员》杂志的时候看到的一篇文章：被《偷走的童话结局-对营销和研发分工的考核》。中间反映的问题感觉和现在的工作息息相关，整理下来供思考。项目管理者联盟
一、如何进行职责的划分?项目管理者联盟
产品经理和研发经理是一个研发团队的重要组成部分，大体的分工均会这样：研发经理负责技术核心，按照需求进行开发。产品经理作为研发部门的边界部门，与市场对接并提炼需求，以缓冲外部环境的不确定性对核心技术的直接影响。如此一来研发经理可以更加专注于项目管理与技术，产品经理则可以更加专注于产品管理与市场。service.mypm.net
二、如何进行正确的考核?项目管理者联盟
如果能将组织中每一岗位的工作无歧义的描述，整个组织必然会想程序中的逻辑处理一样，可以高效的完成任务。这样产品经理和研发经理也会各尽其职。事实是没有人可以拥有足够的信息把组织内所有成员的行为当作机器一样的程序化。也没有谁预知到未来会发生的所有问题，并安排好对策。于是，我们就看到更多的组织将不同领域的决策下放给部门或个人，让部门或者个人在其专业领域享有自主决策权，这样就有产品经理与研发经理各司其职、各行其权的局面。项目管理者联盟
假设其他条件不变的前提下，项目的产出是产品经理与研发经理努力程度的函数。无论是产品经理还是研发经理的进一步努力，都会提高项目的产出。比如，产品经理更努力地关注市场、整理需求，研发经理更努力地追踪项目风
险、及时处理项目中的问题等，这些努力都会或多或少地增加项目的产出。有些情况我们无可否认：一个愚蠢的产品理念足以让研发经理的努力付诸东流、一个糟糕的研发团队也足以使
产品经理空守着一个好点子望洋兴叹。但这仍无损我们的命题：任何一方的努力与项目产出都是正相关的。项目管理者联盟
由于项目产出与产品经理和研发经理的努力息息相关，那么对于管理者而言，如何更好地激励产品经理与研发经理努力工作便是一项很重要的任务。最常见激励方式为经济激励。其主要分类为按岗位考核和按项目考核。项目管理者联盟
在使用岗位考核制的企业里，管理层通常用及时交付率、软件缺陷率、文档规范度等来考核研发经理，用规格的详尽度、产品工具的规范度等来考核产品经理。显然，我们都知道这些并不是产品经理与研发经理工作的全部，
这些标准的完成并不表示项目的成功，有时还会由于对这些可见标准的过分重视导致被考核者产生机会主义心理，甚至导致项目的畸形发展。但管理者为什么还将其作为考核标准呢?这背后的假设是：雇员的工作努力程度是可观察、可量化并可独立考核的。显然，这并非亊实。
一方面，随着企业中专业化程度的不断加深，要理解其他专业人的工作越来越难，尤其是对于专业的知识工作者，很难对其工作进行客观的量化评估;另一方面，独立考核的标准极有可能与组织的整体利益相冲突。一个按时完成的项目不一定是成功的项目，一个实现了所有需求的产品不一定是好产品。
在今天，我们批判这类对研发经理与产品经理的岗位考核，不是它所定标准不全面，而是它企图将不可量化的事物强行量化。不是因为它不完美，而是因为这本身就是荒谬。项目管理者联盟
按项目考核比岗位考核好一
些，至少它不再坚持努力程度可观察、可量化的错误假设，而是直接考核可见的结果，同时用结果说话，避免独立考核时引发的机会主义心理对整体利益的损害。考虑一个简化的例子：产品经理A与研发经理B的境况。
我们假设他们一起负责一个项目，在项目完成 后，企业将对他们进行整体考核：如果双方都努力工作，项目会取得最高产出，并因此得到最高
奖励10万元;而在一方努力、另一方卸责的情况 下，项目产出则大大降低，奖励4万元;如果都不努力的话，则两人什么都得不到。项目管理者联盟
项目管理者联盟
第一，如果双方都努力工作的话，各人都可获得最高的报酬。pmp.mypm.net
第二，每个人的努力与自己的收益是正相关的。项目经理博客
第三，每个人所
获得的报酬都会因另一方更努力的工作而得到提高。这也是团队工作的明确特征。似乎会得出这样的推论：个人会倾向于努力，因为只要努力就会有回报(2万元)，而且总是正相关的。当然，另一个人也必然受此激励，最终双方一起得到了最好的结果(5万元)。项目管理者联盟
上面这个例子描述了一个美好的前景，但事实是否如此呢?让我们在报酬矩阵中加人努力成本这一因素，这是现实的，因为我们完全可以在一定程度上假设每一个人努力工作的同时必然伴随着更多的精神成本。现在我们假设努力工作所付出的精神成本相当于货币3万元，也就是说当产品经理或研发经理在确认努力工作能换来3万元奖励时才认为努力是值得的，那么更新矩阵如表2所示。项目管理者联盟
转自项目管理者联盟
这样，在更贴近现实的同时我们之前的结论随之而不再成立：因为加入努力成本后，个人的努力与收益不再是正相关的了。虽然双方一起努力的话，大家仍然都会更好(每人2万元净收益)，
但单方面卸责却变得更有吸引力，因为这一策略可以依靠他人的努力仍然保持2万元的净收益，同时还能避免他人单方面卸责伤害的可能(-1万
元)。这样一来，在投机与猜疑的作用下，共同努力的局面将很难维持。双方都不再(也不敢)对共同努力抱有希望，因为每一个人都不认为自己的努力必然会使自己的处境更好。项目管理者联盟
当然，“普遍卸责”这一极端的结论并不为事实证据所支持，至少通过经验观察并没有发现在企业中存在普遍明显卸责的行为。但企业中普遍
存在的“松懈”却是显而易见的，这在一定程度上吻合了我们的推论。这种普遍存在于组织中的松懈、卸责，实际上都可以归结为经济学理论中的“外部性”，即每个人努力的好处会平等分K，但成本对各人却不同，从而使
人们倾向于“搭便车”。项目经理圈子
在软件企业里，无论是产品经理，还是研发经理，每个人都可以在各自的职责范围内作出损害项目利益的决策却让整个团队分摊相应后果。研发经理可以为了冒险褚神、盲目引
入新技术而不顾项目风险;产品经理也可以对需求不加过滤、任由产品臃肿不堪而到最后什么都不是。这难道不正是我们平时观察到的典型现象?如果每个个体都渐渐明白：自己的努力在整体绩效面前是如此渺小、面对背叛时又是如此脆弱，谁还愿用努力工作去赌那不堪一击的团队精神呢?项目管理者联盟
于是我们陷入一种两难境界：一方面，我们无法按岗位考核来分开激劻产品经理和研发经理;另一
方面，我们又无奈地发现，将双方命运绑在一起也并不能必然激励他们共同努力。分工只是开始，
但分工并不暗示着某种必然的美好结果。我们常听说王子与公主最后一起过上了幸福的生活，但幸福不是必然。王子与公主是知道的，如果一起
力的话，他们会从此过上幸福的生活。但他们也知道，没有谁能保证另一半也是这样想。training.mypm.net
三、看不见的较量pmp.mypm.net
有种情形非常见：作为下游，研发经理常抱怨产品经理的工作很糟糕，指责他们的需求含糊不清且相当易变;而产品经理则认为在给定的材料下他已经做得最好了。同样，产品经理也会经常抱怨，不明白一个简单的修改为什么会这么难;而研发经理则认为，作为上游的产品经理根本没有意识到相关修改的技术难度与附加成本等。项目管理者联盟
假如在一 个信息透明的世界里，这一切都不会发生，就像如果每个人都知道某种商品买卖双方的底线，那
么讨价还价将没有任何意义。但可惜的是，产品经理并不具备研发经理所掌握的信息与技能，研发经理也同样不具备产品经理所掌握的信息与技
术，这种信息的不对称使得双方都会乐于耗费时间虚报自己的偏好并试图看穿对方的底细。因为通过自己手中独一无二的信息，可以使他在各种讨价还价的战争中有利地保护自己的利益。项目管理者联盟
有时，我们会发现产品经理与研发经理之间的交涉与小贩们并无本质差别。当客户需要得到某个功能并指定了某个期望时间时，产品经理往往不会把真实的需求时间告知研发经理，而是倾向于报一个更短的时间，因为他假设对方的估算总是
有水分或者预期会“还价”;而在研发经理给出时间估算时，我们自然也不能阻止他猜疑期望时间的真实性，从而报出一个更安全的时间。也许这个经研发经理“深思熟虑”的时间甚至都超过了客户的预期，这样一来，一个可为产品增值的机会就在这愚蠢的讨价还价中与我们失之交臂。
又或者，研发经理接受一个据说“紧急”的需求，
这个需求原本是可以在真实的需求时间里做好的，但由于时间紧急，研发经理被迫采取一些临时手段来达到产品经理的目标，这样结果可想而知。一种可能是，这个需求被匆忙地实现，最终因为技术债务越来越多反而超过真实时间;另一种可能是，产品经理最终如愿以偿，只不过得到的是一个埋下一堆潜在风险的版本。项目管理者联盟
讨价还价总是有成本的，而这些成本往往又是如此触目惊心。在商业世界里，我们可以因价格不满意而寻找其他卖家。在商业世界里，没有效率的供应商会被竞争无情地淘汰。但这些在企业部
门之间的交易中却不存在。研发经理不能因为产品经理无能而选择与其他产品经理合作;而产品经理也往往没有权力淘汰研发团队。随着过程越来越专业化，这种存在于组织中的部门垄断力度也就越大。其必然结果就是，研发经理与产品经理都没有改进自己效率，也都没有改进合作的过程，讨价还价的成本会一直存在。club.mypm.net
四、不理性的理性决策项目管理者联盟
|
