創業型的網際網路專案，一般需要列半年規劃，半年是一個里程碑，應該已經完成MVP（最小可行性測試）基本上能測試出專案行不行，行的話，這六個月就是從0到1的過程，可以融資做從1到100的過程了。不行的話，就要考慮專案是不是流產了。

太久了，要快速迭代，快速試錯不斷修正產品設計和目標，天下武功唯快不破。等你排期做上半年，產品出來了，可能競爭的產品早就佔領市場了

網際網路功能開發，如果排期在半年左右，基本上象徵意義大於實際意義，但是在實際的開發中確實會出現半年排期這種情況，為什麼出現這種情況呢？

第一：網際網路開發的排期往往按照優先順序進行。優先順序非常高的功能往往是按天（小時）計算排期的，接下來是按照周、月、季度來進行排期。但是嚴格的說，功能本身並不存在輕重緩急的問題，任何需求本身都存在一定的必要性，但是排期靠後的開發內容往往是一種方向性的選擇。

第二：追求功能的結構性。按照實際開發情況來看，不少半年排期的開發基本上都不用開發了，原因在與產品經理可能會對開發進行不斷的迭代，在迭代的過程中，基本上就會把很多排期進行調整，而半年排期的內容本身具備很大的不確定性，被迭代掉也是比較常見的情況。所以，半年排期往往是出於功能的結構完整性方面來考慮。

第三：完善業務邏輯（生態）。對於網際網路產品來說，不少半年排期都是為了追求生態建設的完善性。舉個例子，我帶隊開發了一款線上智慧診療系統，在產品排期上，為了讓整個診療系統有一個完整的生態結構，打造出醫生、患者、第三方服務機構的整體聯動，就排出了一個半年排期計劃，這個排期主要是從生態結構上來考慮。

另外，半年排期也有一些迫不得已的苦衷，比如很多功能的排期本身就存在前後依賴的問題，另外還有團隊自身的因素影響等等。通常情況下，網際網路產品的排期都會預留出一定的時間來處理一些比較棘手的問題，但是實際的處理過程往往與排期還是有一定出入的。

排期是產品經理的一個基本技能，產品排期也考驗著產品經理對產品本身和開發團隊的認知程度。

網際網路這個行業，已經屬於紅海了，競爭激烈達到白熱化階段。

網際網路開發排期半年？排期半個月都已經極限了，知道競爭對手有多少嗎？知道每天有多少同類產品出爐嗎？知道使用者的需求時時刻刻都在變化嗎？

網際網路瞬息萬變，爭分奪秒，如果真要做一個新產品上線，做一個MVP產品去驗證可信性，千萬不要做大而全的產品再去上線驗證，到那個時候已經黃花菜都涼了。