這是之前今年5月份的一個新聞，軟件公司老闆被員工用顯示器砸臉。看這受傷的程度，一定不是丢過去，隻砸一下。一定是：

為什麼工程師對修改需求的人如此深惡痛絕呢？随意變更需求、随意增加需求，也是對工程師早期勞動的極大的不尊重。造成公司資源的極大浪費。

因為需求的更改，是對工程師與之相關的前期工作的否定。

好的産品隻會修改細節，不會亂改主體結構，不改需求是産品經理不稱職，但動不動改主體就是對産品不負責。

工程師也很郁悶，當初需求沒有描述清楚，做出來之後才說，不斷的增加新需求，導緻不斷的修修補補。很多時候老闆提出的需求也是一時興起，第二天起床可能又覺得頭一天說的那個需求不合理了。

工程師想表達的是：我本善良，往往是被逼得出手的。

那麼如何才能這種暴力事件減少呢？

措施1、找一個超強的架構師，或者産品經理，設計出來的完美，考慮完美的需求。這個措施，我随便說說，你不要當真。

措施2、建立一個好的機制，對需求進行評估，避免返工，避免頻繁的需求更改，避免随意的需求更改。

這個體制的建設，其實就是一種項目的“範圍管理”。

那麼我們看看華為是怎樣在這個領域進行範圍管理的。

範圍管理的定義

範圍管理是指收集和定義項目的需求，标識項目的交付和驗收标準；通過變更控制和驗收活動，确保交付滿足項目要求。

簡單地說就是：範圍是需求的集合。

範圍管理與需求管理的區别：

範圍管理包含：分析範圍，定義和明确範圍、控制範圍、控制範圍變更、驗收範圍。

範圍管理包含一系列的過程，用以确保項目包含且隻包含達到項目成功所必須完成的工作，範圍管理主要關注項目内容的定義和控制，即包括什麼，不包括什麼。而需求管理是确保各方對需求的一緻理解，管理和控制需求的變更，以及需求的跟蹤。所以需求開發和管理的目的是通過調查與分析，獲取用戶需求并定義産品需求，還要确保各方對需求的一緻理解，管理和控制需求變更，需求的雙向跟蹤而範圍管理的目的是确保項目包含且僅僅隻包含項目所必須完成的工作。需求管理是對已批準的項目需求進行全生命周期的管理，過程包括需求管理定義、需求管理流程、制訂需求管理計劃、管理需求和實施建議等，其主要的工作就是需求的變更管理範圍管理過程包括範圍計劃編制、範圍定義、創建工作分解結構、範圍确認和範圍控制。他們之間的首先通過需求開發來獲取項目的需求，再此基礎上确定項目的範圍、進行項目範圍管理其次需求的變更會引起項目範圍的變更

需求的收集與接受

首先，在需求收集和接受過程中，需要仔細思考，深入讨論。在華為這樣的企業可能從上層會有一些戰略部署，和規劃。一些初創公司可能需要全民皆兵的去思考需求，思考項目的範圍。

先說，華為的情況：

1、需求獲取：

2、需求分解：項目的目标和成果，在早期會被分解成為可管理、可交付的組成部分。同時明确項目成功交付的标準，例如：需要滿足什麼功能，什麼性能、什麼準确度。除了從客戶層面去考慮問題之外，還需要考慮自身條件:成本、性能、技術限制、配套、節能減排、可靠性、準入限制、可安裝性、可維護性、易用性、可制造性、可測試性、歸一化、可行銷性、安全性、全球化、可采購性等等維度需要考量。

3、需求分析：

對所有需求進行分析，并把啊分析結果文檔化，可以是《包需求列表》。所有需求都應該用恰當的語言進行描述。對每個需求的驗證方法也需要定義清楚，并且與客戶讨論确定下來，這是客戶驗收标準的輸入之一，是成功移交項目成果和客戶客戶滿意的必要條件。

需求分析需要采用 5W2H方法（What，Why，Who，Where，When，How，How much）

4、需求優先級排序

考慮幾個因素：投資回報率、需求來源及客戶優先級、對客戶滿意度的影響、對競争力的影響、實現難度、成本等。

