在日常工作中，經(jīng)常會接到明明是坑的項目，但是沒有辦法正所謂產(chǎn)品不入地獄，誰入地獄呢，關(guān)鍵是別讓事情別的更糟就好。

項目中的墨菲定律——如何防止事情變糟

永遠不要相信計劃會一帆風順地進行至結(jié)束——要么風險已經(jīng)來到，要么正在孕育更大的風險。

曾看到一句話說：企業(yè)家常?？吹綑C會，而投資家則往往關(guān)注風險。我認為，產(chǎn)品經(jīng)理不僅僅需要看到機會，更要看到風險。在項目啟動之后，風險往往是導(dǎo)致項目走向失敗的不穩(wěn)定因素。

在呂克?貝松的電影《Léon》（國內(nèi)翻譯作《這個殺手不太冷》）中，馬蒂爾達（納塔麗?波特曼飾演）問了這樣一個問題：

人生原本就是如此艱辛，還是只有童年如此？始終如此。

產(chǎn)品經(jīng)理或許都想問一個類似的問題：所有項目都充滿著各種風險，還是僅僅在剛?cè)腴T時如此？我想借用Léon 的回答：始終如此。風險不可避免，從統(tǒng)計學(xué)角度看，項目出現(xiàn)問題的幾率不會為零。

這句話不是哪位名人說的，是我個人的感觸。經(jīng)歷了如此多的項目和版本迭代之后，我重新認識到了項目風險這個變量是多么麻煩。就拿我寫作本書來看，把整本書看成是一個產(chǎn)品項目，已經(jīng)經(jīng)歷了許多風險：

• 寫作難產(chǎn)。
• 案例難找。
• 其他事情的沖擊。

而在寫書計劃開始之前，我對于寫作的評估還是預(yù)留了一個月的緩沖期，得出結(jié)論需要半年時間。但顯然寫作這件事情并非是一種累加工作量和時間就可以保證質(zhì)量產(chǎn)出的項目，未知的因素太多：時間不夠、精力不足、生病、沒有靈感、缺乏有力的證據(jù)和案例、把時間耗費在查找資料上……而我個人作為項目的工程師，同時也是項目經(jīng)理，可以隨時調(diào)整自己的時間計劃，盡可能地趕上截稿日，但如果是多人參與的項目呢？或者是真正的產(chǎn)品項目呢？

在經(jīng)歷了如此多的項目之后，我得出了本節(jié)開頭的那句話，項目出現(xiàn)問題的幾率不會為零，即沒有不存在風險的項目。

曾經(jīng)跟進過一個很簡單的需求，按照之前的工作量評估只需要3 天就能完成，但由于涉及前后臺聯(lián)調(diào)，期間出現(xiàn)了許多意外。開發(fā)工程師請假、后臺測試環(huán)境搭建有問題、聯(lián)調(diào)的時候又出現(xiàn)意外、因為節(jié)假日造成拖延，總之這個需求前前后后一共做了10 天。這僅僅是一個小需求，而整個項目肯定不只10 個這樣的需求。對于項目來說，這種隱性的未知風險越多，延期的情況會越嚴重。項目延期可不是一件好事情，不僅有可能錯過最佳的發(fā)布時機，還有可能引起團隊內(nèi)部的不穩(wěn)定——畢竟時間越拖越久，每個人都容易產(chǎn)生不滿情緒。

出現(xiàn)了問題就需要去解決問題，團隊內(nèi)部存在這樣一種角色：項目經(jīng)理。項目經(jīng)理的職責很簡單：團隊和項目的所有事情都和他有關(guān)。有的團隊可能是由產(chǎn)品經(jīng)理去兼職項目經(jīng)理的職務(wù)，但對于一些大團隊來說，項目經(jīng)理的出現(xiàn)大大減輕了產(chǎn)品經(jīng)理的工作。比如，產(chǎn)品經(jīng)理只需要關(guān)注產(chǎn)品并保證質(zhì)量和用戶體驗即可，不需要考慮太多排期和資源的問題。但如果需要兼職做項目管理的工作，產(chǎn)品經(jīng)理就無法很用心地把時間花在產(chǎn)品上，而需要不斷開會溝通，不斷協(xié)調(diào)資源。

產(chǎn)品經(jīng)理同時兼任項目經(jīng)理的最不好的情況是，為了避免延期而做出砍功能的決策，但往往砍功能又會陷入另一種困境。為了打造最佳的產(chǎn)品體驗，每一個功能都有對應(yīng)的作用，如何決策又成為了一個難題。

