iOS軟件開(kāi)發(fā)：從新手到專(zhuān)家的一些建議

　　iOS軟件開(kāi)發(fā)：從新手到專(zhuān)家的一些建議

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

　　產(chǎn)品經(jīng)理最希望看到的就是自己的產(chǎn)品意圖能被完整的實(shí)現，并按照PRD的設想，按部就班的一點(diǎn)點(diǎn)實(shí)現。在PRD Review的時(shí)候，團隊成員可以提意見(jiàn)，但最終還是要由產(chǎn)品經(jīng)理來(lái)拍板決定才行。特別是產(chǎn)品經(jīng)理負責制的團隊，對產(chǎn)品層面的把握，產(chǎn)品經(jīng)理要有決策權， 這樣才能保證產(chǎn)品可以按照規劃去一步步實(shí)現。若開(kāi)發(fā)人員對產(chǎn)品指手畫(huà)腳，并在開(kāi)發(fā)過(guò)程當中加入進(jìn)去很多自己的想法，無(wú)疑會(huì )影響到整個(gè)產(chǎn)品的規劃，若加進(jìn)去 的是錦上添花的東西也還好說(shuō)，萬(wàn)一打亂了產(chǎn)品的功能結構，無(wú)疑會(huì )讓產(chǎn)品經(jīng)理很郁悶，甚至也會(huì )影響到整個(gè)產(chǎn)品團隊的績(jì)效。

　　俗話(huà)說(shuō)的好，聞道有先后，術(shù)業(yè)有專(zhuān)攻。大家各司其職，把各自最擅長(cháng)的部分都發(fā)揮出來(lái)，就能對產(chǎn)品有很大的助力，而不是在自身不擅長(cháng)的領(lǐng)域多加干涉。我 承認有很多開(kāi)發(fā)人員都有做產(chǎn)品經(jīng)理的潛質(zhì)，也確實(shí)有一批產(chǎn)品經(jīng)理是技術(shù)出身的，我本人也是，但若你還沒(méi)有轉職，就還是應該扮演好自己的角色，產(chǎn)品經(jīng)理主要 負責產(chǎn)品的規劃和設計，開(kāi)發(fā)人員負責實(shí)現。這樣也就有人什么樣的開(kāi)發(fā)人員是產(chǎn)品經(jīng)理比較喜歡的話(huà)題。

　　最受歡迎的是實(shí)干型的

　　打個(gè)比方，產(chǎn)品經(jīng)理是畫(huà)圖紙的，開(kāi)發(fā)人員就是施工的，要嚴格按照圖紙所畫(huà)的設計來(lái)施工，大樓才不會(huì )倒塌。實(shí)干型的開(kāi)發(fā)人員是最受產(chǎn)品經(jīng)理歡迎的，這樣 的人可以切實(shí)的把產(chǎn)品意圖實(shí)現出來(lái)。當然也不是盲目的施工，在充分理解PRD的基礎上，了解一定的背景，知曉其價(jià)值所在，對設計方案并無(wú)大的異義，技術(shù)實(shí) 現上也無(wú)難題需要攻克的，然后按照PRD進(jìn)行開(kāi)發(fā)。實(shí)干型也不代表悶聲不響，有意見(jiàn)可以提，要的只是大家達成一致后，或沒(méi)有達成一致的情況下，產(chǎn)品經(jīng)理拍 板了其中一種設計方案，后續可以按PRD照常開(kāi)發(fā)的，這樣才是產(chǎn)品經(jīng)理喜歡的。

　　有疑問(wèn)是好事，證明花時(shí)間去理解產(chǎn)品設計的思路和意圖了，這樣也能幫助開(kāi)發(fā)人員自身熟悉業(yè)務(wù)，提升自己的水平。產(chǎn)品經(jīng)理負責制絕不是搞“一言堂”，還 是很民主的，只是在大家爭執不下的時(shí)候，擁有最后的決策權。產(chǎn)品團隊在這個(gè)時(shí)候要的就是堅實(shí)的執行PRD，而不能抱著(zhù)懷疑態(tài)度在開(kāi)發(fā)過(guò)程當中去篡改。

