都會女子的異想世界

由此表中，我們可以去控制每天應要完成的項目，因為實在無法將整個甘特圖都放上去，也無法將表格列印給大家，因為，我知道根本不會有人去看它，所以只能依每個星期為一個衝刺週期（sprint），讓大家可以清楚知道今天要交付的是什麼，這應只是個「提醒」的動作！

對於十一個人的團隊來說，用這種方式運作了兩個多月了，其實控制的很順利，只是，隨著每一支程式越來越難、程式的工程期越長後，有個問題浮現了出來：此白板上，只提醒了工程師今天要交付的項目，但往往工程師們會忘了那一天要開始，導致到前一天才發現做不完！

當然，這是工程師本身的問題，他應要自己記錄下專案經理所交付的工作，而這些文件，SVN 上都有，只是，如何順利幫助工程師可以更安心的工作，也是專案經理的工作。

剛好，這期的 HBR 中有一篇文章：產品開發六大迷思，其中有一幅圖表示了產品開發的工作清單管理，其實，這是專案管理很有名的一項管理理論工具－Scrum 中常時用的 「控制版」。




圖示來源：http://scrum.tw/index.php/tw/aboutscrum/aboutscrum

在 T 專案失敗原因檢討 一篇中提到：「專案之所以稱之為專案，就是因為它每一個都不同。」

所以，千萬不要只是依樣畫葫蘆，一定要配合自己的專案特性做變革。於是大家就來個「Game stoming」。這是我現在正在閱讀的一本書，也來利用這書上的規範，和團隊們玩一次腦力激盪。

Memo ，真是個好物，團隊的腦力激盪，都不約而同的利用 memo 紙來做創意分享，所以，大家也一起拿起 memo 紙貼啊畫的，一起討論出最佳化的工作控制版！

它終於在大家修修改改中完成了！

X 軸是工作流程，Y 軸是團員的名字，中間呢，則是一張一張的 Memo，上面為任務內容：


任務 Memo

１．程式名稱
２．SD 的名字，SD 任務起迄日期
３．PG 的名字，Coding 任務起迄日期
４．SD 的名字，測試任務起迄日期

任務第一欄：等待中的程式（下一支程式）
任務第二欄：目前正在 SD 的任務，配合 Memo 上的第一項任務
任務第三欄：目前正在 Coding 中的任務，配合 Memo 上的第二項任務
任務第四欄：目前正在 測試中的任務，配合 Memo 上的第三項任務

Memo 會依著任務的不同，及人員的不同，跟著移動，一直到第五欄：今日交付。


所以，現在工程師可以走到白板前，看到自己的：
１．任務程式的編號
２．任務的起迄日期
３．任務的相關人員
４．它現在進行到那個步驟
５．什麼時候應要上線
５．然後，有下個任務已在排隊，它應在什麼時候開始
　　我應要有點緊張的壓力

但這壓力只有手上這支，及排隊的一支，而不是手上己分了十幾支，然後，覺得好多工作的壓力，尤其對那種較不積極的工程師來說，丟一堆工作給他，是一件很不智的舉動。因為到交付的最後一天，專案經理才會發現，完成度可能不到一半。


而專案經理也可以從這控制表中，得知那些任務等著排隊上線，它都壓在誰身上，也可以讓大家都明白每個人的工作狀況、誰的 loading 最重、誰已空了，其它 SD 可以將庫存送出.....


當然，它有電腦軟體，為什麼不用呢？因為沒有人會去看！

而放在公開場合，可以讓大家一起參與討論，凝聚更多的力量！

小小的經驗，分享給大家！

Retake 任務 Memo，就是被 SA 退件啦！

CR 任務 Memo