別怪技術同學不給力,首先你要搞清楚這幾點

9 評論 11866 瀏覽 35 收藏 19 分鐘

身為產(chǎn)品經(jīng)理的同學要明白一個道理:有的時候真的不是技術的同學不給力,而是我們自身沒有做好這幾點。

轉(zhuǎn)眼又進入了新的一年,經(jīng)過2018年年終的述職總結,很多小伙伴期望在新的一年里有所改變。

期望團隊更加的和產(chǎn)品同心,以更加高效的速度將產(chǎn)品進行推進和落地,比如在原有的合作方式上疊加了各種流程、管理軟件,甚至是自掏腰包請團隊成員喝個奶茶賄賂賄賂……

(請喝個奶茶,賄賂賄賂……)

然而這一切能解決根本性的問題么?其實作為產(chǎn)品經(jīng)理我們擅長的就是分析用戶的需求,但是我可曾分析過團隊其它小伙伴的需求么?知道他們想要什么嗎?

  • 我們曾經(jīng)把技術小伙伴的各種配合當做理所當然,一切都是應該的……
  • 我們很多時候在道德的高點上認為大家都是平等,只是分工不同而已,我們負責產(chǎn)品設計,它們負責實現(xiàn),就如同你們負責掙錢,我負責美一樣的……
  • 我們很多時候是將產(chǎn)品原型設計出來,直接告訴它們怎么怎么做,然后坐在自己的位置上等著收獲……
  • 我們很多時候以為以目標為導向最終我們和團隊會走到一起去……

最終我們認為的認為的最終并沒有成為現(xiàn)實!

其實原因并不是大家不努力,每天晚上熬燈夜戰(zhàn)往往也是技術小伙伴。

我曾經(jīng)近距離的觀察過很多團隊的做事方式,也看多很多產(chǎn)品經(jīng)理的工作方法,抗拒技術同學參與產(chǎn)品方案的討論的都是自己的心理在作祟,在沒有實際操作之前就已經(jīng)給技術的同學打上了各種標簽。原因無外乎于以下幾點:

一、技術同學不懂業(yè)務

關于這點其實是一個悖論“有關技術是否應該了解業(yè)務邏輯”雖然早已有了結果,然后實際操作并沒有這樣。我們暫時先不討論技術同學是否應該了解業(yè)務邏輯,先從現(xiàn)實中的小的案例來說明:

1. 因為不懂業(yè)務,技術實現(xiàn)的時候很多小的細節(jié)處理的很業(yè)余,然后會被產(chǎn)品給教育;

2. 因為不懂業(yè)務,所以對于產(chǎn)品所說的產(chǎn)品中涉及的業(yè)務邏輯一頭霧水,不知所云,產(chǎn)品要死的心都有;

3. 因為不懂業(yè)務,技術在實現(xiàn)的時候需要產(chǎn)品做相對詳細的注釋說明,且在技術方案設計的時候高度參照產(chǎn)品說明文檔,需求發(fā)生變更,技術同學整個的要死要活的……讓產(chǎn)品目瞪口呆。

在日常工作中涉及到技術同學不了解業(yè)務邏輯的案例還有很多,可能有些產(chǎn)品同學會說,業(yè)務邏輯的科普和我有什么關系呢?

然而實際過程中,很多的業(yè)務邏輯是經(jīng)過產(chǎn)品經(jīng)理設計出來,現(xiàn)實中有邏輯對照的相對來說較少,也就是在整個的產(chǎn)品開發(fā)團隊中,產(chǎn)品經(jīng)理是最了解業(yè)務邏輯的,那么產(chǎn)品經(jīng)理就應該肩負起這個責任。

在這里再強調(diào)下:

產(chǎn)品和技術組成團隊就是通過業(yè)務邏輯的實現(xiàn)來達成產(chǎn)品的目的。

產(chǎn)品并不僅僅是產(chǎn)品經(jīng)理的,也是技術以及團隊其它小伙伴的。這里面有一個價值的認知,我覺得產(chǎn)品經(jīng)理越早意識到越好:團隊小伙伴工作的價值是指交付給用戶的價值,而不是自己工作內(nèi)容的價值!

在此我們可以看到其實大家的目的和價值衡量是一樣的(關于這點我在后文詳說),但是在達成這個目標的過程中存在分工的不同,但是大家都是圍繞這個業(yè)務邏輯來工作的。因此讓整個團隊都了解咱們的業(yè)務邏輯,對于效率的提升和業(yè)務的實現(xiàn)是有極大的好處。

