30 天 redesign 心目中的 LINE 的章節已經結束囉，有興趣的話可以點此看看總回顧，現在開始進入番外篇，分享從事軟體業的經驗與體悟～

在這留在公司加班等測試的此刻，似乎很適合編輯鐵人賽的文章呢。

延續前兩天的話題，今天來聊，在了解工程師特質後，如何將這些理解帶到真實世界，提供相對應的安排與協助～

首先，我覺得自己很幸運的地方是，所接觸的工程師年資幅度之大，從 0 年(剛畢業) ~ 20 年以上都有，所以算是有很豐富的素材可以觀察與學習。

這邊先分享一個心得是，以我自己的了解，工程師的年資、開發能力與管理能力，沒有絕對的正向或負向關係，而與個人的個性特質及工作動機比較有關係～

當然不是每個人都生來會管理、帶人，這些都是需要學習的。但是有些工程師，至少，我遇到幾個厲害的工程師大大，如果可以選擇～他們會比較喜歡單打獨鬥。這不是說他們排斥團隊合作哦，如果新人遇到問題，去請教對方的話，基本都還是很願意回答。只是就比較沒辦法不擅長手把手帶領（守護者除外）。

再舉例來說，如果今天要衝短期交付且不能 delay 的新功能，一般就會安排有數十倍戰鬥力的戰士去處理。

其實我們都明白開發很難沒有 bug，只是如何減少。那在快速交付（基本上是每週交付）、且系統越來越龐大的過程中，其實會累積很多技術債，有些技術債很可怕的地方在於，bug 會出現在你萬萬想不到的地方，而當那個地方是服務主流程，就很可怕了@@

這裡可以舉一個情境題。像這樣專案人手不足，小 bug 滿天飛（我們也被電得滿天飛...）、除了需求規格書規範的項目，還會有其他介接相關的服務需要處理的情況下。

如果是你，會怎麼做？或是～會希望 PM 怎麼做呢？

• 要求戰士重構程式碼？
• 忽略技術債？
• 還是直接讓其他工程師接手處理？

Image Credit: Unsplash

如果是我，在開始解題前，會先釐清...

• 當下的目標是什麼？
• 當前目標是優化，還是交付？
• 我們是否清楚客戶期待值在哪裡？
• 哪些屬於一定要先完成的主流程，哪些是可以後續再持續優化的流程？

再去思考...

• 身為 PM，當 bug 已經不可控，這樣的交付還是交付嗎？
• 而又如果，讓一天產值高於其他工程師數十倍的戰士花時間重構，有符合成本效益嗎？
• 這時如果直接安排其他工程師接手，會不會讓戰士有不舒服的感覺？
• 話說，真的多的人手可以協助處理嗎？

當時的案子還有弓箭手、傳道士與守護者在這個案子。先回顧一下......

1. 守護者：技術強，適合擔任團隊的技術專家（在此案例資歷最深，與戰士同樣有高產值的表現）
2. 傳道士：溝通強，性格及開發品質皆穩定（在此案例資歷較年輕）
3. 弓箭手：態度正、重思考（在此案例資歷較傳道士輕一些些）

我們當時的做法是...在不影響原有交付項目為前提...

1. 安排弓箭手先發展技術服務相關工具，在工具出來前，由戰士與傳道士做掩護、由他們消耗外來的服務需求
2. 待工具發展完成，由傳道士與戰士溝通，了解戰士原有的邏輯，再由傳道士設計並進行重構。傳道士重構時，換由戰士與弓箭手掩護
3. 最後... 當然就是好的結果啦！詳細也可回顧前面的文章為什麼優化工作流程，不只可以改善工作效率、還能做出更有價值的產品呢？

順帶一提，這也提到資源分配的哲學。那就是，從進度條來看，20 個完成度 65% 的待完成事項（功能繁複但還無法讓 end-user 使用），比不上 5 個完成度 80% 以上的項目（功能精簡但運作正常）

所以我們的做法，就是視情況集中火力、再偶爾各個擊破、分頭進行。

PS 感謝我的好導師，也就是我們的團隊守護者。總放手讓我嘗試，但又能在需要的時候，在團隊面前表達支持、並給予非常實用的建議，真的非常感謝：）

PPS 上述，不代表至此之後我們的專案就沒有 bug 哦（I hate 測試），只是透過種種方式，有效降低同仁 23% 工作量、以及讓曾經的主流程 bug 消失不見罷了 :D

今天就到這裡囉，謝謝你的瀏覽～這次的鐵人賽剩下明天最後 1 天！很開心這段時間有大家的陪伴。如果有任何指點與建議，也歡迎留言交流哦～～

我們明天見：）