- 深入核心的敏捷開發(fā):ThoughtWorks五大關(guān)鍵實踐
- 肖然 張凱峰
- 3351字
- 2019-12-20 20:32:54
需求風(fēng)險的壞味道和對策
大部分項目上,我所承擔(dān)的角色是幫助客戶尋找到產(chǎn)品戰(zhàn)略,并著手落地開始項目實施,在這個過程中,我需要強制自己迅速從發(fā)散思維中回到收斂思維、從機會導(dǎo)向回到風(fēng)險導(dǎo)向,因為大部分的IT項目都可能失敗,成功對于IT項目而言很可能是“不失敗”。
這說起來似乎有些“缺少志向”,但是在現(xiàn)實中IT項目所面對的,除了軟件工程本身的巨大挑戰(zhàn)、還有技術(shù)之外的需求、設(shè)計、溝通、政治、分工、計劃等諸多變數(shù),作為一個大型項目的負責(zé)人,一旦進入交付落地階段,就應(yīng)該進入“風(fēng)險模式”。
而“控制需求”成為了“控制風(fēng)險”中最重要的一環(huán),換言之,對于一個失敗的項目而言,需求未得到有效的控制,往往是最重要的原因。本文將討論多年來我在需求控制方面的一些心得。
識別壞味道
要明白軟件工程是一件專業(yè)性很強的事情,你必須教育客戶,讓他明白如何管理一個軟件項目的“壞味道”,以下場景你是否似曾相識。
- “這個需求我們實現(xiàn)過,只需要一周時間就可以完成。”
- “關(guān)于這個需求,你做個方案給我選一選。”“這兩個方案我都不喜歡,要不你們再想想?”
- “這是領(lǐng)導(dǎo)要的,我也沒辦法。”
- “沒有這個功能,我們不能上線。”
當(dāng)聽到這些話的時候,作為工程管理者的你,就應(yīng)該警惕可能在“需求控制”方面正在遇到挑戰(zhàn),讓我們來分析一下每句話背后的挑戰(zhàn):
“這個需求我們實現(xiàn)過,只需要一周時間就可以完成。”
你的客戶正在插手你的工作量估計,這往往是最危險的。一個優(yōu)秀的項目管理者首先需要做的是讓客戶完全了解你的工作量估計系統(tǒng)是如何工作的,并不斷強調(diào)你的工作量估計是合理、公平和有效的。
“關(guān)于這個需求,你做個方案給我選一選。”“這兩個方案我都不喜歡,要不你們再想想?”這代表你的客戶不理解在軟件開發(fā)中,“需求分析”也是工作量的一部分,AB稿在設(shè)計界中廣泛存在,在我看來是最低效的一種決策方式,這一問題在軟件交付中也同樣存在。你會盡可能做出一個更趨向于復(fù)雜的設(shè)計、以求得客戶的決策,最終結(jié)果是需求被放大。
“這是領(lǐng)導(dǎo)要的,我也沒辦法。”
這代表你的客戶正在拋開自己的決策責(zé)任,嘗試用最不負責(zé)任的方式逼迫你答應(yīng)需求,一旦成功,這種行為就變成一個肆無忌憚的借口。
“沒有這個功能,我們不能上線。”
必須據(jù)理力爭,請堅信,沒有阻止上線的功能,只有阻止上線的、不理智的、缺乏安全的客戶。
這些“壞味道”是我經(jīng)常遇到的情況,有什么方法和對策呢?以下是我的一些總結(jié)。
1. 盡可能靠近決策者
軟件工程同樣是一個“社會工程”,軟件項目的失敗往往是因為其社會性的復(fù)雜,導(dǎo)致身處其中的人無法處理所負責(zé)的合作、組織、政治和職責(zé)關(guān)系。
而越是處于復(fù)雜社會網(wǎng)絡(luò)的中間、越無法對整個復(fù)雜網(wǎng)絡(luò)產(chǎn)生影響,最好的辦法是盡可能地接近決策者。但往往你總是在跟你的直接客戶合作,決策者也許是他的上級,你如何接近決策者呢?
我的建議是:盡可能幫助你的直接客戶接近他的上級、也就是真正決策者,在上一個客戶中我們做了以下幾件事情。
- 為客戶包裝向他的上級匯報的PPT。
- 總結(jié)他的上級的想法,例如用可視化的方式概括他的上級在說什么。
- 將工作過程拍成視頻,供他在組織內(nèi)傳播。
- 每周一次Newsletter,制作一些易于傳播的圖片和小視頻等。
這些內(nèi)容被我們的客戶傳播給了他的上級,甚至上級的上級,不一定要等到成功的項目,我們就已經(jīng)將影響力傳遞到了決策者,這使得你和你的客戶不再是甲乙方的關(guān)系,而是合作者,明確這個地位,才是接近決策者的重要意義。

