作為互聯網界的兩個對立的物種，產品汪與程序猿似乎就像一對天生的死對頭；但是在產品開發鏈條上緊密合作的雙方，只有通力合作，才能更好地推動項目發展。《開講啦》第十八期，讓我們跟快碼眾包創始人兼CEO 朱雄業（Bruce）一起，看看如何才能讓產品汪與程序猿和諧共處，打造出用戶滿意的產品。

嘉賓介紹

朱雄業（Bruce），快碼眾包創始人兼CEO。互聯網行業近10年的從業經驗，資深CTO、攻城獅，2010~2012年作為合伙人創立國內第一家APP在線生成平臺《完美e端》，2013~2014年在TagAlong(同游網)擔任CTO職位。曾獲得盛大《2008Widget設計大賽》、淘寶《2011移動電商應用開發大賽》、創業邦《2011微創業計劃大賽》等眾多獎項。

產品經理和程序員的那些“恩怨情仇”

相信大家讀聽過“五個程序員殺了兩個產品經理”的故事，雖然故事有點夸大，但卻反映了程序員和產品經理之間長久以來的“恩怨”。做為開發中的兩個關鍵角色，程序員和產品經理的沖突在哪里呢？作為一個做了十年技術，同時也有過主導產品經驗的程序員，今天和大家分享一下我的理解和體會。

首先，我們先來總結一下，沖突發生在哪里？

第一點，產品經理不尊重技術規則，程序員不尊重產品經理的創作用心

這方面可以總結的例子很多，舉一個極端的例子：程序員調了一天的bug，產品經理過來看了看，直接就說一句：“今天什么都沒改嘛”，甚至有的產品經理就可能說出這個程序員“很懶”的話來。

Bug有很多種類。很多不懂技術的產品，大多都以為程序員解決的問題都是自己操作上用到的或者看得到的功能，對一些純技術層面的東西是不大了解，更不懂得做這些事情需要花費的時間。只要界面不變，操作不變，就覺得程序員沒有在做事情。對于一些有難點的技術問題，程序員“當機”好幾天的情況還是會有發生的，這個需要產品經理多去理解。

還有一種“Bug越改越多”的情況，這個估計也是不懂技術的產品經理無法理解的。項目開發催得越緊，程序員自顧不暇，出狀況的概率也會變高；不經意修改了核心代碼的某個部分，連鎖效應就會影響到很多關聯部分的代碼，對正在驗收的產品經理來說，就是一夜回到解放前的感覺；甚至會覺得是程序員在“使壞”，故意搞的。

另一方面，程序員跟IT的關聯更為密切，對計算機、互聯網的產品的了解是隨著興趣、從學習開發語言的時候就開始了，所以對于互聯網產品都會有自己的見解。但往往也會因為這樣，對產品經理的工作指指點點，甚至把對產品原型的不滿情緒帶入開發當中。

同類的問題很多，產品經理若懂得技術，那固然是好事情。但這個要求不大合理，那需要的就是需要雙方各自尊重對方的“專業”。產品經理對技術不要盲目揣測，程序員也要尊重產品經理的專業性，多體會產品經理創作產品的用心。

第二點，關于開發進度

有的時候，程序員迫于壓力和暫時的效率自信，預估的工期本身就是短了的。進度問題已經發生，程序員在努力趕進度的時候，產品經理來了：“為什么這么慢？不是說好什么時候做完的嗎？”；或者一個功能一個功能地過“這沒做完，這個也沒做完”；甚者“最多給你兩天，后天一定要做完”。進度沒有完成，產品經理的心情可以理解，但是這些有幫助嗎？時間用在這些方面了，誰來寫代碼？搞到程序員心情煩躁，還能指望著效率的提升嗎？

進度問題的產生，需要產品經理和程序一起總結，共同探討解決的方案。但畢竟這是共同完成的一個項目，雙方的信任還是必須要有的，另外還是需要把精力用到開發上面，而不是沒完沒了的爭執和總結。

