身為 PM,該怎麼評估一項新需求?身為需求端,又該怎麼跟 PM 提需求?

身為 PM,該怎麼評估一項新需求?身為需求端,又該怎麼跟 PM 提需求?

會想寫這篇文章,是因為自己剛好是從「需求端(行銷)」轉移到現在的「實作端」aka 接收需求端(PM)。

被同為需求端的人問過:「到底要怎樣跟 PM 提需求,他們才聽得懂?」,也被 PM 問過:「為什麼那些需求端怎麼講都講不聽?需求不是這樣提的!」既然發現兩端在溝通上有點落差,那就寫篇文章分享一下個人經驗與想法吧。

這篇文章有點貪心,想要同時滿足 2 種需求的人:

對於接需求的 PM,最在乎的應該是「該怎麼評估一項新需求?」

對於提需求的需求端(如業務、行銷、BD、客服等),較重視的則是「該怎麼提(一個不會被 PM 打槍的)需求?」

文章主軸會從 PM 視角出發,先介紹 PM 通常會如何評估一項需求的緊急度、可行性與必要性,接著則會分享需求端該如何「正中下懷」,根據 PM 評估標準去描述自己的需求。

0. 需求的資訊充足性

「提需求」看似簡單,但不同人有不同做法。我遇過有人把提需求當作許生日願望,只說「我想要做一個 XXX 功能」,也有人把提需求當作寫日記,鉅細靡遺載明人事時地物,還會附加說明自己目前遇到的難關以及對於這個需求的迫切心情。

至於需求到底該怎麼提呢?

其實提需求沒有一個固定格式,每家公司都有不同作法,每個 PM 與需求端也都有各自的習慣。但即使沒有範例文件可以參考,提需求時,可以先想清楚以下幾個背景因素:

  • 目前遇到什麼問題?
  • 可能可以有什麼解法?
  • 這個問題解決後,會帶來什麼好處,或者解決哪些困難?

要注意的是,做為需求端,有時可能只能盤點出目前遇到的問題,不一定能想到解法。這也沒關係,別擔心!因為想解法是 PM、設計師和工程師等實作端的任務,作為需求端,只要把問題與目標闡述清楚,讓實作端找到連結問題與目標的橋樑就行。

而且,只要回答出上面這 3 個問題,PM 就可以寫出一個很粗略的 user story 了,最典型的 user story 公式就是:

作為{某種使用者},我想要{做到某件事},這樣我就可以{達到什麼目標}。

比如:

作為{數位行銷},我想要{讓消費者有優惠},這樣我就可以{吸引更多人來購買公司產品}。

作為{業務開發},我想要{收到更多潛在客戶名單},這樣我就可以{在每天打出更多陌生開發電話}。

這個公式看來簡單,但其實很多人在提需求時,往往會直接落到「解法」,比如上例的數位行銷會直接說:「我想要做折價券功能」或「我想要做客戶消費點數回饋功能」、業務開發則會說:「我想在網站上放一個『請留下 email』的彈窗」。

「忽略目標,直接落到解法」的問題是,因為沒有好好聚焦目標、沒有好好思考問題的根源,所以想出的「解法」跟「目標」之間雖有相關性(correlation),但沒有因果性(causation),且這個解法也不一定是最佳解,反而限縮了實作端發揮的空間。(後面再詳述)

總之,作為需求端,只要用上述公式把需求提給 PM 即可。

當 PM 接到需求後,則可以透過以下幾個元素評估這個需求該不該做(是否受理)、該怎麼做(解法為何)、該什麼時候做(優先級如何):

1. 區分必要(非要不可)vs. 想要(有了更好)

通常最容易的就是先看這個需求是必要(must-have)還是想要(nice-to-have)。簡單來說就是「完成不了這個需求的話,我們會怎樣?」

比如有用戶抱怨網站上的字太小 vs. 有用戶反映用手機打不開網站首頁的某個連結。前者是「事情能完成,但不太能順利完成(用戶依然看得到字,只是嫌字很小)」,後者則是「事情根本無法完成(連結進不去)」,這樣一比,通常後者需求就會比前者更優先處理。

