1. 程式人生 > >漫畫:程式設計師,你能“管理”好你的產品經理嗎?

漫畫:程式設計師,你能“管理”好你的產品經理嗎?

一、第三選擇

在工作中,你面對產品經理的各種需求變動、專案經理對關鍵點的 Deadline,總會有一些衝突發生。而對於事情最終執行的開發人員來說,如果這些衝突處理的不好,可能就會變成你個人的問題。

做為最終實現功能的程式設計師,你總不會想被貼上一個 “無法按時完成任務的開發” ,這樣的標籤吧?

這些問題,其實都可以借鑑第三選擇的思想來解決。《第三選擇》是一本書,作者是 史蒂芬·柯維,我想說到該作者的另外一本書,應該更多人能知道,《高效能人士的七個習慣》。而在《第三選擇》中,他把之前的七個習慣濃縮成一件事情,可以說,第三選擇是解決所有難題的關鍵思維。

當我們面對衝突的時候,正常的思路如何解決?

  1. 我打敗你。
  2. 我認慫,你打敗我。

而站在第三選擇的思維下,你還有一個選擇:我們共同找到一個雙方都能接受的解決方案,達到共贏。

注意,這裡的第三選擇,絕對不是來自某一方的妥協,或者一人讓一步,核心思想是創造力。如何通過第三種選擇,雙方協同達成另外一個更好的結局。

例如兩個人分蘋果,一人一半?這個方案對兩個人都有虧欠,畢竟我贏了是可以得到一個完整的蘋果的。那什麼是第三選擇?我們把蘋果拿出去換點什麼,然後再來分,或者把蘋果種成蘋果樹,只要願意長線投資,最終我們一人可以收穫半棵樹的蘋果。這些都是第三選擇,只要雙方能達成共識,這是一個雙贏的局面。

二、面對產品經理的衝突

那麼我們在和產品經理合作的過程中,通常會面臨什麼衝突?

2.1 現階段,技術上無法實現的需求

不能要求所有產品經理都是技術出身,當產品經理對技術細節不那麼瞭解的時候,總會有一些異想天開的產品方案。當然有一些並不是技術無法實現,可能是現階段你的團隊實現起來會很吃力,可能會面臨一些未知的坑,而導致整個專案進度很難把控。

面對這樣的需求,你不要直接拒絕,尤其是不要立刻拒絕,說這個需求做不到,這就把對方推入了衝突的局面。你拒絕他,不做這個需求了,或者他說服你,強行要實現這個需求,這都不是我們想看到的。

那現在冷靜一下,想想第三選擇?

我想大多數產品方案,其實並不是唯一的解決方案,你總是想到一些更容易實現的方案的。

你可以問清楚對方的真實需求,給出一個你可以做到的方案,而不是直接拒絕對方的方案。

2.2 需求複雜度和開發時間不匹配

當你面對一個過於複雜的需求的時候,可能因為各種原因,給予你實現功能的時間並不寬裕。

這個時候怎麼辦?自己加班加點完成嗎,大家都是程式設計師,加班寫出來的程式碼具體質量如何我想你也應該心裡有點數。你因為加班寫出了質量不好的程式碼,於是上線之後的 Bug 增多,還需要花時間處理,並且新週期新需求也立刻緊跟上來,發現質量不好的程式碼擴充套件性差,想重構時間上又不允許,只能打補丁,越幹越慢,越幹越爛,Bug 越來越多,於是你壓力越來越大,被抱怨的越來越多。

現在欠下的技術債務,之後總是要償還的,否則長此以往,只能是惡性迴圈。

這個時候直接答應或者拒絕,又會陷入衝突的境地。想想第三選擇,你不要直接說 “不”。你應該先了解清楚,他為什麼要這麼做這個需求?出發點在哪裡?目的是什麼?當你瞭解清楚產品經理對這個需求的真實意圖的時候,你可以從自己技術的角度,給出一個自己能接受的方案,或者和對方討論出一個性價比更好的方案。

能討論出一個大家都接受的方案,固然是好的,但是如果依然很需求複雜,時間和複雜度依然不匹配,怎麼辦?

