提起需求設計，很多人都會感覺到頭疼：很難挖掘使用者真正想要的，使用者需求頻繁變化……但是，需求分析卻是軟體開發過程的第一步，也是最重要的一步，產品半數以上的問題禍根都深埋於產品需求設計階段。
對於從事產品需求設計的人員，普遍的認識是他們對技術的了解不一定深入，但是要有良好的溝通和文件能力。事實上，越來越多高層級的產品需求師們在顛覆這一形象。用友u9研發中心的u9產品總監任曉慧就是其中之一。
2023年4月的一天，初見任曉慧的時候並沒有特別的感覺，她的親切讓接受採訪的她更像是一位有經驗的師傅在向徒弟傳道授業。但是在了解到她從2023年進入用友，在用友工作13年，歷任u8、nc、u9三個產品線的主需求、產品經理、應用架構師和產品總監時，著實讓我吃了一驚。執著的人讓人佩服。
而在u9的需求設計過程中，任曉慧針對u9業務驅動的特點，創造了以特性驅動的需求設計模式，為u9產品的發展和規模化做出獨特的貢獻。
需求設計五階段
u9作為一款大型erp產品，從產品構想到最終上市，整個過程歷時5年，而需求設計階段幾乎佔整個產品誕生所需時間的1/2.在這樣乙個時間跨度如此之大長的需求設計全過程，u9的需求設計人員是分為哪些階段來實現的呢？
在任曉慧看來，u9產品的需求設計階段與其他產品並無太大不同，主要包括以下五個階段，而u9產品需求的獨特之處在於它的特性分析階段。
產品定義：
由產品經理和架構師主導，根據市場分析，特別是產品所定目標群的情況，確定下不同版本所要解決的不同問題，適用於哪些行業。
比如，對於u9來說，其主要面向製造行業，從1.0版本的定位就是如此。2.0版本則更強調對裝備製造業的支援。
特性分析：
一般傳統軟體按照功能模組來設計和開發產品。u9的特點在於業務驅動，比如在銷售部門錄入一張訂單，接下來需要生產怎麼準備，財務怎麼配合，這就是在驅動後端。針對u9這一業務驅動的特性，u9的產品設計增加特性分析環節，每個特色都可以認為是乙個業務流程，比如委託加工，這是乙個業務流程，涉及到企業生產部門、採購部門、財務部門、倉儲部門，它對應到產品功能模組會包括很多，生產、採購、財務等。我們會根據委託加工這一業務流程或者說特性設定負責人，目的是將委託加工特性的場景，以及特性在u9各個模組之間的配合模式都設計出來。
詳細需求：
詳細需求就要面向模組。面對模組針對不同特性，比如訂單如何調整、收貨如何調整。在模組設計中加入對各個特性的描述。
總體設計：
總體設計就是劃分元件以及元件職責、流程和介面等。
詳細設計：
詳細設計則是針對元件的詳細設計。
特性驅動的需求設計模式
特性驅動的需求設計模式是u9產品需求設計中濃墨重彩的一筆。所謂特性驅動，首先要對特性進行分析，這樣，乙個特性能夠真正從頭到尾將其所涉及到的模組完整貫徹下來。然後，乙個特性設定乙個負責人，由特性負責人對特性的場景和實現模式負責。這一方式打破了按模組劃分任務的常規慣例，避免了以前每個人只負責自己的模組，容易導致特性之間的銜接出現問題。包括u9後續的開發和測試，特性驅動都對產品質量和業務流程有了更多保證，對於u9業務驅動的業務模型發展和完善起到很大的作用，對於人員的成長也有很大的好處。
從2023年底開始，一直到去年全年，在u9研發中心全面推行按特性的驅動方式。「整體下來，效果比較好，對於人員成長和業務流程打通都是很有效的。」任曉慧表示。
需求過程三經驗
任曉慧長達13年的需求、產品、架構等職業經驗，在u9產品需求設計中得到了充分發揮和利用，其中又有哪些是可以與大家分享、借鑑的呢？
經驗1:敏捷過程
任曉慧談到，u9產品的發版流程通常是這樣的：比較大的版本，比如1.5版本（1.0和2.0版本間的乙個較大版本），在1.0版本開發沒有完全完成時，需求設計部門就開始先做它的產品定義、需求設計了，而在交給開發去做開發和測試的時候，需求部門又已經投入到下一版本的需求設計中。比如，今年要發布的2.1版本，需求設計已經告一段落，進入後期開發測試階段。接下來，需求團隊將投入今年以及明年版本的需求設計中。這是乙個迭代的過程。
u9研發中心一般在每年的固定時間，比如十月，會將下一年發幾個版，每個版面向的需求定義下來。比如，今年要發版的2.1,在去年就已經有公司專家產品委員會評審並確定。
經驗2:調研經驗
需求人員在工作最容易遇到的難題是如何完整準確地獲取需求。對客戶需求的獲取不完整，或者不準確，都會造成最終產品無法滿足客戶要求。因此，調研工作變得如此重要。在任曉慧看來，調研的關鍵是找到這樣乙個適合的客戶，這個客戶也願意配合你，這是非常重要的。另外，在調研前需要做好充分的準備，因此調研者的經驗也是同樣重要的。一般，我們會到u9客戶比較集中的區域，比如製造業發達的華東、南部地區，這樣能夠收集到區域的特點，也有行業的特點。所以，總的來說，u9需求團隊的調研過程包括調研前準備調查提綱；調研中以交談為主，了解使用者日常工作流程為主；調研後進行分析，形成總結。
經驗3:需求團隊
目前，u9的需求設計團隊有60多人，包括產品經理、需求人員、設計人員。從從事需求工作的第一天開始，任曉慧就認為，在軟體開發企業，需求人員是代表客戶的，需求人員最應該具備的素質是要站在客戶的角度。而她也是這麼去做的：「為夢想而奮鬥，以客戶為核心，做使用者朋友」.只有站在客戶的角度想問題，客戶才會滿意。她把這一點看作是需求人員從本質上要改變的一種觀念。從能力和經驗角度，需求設計工作也需要需求人員有一定的客戶實務經驗，具有一定的抽象和分析能力。
作為使用者的代表，如何使用者需求與開發實踐產生衝突該如何解決呢？任曉慧的經驗是：如果客戶需求和開發時間有衝突，一般有兩種處理方式，一是建議客戶等，等到新產品出來後再用。二是先為客戶單獨解決，滿足客戶上線需要，後再產品標準化。
奇門對接需求設計 奇門中的特性要求
奇門中的特性要求 一 空亡。事物隱藏，潛藏的隱患。測事，正好臨上空亡，隱藏的問題要馬上面對或解決。這是直接影響到了。測的事沒臨上空，但局裡有空亡，空亡也能反映事情存在的問題，但是不是要馬上面對，不一定。可能不足以影響事情的發展。這是間接影響。要看重點落在哪兒。即用神落在哪兒。用神對面宮空亡，也是直接...
讀《領域驅動設計與模式實戰》
有關領域驅動方面的書籍不多，jimmy的 領域驅動設計與模式實戰 便是其中的一本。讀本書前，最好有讀過eric的 領域驅動設計 ddd 與martin fowler的 企業應用架構模式 poeaaa 否則很難看懂。這是一本注重實踐與應用的書籍，作者將多年從事軟體開發的經驗融入書中，結合tdd向讀者展...
書評 領域驅動設計與模式實戰
最經典的書籍不一定最容易懂，正如陽春白雪之於下里巴人。在設計模式的世界中，gof的 設計模式 永遠都是人們推崇的經典，然而真正能夠將開發人員引入設計模式殿堂的，或許還是 深入淺出設計模式 或其他類似書籍 前者是永恆的經典，後者則是入門的經典。學習一門技術，正需要這樣面向不同讀者群的兩種經典。領域驅動...