你真的想惹恼开发人员吗？

产品经理与开发团队（或工程团队）的关系是最重要的关系之一，所以我从开发团队开始讨论。软件开发人员是一个有趣的群体，但倘若你没有技术背景，你会感到他们往往是一群不太容易相处的人。正如早先提到的，谷歌公司之所以只聘用有计算机科学背景的产品经理，是考虑到任何缺少技术背景的产品经理将无法赢得开发团队的尊重。开发人员对缺少技术知识的人缺乏耐心，这一点完全可以理解；对他们而言，编程语言、结构、软件架构、操作系统、网络，以及硬件操作是每天工作的具体内容。每一项都有着自身的规则和限制条件，一个开发人员需要协调所有的限制条件，就像解一个多维的填字游戏，才能让产品真正地工作。出其不意和不切实际的设计是令人愤怒的。

真正出色的开发人员能凭直觉从一组软件需求中辨别出，产品在从愿景变为现实的过程中，哪里较为复杂，哪里是性能的瓶颈，还会产生其他哪些困难。之后他们也许会遇到一个此前没有发现的故障，存在于组装产品所依赖的第三方软件的许多不同构件之一，这迫使他们要么重新思考整个方法，要么下大功夫设计迂回开发方案，绕过这个难题。开发人员就像汽车修理师，仅凭引擎转动的声音就能判断出哪里的气缸盖衬垫泄露，并且在下午结束前就能拆卸并修好出故障的零件——开发人员比汽车修理师更厉害。他们是奇迹般的工作者，能将一个产品从愿景变为现实并让其看起来很简单。

如果你真的想惹恼开发人员，下面几个简单的步骤就能做到：

• 没有任何技术知识，也没有任何学习意愿；
• 描述产品需求时含糊不清；
• 低估任务难度并宣称不可能那么难；
• 从不使用产品；
• 毫无预兆地改变想法，并期待交付时间与原先一样；
• 将产品失败的责任全部推到开发团队身上；
• 当真想推动某事时，像个孩子一样喊叫跺脚；
• 宣布决定时永远不给出背景和原因；
• 纵使你根本不知道怎么做，仍开始对如何实施某个特性指手画脚；
• 使用你根本不知道什么意思的技术术语；
• 在做出一个技术决定之前从不跟开发团队的任何人商量；
• 跟用户承诺某些特性，事先却不曾检测一下是否可能实现；
• 从不跟开发团队一起庆祝产品发布或庆祝赢得用户。

另一方面，如果你想和他们很好地共事，就要努力理解他们所应对的难题，这一点大部分公司的许多人都忽视了。

你和开发人员的关系如此重要是有很多原因的，其中一个就是高层管理人员经常认为开发团队要么处处阻挠，要么行动迟缓。当然，这种批评有时确实很中肯，但更多情况下，开发团队已经做得很出色了，而高层管理人员却对指定时间段内完成的工作量有着不切实际的期待，或者某个难题太棘手了，哪怕做一些很小的变更，都需要花上很长的时间。而当开发团队不得不遵循某些过时而复杂的流程，只因没有权力精简流程的时候，团队的效率也会大受影响，而高层管理人员对此却置若罔闻。

当然也不能否认，开发人员有时候确实难以共事。这些人时刻关注软件的细微差别和复杂的交互，会过分关注细枝末节而忽视全局——有时甚至到了执迷不悟的地步。他们对什么是"正确的"做事方式有着近乎宗教般的热情，而在别人提出替代方案的时候，又有惊人的精力来为他们的观点辩护，这类人确实特别令人沮丧。

在我职业生涯的早期，当我还是宙斯科技的一名技术支持的时候，我总能轻易地挑起整个开发团队的激烈争论。我只需要像扔手榴弹一样抛给他们一个问题就行了，比如问一下当时两个主要文字编辑器哪一个更好写代码。不可否认，开发人员有时也令人讨厌。我记得在一次宙斯的社交晚会上，当房间一边的销售们正在卡拉OK（一种伴奏系统）机上引吭高歌、推杯换盏的时候，另一边的开发团队却草草安装了一个多人的电脑游戏，一群人都围着一个桌子，眼睛死盯着屏幕不放。

在任何一个团队，你都会发现有许多不同性格的人，开发团队也不例外。然而，我发现他们确实会分成这几类：一类是梦想者，很可能正在某处的白板上激情昂扬地写写画画，或许还戴着帽子和披风；一类是研究范围窄而精的专家，是像智者一样的，让初级开发员有些敬畏的角色；一类是完美主义者，是最有可能就编程的某个无关紧要的方面争论不休的人；还有一类是废话少、做事踏实的执行者。你还是很有希望地在他们中间找到团队合作者，这类人是非常有帮助的内部人士，他们能化解争论，协调团队的其他成员，最终就实际上什么是"正确的"方式达成共识。

