這個週末去上了識博管理所開的: 流程設計與跨部門溝通. 之前聽人家說這門課十分有趣, 並且 JB 也鼓勵我來看看. 因此特定找了一個時間來上課.
Joe 和 Bryan 說他們不會先講大道理, 會先藉由大家動手做, 然後再啟發大家去思考學習. 我很喜歡這樣的上課方式, 因為講再多, 都沒有動手來的印象深刻.
遊戲的細節當然不能多講, 破梗了就讓後面上課的人覺得沒趣, 因此只貼個照片讓大家過癮.
下面就開始講講幾個有感的地方
流程是什麼
老師一開始介紹何謂流程時, 讓我十分震驚, 所謂的流程, 讓最強的一群人, 做出最強的產出.
一般我們在訂流程時, 很容易把重心放在除弊, 要確保大家照表抄課. 這樣的思維, 導致公家機關的人, 每個人都怕犯錯, 都認為他有照著流程做, 沒有犯法是最重要. 至於能不能帶給大家最好的價值, 是否能夠做得更好, 這不在他思考範圍. 因為, 這跟流程不符.
學習 Scrum 也是一樣, 我相信一定不會有一種軟體開發方法, 可以適用到所有環境和專案. 你應該是掌握其精神, 讓他幫助你產生價值, 而不是時時刻刻在思考這是不是符合 Scrum.
流程改善
當火車遊戲第一回合結束後, 大家坐下來檢討. 這個跟 Scrum 中的 retrospective 會議很像. 大家週期性來討論, 目前的做事方法有哪些地方需要改進.
在這個過程中, 老師有提到幾個重點
(1) 資訊視覺化
有些改進方法是貼上標籤, 讓大家可以看到, 就知道對方要做什麼. 同樣地, 在軟體開發中也是有這樣的手法, Scrum 會利用 task board, 而非冷冰冰無人理的 MS project 檔案, 來呈現大家要做什麼, 目前在做什麼, 和已經完成什麼. 大家看到後, 才會容易知道要如何改進, 才會知道問題出現在哪裡.
(2) 利用實驗驗證想法
流程設計不是天馬行空, 而是要仰賴反覆實驗與修正. 很多時候沒人知道什麼是正確的答案, 或者是只知道這可能是目前想到的最好作法. 因此, 下一步就是要去實驗, 要去驗證這些想法是否正確. 並且針對某個小範圍處理, 而非是一開始就大規模試用.
這個想法也跟 Scrum 雷同. Scrum 利用迭代的方式, 每次只處理部分功能. 然後看看這段時間內, 做事的流程是否正確, 並且最後檢視交付出來的功能是否是客戶要的. 如果效果不好, 我們就會討論要如何調整, 然後在下個迭代中, 進行新的嘗試.
(3) 持續改進
持續改進這件事情, 並不是久久才進行一次. 應該是要隨時隨地都要注意. 這不是只有經理的事, 團隊成員也要有意識. 並且不是只有改善流程, 可以促進團隊效率. 改變組織結構也會幫得上忙.
Agile 也有相同的想法, 敏捷認為有回饋可以幫助改進, 因此很多 practice 都是在給回饋, 幫大家做更好. 像是 pair programming, continuous integration, daily scrum, sprint retrospective 等等都是.
瓶頸
流程視覺化以後, 大家就容易找出問題出現在哪. 在 Kanban 中也是有找瓶頸的方法, 那時候我比較頃向使用 限制理論 的做法. 不過這個東西還蠻複雜的, 會的人不多, 因此不容易使用. 但是在課堂上, Joe 有介紹一些瓶頸常出現的地方, 每個項目都很實在好用. 或許這可以當作一個好的 checking list, 用它當做好的開始. 不要再強迫大家去懂限制理論了 XD
所謂英雄所見略同, 當武功層次到了頂尖, 大多是殊途同歸. Joe 和 Bryan 所提到的很多想法, 都跟敏捷和 Kanban 的做法相近. 因此, 如果自己能夠多些異業學習, 多和不同行業的人交流, 我想會更容易印證自己過往所學的東西.
嗯 ….. 這次課堂中, 居然只有我可以做出飛機, 大家離童年都太遠了嗎? 哈哈
全站熱搜
留言列表
