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

   <p>写在前面：</p>    <p>看到这篇文章的时候恰好自己在读那本《设计冲刺》。同时也了解到 <a href="/misc/goto?guid=4959736901020830738" rel="nofollow,noindex">甘特图</a> 的来源--读到这里的时候记起去年看的一本书好像也提到了Taylorism。感觉就像是在说明，比起现在比较流行的敏捷开发方式追求速度而言， <strong>做产品也要有一定方法论。</strong></p>    <p>而在翻译方面，感觉自己把“Rough architectures” 翻译成“粗略的架构”以及“play”翻译成“策略，方法”都有些没有完全表达作者的含义。同时没看过美式橄榄，中间举着些的例子自己也是比较勉强照搬，有点意会而无法言传的意思 :p</p>    <p>译文部分：</p>    <p>以下是我在2016年7月21日温哥华的设计与内容会议上的演讲 PPT 和笔记。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/930faecfd38d91b19ba204e22aebe4f7.jpg"></p>    <p>让我先问问你们一个简单的问题。你是如何完成你的工作？一个语法不太好也不太押韵的句子，对么？意思其实是说，对于最擅长的东西，你一直在重复并持续做着什么？</p>    <p>你们可以继续想想这个问题，让我先来讲讲我回答这个问题的经历。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/203b0e627a92cc5b88e896a45d7905dc.jpg"></p>    <p>我是1994年开始从事互联网行业。那时的互联网有太多糟糕的产品经理驱动项目，这些产品经理往往被开发过程折磨得痛苦不堪而没有能力去应对软件开发过程中的不确定性和波动性。而我则从这第一波互联网浪潮中存活了。</p>    <p>需求文档往往第一天创建后到第二天就没用了，然后整个过程中就开始口述一个很复杂的协议，就是为了取消本来第一天就同意的需求。</p>    <p>而改需求是如此痛苦所以通常会被所有人不惜一切代价去避免。于是最终你会工作在一个基于错误假设而产生一系列不明智需求的项目中。最终导致了大量设计和开发成本，同时也作出了一个在还没上线就缺胳膊少腿的产品项目。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/f69d50a03b817f4192668cf160dc7d52.jpg"></p>    <p>当时比较流行的文档记录方式是甘特图,好像是微软项目（Microsoft Project) 唯一的产品。如果你经历过那个时代，你可能记得整个墙面都被项目的甘特图覆盖的场景。</p>    <p>甘特图展示了工作流程进度和每个流程之间的独立性。人们谈论的瀑布流进程，就是甘特图演化而来。表格记录的工作流之间的依附性就像“瀑布”一样…同时（“瀑布”）也是 TLC 乐队的一首歌名 ;p</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/bb1fbc9311a4772dac031d381fb65b37.jpg"></p>    <p>甘特图的起源大概要追溯到一个世纪以前，一个叫做科学管理的理论。通过科学管理也输出了大量管理咨询人员。科学管理（Scientific Management),也叫泰罗制（Taylorism),是一个分析和综合工作流的管理原理。它的主要目的是为了提高经济效率，尤其是劳动产出。它试图在工厂和商店领域通过最小化无效率员工造成的成本浪费从而最大化他们的经济效益。</p>    <p>甘特和泰勒的发明在1930年代被广泛唾弃和放弃。这些原理非常的丧失人性同时也降低了工人们的士气，这些实践最终失败了。</p>    <p>科学管理的理论依赖于一种观念：完成一项任务只有一种最佳方法。而通过科学管理你可以决定工人最有效率的工作方式（例如，挖煤的最佳方法），然后让所有的员工都使用这种方法。</p>    <p>科学管理理论的内在缺点是对于技术创新或者持续提高效率方面并没有一个清晰的方法。</p>    <p>尽管最后失败了，但是科学管理理论中仍有可取之处应用到了现代工作模式中，两个著名的应用领域就是时薪制和甘特图。</p>    <p>当我在90世纪中期接触到甘特图的时候，它已经80岁了，像是一个由高效产出的生铁文物，也像是即将被运用到软件设计和开发的一剂火药。（翻译得好生硬....)</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/b7d6d5e69f15d734de77036fd9226127.jpg"></p>    <p>但是到了2000年早期，开发软件的纯粹方法逐渐开始出现漏洞:开源软件数量的上升，硬件成本降低以及一些网站公司的不断涌现。</p>    <p>很明显许多第一代网络公司是因为他们开发产品的方式而失败的：单纯的在一个笨重的软硬件模式之上开发自己的产品。（我猜是指开发客户端模式，就像在windows系统上开发软甲客户端这种）， Venkatesh Rao 曾说过这理由也同样适用于工业时期的产品，分发和销售模式的失败。</p>    <p>到了2000年到中期，一大波运用敏捷开发方法开发产品的新型公司诞生了。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/42830dc7e08277a026497e0160c7d272.jpg"></p>    <p>这样的转变绝大部分应该归功于在2001年在Snowbird utah (滑雪胜地）讨论轻量开发方法的17个软件工程师。</p>    <p>他们一起讨论并写下了我们如今叫做敏捷开发方式的一系列意义。</p>    <p>这些意义在变化和适应性上有非常重要的价值</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/fe290ae4cd752a6c9e6f541a09cd7972.png"></p>    <p>与此同时，一些设计公司也意识到了同样的问题，慢慢地，我们不再生成大量的线框图和静态模版，而是产生了大量的工具软件和迭代。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/8539936c8426e4090f3136db82934e24.png"></p>    <p>2000年代见证了技术对商业实现路径的缩短和对传统商业模式的破坏。随着技术将商业分发成本减少到接近于零，速度和敏捷性对于技术公司而言不再是商业竞争的目标而是一种商业化发展的必备存在。</p>    <p>到了2000年代后期，硅谷公司甚至宣布只要发布够快产品失败了也是能被接受和欢迎的。敏捷方法让失败来得更快同时也会出现更多优秀的产品。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/fd5bbe568f89e089996bf2fe5bc419b3.png"></p>    <p>healthcare网站的系统崩溃问题（上图）对于如今在技术圈工作的人都是无可避免的。而这个由秉信工业时代方法的公司（政府项目承包商）开发出来的网站最终得以解救的原因是一群来自硅谷创业公司的开发人员带来的解决方法。</p>    <p>这场失误最终作为了两种不同世界观斗争的结束。在这场斗争中，务实和敏捷最终战胜了死板的方法。</p>    <p>也就是在这种环境中，我们牺牲了“过程”而不断的实现敏捷开发。</p>    <p>过程程序似乎成为了老顽固方法的代言人，成了进步的敌人。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/03fff0efab4392a4670a427771ba586b.png"></p>    <p>自从我们强调了敏捷性，各种各样的工具不断出现并让我们争相追逐使用。这样相似的产品和不断提升的技术已经让开发软件的方法变得越来越容易。这些工具都非常厉害，他们释放了我们的创造力同时也帮助我们找到改善生活的解决办法。</p>    <p>但是我们也开始花费大量时间讨论拿个Javascript 框架更好或者哪个原型工具更出色。我们不断地讨论是否设计师需要学习写代码或者需要学习哪一门语言。</p>    <p>我们一直沉迷于速度，敏捷性以及如何实现它。</p>    <p>而我也一直坚信快速迭代和验证....</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/fabad321c1e4e9f9e7978a6915c1066a.png"></p>    <p>当速度成为了我们唯一的要求，就会变得糟糕起来...非常糟糕。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/23a102f8b782444e64a7fc14bd3fd98c.png"></p>    <p>当我们停下来，然后问自己“你是如何完成你的工作的？”。我们通常不太会回答。我们会倾向于回复一些我们使用的工具。问设计师他们怎么设计的时候，他们通常会回答“用 Sketch”。</p>    <p>这就像是问一个木匠怎么做的家具然后他们回答“用斧子”。</p>    <p>所以回到我在最开始问到的问题…“你是怎么完成你的工作的？”</p>    <p>过去几年我一直在研究这个问题，我对回答很感兴趣所以我问了很多人而我得到的最普遍的回答是...</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/8619c1d8920adb2f00688cf27c328116.png"></p>    <p>“看情况”是一个非常糟糕的回答。但是说出来却感觉不错，因为我们在一个对快速迭代和变化非常看重的行业。这取决于保留选择的价值。</p>    <p>想一下听到用“看情况”作为一个问题的回答，你会选择哪一个？</p>    <p>Q: 机长，你打算怎么开飞机？</p>    <p>A: 看情况。</p>    <p>Q: 医生，你怎么实施今天的手术？</p>    <p>A: 看情况</p>    <p>Q: 你爱我吗？</p>    <p>A: 看情况</p>    <p>用“看情况”回答一个问题有两个问题：</p>    <p>第一，这个回答表明你还不知道你自己擅长什么。也意味着你还没有找到一个可以不断创造成功产出的有效方法。</p>    <p>第二，这个回答是错的。你其实做了很多事情；解决问题，写文档，设计，调研，收集并分析数据。你只是还没有讲这些模式形成规范。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/4ea2263cc46264b8b1f8b50a33737ff3.png"></p>    <p>在对过程进行任何讨论前你必须承认我们的工作并没有那么美好。你必须相信创造产品或者无论你在从事的什么，都不是看不见的，而是可以通过有意的重复动作和框架体系来实现的。</p>    <p>这并不是说机会或者时间都不是变数，只是他们不是唯一的变数。这也不是说一个细致的过程能保证成功，但是能更接近成功。</p>    <p>如果你相信为了找到适应市场的产品的唯一方式就是丢一大堆产品去验证的话，那么接下来讨论一些固有方式就变得很困难了。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/b59ca6bff0cbf8c194b8361deb4a5830.png"></p>    <p>而如果你相信全部都是偶然。那么你也最好不要继续听下去。这就像在说，吸引力法则（The Secret）是一个值得实践的哲学,那么接下来的讨论也会是浪费你的时间。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/1332de2c919110e1b901a67f644d2894.png"></p>    <p>我不相信偶然。我不相信随机性。我相信所有伟大的产品都不是通过偶然而产生的。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/1a31128349b89025b9d5cc6abdb08657.png"></p>    <p>多少人熟悉这个？（上图），这来自 Spotify 向人们解释他们怎么实现敏捷开发的演讲。无论何时我向人们谈论要带目的性地创建我们要做的事情，这都是我想展示的不要太死板的典型例子。</p>    <p>图中有两个问题。</p>    <p>这张图是一个比较典型的迭代设计的简化，所以我想你不会再设计一辆车的时候第一次就想到设计一个滑板。同时图中也在假设有一些足够清晰的证据或数据表明摩托车可以或者应该成为一辆车。</p>    <p>第二个问题是，我们似乎从没有讨论到下一张ppt...</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/19c06259222ff3443a11f9e4f89532de.png"></p>    <p>另外人们讨论得比较少的还有这一张，这张讲到在开始做敏捷开发前应该需要一些计划。粗略的适应性的体系结构会让我们对产品有一些清晰的认识。</p>    <p>但是，什么是粗略的适应性体系结构？</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/f9231f3289801955c807e59f9c0122bc.png"></p>    <p>粗略的体系架构是一系列在不确定环境中提供方向的边界条件。</p>    <p>在即兴发挥音乐中粗略体系架构就是节奏和音调。只要音乐家们不会破坏这些体系并达成一致性，他们就可以创造出无穷无尽的音乐。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/f95c380acbac51930b7f97deb995bc3c.png"></p>    <p>在一些即兴发挥剧院中，粗略的架构体系则是一系列像这样的规则... 说“是的，并且”，“在并且后面加上信息”。“避免问题”，</p>    <p>如果你问一个喜剧演员他是如何即兴发挥的，他们的回答一定不是“搞笑就行了”，他们会告诉你一系列的规则...</p>    <p>我发现的构建产品的最佳架构体系来自于….</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/4be07e3e49154ccba29e2d01688263fe.png"></p>    <p>美式橄榄。</p>    <p>美式橄榄球是一项需要球员和教练随时根据场上不断变化的战况而做出关键策略的运动。队员们需要不断奔跑或者互相传球最终让橄榄球到达指定位置。</p>    <p>关于美式橄榄你最需要知道的就是，它的粗略架构体系，除了规则之外，就是策略。</p>    <p>攻守双方都是通过策略方法来试图赢得比赛。</p>    <p>在每场比赛开始前，教练都不会说提前确定好用哪个策略，因为在队员上场之前没人能知道哪个策略方法会管用。</p>    <p>同样对于球员而言，在场上并不是他们想怎么打就怎么打，为了赢得比赛，队员之前的协调和合作也是必要的。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/3398f08d15f71066570fd8bcc82e5889.png"></p>    <p>在每个美式橄榄教练的职业生涯中，他们或是自己写或是继承出成百上千的策略方式。这些都会写到策略手册当中。如果你从没看过一场美式橄榄比赛，他们看起来就像这样…</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/ced632a8950fefd50f696c598e698393.png"></p>    <p>在美式橄榄中，抢断会破坏防守，三个边锋会守在侧位（没看过美式橄榄，凭一点看足球经验翻的 -0-）。这些你不了解并没什么，最重要的是你需要了解一场比赛的核心关键。</p>    <p>一份策略就是团队对一种比赛情境的一系列应对反应。当教练说“let’s run Statue of Liberty Buck Sweep”（没法翻译..-0-）每个人都知道这是什么意思并且会在赛场上执行这一策略。</p>    <p>如果你说“let’s build an MVP” 大家会知道是什么意思么？（应该是跟上句对应）我们会知道我们该怎么做么？</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/9b430e9f16356932ae74512752594446.png"></p>    <p>如果你看过美式橄榄，你就会发现教练都会拿着一个和图中一样的板子。</p>    <p>板子里都是一些摘自教练自己手册中的策略，这些策略都是为当前比赛准备的。这对他们即时作出决定有帮助。教练一般会有成百上千的策略记在手册上，而真正用上比赛的可能只有一小部分。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/5f5d7189e432ac5f4029e5b8481fd0b1.png"></p>    <p>策略板上有不同的提纲方法选择，以适应一场比赛中可能遇到的不同情况。例如， 3rd down plays, 2 minute drill, kick off plays （我又没办法翻译了-0-).这些策略会在教练的职业生涯中不断被创建。一本策略手册就是一个球队或者教练关于“你如何完成你的工作”问题所搜集到的知识。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/c63ddcc1660bca3983059cf89be3e177.png"></p>    <p>我觉得我们也需要为做产品而写一本策略手册。为了更好更快的做更好的产品我们需要制定一系列策略方法。</p>    <p>为你如何做产品去写一份策略手册对每个公司都是十分重要的，但是也是最容易被忽略的。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/18b7d7571370b67b5f1ef8e437d21d53.png"></p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/da61add38bc70b4e74aa449e01f3cd10.png"></p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/a6f0ca3761ae3e2148c5f81ac3a92a74.png"></p>    <p>有一个一致的格式去归档策略方法是非常重要的。一旦策略方法有了一个标准的格式（成分，过程，工具）就跟食谱很像，这也会让它更容易阅读和理解。</p>    <p>所以你的策略手册也应该有一个一致的格式。你可以创建任何你喜欢的模版。下面是一些可以从美式橄榄方法中学习到的一个模版.</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/d28a8f79973197b95dd727d88b4d17e2.png"></p>    <p>给方法命个名 — 方法命名之后就会有个共享的代号。确保这个名字每个人都能理解。一个叫做 MVP 的方法可能会有许多种含义。</p>    <p>何时开始实施 — 列出方法开始实施的情况。绝大多数方法可能随时在一个产品的生命周期的某个点运用上去。在做产品时事后检讨或者太早评估都不会是最好的，就像在第二场中反击不是一个好主意一样。</p>    <p>为什么实施 — 如果团队运用这个策略用得非常好，他们会期待什么？为什么这个方法最好同时团队会接受 或者团队希望实施之后得到什么好处？</p>    <p>角色 — 列出这个方法中需要的角色，同时还有每个角色需要干的事情。</p>    <p>怎么实施 — 列出实施步骤。以及你可能要做的重复动作。</p>    <p>小提示 — 任何团队需要知道的东西。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/191d00f2dc30cb16f151d0da74cfd304.png"></p>    <p>我看到许多在非死book 的团队用这个方法：设计冲刺。</p>    <p>设计冲刺可以运用在一个项目的特殊阶段从而取得进展。它们有一系列不相关但定义好的方法可以直接运用，从而产生期待的结果。它们有可重复的步骤。</p>    <p>设计冲刺有5天时间，有规定的方法和角色。每一个设计冲刺都是不一样的，所以它也有一个规则去遵守。设计冲刺在项目早期效果最好，但是也可以在产品周期的任何时段去运用（越靠近上线时间效果越差）。</p>    <p>内容地图，原型, 国际化，测试，上线计划…这些都是策略方法。任何可以重复操作的事情都可以算作一个方法。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/5504213caf48be765b3900d8ff6b8a01.png"></p>    <p>有些你可能用得很多...</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/87ffda5b65d6d09bbd0cec22691d2fd7.png"></p>    <p>… 有些可能你不常用。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/8284a3820b2348d202fd3263bc1a60af.png"></p>    <p>有了策略手册，你就可以随时运用到产品中以获得提高：将老的不再适用的方法剔除并持续增加一些新的进去。记住策略手册只给团队用并且里面的方法也只适用于他们。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/62ebed0271e6bb8a8c4aa04f9c3db20c.png"></p>    <p>策略也可以以任何你想要的方式分组...可能你会觉得斯坦福 D学院的思考方法最好（上图）。你可以随时将你的策略方法组织到这些不同的阶段中去。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/0cde548ab0c0249f26ae213e971537f4.png"></p>    <p>一个更偏开发部署的模式</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/a04db01a24c0c1bd04683e17e2236b42.png"></p>    <p>也可以更偏类型一些。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/93738e06e8fd8c8bc07d3c662df18280.png"></p>    <p>也可以按情况来定。从图上可以看到这是团队中队员们知道如何找到自己定位的情况（build mvp），这里是他们可以运用到以前已经有成效的情况（how to test if the product is working）,如果你试图验证一个想法，你可以用这些方法（is this idea any good?)，如果你想决定先做什么并列出优先级，你可以尝试这样一些方法（what should we build first?)</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/02f4563aca8a0359d89f9434a6982cfa.png"></p>    <p>所以下一次有人问你这个问题... 你可以给他们展示你的策略手册。</p>    <p> </p>    <p>来自：https://segmentfault.com/a/1190000008328769</p>    <p> </p>