編輯導語：在上一篇文章《超硬幹貨：如何把需求變成產品方案？》中，作者從前期準備、方案設計、需求評審三個層面，為我們分享瞭如何把需求變成產品方案。本篇文章中，作者和我們聊一聊在評審會之後，進入到產品開發過程有哪些關注點。
上一篇文章，我給大家介紹了把需求變成產品方案過程，以及為了通過需求評審，要注意的幾個點。
那通過評審會之後，我們產品要做的工作，就是推進項目、關注進度、並按時上線。所以，這篇文章，我會在“實用”的層面，從項目排期—>需求開發—>上線前體驗—>產品上線，這四個步驟，給大家從介紹下，在產品開發過程中要關注點。
一、項目排期通過評審會的需求，需要根據需求的優先級，進行資源分配，排期開發。
如果大廠的話，一般都會有項目經理來支撐這塊工作；如果是中小公司的話，通常是由研發負責人來承擔分配任務的角色的。此時，我們產品需要做的工作就是，關注自己需求的排期情況。
如果是較緊急的需求，或領導比較關注的需求，要儘可能需求提高優先級，為自己的爭取開發資源。
在這個場景下，溝通技巧就很重要了。如果是優先級較高的需求，我的方法是：先跟對方陳述需求背景，然後強調需求儘快實現重要性，輔以領導關注的背景，將壓力傳遞過去，提高需求優先級。
其次，在溝通時，最好是線上溝通，否則資源緊張排不上期，後面領導問起來，也有文字留檔。
二、需求開發需求排期之後，一般項目經理會通過既定渠道告訴你，你的項目已經分配到對應的開發了，那次是，我們就可以跟進需求開發的情況了。
根據經驗，在開發階段，是最容易導致需求延期的。所以，我們要利用項目管理的方法，儘可能避免出現延期的風險。總的來説，需求開發跟進過程要保證分工具體、工作量化、風險可控這三個點。
1. 分工具體：方案同步，拆解工作首先，在開始之前，我們首先要根據需求文檔，跟對應的開發闡述需求。
力求對方和自己要實現的需求預期是一致的，如果是多端合作的大需求，工作分配要具體到人的話，每項工作，每個功能模塊都必須拆解出來，並以會議形式同步。
關注明確需求的負責人，將負責人落到會議紀要，並最終在項目羣羣裏同步。
2. 量化工作：明確開發週期在同步好方案後，就需要明確開發的開發時間。即：我們要關注誰，在什麼時候開始，預期什麼時候能完成。
我們團隊的開發流程，一般是需要開發根據需求文檔，出技術方案，然後提交到技術團隊，進行內部技術方案評審，評審通過之後才能知道具體的開發工作量。
所以，在前期溝通方案時，我也會先跟對方明確技術文檔完成時間和上會時間。在明確技術方案之後，再和相關同事對齊具體的開發排期，並在羣裏同步。
這裏我有個小技巧，就是我一般會在開發評估的時間上，多加上1-2天，然後再同步出來。因為人都是會高估自己工作能力的，所以在開發過程中，很可能會超出既定預期的。
我們團隊的項目經理會通過“甘特圖”來明確項目的進度和落地進展。
所以，工作量如果確定下來，我們可以用上面甘特圖的方式，將拆解出來的任務、預計進度、實際進度，統統進到表中。我們一般是在“騰訊文檔”上，通過建立共享文檔的方式，來給團隊各成員同步項目進展的。
3. 風險可控：設置反饋節點，按時回收反饋在確定好項目安排之後，就可以正式進入開發階段了。在開發階段，最容易出現的風險的，就是因為開發未按照預定時間開發，導致延期。
所以，我將從向下和向上的兩個角度，來介紹如何讓風險可控：
1）向下管理：負責的項目，及時瞭解項目進展
在開發過程中，我們項目根據甘特圖排好期之後，還需要另外設置反饋節點，然後定期回收反饋信息，才能知道我們手裏需求的開發的進度。
我如果手裏有多個需求在並行的話，我每天早上和下午都分別會花1-2小時，分別跟進開發的開發進度，並且叮囑對方，如果有發現困難需要我支持的，要及時跟我同步。
因為，在實際工作中，並不是所有開發都是很主動的，所以我們自己要主動去了解開發進展，看是否有方案上的調整，開發延期的情況。
如果有方案上的調整，尤其是涉及產品功能的調整，我們要及時用文字方式，在羣裏跟項目成員同步調整的原因和調整後的結果。
而後，儘快抽時間更新需求文檔，明確調整時間。如果是大項目的話，可以定個一週/次的項目同步例會，以便定期和各方同步項目進展，以及遇到的困難。
2）向上管理：跟領導及時彙報進展，同步困難
在瞭解項目進展之後，我們也要及時和領導同步自己手中的需求進展情況，有困難要及時暴露出來。我見過一些剛入行的新同學，可能是礙於情面，不敢或不好意思跟領導説明困難，最終導致項目延期的。
其實，這是一個非常不好的“學生氣”。我們遇到問題時，能夠適當尋求領導支持，對工作來説，也是很重要的。
但注意，我這裏説的要“適當”，是我們要注意把握“度”，遇到困難我們要先嚐試自己解決，不能説每個需求都讓領導支持，否則領導也會懷疑我們的工作能力。
我的習慣是會在每週的週三下午，在有領導的項目羣裏，@下領導和對應開發，同步開發進展、完成時間和項目困難。
我選週中是因為我預留了調整的時間，如果真有問題，週四週五可以及時調整，時間上才不會太緊。如果有人對進展或需求有問題的話，也可以及時在羣裏討論解決。
這樣做，除了同步進展和預留時間之外，還有一個好處：在羣裏通過文字留檔，起到保護自己的效果。
三、上線前體驗在需求開發完成後，需求離正式上線只有最後兩步之遙——產品測試和產品走查。
1. 產品測試在需求開發完成後，首先進入測試環節。測試環節，我們首先需要在測試環境，體驗產品核心流程是否符合開發預期。
然後，根據需求文檔，給測試介紹整個需求的背景和需求預期，以便測試輸出測試用例，這裏主要是針對異常流程的測試。這裏的重點是，必須讓測試對產品的理解和你是一致的，否則容易出現部分異常流程沒有測到的情況。
最後，就是讓測試同學的工作，也要遵循在開發階段，需求推進的三步走策略——明確分工、量化工作、風險可控這三點。
2. 產品體驗走查在這個環節，主要是針對有前端頁面的需求，在產品的使用流程和前端的頁面設計的走查。這部分的工作，通常需要交互和設計同學支持，看這裏的體驗是否符合產品設計的預期。
而在這個階段，產品也需要和交互設計一起，體驗產品的細節。這是一個非常磨鍊產品人，可是卻不能偷懶的工作。我見過所有優秀的產品經理，都對產品細節有極致的追求。
我一開始其實也做的不好，主要是沉不下心來做這個事，所以也經常因為粗心出過錯。
但後來，我看過一本叫《清單革命》的書：書中主旨是：因為粗心出錯的情況，在各行各業都比比皆是。但所有的複雜流程，都可以通過建立清單的方式，減少出錯的情況。
即：把工作中所有的必做項，都列成清單，在具體實施的時候，一項項勾兑完成。這樣就能極大地減少出錯的情況，做到不重不漏。後來我也建立了屬於自己的《上線走查清單》，從頁面中從上到下要關注的細節，流程中從入口到出口的頁面，逐一體驗通過。
所以，我建議大家如果沒有建立走查表清單的同學，也開始建立一套屬於自己的清單，可以極大地減少，由於粗心導致的問題。而且，如果有問題但當前版本已經來不及調整的話，我們也可以把這個優化點放到需求池中，下個版本的規劃中，再放進去。
四、需求上線在完成上線前的測試和走查之後，需求就可以根據原定的時間安排上線了。而在上線前，可能還需要準備一些資料。
如app上線的話，需要準備一些應用商店的文件、描述、圖片；或是產品內幫助中心的文檔、智能客服的描述；但如果是B端產品，可能需要準備新功能的客服或銷售的培訓文檔等。
因為產品的不同，需要準備的東西可能也不一樣，這裏大家要根據自己的產品或行業準備即可。當然，如果比較複雜的，也可以用上面説的清單的方式，來建立走查表。
除此之外，我還想講兩個，個人認為非常重要的點：
1. 關注數據變化：是產品優化的方向我之前有很多需求完成之後，沒有及時關注數據變化的。當時我的領導在會上有“提醒”過我，他説：有些同學工作習慣還是要加強下，產品上線後不看數據的，你根本就不知道你這個產品功能有沒有用户用。你不看數據和沒做需求有什麼區別？
後來，我領導為了專門培養我這個習慣，隔三差五就會問我某個功能的數據情況。而後，我為了減少被領導問到的窘況，我每天早上都會花一個小時的時間，看產品數據，並嘗試分析數據抖動的原因。
2. 項目覆盤：不復盤=白忙活產品的工作，失敗的需求要遠多於成功的需求。我們團隊的產品，為了實現破圈，去年一年在產品上新增的功能，無一不是失敗的。
為了增加產品留存，我們增加過遊戲模塊，上過簽到返現能力，也弄過積分體系、會員體系，可無一被用户接受。可失敗之後，我們一直在覆盤，因為覆盤，是我們唯一能從失敗中獲取的最有價值的東西。
我覺得對產品人來説，最好，也是成長最快的捷徑，就是覆盤。具體覆盤的話，可以從整體的產品流程入手。
從前期調研—>需求分析—>方案設計—>需求開發—>產品測試—>產品運營入手，對整個項目流程進行復盤。結合當時背景、遇到問題、當時處理方式等，進行反思和總結，最終得出優化的覆盤方案。
我們也可以從目標入手。對比目標預期和實際實踐環節，對比差別，看到不足之處，以及如果重新做的話，我該如何優化實施環節。並且，我們還要結合產品數據表現，進行更全面的思考分析，輸出優化的結論。
這樣，我們的項目，才形成了一個優化迭代閉環，在下一個需求或項目時，才不會重蹈覆轍。
五、寫在最後產品需求落地的過程，就是項目管理實操的過程。
- 首先，我們要先明確項目排期，可以用背景+領導關注的闡述方式，提高需求優先級；
- 其次，需求開發和測試過程中，要遵循分工明確、工作量化、風險可控這三個原則；
- 然後，在上線前體驗過程中，可以通過自建走查表的方式，減少出錯的可能性；
- 最後，需求上線之後，需關注數據變化，並及時覆盤，記錄優化點，輸出改進結論。
這樣，我們才構建了一套完整的需求閉環。
本文由 @豆奶 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。