每天都在接業務需求，涉及部門多的，時間較長的要立項，以項目管理的方式去執行。

每個人都會參與其中，或作為項目組成員，或作為項目組長、或作為項目經理，職責不同，工作不同，但是目標應該都是相同的，就是項目最后成功上線。

互聯網電商的項目和傳統企業的項目有何不同，應該如何去更好的管理，一直是我們急需解決的。

電商行業的特點就是快！

市場變化快、業務方向變化快、項目版本迭代快、組織結構調整快、競爭對手跑的快、技術更新快……

在這樣的環境與氛圍中，如何更好的完成項目需求，對于我們都是挑戰。

幾天前，找幾位前同事簡單了解了下不同公司在項目上是如何協作的發現，其實對于大多數公司都在傳統管理項目方式上進行改變，根據公司的特點也在不斷的尋求變化。

1.嘗試敏捷項目管理，在產品研發團隊推行，定期進行跟進成果。

2.以類似事件管理的工單方式跟進項目需求，定期跟進進展，如果有延時或風險會需要其上級領導匯報，層層升級與績效關系很大。

3.從0到1的項目一般在要求1~3月內完成（需求、技術、測試、上線、維護），然后每1~2周進行功能迭代。

4.重要項目進行立項，嚴格按照項目管理章程進行，設置不同階段的里程碑，定期舉行項目例會進行匯報，對進度、風險、成本進行評估（典型的傳統項目管理）；在各小項目里各團隊會采取不同的管理方式。

……

無論現在按傳統方式管理或敏捷思想、還是以OKR為導向的目標管理，對于產品研發團隊影響和幫助有多少？

不敢做過多的評價，因為大的復雜的項目沒有參與太多，個人雖然比較傾向“項目經理負責制”的方式，但根據實踐因各種原因，結果卻不理想。

電商公司是否需要設立PMO（項目管理委員會），是以項目經理（PM）還是以產品經理（PM）為主呢？

Project Manager：在大型項目和傳統的系統集成性型公司都是非常重要的且不可或缺的。

Product Manage：是隨著互聯網行業而興起的，有從由項目經理轉型的，有從業務、研發等不同行業人員轉型的。

其實無論是PM還是PM，都只是一個角色而已，只要能快速適應公司的發展，啥方式不重要，結果才是最重要的。

項目和產品的定義

項目是為創造獨特的產品、服務或成果而進行的臨時性工作，它有開始有結束，是有生命周期的（PMBOK）

產品是指能夠供給市場，被人們使用和消費，并能滿足人們某種需求的任何東西，包括有形的物品、無形的服務、組織、觀念或它們的組合，互聯網電商中可以是一款APP、一個數據分析的軟件、倉儲軟件，也可以是咨詢服務等。

個人理解，項目是為產品的實現而實施的一套管理辦法，產品/研發經理都可以成為項目經理，公司可以根據實際情況不設置項目經理崗位，但應該建立虛擬的項目組織，著力培養一些有潛力的產品、研發去擔當項目經理，運用項目管理的方式去推進每一個需求、每一個產品的開發上線。

當產品上線后，經過短暫的維護期，要交回給負責系統產品的研發與產品經理進行后期的規劃與迭代，以延長產品的生命期。

一般的公司都是以業務結構為基礎進行組織劃分，同時產品技術部也會根據其業務分成多個小組，如購物流程、倉儲物流、線下門店、OMS、POP平臺、供應鏈、財務等，而且都會有專門的產品和研發團隊負責。這種劃分在項目管理中屬于職能型團隊，學習過項目管理或讀過相關書籍的同學應該都知道，矩陣型的團隊是比較好的，目前這種在外包公司、專用軟件開發公司比較常見。

互聯網電商仍然是業務驅動技術的，所以以職能團隊為主，矩陣項目為輔的方式；可以想像一下自己所在的公司是什么樣的？

其實工作這么多年，參與過很多項目，個人覺得項目需求管理的形式有千千萬，應該以最終結果為評價標準，其它為輔的方式進行。

人、流程、環境

下面主要說下我對項目需求管理的簡單理解，主要是三部分人和流程，其次是環境。

