太多的產品新人，甚至于工作1兩年的產品汪，在開發階段往往出現很多對接問題，影響上線進度。在此，我將程序開發階段總結為一下4個流程，并會用故事的形式，分流程介紹我們該如何與開發對接。因內容較多，且需要與實際工作結合進行考慮，所以建議大家收藏下來，慢慢看。

下圖為此系列內容的大綱

（此系列內容的大綱）

今天我們聊聊第2部分，制定開發流程與關鍵節點。如果沒有看過第1篇文章的，請點擊下面的傳送門：《小明與老王的日常：學會做這4件事，讓你的產品提前上線（1）》

第二天，小明按照老王的吩咐，召集了技術部的同事們進行了項目評估會議，會議中，小明從項目背景介紹、功能流程介紹、關鍵目標確定三個方面，向程序猿們描述了接下來要開發的產品。會后，老王將小明叫到了會議室，習慣性的點了一根煙，深吸了一口說道：小明，還不錯，該講清楚的都講清楚了，就是在講的時候，需要再自信點。你要對自己的產品有自信，別人才會認可你的產品。您說是吧。

小明：嗯，都是王總教的好，以后我會記住的。對了王總，那接下來我該做什么呢？

老王：別急，這次叫你過來，就是跟你說接下來的事情的。開會前，你是不是把產品原型、產品說明文檔、設計稿、交互稿都交給程序猿了？

小明：嗯，是的，都發給他們了。

老王：好，那接下來，你需要做的就是協調項目經理、程序猿們一起確定項目的工作量、開發順序與關鍵節點。當然了，我們公司沒有專職的項目經理，這個你可以直接找孫總。（孫總是公司的技術總監）

確定項目開發工作量

老王抽了口煙，繼續說道：首先呢，你先去找項目經理溝通一下，看項目經理能否在近期（一周左右）對項目的開發量進行一個評估。至于這個評估時間，你不要卡的太死，給他們充足的時間去仔細研究。這個階段是程序猿了解需求的時候，我們需要給他們充足的時間去研究需求，只有需求研究透了，才不會出那么多bug嘛。

老王：那在這個階段，你可能會遇到下面這幾種種情況：

1. 程序猿需要你幫忙解釋需求。
2. 程序猿給產品提修改建議。
3. 程序猿要求砍掉部分需求。
4. 提交的PRD、設計稿、交互稿缺少部分內容。
5. 反饋回來的工作量評估表很粗糙。

小明：王總，上面這幾種種情況，第4個我會處理，缺少的內容我回去找一下，看看是不是我提交的時候遺漏了，如果確實是沒有做的話，到時候再從新做一下，補給他們就好了。那剩下的幾個問題呢？通常我們都是怎么處理的？

老王：別急，讓我慢慢跟你說。這第1個問題呢，是我們肯定會遇到且必須要做的事情。不過在做的時候，一定注意不能太急躁，不能一上來就說：需求里面說的很清楚啊，就是這這樣···那樣····。如果你這樣做的話，程序猿肯定給你一個大大的白眼，心里想：我TM能看懂我還讓你解釋什么？這個時候正確的姿勢應該是，從場景出發，解釋用戶在日常工作中是怎么使用這個功能的。如果是問到一些數據調用的問題，需要說明數據是在哪里產生的，這樣程序猿們會清楚哪些數據是需要從新建立數據表，哪些是已經有現成的數據。當然了，如果你短期內也解釋不清楚的話，就誠實的跟程序說，我先回去看看，等等給你答復。不要在自己不清楚的時候下結論。

老王：第2個問題呢，當程序猿給你提修改建議的時候，一定不要直接否定了，很多好的創意，都是程序猿想出來的。如果程序猿提出來的建議是你之前思考過的，你可以把你之前考慮的思路跟他溝通一下，如果能說服他最好，如果說不不了他，而且此功能對用戶沒有太大影響的話，可以適當的進行修改。那如果程序猿提出的建議是之前沒有考慮過的，這時候你要仔細聽一下程序猿是怎么說的，不要當場回復，回來再考慮一下，整理一下方案是否可行，再去溝通確認。這個時候記住一點，所有的建議，必須以方案的形式進行落地。這才有執行價值。

