2018-10-14專案執行過程中的一些思考
摘要：
最近的一週，產品開發逐步走向正軌（產品當前處於從0-1的階段），我的工作也抽出一些時間用於專案執行跟蹤，主要包括：
1 專案進度制定和跟進
2 當開發和UI設計人員遇到對需求、原型等不理解的時候，及時解答
3 一些臨時性變更的調整和處理
4 ...
這裡發現幾點原則十分重...
最近的一週，產品開發逐步走向正軌（產品當前處於從0-1的階段），我的工作也抽出一些時間用於專案執行跟蹤，主要包括：
1 專案進度制定和跟進 2 當開發和UI設計人員遇到對需求、原型等不理解的時候，及時解答 3 一些臨時性變更的調整和處理 4 ...
這裡發現幾點原則十分重要：
1 開發提出一些功能可能會花費較多開發時間，希望砍掉或修改設計，我的思考和處理如下：
① 必須確保功能的完整性 ② 必須確保“說的過去”的使用者體驗 ③ 目前是從0-1階段，儘快上線，讓真實使用者見到產品更重要，複雜的功能在與前兩點不衝突時可以砍掉，但要將砍掉的部分記錄到需求池，等到時機成熟再進行迭代 ④ 及時變更產品說明文件和原型設計，並和專案組成員、領導和其它相關部門同步資訊
2 尊重資源
很多公司都是多個產品線並行執行，每個人都會遇到工作衝突，專案排期時應當充分考慮這個客觀現實。我的解決方法是：
① 在制定排期時，乘以一個1.2~1.5安全係數 ② 向領導層提前通報存在的風險，並告知我的處理方案 ③ 將風險和解決方案寫在排期表顯眼的位置
3 時間排期的思考
其實時間排期是根據經驗推算出來的，有經驗的團隊估算的時間往往是靠譜的。但對於新組建的團隊，過去的個人經驗往往會失真。需要經過一段時間的磨合，經過一兩週的實際專案推進速度再估算排期會更加精準。
我的解決方法和產品迭代思維一樣：在團隊磨合過程中，時間排期也會從不成熟逐步迭代到成熟的過程。這個時期，產品經理應該定期與團隊成員溝通排期的變化，更新專案排期表並通報給大家和管理層，就像定期迭代的產品一樣。
4 階段性成果演示
站在公司領導的角度想，從0-1的產品開發時長比一般的迭代週期要長很多，執行過程就像個黑體，中間出現問題很難發現，產品經理不可能及時知情。
我的思考：要有個定期成果演示（比如每週一次），
① 向領導、專案成員、甚至是特約使用者演示，儘量用前端頁面的形式展示 ② 可能頁面尚未完成，如按鈕不能點選，資料是一堆“XXXX”，沒有校驗，但要讓大家看出每週都在進步 ③ 演示前要通報演示的範圍和可能存在“八阿哥”，畢竟這就是半成品 ④ 演示後讓大家提出想法，比如是否符合公司的戰略、使用者體驗、互動意見等方面，這樣及時發現問題，便於產品調整，從而降低風險。提議儘量是開放性的，但要控制時間 ⑤ 將大家的提議記錄到需求池，並根據優先順序決定是走需求變更還是今後迭代