我們公司在星期六舉辦了運動會, 其中有一個項目就是大隊接力. 這個項目是我們這個部門的強項, 連續兩年都拿第一名.
從這個過程中我發現我們部門成功的原因, 和軟體開發的過程很相像, 因此想分享給大家知道
1. 沒有接力棒, 就沒有勝利
大隊接力贏的條件是什麼? 就是看哪一隊最快把加油棒, 傳送到終點. 記住是加油棒喔, 不是人喔.
這點跟軟體開發很像, 交付的軟體是要對人產生價值(outcome), 而不是你有產出就好(output). 很多經理只是拼命想交付很多功能, 而沒有去思考這些功能帶來的價值是什麼, 對客戶的幫助是什麼?
2. 交接處是問題所在
接著上一點, 我們在開始比賽時, 就深知一點: 只要沒有掉棒, 就贏一半. 畢竟我們不是專業, 並且年紀也有點, 重點不一定在要很快, 而是讓整個傳遞加油棒的過程很順利.
因此, 在比賽進行的過程中, 我們就發現 80 % 的隊伍會掉棒, 只要不掉棒的大多是前面幾名.
同理, 軟體開發也有類似的問題. 往往是不同角色交接時, 發生很多問題. 像是開發人員不懂系統分析給的需求, 或是測試人員不了解開發人員的設計或功能, 導致整個過程來來回回沒有效率.
3. 減少浪費
另外, 除了不掉棒外, 我們也熟知另一件事情: 不要跌倒. 因為跌倒, 就要再花時間爬起來, 然後再花時間加速. 更慘的是, 我們年紀大了, 能不能在短時間爬起來, 還是件未知數了.
同樣地, 在軟體開發也是一樣, 如果我們能在每一關就設法減少 defect, 日後不會因為要修復這些 defect 花很大的代價. 因此, 像是 prototyping, design review, code review, test automation 等等這些招式都要加減使用, 好讓浪費減少.
4. 不一定要每個人都很忙
就如果一開始講的, 接力賽贏的標準, 就是看誰最先把接力棒送到終點. 而不是每個人都衝到終點.
專案經理在帶團隊時, 常常犯的一個錯誤, 就是想讓大家都很忙, 沒事就讓大家每個人工作量都滿載.
可是, 當遇到警急狀況時, 就完全沒有人可以出來救火, 只好讓大家加更多班. 另外, 也因為大家都很忙, 因此沒人研究新的技術或是新的做事方法, 因此團隊只能用舊的方式, 繼續痛苦下去.
沒想到, 一場小小的大隊接力, 可以給我這麼多啟發.
全站熱搜
留言列表
