大家可能會好奇，做完一個軟件項目，平均需要完成多少件任務。
我生涯做過幾十個項目，我對過去的項目，曾經做了一個統計。
一般來說，一箇中型項目，從立項到第一版，平均需要完成 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。