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

避免理想化的産品流程

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

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

市場部整理需求如下：

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

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

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

産品部收到需求，并進行分析，繪制流程圖。

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

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

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

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

• 強化測試的權威性：
• 抑制生成報告測試：
• 專家選擇的順暢性：

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

避免職責劃分的清晰性

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

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

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

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

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部