項目流程中，如何有效減少返工率？

具有主人翁精神，作業之前都考慮幾步，後期就能為自己減少返工率。

為什麼需求一改再改，為什麼排期每天一變，導致設計與技術工作停滯或重複做工，抽出想殺死產品的刀，怨氣衝天。最後項目上線延遲，BOSS怪罪，技術說因為設計稿沒到不能開工，設計說因為原型沒確定不能開工，產品一臉苦笑，攤開雙手說業務方一會需求這樣一會那樣什麼都沒定下來，業務方猶豫半天道出老闆你不是說要新加XXX？這就是互聯網公司項目流程普遍規律，如果說能做到零返工率，就如技術說零bug一般扯談。

避免理想化的產品流程

項目流程中，BOSS/業務部門為需求方，產品部為中轉站（協調方），設計/技術為執行方。

案例：某諮詢平台與一家權威機構合作，對方免費提供測試題目，如需生成測試報告則需付費；專家可通過該測試報告作為了解用戶情況的參考依據。如用戶在其他渠道進行該測試，則需要繳納費用，boss的意思是在APP端加入測試入口，通過免費測試引入用戶流量，為諮詢業務帶來獲益。

市場部整理需求如下：

套餐分類根據諮詢時長決定不同價格體系。

通過運營部協作，為該測試版塊拉入一部分諮詢專家，諮詢方式為「見面」與「電話」。用戶可在線發送報告至專家，也可列印報告線下諮詢時提供，市場部提供套餐詳細信息，用戶可進行多次測試或多次預約專家，該測試套餐一旦購買則不能退款。

需求目的：一定要達到XX%營收，關係到所有部門績效考核。

產品部收到需求，並進行分析，繪製流程圖。

流程與需求方確認之後完成產品原型繪製完成，再次與需求方確定最終原型方案，通過之後產品部召開第一次技術評審會，並無技術難度。沒問題先給設計排期，設計作業并行時間中，開發需半天左右根據原型初步評估工時，涉及到前端後台還有測試，設計完稿日期之後+1天，上午召開第二次技術評審會，下午根據設計稿評估精確工時，整個項目貌似有條不紊的進行中。

從測試到預約專家諮詢流程，確實毫無問題，但是在這個流程中，我們每個環節思考的點都是理想狀態，從用戶的層面上考慮，我為何要一步步都跟著你的流程走呢？

• 並不是所有用戶都知道該測試的權威性與在其他渠道必須收費，有免費的何必要付費呢。
• 這份測試題是全國通用的諮詢前必填的，具有參考依據的權威性，如用戶曉得，可在我方平台測試，提取報告找平台以外專家諮詢。
• 互聯網時代最不缺的是各種測試，用戶如抱著測試玩玩的心理，幾乎不會付費預約專家。
• 並不是所有用戶都熟悉專家的專業性，即使通過免費測試得出報告想預約專家，也無從選擇。
• 如兩種諮詢方式費用相同，用戶更趨向於見面諮詢，與專家見面可以交談的更深入，或抱著僥倖心理購買低時長套餐線下要求專家拉長時長。
• 如用戶可無線次數測試，極有可能為了檢測報告差異性測試性的胡亂答題，造成我們成本流失。

這幾點問題，是在設計結束進入開發期間財務部和市場部再次細細看原型補充出來的，從我們理想化的流程中，成本流失率比獲益轉換率高。解決方案如下：

• 強化測試的權威性：可在測試詳情頁做詳細介紹
• 抑制生成報告測試：可免費測試生成報告一次（前端不做提示），如第二次測試需預約專家才可生成報告
• 專家選擇的順暢性：測試詳情頁推薦熱門專家（用戶通過了解測試產生諮詢需求）；也可從專家詳情頁購買測試套餐（用戶通過了解專家產生測試需求）

於是，在設計抓狂的怨氣中，整個原型又要修改，重新走一邊始點，之前的所有排期都不作數。

避免職責劃分的清晰性

如果產品部與技術部合為一個部門，那產品部的職責就像指揮官，同個時間段，需要往哪個方向打戰，怎麼布兵，什麼時辰出兵，產品部門需做判斷，怎樣使出兵出的值。出現需求變更，有很大一部分責任在於產品部把自身職責拎的太清，把自己當作執行方，只需要依據業務部門的業務流程畫出相對應的流程圖。如產品部不能更為熟悉業務，找到用戶的痛點爽點，一而再而三的跑一遍流程，描述用戶使用場景，每個環節的用戶心理變化，則產品就如一個空有架構的虛無品，不能達到業務目的。

一個完整的項目流程是：需求方輸出需求——產品審核需求並做出判斷獲益性和實現性——設計接收原型並審核產品考慮不周之處——技術評估或執行時審核原型或設計的無理性——測試在評估原型時期編寫測試樣例，找出原型缺少狀態。

如在這個流程線上各部門職責劃分太過於清楚，則產品的成功與否，僅綁定在源頭需求方，人無完人，一個人走不遠，一個團隊才能走的遠。具有主人翁精神，作業之前都考慮幾步，後期就能為自己減少返工率。

本文由 @十二 原創發佈於人人都是產品經理。未經許可，禁止轉載。