如何優(yōu)雅地完成緊急需求
編輯導語:作為一名B端產(chǎn)品經(jīng)理,有時候可能會接到客戶突然提出來的“緊急需求”,這種時候,該怎么做才能既讓客戶滿意,又不傷害原系統(tǒng)呢 ?本文作者總結出了三點注意事項,一起來看一下吧。
一名B端產(chǎn)品經(jīng)理可能時不時會接到客戶提出的“緊急需求”。
之所以“緊急”,可能是因為客戶前期沒有和乙方溝通好,需求提出時已接近項目上線時間;或是一拍腦袋想出一個新主意,不顧項目進度執(zhí)意加塞需求;或是對某個服務環(huán)節(jié)產(chǎn)生不滿,故意為難乙方;亦或是下周突然要與領導匯報……
遇到這種情形,產(chǎn)品經(jīng)理是否應該馬上開始著手需求設計呢?
當然不是。
除了本已存在于客戶原始規(guī)劃中的需求,這類“緊急需求”往往在提出時就非常欠考慮。有時就算看起來非常不起眼的改動,也會對整個系統(tǒng)造成意想不到的混亂。
那么在這時,產(chǎn)品經(jīng)理該怎么做,才能既讓客戶滿意,又能不傷害原系統(tǒng)、不拖累項目進度,更不給自己埋坑?踩過無數(shù)坑的我,對此總結了三點注意事項,希望可以幫助減少處理緊急需求時的手忙腳亂。
01 最簡化原則
怎么做最簡單?這是接到緊急需求時產(chǎn)品經(jīng)理需要優(yōu)先思考的問題,也就是從系統(tǒng)整體考慮,如何用最小的改動滿足客戶需求。比如,如果可以復用已有組件,就不做重復開發(fā);如果可以只讓前端修改,就不動后臺;如果可以只加字段,就不開新接口……
另外,客戶有時因為需要某些數(shù)據(jù),所以要求乙方給報表加字段、增加報表的導出功能等。如果數(shù)據(jù)量不大,此時可以考慮請后臺直接導出,再由人工對數(shù)據(jù)進行二次處理。如果導出頻率較低,后續(xù)可以維持此流程;如果導出頻率較高,則要協(xié)調人力盡快開發(fā)功能。
如果是SaaS產(chǎn)品,變更一個功能,將不止影響一家企業(yè),因此SaaS產(chǎn)品經(jīng)理非??粗匦枨笸ㄓ眯浴5谥С志o急需求的情況下,有時并不能只考慮通用性,畢竟通用性強的需求往往意味著邏輯多、開發(fā)量大。此時可以先上線一個簡單功能,再根據(jù)自己的規(guī)劃,后期做功能變更或擴充。
02 不要盲目相信原始需求
時間的緊迫容易讓人缺少正確判斷,更容易讓產(chǎn)品經(jīng)理只顧解決問題,拿到客戶的原始需求就直接開工。事實上,就算此時時間緊迫、不便與客戶直接接觸,產(chǎn)品經(jīng)理也應該花一點時間,聯(lián)系銷售、售前等部門同事,了解需求究竟從何而來,弄清客戶的真正意圖。
我曾接到這樣一條緊急需求,客戶要求將我們的學員端登錄頁改造得與管理端相同。已經(jīng)被其他需求壓得喘不過氣的我準備直接向研發(fā)提出“為該企業(yè)定制一個和管理端相同的學員端登錄頁”,此時一位前端工程師提醒我,管理端和學員端的前端架構不一樣,不是復制一個登錄頁給學員端就可以,現(xiàn)在給的開發(fā)時間完全不夠。
這才讓我冷靜下來思考這個需求的合理性,我開始回想我了解到的需求背景:客戶在使用我們的平臺之前,管理端和學員端是一起的。這次更換平臺,客戶并不想改變已有習慣,但我們又不可能真的把兩端放在一起。因此雙方各退一步,最后客戶與售前將需求確定為:保持管理端和學員端的登錄頁是兩個登錄地址,但樣式相同。
很明顯,要求頁面樣式相同只是表面需求,客戶的深層需求其實是不想把管理端和學員端割裂。這樣一想,也就不必拘泥于做一個新頁面了。我很快改變了思路:給客戶定制一個管理端至學員端的免登。這就已經(jīng)足夠。
不盲目相信原始需求,看清客戶的真正意圖,除了能獲得一個更好的需求設計,有時還能因此看清這條需求其實完全沒必要做,進而直接消滅需求,這對項目組所有人來說是再好不過的事情。
03 不要盲目復用已有功能
在上文的最簡化原則中提到,“如果可以復用已有組件,就不做重復開發(fā)”。這個方法對處理緊急需求十分有效,但并不是減少產(chǎn)研工作量的萬金油。兩個提出相同需求的客戶可能有兩種完全不同的使用場景,因此在功能看似可以復用時并不意味著需求就此萬事大吉,說不定在復用后就被客戶投訴“根本不能用”。
我們把上面的例子反過來。假設客戶直接提出了“我需要從A平臺無需再次登錄就可以跳到B平臺”,此時研發(fā)告知產(chǎn)品經(jīng)理,此前在某定制項目中開發(fā)過相同的功能,復用即可,于是產(chǎn)品經(jīng)理欣喜地在需求中寫下“復用XX項目的免登功能”。
結果需求上線當日被提報生產(chǎn)問題,原因是已有的免登功能僅支持手機號登錄,現(xiàn)在客戶用的是郵箱登錄。
這個例子看起來可能有些極端和好笑,但事實上我曾見過不止一位產(chǎn)品經(jīng)理犯過類似的錯誤(包括一些資深的產(chǎn)品經(jīng)理,以及我自己),也就是急于復用現(xiàn)有功能,忘記將功能放在客戶場景中,考慮整個業(yè)務流程是否已完成閉環(huán)。
以上三點就是我對緊急需求處理的一些看法,也是我對自己過往工作的總結,不足之處還請大家多多指點,也歡迎大家共同討論。
作者:JaneGinkgo,還在不斷學習中的95后產(chǎn)品經(jīng)理。
本文由 @JaneGinkgo 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉載
題圖來自 Unsplash,基于 CC0 協(xié)議
對于B端新手產(chǎn)品看了真的超級有用,但還有個問題想請教下~
雖然很多緊急需求,也許并不重要,但對客戶來說是既緊急且重要的。甚至客戶有時候會強制要求執(zhí)行原始需求,面對不合理需求與強硬的客戶,大部分情況都會選擇妥協(xié)并執(zhí)行。針對這一問題,如何能做到有效說服客戶/領導呢?又或者作為打工人,我們只需要執(zhí)行好就行?
感謝你的評論~下面是我的看法。
拒絕不合理需求有很多種方式,但前提一定是我們非常了解整個項目狀態(tài)以及客戶實際需求。可以從客戶使用場景切入,告知客戶當前需求的漏洞,例如這種做法功能未閉環(huán)會引發(fā)諸多問題、不符合業(yè)務場景、不能解決實際問題等等;或從項目工期考慮,讓客戶理解當前研發(fā)任務量已經(jīng)非常繁重,新需求建議放到二期或者變通解決;還可以直接了當?shù)母嬷蛻舢斍靶枨蟛辉诤贤秶鷥仍圃?。實際用哪種方式就要具體問題具體分析了,溝通過程中注意態(tài)度明確、有理有據(jù),不要讓客戶認為是乙方推脫責任,必要時也可以請項目組的銷售部門同事一起加入。
當然作為一個打工人總有身不由己的時候,這時我覺得我們能做的,就是提醒自己當前行為的不合理性,決不能讓這成為自己工作的常態(tài)。