Project 🚩產品經理需要懂技術嗎?從三大情境的提問來避免技術風險

Jayden Lin
Aug 2 · 9 min read

筆者任職 Yahoo ,《軟體需求溝通 ─ 從外商公司學跨部門協作開發》線上課程講師,紛絲團《程式猿吃香蕉🍌》

Hi 大家好,我是 Jayden ,最近看到幾篇文章討論到「產品經理需要懂技術嗎?」,這讓我想起很多 PM 曾經問過我類似的問題,甚至是直接問我要不要去學習寫程式。

先說結論,我認為產品經理需要理解的是「技術風險」相關的知識。舉例來說,若將軟體開發比喻成蓋房子,產品經理不會親自蓋,但會需要知道在蓋大樓前,要先有地基才行,否則會有「風險」。我在美國遇過幾位很厲害的 產品經理,他們雖然不會寫程式,但是都有能力掌握技術風險,這項關鍵的能力也讓他們脫穎而出,有辦法完成重大的專案。

如果對我在跨國開發的血淚有興趣的話,可以參考:

這篇文章將會分享技術風險怎麼影響到產品功能,然後依我過往的經驗,分享實用的方法,說明產品經理怎麼透過「提問」來避免技術風險。

由於我主要的經驗是在網路軟體產業,所以以下的經驗主要也是面向網路軟體產業的產品經理

▍技術風險怎麼影響產品功能

考量以下的情境:

「促銷活動第一天網站就掛了,是不是沒規劃好?」

「系統 1 個月要停機維護一次,上線前都沒考慮到?」

「使用者抱怨下訂單後 10 分鐘還收不到認證簡訊,怎麼規劃的?」

「我們要多支援一種登入類型,什麼?為什麼做不到?」

以上的情境,就是因為忽略技術風險,影響到了線上產品的功能。這樣深陷技術風險的情況,可以用下面這張圖來說明:

相信許多作敏捷開發的人對於這張圖都不陌生,它的原意是指「做軟體要循序漸進地、持續交付價值」,當客戶想要一台車的時候,我們應該要在每一階段的軟體釋出都滿足客戶一點點,圖中建議我們要像圖的下半部那樣做軟體:先做滑板車、再做腳踏車、再做機車,最後做汽車,而不是像圖的上半部那樣一次交付一個零件(無法提供任何價值),但是這裡我想指出的是:

先做腳踏車最後做汽車的作法,是忽略技術考量的,每個階段幾乎是要砍掉重練。

我們只在意「功能」的結果,就是忽略技術上的風險,導致在錯誤的基礎上 (滑板車) 一路走到黑。以蓋房子的方式譬喻,就有如你不知道蓋大樓前要先打好地基,每一次蓋更高的樓都要重蓋,徒增了很多不必要的成本。

產品經理會根據商業目標規劃產品功能,而技術是實現些功能的方式。如果不具備技術風險相關的知識,在長長的需求待辦清單裡面,可能會過於重視產品功能的優先序,而忽略技術方面的規劃。

在需求管理的專業術語裡面,會將需求分為兩類:

❶ 功能性需求 (Functional Requirements):定義軟體要做什麼(What)? 例如:

❷ 非功能性需求 (Non-Functional Requirements):定義軟體要做得多好(How Good)? 例如:

其中,非功能性需求會決定產品的技術風險,我認為產品經理需要具備的技術知識是:要有能力「問」出非功能性需求,有句話是這樣說的:

有時候你不問,我不說,事情就這樣錯過了

產品經理跟工程師的關係也是一樣的,有些風險產品經理不問,工程師不說,可能就會造成問題。我記得我遇過一位產品經理,他在產品討論時有點不好意思地跟我說,他想要確認更多細節,因為:

If I don’t ask, the issue could happen.

他的每個問題都很精準地確認了技術風險。我認為能夠做到這樣就已經是具備有「技術」力的產品經理了。以下我將分享實用的技巧,從三大情境的提問,幫助產品經理了解這些技術風險要怎麼「問」出來。

▍從三大情境的提問來避免技術風險

在現實世界當中,系統會面臨各式各樣的情況,不一定時時刻刻都保持高效地運轉,舉例來說,系統在面臨尖峰流量的時候,吞吐量可能會降低。在產品規劃時,需要考量這些系統限制,否則很有可能上線後會面臨很大的風險。

以我的經驗,產品經理可以透過「使用狀態」、「環境與資源限制」、「系統執行週期」這三大不同的情境,把非功能性需求「問」出來,來避免技術風險,以下依序介紹。

1. 使用狀態

