最近幾年要說哪個領(lǐng)域最火，無疑是互聯(lián)網(wǎng)領(lǐng)域，而隨著互聯(lián)網(wǎng)的火熱，伴隨而來的也是相應(yīng)的互聯(lián)網(wǎng)職位的火熱，比如炙手可熱的程序員和產(chǎn)品經(jīng)理（或者叫程序猿和產(chǎn)品汪）。我也是一個剛?cè)胄胁坏饺甑牟锁B程序員一枚，大學(xué)學(xué)了四年計算機，畢業(yè)以后就一直在寫程序。就像很多人說的那樣，大部分時間似乎是在為了實現(xiàn)產(chǎn)品經(jīng)理的需求而寫程序，于是程序猿和產(chǎn)品汪之間那些相愛相殺的事情，我也基本都能體會一二。

如果按照主流的做法，作為程序猿王國里的一猿，我應(yīng)該揮舞起長矛大刀對產(chǎn)品經(jīng)理口誅筆伐一番，但是這里我卻絲毫不想去為了黑而黑，而是一反常態(tài)，從自己的角度來談?wù)?，作為程序員，我們應(yīng)該從產(chǎn)品經(jīng)理那里學(xué)到些什么能力，而這些能力，程序員往往做得不夠好甚至可能是欠缺的。

01 文案能力

對的，沒錯，就是文案能力。程序員最擅長的是寫代碼，用文字符號來清晰地表達程序的運行邏輯，簡簡單單的if.。.else、for就能表達很多復(fù)雜的運行邏輯，時間久了，對于母語的表達能力漸漸下降，寫個注釋往往都能詞不達意。更何況現(xiàn)在代碼風(fēng)格指南都在強調(diào)好的代碼不需要注釋，于是程序員越來越少寫自然語言了。

于是就經(jīng)常出現(xiàn)一種場景，產(chǎn)品設(shè)計了一個靜態(tài)頁面，上面全是產(chǎn)品說明、用戶指南等等，程序員覺得這個太簡單了，復(fù)制粘貼，就一段HTML，嗖的一下就上線了。但這只是開始，你會發(fā)現(xiàn)產(chǎn)品經(jīng)常時不時地修改文案，換掉圖片，于是你不停地修改，不停地再上線…

除了靜態(tài)頁面這種大面積的文案時不時地修改，彈窗提醒這種犄角旮旯的文案也不說是寫好一次就能一勞永逸的，總之文案這種在程序員看起來不起眼的東西，在產(chǎn)品經(jīng)理那里就會非常被重視。

不重視文案的后果，就是程序員有時候自己寫的文案往往讓人感到可怕。比如，直接給用戶來個“500內(nèi)部錯誤”，此時的用戶估計也是一臉懵逼：錯誤就錯誤，啥是內(nèi)部錯誤？內(nèi)部錯誤就內(nèi)部錯誤，500又是什么鬼，瑪雅人的神秘符號？

程序員自己都明白，500是個HTTP狀態(tài)碼，內(nèi)部錯誤指的就是Internal Server Error，但是用戶不知道啊程序員大哥！

那我們再來看看，如果是產(chǎn)品經(jīng)理，會怎么提示用戶出現(xiàn)錯誤的？列舉幾個我看到的：“主人，服務(wù)器開小差了，請等會再試試吧！”，“服務(wù)器提了一個問題，我們正在緊張地撰寫答案”，等等。這些文案是不是看起來要比“500內(nèi)部錯誤”好很多呢？是不是有點俏皮與嚴謹?shù)耐瑫r，又能給用戶一個心理安慰呢？

當(dāng)然，我說的是面向用戶，如果你是程序員，可能會覺得真磨嘰啊，直接告訴我錯了不就行了嘛！但是，如果你正在使用別人家的app，不是你自己在調(diào)試程序，想想看別人家的app給你突然彈個窗“500內(nèi)部錯誤”，你還不是一樣爆個粗口，大呼“臥槽”！

02 溝通能力

據(jù)我的觀察，畫原型圖只占據(jù)了產(chǎn)品經(jīng)理工作時間很短的一部分，剩余的大部分時間是在和老板、開發(fā)、設(shè)計、測試溝通，推進產(chǎn)品的一次次迭代。所以，在一個程序員眼里，產(chǎn)品經(jīng)理是要協(xié)調(diào)各方一起推進產(chǎn)品上線的角色，如果有人對需求產(chǎn)生了認知上的偏差，產(chǎn)品經(jīng)理是要負很大一部分責(zé)任的，至少說明產(chǎn)品經(jīng)理的溝通沒做到位，而這樣的產(chǎn)品經(jīng)理大部分都被辭退了，因為出現(xiàn)溝通問題最嚴重的后果就是上線延期甚至產(chǎn)品失敗，一個產(chǎn)品的失敗是對產(chǎn)品經(jīng)理最大的否定。

