這篇是參加 #技術管理者交流論壇 - 技術與商業間的平衡 的活動筆記，技術管理者論壇說明如下
這是一個專屬於「技術管理者」的交流社團，所謂的技術管理顧名思義指的是在職務角色上需要肩負起技術選擇與應用，並隨公司狀態持續改善技術框架的成員。例如研發與IT部門的管理者，或者是架構師。當天是論壇所舉辦的第一次線下活動 : 活動頁說明，自己參加後也整理當天活動的筆記方便日後回顧(lag 很久)，如果內容有錯誤或是有理解錯誤的地方請跟我說會立即修正，謝謝
起心動念
實際上技術主管的養成是相對難的事情，尤其你要在面對多變的商業環境上不單純是管理人的問題，很多在做技術決策，商業決策你的洞見才是關鍵的地方，在技術論壇中會分為多個part，除了有講者分享過去的經驗之外，還會有更多分組的討論與交流，不單純的只是聽講而已，更希望的是藉由討論的過程中可以從別人的身上吸取經驗，這也是社群中最重要的力量。
補充 : 技術管理者論壇籌辦初心說明
召集人
接著請五位招集人與大家聊聊建立技術管理者論壇的起心動念
Tomas
- 傳承 : 大家在每一個自己的組織走到現在都是個「傳奇」，都是你組織的那個傳奇，怎麼把傳奇傳承下去都是個重要的課題。
- Legacy Code = 祖產 : Legacy Code (遺留代碼、技術債) 從兩三年前我開始推廣這字叫「祖產」，如果用「技術債」這個字比較像是一個包袱，是一個很沉重的事情。但反過來想 如果沒有 Legacy Code 怎麼會有現在的公司營收，如果用祖產的觀念來看技術債則會有不同的思維，思考怎麼樣幫祖產來做變現或是拉皮(refactoring)的動作，如果不會可以找祖產拉皮師 91，怎麼用重構而不是用 rewrite 來解決組織的痛點是大家要一起學習的。
- 共好 : 在不同公司大小規模不同產業的的企業，可能都會遇到些題目(問題)是差不多的，能不能有種整合匯聚或是共同學習的方式，想透過一些方法想將在台灣看到的一些組織的困境讓它浮現，提供可以解決問的patten，找到每一個企業根據 context 的最佳解或最適解。
- 做了一個採訪系列的節目，採訪一位從香港來台灣的老闆，在討論過程中提到一個問題，
- Q : 你覺得做管理跟以前在寫程式 你覺得差異最不一樣的是什麼 ?
- A : 寫程式至少東西是有解的，會的方法論算一算之後可以寫出一個 pattern；但是在管理方面自己也還在學習，因為管理的人的時候用同一套方法可能最後全部的答案(結果)會不一樣。其實你會發現很多工程師踏入到管理領域之後會很困難，因為在管理每一個人時需要花不同的管理方法、需要用不同的方法來溝通，才會得到想要的答案。自己在這部分也在學習中。
- 如果能夠跟各種不同的人溝通都能順暢時，很快的組織溝通就慢慢的順暢，跟 Tomas 聊天的過程學到對話的細節是重要的，舉例來說在問「為什麼你這樣做」跟「你要不要跟我說說你為什麼這樣做」，感受不同你得到的答案也會不一樣，這是很細的管理議題(IF-ELSE)，希望大家在過程中玩得開心。
- Gipi 昨天在 fb 有發一則很有趣的故事，故事來是「[五項修練的故事3：洞穴人的陰影]」，這故事提到原始人的部落分為兩派，一派是主張狩獵的長茅派，一派是主張採集的竹簍派，這兩派人主要是在不同的高塔裡面用不同的視角看到的東西產生不同的心智模式；長茅派在高塔上看到的是部落東邊的環境，有很多的水牛 野豬等，因此主張狩獵為主；竹簍派看到的是部落西邊的環境，有很多的葡萄 玉米，主張採集為主。兩派所看到的東西不同導致心智模式也不相同，導致部落裡面產生很多矛盾與爭執最近漸行漸遠。
- 這情況跟我們觀察到業界的情況很類似，技術人員會覺得管理人員只會出張嘴 壓時籌 不會做產品；管理人員可能技術人員不懂商業價值，只會關注在自己的技術浪漫中；兩邊觀點不同導致很多企業間的資源浪費與沿生出來的痛，我們想要改善這情況
- 工作初期擔任 Team Leader 到這幾年在企業擔任顧問與教練，所扮演的角色就是在兩座高塔中之間做溝通，持續的了解管理人員與技術人員「想要」跟「需要」的是什麼，公司的目標是什麼，在透過翻譯與引導的方式讓對方一起活下來，
- 希望透過技術管理者論壇，可以幫助大家或是公司看到全局，像是划龍舟一樣不是拼命划就夠了，還需要朝相同的方向，一起用力才有機會用最快的速度朝向共的目標前進
- 五項修練的故事3：洞穴人的陰影
- 91 補充 : 指引其實一直都存在，只是我們未曾去發掘、體會與練習 from FB
Ant
- 生涯規劃
- - 10 大科技公司裡面，有幾位 CEO 有工程背景 > 8位
- - 20 大受青睞的公司裡面，有幾位 CEO 有工程背景 > 12位
- - 自己或是朋友在面試時會詢問面試者，對於自己職涯或是生涯規劃會是什麼? 8成會說是架構師，1成 CTO
- DX : 在過去國內或是國外近幾年談的都是 User experience (UX)，但比較少提到 Develop experience (DX)，從內部(技術人員)的角度出發發現中間可能會有可以結合的點
- 傳承 : 最近都有與 Conf 的召集人在談，這幾年在常見的 Conf 上台的人絕大部分的都是認識的，Ant 鼓勵有興趣的年輕人上台分享，如果想不到題目可以一起討論，思考分享怎樣的題目讓大家更有幫助，希望在技術分享上也可以做到傳承的精神。
技術管理
- 如何做好在技術上面的商業決策
- 如何做技術的選型
- 如何評估選型之後怎麼做好與技術之後的發展軌跡
- 如何面對技術債與新功能與之間的取捨
識別可能性
PM 需要懂技術嗎 ? 大家覺得需要的原因是甚麼呢對不懂技術的 PM 來說，在談時程合不合理時，可能無從判斷起；在談解決方法好不好不知道時，只能信任工程師的建議與判斷；懂技術這件事情對於管理有什麼幫助
提高可能性
包含下列這些事
- 獨特性 : 產品或是技術有沒有獨特性。技術本身是有機會讓產品有競爭力的，但在過去可能很少被談論。可以有專利但在一班公司很少談這件事情，可能認為技術就是一個實踐手段但不具備獨特性的地方，但如果可以識別技術的邊界，利用其技術特性創造產品的可能性或是商業的可能性，本身是會有獨特性的。
- 延展性 : 在做技術選型時是否有思考到他能夠延展的邊界是什麼，可能不會討論套件是不是夠完整 討論社群是不是夠成熟 可能在過去很少在思考 如果今天是在做一個商業軟體的話 可能要思考這些事情，是不是有那麼豐富的支持，因此可能在技術選型或是技術決策時候可能要考慮到技術的延展性，也是一個相當重要的關鍵點
在溝通時可以提高溝通的品質，了解技術解決方案的優缺點是什麼以及是否合適；在風險的控管與品質上掌握度較高。
過去在管理開發團隊上都 focus 在 #提高可管理性 出發，PM 與技術主管可能大部分工作都在做這件事情，但忽略 #提高可能性 這更重要的事情，技術管理不單單在講把帶的 RD 團隊帶好就好，希望更廣泛一點從技術管理的角度來談論是值得被探討的。
過去 v.s 未來
從傳教到傳承
Ruddy 老師
- 一般的技術人員在成長到一定的經驗後，通常缺乏管理的能力
- 敏捷比較少講管理兩個字，通常講的是激發，激發團隊的方法讓他們可以表現可以超出團隊的潛能
- Q : 你們忙不忙? 一個敏捷的團隊應該很忙嗎 ? 讓下屬不忙是管理者(你)的責任
- 敏捷口訣:小增量、多迭代、尋求回饋
- 如何提升速度 : 把一個大目標切成一個小目標，如果將目標切成四塊，可能做完其中重要的一塊可以達到80%的效果
- 一分鐘衡量 : 衡量目標是否有達成，可以透過 OKR 來達到這件事情，目標>關鍵結果>是否達成
- 一分鐘稱讚 : 目標有達成，不吝嗇地稱讚下屬，稱讚做對的地方，希望持續地保持下去
- 一分鐘更正 : 目標未達成，嚴正地跟他說哪裡錯誤，要跟他說對他是有信心的，雖然這次表現比較差，你也知道發生錯誤的原因，相信下一次一定會做得很好
- 一分鐘風險控管 : 看板走的是限制理論，思考現在最大的約束在哪裡，如果是最大的約束要如何解決它。
- 一分鐘經理（新版）
- 全公司最用功的是 CEO，第二用功的是 CIO (有趣)，你的層次越高求知慾望應該會越高
技術管理者論壇 - 計畫說明
主要分為三大塊
- 社群
- 講座
- Mentoring program
社群
歡迎大家有問題都可以在社群提問，有很多大神可以幫忙回答喔喔 XDDD
Mentoring program
半年的時間與五位召集人 1on1，遇到問題時給予建議與幫助
資格限制
詳細細節以技術管理者社群公布辦法為主
商業與技術間的平衡 - Gipi
- 從商業的角度來看，商業更強調的是價值；技術強調的是登峰造極，效能更好；但是追求更好品質最佳的過程，很有可能忽略商業的目標，但如果捨棄掉的話有可能技術上面就沒辦法更精進了。
- 舉例來說 : 追求 99 ~ 100 的過程是技術能力精進的重要環節，但可能沒那麼符合經濟效應。
- 技術某種程度上是為了創造價值，商業在談的是更高效率的創造價值，技術應該追求的是極致跟如何應用它，這兩者之間可能會有 trade-off，但絕對沒有100%的對或錯。今天就先來跟大家分享自己對於這議題的看法
經驗分享
- 要跟大家分享一個過去比較不好的技術管理的經驗，這是前東家的狀況，但後來發現這狀況在台灣還蠻常見的
- 一間公司有一百位RD時是否應該具備完整的流程呢 ? 答案是沒有，光版本控制工具就有五套。
- 缺乏制度 : 遇到機器需要擴充的問題，發現Production 的機器不一樣，windows 版本不一樣，裡面的程式碼1/3也不相同，版控上的程式碼也不是最新的，造成不知道 scale out 的基準點(標準)是什麼。
- 開發也需要維運，白天開發，晚上維運(?
- 如果沒有辦法從技術架構、技術管理的流程上解決這問題，這問題還是會發生
技術不見得能100%決定能不能活到現在，但會決定接下來能不能活得好 人很重要，但不應該是 100% 的全部；人如果沒有 sense，就很容易一團亂
- 每天線上問題都有很多 workround
- 對於需求沒有管理，因此不斷變更需求，業務只要罵得兇就先做，不會去探討背後的價值是什麼
- 為什麼業務的需求都比技術債來的重要，因為業務單位的需求講得出價值，技術債不好衡量，但技術債真的沒價值嗎?其實不是，債是累積下來的，影響性是跟深地步的，是有可能會越變越糟的。
- 在過去所有人都可以向RD開發團隊及工程師提出需求
- 需求沒有經過管理與收斂排定優先順序，因此工程師常常會被不同業務來的需求打斷，或是為了處理線上問題而影響到既有專案的開發進度
- 為了改善之前的問題，由產品經理收集需求與 stakeholder 溝通，不在直接找工程師來提需求，讓工程師的資源投入在最有效益(最有商業價值、技術債)的地方
- 由產品經理來收斂問題與排定優先順序，透過運營及數據資料來支撐背後的價值來說服需求單位
- 產品單位有些需求是需要很長的時間完成，與產品單位討論後初期先透過人工的方式來驗證其可行性，而不是一定要透過技術問題才可以解決。
- 舉例來說，挑選兩百位客戶，先讓客服人員與客戶溝通與人工目標設定，在透過每周的迭帶與需求反饋，了解客戶會遭遇到甚麼問題，讓這群人在面對問題上也可以很 Agile (更快解決問題)
敏捷
- 我們正面對一個 VUCA 的環境
- 那為何世界會變得如此VUCA呢？
- VUCA : Volatility、Uncertainty、Complexity、Ambiguity
- 以前在製造業時代會發現需求改變的周期是長的，六個月~兩年都算是正常
- 小時候商品在賣可能商品不改包裝還是賣的動，像是乖乖、旺旺仙貝；但現在像是3C產品或是科技產品半年不動，就不會想買了因為有更新好的東西出現。
- 小時候住在鄉下，附近的電器行賣電視、洗衣機、冰箱，可以選擇的商品與品牌相對少，如果家附近只有兩間電器行只能二擇一做比較，選擇較少
- 供應商給什麼，消費者只能被動接受
- 在過去可能只能挑家附近的電器行做選擇，網際網路興起之後，可以上網到電商網頁有更多選擇
- 市場的變化速度加快，變為3~6個月
- 全球化之後更不一樣，上 Amazon 之後可以買全世界的商品
- 漸漸地可能會進入C2B(Customer to Business）消費者主導
- 變化頻率更快，要根據數據蒐集使用者的偏好來調整商品
- 在過去可能沒辦法想像 Amazon 為何要做雲端 SAAS 服務 ? 為何要自己開發物流 ?
- 越來越多大企業開始跨出原有產業鏈與領域
- 當你能更應變的時候，就能主動掌握機會，被動的時候就會發現機會在別人手上
- 商業連結已經越來越複雜，不是沒有受影響就沒事
- 不確定性 : 可能主要合作夥伴受到影響，就有連帶關係(連結越多，脆弱點會出現)
- 關心合作夥伴會不會出狀況，公司會不會有新機會出現
- 是否有機會建立新的連結，來因應(VUCA)新的變化
關鍵二
- 隨著時間的推進，科技的進步速度更快。在過去可能 10 年提升一個 level(紅框一)，後來演進速度越來越快變為2~3年(紅框二)
- 科技進步的速度這麼快，大家認為誰可以來掌握 ? 誰在公司做決策因應科技變化 ?
- 商業推進的速度與科技對比起來，商業是比較慢的；如果可以掌握商業運作的脈絡，掌握不變的部份再把科技的部分加進，會比強調一直在追新技術是相對重要的。
- 當技術科技變化快的時候人沒跟上，就會用舊的思維來做出(新世界)的決策
- 別人都上太空了，你還在殺豬公
- 技術決策還掌握在不碰技術人的身上；產品決策掌握在不接觸新的產品應用的人身上
- 那我們如何因應科技化變這麼快的環境 ? 敏捷
- 適應性、快速迭帶、小步快跑
OKR
- 為什麼老闆的一個需求到後來(可能)會變成爛的決策 ?
- 可能是因為 溝通
- 可能是因為 環境變化
- 老闆交辦後過了一個月，現在情境可能不一樣了，大環境(外部)在變化但可能內部沒做調整，導致問題發生。事情越頻繁的發生，發現是不是應該讓組織上下要目標對齊，review 後調整彼此的作法
- 在過去內部從上到下光四層同步一個決策，到貫穿要開始執行可能要兩個月的時間；但在這個時代變化頻率很快的時代，很有可能原本老闆看到的機會，一個月後可能就會不一樣了
- 基於以上原因，上下層就會產生很大的紛爭。
- OKR 很大一部分是為了解決這問題，理解公司的目標是什麼後開始進行，而不是圍繞目前手邊做的案子做到完美而忽略了外部的變化
- 當你理解公司與上層的目標之後，在做的事情就可以時時與目標對齊，隨時調整作法。當每一層都可以很好的做好這些事情，這也是OKR 希望達到的目的。
- 今年如果公司目標是要將利潤提升 2%，有多少基層員工可以理解利潤提升背後的意義是什麼 ?
- 其實是有難度的，可能需要透過多層的轉述讓你理解，這中間可能就會有時間與溝通的落差，也可能導致做事情不一致。
- OKR 形成的本質與敏捷極為相似。
數位轉型
- 老闆在怎麼英民神武，也很難因應各種快速的變化
- 如果交給你決定，你有把握做出好決策嗎？
- 當你對商業一無所知的時候，也無法平衡技術與商業之間的決策
- 上層是很理解對商業的掌握度是很高的，但到越下層了解度是相對較不足
- 從RD角度理解產品在想甚麼，如果不去理解問題就會一直存在，過去傳統的分工思維需調整，彼此 cover overlap 的部分。
- 鈦坦 Maryanto 「法國麵包」切法
第一種解法
- 商業管理本身是一門專業，並不是看了幾本書就可以學會的;科技技術也是一門專業。
- 雙職涯路徑，管理職與專業職是分開的，舉阿里巴巴為例管理是 M(management)，專心關注商業面管理決策；技術職是 P(professional)專注在科技與技術管理決策。
- 讓負責科技決策的人稍微往商業移動，不需要知道商業模式設計的全貌，不需要理解那麼深刻；但不能對於商業的事情是一無所知的。
- 今天 Ant 也有提到前 10 大科技公司 CEO 10 位有 8 位是工程背景，很大一部分原因是現在做生意要與商業脫鉤是不行的(也無法脫鉤工程)，從科技要去理解商業部分難度是比較低的。
- 從組織架構重新思考，從組織面調整
- 當流程明確清楚的知道交付內容的話適合功能型組織；有一定不確定性的話可能適合ＢＵ（專案型）組織；兩者各有優劣與適用性
- 團隊是 End to End，可以解決大多數的問題，也可以與其他團隊一起合作。比如說敏捷團隊就不會搭配法務
- 接下來還有甚麼可能性呢?
- 大部分公司推敏捷很大一部分還是侷限在開發團隊裡頭，並沒有跨出開發團隊
- 老闆在怎麼英明神武也有可能沒辦法搞定複雜的問題，只能透過蒐集更多專家的資訊&建議，做出現在適合的最佳解。
- 轉個角度來看，你也希望做的東西有價值，為什麼不協助老闆呢?也是在幫助自己做出有意義的事情
- 舉例來說你在開發一個服務，如果希望做出的服務是有價值的，但又不願意去了解是解決甚麼問題，怎麼服務客戶的 怎麼交付價值，如果不願意去理解這些事情，你就是把交付價值這件事情的權力，交付給老闆身上他決定錯了就錯了，自己的時間也就浪費掉了。
上游思維
- 大家回答 : 跟上游溝通、找其他下游一起找上游理論、換一條河、幫助上游、搬到上游(互相傷害)。
- 在公司裡面是不是也是面臨到一樣的狀況，上游可能是你的老闆、可能是業務部門
- - 跟上游溝通 : 找老闆溝通
- - 找其他下游一起找上游 : 找其他部門一起跟(說服)老闆溝通
- 解決他(老闆)的問題就是解決你的問題，才不會一直往下游丟垃圾
- 91影片分享 : Taking Responsibility is taking your power back ! by Will Smith
- 換一艘船 > 換工作
- 換一片海 > 換腦海
- 技術 : 追求極致，思考新的技術是否能解決舊的問題
- 商業 : 做的東西要有價值，透過驗證 value 做出決定
- 人文 : 要怎麼領導與激勵下屬，人的部分是不能忽略的
心得
議題心得
- #經驗分享 : 或許是有些過程有一起經歷過的緣故，今天在活動聽 gipi 分享時感觸蠻深的(擔任志工時偶爾插花偷聽一下)，在 T 社從一開始進去組織的混亂、開發團隊制度的不完全、被業務單位壓著打到後來局勢逐漸逆轉的經歷，幾張投影片或許聽起來很簡單，但也花了兩年多才搞定這些大大小小的事情。
- #商業思維 : 在與高層溝通的過程中，應該嘗試用帶來的商業價值角度來討論，技術人員或許不應該活在自己的技術浪漫，堅持要用最新或是最潮的技術解決方案，而忽略了要解決的商業問題是甚麼(技術有可能不是唯一解)，了解商業的價值與目的，在把其意義分享給開發團隊，這也是自己這幾年一直在調整的方向。
在技術管理者論壇創辦前期，與 Gipi 聊一聊後就自願報名志工的角色(入教?)，從開始的找活動場地到建立活動售票網頁、與贊助廠商討論活動如何配合、活動行前通知與活動問卷填寫...自己也學到辦活動需要注意的地方，還好有另一位有經驗的志工 kyle 協助，否則自己可能會手忙腳亂地。透過親身經歷也可以理解辦活動辛苦的地方，背後有一群人默默付出的付出活動才可以順利進行，謝謝當天贊助錄影的五倍紅寶石軟體，也非常感謝當天一起參與的九位志工朋友們，辛苦了 #辦活動超過百人紀錄達成
注重細節
在起心動念有提到，希望參與線下活動的各位朋友透過議題討論分享各自在組織遇到的問題與解法，讓彼此可以吸收更多經驗帶回到自己的團隊中。在前一天對 rundown 的時候，原本規劃是 14 位一組有 mentor 來帶，91 提到一組 14 位討論的人數太多，會影響到大家發言時間，加上圍著一張海報討論時就有可能變成兩排，沒辦法達到我們希望預期達到的效果，建議人數調整為7位大家才有更多發言與討論的機會。這是自己當初沒思考到的點，下次線下活動也可以作為借鏡 (可能也要等疫情穩定 XDDDDD)
最後，透過活動的大合照來做 Ending，希望大家在這過程可以玩的愉快 :)
0 意見:
張貼留言