找開發團隊之前，你應該先準備好哪些東西

大多數出問題的專案，問題都不是發生在開發期間。它們出問題，是在撰寫需求的那一週，只是兩個月後才有人發現。

想要好的開始，你不需要一份技術規格書。你需要的是幾個問題的清楚答案，而這些問題沒有任何開發者能替你回答。

實際上到底是誰在用

不是「我們的客戶」。是哪些客戶、在做什麼、用什麼裝置、在什麼情境下。

一套由辦公室人員坐在桌前使用的預約系統，和一套由司機在雨中用手機操作的預約系統，是兩個不同的產品——即使兩份需求上寫的都是「預約系統」。

說出主要的使用者是誰。如果有兩種差異很大的使用者，要盡早講——這會改變整個開發的樣貌，而在一開始就知道，成本低得多。

做好之後，哪個問題會消失

具體描述痛點，而不是功能。

「我們想要一個儀表板」是一個解決方案。「要花兩天才能查出哪些案子還沒收款」是一個問題——而它可能用比儀表板簡單得多的方式就能解決。

描述問題的團隊，會比描述解決方案的團隊得到更好的成果，因為開發者能提出更省錢的方法達到同樣的結果。帶著功能清單來的團隊，就會剛好得到那份功能清單，不論它有沒有真正解決任何事。

現在是怎麼運作的，包括混亂的部分

把目前流程實際運作的樣子寫下來——包含例外狀況、手動調整，以及那些「直接打電話問同事」的情況。

這些例外正是軟體專案超支的地方。開發途中才發現的每一個例外，都是一次變更需求；一開始就知道的每一個例外，只是一個設計決定。

如果你的流程只存在某一個人的腦袋裡，就請那個人來參加第一次會議。

誰可以說好

每個專案都會遇到必須在兩個合理選項中做出選擇的時刻。如果那個人沒空，工作就會停下來，或是有人只能用猜的。

專案開始前就決定誰有最終決定權，並確保他有時間處理。一個有三位兼職決策者、卻沒有人能拍板的專案，前進速度會被最難喬的那個行程拖住。

第一版的「完成」是什麼意思

你能帶來最有用的東西，是一份簡短的清單，寫出第一版必須做到的事——以及一份更長的清單，寫出它刻意不做的事。

第二份清單更重要。它能阻止一個三個月的專案變成九個月，而且在一開始寫，比在半途中協商容易得多。

「現在不做」清單上的任何項目，之後仍然可以做。只是要等真實使用者告訴你，它到底是不是真的需要。

你真的不需要準備的東西

你不需要知道該用什麼技術、資料庫要怎麼設計，或畫面應該長什麼樣子。那正是你聘請團隊來做的工作。

你也不需要完成的設計稿。畫在紙上的草圖就很好，而且往往更好——草圖會讓人想修改，而精美的模型只會讓人想點頭同意。

一份合理的起始資料包

帶著這些來，任何稱職的團隊都能準確報價：

• 一段話說明要消除的問題
• 主要使用者是誰，以及他們使用時身在何處
• 目前的流程，包含例外狀況
• 第一版的必備清單，以及一份明確的「現在不做」清單
• 誰負責核准決策，以及他們能撥出的時間
• 任何硬性限制——無法延後的期限、必須串接的系統、必須遵守的法規

這通常只有一到兩頁。它能省下的時間，比一份五十頁的規格書還多，因為其中每一行，都是只有你才能提供的資訊。