在平常的開發過程中,大家在乎的通常都是「如何在期限前解決問題」,碰到突發狀況時,很可能因為時間與人力限制,只能用最快、最省力的方式解決,也就是說,解決的通常是單點的問題;相較之下,retrospective meeting 的目的是讓大家不要一味地趕專案死線,而是要從過程中學習、檢討,讓下一次的專案跑得順利,所以討論問題的角度可能可以提升到「線」或是「面」。
看完一堆敏捷文章,講了一口好敏捷,但真的實際去實作或推動總是力不從心嗎?Daily Stand meeting, Planning meeting, Demo meeting, Retrospective meeting… 這些會議是什麼、會議要持續多久、要注意什麼、成員在會議中扮演什麼角色?如果你對這些不太清楚,讀完這篇你會對敏捷實作更有一些想法。
經典的 Scrum 是每兩週一個循環,包含 Planning、Review、Retrospective、Stand-Up 等會議,會議時間平均每週就要 2–4 小時,還不含負責人準備會議需要付出的額外時間。我的版本則是一週 0.5–1 小時,是 2–8 倍的效率差異。我已經在無數個專案中驗證了這套方法,很多專案每週例會還遠低於一小時,同時維持著高度的向心力。想把思路分享給你,期待你也能從中得到啟發,一起用最小的成本創造最大的價值。
文章主軸會從 PM 視角出發,先介紹 PM 通常會如何評估一項需求的緊急度、可行性與必要性,接著則會分享需求端該如何「正中下懷」,根據 PM 評估標準去描述自己的需求。
關於是否是一位好的產品經理,大家各自表述,因應不同公司、產品或職階,對於 PM 的能力素養及要求也不同;即便如此,有些能力,是可以從入門時期就慢慢累積的喔!今天 sofasoda 這篇文將會綜合前人的心法,針對通用能力面,給想成為 PM 的求職者一些忠告。
訂閱沙發練習室,每兩週會有更新的內容
Subscribe to receive the latest blog posts and updates.