產品經理如何防止事情變糟?
在日常工作中,經常會接到明明是坑的項目,但是沒有辦法正所謂產品不入地獄,誰入地獄呢,關鍵是別讓事情別的更糟就好。
項目中的墨菲定律——如何防止事情變糟
永遠不要相信計劃會一帆風順地進行至結束——要么風險已經來到,要么正在孕育更大的風險。
曾看到一句話說:企業家常??吹綑C會,而投資家則往往關注風險。我認為,產品經理不僅僅需要看到機會,更要看到風險。在項目啟動之后,風險往往是導致項目走向失敗的不穩定因素。
在呂克?貝松的電影《Léon》(國內翻譯作《這個殺手不太冷》)中,馬蒂爾達(納塔麗?波特曼飾演)問了這樣一個問題:
人生原本就是如此艱辛,還是只有童年如此?始終如此。
產品經理或許都想問一個類似的問題:所有項目都充滿著各種風險,還是僅僅在剛入門時如此?我想借用Léon 的回答:始終如此。風險不可避免,從統計學角度看,項目出現問題的幾率不會為零。
這句話不是哪位名人說的,是我個人的感觸。經歷了如此多的項目和版本迭代之后,我重新認識到了項目風險這個變量是多么麻煩。就拿我寫作本書來看,把整本書看成是一個產品項目,已經經歷了許多風險:
- 寫作難產。
- 案例難找。
- 其他事情的沖擊。
而在寫書計劃開始之前,我對于寫作的評估還是預留了一個月的緩沖期,得出結論需要半年時間。但顯然寫作這件事情并非是一種累加工作量和時間就可以保證質量產出的項目,未知的因素太多:時間不夠、精力不足、生病、沒有靈感、缺乏有力的證據和案例、把時間耗費在查找資料上……而我個人作為項目的工程師,同時也是項目經理,可以隨時調整自己的時間計劃,盡可能地趕上截稿日,但如果是多人參與的項目呢?或者是真正的產品項目呢?
在經歷了如此多的項目之后,我得出了本節開頭的那句話,項目出現問題的幾率不會為零,即沒有不存在風險的項目。
曾經跟進過一個很簡單的需求,按照之前的工作量評估只需要3 天就能完成,但由于涉及前后臺聯調,期間出現了許多意外。開發工程師請假、后臺測試環境搭建有問題、聯調的時候又出現意外、因為節假日造成拖延,總之這個需求前前后后一共做了10 天。這僅僅是一個小需求,而整個項目肯定不只10 個這樣的需求。對于項目來說,這種隱性的未知風險越多,延期的情況會越嚴重。項目延期可不是一件好事情,不僅有可能錯過最佳的發布時機,還有可能引起團隊內部的不穩定——畢竟時間越拖越久,每個人都容易產生不滿情緒。
出現了問題就需要去解決問題,團隊內部存在這樣一種角色:項目經理。項目經理的職責很簡單:團隊和項目的所有事情都和他有關。有的團隊可能是由產品經理去兼職項目經理的職務,但對于一些大團隊來說,項目經理的出現大大減輕了產品經理的工作。比如,產品經理只需要關注產品并保證質量和用戶體驗即可,不需要考慮太多排期和資源的問題。但如果需要兼職做項目管理的工作,產品經理就無法很用心地把時間花在產品上,而需要不斷開會溝通,不斷協調資源。
產品經理同時兼任項目經理的最不好的情況是,為了避免延期而做出砍功能的決策,但往往砍功能又會陷入另一種困境。為了打造最佳的產品體驗,每一個功能都有對應的作用,如何決策又成為了一個難題。
那么如何解決問題呢?項目經理常用的手段是建立流程——通過流程來把控項目的進度,這又是一把達摩克利斯之劍。良好的流程的確可以讓每個決策、每個風險和難題都擁有處理依據,可以快速定位問題并解決問題。但流程如果不起作用,則是團隊中所有人的災難,產品經理會抱怨流程復雜影響產品迭代;開發人員則抱怨時間太緊張,不允許給出一些緩沖時間;測試人員則會認為整個流程化的結果雖然好,但萬一開發階段就出現了問題,會讓測試工作更加難以展開。
項目經理可能會據理力爭,你們沒有完全按照流程來進行——但流程其實也有缺陷,比如流程化影響了快速迭代的方式。產品經理發現了問題應該直接找開發工程師修改,然后由測試工程師盡快驗證并得出結果,但流程意味著這些都需要一步一步通過審批的方式來處理——這也是一種風險。
所以風險無處不在,我們所能做的并非是拒絕風險,而是迎接風險并快速響應。正如下雨天,我們即便沒有撐傘,也不應該繼續在街頭慢悠悠地走著,而是快速跑到避雨處或者尋求雨傘等可以解決問題的方案。
項目中的風險管理提到風險,不得不提到一本書《黑天鵝》。作者塔勒布在書的開頭這樣描述:在發現澳大利亞黑天鵝之前,所有歐洲人都確信天鵝全部是白色的。這是一個牢不可破的信念,因為它似乎在人們的經驗中得到了完全的證實。對一些鳥類學家(以及非常關心鳥類顏色的其他人)來說,看見第一只黑天鵝大概是一種有趣的驚奇體驗,但這還不是澳大利亞發現黑天鵝的重要性所在。它說明我們通過觀察和經驗獲得的知識具有嚴重的局限性和脆弱性。僅僅是一次觀察就可以顛覆上千年來對白天鵝的數百萬次確定性觀察所得出的結論。你所需要的只是看見一次黑天鵝就夠了。
作者得出“黑天鵝”事件的三個特點:
- 稀有性。
- 巨大的沖擊力。
- 事后可預測性。
但我從中受益最多的是這樣一種視角:經驗不一定是可靠的。正如我周六下午一如既往地帶著貓咪去寵物店洗澡,但寵物店老板告訴我今天這里都是狗,不能給貓洗澡。按照以往6 次經驗,周六不會出現如此緊張忙亂的情況,而且狗的數量也大大超過了從前。這不是關鍵,關鍵是我今天有一個重要緊急的事情需要處理,順便出門把貓帶去洗澡——這一意外直接干擾了我的計劃,導致我不得不花費更多的時間。原本我可以出門一次就完成兩件事情,但因為意外,我不得不在路程上多花費一倍的時間。
產品進入項目周期的時候同樣會出現這樣的問題。有一次開發工程師評估了兩個需求,覺得可以一起做,于是就把工作時間縮減了一下。結果在開發過程中發現兩個需求的后臺機制是不一樣的,嚴重影響開發時間。這就類似“貓咪洗澡”事件。最開始大家都很開心可以在5 個工作日完成兩個需求,結果發現這兩個需求要花費10 個工作日,這種風險對于項目來說是致命的。
著名的項目管理書《人月神話》提出了一個有意思的問題:在項目中增加更多的人手能不能提高效率,從而在更短的時間內完成項目?100 等于25 乘以4,也等于50 乘以2,這是一種線性計算。但在項目中并非如此。100 人?日的工作量并不會因為開發人數增加一倍而變成50 人?日,很有可能還是100 人?日,甚至是超過100 人?日。
人月神話(The mythical man-month):講述了人力(man)和時間(month)并不呈現線性關系。指出投入大量人員并不能縮短軟件的開發進度。一窩蜂式的作業方式無助于軟件生產,而且會制造麻煩,產生出更差的軟件。向進度落后的項目追加人力,只會使進度更加落后。因為新進的人員需要時間了解整個項目,而增加額外的溝通消耗。若有N 個人必須在這群人之中進行溝通(無階級關系),當N 增加,其溝通所消耗的M 將抵消其產生的效益,甚至出現負增長(最后幾天所完成的進度,遠不如剛開始幾天所完成的進度,像是發現了許多錯誤)。
不過這種計算方式是在一個宏觀層面上去看待項目,落實到實際操作中時,還會源源不斷地出現各種問題。舉例來說,有一次,產品有一個業務需求是由兄弟部門支持的,之前都定了合理的時間,并保證了質量。最后出現了大家都沒想到的情況——這項業務涉及的一些功能無法通過App Store 的審核,不得不打回,重新修改然后上架。對于本團隊需求來說,及時調整和修改還算比較敏捷,但對于外部業務來說,溝通的成本和修改的成本就大大提高了——業務需要考慮修改了之后是否會對產品產生影響,功能是否會因此減少,體驗是否會有明顯的降低。
對于測試人員來說,每一次的發布都是工作量最飽和的時候,因為大量的修改都需要驗證通過之后才可以發布。何況,這僅僅是一次可以規避的意外,還有許多未知的事情在尋找機會發生——這就是風險所在。
對于新人來說,風險更容易出現。我并不否認經驗對于工作和降低風險的重要作用,但往往有一些事情無法被預知。恰如混沌理論中的“蝴蝶效應”,牽一發而動全身。初為產品經理時,我曾遭遇過兩個與此相關的事件。
事件一:風險的出現起源于一份沒有說清楚的需求文檔。當時我交付了對應的需求文檔,但由于缺乏經驗,對于細節的把握少有提及,往往是把交互操作和頁面跳轉的邏輯重述了一遍,忽略了對于字段長度的限制、意外情況展示等方面的描述,導致開發人員對此理解有偏差。但當時我和開發人員并沒有建立很緊密的關系,雙方都按照各自的理解進行工作,沒有及時溝通,甚至在需求評審的過程中也沒有對細致的結果進行充分溝通。隨著開發時間的逼近,我開始體驗功能時才發現了許多小問題沒有解決。本以為這些小問題可以很容易地處理,結果被告知整個實現方式并不能修改為我想要的效果,不得不推翻方案重新開發。
在這個事件中,溝通是最大的問題。但如果產品經理有經驗,一開始就確認一些細節問題,并及時跟進體驗,多與開發人員進行交流,可以避免很多問題。
事件二:無法被預知的風險才是最可怕的事情。當接近開發尾聲的時候,發現老板要把方案進行調整。此時就會遇到一個棘手的問題:如果要按照方案調整,就不得不推倒重來;但重來的話,會影響到整個項目進度。于是不得不找到開發人員的負責人和項目經理重新商議此事。這種臨門一腳的調整往往有可能帶來許多煩惱。
所以,我們不得不把風險永遠地列入產品經理和項目經理的關鍵詞列表。關于風險的概念不需要我再多做解釋,唯一可以承認的事實就是:無法預測。
正如時間的流逝,風險的存在并不是一個可控的問題,也不是一個管理問題,而是如何應對的問題。我們無法完全地杜絕風險,而應該迎接風險。正如LinkedIn的創始人霍夫曼在《至關重要的關系》一書中所提到的:風險常在,因此我們所有人都得去冒險。但是,在面對風險的時候,并不是所有人都能聰明地應對。許多人認為,最小化風險就能獲得穩定的事業。但是,相當諷刺的是,在一個千變萬化的世界里,這會是你做的最具風險的事情之一……
風險因人而定,而且是動態變化的。
所以,讓我們迎接風險,學會與風險并存,及時發現風險,管理風險,這是應對不斷變化的現實的最佳策略:趁勢而為。
不過,就算我們承認需要主動地與風險打交道,還是面臨這樣的問題:
- 如何有效地規避一些風險?
- 如何制定有效的機制及時發現風險,而不是等到后期才發現?
- 如何管理風險?
作者:mary
via:騰訊大講堂
- 目前還沒評論,等你發揮!