　　最討厭的就是表里不一的

　　在討論產(chǎn)品需求的時(shí)候大家都達成一致了，最后開(kāi)發(fā)出來(lái)發(fā)現完全不是那么回事，這個(gè)時(shí)候最郁悶的就是產(chǎn)品經(jīng)理了，自己的設計被別人改的面目全非不說(shuō)，還 要花時(shí)間重構，影響到整體的項目進(jìn)度。在一個(gè)產(chǎn)品團隊待久了，很多學(xué)習能力強的開(kāi)發(fā)人員就會(huì )對產(chǎn)品或所負責的業(yè)務(wù)形成一定的自身見(jiàn)解和認識，這種認識有時(shí) 候是好事，可以幫助開(kāi)發(fā)人員快速的理解新需求，有時(shí)候又是壞事，會(huì )先入為主的使開(kāi)發(fā)人員認為玩來(lái)玩去就這么點(diǎn)內容，他已經(jīng)都掌握了，會(huì )產(chǎn)生一些自身的想 法，進(jìn)而將這些想法加入到產(chǎn)品當中。這種情況最要不得。

　　還有一種很杯具的情況，就是開(kāi)發(fā)人員越過(guò)產(chǎn)品經(jīng)理，自己去和業(yè)務(wù)人員溝通需求，并自認為掌握了一手的需求，只要幫業(yè)務(wù)人員快速實(shí)現對應的需求就是莫大 的功勞。殊不知一手需求大多都是不可用的，都需要經(jīng)過(guò)轉化，并且大多數用戶(hù)都無(wú)法清楚的表達自己的需求，只能描述自己日常的操作是這樣的。若按這樣子去實(shí) 現，做出來(lái)的產(chǎn)品只是線(xiàn)下操作的線(xiàn)上化，毫無(wú)產(chǎn)品規劃可言，也不符合業(yè)務(wù)邏輯。這樣子做等于是架空了PRD，完全把PRD當成是擺設，這是非常不可取的行 為。

　　開(kāi)發(fā)人員應具備的能力素質(zhì)

　　最基本的就是技術(shù)水平。作為開(kāi)發(fā)人員，不去鉆研技術(shù)，學(xué)習新興技術(shù)，最終就會(huì )被淘汰。IT行業(yè)是更新最快的行業(yè)，不斷有新技術(shù)，新概念出現，不與時(shí)俱 進(jìn)就會(huì )被時(shí)代拋棄。再就是技術(shù)是個(gè)無(wú)底洞，越深入研究?jì)热菥蜁?huì )越多，精通某項技術(shù)比略知N項技術(shù)要有價(jià)值的多。有時(shí)候工作經(jīng)驗的長(cháng)短并不能代表技術(shù)能力， 關(guān)鍵還是要看自身是否肯去研究。毫無(wú)疑問(wèn)，技術(shù)能力強的開(kāi)發(fā)人員更受產(chǎn)品經(jīng)理喜歡。

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

　　邏輯思維能力。主要在于代碼邏輯是否嚴謹，特別是在條件判斷情況比較多的時(shí)候，大家都懂if和else，也知道and和or，怎么使它們配合出來(lái)多樣的條件組合，以滿(mǎn)足產(chǎn)品的業(yè)務(wù)邏輯和流程邏輯，是開(kāi)發(fā)人員要考慮的。這點(diǎn)比較類(lèi)似于BUG的數量。

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

　　在產(chǎn)品團隊內部，產(chǎn)品經(jīng)理和開(kāi)發(fā)人員之間相處融洽了，配合無(wú)間了，是產(chǎn)品成功的有力保障。相反，若雙方之間矛盾重重，則只會(huì )一事無(wú)成。因此，產(chǎn)品經(jīng)理 和開(kāi)發(fā)人員之間的關(guān)系維系向來(lái)比較讓人頭疼，多數情況向都是產(chǎn)品經(jīng)理在妥協(xié)和配合，在此，我也希望開(kāi)發(fā)人員能夠體諒和配合一下產(chǎn)品經(jīng)理。