需求分析之從編寫到閱讀到討論
1. 落筆/需求理解
1.1 背景
我們在面向用戶需求時（開始編寫/閱讀文檔），首先要做的就是去理解這個需求出現的背景。通常，分析師會在該節闡述用戶業務痛點，以幫助研發人員充分理解我們做這個項目的意義，對這個環節的理解程度，將直接影響項目的成果甚至成敗。
1.2 目標和邊界
然后就是“目標”，這個目標的設計，通常情況下是以項目為計量單位，或是一個項目的某個階段的目標，在快速迭代的敏捷團隊中則是一個里程碑。
我們討論的最終目的，是“達成共識”。而明確的目標，清晰的邊界，是我們要達成的第一個共識，所以，為了解決用戶業務痛點，我們要做這個項目是沒錯，但做到什么程度，達到什么樣的效果，則是根據多方因素（時間，人力，機會成本等）衡量出的結果。比如用戶只想要一個填寫表單存到數據庫，並提供簡單查詢的簡單功能，那么，我們就不能無限發散，將查詢做成全文檢索，或使用其他復雜的設計，都是不可取的。但如果說需求分析師預測到用戶有80%的可能性會有全文檢索的需要（依據用戶習慣，數據體量等因素），那么開發人員在設計實現方案初期，就可以花費少量的時間為全文檢索設計預留接口，當用戶真正需要這個功能的時候，去做這個接口的實現。相反，如果我們沒有預測到用戶可能的需求，開發也沒有根據預測預留設計接口，后期更改的成本往往是巨大的。
我們學習數據庫設計范式、程序設計原則和設計模式的目的，不外於此。
因此，“目標和邊界”這個問題寫清楚或問清楚，是需求理解和討論的基礎，更是在面向用戶需求變更時，項目成本考量的依據。
2. 項目依賴
當下微服務之所以流行，是因其“微”。“微”則意味着快，開發快，上線快，修復也快。 在當今多變的用戶需求環境下，意味着我們能快速啟動一個項目，以盡量小的成本去試錯。這也是防御性編程思想的體現，其核心則是機會成本的計量。同樣做一個項目，花費3周做出一個粗糙的版本給用戶使用並持續迭代3個月和花費3個月之后再給用戶使用，哪個對於用戶價值交付更有意義是顯而易見的。況且等你3個月做出項目來，市場和需求早就變了。
但微服務的微，帶來的代價則是運維成本和隱性開發成本的增加。沒有DevOps，就沒有微服務（這是個先有雞還是先有蛋的問題，不要跟我討論這個）。而隨着微小的服務越來越多，項目間復雜的依賴和關聯關系，則成了開發團隊的噩夢。
因此，團隊各角色成員，均應對平台項目有一個清晰的了解，最起碼應該有一個速查表，哪個項目提供哪個功能，輸出了哪些數據。我當前寫的看的需求文檔，業務流程是從哪開始的，數據是從哪個項目來的，持久化的數據有哪些項目要訂閱，等等這些，都是我們應該重點討論的問題。
當前團隊技術平台建設尚處於開始階段，我們的標准庫等很多基礎設施還在建設中，在開發業務項目的過程中，將服務能力中公用的部分沉淀下來，則是團隊所有角色成員共同的責任。注意我說的是所有角色，不僅僅是開發人員這個角色。
一言以概之：捋順項目間的依賴關系，整理出哪些項目哪些接口和數據被依賴的多，我們就沉淀哪個服務/接口為公用服務/數據。
3. 功能分解
功能分解的支撐思想是“解耦”。解除各模塊，各功能之間的耦合，使各模塊功能之間通過接口或服務進行調用，能提高代碼復用率。
水平層面的功能分解相對簡單，比如發送語音和人臉識別，這在程序員之外的群體中可能是兩個完全不同的功能。但若要從程序設計的角度去分解，則需要一定程度的抽象思維，從垂直的方向上去分解。
同樣是發送語音和人臉識別這個例子，有一定經驗的開發人員，會將其分解為“基礎通信層”和“數據處理層”。基礎通信的方法可能是WebSocket，也可能是Stream或者Http，且因其多樣性，必須要做出抽象接口以提供具體實現的支撐。數據處理層則將人臉數據和語音數據作為輸入數據進行持久化，在程序設計師的眼中，他們只是數據的不同表現形式，並非是兩種完全不同的數據。所以，在這個層面上來說，程序設計師將會做兩個項目，一個是基礎服務，提供通信服務，另一個是業務服務，提供業務接口和數據持久化。而分解出來的這個基礎服務，則會為后續類似的業務需求提供技術支撐，從而在平台的層面上降低研發成本，提高開發效率。
總結一下，發送語音和人臉識別這個例子，在程序設計師的眼里，和在用戶以及需求分析師，UI設計人員的眼中，是兩種完全不同的設計思路和分解方法。在我們說到功能分解的時候，大家要意識到，“功能”這個詞，在不同的人思維里，是不同的東西。
所以，團隊各角色的成員，需要將自己所設想的功能分解說出來，都需要告訴大家，我的分解為什么是這樣的，這樣分解有什么好處，這樣分解如何為用戶服務以及價值。
4. 用戶群體划分
沒有明確的用戶群體的區分，做出來的項目功能面向用戶群體模糊，我們得到的反饋往往就是用戶的一句：不好用。
我們經常會看到有些系統具備管理員角色負責系統的各項配置，普通用戶角色負責數據錄入，而領導層的角色則只是看看報表無法操作數據錄入。
其實在我們編寫/閱讀需求文檔的過程中，也同樣需要搞清楚我寫/讀的這個功能所面向的用戶群體，解決的是該用戶群體的哪個業務痛點。你給A群體用戶展示/操作B群體用戶的業務痛點，顯然A群體用戶根本就不會在乎數據的真實性及時性和准確性。如此這般，最終導致的結果就是用戶反饋差，整個團隊的勞作成果付諸東流。
5. 象限歸類
象限歸類方法是目前各行業各崗位非常流行的工作技巧。在項目實施規划中，可以從：
v 主要功能，必要需求
v 外圍功能，必要需求
v 外圍功能，輔助需求
v 主要功能，輔助需求
四個方面對項目，模塊，功能進行歸類，這樣做的好處是什么呢？
首先想到的就是用戶價值最大化和降低實現風險，同時還能作為我們迭代的依據。更厲害的是，這個簡單的象限圖，還能幫我們抵御各種實現風險。
想想看，眼看項目要延期了，而開發人員早就把核心功能做好了，現階段正在做某個外圍的輔助功能，我們這時候能不能上線？
項目開發依賴，開發風險，服務/模塊/功能依賴，都可以在這個象限圖上表達出來。可以說這個圖畫的越好，你的項目做的就會越成功。
6. 總結
綜上所述，我們編寫/閱讀需求文檔的時候，是需要有一套高效的方法的，不能說這個點直覺上感覺很別扭，我得好好琢磨琢磨再寫再討論，而是先將大綱羅列出來，分門別類划重點（用戶群體，象限歸類），重點解決核心問題。
同樣，我們在一起討論業務、設計或實現的時候，也需要提前有所准備，我要問的問題是什么，歸類到哪個象限，解決的是哪個用戶群體的哪個業務痛點，花費多長時間討論是值得的？
這些都是我們在動筆或討論前需要准備的，所謂謀定而后動。