女生天生就是產品經理

知識 01-18

女生天生就是產品經理

打開今日頭條，查看更多圖片

作者 | 李輝
責編 | 郭芮

大蒜，牛油果，西葫蘆，包菜，雞蛋，西紅柿，雞腿，三文魚，土豆，洋蔥，黃瓜，杏仁干……這是我買菜前在手機里列出的購物清單。我覺得我已經比很多相信自己腦子記得住、卻常常丟三落四買了醬油忘了醋的理工男靠譜了。畢竟我買東西都是一樣不少買回去的，但是每次回家還總是被老婆數落，這個不對那個不滿意的。

有一天我終於忍不住爆發了，說那你給我個購物清單吧，到底要買什麼？！然後她的清單發來了：

大蒜一掛，要 Bio（有機）的；
西葫蘆一根，注意不要破損的，指甲印太多的；
雞蛋一盒6個裝，黃殼，不要白殼；
西紅柿Bio 650g 8個裝那種，買前捏一下，軟的不能要；
兩個雞腿，500g左右盒裝，盒子上要標「非轉基因」；
三文魚200g，不要冷凍，要冰鮮的，去鮮魚櫃檯買；
洋蔥一包，白皮圓形大個的，不要紅皮；
小脆皮黃瓜，9cm左右的買6根；
杏仁干，250g一袋，碳水含量低於4%；
……

PS: 所有上述食品都要看保質期。

你可能要問：土豆不就一種嗎，不就是馬鈴薯，洋芋？那你太天真了，德國是個有200多種土豆、能把土豆吃出花來的國度。

我在超市裡盯著這個採購清單，突然無比後悔剛才的衝動。本來作為直男，採購的速度是以光速計算的，只要找到貨架位置，刷刷刷把東西扔進購物車就行。現在我必須一個個按規定檢查，在一排排同類但不同生產商的貨中挑出符合規定的東西，還要看保質期。採購速度直接翻了五倍，本來一刻鐘左右我就應該出現在收銀台的，現在快一小時了我還在乾果區找碳水含量低於4%的杏仁干，最後抓了一個路過的店員一起找了半天才在零食區發現。

好不容易採購完畢回家後，心想這次總該不會不滿意了吧。結果棋差一著，還是被抱怨了：那盒雞蛋有一個蛋破了。我按習慣是打開盒子，掃視一下外殼的，但我萬萬沒想到，那個蛋底部破了。所以今後清單上又多了個標註：雞蛋檢查盒子底部，看有沒有蛋液滲出。

回歸正題

男人的思維方式，大多數情況下是直線式、收斂式、簡單式的，他們天生排斥「不必要」的修飾和麻煩。我敢打賭，99.999%程序猿的購物單和我一樣。那些各種各樣的「細節」和「形式」，在女人看來無比重要的細枝末節，在多數男人看來，只是浪費時間和吹毛求疵的表現。

這和軟體開發有什麼關係？如果把這份購物清單看做客戶發給你的產品需求，或者一份軟體設計文檔呢？

產品需求分析

因為工作領域關係，經常有朋友找我諮詢一些軟體項目的問題，比如：

開發一個教育類App多少錢？
做一個網店多少錢？
我想做一套在地圖上實時顯示數據並且分析的可視化平台，開發周期一般多久？
我需要一套採購物流系統，開發周期一般多久？

我的回答一般都是以這句話反問：

我問一下，你所在城市房子多少錢一套呀？

別人一般回答：

這要看房子大小，朝向，哪個區買的，差別很大啊。

我會接著說：

做軟體和買房子一樣的，按軟體實際的需求和開發構架的差別，開發周期和費用也是有很大的變化區間的。

然後再一步步細問對方的實際需求，最終可以得出一個大概的項目開發預算和時間預估。

需求設計文檔

我平時習慣在談項目初期，先做業務和構架需求分析，但還是時不時一個方面沒考慮到，就入了坑。曾經有一個做產品經理的朋友找我合作一個項目：客戶要做一個電商系統，項目第一版的要求很簡單，只要能運行正常購物流程即可：

電腦和手機可以訪問；
用戶可以郵件註冊，也能微信註冊；
有產品列表展示，購物車，訂單，用戶掃二維碼支付即可；
用戶界面自己決定，以後可以換模板；
管理員後台能管理產品，批量上傳訂單，上傳上傳圖片，查看客戶訂單。

我自己手頭有一套完整的基於Spring的CMS開發框架，包括前端API模塊、後端管理模塊、用戶許可權模塊、數據持久化模塊等等，所以上面這些按估算很容易搞定。第3點裡的產品，購物車、訂單分成三個小模塊，做個二維碼支付也不是大問題。而且第一版只要基本功能，不用考慮任何的分散式，大流量，並發搶購等今後做大了要考慮的問題，無需過度設計。

我這個朋友也是個資深程序猿出身，所以我也很放心他作為客戶傳話筒，所有需求遵循KISS原則，但保留基本的模塊擴展性。討論過後，這第一版的構架圖簡單如下圖所示，我也寫了個相應的需求列表。

女生天生就是產品經理

我們這邊技術層面一切OK，客戶那邊看起來也很佛系，對於我們寫的第一版的基本需求列表沒有異議，事情似乎向著陽光的方向發展。我想到了所有技術和構架上能想到的點，卻單單漏了一點：

朋友是個男性產品經理。

所有該談的事情談定了後，最終朋友從客戶那裡得到了一個產品需求細節文檔：

