需求分析之從編寫到閱讀到討論

需求分析之從編寫到閱讀到討論

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. 總結

綜上所述，咱們編寫/閱讀需求文檔的時候，是須要有一套高效的方法的，不能說這個點直覺上感受很彆扭，我得好好琢磨琢磨再寫再討論，而是先將大綱羅列出來，分門別類劃重點（用戶羣體，象限歸類），重點解決核心問題。

一樣，咱們在一塊兒討論業務、設計或實現的時候，也須要提早有所準備，我要問的問題是什麼，歸類到哪一個象限，解決的是哪一個用戶羣體的哪一個業務痛點，花費多長時間討論是值得的？

 

這些都是咱們在動筆或討論前須要準備的，所謂謀定然後動。