以產(chǎn)品經(jīng)理的視角看待項目,以及如何管理項目(下)(作為產(chǎn)品經(jīng)理如何做好項目管理)
對很多產(chǎn)品經(jīng)理而言,特別是身處創(chuàng)業(yè)團隊,往往都是一身挑幾職,產(chǎn)品和項目,理不清理還亂。從本文開始,以產(chǎn)品經(jīng)理的視角看待項目,以及如何管理項目。
接上篇。
四、合適的人與靠譜的計劃
幾乎每個項目都有人吐槽,太坑太扯淡。
實際上,項目之所以會扯皮,往往在前期就埋了下巨坑,隨著項目的進程問題越來越嚴重,直到不能收場。
在上文我們已經(jīng)厘清了項目的幾個核心概念 ,我們知道要想做好一個項目首先要搞清楚項目利益相關(guān)方,組建合適的項目團隊,然后我們需要分解我們的項目任務,制定一個清晰的項目計劃,才能指導和推動項目的進展。
我們現(xiàn)在從案例來還原項目前期的挖下的坑:
A公司目前正在為一個醫(yī)院開發(fā)一套系統(tǒng),現(xiàn)在項目按時間開發(fā)完成了,也做好了相關(guān)的培訓工作,但始終無法驗收,醫(yī)生說不好用,而且還有三個需求要變更,開發(fā)工程師下個月要離職了,各種問題層出不窮……
假設你是這個項目的項目經(jīng)理,我們一起來看看你踩的雷。
1. 項目第一坑:“人”才是最坑的
你從銷售經(jīng)理那里獲悉,這個項目是內(nèi)科的科長最開始發(fā)起的,副院長也很支持。
你很開心,感覺這個項目牽涉的人比較少,就開始了這個項目,并且定期發(fā)送相關(guān)的進度報告:
隨著在醫(yī)院的了解越來越多,你發(fā)現(xiàn)醫(yī)院的關(guān)系越來越復雜,各種不配合扯皮的現(xiàn)象——很多沒必要的需要變更,培訓的效果也沒有看上去理想。
你認為這是院長負責的項目,一定大家都會支持;你以為給內(nèi)科做了一次培訓,大家都會使用;沒想到培訓完之后他們還是反饋說系統(tǒng)不太好用。
這些問題,本質(zhì)上就是項目開始階段想得太簡單,沒有能搞清楚相關(guān)方的利益關(guān)系。
這是項目的第一步,也是項目的關(guān)鍵一步。
多數(shù)情況下,一個項目有支持者,往往就有反對者;項目的支持者能讓項目錦上添花,但反對者往往決定成敗。
如果在項目開始階段,沒有找出那項目能夠施加積極和消極影響力的人,注定整個項目會很艱難。
同時,你還需要找到一個最具有推動力的關(guān)鍵人,對內(nèi)爭取更多資源,對外擺平各種關(guān)系。
所以,這個項目的干系人需要更完整:
越是大型的項目,人的因素影響越大,也越難以把控。
那些決定項目成敗的,能出力的人,都應該是你的項目組成員,還有一些人,你需要TA掛一個虛職,并告訴及時告訴TA進展。
我們常常見到一個項目進行了一半,才臨時通知或者征調(diào)其他部分的人參與,帶來的問題就是溝通成本非常的高,過程完全不可控。
2. 項目第二坑:只有任務,沒有成果
項目的第二步,是要分解項目的具體工作任務,也就是要分配張三、李四分別要完成的工作。在PMP體系中這個叫WBS,在Prince2的體系中則強調(diào)的是PBS。
最直接的做法,通常都是根據(jù)“事項”來分解;畢竟我們需要把任務分配給不同的人來執(zhí)行,并根據(jù)這個任務來估算時間,確定進度。
所以最常見的分解方法就變成這個樣子:
但為什么這種分解方式會導致項目做到一半就會人員流失,士氣低下呢?
根源在于這種任務分解只關(guān)注了過程,沒有確定到底要做成什么樣,沒有邊界和具體的目標。
沒有驗收的標準,沒有衡量的指標,所有的人都在忙,忙到最后發(fā)現(xiàn)客戶不買賬。
比如項目計劃里面UI設計的是10天,為什么不是9天或者11天呢?要輸出多少個頁面?
科室培訓是培訓一天就可以了嗎?還是1小時就可以結(jié)束而且所有人都能熟練掌握?用戶向要在用戶登錄模塊里面添加一個找回用戶名的功能,要不要增加?
諸如此類的問題,隨時可能發(fā)生。
因為這種結(jié)構(gòu)是沒有辦法落實到具體一個功能需要的耗時,所以會不會打亂整個計劃就說不太清楚。
僅僅知道什么時候做什么,對項目的成敗而言是沒有意義的,關(guān)鍵是結(jié)果是什么,沒有成果的努力,都是一種自嗨。
回顧前文 “ 如何用Axure輸出高質(zhì)量的PRD?”,為什么會強調(diào)“故事”呢?
基于“用戶故事”來分解這個項目的任務——構(gòu)建一套以用戶需求驅(qū)動的PBS,才能滿足用戶的需求,也才能真正估算一個可行的項目計劃,雙方也才能在一直的目標下推進具體的功能。
這是一個項目成果的護身符,當任意發(fā)起與PBS相違背的變更都會影響到項目的進度,界定了項目的邊界,為日后的項目進度規(guī)避了許多不必要的障礙。
因為在這種結(jié)構(gòu)下,任何的變更都可能導致整個路徑的紊亂,從而項目失控?;蛘邽榱隧椖窟M度,投入更多的資源,或者友好協(xié)商推遲項目的進度。
搞不定人事,理不清邊界,是項目失敗的最關(guān)鍵因素,作為項目經(jīng)理(有一些情況下是產(chǎn)品經(jīng)理直接帶項目)務必保持清醒的頭腦。
五、項目節(jié)奏和潛在的風險
我們搞清楚了項目的利益相關(guān)方,理清楚了項目的范圍,要做什么工作也已經(jīng)妥當?shù)陌才藕昧藢H素撠?,然而項目依然還會失控。
原因何在?
展開話題之前,先回顧一下我曾經(jīng)的一個項目。
大概在12~13年左右,我有幸參與了一個大型的項目,負責整個平臺的搭建,這是一個從0到1的過程,公司和客戶都沒有過類似的項目實踐。
這個項目,看上去“沒有想象中的復雜”,關(guān)于是接單、派單、回單的過程,所有人都很樂觀,整個項目氛圍特別的輕松,3個月拿下完全沒有問題。
然而,隨著項目的推進,直到整個項目真正上線,前后耗時8個月。
項目開始前,當你能描繪一個美好藍圖的時候,所有人都會被感染,然后所有人都很樂觀,被這種情緒感染的時候,每個人都會高估自己的產(chǎn)出,并且“有意識的”低估項目的復雜度。
甚至直到項目被徹底拖垮后,人們并不愿意承認這種盲目自大的情緒最終會給項目造成危害。
在項目過程中,所有輕松的氛圍下,極其容易帶來錯誤的判斷,低估項目復雜度,低估項目的資源消耗,在商業(yè)行為上會演變?yōu)榈凸理椖績r值,從而埋下巨大的隱患。
所以,對PM來說,關(guān)注和把握好團隊的氛圍非常的重要,深刻的發(fā)現(xiàn)和傳遞項目價值,爭取相對于的資源是極為重要的。
1. 合理制定計劃,更需恰當?shù)目刂乒?jié)奏
路易十四把你抓為俘虜,要求你替他做一個計劃,為他的城堡添加三個新地牢:
- 小的地牢很難設計(最快要12周),但是容易建 成(1周)
- 中等的地牢是典型的,設計(5周),施工(6周)
- 大的地牢容易設計(1周),但是很難建造(9周)
你是這個項目的項目經(jīng)理,你有一個設計師和一個建筑師,但你的設計師不會建造而建造師不會設計。
你會怎么制定項目計劃?
在做這個計劃前,根據(jù)我的經(jīng)驗,最好還是重新檢查一遍項目的任務分解情況,其中往往暗藏風險,一定要讓你的項目是根據(jù)結(jié)果導向來反推工作事項,才能真正估算每一個結(jié)果的產(chǎn)出所需要的工作量。
正確的工作量預估,才能帶來可行的項目計劃。
所以,最直接的方式就是“物盡其用”,根據(jù)工作量估算直接安排項目計劃,每個人的工作看上去都安排很飽和。
但實際上,整個工程工期太長,資源消耗過多。
既然老板們不同意,那我們就必須尋找更好的辦法來壓縮工期。
1.加班。
在項目范圍不變的情況下,加班是一個壓縮項目周期的途徑,但很容易導致項目團隊的氛圍下降,進而引發(fā)質(zhì)量的下降。
對于加班,我們先不去做過多的討論,但我想強調(diào)的是:項目中要把握好節(jié)奏,只加有意義的班,而不以加班為樂。
2.加人。
加人這個辦法只適合項目早期,而且是越早越好——這其實意味著要在項目的早期爭取到更多的資源。
而在項目過程中,團隊穩(wěn)定才是關(guān)鍵的,往往不等于加人就可以壓縮周期,甚至只會適得其反。
把新人直接塞進項目,多少情況下不是好的選擇。
1個媽媽生一個寶寶要10個月,10個媽媽生一個寶寶,能不能是一個月?
還有一種辦法,就是通過關(guān)鍵路徑法。
既然造房子要先做好設計,那就可以把設計和建造的工作進行“分離”,先排出項目事項的優(yōu)先級,說白了就是資源的投入順序。
再找到一條完成整個項目最短可行的任務路徑,這個叫做“關(guān)鍵路徑”。
這個表,就很清晰的知道整個項目需要耗費的時間和資源,也很清晰的看到,什么時候什么資源應該投入項目。
也就是這每一個關(guān)鍵節(jié)點(里程碑)上都有真正的成功輸出,管理好每一個關(guān)鍵節(jié)點,并準備好下一個節(jié)點的資源投入,項目總體的進度會比較有序可控。
而且,這里有一個非常重要的工作——項目計劃一定要實時更新。
一個過時的計劃表,等于項目沒有計劃。
2. 風險往往存在于不經(jīng)意之間,一定要頭腦清晰
假設一個公司有多個項目并行在展開,意味著全公司的資源能夠交叉的完成的不同的項目,看上去多個項目在并行開展。
效率很高。
但這種方法卻是最難管理的,而且還帶來額外的管理風險。因為我們難以準確的估算每一個工作環(huán)節(jié)的工作量,也難以確保項目進度沒有其他因素的占用時間——比如某一個技術(shù)難點帶來的某個節(jié)點的時間延期。
在這種交叉的項目環(huán)境下,項目非常容易失控。
很多時候,我們常能聽到說并行開發(fā),實際上是對整個資源的過度自信和對項目的認識不足。看上去項目都啟動了,但質(zhì)量、進度難以保障。
同時干幾件事情的美好愿望最終導致一系列的糟糕局面。
四處救火的局面,應該盡可能的少發(fā)生。一定要能學會找出項目最重要的事情,而少去干緊急的事情。
理論上來說,在項目進入到整個階段,作為項目經(jīng)理只需要定期檢查里程碑的節(jié)點輸出即可。
在路易十四的項目中,如果你仔細再看這個表,你一定發(fā)現(xiàn)建筑工人有兩周的空閑時間。
兩周的時間,建筑工人無所事事,整天游手好閑——某一天路易十四巡視工地發(fā)現(xiàn)建筑工人睡大覺,還引起設計師的極大不滿。路易十四認為你的計劃有問題,浪費資源。
所以他直接把資源調(diào)走,理由是:建筑師并沒有完全被使用或者沒有全情投入。
你怎么辦?
這個就叫項目風險。
所謂風險,就是不確定的事情。你不能完全的規(guī)避風險,有些時候你還需要把一些風險利用起來推動項目的進展。
通常的做法是:在項目的開始階段列出一個風險清單,提醒相關(guān)的人員注意可能的狀況,防患于未然。
也就是,在項目過程有一項關(guān)鍵的節(jié)點,就是搞一個正式的儀式——召開一個項目啟動會。講清楚項目的價值、背景,需要的資源和進度,影響的范圍以及可能的風險。
把所有好的結(jié)果畫一個大餅給所有人,把所有壞的局面講清楚給所有人。
這個會上,不僅僅是傳遞信息,也是爭取資源和權(quán)力的關(guān)鍵時刻。那些資源是必須保障的,那些事情是需要經(jīng)過審批的,那些事情是需要注意,都需要講清楚。
必須確保整個項目有一個完整的可行的規(guī)則。
如果你只想做個老好人,沒有通過一個正式的儀式來獲得相應的權(quán)限,這個項目會變成非常的難以推進。
首當其沖的就是需求的變更。
要知道牽一發(fā)而動全身,一個小小的變更,甚至會引發(fā)整個項目的范圍、進度、質(zhì)量、成本的大調(diào)整,甚至可能讓整個項目處于一個分崩離析的狀況。
六、期望與權(quán)力
任何項目都有一個特色,那就是項目之前群情激昂,至于過程和結(jié)果,有的怨聲載道,有的劫后余生,萬象叢生都很正常,越大的項目故事往往越多。
在前述的文章里面,我從項目的環(huán)境,復雜的各方利益,項目的任務分解和任務進度的制定,多個角度分析和闡述了根本原因,這些誘因最終會在項目過程中成為無休止的變更,從而讓整個項目陷入不可救藥的局面。
所以,需求的變動那是家常便飯,沒有變更往往不正常,而變更的管理和文檔的確實會進一步加劇這種現(xiàn)狀。
變更,分為兩種類型,其一是完全不可控因素,既是未知的,也是不能改變的。
比如,公司的經(jīng)營方向發(fā)生了改變,導致項目的預算被削減(增加),從而影響項目的進度。特別是在創(chuàng)業(yè)型團隊,老板臨時改變注意,發(fā)現(xiàn)某個方向可能更有潛力,調(diào)轉(zhuǎn)槍頭也未可知。
作為一個項目的負責人(執(zhí)行者),在項目啟動之后,唯一的使命就是促使項目成果,或者結(jié)束項目。對未知和不可控的任何局面,都無需過多的投入精力。你能做的,就是管理那些可以被管理的內(nèi)容。
那些內(nèi)容是可以被管理的?(如何管理)
可控的需求變更,無非三大類:
- 沒有細化清晰的項目需求
- 沒有明確清楚的項目邊界
- 存在設計缺陷的軟件結(jié)構(gòu)
深究起來會發(fā)現(xiàn),在項目已經(jīng)啟動后,真正與客戶直接相關(guān)的就是第二條,由于沒有明確的項目邊界,從而導致用戶無休止的提出各種需求和變更。
而對需求本身的理解和軟件的設計,則考驗產(chǎn)品經(jīng)理和整個團隊對業(yè)務的理解、把握和產(chǎn)品設計能力。這也是為什么我一再強調(diào)“用戶故事”的原因,而這種變更則需要團隊具備極強的消化能力。
1. 建立完整的流程變更機制并嚴格遵守
項目管理,本質(zhì)就是對過程的管理,也就是要有完備的流程和堅決的執(zhí)行,通過流程來規(guī)避可能的風險。
所以,項目的第一件就是設立一個需求變更機制(如果你還記得之前談到的項目啟動會,項目經(jīng)理一定要借助這個會議讓項目的所有相關(guān)方知悉這個流程)。
這個流程有兩個核心觀念,也是你一定要能爭取到的權(quán)力:
所有人都可以提出需求變更的請求,但只有一個需求的入口——這個入口必須是你,如果你爭取不到這個權(quán)力,那整個項目一定會失控。任何都可以提出需求和變更,但你必須作為唯一的接口人和過濾器。
為此,你應該有足夠的心里準備,你需要面對N多方的壓力和“撕逼”。甚至,為了項目交付的這一終極目標,你需要有不惜得罪人的思想準備。越是大項目,越是牽涉多方的項目,風險和協(xié)調(diào)都會是指數(shù)級的放大。
只有當你具備這個權(quán)力的時候,你才能確保項目在預設的軌道上進行,也只有你才可以清晰的回答當前要做什么,能做什么,以及不能做什么。
只有評審過的需求才可以被執(zhí)行。
“不要接到需求就直接動手”。這是項目的至理名言。
你需要讓整個項目團隊,包括上至老板、直到程序員,也包括外部的客戶,都認同、理解并遵守一個基本原則,那就是程序員不直接接受任何非PM的需求,不接收任何非經(jīng)過評審的需求——所有未經(jīng)過評審的需求,只可討論,不可執(zhí)行,減少(避免)張嘴就來的非必要、非緊急、非合理的無效變更。
切記:不是所有的需求都要接受,也不是所有變更都要立刻修改,一定要能敢于拒絕需求。
作為產(chǎn)品經(jīng)理,在需求變更收集上來之后,根據(jù)需求提出方的業(yè)務進行分析后,邀請需求方、技術(shù)、設計和測試多個環(huán)節(jié)進行分析,從而判定需求對于項目的影響如何,確定是否接受變更并將變更排列優(yōu)先級。
但最終一定要你拍板,這是你需要爭取到的第二個權(quán)力。你不能最終決定一個需求的價值,對你而言,項目已經(jīng)離失控不遠了。
當然,你可以適當根據(jù)需求的范圍大小,決定評審的范圍,甚至可以決定需要告知的對象,這沒有標準,需要靈活把握。
這里其實是有一個例外,那就是技術(shù)本身驅(qū)動的變更;比如有更好的實現(xiàn)方案可以帶來性能的提升,這個情況,需要根據(jù)整體項目狀況,結(jié)合技術(shù)本身的能力判斷。
一定要爭取到合適的權(quán)限范圍,才可能有序的推進項目進程。
2. 建立完善的文檔管理機制并落實到位
俗話說“好記性不如爛筆頭”。
項目過程中,文檔是極為重要的工具,雖然管理文檔費時費力。對于產(chǎn)品經(jīng)理(創(chuàng)業(yè)團隊還是兼任項目經(jīng)理)而言,一定要持續(xù)的追蹤項目的所有需求文檔,變更記錄。
一定要所有的文檔,形成版本機制并同步到到團隊的沒有給成員,你可以借助一些在線工具來幫助你完成這項功能。
要知道,但凡失控的項目里面一定有一條就是找不到需求的出路,不知道為什么要這么做,也不知道誰要求這么做,反正就是做了,然后誰也講不清楚由來。
任何需求,都必須記錄在案,甭管是否執(zhí)行,需求的第一個動作就是備忘,第二步才是決定是否執(zhí)行。一定要專人負責需求的梳理,跟蹤和進度的反饋。
完整的需求變更記錄文檔將有助于你了解整個項目情況,包括執(zhí)行的需求,被拒絕的需求,你需要一個“需求池”統(tǒng)一管理來自業(yè)務端、技術(shù)端的需求,并針對項目中出現(xiàn)的資源、時間等因素可以合理的進行調(diào)配。
3. 張弛有度,控制項目的節(jié)奏
你確定了規(guī)則,梳理好了邊界,甚至也形成了流程。下一步,你得控制好整個產(chǎn)品的推進節(jié)奏,合理的控制和調(diào)節(jié)需求、變更的優(yōu)先級,以及資源的投放力度:什么時候該投入多少資源,什么時候該做什么事情,什么是關(guān)鍵路徑,什么是關(guān)鍵角色,你必須門兒清。你得想方設法讓你的項目,在你所能控制的范圍內(nèi)進行,一旦超過邊界,你可能需要啟動后備資源予以干預,而且是在苗頭開始之際。
你所有的干預手段,預防機制,都是為了確保項目按照一定的規(guī)則和秩序推進;也只有基于可控的節(jié)奏,你才能確保整個過程的質(zhì)量,以及最終交付的質(zhì)量。當過程不可控的時候,往往結(jié)果會很糟糕。
最后,一定要深刻的理解,需求是不斷的演進和變化的,合理的規(guī)避不合理的變更方為上策。
有些時候,無論你怎樣控制,由于市場的壓力,總會碰到各種“無理”要求,如何看待這樣的問題,就不是簡單的控制問題了,這就需要更高的層面去權(quán)衡利弊,如果確實不值得,也只能放棄。
寫在系列收尾處
產(chǎn)品經(jīng)理作為引路人,就是盡可能的讓不確定性的因素,變?yōu)榇_定的,可被執(zhí)行的流程、方案。
不管你是否兼任“項目經(jīng)理”的角色,在一個產(chǎn)品從0到1的過程里面,產(chǎn)品經(jīng)理必須深刻的理解整個過程的艱巨,要能與團隊一起致力于整個項目的成功。
至此,本系列從項目和產(chǎn)品的概念出發(fā),到項目環(huán)境的分析,以及對項目過程的幾大巨坑一一做了闡述,也許你還需要一些工具,或者模板來提高項目過程管理的效率。
#專欄作家#
杜松,公眾號:產(chǎn)品微言,人人都是產(chǎn)品經(jīng)理專欄作家。專注于人工智能方向,擅長產(chǎn)品規(guī)劃和架構(gòu)設計。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
題圖由作者提供