一個軟體專案的開展，簽約是一個最重要的里程碑。不論是接案還是外包，能走完簽約這一步，總是有一種「終於搞定」的感覺，雖然開案之後還是有很多事情要處理。
不過，要走到簽約這一步也不是那麼的容易。這中間還有很多預備的文件要先完成，才能讓專案的範圍、驗收條件和專案費用變得透明，在最後簽約的時候才會比較有信心這個案子不會出什麼問題。
當你剛開始創業只有自己一個人的時候，很多細節都必須瞭然於胸，才能夠知道如何跟業主溝通，釐清工作範圍和責任歸屬，或是進行談判協調專案費用。
接下來要介紹的這個流程，是個人從過去接案的過程中歸納出來的細節。其中每一個階段的文件都可以由發包方或是接案方來產出，看彼此的合作方式或是商業模式而定。唯有 Milestone Schedule (時程) 和 Quotation (報價) 是由接案方提出。
大致上整個流程可以分成三個階段：
- 創意階段－整理產品的使用者需求
- 草案階段－轉換成工程端與專案端的語言
- 簽約開案－決定專案範圍與商業條款
Scenario 使用者情境
做一個軟體產品最重要就是知道要提供什麼功能給使用者。如果是 1) 做自己的產品的話，可以從前期調研的 Persona 整理出使用者需求；如果是 2) 接案的話，有時候業主只有一個很粗略的想法，並沒有太多細節可以參考，這樣情況是經常發生的事。
所以這個階段最重要的事，就是把使用者情境描述記錄下來，而使用者情境描述可以利用下面這個公式：
作為一個 <某類型的使用者>，我想要 <達到某一個目標>，這樣做 <的原因是什麼>
例如我們以《如何使用實精畫布》的分享相片這個情境為例：
作為一個爸爸/媽媽，我想要分享我的小朋友的相片給其他的親朋好友，這樣我們可以隨時分享生活中美好的時刻。
子句一 (作為一個…)：說明這個使用者情境是屬於精實畫布上的哪一個客群。
子句二 (我想要…)：說明這個客群想要解決的問題或是他們的需求。
子句三 (這樣…)：說明這個客群，想藉由處理前面子句二的問題或需求，來滿足他們內心真正的渴望和訴求。所以在精實畫布上的解決方案和獨特價值主張，要能夠呼應這個客群的內心需求。
運用這樣的描述法，可以很完美地跟創業者的精實畫布中的規劃相呼應。同時，創業者也可以藉此，去挑選出真正需要解決的問題，以及針對這些問題去設計最好的解決方案。
UI Wireframe 線框圖
經過 Scenario 階段之後，使用者的問題應該已經被條列出來了。接下來，是發揮創意來解決這些問題的時候了。
以分享相片為例，在線框圖階段的時候，創業者需要決定用什麼方式來處理使用者的需求。
使用者想要分享相片的時間點，可能是剛拍完照的時候，也可能是想分享之前的相片。分享的對象可能是固定的某些人，或者是分享時才想要決定對象。依照這些不同的情況，所設計出來的操作流程也會不同。
將這些操作流程用線框圖視覺化之後，創業者就可以很清楚地看出完整的操作流程，是不是能夠很方便地處理使用者想要分享相片的需求。
當然，一個產品可能不會只有分享相片一個需求。所以，如同前面對分享相片的作法一樣，將其他需求都使用線框圖視覺化之後，整個產品的輪廓就非常清楚了。瞭解整個產品的輪廓之後，接下來，是該瞭解如何實現產品的時候了。
Product Requirement Document (PRD) 產品需求文件
這裡我先引用一下維基百科上關於 PRD 的定義，其中介紹一般典型的 PRD 應該包括以下這些部份：
- Title & author information
- Purpose and scope, from both a technical and business perspective
- Stakeholder identification
- Market assessment and target demographics
- Product overview and use cases
- Requirements, including
- functional requirements (e.g. what a product should do)
- usability requirements
- technical requirements (e.g. security, network, platform, integration, client)
- environmental requirements
- support requirements
- interaction requirements (e.g. how the product should work with other systems)
- Assumptions
- Constraints
- Dependencies
- High level workflow plans, timelines and milestones (more detail is defined through a project plan)
- Evaluation plan and performance metrics
從精實畫布開始，走過 Scenario，走過 UI Wireframe，PRD 的第 1、2、4、5、7 點其實已經整理完畢。後面 R & R 階段可以完成 PRD 的第 3 點； Milestone Schedule 可以完成第 9 和 第 10 點，而第 6、8、11 點則是這個階段的重點。
PRD 是產品完整的需求書，也是說明實現這個產品應該包含哪些技術和資源的重要文件。前面透過線框圖，整個產品的流程細節都已經表露無遺，PRD 可以接續著把設計的語言，轉換成專案管理和軟體工程的語言。
接著，我們需要從線框圖中的每一個頁面之中，將每一個按鈕、每一行文字、每一張圖片背後所隱藏的服務運作細節找出來。例如：
- 分享相片需要至少一台伺服器
- 需要建立網路服務 API
- 資料傳輸的回應時間
- 分享對象則會有權限控管的問題
- 分享成功會有訊息通知則需要架設 Notification Server
- 資料上下傳需要做資料加密則需要購買 TLS Certificate 等等。
如此一來，需要完成什麼任務和取得什麼資源，才能完成這個產品就一清二楚了。同時，每一項功能的限制條件和測試驗收方法，也可依此來描述。
舉例來說，假設我們需要設計一個音樂串流的 API。在網路傳輸上，音樂的封包在網路上延遲不能超過 20 ms，不然會被人耳察覺音樂有遲頓的現象。
所以這 20ms 就是封包傳輸延遲的限制條件，而驗收方法則可以是，使用工具軟體檢查每一封包之間的延遲，以確認每個封包的延遲時間低於 20ms。
R & R Matrix 角色與責任陣列
在 R & R 文件中，基本上會說明專案中每個角色所賦與的任務。其中當然也包括合約中供應商的角色，以及供應商應提供的軟體、硬體或是支援服務。另外，R & R 文件中也應該標示其他第三方關係人與專案有關聯的角色及責任。
| 專案角色 | 專案職責 |
|---|---|
| 專案負責人 | 執行專案的決策。包括決定產品功能、是否支付費用等重要決定 |
| 專案經理 | 確保專案成員準時交付專案成果 |
| 專案成員 | 實際執行專案任務的每一個人 |
| 使用者代表 | 代表實際用戶對專案成員說明用戶對產品的期待，並進行測試，提供回饋 |
| 客戶決策代表 | 負責將客戶組織內部的共識，也就是對專案問題以及專案成果的想法，與專案經理溝通。 |
| 供應商 1 | 負責照片分享功能 |
| 供應商 2 | 負責照片特效濾鏡功能 |
R & R 的重點在於界定每個角色在專案中的職責範圍。而細節的功能實作任務，則可以放在 Milestone Schedule 裡面描述。做到這裡，PRD 的第 3 項就可以補上了。
Milestone Schedule 里程碑時程
在展開 Milestone Schedule 的時候，可以善用一些工具，像是 Microsoft Project 或是 OmniPlan。以下的附圖是利用 OmniPlan 展開工作項目的例子。
在前面 PRD 的階段，所有工作細節應該已經從 Wireframe 中，一樣一樣的抽取出來。然後依照軟體、硬體、雲端程式、App 程式等等的類別，分門別類，排列妥當。
現在只要將每一項工作，抄錄在 OmniPlan 或是 Microsoft Project，再填入工作負責人以及預估工時，再依照專案任務的相依性，重新整理專案，則專案的關鍵鏈，或者稱要徑 (Critical Path)，也就是專案時程中最長的那一條路，所有會影響專案時程的任務，都會被找出來。
做到這裡，PRD 的第 9，第 10 項又可以補齊了。
Quotation 報價
有了前面預估的人力工時 (描述於 Schedule)，以及應該取得的設備或是資源 (描述於 PRD)，所有的專案成本就攤開得差不多了。再來，如果你是接案方，就看你要賺多少，把你的利潤加上去；如果你是發包者，就可以藉自己預估的成本，來檢視每一家的報價是不是合理划算。
這裡要強調一件事，這裡的預估成本來自於最前面的 Scenario。所以越精準的需求，這裡的預估成本就越精準。反之，如果需求不明確，專案範圍難以界定，最後提出來的報價誤差就越大。
一般接案方，當然會想留比較大的利潤空間，但是也會擔心過高的報價拿不到案子，心裡也是兩難。同樣的情況對發包方也不是好事，因為需求沒有界定清楚，實作上就有不同程度的實作空間，對於實際成果與原先預期結果也會存在比較大程度的落差。
Contract 合約
最後，最重要的工作就是簽訂合約。
我認為簽訂合約最重要的三件事，還是文章一開始所提到的，專案範圍、驗收條件和專案費用。一個好的案子，這三件事一定是清清楚楚，而且是雙方都接受的條件。代表這個案子，不會有太多的意外。其他部份則是專案維護時效、付款條件、所有權歸屬、法律責任歸屬等。最後記得把 PRD 作為附件附在合約上，之後雙方有任何異議，都可用 PRD 的內容來釐清。
結語
專案管理其實跟軟體工程一樣，都要運用大量的邏輯思考，才能將流程的每一個環節拼湊起來。從 Scenario 到 Contract 這段路的重點在於，確保「對的產品，能夠被做對」。
