PM每天都在跟不同部門、職能的人打交道,面對新需求時要如何溝通協調?本文列出5種常見的PM與需求端溝通的情境,例如需求 / 痛點太模糊、需求不合理、時程緊繃、開發資源不足、需求臨時變動……等,並分享適合的應對方式及建議!
文/MH
作為PM,應該每天都在跟不同部門&職能的人打交道,比如跟工程師討論哪個需求的哪個部分不好做,有沒有替代方案、跟QA確認測試範圍和各種極端案例該怎麼處理、跟設計師來回拉扯畫面上的各種排版、顏色、文案與字級大小,此外,還得跟需求端討論要處理哪些需求、怎麼排優先級、時程該怎麼調整。
跟需求端溝通,既需要腦力也需要耐力,這邊並不是說需求端有多可怕(但當然,有些真的很可怕……),而是因為多半的需求端並非來自產品或技術相關背景,他們不知道(也沒有義務知道)這些系統背後的運作邏輯是什麼、哪個功能是怎麼做出來的、為什麼這個功能只要這樣用……等,即使我自己也被需求端搞瘋很多次,但理智的我還是認為,一個好的系統或產品應該要讓用戶能「無痛」上手,不該是用戶去習慣或刻意認識某些功能或介面。
話雖如此,還是會有許多情境得仰賴PM的腦力和耐力,用最簡單但明瞭的方式讓需求端知道why & why not,以下會以各種「PM跟需求端協作時,常會遇到的頭痛情境」舉例,或許會對於需要頻繁和需求端溝通的PM有些幫助。
「需求端」來自四面八方,在此先把他們的「用途」視為「PM所負責產品的主要聯絡窗口」,比如產品改版需要收集用戶意見、安排時程等,這個「需求端」通常即有一定的責任和權力和PM一起處理這些事。
所謂的「需求端」,可能是「客戶」,也可能是「用戶」。比如做to C產品,通常各種需求都是來自於第一線的使用者,就像你我對於instagram就是這樣的關係;做to B產品,提需求的人很可能只是負責採購或導入這個產品到企業端的「間接」使用者,可以廣泛地稱他們為「客戶」,且他本人不一定真的是該產品的使用者,有時只是負責轉達其他人的需求。
至於我現在做的企業內部產品,提需求人的既是直接用戶,也是間接用戶 — — 比如財務系統的PM的需求端就是來自於財務部門的某個同事,這位同事本人平常就有在使用財務系統,但與此同時,他也會需要收集其他人的意見,並且和財務系統的PM一起討論這個系統後續有哪些要優化的地方、哪些優化又應該被視為最高優先級、這些優化該什麼時候上線等。
介紹完需求端,下面就列出一些常見的PM與需求端溝通的情境,看看PM有哪些比較適合的應對方式。
一個產品/功能的需求端來自各個部門,其中很多人都沒有產品相關背景,所以討論需求時,難免會讓PM有種「你怎麼連話都說不清楚」的感覺,這時PM就要扮演循循善誘的角色了(後面會一再出現「循循善誘」的相關例子)。
最近一次發生的案例是,某個部門的HR跟我說:「你們這個考核系統用手機真的是太難用了,能改一下嗎?」
在最初設計這個系統時,由於資源有限且當時沒有需求,就沒有考慮到行動版的使用場景(但也沒有完全阻斷行動版的入口),所以的確用手機進入考核系統的網站後,就會感受到一場災難……但我除了說明這些背景、同意HR感受到的痛點之外,也有追問HR:「是怎麼樣的『難用』呢?我想知道你會常用哪些頁面或功能,我們可以著重改進那些地方,不然整個系統如果都要做成行動版,這樣要等太久了。我們先從最有感的地方改起好嗎?」
所以接下來我們就一起討論,並決定要優先改良行動版操作體驗的部分(比如哪幾個頁面、頁面上的哪些功能等)。這整個過程讓我可以更清楚用戶的痛點、需求到底是什麼;對HR來說,他也藉此了解要怎麼把需求說得越來越清楚。
後記:這次優化上線後,我稍微感受到的是,HR 似乎頗有成就感,對產品團隊的信賴感也有提升;若要猜測原因,或許是因為他提的意見和疑問都有被好好解答,需求也有被好好處理吧。
建議:當需求端給的需求/痛點太模糊,PM 就是一直往下追問、追問再追問!
PM做久了,或許會有一種「什麼需求都有、什麼需求都不奇怪」的麻痹感,但如果照單全收,也很容易造成自己在跟設計師或工程師過需求時被挑戰,所以如果接下了連自己都無法認可的任務,到時累的也是自己……那不如在一開始就先好好把關。
有些需求很具體,但卻「不合理」。但「不合理」又分兩種,一是「痛點本身就不合理(或者痛點並非產品所造成)」,二是「痛點合理,但(需求端提的)解決方式不合理」。
如果是前者,通常我會直接(委婉地)告知對方,這是流程問題、不是產品問題,已經超出產品本身能協助的範圍了。這邊再拿上面提到的考核系統為例,曾有主管反應寫考核的時間太短,希望能有AI生成內容、考核模版等輔助功能,以便他在更短時間內寫完所有下屬的年度考核。然而,「寫考核的時間太短」這個痛點並非考核系統所造成,可能是該名主管的時間管理能力有待加強,也可能是公司給的寫考核時間真的太短。但無論如何,提供「AI生成內容」或「考核模版」對考核系統這種企業內部工具來說,都不是一個優先級很高的需求,且甚至不太合理。因為「考核」重視的是「品質(主管是否有給出有建設性且務實的意見)」而非「數量(主管完成考核的時間、整體效率)」。
上面說的例子是「痛點本身就不合理(或者痛點並非產品所造成)」,那如果是二「用戶痛點合理,但(需求端提的)解決方式不合理」呢?
有時候PM在收到需求時,儘管覺得不合理,但無法馬上說服需求端並擋下需求,或者需求端聽不進去,如果兩邊意見不同,盡量試著爭取時間去驗證這個需求的合理性與效益,比如做用戶調研(用戶訪談或問卷等)、數據埋點/撈數據等。
如果時間真的太有限,來不及做上述事情,至少請對方提供更多佐證或資訊,比如先問問需求方:
根據個人經驗,有時候需求端不一定有仔細想過這些問題(畢竟他們上面也是有老闆),可能只是某個主管施壓或隨口提到「如果可以#$%^就好了」,他們就沒想太多來找PM討論,一旦有時間細想,禁不起這些「靈魂拷問」的偽需求就會逐漸消失了。
建議:當需求端給的需求太荒謬,建議PM還是要擔任「需求守門員」,別只把自己當成需求傳聲筒,這樣久而久之,只會讓團隊越來越感受不到PM的重要性和價值。
這應該也是產品開發的過程中必然會遇到的問題,就是需求端期待的時間 vs. 開發端需要的時間很常沒有共識。PM們應該很常聽到需求端說:「這個很簡單吧?」、「改一下很快吧?」、「這個小東西應該不難做,兩三天能做完吧?」而且,不要以為只有不熟技術的人會這樣說,其實我也很常遇到工程師這樣說!
有時候(尤其做內部產品,其實是「很多時候」)這些需求和時程都擋不住,大老闆就是想要「又快又快」,那麼底下的產品團隊也只能在內心高歌一句「需求來得太快太像龍捲風」(2000年的杰倫金曲,現在還有人知道這首歌嗎?),然後硬著頭皮加班趕工。
但如果可以,作為PM的我還是會盡量跟需求端討價還價,苦口婆心地跟他們說明時程來不及的原因,希望他們可以好好考慮調整預期的死線。在這整個過程中,我的心態都是「寧可囉唆,也不要馬虎帶過」,畢竟還是希望維持和需求端的合作關係,沒有必要為了一個不合理的死線而讓雙方的溝通馬上陷入死局(尤其來日方長,未來搞不好還得跟同一人繼續共事)。
比如一個功能需要15個工作天才能做完,需求端卻期待5天做完,這時我不會只說「真的來不及」,而是會試著給一些折衷方案,比如:功能可不可以簡單一點?適用的情境可否縮減一些?可否用其他方式達到同樣目的?這時,如果需求端還是不接受,至少PM的立場可以是「不是沒有給你選項,而是這些選項你都不要」;如果什麼都沒給,需求端很可能會覺得PM沒有在解決問題,這對雙方的合作關係也沒幫助。
雖說不想跟對方交惡,但如果碰到太強硬的需求端,建議PM還是得設好底線,並且要好好尊重這個底線!比如上面這些折衷方案都被拒絕的話,我也只能告訴對方:「我有提供這些選項,但如果我們都沒辦法各退一步,那不好意思,我們真的沒辦法在你預期的時間完成你想要的東西」。
作為PM,有時得勇敢當壞人(或者把主管推出去當壞人),如果碰到什麼需求都照單全收、什麼荒謬死線都答應,最後只會搞得整個產品團隊都在加班趕死線。個人認為「加班是最蠢的解法」,一旦答應了加班,往後有類似情況,很容易給人一種「沒有加班解決不了的問題,如果有,就再繼續加班」。
前陣子耳聞現職公司的某團隊在某地區的工作文化是「直接壓死線,不需工程師估時」。也就是說:不管這個功能要做5天還是50天,都沒關係,因為工程師的估時是「被」死線決定的,如果平日8小時做不完,那就加班;如果還是做不完,那就週末繼續。
作為PM,個人認為這個工作的職責是「在合理範圍內使命必達」,而不只是那麼簡單的「使命必達」。
當PM終於釐清需求、跟需求端討論好要做哪些東西、協調雙方都同意的死線後,功能終於可以準備進入開發了。但~總是會有那麼一個「但」,可能原本排好的開發資源被借走了,那該怎麼辦?
這又是一個我很常經歷的悲慘情況。我目前負責4~5個企業內部產品,在人力有限的情況下,這些產品之間必定得先排出優先級,更麻煩的是,這些產品所屬的工程師們,他們也是一人得兼顧多個產品,所以「工程師得先做哪一個產品」也有優先級,PM之間也時常需要協調同一個工程師手上的多個產品的優先級。
以我目前負責的某產品來說,已經長達一年沒有工程資源,但產品本身還是有極大量的內部用戶存在,所以bug待修清單也只能越累積越長了……。
有的需求端聽完上述情況後,知道再怎麼提需求也沒用,不如繼續忍受現況;但我也碰過非常有毅力的用戶,剛開始是動之以情(「沒有這個功能真的太崩潰啦,每次要手動自己處理都很花時間,能不能幫個忙,請個工程師來看一下,這個功能做起來很快的」),到後來還搬出他團隊的工程師說之以理(「我們這裡總共有xx個團隊都需要這個功能,也能節省大約xx的時間,影響非常大的!而且我看了一下,你們改動大概也只需要xx天,做起來效益很高」),真的是非常鍥而不捨。
然而,沒資源就是沒資源,再怎麼喬也沒用,最後我還是只能用一樣的原因(真的沒有開發資源)拒絕這位用戶的需求(儘管他的需求真的非常合理、也很值得開發)。
建議:如果做不了這個需求,我還是會建議PM就說「現在真的做不了」,不要為了敷衍對方或拖延而說「有機會會安排」或「我們再看看」這種模糊的話,因為這會給需求端錯誤期待,或許過幾天他又會來問「那安排得如何」?PM能做的就是把這些願望們放到backlog,之後真的有餘裕時,可以從backlog(有點像是產品的待辦清單)撈一些功能來做。
這段又得拿前面的考核系統為例,由於公司固定會在5月進行年中考核,所以作為考核系統的PM,我在Q1就會開始跟各部門的HR收集需求,這樣才能在4月時整理需求、發想功能,以便後續進入設計與工程階段,等到5月的年中考核來臨前,就可以把相關需求都完成並推上線。
然而時間來到4月中,團隊已經準備要開始做某個功能了,這時突然有個公司的高階主管跟HR反應,他覺得系統內缺少某個功能,讓他使用上非常困難且困擾,所以要求HR想辦法,於是HR就找上我了。我和HR在最短時間內釐清這個高階主管的痛點、和設計師一起討論解法,結論是:HR擋不了這個(說話很有份量的)高階主管突如其來的許願,而工程師評估這個功能不算太難做,一週內可以搞定,所以這個需求算是非做不可。
但問題來了:我們在年中考核來臨前已經排滿了開發時間表,沒有那奢侈的一週空檔可以讓這個需求插隊。
這個問題跟上一段提到的類似,就是實務上很難兼顧「最短時間」、「最少人力」、「最多/最佳功能」,不過「幸好」這次是需求端(HR)自己先變卦,所以作為PM的我更有立場去討價還價。像這次原本已經要做3個需求,現在再加進第4個的話,要麼拿原本的需求來換,要麼延長死線,畢竟凡事都得有個取捨嘛。
剛開始HR有點為難,畢竟這些需求已經是他們精挑細選過的,所以他們也不知道該拿掉哪個需求;但HR也不能改動需求要上線的死線,因為全公司的考核時間都是一樣的,不能因為這個功能而異動原本的考核時間線。
我也理解他們的猶豫,於是我給了另一個方案:原本做完這些需求後,整批開發團隊要去趕另一個內部系統的功能。如果他們可以自己跟那個內部系統的需求端協商,那我們就有時間可以做這個功能。後來他們真的也協調好了,決定先以考核相關的需求為優先,另一個系統的需求可以暫緩,所以這4個需求最後也如期上線啦。
建議:PM 要不斷「提醒(教育)」需求端「什麼叫做『取捨』」,取捨很難,但就是有取捨的必要!如果每一個需求都很重要,那不就代表什麼都不重要了嗎!
會想寫這篇文章,一方面是想分享一些工作心得(就如前面幾段寫的),另一方面其實是想記錄自己心境上的一些變化,我就寫在最後這段了。
作為PM,工作中每天都在面對各界壓力、每天都在喬時間、喬人力、喬功能,剛開始的我,會想要盡善盡美,覺得重要的事情能做就盡量做。
我永遠記得,加入公司後的第一個中秋節適逢週末,我和幾個同事相約去烤肉,在賣場採買時,手機突然響起,是某個需求端透過公司通訊軟體打給我,要跟我討論某個需求。那時候還很奴(他奴我也奴),他提完需求後,我還真的再打給工程師,問對方一些技術細節。後來回到同事家備料時,我幾乎沒有參與那個過程,因為我一直在打字和講電話……。
現在回想起來,真的很對不起那位工程師(當下也覺得很對不起他,但還是希望能把需求端那邊顧好),也很對不起當時的烤肉夥伴(那個當下我只是『肉身』在現場,但根本沒有參與到活動),以前的自己總是想要多做一些,會為此四處找資源、壓時程、砍規格,需求端的確很滿意,但自己和開發團隊真的好累好累。
經過這幾年後,歷經公司的一些風波和個人經驗,總覺得自己和團隊的努力越來越被當作理所當然 — — 「多做的」被當作「該做的」,而且兩者並沒有得到很不同的迴響或實質鼓勵,久而久之,要說自己的心態被玩壞也好,要說是變得自私/務實/勢利都好,總之,終於有種「看開了」的頓悟感。
註:這個「頓悟感」是來自很具體的兩個工作上的事件,礙於隱私,這邊不能細說。但這種「頓悟」本來就是很個人的事情,每個人都有不同的「引爆點」,大概真的要碰到了才會知道吧。
現在碰到上面這些情境,第一個念頭不再是「要怎麼才能達到你的期望?」,而是覺得「我何必把自己和團隊逼死?」。
所以呢,現在碰到有需求端想要壓死線,有時候甚至還有些更激動的人會說「我請我主管去跟你主管聊聊好吧?」之類的話,意思約莫就是暗示「既然跟你談沒用,那就叫你主管出來」。
碰到這種,我剛開始還會覺得有點不好意思,不想要因而驚動到我主管,也怕主管難做人。但現在碰到這種人,我會欣然接受……都會直接跟他說「你可以去找我主管沒問題,如果能幫我要到資源就更好了!我也跟組內爭取過很多次了,但就是沒人呀,你去說,或者找你主管一起去說,搞不好更有份量呢!」
我也沒有想要酸對方,而是真心這麼覺得。如果他在我主管那邊碰壁,代表我和主管口徑一致,對方也會更加心服口服、尊重我的判斷與決定。如果主管真的答應了,那這就是另一場我(以及開發團隊)和主管的戰爭了,不過這個和這次談的主題就沒關係,如果真的有碰到(希望不要),再寫成別的主題分享吧。
最後的最後,還是要強調一下,最後這段結語的意思,絕對不是叫大家將就或隨便,該做的還是要好好做!重點是要找到一個「甜蜜點」,也就是在完成(大多數)用戶期待之餘,也要注意自己與團隊的身心是否健康、做的事情是否有價值,而不要淪為需求端的應聲蟲,畢竟這樣長久下來,對自己、對團隊都不是一個很友善且能永續的工作方式。
(原文標題:說「不」的勇氣:如何跟需求端溝通&協商)
沒看到有興趣的職缺嗎?
你是搶手的數位人才嗎?104有超多寶藏職缺等你探索⮕