業(yè)務邏輯的科普并不是靠一次兩次的全范圍的業(yè)務講解就是可以的,業(yè)務邏輯其實是一個相對復雜的事情,囊括了業(yè)務流程、行業(yè)基本認知、異常等各種情況。

此外隨著產(chǎn)品的設計,業(yè)務邏輯在某種程度上也在變化。基于以上兩點我們知道希望通過一次兩次的大范圍的講解就可以解決這個問題是不太現(xiàn)實的。

因此日常關于產(chǎn)品方案的討論和評審的時候帶這技術的小伙伴一起參與,是很有必要的,能夠想小伙伴傳輸業(yè)務邏輯,同時對于小伙伴不了解的點進行個性化的講解,最終的效果應該是很理想。

并不是技術同學不懂業(yè)務,而是你根本沒有給予人家了解業(yè)務的機會;并不是技術同學不需要了解業(yè)務,而是你對于技術工作的價值認知是錯誤的。

二、效率低

認為技術同學參與產(chǎn)品方案的設計會導致效率的降低是產(chǎn)品經(jīng)理拒絕技術同學參與產(chǎn)品方案設計的一個主要原因,我在很多場合都聽到諸于此類抱怨。

關于效率我們需要從多個方面來看待:

1. 讓產(chǎn)品方案定性的時間變的更長。這在某種程度上是事實,但是從長期來看它又并非如此。一些工作策略的帶入和長期參與的堅持,最終這種對于決策時間的影響應該是越來越小。

產(chǎn)品方案的設計是我們產(chǎn)品經(jīng)理的主要工作,在某種程度上團隊內(nèi)的任何成員也是替換不了的,因此在關于產(chǎn)品方案的討論之前我們應該都做過了相對完成的梳理和一定的設計,在討論之前將這部分內(nèi)容同步給團隊技術同學,使得大家能夠提前去研究,最終在產(chǎn)品方案設計的討論會上,無非就是優(yōu)化、補充、選擇么?并不是任何一場產(chǎn)品方案討論會都是漫無目的,嘈雜的長達幾個小時的會議,早期做好相應的準備難道不是我們的工作內(nèi)容么?

2. 隨著這種討論會的增加,大家之間的磨合越來越好,也越來越高效,對于流程和方式也越來越適應,最終整體上也在提升會議的效率。

此外我們要看到這種效率的提升所帶來的價值,對于我們產(chǎn)品經(jīng)理來講是極其值得。那么技術參與產(chǎn)品方案的討論會帶來哪些好處呢?

1. 業(yè)務邏輯的科普:所有關于產(chǎn)品方案的討論都是建立在對于業(yè)務邏輯的認知,因此關于產(chǎn)品方案的討論必定在某種程度上讓技術團隊對于業(yè)務邏輯更為的理解,這點也對接上我們前面講的技術團隊應該了解業(yè)務邏輯。伴隨著業(yè)務邏輯的熟練,在日常開發(fā)中遇到了上文所說的業(yè)務邏輯問題的時候解決的更為的自主且快速,導致后續(xù)的返工或者測試修改的機會變的更少,在一個點花費多一點時間,在后續(xù)節(jié)省大把的時間難道是不經(jīng)濟的?

2. 產(chǎn)品方案的完善:老話說的好“三個臭皮匠,頂個諸葛亮”,我們知道任何一個人的行為決策都是受自己的認知所影響的,對于我們產(chǎn)品經(jīng)理也是一樣,我們在思維上和認知上都有自我的局限,而這種多人參與,有的時候很好的彌補這個缺點,使得產(chǎn)品的方案更為的完整和可行,舉一個常見的例子:

大多數(shù)產(chǎn)品經(jīng)理在設計業(yè)務邏輯的時候是希望按照自己預期的結果也做,也就是按照正常的邏輯來設計產(chǎn)品原型,但是如果開發(fā)參與產(chǎn)品方案的討論的時候,他們考慮的很多是邊界值、異常處理等等情況,他們往往能夠很好的發(fā)現(xiàn)我們這方面的業(yè)務邏輯缺失。

3. 參與感:幾乎每一個產(chǎn)品經(jīng)理對于小米贊譽有加,幾乎都知道小米的七字訣,很多同學也讀過黎萬強的《參與感》這本書,對于小米產(chǎn)品設計和用戶運營思路季度的贊賞,甚至在做產(chǎn)品運營的時候極力的邀請用戶來參與產(chǎn)品的設計。為什么我們行為上這么做了,但是卻忘記了每天在一起工作的人呢?正是技術小伙伴們參與產(chǎn)品方案的討論,使得他們感覺到足夠的尊重,從而對于產(chǎn)品的推進更加的用心,更愿意去投入。

