產(chǎn)品經(jīng)理的自我反省
本文作者君分享了一個需求實現(xiàn)的曲折經(jīng)歷。故事的開始并不復雜,但因為自己的操作掉坑最后做出了很多額外的事情。一起來看看。
這一個多月以來,在老業(yè)務基礎上,做了一個業(yè)務邏輯不復雜,但是涉及N多業(yè)務方的需求(我這邊屬于是數(shù)據(jù)上游部門,需要我方下發(fā)給其他各業(yè)務線)。方案設計、UIUE、需求宣講、研發(fā)排期……前面一切都比較順利,還咨詢了運營、風控等業(yè)務部門??傊?,在需求的第一周,一切都在計劃之中進行。第一周我們的需求溝通群算上領導僅有9人,可到后來,到了項目上線那天,群里面竟然有了64人。這中間差出來的55人,的確值得靜下來反思下。
一句話總結這55人增量的原因,就是“前期調研做的不到位,把需求想簡單了”。需求涉及到手機客戶端、PC端,還需要考慮到適應各業(yè)務線的業(yè)務規(guī)范和上線標準。其實這些在動手之前也已經(jīng)考慮到了,歸根結底是沒能從技術實現(xiàn)角度好好梳理各技術部門的配合流程和路徑。
靜下心來回想,作為需求發(fā)起人和負責人,我的確要承擔主要責任。由于涉及到客戶端開發(fā)就要面臨著上線日期要受限于固定的發(fā)版日期(iOS客戶端的改動需要在蘋果商店里上架、安卓客戶端的改動需要在各手機廠商應用商店以及Google Play商店上架),所以在需求調研前期,我們主動放棄了一些涉及到客戶端修改的方案,選擇了服務端改造的方案。事實也證明了欲速則不達,在方案調研前期就應該選擇最優(yōu)方案而不是“最速方案”。
至于我們?yōu)槭裁礇]意識到這個問題,其實在需求初期我也做了簡單的調研,就是找了兩個業(yè)務場景對應的客戶端研發(fā)同學,在辦公IM上簡單咨詢了下本次需求的實現(xiàn)方案在客戶端實現(xiàn)效果上會不會有什么紕漏。打字方式簡單咨詢換來的結論通常也是“應該”性結論。錯就錯在了我拿著“應該”性結論當了令箭,自以為是的繼續(xù)推動需求開發(fā)工作。
時間來到了提測時間,需求建立到提測時間之間間隔了一個五一假期。雖然節(jié)前節(jié)后食堂通常冷冷清清,但好在我們假期可以線上加班。之所以說需求本質上并不難,是因為時間幾乎都用在新上手的研發(fā)同學梳理代碼邏輯、掉進坑里再從坑里爬出來??傊_發(fā)過程雖有波折,但也趕上了提測時間。?????????
測試工作異常艱難,但如果結果是好的,我個人愿意與測試同學共患難??蓡栴}就在于需求沒有達到預期效果(這里有個疑問到現(xiàn)在都沒解決,事實上研發(fā)同學自測是沒問題的,可為什么在測試環(huán)境、仿真環(huán)境里就會出現(xiàn)各種各樣奇怪的問題???)。??
在需求前期調研時,我們設計的技術實現(xiàn)路徑圖是這樣的:
而本次需求的最終版技術實現(xiàn)路徑圖是這樣:
對比一下可以發(fā)現(xiàn),網(wǎng)關平臺和客戶端是我們在需求之初沒考慮到的地方。測試同學在測試時發(fā)現(xiàn),在客戶端上實現(xiàn)的效果不對。有問題就得解決問題,于是技術同學開始排查。沒有甩鍋的意思,因為是老業(yè)務,代碼邏輯確實很古(shǐ)早(shān),而且涉及到的業(yè)務線很多。很多之前負責這部分產(chǎn)研同學都已經(jīng)另謀高就甚至換了幾茬,再加上提測之后很多技術同學就已經(jīng)投身到了其他需求,所以排查問題之路就走的格外艱辛。
終于我們定位到了是客戶端上缺少部分參數(shù)導致的問題。回想之前的“應該”性結論,我就應該在需求開始之前,預定個最大的會議室,把涉及到的全部業(yè)務方產(chǎn)研同學都拉過來修煉心法,后來也確實這樣做了(超大的會議室,一個人循環(huán)搬椅子),但是“后來”就意味著時間緊促和氣氛緊張。
定位到了問題,再往上捋發(fā)現(xiàn)各業(yè)務線服務端和客戶端中間還隔著一道網(wǎng)關平臺。沒辦法,重新拉回,跪求相關產(chǎn)品同學協(xié)調排期,組織相關技術同學把問題解決。由于上線的日子拍在了有意義的日子,有意義的日子不能變,所以上線的日子也變不了。在測試過程中發(fā)現(xiàn)大雷再找女媧補天的緊張感無異于到了機場發(fā)現(xiàn)身份證沒帶。更生動的例子是小學時上課不好意思舉手去拉屎,結果下課沖到茅坑,在雙腳跨過那道溝壑之時體重不發(fā)生變化的一瀉千里。爽是爽了,但是上課鈴馬上就要響起,卻要擔心如何洗褲子和找一條新的褲子。?????????
求爺爺告奶奶,組織封閉開發(fā)后萬幸終于解決了問題??捎钟龅搅诵碌膯栴},由于最后確定的技術實現(xiàn)路徑圖涉及到了很多技術方,問題修復后的測試工作又遇到了難點。首先每次測試環(huán)境的配置都需要不短的時間,其次各業(yè)務對應的研發(fā)同學需求開發(fā)時間前后不一導致測試同學無法集中測試需求點。而且發(fā)現(xiàn)了問題,通常需要多方技術同學聯(lián)合修改和調試。結果就是上線之前那幾天,測試同學每天都加班至后半夜……???????????
此刻我在加班畫ppt,分析需求上線前后數(shù)據(jù)情況,我意識到需求也上線一周了。ppt里我啥都不想畫,我現(xiàn)在就想把反思寫進去。的確我前期調研工作沒做好,把問題考慮的簡單了,我應該在前期調研階段把所有可能的問題都排查好,把風險都考慮到。
此外我還想反思點兒其他的。發(fā)現(xiàn)問題不逃避,不遺余力的解決問題是打工人應該做的。加不加班的我也沒啥所謂,一個人閑著我的精神也不太正常。我要反省之處在于,求爺爺告奶奶是不對的,做一個無理要求的傳聲筒也是不對的,對事又對人就好比又當又立也是不對的。我對我最愛的人和最愛我的人都很自我,經(jīng)常也會把最負面的情緒給到她們,也會經(jīng)常沒有耐心,所以我也不必也再不會每次都真誠且懷揣著善意面對應該把本職工作做好的引號同事們了。一想到之前對我最愛的人和最愛我的人都很自我,甚至沒做到每次都真誠,收不住負面情緒,就覺得挺對不住他們的??尚Φ氖俏疫€得組織項目復盤,總結并規(guī)避本次需求中發(fā)現(xiàn)的問題。
作者:產(chǎn)品小吳,公眾號:產(chǎn)品小吳
本文由 @產(chǎn)品小吳 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉載。
題圖來自Unsplash,基于CC0協(xié)議。
該文觀點僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務。
產(chǎn)品總會把鍋攬到自己身上,對自己好一點哦