Question

“更多的产品特性”并不一定是正确的事情，所以看起来人山人海的开发活动中，各个小组在做的事情也就不一定“都”那么正确。总有团队、总有项目、总有产品会是牺牲品。切近形势的大体上会好一些、保险一些，但一旦形势逆转，又福祸两不知了。这也就是我们所谓的“大……规模开发”中的现实状况——所有人都在战战兢兢，为项目的生死而担忧，为“明天做什么”以及“我能不能做得了”而焦虑。

我在“大规模开发”中间加上了省略号来表示“无限”。因为在我看来，这是一种由“产品多寡”带来的虚假的繁荣。这种虚假繁荣背后是有理论支撑的，亦即“快速试错”与“短平快项目”。前者是一种产品策略，后者是应对产品策略的项目方法——与此还多少有一定关系的，是敏捷开发方法。“快速试错”真的是可行的产品策略吗？答案是肯定的，但必须同时明确：所谓试错总是要付出代价的。这种代价要么是时间，要么就是组织。“较为明智的”做法大体上是牺牲二者中最小的一个。例如创业团队，组织规模是牺牲不起的——总的来说就三五个人十来条枪，所以就只好牺牲时间，于是创业迟迟不成通常是因为产品投入得不对，最后试错成本越来越高以至于不得不放弃 2 。又如大公司的产品线，在组织规模上“通常”是牺牲得起的，因而往往试图同时开发多个产品来及时响应不同的市场需求，于是组织规模越来越庞大复杂，最终组织成本大于产品成本，又变成得不偿失。

试错的定义终是基于成功二字的——成王败寇就是这么个意思。但是对于我们要讨论的对象来说，试错的对象不同，成功的意义也就不同。在团队、项目与产品这三个企业经营的关键视角中：

• 如果试错以团队为目标，则显而易见地变成了组织重构这样的事情；又若以团队为试错基础，即团队可以自行选择要做的事情以及其价值判断，则是各自为战的战术方法。
• 又如果试错以项目为目标，则容易多劳而无功，渐成组织内耗，例如，一个产品开发完就被扔掉便可能是运营部门、生产部门所谈的“项目”在内容上互不相同；但若以项目为试错基础呢，则项目是否作为基础单元以包含对所涉及全部资源的把控，便成必然要求。
• 因此，第三个视角便成了更为常见的选择，即以产品为试错对象。这既在于产品的成败有明确的定义，又在于“面向产品的项目”的管理与控制过程在企业的组织形式上已经较为成熟。

总的来说，在这些视角下存在着职能部门、事业部与产品线这些不同的组织形态，以及各自不同的关于成败与价值取向的定义 3 。

试错的可行总的来说取决于两个方面的前提。第一个方面的前提是组织的可行性。在一个不适宜的组织结构上“试错”，其代价必将是惨烈的——所谓船大难掉头，倒不真的是“船太大”，而可能是船上的拖网太多，要先砍掉拖网才能掉头。所以，这些试错产品便是随时要砍掉的拖网，于是这些拉着拖网的人，便随时可能因为碍事而被推下水。进而，即使船再大，船上的人也都无不战战兢兢了。

一个组织，例如公司或部门，对于试错的结果是否有预期？对于试错的“错”是否能承受？对于试错的收益如何评价？对于试错团队的牺牲持何种态度？这些都是组织层面要考虑的事情。例如，如果我们要有尖刀班尖刀连，那就得有让他们“虽死尤荣”的体制与背景 4 。此外，“短平快”带来的通常是项目主体完整而缺乏细节。因而如何将一个“缺乏细节”的产品推到用户面前而不会招致反感，是一个组织化的行为，也就是说，需要市场、营销与产品的配合。因此，“短平快”如果缺乏组织力，与“死得快”是没区别的，开发完就扔掉、还没上线就说 No、用户三分钟热度等这些问题，基本上都是由此导致的。这也是大公司通常会做“小规模内测”，以及划分高端用户、体验用户、概念用户等特殊用户群体的原因——当我们把“试错”当成一种稀缺资源时，试错就变成了“试鲜”，成为用户有品味的、有 VIP 身份的或者有特权的一种表征了。

第二个方面的前提是试错的必要性。如果一个组织中的大多数项目都是在试错，这既对组织整体的积极性、荣誉感是一种打击，对经营收益来说也是巨大的负担。所以总体趋势上，我们是要减少（而绝不是增多）试错项目的。因此试错绝非“正常的产品决策”活动中的首选手段，它只有在当产品——必须再次强调，这里讨论的“试错”是以产品为目标的——面临类似如下无法直接抵达用户或抵达成本过高的困境时，才适宜作为一种产品的阶段性决策工具来使用：

1. 无法获得用户反馈来支撑它的价值（例如产品线中规划的关键产品环节）；
2. 无法与产品的直接用户沟通需求（例如通过市场调查报告来决策的产品）；
3. 难于获得用户使用产品的细节等。

永远不要试图生产一个“不知道用户是谁”的产品来试错，这绝对是系统性的灾难。反之，若是已经明确了或可以通过用户接触来逐渐明确了用户是谁，要什么，用什么，怎么用等问题，那么这样的产品就不是“试错”，而是“试对”了 5 。

真正有效的、可实施的大规模开发，既是组织上适宜的，也是方向上适宜的。在组织与方向不匹配的情况下的“规模庞大”，既是假象也是负担。而在这其中，“敏捷团队+测试驱动”只是适宜作为一种试错的方法而已 6 。然而无论投入产品的数量，还是实施方法的合理性，实质上都是无助于解决上述问题的。之所以我常常不讨论方法问题，而偏向于讨论方法的前提，其原因就在于此。我们往往在“技术上”准备好了试错，但试错的前提（组织的与方向的，可行性与必要性的）却常常不具备。这种情况下，看起来不错的项目或产品，其最终的失利自是必然，而其成功也多是机遇罢了。