【第一次當產品經理就上手】Part 3 - 不可不知的產品開發細節與上線規劃的策略
繼上一篇 【第一次當產品經理就上手】Part 2 - 需求如何排序與規劃以及專案啟動會議(Kick-Off Meeting)
說明當接到需求後如何去排序跟規劃與對焦，接下來要進入產品開發的階段了，也就是後續的流程拆解。
6.產品進場開發
當專案啟動會議(Kick-Off Meeting)拍板後，接下來就要將會議內決議的重點跟方向，跟團隊佈達並開始進場開發了，首先要邀約開發團隊做進場前的會議說明。
- 與團隊說明跟需求方取得的共識與目標
- 當專案啟動會議(Kick-Off Meeting)確定後，目的就非常明確，需求方到底期望達到哪種目的與預期效果，要能夠與團隊說明，通常我會與開發團隊簡報的內容如下
- 需求的來源與目的：開需求的時後要讓團隊知道前因後果，很多時後PM會避開需求的根本原因以及產品要解決的問題後面實際的目的，而我自己覺得PM要能夠將需求的來源與最終結果"收攏"精簡說明並給予一個產品的詮釋，避免團隊收到不必要的資訊而錯誤解讀，或者沒有收到完整資訊而忽略了產品的目的。
- 我這邊舉個例子：
例如我某個需求雖然是客製專案，是某客戶的需求，但我們卻要花超過客製專案等級的資源，釐清後才知道其實公司背後的目的是希望能藉這客製專案與某第三方達到地區性的策略合作，所以需求來的又急又火，然後排擠了目前的專案，當我收到訊息時，我必須清楚地告知開發團隊為何插件然後又急又火，這時候把需求拉高到公司層面會是比較適合的，因為跟公司策略有關，就是每個開發的團隊必須配合的，若我只是告知某客戶的客製專案，那開發團隊就會提出很多質疑，例如排擠了對公司所有客戶都有幫助的產品排程，或者是花了很多資源卻只為了一間客戶使用卻得不到該有的價值，這時開發初期就會遇到很多阻礙，如無法說服開發團隊全力支援等；但如果我明白告知公司的策略就會拉高了開發團隊的共識與意願，通常我會補上這開發後除了主要目的(策略合作)外，還會有其延伸價值，如該客製的專案其實可以幫助客戶帶來GMV，也可以將該客製專案裡面的泛用性功能開發時與目前既有類似產品或服務去進行迭代優化，幫助團隊提高效能與降低維運，而這兩點其實對團隊來說是最有感的，通常團隊也願意讓這又急又火的專案插件並且全力協助。
- UX版的產品Prototype示範
- 還記得與需求方的專案啟動會議時，DEMO 產品的 Prototype，這時候產品Prototype大致底定，除非會議上有大調整，不然大部分產品UI已經確認了，這時候才能跟團隊說明產品樣貌與實際的畫面與流程，而後續開發流程才會取得共識並且有清楚的開發Roadmap，若沒有確定UI介面與流程時千萬不要進場，避免開發團隊重工，造成資源浪費與錯誤決策。
- 我這邊舉個案例：
我有個產品需求是選擇篩選條件，但篩選的方式與介面是我跟UX討論過適合的，但並沒有跟需求方對焦就進開發，等開發到一半時因某原因需要在跟需求方過一次，這時候將規劃好的流程跟介面拿來對焦，沒想到不符需求方預期，來回討論了好幾次才定版的介面已經與開發團隊正在開發的相去甚遠，這時候就遇到一個問題，要打掉重練還是折衷優化?
因時間不夠我選擇折衷優化並持續與需求方溝通取得共識才進場，但我溝通已經浪費了開發時間，而錯誤的開頭要修正也讓團隊繞了一段遠路，這一段後續檢討時，團隊與我都有共識，一定要需求方先確認過UI介面跟流程後才進場開發，避免無效的開發。
- 拆解開發細部功能與工時跟排程規劃
- 等團隊了解產品的UI介面跟操作流程後，這時候會針對免個介面、元件、流程與串接的服務去做評估開發工時以及順序，這時候會切幾個Sprint(迭代交付，一般來說是兩周)去開發，而每個Sprint會完成被拆解的部分到全部完成需要多少時間，而這邊要注意幾個事情
- 同時間是否有其他專案並行或排擠?
如果有就要協調時間並確認是否影響交付日期。 - 同時間開發的RD是否有專案衝突或者資源足夠?
以我們團隊來說分前端、後端、資料工程師，三個職能的RD不能能full time只開發一個案子，一定同時有其他的案子要進行，所以這時候除了專案的排序外，RD開發的排序也需要確認，避免影響了開發的進程。
- 產品開發Scrum開跑：Sprint的流程運作(Refine、Planning、Daily、Demo、Retro)
- 敏捷與瀑布的混和式開發：
我們公司是跑敏捷式開發，但我們團隊非完全比照，我們會抓裡面適合公司或團隊運作的要素納入，並且也抓取了傳統瀑布式開發(waterfall)適合團隊或公司的部分，整合一個MIX版。 - 我這邊舉一個例子：
因為我們是B2B，且有時候會有客製或者跨團隊協做產品，這時後交付日期就需要確認，且交付的內容也很明確，這一段就很像傳統的瀑布式開發，但為了交付我們會小步快跑分段交付及時修正，這一段我們開發就會像敏捷式開發，所以其實團隊並不會只依賴一種流程，我們會擷取各種開發流程的精華並且融入我們的開發流程中，目的只有一個，讓開發流程更順更適合團隊，效果更好。 - Sprint的會議流程與運作：
我這邊只講Sprint流程中每個會議環節我們是怎麼運作，並沒有完全比照Scrum的流程與精神，所以可能跟信仰者的認知有不同，這一段就請不要太在意，畢竟只要能夠完成專案有效率的交付，任何有效的方式我都會採用。 - Refine：針對下個Sprint確定要進場的Product Backlog，開Stroy說明目的、內容、需求與交付日期，這時候團隊會收到需求後並且帶回去評估做法於下次Planning會議上提出做法與預計工時。
- 案例：
通常RD這時候也同步開發該Sprint的工作，並不一定有時間可以一起討論作法或評估，我們PM會Refine後針對會議上要討論的議題邀約會議與相關RD開會討論擬定作法，避免Planning會議上才開始討論拖延了會議時間。 - Planning：會議上會針對Refine的Story需求的做法跟估時提出說明，並且與團隊確認內容與細節，沒問題就直接進場開發，這時候因為中間已經有約RD會議說明與討論，所以Planning只是拍版，如果還有議題都會留下來討論直到定案為止。
- Daily Standup：Planning確認的Story與Task就會在每天的Daily Standup跟團隊同步開發進度與遇到的問題釐清。
- 這邊要注意的是若產品線過多會議上容易過多討論造成會議過長，例如我們因為每天可以一起討論的時間就是Daily Standup，所以常常有問題現場討論導致會議拉長，而並不是每個RD都有參與專案，所以後來為了讓會議加速並且達到會議的目的，我們做了幾個優化
- 從RD出發報告個人進度改成由專案出發，每個參與的RD報告該專案的進度，這一段的好處是可以讓負責專案的PM快速對焦目前進度與問題，避免各自報各自的進度不好統整，專案進度的報告就會快很多。
- 有問題需要討論的若超過2分鐘則列入會後議題，由相關的RD留下來繼續討論，這好處是可以避免會議失焦，也可以避免浪費不相關的RD時間，而要討論的議題也可以有效聚焦的討論。
- 優化後縮短了一半的時間，本來我們站立每次大概都會站30~60分鐘，縮短後大概是15分鐘上下，最長最多30分鐘內可解決。
- DEMO(Review)：這會議主要是將這次Sprint的成果展示給團隊跟相關的單位看，也是驗收Story的時候，而這時後大家都可以針對DEMO後給予意見，會議上PM會收整做後續優化或者發現沒注意到的地方，讓產品或需求能夠更完整的交付。
- Retro：這會議簡單說是檢討會，一般來說有心情起伏圖或者是投票表決要討論的，會由Scrum Master主持，在我們團隊會是Tech Leader主持，有時候會由PM主持，我主持時通常都會用自己的方式，主要是讓列出目前遇到的問題與題目，然後由每個人於白板寫出意見，然後每個人發表意見，我可以解答或引導討論就會直接進行，希望能讓大家遇到的問題在這個會議上能有初步的釐清與共識，如無法解答就會帶回去給主管回覆或評估，若會議上大家可以決定要優化團隊哪個地方，會議後就會記錄下來並且實際去執行，後續都會對團隊有很大的幫助。
- 這邊我也要提一個實際的狀況，Retro很容易陷入既有問題的抱怨與不滿，所以這時候主持人要避免老生常談但無法解決的問題出現或者切斷無法解決的不滿情緒討論，避免會議失焦而讓團隊氣氛很差或者死氣沉沉，有時候無法解決的問題只是時間問題，時間過了，問題就會解決，解決方式通常會是別人解決、或者因政策解決或者有更重要的相比要解決，原本拘泥的問題就顯得不是問題了，時間可以解決任何問題。
7.舉辦產品體驗會收集回饋
當需求或產品完成時，我會評估是否要舉辦體驗會，如果是新產品、大改版我就會舉辦產品體驗會，主要是新的流程或操作容易讓人不知如何使用，這時候舉辦產品體驗會有助於釐清產品與市場上的差距，我們通常會做幾件事。- 對焦產品體驗內容與時程
- 當產品在上線前，我會準備產品體驗的內容與流程，舉辦一場產品體驗會，目的是收集上線前的反饋，看哪些是團隊沒注意或者使用者覺得有問題的地方，趁上線前好好修正。
- 邀約需求方體驗產品
- 需求方：提出該需求的人，能否順利交付的關鍵人物。
- 業務：我們家的產品除了交付需求外，能否讓大量客戶使用都需要靠業務推廣，而業務基本上也是第一線面對客戶的人，所以產品能否受客戶喜愛，業務有很大的關係，如果業務覺得好用喜歡，那後續推廣自然會很順利。
- 市場推廣單位：除了第一線面對客戶的業務單位外，面對市場上相關產品推進跟推廣，所以邀約他們有助於釐清產品跟市場的距離。
- 相關單位主管：若該產品牽涉面過大或者有高層注目，這時候就要邀約相關高層主管參與，一個是讓主管放心，一個是理解產品跟主管預期效果中間的落差有多少，未來評估如何補上。
- 營管：產品推出後想當然爾都會有相關客訴或者使用的詢問，邀約對應的客服或營管單位有助於第一線釐清產品或者使用方式，快速解決客戶問題。
- 舉辦體驗會議：介紹與說明、分組操作體驗、使用回饋與收集
- 為了讓產品體驗會順利進行，我會先針對產品簡介，並且提供使用情境，然後安排相關情境給參加體驗的人實際操作快速理解，過程中會分組，每組由開發的RD負責解說與引導，並且收集體驗的回饋。
- 我這邊提供我通常會使用的流程
- 產品情境說明：5 min
- 產品操作說明：10 min
- 產品體驗：40 min
- 分組 (請各組務必玩過一次，有問題請問相關開發者或PO)
- A組：RD、QA；UX…..
- B、C、D組....
- 流程
- 操作流程1 ：如建立
- 操作流程2 ： 如新增
- 操作流程3 ： 如介面操作
- 體驗回饋收集：5 min
- 問券調查(現場提供線上連結讓人填表快速收集)
- 現場收集問題與回應
- 針對體驗會回饋團隊討論共識項目優化
- 讓RD於分組體驗時負責解說跟引導的目的有幾個
- 目的1：讓RD面對需求，了解產品使命
- RD通常不會在第一線面對需求，而是由PM轉達，通常會造成不信任感，但讓RD直接面對需求時，可達到換位思考，幫助RD開發產品時思考需求方的感受。
- 目的2：提升團隊的意願與共識，讓產品更完整
- 產品上線前總是不夠完整，需要優化的地方過多，透過回饋與收集的檢討，團隊有了現場感受後，更能於體驗會後主動提出解決問題的意願，或者是同意後續優化項目，避免落入PM孤立無援的窘境。
- 目的3：提升團隊士氣，與有榮焉
- RD過往容易有事不甘己的思維，透過產品評分，讓RD以產品為榮，提升團隊士氣，將產品視如己出，未來調整或優化都會有認同感，對團隊也會更有歸屬感。
- 這邊我提供幾個過去產品體驗回饋的調查表如下圖，透過直接的評價回饋，通常會讓讓RD覺得自己開發了一個很棒的產品，也提高主動想要優化產品的意願。
8.產品上線流程與注意事項
- 確認公司產品上線時程與流程是否符合
- 每個公司都有一個固定上線的時程與流程，避免各團隊自己上Code影響其他團隊或者隨便Rolback導致其他團隊的Code被退版，所以上線時要確認是否符合公司規範。
- 撰寫教學文件與使用情境說明
- 當產品即將上線時，第一次摸的使用者一定不知道怎麼用以及可以做甚麼? 所以教學文件非常重要，我通常會於教學文件寫下幾個重點
- 產品主要解決痛點：每一個產品都有主要解決的問題，開頭必須破題而入且切入重點，引人興趣才會讓人想看下去，不然一般人沒興趣就直接按上一頁或關閉了。
- 產品邏輯簡述：任何產品都有其運作邏輯，透過簡單的說明清楚告知，會讓閱讀者更快進入狀況。
- 使用流程：因為第一次看到介面大部分不知道該從哪下手，這時候有個範例教學，將使用流程一步一步帶著走，會降低使用門檻。
- 使用情境：任何產品都有一個要解決的痛點，就像一個故事的主軸一樣，要先有情境營造，然後遇到低潮，接著透過這產品走上高潮(解決痛點)，然後有個完美End，這樣的故事架構才會讓人感同身受。
- 成效指標範例：其實商業模式的運作都有其指標需要觀測，而每個產品都是輔助指標成長，故一定要提供建議觀測的成效指標，這樣使用產品的人才能快速評估產品成效，也可以降低知識落差，避免拿A成效指標看B產品，沒有對到焦而錯估了產品成效。
- 產品上線關卡：QA、Stage、PP、Prod
- 一般產品要上線前都要先經過QA環境通過驗證，好的QA一開始就會參與專案開發並且收整歸納出HappyPath，讓RD開發差不多時可以走一下HappyPath看有沒有問題，QA也可針對HappyPath設計出自動化驗證流程，這樣會加快QA環境驗證，等到驗證完畢就要上Stage or PP環境，這環境通常是模擬正式環境的資料與後台，可以驗證若上線後是否可正常使用，等到通過後就會上Pord正式環境，產品才算真正的Release上線。
- 產品上線通知需求方與相關單位
- 一般有點規模的開發公司，每個上線的日期同時都有很多功能要上線，相關單位並不會清楚產品上線的確切日期，所以這時候通知需求方跟營管單位或相關單位是非常重要的，避免資訊沒同步。
- 上線後觀測狀況與影響
- 產品上線就沒事了嗎? 其實不然，上線後還要觀測幾個項目避免增加維運量。
- 產品是否正常運作
- 是否影響其他功能
- 系統是否可乘載其使用量
- 監測系統是否正常運作
以上，就是產品開發細節與上線規劃的策略，這一段相對重要，除了是PM跟團隊共同協力的階段，也是最扎實的開發過程，一個產品能否成功就看這一階段了。
同場加映 產品未來的擴充跟泛用性與架構優化
除了產品開發的正規流程以外，我還會去思考產品的擴充跟泛用性，為了讓產品的路走得更遠更久，我通常會去思考幾個點
- 產品未來的規模：
- 這產品可以走到哪個方向，我們目前規劃的產品內容，還有哪些後續可以增強，可以延伸的部分，都需要思考，並且在初期開發時期就請RD先行評估，避免未來架構不敷需求而重新打造。
- 案例說明：
- 我們開發一個自動化溝通的工具，初期只能上線幾個篩選條件跟溝通的媒介(推播)，但我知道未來溝通的媒介只會越來越多(如LINE 貼文、簡訊、Email等)，所以當初就請RD要連同未來會開發的媒介串接架構一起打底規劃進去，避免到時候無法串接。
- 產品未來是否可幫公司增加新營收：
- 通常開發一個產品會遇到是否要收費的問題，這通常會跟業務單位有很大的拉扯，也跟公司的營運模式有很大的關係，所以任何產品開發初期就要思考是否有收費的議題，會有收費的規劃就需要將後續對應的服務跟架構思考進來，沒有收費就必須提供產品的貢獻價值成效指標出來，讓產品能夠量化價值。
- 案例說明：
- 我們有個行銷通知需要開發Email，但訪間Email其實有成本問題，所以我們也規劃了相關收費跟對帳的機制，初期可能先免費試用，但未來要能夠收費且能彈性的規畫收費方式，所以一開始的架構就討論清楚要開發記帳跟不同客戶的計費方式，雖然功能上線初期是免費試用，但後續要收費我們也有完整的架構，且這架構也能通用其他產品去發Email，所以架構打底延伸使用跟泛用其他產品的特性都需要思考進來。
- 既有產品泛用性
- 通常一個公司會有很多產品，互相間很容易因為各自開發不相通，所以產品規畫初期要思考是否其他產品也能夠用或者連動，讓產品的泛用性更廣也幫助其他產品有更多的使用方式以及效益，這樣產品的價值才會拉高。
- 既有架構優化
- 一個產品的開發一定程度建立在既有的基礎功能上，而基礎功能因為開發年代久遠，總有些需要淘汰或者不敷使用造成一般維運問題，而新功能的開發若有牽扯到基礎功能，我們都會評估是否就一併將基礎功能迭代優化，讓基礎功能能夠適用於未來的技術或者發展，除了讓產品上線外也同時讓基礎建設執行，降低一般維運。
最後，產品上線了，然後呢?
接下來我會帶你來看以下的開發流程做最後的收尾。
留言
張貼留言