作為互聯(lián)網(wǎng)界的兩個對立的物種，產(chǎn)品汪與程序猿似乎就像一對天生的死對頭；但是在產(chǎn)品開發(fā)鏈條上緊密合作的雙方，只有通力合作，才能更好地推動項目發(fā)展?！堕_講啦》第十八期，讓我們跟快碼眾包創(chuàng)始人兼CEO 朱雄業(yè)（Bruce）一起，看看如何才能讓產(chǎn)品汪與程序猿和諧共處，打造出用戶滿意的產(chǎn)品。
嘉賓介紹
朱雄業(yè)（Bruce），快碼眾包創(chuàng)始人兼CEO。互聯(lián)網(wǎng)行業(yè)近10年的從業(yè)經(jīng)驗，資深CTO、攻城獅，2010~2012年作為合伙人創(chuàng)立國內(nèi)第一家APP在線生成平臺《完美e端》，2013~2014年在TagAlong(同游網(wǎng))擔任CTO職位。曾獲得盛大《2008Widget設計大賽》、淘寶《2011移動電商應用開發(fā)大賽》、創(chuàng)業(yè)邦《2011微創(chuàng)業(yè)計劃大賽》等眾多獎項。
產(chǎn)品經(jīng)理和程序員的那些“恩怨情仇”
相信大家讀聽過“五個程序員殺了兩個產(chǎn)品經(jīng)理”的故事，雖然故事有點夸大，但卻反映了程序員和產(chǎn)品經(jīng)理之間長久以來的“恩怨”。做為開發(fā)中的兩個關鍵角色，程序員和產(chǎn)品經(jīng)理的沖突在哪里呢？作為一個做了十年技術，同時也有過主導產(chǎn)品經(jīng)驗的程序員，今天和大家分享一下我的理解和體會。
首先，我們先來總結一下，沖突發(fā)生在哪里？
第一點，產(chǎn)品經(jīng)理不尊重技術規(guī)則，程序員不尊重產(chǎn)品經(jīng)理的創(chuàng)作用心
這方面可以總結的例子很多，舉一個極端的例子：程序員調(diào)了一天的bug，產(chǎn)品經(jīng)理過來看了看，直接就說一句：“今天什么都沒改嘛”，甚至有的產(chǎn)品經(jīng)理就可能說出這個程序員“很懶”的話來。
Bug有很多種類。很多不懂技術的產(chǎn)品，大多都以為程序員解決的問題都是自己操作上用到的或者看得到的功能，對一些純技術層面的東西是不大了解，更不懂得做這些事情需要花費的時間。只要界面不變，操作不變，就覺得程序員沒有在做事情。對于一些有難點的技術問題，程序員“當機”好幾天的情況還是會有發(fā)生的，這個需要產(chǎn)品經(jīng)理多去理解。
還有一種“Bug越改越多”的情況，這個估計也是不懂技術的產(chǎn)品經(jīng)理無法理解的。項目開發(fā)催得越緊，程序員自顧不暇，出狀況的概率也會變高；不經(jīng)意修改了核心代碼的某個部分，連鎖效應就會影響到很多關聯(lián)部分的代碼，對正在驗收的產(chǎn)品經(jīng)理來說，就是一夜回到解放前的感覺；甚至會覺得是程序員在“使壞”，故意搞的。
另一方面，程序員跟IT的關聯(lián)更為密切，對計算機、互聯(lián)網(wǎng)的產(chǎn)品的了解是隨著興趣、從學習開發(fā)語言的時候就開始了，所以對于互聯(lián)網(wǎng)產(chǎn)品都會有自己的見解。但往往也會因為這樣，對產(chǎn)品經(jīng)理的工作指指點點，甚至把對產(chǎn)品原型的不滿情緒帶入開發(fā)當中。
同類的問題很多，產(chǎn)品經(jīng)理若懂得技術，那固然是好事情。但這個要求不大合理，那需要的就是需要雙方各自尊重對方的“專業(yè)”。產(chǎn)品經(jīng)理對技術不要盲目揣測，程序員也要尊重產(chǎn)品經(jīng)理的專業(yè)性，多體會產(chǎn)品經(jīng)理創(chuàng)作產(chǎn)品的用心。
第二點，關于開發(fā)進度
有的時候，程序員迫于壓力和暫時的效率自信，預估的工期本身就是短了的。進度問題已經(jīng)發(fā)生，程序員在努力趕進度的時候，產(chǎn)品經(jīng)理來了：“為什么這么慢？不是說好什么時候做完的嗎？”；或者一個功能一個功能地過“這沒做完，這個也沒做完”；甚者“最多給你兩天，后天一定要做完”。進度沒有完成，產(chǎn)品經(jīng)理的心情可以理解，但是這些有幫助嗎？時間用在這些方面了，誰來寫代碼？搞到程序員心情煩躁，還能指望著效率的提升嗎？
進度問題的產(chǎn)生，需要產(chǎn)品經(jīng)理和程序一起總結，共同探討解決的方案。但畢竟這是共同完成的一個項目，雙方的信任還是必須要有的，另外還是需要把精力用到開發(fā)上面，而不是沒完沒了的爭執(zhí)和總結。
同時為了確保開發(fā)進度，產(chǎn)品經(jīng)理需要多做一些“細致”的工作。有些產(chǎn)品出的產(chǎn)品原型，是只有“主線”的頁面的，看圖能理解開發(fā)的是個什么樣的產(chǎn)品，大致怎樣的流程和處理方式。但在開發(fā)中間，程序員會發(fā)現(xiàn)有很多的“缺失”而走不下去。極端的情況，有直接給程序員產(chǎn)品原型和一兩張主要界面的UI圖，就讓程序員去開發(fā)的，各種去操作的界面讓程序員去腦補，或者是需要的時候再去要，再去補。這樣自然會影響進度。這部分的圖可以晚點給，但進入開發(fā)之前一定要提前交給程序員。
關于工期的預估，產(chǎn)品經(jīng)理也需要和程序員提前進行溝通，不要自己做工期的預估，如果產(chǎn)品經(jīng)理的經(jīng)驗更豐富些，對于一些程序員過于自信的估計，要有自己的堅持。
第三點，關于“改動后”的需求
這個沖突的根源，更多是產(chǎn)品經(jīng)理和“老板們”關起門來開了個會，腦細胞激蕩后，趕出原型和UI圖，之后交給程序員的就是“圣旨”?！胺凑覀兙瓦@么定了，你照著開發(fā)吧，技術問題自己解決”，更可怕的再來一句“這個改的不多，工期還是按照原來的哦”。
如果是懂技術的產(chǎn)品經(jīng)理，對當前開發(fā)的程序架構有充分的了解，并且對改動后的需求已經(jīng)有了明確且可行的技術解決方案，倒也無可厚非。但是，如果到了程序員哪里，真成了要“大動干戈”的事情，那這個怎么去收拾？產(chǎn)品經(jīng)理再去和“老板們”頭腦風暴？估計很多產(chǎn)品經(jīng)理是不愿意這么去和“老板們”重來一遍的，那么就變成了對程序員的“收買”或者是“戰(zhàn)爭”。
我的建議，但凡是涉及到“需求改動”的，產(chǎn)品經(jīng)理最好是先和程序員討論一下方案的可行性。尤其是對那種“層級關系”比較分明的公司，這點尤其重要。
第四點，關于“反技術”的原型設計
這點我想單獨拿出來說一下，因為對于創(chuàng)業(yè)公司來說這點尤其重要，“反技術”的設計意味著成本大幅度升高。
大多數(shù)產(chǎn)品由于不懂技術，不清楚不同操作系統(tǒng)有什么不同，iOS有的，非得安卓的APP也要，也不考慮當前可用的開發(fā)能力，即便只有一個程序員也要求各種細節(jié)的提升和完備，各種“極致”。
對創(chuàng)業(yè)項目來說，能充分利用現(xiàn)有的資源，對開發(fā)必然會有很大的幫助，但如果一個項目，各種組件、各種操作都是“新”的，都需要程序員去研發(fā)，甚至超出程序員的當前能力要求，這似乎就有點不應該了。
如果要避免出現(xiàn)這種狀況，在原型確定前多和程序員溝通是很有必要的。
第五點，關于驗收
大部分的項目團隊，驗收都很靠后，都會等到beta版本出現(xiàn)之后，才進入驗收環(huán)節(jié)，一旦出現(xiàn)問題，就是各種修改。
中途介入驗收，能提前進入驗收環(huán)節(jié)，把驗收分散于整個開發(fā)的環(huán)節(jié)當中，提升產(chǎn)品的品質(zhì)。但是需要有合適的配套工具，否則也會導致工作量的增加。另外需要轉(zhuǎn)變驗收的心態(tài)，不能把半成品當成是成品來驗收，或者是當成是盯程序員工作進度的工具“這個做了這么多時間，那個簡單點的，為什么也要用那么多時間。”等等。
第六點，不得不說的BOSS
是誰在阻止“程序員”和“產(chǎn)品經(jīng)理”的相愛？
作為產(chǎn)品經(jīng)理，需要一款產(chǎn)品讓自己揚名立萬，而這個產(chǎn)品出自你身邊的程序員之手；
一款好的產(chǎn)品，也能給程序員帶來資歷的提升，提升自己的身價。
所以，還是好好相愛吧！
（點擊可以查看大圖）
本次分享PPT下載： http://pan.baidu.com/s/1qWPzISc
最后的寄語
作為開發(fā)鏈條上的緊密合作的雙方，產(chǎn)品經(jīng)理要和程序員要“隊形一致”才能更好地幫助到項目的發(fā)展，多溝通，多從對方身上學習才能真正地帶來雙方的進步。
希望一個做了十年技術的程序員的總結，能給大家?guī)硪恍﹨⒖己蛶椭?/p>
