你一定要用任務追蹤系統管理工項的4個理由(下)
細節看得清楚
用戶體驗好不好，固然跟實作者有直接關係，但更深的關係是來自於規格背後的原因。規格如果是「What」，那背後的需求就是「Why」。
要求組員寫出每個工項要做什麼事情，一直都是蠻困難的事。許多組員會"忍不住"一頭栽進「執行比空想重要」的思維中，有時他們會接到用戶提出一些他們自己也覺得很讚很重要的需求，他們就會"順便"，或是說服自己：這是一個必須完成的中間事項🤨，然後就花下大把的時間去做。或是他們很簡單，很"概要"式的講一下要做的內容(像是「優化效能」。天啊，你知道這件事可以搞多大嗎？😜)。這些都是他們根本沒想清楚要做什麼及為什麼要去做 的時候，也是身為技術經理人一定要catch到的東西。技術經理人的職責中，幫助成員釐清任務的「為什麼」是非常重要的。你通常有著較豐富的實務經驗，這「經驗」不只是你的 所剩無幾的 技術，而是知道問題後面的問題(QBQ)。如果成員要執行的任務，寫出來連你都看不懂，那只有兩個原因：一是他寫作表達能力真的不好，你得問過一輪才知道他"實際"上要做什麼；二是他寫的東西你沒跟上，經過討論後才知道你"應該"要知道什麼。但不管是哪一種都很重要，他寫不出來表示他沒想清楚怎麼做，你沒跟上就代表你沒搞清楚為何要去做。
有一張圖很有趣，大家一看就能心領神會：
當問題在發想，計劃，設計或是開發階段被發現的時候，修復它的成本都很低。若是等這個問題在測試/品檢期才被發現的話，修正它的成本就不低了(因為通常要重現它的成本就不低了)，若是等到產品上架了，要修正它的成本就更高了。
Redmine在實務中扮演的角色，很多時候就是一個「備忘錄」。有時一些很重要的"小"任務，是在口頭討論中決議的。有時一些的"怪怪的地方"，都是在不經意的狀況下發現的。大家都會說要重視品質，可許多品質就是在這些 把小地方做好，把違和感磨平 的地方展現出來的。當你和團隊能達成共識，習慣在第一時間就把該做的事情開出工項時，大家對於「What's next？」是非常清晰可見的，是集中心力有效協作的，許多細節就會很系統化的完成，而不會在測試或產品階段才"想起來"要處理(而且那時候你一定沒有資源可以處理…)。
經驗留得下來
我們現在雖然在說「任務追蹤系統」，但其實使用這種系統最重要，最重要，最重要，重要到可以說三次的理由，是要把「經驗」留下來，而且不是留在某個人不可靠的腦袋裡(沒有貶低任何人的意思，但人的記憶力就是這麼不可靠…😅)。
許多開發者都聽過「案子結束的時候，應該花時間寫結案報告，結果案子根本沒有"結束"的時候…」這類鬼故事😨。這種故事還有許多變體，像是前一個案子還沒結束，下一個案子已經同步在進行了；或是案子結束的時候，什麼"問題"都沒有，沒什麼值得寫的；還有就是相關的開發經驗其實都忘得差不多了，只剩下一些概念可以寫；要不然就是被安排寫文件的時間根本也不多，只夠一點概念的內容可以寫。基本上，「以後有空會寫」的成真率就跟「軟體產品會準時交付」一樣的機率一樣低。
另外一種天災(其實是人禍)，也是不可抗力的因素就是成員開刀，車禍，婚假，喪假，調離部門，支援其他單位，蕯諾斯彈指…這類多的是可以讓核心(唯一)開發者消失的狀況會發生，但"精實"的團隊往往是一人身兼多職的，也就是不會有後備人力可以馬上替補上去。就算有，這個人力替補上去後，也得花上大把的時間，去熟悉原開發者的整個狀況及進度。小一點的，短期看得到的成本是時間上的損失，大一點的，長期大家看不到(不想看)的，則是重新創造輪子，重新熟悉，重新驗證…那些"重新"賠進去的設計及實作，才是在品質上莫大的損失。
這應該要是Redmine在使用上，被每天要求的事。
在輸出實作記錄的要求上，可能會遭遇前所未有的抵抗。成員可能會向你反饋，他只是定出程式中的類別，重構了實作的架構，或是優化了執行時的效率，這麼無關緊要的細節，寫出來到底對誰有幫助？當然有，幫助可大了😏。成員的視角看到的確實是一些片段，但具有不少實務經驗的你，光是這些片段就足夠讓你拿來問出有效或重要的問題：為什麼這個類別是叫這個名字，它實際上會打算用來做什麼？為什麼優化的方向是從這裡切入，你有確認瓶頸在這裡嗎？你三天前只寫了「等待業務回應」，經過了三天，業務究竟回應了沒有？他沒回應，你不應該去詢問嗎？…你問出來的問題，除了是你的經驗，也會在這個過程 注入他的體內 成為他的經驗。
另一個可以辨個三天三夜的事情是：我不能只挑「重要」的事情寫嗎？你看，這不是兩造雙方都滿意嗎？但實務經驗是：我們其實不會有足夠的時間去思考，什麼是「重要」的事情。就跟偵探辦案一樣，多數我們不會注意的細節，那些不是"重點"的事實，往往就是一些偵破奇案的關鍵。如果留下任何實作中的細節，都是痛苦的成本(描述能力和時間)，可想而知實作者會儘可能的，"最佳化"寫這些東西的時間及型式。而將來(不用很遠，三個月就很久了)因為任何原因，要再回頭瞭解關於這個工項的一切時，他們就會後悔當時沒留下更多的文件及線索(或是沒把相關的記錄刪得乾淨點…😜)。
該寫什麼東西，該花多久寫，這沒有標準答案。我們自己到目前為止的經驗，都是要求實作者以「讓未來的自己會感謝現在的我，所寫下的一切」這個原則去寫。這個過程我會搭配說明的是，他們現在寫下來的東西，都是將來的「呈堂證供」，也就是他們要準備簡報或文件時的資料來源，被要求簡報或輸出文件，通常是難以避免的要求。要準備簡報最困難的有時不是演說的部分，而是資料的來源。一但習慣在Redmine中記錄這些零碎的資訊，等到要寫文件或作簡報的時候，他們根本就不用再"擠"什麼內容出來，唯一要做的是從系統中"選"一些內容貼上去而已。
所有的實作者留下了所有的經驗，對你還有什麼重要的好處呢？就是考績評鑑。
這不是指打考績的時候，你要去把所有人寫過的東西都看過一輪，這種事情應該連蒼蠅都辦不到。當實作者每天持續不斷的輸出內容，你都能理解及跟上他的報告內容時，你才能以最客觀的角度去評鑑這個成員該得到什麼考績。許多大公司是一年才打一次考績，每次的考績都直接影響調薪及獎金，當然是必須慎重看待的事情。越是這麼慎重，需要絕對客觀的評估的事情，就越是仰賴你平日對這個成員的考察。技術研發性質的工作，有時會很順利，有時則是困難重重，順利的時候他是否能對其他成員伸出援手，卡住的時候他是否能有效突破，這就是任務追蹤系統該能讓你知道的事實。
成員獲得的是實作技術相關的知識和經驗，而你能獲得的是對成員正確評價的事實和觀察，這就是一開始提到，你要使用任務追蹤系統最重要的理由。
「品質」是要求出來的
你對「品質」的定義是什麼？
每個人都會有自己的答案清單，但我想都會有一個項目叫「細節」排在裡面。在導入任務追蹤系統的過程，會讓實作者多出許多工作要做，不用他們說，你也知道這真的是額外的成本。可要求細節本來就是一份成本，各行各業皆然。技術研發性質的工作，基本上整份工作從投入到產出都是滿滿的細節，從為什麼去做？誰去做？何時做？怎麼做？障礙怎麼突破？…這個全程是沒有「中間產物」可言的，沒有不重要的，只有還沒用到的。要管理這麼多細節，讓它們在需要的時候能被找到及被使用，就看你對品質的要求程度，不只是對產品的品質要求，更是對團隊跟對你自己的品質要求。