項目管理:產(chǎn)品經(jīng)理如何進行項目管理?

28 評論 49720 瀏覽 528 收藏 23 分鐘

在產(chǎn)品迭代中,產(chǎn)品經(jīng)理要負責(zé)相關(guān)產(chǎn)品開發(fā)周期和進度的把控,進行跨部門協(xié)調(diào)和溝通,最終保證新版本按時上線,這就需要產(chǎn)品經(jīng)理具有項目管理能力。今天,我們就來聊一聊項目管理。

本文結(jié)構(gòu)如下:

產(chǎn)品經(jīng)理的自我修養(yǎng)(項目管理)

項目管理不單單是在產(chǎn)品開發(fā)過程中進行,在對一個項目進行管理時,開發(fā)前的需求傳達,項目排期,以及開發(fā)中的跟進開發(fā),都是非常重要的,做好以上幾點,版本按時上線也就不難了。

一、需求傳達

由于程序猿們沒有經(jīng)歷需求篩選,需求分析等步驟,因此當產(chǎn)品經(jīng)理決定上一個新功能時,一定要和程序猿們進行完整的需求傳達。在需求傳達時,我們可以按照項目背景以及功能流程進行介紹。

1. 項目背景介紹

在進行項目背景介紹時,我們要清楚的告知程序猿這個新功能所針對的目標用戶是誰,使用場景是什么,以及這個項目解決了用戶什么需求,總結(jié)下來就是5w1h:who、when、where、what、how、why(誰,在什么時候,在哪,解決什么問題,如何解決的,為什么去解決)。

為了形象而具體的講述以上幾點,我們用講故事的方式為程序猿進行講解,假設(shè)這次增加的是線上減肥課程的功能,我們可以這樣來描述:

“小明是一個26歲的白領(lǐng),每天到了公司就是開會、敲鍵盤、趕項目,典型的脫發(fā)人群。小明每天下班就已經(jīng)不早了,再加上地鐵和走路的時間,經(jīng)常很晚才到家,長期勞累且缺乏鍛煉的生活使他體重上漲,為了健康,也為了找女朋友,小明痛下決心要減肥。

但是由于小明每天下班晚,回家的路程又遠,沒有整塊的時間去健身房,自己在家練吧又找不對方法,這使得小明非??鄲馈?/p>

而我們這次上的新功能呢,就是幫小明這種沒有時間去健身房,也不知道該如何減肥的人完成瘦身目標。你看:小明下班到家后,只需要打開手機app,選擇適合自己的減肥教程,然后跟著教程進行訓(xùn)練就好了,訓(xùn)練完后還可以將系統(tǒng)生成的圖片進行分享,發(fā)送到朋友圈中讓大家來監(jiān)督他減肥。所以我們這個功能不僅幫小明節(jié)省了往返健身房的時間,還幫他免去了請私教的錢,是一個真真切切服務(wù)用戶的功能。”

用講故事的方式來描述項目背景的好處是,可以更好地把對方帶入到使用場景之中,從而能感同身受的理解用戶的痛點。最后在說新功能好處的時候,可以稍稍夸大一點,這樣可以激發(fā)程序猿的工作熱情,讓程序猿覺得自己在做一件非常有意義的事。最好我們講的故事能讓程序猿產(chǎn)生“躍躍欲試”的心理。

2. 功能流程介紹

項目背景介紹完了,程序猿們對項目也有認同感了,接下來的就是功能流程介紹了。

功能流程介紹分為業(yè)務(wù)流程介紹和數(shù)據(jù)流程介紹,業(yè)務(wù)流程介紹是站在用戶的角度上來展示用戶是如何使用的,按照用戶的操作順序,對照流程圖進行講解。比如:小明到家后打開APP,根據(jù)自己的需要選擇相應(yīng)的課程類別,選擇類別后出現(xiàn)屬于該類別的課程列表,然后再選擇具體的課程進行訓(xùn)練,訓(xùn)練結(jié)束后系統(tǒng)將生成的圖片供用戶分享。

如下圖所示(已忽略所有異常情況):

產(chǎn)品經(jīng)理的自我修養(yǎng)(項目管理)

業(yè)務(wù)流程介紹可以簡短一些,只要讓程序猿了解功能點和頁面都有哪些就可以了。

需要詳細介紹的是數(shù)據(jù)流程,畢竟程序猿是天天跟數(shù)據(jù)打交道的,在介紹的時候要按照邏輯,以數(shù)據(jù)流為主線進行介紹,讓程序員們知道每一個數(shù)據(jù)都是哪里來的。比如首先要在服務(wù)器存儲相關(guān)的課程數(shù)據(jù),在用戶進入app選擇課程類別時,前端向服務(wù)器索要有關(guān)課程類別的數(shù)據(jù)并進行展示,這里用UML序列圖展示:

產(chǎn)品經(jīng)理的自我修養(yǎng)(項目管理)

在我們在按照數(shù)據(jù)流講解完之后,程序猿就能比較清楚的知道自己要做一個什么功能了。到這里,需求傳達就已經(jīng)基本完成了,其實需求傳達屬于需求評審中講解的內(nèi)容,需求評審結(jié)束后,我們就要著手準備項目排期了。

二、項目排期

在進行項目排期前,我們一定要提前把原型和文檔等資料交給程序猿們,最好在需求評審之前就開始讓程序猿們提前熟悉,這樣可以盡快的明確開發(fā)工作量。

1. 明確工作量

在這個階段我們的主要任務(wù)就是和項目經(jīng)理進行溝通,確認什么時候可以進行項目排期。因為在需求評審后需要給程序猿們一段緩沖期,程序猿們會利用這段緩沖期更仔細的了解需求,并思考開發(fā)方法;緩沖期結(jié)束后再進行項目排期。緩沖期的時間盡量讓項目經(jīng)理來定,我們不要太多的干預(yù),程序猿對需求研究的越透徹,思考的越全面,在后面的開發(fā)中才會越順利。

在經(jīng)過緩沖期后,程序猿們基本已經(jīng)對項目的工作量了然于胸了,這時程序猿往往會提出一些建議,出現(xiàn)最多的情況有以下兩種:

  1. 程序猿希望對需求提出異議(比如頁面交互,以及部分流程);
  2. 程序猿希望砍掉部分需求。

針對第一點,我們一定要耐心聽完程序猿修改需求的理由,千萬不要覺得需求分析是自己的職能,他們提建議是在多管閑事,想把一件事做到面面俱到是很難的,有時候程序猿提的點子正好是你沒想到的地方。當出現(xiàn)這種情況時,不要著急給答復(fù),回去將程序猿給出的方案和之前自己的方案仔細對比一下,選出一個最優(yōu)的。如果你覺得程序猿給出的建議更好,那么就采納程序猿的建議,同時更新文檔并告知其他團隊人員。

如果是第二點,那么就要分情況討論了,如果是不那么重要的需求,可以放在下個版本,如果是自己本身也模棱兩可的需求,那么直接砍掉就好了。但如果是核心需求,那么堅決不砍,絕不讓步,核心需求是下個版本最重要的部分,是萬萬砍不得的。

當把工作量弄清楚以后,下一步就是確認開發(fā)順序和開發(fā)時間。

2. 確認開發(fā)順序

這里主要需要確認的就是先開發(fā)哪些功能模塊,后開發(fā)哪些功能模塊,這里注意,有了開發(fā)順序才能進行項目排期。

在確認開發(fā)順序的時候,我們?nèi)匀灰晚椖拷?jīng)理進行充分溝通,明確本次開發(fā)中有溢出風(fēng)險的模塊,也就是說出了問題會嚴重影響其他模塊乃至整個產(chǎn)品上線的地方。

舉個栗子:假如我這次做的是一個智能穿戴設(shè)備的APP,那么最有溢出風(fēng)險的模塊是哪個呢?

不是注冊登錄,也不是數(shù)據(jù)顯示,而是設(shè)備與手機進行藍牙連接的模塊:注冊登錄我們可以用第三方登錄來解決,如果數(shù)據(jù)展示因為工期問題做不完,我們也可以砍掉部分展示數(shù)據(jù)以保證按時上線。但藍牙設(shè)備連接是不可能砍的,這是智能穿戴設(shè)備功能的基礎(chǔ)。

所以說,藍牙設(shè)備連接就是有溢出風(fēng)險的模塊,在開發(fā)順序中一定要放在前面,這樣我們就可以先對藍牙連接模塊進行測試,這樣出現(xiàn)問題時可以提前解決,不會影響其他功能。

3. 確認開發(fā)時間

當確定好開發(fā)順序后,我們就可以根據(jù)開發(fā)順序來確認每個模塊的完成時間了,用甘特圖是一個不錯的選擇,制作甘特圖的時候,我們需要定任務(wù),確職責(zé)。所以在表中我們要寫明任務(wù),負責(zé)人,起止時間,以避免后期的扯皮。

