起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識別怪技術同學不給力，首先你要搞清楚這幾點
身為產品經理的同學要明白一個道理：有的時候真的不是技術的同學不給力，而是我們自身沒有做好這幾點。
轉眼又進入了新的一年，經過2018年年終的述職總結，很多小伙伴期望在新的一年里有所改變。
期望團隊更加的和產品同心，以更加高效的速度將產品進行推進和落地，比如在原有的合作方式上疊加了各種流程、管理軟件，甚至是自掏腰包請團隊成員喝個奶茶賄賂賄賂……
(請喝個奶茶，賄賂賄賂……)
然而這一切能解決根本性的問題么？其實作為產品經理我們擅長的就是分析用戶的需求，但是我可曾分析過團隊其它小伙伴的需求么？知道他們想要什么嗎？
- 我們曾經把技術小伙伴的各種配合當做理所當然，一切都是應該的……
- 我們很多時候在道德的高點上認為大家都是平等，只是分工不同而已，我們負責產品設計，它們負責實現，就如同你們負責掙錢，我負責美一樣的……
- 我們很多時候是將產品原型設計出來，直接告訴它們怎么怎么做，然后坐在自己的位置上等著收獲……
- 我們很多時候以為以目標為導向最終我們和團隊會走到一起去……
最終我們認為的認為的最終并沒有成為現實！
其實原因并不是大家不努力，每天晚上熬燈夜戰往往也是技術小伙伴。
我曾經近距離的觀察過很多團隊的做事方式，也看多很多產品經理的工作方法，抗拒技術同學參與產品方案的討論的都是自己的心理在作祟，在沒有實際操作之前就已經給技術的同學打上了各種標簽。原因無外乎于以下幾點：
一、技術同學不懂業務
關于這點其實是一個悖論“有關技術是否應該了解業務邏輯”雖然早已有了結果，然后實際操作并沒有這樣。我們暫時先不討論技術同學是否應該了解業務邏輯，先從現實中的小的案例來說明：
1. 因為不懂業務，技術實現的時候很多小的細節處理的很業余，然后會被產品給教育；
2. 因為不懂業務，所以對于產品所說的產品中涉及的業務邏輯一頭霧水，不知所云，產品要死的心都有；
3. 因為不懂業務，技術在實現的時候需要產品做相對詳細的注釋說明，且在技術方案設計的時候高度參照產品說明文檔，需求發生變更，技術同學整個的要死要活的……讓產品目瞪口呆。
在日常工作中涉及到技術同學不了解業務邏輯的案例還有很多，可能有些產品同學會說，業務邏輯的科普和我有什么關系呢？
然而實際過程中，很多的業務邏輯是經過產品經理設計出來，現實中有邏輯對照的相對來說較少，也就是在整個的產品開發團隊中，產品經理是最了解業務邏輯的，那么產品經理就應該肩負起這個責任。
在這里再強調下：
產品和技術組成團隊就是通過業務邏輯的實現來達成產品的目的。
產品并不僅僅是產品經理的，也是技術以及團隊其它小伙伴的。這里面有一個價值的認知，我覺得產品經理越早意識到越好：團隊小伙伴工作的價值是指交付給用戶的價值，而不是自己工作內容的價值！
在此我們可以看到其實大家的目的和價值衡量是一樣的(關于這點我在后文詳說)，但是在達成這個目標的過程中存在分工的不同，但是大家都是圍繞這個業務邏輯來工作的。因此讓整個團隊都了解咱們的業務邏輯，對于效率的提升和業務的實現是有極大的好處。
業務邏輯的科普并不是靠一次兩次的全范圍的業務講解就是可以的，業務邏輯其實是一個相對復雜的事情，囊括了業務流程、行業基本認知、異常等各種情況。
此外隨著產品的設計，業務邏輯在某種程度上也在變化?；谝陨蟽牲c我們知道希望通過一次兩次的大范圍的講解就可以解決這個問題是不太現實的。
因此日常關于產品方案的討論和評審的時候帶這技術的小伙伴一起參與，是很有必要的，能夠想小伙伴傳輸業務邏輯，同時對于小伙伴不了解的點進行個性化的講解，最終的效果應該是很理想。
并不是技術同學不懂業務，而是你根本沒有給予人家了解業務的機會；并不是技術同學不需要了解業務，而是你對于技術工作的價值認知是錯誤的。
二、效率低
認為技術同學參與產品方案的設計會導致效率的降低是產品經理拒絕技術同學參與產品方案設計的一個主要原因，我在很多場合都聽到諸于此類抱怨。
關于效率我們需要從多個方面來看待：
1. 讓產品方案定性的時間變的更長。這在某種程度上是事實，但是從長期來看它又并非如此。一些工作策略的帶入和長期參與的堅持，最終這種對于決策時間的影響應該是越來越小。
產品方案的設計是我們產品經理的主要工作，在某種程度上團隊內的任何成員也是替換不了的，因此在關于產品方案的討論之前我們應該都做過了相對完成的梳理和一定的設計，在討論之前將這部分內容同步給團隊技術同學，使得大家能夠提前去研究，最終在產品方案設計的討論會上，無非就是優化、補充、選擇么？并不是任何一場產品方案討論會都是漫無目的，嘈雜的長達幾個小時的會議，早期做好相應的準備難道不是我們的工作內容么？
2. 隨著這種討論會的增加，大家之間的磨合越來越好，也越來越高效，對于流程和方式也越來越適應，最終整體上也在提升會議的效率。
此外我們要看到這種效率的提升所帶來的價值，對于我們產品經理來講是極其值得。那么技術參與產品方案的討論會帶來哪些好處呢？
1. 業務邏輯的科普：所有關于產品方案的討論都是建立在對于業務邏輯的認知，因此關于產品方案的討論必定在某種程度上讓技術團隊對于業務邏輯更為的理解，這點也對接上我們前面講的技術團隊應該了解業務邏輯。伴隨著業務邏輯的熟練，在日常開發中遇到了上文所說的業務邏輯問題的時候解決的更為的自主且快速，導致后續的返工或者測試修改的機會變的更少，在一個點花費多一點時間，在后續節省大把的時間難道是不經濟的？
2. 產品方案的完善：老話說的好“三個臭皮匠，頂個諸葛亮”，我們知道任何一個人的行為決策都是受自己的認知所影響的，對于我們產品經理也是一樣，我們在思維上和認知上都有自我的局限，而這種多人參與，有的時候很好的彌補這個缺點，使得產品的方案更為的完整和可行，舉一個常見的例子：
大多數產品經理在設計業務邏輯的時候是希望按照自己預期的結果也做，也就是按照正常的邏輯來設計產品原型，但是如果開發參與產品方案的討論的時候，他們考慮的很多是邊界值、異常處理等等情況，他們往往能夠很好的發現我們這方面的業務邏輯缺失。
3. 參與感：幾乎每一個產品經理對于小米贊譽有加，幾乎都知道小米的七字訣，很多同學也讀過黎萬強的《參與感》這本書，對于小米產品設計和用戶運營思路季度的贊賞，甚至在做產品運營的時候極力的邀請用戶來參與產品的設計。為什么我們行為上這么做了，但是卻忘記了每天在一起工作的人呢？正是技術小伙伴們參與產品方案的討論，使得他們感覺到足夠的尊重，從而對于產品的推進更加的用心，更愿意去投入。
三、人多意見雜，共識難道成
我們經常說“有人的地方就有江湖”，也有說“眾口難調”。這都是客觀實際，每個人的認知不一樣，自然每個人對于事物的評論也是不一樣。
每個人的出發點不一樣，自然每個人的方案是不一樣。這些都屬于正常范圍的事情，但是我們并不能因為可能難以達成一致，就放棄做這樣的事情，此外也有老話說“事越辯越明，理越辯越清”。
關于這件事情我是這樣理解的：
1. 意見管理是一項軟技能。對于任何一個在職場上混的人來說，如果的管理各方的意見是一個必備的技能，我們作為產品經理不僅應該具備這項技能并且最好要勝于常人，因為產品經理經常要協調各方資源來達成產品的目的，收集各方需求最終找到普遍性需求并最終實現。因此這難道不是我們關于該技能的練兵場么？
2. 尋求相對最優解。有多種方案多方建議是正常的，我們尋求的是相對最優解決辦法，而不是絕對完美的解決辦法。這是一個基本的常識，我們很難做一個絕對完美的方案出來，只能從眾多方案中挑選出相對最優的解決辦法。這里面有一個價值觀：“討論的目的是找到最好的解決辦法，而不是我的辦法”。
在實際操作過程中我這里面有幾個小技巧：
A：如果節奏不是很緊張，兩種方案不能很快的判斷優劣，是可以采用A/B Test,實際環境中跑一下，最后以實際數據來選擇好了。
B：少數服從多數，少數意見保留。這種方式對于商業價值影響不是很大的產品方案問題不大，但是對于重要的節點，這種方案風險太大，群體性決策失誤比比皆是。
C：對于沒有太實質性的差別的方案，或者影響相對不大的方案，產品經理要學會妥協，適當的采用團隊成員的方案是個明智的選擇。
最后給大家包括我一個忠告：
作為產品經理的我們的有的時候要能夠放的下臉面，以開放的心態，采納最好的方案，接受別人指出的不足。一方面能夠逼迫我們在業務上更加精進，一方面也有利于產品的成長。
成功的產品是我們的代言，成功的產品是我們的臉面，在此之前不要自尊心那么強。其次要學會妥協，產品的推進和落地非一日之功，需要時間的逐步的完善推進，作為產品經理的我們要著眼長遠。
四、技術和產品工作的差異
作為產品經理我們每天的工作有著明確的目標，我們的目標并不是今天畫了一個產品原型，明天寫一個產品說明文檔，這些只是我們工作的手段并不是產品層級的目標。
作為產品經理我們關注的應該是新增用戶、活躍用戶、注冊率、轉化率等數據性指標。也就是對于產品經理而言我們是以目標達成為目的。
在傳統的產品開發團隊中(技術不參與產品方案的討論)技術小伙伴每天所做的工作就是功能模塊的實現，在時間的緯度上不停的通過技術來實現業務邏輯，甚至很多時候還會給技術小伙伴來做工作分解，我所見過的工作分解能夠細化到某一功能模塊的建表，時間緯度可以細化到2個小時的單位，真是細思極恐。在這種背景下技術同學的工作是以產品功能模塊的交付為目的。
在這里我們可以看到原本我們以為的大家的目標一致在實際操作過程中差之千里，既然目標都不一致，最終的效果必然是差強人意，才導致最后的“技術小伙伴不給力”。說不定在背后技術同學真在罵“產品狗太扯淡……”呢！
So，并非是技術同學不給力，而是我們打心眼里并沒有將技術同學當做自己人，沒有給予充分的尊重和同理心。
五、技術和產品工作目標的問題
關于兩者目標的問題在我眼里其實是對于價值的認知問題。我們每天工作的價值是由什么來決定的？
- 由我們工作內容來決定的？
- 由上級領導或者老板來決定的？
- 由每天工作的8小時來決定的？
- ……
我們每天工作的服務對象就是用戶/客戶，由客戶決定是否最終買單，用戶買單之后才會通過公司體系給每一個參與者發放相應的報酬。因此我們每天工作的價值由用戶來決定的，用戶通過什么來判斷價值的呢？用戶是通過我們交付給他們的產出來判斷的。
因此我們交付給用戶的產出的價值決定了我們工作的價值！
任何基礎建設、中間產品、流程等最終沒有交付給用戶的價值都不產生任何的價值，比如：
- 技術建了一張存儲表
- 產品畫的原型、產品文檔
- 設計師畫的設計稿
- 測試寫的測試用例
- ……
而最終交付給用戶的產品是全體團隊成員工作的結晶，是由全體成員來完成達到，因此從價值認知的角度出發，團隊的每一個人應該專注于“可交付的產品及可交付產品的價值”。
前者是前提，只有交付了產品才有可能產生價值，如果連產品都沒有交付必定不存在任何的價值?？山桓懂a品的價值有兩方面決定的：
1. 是產品方案的價值，這部分從分工的角度出發是由產品經理決定的，團隊成員的參與。
2. 產品方案實現后的產品系統的價值，這部分工作基本上是有技術同學決定，涉及到系統的可用性、穩定性、容錯性、體驗等等方面。但是這兩種價值在主觀上是不可分離的，只不過在理論上我們進行了拆解分析。
所以實質上產品和技術的目標從價值導向上講完全一致的而且是必須一致的。
結論
技術同學不給力，并不是因為他們真的不給力，而是你將其推到一個目標陷阱中去了，強制讓他們從你的目標中進行脫離，而進入到了以“功能模塊交付為目的的軌道上去了”。
技術同學不給力，并不是因為他們真的不給力，而是你在沒有動手之前直接給他們貼上了標簽，他們不懂業務，他們無需懂業務。
技術同學不給力，并不是因為他們真的不給力，而是你從來沒有問過他們的需求是什么？要知道成功的產品也是技術同學的代言人。
技術同學不給力，并不是因為他們真的不給力，是我們根本就沒有尊重別人，一廂情愿的以為所有的這一切都是應該的……
本文由 @xishui2011 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
我是贊同技術也要懂一些業務的，關鍵是有的技術不愿意去了解業務，有時候跟技術將為什么這么做。。技術直接說不想聽，你就告訴我怎么做就行。。
處理的方式有很多種，我個人經驗僅供參考：
1、產品需求評審的時候，順帶講講業務背景，業務邏輯如此設計的原因。
2、在開發過程中，技術一定會越到一些業務相關的小細節問題，解答是必須的，順帶敲一下“你看業務還是要懂的吧”也是可以的。
3、在團隊活動的時候，特別是總結會、反思會場合下業態提出來的。
整體上帶動這種氛圍吧！沒有絕對的答案！
這里有個疑惑?? 前端小伙伴需要懂需要懂業務嗎 身邊的前端小伙伴每次一和他講業務 就被無視…
當然要的，理論上整個產品團隊的人都要懂業務！
你本人 是技術轉產品的吧
說到點上了 ?
這個要看你怎么看！專業的確是計算機
任何基礎建設、中間產品、流程等最終沒有交付給用戶的價值都不產生任何的價值。
很對！
好，很好