敏捷式管理Agile

其實一直覺得管理是一種很模糊的東西,就是因為他不那麼的具體. 但其實身處在工作中你又會覺得管理其實是一個很具體存在的東西.

在挖掘工作職缺時候發現一詞“敏捷式管理”, 因為專案的變化很快, 所你要有更快的時間,更有效的方法去反應改變你現在管理的方向, 所以是”敏捷式管理“, 是的我有,我想我具備了?!

網路上都有很多關於敏捷式管理的文章, 深深地了解了一下

敏捷式管理的定義：起源於軟體業的開發模式因為變動很快例如需求變動,環境變化等不穩定,會需要快速的有一個Sample進行測試後根據相關的數據或是實用的反饋進行方向的調整, 所以有了敏捷式管理的一詞說法

在沒有敏捷式管理之前是“瀑布式管理”就像名字所述的他像瀑布一樣,一條直線,必須有方向性,這個完成後才可以抵達下一步,這一連串的步驟涵括一開始的概念、一連串的分析、開始進行專案設計、規畫專案的進行、實際開始著手操作、有了初步的測試、推行實施、和實施後問題的維護。聽起來其實很正常也沒有什麼不好, 感覺是走一個完整的專案會需要的步驟。

但我覺得日益變化的時代, 本來會延伸出不同的世代不同的行業需要有不同的方法所以延伸出了“更快”,“更有效”的說法, 其實往往在舊有的瀑布式裡面就不能維持原有的步驟但每一步加快嗎？個人是覺得可以

所以無論是瀑布式的『循序漸進』亦或者敏捷式的『彈性』其實本來就是可以你儂我儂的一起合作, 所以也有看到延伸出了混合式的說法, 所以沒有必要完全的分割清楚關係

想再介紹一詞 Scrum 他是Agile 裡面的一個方法, Scrum 查了一下中文的意思是“框架”, 更直接的翻譯是“衝刺”, 看到網路上介紹的是說, 起源於橄欖球的運動裡的“衝”, 因為當你接到球的那瞬間你沒有方向, 必須快速地做出判斷並且讓所有的隊員跟著你一起配合著某項策略快速的衝向得分區, 所以衝呀!

在Agile裡面其實有很多種方法, Scrum 只是其中一種, 看到資料顯示包含以下四場會議的模式來運行Scrum方法 : 短衝刺規劃會議(每週一早上)->站立會議(每天)->產品檢視會議(每週五下午)->自省會議(週五下班前)

在這裡面短跑衝刺會議 : 俗稱「Sprint 」覺得很有趣, 像是每週的一開始大家align好本週的進度,然後開始每天早會的例行追蹤專案的進度,到週五的時候再來一個專案一週總結的會議,最後再由每個專案的所有人參與最後的自省會議.

這裡面有一個很關鍵的角色,產品負責人,我就理解為大PM=總PM, 他必須主導所有的會議, 並給出方向的導正, 並日復一日,週復一週的循環直到專案結束, 皆大歡喜

但在這過程中, 一定會有很多很多問題, 其實無論哪一種方法, 合作就是會有分歧, 有分歧就是透過種種的方法來解決, 在此小小分享我的觀點

1. 明確會議的目的是什麼, 大家是否知道明瞭?

   從上面的會議上來看每週基本上就有8個會, 還不包括突然新增的會議, 每天真的有很多的會, 開會往往是最殺時間的, 然後, 把大家聚集在一起殺時間, 一起殺時間時間過得比較快?

   其實,開會這件事情是必要的, 但往往參與的角色太過模糊, 全員參加還是各部門的負責人參加, 參加的過程中可能包含各式各樣的主題, 主題之間是否可以做個分類, 讓各小組可以依序進來報告討論, 而不是大雜燴的形式.

   是的, 可能需要提前standby, 身為PM角色的人確實是有必要知道整個專案的全貌, 需要全程參與但真的並非所有人員需要全程參與整個會議, 這就是往往時間消磨在永無止盡的會議裡

   每個人要知道會議的目的, Sprint & 每日週會 &週五的兩個會 目的是什麼？每一個來參加的人是清楚的嗎？大家唯獨知道自己的各司其職,會議才不會長如江水細水長流

   今天會報的重點, 要得到什麼結果, 遇到什麼問題, 需要什麼幫忙, 都需要簡而有力, 是的一個專案的問題很多, 也沒辦法在會議上逐步挖掘分析問題, 所以大家一定要提前準備, 如果還要下來討論的會議就必須快速了當的線下另行舉會, 提高會議的效率

2. 責任的下發「信任」

   在遇到問題時, 真的要給予足夠的下屬決定的權利, 每件事都來詢問你, 如果你可以馬上給出答案那很好, 但如果主管剛好不在可能在開會在出差的路上, 如果聯繫不上主管是否專案就會delay, 所以, 上司真的要給予下屬足夠的「信任力」,相信他們的判斷

   如果是很不放心的上司, 可以多一點的主動詢問也是可以的, 把他來找你經過你的許可這件事, 是不是可以反過來變成先讓他做出他的決定, 而你去向他詢問進度之類的, 這些東西在每天的部門例會上也可以了解進度, 並不會因為讓下屬做了決定好像上司一切都不知情

   當然, 也會有什麼都會主動『向上管理』的同事, 他們真的每件事都會向上匯報, 鉅細彌遺, 這種模式除非你能夠95%聯繫上主管並且都能夠馬上得到主管的反饋, 不然我覺得這種模式並不適合於現在的管理模式裡, 無論是敏捷或不敏捷的管理方法

3. 定義角色, 了解組織裡那神奇的關係

   在一個大組織裡定義角色更容易模糊, 如果角色不清楚分配下去的工作就會延伸出你推我, 我推他, 最後推向專案負責人由他來定奪誰來負責這件事情, 所以, 這時候組織裡每一位員工的關係, 要了解這些關係就是一件很複雜的事情(我也非常不擅長)

   確實在工作裡, 個人的情緒常常會讓一件事情變得有趣, 艱難的有趣, 開始一連串的溝通, 最後才能讓事情順利的繼續走下去, 定義角色貌似也沒辦法完全解決這種情緒的事情, 但是我相信在職場上的每一位同事都有一定的「成熟度」, 對於敵人也應該保有基本的合作關係, 說不定主管工作分配的巧妙可以讓兩位同事化干戈為玉帛

   上司應該盡可能地降低工作分配的模糊度, 這也能夠幫助員工順利的完成任務

   ---

回到敏捷式管理, 我覺得他的本質是

• 快速產出,先行部隊

• 直來直往,面對問題有話直說, 少一點辦公室的政治

• 工作分配界線清晰

• 足夠的信任值,發揮最大的效益

• 勇於接納錯誤別人評判的能力（我們不可能永遠是對的）

• try try try ....