如何打造年利润4000万美元的产品——我在微软、亚马逊和百场汇的实践 | 峰瑞商学院
产品开发模式事关初创公司的生死。
什么是产品开发的正确方式？
传统的产品开发思路成本高、速度慢、风险大。如果花高成本做出来的产品不被用户认可，是件可怕的事情。那么，是否有成本低、速度快、风险小的方法呢？做出微信这款伟大产品的张小龙，提到了「敏捷开发」：
「我们今天可以想一些与众不同的点子，然后可以很快就看到效果，因为我们可以很快把它上线了，然后去验证，如果不对就下线，如果有改进余地，下个星期再去改它。这是一个能够持续实现你的想法的过程。」
这种方法由来已久，已被 Google、Facebook 等硅谷企业广泛应用。峰瑞资本（FreeS Fund）投资项目百场汇的 CTO 朱瑞清对此也颇有心得。采用这种模式，他曾在亚马逊带领 8 名工程师创造出 4000 万美元的年利润。2017 年 6 月 30 日，朱瑞清在「Teambition 敏捷项目管理 Roadshow」上分享了自己的实战经验。
在本篇文章中，朱瑞清围绕敏捷开发实战经验，聊了聊这些问题：
- 产品开发的核心是什么？
- 为什么产品开发模式事关初创公司生死？
- 历时 6 年研发的 Windows Vista，为何会失败？
- 产品技术团队和业务团队间为何总有冲突？
- 多少人的团队可以实现规模与效率的平衡？
本期分享嘉宾
朱瑞清 / George
百场汇联合创始人 & CTO
在加入百场汇之前任艺龙副总裁
此前供职于亚马逊、微软、HTC 带团队
负责多条核心产品线的研发
超过 16 年的软件研发和产品管理经验
他曾在微软亚马逊主持大型开发，现在把10万场地空间放进了你的口袋
作者/ 朱瑞清
来源/ 百场汇
我成长在中国，早年去美国留学并工作，在微软和亚马逊做过工程师和产品经理，后来成为职业经理人。在这期间，我曾帮助台湾 HTC 公司在西雅图创建 100 余人规模的研发中心。两年前，我回到中国参与创办了百场汇。
总结起来，我的工作经历包括：在世界 50 强公司主持大型产品开发；在成长型上市公司开疆辟土；在初创公司（百场汇）完成从 0 到 1 的成长过程。在不同环境中开发产品，我有一些成功的经验，也有很多失败的教训。这次很高兴有机会和大家分享。
产品开发的核心是什么？
任何公司的产品开发，核心都是 Deliver（交付）。
也就是说，一个公司无论在其它方面做得多好，如果不能够持续产出优秀的产品，就不可能获得长久的成功。当然，也有一些公司靠 PPT 混得风生水起，但这样的公司不会持久。我相信，这也不是各位的目标。
互联网公司最重要的产出一般是「软件」。软件工程兴起于美国。在过去 50 年中，业界经过长期思考总结后发现，要想完成软件开发，无非是用以下 2 种方法：
-
以功能为驱动： 产品实现某些功能点后，再把它推向市场。例如微信，大家使用微信这么多年，它的外观都没有特别显著的变化，但它把越来越多的功能默默集成起来，成为了全世界最成功的软件之一。
-
以时间为驱动： 一定要在某个时间点之前推出产品。例如一款为双 11 电商节而开发的机器人玩具。一旦产品推出错失了双 11 这个契机，即使产品做得再好，也可能无法完成年度销售额。
▲ 这张图列出了经典软件产品生命周期的 10 段过程，它需要公司多个部门的合作，从市场、产品、开发、测试到运营、销售，非常复杂。
Windows Vista 为什么会失败？
软件业早期，大家普遍使用一种叫做**「瀑布方法」**的开发模式。在这种模式中，项目开始于业务、产品、技术等部门在会议室里的决策——在未来的某个时间点，发布一款拥有 n 个酷炫功能的产品。
在这个会议室里，产品技术团队和业务团队之间往往会产生激烈的冲突，原因在于：
首先，业务团队难以理解需求的复杂度。 例如，业务团队认为在表单上添加一些按钮非常简单，但产品技术团队要考虑的却不仅仅是功能的实现，还有可维护性、可扩展性、可测试性等。对于基础系统尚缺失的初创公司而言，实现这些辅助性功能往往会消耗掉大量的开发资源。
其次，业务团队认为产品技术团队过于保守。 初创公司的业务负责人很可能是一个非常乐观的角色（所以他才会选择创业），会说：「只要大家再努力一些，我们一定能够按时把这个优秀的产品做出来。」但是，产品技术团队知道，**努力只是镜子的一面，需求本身可能会在几个星期后完全变样。**开发过程中的不确定因素不胜枚举。
冲突的结果是大家最终接受折中方案，列出一系列需要完成的任务，然后由产品技术团队为每个任务赋予开发时间值，制定出长度在 3-6 个月的开发计划，大家去执行。
这种模式确实产生了许多优秀的产品，但也有很多失败案例。我个人经历过的失败案例是在微软时参与开发的 Windows Vista。
在 Vista 之前，微软推出的操作系统 Windows XP 是一款非常成功的产品，其在 2001 年发布后打破了各种软件销售记录。做完 Windows XP 后，微软定下了雄心勃勃的计划——用下一代操作系统革命性地改变人们使用电脑的方式。可惜事与愿违，Windows Vista 的开发周期长达 6 年，期间多次延迟进度，数位 VP 被调离，最终在 2007 年 12 月时才勉强发布。之后不到两年，它就被 Windows 7 取代了。直到今年 4 月，微软宣布不再对 Windows Vista 进行「大规模」的维护。
为什么会出现这样的问题？
原因有很多个，其中最重要的是：**当项目开始失控时，决策者本能地投入更多的人力资源。但随着参与人数的增加，沟通成本也成倍增加。**这导致了两方面的后果：
第一，组织结构变得更加复杂。 决策者无法倾听到所有一线人员的意见，必须再找一批产品经理或项目经理代其收集信息和沟通执行。决策者离细节越来越远，决策的失误率和执行的误差率越来越大。
第二，系统的设计和项目团队的沟通方式趋于同态化。 当团队沟通变得低效时，它所搭建的系统架构也会随之变得低效。
在 Windows Vista 的开发过程中，这样的事情发生了许多次。最后，公司不得不进行大规模重组，在数次延迟后，用止血的方式把产品推向了市场。
初创公司如何设计产品开发模式？
意识到传统模式存在诸多弊端后，软件业的有识之士开始一致探索更好的开发模式。于是，在 2002 年，著名的「敏捷宣言」诞生了。
▲ 敏捷宣言的价值观是：
个体和互动 > 流程和工具; 工作的软件 > 详尽的文档
客户合作 > 合同谈判; 响应变化 > 遵循计划
「敏捷宣言」是一系列指导原则，它承认了软件开发的不可预知性，以及开发过程中所存在的随机性。它主张，团队与其把注意力集中在时间和产量上，不如集中在如何改善开发过程，用可迭代、可测试、可成长的方法打磨产品上。
互联网的兴起为敏捷开发提供了更多可能性。我从 2006 年开始大规模采用敏捷开发模式，也取得了一些成功。
比如，我在亚马逊带领过一个库存团队。这个团队只有 8 名工程师，需要支持亚马逊全球的仓储系统，管理超过 30 项服务，处理交易量峰值在每秒 10 万次以上。团队每年能够为公司创造 4000 万美元的运营利润，而实现这些优秀指标的重要原因之一，正是对敏捷模式的有效应用。在传统的瀑布模式下，我们很难达到相同的效果。
大多数公司不会、也没有必要成长到微软、亚马逊的量级。那么，对于初创公司而言，我们应该如何设计开发模式呢？
每个公司的基因不一样，市场环境不一样，产品结构不一样，人员素质也不一样。因此，我并不认为存在一个适用于所有公司的、完美的 SDLC（软件开发生命周期）。不过，在设计开发模式时，我们可以借鉴一些通用的方法论。
首先，我们需要确定组织架构。 这里有 6 个著名公司的组织架构图，基本贴切地描述了他们的架构原则。其中，亚马逊、Google 和 Facebook 的组织架构更适用于互联网公司。
然后，我想介绍一下在敏捷开发中起到关键推动作用的**康威定律 (Conway's Law)。**50 年前，康威从实践意义上提出了关于系统设计的几条定律，在过去 50 年的实践中，这些定律被一次又一次地验证：
- 通讯决定设计。 也就是说，开发组织的沟通方式，决定了最终产品的设计方式;
- 公司的组织架构将会向顾客输出。 尤其是大公司，产品非常明显地展示了内部组织架构的边界。
- 大的组织一定会比小的组织更快崩溃。 崩溃的原因上文也有所提及：组织越大，沟通成本越高；决策者随之引进更多的管理成本，导致信息上下传递的失真，系统臃肿化、复杂化直至瘫痪。
在过去 50 年的实践中，上述定律被一次又一次地验证了。
从康威定律出发，我们能够得出非常重要的推论：组织架构确定后，我们需要确定产品开发部门在公司内部的定位。
业界普遍认可两种定位方式：
以产品定位团队。 产品开发部门不仅仅负责功能输出和产品上线，还会负责整个产品生命周期。他们不仅参与决定「什么样的产品可以被开发、被推向市场」，还需要在产品生命周期的各个环节精细耕耘。
以 IT 项目定位团队。 这种方式在传统公司中更为普遍。比如说，公司需要一个 ERP 系统，就召集一帮工程师把这个系统做出来，项目验收完成后，他们会回归各自的团队，继续他们之前的开发工作。
▲ 两种定位方式的一些对比。
在互联网领域，我认为「以产品定位团队」的方式更能帮你实现成功。
百场汇的敏捷开发实践
在确定架构和定位后，如何打造一个高效而灵活的团队？
首先，要确保信息高效流通。
在传统企业里，信息是权力的一种衍生形式，往往拥有了信息，也就拥有了权力。但在一个先进的互联网公司中，任何人都不该因为信息流通问题而导致他的贡献被公司忽略。这件事情说起来简单，做起来并不容易，需要公司最高决策层的认同。
举例来说，Google 每周五都会举办公司人员和创始人交流的茶话会，所有人都可以直接向创始人提问，包括关于公司战略的关键问题，创始人会坦诚回答，至今公司也没有因此发生重大泄密事故。
其次，与人沟通时要重视书面表达。
企业创立初期，口头表达往往是最有效的方式。可一旦团队规模到了 20 人或以上，口头沟通就会变得复杂而低效，书面表达则会成为更优的沟通方式。
▲ 口头表达（左）与书面表达（右）在逻辑性、系统性上有所区别。
当你希望了解某个话题时，一份书面报告的质量往往高于口头报告或是幻灯片展示。这是因为，当人们用记叙体描述事情前，他自己必须已经把这件事情想得很透彻，书面表达的过程可以帮助他仔细而系统地思考问题的各个方面。
此外，书面表达还可以方便地整理为一个有记录的、可查询的系统。对历史决策有分歧时，大家只要查询之前的书面表达就可以避免很多主观误判。
第三，最有效的作战团队规模是 7-8 人。
亚马逊有一个著名的定律叫做「两个披萨饼定律」，Jeff Bezos 曾说：「任何一个团队如果不能够用两张披萨饼喂饱的话，那么这个团队的规模就太大了。」当然，美国的披萨饼比较大，大约能够 7-8 个人吃。
这个规模恰巧也是美国海军陆战队一个突击小队、或者中国陆军一个班的规模。人类在多个社会领域的实践中都发现，7-8 人最能够平衡团队的规模和效率。
我们公司目前大约有 80 人。如果以 8 人为规模组成小组，会产生 10 个合作小组。考虑到有人会参与多个项目，合作小组的数量还会增加。
这时，一个好的协同工具就变得非常重要。目前，我们使用 Teambition。它的优点是能够快速按照产品和版本组织起多个迭代小组，有效地跟踪和解决各个迭代中遇到的问题。
下图是我们每天在用的敏捷看板，大家可以根据自己公司的情况定义更多或更少的阶段。对我们来说，每一项任务会包括计划、进行、Code Complete、测试，到最后的 Release。
▲ 百场汇的 Teambition 看板，用于跟踪任务进度，责任到人、进度清晰。
再回到如何组织一个高效的团队这个问题上。
效率高低取决于团队能否始终寻找到更好的做事方法。我们不断在做的一件事情就是**把复杂的事情流程化，把复杂的流程简单化，然后把简单的流程自动化。**这样，我们可以把最核心、最昂贵的人力资源聚焦在需要创造力和想象力的任务上。我们相信，很多人力在做的任务是可以用技术的力量解决的。
举一个例子，十年前很少有公司使用开发运维（DevOps）模式。每个公司会有一个运维团队把工程师开发好的程序部署到服务器上，然后监控服务器，一旦软件、硬件、或网络出现问题，他们就会去修复问题。
今天，越来越多的公司不再有这样的团队，尤其是初创公司，例如我们公司就没有。那么上面提到的任务由谁来负责呢？答案是 90% 用软件以及工具完成，剩下的 10% 由开发团队的力量直接完成。
敏捷开发可以为公司创造出有「护城河效应」的战略优势。 因为敏捷开发，我们可以用更少的资源得到更多的产出。当技术平台和产品平台充分地模块化和标准化之后，我们才能够针对每一个细分市场提供定位明确、功能鲜明的个性化产品和服务。
▲ 细分市场的产品策略。
不管是敏捷开发还是瀑布开发，都不是产品技术团队在真空中做出的决策。开发模式对一个公司，尤其初创公司来说，是事关公司生死的大事。初创公司的产品线、技术线、PR 线和资源线都在大幅抖动，存在巨大不确定性。
敏捷开发的前提是团队承认我们很难事先预测开发过程中可能遇到所有的问题， 所以我们拥抱变化，相信能够以迭代的方式产出趋近完美的产品。
▲ 拥抱变化的科学管理。
不过，这也并不代表敏捷模式就没有时间上的限制。任何一家公司，无论产品打磨的多么好，资金链断裂的时候就是大家一起 Game Over 的时候。所以，我认为并不存在完全意义上的敏捷开发，因为时间限制永远存在。
最后，我想举一个在功能和时间上都完成的很好的成功案例。
1961 年，肯尼迪总统向世界宣布，美国会在 60 年代末之前，把人送到月球并安全返回。当时世界上没有任何一款火箭可以到达月球，更不要说返回地球了。但经过美国举国之力，在 1969 年实现了这个目标。很多人并不知道，当时美国同时开发了 20 多套系统。最后把阿姆斯特朗送上月球再带回来的，只是众多系统中的最成功的一个。
所以，再复杂的系统或产品，只要大家怀抱信心、拥抱变化和足够努力，总是有办法达成的。谢谢！
▲ 一个喷嚏都能传染5个人，为什么你的产品烧了500万都不行