人：沒有人做啥，所以要有人，而且要有優秀的人。

1.對于產品技術而言，產品總監與技術總監就是項目需求負責人，他（她）們需要對產品、項目、系統負責，否則就慘了。他們站在高一層級來統籌安排與業務部門協調，是影響公司運營的和戰略的關鍵人員，他（她）們就可以做為虛擬的PMO組織存在，可以同召集幾個業務或技術專家，但人不易過多，以5~6個人為佳。

2.項目經理：可以以虛擬項目形式存在，即需要時由PMO根據項目大小、涉及的部門多少、業務的復雜度來指定。

注意，這里僅是指產品、技術團隊等獨立的部門，在整個項目中屬于小項目經理，不是負責其它業務部門的所有進度、風險、范圍等。

作為項目經理他可以同時承擔產品的設計、也可是負責具體的研發工作，但主要的責任是協調產品、技術各團隊，把控進度、及時發現項目風險，對項目的成功與否負責。

同時擔任此職位的人，在KPI考核中要有相應的獎勵與懲罰，這樣才能促進人的積極性，也能促進個人不斷的學習進步。

3.項目團隊成員：按目前相關公司的組織來看可以分為幾部分

A.產品經理，在現在的互聯網電商中的地位不言而預，是需求項目成功的關鍵人員，是技術與業務溝通的橋梁。

需要用產品思維去思考、去規劃系統；以用戶的心態去理解業務；絕不是為了完成工作而完成。在人人都是產品經理網站上看到一篇文章，說產品經理有四個階段：功能設計階段、產品設計、業務設計及模式設計；感興趣的可以去讀一下《產品經理成長的4個階段》。

B.主要系統模塊的開發人員：要有一定的技術能力，同時對于涉及的相關業務較熟悉；可以帶領人員進行相關設計、技術選項等，可以合理的安排任務。

研發同學強的是技術，都希望成為技術大牛，一般都不愿意擔任太多的瑣事，在相關會議上扯來扯去遠不如寫段代碼帶來的快感與滿足。

未來應該還是業務驅動技術發展的，業務架構師是牛逼的人才，大家應該向這個方向發展，除非你技術真牛，往技術架構師上發展；選擇好就勇往直前吧，兄弟！

C.測試負責人：是質量的保障師，是上線前的最后一道保險，這里需要她（他）們對業務特熟，對需求理解特別深刻；對原則問題特別認真，而且最重要的還是要有耐心。

D.研發、測試成員：涉及改動的系統或模塊的參與人，也是工作量最多的同事，是項目進度的直接干系人，是導致需求變更的關鍵節……，太重要了。

E.運維、數據、安全、架構：這部分技術同事一般都會涉及每個項目，是上線后系統穩定運行的保障，是出現問題最先介入的人。

運維是最常打交道的人，服務器的申請、部署、CDN、負載、網絡等等

DBA是指導項目實施中建庫、建表、索引等工作，是數據直接的維護者，他（她）與運維也會頻繁的溝通。

架構、安全對具體項目參與不多，主要是涉及技術選項、安全風險時要進行參與討論，給出合理的有效的建議和可落地的方案，注意這里強調落地，即可實施的，在項目開發過程中學習成本要低。

流程：沒有規矩，不成方圓，流程是指導項目一步步走向成功的階石。

一、遵循主流程，結合現下的不同項目管理模式進行改進。

主流程共計7個 階段：啟動、需求、分析設計、編碼、測試、上線、總結。

1.啟動階段

在此期間，主要是進行需求的調研與相關風險評估，以及項目范圍的確定，遵循”產品項目需求流程規范”，在項目中需要參照相關信息的填寫與維護。

2.需求階段

產品同事出具PRD文檔，研發同事確定相關負責人及項目需求參與人員；目前此過程是一個多次的反復過程。

PRD文檔的質量是最評審階段最耗時的，要及時分享，補充修正是家常便飯，如果項目工期緊，要懂得取舍，不要眉毛胡子一把抓。

3.分析設計階段

此部分主要是研發同事需要進行的，包括分析與設計、設計評審并給出詳細的任務計劃與排期，如果發生變更請填寫需求變更表格。

