一、事件經過

目前在公司接手一個賬戶中心的產品，產品形式是預裝到手機里的客戶端，類似于小米的“我的小米”，此產品收集終端用戶最基礎的信息，為后續(xù)開展業(yè)務統(tǒng)計、對外合作等提供數據依據。

公司是上市公司，部門龐大，合作方也是大上市公司，雙方勾搭對接的環(huán)節(jié)是這樣的

1. 業(yè)務<–>業(yè)務
2. 產品<–>產品
3. 研發(fā)<–>研發(fā)

中間流程環(huán)節(jié)太多，每次郵件大票人馬，最后干脆讓研發(fā)直接對接。我方業(yè)務及領導對對方基本上是有求必應，發(fā)展至最后，到了對方業(yè)務人員直接讓我方研發(fā)改代碼的程度。

哥接手后，某日對方業(yè)務部門要求我方客戶端直接給他們服務器傳參數，我拒絕了，理由如下：

1. 流程居然是：我方客戶端–>海外AWS服務器–>服務系統(tǒng)A（上海）–>服務系統(tǒng)B（深圳）–>合作方客戶端
2. 客戶端是直接面向用戶的，修改要重新發(fā)版引導用戶升級，這對用戶是極大的干擾，且升級覆蓋率也不高；
3. 業(yè)務邏輯盡可能放服務端實現，客戶端負責業(yè)務展示應盡量簡單以適應業(yè)務變化；
4. 就不要扔到客戶端來做，要解耦，況且還是跟外部合作方的系統(tǒng)耦合，簡直沒有天理！

作為一只有原則的汪，底限是要堅持的，業(yè)務邏輯是會變更的，一旦開了口子，往后就是無盡的深淵，哥有理有節(jié)，不干！您請找我方業(yè)務轉接到服務端去~ 以為事情就此結束，接著了解到業(yè)務部門推不動中間環(huán)節(jié)的兩個服務端部門，然后呢，層層郵件升級給各種叫大領導的生物，在一封轉到我這只有一句“請客戶端產品xxx務必盡力支持！”的回復后，哥的原則就像多年前堅守的節(jié)操一樣，瞬間碎了……真實憋屈……這通常就是大公司里撕逼的常見方式，苦笑。

二、事件后果

1. 業(yè)務部門抱怨產品部，就一個小需求都做不好；
2. 研發(fā)同事極度苦悶，需求一時一個變，毫無規(guī)劃，今天改了明天又反復；
3. 產品狗也郁悶，被業(yè)務和研發(fā)兩頭夾著，里外不是人；
4. 合作方也有抱怨，貴方效率這么挫，還要不要玩耍了？

三、原因分析

1. 系統(tǒng)支撐缺乏規(guī)劃，前期系統(tǒng)設計可擴展性差，導致各個子系統(tǒng)分散各地；
2. 歷史債，公司大了，部門割裂嚴重各自都是屁股決定腦袋，各種交接留下的爛攤子；
3. 溝通問題，業(yè)務部門做事方式實在太粗糙粗暴，只管拉上級施壓而不考慮為何實現困難，鴨梨下來產品研發(fā)也只能頭痛醫(yī)頭腳痛醫(yī)腳；
4. 產品缺少定位無規(guī)劃，一個需求是否要加上，什么時候加上，以怎樣的形式加上，都需要用產品定位來衡量決定。定位混亂各部門就都想來插一腳加幾個需求，于是乎系統(tǒng)最后臃腫不堪，七零八落再做減法就難了；

四、反思與改進

產品定位始終要明確

產品必須有一個明確的定位，不忘初心，也就是開發(fā)這產品時的需求出發(fā)點必須堅持。如果需求點已變，也要清楚變成了什么，然后才能圍繞這一定位來構造產品。對于產品需求來說，定位不清，何以加為？產品定位，是衡量新需求的標尺。賬戶中心的產品定位應該是：賬戶中心一個用戶信息平臺，匯集用戶各類信息為畫像及數據挖掘服務，同時也是各項業(yè)務的入口。但也只是入口，不應跟具體業(yè)務耦合太高，更不應該直接參與具體業(yè)務實現。

溝通溝通溝通

如果有機會再處理一遍這次事件，我覺得步驟應該是這樣的：

1. 充分了解現狀及問題所在，了解各方關注點；
2. 確定方案，本次按應急處理，召集各相關人員包括施壓的大領導們申明利害，后續(xù)把梳理產品流程，拉回到正常軌道來。

就這樣！

本文由 @淺沙 原創(chuàng)投稿，并經人人都是產品經理編輯。未經許可，禁止轉載。