項目流程中,如何有效減少返工率?

2 評論 11989 瀏覽 47 收藏 8 分鐘

具有主人翁精神,作業(yè)之前都考慮幾步,后期就能為自己減少返工率。

為什么需求一改再改,為什么排期每天一變,導(dǎo)致設(shè)計與技術(shù)工作停滯或重復(fù)做工,抽出想殺死產(chǎn)品的刀,怨氣沖天。最后項目上線延遲,BOSS怪罪,技術(shù)說因?yàn)樵O(shè)計稿沒到不能開工,設(shè)計說因?yàn)樵蜎]確定不能開工,產(chǎn)品一臉苦笑,攤開雙手說業(yè)務(wù)方一會需求這樣一會那樣什么都沒定下來,業(yè)務(wù)方猶豫半天道出老板你不是說要新加XXX?這就是互聯(lián)網(wǎng)公司項目流程普遍規(guī)律,如果說能做到零返工率,就如技術(shù)說零bug一般扯談。

避免理想化的產(chǎn)品流程

項目流程中,BOSS/業(yè)務(wù)部門為需求方,產(chǎn)品部為中轉(zhuǎn)站(協(xié)調(diào)方),設(shè)計/技術(shù)為執(zhí)行方。

案例:某咨詢平臺與一家權(quán)威機(jī)構(gòu)合作,對方免費(fèi)提供測試題目,如需生成測試報告則需付費(fèi);專家可通過該測試報告作為了解用戶情況的參考依據(jù)。如用戶在其他渠道進(jìn)行該測試,則需要繳納費(fèi)用,boss的意思是在APP端加入測試入口,通過免費(fèi)測試引入用戶流量,為咨詢業(yè)務(wù)帶來獲益。

市場部整理需求如下:

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

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

需求目的:一定要達(dá)到XX%營收,關(guān)系到所有部門績效考核。

產(chǎn)品部收到需求,并進(jìn)行分析,繪制流程圖。

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

從測試到預(yù)約專家咨詢流程,確實(shí)毫無問題,但是在這個流程中,我們每個環(huán)節(jié)思考的點(diǎn)都是理想狀態(tài),從用戶的層面上考慮,我為何要一步步都跟著你的流程走呢?

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

這幾點(diǎn)問題,是在設(shè)計結(jié)束進(jìn)入開發(fā)期間財務(wù)部和市場部再次細(xì)細(xì)看原型補(bǔ)充出來的,從我們理想化的流程中,成本流失率比獲益轉(zhuǎn)換率高。解決方案如下:

  • 強(qiáng)化測試的權(quán)威性:可在測試詳情頁做詳細(xì)介紹
  • 抑制生成報告測試:可免費(fèi)測試生成報告一次(前端不做提示),如第二次測試需預(yù)約專家才可生成報告
  • 專家選擇的順暢性:測試詳情頁推薦熱門專家(用戶通過了解測試產(chǎn)生咨詢需求);也可從專家詳情頁購買測試套餐(用戶通過了解專家產(chǎn)生測試需求)

于是,在設(shè)計抓狂的怨氣中,整個原型又要修改,重新走一邊始點(diǎn),之前的所有排期都不作數(shù)。

避免職責(zé)劃分的清晰性

如果產(chǎn)品部與技術(shù)部合為一個部門,那產(chǎn)品部的職責(zé)就像指揮官,同個時間段,需要往哪個方向打戰(zhàn),怎么布兵,什么時辰出兵,產(chǎn)品部門需做判斷,怎樣使出兵出的值。出現(xiàn)需求變更,有很大一部分責(zé)任在于產(chǎn)品部把自身職責(zé)拎的太清,把自己當(dāng)作執(zhí)行方,只需要依據(jù)業(yè)務(wù)部門的業(yè)務(wù)流程畫出相對應(yīng)的流程圖。如產(chǎn)品部不能更為熟悉業(yè)務(wù),找到用戶的痛點(diǎn)爽點(diǎn),一而再而三的跑一遍流程,描述用戶使用場景,每個環(huán)節(jié)的用戶心理變化,則產(chǎn)品就如一個空有架構(gòu)的虛無品,不能達(dá)到業(yè)務(wù)目的。

一個完整的項目流程是:需求方輸出需求——產(chǎn)品審核需求并做出判斷獲益性和實(shí)現(xiàn)性——設(shè)計接收原型并審核產(chǎn)品考慮不周之處——技術(shù)評估或執(zhí)行時審核原型或設(shè)計的無理性——測試在評估原型時期編寫測試樣例,找出原型缺少狀態(tài)。

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

 

本文由 @十二 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 這篇文章的邏輯,或者說兩個部分的標(biāo)題不太正確。

    第一個例子的問題,與其說是“避免理想化的產(chǎn)品流程”(這只是現(xiàn)象),倒不如說是挖掘用戶場景挖掘的不夠深,和需求方溝通時挖掘的不夠深。

    第二個例子的標(biāo)題就很讓人很奇怪了,什么叫做“避免職責(zé)劃分的清晰性”?那所以就是不清晰劃分職責(zé)咯?再細(xì)看了幾遍內(nèi)容后才勉強(qiáng)理解作者的意圖。
    那么,這問題是出在職責(zé)劃分太清晰?不是。挖掘需求方的需求,這本來就是產(chǎn)品經(jīng)理分內(nèi)的事情呀。所以與其說這犯錯在職責(zé)劃分太清晰,倒不如說是文中的產(chǎn)品經(jīng)理沒有承擔(dān)足夠的產(chǎn)品經(jīng)理職責(zé),只是需求方和設(shè)計、開發(fā)間傳聲筒。文中看了幾遍實(shí)際上也是這個意思,但是切入的角度不太正確,以至于讓理解產(chǎn)品經(jīng)理職責(zé)的人看起來,反而摸不著頭腦。

    來自上海 回復(fù)
  2. 不錯??,學(xué)習(xí)了

    回復(fù)