那么如何解決問題呢？項目經(jīng)理常用的手段是建立流程——通過流程來把控項目的進度，這又是一把達摩克利斯之劍。良好的流程的確可以讓每個決策、每個風險和難題都擁有處理依據(jù)，可以快速定位問題并解決問題。但流程如果不起作用，則是團隊中所有人的災(zāi)難，產(chǎn)品經(jīng)理會抱怨流程復(fù)雜影響產(chǎn)品迭代；開發(fā)人員則抱怨時間太緊張，不允許給出一些緩沖時間；測試人員則會認為整個流程化的結(jié)果雖然好，但萬一開發(fā)階段就出現(xiàn)了問題，會讓測試工作更加難以展開。

項目經(jīng)理可能會據(jù)理力爭，你們沒有完全按照流程來進行——但流程其實也有缺陷，比如流程化影響了快速迭代的方式。產(chǎn)品經(jīng)理發(fā)現(xiàn)了問題應(yīng)該直接找開發(fā)工程師修改，然后由測試工程師盡快驗證并得出結(jié)果，但流程意味著這些都需要一步一步通過審批的方式來處理——這也是一種風險。

所以風險無處不在，我們所能做的并非是拒絕風險，而是迎接風險并快速響應(yīng)。正如下雨天，我們即便沒有撐傘，也不應(yīng)該繼續(xù)在街頭慢悠悠地走著，而是快速跑到避雨處或者尋求雨傘等可以解決問題的方案。

項目中的風險管理提到風險，不得不提到一本書《黑天鵝》。作者塔勒布在書的開頭這樣描述：在發(fā)現(xiàn)澳大利亞黑天鵝之前，所有歐洲人都確信天鵝全部是白色的。這是一個牢不可破的信念，因為它似乎在人們的經(jīng)驗中得到了完全的證實。對一些鳥類學(xué)家（以及非常關(guān)心鳥類顏色的其他人）來說，看見第一只黑天鵝大概是一種有趣的驚奇體驗，但這還不是澳大利亞發(fā)現(xiàn)黑天鵝的重要性所在。它說明我們通過觀察和經(jīng)驗獲得的知識具有嚴重的局限性和脆弱性。僅僅是一次觀察就可以顛覆上千年來對白天鵝的數(shù)百萬次確定性觀察所得出的結(jié)論。你所需要的只是看見一次黑天鵝就夠了。

作者得出“黑天鵝”事件的三個特點：

• 稀有性。
• 巨大的沖擊力。
• 事后可預(yù)測性。

但我從中受益最多的是這樣一種視角：經(jīng)驗不一定是可靠的。正如我周六下午一如既往地帶著貓咪去寵物店洗澡，但寵物店老板告訴我今天這里都是狗，不能給貓洗澡。按照以往6 次經(jīng)驗，周六不會出現(xiàn)如此緊張忙亂的情況，而且狗的數(shù)量也大大超過了從前。這不是關(guān)鍵，關(guān)鍵是我今天有一個重要緊急的事情需要處理，順便出門把貓帶去洗澡——這一意外直接干擾了我的計劃，導(dǎo)致我不得不花費更多的時間。原本我可以出門一次就完成兩件事情，但因為意外，我不得不在路程上多花費一倍的時間。

產(chǎn)品進入項目周期的時候同樣會出現(xiàn)這樣的問題。有一次開發(fā)工程師評估了兩個需求，覺得可以一起做，于是就把工作時間縮減了一下。結(jié)果在開發(fā)過程中發(fā)現(xiàn)兩個需求的后臺機制是不一樣的，嚴重影響開發(fā)時間。這就類似“貓咪洗澡”事件。最開始大家都很開心可以在5 個工作日完成兩個需求，結(jié)果發(fā)現(xiàn)這兩個需求要花費10 個工作日，這種風險對于項目來說是致命的。

著名的項目管理書《人月神話》提出了一個有意思的問題：在項目中增加更多的人手能不能提高效率，從而在更短的時間內(nèi)完成項目？100 等于25 乘以4，也等于50 乘以2，這是一種線性計算。但在項目中并非如此。100 人?日的工作量并不會因為開發(fā)人數(shù)增加一倍而變成50 人?日，很有可能還是100 人?日，甚至是超過100 人?日。

人月神話（The mythical man-month）：講述了人力（man）和時間（month）并不呈現(xiàn)線性關(guān)系。指出投入大量人員并不能縮短軟件的開發(fā)進度。一窩蜂式的作業(yè)方式無助于軟件生產(chǎn)，而且會制造麻煩，產(chǎn)生出更差的軟件。向進度落后的項目追加人力，只會使進度更加落后。因為新進的人員需要時間了解整個項目，而增加額外的溝通消耗。若有N 個人必須在這群人之中進行溝通（無階級關(guān)系），當N 增加，其溝通所消耗的M 將抵消其產(chǎn)生的效益，甚至出現(xiàn)負增長（最后幾天所完成的進度，遠不如剛開始幾天所完成的進度，像是發(fā)現(xiàn)了許多錯誤）。

