在介绍工具进行高速迭代之前，这一章我要先谈谈，如何在时限之内，准时上线项目的技巧。
一个项目高达 600 个细节，其实也不是一件轻松的事情上。我们不仅准时完成，细节还经过打磨。其实背后是有秘诀的。
我们内部做项目，其实也有一套与一般团队不同方式的开发顺序。这套方法，我们称之为「逆向法」。
2012 年，我曾经与朋友双人组队，在 Facebook 举办的 Hackathon 获胜拿下大奖。
大概在六年前，我还没开始创业前，当时我个人搭建项目的速度已经很牛逼。
其实连这次参赛，也是有备而来，只是我没想过会拿第一名而已。
很多人以为 Hackathon 获胜需要完全凭藉运气与技术功底，但是，其实 Hackathon 其实也是可以「准备的」。
我当时参赛的作品是一个书签收集服务（其实挺无趣的）。当初打算解决的痛点是：
- 当时每个人在 Facebook 每天都会 Like 很多页面
- 但是一 Like 过，隔几天就不知道去哪里了。
- 无法储存收藏觉得有价值的连结
我想开发一个网站，让一般使用者透过这个服务，可以自动收集整理自己曾经在 Facebook Like 过的书签，并且搜索整理。
听起来真的挺没劲的。这个功能 Facebook 怎么可能没有。但是在 2012 我参加这个比赛的时候，Facebook 还真的没有这个功能。
这个功能，Facebook 一直到 2014 年才上线。
当时朋友也觉得我这个点子，当时听起来就是去送死。做这个产品有意义吗？
但是，挑选这个点子，作为参赛项目，真的是有目的性的。
在比赛前，我总结以前打过几场 Hackathon 的经验，检讨出前几次我之所以落败的几个主要原因：
- 太贪心 - 想在比赛里面做尽可能多的 Feature，结果作不完
- 没有人懂价值 - 功能作不完，简报没时间做，上台乱讲导致上台时没有人懂这个产品的价值
- 不能用 - 写不完结果没有时间测试，裁判一按下去，产品就是烂的不能用
- 自HIGH - 自己做了一个觉得很炫，工艺很高的产品，但是完全不合主办单位举办这个比赛的期望
以前在我单纯的想法里面，我认为打 Hackathon 要赢：只需要代码牛逼，IDEA 牛逼，这样就能确保最后胜利。
但是往往事与愿违。
一般来说，在黑客松结束过后，大家批评得最凶的往往是「赢下大奖的怎么都是那些 "PPT 组"」。
从这件事，我却发现了一个隐藏的真理。虽然很不公平，但是在实际状况中，一般评审根本没空可以查核代码质量，评审只关心最终成品解决了什么问题，试用的时候是否真如同参赛者宣称的一致而已。至于作弊与否，那都是赛后的事了。
所以这就是为什么 PPT 组容易赢的原因。评审多半只评审最后结果。没有兴趣去评核后面的工艺。
但是即便我知道这个「密技」，身为有一个有自尊的程序员，在 Hackathon 中「作弊」 -- 改用 PPT 去竞技，是绝对不可能的念头。
无论如何，我觉得过去的打法，的确是有不少改进空间。我归纳出了几条很简单的战略：
- 功能要单纯，最好只有一个主要功能，这样才做得完。
- 要做对主办单位有意义的项目
- 扣除开发时间外，要留足够多的时间写投影片与 DEBUG
下次这么做也许有可能赢。所以才挑了这么样的题目 --- 无聊但对主办方有价值的题目。却没想到一举赢下了最大奖项。
我认为打 Hackathon 其实跟创业这件事其实是非常相似的。
- 需要牛逼幻灯片
- 正确的产品，适合主办方开新闻发布会
- 在最短时间，开发最小可行性产品
- 需要牛逼幻灯片
- 被市场认可并获利
- 在正确的时间点启动上线
所以。其实我们可以把打赢一场 Hackathon，比喻为挑战在 10 小时之内创业。
当时我们是怎么赢得 Hackathon 大奖的呢？
主要有几点关键因素：
- 我们上台的时候，做了很牛逼的投影片。甚至在上台之前，我在台下演练了很多遍。
- 最后做出了一个对主办单位很有意义的项目
- 比赛时间只有 9 小时，我们在时限之内做出了一个完整的产品
在这当中，我们用了以下这样的策略：
当时比赛是是早上9点开始的，下午6点必须上台 pitch。所以总长总共有九个小时。
因为时间只有这么短，但却要有完美的效果。
我计算出来，我必须至少留两个小时写投影片并且彩排。
所以开发时间剩下：九个小时扣掉两个小时就是七个小时。那七个小时里面又扣掉吃饭的时间，还有上厕所的时间，大概一个半小时到两个小时。所以留给真正开发的时间只有五个小时。
那么五个小时之内，可以开发多少功能呢？
给大家五秒钟的时间想看看，五个小时我能写多少功能？1、2、3、4、5，答案是一个功能。
为什么到最后决定只写一个功能？
各位应该有这样的经验，每当你时间不够的时候，还特别容易出错。平常比如说开发一个功能，估计实际测试时，可能会出现五个Bug。所以时间要留开发一个功能与 de 5 个 bug 的时间。
但是时间特别紧急的时候，可能就不是这样了，甚至很可能会发现一口气出现了 15 个 bug。修了这个还出现别的没想到的 bug。
特别紧张的时刻特别容易出现。
为了怕莫非定律干扰。我算了一下，如果开发时间只有五个小时，原本依照我的功力应该可以写五个功能。
但是因为一定会出现莫非定律，所以最保险的策略应该是只做一个主要的功能。
所以这是我们第一个策略。我们作品的核心功能非常简单，就是一个网站收藏工具，去抓取并分析Facebook上面的动态，储存回数据库，让使用者之后可以查找。也没有什么特别高大上的功能。
早上9点一到会场，我就只花了简短的时间跟我的队友进行简短的沟通关于早上的战略。
虽然他觉得这点子好像太单薄了。但是因为他比较资浅，所以还是以我的意见为主。
我在以前打 Hackathon 学到的另一个宝贵经验：在比赛时千万不要找太多队友，队友太多意见也会太多。最后光讨论与辩论，时间就用光了。
我记得之前有一次打比赛时，遇到有一个大神组。别人一组顶多 3-4 个人。那组有 11 个。队友每一个都是各领域里面赫赫有名的资深开发者或大神。但是他们那一组，到最后都花在吵架，产品最后真的不怎么样。。。。。
所以这次打比赛，我决定只找一个队友。
因为组成简单，我们只花了很简短的时间，就决定主要进攻方向是什么。
先花了半小时，决定要做哪一些工作。再花一个小时，把雏形框架部署到机器上。
部署网站到机器上。通常是产品做好之后的最后一步。但是，我以前的经验是等到把作品做好之后，放到这个远端的机器里面时。因为本地的环境跟远端的环境还是很不一样。所以得要花很多时间调试，而且在最后面时，时间肯定也不够。
那时候一定会出非常的多的包，会导致投影片也没办法写完。
所以我们先解决这当中可能预见的最大风险。
接下来我们的第二步，再花了一个小时，把主要功能赶快做好，做了一个能够动的第一版 app。
9 点比赛开始，在中午12点左右，我们就有一个可以动可以展示的第一版了。主干功能全部做完。
在12点前开发完第一版有一个很大的战略意义。
很多人不明白为什么要在12点之前要做完？明明下午6点才是截止时间。
在中午12点做完有个好处，就是当中午吃饭时间，其他人还在讨论项目细节的时候。我就在拿着我的笔电炫耀我已经做完的进度。虽然只是第一版App，但是其他人不知道中间其实省略很多细节。只会觉得「我操，Xdite实在太牛逼了。我们可能已经赢不了。」
我要的就是这种效果。所以才拼死在 12点的时候把主要的功能赶快写完 XD。
我第三阶段开始做的是把主干功能上面可以微调的小部分的功能，慢慢的补完。接着拿这个作品到Facebook上面请我朋友真实测试网站上面有没有什么使用上的问题。
为什么要做这件事情？
之前我在参加其他 Hackathon 比赛的时候，最大的扼碗是，根本没有时间好好测试，就是自己觉得简单 debug 完就觉得 ok 了。结果评审一测的时候就烂掉了。
这件事情实在是太囧了，绝对不能再发生。
所以这次比赛的策略是一做完就丢给外面的真实的用户去测，尽可能的在上线前，把有可能出包的问题先都找出来修复。
果然这些测试用户，马上就帮测到很多我不可能发现的小细节。
当时印象中，他们测到有一个非常有用的体验细节：
因为这个项目是分析每个人在Facebook上面的动态，找过自己 like 过的网站。所以需要一定的汇入时间与分析时间。在三个人同时在线的时候，这个网站的汇入速度还是正常的。但是在丢给50个人去测试时，机器就没办法消化这么大的量了。
就一个使用的体验来说：按下汇入按钮，但是却没有马上看到结果或者是进度。正常人会以为是功能烂了。
我才发现，我的排程演算法规划错误了。实际上是有汇入的，只是他们可能没办法马上看到。我设计的过场等待画面，也没办法有效的拖住使用者。
发现这件事情后，我立刻进行细节修正。要是没有做这轮测试的话，估计上线评审一按，马上就会「烂掉」。
所以我真的很庆幸，当时做了一轮完整的使用者测试。大概是在下午三四点的时候，我就把所有的bug全部都修掉了。
在测试这些网站功能的时候，突然间有一个朋友就问： xdite 你们这个产品到底是在做什么的？
我说这产品不是很明显吗？当你每次在网路上赞过很多Facebook连接，过几天要回去找时，就忘了在哪里。FB 没有整理收藏功能，所以我们就做一个外部收藏整理服务。我们是做这个题目，你看不出来吗？
他说鬼才有办法一眼就看出来。你们的首页呢？
他说一般的产品首页都会明自己提供什么服务，建议我们得做一个。
所以我就赶紧做了一个 Landing Page（当时我都还不知道这叫 Landing Page），只知道必须做一个一眼就能说明自己用途的首页。
到了这个阶段，最后还剩下一些时间。我边写投影片边调整。在写投影片的过程中，需要调整一些截图与过场，我就顺便同时调整了网站上一些细节。
在上台之前，我已经台下排练了至少五遍以上PPT。
正常来说，程序员在上台 Pitch 自己作品前，都会相当紧张，一紧张就结结巴巴讲不好，更何况还要Demo，Demo错了之后就更加完蛋。
因为反覆排练了很多遍，在五六点上台Demo时，我的表现简直就是完美（当时是自我感觉）。
所以最后结果是这样的：
- 我们的投影片非常牛逼
- 我本人demo的时候非常的牛逼
- 我们做了一个有意义的产品。要知道这个黑客松是Facebook办的，我们做了其实Facebook想要做的一个功能，但又不知道要不要花RD资源去做做，也不知道有没有市场，所以我们第三个做了一个有意义的产品
- 我们的产品是没有bug的，在 demo 前给很多人测过了，所以没有bug
- 100%production ready，也就是说明天上线，要跟用户收钱或是直接使用，是完全没有什么问题的，完成度极高。
所以这就是为什么我们当场赢得台北站。后续也拿到世界第一名（Facebook 分 3 大洲 23 个城市比赛）。因为我们的产品完整度与意义实在是太高了。
这里我要跟各位分享其他人是如何搞砸他们的黑客松。
不能说是搞砸，没有人愿意搞砸自己的项目。
但是一般人去打黑客松的时候，会是怎么样的策略？
首先一般团队会这样做：
到会场第一个先找小伙伴，看会场有哪些牛逼的小伙伴，然后就询问你要不来我们这一组？
即使他们组成了一个非常牛逼的团队，下一步要做一个牛逼的产品。假设这组有五个人，每个人提了5个feature，光功能讨论会议，就可以花老长时间。可能最后得花了一个多小时，才能决定最后要做的十个功能。
但是十个功能，可能真是做不完的，所以最后砍到 6 个功能。所以他们就分头去做六个功能。接下来 5 个小时，他们埋头的开始疯狂地做实做这些功能。
但是快到截止时间要上台发表了。才惊觉 Fuck，怎么做不完。就只好草草砍到两个确定完整的功能，急急忙忙的收尾。
然后赶快指定一个其中比较闲的人做投影片，另外一个人彩排练习。
但是因为真的没时间测试产品，所以这一队就上去第一个就先道歉：「抱歉我们这个产品没有做完，请大家不要见怪。」
另外一件比较常出现的状况，是demo之后，然后评审以及其他队伍听的这项目觉得可能有点意思，想去试用。结果一开，烂掉了。它自然就被打零分或者是很低分。
几乎99%以上的人打黑客松都是这样输掉，包括我以前也是一样这样输掉的。
这当中我这次的表现跟他们的差别在哪里？
一开场我就已经定调节奏，坚持在中午12点前把一切的东西都做完，并且预留一段完整的时间专注彩排。
我的策略是先保留两个小时彩排时间，两个小时的时间修bug时间。而且在实做做功能上也极度节制。
但是其他人的策略是「没有计画」，直接埋头苦干去做。
所以纵然大家都有 9 个小时时间，但是最后的结果有极大的差异：
- 我把功能完整的上线
- 其他队伍只做出了一个什么都不是的东西
其实，打 Hackathon 这样的策略，不是那一次才想到。早在参加 Hackathon 前，我平常做项目也是类似的结构安排。反而是在打 Hackathon 时，因为没有计画，老是莫名其妙输掉（其实也不冤）。
所以最后我痛下决心，检讨 Hackathon 战略。把平时我在做大型项目的战略技巧搬过来，才大获胜利的。
这样的技巧，可以用在大的中的小的项目。
假设今天我们要做的这个项目，工期时间有三个月。
那么要如何管理这个项目的时间？
我的作法是，不管这个项目是要开发什么软件。一定会先保留最后一个月的时间，最后一个月的时间不能被动。
也就是说老板给我三个月时间做这个项目，我会告诉自己，只有两个月时间能做开发。
最后一段空白，谁都不能动，这段时间是保留给测试的。
接下来我会把剩下来那两个月的时间，再切成把它切三段。
基本上是一些地面作业：
- 项目部署
- 前面章节讲过的「重构法」里面的主干路线
让所有人可以一开始很快的出发，不置于在中间或最后被绊倒。
第二第三阶段实做主干打磨细节：
把整个项目的 must have 主干拉出来。先把整个架构打起来。再利用「重构法」补充细节。这样做的好处是在第二阶段，很快就能知道哪些路是「跑不通的」「没有时间作的」「太过复杂」的。这些主干就可以先「被消失」。
而因为主干功能都已经出来。每个功能的精致程度取决于「重构次数」。所以无论哪个版本。都可以被称之为完整版。
到了最后一个阶段。因为有「足够充裕」的时间。就可以有时间测试，打磨细节。
我在 Hackathon 里面也是这样子做的。先是把下午两个小时的时间完整的保留起来，以中午12点为中间界限。集中火力在早上把大的功能跟最危险的部署部分完工。下午专注在补足功能细节以及修正用户测试后的反馈。
接著很顺利的完成demo pitch，完成上线。
很多人在参与大工程时，很容易一下子就失去了方向准则，以为只要猛力做，最后就会达到所谓的成功。
但是我做项目的做事方法并不是这样子的。
我在启动任何项目前，我都先找出「成功的定义是什么」？
比如说创业第一个「成功」目标是什么？
答案，可能是「顺利完成第一版，成交第一笔订单，收到第一笔入帐」，叫做所谓的成功。如果花了时间，做了一个产品却没有收到钱，这件事情叫做失败。
那么打 Hackathon 中，成功的定义是什么？
我发现的「成功」的定义并不是代码写的多牛逼，而是得让评审认知到这个产品的价值，也就是唯有准备好的投影片，跟好的pitch，吸引评审的目光，你的产品的代码价值才有机会被看见。
所以我反其道而行，「奢侈」的我花了两个小时准备投影片与 Demo。
明明我在写代码上造诣非常牛逼，却选择把最重要的精力放在这里。这是因为在这个场景中，专注准备投影片才能达到「成功」
先找出「成功」的定义，再依据这个准则，去安排当中的进度。
- 什么是主线？
- 什么是副线？
- 什么是风险？
在这个过程中就可以把细节一一梳理出来。
我的作法是：一开始就把风险的活都先抓出来。先建立主干，然后慢慢修整副干。如此一来就会有充裕的时间，知道当中什么事必须做，什么事不需要做。
我在这里，想要再次强调一个概念「项目不是死的，是活的」。
很多人对于项目开发最大的误解，就是认为项目是死的，固定不动的。
项目的进行得按照项目经理写完的一页纸，或是说一大本规划严格执行规划。
但现实真不是这么执行的。在做项目的过程当中，你会逐渐发现，很多当初的预想都跟真实的想象非常不一样。
正常的状况，是很难完成当初预期的一直线计画，去完成所有的进度。只能「尽力」的「无限逼近成功」。
我在这里，为各位总结一下「逆向法」的步骤：
- 先定义成功
- 根据「成功」排定优先级
- 预先保留「测试时间」
- 将剩下的时间切成「三段」
- 第一段：探索、架构主线、预备资源
- 第二段：进行主线要做的事、逐步放弃不重要的事
- 第三段：做好做满收尾主线，尽量丰满支线，迭代「重构」功能，始终保持每个版本都是「完整版」
- 大量反覆验收有风险，会出包的部分
我们在 OTCBTC 开发期间，也是按照这样的节奏。
整个工期是 35 天。切 10 天为测试期，25 天是 开发期。
10 天又分为两种测试：
- close alpha
- close beta
close alpha 的对象是开发组以及营运组人员。也就是与核心较为相关的组别。此时针对的测试目标是这个项目业务上应该被「实作」的 主要故事。
在 OTCBTC 这个项目里，主要的故事
- 使用者可以存币，取币
- 使用者可以发布广告
- 使用者可以下单
- 使用者可以透过站内系统进行交易细节沟通
- 使用者下单后可以对交易进行评价
测试时的情景，要以不同角色各自对这些故事各模拟一遍。因为不同角色在同样功能跑出来的故事流程，是很不一样的。我们测试的角色有：
- 未登入会员
- 登入会员
- 客服权限
- Admin 权限
各个角色都测过一次。
之所以需要这样测试的原因，是因为程序员在撰写功能时，为了方便几乎都是以 admin 帐号在开发。
如果不制定测试步骤和角色，很容易出现流程上的大漏洞。
此时的修复重点放在「补完流程」或「舍去流程」，确认所有「有价值的故事」是否正常运作。
但不需要理会易用度，也不能进行任何 UI 动线上的调整。
close beta 的对象是全公司所有人，公司员工的亲朋好友，可以信赖的死忠会员等等...etc. 此时针对的测试目标是这个项目的使用者体验。（我们后面会有一章 Onboarding，主要就是在讲如何领先竟者，预先几个月迭代出良好的使用者体验）
- 测试第一次存币提币的用户是否流程容易卡住
- 发布卖币广告有许多细节要注意，如何降低使用者门槛，又不容易发错广告造成纠纷
- 流程动线是否让买卖双方容易觉得产生不信任
- 不知道下一步该按哪里
- 网站新讯息的流动是否不够快速，容易造成网站看起来一片死城
此时已经是视同准上线了（所以 Close Alpha 阶段的资料会清掉），所有运营组的人必须视同营运状态一样运营站务。
我们还会用真钱真币实际做交易。以免测不出真的细节。
我们印象中一个比较深刻的测试，是测双方的下单互动。当时程序员都是「快转」测试。也就是两个程序员坐在一起，互相发广告下单，跟隔壁说「我已经转钱了，你快给我放币」。
这样其实是测不出来细节的。所以我下令测试的时候，两个测试搭档是必须要坐在相隔很远的办公室，甚至一个人要在家里，不许用其他方式，不许打电话。纯用网站下单沟通，这样才能真实模拟出来我们的软件有什么问题。
所以后来在我们推出新功能后，都会多测一个「快转」场景。有什么场景是你因为是自己开发了，已经很熟，或者是步骤很复杂，所以下意识在测试时「想快转」。这些在 beta 测试时，都要拿出来一个一个仔细测。
甚至我在上线的头两个礼拜。给了各 10 万人民币给两位运营组同事，请他们也真实下去扑单交易。跟一般用户真实做交易。
一旦用真钱，测试的人，就会更小心。就会更回到用户心态。用这个方法，我们在早期捕捉到了很多内部测试里面，自己没有感知到的细节。
这个阶段的修复重点放在 UX 动线的调整，以及运营方针、步骤的调整，避免开站之后迭代太慢，网站变成死城。
我们把 25 天分为三个阶段。
- 部署期
- 主要功能开发期
- 细节补完期
这个项目的部属期比较短。很大的原因是我们上一个项目是做区块链投资平台，所以已经有基本的钱包功能（存币/取币）了。
所以部署期比较短，主要的时间都是在上一个项目不需要的代码。
我们在上一张提过 User Story。当中的第五版 User Story 长成这样
- 身为一个商家，我要能够在后台上架卖币广告，并且设定上架贩卖
- 身为一个卖家，可以在管理后台上架广告
- 身为一个卖家，可以在发布广告时调整价格
- 身为一个卖家，广告锚定的应该是全球 BTC 行情均价
- 身为一个卖家，可以在买币者下单后，与卖家沟通进行交易
- 身为一个卖家，可以在买币者付完钱打款后，释放数字货币给对方
- 身为一个卖家，可以在买币者下单后，收到通知后，立即处理订单
- 身为一个消费者，我要能够在前台看到广告，并且下单购买
- 身为一个消费者，可以在前台看到下单广告列表
- 身为一个消费者，可以在前台看到广告内容详情
- 身为一个消费者，可以在下单后，与卖家沟通进行交易
- 身为一个消费者，下单之后，卖家数字币必须进行锁定，确保交易安全
- 身为一个使用者，必须在站上拥有数字货币钱包，进行充值 / 提币
- 身为一个使用者，可以申请一个钱包 (BTC/ETH)
- 身为一个使用者，申请钱包后，可以拿到一个数字钱包地址
- 身为一个使用者，可以充值到钱包地址（6个确认后到帐）
- 身为一个使用者，可以发起提币
- 身为一个使用者，必须经过身份验证功能，才能使用完整功能
- 身为一个使用者，必须通过 email 验证
- 身为一个使用者，必须通过 实名 验证（身份证）
- 身为一个使用者，必须通过 进阶 验证（银行卡）
- 身为一个使用者，为了确保资产安全，必须绑定联系方式
- 身为一个使用者，必须通过 email 验证
- 身为一个使用者，必须绑定二步验证
所以这阶段的主要任务是在完成以下 Story 的第一版
- 身为一个商家，我要能够在后台上架卖币广告，并且设定上架贩卖
- 身为一个消费者，我要能够在前台看到广告，并且下单购买
- 身为一个使用者，必须在站上拥有数字货币钱包，进行充值 / 提币
- 身为一个使用者，必须经过身份验证功能，才能使用完整功能
- 身为一个使用者，为了确保资产安全，必须绑定联系方式
在这个阶段，甚至我们做得很简略。甚至是勉强完成整个动线而已。
比如说这个动线。商家发布广告 => 使用者看到列表 => 使用者看到广告页面下单 => 检视下单细节
主程的工作就是先完成每条故事的闭环初稿。接著每两三天，集中起来一条线一条线的「完成主干功能」。
而细节补完期，就是完成第一版之后，重构一遍再一遍。在进行测试前，至少重构三遍。以下是我们钱包页面的演化。
第一版甚至连钱包的地址都是假的。程序员只需要专注在页面上的功能实现。如「显示二维码」「复制地址」「察看区块链浏览器」。
而真实的地址可以交给独立的钱包工程师去实现。这样就可以把开发的相依性彻底分开。
而功能在第二版开始就是「完整版」了，只是「比较丑」而已。
运用这样的开发法，理论在哪一版都是「完整版」。差别的只是体验细节。
我们原本信心满满的想要在一开始就做出全功能版。
但是在主干开发期的第三天，程序员就愁眉苦脸的来找我，说完整版实在做不出来。因为我们根本是重新发明「币版」的「淘宝」与「阿里旺旺」。
所以当下我的决定，就是
- 将「全功能的买卖广告」砍到只有「卖广告」
- 即时聊天室砍掉变成要手动刷新的留言板
- 第一版只支持 BTC
- 只支持简体中文版
后面才在「细节补完期」。视人力资源调配，慢慢偷偷补回来。
我在本书一直强调一个概念：「项目是活的」，所以没有什么是不能砍的或者是加上去的。
甚至是后期在 onboarding 期间补的细节，还会甚至远超过大家的想像。但最重要的是，得一直以「成功的完整版」的概念去释出。「成功的完整版」是指这个网站能够完成「Jobs to be done」的任务。
Jobs to be done 是创新大师 Clayton Christensen 有一本书 Competing Against Luck: The Story of Innovation and Customer Choice 当中的一个概念。他认为每一个消费者会去使用一个产品，本质上是雇用这个产品去干一件活(Jobs to be done)。
这本书的理论是创新不必靠运气或通灵，只要你找到这件事并正确的提供解决方案，最有效帮助顾客达成任务的业者，就能取得竞争的优势。
我们做项目的原则与准则也是如此的。