三、人多意見雜,共識難道成

我們經(jīng)常說“有人的地方就有江湖”,也有說“眾口難調(diào)”。這都是客觀實際,每個人的認知不一樣,自然每個人對于事物的評論也是不一樣。

每個人的出發(fā)點不一樣,自然每個人的方案是不一樣。這些都屬于正常范圍的事情,但是我們并不能因為可能難以達成一致,就放棄做這樣的事情,此外也有老話說“事越辯越明,理越辯越清”。

關于這件事情我是這樣理解的:

1. 意見管理是一項軟技能。對于任何一個在職場上混的人來說,如果的管理各方的意見是一個必備的技能,我們作為產(chǎn)品經(jīng)理不僅應該具備這項技能并且最好要勝于常人,因為產(chǎn)品經(jīng)理經(jīng)常要協(xié)調(diào)各方資源來達成產(chǎn)品的目的,收集各方需求最終找到普遍性需求并最終實現(xiàn)。因此這難道不是我們關于該技能的練兵場么?

2. 尋求相對最優(yōu)解。有多種方案多方建議是正常的,我們尋求的是相對最優(yōu)解決辦法,而不是絕對完美的解決辦法。這是一個基本的常識,我們很難做一個絕對完美的方案出來,只能從眾多方案中挑選出相對最優(yōu)的解決辦法。這里面有一個價值觀:“討論的目的是找到最好的解決辦法,而不是我的辦法”。

在實際操作過程中我這里面有幾個小技巧:

A:如果節(jié)奏不是很緊張,兩種方案不能很快的判斷優(yōu)劣,是可以采用A/B Test,實際環(huán)境中跑一下,最后以實際數(shù)據(jù)來選擇好了。

B:少數(shù)服從多數(shù),少數(shù)意見保留。這種方式對于商業(yè)價值影響不是很大的產(chǎn)品方案問題不大,但是對于重要的節(jié)點,這種方案風險太大,群體性決策失誤比比皆是。

C:對于沒有太實質(zhì)性的差別的方案,或者影響相對不大的方案,產(chǎn)品經(jīng)理要學會妥協(xié),適當?shù)牟捎脠F隊成員的方案是個明智的選擇。

最后給大家包括我一個忠告:

作為產(chǎn)品經(jīng)理的我們的有的時候要能夠放的下臉面,以開放的心態(tài),采納最好的方案,接受別人指出的不足。一方面能夠逼迫我們在業(yè)務上更加精進,一方面也有利于產(chǎn)品的成長。

成功的產(chǎn)品是我們的代言,成功的產(chǎn)品是我們的臉面,在此之前不要自尊心那么強。其次要學會妥協(xié),產(chǎn)品的推進和落地非一日之功,需要時間的逐步的完善推進,作為產(chǎn)品經(jīng)理的我們要著眼長遠。

四、技術和產(chǎn)品工作的差異

作為產(chǎn)品經(jīng)理我們每天的工作有著明確的目標,我們的目標并不是今天畫了一個產(chǎn)品原型,明天寫一個產(chǎn)品說明文檔,這些只是我們工作的手段并不是產(chǎn)品層級的目標。

作為產(chǎn)品經(jīng)理我們關注的應該是新增用戶、活躍用戶、注冊率、轉(zhuǎn)化率等數(shù)據(jù)性指標。也就是對于產(chǎn)品經(jīng)理而言我們是以目標達成為目的。

在傳統(tǒng)的產(chǎn)品開發(fā)團隊中(技術不參與產(chǎn)品方案的討論)技術小伙伴每天所做的工作就是功能模塊的實現(xiàn),在時間的緯度上不停的通過技術來實現(xiàn)業(yè)務邏輯,甚至很多時候還會給技術小伙伴來做工作分解,我所見過的工作分解能夠細化到某一功能模塊的建表,時間緯度可以細化到2個小時的單位,真是細思極恐。在這種背景下技術同學的工作是以產(chǎn)品功能模塊的交付為目的。

在這里我們可以看到原本我們以為的大家的目標一致在實際操作過程中差之千里,既然目標都不一致,最終的效果必然是差強人意,才導致最后的“技術小伙伴不給力”。說不定在背后技術同學真在罵“產(chǎn)品狗太扯淡……”呢!

So,并非是技術同學不給力,而是我們打心眼里并沒有將技術同學當做自己人,沒有給予充分的尊重和同理心。

五、技術和產(chǎn)品工作目標的問題

