眾所周知，在 IT 公司，不吵架的程式設計師和產品經理，不是一名合格的程式設計師和產品經理，不過大部分原因是因為產品經理的不合理需求所引起，例如有這樣一個需求：
App 的主題顏色可根據手機殼顏色自動調整
對於這樣謎一般的需求，程式設計師最終按捺不住還是動了手。本以為這僅是一個素來“死對頭”即程式設計師和產品經理之間的一個段子，萬萬沒想到事件得到了進一步的證實。
那麼在這些問題暴露的同時，隨之而來的就是另一個問題，小公司到底需不需要產品經理？
就在今天早上開例會的時候，老大還在說“就我們們公司這點業務，完全不需要產品經理，憑我們開發的聰明才智，自己去和業務人員確定需求就好了嘛！”
所以，有時候我也在想，產品經理應該怎樣和程式設計師友好地合作呢？
一、提清楚需求，這是最重要的第一步
無論是什麼樣的程式設計師，他都希望自己對接的產品經理能夠把需求提清楚，我每到一個公司的時候，都會先跟程式設計師同事確認他們喜歡什麼樣風格的需求，得到的答覆基本都是隻需要把需求寫明白提清楚就可以了。
所以，產品經理一定要學會把需求提清楚。你可以嘗試畫高保真原型，把一些比較複雜的互動使用動態效果表現出來，這樣做的目的不是為了炫技，而是為了減少不必要的溝通，提高研發效率。要知道，很多時候，產品經理的需求多寫一句話，就有可能讓程式設計師少返工一次。
遇到不了解的邏輯怎麼辦？大膽去問，不要怕程式設計師認為你不懂技術，也不用擔心問他們會丟面子，術業有專攻，你要做的是給出可以執行的需求，如期完成研發工作發版上線，面子什麼的不重要，都是自家哥們，何必糾結繁文縟節。
二、技術崇拜，能動手儘量不撕逼
大部分的程式設計師唯技術論，他們認可一個人的重要指標是這個人的技術能力如何，IT界有一句名言是“Talk is cheap ，show me the code”，大致的意思就是“會說不算什麼本事，把你的程式碼拿給我看看”。
記得當初在一家公司做產品負責人的時候，新來一個安卓程式設計師，入職第一天就過來跟我們說他來公司不是寫程式碼而是管人的，結果第三天就辭職了，問了個比較熟的程式設計師哥們，告訴我說這傢伙寫不出程式碼，導致組員不服他的管理。所以產品經理們一定要注意一點，就是千萬不要炫技。
這一點在那些從程式設計師轉型做產品經理的人身上是最容易出現的問題，程式設計師轉型做產品經理的人有一個最大的優勢在於，因為非常清楚程式碼邏輯，所以在寫需求文件的時候，可以很好的寫出讓程式設計師容易理解並執行的需求。
但是，這往往也是最容易出現問題的一點，我見過不少程式設計師轉型的產品經理，會經常與研發部門的同事之間因為一個功能的程式碼應該如何去寫而吵得不可開交，其實這是非常不明智的做法。
很多時候，程式設計師同學選擇如何去寫程式碼，並不是受制於本身的技術水平，而是來源於系統架構、業務邏輯與其他系統模組的耦合程度等因素的影響。
既然你選擇了產品經理這個崗位，那麼就應該把專業的事情交給專業的人去做。你可以提建議，但是不要去教他們怎麼寫程式碼。
三、程式設計師說話直接，也希望你說話直接清楚
沉默寡言是大部分程式設計師給人的第一印象，但是其實這並不完全正確，很多時候你會發現程式設計師的沉默寡言只是對你如此，因為他們認為跟你沒有什麼好說的。
你既不會寫程式碼，也不懂資料庫，但是他們在同組之間的話題永遠不會少，而沉默寡言也會相應的導致程式設計師們說話會很直接。
如果當你發現一個程式設計師同學開始學會跟你講套路的時候，那麼他極有可能已經升級為組長級別了。
大部分的程式設計師在說話的時候通常不會講太多廢話，因為他們與其浪費那麼多時間來說話，倒不如多寫幾行程式碼，所以能一句話說完的事情，儘量不要三句話。
在你想要跟程式設計師溝通一件事情的時候，請先把你想要說的話在腦子裡過一遍，抓住重點，理清思路，實在不行，你可以拉住別的同事，跟他說一遍你的想法，看看他能不能快速理解你的意思。只有這樣，你才能不引起程式設計師的厭煩情緒。
四、程式設計師尊重他人，也希望得到你的尊重
現在越來越多的段子都是在全方位的嘲諷程式設計師，說什麼“找男朋友要找程式設計師，錢多話少死的早”，什麼“程式設計師沒有女朋友，男朋友到是有很多”這類的話。
作為產品經理，這樣的段子自己知道就好，不要不適時宜的去拿來跟你的同事們開玩笑。
要知道，你在天馬行空設計出好玩、酷炫的功能的時候，是程式設計師一行一行的寫出程式碼實現的；公司盈利、上市，是程式設計師熬了無數個通宵創造出來的價值。
拿程式設計師來進行調侃，實在不是一件多有趣的事情，所以請尊重他們，能閉嘴的時候，儘量不要開口。
五、提出問題之前，請先稱讚程式設計師
很多人都知道，程式設計師最不喜歡聽到的一句話就是“你這個功能有BUG啊”，“你這個功能做得不對”，先不說到底是不是真的有BUG，當你說出這句話的時候，就意味著你完全無視了他們工作的過程，這會讓他們本能地產生抵抗的情緒。
雖然程式設計師不一定是玻璃心，但是人都是習慣於聽好話而不喜歡聽壞話。所以在你提出你的問題之前，先稱讚他們，你可以告訴他們，功能做得挺不錯的，但是好像還存在著一些問題。
所以，你也可以告訴他們，程式碼寫得挺快的，但是結果好像跟預期的不一樣。你也可以直接讓他們來現場操作功能給你看，如果真有BUG，相信他們也一定會發現。
六、如果程式設計師想多瞭解業務，花點時間溝通
在我職業生涯裡，一直是以懟天懟地懟空氣自居，曾經在一家公司撕遍全公司所有組長，卻在一次對話中，頭一次讓我覺得啞口無言。
當時是我在提交了版本需求給研發部們了以後，接著規劃下個版本的需求。按照慣例，接手我需求的程式設計師組長會把根據需求評審會上的內容，將版本功能進行拆分，然後分配到每個組員身上。
其中，PHP的組長在分配完工作以後，就其中的一個功能跟我進行了討論，大致對話如下：
程式設計師：這個功能的邏輯感覺有點不太對啊，這樣做沒問題麼？
我：我在評審會上講清楚了，需求裡也寫清楚了，你們就按照這個來做就好。
程式設計師：但是我沒見過有這樣的做法的，是因為什麼原因要這樣設計功能呢？
我：因為公司業務要求這樣去做，所以你們就按照這個來做就好了。
程式設計師：那你能跟我講講是什麼樣的業務要求麼？
我：你很煩啊，你不要管業務要求是什麼，你只要按照需求來寫程式碼就好了。
程式設計師：你怎麼這樣呢，我作為程式設計師，想了解多一點業務，只是怕到時候功能寫錯了，又要返工，到時候你也會捱罵。你作為產品經理，還不如我一個程式設計師對業務上心！
當時因為頻繁加班，而且拼命趕進度，我的狀態並不是很好，所以在跟這位程式設計師同學溝通的時候，難免有一些不耐煩，原話我不太記得了，但是我承認他在說那句話的時候，我瞬間感覺很難堪，他只不過是對專案負責，對系統負責，而我甚至都不願意抽點時間來回答他的問題。
所以，自那一次開始，我對於任何一個程式設計師同事都會或多或少的講一講公司的業務模式、業務發展需要，即使是他們不一定能聽得進去，或者不一定能夠理解的了。但是我相信，會有很多程式設計師需要對業務有一定的瞭解。
七、不要只是告訴程式設計師做什麼，還要告訴原因
提需求很簡單，但是講清楚故事就會很難，很多產品經理在提需求的時候，往往會忽略了一件事情，那就是應該要告訴他們為什麼要這麼做。
特別是在提出臨時的緊急需求的時候，為了避免引起不必要的麻煩，你其實是可以好好跟他們溝通的。
你可以告訴他是因為老闆臨時調整了思路，你已經為他們爭取最大程度降低工作量了，希望他們能抽出點時間幫你改一下需求；也可以告訴他們因為運營這個月打算衝一衝註冊量，這樣一來，這個月的新註冊使用者數可以破百萬，這是產品的非常重要的里程碑時間。
要知道，程式設計師也是這個團隊中的重要參與者，他們是有權力知道專案的所有事情的，雖然很多時候出於崗位職責不同，你往往忽略了這些東西，但是不代表你就可以完全不用告訴他們。
得到他們發起內心的認可，是為對你們的工作有很大的幫助的。
八、聊聊家常，不要刻意得去營造隔閡
見過很多的產品經理，好像生來跟程式設計師就有仇一樣，除了正常提需求、解答問題以外，甚至都不願意跟他們多說一句話，更不用說聊天了。
要知道，程式設計師也是人，他們也會有喜怒哀樂，也會經歷悲歡離合。你們之間不應該只有工作上的交流，還應該有朋友之間的友情。
我可以清楚的知道研發部門大部分人的籍貫、家庭狀況、哪個學校畢業的、有沒有結婚、女兒還是兒子等等。
其實，很多時候你會發現，和他們相處，有的時候真的很簡單。不要老覺得程式設計師很沉悶，跟你之間不會有太多的話題可以聊，但是其實他們很多時候也會想要把自己的快樂分享給別人，也會想要找個人來傾訴自己的痛苦。把你們之間的隔閡去掉，拉近點距離。
九、學會承擔責任，不要老甩鍋
不知道從什麼時候開始，教產品經理如何把鍋甩到程式設計師身上成了一種主流論調，居然還會有人寫出課程長篇大論的分析應該怎麼去甩鍋，這是非常可笑的想法。
作為一個產品經理，要先想著承擔責任，然後再想甩鍋，而不是先想著甩鍋，再去承擔責任。思想的先後順序不一樣，所造成的影響也是不一樣的。
前者是以甩鍋為己任，只有當遇到甩不出去的時候，才想著應該要由自己來承擔責任了；而後者是以承擔責任為目標，只有在必要的時候甩鍋給程式設計師，懲罰不是目的，而是為了避免下次出現同樣的問題。
十、你和程式設計師都該知道彼此的底線在哪
瞭解並堅守彼此的底線，是與程式設計師相處時候的關鍵，你可以告訴他們你可以允許研發進度延期，但是最多能延期多少天。
你也可以告訴他們允許出現BUG，但是在多久的時間內必須解決BUG併發版上線，你也可以嘗試去了解他們的底線，彼此保留一點神祕感，不是更好麼？
只要你還在做產品經理的一天，你就要學會如何去跟程式設計師打交道，不要把他們想成是豺狼虎豹，也不要把他們視為洪水猛獸，以平常心來對待，你將會感受到不一樣。