項目進行過程中,如何把控B端產品的風險管理?
B端產品從需求調研到產品上線,需要經歷一系列流程。那么,為了推進產品進度,我們需要做一些風險管理。作者結合自己的項目,總結產品線流程中,如何進行風險管理以及相關應對措施,希望對你有所幫助。
B端產品從需求調研、產品設計、開發、上線、推廣培訓等環節中,除了推進產品進度,風險管理也至關重要,稍有不慎,就會影響項目進度。那么如何識別風險?風險出現的概率如何評估?如有風險則如何應對?解決方案可以提前構思嗎?等等有關風險問題,都需要產品經理在跟進產品全流程環節中,反復想清楚,才能確保產品保質保量上線。
筆者剛從事產品工作時,作為產品助理,主要是跟著產品經理進行原型設計,當時比較關注的是產品流程執行方面工作,如頁面功能設計、PRD的編寫、上線前的測試、上線后的推廣培訓工作,并未關注到風險方面。
后面獨立負責單獨的產品和產品線以后,發現,底層的執行方面工作其實是最固定的,風險也是最低的,因為確定性比較高,方向定了干就完了。而挖掘需求、產品方向、資源協調等大方面事宜,不確定性很高,風險也比較大,所以就需要有意識投入更多精力關注到風險這條線,與產品流程線并行,才能保證產品穩步進行。
筆者負責的幾個項目中,有過好成績,也有過生產事故,血的教訓,讓我對風險管理逐步建立起完整方法論。風險本質上是實際結果和預期未完全匹配,遭到客戶或用戶等相關方的投訴,例如用戶投訴你設計的產品特別難用,找不到想要的按鈕。或是產品運行中出現數據紕漏,導致業務無法在規定時間完成工作等,都屬于風險事故。
風險管理,其實就是有限的時間和資源下,管理未來目標的實現和相關用戶的期望值不出現巨大偏差,就需要在必要節點與相關方充分溝通,方案設計也不能太滿,要留有一定容錯空間,與用戶溝通也是如此,話不說滿,留有余地,比如上線時間需充分評估不能太緊。
所以說產品經理要了解心理學,就是需要洞察一些人性規律。比如期望如果很高,實際達不到,則大概率是失望的,但是期望如果低一些,實際容易達到,那么大概率就是驚喜。
還有,和各類相關方溝通時,尤其是B端涉及業務流程改造改革方面,用戶投訴產品不好用,不代表著真不好用,可能本質原因是他們不想更換工作流程,因為學習成本較高,或是銷售為了隱藏業績沒有實際錄入系統等等,所以業務里面的可說部分也許是水平面的冰山一角,很多業務也需在水面下面,需要產品經理潛心挖掘。
下面就從幾方面,總結下產品線流程中,并行的風險這條線,如何進行風險管理,以及相關應對措施。
一、需求調研階段
此階段的風險最主要是需求判斷失誤,不滿足用戶或相關方的業務痛點。
這里需要解釋下,B端產品的成功不僅只是滿足使用者(即用戶)的需求,還需滿足相關方(如直屬業務sponsor、上下游業務關聯方等)的需求。一般用戶屬于執行者,注重業務流程上的一個操作點,并不能全流程串聯起來。而項目相關方,一般是項目的發起人,B端產品基本就是業務領導,站在公司降本增效角度,全流程的進行業務改造。而信息化產品就是最有利的抓手,可以更快實現降本增效目標。
所以此階段,不僅要和用戶聊、也要與業務領導層充分溝通,目標、方向的確認也是基于業務領導層對工作的規劃,具體方案如何實現就需要和用戶充分溝通。當然,前面也講過,有些話用戶直接聊了,但有些話沒聊不等于沒有,需要產品經理運用縝密的邏輯進行推敲,串聯起業務流程,一次沒聊透徹沒關系,換用戶多次聊,最終保證需求不偏離用戶、業務領導的實際現狀。
以上是介紹如何降低風險的方式,就是利用透徹的需求調研方式保證需求獲取是準確的,是貼合業務的,具體可看筆者另外一篇文章《需求調研做好了,事半功倍!》http://www.aharts.cn/operate/5733996.html。
那么如果真的出現需求偏離現狀,需求調研失誤,又如何處理呢?
此時,也莫慌。一般需求調研階段,時間相對來說寬裕一些,并沒有方案確定后立馬投入開發、上線階段時間緊,所以還是有時間再修正需求結論的。而且這個時候,也不要為了趕進度,或是僥幸心理,覺得沒必要較真真實需求,先做個方案試驗一下不行再改,就急匆匆進入下一個階段,設計方案。因為越早發現問題,試錯成本就越低,越到后面產品設計、方案實施階段再發現問題再改,時間成本和開發成本就太大了。
筆者經歷的一個項目中就遇到了類似問題,前期因為調研需求是只針對某幾家公司調研,忽略了全國其他城市公司的業務特點,導致開發出來的產品只適用于這幾家公司,其他幾十家無法適用。好在業務領導也知道屬于前期探索階段,沒有對實際上線推廣時間有過多要求,才給予團隊快速調整的時間。
B端產品的業務較復雜,現狀流程都散落在多個角色用戶的腦袋里,未來改造流程也在業務領導的未來規劃中,一切都是變化著,就像之前有句話,唯一不變的就是變化。變化會帶來機會也會帶來風險,產品經理需要做的就是提前識別風險,需求環節獲取的每個流程都需仔細推敲,判斷是否有邏輯風險,并且根據現狀和未來發展,判斷風險概率大小。小概率事件則可暫時忽略,但不代表一直忽略,后續隨著業務發展也可能會變為大概率事件,定期檢視產品的各個環節也是很重要的。
二、方案設計與產品開發
需求確認無誤后,方案的設計就會水到渠成,但此時重點需要關注未來變化,方案也需要面向未來設計,留有一定易修改空間。
如筆者之前設計的產品方案緊跟需求,未深入挖掘,導致方案比較刻板,包容性不好。而且很多時候,方案的大小、好壞,都會決定費用的投入多少、未來上線質量的高低。那如何設計一個好的方案呢?
這就需要確認需求本質和判斷未來變化能力了。就像用戶說要一匹更快的馬一樣,如果你只盯著找馬,不如換個思路,汽車更能滿足用戶需求。
在實際項目如計算傭金規則方面,用戶說我的規則是銷售額乘以提成比例,提成比例又是根據銷售額梯度遞增,但另外公司的用戶所在市場不同,提出提成比例是按照銷售額梯度遞減,兩種相悖的規則,如果只考慮前者,后面就無法兼容,所以要提前考慮。
方案的設計也會直接影響開發工作量,就如上述案例,如果開發完成重新推翻再建立新規則,成本肯定很大。如果提前考慮未來解耦設計,單獨出獨立模塊,即使A模塊有變化,也不影響B模塊,也可以額外新增C、D模塊,都會大大提升工作效率,這就屬于包容性很好的產品方案,另外也需督促開發也朝著此方向發展。
小tips,方案設計完成后,一定要與業務對接人(出錢的人)進行確認,郵件或合同確認方案整體流程和方案細節,防止后面扯皮。這也是前面說的,風險的存在是因為業務人員想象中的結果和實際真實結果不同,未達到兩部分平衡,demo方案就是很好的落地形式,雙方基于同樣的東西進行確認,防止飄在空中,雞同鴨講。有了這個確認過的方案,后續用戶突然臨時新增需求,或是用戶想象中的產品和實際開發不同等情況,都有據可依了。
產品開發的風險主要是人,開發人員能力直接影響開發進度、開發質量,所以就需要產品經理提前找到磨合過的優質開發資源。如果新合作的開發人員或是合作過但開發能力不行的,就只能提前延長工期。如果項目非常緊急無法延長工期,要提前識別出資源風險緊張,趕緊找領導協調,這也是需要產品經理格外關注的。
項目開發中主要就是日會、周會確認開發進度,測試資源也需盡量保證充足,避免上線bug不斷。人員不夠也需產品頂上,總之,開發過程中就是高頻高效開會拉通團隊成員進度。
還有一個容易踩坑的點是,需求評審(主要是產品經理敘述背景、產品方案細節)后,一定過幾天就讓每個開發講解自己為了完成產品功能,需要做哪些事兒,然后就是測試用例評審會收尾,保證全組成員方向不偏。
筆者就出現過好幾次因為開發想當然以為產品功能是這樣設計,實際上沒有深入理解,導致開發結果與產品功能出現偏差。需求評審時只是產品經理輸出,并未融合開發獨立思考后的結果,所以容易出現偏差。所以開發評審主要就是針對開發基于產品方案,搭建開發方案,反饋產品經理,保證雙方達成共識。而且產品經理在設計產品方案時會側重需求方,對開發實現難易程度、具體如何實現未做過多深入思考,也會有些偏差,溝通會就非常有必要,也是提前降低風險的有利措施。
產品經理兢兢業業緊盯項目進度,最終測試通過,可以上線了,就需要提前與用戶溝通好準備工作,比如數據初始化、賬號權限安排等,而且大產品上線進來不要全部用戶一起上,而是找試點公司用戶,試運行一段時間修復完已知未知的bug后再全面鋪開,降低風險。
三、產品運營/運維
產品穩定運行后,你以為就可以萬事大吉了么?切不可掉以輕心,筆者就的一個項目事故就是在這個環節爆發出來,以為沒什么大bug、大需求,產品穩定期應該沒什么大問題,就放松警惕,疏于定期管理與審視,導致突然出現數據錯誤,引起用戶和業務支持者投訴。
究其原因,就是因為產品在上線初期重點關注大概率的場景,比如業務上經常出現的流程,而小概率場景沒有過多考慮,可能半年也不會出現此場景,也就沒有重新整理。慢慢的就把一些系統風險遺忘,導致突然某一天,小概率場景出現,引起大批量數據錯誤。
經歷此次事故,我們團隊也認真復盤,大家一致認為,針對穩定運行的產品功能,隨著業務的變化,也會有一定影響,所以需建立定期風險排查動作,將實際業務場景逐一梳理分析,再走一遍系統流程,反推是否有功能異?;驍祿栴},盡早發現,盡早解決。
總結:風險無處不在,有大有小,細想也都有應對的方案,但前提是心中要有這根線,時刻多問問自己,完成這部分工作了,有哪些環節沒考慮到嗎?干好的標準是什么?干差的情況是什么?干差的風險概率多大?應對措施有哪些?提前考慮到了,到事兒上就可以臨危不亂。
本文由@元方 原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自 Unsplash,基于 CC0 協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論,等你發揮!