前言
作為未來有興趣往 PM 發展的工程師，閱讀到這段馬上就選擇報名了。
本文
上半場
開場由 91APP 的 Ruddy 老師導引了一些敏捷團隊該努力的方向。
自己聽到的重點有：
- 敏捷團隊不該出現很忙的情況，代表有問題沒有釐清，反思敏捷精神。
- 小增量
- 多迭代
- 求回饋
- 尋求議題清晰，目標清楚。
- 使用 OKR。
詳細內容可參考 Ruddy 老師寫的這篇文章：
主管；你很忙嗎?
這邊個人理解成，真正有照著敏捷跑的團隊因為目標夠明確，能夠切分，所以應該都要能夠在一個時程內完成。
上半場的感想，確實比較面相對已經是管理階級的工程師開的論壇，但整個大主題圍繞在 傳承 這些經驗、或是帶著大家找尋最佳解，就代表也需要有新血流入，況且主題是管理結合技術本來就是我比較感興趣得題目，可以再多關注社群公布的消息。
下半場
下半場開場由商業思維學院院長 Gipi 分享之前在業界的經驗。
首先提到了為何台灣的技術思維還停留在原始代工的階段，而期望達到的境界為：
從他的自身經驗分享提到公司團隊合作方式。
第一階段：未開化時期。
所有需求單位都可以直接對工程師提需求，而造就了這種情況。
這張圖出現的時候，馬上就引起不少共鳴XD
第二階段：逐漸敏捷。
公司開始有一個產品經理的職位出現，但因為以前都能直接對工程師提需求，所以需求單位並不習慣這種方式，於是就需要有數據佐證，透過產品經理的職位來達到雙向溝通；提升了多少等數據。
這邊有提到目前大多數的公司敏捷團隊都只停留在技術團隊，有沒有可能跨出技術團隊，讓整個組織都敏捷呢？
第三階段：敏捷完整體。
讓敏捷的精神跨出技術團隊，帶入整個公司，Gipi 提到，他們當初是透過接收需求端後，找出目標實驗客群，透過目標推送客製化內容，每兩周讓客服與客戶對焦回饋心得，以此方式迭帶收集需求，最後找到一個最佳解再進行工程團隊開發。
第二個主題分享是目前很多企業推廣敏捷、OKR、轉型的原因。
敏捷
世界為何變得 VUKA？
VUKA 是「波動、不確定、複雜和模糊的縮寫」（volatile, uncertain, complex and ambiguous）。
1、全球化。
=> 競爭對手已經不適原本所想的那些人。
這邊自己所想到的例子是：Amazon。
從最早的網路書店，轉型成電商平台，現在又跨足了雲端、食品、影視等產業。
因為基礎建設完善，跨足產業容易，因為這些產業而形成了亞馬遜生態系。
2、尋求變化速度改變。
網路更快、消費意識抬頭、全球化競爭 => 應變速度要更快。
Ex:過去鄉下地方買電器可能找鄰近的電器行，而電器行會透過合作廠商推廣電器，消費者選擇少；現今使用網路選擇多樣化的情況下，廠商競爭者變多了。
3、商業合作面。
過去產業鏈單純、現在跨界企業出現。
講者是以 Tesla 顛覆汽車業做舉例。
這邊我也是想到 Amazion，顛覆原產業、連結整個 Amazon 生態系。
4、科技。
科技進步速度加快。
Ex:摩爾定律。
這邊有提到如何用舊思維理解新技術？
高層可能會遇到難以理解新技術的情況。
這邊個人想到的是當初教授有提到，新技術根本還是回到 Computer Science 本身，DS、OS、演算法這些本同源，永遠不會過時，所以個人對這點也比較難以理解。
後來分組討論的 Konrad 老師，本身也在台積電待了很多年現已退休，最後也是告訴我們有些東西不會過時，而那些根本才是技術人的精隨。
OKR
台灣晚了20年導入。
一開始的導入原因，需求難以對焦，從高層傳達下來的時間過長、甚至意思不夠明確。
關鍵問題在於：
外部變化速度快於公司內部同步速度。
最後就會演變成上層沒意識到溝通速度太慢，而導致 OKR 本質偏移，根本問題還是沒處理。
數位轉型
上面兩種都嘗試過後，就會開始談數位轉型。
而談到數位轉型的根本，為甚麼要轉型？
錢賺不夠多了，但問題是怎麼轉？
這邊就提到了過去引領企業走上正軌，因此升遷到一定位子的主管，可能因為時間的推移，他們的經驗已經不符合當代的技術，甚至給不出甚麼好建議。
提到了不能全怪老闆…
若老闆真的下放權力給你決定，你真的有把握做出正確的決策嗎？
所以為了提高做出正確決策的機率，技術人也應該要去了解商業層面的東西。
現實情況就是位階高的人具備高的商業掌握度，但卻少了科技的掌握度。
這邊就提到了，分工應該要重新定義，工程需要了解業務面的需求，PM 也該了解技術面的解決方式，彼此互相 Cover 協作。
因此有了幾種職涯的路線圖。
第一種雙專精職路線圖，也是目前較多公司熟知的方式：
第二種讓有技術背景的人培養商業思維：
(個人認為這邊就是資管的優勢)
第三種類似於現今扁平化組織，推行敏捷的架構：
第四種最終型態：
在第四種型態的組織架構下，商業已不在只是老闆該負責的事了，是每個人的事。
(若你對環境是有責任，就需要跨出自己工作的守備範圍。)
這邊提到了思維上的轉換：
一般情況下抱怨決策不當，扯上自己要幫忙解決的時候可能會覺得超出自己工作範圍，覺得煩躁。
換個方式，你去幫助一個甚麼都不懂得人，可以獲得更多成就感，甚至能夠對某些決策靈敏度提升。
最後總結提到了技術管理應具備的三大元素：
想看更多精彩的內容歡迎到社群觀看：
技術管理者交流社團
後記
印象深刻現場因為不少工程師，在 Gipi 提問到認為 PM 是否該懂技術的時候，大概超過八成的人舉手。
也從企業顧問的角度了解到，的確在多數企業中管理職人員與技術職人員溝通上的差距還是很大，所以他們也想找出一個能夠傳承的方式，才會有了技術管理者論壇這些活動。
除了分享內容豐富，留下的討論階段也是獲益良多，能夠跟不同公司的人交流、互相分享情況，最後再透過每個組別的一位導師統整問題後給予一些建議，最後討論到大家都不想走了。
另外在討論的時候才發現原來在場的工程師、或是 PM、相關管理職人員都有一定年資，自己還沒滿兩年資歷的真的是少見啊XD