總之，產(chǎn)品經(jīng)理絕不是埋頭苦干的原型畫家，要去關(guān)注外界、關(guān)注他人，平衡各方利益并且化解沖突。溝通，本質(zhì)上也是權(quán)衡與妥協(xié)的藝術(shù)。我看到的和遇到的產(chǎn)品經(jīng)理，溝通能力普遍都是很好的，至少大部分都不輸于程序員。

如果你是是經(jīng)常埋頭寫代碼的程序員，那我真要建議你抬起頭來，向產(chǎn)品經(jīng)理學(xué)習(xí)，比如學(xué)會主動和領(lǐng)導(dǎo)溝通進度、和同事溝通想法。確實存在這樣的一些觀點，程序員寫好代碼就行了，不用想其他的。我是不太贊同這種觀點的，如果自己僅僅埋頭寫代碼，不和同事相互Review，不去探討更好的做法，不去學(xué)習(xí)他人優(yōu)秀的命名方式或者另辟蹊徑的算法，是不大可能寫出好代碼的（除非你是Linus這樣的天才）。

在很多人看來程序員屬于悶騷型群體，不擅長與人溝通，但其實在我看來，程序員是一種對溝通能力要求一點也不低的職業(yè)，至少我身邊的程序員同事溝通能力都不差。比如在接口定義、排查錯誤這些需要和其他程序員和測試溝通的場景中，如果程序員過于悶騷和不知變通，多半是要出現(xiàn)相互甩鍋和爭吵的場景的。

03 整體思維

現(xiàn)在稍微有點規(guī)模的互聯(lián)網(wǎng)公司都會把各個業(yè)務(wù)或者功能進行細分，很多程序員往往會專注于自己的業(yè)務(wù)和細分領(lǐng)域。精細化分工，是現(xiàn)代社會發(fā)展出來的一個高效率生產(chǎn)方式，對提高公司的競爭力是大有好處的。但是這有一個負面的影響是，很多程序員往往過于專注自己的一畝三分地，不太關(guān)心甚至忽略了整體的存在。

曾經(jīng)聽到過一個產(chǎn)品經(jīng)理這樣對開發(fā)人員實現(xiàn)的結(jié)果表達不滿：我們做的是產(chǎn)品，不是功能！這句話深深觸動了我，因為我以前很長一段時間總是關(guān)注在能不能實現(xiàn)這個功能，很少考慮這個功能之外的東西，比如只管實現(xiàn)這個需求，而不管到底為啥要這么做，這么做的壞處是什么，所以實際上背后的實現(xiàn)邏輯最后越來越復(fù)雜，結(jié)果導(dǎo)致實現(xiàn)的東西不僅沒有產(chǎn)生理想的效果，反而做了很多的無用功。

產(chǎn)品經(jīng)理思考的出發(fā)點往往會從整個產(chǎn)品本身出發(fā)，某個功能點只是產(chǎn)品整個價值體現(xiàn)的一部分，做產(chǎn)品不只是做功能，還要思考這個功能背后到底解決了用戶什么樣的痛點，是不是會傷害用戶體驗，是不是會產(chǎn)生運營上的問題，等等。思考到這一點，也許程序員最后發(fā)現(xiàn)能找到其他的解決方案來實現(xiàn)最本質(zhì)的需求，而很可能比最開始的解決方案更加完美。

像產(chǎn)品經(jīng)理一樣，從整個產(chǎn)品的角度思考問題，而不是只局限于某個細節(jié)，適當(dāng)?shù)靥隹蚣?，從更宏觀的角度看待系統(tǒng)、業(yè)務(wù)、公司，程序員也能更好地理解我們的系統(tǒng)為什么這么做，代碼為什么這樣寫，從而幫助公司實現(xiàn)整體意義上的產(chǎn)品價值。

總結(jié)

一個好的產(chǎn)品經(jīng)理其實絕不止這些能力，而文案、溝通、整體思維這些能力是我所觀察到的作為產(chǎn)品經(jīng)理最容易被放大和辨識到的能力，也是多數(shù)比較容易被程序員忽視的能力，程序員學(xué)習(xí)到產(chǎn)品經(jīng)理身上這些最容易被觀察到的特質(zhì)，對程序員本身來說是一個非常好的進步的過程。所以，程序員，請多看看產(chǎn)品經(jīng)理發(fā)給你的文案，是不是比你自己寫的更友好，逼格更高？多觀察產(chǎn)品經(jīng)理是怎么說服大家接受需求變動的，如果換作是你，你能安撫大家的小情緒嗎？多體會產(chǎn)品經(jīng)理對產(chǎn)品設(shè)計和預(yù)期的宏觀描述，再簡單的功能也有它背后的邏輯和存在的意義。
責(zé)任編輯：wv