可以選擇拆分需求。你可以說,這個需求我仔細分析了一下,需要做 A、B、C 工作,以現在分配的時間來說,我只能做到勉強實現 A、B,並且 B 並不保證質量,你看你這個功能,我們能不能拆分成兩期來實現,調整一下需求,這樣我能保證程式碼質量,第一期先保證基本功能,上線讓使用者來驗證需求,第二期再根據使用者的反饋調整細節。

相信我,產品經理也是有各種壓力的,他也需要保證進度在推進,在一個完成和完美的選擇中,我想這不難選擇。

這裡的訣竅是:當我不能完全滿足你的時候,我可以選擇有條件的滿足你。

這樣的好處在於,你把選擇權留給他了,這一部分壓力是你們共同在承擔。如果誰對於這樣的延長的週期有異議,你的產品經理也會幫你說話,說自己需求設計的很細,所以我們決定按兩期來做,這樣也顯得他對需求細節的把控很有力。

2.3 需求變動太頻繁

作為開發,有時候自己寫程式碼的時候,可能寫著寫著發現最初的方案或者選型不合適了,就會主動去調整程式碼、重構程式碼。而產品經理在設計需求的時候,也會有這樣的問題。可能是開始沒有考慮的那麼細,可能因為來自第三方的壓力等等問題,種種原因吧,最終導致需求需要調整,而產品方案的調整,在開發週期內,他是沒法自己獨自調整的,工作壓力一定會轉嫁到實現需求的開發身上。

首先我想說,需求變動是一定會發生的,所以擁抱變化。

本身在需求排期的時候,開發者就應該預留出一些時間來應對這些變化,可這也架不住產品太頻繁的變動,甚至太過分的明天要封板了,今天還在改需求。

這樣的情況,你需要做的是儘量和他捆綁壓力,既然對方把壓力給了你,你要想辦法把這個壓力還回去,讓對方和你一同來分擔這個壓力。

我通常的做法是:

1、先用快捷的方法實現並上線,後續再要時間償還債務

我想很多功能,總是有一些粗暴而不優雅的方式來實現,而這些都是技術債務,之後是需要時間來償還技術債務。

要讓產品經理認領這些技術債務,並且必須立刻給予時間來償還這些債務。

最簡單的一個選擇是,我可以加班加點以一個比較粗暴的方式完成這個需求,但是面臨的問題是後續可能效率會有問題、擴充套件會有問題等等。這事後,下個週期我需要額外多出一個星期的時間來優化這一段程式碼,這就是對技術債務的立即償還。

2、拆分變動

和之前的思路一樣,將變動在現有的基礎上最小化,以最精簡的方式去完成這些變動。

如果沒法精簡,想辦法拆分成二期來實現。

3、增加變動成本,給予對方壓力

雖然所有需求上的變動,最終影響的是開發人員,但是並不是說其他人就沒什麼事情可做了。想辦法增加產品經理的變動成本,讓他來共同承擔壓力。

例如:

  • 增加了這個功能,UI 也需要變動,那你能不能和設計師溝通我們這一期就不要扣太多 UI 細節。— 減少溝通成本
  • 這個需求的變動影響了原本的開發安排,你看能不能將另外一個需求(不那麼重要)延期。— 置換不重要,但是需要花時間做的事情
  • 這個需求如果遇到這樣的情況,是不是沒有辦法得到處理?— 提醒他完善需求,避免再次改動
  • 這個需求還有一些 “資料” 需要處理,你看能不能手工幫我處理一下。— 給他找點事兒做,有點損,不推薦

寫在最後

在工作和生活中,不要把所有事情的解決方案都放在:不(第一選擇,要贏)或者 是(第二選擇,認慫)上,如果只存在兩種選擇,很容易就進入一種推拉的環境中,實際上是可以考慮考慮第三選擇 。

第三選擇並不是某一方的妥協,他的核心思想是創造力,找到新的出路,讓雙方協同找到一個大家都能接受的新方案。

說了這麼多,其實都是《第三選擇》的思想,推薦閱讀。

今天在公眾號後臺回覆成長『成長』,將會得到我整理的一些學習資料,也能回覆『加群』,一起學習進步。

推薦閱讀: