養成技術提案的能力

Goran Bogicevic via Shutterstock
如果在學習知識的過程中,撰寫blog文章是內化外顯知識的核心,那麼技術提案,也就是proposal,我認為是自我學習跟在公司內創造價值中間的橋樑,也是讓知識落地、務實、導入的起點。

最近挺多工程師詢問到,要成為一位tech leader該具備哪些技能,該怎麼樣培養自己的能力呢?

這問題當然是個大哉問,也沒有所謂的正確解答。但我總會建議他們:「要讓自己往tech leader前進,你應該要養成提供技術提案的能力。並透過這個方式,不斷鍛鍊自己。」

如果在學習知識的過程中,撰寫blog文章是內化外顯知識的核心,那麼技術提案,也就是proposal,我認為是自我學習跟在公司內創造價值中間的橋樑,也是讓知識落地、務實、導入的起點。

向外取經

公司內部軟體開發,往往會慢慢趨向於穩定,因為穩定可以降低學習成本、減少風險,基於不變的情況下提昇效率(效率不等於效果)。

然而,如果工程師的學習來源僅限於公司內部,那公司與個人的進步,就會停滯不前了。這也是常被稱為「活在自己井裡」、「一年的經驗重複N次」的情況。要帶領公司跟團隊前進,tech leader得不斷補充活水,向外取經學習,才能引入變革。

向外取經的渠道包含以下幾種。

1. 參加社群活動

社群活動往往是主題內聚含量極高的活動,不一定只能從主講人身上學到東西,很多時候從與會人員身上也可以挖到不少難能可貴的經驗來借鏡。另外,不論技術好壞,這群參與者肯定都有一定的技術熱情與學習心。建立這樣的connection不論對自己或是公司,都可以有所幫助。

  • 正確的姿勢是:多跟台上台下的人進行「雙向交流」,不要怕丟臉,分享自己的經驗跟想法,不懂的人可以從你身上學到東西,比你懂的人,會樂於給你一些補充跟回饋,兩種都很有價值。

2. 參加研討會

研討會的議題通常與潮流和技術趨勢比較相關,想要聽到新的應用、工具、框架,研討會也不失為一種方式。但我個人認為,研討會因為形式往往是演講跟演示,較少互動(除非有Open Space或講師面對面的安排),就不容易深入主題,只能當作開視野、聽新知的機會。

  • 正確的姿勢是:把握任何機會,不要臉地纏著講師進行請教與交流。前提是,你應該準備好你的問題,講清楚你的context,讓對方知道你是有準備的,有交流跟學習的態度。

3. 參加培訓

根據經驗,自費的效果往往比公司補助來得有效許多,不論是動機、熱情、預習/練習/複習,都特別有效果。參加培訓,一定是對某個主題領域有興趣,或是實務上碰到一些問題,也就是一定能帶著目的性去。

  • 正確的姿勢是:帶著實務上的問題與需求前去,很清楚知道自己上課的目的,想要學到的東西或解決的問題,想清楚自己的context跟實務限制,在發問時這是必備的功課,增進講師回答的效率跟質量。正所謂模糊的提問,只會得到模糊的答案。

4. 邀請教練

如果公司有請外部的顧問或技術教練,盡可能增加跟教練一起貼身肉搏的機會,那種只出一張嘴的顧問跟教練,就不太需要跟他浪費時間。真正的技術教練是要能跟你一起進行實務的任務,貼身肉搏,拳拳到肉。

  • 正確的姿勢是:盡可能增加跟教練一起在實務上貼身肉搏,不是只請教練示範,教練再厲害也只是他厲害,技術是教不來的,自己學來的,搭配大量練習,持續觀察跟校正,才會特別有效。此外,不要只是關注在外顯的技巧,而要更深入去瞭解教練解決問題的思路脈絡,是如何定義問題,如何嘗試,如何觀察到變化跟著進行調整,如何找到解決方案,以及詢問他,在該領域有哪些學習資源,以及依據你的情況他所建議的學習方式跟資源。

5. 有效閱讀

