需求開發是指通過對使用者需求進行分析，開發產品需求的過程。需求開發在於把面向使用者的需求轉換為面向研發團隊的需求的過程，回答研發團隊「我們要做什麼樣的產品」的問題。需求開發直接面向研發團隊，是使用者需求傳遞到研發團隊中的必要一環。本文主要闡述在專案需求開發過程中涉及的主要規程、可能存在的問題、分析這些問題並提出相應的改進措施。
一．需求開發的規程
在輕量級過程改進系列的上下文中，關於需求管理和需求開發的區別和聯絡已經在「需求管理」這一改進域中有明確說明，這裡不再展開。該上下文可能每個團隊都有不同的理解和詮釋，但需求開發的主要任務就是讓研發團隊獲取產品的需求並根據產品需求進行系統設計和實現，需求開發通常也是一項跨職能團隊的活動，通常包括的規程有：
1. 需求分析
2. 需求評審
二．需求開發中的問題
需求開發在本系列文章中屬於產品管理範疇，主要是以產品經理為代表的產品管理團隊進行工作展開，產品管理難度很大，除了需求開發過程還有產品平台、標準化等多項工作，所以這裡的產品需求開發只從需求分析定義的角度出發進行討論，相對比較簡單，主要涉及的是需求分析的工具和方**，存在的問題可能有：
1. 需求定義的粒度和維度不合理
需求定義普遍存在的乙個問題是需求的粒度和維度問題，也就是我們如何進行需求分解和描述的問題。不合理的需求定義粒度會加大研發工作的管理難度，因為研發範圍的管理通常都會以產品需求的定義粒度為基準，粒度太大不便資訊同步，粒度太小則加大管理成本。從維度上講，乙份對非功能性需求以及其他輔助性需求有明確定義的需求會對研發工作的展開和度量起到促進作用，反之則需要一定的協調工作才能對這些需求進行定義和開發。
2. 需求定義的展現方式太單一
有時候需求定義的表現形式很重要，無論是使用者體驗驅動的網際網路產品還是業務領域驅動的企業級應用，找到合適的需求定義方式並不容易，需要根據具體產品進行靈活把握。但無論何種產品需求定義，採用多樣化的表現形式往往能更好的表達需求本身的含義，確保研發團隊能夠快速直觀的進行需求理解。很多需求難以理解和維護就是因為其表現形式過於單一，不利於團隊充分把握需求的細節。
3. 缺乏統一的需求建模過程
需求分析過程中進行需求建模是必要的，建模的程度可能視系統特點和複雜性而異，但我們都應該採用一種被團隊普遍認可的、統一的建模方式進行需求的梳理。缺少需求建模的結果就是每個需求定義人員都可能有自身的一套規則和方法，可能導致不同的人對同乙份需求有不同的理解和維護方式，在團隊協作環境下就形成一種無形的壁壘從而降低了工作效率。
三．需求開發的過程改進
1. 關注產品需求的分解
需求分解的通用原則無論對使用者需求和產品需求都同樣有用，但通常產品需求的粒度和維度都會比使用者需求更加需要斟酌，因為產品需求是開發人員對產品理解的主要**，直接影響研發團隊的開發計畫和系統設計。關注產品需求分解也是乙個裁剪的過程，需要根據團隊認知的現狀以及產品開發的特點達到一種平衡。
2. 關注建模工具的使用
本質上需求分析可以理解為乙個系統建模的過程，系統建模也是乙個很大的領域，無論是結構化分析方法還是物件導向的建模手段都能夠為我們提供乙個系統模型。在需求開發的改進過程中，使用統一的系統建模工具能夠確保產品需求符合目前業界主流的分析和定義風格，確保團隊成員尤其是研發人員對產品需求得到充分認識，消除不必要的歧義和誤解。
3. 關注需求的表現形式
不同團隊可以使用不同的需求表現形式，但需確保團隊理解和認同這種表現形式。上文提到的需求定義展現方式單一的問題是改進過程中的乙個關注點。另一方面，表現形式務必做到統一。
針對上述切入點，我們梳理需求管理過程改進的模式和實踐包括：
1. 確立配置管理理念和流程
需求管理中提到的對需求的配置管理理念和流程同樣適用於需求開發過程，這裡不再展開。
2. 靈活應用各種「**」
產品經理手中應有一些產品需求開發的**，這些**從不同的方面對產品需求進行展現，這裡列舉幾項個人認為比較重要又容易把握的**：
3. 開展系統建模工作
系統建模的方**有很多，如結構化分析、物件導向、領域驅動等，作為這些方**的支援性工具，uml是目前主流的系統建模工具。uml既可以作為需求分析建模，也可以進行系統設計建模，這裡舉uml順序圖作為需求分析建模的乙個例子，如下圖：
四．需求開發的過程資產
1. 產品需求說明書
產品需求說明書主要包括以下要點：
五． 小結
需求開發屬於產品管理類改進域，相比需求管理更加偏向於團隊內部的規範。需求開發通常會與產品平台和標準化建設緊密結合，改進過程中也主要關注產品需求的定義和表現形式。但產品管理遠不止需求開發，關於產品的定位分析、產品功能的優先順序等決策等我們將在後續產品管理類改進域中進行詳細闡述。
我出版了《系統架構設計：程式設計師向架構師轉型之路》、《向技術管理者轉型：軟體開發人員跨越行業、技術、管理的轉型思維與實踐》、《微服務設計原理與架構》、《微服務架構實戰》等書籍，並翻譯有《深入rabbitmq》和《spring5響應式程式設計實戰》，歡迎交流。
輕量級過程改進之綜述
輕量級過程改進 light weight process improvement，lpi 是一種針對中小型團隊軟體研發過程中普遍存在的重技術輕管理 研發管理缺乏規範 過程改進理念淡薄等現狀和問題而整理的一種 軟體過程改進方法和規範 有眾多輕量級過程改進域組成，主要對中小型團隊持續地改進其軟體過程能力...
輕量級過程改進之綜述
輕量級過程改進 light weight process improvement，lpi 是一種針對中小型團隊軟體研發過程中普遍存在的重技術輕管理 研發管理缺乏規範 過程改進理念淡薄等現狀和問題而整理的一種 軟體過程改進方法和規範 有眾多輕量級過程改進域組成，主要對中小型團隊持續地改進其軟體過程能力...
輕量級過程改進之績效管理
績效管理是對團隊成員進行工作評估和激勵的過程，雖然很多時候會由人事部門進行員工的績效管理，但對研發團隊而言，技術人員的績效管理很難把控，所以很多團隊往往對績效管理避而遠之，採用管理層主觀判斷的方法進行績效把控 有些團隊雖然會做一些績效管理，但只是關注於績效考核，而忽略績效背後的工作計畫 評估 激勵以...