同時為了確保開發進度，產品經理需要多做一些“細致”的工作。有些產品出的產品原型，是只有“主線”的頁面的，看圖能理解開發的是個什么樣的產品，大致怎樣的流程和處理方式。但在開發中間，程序員會發現有很多的“缺失”而走不下去。極端的情況，有直接給程序員產品原型和一兩張主要界面的UI圖，就讓程序員去開發的，各種去操作的界面讓程序員去腦補，或者是需要的時候再去要，再去補。這樣自然會影響進度。這部分的圖可以晚點給，但進入開發之前一定要提前交給程序員。

關于工期的預估，產品經理也需要和程序員提前進行溝通，不要自己做工期的預估，如果產品經理的經驗更豐富些，對于一些程序員過于自信的估計，要有自己的堅持。

第三點，關于“改動后”的需求

這個沖突的根源，更多是產品經理和“老板們”關起門來開了個會，腦細胞激蕩后，趕出原型和UI圖，之后交給程序員的就是“圣旨”。“反正我們就這么定了，你照著開發吧，技術問題自己解決”，更可怕的再來一句“這個改的不多，工期還是按照原來的哦”。

如果是懂技術的產品經理，對當前開發的程序架構有充分的了解，并且對改動后的需求已經有了明確且可行的技術解決方案，倒也無可厚非。但是，如果到了程序員哪里，真成了要“大動干戈”的事情，那這個怎么去收拾？產品經理再去和“老板們”頭腦風暴？估計很多產品經理是不愿意這么去和“老板們”重來一遍的，那么就變成了對程序員的“收買”或者是“戰爭”。

我的建議，但凡是涉及到“需求改動”的，產品經理最好是先和程序員討論一下方案的可行性。尤其是對那種“層級關系”比較分明的公司，這點尤其重要。

第四點，關于“反技術”的原型設計

這點我想單獨拿出來說一下，因為對于創業公司來說這點尤其重要，“反技術”的設計意味著成本大幅度升高。

大多數產品由于不懂技術，不清楚不同操作系統有什么不同，iOS有的，非得安卓的APP也要，也不考慮當前可用的開發能力，即便只有一個程序員也要求各種細節的提升和完備，各種“極致”。

對創業項目來說，能充分利用現有的資源，對開發必然會有很大的幫助，但如果一個項目，各種組件、各種操作都是“新”的，都需要程序員去研發，甚至超出程序員的當前能力要求，這似乎就有點不應該了。

如果要避免出現這種狀況，在原型確定前多和程序員溝通是很有必要的。

第五點，關于驗收

大部分的項目團隊，驗收都很靠后，都會等到beta版本出現之后，才進入驗收環節，一旦出現問題，就是各種修改。

中途介入驗收，能提前進入驗收環節，把驗收分散于整個開發的環節當中，提升產品的品質。但是需要有合適的配套工具，否則也會導致工作量的增加。另外需要轉變驗收的心態，不能把半成品當成是成品來驗收，或者是當成是盯程序員工作進度的工具“這個做了這么多時間，那個簡單點的，為什么也要用那么多時間。”等等。

第六點，不得不說的BOSS

是誰在阻止“程序員”和“產品經理”的相愛？

作為產品經理，需要一款產品讓自己揚名立萬，而這個產品出自你身邊的程序員之手；

一款好的產品，也能給程序員帶來資歷的提升，提升自己的身價。

所以，還是好好相愛吧！

（點擊可以查看大圖）

本次分享PPT下載： http://pan.baidu.com/s/1qWPzISc

最后的寄語

作為開發鏈條上的緊密合作的雙方，產品經理要和程序員要“隊形一致”才能更好地幫助到項目的發展，多溝通，多從對方身上學習才能真正地帶來雙方的進步。

希望一個做了十年技術的程序員的總結，能給大家帶來一些參考和幫助。