在很久很久之前,有一個日本人叫做宮本武藏,他在晚年的時候,寫了一本書叫做五輪書,書中寫的是劍士對決的經驗,之中有一個很重要的觀念就是,節奏感,在對決的時候,一但對手的節奏感被您所破壞,就差不多要落敗了。這跟軟體專案有甚麼關系? 或許許多的專案管理書都是西方寫的,所以我們大多在談所謂的人月等很科學的事物,卻極少在談論東方的哲學之美,但在我的有限經驗中,我卻發現軟體專案也有一種節奏感,節奏感如果很順暢,通常專案就會行進的相對順利,反過來,一旦這個節奏感出現異常,通常就代表有問題發生,可以做為預警之用,但能否修正則看問題的原因了,有時政治問題也只能用政治手段來解決了。

在我的經驗下,軟體專案不可能始終維持在同一個頻率,不同階段會用不同的速度行進,嘗試打破節奏感,都是不好的事。最常見的是嘗試加速行進速度,在我個人經驗中,如果在範圍、資源不變的情況下,加速的結果還沒看過成功的。反過來說,那放慢就會比較好嗎? 我也不覺得,因為太慢的節奏感,最有可能的結果,就是整個團隊無法團結在一起,要不就是因為資源有剩,所以就被其他更急的地方收納去,太慢的節奏感只是浪費更多的時間與資源而已

回到正題,在我的想法中,專案的節奏理想的情況應該是怎樣
1. 起始階段
理論上,這個時候節奏是最慢的,重點在調整專案成員的節奏感,讓陸續到位的專案成員知道接下來要去哪裡,要怎麼做,或進行早期的RD研究,降低未來的風險。
2. 開發階段
正常的話專案節奏已經統一了,成員知道自己要怎麼做了,可以加速了,至於跟不上的同仁,就要注意了,因為落後的同仁在群體中就會變成很明顯,要盡快跟上。
3. 驗收或上線前期
這個時期最好是控制在4-6周內,最長也避免超過8周,也就是兩個月。主要原因,就在於這個時期往往就是整個專案節奏最快的時候,為了追趕進度,為了配合後期客戶才提出來的問題單與需求單,團隊會處在很緊張的情況,個人的經驗,若在4-6周內,適當的壓力可以凝聚團隊的意識,讓團隊維持在快節奏下而不會出事,但如果超過2個月,這時候的團隊就會開始解體,團隊內的衝突會出現,而所謂的加班效果也快速遞減中,並有可能惡化到團隊失控的情況,對於專案而言要盡可能避免走到這一步,不過,理論歸理論,在實務上,什麼千奇百怪的問題都有,有的能解,有的要很多人一起下去解,甚至業務或高級長官也要一起協助才有機會解開。
4. 驗收或上線後初期
走到這一步,系統的重大問題理論上應該已經處理的差不多了,但還稱不上穩定,許多問題單或需求單仍會出現,對於團隊而言每天都是考驗,不過畢竟已經驗收或上線了,對於團隊而言會有士氣提振的效果。理論上,這個階段的行進速度會受到問題單數量與嚴重程度的影響比較大,初期仍然很緊,但會逐漸放鬆,若過程中有小空檔可以休息,例如雖然每天仍有很多的問題單,但沒有重大風險,或這些問題單也不是馬上就能處理的,就我過去的經驗,我會鼓勵同仁抓到時間,縱使是半天都好,休息一下,因為從上階段到這個階段,很可能已經維持數月之久了,適當的休息,可以重新讓團隊有活力一點,至少笑聲又會出現了,有助於團隊撐過後面痛苦的時刻點,總不能每一個專案都走一批人,這不是在幫其人公司練兵嗎?
5. 最後階段
保固與人員抽離,一段時間之後,系統會相對穩定,只需要保留適當的人員,或是移交給維運團隊,這時候就有成員陸續離開專案,一些交接或事後檢討部分就不討論了,不過,理論上,這個時候的團員會相對輕鬆一些,這階段就是請他們接受下一個挑戰的時候,也是另一個起始階段的開始。

創作者介紹

Min's Web Life: 談網路產業研究與生活閒聊

miin1130 發表在 痞客邦 PIXNET 留言(0) 人氣()