書跟文章是看不完的,因為書跟文章的產生速度遠高於你的閱讀、理解、消化速度,而且品質不好的內容,可能導致沒有分辨能力的人理解錯誤,有分辨能力的人則是浪費時間。所以書該怎麼挑,書該怎麼看,我提供一些個人的經驗:

  1. 加入該主題相關的社群、活動:例如從線上的社群交流與活動,能瞭解哪一些人是特別有熱情的,哪一些人是該領域的專家,他們常在論壇、社群/社團中發聲,不管是推薦學習資源、分享新知、拋出開放性的問題引發討論,或是針對別人的疑問提供見解。可以嘗試著從別人的討論串開始嘗試一些互動。

  2. 請教社群提供學習的建議:描述清楚你的context,例如你的學習目的、你目前在該領域的熟悉程度,已經自己看過學習過哪些東西,以及你打算在哪運用。請大家依據你的context提供適合的學習資源與方式給你。不要輕忽了描述你context的重要性,因為學習都是由淺入深的,每個人狀態不同,自然推薦給他的學習建議就該不一樣,才會有效。由這些社群專家跟先驅者來幫你過濾、篩選、推薦,可以節省你走很多冤枉路的時間跟成本,因為在這個資訊爆炸的時代,應該先花時間在高品質的內容中。

有了社群幫忙推薦跟過濾後的切入點,接著就該進行點、線、面的學習。

如果是有品質的文章,通常文章中或blog上,會額外推薦一些相關文章或網站的連結。如果這篇文章品質是好的,往往它所推薦的其他資源也都是寫得不錯的,記得往外延伸挖寶,通常寶藏都是在這過程中發現的。

如果是書籍,我建議你可以到Amazon上搜尋一下,買了該書的人,同時還買了哪些書或對哪些書有興趣。該作者除了這本書以外,還有出哪幾本書。該作者除了自己的書以外,還幫哪些書寫過推薦序。

我自己看書的方式,先從社群的專家依據我的context推薦值得學習的經典書開始,我會同時把該領域評價不錯的書都一併買下來,我看書向來不死守著「一本書看完才換下一本」的規矩。原因是:

  1. 如果我買的書品質都是很不錯的,通常書的脈絡跟組織,都是由淺入深的。當我看第一本書到某個主題卡住時,我會先努力試著理解,尋找相關資源,如果無法突破,我就會跳過這本書,改看該領域別本書。當看某本書卡住看不懂時,有可能是作者跟你的context不一樣或差異很大,所以他說明的方式、舉個例子,你沒有感覺,不容易理解。也有可能是因為你少了某些前置知識點,所以知識銜接不起來。

  2. 這時改看同領域別本經典書,前面你已經知道的部分,通常可以看很快,而把精力花在你不知道的部分。有可能因為別本書而補足了你的前置知識點,而且換個作者來解釋概念,就像另外一個老師換另外的例子與方式來跟你解說同一個觀念,要突破知識瓶頸往往就會容易一些。

取經完,Then?

不論參加了幾場社群活動、研討會、培訓活動,看了多少文章或幾本書,重點在於:然後呢?很多人就沒有然後了。

你有看過光看食譜,就能當上餐廳主廚的嗎?看了 50 本程式設計的書,沒有動手寫,仍然不會理解寫程式會碰到哪些問題。

很多人取經完之後,都以為自己多學到了一些知識,事實上這只是喝了心靈雞湯之後的飽足感罷了。其實聽的時候好棒棒,聽完當下嗨了一下,接著大腦過一陣子就代謝掉這段記憶了。

也有些人取經之後,回到公司跟團隊,參考活動的簡報、講義,依樣畫葫蘆的分享給其他人,其實只是拾人牙慧,為了交代而分享,並不足以構成價值跟促使變化。

取經之後的重點在於反思,反思的重點在於建立知識連結。如何把新的外部刺激,與原本的知識體系建立連結,進而透過行動來引起一些變化,而且這些變化的目的是為了創造價值。

那麼該反思哪些東西呢?

新的解決方案所存在的意義?

解決方案包括了方法論、工具、框架跟某類模式,而這些東西之所以存在或是受到注目,通常都是因為它的本質可以幫助解決某一類型的問題,在某些限制、前提、環境下,它解決問題的方式比較優雅。例如:學習門檻比較低、可讀性與維護性比較好、效能比較快、生產力比較高等等…

需求或問題的存在是中性的,推陳出新的解決方案往往是針對某個特定問題與應用來最佳化。當我們關注這個新的解決方案,要避免只是為了潮、為了新,而是該回顧它存在的本質,是為了解決什麼樣的問題,滿足什麼樣的需求。

而我們的公司、產品、團隊、流程,目前是否存在著這樣的問題?未來會不會發生這樣的問題?這才是引入活水關鍵的起手式,如果沒有價值導向,那所有的變革都是徒增成本跟困擾。

我們現在是怎麼做的?

如果我們現在也面臨這樣的問題,或是可見的未來也可能會發生這樣的問題,那麼自己試著回答下列問題:

  • 我們現在是怎麼做的?
  • 付出的代價是什麼?
  • 達到的效益如何?
  • 是否已符合我們的期待?我們的期待為何?

先定義問題,才能解決問題。確認期望,才能評估是否有效。

比較方案

同樣的需求與問題,除了新引入的解決方案以及我們現行的作法外,這個世界還有哪一些方式可以解決這類的問題呢?

  • 調研一下這個問題或需求,有哪些其他的解決方案
  • 各自的優缺點與適用場景
  • 動手設計一些範例、雛形,進行概念驗證(POC)

建議方案

基於我們公司、團隊、產品、環境、流程、組織與文化等等,建議採用哪一個方案,並說明為什麼?應包含預計需付出的成本、風險、影響範圍、帶來的效益、需要的時間、前置作業以及必要條件。

引入變革的行動規劃

如果要開始試用與導入,可以從哪邊開始?為什麼?

規劃應包含:

  • 先從哪一個專案、團隊或功能比較合適?為什麼?
  • 預計何時開始?需要多久?檢核點的日期?
  • 哪些人合適當首批引入與配合變革的人?
  • 如何評估效益?
  • 如何制訂政策來鼓勵加入變革的同仁?
  • 你需要什麼樣的support跟resource?

結論

Tech leader與一般senior engineer之間一個最大的差異是:影響力。

Tech leader得站在公司產品的角度、考量團隊與限制,不斷提昇團隊技能、生產力與產品品質,不一味追求高大上或潮流,而是務實與通盤考量的進行思考、學習、分析、整理、練習,確認價值與可行性,從選擇中挑一個最適當解決方案,迭代式地頻繁進行行動、觀察、調整。

這是tech leader自己一個很重要的學習模型,也是產品與團隊需要的幫助,也是公司所需要的專業價值。這一整串的過程,是鍛鍊自己內外軟硬技能很好的方式,不管最後是成功或失敗了,自己身上累積的能力經驗不會消失,而公司也需要在風險可控的情況下,嘗試一些DNA的突破,才能獲得本質性的提昇。

我自己很認同Modern Agile所推崇的那四點,這四點就是本文所提的技術提案與引入變革所需的基石:

  • Make people awesome
  • Make safety a prerequisite
  • Experiment & learn rapidly
  • Deliver value continuously
91

本文由陳仕傑授權轉載自in 91

《數位時代》長期徵稿,針對時事科技議題,需要您的獨特觀點,歡迎各類專業人士來稿一起交流。投稿請寄edit@bnext.com.tw,文長至少800字,請附上個人100字內簡介,文章若採用將經編輯潤飾,如需改標會與您討論。

(觀點文章呈現多元意見,不代表《數位時代》的立場。)

陳仕傑

我是Joey,大家都叫我91,是TDD的狂熱者,將敏捷精神融入到自己的生活與人生。目前在 Odd-e擔任敏捷教練,主要負責台灣的所有業務。曾任JCConf,PhpConf,WebConf與Agile Tour Taipei&Hsinchu等研討會講師,也活躍於兩岸的敏捷及技術社群,熱愛寫作,是位技術部落客,技術專欄作家,也身兼技術書籍的作者與譯者。

追蹤我們