［译］伟大的产品并非诞生于偶然

---

写在前面：

Medium 上标记为14min阅读时长的文章，翻译花了大概五六个小时。
看到这篇文章的时候刚好本身在读那本《设计冲刺》。同时也了解到 甘特图 的来源--读到这里的时候记起去年看的一本书好像也提到了Taylorism。感受就像是在说明，比起如今比较流行的敏捷开发方式追求速度而言，作产品也要有必定方法论。
而在翻译方面，感受本身把“Rough architectures” 翻译成“粗略的架构”以及“play”翻译成“策略，方法”都有些没有彻底表达做者的含义。同时没看过美式橄榄，中间举着些的例子本身也是比较勉强照搬，有点意会而没法言传的意思 :p

---

原文地址 Great Products Don’t Happen By Accident

---

译文部分：

如下是我在2016年7月21日温哥华的设计与内容会议上的演讲 PPT 和笔记。

让我先问问大家一个简单的问题。你是如何完成你的工做？一个语法不太好也不太押韵的句子，对么？意思实际上是说，对于最擅长的东西，你一直在重复并持续作着什么？
大家能够继续想一想这个问题，让我先来说讲我回答这个问题的经历。

我是1994年开始从事互联网行业。那时的互联网有太多糟糕的产品经理驱动项目，这些产品经理每每被开发过程折磨得痛苦不堪而没有能力去应对软件开发过程当中的不肯定性和波动性。而我则从这第一波互联网浪潮中存活了。

需求文档每每第一天建立后到次日就没用了，而后整个过程当中就开始口述一个很复杂的协议，就是为了取消原本第一天就赞成的需求。

而改需求是如此痛苦因此一般会被全部人不惜一切代价去避免。因而最终你会工做在一个基于错误假设而产生一系列不明智需求的项目中。最终致使了大量设计和开发成本，同时也做出了一个在还没上线就缺胳膊少腿的产品项目。

当时比较流行的文档记录方式是甘特图,好像是微软项目（Microsoft Project) 惟一的产品。若是你经历过那个时代，你可能记得整个墙面都被项目的甘特图覆盖的场景。

甘特图展现了工做流程进度和每一个流程之间的独立性。人们谈论的瀑布流进程，就是甘特图演化而来。表格记录的工做流之间的依附性就像“瀑布”同样…同时（“瀑布”）也是 TLC 乐队的一首歌名 ;p

甘特图的起源大概要追溯到一个世纪之前，一个叫作科学管理的理论。经过科学管理也输出了大量管理咨询人员。科学管理（Scientific Management),也叫泰罗制（Taylorism),是一个分析和综合工做流的管理原理。它的主要目的是为了提升经济效率，尤为是劳动产出。它试图在工厂和商店领域经过最小化无效率员工形成的成本浪费从而最大化他们的经济效益。

甘特和泰勒的发明在1930年代被普遍唾弃和放弃。这些原理很是的丧失人性同时也下降了工人们的士气，这些实践最终失败了。

科学管理的理论依赖于一种观念：完成一项任务只有一种最佳方法。而经过科学管理你能够决定工人最有效率的工做方式（例如，挖煤的最佳方法），而后让全部的员工都使用这种方法。

科学管理理论的内在缺点是对于技术创新或者持续提升效率方面并无一个清晰的方法。

尽管最后失败了，可是科学管理理论中仍有可取之处应用到了现代工做模式中，两个著名的应用领域就是时薪制和甘特图。

当我在90世纪中期接触到甘特图的时候，它已经80岁了，像是一个由高效产出的生铁文物，也像是即将被运用到软件设计和开发的一剂火药。（翻译得好生硬....)

可是到了2000年早期，开发软件的纯粹方法逐渐开始出现漏洞:开源软件数量的上升，硬件成本下降以及一些网站公司的不断涌现。

很明显许多第一代网络公司是由于他们开发产品的方式而失败的：单纯的在一个笨重的软硬件模式之上开发本身的产品。（我猜是指开发客户端模式，就像在windows系统上开发软甲客户端这种）， Venkatesh Rao 曾说过这理由也一样适用于工业时期的产品，分发和销售模式的失败。

到了2000年到中期，一大波运用敏捷开发方法开发产品的新型公司诞生了。

