大型团队开发的产品为什么经常失败？

编者按按道理说大型团队的资源和人力都要比小团队要丰富得多，为什么做出来的东西却经常容易失败呢？MojoTech的创始人兼CEO Nick Kishfy认为，这主要是因为屁股决定脑袋项目的参与者存在本位思想，没有人对最终产品负责。对此他提出了一套可行的解决方案。

有一桩轶事说的是小鸡和一只猪的故事。

故事大概是这么讲的

一头猪和一只小鸡在马路上走着。

小鸡说；“嘿猪，我在想我们应该开一家饭馆！”

猪回答说“嗯，也许吧。那应该起什么名字呢？”

小鸡回应说“叫‘火腿与鸡蛋’如何？”

猪想了一下说“不要。我都献身了，而你却只是参与而已。”

这是一个有趣的故事，但它聚焦了一个问题，在开发产品的问题上，这将意味着成功与失败的差别。

项目管理与产品所有权

技术界给历史更久的既有企业施加了巨大的压力。

成为一家“技术”公司存在很多的压力——要快速、有求必应、敏捷，要开发出伟大的产品（这毕竟是“公司的未来”），但其实这些团队大部分都不知道怎么去做。

团队往往有项目和任务经理，但他们都是在相互独立的IT、设计等部门内工作的，而在很多情况下，没人对整个产品拥有所有权，所以也就没有一个领导来统一自己的团队。

而这个会变成一个很大很大的问题。

传统项目管理的消极影响

这种组织办法的危险是因为但烟囱式的部门只对最终产品的一小部分负有责任时，他们受到的激励是要完成自己的任务，而不是为产品整体创造出最好的结果。

但好产品是不可能由一个四分五裂的团队各自为政地做出来的。

个别部门的“需要”必须让位于产品的需求，否则的话你最终将解决不了合适的问题。

比方说，假设设计团队拿到了产品额度初步概述并被告知了交稿的截止期限。但在第一阶段的过程中，开发团队碰到了一个障碍，这个障碍需要作出困难的取舍；要么关键的设计要素需要变更，要么如果实施新的技术解决方案的话，整个项目都要延误。

这是产品团队经常都要面临的艰难选择，但在基于任务的项目管理环境下，每一只孤立的团队都会为对自己最有利的事情进行抗争。在这里的情况下设计团队不希望返工重新调整自己的工作……如果项目延误的话，好吧，“那是开发者的问题”。

如果致力于一个产品的每个人对最终目标不负责任（实现想要的结果的成功产品），那么这支团队在做出这些艰难决定时永远都会遇到极大麻烦。

就像小鸡一样，每个人都参与了，但没人全身心奉献。

产品管理一个更好的方案

在一个到处都是小鸡的世界里，猪就是国王。

正如我们定义那样，这只“猪”就是产品所有者——对成功产出负责的那个人，在开发和推向市场期间负责指导产品的那个人。

产品所有人被授权对与产品有关的东西做出决定。

他需要做出权衡，确保产品满足你的用户的需求。

他说“我们的用户已经明确指出他们需要这些功能。要开发出来。”

但他还说了“我们不需要你提出的那3项功能。不要浪费时间去开发了。”

然后他又说“我们需要改变这一设计的方向。我们来做吧。”

产品所有者就这样来引导产品走向最终结果一次成功的发布，实现了原来的目标。

可这个角色大多数且根本就没有。实际上，“产品所有者”角色往往由部门经理担当——你觉得他们会为谁的利益去争取呢？

产品团队应该是什么样子？

如果你希望设定一个产品管理方案，那就需要重新组织，让团队像一个产品所有者汇报，而不是部门经理。可能我们需要建立这样一个“产品所有者”角色。

你将需要更多的猪而不是小鸡来让这件事情起效，如果你的组织已经有很多层级的话这实施起来会有点困难。

但重组的痛苦会让你以比旧的项目管理方案快得多的速度创造出好得多的产品并推向市常没有拖泥带水，执行会更加干脆。

相反，你会得到一支统一的团队，大家会有统一的目标，也就是产品的成功发布，而不是部门貌合神离的一起工作。

KPI将会聚焦于商业价值以及对用户的价值上，而不是考核部门的生产力指标。而整个团队将会理解“成功”的真正样子如何怎样，而且将会团队在那些目标背后。

如何实现这种产品管理方案？

我的最好建议是从小处开始。

挑一组人，这些人应该是愿意并能动摇组织现状的人。

你必须至少有一个足够资深的人去克服其他部门沿用旧的项目管理方案的惯性。

赋予这支团队更多的责任，让他们为一个明确定义的KPI负责。

从你可以个用户带来价值的最小项目范围开始。这样的话你就能够找到试验成功的方向。

避免使用针对不同目的创建的现有工具和流程。

要尽可能让你的新产品团队独一无二。让他们选择自己的工具和流程。然后支持他们的决定。

把猪带进鸡舍

从一种工作的项目管理方式切换到另一种工作的项目管理方式是一个很大的改变。这是衡量成功和追求成功的全新方式。

这会让人感觉比较冒险——因为这不仅仅是在打打勾。

你还会面临着小鸡的抵抗。许多员工对于仅仅做被告知要做的事情感到很舒服，对产品的设计和定义做出贡献就不一样了。

但这种改变是值得的。

结论

我们的团队不止一次被召唤去拯救因为本文提到的原因而跑偏的项目。

公司也许会错过新产品的几个截止期限。或者数月（或数年）后他们最终发布了新产品——但却发现自己的用户并不认账或者不知道该怎么用。

他们需要修补产品，而且要快。

几乎在每种情况下，我们发现都是牵涉到了很多人却没有一个人对结果有所有权。

如果你的组织在及时发布产品上遇到了困难，或者未能适应市场，那我建议你先从所有权开始。