用第一次成功建立信心

給予空間、給予適應、不限方式，讓團隊創造第一次成功

制定了目標、習慣以團隊思考、有了些管理工具、也有一群在乎使用者痛點的IT夥伴，那就要創造一次成功經驗了！為了要讓IT團隊成功創造使用者有感的效益，身為產品經理的我，可是下足了不少功夫，在今年初組織調整之後，我手邊的IT資源是一名全端工程師、兩名實習生，直到正職的兩位全端工程師加入，我約莫有半年的時間，在持續作戰的狀態下，邊掌握邊收斂、邊照鏡子邊影響窗口，讓IT團隊可以具備足夠的資源與條件下，建立第一次的成功。我做了以下幾件事情：

1. 給予空間
2. 給予適應
3. 不限方式

給予空間

空間包含時間上的空間和技術上的空間，我相信一位優秀的工程師一定會致力於在單位時間內創造最大價值，在蹲點使用者等待IT新血加入時，我把時間先拉出了緩衝時間(理論上，緩衝時間應該是由工程師依據自身能力與工作狀態，衡量並估時)，讓所有需求對接窗口感受到並且接受其必要性，一位資深工程師告訴我：「IT在做的事，是創意發想型的工作，所以都會有風險」，緩衝時間便是為了風險而預留。而後，我依據時間的用途，先為工程師留下會議的時間，讓他們在忙於BAU之際，有機會停下腳步，彼此分享工程做法或是檢視自我的程式。時間上的空間，我的重點放在，將這樣的mental model傳達出去，同時掌握著IT時間的主導權，讓我可以為IT嚴守時間資源，使其可以同時進行BAU、開發、會議。參與公司部門運作的人都知道，只要討論到資源議題，就會引起反彈，獲得主管支持、促使工程師能協助正向呈現效益、不厭其煩的溝通，在這個過程都沒有少過。相較之下，技術上的空間就簡單許多，過去我會習慣性，很快跳到解方設計，讓問題的表述讓淡化，這樣造成工程師的input受限，也會讓自己很容易成為捍衛解方的人，現在，我著重於問題表述，為了加速討論流程，我會以拋出提案但不限提案的方式，讓工程師可以參與解方發想，比起怎麼解決，我現在花很多時間在為何要解決，而這樣和工程師間，我們是共同的關係，而不是彼此挑戰、檢核的關係，可以增加更多信任感。

給予適應

當IT新血加入時，彼此尚不熟悉、對公司不熟悉、對業務不熟悉，所以我們沒有急於啟動打造IT的軟體開發文化，設定以1個月為期，讓新來的工程師可以探索遍BAU，仰賴於過去半年的累積與收斂，我開始可以為BAU分類，並在配給或安排任務的時候，確保每一位都可以經手不同類型的工作，使新工程師可以將觸角放到最大，因為是人力資源的擴充，所以我請原本的工程師夥伴，退居幕後，協助新夥伴的第一線處理業務，當然，我會記下這類型業務是否為新夥伴的第一次接觸，第一次會為其保留更多時間，之後縮短。同時，我也會藉由新夥伴的視角，來看現行做法有無可以更好的地方。

不限方式

沒有任何一套方法是可以直接套用的，我們或許很想要導入Scrum，但是要達到scrum，需要打通很多環節，比起瞭解新方法，我們花更多心思想要了解現在的自己和現在的團隊，所以在這次開發時，雖然我們有用到一些Scrum常用的工具，我們並非高舉著Scrum大旗說，要用Scrum的方式進行。除此之外，包含要使用什麼管理工具等，我們都不急於當下決定，一個Notion、googlesheet、白板就支撐起了第一次開發。這讓我們更能感知我們的現況，知道團隊缺少的、找到初步和使用者溝通的切口。

在有SMART的目標基礎下，和這些條件基礎下，我們成功地打下第一次成功，中間當然不乏產品經理和工程師之間的拉扯，在接下來的兩天，我們會持續探究如何促成彼此信任感的建立，當然，這是我到目前的經驗，信任感這件事，是每天每天沒有終點的團隊課題。