不過也有很多時候,需求端會覺得這個需求是「必要」,PM 卻覺得只是「想要」,那這時該怎麼辦呢?或許可試試後面的步驟,逐一分析這項需求。

2. 商業價值與目標:解決這個需求,將帶來哪些價值

對工程師或 PM 來說,「產品能順利運作、被用戶使用」就是一個產品的最低標,所以需求若與此無關,很容易被 PM 視為「想要」而非「必要」,也就是所謂的「有了會更好(沒有也不會死)」的功能。

然而,這些被視為可有可無的功能,很有可能會帶來極大的商業價值。這時,就仰賴需求端的銷售功力了。

即使都是同個公司的同事,大家的目標應該是一致的,但畢竟每個團隊有不同方式達成同個目標,所以很多時候,仍需要透過各種「手段」(遊說、死纏爛打、內部 pitch、找主管…etc)才能說服其他團隊用你想要的方式達成目標。

作為 PM,產品的好用固然重要,但產品能幫公司帶來價值也非常重要,所以當一個需求很有價值(不論是為公司帶來名還是利),通常優先順序也會比較前面。

比如有用戶抱怨網站上的字太小 vs. 有用戶希望網站舉辦優惠活動時,作為消費者,不用手動複製並輸入優惠碼,可以一鍵領取並抵用。

兩者都是「想要」而非必要,那該怎麼比較?

可以思考的是:做好這些需求,他們各自帶來的價值是什麼?或者換個角度思考:不解決這些問題,用戶會怎樣?會繼續抱怨而已?還是會從此離開、不願使用這個網站?還是營收會有顯著影響?

如果用戶反映的頻率和件數差不多,解決「網站上的字太小」能帶來的商業價值應該遠小於「一鍵領取並抵用優惠」,畢竟後者跟付費流程有更大的關係。

作為需求端,也可以在提需求前多找點資料,比如:用戶多常來抱怨這件事?這件事情造成哪些影響?比如會影響客單價、DAU、跳出率嗎?如果有數字佐證,通常就能夠更快推動實作。

3. 相關性與因果性:這個需求與解法之間的關係

若依照上面的步驟,現在已經完成了 why 的部分,包含:釐清需求、確認需求的必要性、確認需求有其對應價值,再來要思考的就是 what & how,也就是需求的「解法」。

延續上面說的,作為需求端,其實大可不必直接給出建議做法,而是提供足夠的背景資訊與需求脈絡即可,比如目前遇到什麼問題、為什麼想要做,至於「要怎麼做」,需求端當然可以給建議,不過也要留給實作端一點空間。

原因主要就是前面說的:如果直接落到解法,有可能會出現「該解法不一定能真正解決原本的需求」的窘境。

比如業務團隊發現某功能的點擊率很低,直覺推測是因為該功能的入口不夠明顯,所以直接要求設計師把入口的文字顏色改得更顯眼、文字變得更大。

然而,這個「點擊率低」的問題背後可能有很多原因,比如:用戶有看到入口,但覺得這功能沒什麼用,所以不想點、用戶其實有點擊,只是內部數據異常、用戶根本沒有看到這個入口、用戶有看到,但甚至不知道這是一個入口。

上述每一個原因都會導致「點擊率低」,但有趣的是,每個原因的解法都不同,所以這就是前面說的:如果沒有跟產品、設計或工程團隊好好討論,而是從需求直接落到解法的話,很有可能出現「需求與解法之間無因果性」的狀況。

事實上, PM 在跟設計或工程團隊討論需求時,也不太會直接說:「這個需求我想好解法了,你們就照做即可」,而是會跟團隊說:「關於這個需求,我有想出幾個解決方式,但不確定有沒有更快或更適合的解法,我們可以討論看看」。

