1. 明確分工，知其表亦知其里

做排期之前一定要明確產品開發必須的生產要素，即設計、測試、前端開發、后端開發等。

設計

交互設計與UI設計，當原型圖設計完成后第一時間要和設計溝通并做出相應設計圖，根據以往的UI基調設計出相應的設計圖并交付給前端。UI設計的一致性很重要，在產品之初就要想清楚并定義好，就算后期涉及到某些人事變更，也需要保證UI/UX風格的統一性，或者能夠保證修改后的UI/UX風格一致性地實現落地。不止一次看到一個產品里面的UI/UX風格元素有好幾套，這樣是很傷體驗的，之于這點，做無論是做產品還是設計都要有所考慮。

測試

測試就是保證產品的質量即可用性，通俗而言就是提bug給技術開發，做bug排期，跟進bug以確保至少沒有重大bug以發布當前版本產品。很多人提倡開發自測，這點很不靠譜，就像一個技術如果不丟掉自己技術思維去做產品一樣，做出來的產品刻板可笑，測試思維和技術思維是兩碼事，必須要有一個能夠為產品質量負責的角色。（PS. 如果一個技術擁有測試的思維，那他也可以做自測，問題是這樣的人很少，這也是為什么TDD即測試驅動開發不火的原因，確實是對dev的要求很高?。?/p>

前端開發

包括Android、iOS、Web前端開發等等，即實現view且會涉及到一部分view所包含功能邏輯的角色。關于web前端開發，web app的概念日盛，web開發可做的事情也越來越多，H5大行其道、方興未艾，native app大有被其揚棄之勢，混合開發亦早已是常態。產品經理在設計view時也需要考慮到這些，并且在對具體item定義和設計時關注其可復用性，并且時時刻刻關注產品功能設計的可延展性也要想清楚，在設計和前端開發的合理排期中這點也十分重要。

后端開發

包括架構、數據、接口、后臺管理、（運維）等，后端開發需要搭建web框架以滿足前端web或者app的接口訪問需求以提供數據，合理定義并搭建數據結構以滿足無論是后臺管理還是web框架的CRUD（增刪改查）需求。后端重業務邏輯和數據處理，一方面后端開發要對前端產品的接口可用性負責，而在數據和業務方面，則無論是在數據挖掘、爬蟲、數據匹配推薦、搜索、標簽系統、anti-spam等方面都可能有所涉獵。這些的大前提都是在產品提供一個合理的產品結構和業務需求的基礎上實現的。如果是技術出身的產品經理，最好能把產品數據結構圖實現，如果不是那也需要盡力去配合后端開發并與之在此處達成一致以保證對后端整體數據有一個清晰的脈絡認識。對數據有感知的產品經理必然會反過來加深其對業務的剖析和理解，并優化其對產品業務需求的整體把控。

2. 別讓測試等著開發，也別讓開發等著測試

提倡邊做邊測，在合理的功能模塊（開發需求模塊）劃分的粒度內進行做完就測、測完就改、然后再回歸繼而再反復，這樣的好處有以下：

1. 開發者本身對代碼的熟悉度一定是隨著時長而減弱的，能夠快速地反饋問題并處理問題，其在效率上的表現一定是更好的且具備一定的連貫性；
2. 質量把控是一個長期持續的過程，是一個發現問題、解決和優化的過程，保證這個過程的動態可持續性（彈性）也要求需要邊做邊測而不是等開發完成；
3. 測試是劃分單元進行的，在某種程度上也可以驗證當前迭代排期的合理性，以完善優化整體排期。

3. 串行和并行：合理的穿針引線

正如上文提到的：別讓測試等著開發，也別讓開發等著測試。合理的排期一定是串行和并行任務合理交織安排的，串行即人與人之間的協作以一個人完成交付物后交付給另一個人就方可可執行的；并行即人與人之間互不干擾就可以執行的。

常見串行：

1. UI交付：當UI完成設計圖后前端實現；
2. 功能測試：一個功能模塊開發完交付給測試（無論前端后端）；
3. bug提交：測提交bug并交付給開發解bug；
4. 接口交付：（不提倡假接口），真實的接口準備好之后做相應的功能開發；
5. 數據訪問： 數據庫表結構創建、數據訪問層等搭建完成，可CURD，進行后臺管理和接口的開發；

等等…

所有串行之外的任務都是可并行的。

首先要考慮功能閉環或者模塊的完整性，這樣提供給測試形成一個開發測試質量ok的周期閉環，其次要在后臺能夠保證提供前端可用接口的基礎上進行前后端并行，依據這些原則進行view的實現即UI/UX的設計和實現落地。（這也是我目前的做法，可能每個人的做法各有不同，因人而異，僅代表個人觀點）

總之，我認為排期要遵循：

“串行優先滿足，并行合理安排，最終要交付一個需求開發完成的可用的產品！”

4. 不確定性始終存在：小步快跑！

