產品經理喜歡的開發人員如何誕生

【導讀】之前寫過一篇《打造開發人員喜歡的產品經理》，這可以算是姊妹篇了。 作為開發人員，不去鑽研技術，學習新興技術，最終就會被淘汰。 IT行業是更新最快的行業，不斷有新技術，新概念出現，不與時俱進就會被時代拋棄。 再就是技術是個無底洞，越深入研究內容就會越多，精通某項技術比略知N項技術要有價值的多。

眾所周知，產品經理都是很苦逼的角色，苦逼到要去迎合任何角色，這邊協調，那邊哀求，我想很多人都有深切的體會。 但是，大家都是一個產品團隊裡面的成員，要想融洽的配合，以完成產品目標，就需要相互之間可以親密無間，毫無障礙的配合，以及相互之間的忍讓與寬容。 因此也不能一味的要求產品經理去遷就開發人員，每個人都有自己的個性，開發人員也需要遷就產品經理，相互之間各退一步，就海闊天空了。

產品經理最希望看到的就是自己的產品意圖能被完整的實現，並按照PRD的設想，按部就班的一點點實現。 在PRD Review的時候，團隊成員可以提意見，但最終還是要由產品經理來拍板決定才行。 特別是產品經理負責制的團隊，對產品層面的把握，產品經理要有決策權，這樣才能保證產品可以按照規劃去一步步實現。 若開發人員對產品指手畫腳，並在開發過程當中加入進去很多自己的想法，無疑會影響到整個產品的規劃，若加進去的是錦上添花的東西也還好說，萬一打亂了產品的功能結構，無疑會讓產品經理很鬱悶，甚至也會影響到整個產品團隊的績效。

俗話說的好，聞道有先後，術業有專攻。 大家各司其職，把各自最擅長的部分都發揮出來，就能對產品有很大的助力，而不是在自身不擅長的領域多加干涉。 我承認有很多開發人員都有做產品經理的潛質，也確實有一批產品經理是技術出身的，我本人也是，但若你還沒有轉職，就還是應該扮演好自己的角色，產品經理主要負責產品的規劃和設計，開發人員負責實現。 這樣也就有人什麼樣的開發人員是產品經理比較喜歡的話題。

最受歡迎的是實幹型的

打個比方，產品經理是畫圖紙的，開發人員就是施工的，要嚴格按照圖紙所畫的設計來施工，大樓才不會倒塌。 實幹型的開發人員是最受產品經理歡迎的，這樣的人可以切實的把產品意圖實現出來。 當然也不是盲目的施工，在充分理解PRD的基礎上，瞭解一定的背景，知曉其價值所在，對設計方案並無大的異義，技術實現上也無難題需要攻克的，然後按照PRD進行開發。 實幹型也不代表悶聲不響，有意見可以提，要的只是大家達成一致後，或沒有達成一致的情況下，產品經理拍板了其中一種設計方案，後續可以按PRD照常開發的，這樣才是產品經理喜歡的。

有疑問是好事，證明花時間去理解產品設計的思路和意圖了，這樣也能説明開發人員自身熟悉業務，提升自己的水準。 產品經理負責制絕不是搞「一言堂」，還是很民主的，只是在大家爭執不下的時候，擁有最後的決策權。 產品團隊在這個時候要的就是堅實的執行PRD，而不能抱著懷疑態度在開發過程當中去篡改。

最討厭的就是表裡不一的

在討論產品需求的時候大家都達成一致了，最後開發出來發現完全不是那麼回事，這個時候最鬱悶的就是產品經理了，自己的設計被別人改的面目全非不說，還要花時間重構，影響到整體的專案進度。 在一個產品團隊待久了，很多學習能力強的開發人員就會對產品或所負責的業務形成一定的自身見解和認識，這種認識有時候是好事，可以説明開發人員快速的理解新需求，有時候又是壞事，會先入為主的使開發人員認為玩來玩去就這麼點內容， 他已經都掌握了，會產生一些自身的想法，進而將這些想法加入到產品當中。 這種情況最要不得。

還有一種很杯具的情況，就是開發人員越過產品經理，自己去和業務人員溝通需求，並自認為掌握了一手的需求，只要幫業務人員快速實現對應的需求就是莫大的功勞。 殊不知一手需求大多都是不可用的，都需要經過轉化，並且大多數使用者都無法清楚的表達自己的需求，只能描述自己日常的操作是這樣的。 若按這樣子去實現，做出來的產品只是線下操作的線上化，毫無產品規劃可言，也不符合業務邏輯。 這樣子做等於是架空了PRD，完全把PRD當成是擺設，這是非常不可取的行為。

開發人員應具備的能力素質

最基本的就是技術水準。 作為開發人員，不去鑽研技術，學習新興技術，最終就會被淘汰。 IT行業是更新最快的行業，不斷有新技術，新概念出現，不與時俱進就會被時代拋棄。 再就是技術是個無底洞，越深入研究內容就會越多，精通某項技術比略知N項技術要有價值的多。 有時候工作經驗的長短並不能代表技術能力，關鍵還是要看自身是否肯去研究。 毫無疑問，技術能力強的開發人員更受產品經理喜歡。

技術架構能力。 PRD只是把產品需求層面的東西表述清楚了，技術設計層面的還是要靠開發人員來設計。 一個系統的可擴充性、穩定性等都靠技術架構的構建是否合理。 好的架構可以讓產品擁有千變萬化的能力，雖然需求不能的在變，但都能稍改一下就能適應。 這樣的結構無疑是更令人欣賞的。

邏輯思維能力。 主要在於代碼邏輯是否嚴謹，特別是在條件判斷情況比較多的時候，大家都懂if和else，也知道and和or，怎麼使它們配合出來多樣的條件組合，以滿足產品的業務邏輯和流程邏輯，是開發人員要考慮的。 這點比較類似于BUG的數量。

溝通能力。 產品團隊中的任何成員都需要有良好的溝通能力，至少得把你想表達的事情說清楚，不能說了半天，都無法讓人搞清楚你在說什麼。 有例證的溝通是比較有效果的，可以依照PRD的設計，加上例舉，來表述設計上的疑問，這樣產品經理最容易理解。 但前提是一定要好好看PRD才行，不能文檔都不看，就開始提一堆問題，這樣只會讓人反感。

在產品團隊內部，產品經理和開發人員之間相處融洽了，配合無間了，是產品成功的有力保障。 相反，若雙方之間矛盾重重，則只會一事無成。 因此，產品經理和開發人員之間的關係維繫向來比較讓人頭疼，多數情況向都是產品經理在妥協和配合，在此，我也希望開發人員能夠體諒和配合一下產品經理。