用戶分級別，享受不同折扣率；
產品含品牌屬性；
產品歸於相應的一級和二級目錄；
產品由不同供貨商提供；
產品含顏色和大小等屬性；
產品分官方價格和折扣價格，訂單扣費按當天折扣；

支付和交易需要後台管理；
產品按重量和大小分不同的物流渠道以及關稅申報登記；
訂單最終價格是折扣後價格，加上動態計算的物流價格；
訂單表含發票和發貨模塊，同時擴展物流模塊；
發票模塊需要調用一個第三方發票在線生成系統；
支付模塊並不和支付寶直接對接，而是和一個境外第三方支付機構；
特價，打折模塊；
官方Blog模塊；
若干其它模塊......

如果真正做過電商系統的朋友，看到第5點可能會心裡一顫，這個就是要做一個完整的SKU系統啊！SKU是大型電商系統的基礎，複雜度不言而喻。按之前的開發預算和時間預估，這麼多關聯模塊根本不可能完成。

把朋友電話里暴揍一頓後，按客戶的產品需求，產品構架思維導圖變成了這樣。

女生天生就是產品經理

我得到的教訓就是：

在沒有客戶的詳細需求設計文檔之前，絕對不要做任何項目估算，更別提動手開發！

看到這，各位是不是很容易聯想到你們的男性產品經理或是項目經理，和客戶開個會後，就急沖沖地列出一份新的Feature所需大致功能，然後馬上發郵件或者口頭傳述給開發團隊，程序員直接就開始開發。

這裡可沒有性別歧視，我工作中遇到的男性產品經理或程序猿在做功能設計文檔時，常常沒有女性產品經理那麼細心和耐心。這種文檔不明確就開發的做法，看似敏捷快速迭代，但做出來的功能往往和客戶所需相差甚遠，最後返工付出的代價難以計算。

分析細節標準

我們公司有個客服系統，客戶在使用產品遇到問題時，會郵件或者電話給客服，客服錄入系統後會分配給相應研發團隊。這是一個常見的一問一答流程，我們的反饋會通過客服發給客戶。

客戶：我App突然登陸不了。
研發：請問您用的系統版本是什麼？App的版本是什麼？登陸時發生什麼錯誤？

客戶：我的系統版本是xx，App版本是xxx。輸入用戶民和密碼後，登陸界面跳轉到瀏覽器，然後就沒反應了。
研發：請問瀏覽器里顯示什麼，有沒有錯誤代碼，是什麼時候登陸的？
客戶：瀏覽器里顯示「Request Error」，時間是xxxx。
研發：請嘗試清空App的緩存，以及瀏覽器的緩存。步驟如下……….
…….

有沒有感覺這樣的溝通成本其實很高，客戶提供的信息模糊，研發問得也不盡清晰。這裡和產品需求文檔類似，到底細節的標準在哪？

我建議我們程序猿在做需求分析時，先向你的女朋友或妻子學習如何分析細節，比如分辨下面這些：

女生天生就是產品經理

呃，好吧，當我沒說……

我的建議是需求也業務拆分儘可能詳細，考慮周全，最好能覆蓋今後絕大部分的測試用例。

比如需要開發一個用戶註冊登錄的功能，從某個男性產品經理嘴裡說出來可能就一句話：給我開發一個用戶系統，能註冊，能登錄，三天夠不夠？

從女性角度，她們習慣把一件簡單的事情變的複雜化——如果這裡的簡單並沒有你想像的那麼簡單呢？

如果你足夠細心，就需要和客戶做仔細溝通後達成共識，最終交付給研發團隊的應該是如下一份需求Kickoff列表（只是舉例，考慮並非100%全面）：

用email註冊還是用戶名註冊？
如果是用戶名，最短几位，最長几位，允許特殊字元嗎，密碼最短几位，最長几位？
如果email註冊，是密碼一起填寫註冊，還是有驗證步驟？
點擊註冊前，是否展示用戶協議。不勾選顯示什麼錯誤？
如果有驗證步驟，需要手機驗證嗎？如果要，要對接哪個API，驗證碼長短，過期時間？
手機驗證碼發送時間間隔，以及發送頻率限制；
如果只需郵箱驗證，發送給用戶的激活鏈接有效期多久，過期了怎麼辦？

驗證這個業務要不要持久化？
發送激活郵件的模板，HTML還是txt，誰來設計？
激活鏈接過期後，顯示什麼錯誤，然後跳轉到驗證郵件重發界面？
激活鏈接激活後，顯示什麼信息，自動跳轉到哪個界面，比如設置密碼界面？
密碼設置允許特殊字元嗎，最短几位，最長几位？
密碼入庫前採用何種加密演算法，以哪個屬性作為salt？
用戶密碼設置成功後，跳轉哪個界面，顯示什麼消息？
用戶後期允不允許改用戶名或註冊郵箱嗎？
用戶後期修改密碼是否需要郵件或手機驗證？
允不允許單用戶多地點登錄，如果不允許，顯示什麼錯誤自動登出？
支不支持單點登錄SSO？
要不要開發移動端App，需不需要提供註冊和登錄API？
API需不需要支持OAuth2，或是Token？
登錄構架是單體還是需要考慮分散式Session？
用戶許可權系統設計，多Role或是單Role設計？
鑒權系統設計是無狀態還是有狀態？
用戶自己或者管理員關於許可權系統的操作流程是什麼？
有沒有第三方SNS介面註冊接入，如果接入，需不需要同步頭像，需不需要同時必須新建本地賬號。
第三方SNS接入的流程，回調介面，以及界面設計；
相關前端和App界面設計圖，錯誤對話框UI；
......