而在開發(fā)過程中,前端在進行框架選取及頁面開發(fā)的時候,是不需要后端提供數(shù)據(jù)的,在后端進行數(shù)據(jù)庫設(shè)計以及編寫接口的時候,也是不需要UI設(shè)計師切圖的。因此前端開發(fā)和后端開發(fā)是可以并行的,如下圖所示:后端的橫向柱狀圖空缺的部分,是留給他們進行接口調(diào)試和bug修改的。

產(chǎn)品經(jīng)理的自我修養(yǎng)(項目管理)

上圖這張甘特圖只是舉例,在實際的工作中,可以按每個模塊來劃分,將核心的、高風(fēng)險的模塊向程序猿重點說明,在開發(fā)的過程中也要更細致的跟進

如果項目有明確的截止時間,那么我們就根據(jù)截止時間來倒推每個模塊的完成時間,如果時間實在不夠,砍需求吧,程序猿們會感激你的。

三、項目跟進

經(jīng)過前期的工作,我們終于把事情推進到開發(fā)階段了,那么產(chǎn)品經(jīng)理在開發(fā)過程中會很輕松么?當然不是,我們要對產(chǎn)品的結(jié)果負責(zé),當然要對項目進行跟進。

1. 鱒魚和橋梁

在項目跟進的過程中,我們雖然對敲代碼沒有發(fā)言權(quán),但是我們要時刻清楚地知道項目動態(tài),并作為程序猿們溝通的橋梁,遇到問題時要協(xié)調(diào)相關(guān)人員進行溝通,像鱒魚一樣提高團隊的積極性和效率。

項目動態(tài)我們可以用每日站立會的方法來進行,站立會表面聽起來是開會,但是實際上我們不需要拘泥于開會的地點和形式,我們可以在每天早晨剛到公司的時候和程序猿溝通,也可以午休后在工位上進行,甚至一起上廁所的時候也可以。

開會的內(nèi)容主要是昨天都做了什么,今天要做什么,遇到或者可能會遇到哪些問題。然后我們要積極的去協(xié)調(diào),來幫助程序員解決問題。最好在程序猿開發(fā)某個模塊之前與他進行需求再確認,以確保最終開發(fā)出來的東西是我們心中所想的那樣。

在這個過程中,需要我們自身有主人翁意識,靈活而又勤快的去推動項目的進行。

2. 異常情況處理

雖然做足了準備,但還是經(jīng)常會有異常情況出現(xiàn),可能出現(xiàn)的異常情況有:

(1)程序員對需求理解有偏差

在項目的開發(fā)過程中,經(jīng)常會出現(xiàn)這個問題,但這不能怪程序猿,畢竟寫的再詳細的文檔,不同的人看也可能會產(chǎn)生不同的理解,還有可能是我們的文檔寫的不夠詳細。

針對這個問題,我們應(yīng)該把主要精力要放在預(yù)防上面:

在程序猿開發(fā)某一個小模塊前,尤其是新出現(xiàn)的或者是重點模塊,主動去找程序猿進行需求再確認,再和程序猿講明需求,也可以讓程序猿口述一下需求,我們來聽。最終目的就是要確認程序猿已經(jīng)完全理解了需求,避免后續(xù)的更改與返工。

如果在開發(fā)過程中仍然出現(xiàn)了對需求的理解問題,比如前端和后端對接口的理解不一,如果你此時不去協(xié)調(diào),那么這個問題可能會被擱置,后期還是會爆發(fā)出來。還有可能是理解錯誤的一方將另一方說服,從而造成后期的返工和改動,這是很傷的。

當發(fā)現(xiàn)雙方有理解上的偏差時,一定要把雙方叫在一起討論,確保前端和后端都能正確的理解需求,再進行開發(fā)。在項目開始前一定和程序猿講明,對需求有任何分歧一定要找你,大家商議解決,而不要私下討論。

(2)出現(xiàn)需求變更

需求變更,無論是產(chǎn)品經(jīng)理還是程序猿,看到這個詞都會覺得頭疼。

出現(xiàn)需求變更的原因主要有三個:

  1. 產(chǎn)品經(jīng)理自己沒有思考全面,比如對異常情況的處理不夠細膩等等。我們應(yīng)該盡量避免這種情況的發(fā)生,如果總出現(xiàn)這個問題,說明我們的工作是有疏忽的,程序猿也會對你產(chǎn)生不信任感。如果因為這個原因出現(xiàn)了需求變更,去找程序猿大爺說明吧,回來后對自己進行充分反思,并爭取在下一次做得更好。
  2. 老板要求改需求,這種情況我們看似無能為力,但實際上也是有操作空間的。對于老板的要求,我們首先要仔細的思考利弊,如果仍然覺得之前的方案好,拿出證據(jù)向老板說明。如果老板的方案更好,那么我們就要有技巧的向程序猿說明。同樣可以利用講故事的方式,向程序猿說明更改需求的原因與必要性。這時就是考驗?zāi)愫统绦蛟酬P(guān)系的時候了,沒事的時候記得和程序猿們打好關(guān)系哦。
  3. 自己腦袋中突然靈光一閃,覺得某個功能點有更好的方案。如果是這種情況,哪怕這個方案真的好,哪怕它能提升50%的轉(zhuǎn)化率,我還是建議放在下個版本進行優(yōu)化,如果我們站在程序猿的角度上想:“需求是你定的,我代碼都寫一半了,你突然有了更好的點子,然后就讓我刪除自己辛辛苦苦敲出來的代碼,憑什么?”