當然，自然有人是把Boss或者領導的指令當做優先級第一的需求，這就是任老闆說的：“臉朝着領導，屁股就會朝着客戶；臉朝着客戶，屁股就有可能對着領導”

對于初創公司，在範圍分析環節，建議：

a、關鍵需求文檔化，便于跟蹤，設計不能太随意；可能不可能像華為那麼完備的範圍分析，但是關鍵需求需要文檔化。

b、搞清楚，自己的目标客戶到底是誰，不要搞大而全的産品，需求不要貪多、貪全，要一招制敵；專注、極緻、快！

c、小步快跑，階段功能測試，階段需求确認，快速叠代，避免需求理解錯誤，導緻大量返工。别指望憋大招。

d、需求務必讨論清楚，再動手，不要渾渾噩噩開發。

落實需求

估計有些工程師，在施工的時候，會發現：一開始讨論需求時，熱火朝天。但是，做出來的東西，跟一開始的設想完全兩樣。

這裡裡面缺少的環節就是，如何去分解需求，落實需求。

WBS是一個把交付成果層次分解的工具。

WBS：工作分解結構（Work Breakdown Structure） 創建WBS：創建WBS是把項目可交付成果和項目工作分解成較小的，更易于管理的組成部分的過程。

WBS是項目管理重要的專業術語之一。WBS的基本定義 ：以可交付成果為導向對項目要素進行的分組，它歸納和定義了項目的整個工作範圍每下降一層代表對項目工作的更詳細定義。無論在項目管理實踐中，還是在PMP，IPMP考試中，工作分解結構（WBS）都是最重要的内容之一。WBS總是處于計劃過程的中心，也是制定進度計劃、資源需求、成本預算、風險管理計劃和采購計劃等的重要基礎。WBS同時也是控制項目變更的重要基礎。項目範圍是由WBS定義的，所以WBS也是一個項目的綜合工具。

WBS可以是樹形圖，也可以是表格，也可以是甘特圖

範圍蔓延

指項目在進行期間需求緩慢增加，超出原先的範圍框架，造成質量，成本，進度等的失控。例如，未對時間和成本影響進行評估，增加額外的功能和服務。

項目要嚴格控制範圍變更，評估範圍變更對進度、成本、質量的影響，防止項目失控。

在目前，快速叠代的時代，如何能夠控制項目的蔓延，就是一個非常重要的課題。

其實仔細分析過上圖中小米的開發節奏，需要做到一周一版本的水平，其實是有一定難度的。這裡面需要對需求準确的把握，需要對任務的分配做準确的把握，同時，在做的過程中應該是嚴格杜絕範圍蔓延。一周的項目計劃就是一周的項目計劃。當然，這個過程中，需要工程師持續的高強度的努力和責任心。

範圍其實跟計劃一樣，都是在項目的進展過程中，漸進明細的，随着項目進展，項目信息越來越精确。由于認知能力的局限，項目範圍在開始的時候有可能不清晰，需要不斷的細化和完善。在很多項目中，客戶或者項目幹系人在項目初期往往隻能提出大概要什麼，但無法很具體、怎麼做，那些需求的優先級和工作量也都無法評估。

不管是開發者，還是管理者，都應該有清醒的頭腦。提醒自己，不要範圍蔓延。

特别是初創團隊，可以做的事情很多，可以讨論和發展的方向也很多，是不是能像餘承東、任正非說的那樣呢？

“腳踏實地，做挑戰自我的長跑者”

“我們一再強調終端要有戰略耐性，要耐得住寂寞。”

“如果你們匆匆忙忙發展，可能因為一個零件問題，這批手機幾十萬部、幾百萬部出問題，就會毀了整個終端公司，有時很難再爬起來。所以我們還是要踏踏實實，控制欲望、控制合理發展速度，“雞血”沸騰一定是犯錯誤的前兆。”

應對老闆需求蔓延的辦法：

1、對于你自己産品的需求一定要很清楚，要做到比老闆更專業，要有權威性，這樣在進行需求讨論的時候他才會聽取你的意見，需求才會讓你主導。如果需求是你主導的，那麼很多問題就很好解決了。

