如果你提的需求,技術同學“百般推諉”怎么辦?
技術不愿意接產品經理提的需求,該怎么辦?這不僅僅是面試中經常被問到的問題,也是實際工作中常碰到的情況。作者從為什么開發不愿意做、怎么做展開了,最后也挖掘了個人之外的因素,來看看能否給你帶來啟發吧~
這個問題,在產品經理面試時的“出鏡率”是比較高的,我之前也經常問,但是沒有遇到過比較滿意的回答。而且這個問題對于實操性的要求非常強的,能否順利解決,不僅考驗著這位產品人的基本能力,如溝通、權衡、協同,也決定了他的思維能力、全局思考和透過現象挖掘本質的能力。
同時,類似的問題不僅限于產品和技術之間的協同,很多其他工種之間也會存在相似的困惑。
所以今天簡單總結我的做法,希望能夠在面試或者實際工作中為大家帶來一點幫助。當然,我的解法都是從工作中積累而來,可能存在一定的局限性和行業性,因此希望讀者能夠以小見大、舉一反三、不吝賜教。
- 先分析常見的推諉原因,并對號入座;
- 再思考原因背后的故事,找到應對方式;
- 最后挖掘個人之外的因素,即是否存在“治標治本”的方法。
一、他為什么不愿意做?
這個問題可能有很多原因,整體區分為以下幾類:
1、個人態度問題,習慣躺平
雖說這兩年行業整體風氣有些下滑,但很多人只是在網上吐一時之快,真正在工作時還是能夠認真負責。但自始至終存在一部分人的工作態度有問題,尤其是面對一些需要“共進退”的階段性挑戰時,團隊的整體戰斗力則受限于這塊最短的木板。
- 這個我干不了,你找別人吧;
- 這個不是我負責的,你找別人吧;
- 這段代碼不是我寫的,我也不知道怎么改。
諸如此類,很容易讓你情緒出現波動。
2、工作難度問題,確實不好干
產品經理經常會苦于領導/客戶的“一句話”需求,會覺得領導把問題想簡單了,這個需求做下來真的不容易啊。類比到技術同學也是同樣的道理。
有時我們認為不就是加一個狀態嗎?不就是多了一步操作嗎?怎么就不好改了。可能還真的就不好改哦。里面涉及到很多技術層面、架構層面、關聯業務層面的改動,可謂牽一發而動全身。
所以很多同行會說,產品經理懂技術的話,是否能夠更有助于工作?關于這個問題去年我也寫過一篇看法(辯證難題 | 產品經理要不要懂技術)。
面對這個問題時,如果懂技術,則可以區分出來這個難改,到底是真的難改,還是對方夸大其詞,或者困在其中。
3、職責劃分問題,擔心背鍋
有時技術同學不愿意做,可能是擔心做不好:
- 比如中途接收別人的項目,現在又要在項目的基礎上進行迭代,他內心慌得一批;
- 比如最開始需求范圍定了10個功能,結果在討論的時候衍伸出來了3個,那他可能就不愿意做多余的內容;
- 也可能存在相反的情況,在最終分析的時候,發現了一些功能隱患,他覺得需要做。雖然產品說可以先不管,但他依然覺得應該做。
諸如此類,都是在執行的過程中出現了一些偏差,讓他擔心這些工作按照產品的想法推進之后,會對自己產生一些不利的影響。
4、優先級排列問題,沒時間搞
無論是個人,還是技術小組,大多數都不會只做一件事。當涉及到多個任務并行時,就要考慮優先級的問題。
可能你需要他支持的工作很重要,但是他手上有自己的直屬領導安排的其他任務,也可能有自己覺得比較重要的任務。這些任務都還沒做完,產品又來加塞,那我肯定不愿意搞咯。
5、個人性格問題,執拗不聽勸
這一類問題,雖說很多人可能都會出現,但更難協調的是一些技術水平不錯的伙伴。他們有自己對技術的追求,也有自己對業務的見解,經常會覺得你的設計不合理。
也許是你的設計真的不合理,也許是他在鉆牛角尖。而解決鉆牛角尖的情況,則不太容易。
6、我的問題,需求本身沒搞明白
我們往往會忽略自身的原因,就像前幾天我和同事溝通時說的一樣:
我們很多時候的關注點都在外界,喜歡挑別人的毛病,卻很難保證自己的任務不出大的偏差,時而忽略自己工作的完整性和合理性。
其實有很多產品同行,在最初定需求的時候并沒有把這個場景搞明白,或者沒有把系統現狀搞明白,所以提出來的新需求確實缺少合理性。
當我們不覺察這些問題時,輕易去向下一個節點推進,不僅會困難重重,也將為自己后續埋下一些不好填的坑。
7、工作模式問題,逐漸崩塌的信任感
如上一條所言,當自己的工作缺少完整性時,很容易讓其他同事缺少對自己的信任感,后續即便自己提出合理的需求,也可能會先被質疑,從而形成惡性循環。
同理,技術同學也是這樣。當有些人推諉的緣由被你識破之后,即便以后真的有難題,你也會習慣性的以為他又在找理由。
所以,這種現象不僅是個人問題,也可能是團隊內部工作模式的問題。
二、方法總比困難多
以下提及的方法并不與上述問題一一對應,在實踐過程中,往往是多種方式一起組合,效果才會更好(你還有哪些好的辦法,歡迎一起分享)。
1、維護好私人關系,哪里都有人情世故
“人情世故”四個字是咱們的傳統文化,工作生活方方面面都離不開。所以在這個問題上依然可以采用。
私下和同事多聊聊天,一起吃吃飯,喝個奶茶啥的,一定要自己主動,因為技術同學,更多比較直爽,而且都很單純,內心并不像其他崗位那么復雜。所以你對他好,他大概率會對你好(當然,并不是所有人都值得我們付出,相信這一點大家也都能理解)。
前些年,在這個問題上我非常有感受。因為和大多數同事的關系還不錯,當我需要幫助時,電話打過去都能收到快速的支持。同時我也會這樣回饋對方。
久而久之,你會發現有些人值得你做到100分,甚至值得做到120分,當然也有很多我只會付出60分或者80分。
自己尚且如此,何況對方呢?
但是這又可能會引起另一個問題:公司內部的“小團體”作風。當然這是另一個問題,不在今天的討論范圍之內。
所以,第一個解法便是“適度、適當的維護好私人關系”。
2、“擦干凈”共同的目標
產品經理所負責的需求,有哪些價值,要達成什么目標,自己是清楚的。但是技術同學并不清楚,或者不覺得你的目標也是我的目標。
所以,如果想讓對方盡力配合,第二個解法則是梳理雙方的共同目標。
- 比如技術同學可以通過此次迭代承接團隊內重要的模塊,可以接觸更新的技術,更完整的架構,可能會涉及到性能問題需要他解決
- 比如這件事做好之后,在領導那里是加分的,對后續的職業發展有好處,或者有重要客戶提出來的問題,我們及時響應之后對團隊會有哪些利好
隨著被諸多繁雜事項的干擾,我們很容易陷入每件事的局部思維中,恰恰缺少了對于做這件事的目標認知。所以和對方溝通需求的重要性,需求的價值,以及做完之后我們的收獲,你的收獲,試著點燃對方心中的火種。
當然,這種方式不能濫用,否則容易變成“畫餅”,技術同學比產品同學更煩“畫餅”,因為他們的思維更直接,思想更單純。
我也不建議在自己沒有準備好,或者自己沒有想清楚之前使用,容易被對方給懟回來,反而得不償失。
但是,畢竟產品經理的溝通能力理應能夠搞定這個問題,否則將來如何面對客戶、面對上級的各類更加復雜的場景呢?
3、把“令箭”包裝成“雞毛”
古有“拿雞毛當令箭”的俗語,而我今天的第三個解法,則是把“令箭”包裝成“雞毛”。這種方法屢試不爽。
比如,之前客戶提出了一個有點難度的需求,我們設計好方案之后,技術負責人覺得改動太大,于是設計了一個新的方案。
新方案的工作量將近少了一半,大多數場景也能解決,但是拓展性不好。如果這時我們采取較為強硬的態度與其溝通,對方很可能陷入“牛角尖”的情緒,你們爭執一通并沒有效果,反而傷了和氣,于是我們可以采用“緩兵之計”。
之后我苦思冥想,想到了一個特殊場景,這個場景現有的設計無法支持,而此場景雖說頻次不高,但確實存在。剛巧,過兩天我要和技術負責人一起出差,于是我便在出差任務完成后,大家都很放松的時刻提起了這件事。
通過場景描述,再進一步說明這個客戶多么重要,現在雙方合作越來越好,新版本發布之后能夠收到怎樣的效果,讓對方通過場景來發現現階段設計的不合理性。
最終,我沒有說讓他改,他說這玩意得改啊。我反倒“裝起來”問他:這好改嗎?工作量不小吧?他說,一會兒回去6個小時的高鐵,只要沒人打擾我,下車就弄完了。
所以啊,很多時候,工作也是套路和反套路的過程。
4、適度示弱,激發對方的善意
類似的情況,還有一種解法,則是主動“示弱”。
很多人不善于在職場上示弱,會覺得這樣有損形象,但殊不知“越是張牙舞爪的人,內心越脆弱”,主動示弱的人,則是真正的有自信。
記得初入職場的那幾年,有一次在客戶現場做攻堅項目,我負責需求但并不熟悉這個需求,客戶卻是一位老江湖,我始終被牽著鼻子走。在開發階段需求依然經常變更,而且很多變更我都無力反駁,造成團隊內部開發人員也是怨聲載道。
在聯調測試后期,客戶把之前的一個需求變更又改回去了,這次修改浪費了我們兩周的時間。散會之后我不知道如何向兄弟們說這件事,最后采用了主動示弱的方法。
我和開發的兄弟們表達這段時間的委屈和無奈,同事主動過來安慰說:算了,沒事,反正也快上線了,咱們再最后改一次,改完也就熬過去了。
這次的經歷,雖然把當下的問題解決了,但我始終處于自責之中,也為我后續的需求、產品、項目管理等工作積累了一些經驗,這些經驗并不是今天所說的主動示弱,而是在需求把控、進度把控、客戶溝通上的技巧。
所以,每一次失敗,并不是讓自己放棄的理由,從失敗中收獲,整理背包再次上路,才是我們更應該堅持的選擇。
5、一起解決他的問題
如果技術人員確實遇到了難題,我們首先要做的不是“嫌棄”,而是主動伸出手來幫助。畢竟,這是你負責的需求,你也要為最終的結果負責。
所以我們經常會和技術團隊一起分析業務場景和處理邏輯,或者主動梳理系統現狀,從中尋找問題的難點,并試著找出可以解決的思路。
這時,則需要我們對業務場景理解的更透徹,對于功能操作之后的“業務處理邏輯”有清晰的認知。比如我們通過查日志,畫出此功能的現狀流程圖,對照著流程圖進行修改,同時分析出這次變更的關聯功能。
總之,要拿出一個積極的態度和主動的行為,一起解決問題。這樣體驗一段時間之后,不僅自己對于業務的理解更加全面,在同事中的信任度也會逐漸增強。
6、把對方“騙”上一條船
在需求正式開始推進之前,對于系統中涉及的現狀、修改難度、迭代合理性等問題,我們可以提前、非正式、多次和技術人員溝通,其中的一些小問題也可以拋出來。比如現在系統只能支持A場景,如果后續客戶想要支持A+的場景,我們有哪些方式可以拓展呢?
通過技術同事主動幫忙分析建議,最終整理出來的方案,起碼從可行性上不會受到排斥。而且這個過程中又體現了他的價值,開會的時候也可以說,之前通過張三的幫助,幫我們設計出了一個比較可行的方案,下面我們一起來評估一下。
這樣即給了張三面子,又把他拉上船。
7、協調新的資源
這個方式,是大多數同學都會想到的,我把它放到最后,而且也不打算展開介紹。
因為很多時候,資源不會那么容易協調到位,更多的情況還是需要利用現有資源來解決問題。而且上述的6個方法已經能夠解決大多數情況。
自古真情難留住,偏偏套路得人心。
談戀愛如此,推進工作依然如此。畢竟每個人都不是一個獨立存在的個體,也不是說拼到一起就能成為牢固的積木。
每個人都有自己的訴求,每個團隊都有自己的核心利益和目標,每個領導也都有自己更加看重與追求的方向。
所以在這樣一種復雜的環境下,經常會讓我們推進乏力。但只要我們放平心態,冷靜思考,逐個擊破,終究會找到很多種解法。畢竟我們的工作內容和難度,在高水平選手看來并不值得一提。
也許我們追求的技巧,只是別人的基本功罷了。所以這些困難,并不是真正的困難。
三、也許是團隊管理的綜合問題
1、態度欠缺的選手為什么會招進來、留下去?
- 團隊的招聘+用人制度,或執行層面遇到了難題
- “食之無味,棄之可惜”
首先,從面試到轉正,這個過程沒有統一標準,或者缺少一些考核或可量化標準。
不過這個問題比較大,如果細說可能又需要一篇長文。去年我也整理過一些面試、試用期培養/考核之類的經驗,可以查看歷史文章。
相信各個公司、團隊都有相關的流程制度,很多領導也想提升這方面的管理和效率,但真正推進之后的效果,以及人員的執行情況,確實相差甚遠。
畢竟,很多團隊都是在解決看起來“重要且緊急”的事情,從而忽略了“重要但不緊急”的事情,導致惡性循環。
另外,當我們發現有些團隊成員在某些方面存在問題,或者無法達到繼續留用的標準時,也會很難選擇淘汰。
我們暫且不說淘汰相關的利益問題,僅從團隊用人角度來看,經常會出現“這個人雖然有很多問題,但是也能解決一些問題,總比沒有強”、“下一個也許還不如這一個”諸如此類的想法。
因為人的問題,導致事的問題,又因為事的問題,導致沒有精力解決管理的問題,從而惡性循環,疲于奔命。
所以,從上述的需求難以推進,我們可以分析出團隊成員的問題,而團隊成員的問題均來自于團隊管理的問題。
我想,正是這些表象背后反映的深層次問題(當然,如果再去深挖管理問題背后的問題,那又要大書特書,本文就到此為止吧)。
2、資源為什么一直不足?
解決問題時,比如在優先級確實排不開,技術人員確實沒時間,但你又很著急的情況下,我們會很容易想到協調資源。
但是往往這些資源很難協調到,可能我們將長期面臨著在資源不足的情況下開展工作的現狀。
那么,我們可以進一步思考,資源為什么一直不足?是你所處的團隊問題,還是自己負責的需求沒有那么重要?亦或是公司本身的運營模式問題?不同的問題也對應著不同的態度和解法。
并不是一句資源不足,就能解釋這些問題,因為資源只是表象,其背后的底層原因,才是真正的問題所在(我發現最后這四條,每一條都能展開單獨寫一篇長文)。
3、“準入準出”的流程是否完善?
其實這里又涉及到整個項目管理或者研發管理的流程,只不過從產品和技術對接過程來看,主要在于需求分析、系統設計的準入準出條件。
- 需求池的哪些需求計劃歸入下一個迭代版本?不在最初選擇時就挑一個不可能完成的任務,或者對于團隊而言價值不高的任務;
- 需求分析完成后,如何規范需求評審流程,從而保證評審通過的需求能夠順利進入系統設計階段,而非在設計階段質疑需求的合理性并進行推翻;
- 系統設計階段如何保證能夠滿足本次需求的目標,保證最終的交付物盡量不打折扣,保證具體的技術人員能夠理解自己的設計流程和規范
還有很多其他相關的問題,而這些問題背后所反映的則是流程中的準入準出條件不規范,或者執行不足。當這些規范性制度存在之后,也能夠減少在對接過程中的推諉扯皮。
所謂治本,則是從這些方面下手,而不是遇到問題解決問題。
當然,沒有絕對完善的流程,也沒有能夠把完善流程不打折扣落地的執行者。很多流程的推進受阻,除了流程本身的不適用,也存在團隊與流程之間的“水土不服”,這又是一個非常復雜的問題。
我提出這個觀點,并不是說一定要通過流程才能提升效率,而是讓大家提升對于“流程”、“規范”的重要程度,避免在日常工作中僅在思考大量的執行,僅是不斷陷入事務的海洋里,而缺少了探出頭思考習慣。
4、有沒有可能,你覺得是問題,領導并不覺得是問題?
領導并不覺得這是問題,這句話要兩面看:
第一反應可能覺得是領導沒有察覺,進而覺得這領導水平不行,這么明顯的團隊管理問題都不知道,長此以往還有沒有必要長期干下去?
而另一層意思,則是這些問題在領導的意料之中,他采用了“無為而治”的方法,在問題處于可控范圍內時,讓其任意發酵,同時在發酵的過程中,歷練、磨合、篩選團隊成員,從中尋找誰能主動擔責,適合委以重任,誰只能作為一塊磚來使用,誰又不適合團隊現狀。
讓團隊經歷一些困難與磨煉,后續的戰斗力往往會更強。畢竟自己摸索出來的解法,比領導直接安排的流程要更容易被遵循。
如果遇到第一種領導,我覺得還是早遛為上;如果遇到第二種領導,那么恭喜你,你的成長空間還有很多。
四、寫在最后
所以說,很多問題背后的原因并不是真正的原因,透過表象看本質,本身也是產品經理在進行需求洞察時的必要能力。而運用到團隊協作等領域時,這種能力依然可以發揮著重要的價值。
解決問題,既要治標,又要治本,有時揚湯止沸立竿見影,有時釜底抽薪效果更佳。
最終面對今天提到的問題,原因有很多,解法也有很多,更重要的是不帶入主觀情緒,結構化思考,拆解出一個又一個可執行方案,然后在實踐中總結。
畢竟,產品經理是要真正解決問題的人。
今天的分享,有些方法可以直接用于日常工作,有些思維可以幫助我們建立更全面的分析和洞察能力,而且將本文的內容進行提煉精簡,再融入自己工作中的例子,應該能做到一個不錯的面試回答。
希望能為各位帶來一點幫助。
專欄作家
不想延期,公眾號:不想延期,人人都是產品經理專欄作家。半路轉行的B端泛金融產品,堅持“以實踐驗證理論,以輸出倒逼成長”的目標。點滴珍貴,重在積累
本文原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自 Unsplash,基于CC0協議。
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
有思想,有方法,可落地
很棒
都是真實有效的問題和解決方法!我的總結和思路和你完全一樣。我覺得更重要的是團隊氛圍如何營造,建立一個有人情味的團隊文化可以事半功倍。然后就是溝通交流要準確切入。
是的,團隊文化和工作模式非常重要