如何做一個懂產(chǎn)品的程序員？

源 / 跨界架構(gòu)師   文 / Zachary

兩個相愛相殺的崗位，想要更好的達(dá)成共識、更好的合作，自然不僅僅是一方的事情。這次Z哥先會帶你看看產(chǎn)品經(jīng)理眼中的程序員是什么樣子。然后給出一些我的建議。

直接進(jìn)入正題吧。

從產(chǎn)品視角是怎么看程序員的呢？我根據(jù)我自己的經(jīng)歷以及與其他產(chǎn)品經(jīng)理的交流下來看，吐槽的主要是以下幾點(diǎn)：

1. 這個功能實(shí)現(xiàn)不了。

2. 希望所有產(chǎn)品都不要改版，一次性把現(xiàn)在或未來要做的開發(fā)完。

3. 只關(guān)心要寫多少代碼，不在乎產(chǎn)品體驗(yàn)。

4. 寫完程序從不自測，直接丟給別人測試。

5. 過分追尋新技術(shù)潮流，完全不考慮對產(chǎn)品帶來什么價值。

第一點(diǎn)，的確存在一些由于技術(shù)限制導(dǎo)致實(shí)現(xiàn)成本無限大的需求，比如手機(jī)屏幕背景色根據(jù)手機(jī)殼顏色切換……

但是，國內(nèi)的技術(shù)環(huán)境不像老美那的技術(shù)味道重，大多還是商業(yè)導(dǎo)向的，很少企業(yè)里需要用到高精尖的技術(shù)，所以，真正實(shí)現(xiàn)不了的功能微乎其微。

對于大多數(shù)的功能需求來說，無非是一個成本大小、價值高低的問題。從立場上看，程序員自然是站在「成本」一方的，但對大多數(shù)人來說，決定這個成本的主要因素往往是自己工作的難度和耗時，費(fèi)時費(fèi)力的功能就容易得到“實(shí)現(xiàn)不了”的結(jié)果。

第二點(diǎn)對大多數(shù)產(chǎn)品經(jīng)理來說是他們的對立面。因?yàn)榇蠖鄶?shù)產(chǎn)品經(jīng)理最喜歡“走一步算一步”地高頻迭代，甚至是有一個想法就開始干。而程序員則喜歡來一個大而全的，并且內(nèi)容要非常詳細(xì)的，心里的想法是，這樣的話我一開始就可以設(shè)計(jì)一個完美架構(gòu)來支撐它。

而且，內(nèi)容越詳細(xì)，產(chǎn)品經(jīng)理就越不敢亂調(diào)整需求，畢竟“證據(jù)在手”嘛：D。

第三點(diǎn)在大多數(shù)程序員身上都能看到。畢竟做程序員的還是理科男偏多，對需要有同理心、需要靠感受的事情的確弱了一些。

第四點(diǎn)的原因主要有兩個。

一個是對自己的代碼過度自信導(dǎo)致，我自己深有體會。我還記得有一次我交付一個功能，那個功能我單元測試都寫了不少，對質(zhì)量很有信心，覺得就算有bug也都是比較深層的bug。結(jié)果沒想到……第一天就測出來好幾個低級的bug。

另一個原因是反正有測試人員在，等他們測出問題我再改不是更輕松。惰性使然，從個人角度的確如此。但是從團(tuán)隊(duì)角度來看，徒增了不少的溝通成本。

第五點(diǎn)的原因也有兩個。

一個是行業(yè)里的新技術(shù)迭代的確太快，怕不學(xué)新技術(shù)被淘汰。

另一個原因是，只有用上新技術(shù)才能有談資，顯得自己與眾不同、有成就感。

以上就是對這五點(diǎn)的簡單分析，那么如何改善呢？繼續(xù)往下看。

下面這些方法都是我親測有效的，強(qiáng)烈推薦你也試試。這里的序號與前面被吐槽的五點(diǎn)一一對應(yīng)。

01  說實(shí)現(xiàn)不了之前，先三思

根據(jù)先后可以做以下3個思考：

1. 是覺得這個功能沒有價值不想做嗎？

2. 真的實(shí)現(xiàn)不了？我想全了嗎？

3. 這些方案里，有成本比價值低的嗎？

第一個問題先確定必要性。我們不是說不能推需求，而是要推掉低價值、無價值的需求。當(dāng)然有沒有價值不一定你說了算，但至少這才能算是拒絕的理由。

第二個問題，努力拓寬自己的邊界、舒適區(qū)。如果我們總是習(xí)慣性地從大腦的記憶中找解決方案，那么將會永遠(yuǎn)在舒適區(qū)止步不前。

