一個小需求引發的撕逼記
一、事件經過
目前在公司接手一個賬戶中心的產品,產品形式是預裝到手機里的客戶端,類似于小米的“我的小米”,此產品收集終端用戶最基礎的信息,為后續開展業務統計、對外合作等提供數據依據。
公司是上市公司,部門龐大,合作方也是大上市公司,雙方勾搭對接的環節是這樣的
- 業務<–>業務
- 產品<–>產品
- 研發<–>研發
中間流程環節太多,每次郵件大票人馬,最后干脆讓研發直接對接。我方業務及領導對對方基本上是有求必應,發展至最后,到了對方業務人員直接讓我方研發改代碼的程度。
哥接手后,某日對方業務部門要求我方客戶端直接給他們服務器傳參數,我拒絕了,理由如下:
- 流程居然是:我方客戶端–>海外AWS服務器–>服務系統A(上海)–>服務系統B(深圳)–>合作方客戶端
- 客戶端是直接面向用戶的,修改要重新發版引導用戶升級,這對用戶是極大的干擾,且升級覆蓋率也不高;
- 業務邏輯盡可能放服務端實現,客戶端負責業務展示應盡量簡單以適應業務變化;
- 就不要扔到客戶端來做,要解耦,況且還是跟外部合作方的系統耦合,簡直沒有天理!
作為一只有原則的汪,底限是要堅持的,業務邏輯是會變更的,一旦開了口子,往后就是無盡的深淵,哥有理有節,不干!您請找我方業務轉接到服務端去~ 以為事情就此結束,接著了解到業務部門推不動中間環節的兩個服務端部門,然后呢,層層郵件升級給各種叫大領導的生物,在一封轉到我這只有一句“請客戶端產品xxx務必盡力支持!”的回復后,哥的原則就像多年前堅守的節操一樣,瞬間碎了……真實憋屈……這通常就是大公司里撕逼的常見方式,苦笑。
二、事件后果
- 業務部門抱怨產品部,就一個小需求都做不好;
- 研發同事極度苦悶,需求一時一個變,毫無規劃,今天改了明天又反復;
- 產品狗也郁悶,被業務和研發兩頭夾著,里外不是人;
- 合作方也有抱怨,貴方效率這么挫,還要不要玩耍了?
三、原因分析
- 系統支撐缺乏規劃,前期系統設計可擴展性差,導致各個子系統分散各地;
- 歷史債,公司大了,部門割裂嚴重各自都是屁股決定腦袋,各種交接留下的爛攤子;
- 溝通問題,業務部門做事方式實在太粗糙粗暴,只管拉上級施壓而不考慮為何實現困難,鴨梨下來產品研發也只能頭痛醫頭腳痛醫腳;
- 產品缺少定位無規劃,一個需求是否要加上,什么時候加上,以怎樣的形式加上,都需要用產品定位來衡量決定。定位混亂各部門就都想來插一腳加幾個需求,于是乎系統最后臃腫不堪,七零八落再做減法就難了;
四、反思與改進
產品定位始終要明確
產品必須有一個明確的定位,不忘初心,也就是開發這產品時的需求出發點必須堅持。如果需求點已變,也要清楚變成了什么,然后才能圍繞這一定位來構造產品。對于產品需求來說,定位不清,何以加為?產品定位,是衡量新需求的標尺。賬戶中心的產品定位應該是:賬戶中心一個用戶信息平臺,匯集用戶各類信息為畫像及數據挖掘服務,同時也是各項業務的入口。但也只是入口,不應跟具體業務耦合太高,更不應該直接參與具體業務實現。
溝通溝通溝通
如果有機會再處理一遍這次事件,我覺得步驟應該是這樣的:
- 充分了解現狀及問題所在,了解各方關注點;
- 確定方案,本次按應急處理,召集各相關人員包括施壓的大領導們申明利害,后續把梳理產品流程,拉回到正常軌道來。
就這樣!
本文由 @淺沙 原創投稿,并經人人都是產品經理編輯。未經許可,禁止轉載。
評論
- 目前還沒評論,等你發揮!