餘晟：做個懂產品的程式設計師

　　大概六年前，我在一家名為“抓蝦”的線上RSS閱讀網站工作（如果你不清楚RSS閱讀網站是什麼，可以參考Google Reader）。閱讀器都需要顯示當前使用者的未讀數，抓蝦的做法是給出精確的數字，明確告訴使用者“你還有2456篇文章沒讀過”，Google Reader則顯示為10+、100+等形式，告訴使用者“我還有十多篇/一千多篇文章沒讀過”。初看看來，這只是一種普通的差異，但產品人員提出10+、100+的形式更好，原因我如今記不太清楚了，似乎是說這樣給使用者的心理壓力更小，因為如果數字比較大，使用者就不需要知道具體的數值，所以閱讀體驗更好。雖然程式設計師都並不認同這種理論，但因為分工不同，最終做開發的大夥還是完成了這個功能。“可想而知”的是，這個功能上線之後並沒有帶來明顯的正面反饋。更好玩的是，過了一週，Google Reader的未讀數竟然改成了準確數字！

　　前幾周，我在twitter上說起這個故事，本來只是湊興當個玩笑，收到的反應卻出乎我的意料，因為反饋大都是對產品經理一邊倒的負面評價。我又想到自己的一個朋友，他在某家以產品經理文化著名的大公司做開發，談到理想的工作，他的要求是“找個產品經理少的地方就好了”。這樣看來，程式設計師和產品經理的矛盾是普遍而且深刻的。

　　按常理推斷，如果合作雙方處於這種彆扭的狀態，必然無法得到滿意的工作成果。但究竟是什麼原因造成了這種彆扭呢？我仔細思考之後認為，重要原因之一就在於工作的割裂：在很多公司裡，程式設計師和產品經理是“鐵路公安，各管一段”，程式設計師只負責實施，根本不關心也不用關心是誰在什麼情況下用這個產品，用來幹什麼；產品經理只負責規劃，根本不關心技術上能不能實現，也不關心實現代價多大。估計在這樣安排的人心裡，程式設計師就像瞎子，只會走路不會看路；產品經理就像跛子，只會看路不會走路。所謂分工協作，就是跛子指揮瞎子，大家一起逃命。然而隨便想想就知道，產品是個有機的複雜整體，“逃命”只是簡單的、目的明確的短期行為，跛子-瞎子這種的配合，即便真能逃命，也不適合做產品。

　　退一步說，即使產品真的像逃命那麼簡單，跛子只管跑路，跛子只管指揮，這樣的組合就能順利逃命？就能每次都順利逃命？答案顯然是否定的，所以在真實世界中我們經常看到，這種瞎子-跛子的組合，經歷過幾次失敗，往往大家都會不甘心，要越界工作，於是瞎子也會去摸索，跛子也會勉強走幾步——程式設計師踢開產品經理或者陽奉陰違，產品經理挽起袖子親自寫程式碼。這樣的事情，不是也常有發生嗎？

　　據我觀察，要想真正做出好的產品，程式設計師和產品經理對於最終目標的認識必須相當一致，而且必須打破“井水不犯河水”的分工局面。換句話說：在最終目標認識一致的前提下，產品經理必須有技術思維，必須瞭解哪些能實現，哪些不能實現，怎樣實現起來困難，怎樣實現起來容易；程式設計師也必須有產品思維，不能只關心實現，必須從更廣闊的角度去理解和看待自己的工作。這樣配合起來，才有可能做出不錯的產品。因為我自己有較多程式設計師方面的經驗和思考，所以下面只講解程式設計師應當具有的產品意識。

　　程式設計師具有產品意識，是非常有益而且非常必要的，原因至少有三條。

　　第一，優秀的產品經理是非常少的。包裝出來的“賈伯斯”的例子誤導了太多的人，似乎產品經理可以不講道理，靠天賦和直覺即可。其實真正的產品經理既需要天賦，也離不開訓練，他起碼應當具備嚴密的思維，在產品尚未開發出來之前，可以在大腦裡全面地推敲；具備良好的溝通能力，能將關於產品的設想和規劃準確傳達給相關各方；具備一定的資料分析能力，以便客觀判斷使用者的反饋；如果再加上一點技術背景，就更好了。不幸的是，目前這樣的產品經理少之又少，相當部分的產品經理都是拍腦袋派（我想到了，這個就應該這麼辦，你別多問）、唯上派（你別問我說的有沒有道理，老闆就是這麼要求的），甚至就乾脆就是“功能經理”。如果程式設計師沒有產品意識，又不幸與這樣的產品經理搭配工作，結果往往稀裡糊塗就掉到坑裡，更可惜的是，連反思提高的餘地都沒有。

