好讀 Medium 版：https://tinyurl.com/y6o59mx6
前陣子有幾個同事離職，參加了幾場歡送會，因為老闆不在場，同事們不免俗地
討論起在工作中的甘苦談，抒發一下情緒。抒發情緒是好的，好讓我們把情緒說
出來，獲得同儕的認同感，明天可以打起精神面對接下來的工作。
原本我只是想趁機去吃吃喝喝，不過談的話題讓我有些感觸。像是老闆的決策讓
他們很難作事。或是自己提出重要的對公司好的改變，沒有被接受。或是產品各
版本開發流程常常出現狀況之類的。
我有感觸的是在我過去工作的歷程，我也和他們一樣在其中會有些疑惑和抱怨，
我回想起當時我的感覺和現在的差異，用一句話形容，應該就是「視野不同」吧。
工程師的視野
在以前當工程師，面對的只是需求、眼前的螢幕、文件和Stackoverflow，我不
知道需求怎麼來的，只知道需求很奇怪，時程很奇怪，做出來的功能也很奇怪，
不免會抱怨一番。現在回想起來，是因為當時我的世界太單純了，
能忠實反應我寫的bug的編譯器、書本裡Best Practice和Stackoverflow的解決方案，
只要不合於我世界中的正確答案，我都標上「奇怪」二字，並提出如何解決這個奇怪，
來符合我腦中的正確答案。
當時的我認為這才是對的，而主管應該要回應我，然後改變現況。但是事與願違。
當時帶我的資深工程師說「我知道你提的東西很難做到，但又不想一直在潑你冷水」，
我不懂什麼叫很難做到，我當時只知道你們是不想做。
PM的視野
我在當PM的時候，著重在如何讓我們產品貼近用戶族群習慣，因為是在外國工作，
台灣的習慣和當地的很不一樣，像是金流就需求大調整，行銷的手法也和台灣不一樣，
首先就先打通當地金流，那麼我提出一套建立在現有金流機制上最基本的變更，
來符合當地習慣。（當然這是我當初自認為的最基本）不過也沒有被接受，
反應是變動太大，不可能進行。當時我也不懂什麼叫很難做到，我當時只知道
你們是不想做。
技術總監的視野
當技術總監和之前的經驗很不一樣，老闆會開始和你聊營收、成本，我可以明顯
的感受到以前沒感受過的壓力。我仍然知道正確答案該怎麼做，假設要花六個月
才能完成一個會賺錢的功能，但是公司資金只能撐五個月，那麼該怎麼辦？
當然最直接的就是叫老闆去生錢出來，不過技術總監就是該在現有的資源下要
產出最大效益的東西來，所以我就必須把六個月的功能拆成四個月可以完成，
有些功能放到後面去做，有些功能先作一半，程式髒一點、醜一點沒關係。
當我把規格定出來後，感覺一股熟悉感，啊幹這不是我以前我覺得奇怪需求和
奇怪時程的味道嗎？
不過我有做了幾件和以前主管做不一樣的事情：
1. 偷渡一項工程師對系統想要優化的改變。
2. 和老闆討論這個功能做完上線後維運期我們要作一些體質調整的事。
3. 老實說明公司的狀況和做這個決定的來龍去脈
尤其是第三點，以前的主管可能沒有耐心說明這個需求整個故事背景，然後只給
工程師片段的資訊，然後工程師就拿著片段的資訊去猜公司到底在想什麼，
然後日積月累造成極大的徧差。
提出改變建議不被接受
聽著同事在聚餐中的分享，回想到我以前我會抱怨只是因為我的想法沒有被接受，
但是我也沒有接受老闆的想法，只是屈服罷了。不過我們經驗不同，視野也不同，
想要解決事情的重要順序一樣也會不同。以前的我只是提出問題，想要對方可以
解決我的問題，但是同樣的老闆也提出他的問題。我不斷用不同的角度去切入，
凸顯我的問題的重要性，老闆也同樣用其他角度切入來凸顯他的問題。
那麼我們只是在申明自己立場而已，並沒有溝通。
設身處地想成本的事才能找出好解法
我在想要做的改變時，我都會想著：這間公司一個月成本支出要XXX萬，要養XX個員工。
那麼我提出的做法會不會給這間公司造成很大的負擔？
有人可能會說這是老闆要擔心的事情，為什麼我們要想這個。
沒錯，實際負擔起公司的是老闆，那些成本也是不從我口袋支出。不過如果我要
讓事情能順利進行，我就不應該提一個等同於蓋世界奇觀的計劃。當我想著成本
支出的事情時，我就會刻意的把規模縮小，讓人力和時程有辦法應付日常營運和
開發，又不會增加太多成本並把計劃排個優先順序，先瞄準痛點，就會讓所有人
都有感。
從無到有建置一個專案不難，但是在現有專案中，在人力、時間、成本、效益找到
最平衡的做法，才是真正考驗工程師的功力。
以前的我，只是在意我的意見有沒有被接受，我有沒有被認同，最核心的點是自己
無法認同自己的價值，才會追求別人的認同。現在的我是知道自己的能力和能耐，
認同自己是一個很不錯的人，於是就不會把別人的認同看得那麼重，我才能專注在
「如何把事情做好」。
看到這邊如果你也有些感觸的話，不妨也問問自己「我有認同我自己嗎？」
以推行寫測試為例
今年我在公司推行測試計劃和程式的重構。由於過往PM們有不好的經驗，所以一
開始就受到阻礙。
我就從自己做起，估的時程和以往一樣，並不會因為寫測試而增加時間，
並為內部寫下Unit Test & Feature Test文件和實際案例。然後開內部講座
指導工程師如何寫測試，並說明和PM回報預估時程不能加上測試，只是把原本自己
做的人工測試，把重要的改為自動測試。反覆人工測試的時間，拿來寫自動測試
其實很划算。
五月份的時候每週分享測試心得和自己寫的案例，到九月份的時候每個人的專案
都已經有基本的測試了。
在這個過程中，我也和老闆說明測試的重要性，每一點都直擊痛點。
1. 人員流動接手專案比較不容易改A壞B，負責專案的工程師請長假也不用太擔心
2. 測試所需程式的結構會順便統一，人員流動接手專案上手會變快
3. 接大型案子難度降低
然後在下半年的考核標準加上寫測試這一項。這過程中PM感覺不到時程因測試而
變胖，專案也開始可以在內部輪調了，每個案子至少有兩人接觸過，人員調度
也變輕鬆了。
以推行程式重構為例
我接手 SurveyCake 後端的專案，過去曾經有重構一部份，仍然留下許多legacy code，
剛好這次後端開發時程超前，於是我們可以做重構的事情。我是這樣做的。
我去訪問了各部門，最常找後端工程師協助的事是什麼事，大概一個月會有幾次，
一次平均會花多少時間。一問之下發現一個月會讓一個工程師有4-6個人天在處理
某件雜事。就叫它A功能好了，假設一個人的一天成本是N元，工程師耗的是6N，
PM、業務、客服三人所耗的心力不同，粗估一個月2N好了，也就是A功能讓公司
一個月要支出8N的成本在上面。
光這樣提出來，大家就有「嗯嗯，是應該要處理了」的感覺，所以我推這個功能
的重構沒有任何阻力。
再來是最近老闆想要減少測試所花的人力，所以我們嗅到好機會，提出
Test Covarage改善計劃，首先第一步就是把還沒有辦法寫測試的項目，
都改為可以寫測試的結構，主要是進Laravel框架。
剛好前陣子有銀行業找上門，他們的規範是資料要留在台灣，那麼就使用GCP建置，
但我們原本的程式很多都是直接串AWS，但是只要進Laravel框架，我們就很好擴展
成AWS & GCP雙棲。所以提出重構的第一波計劃就瞄準了痛點：
1. 為了測試而調整，減少內部QA時程，開發週期縮短
2. 讓A功能一個用8N的成本降低50%以上
3. 可很好擴展到GCP上，業務更好賣
對於內部工程師，也說明了重構可分「可以順便做的」和「不可順便做的」，
可以順便做的我們在開發時就順便做，但不需要太完整，有時候太完整會把擴展性
變很低，大概70%整理過，30%Legacy為黃金比例來做，一點一點補起來。
不可順便做的順便做的重構就會用上面的那些角度切入，排入正式計劃。
其他還沒有重構到的，沒關係，我們可以等待下次的時機。
心得
回想起過去提出測試和重構，理由是「這樣我們比較好寫程式」，這只是主要是
為自己的方便，不見得其他人也方便，也可能會造成他人的麻煩。
我所作的，只是把其他的人顧慮的點納進來，從中找出一條生存之道，
能達到我想要達到的事。其他還沒做到的事，就要等到天時地利人和都俱足時，
再去進行就好。
剩下的時間就悠哉過我的小生活就好，人生不是只有工作嘛！