这样的转变绝大部分应该归功于在2001年在Snowbird utah (滑雪胜地）讨论轻量开发方法的17个软件工程师。

他们一块儿讨论并写下了咱们现在叫作敏捷开发方式的一系列意义。
这些意义在变化和适应性上有很是重要的价值

与此同时，一些设计公司也意识到了一样的问题，慢慢地，咱们再也不生成大量的线框图和静态模版，而是产生了大量的工具软件和迭代。

2000年代见证了技术对商业实现路径的缩短和对传统商业模式的破坏。随着技术将商业分发成本减小到接近于零，速度和敏捷性对于技术公司而言再也不是商业竞争的目标而是一种商业化发展的必备存在。

到了2000年代后期，硅谷公司甚至宣布只要发布够快产品失败了也是能被接受和欢迎的。敏捷方法让失败来得更快同时也会出现更多优秀的产品。

healthcare网站的系统崩溃问题（上图）对于现在在技术圈工做的人都是无可避免的。而这个由秉信工业时代方法的公司（政府项目承包商）开发出来的网站最终得以解救的缘由是一群来自硅谷创业公司的开发人员带来的解决方法。

这场失误最终做为了两种不一样世界观斗争的结束。在这场斗争中，务实和敏捷最终打败了死板的方法。

也就是在这种环境中，咱们牺牲了“过程”而不断的实现敏捷开发。

过程程序彷佛成为了老顽固方法的代言人，成了进步的敌人。

自从咱们强调了敏捷性，各类各样的工具不断出现并让咱们争相追逐使用。这样类似的产品和不断提高的技术已经让开发软件的方法变得愈来愈容易。这些工具都很是厉害，他们释放了咱们的创造力同时也帮助咱们找到改善生活的解决办法。

可是咱们也开始花费大量时间讨论拿个Javascript 框架更好或者哪一个原型工具更出色。咱们不断地讨论是否设计师须要学习写代码或者须要学习哪一门语言。

咱们一直沉迷于速度，敏捷性以及如何实现它。

而我也一直坚信快速迭代和验证....

当速度成为了咱们惟一的要求，就会变得糟糕起来...很是糟糕。

当咱们停下来，而后问本身“你是如何完成你的工做的？”。咱们一般不太会回答。咱们会倾向于回复一些咱们使用的工具。问设计师他们怎么设计的时候，他们一般会回答“用 Sketch”。

这就像是问一个木匠怎么作的家具而后他们回答“用斧子”。

因此回到我在最开始问到的问题…“你是怎么完成你的工做的？”

过去几年我一直在研究这个问题，我对回答很感兴趣因此我问了不少人而我获得的最广泛的回答是...

“看状况”是一个很是糟糕的回答。可是说出来却感受不错，由于咱们在一个对快速迭代和变化很是看重的行业。这取决于保留选择的价值。

想一下听到用“看状况”做为一个问题的回答，你会选择哪个？

Q: 机长，你打算怎么开飞机？
A: 看状况。

Q: 医生，你怎么实施今天的手术？
A: 看状况

Q: 你爱我吗？
A: 看状况

用“看状况”回答一个问题有两个问题：

第一，这个回答代表你还不知道你本身擅长什么。也意味着你尚未找到一个能够不断创形成功产出的有效方法。

第二，这个回答是错的。你其实作了不少事情；解决问题，写文档，设计，调研，收集并分析数据。你只是尚未讲这些模式造成规范。

在对过程进行任何讨论前你必须认可咱们的工做并无那么美好。你必须相信创造产品或者不管你在从事的什么，都不是看不见的，而是能够经过有意的重复动做和框架体系来实现的。

这并非说机会或者时间都不是变数，只是他们不是惟一的变数。这也不是说一个细致的过程能保证成功，可是能更接近成功。

若是你相信为了找到适应市场的产品的惟一方式就是丢一大堆产品去验证的话，那么接下来讨论一些固有方式就变得很困难了。

而若是你相信所有都是偶然。那么你也最好不要继续听下去。这就像在说，吸引力法则（The Secret）是一个值得实践的哲学,那么接下来的讨论也会是浪费你的时间。

我不相信偶然。我不相信随机性。我相信全部伟大的产品都不是经过偶然而产生的。

多少人熟悉这个？（上图），这来自 Spotify 向人们解释他们怎么实现敏捷开发的演讲。不管什么时候我向人们谈论要带目的性地建立咱们要作的事情，这都是我想展现的不要太死板的典型例子。
图中有两个问题。
这张图是一个比较典型的迭代设计的简化，因此我想你不会再设计一辆车的时候第一次就想到设计一个滑板。同时图中也在假设有一些足够清晰的证据或数据代表摩托车能够或者应该成为一辆车。
第二个问题是，咱们彷佛从没有讨论到下一张ppt...

另外人们讨论得比较少的还有这一张，这张讲到在开始作敏捷开发前应该须要一些计划。粗略的适应性的体系结构会让咱们对产品有一些清晰的认识。

可是，什么是粗略的适应性体系结构？

粗略的体系架构是一系列在不肯定环境中提供方向的边界条件。

在即兴发挥音乐中粗略体系架构就是节奏和音调。只要音乐家们不会破坏这些体系并达成一致性，他们就能够创造出无穷无尽的音乐。

在一些即兴发挥剧院中，粗略的架构体系则是一系列像这样的规则... 说“是的，而且”，“在而且后面加上信息”。“避免问题”，

若是你问一个喜剧演员他是如何即兴发挥的，他们的回答必定不是“搞笑就好了”，他们会告诉你一系列的规则...

我发现的构建产品的最佳架构体系来自于….

美式橄榄。

美式橄榄球是一项须要球员和教练随时根据场上不断变化的战况而作出关键策略的运动。队员们须要不断奔跑或者互相传球最终让橄榄球到达指定位置。

关于美式橄榄你最须要知道的就是，它的粗略架构体系，除了规则以外，就是策略。

攻守双方都是经过策略方法来试图赢得比赛。

在每场比赛开始前，教练都不会说提早肯定好用哪一个策略，由于在队员上场以前没人能知道哪一个策略方法会管用。

一样对于球员而言，在场上并非他们想怎么打就怎么打，为了赢得比赛，队员以前的协调和合做也是必要的。

在每一个美式橄榄教练的职业生涯中，他们或是本身写或是继承出成百上千的策略方式。这些都会写到策略手册当中。若是你从没看过一场美式橄榄比赛，他们看起来就像这样…

在美式橄榄中，抢断会破坏防守，三个边锋会守在侧位（没看过美式橄榄，凭一点看足球经验翻的 -0-）。这些你不了解并没什么，最重要的是你须要了解一场比赛的核心关键。

一份策略就是团队对一种比赛情境的一系列应对反应。当教练说“let’s run Statue of Liberty Buck Sweep”（无法翻译..-0-）每一个人都知道这是什么意思而且会在赛场上执行这一策略。

若是你说“let’s build an MVP” 你们会知道是什么意思么？（应该是跟上句对应）咱们会知道咱们该怎么作么？

若是你看过美式橄榄，你就会发现教练都会拿着一个和图中同样的板子。

板子里都是一些摘自教练本身手册中的策略，这些策略都是为当前比赛准备的。这对他们即时做出决定有帮助。教练通常会有成百上千的策略记在手册上，而真正用上比赛的可能只有一小部分。

策略板上有不一样的提纲方法选择，以适应一场比赛中可能遇到的不一样状况。例如， 3rd down plays, 2 minute drill, kick off plays （我又没办法翻译了-0-).这些策略会在教练的职业生涯中不断被建立。一本策略手册就是一个球队或者教练关于“你如何完成你的工做”问题所搜集到的知识。

