回想起第一次开发软件做Demo时，在Demo之前，我是做了充足的准备，软件测试过好几次，可谓是信心十足。不过到了现场演示时，但是还是出了岔子，因为会议台式机网线插口坏了，就借了一台笔记本，装上软件，结果死活连不上数据库，好不容易搞定了，界面显示又一片混乱。:(
我常常将这些问题归结人算不如天算等等。但是xdite接下来所说的逆向法，能确保我们不会陷入这种大多数人都想不到的问题：这个方法就是逆向法。xdite讲起他过去参加facebook的骇客松比赛，当时他就用了极简的软件功能法以及加强型的测试和PPT演示，取得了facebook的大奖。
创业公司的软件产品莫不是如此，你认为再完美的产品，但在客户那儿，总会有各种稀奇古怪的异常产生，所以测试何其重要。
我们看看xdite是如何赢得这个奖的，她是怎么规划和怎么做到的。
以获胜的标准去作好准备
- 一个项目项目高达600个细节、功能，其实也不是一件轻松的事情。
- 我们不仅准时完成，细节还经过反复修正、改良。背后也有秘诀。
- 我们内部做项目，其实也有一套与一般团队不同方式的开发顺序。
- 这套方法，我们称之为“逆向法”。
- 2012年，我曾经和朋友双人组队，在Facebook举办的Hackathon获胜拿下大奖。
- 我如何赢得Facebook的Hackathon大赛
- 我当时参赛的作品是一个书签收集服务（其实挺无趣）。
- 当初打算解决的痛点是：
- 当时每个人在Facebook上每天都会按赞很多页面。
- 但是按赞过，过几天就不知道在哪里了。
- 用户无法储存、收藏觉得有价值的链接。
- 当初打算解决的痛点是：
- 在比赛前，我总结以前打过几场
Hackathon的经验，检讨前几次我落败的几个主要原因：
- 太贪心：想在比赛里面做出尽量多的Feature，结果作不完。
- 没有人懂价值：功能作不完，简报没时间做，上台乱讲导致上台时没有人懂这个产品的价值。
- 不能用：写不完结果没有时间测试，裁判员一按下去，产品就是烂到不能用。
- 自HIGH：自己做了一个觉得很炫，技术水准很高的产品，但是完全不合主办单位举办这个比赛的期望。
- 评审只关心最终成品解决了什么问题，试用的时候是否如同参赛者宣称的成果一致。
- 至于作弊与否，都是赛后的事了。
- 但无论如何，我觉得过去的打法，的确有不少改进空间。
- 我归纳出几条很简单的战略：
- 功能要单纯，最好只有一个主要功能，这样才做得完。
- 要做对主办单位有意义的项目。
- 扣除开发时间外，要留足够多的时间写投影片与DEBUG。
- 这么做也许有可能赢。所以我才挑了这个题目：无聊，但对主办方有价值的题目。
- 没想到竟然一举赢得最大奖项。
- 我当时参赛的作品是一个书签收集服务（其实挺无趣）。
- 打骇客松与创业非常相似
- 我认为打Hackathon 其实跟创业这件事其实非常相似。
- Hackathon：
- 需要厉害投影片。
- 正确的产品，适合主办方开新闻发表会。
- 在最短时间，开发最小可行性产品。
- 好的创业产品：
- 需要厉害投影片。
- 被市场认可并获利。
- 在正确的时间点启动上线。
- 所以，我们可以把打赢一场Hackathon，比喻为挑战在10小时之内创业。
你可以看到好的创业，在先的并不是一个牛得不能再牛的产品，而是被市场认可的机会。xdite是以获胜的标准去参加比赛，因此一定要有优秀的输出认同，她是如何做到的呢？
什么是获胜策略？以Hackathon 为例
- 盘点资源
- 给大家五秒钟的时间想想看，五个小时我能写出多少功能？1、2、3、4、5……
- 答案是：一个功能。
- 莫非定律
- 因为害怕莫非定律干扰。
- 我算了一下，如果开发时间只有五个小时，依照我的功力原本应该可以写出五个功能。
- 但是，一定会出现莫非定律，所以最保险的策略是只做一个主要的功能。
- 比如说，平常开发一个功能，估计实际测试时，可能会出现五个Bug。
- 所以要留开发一个功能与除去5个bug的时间。
- 但是时间特别紧急的时候，可能就不是这样，甚至很有可能会发现一口气出现了15个bug。
- 修改过程还会出现别的、没想到的bug。特别紧张的时刻特别容易出错。
- 风险控管
- 在比赛时千万不要找太多队友，队友太多意见也会太多。
- 最后光讨论与辩论，时间就用光了。
- 因此这次打比赛，我决定只找一个队友。
- 组成简单，我们只需花很简短的时间，就决定主要进攻方向是什么。
- 先花费半小时，决定要做哪一些工作。
- 再花一个小时，把雏形框架传到机器上。
- 预先解决主要风险
- 因为本地的环境跟远端的环境还是很不一样。
- 所以得要花很多时间调整测试，在最后阶段，时间肯定也不够。那时候一定会出非常的多的包，会导致后续投影片也无法完成。
- 所以，我们先解决这个可能预见的最大风险。
- 反复修正测试，降低出错概率
- 在第三阶段，我开始把主干功能上面可以微调、小部分的功能，慢慢补完。
- 接着拿这个作品到Facebook上面，请我朋友实测网站有没有什么使用上的问题。
- 所以我真的很庆幸，当时做了一轮完整的使用者测试。
- 大概在下午三、四点的时候，我就把所有的bug全部都修正完毕。
- 展示产品的价值
- 一般的产品首页都会标明自己提供什么服务，他建议我们得做一个首页。
- 所以我就赶紧做了一个Landing Page，当时我都还不知道这叫Landing Page，只知道必须做一个一眼就能说明自己用途的首页。
- 到这个阶段，最后还剩下一些时间。我边写投影片边调整。
- 在写投影片的过程中，需要调整一些截图与过场，我就顺便同时调整了网站上一些细节。
- 无聊的作品无聊的过程才能赢
- 所以最后结果是这样的：
- 我们的投影片非常厉害。
- 我本人Demo时非常厉害。
- 我们做出一个有意义的产品。
- 要知道这个骇客松是Facebook主办，我们做了其实Facebook想要做的一个功能，但又不知道要不要花RD资源去做，也不知道有没有市场，所以我们做了一个有意义的产品
- 我们的产品没有bug，在Demo前给很多人测过，所以没有bug。
- 100% production ready，也就是说就算要明天上线，跟用户收钱或是直接使用，完全没有什么问题，完成度极高。
- 所以最后结果是这样的：
- 其他人的参赛策略
- 但是一般人去打骇客松的时候，会是怎么样的策略？
- 首先一般团队会这样做：到会场第一个先找伙伴，看会场有哪些厉害的伙伴，接着就询问你要不要来我们这一组？
- 假设这组有五个人，每个人提了5个feature，光功能讨论会议，就可以花费很长时间。
- 可能最后得耗去一个多小时，才能决定最后要做的十个功能。
- 接下来5个小时，开始埋头疯狂地实做这些功能。
- 另外一个人彩排练习。可是因为没时间测试产品，所以这一队上去第一个就先道歉：“抱歉我们这个产品没有做完，请大家不要见怪。”
- Demo后，评审以及其他队伍听起来觉得这项目可能有点意思，想去试用，结果一开，烂得无法用。它自然就被打零分或是很低分。
- 但是一般人去打骇客松的时候，会是怎么样的策略？
- 结果导向去做进度安排
- 一开场我就已经定调节奏，坚持在中午12点前把一切东西都做完，并且预留一段完整的时间专注彩排。
- 我的策略是先保留两小时彩排时间，两小时修bug时间。而且在实做功能上也极度节制。
- 我把功能完整上线。
其他队伍只做出了一个什么都不是的东西。
我们自己在做任何事何偿不是如此呢？越简单越来掌控，而无论准备有多充足，临时的测试以及最佳的演示效果，是我们带给评审或客户的终极印象，大多数人本末倒置，xdite导是清楚的把握住了方向，那么究竟什么是逆向法？
绝大多数项目都适用：逆向法
- 检讨Hackathon战略。把平时我做大型项目的战略技巧搬过来，才大获胜利。
- 这样的技巧，可以用在大的、中的、小的项目项目。
- 1.先保留最后“测试”时段
- 不管要开发什么软件。一定会先保留最后一个月的时间，最后一个月的时间不能被挪用。
- 也就是说，老板给我三个月时间做这个项目，我会告诉自己，只有两个月时间能投入开发。
- 最后一段空白，谁都不能动用，这段时间需要保留给测试。
- 不管要开发什么软件。一定会先保留最后一个月的时间，最后一个月的时间不能被挪用。
- 2.有节奏的冲刺“完整版”
- 接下来我会把剩下来那两个月的时间，再切成三段。
- 基本上是一些地面作业：
- 项目部署。
- 前面章节讲过的“重构法”里面的主干路线。
- 第一阶段，先让所有人可以一开始很快的出发，不置于在中间或最后被绊倒。
- 第二、第三阶段实做主干，反复修正细节：
- 把整个项目的must have主干拉出来。先把整个架构打起来。再利用“重构法”补充细节。
- 这样做的好处是在第二阶段，很快就能知道哪些路是“不通的”、“没时间制作的”、“太过复杂的”。这些主干就可以先“被消失”。
- 因为主干功能都已经出来。每个功能的精致程度取决于“重构次数”。无论哪个版本，都可以被称之为完整版。
- 3.打磨细节，消除瑕疵
- 到了最后一个阶段。因为有“足够充裕”的时间。就可以有时间测试，反复修正细节。
- 任何项目都得先定义“成功”再开始起跑
- 我在启动任何项目前，我都先找出“成功的定义是什么”？
- 比如说创业第一个“成功”目标是什么？
- 答案可能是“顺利完成第一版，成交第一笔订单，收到第一笔入帐”是所谓的成功。
- 如果花了时间，做了一个产品却没有收到钱，这件事情叫做失败。
- 先找出“成功”的定义，再依据这个准则，去安排当中的进度：
- 什么是主线？
- 什么是副线？
- 什么是风险？
- 我的作法是：一开始就把风险的部分都先抓出来。先创建主线，然后慢慢修整副线线。如此一来就会有充裕的时间，知道当中什么事必须做，什么事不需要做。
- 项目不是死的，是活的
- 在做项目的过程当中，你会逐渐发现，很多当初的预想都跟真实的情况非常不一样。
- 正常的状况很难完成当初预期的一直线计划，常常只能“尽力”去“无限逼近成功”。
- 我在这里，为各位总结一下“逆向法”的步骤：
- 1. 先定义成功。
- 2. 根据“成功”排定优先顺序。
- 3. 预先保留“测试时间”。
- 4. 将剩下的时间切成“三段”
- a. 第一段：探索、架构主线、预备资源。
- b. 第二段：进行主线要做的事、逐步放弃不重要的事。
- c. 第三段：做好做满收尾主线，尽量丰满支线，迭代“重构”功能，始终保持每个版本都是“完整版”
- 5. 大量反复验收有风险，会出包的部分。
可见，所谓的逆向法是以结果为导向的项目战略，就是先定义好结果，成功的结果，然后一定要保留大量的测试时间，如果开发的时间远远不够的话，则砍掉不重要的功能，或者是用精简版的功能取代，但始终保持版本的完整性。
OTCBTC 35天的开发周期，就是使用了逆向法，看看xdite的团队是如何做到的？
OTCBTC 的35 天开发是怎么做到的？
- 1.先保留10天测试开发期
- 整个工期是35天。预留10天为测试期，25天是开发期。
- 10天又分为两种测试：
- close alpha。
- close beta。
- Close Alpha，内测，5个工作天
- Close Alpha是开发组以及经营组人员，也就是与核心较为相关的组别。此时针对的测试目标是这个项目业务上应该被“实作”的 主要故事。
- 在OTCBTC这个项目里，主要的故事：
- 使用者可以存币，取币。
- 使用者可以发布广告。
- 使用者可以下单。
- 使用者可以透过站内系统进行交易细节沟通。
- 使用者下单后可以对交易进行评价
- 我们测试的角色有：
- 未登入会员。
- 登入会员。
- 客服许可权。
- Admin许可权。
- 每个角色都测过一次。
- 程序设计师在撰写功能时，为了方便几乎都是以Admin帐号进行开发。如果不制订测试步骤和角色，很容易出现流程上的大漏洞。
- Close Beta半公测
- Close Beta，是全公司所有人，公司员工的亲朋好友，可以信赖的死忠会员等等。此时针对的测试目标是这个项目的使用者体验。
- Onboarding主要就是在讲如何领先竞争者，预先几个月迭代出良好的使用者体验）
- 此时，已经视同准上线了（所以Close Alpha阶段的资料会清掉），所有经营组的人必须视同运作状态一样经营站务。
- 必须花真钱，甚至是自己的钱去测
- 我在上线的前两个礼拜。各给两位经营组同事10万人民币，请他们也真实下去跟一般使用者真实交易。
- 25天开发期
- 我们再把25天开发期分为三个阶段：
- 部署期。
- 主要功能开发期。
- 细节补完期。
- 部署期
- 这个项目的部属期比较短。很大的原因是我们上一个项目是做区块链投资平台，所以已经有基本的钱包功能（存币、取币）。部署期比较短，主要的时间都是在去除上一个项目中这次不需要的程序码。
- 主要功能开发期
- 我们在上一章提过User Story。当中的第五版User Story长成这样：
- 身为一个商家，我要能够在后台上架卖币广告，并且设定上架贩卖。
- 身为一个消费者，我要能够在前台看到广告，并且下单购买。
- 身为一个使用者，必须在网站上拥有数码货币钱包，进行储值、提币。
- 身为一个使用者，可以储值到钱包位址（6个确认后到帐）。
- 身为一个使用者，必须经过身份验证功能，才能使用完整功能。
- 身为一个使用者，为了确保资产安全，必须绑定联络方式。
- 我们在上一章提过User Story。当中的第五版User Story长成这样：
- 细节补完期
- 细节补完期，就是完成第一版后重构一遍再一遍。在进行测试前，至少重构三遍。
- 功能的取舍，随时随地都是完整版
- 后面才在“细节补完期”视人力资源调配，慢慢补回来。我在这本书一直强调一个概念：
- “项目是活的”，所以没有什么不能砍或者是再加上去的。
不管项目有多紧，测试周期总是预先保留的，基于角色的用户测试，确保呈现给用户的都是完整的有价值的操作。功能方面虽然有所取舍，都保留了完整版本特点。值得软件创业人参考。
