產品策劃設計和程序員之間的矛盾

那天看到了一篇分享，說的是產品策劃/設計和技術人員之間的矛盾該怎麼解決的討論總結，忽然，我想到了，可能這就是信管這個專業之因此出現的緣由吧~

       由於討論的大意就是說，產品沒有技術知識，因此常常和技術人員有矛盾，好比像個人親身經歷那樣，就是產品想出來的東西，不是沒法實現，就是天馬行空，因此，有不少次被咱們壓回去，就是由於想法不夠完備和沒法實現。

       因此，我以爲信管，若是學好了，真的有它的價值的。由於信管必需要有產品的創新觸覺，也必須有技術的實踐能力。這樣出來的產品或許就會更好。因此讀信管的看完這個能夠自行斟酌一下專業的路怎麼走，真能勝任這個職位的人數缺口仍是蠻大的。努力吧~

如下是前一段時間，在UCD討論組上面，和一些朋友進行的討論。

 

——————————————------------------------------------------------------------------------------------------------------————————–

 

程序員老是想盡可能精簡或者是按照本身的程序編寫方便來完成一些功能，有時候就是，爲了完成功能，並無考慮到產品設計上，將來可能會發生的變化，等到變化來臨時，又找出藉口來講，這個功能會影響XXX，沒法作，或者很難作，以此來刁難。

作產品的時候，老是想一開始就作一個大而全的東西，別人有的我要有，別人沒有的我也要有，老是先模仿同類的其餘網站，這樣很難有本身的特點。

程序員作的不是本身想作的，因此他們老是消極怠工，或者是代碼考慮不周全，留下了將來的一大堆隱患，或者是原本能夠很快完成的任務，他說是很複雜，這個須要作好久，以此來表達本身的不滿和抱怨，反正我又沒打算一直幹下去。

若是是程序員本身給本身寫程序，就不會這樣，開發速度很快，考慮也很細緻，傾盡本身所能，以表現本身的技術高超。

或許是技術團隊，沒有一個頂尖的leader來領導程序員？
或許是沒有一個優秀的產品經理來讓程序員信服？
仍是有其餘一些矛盾？

好像每一個公司，都有一些和程序員的矛盾，這個如何能儘可能避免呢？

 

我想可讓部分關鍵程序員前期介入，參與產品需求分析和設計。這樣的設計也兼顧了
不少實際的條件，更有實現的可能性。程序員的參與度高，對需求的理解也到位些，責
任感、成就感也強吧。

 

是有這樣的問題，咱們如今的作法是，產品設計階段就讓技術人員參與，而後通過屢次和技術人員討論造成最終的開發文檔，技術人員根據開發文檔制定開發計劃，這樣的好處是不會讓技術人員以爲產品與我無關，沒有體現個人價值，其實技術的前期參與也能夠提出不少建設性的建議。

另外，對於不一樣類型的程序員須要不一樣的對待，有些程序員在產品開發過程當中有很是多的建議和想法，對產品的控制慾望很強，這樣的程序員須要咱們投入更多的耐心，和他探討問題，這樣的程序員一旦你和他達成一致，他們的開發和合做會很是好。我我的比較喜歡和這樣的程序員溝通。還有寫程序員很是嚴格按照你的產品文檔開發，對產品自己沒有太多的想法，這樣就須要咱們把文檔寫的儘可能詳細，由於若是有考慮不周全的地方，他們也會按文檔開發。

總之，遇到這樣的問題仍是多找自身的問題，充分調動你們的積極性把產品作好纔算一個合格的產品經理

 

贊成。作好一個產品不能僅僅是產品經理的事情，產品經理最重要的一個功能就是調度起跟產品有關的人的積極性，讓全部人都發揮其最大的力量。因此，我以爲「控制」對產品經理來講相當重要。

設計的前期我以爲要常常和技術人員溝通，可讓一些對設計有興趣有想法的開發人員加入進來，他們能夠從技術可行性上給予幫助。不過有個問題就是，技術人員也許不懂UCD，並且他們常常是從程序的角度去思考和設計產品，這個時候就須要咱們去把握和掌控產品設計。

有些程序員對產品設計能夠說絲毫興趣沒有，他們只管本身的代碼是否漂亮，這些程序員最怕的就是你開發過程當中變動需求，這就要求咱們前期需求明確，指定完善的開發文檔，深刻到產品的各個細節。

 

對於不一樣的研發，是要有不一樣的協調方法。
我還有一個我的的小經驗，就是不只要和研發的同窗協調好，更應該先和測試的同窗搞好關係。在個人工做圈子裏，我瞭解到大多數研發對於產品消極的處理都是與測試team的考覈有直接關係。
因此，我平時會和測試、研發同窗常常一塊兒溝通，最大的目的就是指望你們在遇到問題的時候首先能一塊兒瞭解問題，而不是互相推卸責任。
固然，在這個過程當中PM要把握測試的緯度和實現的程度。

 