2、在老闆提出需求之後，要認真的分析這個需求的可行性，如果明顯是跟産品的大方向相反或者其他顯而易見的不合理，那麼就直接的回絕老闆，但是回絕老闆要講究技巧，不要直接說什麼“你想的不對”，要有理有據有分析。3、對于某些需求你覺得合理，但是做起來很費勁的，你可以跟老闆溝通實現這個需求的成本。畢竟老闆的目的就是為了要賺錢呢，你要把時間、成本和質量三方面跟老闆講清楚，如果老闆覺得時間長，成本高都無所謂，那麼對工程師來說也需就沒那麼的反感了，因為時間沒有要求那麼的緊張，程序員壓力也不至于那麼的大。

所以你需要跟老闆說故事：

瓦薩王朝統治時期，瑞典是歐洲的強國之一。為了與勁敵丹麥、波蘭對抗，稱霸波羅的海，瑞典國王古斯塔夫·阿道夫斯二世要求建造一批新的戰艦，并要求戰艦航速要快、火力要強、裝飾要華麗，因為這樣才足以顯示瓦薩王朝的權力、财富和戰鬥力。1626年初，作為其中最大的戰艦“瓦薩”号在國王的親自監督下正式開始建造。

國王總是有太多要求。在“瓦薩”号建造期間，他不斷下令依照他的旨意改變設計和建造要求。在“瓦薩”号的骨架已經安裝好的時候，他下令增加戰艦的長度。1627年,國王得知了丹麥建成雙層炮艦的消息，于是他又決定，為原計劃修建單層炮艦的“瓦薩”号增加一個槍械甲闆，把它改建成“雙層”炮艦。這樣一來，“瓦薩”号便擁有了雙排共64門艦炮，全長達到了69米，成了當時裝備最齊全、武裝程度最高的戰船。

1628年8月10日，離岸還沒來得及揚帆遠航的“瓦薩”号在一陣大風浪過後，開始傾斜，接着又慢慢恢複平衡，但随即再一次朝右舷傾斜。岸上的人們都驚得目瞪口呆。“瓦薩”号的下層甲闆在慢慢進水，艦體開始晃動下沉。“瓦薩”号就在衆目睽睽之下沉沒了。

範圍控制

控制範圍，不是不讓改需求，不是用顯示器砸老闆，而是保證範圍的正确變更。對于可能的、合理的範圍變更，應積極主動的分析是否存在價值，盡可能的創造條件讓高價值的需求變更落地。

在範圍變更分析的時候，需要重點考慮對項目價值、項目策略、項目質量、項目周期、産品目标成本等的影響。變更之時，還需要考慮：項目中需求的冗餘、錯誤之處，新技術引入帶來的風險，導緻的連鎖需求變更。

CCB(Change Control Board) 在CMMI(Capability Maturity Model Integration)中，是“變更控制委員會”的含義，同時具有配置控制委員會（Configuration Control Board）的含義。

當組建包含軟硬件兩方面項目的CCB時，還應當包含來自硬件工程、系統工程、制造部門或者硬件質量保證和配置管理的代表。

CCB是系統集成項目的所有者權益代表，負載裁定接受那些變更。CCB由項目所涉及的多方成員共同組成，通常包括用戶和實施方的決策人員。CCB是決策機構，不是作業機構，通常CCB的工作是通過評審手段來決定項目是否能變更，但不提出變更方案。

對于初創團隊，需求變更也應該是：有制度、有記錄、有讨論、有跟蹤；而不是随意變更。否則船還沒出海就沉了。

範圍驗收

在項目的結束，或者中間節點，可以檢查項目已經完成部分的交付成果的過程。可以按照需求跟蹤表，或者需求跟蹤矩陣一一核對。

方法：可以是評審、内部測試、客戶測試、試驗驗證、準入測試、認證測試等活動的集合。

總是是要看看我們做出來的東西是不是客戶要的。

最後，祝願大家找到好老闆。

提醒一句，工程師如果會空手道、跆拳道、截拳道、中國功夫，已經成為就業的劣勢條件了，找工作時，注意隐藏這些經曆或技能。