編輯導語：產(chǎn)品經(jīng)理往往要對工程師提出各種各樣的需求，而這些需求就會轉化為工程師的工作量，因此在產(chǎn)品經(jīng)理與工程師之間就存在著一定的博弈。對于沒有經(jīng)理權力的產(chǎn)品經(jīng)理來說，如何才能調動工程師的積極性、滿足他們的需求，從而順利的推動項目的進度呢？來看本文作者的分析吧。

產(chǎn)品經(jīng)理苦“經(jīng)理”久已，想必每一個產(chǎn)品經(jīng)理在工作中都或多或少的遇到過被懟的情景。

其緣由大多也都是懟我們的人認為我們產(chǎn)品經(jīng)理沒有經(jīng)理的權利，卻總是行使“經(jīng)理”的權利提各種各樣的需求，那做為一個沒有經(jīng)理權利的產(chǎn)品經(jīng)理如何做好“經(jīng)理”的工作呢？

一、影響做“經(jīng)理”工作的因素

在做“經(jīng)理”工作前我們要分析影響“經(jīng)理”工作的因素都有哪些，就像業(yè)務向我們提出需求時，我們要先分析需求的背后本質的是什么一樣，只有挖掘出需求的本質才能設計出讓用戶滿意的產(chǎn)品。

在產(chǎn)品經(jīng)理的工作中會經(jīng)常接觸的且要行使“經(jīng)理”權利的角色一般有業(yè)務人員、設計人員及工程師。

拿與產(chǎn)品經(jīng)理“積怨已久”的工程師舉例：產(chǎn)品經(jīng)理與工程師的對立的原因是在工作流程上處于工程師的前置位，所會對工程師提很多需求；而每一個需求都會轉化為工程師的工作量，需求的多少決定著要做的工作量的多少，這就形成了天然的形成產(chǎn)品經(jīng)理與工程師博弈。

在這場博弈中工程師注定是要失敗的，因為產(chǎn)品經(jīng)理往往帶著業(yè)務人員、老板的加持，讓工程師不得不接受產(chǎn)品帶來的需求，由此種種產(chǎn)品經(jīng)理與工程師的對立油然而生。

但這種對立也只是表象，產(chǎn)品經(jīng)理與工程師對立的本質的產(chǎn)品經(jīng)理是在與人性對抗。因為人性的本質是懶惰的，社會的發(fā)展就是滿足人性的懶惰，不然不會有馬車以及更快的馬車——汽車、不會有外賣、不會有……

但人性也是積極的，前提是要有合理的動機，作為一個合格產(chǎn)品經(jīng)理如何調動人性積極一面來行使“經(jīng)理”的權利的重要不言而喻。

我們經(jīng)常用馬斯洛需求分析我們產(chǎn)品是否能滿足用戶的某一需求，同樣的在做“經(jīng)理”的工作的時候也同樣適用。我們可以把團隊中的其他成員當成我們的用戶，分析我們如何滿足他們的需求從而推進項目的進度。

馬斯洛需求的五個層級從低到高分別是：生理需求、安全需求、愛與歸屬、尊重需求、自我實現(xiàn)。五個層級又分為兩大類，其中生理需求與安全需求為缺失性需求，愛與歸屬、尊重需求、自我實現(xiàn)為成長性需求。

如下圖所示：

生活在和平年代的我們已經(jīng)滿足了缺失性需求，但成長性需求卻是伴隨我們終生的。

下面我們從成長性需求的愛與歸屬、尊重需求、自我實現(xiàn)三個方面聊聊如何對抗人性的懶惰，給予人性積極的一面以合理動機，讓產(chǎn)品經(jīng)理能愉快的行使“經(jīng)理權利”。

二、歸屬感之信息共享

與團隊成員共享有關項目的所有信息，讓團隊成員感覺的到是大家一起在做事情，而不是某一個人在做事情，從而產(chǎn)生歸屬感。

產(chǎn)品經(jīng)理的崗位是獲得信息的最多的一個崗位，因為我們經(jīng)歷了一個功能從需求的提出、到功能的設計、再到功能最終定稿的完整流程。所以我們知道為什么要做一個這樣功能、做這個功能能滿足什么樣的目的、這個功能是否值得我們做等相關的顯性及隱性信息。

但當我們與工程師評審時往往會比較簡單的講需求的原因及目的，更有甚者可能就是一句帶過，然后直接講功能的邏輯及要求。這就到導致工程師的感知是——又來任務啦，這個需求著急上線又要加班了。

對工程師而言，產(chǎn)品經(jīng)理又派給我們更多的工作。

當我們講完需求后經(jīng)常得到工程師的反饋不是“這個功能做不了”就是“你的給的時間太短了最少需要兩倍的時間才行”，面對這樣的永遠有做不完的工作時候，不要說是工程師了，相信每個人都會消極懈怠的。

那怎么做才能讓工程師積極響應你的需求呢？

通過馬斯洛需求中的歸屬感可窺見一二，那就是要與團隊共享信息，讓大家知道做一個功能的前因、后果以及要達到什么樣的目的、和未來的規(guī)劃；而不是需要用到那個人的時候才讓TA參與其中，搞得每個人都是一頭霧水的在做事，覺得做好眼前的事情就行了，其他跟我無關，更不要提什么歸屬感了。

