Management

該使用什麼樣的管理模式?


該使用什麼樣的管理模式?

在文章 “[翻譯] 超越極限:讓遊戲團隊啟動並對專案有熱情" 文章中有網友問到:

(在甚麼情形下)該使用什麼樣的管理模式?

簡答:看情況,沒有絕對.讓團隊決定。

詳答:

這個命題應該是:

A) 當團隊變大時,管理方式是否應該變更?

其實這個問題很困難。
微型團隊(通常是一到三,小於十都算)幾乎不需要管理,
因為所有人都都可以透過點對點的溝通得到他所需要的資訊。
同時需要討論的人可能只有個位數。

所以管理方式想要(被迫)變更的時候,
可能代表團隊已經發生 “點對點溝通無法讓團隊順利運作" 的困難了。
也就是遇到了問題,只好想辦法解決。

我本身遇過也聽過不同專案團隊,運作一定時間(有可能是人數變多,或是士氣下降)後,開始規定上下班時間,開始導入績效評核,開始將團隊拆分為功能組,或是建立主程式,主企畫,主美術的組織架構。

請特別注意,這時候其實是如履薄冰,非常危險的決定。

請考量到一個可能性:制度的改變可能並不能解決問題。同時因為制度改變,新的制度會帶來新的問題,導致士氣又更下降的情況。

尤其是小團隊創立之初,多半都是微型團隊。創始元老多半都能接受人治,義氣相投,所以才在一起。當要改成所謂的有制度時,反而違逆了當時促成這些人在一起的原因。(有部分的人就是不喜歡大公司的運作方式,喜歡小團隊共同打拼的溫馨感才會跳出來成立小團隊。)

很可惜的對此確實沒有標準答案,正確解答。

但我會建議:

  1. 先解決原本的問題,才改變制度/找外援。(例:先解決團隊內效率不彰的原因,改進之後針對趕不上的部分才找外包。)
  2. 改變制度最好在專案的斷點執行,專案釋出後,開新專案時。盡量不要在專案的開發中改變規則,因為那會給人一種(團隊開始時所看到情境的)合約被片面改變的感覺(例:我加入時團隊給我的感覺是如此溫暖,但現在卻變成冷冰冰的績效數據)。
  3. 導入管理制度是為了減少工作,請一定不要違逆這個原則。當發現管理帶給了團隊成員增加了過多的庶務工作時,可能這個管理制度是不好的。請採用別種替代方案。

B) 當團隊大小不同時?管理方式是否應該不同?

當我們學習 Scrum 時發現它對於團隊人數有個人數限制,也就是大於七或九人就應該拆分新的 Scrum team,也就是說 Scrum 在設計之初就已經承認一點:Scrum 是一種不會管理的人湊在一起該怎麼運作的管理方式,當團隊變大時該怎麼處理?就是拆成新的 Scrum 團隊,繼續保持小團隊的習性。

所以沒有因為團隊變大就一定要用甚麼管理方式的規定。

即便是小團隊也可以採用瀑布式。純粹是依據團隊的工作習性而定。

到底該使用甚麼管理方式,這裡引申成功的秘訣:專注內所分析:

  • 敏捷式其實適合每個成員都同等資深(但又沒有一個特別優秀的領導者),且能夠自主激勵,不會偷懶。
  • 瀑布式其實適合母雞帶小雞,資淺的成員需要被規範,需要被安排工作,否則他不知道該做甚麼(因為專案經驗不足)
  • 原型式適合菁英的反應小團隊,搭配專精量產組的組合。

共勉之。

 

廣告

發表迴響

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

WordPress.com Logo

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

Twitter picture

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

Facebook照片

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

Google+ photo

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

連結到 %s