好读 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为黄金比例来做，一点一点补起来。
不可顺便做的顺便做的重构就会用上面的那些角度切入，排入正式计划。
其他还没有重构到的，没关系，我们可以等待下次的时机。
心得
回想起过去提出测试和重构，理由是“这样我们比较好写程式”，这只是主要是
为自己的方便，不见得其他人也方便，也可能会造成他人的麻烦。
我所作的，只是把其他的人顾虑的点纳进来，从中找出一条生存之道，
能达到我想要达到的事。其他还没做到的事，就要等到天时地利人和都俱足时，
再去进行就好。
剩下的时间就悠哉过我的小生活就好，人生不是只有工作嘛！