search
你是產品經理,也負責項目管理

你是產品經理,也負責項目管理

如今的大部分互聯網公司,是不怎麼區分產品經理和項目管理經理了。也難怪,它們的工作職責中是有很多重合的部分,因此,往往產品經理也會擔著項目管理的活兒。今兒,咱們就聊一聊項目管理的那些事兒。

你是產品經理

也負責項目管理

天天各種問題都要經歷

前腳方案被斃

接著開發就延期

新版上線實屬不易

即使這樣

踉踉蹌蹌

產品經理依然不一樣

我希望你

鬥志昂揚

仔細閱讀這篇文章

相信項目管理不會再成為你的弱項

運營mm:「老王,你看這個需求這一期能不能給俺加上啊,你要這期給俺做的話,我就答應跟你去看電影」

我:」嗯,別慌,容我考慮一下!」

運營gg:「小王啊,這期這個需求一定要給我加上啊,這都拖了快半年了,啥時候是個頭啊」

我:」急啥,下期一定給你加,這期的話,是不行了」

當然,作為一個鐵面無私的產品經理,一定是本著對需求負責的態度,那麼,對於這些來源於不同部門,像是一團散沙的需求,如何去整理歸類呢。

需求池的建立

需求這東西,就好比是一條條小魚,平時你不管它的時候,它活蹦亂跳,真正想去找它的時候,卻發現它消失的無影無蹤。既然這樣,我乾脆就把它們圈養起來。什麼時候想吃烤魚了,撈出一條就直接烤了吃,方便快捷。

說起需求池,就不得不說一下需求的來源。一般分為3類:

運營需求

運營部門是銜接產品和用戶的橋樑,有時候再細一點會分為用戶運營和產品運營。運營在和用戶溝通的過程中,會直接的成為用戶的吐槽目標。用戶說:「你們這個功能怎麼用啊?」運營mm:「你好,這個功能balabalabala」,在這個過程中,運營mm知道了用戶覺得這個功能不好用。但往往產品經理卻很難有精力注意到類似的對話。很多這樣的功能改進意見,第一發現者是運營。那麼運營便會將該需求提給產品,由產品對該需求進行管理、評定、實現等工作。

戰略需求

戰略需求,說白了就是BOSS提出的戰略層面的需求。這部分需求,作為產品經理,當然可以質疑其合理性,但往往需要堅定不移的去執行。也許,從產品層面上思考,這並不是一個合理需求。但老大思考問題的高度,可能會從各方面去權衡。「小孩才分對錯,大人只看利弊」。就像最近很火的人工智慧音箱,各大廠商,都開始著手布置自家的人工智慧產品,與其說是新需求,不如說是戰略性的防禦。你不做,別人便會做,到時候侵佔的是本屬於你的市場份額。大到產品,小到功能。往往BOSS提出的要求,都需要產品經理站在更高的角度去俯視這樣一個需求。

迭代需求

回歸自我,作為一名產品經理,應有著自己的迭代節奏,在 什麼階段,出什麼需求,做什麼功能。每次迭代更新的目標究竟是什麼,都應有著清晰的規劃。比如前期,產品不完善,體驗不佳,應本著「小步快跑」的節奏,迭代頻繁一些,讓整個產品在每一次的更新中,都有著最直觀的改進。而到了有一定用戶量,活躍度的情況。就應該想著如何去維持現有的活躍,是否要搭建用戶激勵體系,去提高當前用戶的活躍度。是否要構建內容型社區,來充實整個產品的UGC氛圍。這些都是在產品不同階段需要去規劃的需求方向。

這麼多需求,如果來一條,想一條,一會就都亂掉了。最好的辦法是把他們歸納在一起。根據版本迭代的節奏,去決定哪些需求,在什麼時候去實現。用一個簡單的Excel表格,將每一項都填寫完整,區分該需求屬於優化部分還是新功能部分,然後通過顏色去區分當前的進度。綠色代表已實現,灰色代表被擱置,藍色代表正在開發。簡潔易懂,清晰明了。每次新版本規劃時即可從這個需求池裡提取需求。

項目進度的把控

