本文作者：老吳 原文地址：猛戳這裏
從主教花園望見的索爾茲伯裏大教堂
上圖是一副非常有名的畫作，名爲『從主教花園望見的索爾茲伯裏大教堂』，作者康斯太勃爾，英國的著名油畫家。某年某月的某一天，康斯太勃爾去他的金主大教堂的主教Fisher先生（後面簡稱大魚）家裏玩。大魚主教跟畫家先生說：“親愛的畫家，你幫我畫一幅畫吧。把我和我美麗的妻子以及我這大教堂一起畫到畫裏。我要把畫留在教堂，成爲鎮堂之寶。當然，我是給錢的，於是康斯太勃爾先生很高興的接下這個項目。
畫家開始了辛苦的工作，經過一段時間終於把這幅畫完成了。畫家畫這幅畫時可能心情不好，所以在教堂塔尖上方的天空有一片烏雲。大魚主教看到這幅畫後，很不滿意。雖然畫家把主教大人、主教夫人和教堂都畫進去了，但是兩口子只在左下角露了個背影，這也就忍了。“下面那幾頭牛是怎麼回事，爲什麼比我們佔的鏡頭還多？”主教問。畫家說：“你沒看懂？我是在恭維您呢，是說您和您夫人好牛！”，大魚先生沒什麼話說了，然後又找到了新的吐槽點：“爲什麼天空的雲都是烏雲？”。他邀請畫家再去他家做客，重新觀察，以便於修改畫作。畫家很不高興了，就單獨把畫展出了。展出之後得到很多好評，於是回信給大魚主教：“你看，大家都說很好看，不用改了。”，大魚主教收到信後也怒了，回信就說了一句話：“給我改！！！”。
從回覆文字的三個歎號上可以看出——主教很生氣、後果很嚴重。這就是關於需求的故事，請您再看上圖，看看教主和教主夫人被畫到了哪裏？您能找到嗎？
從上面案例中您看到了哪些與需求相關的問題？爲什麼導致客戶不滿意並被要求重畫？
1、需求表達不到位。大魚教主想要一幅畫，畫裏有他們夫妻二人和教堂，需求表達完後，並沒有再對需求進行更具體的說明。除了以上要求外，畫作裏是否還可以加些其它元素？人物要求畫正面還是背面？畫作的背景是什麼？需要表達什麼樣的情感？
2、沒有與客戶認真溝通需求。當主教讓畫家畫一幅畫時，最初只是一個想法，並沒有太具體的要求。細節需要畫家一點點的引導，從而勾勒出畫作的輪廓，這個輪廓就相當於產品的原型。與客戶溝通好需求並得到客戶認可後再開始畫作，需求變更的可能性就會大大的降低。
3、需求理解不正確。畫家在畫作裏多畫了一些牛，並認爲這樣會更好，寓意深刻，可以表達出大魚主教和夫人“很牛”的意思，還根據自己情緒需要將天空畫得“烏雲密佈”。這說明畫家沒有正確理解客戶意圖，把需求想當然化了。我們應該合理控制需求，合理規劃需求，不能隨意的增加或刪減需求，這都是不正確的。需求的管理也不應該是一人堂，要有需求評審等需求審覈流程，讓相關人一同參與、共同把握需求。
4、沒及時讓客戶參與。在畫家進行創作的這段時間裏，畫家並沒有邀請大魚教主來看畫作，這也就錯過了最後彌補的機會。當整個作品完成後，客戶纔有機會看到作品，得不到客戶認可的產品再努力也是徒勞。
5、不願聽取意見。當客戶明確提出自己的意見後，畫家還是一意孤行，將作品拿出來展覽，這對客戶來說是種傷害。即表現出對客戶的不尊重，又表現出了自己的自大。這就相當於還沒得到客戶、相關領導認可時，私自發布產品，它所產生的後果可能是無法想像的。所以，難怪主教生氣。
從上面故事可以看出，項目的成敗與需求關聯非常密切。如果想要做好一款產品，從需求調研、需求分析、文檔梳理、需求評審每一步都要走的堅實，不可以走過場。一點的疏忽都可能導致產品的失敗，需求變更，也就再所難免。有的需求變更是無法避免的，如客戶、領導在產品開發階段要求增減需求；有的需求變更是可以避免的，如需求調研的不夠充分、分析的不到位、評審的不夠嚴格。只要我們更虛心一點、更認真一點，需求管理流程更規範一點，許多變更都是可以避免的。
針對需求變更要早發現、早預防
需求變更避免不了，既然不能避免，那我們就要敢於直面慘淡的人生。引入需求變更管理機制,以降低需求變更帶來的風險。需求變更管理的核心是減少變更所產生的影響，而非消滅變更。通過變更管理可以降低開發返工、重工的工作量，以減少項目風險。需求變更屬於需求管理範圍，同時也屬於風險控制範圍，對於產品經理要隨時關注產品，定期對需求進行跟蹤，做到“早發現、早治療”，以防病入膏肓後才下手。那樣，可能癌細胞已經擴散了。對已變更的需求要做到文檔標記更新，編寫需求變更說明，保證需求與開發工作一致，不要出現“兩層皮”的現象。從技術角度考慮，技術架構要做到可擴展，以彈性的架構來解決變更的需求，把變更造成的影響降到最低。
需求變更流程
當發生變更時，正規的流程需要走變更申請，申請後組織人員對變更進行分析、評審，以判斷變更是否必要，對項目的影響有多大。又必要又緊急的需求要排到開發計劃中，儘快安排開發；對必要不緊急的需求要考慮是否可以放到下一版本安排開發；對緊急不必要的需求，要根據項目實際情況考慮，是否可以不要？對不緊急也不必要的需求應該直接砍掉，無須變更。評審完成後，對於需要安排開發的變更需求，先整理變更需求說明書，以幫助開發人員、測試人員瞭解變更內容，指導技術人員開發。
如何分析需求變更的合理性？從哪些方面着手？
1、從業務方面分析。需求變更基本都是因業務變化而產生的，當發生變更時，我們也要從業務角度多思考，變更的是否合理，是否必要，與產品定位是否相符，能給產品帶來哪些好處？如果不做變更是否可以？
2、從技術方面分析。變更會對開發有多大影響，需求變更的部分是否已經開發？開發到什麼程度？工作量多少？是否可以通過技術框架的擴容性很好的解決變更？
3、從項目方面分析。從項目角度考慮，變更會使項目的時間、資源、費用上產生多大影響？影響是否能夠承受？本次變更的需求必須本版本開發完，還是可以放到下一版本迭代開發？
從以上三方面分析清楚後，變更的需求脈絡也就理清了，變與不變、現在變還是以後變也能分析得透徹。
總結：
需求變更對每一位產品人來說都會經常遇到，產生變更的原因很多，有外在的、有內在的，但不論是因爲什麼產生的變更，遇到了就要正確的、合理的分析、評估，給項目以正確的指導。如果項目前期進行了大量的調研、跟蹤、分析、評審，並請客戶儘早參與，許多變更是可以避免的。如果，技術框架設計的可擴展，程序設計的可擴容的話，當發生變更時也可以把變更對項目產生的影響控制到最小。防微杜漸、未雨綢繆，還是那句話：“早發現、早治療”。最後，以“扁鵲見蔡桓公”的故事結尾。
扁鵲進見蔡桓公，（在蔡桓公面前）站了一會兒，扁鵲說：“您在肌膚紋理間有些小病，不醫治恐怕會加重。”蔡桓公說：“我沒有病。”扁鵲離開後，蔡桓公說：“醫生喜歡 / 習慣給沒病的人治病來當作自己醫術的功效。” 過了十天，扁鵲再次進見蔡桓公，說：“您的病在肌肉裏，不及時醫治將會更加嚴重。”蔡桓公不理睬。扁鵲離開後，蔡桓公又不高興。
過了十天，扁鵲再一次進見蔡桓公，說：“您的病在腸胃裏了，不及時治療將要更加嚴重。”蔡桓公又沒有理睬。扁鵲離開後，蔡桓公又不高興。
過了十天，扁鵲（遠遠地）看見桓侯，掉頭就跑。蔡桓公於是/特意派人問他。扁鵲說：“小病在皮膚紋理（之間），湯熨（的力量）所能達到的；病在肌肉和皮膚裏面，用鍼灸可以治好；病在腸胃裏，用火劑湯可以治好；病在骨髓裏，那是司命神管轄的事情了，（醫生）是沒有辦法（醫治）的。現在（病）在骨髓（裏面），我因此不再請求（爲他治病）了。”
過了五天，蔡桓公身體疼痛，派人尋找扁鵲，（扁鵲）已經逃到秦國了。蔡桓公於是病死了。
文章作者
產品人老吳，微信公衆號：ChanPinLaoWu，產品壹佰專欄作家，北京金馬甲產權網絡公司產品總監，產品講學堂自媒體人。十多年軟件行業從業經驗，做過軟件開發、項目管理、產品經理，希望能夠與大家分享更多產品經驗和知識，歡迎關注更多老吳產品講學堂的產品觀點。
