本文作者根據自己的創業經歷，分享了項目管理以及產品版本迭代的相關經驗。
18年3月份，接到一位創業兄弟的邀請，加入團隊負責項目管理流程的規範，他表示：
現有項目的開發流程太亂，項目交付太慢。
剛開始接到這個需求，我的內心是很虛的，只有一年工作經驗的PM Dog，哪有能力搞這麼高大上的東西。
雖然顧慮重重，但想體驗創業快感的我，還是硬著頭皮上了，畢竟，萬一失敗了，虧的又不是我的錢……哈哈（奸詐臉）！
由於該公司紮根的垂直領域圈子太小，為了隱私起見，下文對該公司簡稱為：A公司。
背景
A公司是在某個垂直領域做專業的解決方案供應商，目標客戶群體是大集團企業，項目週期一般是1年左右。
需求調研（用戶訪談)
接手這個團隊的時候，團隊有20來號兄弟，其中市場部主要負責項目的同事有三名，大概瞭解了團隊架構之後，我就詢問市場部同事當前的項目管理流程。
他們是這麼說的：
跟客戶拿需求過來，如果自己無法評估技術的可實現性，就拿回來給研發，實現性沒問題，就做……
然後我又去問了研發，研發的兄弟們是這麼說的：
市場部那邊，老是一句話需求，剩下的自己腦補，真讓人吐血。有的時候，突然就來了個需求，明天就要上線，措不及防又是一頓熬夜趕工，交出一個應付性版本……
最後是技術部的兄弟們，他們是這麼說的：
上線的版本老是不穩定，有的時候還沒有測試就上線了，功能都跑不通，一臉懵逼。產品體驗太差，運維壓力太大，頂不住……
通過一輪的訪談下來，需求的流向看似很健康，由：市場->研發->技術->市場，其實幸虧兄弟們關係鐵，不然早就拔刀相見了。
需求分析
第一、開發流程問題：沒有對客戶的需求進行“反饋式確定”，由開發人員直接做邏輯設計兼開發工作。
比如客戶說，我要做庫存管理。這一句話需求，有可能出現什麼情況呢？
我方：哦，庫存管理，那就做一個臺賬，顯示客戶的庫存，再加個“增查改刪”，OK，搞定。
- 增：有新品種貨物進庫，新增該品種庫存；
- 查：品種太多，我加個查詢框，便於快速找到該品種，查看其庫存；
- 改：庫存數量有誤，需要修改；
- 刪：該品種不做了，刪除掉避免產生信息垃圾。
看似考慮得挺周全，其實還是有可能與客戶的想法有出入的，比如：
- 增：新增品種庫存時需要輸入哪些字段，哪些字段是必填的等等；
- 查：需要對哪些字段進行條件查詢功能；
- 改：哪些字段可以修改，哪些字段不可以修改；
- 刪：在什麼情況下可以刪除，是否需要權限限制等等。
更多的可能有：臺賬是否具有排序功能、臺賬是否需要庫存預警、庫存預警閾值是否可自定義設置等等。
很多細節性的功能就這麼忽略了。
如果你說，我們多替客戶考慮，把我們能想到的功能都做上去，這樣很容易造成開發資源的浪費。
如果做不到位，就會造成返工，客戶對我們不信任，為後續的合作埋下隱患等等。
正確的做法是：
新增原型圖評審環節：
就客戶提出的需求，根據我們的理解及專業性判斷，輸出原型圖，跟客戶一起評審確定。
如果我方對功能的設計有疏忽之處，在原型圖階段就進行修改，直至滿足甲方真正的需求，完成簽字確定，再投入開發。
這樣做的好處是：
- 更好地將客戶的需求還原出來，對比下我們的理解跟客戶的需求是否有偏差。如果出現了偏差或者客戶有需求變更，也只需要修改原型圖，不需要修改代碼，降低修改的成本。
- 客戶充分參與了設計，有了參與感，對後面開發出來的產品，也會比較有認同感，一般就不會有大的改動。畢竟，誰都不願意打自己的臉。
- 將開發人員進行邏輯設計的工作釋放，由產品經理進行設計，再輸出開發文檔，開發人員只需要將文檔語言轉化為系統語言即可。避免出現開發兼設計導致邏輯考慮不足，功能跑不通的情況出現。
這樣就解決了一句話需求研發腦補、返工、功能跑不通、體驗性太差的問題。
第二、項目迭代節奏的問題。
創業公司人少事多且繁瑣雜亂，現在的市場部同事並非純真的項目經理。只是他們把東西賣給客戶了，客戶有什麼訴求，第一個找的肯定是他們。所以慢慢的，他們也就成為了所謂的項目經理。
在這個背景下形成的項目經理，有以下特點：
- 沒有主動深入瞭解客戶的使用情況，只會被動接受客戶提過來的需求。
這個是很多緊急需求的本質來源。沒有站在整個項目的高度上做一些開發的規劃，非得等客戶真正需要用到了，發現沒有這個功能，然後就找到了我們的項目經理，項目經理把需求帶回來，做好了再更新到客戶那邊，事情完結。 - 沒有做一定的項目總結及系統價值的提煉。
在整個項目的跟進過程中，項目經理充當了一個傳話筒的角色，沒有總結，就沒有進步。沒有價值點提煉，就沒有存在感。最後導致我們的客戶，對我們產生的印象是：我們說怎麼樣，你們就做成什麼樣，我們不說，你們也不會站在你們專業的角度來替我們思考。
基於這點，我覺得職責需要明確，所以就以公司的名義發了封正式的公告，任命其為項目經理，對項目負責，需要把控項目的迭代節奏。
這樣也就解決了緊急需求的問題。
協調各方資源，設計（包含了埋點設計）、開發、V1版本上線
基於以上的問題，我就做了以下三點措施：
- 發文任命項目經理；
- 梳理出開發流程，為全員做相關培訓，項目經理主責落地跟進；
- 製作甘特圖，反映我司人員在項目上的具體投入，以瞭解項目的收入成本比。
關於埋點分析，來源於老闆的訴求：大家看起來都很忙，但項目交付太慢，導致回款出問題；
上圖是我之前做產品時的項目管理經歷，就想把它借鑑過來，記錄下項目人員的投入分佈圖。
另外，給新入職產品/項目管理的童鞋一個建議：好好管理產品/項目的迭代歷程，便於自己總結回顧並針對性地提升自己！
產品上線後
產品上線以後，跟進用戶反饋、埋點數據分析，以便更好地進行下個迭代版本的設計，不斷靠近產品的目的。
關於埋點數據的採集，我是讓每個人以日報的形式發給我，我再進行整理，歸納到項目管理表中，最後得到了以下分佈圖：
慢慢的，我覺得不太對勁：我都沒有接到需求，但研發的同事一直在開發的路上。
更加奇怪的是：研發一直在不停的開發，但項目驗收情況依舊不容樂觀。對於一個初創團隊來說，研發是一個比較重的開支，所以必須得搞清楚裡面是什麼原因，達到開源節流的目的。
於是我就梳理了一下記錄，發現很多的工作都是在：修改、修復、優化，而且極其碎片化。
經過深入瞭解，原來都是在補之前的坑。比如之前給客戶做了一個功能，主功能能跑通，但忽略了其他的異常情況，客戶到現在才發現，就得進入緊急修復狀態。
我也回訪了一下各部門的同事，得到以下信息：
- 項目經理：工作量比較大，市場打單已經耗費了我很大精力了，又要跟進項目管理，有點兼顧不過來。有時候跟研發的同事在溝通需求，約好了時間節點，我去忙其他的了，研發的同事就忘了時間節點，導致任務的延期。
- 研發同事：任務太多太雜了，而且總是有新的需求插隊，所以經常會先把那些催得緊的需求先做了，導致其他需求的延期。有些需求沒人催，久而久之也就忘了。
- 技術部的同事：運維佔了我們很大的一部分工作量，又沒有專職的測試，所以只能藉著運維的間隙測一測功能是否能跑通。有的時候客戶催得緊，沒有辦法，來不及測試，只能直接上了。
另外，我發現了研發同事有一個問題：沒有進行版本管理；
個人覺得沒有版本管理，會有以下缺點：
- 增加同事間的溝通成本：研發更新了新版本，負責測試的技術同事沒注意，還在測老版本。
- 開發戰線拉得比較長，團隊成員心理負擔會較大。
- 在客戶面前沒有主動權。如果我們有做版本管理，我們可以說明版本上線的時間節點以及版本更新的內容，給我們自己喘息的時間，也顯得我們有計劃，比較專業。而不是客戶說什麼我們就做什麼，而且是馬上做。
綜上所述，我總結下問題：
- 項目經理精力有限，無法做到項目的有效管理；
- 研發同事忙於補之前沒有項目管理留下來的坑，而且還有很多隱形的坑有待發掘；
- 研發工作比較碎片化，項目迭代沒有節奏，導致需求插隊等，造成有些任務的延期；
- 由於有些bug沒有辦法及時修復，造成運維工作壓力較大，沒有精力測試新上線的版本，從而形成惡性循環；
- 版本管理需要建立。
V1版本上線後
V1版本上線後，通過數據、用戶反饋發現問題，就得設計一個新版本，來解決V1版本出現的問題，我把它定義為V2。
針對以上問題，我做出了以下措施：
1. 協助項目經理組建自己的小團隊，由項目經理一個人主責變為項目經理主責、團隊成員擔責。
之前是項目經理跟研發同事提需求，有時候無法具體到給哪位研發同事提需求，造成溝通成本的浪費及事後推責等問題。
現在我就為每位項目經理都配了一名研發、技術同事，這樣從項目經理、研發、測試、運維整個落地閉環就形成了，形成了N個作戰小部隊。該作戰部隊，由項目經理掌舵，其他成員積極配合，如果該團隊負責的項目出現了問題，項目經理擔擔責，其他團隊成員擔小責。
2. 為了保證需求的流轉記錄，推出項目管理工具：禪道。
之前對於需求的流轉，項目經理疲於督促管理，口頭的流轉存在很大的扯皮隱患，需求的流轉記錄急需立字據。
經過項目管理工具的調研，大家對禪道的應用比較感興趣，所以選擇了禪道作為項目的管理工具，並制定了以下管理流程：
這樣整個需求的流轉清晰了，大家有跡可循，避免信息的溝通失真。
3. 版本的管理
在我們的系統上線【版本日誌】界面，並全員分享版本管理的好處。
V2版本上線，繼續跟進用戶反饋、數據分析
經過V2版本的優化上線，基本解決了以下問題：
1. 項目管理不再是一個人的責任，而是一個團隊的責任，營造了團隊的作戰氛圍；
2. 需求流轉可視化，降低溝通成本，避免信息的傳遞失真；
3. 增強版本管理意識，增加版本迭代日誌，建立自己的迭代節奏。
經過兩個版本的迭代管理，基本解決了項目的管理問題，只留下一個問題暫時沒有辦法解決：填之前項目的坑。
本來想著該問題只能隨著時間的推移慢慢得到根治。
不過隨著時間的推移，我覺得問題，並沒有那麼簡單：來自舊項目上的需求源源不斷，驗收卻遲遲沒有進展，項目款回收比較困難。
經過了解，原來之前籤的項目，需求顆粒度是很粗的，後續進場開發也沒有進行詳細的需求調研、需求確定等，都是跟客戶口頭確定大概要做成什麼樣子，再根據自己的判斷做出來，交付給客戶。
客戶試用，有問題，提，我們改，一直如此的重複。客戶也不會輕易簽字，畢竟一簽字，再開發就需要另外付錢了。
這就造成了之前提到的問題：需求不斷，開發很忙，項目交付卻很慢，而且需求極其碎片化，用戶一會需要加這個字段，一會兒需要新增判斷邏輯等等。
更致命的是，我們的專業性會慢慢的被磨沒，直至客戶說什麼，我們就做什麼，客戶不說，我們也不會主動跟進。
目的地都無法確定在哪裡，漫無目的地走著效率是最低。
我就跟各方同事確定，最後在市場部的同事那裡得到了本質信息：手頭沒有“菜單”，所以客戶要什麼，我們就答應做什麼，項目虧不虧我不管，我們的任務是把項目簽下來就ok。到時候做到什麼樣再去走“商務”，也就是靠關係。
這個讓我大為驚訝， 我覺得我們做生意是平等的，你給我錢，我為您提供服務，必須要把賬算清楚了，而不是靠走後門、刷老臉來驗收項目。
結合用戶調研及需求反饋，設計V3版本
於是我就著手開始製作“菜單”：
- 把系統功能框架羅列出來，標上對應的售價，市場打單用。
- 針對系統功能框架製作一份功能明細，後期進場調研時用。在這份功能明細上做增查改刪，再由甲方簽字，就可以進行後續的原型圖設計、需求確定投入開發了。
這樣就確保我們有了驗收標準，有了依據有了目的地，更好地規劃我們的迭代節奏。
版本迭代日誌
總結一下在整個項目規範流程中的版本迭代日誌
V1：
- 施行項目經理制，責任到人；
- 梳理出開發流程，為全員做相關培訓，項目經理主責落地跟進；
- 製作甘特圖，反映我司人員在項目上的具體投入，以瞭解項目的收入成本比。
V2：
- 組建項目作戰小團隊，主責到人、團隊擔責；
- 藉助項目管理工具，做好需求的流轉記錄；
- 制定版本規範制度，上線【版本日誌】模塊。
V3：
- 上線系統功能清單及報價；
- 上線系統功能明細，確保有驗收標準。
以上三個版本，就是我覺得最有里程碑意義的迭代歷程，它讓項目從需求的來源、落地、驗收整個流轉得以規範。看似簡單，其中也走了不少彎路，希望可以給大家帶來借鑑意義。
本文由 @銘創優品 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議