大家可能会好奇，做完一个软件项目，平均需要完成多少件任务。
我生涯做过几十个项目，我对过去的项目，曾经做了一个统计。
一般来说，一个中型项目，从立项到第一版，平均需要完成 600 个任务。OTCBTC 的数字也大概是如此。
但是，600 个任务，对一般非软体从业界的人来说，听起来简直是天文数字。
这么多的任务，这么多的参与的工作人员。究竟要怎么管理呢？
很久以前，我也对这件事情很有疑惑。直到了我加入了网路公司，我才发现这是有解法的。不仅有解法，解法还多的眼花缭乱。
在一般的网路公司，我们通常会用 "项目管理软件"，进行协作。
我们这里说的"项目管理软件"，并不是单纯指一套工作方法，一套工作软件。根据项目不同的体型，用的项目管理软件也不太一样。
一般小型协作项目的开发，我通常会推荐 Trello。（30 个以内待办事项需要管理）
Trello 是看板式管理。适合待办事项状态简单型的项目（如：尚未实做，实做中，已结束）
中小型项目，我推荐 Tower。（100个以内以内待办事项需要管理）
Tower 适合待办项目多类别型的项目。比如我写书就会用 Tower(第一章需要完成什么，第二章需要完成什么)
至于公司内部软件开发，我们用的就是重武器 Redmine。
Redmine 是一套开源软件。非常适合用来管理复杂的项目。这套软件里面的常见功能，跟一些复杂型项目管理软件(Trac / Jira)相似，但一些特殊功能
- 子母票（展开 User Story）
- 里程碑 （倒数法）
非常整合我们这本书之前提到的流程，加速前进。
在我还没有变成职业程序员前，我曾经以为协作是很简单的。
两个人一起工作，顶多用 email 或者 skype 软件互相沟通需求就好了。后来才发现协作这件事情并不简单。
工作内容是沟通了。但是什么时候开始做，又有多少工作要做，哪些是紧急的，那些是不重要的。待办事项一多或者成员一多简直没法管。个人项目 side project 勉强可以用纸笔或 email 纪录。但是要进入大型协作（一个项目少说10个人以上参与），就一定要用软件管理。
我才知道，连这样的问题，不但已经有解决方案了，还相当成熟。
项目管理工具可以帮到项目什么呢？
通常项目管理工具多具备这些功能：
- Issue 的主题
- Issue 的内容
- Issue 现在的状态 (新建立、已指派、已解决、已回应、已结束、已搁置...etc)
- Issue 优先权 (正常、重要、紧急、轻微、会挡路...etc.)
- Issue 发生日期
- Issue 希望解决日期
- Issue 实际解决日期
- Issue 被分派给谁
- Issue 的附件
- Isuue 的观察者
项目管理软件主要能提供以下这一些的价值：
- Issue List - 透明的列出所有需要被执行的项目
- Issue Milestone 一个地方可以列出阶段内需要被执行的项目
- Project Daily Progress 项目今日整体动态
- Issue Ticket - 一个可以记载 内容，状态、优先权、日期、分派者、观察者，且具有「permalink」、「权限控管」，且让大家可以讨论执行项目细节的地方
- Related Tickets - 可以 cross reference 或具有子票功能
- Wiki - 一个地方可以整理统合专案现在所有的相关资讯
- Personal Dashboard - 一个地方可以看到自己今天需要 Focus 进行哪些项目
- Custom Query - 一个地方能让 Manager 可以看到自己的同事正在进行哪些项目，这些项目目前的状态是什么。
以下是我在 2010 年带领团队费时 2.5 个月开发出来的一套论坛系统。（ 75 天的速度，以2018的标准对我们团队来说是不合格的。但在2010年，这已经是闪电式开发）
开发流程也是一模一样的。我们先写好主干 User Story。然后一条一条的展开次级故事开发。
在展开大的项目故事之后，我们开始利用逆向法，结合 Redmine 的 Milestone 功能，把这些 Issue 一张一张归类到 Milestone 去。这样对每一周需要做哪些项目。就有很明确的归属。
从这一张票上面，就可以看到每一周明确冲刺的进度是很不一样的。
- 第一周 - 准备工程
- 第二周 - 困难技术研究
- 第三周 ~ 第五周 - 主干功能开发
- 第六周 ~ 第八周 - 次干功能开发
- 外包细节单独 Milestone 控管
- 倒数三周 UI 修正
- 倒数两周 - 封闭测试票
- 倒数一周 - 上线前细节票
每一周都有很明确的任务，要完成哪一些任务。
身为项目负责人，我在每周三四的时候，根据这些里程碑内的 issue 消化速度，也大概可以感知到项目现在的进度是落后,超前,卡住, 还是此前过于乐观，据此来调整下一周的待办事项饱和度以及优先权，甚至砍 Story。
Redmine 默认配置只有三种状态 「新建立」=>「制作中」=> 「完成已结束」
我们会扩充到六种不同的状态，以配合真实状态中会发生的状况
- 新建立
- 实做中
- 已回应
- 已解决
- 完成 & 结束
- 搁置不实做
有时候技术改进的决策，在代码上面是无法被叙述追踪的。于是在往前追朔 debug 时，就会无意间破坏原始的设计。越改越烂。
所以我们在工程上做了一些改进。配合 Git 版本控制，希望程序员在开发功能时，以一张 Redmine Issue 作为开发单位。
每一张 Issue 的实做单独开一个 branch。branch 名称取名叫 T5267
指令 git checkout -b T5267
Redmine 上原始决策与设计稿
Git 上实际实现的代码
这样的实做方式可以让
- 每一行代码背后都能重现决策
- 程序员能够将任务切分干净，而不会有一大包任务作不完的感觉
Redmine 切任务切得当，是有办法让程序员感觉沈浸在打怪升级破关之中，而不是一个永远没有尽头解不完的大泥淖。
- 单用 User Story，可以把角色关系厘清的更干净
- 单用 Redmine 项目管理工具，可以协作的更快速
但接下来，我会介绍我们团队怎么样把速度逼到极致。
User Story 其实只是很粗的实做版本。但是实做一张母票，经过统计，平均也是再细切成 10 个子任务，逐步迭代。以下我会分析一些切票的诀窍：
在第一阶段，我们会根据开发周期粗切。大至归类到每个 MileStone 去。 这一类的票的粒度大致上就会是这种等级：
- 身为一个商家，我要能够在后台上架卖币广告，并且设定上架贩卖
- 身为一个消费者，我要能够在前台看到广告，并且下单购买
- 身为一个使用者，必须在站上拥有数字货币钱包，进行充值 / 提币
- 身为一个使用者，必须经过身份验证功能，才能使用完整功能
- 身为一个使用者，为了确保资产安全，必须绑定联系方式
比如说这一周必须要完成「身为一个商家，我要能够在后台上架卖币广告，并且设定上架贩卖」这个大 Story。 那么我们就再把这一个大 Story，再让负责的程序员细切成单天可以解决的任务。
- 身为商家，可以发布广告
- 广告可以设定溢价比例，并跟踪 CoinMarketcap 综合价格
- 上架广告必须缴交手续费
- 下架广告不可以在前台被看到，也不可以被下单
每个人都喜欢自己可以一口气「破关」的感觉。所以得再把任务切到可以「一口吃」的大小
- 广告可以单独设定溢价比例
- 写一支机器人，每五分钟抓取一次 CoinMarketcap 上综合价格并存取在数据库
- 全站每五分钟更新价格，并刷新列表
- 把溢价比例与全站价格做连动
有时候，我们在做某些功能的时候，某些关键功能是无法一个人完成的，甚至得后续花上很多时间。
这时候，切票这一招就非常有用。我们内部有一个原则，凡是：
- 三小时之内没有解法
- 需要其他人给答案
- 或者需要辩论
- 或者需要非常复杂的实做，甚至外包参与
就一律将这一类的问题，开票出来。分配给其他人。
比如说钱包页面，需要展示地址，然后页面上根据地址产生 QRCODE，并且提供自动复制功能
我们就会改成
- 先做一个假功能，产生假的钱包地址
- 根据假的钱包地址产生 QRCODE
- 并且提供自动复制功能
- 请钱包工程师提供真的钱包地址
这样所有的进度，就不会把卡在钱包工程师的进度之上，而一无所获。
相反的，钱包工程师只要一做好这个功能，难度就像一个 "bug fix" 一样。
有时候，我们没有办法一次性写到最完美的功能。比如说在 OTCBTC 当中，买卖家沟通的桥梁是一个能够上传付款截图的即时聊天室。
这个功能难度极度的高，是无法在一周之内就写完的。但是需要有这个聊天室的目的，是要让买卖方在交易当中能够「沟通」以及完成「付款交易」。
所以我们将 User Story 难度降低。
- 第一版降低到双方可以留言，并且上传截图（但是不能即时更新）
- 在第一版写完之后，第二版加上即时刷新功能
- 第三版，接上专业 pusher 第三方服务，重构成真正聊天室
这样不管上线时程如何，我们在哪个时间点，都有一个「聊天室」，只是破不破烂而已。
但不会「没有聊天室」可以用。
在开发中，我们并不会强求，在一张票里面完成所有细节。相反的，我们鼓励把：
对同一个功能的：
- 讨论
- 画面设计
- 后端实作
- UI 调整
- 测试验收
票全部切开独立进行。只是相互关连。这样的好处是不会让一张过长，上面有画面修改又有画面实做，一张票更新长度长达 50 个 update。我们实际上是避免有超长票出现，因为这种票会让程序员想死的心都有了。
短票能够让事情短时间有结论。一张一张的迭代开出来，一张一张的解掉。
整理一下我们的切票原则：
- 大脑当机就该切票
- 被人卡住就切票
- 每个半天都要解掉 1-3 张票
- 有问题就切割出去问，不要耽搁到开发进度
- 切到每张票都能够有「直接解法」。或者是该张票的「主要任务」就是「被切出去弃置」。
虽然感觉这种开票法，会开出非常多票。但是相对的，我们也在当中逐渐把很多细节厘清，并且搁置掉很多因为时间，预算，风险因素，所必须要放一边的待办事项。
虽然票越开越多，但是进度其实是会越来越快的。票开越多才不容易森林大火，因为开票实际上是划出防火巷的一个作法。
这就是为什么我们平均统计，我们一个项目立项到完成必须完成至少 600 个任务。就是利用这种方式加速与逼近。
当然，下一个问题又会冒出来了。根据这样的方式，会有大量的票产生。难道是每个项目组成员自由开打吗？虽然每一阶段有主线，但是看起来支线是自由开打的，会不会方向没有办法被控制，到最后收不了场。
会有这个问题吗？我们其实没有遇到过。我们内部做项目有一个独特的工具以及机制：「指挥官任务」。
这是我在知名辩论家黄执中在罗辑思维「你如何听懂我说的话」学到的一个概念。
30年代，美国陆军的一个排接到的任务是，明早六点钟要登上一个山丘，在山丘上做好防御工事，掩护运输队通过，然后下来帮他们断后，到另外一座桥进行准备补给。
结果第二天一上去，发现山上已经有人了，上不去了，或者天下大雨，上不去，怎么办？
他们的指挥官命就是一句话，如果明天交给你的任务什么都做不到，唯一只能做一件事时，是什么？
那就是保护「运输队通过」。
每个士兵，在接到这个指令时，脑子里会有一个指挥官命令，他知道明天做的事就是保护运输队，一发觉山路泥泞，无法准时在六点上山时，就会立刻改变目标，当到了山顶，发觉视线非常糟，没法瞄准山下的敌人时，也会改变计划。
队员自己就会权衡什么是轻、什么是重。
指挥官命令，就是「只能做一件事，你做什么？」
做 OTCBTC 时
- 我们原先想像的：上线后，马上就有人用。持续 debug，业绩就会增长。
- 真实实际发生的：上线之后，第一天营业额只有38万人民币，3-5天以内业绩都只有100多万，还面临强敌上线险些被灭。
我来谈谈我们 OTCBTC 开站第一个月摆脱死亡漩涡，后续甚至暴冲打下江山的那段过程。
坊间对增长这门技术的印象，就是不断的曝光，不断的增大转化率。
但是创业公司所处的世界，却是这样的：增长的确得不断的增加转化率，但是降低流失率也是增长另一个方向。特别是创业绝大时候，甚至是最初一个月，流失率是远远大于增长率。
如果不把火力集中在「阻止流失率」上，增长只是空谈。
交易所是一个非常特殊的行业。很多人认为交易所只是一个平台。在虚拟币世界里面，交易所等同于「银行 + 股市」的一个角色。要交易，使用者得先存钱进去。但现实来了，一个新币所如何让用户信任，并且开始在上面产生交易。
这件事是没有办法规划的。特别是我们当时在币圈是 nobody。
我们当时在币圈首创了一个先河，就是开了线上即时客服服务。当时我们用了一个线上即时对话工具，叫 Intercom。这个工具很多互联网服务都有采用。但是在币圈都是首创。（即便到现在为止，许多交易所，还是坚持只有 Email 服务，回信周期是「至少一周」。）
很多互联网服务不喜欢提供这个服务，是因为认为运营成本太重，客服成本太高 --- 所以没有必要。
但是我本身是做产品以及增长出身。深知好的客服服务，才是增长之本。（我们在后面的章节会提到客服的章节）
Intercom 真是我们的秘密武器。我们当时是唯一一间，做到早上抱怨，网上就修复上线的币所。全拜 Intercom 所赐。很多早期流程上的瑕疵，就是用即时客服抓出来的。
OTC是一个非常注重体验与运营的行业，因为币圈是一个双方都互相不信任的世界，双方信任非常非常的脆弱。而这样的反应速度，带给了很多试用的客户，极大的安心感。
但很快的，我们发现，体验在其他互联网产品可能是最重要的。但在 OTC 圈不是。OTC 币所，最重要的是深度。
而在站上，最需要宝贝的用户，不是来买币的人，是卖币的人。
为什么是卖币的人？
- 愿意卖币的人，第一得先敢存很多钱
- 能够卖币的人，本身也都很有钱，服务不好他就走了，他没必要跟你在这边瞎闹
所以在这上面卖家地位是远大于买家的，重要性也大于买家。
说穿了，大家都想要买比特币，但是能固定批发做买卖家的就是那几个不动上千万上亿的商家用户。
创业界有一句话是说，可以的话尽量别创需要搞「双边市场」的的公司，难度真的太大。因为双边市场你得同时解决「供应方增长」「消费方增长」的问题。而且也要同时解决「供应方流失」与「消费方流失」的问题。
很不幸的，OTC 平台就是「双边市场」。
开站第一天，我们很快的就意识到，我们网站深度不够。深度就是卖币广告的多寡。而深度是要由卖家来创造。但是我们并没有熟识的卖家。全是尝鲜的散户。
我意识到要是我在第一周没办法解决这样的问题，那么「就没有下一周」了。
所以第一周。我们推出了「永久千一会员」计画。
千一会员计画造成了一个效果。许多平常本身没有卖币的使用者，为了想要刷出资格，各自在微信群里面找朋友「互相刷单」（甚至自己贴手续费）。所以造成两个效果
- 站上广告暴增，想要买币卖币的人绝对找得到对手
- 广告效果直接打穿了，当时币圈每个微信群。甚至对一些 OTC 微信群有了毁灭性的迁移效应
也因为深度直接建起来了。我们 intercom 收到了巨量的反馈，让我们有办法据此迭代改进
我们从倒闭的边缘，瞬间冲到了广告爆棚。（业绩成长到一天一千万人民币）
因为瞬间冲进来了几千个卖家，我们发现，我们对于卖家的机制其实很多细节是不足的。
但是，Intercom 进线进来的客诉太多，我们不知道哪一些该被解决。
而且开发组先改进的功能，客户觉得不重要。反而他们觉得很重要的功能，我们的 PM 却觉得不重要，一直没有安排。所以我的私人微信开始有人直接找我抱怨。甚至扬言不改善他们就走了。
我突然间意识到很严重的一个状况。我们并不是职业交易员，感受不到他们的痛。
所以我立马安排三个内部同事。给他们一二十万人民币。吩咐他们的工作每天就是在上面跟站上的卖家一样职业交易。赚钱算他们的。亏前算我的。果然我们马上抓到一堆「严重」的基本面问题。
例如：防爆仓机制，聊天室通知，改价动线。
因为我们在测试时，都是用假钱与同事互转，根本没有办法测出这些问题。
第三个星期因为量都起来了，深度也足够了。
开始会有一些交易的纠纷。
有一些新手不知道交易的规矩，随意反悔。或者币价波动，反悔。有的根本忘记关广告，不想卖币，反悔。当然，还有随之而来的诈骗（简信诈骗，支付宝微信预约付款然后取消等等）。有的卖家根本不想卖新手等等等等。。。。。
双边市场的难度，还有一个问题在于不指我们网站 UX 设计不好，会让让买卖家流失。交易对手的恶劣态度，也会提高流失率以及丧失对平台的信心。
我们开站时为了要降低门槛，没有经过身分验证的，还是可以买币，但是只能买一百块的比特币，有一些诈骗集团会让卖家先在平台上与他们交易小额，然后诱骗他们绕过平台在微信上直接交易大额。
所以我们又花了一整整个礼拜，针对这一些交易不诚实的举动，全面调整了机制。
这一些举措都不是「预先规划」的。而是我们用 Intercom 侦测到的高并发客诉归纳总结出来的。
我们每一天下午五点都有一个客服交班会议。大概累积到周四，我们就会知道下一周的重点方向应该在哪里。
我们当时只有一个明确的指挥官任务：「不能让上一周的常见客诉，出现在下一周的常见客诉列表」里面。
我们在上线之后的第一个月，几乎是每天工作 16个小时，每周工作七天的状态。我每天都在公司不敢走。前两个礼拜是害怕公司倒，后几个礼拜是 "BUG" 修不完。我不仅要兼当客服，自己还得帮著修代码，写文案。
一直到第一个月把常见客诉消到差不多之后，才开始进行推广活动。
后续又因为客服压力太大。内部又开始开发了部分的客服自动回答辅助机制，以及完整的客服帮助库。
很多人认为做产品与创业，是能够规划的。所以想要追求一套「精准」「按照计画快速执行」的框架。
但实际上要参与这样的游戏，我认为应该要切换成这样的角度。甚至设定成指挥官任务。
- 开发产品进度时「不能被挡住」
- 运营公司时「不能被害死」
所以我们在做产品开发时，每一周都有一个明确要完成的「主干相对完整版」。并且优先权摆在得扫除会卡住的关节进度任务。至于票怎么展怎么砍，原则就是不能 delay。
很多人听到，开发一个项目需要完成六百张票，会感到吃惊。但是我们上线第一个月，细节打磨，就超过了1000票。这些票都不是预先的规划。而是「不做这些就会死」。
我们团队方向不是方向精准，不是老是下对正确决策
这是因为我们体悟到这些事：
- 规划永远与发生的不一样。但这不代表不需规划，而是得做好心理预期，规划有可能不会如你想像的发生，甚至 180 度大拐弯
- 打仗最怕内耗，以及指挥官发出与前线发生不一样的判断，而且不准临机随时应变，结果全队阵亡。所以方向尽量简单，而且只有一个方向
- 创业公司是火箭，不是华丽的太空舱，而是失速（不管是暴冲失速，或者熄火失速）著火的小飞机。太多地方著火了，重要的是去灭下一秒就大爆炸害死所有人的区域。而不是那些关心那些无关痛痒的零件。
- 灭火最重要，姿势不重要。战场上面没有明确与周全，只有 what ever it takes。