在導入敏捷, 進行敏捷轉型時, 我們通常一開始會規劃要怎麼做後, 便開始開工了.
可是轉型這件事情, 就像我之前文章所提到的, 它其實像是一件創業的工作. 你提出來的產品功能或是想法, 都是沒有經過確認的, 使用者可能覺得這不是問題, 或者雖然他是問題, 但是我現在不急, 不想付錢來解決. 因此我們必須要步步為營, 利用 MVP 的概念, 來確認方向是否正確.
那有哪些風險, 在轉型一開始時要注意呢? 以下是常見的種類:
1. 處理到不緊急的問題
首先, 你要做的是解大家最痛的問題, 你說這件事情不是大家都知道嘛. 事實上, 有時候大家只是口頭上說很痛, 但是實際上並沒有這麼嚴重, 或者是現有的 workaround 方式, 其實是大家可以接受的. 在解錯痛點的狀況下, 大家並不會這麼賣力.
2. 是否容易合作
很多時候, 老闆喜歡搞大鍋炒, 有時候是不同地方一起同步進行, 要求推行相同的流程. 可是卻忽略了不同地方可能環境不同, 很難把解法調到都適用. 或者是不同地區在溝通時, 因為時差不同, 語言不同, 光浪費在這些非正題的事務上, 就把大家給整死了. 根本沒有精力放在正事上面.
3. 轉型是否容易持續
任何改變的做法, 都盡量要簡單, 低級, 好模仿. 讓入門的門檻很低, 大家才能很快上手, 轉型才能很快看到第一屆段的成效. 例如: TDD 這種事情, 在很多轉型的活動, 就不該擺在第一步. 說不定有 daily build 或是 schedule build 才是要務啊.
4. 轉型會影響的對象
誰會被這轉型影響最深, 誰需要花最多的時間和精力, 知道苦主是誰, 才能能夠對症下藥. 有時候明明是針對維護團隊的成員, 可是你卻打算使用 Scrum, 要他們怎麼用 sprint 的作法才處理 bug 的修復呢?
不知大家還常遇到什麼問題, 一起來交流一下吧!!
全站熱搜
留言列表