老王停頓了一下，看看若有所思的小明，緩緩道：那我們說說第3個問題，就是程序猿砍需求的情況。這個問題在每個項目的開發過程中，都是經常遇到的，而且還是產品經理與程序猿產生矛盾的集中點。所以在遇到這種情況之前，你首先需要弄清楚你的產品的核心功能（不可缺少的功能）是什么，輔助功能（存在會有更好的體驗，沒有也不影響正常使用）是什么、意淫需求（沒有使用場景或者說使用場景不實際的需求）是什么，模棱兩可的需求（這樣也行，那樣也行）。

當程序猿要求砍掉意淫需求與模棱兩可的需求時，應果斷砍掉。甚至于在他們沒提出來之前，就應該砍掉這里面的部分需求。當提出要砍輔助功能的時候，我們就需要進行合理且善意的引導，盡量讓程序員接受這個功能，可以通過場景進行引導，讓程序猿覺得這是個有用的功能，能帶來價值的功能。如果程序猿堅決要砍掉，我們就需要適當的做妥協，可以將這個功能放在最后開發，甚至于下一期來進行開發，盡量不要產生爭執（這種功能體量普遍較小，開發周期比較快，最后開發與放在下個版本開發，對用戶沒有太大的影響）。至于核心功能，你需要死死的拽在手里，誰說都不能改，這個是原則上的問題。當然了，我讓你改的時候，你還是要聽話的。

小明：王總，我怎么感覺在這3個問題的處理方式上，都是在一直遷就著程序猿??？

老王：這你就不懂了，這是套路。那我問你，在上面這3個問題的處理方式上，你核心功能有沒有變動？

小明搖搖頭道：沒有。

老王：這就對嘛，我們做產品的目的，主要是看結果的，只要結果達到了，怎樣都行。而在這個過程中，充分采納程序猿的建議，一部分是有利于產品更好的發展，畢竟程序猿提出的部分建議，還是很有價值的；另一部分呢，就是讓程序猿多參與到產品的規劃建設中來，增加他們的主人翁精神（這個最好在規劃階段，就多跟技術進行溝通）。只有這樣才能實現我昨天跟你說的，讓程序猿踏上你的“賊船”。

小明想了一會，說道：王總，套路挺深啊，那您繼續說，下面兩個問題怎么解決？

老王：第4個問題，就是提交的PRD、設計稿、交互稿缺少部分內容的情況，這個你剛才也說了一個解決辦法，這里我再給你補充一下，當項目比較緊急的時候，程序的開發與內容的補充可以同步進行。

老王：最后1個問題，反饋回來的工作量評估表很粗糙的問題。評估表內容粗糙，很大的問題在于你跟項目經理的溝通問題上。對于大多數程序猿來說，都不愿意去做寫一份對后續開發沒多大作用的評估表。這時，你需要跟項目經理提前溝通好，說明清楚要寫一份詳細的工作評估表重要性，讓他協調程序猿來完成這項工作。這里我總結為兩點，

第一點：評估表的詳細程度，直接反應了程序猿對項目的了解程度。對于我們產品經理而言，我們不需要那么詳細的評估表，我們需要的是讓程序猿在寫評估表的過程中，充分的了解產品需求，這樣才能避免后續開發過程中不出現較大的問題。

第二點：詳細的評估表也有利于項目經理對項目的管理與跟蹤，對項目管理有非常重要的作用。

老王掐滅了手中的快燒盡的煙頭，淡淡的說道：其實在這個階段，歸根接地就是一句話：盡可能的創造機會讓程序猿們了解產品的需求，并賦予他們主人翁精神，而不是停留在表面。當工作量都已經評估好之后，我們就需要計算一下開發總時長了。在這個時候，我們需要結合公司的要求，如果公司要求必須在9月30號之前完成開發，而我們評估的時間只能在10月10號完成，那我們需要跟項目經理協調壓縮項目時間。壓縮項目時間可以通過增加項目成員與有效加班的方式進行處理。這個后面我有時間再跟你細講。

確定開發順序

老王：第一步已經跟你講清楚了，接下來我們聊聊如何確定開發順序。關于開發順序，我們重點說一下兩個順序，1個是前端與后端的開發順序；1個是功能模塊的開發順序。

老王：關于前端開發與后端開發，你能分的清吧。

