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