在很久很久之前，有一個日本人叫做宮本武藏，他在晚年的時候，寫了一本書叫做五輪書，書中寫的是劍士對決的經驗，之中有一個很重要的觀念就是，節奏感，在對決的時候，一但對手的節奏感被您所破壞，就差不多要落敗了。這跟軟體專案有甚麼關系? 或許許多的專案管理書都是西方寫的，所以我們大多在談所謂的人月等很科學的事物，卻極少在談論東方的哲學之美，但在我的有限經驗中，我卻發現軟體專案也有一種節奏感，節奏感如果很順暢，通常專案就會行進的相對順利，反過來，一旦這個節奏感出現異常，通常就代表有問題發生，可以做為預警之用，但能否修正則看問題的原因了，有時政治問題也只能用政治手段來解決了。
在我的經驗下，軟體專案不可能始終維持在同一個頻率，不同階段會用不同的速度行進，嘗試打破節奏感，都是不好的事。最常見的是嘗試加速行進速度，在我個人經驗中，如果在範圍、資源不變的情況下，加速的結果還沒看過成功的。反過來說，那放慢就會比較好嗎? 我也不覺得，因為太慢的節奏感，最有可能的結果，就是整個團隊無法團結在一起，要不就是因為資源有剩，所以就被其他更急的地方收納去，太慢的節奏感只是浪費更多的時間與資源而已
回到正題，在我的想法中，專案的節奏理想的情況應該是怎樣
1. 起始階段
理論上，這個時候節奏是最慢的，重點在調整專案成員的節奏感，讓陸續到位的專案成員知道接下來要去哪裡，要怎麼做，或進行早期的RD研究，降低未來的風險。
2. 開發階段
正常的話專案節奏已經統一了，成員知道自己要怎麼做了，可以加速了，至於跟不上的同仁，就要注意了，因為落後的同仁在群體中就會變成很明顯，要盡快跟上。
3. 驗收或上線前期
這個時期最好是控制在4-6周內，最長也避免超過8周，也就是兩個月。主要原因，就在於這個時期往往就是整個專案節奏最快的時候，為了追趕進度，為了配合後期客戶才提出來的問題單與需求單，團隊會處在很緊張的情況，個人的經驗，若在4-6周內，適當的壓力可以凝聚團隊的意識，讓團隊維持在快節奏下而不會出事，但如果超過2個月，這時候的團隊就會開始解體，團隊內的衝突會出現，而所謂的加班效果也快速遞減中，並有可能惡化到團隊失控的情況，對於專案而言要盡可能避免走到這一步，不過，理論歸理論，在實務上，什麼千奇百怪的問題都有，有的能解，有的要很多人一起下去解，甚至業務或高級長官也要一起協助才有機會解開。
4. 驗收或上線後初期
走到這一步，系統的重大問題理論上應該已經處理的差不多了，但還稱不上穩定，許多問題單或需求單仍會出現，對於團隊而言每天都是考驗，不過畢竟已經驗收或上線了，對於團隊而言會有士氣提振的效果。理論上，這個階段的行進速度會受到問題單數量與嚴重程度的影響比較大，初期仍然很緊，但會逐漸放鬆，若過程中有小空檔可以休息，例如雖然每天仍有很多的問題單，但沒有重大風險，或這些問題單也不是馬上就能處理的，就我過去的經驗，我會鼓勵同仁抓到時間，縱使是半天都好，休息一下，因為從上階段到這個階段，很可能已經維持數月之久了，適當的休息，可以重新讓團隊有活力一點，至少笑聲又會出現了，有助於團隊撐過後面痛苦的時刻點，總不能每一個專案都走一批人，這不是在幫其人公司練兵嗎?
5. 最後階段
保固與人員抽離，一段時間之後，系統會相對穩定，只需要保留適當的人員，或是移交給維運團隊，這時候就有成員陸續離開專案，一些交接或事後檢討部分就不討論了，不過，理論上，這個時候的團員會相對輕鬆一些，這階段就是請他們接受下一個挑戰的時候，也是另一個起始階段的開始。
留言列表
