最近幾年要說哪個領域最火，無疑是互聯網領域，而隨著互聯網的火熱，伴隨而來的也是相應的互聯網職位的火熱，比如炙手可熱的程序員和產品經理（或者叫程序猿和產品汪）。我也是一個剛入行不到三年的菜鳥程序員一枚，大學學了四年計算機，畢業以后就一直在寫程序。就像很多人說的那樣，大部分時間似乎是在為了實現產品經理的需求而寫程序，于是程序猿和產品汪之間那些相愛相殺的事情，我也基本都能體會一二。

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

01 文案能力

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

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

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

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

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

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

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

02 溝通能力

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

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

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

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

03 整體思維

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

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

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

像產品經理一樣，從整個產品的角度思考問題，而不是只局限于某個細節，適當地跳出框架，從更宏觀的角度看待系統、業務、公司，程序員也能更好地理解我們的系統為什么這么做，代碼為什么這樣寫，從而幫助公司實現整體意義上的產品價值。

總結

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