從主教花園望見的索爾茲伯里大教堂

上圖是一副非常有名的畫作，名為『從主教花園望見的索爾茲伯里大教堂』，作者康斯太勃爾，英國的著名油畫家。某年某月的某一天，康斯太勃爾去他的金主大教堂的主教Fisher先生(后面簡稱大魚)家里玩。大魚主教跟畫家先生說：“親愛的畫家，你幫我畫一幅畫吧。把我和我美麗的妻子以及我這大教堂一起畫到畫里。我要把畫留在教堂，成為鎮堂之寶。當然，我是給錢的，于是康斯太勃爾先生很高興的接下這個項目。

畫家開始了辛苦的工作，經過一段時間終于把這幅畫完成了。畫家畫這幅畫時可能心情不好，所以在教堂塔尖上方的天空有一片烏云。大魚主教看到這幅畫后，很不滿意。雖然畫家把主教大人、主教夫人和教堂都畫進去了，但是兩口子只在左下角露了個背影，這也就忍了。“下面那幾頭牛是怎么回事，為什么比我們占的鏡頭還多?”主教問。畫家說：“你沒看懂?我是在恭維您呢，是說您和您夫人好牛!”，大魚先生沒什么話說了，然后又找到了新的吐槽點：“為什么天空的云都是烏云?”。他邀請畫家再去他家做客，重新觀察，以便于修改畫作。畫家很不高興了，就單獨把畫展出了。展出之后得到很多好評，于是回信給大魚主教：“你看，大家都說很好看，不用改了。”，大魚主教收到信后也怒了，回信就說了一句話：“給我改!!!”。

從回復文字的三個嘆號上可以看出——主教很生氣、后果很嚴重。這就是關于需求的故事，請您再看上圖，看看教主和教主夫人被畫到了哪里?您能找到嗎?

從上面案例中您看到了哪些與需求相關的問題?為什么導致客戶不滿意并被要求重畫?

1、需求表達不到位。大魚教主想要一幅畫，畫里有他們夫妻二人和教堂，需求表達完后，并沒有再對需求進行更具體的說明。除了以上要求外，畫作里是否還可以加些其它元素?人物要求畫正面還是背面?畫作的背景是什么?需要表達什么樣的情感?

2、沒有與客戶認真溝通需求。當主教讓畫家畫一幅畫時，最初只是一個想法，并沒有太具體的要求。細節需要畫家一點點的引導，從而勾勒出畫作的輪廓，這個輪廓就相當于產品的原型。與客戶溝通好需求并得到客戶認可后再開始畫作，需求變更的可能性就會大大的降低。

3、需求理解不正確。畫家在畫作里多畫了一些牛，并認為這樣會更好，寓意深刻，可以表達出大魚主教和夫人“很牛”的意思，還根據自己情緒需要將天空畫得“烏云密布”。這說明畫家沒有正確理解客戶意圖，把需求想當然化了。我們應該合理控制需求，合理規劃需求，不能隨意的增加或刪減需求，這都是不正確的。需求的管理也不應該是一人堂，要有需求評審等需求審核流程，讓相關人一同參與、共同把握需求。

4、沒及時讓客戶參與。在畫家進行創作的這段時間里，畫家并沒有邀請大魚教主來看畫作，這也就錯過了最后彌補的機會。當整個作品完成后，客戶才有機會看到作品，得不到客戶認可的產品再努力也是徒勞。

5、不愿聽取意見。當客戶明確提出自己的意見后，畫家還是一意孤行，將作品拿出來展覽，這對客戶來說是種傷害。即表現出對客戶的不尊重，又表現出了自己的自大。這就相當于還沒得到客戶、相關領導認可時，私自發布產品，它所產生的后果可能是無法想像的。所以，難怪主教生氣。

從上面故事可以看出，項目的成敗與需求關聯非常密切。如果想要做好一款產品，從需求調研、需求分析、文檔梳理、需求評審每一步都要走的堅實，不可以走過場。一點的疏忽都可能導致產品的失敗，需求變更，也就再所難免。有的需求變更是無法避免的，如客戶、領導在產品開發階段要求增減需求;有的需求變更是可以避免的，如需求調研的不夠充分、分析的不到位、評審的不夠嚴格。只要我們更虛心一點、更認真一點，需求管理流程更規范一點，許多變更都是可以避免的。

針對需求變更要早發現、早預防

