手機殼干架的軟體工程指南（20180813更新）

• 2019 年 10 月 6 日
• 筆記

最近「產品經理和程式設計師因需求干架」的段子瘋傳IT圈，下面我用軟體工程的觀點來剖析這件事情。

圖1 傳說中的干架劇本

（1）需求不是為了指導設計而做的

這裡的產品經理，我定義為需求人員。程式設計師，我定義為設計人員。關於需求和設計，我在《軟體方法》第1章中專門闡述（http://www.umlchina.com/book/softmeth_01.htm）。其中有一道自測題是這樣的：

★軟體開發中需求工作的目的是____。

 A) 讓系統更加好賣

 B) 更好地指導設計

 C) 對系統做概要的描述

 D) 滿足軟體工程需求規範

如果您選了B，那就掉入陷阱了。需求不是為了指導設計而做的。需求要考慮的是在當前的市場和競爭現狀下，系統至少要達到什麼功能和性能，才能夠被目標客戶所接受。至於本公司設計人員會不會做，怎麼做，或者由其他公司的設計人員來做，或者由貓、狗、外星人來做，是無所謂的。

如果需求人員通過切實的現狀調研和建模（很多產品經理不具備這個能力而瞎指揮，導致了衝突的產生，這是後文會說的問題。），推導出公司推出的新產品應該封裝根據手機殼顏色切換主題的邏輯，只有這樣公司才能在殘酷的競爭中殺出一條血路，那麼真的是再難也得想辦法往這個方向努力。（事實上，在新聞價值的烘托之下，如果有公司現在推出這樣的產品，很可能吸引到很多注意力）

就像人生病了，病情就擺在那裡，該吃什麼葯，動什麼手術才有生機，和病人有沒有錢買葯，附近有沒有醫生有能力手術沒有關係。

不了解「需求不需要考慮設計」，就會出現各種奇葩的需求規約。有的需求規約里寫上了編碼規範，有的需求規約里詳細給出了介面設計圖、資料庫設計圖，甚至有的需求規約連偽程式碼都寫上了，生怕如果不這樣手把手教設計人員，設計人員不會做。

不了解「需求不需要考慮設計」，還會帶來下面這種思維顛倒：先拍腦袋實現，然後再從實現反推其他工作流的內容。例如下面的對話：

A：這個不應該是系統的用例（如果您不理解什麼叫「用例」，就先把它理解為「功能」好了）。

B：是的！我都寫好了，運行一下給你看，這個系統確實提供了這個用例。

是否系統的用例應該以「好賣」來判斷。權衡涉眾利益之後覺得應該有，系統就有，不該有就沒有，而不是我寫好了程式碼，所以就應該有。

還有某些設計人員的「面向對象設計思想」是這樣的：

A：這兩個類關係不應該是泛化，而是關聯。

B：是泛化，不信我打開程式碼給你看，或者逆向工程轉出類圖給你看。

是否泛化關係應該以「符合領域內涵」來判斷，而不是先寫好程式碼「人是豬的一種」（肯定能編譯通過，正常運行），再用寫好的程式碼來證明「人是豬的一種」。

「投幣法」可以幫助需求人員排除設計人員的影響。

（2）需求人員要提升自己的需求技能

需求技能需求人員要認識到：做好需求需要掌握需求技能，以及反過來，掌握需求技能對做好需求是有幫助的。

遺憾的是，許多需求人員之所以在需求崗位上，並不是因為他掌握了該掌握的需求技能，可能只是因為他工作年限足夠長該換到需求崗位了——和許多年齡到了就上崗的夫妻和父母相似。

許多時候，需求人員沒有意識到「做好需求需要掌握需求技能」，把需求工作想得太容易，以為只要願意花時間去做就能做好。經常可以聽到「採集需求」這樣的表述，好像需求是蘑菇，乖乖地躺在森林裡，需要時就可以像采蘑菇的小姑娘一樣，一個，兩個，三個，四個……把它們都採回來。哪有這麼容易！需求不是蘑菇。需求人員要能夠像獵人一樣，用銳利的眼睛發現隱藏在叢林中的獵物；像偵探一樣，用慎密的思維判斷出偽裝成好人的兇手。

有的時候，需求人員沒有意識到「掌握需求技能對做好需求是有幫助的」，把需求工作想得太難，認為沒有辦法把需求做好。由於沒有掌握需求技能，開發團隊往往覺得無從下手，乾脆破罐子破摔，有意無意地壓縮需求工作時間，或者借「敏捷」的名義直接跳過。

高品質的需求需要需求人員灑下汗水，通過高品質的啟發、建模、推導而得到。不過據我的觀察，很多需求人員，特別是互聯網公司的產品經理，只擅長這一招鮮——頭腦風暴得出介面原型。如果僥倖成功（其實很多成功是公司燒錢所致，並非產品有超人之處），就拚命鼓吹「原型大法好」，因為他就會這個。

頭腦風暴是逃避深入第一線辛苦調研、安心閉門造車的借口。介面原型只是需求的一種視圖，而且是和低級別涉眾交流其崗位工作的視圖。對於更高級別的涉眾，需要其他形式的視圖。和整天在電腦前面勞作的小科員通過介面原型交流還可以。 「局長，這些是系統80個功能的介面原型，我一個一個展示給你看」，難道和局長交流也這樣嗎？

我覺得有兩項需求技能最值得花時間掌握：（1）使用業務序列圖描述業務流程（2）尋找用例的涉眾利益。

具體的方法學詳情，可以看我寫的《軟體方法》一書。我在這裡只列舉幾個例子：

圖2 待改進的業務流程-揚招計程車

圖3 改進後的業務流程-網約車（1）

圖4 改進後的業務流程-網約車（2）

未完待續……