將項目過程拍攝成專業(yè)視頻供組織內(nèi)部傳播,以此接觸高層決策者
2. 做系統(tǒng)決策人
和你的直接客戶建立合作關(guān)系之后,你還要努力將自己打造成系統(tǒng)的決策人之一。系統(tǒng)是各種概念建立關(guān)聯(lián)關(guān)系的結(jié)果,一個優(yōu)秀的系統(tǒng)決策人需要對以下決定產(chǎn)生影響。
- 是否應(yīng)該引入新的概念。
- 是否應(yīng)該將某一概念變復(fù)雜。
- 是否應(yīng)該建立新的關(guān)系。
- 是否應(yīng)該將某一關(guān)系變復(fù)雜。

用系統(tǒng)復(fù)雜度的增量方式,包括新增/加強概念和新增/加強關(guān)系來建立概念系統(tǒng)模型,用概念模型來討論需求
這套“概念系統(tǒng)”應(yīng)該持續(xù)存在于你的腦海里,一旦新的需求出現(xiàn),你就需要對這個需求做出以下決策。
- 這是否引入新的概念?
- 這是否在將現(xiàn)有概念變復(fù)雜?
- 這是否建立了新的關(guān)系?
- 這是否在將現(xiàn)有關(guān)系變復(fù)雜?
我們通常習(xí)慣于從“價值”的角度進行決策,而在真實場景中,對于任何一個沒有上線的產(chǎn)品,談?wù)摗皟r值”的意義都不大。因此談系統(tǒng)復(fù)雜度會是一個更好的策略,因為你把客戶與客戶的討論拖入了一個更偏向于系統(tǒng)工程的專業(yè)討論,而非一個“非專業(yè)”的所謂價值討論。
當(dāng)然你必須給客戶一個明確的優(yōu)先級指導(dǎo)框架,例如在一個新系統(tǒng)里,建立新概念間的關(guān)系,優(yōu)于對于一個已有概念或關(guān)系進行深入優(yōu)化,達成一致后,決策效率會更高。
3. 不要給選擇
這個建議聽起來很專斷,它背后的含義是努力讓客戶認為你所給出的幾乎是最優(yōu)選擇,就算再選,也應(yīng)該是優(yōu)、次優(yōu)、最次選擇這樣的方式,而不應(yīng)該是同等權(quán)值的盲目拍板。給選擇的目的永遠是讓客戶選擇我們期待他選擇的那一項,如果不給選擇也是其中一個選項,那么盡量不給客戶選擇。
我所使用的策略有如下幾種。
- 采用完美的系統(tǒng)思維邏輯幫助客戶認定我們選定的就是最優(yōu)選擇。
- 對我們的方案給出完整的思考和選擇過程、而不是最終方案而已。
- 給出大量的假設(shè)讓客戶認為反正都不知道最后結(jié)果是怎樣,選什么其實都沒那么重要。
- 最后才是給出多個方案,對優(yōu)缺點進行分析。
這樣的方式幫助我們強有力地抓住了需求的源頭,阻止需求擴大、或朝錯誤的方向演進。
4. 管理結(jié)果而非解決方案
管理需求的核心在于管理結(jié)果,而不在于管理解決方案,結(jié)果和解決方案的區(qū)別是什么?假設(shè)一個簡單的在線小額貸款的產(chǎn)品,也許有一長串功能需求,但核心的結(jié)果也許只有幾個。
- 借貸者能夠借到合適利率的貸款。
- 貸款者能夠在合適風(fēng)險下發(fā)放貸款并獲得收益。
- 平臺能夠管理逾期的風(fēng)險,并從中獲益。
把所有的需求討論放在對于這一系列結(jié)果的影響上,而不過多討論具體實現(xiàn)方式:有了它跟哪個核心結(jié)果有關(guān)?有了它會對這個核心結(jié)果有什么影響?沒有它呢?