曾讀《反脆弱》，記憶深刻，不確定性的環境會帶來的進步巨大且不可忽略，不要過分強調預測和長遠規劃。一個好產品的誕生也是如此，必然也是在不確定性中生存發育成長出來的。這個不確定性來自于人、環境等等要素，不斷收集這些要素，產品經理要保持一定的敏銳度，合理調整產品排期和需求以滿足產品以及各位參與的小伙伴和它最終要達到的目標。

關注合理的分模塊的排期，按照串行并行的原則合理排期，并且定好目標，在動態中調整，確保每個小伙伴對自己現在要做的、馬上要做的和要做到什么結果，目標是什么要很清晰。產品經理在排期過程中一定要肩負起“讓大家明白”這個角色，排期一定不是一勞永逸的，其講求動態發展和進步，在不確定性中小步快跑?。▽τ趂eature的priority的排序也是類似的道理）

5. 明確產品經理的定位，再來說說高效運轉

很多時候，產品經理都會在如何協調資源、RD不大配合、為什么遭受質疑等等問題上的犯嘀咕，其實有可能還是對之間的定位不夠清晰或者產品規劃本身存在問題。（或許也有可能是自己low，要好好思考如何提高自己。我有個口頭禪“just 干！”，別想那么多有的沒的，發現問題就特么想辦法解決它！就是干?。?。

產品經理必須要明確自己的定位?。ɑ舅刭|哪些就不談了，比如溝通能力、同理性等等的）

產品經理必須要明確自己的定位！產品經理必須要明確自己的定位?。ㄖ厥氯?/p>

1. 需求創建者：需求的調研與創建（對業務的理解、對運營的理解等）、繼而輸出原型圖；
2. 資源調度協調者：合理的對資源的調度和安排，不要出現因為需求和規劃不合理導致的效率低下、資源浪費以及返工的現象；
3. 任務管理者：task的大管家，合理安排任務以及排期，通過洽淡個的協作方式，比如用project、omniplan或者一些在線協作工具，保證每個人對于任務的時間性和產品整體進度的感知；
4. 對產品負責的角色：很多產品經理缺乏對產品的責任心注定無法level up或者眼界被局限，有時候就是靠那股心氣兒；
5. 傾聽者和思考者：多聽聽大家的意見和想法并多思考，始終保持和大家想法上的同步，確保能夠達成一致，這很重要。

等等…

通過以上建立大家對產品經理的信任，信任感這件事情非常重要，體會一下，不贅述。其中資源調度協調和任務管理很大程度上就取決于：

合理的排期以及合理地安排每個角色在合理的時間完成合理的事情，在某種程度上群策群力地高效運轉并完成。高效是對于企業成本的考量，合理的排期則是對產品能夠順利交付的保證，產品經理必須體會到這些，理解其并使自己不斷level up。

6. 產品經理應該是精英：少即是多

說點關于關于產品經理的想法：

產品經理應該盡可能少，我一直這么覺得。

產品經理一定不是想想idea、調調研、琢磨琢磨需求這么簡單（要知道人人都是產品經理，非得產品經理想idea嘛，能不能學會調動大家思考的積極性？），或者以梳理業務邏輯、需求的調研等等任務量太大需要很多產品經理，純粹扯淡！產品經理不夠自信要以量取勝？其實坦白講，我做過好幾款產品，從需求到原型到落地排期到最后開發出來，包括我現在在做的也是，大部分時間就我1個產品經理即我自己，在2、3個月內一個產品就最終實現出來了，而且功能不弱于很多4、5個甚至更多產品經理團隊做出來的產品，這個問題值得深思。

最好產品經理和技術的比例是1：6~8；

產品經理和運營的比例是1：5左右。

這個并不是我一個人的觀點，正如快刀青衣在《請開掉一半的產品經理??！》表達的，請開掉多余的產品經理吧。如果作為產品經理看看自己所處的team如果不是這樣的配比，那自己的成長速度夠嗎？或者自己做的足夠多嗎？（這一點對創業公司尤為重要）如果真的要招產品，那通過產品專員或者產品實習生搞定的事情，就不要招多余的產品經理！

產品經理對自己的要求應該是精英式的，多學習、多了解其他人的角色，多了解自己能做的事情，以及多看到自己做的事情的不足。

一個好的產品不僅僅就是找一個做過類似產品的或者同行業中做產品的人就能做出來的，他攜帶的只是基于以前舊有的靜態的知識，在不確定性的環境中，我只講反脆弱能力，即動態不確定性環境中進步的能力！產品經理需要成為精英，也必須對自己高要求，要獨當多面。未來的產品經理門檻必然會越來越高，學習多多益善，并理解少即是多。

以上即我個人對于排期和產品經理的一些拙見，基本上是個人的所識所感，整理成文字并分享予諸君，望與切磋交流，學習進步。

本文由人人都是產品經理專欄作家 @王懿Lucien（微信公眾號：jishugou） 原創發布于人人都是產品經理?。未經許可，禁止轉載。