我以为咱们也须要为作产品而写一本策略手册。为了更好更快的作更好的产品咱们须要制定一系列策略方法。

为你如何作产品去写一份策略手册对每一个公司都是十分重要的，可是也是最容易被忽略的。

有一个一致的格式去归档策略方法是很是重要的。一旦策略方法有了一个标准的格式（成分，过程，工具）就跟食谱很像，这也会让它更容易阅读和理解。

因此你的策略手册也应该有一个一致的格式。你能够建立任何你喜欢的模版。下面是一些能够从美式橄榄方法中学习到的一个模版.

给方法命个名 — 方法命名以后就会有个共享的代号。确保这个名字每一个人都能理解。一个叫作 MVP 的方法可能会有许多种含义。

什么时候开始实施 — 列出方法开始实施的状况。绝大多数方法可能随时在一个产品的生命周期的某个点运用上去。在作产品时过后反省或者太早评估都不会是最好的，就像在第二场中反击不是一个好主意同样。

为何实施 — 若是团队运用这个策略用得很是好，他们会期待什么？为何这个方法最好同时团队会接受 或者团队但愿实施以后获得什么好处？

角色 — 列出这个方法中须要的角色，同时还有每一个角色须要干的事情。

怎么实施 — 列出实施步骤。以及你可能要作的重复动做。

小提示 — 任何团队须要知道的东西。

我看到许多在Facebook 的团队用这个方法：设计冲刺。

设计冲刺能够运用在一个项目的特殊阶段从而取得进展。它们有一系列不相关但定义好的方法能够直接运用，从而产生期待的结果。它们有可重复的步骤。

设计冲刺有5天时间，有规定的方法和角色。每个设计冲刺都是不同的，因此它也有一个规则去遵照。设计冲刺在项目早期效果最好，可是也能够在产品周期的任什么时候段去运用（越靠近上线时间效果越差）。

内容地图，原型, 国际化，测试，上线计划…这些都是策略方法。任何能够重复操做的事情均可以算做一个方法。

有些你可能用得不少...

… 有些可能你不经常使用。

有了策略手册，你就能够随时运用到产品中以得到提升：将老的再也不适用的方法剔除并持续增长一些新的进去。记住策略手册只给团队用而且里面的方法也只适用于他们。

策略也能够以任何你想要的方式分组...可能你会以为斯坦福 D学院的思考方法最好（上图）。你能够随时将你的策略方法组织到这些不一样的阶段中去。

一个更偏开发部署的模式

也能够更偏类型一些。

也能够按状况来定。从图上能够看到这是团队中队员们知道如何找到本身定位的状况（build mvp），这里是他们能够运用到之前已经有成效的状况（how to test if the product is working）,若是你试图验证一个想法，你能够用这些方法（is this idea any good?)，若是你想决定先作什么并列出优先级，你能够尝试这样一些方法（what should we build first?)

因此下一次有人问你这个问题... 你能够给他们展现你的策略手册。