首先我要承认，性格缺点的影响是双向的。我有幸一起共事的开发人员也不得不忍受我早晨的大脑短路以及偶尔的歇斯底里。还有一点必须指出，产品经理可能会越界，犯下对产品开发管得过细的错误。有很多时候，我发现自己不仅指出了所需的特性及原因，还走得太远，对如何交付指手画脚。假如有一个对你的工作仅仅一知半解的人，教导你如何做你的工作，可以想象这是多么令人讨厌的事啊。

其实归根结底，大多数开发人员想要从事有趣而令人兴奋的项目，希望自己凭借出色的工作而被人认可，正如其他每个人一样。在与他们的交流中牢记这一点，将大大有助于你更好地应对那些令人恼火的事。试着体谅一下他们自己也面临着诸多挫折。

我共事过的一个开发团队仍然大部分采用自上而下的瀑布模式，产品特性的优先排序采用了MoSCoW方法，即必须（Must）有，应当（Should）有，可以（Could）有，以及将会（Would）或者不会（Won't）有。公司的质量管理流程要求他们估算所有"必须有"和"应当有"的项的时间和工作量，而我还从来没有遇到过哪一个开发人员喜欢做预算。在一个大的公司背景下，有限的开发人员的时间会被多个项目所争夺，要试着透过这些项目来管理他们的可用时间，在管理层的人看来，以上提到的似乎是个明智的方法，然而，现实情况是，做预算的流程所需的时间往往与解决问题的一样多（甚至更多）。

所以在一个有关排除软件故障的项目上，我召集开发团队，悄悄地建议只要他们同意按照优先级别的清单从高往低工作，直到用完所有时间，我会把每个产品需求标记成"可以有"。这意味着他们不需要浪费时间做注定会出错的预算，可以集中精力修复故障，而他们确实修复了很多。每个人都很开心，只有高级开发经理有点儿生气，觉得我们颠覆了他们美好的质量控制流程。但是团队完成了任务。有时候，开发人员就是在寻求用另一种方式操作的许可，因为他们被管得太细而妨害了效率。

开发人员也喜欢自由发挥他们的创造力，这会带来很棒的东西。然而，创造力是一把双刃剑。虽然一点儿横向思维能让我们轻巧地避过某个障碍，它也可能导致项目脱离路线。因此，尽管你并不想事后批评他们的每一步行动，假如你的团队被一个特定的难题困住，你应当同他们一起克服这些障碍。如果发生了那样的情况，我学到的一个办法就是让他们解释一下所做的假设。你也许会发现他们正在努力地保留你产品的某个不再重要的功能，一旦从整体中拿掉这个功能，下面的路对于开发人员而言走起来就容易得多了。他们需要坚守一些规则，而如果你事先告诉过他们不要破坏现有的产品特性，那么他们将竭尽全力尊重你的意愿。你只需要记得告诉他们什么时候可以破例。

在某些情况下，创造力也会导致产品开发变成一个"科学项目"，没有采用直截了当的方式，而是选择了一种怪诞而又复杂的方式，只因为后者很酷，或者此前没有人尝试过，或者将展示开发人员绝地武士般的超凡技术。这会导致为了技术而技术，有时候需要提醒开发人员，他们能做不代表他们应该做。永远警惕科学项目——如果提议的解决方案看起来过于复杂，寻求第二意见并控制局面。

开发人员会提防西装革履的人，这些人容易提出不合理而又出乎意料的需求，扰乱开发团队的安宁和例行工作。产品经理也许偶尔不得不穿上西装，但你应当努力避免被开发人员归为西装革履的人。产品开发人员很容易把你当成另一个骚扰者，认为你会让他们的日子有一阵子不好过，等失去兴趣或者失望后，便会离开。所以对他们而言，无视你是一个很有效的策略。尤其当你是公司新来的雇员，你更需要加倍努力工作来矫正他们的这种印象。你得成为黑带级别的专家，对你的产品、产品的怪癖，以及没有公开的特性（即：漏洞）了如指掌，并能看透妨碍你充分理解问题的令人迷乱的技术术语。只有到了此时此刻，你才能向开发团队证明你的价值，并赢得他们的尊重。一旦走到了那一步，这种建立在相互尊重基础上的工作关系将会给你带来无穷的益处。

 ——节选自乔克·布苏蒂尔《产品经理方法论》