【第一次當產品經理就上手】Part 2 - 需求如何排序與規劃以及專案啟動會議(Kick-Off Meeting)
從上一篇 【第一次當產品經理就上手】Part 1-產品開發需求的來源與釐清跟對焦
我們知道了需求的來源以及釐清跟對焦，這次我們要來講一下，當目標很清楚時，我們如何針對將需求排入開發時程以及拆解需要開發的內容並且拍板Kick-Off 開始進行開發。
接下來將針對產品開發10個步驟中的這三個步驟做說明
3.需求在Roadmap的優先排序
通常當我們收到需求就可以馬上進場開發嗎?
當然是不可能，因為同時間已經有其他專案再進行，團隊的Roadmap也有其他專案等著開發，一般來說起碼三個月內的開發排程都是確認的，除非需求很小，就會找專案跟專案中間的RD資源空檔插入開發，不然就是要跟其他專案PK了，而這時流程大概就是產品經理去評估接下來的專案與目前的需求輕重緩急，然後擬定一個順序回報主管，由主管決議是否調整排序或者協調資源，更甚者可能因為跟其他專案一樣重要就要往更上層大老闆們去協調了。
所以我的流程大概會是這樣
- 梳理目前已排序的專案輕重緩急
- 開發中：專案盡量不能斷，避免無法收尾。
- 排序中：看影響層面，如果跟營收有關就盡量不動，如果有取代方案的就可以先協調。
- 初步釐清開發需求的資源與時程
- 通常我們收了一個需求，會跟團隊的RD主管或者關鍵職能RD初步討論一下需要多人資源跟人天，大概知道一個需求的Size多大多小需要哪些職能的RD，這時候就可以往下排序或盤點。
- 盤點手上的資源
- 因團隊的RD職能包含前端、後端、數據資料處理等，不盡相同，也不是每個專案全部RD都要下去，一定是同時間多專案進行但RD人力不衝突，也可能某個職能的RD剛好不用加入專案或者剛收尾等QA驗證修Bug，這時你大概知道哪些需求可以跟團隊中的RD主管討論資源怎麼規劃跟安排，RD主管會告知相關細節與建議規劃。
- 判定需求方是誰
- 老闆需求：
看到老闆就要想到一件事，是誰付你薪水? 是老闆! 而且他是付所有人薪水，拿人錢財替人消災是非常合情合理的，一般老闆是不隨便插手各團隊專案開發，所以當老闆提出需求，一定就是要盡快處理，因為老闆背後可能會有很多目的，至於後續專案被排擠，通常拿出老闆的令牌，其他人大都不會吭聲 (職場潛規則就是這樣)。 - 例如該需求完成可以拿到別的資源去談判或者執行另一個需求或目的或資源，這是很多相依性的，也可能某個股東大會或者某個公開型曝光會議或演講中需要有這功能才能有其話題或者達到某個目的。
- 跨單位需求：
通常這是專案最多的需求，也是最難協調的，可能業務部門需要A功能去滿足客戶需求，行銷部門需要B功能增加營收，營管需要C功能加快作業降低維運或人工設定，每個單位都很急，這時產品經理會一一跟需求方討論協調，如果協調不定，就會知會各需求方，排序將上呈至主管會議中讓主管們決議排序，Roadmap上的排序專案誰先誰退，這時各單位主管都有共識，拍板的結果就不會讓產品經理為難，畢竟我們都是照吩咐辦事，合情合理大家都沒怨言。
- 是否需要跨單位協助
- 如果需要跨單位協助，例如某些開發團隊是負責會員，某團隊是負責結帳、金物流等，這時候若需求專案需要會員或者結帳功能配合，就需要跨單位協調資源調配，因為其他團隊也有既定專案的排序，怎麼可能為了你而中斷或延後開發，所以跨單位資源的協調溝通也是很重要的一環，大家討論哪時候可進場，誰跟誰有相依性去協調排程等。
- 這邊我舉個案例，我有個會員資料需要新增標籤，然後我拿標籤去做報表等，但會員資料新增這標籤需要開發，所以會先與該團隊的PM討論，是否有資源可協助以及預計時程，簡單的需求可能PM會找空檔或維運資源幫我處理掉，大一點的工程他們就會列入排序，並告知我預計哪個時候會進場跟完成，這時候我才可以拿到資料並且進場開發等等相依性的時程。
4.討論需求開發與產品的內容
等到Roadmap的專案排序確認後，接下來就可以在排序時間前與團隊約會議討論需求的細節內容與相關產品的UX介面設計跟動線，這時我們的順序會是
- 1.確認產品方向與目的
- 先將需求的目的與方向跟團隊佈達，確認產品在商業模式跟價值上的可交付內容，以及團隊是否清楚與明白取得開發專案的共識，為何而戰。
- 例如我們有個客製專案串接第三方工具，這時很清楚就是達成客戶可使用第三方工具的功能，而達到目的中需要的功能一一列出，這就是我們要完成的功能串接。
- 團隊成員因是中途才知道需求，不清楚前因後果時，PM要能夠梳理並表達需求的始末與價值，可能會問為何要接這需求?
其實通常會針對幾個方向，例如是公司政策，這個就是公司價值，團隊也能買單，或者是客製專案收了多少錢，能為公司帶來多少營收，這就是團隊開發的價值等等，這些讓團隊知道後，團隊也才能專心開發，避免過程產生不必要的質疑導致專案不順暢。
- 2.針對需求內容盤點與團隊討論可行性
- 團隊成員討論需求專案時會開始評估範圍與拆解階段以及每一個需要開發的環節或功能，過程中團隊能不能接?有誰能接? 可行性? 不可行是否有取代方式等就會一一定案，這時產品的輪廓就會越來越清晰。
- 3.思考產品相容、擴增性與未來發展並評估納入規則
- 通常開發一個需求/功能/產品時，我都會請團隊去思考開發技術與架構能否相容於現在既有產品，避免用不同技術開發同類型產品導致難以維運與優化，另外也會思考該功能的擴增性，避免是一次性功能，希望每個產品都有其延展性，跟著團隊慢慢長大，最後會思考其產品未來的發展藍圖，可以走到哪個地方，以上如果一開始就規劃好，未來產品的前途就會非常的光明。
- 我這邊舉個案例：
我收到一個第三方工具串接的客製需求，裡面需要將訂單資料傳輸過去，我就思考，訂單資料是很核心的資料，除了第三方工具以外，未來有類似要串接的工具是否能相容，其他團隊或產品要取資料時是否也能相容，這時這功能的擴增跟應用性就會變得很廣，所以一開始串接時就會先打底，把底層加購建立起來，有個中繼系統，未來任一取資料或傳輸資料都可透過API方式傳輸，並且轉譯成各串接工具或產品的規格，例如我拿到一筆訂單資料，裡面有10個參數欄位，第三方工具可能只需要5個，且欄位名稱不盡向同，其他產品需要8個欄位，且名稱也不相同，都可以從我們既有10個欄位針對不同串接的endpoint去傳輸指定欄位並轉譯成對應的名稱或規格，後續有要串接的產品或工具，也可以比照，對我們來說架構都完成了，只要多轉譯跟串接傳輸即可，工相對小很多，功能的泛用性也高很多。
- 4.產品範圍與規格定義
- 產品開發是有時限跟資源限制，時間不夠就要限縮產品範圍，產品範圍擴增就要拉長時間跟增加資源，所以一開始範圍就需要很明確清楚，而規格也是需要定義清楚，避免相關單位不清楚內容的規則與定義。
- 5. 產品的UX與UI設計與討論
- UX算是很核心的單位，UX將情境跟使用流程設計的好，對於團隊的開發會加快，對於產品經理布達產品會更清楚明瞭，所以一開始就要將需求方的目的與想法跟PM預想的所有細節跟情境還有預計達到的成效完整的跟UX溝通，UX就會去思考產品的雛型與流程，最終有個UX版的Prototype將產品具象化(例如用figma呈現)，這樣可以讓團隊跟PM想像產品的樣子跟要達成該介面跟流程是否還有遺漏的開發未討論等等。
- 俗話說
好的UX帶你上天堂，不好的UX帶你變UX(自己來)
我很慶幸配合的UX都超棒，除了完整詮釋PM的規畫外還能加入很多人性化跟便利的流程以及使用情境，多了很多我自己都沒想到的情境跟貼心功能。
- 6. 拆解開發階段與時程
- 產品內容也有了、介面也有了，接下來就是針對開發階段拆解與排時程，這時會有兩個情境。
- 交付日期已確認不能退：
團隊若評估無法如期交付，要嘛增加RD資源，要嘛砍功能保留主要核心功能以求交付並達成目的。 - 交付日期可談：
若PM想要讓產品達到一定程度的分數(如完成目的是60分，好用是80分、好用又好維運是90分)，可以跟需求方溝通是否有機會調整，例如我通常開發會先針對好用又好維運去溝通，真不行先求好用避免可以用但很難用導致產品使用率不高，若好用但維運多，可以後續增加資源去做維運優化，但一開始一定是先讓產品好用，這樣使用率才會高才能獲得更多資源。
5.專案啟動會議(Kick-Off Meeting)
當UX版的產品Prototyp有了，功能跟時程也出來了，接下來就是跟需求方約專案啟動會議(Kick-Off Meeting)，做最後的產品範圍與功能對焦，拍板後發會議記錄出來，讓共識有個畫押，避免事後糾纏不清，一中各表，所以會議中有幾個重點。
- 邀約相關人員
- 需求方：提需求的人，確認需求被滿足。
- 使用方：不一定是提需求的人但也會用到這產品，例如這產品是公開販售或新增，不限客戶或單位，所以會用到的單位都需要有窗口與會。
- 相關主管：需求方主管跟開發方主管盡量都要在，會議上有衝突或無法取得共識時，快速確認就是兩邊主管在的意義，當下決議減少反覆對焦會議。
- 推廣單位：非需求方也非使用方，但負責去推廣該產品，例如新客戶開發的業務或者或推廣新產品到市場的單位等。
- 開發單位：會議上會有很多針對功能或流程的討論跟修正，開發的RD主管或主要開發者能到場也能夠知道第一線的反饋以及現場狀況，避免透過PM過一手說明而沒看到重點。
- 說明產品範圍與方向
- 需求方提出需求跟目的，但實際上對於應用跟操作還有情境其實沒有多想，這時候PM很重要，要能夠將專案的產品透過簡報表達
- 是否有滿足需求?
能滿足需求後面都好說。 - 使用的情境會有哪些?
原來需求完成可以如何使用或者應用情境會怎樣等等，讓需求方可以感同身受，或許根本沒想到可以這樣用，那就會對產品多了更多信心與期待。 - 產品的方向與未來(可優化或加值的功能)?
賣一個夢，人類最愛造夢與作夢，而當夢想實現時，就會充滿巨大的滿足與憧憬，如果跟需求方說以後這產品還能怎樣怎樣，那需求方就會對這產品開始充滿愛情，接下來都好談(因為愛情是盲目的....)
- UX版的產品Prototype示範
- 有Prototype最好的就是讓需求方具象化使用，讓大家知道而過程中有疑慮或者瑕疵，隨時可討論或修正，避免開發完成時不符需求或使用不便，我們通常會使用figma來做示範操作。
- 確認是否有符合需求與解決痛點
- 當產品簡報說明完，也示範了Prototype流程，這時就要確認是否符合需求或能解決客戶痛點，這是會議的核心，所以這一Part要能夠非常明確有符合需求。
- 產品開發階段與排程取得共識
- 當以上都沒問題時，就是交付時程的共識了，需求方只想知道哪時候可以上線，而這時會關係上面說的交付期待與上線時程的拉扯(如完成目的是60分，好用是80分、好用又好維運是90分)，這一段通常會有不少討論，需要一些手腕與溝通才能讓大家買單。
- 確認開發的範圍與內容避免無限延伸
- 最後要確認產品上線交付的內容有哪些，因為聽完產品簡報後大家都會有很多對產品的期待與延伸願望。
- 例如：這產品可以發通知，有符合我的需求，但可不可能通知時能夠發點數或折價券等等.....，像這樣就會造成產品無限延伸，所以PM很大一部分要能夠確認需求範圍，避免增加開發時程與範圍。
- 最好的方式就是現場對焦範圍，多出來的無法確定不要先拒絕，都說帶回去評估避免延伸爭議導致無法達成會議目的。
- 例如我會說這次會議目的是確認A需求，至於延伸的B需求、C功能等我們帶回去評估可行性，避免模糊會議焦點，後續相關評估出來後我會個別與提出者討論。
- 會議記錄
- 一定要將會議上的參與者、議題跟確定內容記錄下來發Email，並且cc對應單位主管，這樣未來才不會有爭議，且大家才有共識還可以隨時查詢當下討論了什麼。
以上就是需求拍版與對焦的方式，算是專案開始開發前很重要的一環，這些都確認進開發才不會偏移或者重新進場或異動範圍。
再來關鍵的開發流程，敬請期待。
留言
張貼留言