剛看完“無問西東”，電影裏說人總歸還是要留下些足跡（文字）的，那麼趕緊跑圖書館來留下些文字。
最近去瑞士啓動了一個新的項目，那麼早上做項目，晚上總結留下了一張張思維導圖來記錄當時的感受，
手稿如下，字寫得不好請見諒：）
首先你得知道這個軟件寫出來是做什麼的，因爲不同的應用場景對軟件要求是千差萬別的。
例如，機械控制？那可能需要實時性高；訂票系統？那需要併發性好，還有數據準確性要高；購物系統？簡單，好看，好用，操作不反人類......
所以第一重要的東西就是，Domian Knowledge領域知識。
領域知識
領域知識，怎麼獲得？當然是找三類人（產品經理，領域專家，服務工程師）。
產品經理：是他定義的產品，他當然一般知道用戶的關注點和痛點是什麼，他一般也是在這個行業中摸爬滾打了很多年，你讓他給你講這個行業是個什麼情況，
這個產品大概應該做成什麼樣子，爲什麼要做這個產品，他一般都有自己的一些想法（當然有時候也不是非常全面的）
領域專家：他一般知道客戶生產產品的流程，知道客戶會怎麼使用系統來幫助他們提高產品質量或生產效率，他也知道這個行業的基本技術水平在個什麼高度（現在市面上的軟件能幫客戶產品做什麼方面的管控，如何提高生產效率和產品質量），也知道按照客戶流程這個產品應該怎麼做測試
服務工程師：也就是你這個軟件產品交付給客戶使用之後，他們負責和客戶交互，解決使用和簡單技術問題。所以客戶的一些反饋，客戶如何真正使用軟件，以及客戶心情他們是都知道的。他們是軟件使用的老師傅。
抓住這三類人，你將獲得巨大的領域知識，這樣你提供給客戶的功能不再只是可運行的系統，而是在不斷的給客戶提供價值。
需求文檔
人都是靠需求驅動的，馬斯洛歸納了人類的5大基本需求。軟件當然也不例外，軟件也是靠需求驅動的，粗略的可以分成兩大類--功能性需求和非功能性需求。
所以需求文檔必須包含這兩部分。
功能性需求：主要描述系統的行爲要求。這個一般產品經理都會寫，只是詳略程度各有區別。
非功能性需求：主要描述系統的性能要求。
性能要求一般包括：易用性，效率性，維護性，安全性，可擴展性，等。
性能要求看似不起眼，而且很多情況下產品經理會漏掉定義這些。然後性能要求其實是驅動軟件架構最重要的元素，所以項目開始這些也要定義清楚。
拿到需求之後有以下這些動作是要做的
- 需求的澄清：先閱讀產品經理寫的需求文檔，然後將每條需求大概的用你自己的語言給產品經理講一遍，看看你的理解是否正確，有疑問的話直接問，因爲這些疑問遲早要回答的，越晚回答越對項目造成風險。（在你發問的過程中你會發現其實很多需求產品經理也都沒想透徹，你發問幫助他思考，當然也是幫助自己不要寫無用的代碼）
- 需求排優先級：需求一定是有優先級和版本發佈最小功能集的。如果你不能挖掘出這兩個東西來，你很難做成功這個項目。如果產品經理說說有的需求都重要，請給他100塊錢，然後說：“假設你只有100塊錢來買軟件功能，請將這100塊錢分配到不同的需求上，錢越多表示越重要。”這之後你自然能知道需求的價值和粗略的優先級。需求文檔拿到之後還有一個重要的策略是最小集，你說：“如果我們人手實在有限，只能提供軟件最基礎的功能，請你告訴我軟件上線，哪些功能是必不可少的。”這之後你大概就知道項目的範圍了。這樣一般一個有經驗的項目經理大概就能知道產品按時上市的可行性了。
- 需求文檔經過前兩步，項目目標，可行性和真實需求應該會比以前清楚不少了，那麼後面項目經理一般會讓開發組出一個項目估算。我只能告訴大家這個時候的估算，一般都不是太準的，但是我們可能試着提高估算的準確性。這裏有個技巧就是把需求用User Story（https://www.mountaingoatsoftware.com/agile/user-stories）的方式來描述：As ...(role) I want ...(function)..so that...(purpose) 就是作爲什麼樣的角色我需要什麼樣的功能，這個功能的目的是什麼。可以發現當產品經理提出一個需求的時候你最想問的一般是“你爲什麼要這個功能，這功能誰會用？那他一般怎麼使用？”，當然有時候“你爲什麼要這個功能？”聽起來有點aggressive，但是卻是個好問題：）
- 有了上面的用戶故事，你們團隊就可以開始做估算了。估算一般用計劃撲克會比較好。當軟件有技術難點時一般時間會估得比較不準，所以我建議儘早將系統難點研究一下，之後動手了才能真正知道有多複雜，說不定很簡單呢。人對於自己不瞭解的東西總是有種恐懼感，估算的時候有時會估出一個“天文數字”。估算不是隻做一次，第一次估算只是大概看看人手是否足夠，技術點時候沒太大risk，而不要太在意準確性。估算可以不斷修正的，你瞭解得更多也會估得越準。
- 需求的利益相關者：這一條雖然放在最後，其實最重要：）請確保參與項目的利益相關者都在同一個理解層面上也就是on the same page。所以前期開會要儘量要求所有利益相關者一同開會，對整個項目有個相同的認識，而且對於項目的範圍，目標，時間，質量達成協議，這樣纔好繼續後面的工作。千萬不要孤立或遺漏了重要的利益相關人員，或開很多小範圍的討論會議，這樣很容易浪費時間，達不成共識，項目註定失敗。還有一些重要決定請一定郵件、文檔記錄，簽證畫押~~
需求之後的產出物
- 需求定好了之後一般就可以產出一個基本的系統架構設計了--這個出來之後纔好開始技術研究或相關編碼
- 需求定好了之後一般就可以產出一個Mile Stone和交付計劃了-- 這個出來之後纔好安排相應的測試和其它資源
項目成功最最最最重要的部分，寫在這了
角色定義和授權
- 這個很重要有了角色定義，項目中的角色就有了責任將這個角色扮演好，其它人有問題也可以找到相應的人員，也消除了一部分人不管自己的事情，老去盯着別人
- 授權也很重要，各個角色有什麼權利，管哪些方面定義好了，就不會有模糊領域大家都不管，或者資源不聽使喚
需求文檔 -- 描述了做什麼，什麼不做，做的假設是什麼
用戶故事描述需求--可以捕捉，這個功能是誰要的，爲什麼要這個功能
軟件架構設計--架構設計怎麼來滿足需求中的非功能性需求和功能性需求
估算--用來給項目計劃提供支撐和合理安排資源
項目計劃--給管理層一個時間節點和期望，相應的時間節點做資源安排等
後面找時間寫後面幾篇：
--全新的軟件項目，好的開始決定了成功一半！（架構設計）
--全新的軟件項目，好的開始決定了成功一半！（團隊）
最後給大家show一下我在瑞士買的本子，我喜歡用思維導圖捕捉思想，在瑞士偶遇了這個本子，大小紙張都很合適：）