需求變更避免不了，既然不能避免，那我們就要敢于直面慘淡的人生。引入需求變更管理機制,以降低需求變更帶來的風險。需求變更管理的核心是減少變更所產生的影響，而非消滅變更。通過變更管理可以降低開發返工、重工的工作量，以減少項目風險。需求變更屬于需求管理范圍，同時也屬于風險控制范圍，對于產品經理要隨時關注產品，定期對需求進行跟蹤，做到“早發現、早治療”，以防病入膏肓后才下手。那樣，可能癌細胞已經擴散了。對已變更的需求要做到文檔標記更新，編寫需求變更說明，保證需求與開發工作一致，不要出現“兩層皮”的現象。從技術角度考慮，技術架構要做到可擴展，以彈性的架構來解決變更的需求，把變更造成的影響降到最低。

需求變更流程

當發生變更時，正規的流程需要走變更申請，申請后組織人員對變更進行分析、評審，以判斷變更是否必要，對項目的影響有多大。又必要又緊急的需求要排到開發計劃中，盡快安排開發;對必要不緊急的需求要考慮是否可以放到下一版本安排開發;對緊急不必要的需求，要根據項目實際情況考慮，是否可以不要?對不緊急也不必要的需求應該直接砍掉，無須變更。評審完成后，對于需要安排開發的變更需求，先整理變更需求說明書，以幫助開發人員、測試人員了解變更內容，指導技術人員開發。

如何分析需求變更的合理性?從哪些方面著手?

1、從業務方面分析。需求變更基本都是因業務變化而產生的，當發生變更時，我們也要從業務角度多思考，變更的是否合理，是否必要，與產品定位是否相符，能給產品帶來哪些好處?如果不做變更是否可以?

2、從技術方面分析。變更會對開發有多大影響，需求變更的部分是否已經開發?開發到什么程度?工作量多少?是否可以通過技術框架的擴容性很好的解決變更?

3、從項目方面分析。從項目角度考慮，變更會使項目的時間、資源、費用上產生多大影響?影響是否能夠承受?本次變更的需求必須本版本開發完，還是可以放到下一版本迭代開發?

從以上三方面分析清楚后，變更的需求脈絡也就理清了，變與不變、現在變還是以后變也能分析得透徹。

總結：

需求變更對每一位產品人來說都會經常遇到，產生變更的原因很多，有外在的、有內在的，但不論是因為什么產生的變更，遇到了就要正確的、合理的分析、評估，給項目以正確的指導。如果項目前期進行了大量的調研、跟蹤、分析、評審，并請客戶盡早參與，許多變更是可以避免的。如果，技術框架設計的可擴展，程序設計的可擴容的話，當發生變更時也可以把變更對項目產生的影響控制到最小。防微杜漸、未雨綢繆，還是那句話：“早發現、早治療”。最后，以“扁鵲見蔡桓公”的故事結尾。

扁鵲進見蔡桓公，(在蔡桓公面前)站了一會兒，扁鵲說：“您在肌膚紋理間有些小病，不醫治恐怕會加重。”蔡桓公說：“我沒有病。”扁鵲離開后，蔡桓公說：“醫生喜歡 / 習慣給沒病的人治病來當作自己醫術的功效。” 過了十天，扁鵲再次進見蔡桓公，說：“您的病在肌肉里，不及時醫治將會更加嚴重。”蔡桓公不理睬。扁鵲離開后，蔡桓公又不高興。

過了十天，扁鵲再一次進見蔡桓公，說：“您的病在腸胃里了，不及時治療將要更加嚴重。”蔡桓公又沒有理睬。扁鵲離開后，蔡桓公又不高興。

過了十天，扁鵲(遠遠地)看見桓侯，掉頭就跑。蔡桓公于是/特意派人問他。扁鵲說：“小病在皮膚紋理(之間)，湯熨(的力量)所能達到的;病在肌肉和皮膚里面，用針灸可以治好;病在腸胃里，用火劑湯可以治好;病在骨髓里，那是司命神管轄的事情了，(醫生)是沒有辦法(醫治)的。現在(病)在骨髓(里面)，我因此不再請求(為他治病)了。”

過了五天，蔡桓公身體疼痛，派人尋找扁鵲，(扁鵲)已經逃到秦國了。蔡桓公于是病死了。

#文章作者#

產品人老吳，微信公眾號：ChanPinLaoWu，產品壹佰專欄作家，北京金馬甲產權網絡公司產品總監，產品講學堂自媒體人。十多年軟件行業從業經驗，做過軟件開發、項目管理、產品經理，希望能夠與大家分享更多產品經驗和知識，歡迎關注更多老吳產品講學堂的產品觀點。