做個懂產(chǎn)品的程序員
大概六年前，我在一家名為“抓蝦”的在線 RSS 閱讀網(wǎng)站工作（如果你不清楚 RSS 閱讀網(wǎng)站是什么，可以參考 Google Reader）。同為 RSS 閱讀器，抓蝦的未讀數(shù)是精確的數(shù)字，明確告訴用戶“你還有 2456 篇文章沒讀過”，Google Reader 則顯示為 10+、100+ 等形式，告訴用戶“我還有一千多篇文章沒讀過”。表面看來，這只是一種差異，但產(chǎn)品人員提出 10+、100+ 的形式更好，原因我如今記不太清楚了，似乎是這樣給用戶的心理壓力更小，如果數(shù)字比較大，用戶不需要知道確切的數(shù)值，所以閱讀體驗更好。雖然廣大程序員并不認(rèn)同，因為分工不同，還是完成了這個功能。“可想而知”的是，這個功能上線之后并沒有帶來正面的用戶反饋。不過更好玩的是，過了一周，Google Reader 的未讀數(shù)竟然改成了精確數(shù)字！
前幾周，我在 twitter 上說起這個故事，本來只是湊興當(dāng)個玩笑，大家的反應(yīng)卻出乎我的意料，因為大都是對產(chǎn)品經(jīng)理一邊倒的負面評價。我又想起在自己的一個朋友，他在某個以產(chǎn)品經(jīng)理文化著名的大公司做開發(fā)，談到理想的工作，他的要求就是“找個產(chǎn)品經(jīng)理少的地方”。這樣看來，程序員和產(chǎn)品經(jīng)理的矛盾，是普遍而且深刻的。
按常理推斷，如果合作雙方處于這種別扭的狀態(tài)，就無法得出滿意的結(jié)果。但究竟是什么原因造成了這種別扭的狀態(tài)呢？在我看來，重要原因之一就在于工作的割裂：在很多公司里，程序員和產(chǎn)品經(jīng)理是“鐵路公安各管一段”，程序員只管實施，根本不關(guān)心也不用關(guān)心產(chǎn)品給誰用，怎么用；而產(chǎn)品經(jīng)理只管規(guī)劃，根本不關(guān)心技術(shù)上能不能實現(xiàn)，實現(xiàn)代價多大。程序員就像***，只會走路不會看路；產(chǎn)品經(jīng)理就像跛子，只會看路不會走路。所謂分工協(xié)作，就是跛子指揮***，大家一起逃命。但產(chǎn)品是個有機的整體，而“逃命”只是個簡單的、目的明確的短期行為，跛子-***這種的配合，即便真能逃命，也不適合做產(chǎn)品。
退一步說，即使產(chǎn)品真的像逃命那么簡單，跛子只管跑路，跛子只管指揮，就能順利逃命？就能每次都順利逃命？答案顯然是否定的，所以在真實世界中我們經(jīng)?？吹?，這種***-跛子的組合，經(jīng)歷過幾次失敗，往往大家都會不甘心，要越界工作，于是***也會去離開，跛子也會勉強走幾步——程序員踢開產(chǎn)品經(jīng)理或者陽奉陰違，產(chǎn)品經(jīng)理挽起袖子親自寫代碼。這樣的事情，不是也常有發(fā)生嗎？
據(jù)我觀察，要想真正做出好的產(chǎn)品，程序員和產(chǎn)品經(jīng)理對于最終目標(biāo)的認(rèn)識必須相當(dāng)一致，而且必須打破“井水不犯河水”的分工局面。換句話說：在最終目標(biāo)認(rèn)識一致的前提下，產(chǎn)品經(jīng)理必須有技術(shù)思維，必須了解哪些能實現(xiàn)，哪些不能實現(xiàn)，怎樣實現(xiàn)起來困難，怎樣實現(xiàn)起來容易；程序員也必須有產(chǎn)品思維，能超越單純的實現(xiàn)，從更廣闊的角度去理解和看待自己的工作。因為我自己有較多程序員方面的經(jīng)驗和思考，所以下面只講解程序員應(yīng)當(dāng)具有的產(chǎn)品意識。
程序員具有產(chǎn)品意識，是非常有益而且非常必要的，原因至少有三條。
***，優(yōu)秀的產(chǎn)品經(jīng)理是非常少的。我認(rèn)為，當(dāng)產(chǎn)品經(jīng)理既需要天賦，也需要訓(xùn)練，他起碼應(yīng)當(dāng)具備嚴(yán)密的思維，在產(chǎn)品尚未開發(fā)出來之前，可以在大腦里全面地推敲；具備良好的溝通能力，能將關(guān)于產(chǎn)品的設(shè)想和規(guī)劃準(zhǔn)確傳達給相關(guān)各方；具備一定的數(shù)據(jù)分析能力，以便客觀判斷用戶的反饋；如果再加上一點技術(shù)背景，就更好了。不幸的是，目前這樣的產(chǎn)品經(jīng)理少之又少，相當(dāng)部分的產(chǎn)品經(jīng)理都是拍腦袋派（我想到了，這個應(yīng)該這么辦）、唯上派（不管有沒有道理，這是老板的要求），甚至就干脆就是“功能經(jīng)理”。如果程序員沒有產(chǎn)品意識，又不幸與這樣的產(chǎn)品經(jīng)理搭配工作，結(jié)果往往稀里糊涂就掉到坑里，更重要的是，連反思提高的余地都沒有。
第二，產(chǎn)品經(jīng)理是不能面面俱到的。一款產(chǎn)品必然有許多個層面和方面，最終都是由程序員（開發(fā)人員）一點點完成的，產(chǎn)品經(jīng)理即便涉及了實現(xiàn)過程，也不可能事無巨細、處處負責(zé)。而用戶對產(chǎn)品的體驗是全方位的，許多細節(jié)可能產(chǎn)品經(jīng)理注意不到、想不到，用戶卻可能非常在意。如果負責(zé)實現(xiàn)的工程師在這些方面多一點思考，通常可以起到錦上添花甚至更重要的作用。前段時間網(wǎng)絡(luò)上流傳一篇文章，講解亞馬遜顯示分類菜單比其它網(wǎng)站更迅速的原理，這個改進就是工程師思考的結(jié)果。
第三，開發(fā)工作其實是更廣義的“產(chǎn)品”的一部分。好的產(chǎn)品離不開好的開發(fā)，局限于好的開發(fā)卻不能保證有好的產(chǎn)品。這里不妨對大家都熟悉“三個工匠”的故事做個變通：城市由設(shè)計師規(guī)劃，工匠只負責(zé)砌磚，但是只甘心于自己干活對外不聞不問的工匠，與知道“這是美麗城市一部分”而思考的工匠相比，后者營造出美麗城市的可能性顯然更高，工作所創(chuàng)造的價值也更大。
所以，如果程序員想做出一款用戶滿意的產(chǎn)品，與其期待遇到巨細靡遺的靠譜的產(chǎn)品經(jīng)理，還不如培養(yǎng)自己的產(chǎn)品意識，超越單純的實現(xiàn)去思考問題。而且產(chǎn)品意識培養(yǎng)起來并不難，除了正規(guī)閱讀學(xué)習(xí)產(chǎn)品方面的資料，平時哪怕多思考“誰會在什么情況下怎么使用我的產(chǎn)品”，都會有不小的進步。這樣的例子，我就親身經(jīng)歷過。
那其實是個很小的項目——在倉庫的分撿流水線上，操作員必須復(fù)核確認(rèn)每個包裹的重量。在業(yè)務(wù)量不大的時侯，可以將每天的工作結(jié)果保存到一張 Excel 表格即可。業(yè)務(wù)增長之后這種方式顯然不行，需要有自動化的軟件來協(xié)助操作員。這是一個非常簡單的 GUI 程序，用戶登錄、讀取包裹信息、確認(rèn)核重信息都已經(jīng)有對應(yīng)的 API，條碼掃描槍和電子秤的數(shù)據(jù)讀取也有現(xiàn)成的接口，要做的只是將它們關(guān)聯(lián)起來即可。但是負責(zé)開發(fā)的程序員在程序之外，還著重考慮了好幾個問題：
·怎樣確認(rèn)復(fù)核的重量是準(zhǔn)確的？電子稱需要一段時間才能穩(wěn)定稱量，所以需要多次采樣才能確認(rèn)最終重量，而且這個“多次”是可以設(shè)置的。
·怎樣通知操作員重量已經(jīng)確認(rèn)？最初想法是讓操作員觀察軟件上的數(shù)值穩(wěn)定下來，后來改為用顏色標(biāo)注，未穩(wěn)定之前以紅色顯示，穩(wěn)定之后以綠色顯示。更進一步的想法是加以聲音通知。
·不同電子秤的誤差如何處理？答案是在軟件的設(shè)置里新增“校正”的選項，這樣即便電子秤自身暫時無法校正，軟件也可以進行校正。
·如果數(shù)據(jù)交互時網(wǎng)絡(luò)通訊失敗怎么辦？答案是可以同步或異步交互，通訊失敗的結(jié)果可以先暫存在本地，稍后重新上傳。
這些問題都不是單純的技術(shù)問題，而是產(chǎn)品方面的問題。但不依賴產(chǎn)品經(jīng)理，積極思考的程序員自己就可以解決。而且最終結(jié)果是，這個完全由程序員開發(fā)的軟件得到了用戶（操作員）的認(rèn)可，使用起來可靠方便，日后的修改只是增加新的功能，應(yīng)用方面完全不必改動。我相信，開發(fā)這個軟件的程序員，以后無論是單干還是與產(chǎn)品經(jīng)理配合，能取得成就的機會都要比沒有產(chǎn)品意識的程序員更大。
我有個做金融的朋友，從小參加過不少信息奧賽培訓(xùn)，業(yè)余也寫給自己寫過不少小程序。有一天他問我：“你說程序員的工作有那么高級嗎？不就是寫寫代碼？我也會不少語言，我也寫過不少程序，沒什么了不起的。”我說：“那么，你有沒有寫過給別人用的程序呢？”。他想了一會兒說：“好吧，你贏了。”
