0.前言
“你無法衡量的東西，就無法有效管理”——管理大師彼得德魯克如是說。一個產品從設計、開發、測試到最后上線，必須有嚴格的規劃，并有相關的標準去衡量它，不然整個項目將會像一盤散沙無法管理。對于一款互聯網產品來說，一個生命周期包含從0到1或者從1到無限優化都要做細致的規劃，毫不夸張的說，一個好的規劃可以讓整個團隊有條不紊的運轉，規劃不合理讓團隊怨聲四起甚至引起項目的正常推進而導致延期。
根據我個人的經驗，我把產品的規劃分為：項目整體規劃和產品的版本迭代規劃。
1.項目整體規劃
項目整體規劃指的是項目從立項到首個版本的規劃，即從0到1的過程。這一過程需要確立整個產品的架構，然后模塊化，再模塊下面進行再一次細分，如下圖所示：
一般來說，一個項目整體上分為如下幾個流程節點：
里程碑：里程碑為一個項目的整體目標，產品達到上線標準的總和。比如一個商場APP，想要達成的目標是：商品展示、搜索、購物車、支付、退貨等一整個購買流程，這些目標的集合構成了這個項目的里程碑。
跟蹤項：跟蹤項是只單個的目標，跟蹤項的集合就是一個里程碑。比如把購物車作為一個跟蹤項。
任務：任務作為跟蹤項的子集，比如購物車作為一個大的模塊，里面包含很多功能模塊，可以把任務當做一個功能模塊。
功能：功能指的是一個個具體的功能，而且必須是可用的功能。比如購物車里面一個刪除商品功能、或者選擇優惠的功能，他們都是一個單獨的功能。做出來的功能必須要是可用的，即要進行功能測試。
整個項目的任務結構大致是這個樣子的，但是必須指出的是，里程碑、跟蹤項、任務、功能必須要有截止時間，而且需要有衡量的標準。比如支付可以作為一個任務，包括貨到付款、微信支付、支付寶支付等第三方支付，可以把微信支付作為功能1，規定完成的時間，完成的時間包含測試時間，衡量的標準就是可用，功能能夠走通。同理，支付寶支付也可按照這一標準執行下去。總之，每個節點對應相應的責任人以及完成的時間節點，加上衡量的標準，這樣就可以按計劃執行下去了。
2.產品版本迭代規劃
一款產品正常上線后，各方面的反饋和業務需要必然會推動著產品向前迭代。我個人總結的一套迭代的流程，如下：
產品的版本迭代需要對各個版本更新的內容以及完成的時間點做出嚴格的規劃，即，在下個版本發布的時間截點需要完成哪些功能。比如目前的版本是v1.0，月底要v2.0上線，v2.0需要更新的內容必然是事先規劃好了的，作為產品經理，在團隊開發2.0的時候，就需要開始規劃3.0的需求或功能了。我一般這樣規劃一個版本的流程：首先確定這個版本需求完成哪些功能或者解決哪些bug；其次，如果是新的需求，先做進行需求分析，根據需求的場景與開發溝通原型及流程，適當的做一些修改，確認后，和UI設計師進行溝通，設計師產出設計稿，然后自己產出需求文檔；最后，規劃好了，接下去就是執行了，關于執行的話，可以把這個版本當成一個里程碑，具體的執行步驟就按照上面說的“整體項目規劃”啦，一切就緒之后，版本就可以發布了。
說個題外話，很慚愧，有時看到其他產品經理寫上厚厚一大摞的需求文檔，佩服的五體投地，我的需求文檔相比之下就顯得有些單薄，我一般就在原型里面做一些注釋，就算是需求文檔了。以前確實寫過那種洋洋灑灑上萬字的文檔，現在覺得原型+注釋+流程圖的文檔會顯得相對簡潔一點，當然，這是個人之見。
3.小結
世上沒有完美的流程，在走流程的過程中，一定會有異常情況發生，這就需要產品經理有能力去處理。比如，在一個版本的規劃完成后，臨時有需求出現，如何處理？這就需要我們對需求進行評估，確定優先級，同時規劃的時候預留一點時間。另外，一個功能在做的時候發現流程走不下去，都是坑，該怎么處理？這絕對是產品經理的鍋，一個功能從用戶操作到完結，所有狀況每個步驟，產品經理一定要實現想清楚，不然會妥妥的把開發帶到坑里。當然，規劃好了，接下來最重要的就是執行了，這里不討論了。
總之，項目的整體規劃外加產品的迭代大體上會讓項目在一個正常的軌道上運行。當然，理想總歸是理想。