所以要讓團隊每一個成員都了解項目的動態(tài)，從而營造團隊成員的歸屬感。

舉個在信貸系統(tǒng)中綁定銀行卡功能開發(fā)的例子：

背景：業(yè)務部門反饋很多客戶還款的時候原來綁定的銀行卡沒錢想讓扣從另外一個卡里扣，我們現(xiàn)在只支持綁定一個銀行卡，想加個功能像支付寶一樣可以讓用戶綁多張卡，這樣扣款的時候就從多張卡里扣了；如果多張卡都扣不到的話，還能分別從多張卡里扣不同的金額湊夠應還的金額，這樣客戶就不用麻煩來回轉錢了。

如圖所示：

經(jīng)過一番深入靈魂的需求挖掘，發(fā)現(xiàn)用戶是因為各種原因導致原來綁定銀行卡不能用了，想換一個銀行卡，還款時從換的卡里扣款。

其他需求如綁多張卡、多張卡輪流扣、或者從多張卡里分別扣一定的金額，都是業(yè)務人員自己的想法，結合當期系統(tǒng)的功能梳理好邏輯后與業(yè)務人員溝通。

產(chǎn)品：你提的需求我根據(jù)系統(tǒng)的實際情況梳理了一下邏輯跟你溝通過下，綁多張卡功能可以實現(xiàn)，而且也不太麻煩，因為我們已經(jīng)開發(fā)過綁卡的接口了。

但實現(xiàn)多張卡輪流扣款的功能有點難，因為我們要改產(chǎn)品的全部扣款邏輯，這個需要挺長的開發(fā)時間的；還有另外一個問題是如果按這個邏輯去做，每個人都可能要扣多張卡會。導致我們每日批量扣款的時間特別長，如果用戶量太大，有可能一天都扣不完。

另外一個從多張卡里扣不同金額湊夠應還金額需求，首先每張卡里扣多少，很難確定。因為我們不知道卡里的余額，如果扣不到再降低扣款金額，這個邏輯就更復雜了

其次階梯性扣款這個做法不合規(guī)，我們不能做這個功能。我這邊有一個解決方案，就是讓用戶換一張綁定銀行卡，只需增加一個換卡功能就能搞定，開發(fā)時間也能滿足你的近期上線的要求，而且沒有合規(guī)問題。

業(yè)務：嗯嗯，只有能在客戶還款遇到問題是有辦法解決就行，就按這個方案做吧！

經(jīng)過一番精心設計后，拿著原型開評審會。

產(chǎn)品經(jīng)理：這個需要的來源是……..（講與業(yè)務溝通中得到客戶在使用中遇到的困難，導致產(chǎn)生的問題），因為我們當前系統(tǒng)………(講為什么設計換卡，而不是設計綁多張卡的思考過程)，所以設計了這個功能，大家有什么更好的方案嗎？或者這個功能的邏輯有沒有問題？

工程師：這個方案挺好的，用戶還卡的邏輯其實再綁一張卡，我們后臺記錄這張卡的信息，那原來的卡要解綁嗎？

產(chǎn)品經(jīng)理：設計時沒考慮到這點，要解綁的。從客戶的感知來講是換了一張卡還款，原來的卡綁定關系已經(jīng)沒了，所以還是要解綁的，不然可能萬一扣錯了客戶會投訴的。

最終和大家討論完所有的可能性，形成一個團隊認可的方案然后進入開發(fā)階段。

假設業(yè)務部門在提需求時我們直接拒絕說做不了，對方肯定會覺得這么簡單的功能都做不了？是不想做吧！

在評審時如果不講前因后果工程師對新增工作量肯定也有抵觸情緒，所以與團隊其他成員共享你的得到的所有信息，讓團隊成員了解提需求的始末及目的并與大家一起討論問題的解決方案。

讓團隊成員感覺到是大家一起在做這件事兒，從而讓團隊成員產(chǎn)生歸屬感。

三、尊重之共識

在設計之初就要多與團隊成員溝通尋求他人的意見以表尊重，并對就最終解決方案與團隊成員達成一定的共識。

相信大家都遇到過評審時與工程師劍拔弩張的場景，原因大多都是因為某一功能開發(fā)與否或開發(fā)周期未能與工程師達成共識，且大家都認為自己的想法是合理的。

而問題的爭論可能從一開始的就事論事，到最后成了為證明自己對的而爭論了，而這種爭論對項目的進度卻沒有任何幫助的。

所以為了盡量避免這種場景經(jīng)常發(fā)生，我們在做設計之初就要與工程師就新功能的邏輯達成一定程度共識，不用完全達成共識。

那如何在設計之初與工程師達成共識呢？

我們以信貸產(chǎn)品的還款流程為例：

背景：很多用戶可能會在還款日忘記往卡里打錢，導致還款失敗，銀行一般都會在上午扣款失敗后告知客戶，今天是還款日，該往卡里打錢啦。

