今年年初的時候關注到 TGONetworks 舉辦了場 TGONext 有趣的活動，該活動由台灣的高階主管聯合舉辦，針對技術領域的三大主題：技術創業、技術管理、技術架構進行經驗的傳承。
撇除技術領域來看的話，不管是工程師或是 PM 或是行銷人員總會面臨到，在茫茫職海中我該繼續專研專業領域，或是選擇管理職，抑或是想不開走上創業的不歸路。
任何一條路線皆無好壞，端看如何做選擇。本文梳理了筆者如何在三大領域中做選擇，以及這半年以來技術管理組的參與心得。
主題的選擇
以技術領域而言，可概括為三條路線：Leader、VP、CTO
Leader：
技術角色。團隊內的技術大神，把技術做到專精VP：
同樣也是技術大神，但除了技術外也是管理職的角色CTO：
同樣是技術+管理的角色，但更多是需處理商業上的事，透過商業來收斂公司內的技術發展
在路線的選擇上絕非做越久越可以往下個角色邁進，更多的是思維上的轉變。以 VP 的角色而言，最重要的是溝通能力，也是管理職位需具備的能力，如何做到向上及向下管理更是門藝術，該如何把自己的想把傳達給下面的團隊執行，以及該如何說服上面的人撥資源供團隊運用，皆是管理人員的大挑戰。
而 CTO 同樣也是個有趣的職位，當時主管僅問了一句話，我便認知到尚未具備 CTO 的思維。
假設給你足夠多的人以及足夠多的錢，你知道要開一間怎樣的公司嗎？
假設這個問題你有答案，恭喜你。你已經具備 CTO 該有的三項能力：技術能力、管理能力以及商業思維。
筆者因想繼續精進自己的溝通能力，便選擇往 VP 的職位邁進。
如何問問題？
「明明我已經告訴你應該怎麼做了，為什麼你做出來成果跟我想像的完全不一樣」
“溝通” 是管理組第一次聚會的議題，導師給了一本書：你會問問題嗎：問對問題是成功領導的第一步，第一次聚會便是針對如何溝通做討論。
不論是管理職或是團隊成員一定很常遇到這情境，做法都告訴你了，你也說清楚該如何做了，但後續的成果跟預期完全相反，問題出在哪裡？
盡量別幫別人解決問題
假設溝通的過程不限於 “我告訴你” 而已，而是我們大家共同交換意見解決問題，問題是否會改善？
舉例來說，當團隊成員說：「專案開發過程中寫測試非常浪費時間，如果不寫測試我們能將專案上提早數天時間上線。」，這時你應該怎麼辦？
方法一：直接告訴他做法
你可能會直接跟他介紹寫測試的優點，藉此說服他能寫測試，但團隊成員的心理是抗拒的，就算有補上測試案例也只是表面，一但沒人監督或是換了新主管，整個團隊便會打回原形。
方法二：提問
讓團隊成員認同寫測試這件事是有幫助的，你可以針對幾件事情做幾個提問：
- 專案若提前上線對我們會有什麼幫助？
- 你要如何確保你寫的功能是正常的？
- 你要如何確保加了新功能後不會影響原有的功能？
- 假設功能出錯且修復後，你要如何確保相同的問題不再發生？
團隊成員在回答的過程中會開始思考問題如何解決，最後他們會認同其實寫測試是可以解決上述所提的事項。
但你在過程中僅是一直問問題而已，並沒有幫他們解決問題，因為問題是由他們自己想到而且解決的，所以會格外相信自己所得出的結論，但那又如何，事情仍是朝著你希望的方向繼續發展。
因此回歸到第一次聚會的主題，我們討論了如何溝通這件事。
績效考核與管理
在第二場聚會中，每個人分享了公司內部的績效考核方式，並提出管理上的優缺點與大家討論，但有趣的是，部分與會者後續的解決方法其實極為類似。
回到績效考核的本質，績效考核的目的為何？
公司當然不是吃素的，開公司大部分都是為了賺錢，因此目的很單純，如何幫公司變得更好便是績效考核的目的，更直白的說：誰幫公司賺了最多錢。
因此考核的第一步，不是開始設計 KPI 及 OKR 要有什麼內容，而是攤開公司的成本結構，從毛利率下手，想辦法把利潤與所有公司所有的同仁綁在一起。
毛利率 = 銷售營收 - 銷售成本
工程團隊如何與利潤掛鉤？
這問題端看公司如何待開發團隊，開發部門隸屬於成本中心，還是利潤中心。成本中心是花錢的單位，自然無法與利潤掛鉤。
因此回到上述所說，公司的組織結構其實有一部分決定了績效考核的目的與方式，兩者需相輔相成才是有意義的績效管理。
當工程團隊與利潤掛鉤後，組織上的變化是有趣的，你會發現工程師平常最愛講的測試覆蓋率跟重構已經沒有意義，因為這兩件事與利益沒關係。取得代之的是大家會開始量化重構後的效益，而不是注重在重構這件事上。
Business Model Canvas
這是 TGONext 的最後一場聚會，我們討論了商業的本質。
商業的本質說穿了就是公司靠什麼賺錢，我們使用 Business Model Canvas 這方法來檢視商業策略，但可惜的是，會議的上禮拜瘋狂加班，僅能聽其他與會者提出他們畫好的 Canvas 做討論。
延伸問題
1. 商業模式與技術債該如何做平衡
任何事都有大前提，商業模式的大前提就是先讓公司存活。
一個極端的案例：在有限的時間內，就算技術債債臺高築、後人維護痛苦得要死，但至少產品持續有人買單，公司能存活就是大家的勝利。
只有在公司能存活的前提下所討論的技術債才是有意義的。
2. PM 如何要求 RD 寫文件
PM 不懂技術，就算要求 RD 寫文件也不會受到尊重。但可以塑造團隊的共同敵人，例如找顧問或技術大神，跟團隊說一切都是顧問要求的，吸引成員的砲火。
擁有共同敵人的革命情懷，雖然 RD 們文件寫的不甘願，但也達到 PM 的目的。
總結
從二月的開幕式至今也近半年，在溝通、管理以及商業模式這三大面向都做了很不錯的討論。尤其是導師也是業界知名的高階主管，藉由這幾場聚會其實解決了公司上遇到的許多疑難雜症。
另一個更重要的一點是，參與這幾場活動的人都是你的人脈啊！ 平時要去哪裡認識這麼多高階主管，就算不是帶著問題而來，日後想換去新的公司你也有更多人可以聯絡。