不過這種計算方式是在一個宏觀層面上去看待項目，落實到實際操作中時，還會源源不斷地出現(xiàn)各種問題。舉例來說，有一次，產(chǎn)品有一個業(yè)務(wù)需求是由兄弟部門支持的，之前都定了合理的時間，并保證了質(zhì)量。最后出現(xiàn)了大家都沒想到的情況——這項業(yè)務(wù)涉及的一些功能無法通過App Store 的審核，不得不打回，重新修改然后上架。對于本團隊需求來說，及時調(diào)整和修改還算比較敏捷，但對于外部業(yè)務(wù)來說，溝通的成本和修改的成本就大大提高了——業(yè)務(wù)需要考慮修改了之后是否會對產(chǎn)品產(chǎn)生影響，功能是否會因此減少，體驗是否會有明顯的降低。

對于測試人員來說，每一次的發(fā)布都是工作量最飽和的時候，因為大量的修改都需要驗證通過之后才可以發(fā)布。何況，這僅僅是一次可以規(guī)避的意外，還有許多未知的事情在尋找機會發(fā)生——這就是風險所在。

對于新人來說，風險更容易出現(xiàn)。我并不否認經(jīng)驗對于工作和降低風險的重要作用，但往往有一些事情無法被預(yù)知。恰如混沌理論中的“蝴蝶效應(yīng)”，牽一發(fā)而動全身。初為產(chǎn)品經(jīng)理時，我曾遭遇過兩個與此相關(guān)的事件。

事件一：風險的出現(xiàn)起源于一份沒有說清楚的需求文檔。當時我交付了對應(yīng)的需求文檔，但由于缺乏經(jīng)驗，對于細節(jié)的把握少有提及，往往是把交互操作和頁面跳轉(zhuǎn)的邏輯重述了一遍，忽略了對于字段長度的限制、意外情況展示等方面的描述，導(dǎo)致開發(fā)人員對此理解有偏差。但當時我和開發(fā)人員并沒有建立很緊密的關(guān)系，雙方都按照各自的理解進行工作，沒有及時溝通，甚至在需求評審的過程中也沒有對細致的結(jié)果進行充分溝通。隨著開發(fā)時間的逼近，我開始體驗功能時才發(fā)現(xiàn)了許多小問題沒有解決。本以為這些小問題可以很容易地處理，結(jié)果被告知整個實現(xiàn)方式并不能修改為我想要的效果，不得不推翻方案重新開發(fā)。

在這個事件中，溝通是最大的問題。但如果產(chǎn)品經(jīng)理有經(jīng)驗，一開始就確認一些細節(jié)問題，并及時跟進體驗，多與開發(fā)人員進行交流，可以避免很多問題。

事件二：無法被預(yù)知的風險才是最可怕的事情。當接近開發(fā)尾聲的時候，發(fā)現(xiàn)老板要把方案進行調(diào)整。此時就會遇到一個棘手的問題：如果要按照方案調(diào)整，就不得不推倒重來；但重來的話，會影響到整個項目進度。于是不得不找到開發(fā)人員的負責人和項目經(jīng)理重新商議此事。這種臨門一腳的調(diào)整往往有可能帶來許多煩惱。

所以，我們不得不把風險永遠地列入產(chǎn)品經(jīng)理和項目經(jīng)理的關(guān)鍵詞列表。關(guān)于風險的概念不需要我再多做解釋，唯一可以承認的事實就是：無法預(yù)測。

正如時間的流逝，風險的存在并不是一個可控的問題，也不是一個管理問題，而是如何應(yīng)對的問題。我們無法完全地杜絕風險，而應(yīng)該迎接風險。正如LinkedIn的創(chuàng)始人霍夫曼在《至關(guān)重要的關(guān)系》一書中所提到的：風險常在，因此我們所有人都得去冒險。但是，在面對風險的時候，并不是所有人都能聰明地應(yīng)對。許多人認為，最小化風險就能獲得穩(wěn)定的事業(yè)。但是，相當諷刺的是，在一個千變?nèi)f化的世界里，這會是你做的最具風險的事情之一……

風險因人而定，而且是動態(tài)變化的。

所以，讓我們迎接風險，學(xué)會與風險并存，及時發(fā)現(xiàn)風險，管理風險，這是應(yīng)對不斷變化的現(xiàn)實的最佳策略：趁勢而為。

不過，就算我們承認需要主動地與風險打交道，還是面臨這樣的問題：

• 如何有效地規(guī)避一些風險？
• 如何制定有效的機制及時發(fā)現(xiàn)風險，而不是等到后期才發(fā)現(xiàn)？
• 如何管理風險？

作者：mary

via：騰訊大講堂