還記得校招時,群面環節有一個角色叫做Timer,負責計時間,把控進度的。當時並不理解這個角色的意義所在。但在實際工作中,才發現能讓一切進度按規劃順利進行很不簡單。

由於一個項目往往牽扯到多個部門的協作,因此整個項目進行下來,極其依賴於各個部門之間的配合。就拿現在大部分互聯網公司的項目流程來說吧。一個需求或項目從立項到完成,往往需要產品、設計、開發(前、後端)、測試配合。

可以看出,在項目的不同階段,產品經理都有著不同的工作目標。而每個階段的時間節點,也是由產品經理去把控。這就要求了產品經理對時間管理有著極其嚴格的要求,否則很容易出現項目delay的情況。

(1)第一次評審

每一次項目立項,產品經理在準備充足的前提下,需要主動召集相關人員去針對此項目進行討論。基於產品經理已出方案的情況下,每個部門都應有種參與感,對其方案進行評定,站在技術角度上,站在視覺角度上,站在運營角度上,這樣子產品經理才可以綜合各方面去評定該方案的合理性。這便是第一次需求評審的目標。

(2)調整期

最終結果應是產品經理去做調整,而設計應根據已有結果的原型圖,去重新設計最終的效果圖,值得注意的是,在這個過程中,產品經理應減少對視覺效果的干預,並不是說不注重細節,而是應將精力重點放在功能層面,各司其職。與此同時,開發也有著手準備開發方案,以此來確認開發排期。

(3)第二次評審

應不再對功能層面上進行討論與修改。基於最終的效果圖,針對各種細節進行討論與確認,避免需求不明確的坑。開發也需要確認實現方式及技術方案,並給出產品經理開發周期。這樣最終在需求層面上,產品經理和各個部門達成一致,並對整個項目開發時間和測試時間掌握詳細的排期情況。正式進入開發階段。

(4)開發階段

最容易出現問題的就是開發階段,錯誤評估開發難度、開發結果與實際出入很大。這些問題均會產生一系列連鎖反應,可能導致測試階段無法正常進行,或導致項目Delay。但這並不是說一定都是開發的責任,產品經理也要承擔一定責任。可能由於產品的需求不明確,或漏掉了效果圖上的交互細節。

因此,基於以上的問題所在,產品經理需要定期去了解項目開發進度,把控開發時間。

比如說,開發說可能要延期,那產品經理需要知道延期的原因。到底是開發評估時間過少還是中間有新的需求插入。如評估時間過少,要了解是什麼原因導致的,是開發前期疏忽漏掉了一些功能的工作量還是其他什麼原因。如是新需求插入,則需由產品評估需求的優先順序。在此過程中,要有合理的掌握度,既不能對項目進度完全不知,又不能頻繁的去問開發,以免因打斷開發思考而被打。最好是在項目開發中間階段,抽時間和開發開個項目進度會,了解一下當前進度,並對開發階段遇到的問題進行引導、解決。

(5)測試階段

請一定在提測前,先自測一遍,這應是產品經理的基本素養。如果連最基本的功能都沒有完成,那其實根本沒有達到提測的要求,因此,在測試進行全面測試前,先將本次的需求點自測一遍,這樣可以最大限度的將測試時間花在更多的細節上。在測試階段時,產品經理應抽出一定精力去著手下一個版本的需求整理了,因為如果遵循「小步快跑」的節奏的話,基本測試結束,也就意味著下一版本的開發正式開始了。

整個項目流程中,每個參與人員,都沒有完全的空閑時間。而產品經理,是將他們穿織成一條線,又繞成一個循環圓的角色。

寫到這裡,基本也就是我在項目管理中遇到問題的總結,不同公司、不同項目的流程可能會存在一些差異,但產品經理要有一套自己的流程標準。這樣才能更有序的去管理項目。

#專欄作家#

王偉華,(learnerwwh),一隻略帶文藝情懷的產品汪,擅長社交,資訊領域產品,心理學愛好者,目前正處於知識體系搭建階段。

本文原創發佈於人人都是產品經理,未經許可,不得轉載。

熱門推薦

本文由 一點資訊 提供 原文連結

一點資訊
寫了5860316篇文章,獲得23305次喜歡
留言回覆
回覆
精彩推薦