產品、設計、前端工程師、程序員相互之間責任的推卸是一個很嚴重的問題，隨着分工的越細，這種矛盾有些時候就越明顯，可是不分工又沒有辦法達到相對的專業化。身兼多職的人，就會有所抱怨。

和產品打交道最直接的不知道是否是設計師？

產品 -> 設計師 -> 前端工程師 -> 程序員 -> 測試人員

整個的流程是並行，仍是串行有交叉？我認爲應該整個Team對項目都有所理解，而不是僅僅是各司其職。

 

這些程序員最怕的就是你開發過程當中變動需求，這就要求咱們前期需求明確，指定完善的開發文檔，深刻到產品的各個細節。」

不過產品的改動或變動，直接影響到，後續全部人的變化，這也多是你們比較抵觸的緣由，可是有些時候，某些改動又是必須的。

整個Team成員的相互認知，承認，對矛盾的激化能起到很好的降溫做用，多溝通是一個很好的解決辦法，只是這種溝通是經過會議，仍是私下的午飯、上下班路上、閒聊，仍是其餘方式呢？

有時候，程序員的一個建議，產品沒法拿出很好的建議來反駁，可是產品又不想按程序員的想法來作；
或者是程序員提出一個改動，能夠省下很多的開發時間（不管省下來的時間，他幹什麼了。），同時對產品的影響不大，他都但願產品能作出讓步，若是這個時候產品說，你必須這麼作，很強勢，程序員就會有抵觸情緒，對於這種程序員如何溝通？

 

「有時候，程序員的一個建議，產品沒法拿出很好的建議來反駁，可是產品又不想按程序員的想法來作；」通常遇到這種狀況我會根據建議用原型開發工具把建議用原型實現，而後和程序員一塊兒站在一個使用者的角度去走流程，看看是否合理，這時能夠多找幾我的，立刻你們就會發現哪一種方案更好，咱們公司主要作手機軟件開發，通常程序員的建議能夠反應到產品的表現層，因此這個方法好用，若是原型開發能夠實現一些交互效果會更好，可是不知道這個辦法是否具備通用性。程序員不是咱們的敵人，不要總想着駁倒對方，若是你們都能站在最終產品的角度不少問題都會解決，這須要咱們作產品的多去包容，明確本身的的最終目標是什麼。

 

如何與程序員溝通有時候是一個至關棘手的問題，無論是UI guideline得制定仍是實施過程當中，因爲UI的一個決定可能須要程序員大量工做來解決，碰到比較強硬的程序員就不得不要求PM來進行支持，可是這終究不是完善的解決辦法，完善的解決辦法是，對於一些道理很明顯而程序員出於自身利益的考慮而拒絕合做的能夠書面詳細列舉利弊直接要求PM來支持你UI的工做，而對於兩難選擇，能夠經過創建目標用戶羣來反饋用戶的意見，這個是程序員永遠沒法反駁的，固然有時候用戶羣可能會站在程序員這一邊，咱們天然以用戶意見爲最終指導，起碼能夠按部就班。真正重視用戶體驗的公司是會支持你創建目標用戶羣並進行Usability調查的，而這也是咱們不少UI 目前缺少的經驗。但願你們能多多共享這方面的實際經驗。與用戶站在一塊兒纔會使軟件真正爲人所稱讚而不是成爲用戶發泄怨憤的替罪羊。

 

恩，我就碰到過程序員在設計上堅持本身的建議，這個時候最有力的說服根據就是用戶反饋—一個以目標用戶羣的可用性測試結果。

否則就只能是高層定奪了

 

我也常常碰到這樣的問題。
這樣的問題不只僅發生在產品和技術之間，一樣也會發生在市場和產品之間

我以爲在流程上應該能夠解決一部分問題，在造成產品相關文檔的時候，好比MRD，PRD，這些文檔出來後，能夠跟市場部門的運營計劃一塊兒討論，或者產品
部門內部討論PRD的時候，可讓技術人員參與進來，這樣其實在產品需求肯定的過程當中，就同時考慮了產品運營需求和技術調研，也能讓市場和技術的同事更
有了解產品自己。