人非圣賢,誰也不能保證自己第一個方案就是完美的,當有了更好的點子時,我們不妨再增加一個優(yōu)化版本,反正版本上線后我們也要收集用戶反饋,把這個點子放在優(yōu)化版本里不是更好么?

(3)項目進度延期

當發(fā)現(xiàn)項目進度已經(jīng)落后的時候,我們首先要分析原因,根據(jù)原因來尋找解決辦法??赡艿脑蛴幸韵聨讉€:

①團隊溝通不暢

如果前期做好了預(yù)防,一般是不會出現(xiàn)這個問題的。但真出現(xiàn)了這個問題怎么辦呢?此時我們就需要找到溝通不暢的當事人,詢問原因,是成員之間不能正確理解對方的意思呢,還是互相不認可對方的觀點。

如果是溝通不暢的雙方?jīng)]有辦法正確理解對方的意思,那此時我們要做雙方的“翻譯機”,確保成員之間理解統(tǒng)一;如果是互相不認可對方的觀點,那么此時,抓上項目經(jīng)理或開發(fā)主管,一起來商量誰的解決辦法更好。總而言之,一定要確保團隊成員對項目理解的統(tǒng)一,大家?guī)е粋€目標前進。

②程序猿能力不夠

之前也遇到過這種問題,程序猿小A難以完成分配給他任務(wù),這時我們就要叫上技術(shù)的大佬,然后讓程序猿小A去敘述他遇到了什么難題,讓大家一起解決,解決問題的方法我們就不摻和了,做好團隊之間的橋梁就好。

③程序猿因為生活上的事導(dǎo)致情緒低落,開發(fā)積極性低

我們都是人, 是有情感的動物,難免會因為生活上的的事情影響到工作,這時候,我們要從同事的身份中脫離出來,作為朋友,帶著程序猿去吃點小菜,喝掉小酒,聊聊人生,看看美女,沒事再給程序猿買點零食,送點溫暖。此時對待程序猿要向?qū)Υ约号笥岩粯訙厝幔瑤退麖那榫w低谷中走出來,重新振作開始工作,這樣無論是對于團隊,還是對于他自己,都是有好處的。

④對工期預(yù)估過于樂觀,項目排期出現(xiàn)了問題

項目排期,其實也是一個預(yù)估的時間,誰也不能保證一定可以準時完成,如果是項目排期出現(xiàn)了問題,一般項目經(jīng)理會讓大家用出神技:加班??!

當然此時我們也不能眼睜睜的看著程序猿們加班,我們可以發(fā)揮自己的價值:砍!需!求!雖然心很痛,但是看著程序猿們?nèi)找嫦∈璧念^發(fā),還是咬咬牙把需求砍掉吧,找機會再加。

如果砍無可砍,趕緊重新評估時間并向老大報告,避免因為自己項目的延期影響到整條產(chǎn)品線。

總結(jié)

目前我個人對項目的理解就是這些了,在最后做個總結(jié),要想做好項目管理,產(chǎn)品經(jīng)理要有以下幾個意識:

(1)主次意識

在一個項目里,一定要分清主次,知道哪些是主要的、核心的,要時刻關(guān)注的,哪些是可有可無的,可以砍掉的。

(2)風(fēng)險意識

在項目開始前,我們就要知道哪些模塊是有溢出風(fēng)險的,或者可控性不強的,比如想做智能穿戴設(shè)備,如果不打通藍牙模塊,后面的檢測心跳,記錄步數(shù)等各功能都是沒有意義的。再比如我們把一部分外包給其他公司,這就屬于可控性低的情況下。

因為我們自己公司可以通過加強溝通,加班等方式來解決的問題,可能外包項目就解決不了,出現(xiàn)問題時雙方的溝通效率就是比自己公司內(nèi)部低。如果到項目結(jié)尾才開始驗收外包部分,此時出了問題很大可能會影響項目的按時上線。

