項目流程中,如何有效減少返工率?
具有主人翁精神,作業之前都考慮幾步,后期就能為自己減少返工率。
為什么需求一改再改,為什么排期每天一變,導致設計與技術工作停滯或重復做工,抽出想殺死產品的刀,怨氣沖天。最后項目上線延遲,BOSS怪罪,技術說因為設計稿沒到不能開工,設計說因為原型沒確定不能開工,產品一臉苦笑,攤開雙手說業務方一會需求這樣一會那樣什么都沒定下來,業務方猶豫半天道出老板你不是說要新加XXX?這就是互聯網公司項目流程普遍規律,如果說能做到零返工率,就如技術說零bug一般扯談。
避免理想化的產品流程
項目流程中,BOSS/業務部門為需求方,產品部為中轉站(協調方),設計/技術為執行方。
案例:某咨詢平臺與一家權威機構合作,對方免費提供測試題目,如需生成測試報告則需付費;專家可通過該測試報告作為了解用戶情況的參考依據。如用戶在其他渠道進行該測試,則需要繳納費用,boss的意思是在APP端加入測試入口,通過免費測試引入用戶流量,為咨詢業務帶來獲益。
市場部整理需求如下:
套餐分類根據咨詢時長決定不同價格體系。
通過運營部協作,為該測試版塊拉入一部分咨詢專家,咨詢方式為“見面”與“電話”。用戶可在線發送報告至專家,也可打印報告線下咨詢時提供,市場部提供套餐詳細信息,用戶可進行多次測試或多次預約專家,該測試套餐一旦購買則不能退款。
需求目的:一定要達到XX%營收,關系到所有部門績效考核。
產品部收到需求,并進行分析,繪制流程圖。
流程與需求方確認之后完成產品原型繪制完成,再次與需求方確定最終原型方案,通過之后產品部召開第一次技術評審會,并無技術難度。沒問題先給設計排期,設計作業并行時間中,開發需半天左右根據原型初步評估工時,涉及到前端后臺還有測試,設計完稿日期之后+1天,上午召開第二次技術評審會,下午根據設計稿評估精確工時,整個項目貌似有條不紊的進行中。
從測試到預約專家咨詢流程,確實毫無問題,但是在這個流程中,我們每個環節思考的點都是理想狀態,從用戶的層面上考慮,我為何要一步步都跟著你的流程走呢?
- 并不是所有用戶都知道該測試的權威性與在其他渠道必須收費,有免費的何必要付費呢。
- 這份測試題是全國通用的咨詢前必填的,具有參考依據的權威性,如用戶曉得,可在我方平臺測試,提取報告找平臺以外專家咨詢。
- 互聯網時代最不缺的是各種測試,用戶如抱著測試玩玩的心理,幾乎不會付費預約專家。
- 并不是所有用戶都熟悉專家的專業性,即使通過免費測試得出報告想預約專家,也無從選擇。
- 如兩種咨詢方式費用相同,用戶更趨向于見面咨詢,與專家見面可以交談的更深入,或抱著僥幸心理購買低時長套餐線下要求專家拉長時長。
- 如用戶可無線次數測試,極有可能為了檢測報告差異性測試性的胡亂答題,造成我們成本流失。
這幾點問題,是在設計結束進入開發期間財務部和市場部再次細細看原型補充出來的,從我們理想化的流程中,成本流失率比獲益轉換率高。解決方案如下:
- 強化測試的權威性:可在測試詳情頁做詳細介紹
- 抑制生成報告測試:可免費測試生成報告一次(前端不做提示),如第二次測試需預約專家才可生成報告
- 專家選擇的順暢性:測試詳情頁推薦熱門專家(用戶通過了解測試產生咨詢需求);也可從專家詳情頁購買測試套餐(用戶通過了解專家產生測試需求)
于是,在設計抓狂的怨氣中,整個原型又要修改,重新走一邊始點,之前的所有排期都不作數。
避免職責劃分的清晰性
如果產品部與技術部合為一個部門,那產品部的職責就像指揮官,同個時間段,需要往哪個方向打戰,怎么布兵,什么時辰出兵,產品部門需做判斷,怎樣使出兵出的值。出現需求變更,有很大一部分責任在于產品部把自身職責拎的太清,把自己當作執行方,只需要依據業務部門的業務流程畫出相對應的流程圖。如產品部不能更為熟悉業務,找到用戶的痛點爽點,一而再而三的跑一遍流程,描述用戶使用場景,每個環節的用戶心理變化,則產品就如一個空有架構的虛無品,不能達到業務目的。
一個完整的項目流程是:需求方輸出需求——產品審核需求并做出判斷獲益性和實現性——設計接收原型并審核產品考慮不周之處——技術評估或執行時審核原型或設計的無理性——測試在評估原型時期編寫測試樣例,找出原型缺少狀態。
如在這個流程線上各部門職責劃分太過于清楚,則產品的成功與否,僅綁定在源頭需求方,人無完人,一個人走不遠,一個團隊才能走的遠。具有主人翁精神,作業之前都考慮幾步,后期就能為自己減少返工率。
本文由 @十二 原創發布于人人都是產品經理。未經許可,禁止轉載。
這篇文章的邏輯,或者說兩個部分的標題不太正確。
第一個例子的問題,與其說是“避免理想化的產品流程”(這只是現象),倒不如說是挖掘用戶場景挖掘的不夠深,和需求方溝通時挖掘的不夠深。
第二個例子的標題就很讓人很奇怪了,什么叫做“避免職責劃分的清晰性”?那所以就是不清晰劃分職責咯?再細看了幾遍內容后才勉強理解作者的意圖。
那么,這問題是出在職責劃分太清晰?不是。挖掘需求方的需求,這本來就是產品經理分內的事情呀。所以與其說這犯錯在職責劃分太清晰,倒不如說是文中的產品經理沒有承擔足夠的產品經理職責,只是需求方和設計、開發間傳聲筒。文中看了幾遍實際上也是這個意思,但是切入的角度不太正確,以至于讓理解產品經理職責的人看起來,反而摸不著頭腦。
不錯??,學習了