在合理的流程下，還須要的，就是產品經理對產品的把握和控制了，產品經理必定要考慮到多方面的因素，至少在這個團隊裏，你就是這個產品的專家，你須要說
服你的同事怎麼去作這個產品，須要提出運營的建議，須要及時的跟進，改進產品。無論技術人員怎麼怠工，或者思想怎麼懶散，只要產品真正是在向好的方向發
展，好比是在贏利，或者使用人數是在增長，或者其它相關數值是在你們的努力下一步步上升，那麼這就是一個成功的流程，你們合做就是成功的。相信有過一兩
次這樣的成功合做的經驗，之後，技術部門的同事們也不會再消極怠工了，對於代碼的熱情也會一步步提起來。市場部的同事也同樣，對於產品來講，全部與產品
相關的人就是一個團隊，產品經理須要很好的去調動你們，使產品的開發過程變成一種良性的成長過程，只有這樣，纔會越作越好。

 

這個問題個人作法：
1 PM與RD本就應該關係很是密切，若是PM和RD關係很差，那隻能說PM溝通交際能力不過關，
問下本身：和RD交往多很少，常常一塊兒吃飯吹牛不，別說做爲PM你連交際費都木。

2 RD有一個慣性：就是若是PM不懂技術，他就會有點瞧不起你的想法，因此嘛，我都十分關注技術，
對技術也很熟悉，公司不少小工具，小程序都是偶本身開發的，偶雖然不是一個優秀的CODER，可是
對技術瞭解很普遍，這樣你常常和技術交流，其樂融融載，還會有啥矛盾，固然讓技術參與產品前期
是很是必要的。OVER。。

 

良好的溝通、充分調動你們積極性都是頗有必要的。可是問題依然會出現，咱們如何解決？

下面有一些工做心得與你們分享，FIY。

或許是技術團隊，沒有一個頂尖的leader來領導程序員？
咱們來看一下產品經理的的職責：
一、市場調研
二、產品定義及設計
三、項目管理
四、產品宣傳
五、產品市場
六、產品生命週期管理
……
僅靠產品經理我的來解決問題，顯然不夠現實。有必要在相關工做環節制定相關可用性工做流程。無規矩不以方圓！有了工做流程的保證，纔可以更好的解決現有問題和後續未知問題。

FIY：如下流程比較適合軟件開發團隊，針對團隊大小，可適當調整流程。

一、規劃需求階段可用性工做流程
可用性規劃、界面原型、可用性概要需求、可用性需求評審、可用性詳細需求
二、設計開發環節可用性工做流程
詳細需求、界面和交互支持、界面和交互檢查、可用性專題、專題分析設計、可用性需求評審
三、測試環節可用性工做流程
可用性發版指標、可用性測試、可用性缺陷修復、可用性問題支持、可用性缺陷驗證、可用性發版報告
四、可用性實驗工做流程
制定計劃、實驗準備、可用性實驗、實驗分析

以上的流程，也是在工做中慢慢總結理出來的。問題每一個開發團隊都會有，僅靠良好的溝通和調動你們積極性去處理問題，確定會被累死，效果也不明顯。可用性工做的開展不是一兩我的的工做，咱們須要用咱們專業的可用性知識，在合理的工做流程中去影響規劃、需求、開發、測試人員甚至是老闆。

 ---------------------------------

　　每一個公司都但願有一個傑出的產品戰略，能使公司先於其餘任何公司進入一個新興市場;或者但願有一個這樣的產品戰略，能爲公司源源不斷地提供具備競爭優點的優秀產品。一個有效的產品戰略可以激勵人們開發出成功的產品;相反，即使是最好的開發努力也會因低效的產品戰略而付諸東流。不管是傑出的仍是低效的產品戰略，它們都是產品開發的起點，都在許多重要的方面影響着產品開發。

　　產品戰略是基於戰略高度對產品機遇的前瞻性認識。若沒有這種前瞻性認識，公司就會被迫在看不到各類機遇的全貌的狀況下，做出開發新產品和對現有產品進行更新換代的決策。這樣一來，一些二流的產品可能被開發了出來，而更好的機會卻被忽視了。若是有行之有效的產品開發戰略，那麼，企業在決定投資開發新產品時，它就能確信已全盤考慮了全部的主要機遇。

　　產品(戰略)規劃的四個層次

　　一、產品戰略願景

　　是一個明確方向和內容的願景，它對下一層次產品平臺戰略的性質、時間安排和競爭定位進行指導

　　二、產品平臺戰略

　　是共同技術要素的一個集合，特別是一系列產品實施過程當中採用的核心技術。產品平臺開發的過程包括產品平臺概念的評估、產品平臺規劃和產品平臺開發。

　　三、產品線戰略

　　來自產品平臺戰略，是一個分時間段的、有條件的計劃，爲一個產品線肯定開發產品的順序。這個順序是按時間分階段的，貫穿整個產品平臺和產品線的生命週期。並且，它能夠根據對市場、競爭要求和資源情況的變化而改變。

　　四、產品開發戰略

　　單項新產品的開發則是產品線戰略的具體實施。