最近文章更新很慢，捋了一下這段時間工作上遇到的問題，以及最終的解決方案，還是把他分享出來吧。

新版上線后，又步入了持續的迭代中，各種需求、產品本身的優化不斷。因為此前公司沒有規范的對接流程，導致運營、產品、設計、開發之間的對接混亂。比如：運營（后臺）需求被不斷延期；產品臨時提需求給設計師；設計師的設計稿出太慢，影響開發進度等。所以，后面思考了整個協作流程，現在這種方式在公司已經推行了1個多月，效果還算不錯。

總的規范如下：

1.固定迭代周期；

每個版本開發周期大致1-2周；

2.提前規劃；

產品至少提前2個版本（1個月左右）規劃好接下來的需求安排；

3.提前完成設計；

設計師至少提前1個版本將審計稿完成；

4.規范小需求的處理；

每個開發周期期間，運營及老板的各項小需求不接，除非非常緊急的需求，否則產品需重新對其進行排期，或移至到下個版本；

5.溝通詳盡。

開發前，需求文檔和設計方案細節需要跟相關設計、技術溝通清楚，并對每項任務估時，推導出測試和發布時間；

大致流程如下：

1.收集需求
2.分析需求
3.提出解決方案
4.同步方案
5.開始開發
6.測試
7.提交上線

1.收集需求；

需求來源：
- 由本身業務需求，延伸的功能需求
- 用戶反饋。平常做用戶調研、運營反饋、后臺意見反饋
- 運營需求
- 產品優化需求；

2.分析需求；

- 需求是否合理。
若合理，則細化方案并排期；若不合理，則說明原因；
- 評估需求優先級和開發難度。
優先級的評估是通過該需求對用戶體驗的影響以及對人群輻射范圍的大??；開發難度需要技術評估。綜合兩項，對需求進行排期。

3.提出解決方案；

- 提前跟技術溝通方案；
確定方案前，對一些比較棘手或成本的需求，同技術一起溝通，尋找最合理的解決方案；
- 提前跟設計師溝通需求；
提前跟設計師溝通頁面需求，盡可能在開發前將設計稿準備好；

注意：最終確定的方案要經過仔細思考，考慮周全，盡可能避免后期再更換需求。

4.同步方案；

- 溝通需求場景、方案細節；
跟相關開發一起溝通方案，并提出可能出現的問題，以及應對措施；
- 對每個功能進行估時；
排期時，要預估最終上線時間。這方面最好的方式是，把需求細化成功能，開發對每個功能進行估時。1天內的需求按小時計算，超過1天則用天計算。

5.開始開發

- 跟蹤進度；
最好每天下班前了解開發進度，掌握最新情況，對特殊狀況提前做好預警；
另外：版本開發期間如果出現了新需求，若非特殊情況，放置到下個版本進行排期開發，

6.測試

- 測試該版本新開發的功能；
- 測試整個產品的核心流程；

7.提交上線

- 測試沒問題后，提交上線；
- 關注新下載用戶的反饋。

調整成這種方式后，最大的效果是：

1.每項需求都有反饋，并能高效處理；
2.團隊協作更融洽，不拖沓，不會浪費資源；；
3.保持版本更有節奏感的迭代。