由于時常發(fā)生客戶向銀行卡打錢時間晚于第二次扣款時間，導致客戶銀行卡里有錢，但還是沒有當日還款狀態(tài)還是失??；雖然有寬限期，但客戶還是會擔心逾期上征信，就會打電話給客服讓扣款。但因為系統(tǒng)當前支持批量扣款，只能等第二天才批量扣款才可以。

這樣客戶和客服之間很容發(fā)生矛盾導致客戶投訴，因此需要增加一個可手動發(fā)起對單個客戶扣款的功能。

如果產(chǎn)品經(jīng)理直接設計好功能給工程師，工程師就不理解為什么需要這個功能，有寬限期第二天扣不一樣嘛；但如果我們換個方式用上一章提到的信息共享的方式向工程師講解需求場景，再講一下如果不能解決這些客戶的問題會導致客戶投訴的后果，然后向工程師請教解決方案（有時候即使你已經(jīng)有了解決方案也有必要這么做）。

產(chǎn)品經(jīng)理：你覺得我們怎么做才能解決這個問題？

工程師：手動處理吧，系統(tǒng)只支持批量扣，只能我們手動處理了。

產(chǎn)品經(jīng)理：能不能做個功能，讓運營自己操作，不能總是找你們手動處理，這種事兒多了估計你們也煩。

工程師：也對！還不如做個功能一勞永逸，那就在后臺給他們個按鈕讓他們自己扣吧，那你設計設計看放哪吧。

產(chǎn)品經(jīng)理：得嘞，我先設計下原型，設計的差不多了在跟你過下看有沒有邏輯漏洞哈。

這一頓操作后再評審的時候工程師肯定就不會再提出更多的質疑了，因為在這之前你們就已經(jīng)達成了共識，認可了這個功能必要性。

產(chǎn)品經(jīng)理因為在工作中有承上啟下的作用，如果語言和行為不當就會給團隊其它成員留下你是他們領導的印象，從而讓其他團隊成員產(chǎn)生抵抗情緒。

所以要讓團隊成員多參與產(chǎn)品的設計，多向他人請教，要讓團隊成員感覺到你對他們的尊重，產(chǎn)品設計會參考他們的意見，與他們就功能設計達成共識。

四、自我實現(xiàn)之及時有效的反饋

通過及時有效的反饋讓團隊成員知道自己做的事情是正確的、有價值的從而滿足人性的自我實現(xiàn)需。

我們中華民族其實是一個不太善于直接表達感情的群體，一般表達情緒時都比較委婉，這種方式在批評一個人時會比較好用，不會讓別人覺得很尷尬；但在表揚一個人時可能效果就不會太好，別人有時候可能會感受不到你在表揚他。

假如你負責的項目克服了種種困難成功按時上線了，這時領導一般都是講：大家辛苦了，希望大家繼續(xù)努力。

明明是想表達表揚意思，可聽起來總感覺怪怪的。之所以會形成這樣的印象，是因為我們在表達感情時沒有把表揚、建議分開。

而且我們在表揚一個人時總是希望積累到一定程度再一次性表達出來。

人都是有自我實現(xiàn)需求的，表揚是沒有時間限制的，我們應該的及時表揚以改善團隊的工作狀態(tài)，提高團隊的工作效率。這樣做的成本很低，但效果卻會很好。

舉個例子：

產(chǎn)品新版本更新的時間眼看就要到了，但開發(fā)團隊因為有臨時的需求插進來導致可能要延期幾天才能上線，但老板又要求一定要按時上線，只能與工程師溝通看能不能加班趕下進度。

產(chǎn)品經(jīng)理：大佬咱們2.6版本下周一能按時上線嗎？

工程師：不能，大概要晚2-3天。你知道的，有個業(yè)務有緊急需要插進來，耽誤了幾天。

產(chǎn)品經(jīng)理：我知道最近業(yè)務有個緊急需求插進來，這個問題已經(jīng)導致客戶投訴了，優(yōu)先較高只能先做這個，我理解。這次上線的功能有幾個是老板提的，所以老板一直在問進度，要求一定要按時上線，這咋整??？

工程師：那我們周末加加班吧，這樣應該的按時上線。

產(chǎn)品經(jīng)理：那辛苦大家了，我一直在忐忑怎么跟大家講要加班趕項目進度了，沒想到大家主動提出加班趕進度。能跟你們共事，真的讓我感覺自己運氣好到爆炸。

這時候一定要及時并明確的表揚，但要注意的是不能為了表揚而表揚；如果表揚不是真誠只是為了維護團隊的氣氛和恭維他人，這種假意的表揚他人其實是能感受得到，往往會適得其反，所以表揚一定要是真實的感受。

五、結語

通過信息共享讓大家都了解自己參與的項目的動態(tài)，營造團隊的歸屬感，滿足人的歸屬感需求；通過討論解決方案達成功能應該做成什么樣的共識，滿足人性的尊重需求；通過及時有效的反饋，讓他人感覺到自己做的是有價值的事情滿足人性的自我實現(xiàn)需求。

在滿足人性的成長需求后，你還覺得行使“經(jīng)理” 的權利還困難嗎？

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

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