注：詳細任務計劃與排期，不僅要包括系統的研發任務，還需要包括測試準備計劃與時間、權限資源的申請與開通計劃與時間、數據初始化等

4.編碼階段

此階段是研發人員的主要工作,開發過程要嚴格按主流程進行，涉及到相關規范與文檔如下：

開發過程中要遵守開發手冊與編碼規范，由于使用不同的開發工具所以編碼規范可能會略有不同，但是在技術內部要統一，項目命名、函數命名、代碼縮進、單元測試用例的編寫等等。

源碼管理要遵守GIT或SVN等源代碼管理工具的標準，每個人使用習慣不同，但在此部分要嚴格執行流程。不能隨意的創建分支、隨意的提交代碼到master庫、分支何時合并到主干，由誰來合并，合并前代碼是否Review了需要大家共同遵守。

目前在實際工作中，由于業務需求眾多、每個團隊都可能在進行著幾個項目，項目需求上線時間也不同，這樣對于研發同學產生很大的難度（相同模塊代碼可能幾個項目都涉及更改）；此時就需要項目經理、產品經理和研發負責人來介入了，如何減少沖突是需要方法或個人魅力的。

開發任務與問題管理，要使用統一的管理平臺，如Jira等比較成熟的軟件。

此部分對于項目經理來說，不僅要應用項目管理平臺，也應該利用Project工具做些處理，要關注關健路徑上的任務，掌握進度及影響。

注：編碼期間要進行單元測試及接口聯調，在提交測試組前要進行聯調測試保證整體流程是通的，對于代碼的審核要在合并代碼時或不定期的抽查進行。

單元測試是每個研發同事都必須要做的，這可以作為代碼Review的一部分。

接口聯調的時間往往被大家輕視，實踐證明此部分工作經常是最耗時的階段，也是最不確定的，表現在以下幾個方面：

A.接口在定義時，涉及的雙方并未能夠明確接口的方式、參數、返回值等細節

B.需求業務發生變更，沒有及時通知，你提供的并不是對方想要的。

此部分可以充分利用wiki等來進行信息的共享，加強溝通，一旦確定要以正式的郵件或文檔為準，不要在項目微信或釘釘群里討論這關鍵信息，很容易刷屏。

我曾需到過很多次因聯調時因不滿足互相扯皮的事件，不要以為平時大家時兄弟就降低了要求，工作與感情要分開。

5.測試階段

測試是保證產品質量的不可或缺的重要環節，首先研發人員要按時、按要求進行提測，同時在系統BUG的解決過程中要嚴格遵循測試要求并及時處理。

原則：

當日的問題及BUG要當日處理完成，如果有問題要與相關人員進行溝通，影響嚴重的要升級，絕對不能私下解決。

測試過程中出現開發的系統與需求PRD不符的，要及時與產品、測試及相關負責人進行溝通，同時要確定解決方案

在此階段，測試人員與研發人員是死對頭，這時要互相理解，都是工具不要人身攻擊，也不可意氣用事，家和萬事不興，這句話也同樣適用于項目組。

待項目結束時，回顧這些磕磕碰碰，回顧經歷的事情，才發現成長的路上需要這些，有了這些才成熟，遇事才更穩重。

6.上線階段

上線是項目的一個重要里程碑，上線的成功與否非常重要，所以上線計劃及回滾預案是此環節必不可少的。

上線前需要制定上線任務計劃表，同時要制定回滾的策略，如果存在風險在上線郵件中要聲明，同時項目經理要組織會議進行討論，風險的控制是貫穿于項目始終的；生產環境無小事。

A.上線期間嚴格遵守相關規定時行，嚴格按上線計劃進行每一步驟的操作。

B.上線期間有需求變更，注意風險的評估

C.上線期間任何問題都要詳細記錄，同時關于測試數據與相關規范參見“測試任務流程規范”流程

D.上線日志交接（關鍵問題與遺留工作的交接）

在上線期間，最怕的是臨時修改代碼，這就是悲劇的開始，多少個不眠夜里，一群人圍著一個人在修改代碼，想想……確實挺怕的。

