A、相關的背景：在產品規劃完成後，初次文檔，原型，設計評審後，再進行技術評審過關進行立項並開始開發時，產品也會兼併項目經理的職責，進行項目進度的及時把控及跟進解決問題。
B、存在的問題列舉：
（1）沒有統一的項目管理工具，不能及時的把控每個人的進度，需時常人為跟進；
（2）不明確每個人的項目進展，耽誤上線時間的把控；
（3）沒有相關的績效制度，激勵大家去高效率的進行。
C、相關的解決方案：
（1）規範的使用項目軟件，例如：Tapd，Teambition，禪道，Tower，Project，gitlab等；
Tapd項目管理例圖
簡要說明：需求分解式闡述，可以進行實時提醒相關人員進行查閱需求，變更也會有相關的變更提醒，也可上傳相關的附件文檔，生成產品報表等。
Gitlab管理例圖
簡要說明：便攜式的管理需求，並且該工具可方便開發與產品共同使用，規範文檔至相關的看板中，然後拖拽至不同的階段進行跟進，及時查看及提醒變更記錄等。
（2）明確每一個人的職責及所擔負的相關責任；
通過相關的項目管理工具，可以清楚地看到每個人去領取的需求任務及時間節點，很清晰的把控項目進度。
（3）及時解決項目開發中存在的問題及獲取替代解決方案。
目前測試人員多數都在使用產品系統，便於對bug的提交與迴歸。與此同時產品也可使用禪道進行文檔管理，畢竟可使用開源版。
這裡舉一個項目預估週期內的時發的例子及如何應對解決：
當時做一款公寓項目重構時的一個小的需求點的評估。
D、場景模擬
需求方：需要一個可以國內外共同使用的地圖功能。
功能點：
- 可根據postcode及地圖定位查找所在地；
- 可查到定位點周邊的學校，公交，地鐵等信息；
- 可進行路線查找，計算出各種出行方式及路線詳情；
- 需要免費的接口；
- 其他（暫不做詳細介紹）。
競品的地圖樣式
立項前進行需求調研結果：
1. 經過幾個地圖的對比：Google，必應，百度，騰訊，高德的分析比較後，選擇的必應地圖作為受重點，可基本滿足現有需求，接入7.0版本的接口文檔；
2. 參照競品後發現其使用的是Google+mapbox，但是mapbox是基於免費+收費項目的，所以做了備選方案（經目前使用用戶及訴求，免費版暫時可以作為支撐）；
mapbox接口示例圖
兩套方案進行規劃設計，但是在開發途中，發現了必應的接口升級到8.0版本，很多代碼進行了封裝處理，一些需求點不能進行定製or獲取相應的數據源。
在預估開發時間週期內，此異常行為會耽誤很多開發時間。
因此果斷進行方案二的替換，來避免不必要的開發成本及時間週期，最終解決了異常問題。
D：一些項目進度跟進表也很重要：
需要把控各個需求節點的時間，及時跟進一些問題反饋及做出相應解決方案；與此同時在每個需求完成時都需要去確認產出與期望值是否一致。合理分配每一個需求所對應的人員！
E、總結說明：
在項目跟進中總會遇到形形色色的問題，因此把控好以下幾點顯得尤為重要：
- 需求方案評審立項時，需要自我細分去考慮各個可能發生的問題，做出相應的備選方案以備不時之需；
- PM雖然不需完全懂技術，但是基本的邏輯思維，用到的技術手段or相應的開發文檔需要懂得，這樣的話才能更好地提升與開發同學之間的溝通效率；
- 多去溝通了解，實時把控進度，進行周彙總or總結等習慣，來整理項目中存在的問題及為後續迭代或覆盤做準備；
- 也可以熟悉瞭解數據庫相關知識及接口知識，來提升自我及幫助自我更清晰瞭解全流程。
- 時刻保持與開發的溝通跟進，組織早會，週會進程，把控每個時間節點上開發步調的一致性
- 項目時間評估時，確保時間的真實可靠性，與此同時也需要積極參與技術評審會，瞭解一些技術實現邏輯原理
項目跟進途中也需要測試人員及時輸出測試用例，產品需要進行確認無誤，以便後續測試結果輸出一致。
閱讀更多 產品Leon 的文章
