<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:media="http://search.yahoo.com/mrss/">
  <channel>
    <title>新技術｜林鼎淵 Dean Lin</title>
    <link>https://deanlin.net/tags/%E6%96%B0%E6%8A%80%E8%A1%93/</link>
    <image><url>https://deanlin.net/images/author_hu_aa256fc934e9a932.jpg</url><title>新技術｜林鼎淵 Dean Lin</title><link>https://deanlin.net/tags/%E6%96%B0%E6%8A%80%E8%A1%93/</link><width>144</width><height>144</height></image>
    <description>林鼎淵（Dean Lin）的部落格：生成式 AI 企業內訓講師、外商資安公司軟體專家、7 本書作者。400 多篇文章用白話分享生成式 AI 實戰、Claude Code 與 Vibe Coding 教學、團隊合作與職場成長。</description>
    <generator>Hugo</generator>
    <language>zh-tw</language>
    <copyright>© 2020–2026 林鼎淵 Dean Lin</copyright>
    <lastBuildDate>Mon, 05 Sep 2022 10:07:20 +0800</lastBuildDate>
    <atom:link href="https://deanlin.net/tags/%E6%96%B0%E6%8A%80%E8%A1%93/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>工程師：「為什麼在公司推新技術這麼困難？」（下）</title>
      <link>https://deanlin.net/blog/202209/pushing-new-tech-at-work-2/</link>
      <pubDate>Mon, 05 Sep 2022 10:07:20 +0800</pubDate>
      <guid>https://deanlin.net/blog/202209/pushing-new-tech-at-work-2/</guid>
      <dc:creator>林鼎淵</dc:creator>
      <category>團隊合作</category>
      <description>在上篇文章中，我們分析技術主管會顧慮的點。</description>
      <media:content url="https://deanlin.net/blog/202209/pushing-new-tech-at-work-2/images/cover_hu_fbf4d1903afe2051.jpg" medium="image" type="image/jpeg" width="1200" height="675" />
      <content:encoded><![CDATA[<p><a href="https://deanlin.net/blog/202208/pushing-new-tech-at-work-1/">在上篇文章中</a>，我們分析技術主管會顧慮的點。</p>
<p>的確，導入新技術這件事，無論對團隊還是公司都是一種風險；但現在技術更新的速度遠超過去任何一個時代，如果專案總是用自己熟悉的技術開發，那未來可能就要面對被時代淘汰的風險。</p>
<blockquote>
<p>想當年 Flash 有多紅，結果才過沒幾年就成為了時代的眼淚。（應該還有人記得這門技術吧？）</p>
</blockquote>
<p>醜話說在前面，即使按照文章的建議執行，公司也未必會採納你所提出的新技術；但經過這些步驟，你肯定對新技術有更高的掌握度，未來跳槽時也有更多的選擇。</p>
<h2 id="確認自己有能力駕馭這個新技術"><strong>▋確認自己有能力駕馭這個新技術</strong><a class="h-anchor" href="#%e7%a2%ba%e8%aa%8d%e8%87%aa%e5%b7%b1%e6%9c%89%e8%83%bd%e5%8a%9b%e9%a7%95%e9%a6%ad%e9%80%99%e5%80%8b%e6%96%b0%e6%8a%80%e8%a1%93" aria-label="這個段落的連結"></a></h2>
<p>千萬不要把公司的專案當成白老鼠！</p>
<p>筆者知道有些人是以「練功」的角度來建議公司導入新技術的，本身對技術的認知也僅限於官方文檔的介紹、技術社群的評價，有時自己連一份 Side Project 都沒有做過。</p>
<p>因此建議在推薦新技術前，至少要先做一份 Side Project，並且涵蓋的內容最好包含：</p>
<ul>
<li><strong>這個新技術能解決過去專案的哪些痛點</strong>：以網站來舉例，如果你導入這個技術是為了解決過去系統遇到大流量會當機的問題，那就需要提供相關的測試數據。</li>
<li><strong>確保新技術能完成過去專案的功能</strong>：很多時候我們只注意到新技術能解決的問題，卻沒有去驗證它是否也能完成過去原有的功能。</li>
</ul>
<blockquote>
<p>如果想導入的技術需要額外的費用，那最好做一份簡單易懂的報告。</p>
<p>比如過去商城在舉辦限時搶購活動時，短時間的大流量常常導致系統不穩定甚至當機，這造成原本會下單的潛在客戶流失；如果能列出提升系統穩定度要「花多少錢」以及「預計提升下單數」的比率，領導就更能明白這些錢具體的效益在哪裡。</p>
</blockquote>
<h2 id="先用分享會試試水溫"><strong>▋先用分享會試試水溫</strong><a class="h-anchor" href="#%e5%85%88%e7%94%a8%e5%88%86%e4%ba%ab%e6%9c%83%e8%a9%a6%e8%a9%a6%e6%b0%b4%e6%ba%ab" aria-label="這個段落的連結"></a></h2>
<p>不是每間公司都會開技術分享會，但每間公司一定都有「開會」。</p>
<p>你可以先跟主管說自己最近學了一個新技術，並簡述它的優點；然後再提出自己想透過一個簡短的分享會（15~30 min）跟同事介紹它。</p>
<p>如果當下沒有緊急的專案，大部分主管是很樂意看到成員間彼此交流技術、共同成長的；在這種分享會的形式下，大家也能放下戒心地去「認識」新技術，如果能引起其他工程師的興趣，你就有機會在公司建立盟友。</p>
<blockquote>
<p>盡量不要以「導入新技術」的角度來分享，因為這樣台下的人會用挑惕的眼光來審視這個技術，一下子就把所有同事拉到了對立面。</p>
</blockquote>
<h2 id="前提是技術主管願意學習"><strong>▋前提是技術主管願意學習</strong><a class="h-anchor" href="#%e5%89%8d%e6%8f%90%e6%98%af%e6%8a%80%e8%a1%93%e4%b8%bb%e7%ae%a1%e9%a1%98%e6%84%8f%e5%ad%b8%e7%bf%92" aria-label="這個段落的連結"></a></h2>
<p>如果團隊中的技術主管對新技術不感興趣，那就很難推的動了；因為以技術主管的角度來說，他是不會冒險導入一個自己不理解的技術。</p>
<p>如果想讓新技術成功導入，那技術主管是一個非常重要的突破口，如果他願意學習，並透過實作了解這個技術的價值；在評估完各方面的可行性後，這個技術被導入的機率會大幅上升。</p>
<h2 id="筆者觀點"><strong>▋筆者觀點</strong><a class="h-anchor" href="#%e7%ad%86%e8%80%85%e8%a7%80%e9%bb%9e" aria-label="這個段落的連結"></a></h2>
<p>在公司推新技術也是宣傳自己的一種方式，如果公司因為你引進的技術而獲得利益（ex：開源節流、提升效率），那這份履歷無論在內部晉升，亦或是未來找工作都是非常棒的談判資本。</p>
<p>假使你想導入新技術，是因為公司所使用的技術過於老舊，如果繼續用下去可能會對自己的職涯發展有影響；但在導入的過程中受到保守派的強烈反對，那筆者認為換一間公司未嘗不是個選擇。</p>
<p>人生是自己的，未必要選擇最艱難的道路拓荒，在合適的環境中，成長才會更加快速。</p>
<blockquote>
<p>轉職一定要經過謹慎評估，筆者僅是提出個人觀點。</p>
</blockquote>
]]></content:encoded>
    </item>
    <item>
      <title>工程師：「為什麼在公司推新技術這麼困難？」（上）</title>
      <link>https://deanlin.net/blog/202208/pushing-new-tech-at-work-1/</link>
      <pubDate>Wed, 31 Aug 2022 10:10:00 +0800</pubDate>
      <guid>https://deanlin.net/blog/202208/pushing-new-tech-at-work-1/</guid>
      <dc:creator>林鼎淵</dc:creator>
      <category>團隊合作</category>
      <description>不過學到新技術，跟把新技術應用到專案是兩件事；在這篇文章中，筆者會分析導入新技術前，技術主管會顧慮的點有哪些。</description>
      <media:content url="https://deanlin.net/blog/202208/pushing-new-tech-at-work-1/images/cover_hu_c310d06eaa602887.jpg" medium="image" type="image/jpeg" width="1200" height="675" />
      <content:encoded><![CDATA[<p>應該絕大多數的公司都希望員工自學新技術。</p>
<p>不過學到新技術，跟把新技術應用到專案是兩件事；在這篇文章中，筆者會分析導入新技術前，技術主管會顧慮的點有哪些。</p>
<p>在文章的開頭我們先把新技術分為兩種：</p>
<ol>
<li><strong>在原有的基礎上擴充：</strong> 為了提升效能、解決問題而擴充的「套件」。</li>
<li><strong>直接取代原有技術：</strong> 想導入新的「框架、程式語言、資料庫」。</li>
</ol>
<p>通常第一點的技術導入，團隊都是樂於接受的；所以這裡我們主要討論「直接取代原有技術」會遇到的障礙。</p>
<h2 id="團隊中有多少人接觸過這個技術"><strong>▋團隊中有多少人接觸過這個技術？</strong><a class="h-anchor" href="#%e5%9c%98%e9%9a%8a%e4%b8%ad%e6%9c%89%e5%a4%9a%e5%b0%91%e4%ba%ba%e6%8e%a5%e8%a7%b8%e9%81%8e%e9%80%99%e5%80%8b%e6%8a%80%e8%a1%93" aria-label="這個段落的連結"></a></h2>
<p>如果團隊中只有少數人，甚至只有一位工程師接觸過這門技術；那技術主管通常都會否決掉這個提議，先不論這個新技術有多少優勢，光是讓大家學會這門新技術就是不小的時間成本。</p>
<p>而且可以預見推行新技術時會遇到很多阻力，因為大多數人都不願意放下深耕多年的技術。</p>
<h2 id="導入這個新技術會不會出事"><strong>▋導入這個新技術會不會出事？</strong><a class="h-anchor" href="#%e5%b0%8e%e5%85%a5%e9%80%99%e5%80%8b%e6%96%b0%e6%8a%80%e8%a1%93%e6%9c%83%e4%b8%8d%e6%9c%83%e5%87%ba%e4%ba%8b" aria-label="這個段落的連結"></a></h2>
<p>我們不能只看新技術的優勢，還要看它的成熟度，以及實際使用者的數量。</p>
<p>有時我們在參加技術大會時，會被講師介紹的技術所吸引，進而忽略這門技術潛在的風險。</p>
<blockquote>
<p>以筆者來說，過去就曾犯下對新技術不夠了解，卻用它來開發產品的錯誤，這個誤判讓我在後續維護時吃盡苦頭。</p>
</blockquote>
<h2 id="專案爆掉後的備案"><strong>▋專案爆掉後的備案</strong><a class="h-anchor" href="#%e5%b0%88%e6%a1%88%e7%88%86%e6%8e%89%e5%be%8c%e7%9a%84%e5%82%99%e6%a1%88" aria-label="這個段落的連結"></a></h2>
<p>如果專案在開發過程中就發現新技術的總總缺陷，甚至連第一版都無法順利上線，筆者認為這是相對幸運的。</p>
<p>最慘的是專案在上線後才爆掉，如果團隊成員過去沒有解決這些突發狀況的經驗，一但卡住的時間太久，會很難跟公司（甲方）交代。</p>
<p>因此有些公司在導入新技術時，會安排另一組人用熟悉的技術開發，作為出包時的應對方案。</p>
<h2 id="舊專案如何處置"><strong>▋舊專案如何處置？</strong><a class="h-anchor" href="#%e8%88%8a%e5%b0%88%e6%a1%88%e5%a6%82%e4%bd%95%e8%99%95%e7%bd%ae" aria-label="這個段落的連結"></a></h2>
<p>如果公司過去已經開發了數十個專案，接下來可能會遇到以下問題：</p>
<ol>
<li>舊專案要導入新技術嗎？</li>
<li>如果舊專案要改，那需要付出多少時間、人力成本？</li>
<li>如果舊專案不改，那是不是代表公司還是需要有人來維護？</li>
</ol>
<p>除了上面的問題要思考外，另一個現實的問題就是「招募成本」，假使專案導入新的程式語言；那未來找工程師時，是要找同時會兩種語言的人（招募成本高），還是找只會其中一種語言的人（培養週期長）？</p>
<h2 id="大家可以想一想"><strong>▋大家可以想一想</strong><a class="h-anchor" href="#%e5%a4%a7%e5%ae%b6%e5%8f%af%e4%bb%a5%e6%83%b3%e4%b8%80%e6%83%b3" aria-label="這個段落的連結"></a></h2>
<p>上面所列出的顧慮只是冰山一角而已。</p>
<p>如果有朋友想導入新技術卻被打槍，可以想想上面所列出的問題，自己是否都有相應的配套方案。</p>
<p>在了解技術主管顧慮的點後，<a href="https://deanlin.net/blog/202209/pushing-new-tech-at-work-2/">下一篇文章</a>會跟大家分享做「哪些事前準備」，會讓新技術更容易被採納。</p>
]]></content:encoded>
    </item>
  </channel>
</rss>