最后強調一下：測試階段的數據準備與回收，涉及到生產環境的要檢查、檢查再檢查；審核、審核再審核。

7.跟進總結階段

上線后，需要繼續跟進生產環境的數據與系統的功能是否正常，產品、研發等相關人員都要關注，對于重要數據要進行監控。

主要三部分：系統功能及接口的穩定性、關鍵數據的監控與預警、產品運營效果及數據分析

在此階段最好能夠將涉及的項目組成員召集到一起，做個PPT，展時一些數據，如關鍵服務接口的調用次數與響應時間、上線后帶來的用戶數、訂單數以及業務的回饋。這樣能夠讓參與的項目成員有成就感。

對于遺留問題的分配、要做到有人跟進處理，不能上完線了人就散了，過去的問題也隨之灰飛煙滅。

此時公司或部門能夠有項目獎金就更好了，可以組織成員吃一頓，互相嘮嘮，這時的溝通效果絕對比大規模的團建效果要好。

有的公司沒有經費，是由項目經理或負責人個人組織的這種聚餐，隨著消費的升級，人少還好，人多真TMD的承擔不起；如果看到此文章的管理人員，希望你為你的團隊去爭取一下吧，畢竟公司的成長是需要各個團隊努力付出，好的氛圍是項目成功的一個基本前提。

環境：工作環境好壞也會間接影響項目的成敗。

舉個例子，目前大家都會去外面就餐，你喜歡有點檔次的舒適環境，還是小吃店那種喧鬧的環境。

工作環境也是很重要的，要讓產品、技術的人有一個相對好點的環境，我個人比較想要的是這樣的環境

1.燈光要亮一點，衛生要整潔一點，有陽光才有快樂，每天寫代碼就夠累的了，討論需求、設計，爭論接口邏輯都會影響心情，一個相對寬敞的環境會讓你舒服一點；好的辦公樓租金不菲，但是無論在哪，安點大燈泡子費不了多少錢。

2.要有多一點的會議室，多一點的白板。

這是我這么多年工作最在意的，會議室其實是使用頻率最高的地方，需求評審、技術評審、討論方案、項目例會等等都需要有個地方；團隊里、項目組總得開個會總結，總利有些內部的話要講吧，如果沒有地方，那么對溝通的質量是有嚴重影響的。

討論過程中總要記錄一些東西，白板的重要性相信每個人都清楚，隨手拿起筆，隨時記錄畫下來，是討論過程中最簡單有效的溝通方式。

如果連這些基本的條件都滿足不了，項目執行過程中就需要克服，溝通質量適必下降，適必會額外增加一些時間。

我曾經在一家賣美妝的互聯網公司工作過一段時間，充分感受到了互聯網的氛圍，辦公區有很多會議室，隨處都有玻璃墻、有筆可以讓你在那討論；高管有很多都沒有辦公室，就是為了增加員工開會的空間，人的狀態飽滿，真的挺懷念。

3.電話、視頻會議的重要性。

異地辦公不可避免，所以電話、視頻會議是項目執行過程中不可或缺的過程?，F在釘釘辦公是非常有效的企業辦公軟件，大家可以嘗試。

總結

人是環境、流程指導、環境輔助，這就是我目前對項目管理的理解。這里沒有過多的說敏捷項目管理（因為我也沒有什么實踐不敢亂說），但是我們可以嘗試著去用這種方式在項目執行過程中引用，譬如在需求收集階段我們可以采用用戶故事的方式來引導業務、來提高我們的需求質量；在開發過程中可以充分利用卡片或軟件看板來展示當前的任務，標注出哪些在待開發，哪些在開發中，哪些在已完成，充分了解當前任務進度；每在可以利用幾分鐘的站會來討論問題，以便提前解決問題，控制風險。

無論怎樣，我們無論在大項目，還是小需求上都應該按項目管理的方式進行，可以簡化一些流程，但不能無腦的去改變，基準線和原則還是要把握的，有很多朋友在考PMP或項目管理師，網絡上也有敏捷項目管理的課程，取長補短互相借鑒總是好的， 最后感謝您的閱讀！

作者：倔強的大蘿卜
鏈接：https://www.jianshu.com/p/5460ebaade9a
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。