對于高風(fēng)險部分,我們應(yīng)該提前做好預(yù)案,并在項目過程中對有風(fēng)險的部分多加關(guān)注,將問題殺死在萌芽狀態(tài)。

(3)時間意識

項目管理,無非就是通過資源的調(diào)動來達成目標。資源可以是人員,也可以是時間,而作為重要資源的時間,我們必須時刻關(guān)注,一旦失控可能會造成連鎖反應(yīng)。

在時間的管控上面,我們不僅要做好項目時間管理,同時也要做好自己的時間管理,這樣我們才能在項目中游刃有余的去應(yīng)對難題。

(4)溝通意識

其實溝通在本文已經(jīng)出現(xiàn)很多次了,我們要做團隊溝通的橋梁,就要站在對方的角度,用對方能理解的方式和他進行溝通,多用舉例進行說明,很多事情直接說可能說不明白,舉個例子大家就很容易懂了。

(5)主人翁意識

在項目推進中,是需要我們產(chǎn)品經(jīng)理和項目經(jīng)理一起牽頭的,我們要把自己當成老板,出現(xiàn)意外時多向下想一步,思考一下表象下真正的原因,然后去解決。

我的訣竅就是:先假設(shè)這個問題不是偶然問題,然后站在更高層次去思考解決辦法,這樣就可以避免日后再發(fā)生此類問題。

經(jīng)常問一問自己:“這是問題的真正原因么?這樣去解決以后還會發(fā)生么?”要盡自己最大努力,去做好團隊中的“發(fā)動機”。

 

作者:撒野的氧氣,公眾號:產(chǎn)品汪的成長路

本文由 @撒野的氧氣 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉(zhuǎn)載。

題圖來自Unsplash,基于CC0協(xié)議。

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 自己知道而且能清晰的寫出來,真的很不錯

    來自浙江 回復(fù)
  2. 那個項目管理軟件比較好

    來自北京 回復(fù)
  3. 學(xué)習(xí)了,很實在,可操作!謝謝!

    來自貴州 回復(fù)
  4. 寫的特別好,很有收獲,謝謝大佬

    來自湖北 回復(fù)
  5. 樓主你好,請問哪款項目管理軟件比較好用?

    回復(fù)
    1. 同問

      來自江蘇 回復(fù)
  6. 這段時間就是就在負責(zé)一個項目,其中有部分功能就是需要和第三方集成,耦合性較高,用戶需求還頻繁變動。

    來自北京 回復(fù)
  7. 總結(jié)的很全面,收益?。?!

    來自北京 回復(fù)
  8. 詳細全面 謝謝大佬

    來自江蘇 回復(fù)
  9. 感謝,我覺得項目最大的問題就是在跟程序員小哥哥溝通需求和實現(xiàn)方式那部分。

    來自廣東 回復(fù)
    1. 我感覺就是需求設(shè)計那塊很難,很難想的全,很難和用戶場景完美匹配。

      來自江蘇 回復(fù)
  10. 感謝,文章很詳細邏輯清晰,學(xué)到啦

    來自安徽 回復(fù)
  11. 我感覺還是比較實在的,跟我們上一期的實際情況差不多

    來自上海 回復(fù)
  12. 寫的很詳細呀~

    來自上海 回復(fù)
  13. 謝謝,學(xué)習(xí)了

    回復(fù)
  14. 看了這篇文章,受益匪淺,

    來自廣東 回復(fù)
  15. 你好,我們轉(zhuǎn)載這篇文章在我的公眾號嗎?

    回復(fù)
  16. 基本流程和筆者寫的相同,大體細節(jié)沒有筆者考慮周全,感謝,非常好的一篇文章

    來自江蘇 回復(fù)
  17. 感謝分享,寫很生動

    回復(fù)
  18. 請問一下,跟程序員更好溝通至少需要掌握編程語言到什么程度呀?

    回復(fù)
    1. 入門級就可以啦

      回復(fù)
  19. 剛負責(zé)一個項目,看了大佬的分享,其中很多都需要我去自己去學(xué)習(xí)實施的,謝謝大佬!

    來自重慶 回復(fù)
    1. 加油

      來自北京 回復(fù)
  20. 學(xué)習(xí)了,感謝大佬分享

    來自廣東 回復(fù)
  21. 寫的很好,學(xué)習(xí)了

    來自廣東 回復(fù)
  22. 真好 棒棒噠

    回復(fù)
  23. 非常有營養(yǎng)的文章,贊贊贊~?。。。?/p>

    來自吉林 回復(fù)
    1. 謝謝鼓勵 ??

      來自北京 回復(fù)