第三個問題，拒絕需求雖然不用動之以情，但一定需要曉之以理。當(dāng)你能清楚的闡述利弊、收益比，拒絕需求自然不是一件需要相互扯皮的事情。

經(jīng)過了這三個問題的思考，不管最終能不能實(shí)現(xiàn)，相信可以很好的與產(chǎn)品經(jīng)理達(dá)成共識。

02  明白需求本身也是成本

過度地苛求需求要細(xì)、要完整、要全面，這個本身也是在增加產(chǎn)品經(jīng)理需要投入的時間。你的開發(fā)成本是成本，產(chǎn)品經(jīng)理的也是。

與其等一個“XXXX最終絕對不改版”，不如從已經(jīng)達(dá)成共識的部分開工，在這個過程中再與產(chǎn)品經(jīng)理「共創(chuàng)」，多一起溝通打磨，此時再讓產(chǎn)品完善PRD等文檔，形成最終版。

03  刻意練習(xí)，多換位到用戶視角

平時多去體驗(yàn)一下自家的產(chǎn)品以及競品，把整個過程中的感受記錄下來。比如，哪里感到不太順手、哪里感受到了小驚喜、哪里感到特別煩人等等。結(jié)果不重要，重要的是這個過程，慢慢鍛煉自己作為用戶的感知力。

有些程序員看起來經(jīng)常把用戶體驗(yàn)掛在嘴上，其實(shí)提出來的很多反而是脫離大眾習(xí)慣的“個性化”需求，就是因?yàn)槠綍r缺少對同行、外界的關(guān)注。

04  交付的東西是自己的「招牌」

“有人的地方就有江湖，有江湖的地方就有稱號”。如果長期報以等測出來bug再去修的心態(tài)，你在別人心中的稱號就是負(fù)面的。

輕則影響自己的口碑，影響與他人之間的協(xié)作關(guān)系；重則失去未來的晉升機(jī)會。一個對自己的東西都不負(fù)責(zé)的人，如何負(fù)責(zé)更多的人、更大的事情呢？

在這件事上，除了多自測外，作為過來人，我建議每一個程序員認(rèn)真對待單元測試。特別把核心、復(fù)雜的方法單元測試給做上，這對交付功能的質(zhì)量的提升非常明顯。

05  不產(chǎn)生價值的新技術(shù)是“垃圾”

擁抱新技術(shù)是值得鼓勵的。但是單純的為了體驗(yàn)?zāi)承录夹g(shù)而去使用它，這不但給團(tuán)隊(duì)在挖坑，也在給自己挖坑。

比如你花了不少的時間在項(xiàng)目里用了某個新技術(shù)，但是對團(tuán)隊(duì)沒有帶來什么價值，你說后續(xù)公司還會繼續(xù)投入資源加大新技術(shù)的使用嗎？大概率并不會。那么之前了解到的一些知識，就會隨著時間的推移而淡忘，投入的時間大多數(shù)浪費(fèi)掉了。

所以，對待新技術(shù)Z哥的觀點(diǎn)是。對于無法在工作中找到價值點(diǎn)的新技術(shù)淺嘗輒止即可。相反，遇到可以產(chǎn)生價值的新技術(shù)，請全身心投入進(jìn)去，而不是僅僅在應(yīng)用層面搗騰，不去深入細(xì)節(jié)。

很多程序員對待新技術(shù)的習(xí)慣是，打一槍換一個地方，經(jīng)過了幾年，發(fā)現(xiàn)技術(shù)實(shí)力還在原地打轉(zhuǎn)，不免有些可惜。

另外，推薦大家可以閱讀一兩本心理學(xué)、行為學(xué)相關(guān)的書，特別是我們做程序員的。

這不但可以提高自己對用戶體驗(yàn)的感覺，還能提高對人性的洞察力，包括對自我的認(rèn)知。是一項(xiàng)不管在生活中還是工作中都非常有用的技能。

好了，總結(jié)一下。

這篇呢，Z哥和你分享了我對程序員如何更好地與產(chǎn)品經(jīng)理達(dá)成共識這件事的看法。主要是以下五點(diǎn)建議：

1.說實(shí)現(xiàn)不了之前，先三思。

2.明白需求本身也是成本。

3.刻意練習(xí)，多換位到用戶視角。

4.交付的東西是自己的「招牌」

5.不產(chǎn)生價值的新技術(shù)是“垃圾”

希望對你有所幫助。

— 完 —

一鍵三連「分享」、「點(diǎn)贊」和「在看」

技術(shù)干貨與你天天見~