因為 PM 通常最在乎的是商業目標與整體產品的走向,而設計師更具有 UX 和 UI 的專業,能更全盤地思考並顧及使用者動線與整體操作流暢度;工程師則是實際要去解決這個需求的人(畢竟他是團隊裡負責寫程式碼的人),他通常會較在乎這個解法的通用性與可擴充性,比如這個解法會不會太過客製化,進而影響運作效能?這個解法能否也運用到其他情境,達到通用性?如果未來流量和用戶變高了,這個解法是否依舊有效?

團隊中的每個職能對於同一需求的思考角度不同,所以想出的解法也會不同。總之,作為需求端,會建議給團隊多一點思考與發揮空間,即使最後每個人對於「最佳解」的看法不同,但至少能找出一個折衷解法,有時甚至會有更好的想法出現,最後便能在「大家都覺得這樣可以」的狀況下,完成該需求想達到的目標。

4. 技術可行性:這個需求的解法要花多少成本才能達成

現在又接到了不同的需求:行銷團隊想要做團購功能、業務團隊想要做購物車功能,兩者都跟付費流程有關,且預期帶來的收益都差不多,那怎麼辦?

作為 PM,這時通常會先跟設計師與工程師討論,先和他們做些前情提要,並說明大概的解法、會影響到的部分(比如這些功能需要新增哪些對應的頁面與資料庫欄位、這些功能大概的操作流程),讓他們做出初步的評估。

即使沒有 wireframe 和 user flow,實作單位通常掌握上述基本資訊後,仍能評估出一項需求是「很快可以搞定」、「有點難,因為之前沒做過,但研究一下就可以」、「因為涉及到 #$% 問題,所以會蠻複雜」。

當收益相同,決定優先序的主要變因就是人力與時間成本了。如果一個需求需要花三個月、另一個只要一個月,那「通常」會先選後者,畢竟可以較快看到成效。

某些狀況下,需求端會跟實作端商量「分批交付」,比如原本要做到 100% 的話,需要三個月才能上線,但因為團隊預期該需求帶來的效益驚人,或者老闆真的把死線壓超緊(這可能是更常見的原因吧),需求端希望能早點上線,所以可能做完 30% 或部分功能就先上線,如此一來,可能只要一個月就可以先驗收需求了。

5. 副作用:這個需求的解法是債留子孫還是讓後人乘涼

延續上一段提到的「如果一個需求需要花三個月、另一個只要一個月,那『通常』會先選後者,畢竟可以較快看到成效」,這裡強調了「通常」,代表絕非定則。

有些需求的解法是一勞永逸,有些則是短期的折衷做法,可能是被時限所逼、也可能是當下沒有更好的方式、或者當下的各種環境,所以會採用所謂的 workaround,代表這只是「暫時性」的解法,終究有某天會需要找到真正能解決這個棘手問題的辦法。

workaround 有時候會變成技術債或產品債,技術債就是未來接手的工程師看到時可能會生氣的東西,比如不合邏輯、沒有依循原本模式的程式碼,或者太客製化的處理方式等;產品債也是類似的意思,可能是未來產品迭代時,都要為了這個功能去設想對應的使用情境,或者根本會因此而無法迭代,需要砍掉重練。

總之,雖然大家很常把「反正之後這個功能也不一定是我來優化」掛在嘴上,但秉持著基本的良心(?),還是會建議在提需求與排序需求時,都要考量到完成這些需求後,會帶來哪些正面與負面的效益,不要因為有時限壓力或主管施壓等外在因素,而太輕易做出飲鴆止渴的決定。

以上大概就是 PM 接到一項需求後會開始思考的問題,也是 PM 在評估、排序需求時會參照的點。

不過畢竟產品跟團隊一樣都是有機、不斷變化的,所以上述這些也只是個基本規則,比如若是在重技術的公司,商業價值和用戶體驗就不一定是優先考量;相反地,如果產品非常在乎用戶體驗,那或許團隊會更願意付出開發時間或容忍一些客製化情境。

總之還是老話一句:實際要怎麼做,仍是因人而異,也就是 by case 啦!

 

本文轉貼自:MH原文連結

本站所有文章未經事先書面授權,請勿任意利用、引用、轉載。