小明：前端就是寫頁面的，后端就是寫數據的，我可以這樣理解吧？

老王：嗯，這樣理解沒毛病。從前端與后端的工作內容來看，在一些地方是沒有依賴性的。例如：前端在沒有數據的情況下，是可以寫一些頁面樣式的。后端在沒有前端的支持下，也是可以寫一些數據接口的。那我們就可以理解為，前端與后端是可以同步進行開發的對吧。

小明：嗯。

老王：你過來看一下這張圖，這是我整理的一份程序員開發順序圖。

注：具體項目的開發的開始時間可能不同，道理是一樣的，前端開發與后端開發可以同步進行，但是需要保證前端在進行數據對接的時候，后端提供足夠的可用數據。

小明：王總，后端開發為什么跟前端開發一起開始啊，我記得都是先切完圖后端才開始開發的??？還有就是后端開發后面有個空白的框，是什么東西??？還有還有，就是最后那個測試，為什么跟開發一起啊，不是做完了才進行測試的嗎？

老王：又著急了不是，年輕人，要穩重點。好好看圖，每個橫向的柱狀圖中，都包含了具體的開發流程，在前端進行切圖、框架選取、交互開發的時候，是不需要后端提供數據的，只需要設計稿與交互稿就可以完成了。而后端開發的的過程中，數據庫設計、框架選取、編寫數據庫接口只需要demo與PRD文檔就可以解決，也不需要前端提供頁面，所以這樣看的話，不相干的工作是可以同時開始并進行的。

而后端開發的那個空白的框，是修改bug的時間。因為在開發過程中，前端開發中“對接數據庫接口”這個過程，是需要后端“編寫數據接口+功能實現”兩部分做支撐的，換句話說，后端的工作進度必須領先于前端的開發進度。所以后端開發通常會提前完成，那剩下的這個時間就是用來進行bug修改與功能調試的。而關于產品測試的時間安排，就是接下來我要講的第2部分，確定功能模塊的開發順序。

功能模塊開發順序，顧名思義就是描述先開發哪些功能模塊，再開發哪些功能模塊。這就跟我上次跟你說的那個講解產品的順序一樣，要有一個先后順序。忘記了你去翻一下上次的筆記《小明與老王的日常：學會做這4件事，讓你的產品提前上線（1）》就知道了。確定這些開發順序后，是方便我們再程序為開發完成就進入測試階段，從而節省測試的時間。這下知道為什么測試階段與開發階段放在一起了吧。

明確關鍵節點

小明：嗯，這下清楚了。王總，您渴不渴，我去給你倒杯水。

老王：不用了，我想喝脈動，給我買一瓶脈動吧。

小明一臉鄙視，無奈地去樓下便利店給老王買了瓶脈動，并給自己買了瓶阿薩姆。

老王喝了一口脈動，緩緩地說：還有最后一個階段了，那就是確定關鍵節點。這個階段的主要目的是便于我們與項目經理對開發進度進行把控，這里呢，我們會用到兩張表，這兩張表分別是上面提到過的開發量評估表與功能模塊開發順序表。將這兩張表組合在一起，就能確定我們項目的關鍵節點了。

而這張表中需要包含項目的開始時間與結束時間；每個模塊的開始時間與截止時間（前端與后端是分開的，功能模塊的完成時間以前端為準）；每個模塊（功能）的負責人、完成情況與備注等信息。其中，功能模塊的劃分與開發順序是由功能模塊開發順序表提供的。具體功能的負責人與時間，是由項目評估表提供的。有了這張表，就可以對項目開發過程進行有效的管理。你過來，我找個之前項目的表給你看下。

（此處的數據為模擬數據）

老王：能理解嗎？

小明：嗯，大體清楚了，回去我再整理一下，如果還有疑問，我再咨詢您。我走了，王總。

老王：嗯，走的時候幫我帶上門。

老王看著漸漸走出辦公室得小明，點了一根煙，緩緩地道：哎，天生就是個操心的命！

相關閱讀

《小明與老王的日常：學會做這4件事，讓你的產品提前上線（1）》

作者：李英杰，二一教育高級產品經理，主要負責題庫類產品的規劃與運營工作。

本文由 @李英杰 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Pixabay，基于 CC0 協議