一個用簡單Outcome Dashboard來管理需求的例子,通過考察需求對業(yè)務(wù)結(jié)果的影響來規(guī)劃需求
切記,不是因為東西難就不做,也不是因為東西簡單就做,而是思考一個需求對于整體結(jié)果的影響。換句話說,一個產(chǎn)品的上線,應(yīng)該是一系列結(jié)果的上線,而不是一系列需求的上線,需求是結(jié)果的副產(chǎn)品,應(yīng)該由產(chǎn)品經(jīng)理、設(shè)計師、架構(gòu)師來保證,你只需要和客戶討論最終產(chǎn)品在多大程度上可以滿足預(yù)期的結(jié)果。
如果沒有影響,無論有多簡單,都不應(yīng)該做,如果至關(guān)重要,無論多難,都應(yīng)該完成。
5. 建立游戲規(guī)則
就像之前所說的,游戲規(guī)則必須建立,這里的游戲規(guī)則,我推薦以下幾條,你需要花長時間和客戶進行討論、強調(diào)、教育、再教育。
- 沒有東西是免費的 所有東西都是有價格的,花時間的,這里包括需求的討論、編碼、改動、測試、調(diào)試、溝通等等。
- 講不清楚的需求很可能是沒價值的 如果講都講不清楚,今天講不清楚、明天講不清楚,即使寫100頁文檔,也還是講不清楚。大多數(shù)情況,都是沒價值的需求,不如推遲決策。
- 這是系統(tǒng)思考 任何一個新概念的產(chǎn)生或者一個新關(guān)系的出現(xiàn),都意味著系統(tǒng)其他部分的成本、變動、甚至破壞,謹慎一切新概念、新關(guān)系的產(chǎn)生。
- 社交游戲 復(fù)雜問題最終都是復(fù)雜的社交游戲,能通過政治或者社交解決的問題,盡可能不用技術(shù)解決,例如:當(dāng)前項目上需要其他系統(tǒng)開發(fā)的配合解決,花大力氣放在協(xié)商其他團隊改變開發(fā)計劃,而不是擴大本項目開發(fā)需求。
- 每個階段都有該階段專屬的規(guī)則 特別在需求的前期,討論越多需求,流入后期的需求范圍就越大。在一開始就應(yīng)該建立“需求規(guī)則”的概念,什么該談、什么不該談,而不是簡單跳過(例如放入Parking Lot)。

在前期需求規(guī)劃中,我們就設(shè)定了嚴格準(zhǔn)入標(biāo)準(zhǔn),任何需求的討論,如果不符合這些規(guī)則,都堅決不談
- 交付大于一切 永遠不進行項目延期,目標(biāo)是在交付期中保證交付既定的結(jié)果,而非之前約定的需求列表,可以容忍瑕疵、但不容忍延期。
- 尊重估算 不要嘗試花時間質(zhì)疑估算,你所有的懷疑會變成工程師巧妙的“套路”,他們會在另外的地方找補回來,反正你不懂,若相信,請深信。
最后,大型IT交付項目的巨大風(fēng)險在于“需求管理”,真正的訣竅在于將管理需求上升到新的層次:
- 決策者期待;
- 系統(tǒng)概念和關(guān)系以及產(chǎn)品路線圖;
- 業(yè)務(wù)結(jié)果;
- 組織內(nèi)協(xié)作和社交。
不要著眼于需求本身,如果我們只懂得用需求列表中的工作量估算、功能排期、優(yōu)先級排列,“需求失控”只是時間問題。
- Unreal Engine Physics Essentials
- 自己動手實現(xiàn)Lua:虛擬機、編譯器和標(biāo)準(zhǔn)庫
- 深入淺出DPDK
- 從學(xué)徒到高手:汽車電路識圖、故障檢測與維修技能全圖解
- Serverless架構(gòu)
- SignalR:Real-time Application Development(Second Edition)
- Mastering Android Studio 3
- 軟件工程與UML案例解析(第三版)
- JavaScript前端開發(fā)基礎(chǔ)教程
- Getting Started with RethinkDB
- Mastering Machine Learning with scikit-learn
- 循序漸進Vue.js 3前端開發(fā)實戰(zhàn)
- JavaScript高級程序設(shè)計(第4版)
- Programming MapReduce with Scalding
- MATLAB語言及編程實踐:生物數(shù)學(xué)模型應(yīng)用