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

2022-04-01 09:45:48 字數 2673 閱讀 9806

都並不認同這種理論,但因為分工不同,最終做開發的大夥還是完成了這個功能。「可想而知」的是,這個功能上線之後並沒有帶來明顯的正面反饋。更好玩的是,過了一周,google reader的未讀數竟然改成了準確數字!

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

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

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

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

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

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

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

,這個改進就是工程師自己思考的結果。

第三,開發工作其實是更廣義的「產品」的一部分。好的產品離不開好的開發,只有好的開發卻不能保證有好的產品。想做出好的產品,開發人員當然需要理解產品。這裡不妨對大家都熟悉「三個工匠」的故事

做個變通:規劃城市的是設計師,工匠只負責砌磚,但是只甘心於自己幹活對外不聞不問的工匠,與知道「這是美麗城市一部分」並積極思考的工匠相比,後者營造出美麗城市的可能性顯然更高,工作所創造的價值也更大。

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

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

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

如果有人覺得這還不滿足,希望知道程式設計師有了產品意識還有什麼別的好處?且讓我講個故事:我有個做金融的朋友,從小參加過不少資訊奧賽培訓,業餘也自己寫過不少小工具。有一天他問我:「你說程式設計師的工作有那麼高階嗎?不就是寫寫**?你看我也會不少程式語言

,也寫過不少程式,所以程式設計師沒什麼了不起的吧。」我回答:「那麼,你有沒有寫過給別人用的程式呢?」他想了一會兒說:「好吧,你贏了。」

url:

做個程式設計師

深受 黑客與畫家 的影響,我再次決定做個程式設計師。有些程式設計師自稱 碼農 也許他們真的是 碼農 真正的程式設計師其實是設計師,是藝術家。人工智慧日益猖獗的今天,作為人類中的一員,如果不發揮僅有的一點創造力優勢,好一點的結果是人類顏面掃地,不好的結果可能是人類就此滅亡。所以我們應該用人類的智慧型與...

做個合格的程式設計師

不規範的表現 碰到這樣一種情況,用乙個月的時間做出了乙個產品,然後花了半年的時間來改bug,越改越冗餘,越改越混亂,有時候改乙個bug還會引入另乙個bug。1 乙個好的 是需要設計的,在寫 的時候心中要有架構,這樣寫出來的 才會更內聚,更加模組化,介面明確,邊界清晰。我看到了大量的複製貼上的 有些功...

做個快樂的程式設計師

俄,很長一段時間裡,一直在是否成為職業程式設計師的問題上糾結,最近突然明白,自己也許就是為這行而生的.大致理由有下 1.理工科出生 2.喜歡簡單的生活 待過私企,國企,其中的遊戲規則還是了解一些,發現這些都不是自己想要的 3.自己在cv上還小有研究 畢業後比較慶幸的事情就是自己就一直在做這方面的工作...