　　第二，產品經理是不能面面俱到的。一款產品包含有許多個層面和方面，它們最終都是由程式設計師（開發人員）一點點完成的，產品經理即便涉及了實現過程，也不可能事無鉅細、處處負責。另一方面，使用者對產品的體驗是全方位的，必然有許多細節是產品經理注意不到也想不到的，使用者對它們卻可能非常在意。如果負責實現的程式設計師在這些方面多一點思考，往往可以起到錦上添花甚至四兩撥千斤的作用。前段時間網路上流傳一篇文章，講解亞馬遜顯示分類選單比其它網站更迅速的原理，這個改進就是工程師自己思考的結果。

　　第三，開發工作其實是更廣義的“產品”的一部分。好的產品離不開好的開發，只有好的開發卻不能保證有好的產品。想做出好的產品，開發人員當然需要理解產品。這裡不妨對大家都熟悉“三個工匠”的故事做個變通：規劃城市的是設計師，工匠只負責砌磚，但是隻甘心於自己幹活對外不聞不問的工匠，與知道“這是美麗城市一部分”並積極思考的工匠相比，後者營造出美麗城市的可能性顯然更高，工作所創造的價值也更大。

　　所以，如果程式設計師想做出一款使用者滿意的產品，與其期待遇到鉅細靡遺的靠譜的產品經理，還不如培養自己的產品意識，超越單純的實現去思考問題。產品意識培養起來並不難，除了正規閱讀學習產品方面的資料，平時哪怕多思考“誰會在什麼情況下怎麼使用我的產品”，都會有不小的進步。這類的例子我親眼見過，下面舉個很小很簡單的例子。

　　在倉庫的分撿流水線上，操作員必須複核確認每個包裹的重量。在業務量不大的時侯，將每天的工作結果儲存到一張Excel表格即可。但是業務增長之後，這種方式顯然行不通，需要有自動化的軟體來協助操作員。開發過軟體的人都知道，要做的是個非常簡單的GUI程式，使用者登入、讀取包裹資訊、確認核重資訊都已經有對應的API，條碼掃描槍和電子秤的資料讀取也有現成的介面，將它們關聯起來即可。但是負責開發的程式設計師在程式之外，還著重考慮了好幾個問題：

• 怎樣確認複核的重量是準確的？電子稱需要一段時間才能穩定稱量，所以需要多次取樣才能確認最終重量，而且這個“多次”到底是幾次是可以設定的。
• 怎樣通知操作員重量已經確認？直觀反應是讓操作員觀察軟體顯示的數值穩定，想了想改為用顏色標註，沒穩定時以紅色顯示，穩定後以綠色顯示。更進一步的想法是發聲通知。
• 電子秤有了誤差要如何處理？答案是在軟體的設定裡增加“校正”選項，這樣即便電子秤自身暫時無法校正，軟體也可以進行校正。
• 如果資料互動時網路通訊失敗怎麼辦？辦法是相容同步和非同步互動，通訊失敗的結果可以先暫存在本地，稍後重新上傳。

　　這些問題都不是單純的技術問題，而是產品方面的問題。可是不依賴產品經理，積極思考的程式設計師自己就可以解決。最終結果是，這個完全由程式設計師開發的軟體得到了使用者（操作員）的認可，使用起來可靠方便，日後的修改只是增加新的功能，使用方面完全不必改動。我也相信，開發這個軟體的程式設計師，以後無論是單幹還是與產品經理配合，能取得成就的機會都要比只會“埋頭寫程式碼”的程式設計師更大。

　　如果有人覺得這還不滿足，希望知道程式設計師有了產品意識還有什麼別的好處？且讓我講個故事：我有個做金融的朋友，從小參加過不少資訊奧賽培訓，業餘也自己寫過不少小工具。有一天他問我：“你說程式設計師的工作有那麼高階嗎？不就是寫寫程式碼？你看我也會不少程式語言，也寫過不少程式，所以程式設計師沒什麼了不起的吧。”我回答：“那麼，你有沒有寫過給別人用的程式呢？”他想了一會兒說：“好吧，你贏了。”