關于兩者目標的問題在我眼里其實是對于價值的認知問題。我們每天工作的價值是由什么來決定的?

  • 由我們工作內(nèi)容來決定的?
  • 由上級領導或者老板來決定的?
  • 由每天工作的8小時來決定的?
  • ……

我們每天工作的服務對象就是用戶/客戶,由客戶決定是否最終買單,用戶買單之后才會通過公司體系給每一個參與者發(fā)放相應的報酬。因此我們每天工作的價值由用戶來決定的,用戶通過什么來判斷價值的呢?用戶是通過我們交付給他們的產(chǎn)出來判斷的。

因此我們交付給用戶的產(chǎn)出的價值決定了我們工作的價值!

任何基礎建設、中間產(chǎn)品、流程等最終沒有交付給用戶的價值都不產(chǎn)生任何的價值,比如:

  1. 技術建了一張存儲表
  2. 產(chǎn)品畫的原型、產(chǎn)品文檔
  3. 設計師畫的設計稿
  4. 測試寫的測試用例
  5. ……

而最終交付給用戶的產(chǎn)品是全體團隊成員工作的結晶,是由全體成員來完成達到,因此從價值認知的角度出發(fā),團隊的每一個人應該專注于“可交付的產(chǎn)品及可交付產(chǎn)品的價值”。

前者是前提,只有交付了產(chǎn)品才有可能產(chǎn)生價值,如果連產(chǎn)品都沒有交付必定不存在任何的價值??山桓懂a(chǎn)品的價值有兩方面決定的:

1. 是產(chǎn)品方案的價值,這部分從分工的角度出發(fā)是由產(chǎn)品經(jīng)理決定的,團隊成員的參與。

2. 產(chǎn)品方案實現(xiàn)后的產(chǎn)品系統(tǒng)的價值,這部分工作基本上是有技術同學決定,涉及到系統(tǒng)的可用性、穩(wěn)定性、容錯性、體驗等等方面。但是這兩種價值在主觀上是不可分離的,只不過在理論上我們進行了拆解分析。

所以實質(zhì)上產(chǎn)品和技術的目標從價值導向上講完全一致的而且是必須一致的。

結論

技術同學不給力,并不是因為他們真的不給力,而是你將其推到一個目標陷阱中去了,強制讓他們從你的目標中進行脫離,而進入到了以“功能模塊交付為目的的軌道上去了”。

技術同學不給力,并不是因為他們真的不給力,而是你在沒有動手之前直接給他們貼上了標簽,他們不懂業(yè)務,他們無需懂業(yè)務。

技術同學不給力,并不是因為他們真的不給力,而是你從來沒有問過他們的需求是什么?要知道成功的產(chǎn)品也是技術同學的代言人。

技術同學不給力,并不是因為他們真的不給力,是我們根本就沒有尊重別人,一廂情愿的以為所有的這一切都是應該的……

 

本文由 @xishui2011 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載

題圖來自Unsplash,基于CC0協(xié)議

更多精彩內(nèi)容,請關注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 我是贊同技術也要懂一些業(yè)務的,關鍵是有的技術不愿意去了解業(yè)務,有時候跟技術將為什么這么做。。技術直接說不想聽,你就告訴我怎么做就行。。

    來自北京 回復
    1. 處理的方式有很多種,我個人經(jīng)驗僅供參考:
      1、產(chǎn)品需求評審的時候,順帶講講業(yè)務背景,業(yè)務邏輯如此設計的原因。
      2、在開發(fā)過程中,技術一定會越到一些業(yè)務相關的小細節(jié)問題,解答是必須的,順帶敲一下“你看業(yè)務還是要懂的吧”也是可以的。
      3、在團隊活動的時候,特別是總結會、反思會場合下業(yè)態(tài)提出來的。

      整體上帶動這種氛圍吧!沒有絕對的答案!

      回復
  2. 這里有個疑惑?? 前端小伙伴需要懂需要懂業(yè)務嗎 身邊的前端小伙伴每次一和他講業(yè)務 就被無視…

    回復
    1. 當然要的,理論上整個產(chǎn)品團隊的人都要懂業(yè)務!

      來自浙江 回復
  3. 你本人 是技術轉(zhuǎn)產(chǎn)品的吧

    來自浙江 回復
    1. 說到點上了 ?

      來自福建 回復
    2. 這個要看你怎么看!專業(yè)的確是計算機

      回復
  4. 任何基礎建設、中間產(chǎn)品、流程等最終沒有交付給用戶的價值都不產(chǎn)生任何的價值。

    很對!

    來自山東 回復
  5. 好,很好

    來自河北 回復