系統的使用狀態會影響它的表現,我們可以考量使用量以及使用對象。

(1) 使用量

可以對使用量的情況問一些問題,比如說考量峰值的情況,或是確認是否會因為使用量變多,造成互搶資源的情況:

(2) 使用對象

系統的使用對象可能會在你的預期之外,一些意料之外的使用方式可能會造成系統崩潰,所以要確認系統的使用對象來避免技術風險,例如以下的情境就需要被問出來,才能事先做好準備:

2. 環境與資源限制

系統實際的運行環境可能跟你想的大不同,我們可以考量客戶端狀態、網路限制、運算資源以及法規來避免技術風險。

(1) 客戶端狀態

使用者可能會用不同的裝置使用你的產品,因此客戶端狀態需要多加確認,產品經理可以這樣問:

(2) 網路限制

不同的網路頻寬會帶來不同的使用者體驗,Facebook 和 Gmail 都有針對網路延遲高的偏遠地區提供簡易版的網頁,因此產品經理在規劃產品時,也需要考慮網路限制,產品經理可以這樣問:

(3) 運算資源

以產品經理來說,並不需要知道運算資源的實際運作方式,但需要提醒工程師思考當運算資源過載的時候,會不會影響到產品體驗,例如:

(4) 法規

法規遵循也是產品規劃的重要一環,要確保我們產品的實作是遵循法規的:

3. 系統執行週期

系統跟人一樣,有不同的週期,例如:人在晚上的時候會累,早上的時候精神比較好,系統也有它的執行週期,在系統狀況比較緊繃的時候,可能會有不好的表現,產品經理需要知道的是:在這些不同的系統週期當中怎麼去避免風險。

產品經理可以確認在系統的啟動部署時、備份時、批次處理時、維護時、故障時會有什麼特殊狀況,會不會影響到我們產品的使用者體驗。

(1) 啟動 & 部署時

在系統剛啟動的時候,會有先後次序之分,可能會有部分服務較晚啟動,影響到產品使用,這時候要確認這些延遲的時間是否符合商業的目標,例如:

(2) 備份時

在系統進行資料備份的時候,可能有些服務會暫停,這時候產品經理必須要考量這樣是不是會對產品造成影響,例如:

(3) 批次處理時

對系統來說,有些較為繁重的計算工作會採用批次處理,當批次處理時,系統負擔會較大,這時候產品經理必須要和工程師商定批次處理的時間,以免影響到正常的服務,例如:

(4) 維護時

有些系統會需要固定的維護時間,可能會造成服務中斷,當產品預計進行一些大型企劃的時候,要記得避開維護時間,例如:

(5) 故障時

系統難免會遇到故障的情況,這時候要確認故障時的處理流程,以及故障期間產品的狀態,例如:

▍小結

魔裹藏在細節裡,因為透過三大情境的提問,可以避免許多技術風險,當然技術風險還包含很多面向,例如:

  • 業務需求容量與系統容量對齊: 目前每秒請求量夠不夠?
  • 量化用戶體驗指標:頁面反應慢?怎麼量化改善?
  • 災難復原計畫:避免服務中斷?真的斷了會斷多久?

這些都是我認為產品經理在規劃產品時需要納入考量的,有機會我會再撰寫文章分享。

總結以上,產品經理需要懂技術嗎?我認為是的,產品經理需要知道的是關於技術風險相關的知識,可以此為切入點進行學習,至於要學到多深,則是要看專案的情況而定,以上為我的分享,希望對大家幫助。

—

最近受邀在 Hahow 開設《軟體需求溝通 ─ 從外商公司學跨部門協作開發》線上課程,談怎麼將將商業需求與技術規格對齊,並轉換成工程師可以實作的規格,目前七折優惠中,如果對課程有興趣的話,可以參考。

課程連結:https://hahow.in/cr/rqmt-intro

程式猿吃香蕉

喜歡將軟體知識以簡單生動的方式講給你聽

程式猿吃香蕉

『來點更營養的軟體知識,吃香蕉吧!』我們是一群軟體開發愛好者,喜歡將軟體知識以簡單生動的方式講給你聽,順口好消化,營養又健康!

Jayden Lin

Written by

Yahoo 擔任 Lead Engineer,負責廣告系統,帶團隊做跨國開發。也是《程式猿吃香蕉》團隊創辦人,喜歡將實用的軟體知識以簡單生動的方式講給大家聽 😄😄😄

程式猿吃香蕉

『來點更營養的軟體知識,吃香蕉吧!』我們是一群軟體開發愛好者,喜歡將軟體知識以簡單生動的方式講給你聽,順口好消化,營養又健康!