iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 17
0
Agile

為團隊與組織導入敏捷的經驗分享系列 第 17

組織一起訂定產品的生命週期流程

前幾天講到〈產品從無到有〉〈從驗證完成到開始的準備〉,今天晚點會在《軟體開發隨筆談》系列文〈為軟體訂定狀態階段〉,都是在講產品的生命週期的一部份。除此之外,雖然還有一部分還沒講到,昨天卻先暫停寫相關題材,改講〈授人以魚,不如授人以漁〉,就是先切回來本專欄的名稱「為團隊與組織導入敏捷的經驗分享」。

從鐵人賽第一天到今天,所有題目幾乎都是我在過去一年陸續導入團隊的一些活動和政策,導入的方式差不多都是透過〈導入敏捷的過程也要敏捷〉裡面所提到的方式,每個開發週期進行一小個改變,然後會利用週期中間的某天,將自己所學的內容,透過主題分享的方式去分享給團隊,成為他們日後制定政策的想法來源。若在分享後,直接照自己所講的去落實,最後就會變成授人以魚,這樣可能會導致導入的政策不符合團隊文化或現況,又或是團隊學到的是死方法、形式,而領悟不到其中敏捷精神。所以要由團隊一起訂定才是好的做法。

而這些逐漸被落實的政策,也透過一天約千字的篇幅去講述這些被導入的內容,而產品生命週期當然也是其一。但是這個部分會比較特別,前面的部分幾乎都只發生在團隊內部,但關於產品生命週期會是整個組織的事情,所以特別強調應該要由組織一起訂定,畢竟研發團隊負責的開發和維護只是產品生命週期的一個部分而已,一個產品的經營,卻是由整個組織一起努力的。任何一個人都很難對產品有全面暸解,所以只有一個人去定義產品的生命週期,是個致命的錯誤。

而我們又為什麼要去定義產品的生命週期呢?組織內部會彼此互相詢問的問題,有很多是和產品的狀態有關,比如說「某某 Bug 到底修了沒?修了?!但我操作還是有問題呀?蛤,還沒部署,那是什麼意思?」、「現在到底有哪些新功能是可以用的?不是說開發很久了?」、「某某產品現在還有在賣嗎?」等等。對於產品目前的狀況,宛如一個迷霧籠罩在組織內部,需要花很多溝通成本去釐清,甚至花了溝通成本得到的答案還是過時的。

我們需要有一個方法能清楚明暸的將產品的狀態對整個組織輻射,而減少互相問來問去的溝通成本,這時候看板作為一個資訊視覺化工具顯然是一個不錯的選擇。找一個下午,組織的所有人員,或是各部門的重要代表(端看組織規模)聚在一起,一起訂定產品的生命週期流程的看板,去釐清每個部門對於與自己叫相關的產品階段的定義,暸解現在產品線的現況,最後將這個看板建立在組織所有人都看得到的地方,比如說某個走廊的牆上,讓上面的資訊得以對所有人輻射。

就像前幾天所描述的,產品的生命週期可能包括,產品從無到有、從第一次上線到後續維護、從最後一次更新到退役的一個過程,這些舉例可能還無法包含整個生命週期,中間還有許多迷霧又去補完。可以將產品的狀態分為幾個大區塊,像是驗證、研發與維護、停止維護,而大區塊又分為好幾個狀態,像是驗證裡面可能有待驗證的想法、訪談中、開發 MVP 中、驗證完等等;研發與維護可能就有待研發、研發中、待檢視、已合併、已部署到 staging、已部署到 production 等;停止維護可能還包括還在賣的、沒在賣了但還有提供客服支援、不提供客服支援、產品停止服務等。

根據每個組織對於產品經營的方式不同、這些階段都不一樣,沒有一個不用更改的通用樣板。所以才需要各部門坐在一起,共同訂定,最後將產品的狀態視覺化。視覺化的方式可以在研究過看板後,針對組織對於產品組合的方向去設計。假設永遠只有經營單個產品,那就每個階段下面都是功能或 bug 的便利貼,如果是多個產品,看是要多個看板還是一個看板但是多個河道,一個河道代表一項產品,到底怎樣呈現比較好,都可以透過討論去激發各種想法。

最後,一個這樣的將產品生命流程視覺化的看板,正如以往所提及的,不會是永恆不變的。除了每天去更新上面的資訊外,定期審視各階段的訂定也是必要的,唯有持續改善,才能適應不斷的變化。


上一篇
授人以魚,不如授人以漁
下一篇
限制與協議與尊重
系列文
為團隊與組織導入敏捷的經驗分享32

尚未有邦友留言

立即登入留言