iT邦幫忙

2021 iThome 鐵人賽

DAY 16
0
IT管理

專案/團隊管理的無字天書系列 第 16

強人PM與敏捷相遇 -1

大概在2018年的時候,開始認識敏捷。會想要認識敏捷,其實也是服務的公司碰到了一定程度的發展瓶頸。

那時候公司正處在一個快速發展期,有許多的工作排隊需要完成,進入了一個專案地獄的狀況。一方的論戰認為人力不夠補人就好,但也有主管認為這樣下去也不是辦法,因此在尋找如何提高人力效能的方式。其中的一條線就是開始認識敏捷這樣的方法論。

後來不少團隊紛紛導入敏捷的方法,甚至整個主管高層也邀請了講師認真了解敏捷的精神。有些團隊堅持了兩三年,至今仍運作著,但也不少團隊也適應不良,紛紛更換了專案進行的方法。當然也有不少團隊有了前車之鑑,採取迂迴的方式,逐步進推。

當時,我與幾個資深主管討論起敏捷的話題,討論出幾個非常難以解決的致命問題,導致敏捷的幾個關鍵要素似乎無法滿足。像是PO的角色在公司幾乎不可能滿足、公司內功能部門拆很細等等。而我的後端主管也提出了一個特殊的觀點,公司各部門內技術能力良莠不齊,甚至都在靠資深工程師吃下工作,但敏捷的工作方式會非常需要對等的工作能力,因此要推行起來會非常的困難。

左思右想,如果硬套入敏捷的流程在眼前的這些工程師身上,大概也不會有好下場吧。但我自己認為敏捷仍有幾個非常重要的精神,那就不如先把這些東西落實一陣子再說吧:

1.透明度。我使用的專案管理工具,其實就只是一個todolist。這個工作清單基本上是開放在google excel上,團隊內部只要知道網址的,都可以看的到我所有關注的專案。專案下來時,我會盡可能地說明整個來龍去脈,以及我所看到的戰略價值。會議時間一定提早約,請假都讓所有人知道。

2.使用者故事。在內部說明功能的過程中,我要求我自己,以及專案的團隊都要以「身為<角色>,我想要使用<功能>,達到<目的>」來跟RD團隊溝通。我發現這樣的陳述句,幫助對於商業角色較為陌生的工程師理解功能如何被使用,用一個使用情境去框出功能使用的方式,反推讓工程師知道功能範圍,即便不用訂出功能細節,工程師也能依照經驗開發出適合的功能。

到後來,當我只要說出功能需求是來自於哪個單位時,同仁大概就能快速的抓到需求,甚至可以提案應該怎麼做,達到我所碰到的流程難題。

3.群體Demo驗收工作。在團隊的作業中常常面對一個很有趣的狀況:前端說他做好了,後端也說他做好了,但是合起來的東西卻是壞掉的。早期前後端兩個團隊都還在吵架,但是當直接告訴團隊,我就是要在什麼時候看到可以Demo的進度時,慢慢兩邊團隊重新調整節奏,逐漸調整工作週期,慢慢都能夠在時間內完成串接,做出整個故事完整的操作流程。

"做好了"的定義,在單兵作戰底下視角,大概都是停留在自己的部分完成了,但主管要的"做好了"其實是要看到整體的整合完整的狀況。而整合,才是大家會額外花時間與吵架的階段。就算不管吵架,還要額外花時間才能整合完成,這個狀況就是為什麼專案會一直延宕的原因。

4.公開感謝。因為是技術出身的專案管理人,我一直期望工程師多少要補上專案思維。因此只要技術同仁提出了專案上思考不周的地方,我一定會公開感謝同仁主動的思考題問。

團隊即便人數多,但是大部分的人還是單兵認領任務後作戰,沒有進入真正的團隊運作的經驗。我的想法,就是透過公開的感謝,讓當事人知道自己的主動思考提出問題,是可以得到正面回應甚至得到主管的感謝,同時間也讓其他人知道,這樣才是一個團隊互相幫補的互動過程。

上面的這四點,其實在其他團隊建立或者專案管理流程中都會被提到,只是這四點剛好在敏捷開發的流程中都被提及。所選擇的這四個面向,算是當初整個團隊文化中缺很大的部分,不管在心理層面還是在時間管理務實的層面來說,都是相當不足的。運作一年多後,加上前端團隊內有些人也努力的落實其他敏捷的實踐,後端團隊實踐"天下武功唯快不破"的概念,兩邊共同走出自己的路,但卻又能合作愉快!

PS. 團隊的強壯並不是作對一件事兩件事就能達成,因此沒有人能單獨居功。所有的成功,都是大家做對的多做錯的少累積下來的。


上一篇
主管與技術團隊的分工
下一篇
強人PM與敏捷相遇 -2
系列文
專案/團隊管理的無字天書30

尚未有邦友留言

立即登入留言