為什麼我要從開始就採取可擴張的管理方式

為什麼我要從開始就採取可擴張的管理方式

這裡所謂可擴張的管理方式指的是我一直以來認定正確的軟體專案開發方式,在我的軟體管理經驗談文章中所說,他大體是比較接近PMP專案管理,強調在實作前詳細設計,強調制度,強調責任,強調規格的開始,實作,驗證,與修改的完整流程。在這樣的管理方式下,可以讓團隊徵募量產型(非技術型)的員工,也就是團隊擴張時,把效能維持在高檔,而不會因為人多而反而口雜/手雜。

我要提到這點如此重要的原因在於,很多團隊,剛開始時都很小,可能不過三五人,大多數都會使用敏捷式(或稱為車庫式,同樂會式,烏托邦式)的管理風格。很令人驚艷的,在這樣規模的團隊,這樣的運作方式最簡單直覺,最快速有效。然而,當團隊隨著專案擴張時,到達九人尚勉強可以支撐,一旦超過十人成為一個小型團隊,這種管理方式會因為溝通效率低落,資訊爆炸,沒有找到關鍵人物,沒有真正解決問題,徵募了太弱、太強、或不適應敏捷式的員工的種種因素馬上崩潰。

團隊開始時會採用敏捷式的理由很明顯,就是簡單。而也因為如此容易對於團隊擴充的問題沒有留意,就算有,一般理想的想法多半是當我要變大時,再切換管理方式即可。

但是這樣的切換的設想,不會理想般發生,都需要外力介入。因為團隊使用敏捷式的開發方式成為團隊的文化,而團隊能擴張表示產品必定是成功的(否則團隊不會擴張),而這敏捷式的成功經驗反而阻塞了管理方式的改變。也就是說團隊的成員已經非常習慣於敏捷式的開發方式,而且認為這就是成功經驗(王道),以前這樣都運作的好好,現在不應該也不需要改變。他們沒辦法看出團隊擴增時所造成的問題是來自於管理,而不是來自於人員沒有確實執行敏捷式的開發方式。

這也是為什麼Scrum(敏捷式的其中一種)要限制人數的原因(一般建議Scrum團隊人數5~9人),因為他就是知道,這樣的開發方式一旦團隊超過九人,就會崩潰。而採用Scrum的團隊擴增時,採取的方式就是,把團隊依照功能拆開,變成多個Scrum團隊,繼續保持每個團隊都不超過九人=不會崩潰的穩態。

敏捷式在純軟體有他迷人的地方,但是很遺憾地在遊戲軟體的開發上卻並非如此吻合,因為遊戲軟體的分工已經很細,大的產品可能有五十人甚至超過百人同時工作,很多的團隊成員,並不是在做一個軟體功能,而是在產出一個關卡,劇情,甚至數據。這些非技術性的工作有時並不符合敏捷式原先想要套用的環境。

我的管理方式採取敏捷式其中的幾個精神,數個技巧,但是實際上是跑由上而下分層管理的風格,不管人少或人多都讓它相同,差別在於規模大小與管理所耗費的時間比例而已。

廣告

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s