[心得] 為什麼我們提出改變，常常不被上層同意？

看板Soft_Job作者 (解夢師Raguhn)時間3年前 (2020/09/12 12:37), 3年前編輯推噓34(37推 3噓 55→)
留言95則, 50人參與, 3年前最新討論串1/1
好讀 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為黃金比例來做，一點一點補起來。 不可順便做的順便做的重構就會用上面的那些角度切入，排入正式計劃。 其他還沒有重構到的，沒關係，我們可以等待下次的時機。 心得 回想起過去提出測試和重構，理由是「這樣我們比較好寫程式」，這只是主要是 為自己的方便，不見得其他人也方便，也可能會造成他人的麻煩。 我所作的，只是把其他的人顧慮的點納進來，從中找出一條生存之道， 能達到我想要達到的事。其他還沒做到的事，就要等到天時地利人和都俱足時， 再去進行就好。 剩下的時間就悠哉過我的小生活就好，人生不是只有工作嘛！ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.164.237.32 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1599885468.A.ED7.html
推
09/12 12:45, 3年前 , 1F
推
09/12 12:45, 1F
推
09/12 13:07, 3年前 , 2F
推推
09/12 13:07, 2F
推
09/12 13:11, 3年前 , 3F
推角色不同，看事情的角度也不同
09/12 13:11, 3F
推
09/12 13:20, 3年前 , 4F
推 溝通很重要
09/12 13:20, 4F
推
09/12 13:29, 3年前 , 5F
推推 好棒
09/12 13:29, 5F
推
09/12 13:49, 3年前 , 6F
推分享
09/12 13:49, 6F
推
09/12 14:08, 3年前 , 7F
推好文
09/12 14:08, 7F
推
09/12 14:16, 3年前 , 8F
推
09/12 14:16, 8F
噓
09/12 14:17, 3年前 , 9F
追求正確做法，可以被你說成眼光狹隘，是自己世界太簡
09/12 14:17, 9F
→
09/12 14:17, 3年前 , 10F
單
09/12 14:17, 10F
→
09/12 14:23, 3年前 , 11F
還是換公司最快，通常這種公司沒在管品質的，能動就好
09/12 14:23, 11F
不同的位置會有不同的視野，我在文中可沒講眼光狹隘吧 我的確也是想著換組織換公司，不過至今還沒換到所謂「正確」的組織和公司 我不需要用我的生命來証明那些公司失敗，我想要讓我想作的事落實而已， 所以我才開始研究如何落實，走到現在我個人感想是比追求正確作法實際多了。 如果用一句話來形容是「考量到現實條件儘可能代入正確作法並落實」
推
09/12 15:26, 3年前 , 12F
最正規/最正確的做法有時候不一定是最佳解啦，有時候還是
09/12 15:26, 12F
→
09/12 15:26, 3年前 , 13F
得在現實條件前妥協，尤其是專案類型的公司。
09/12 15:26, 13F
是的，但同樣有自己產品的公司也會有初期先活下來，然後code亂七八糟， 後來整理會整死人的情況，一樣的是在現在條件下找出目前可以執行的解法
推
09/12 15:32, 3年前 , 14F
推
09/12 15:32, 14F
噓
09/12 15:45, 3年前 , 15F
最近怎麼常有medium的來刷流量
09/12 15:45, 15F
→
09/12 17:38, 3年前 , 16F
專案類型的公司的確是這種 公司都沒什麼話語權更不要
09/12 17:38, 16F
→
09/12 17:38, 3年前 , 17F
說自己 真的好缺十之八九都被人佔走了
09/12 17:38, 17F
推
09/12 18:07, 3年前 , 18F
推
09/12 18:07, 18F
推
09/12 18:20, 3年前 , 19F
做過一陣子類似思路 給推
09/12 18:20, 19F
推
09/12 18:45, 3年前 , 20F
不是 medium 的錯，是 ptt 太難寫文章reddit programming
09/12 18:45, 20F
→
09/12 18:45, 3年前 , 21F
也都是貼文章鏈結
09/12 18:45, 21F
→
09/12 18:46, 3年前 , 22F
難道你要在 ptt 貼 code snippet 嗎?
09/12 18:46, 22F
→
09/12 19:00, 3年前 , 23F
最佳解應該要在歸納需求時就想好最佳需求描述，不然
09/12 19:00, 23F
→
09/12 19:00, 3年前 , 24F
不可能實作出來
09/12 19:00, 24F
理論上是這樣啦，但是業務/PM也是人，也是需要學習的，在成長過程中也是會提出些 不太「正確」的描述法和需求，那麼有沒有人可以協助他們了，沒有的話就是自己出馬 去協助，融合雙方需求定出提需求的規則，就算沒有100%到位 但是從10%提昇到50%，讓雙方都省下些時間，我想很少公司會反對的
→
09/12 19:44, 3年前 , 25F
你貼gitpage上來別人也會說是來騙星星的xd習慣就好
09/12 19:44, 25F
推
09/12 20:26, 3年前 , 26F
有溝通能力的技術人員才有辦法做這件事
09/12 20:26, 26F
→
09/12 20:26, 3年前 , 27F
很多技術本位的人根本懶得去花力氣說服別人
09/12 20:26, 27F
→
09/12 21:36, 3年前 , 28F
當你的同事是比你資深n年且等著退休的人，要推什麼都
09/12 21:36, 28F
→
09/12 21:36, 3年前 , 29F
無法
09/12 21:36, 29F
→
09/12 22:12, 3年前 , 30F
碰到無能主管除了換公司還能怎辦 把他鬥下來嗎
09/12 22:12, 30F
我的心得是作這些事情有沒有在公司推行成功並不是主要目標，而是讓自己培養出能力。 我啊，在之前的公司也是推得很挫折，但因為在那挫折環境下，我研究和嘗試了各種方法 ，累積了知識和一些經驗，換到新環境馬上就派上用場。 而不用等環境准備好，我再來學，我的焦點一直都是自己的成長，那麼主管或資深同事 想不想動就和我想不想動一點關係都沒有。
→
09/12 22:13, 3年前 , 31F
職場沒這麼複雜，主管口中的視野高度
09/12 22:13, 31F
→
09/12 22:14, 3年前 , 32F
講白話就是，不要讓我被上面定
09/12 22:14, 32F
→
09/12 22:22, 3年前 , 33F
我這兩年把好幾十支程式和table都翻掉了，我只跟主
09/12 22:22, 33F
→
09/12 22:22, 3年前 , 34F
管説，不會有異常，BU不會抱怨，就算出問題也有備份
09/12 22:22, 34F
→
09/12 22:24, 3年前 , 35F
主管只跟我説，專案不要delay就好，也沒在擋的
09/12 22:24, 35F
還有 22 則推文
還有 5 段內文
→
09/13 15:49, 3年前 , 58F
別人確實也不會多給一毛錢
09/13 15:49, 58F
推
09/13 19:43, 3年前 , 59F
老闆要給時間啊！老闆只懂你未來一個月沒產出，跳腳說
09/13 19:43, 59F
→
09/13 19:43, 3年前 , 60F
不行，也沒法重構練功啦
09/13 19:43, 60F
推
09/14 00:42, 3年前 , 61F
推魚大
09/14 00:42, 61F
推
09/14 11:12, 3年前 , 62F
推推
09/14 11:12, 62F
推
09/14 12:22, 3年前 , 63F
有分享還是給推, 但寫的很多其實沒啥內容...
09/14 12:22, 63F
→
09/14 12:22, 3年前 , 64F
能引起討論我覺得還是好事, 但你這些其實根本就是不透明
09/14 12:22, 64F
→
09/14 12:23, 3年前 , 65F
如果你是其中一角色又能有權利改變 拜託把透明化跟溝通做好
09/14 12:23, 65F
→
09/14 12:23, 3年前 , 66F
什麼叫做視野不同 視野還不是人給的...
09/14 12:23, 66F
推
09/14 12:44, 3年前 , 67F
樓上說的對 要讓開發知道大家在同一條船上
09/14 12:44, 67F
→
09/14 12:45, 3年前 , 68F
把人當可有可無 只給部分資訊 當然做出來的不符合所需
09/14 12:45, 68F
有的人給他透明的資訊他還不想看呢，只想專注在自己認為的「對」 而拒絕接受現況繼續要求環境要改變，這還蠻可惜的呢。 但我的經驗是大部份工程師都願意為自己成長而作些想法和作法上的改變， 成為和我站在同一陣線一起打拼的小團隊呢。
推
09/14 16:15, 3年前 , 69F
功高蓋主，動嘴皮子的工作給你做，了，叫主管吃素嗎？要
09/14 16:15, 69F
→
09/14 16:15, 3年前 , 70F
不等一陣子讓他以自創名義重提，要不就一開始以引導方式
09/14 16:15, 70F
→
09/14 16:15, 3年前 , 71F
讓主管領悟，總之要把發想的風采歸主管。
09/14 16:15, 71F
→
09/14 18:11, 3年前 , 72F
要求上層改變等同賞他們巴掌讓他們沒面子
09/14 18:11, 72F
推
09/14 23:25, 3年前 , 73F
工程師跟老闆之間有溝通的機會嗎
09/14 23:25, 73F
推
09/15 00:16, 3年前 , 74F
很好的文章，還是有酸酸，實在是不大懂....
09/15 00:16, 74F
推
09/15 00:21, 3年前 , 75F
就思考的層次上，原 Po 完全走出自我的思考領域，並
09/15 00:21, 75F
→
09/15 00:21, 3年前 , 76F
設身處地為其他單位、老闆著想，光這件事情就是許多
09/15 00:21, 76F
→
09/15 00:21, 3年前 , 77F
人做不到的，想到要處理這麼複雜、多的單位與人，以
09/15 00:21, 77F
→
09/15 00:21, 3年前 , 78F
同級數的技術總監們可能連想都不敢想。感覺大大又不
09/15 00:21, 78F
→
09/15 00:21, 3年前 , 79F
斷的往上升級了呢！
09/15 00:21, 79F
推
09/15 01:12, 3年前 , 80F
這篇不錯
09/15 01:12, 80F
推
09/15 01:44, 3年前 , 81F
看的出來原po是不錯的主管,可惜這種人不多...
09/15 01:44, 81F
推
09/15 07:37, 3年前 , 82F
感覺其實這問題一直以來處理方法都差不多，跟交往一樣
09/15 07:37, 82F
→
09/15 07:37, 3年前 , 83F
，遇到還能溝通的就相互包容多替彼此的立場設想，遇到
09/15 07:37, 83F
→
09/15 07:37, 3年前 , 84F
無法溝通的就只能忍耐或走人，如此罷了。
09/15 07:37, 84F
※ 編輯: UniFish (59.127.82.251 臺灣), 09/15/2020 13:53:29
推
09/15 16:45, 3年前 , 85F
其實當你由工程師升到主管.沒有換個位置換個腦袋就不對了
09/15 16:45, 85F
→
09/15 16:45, 3年前 , 86F
而且是換腦袋後.懂得怎麼把之前的感受轉換成工程師語言
09/15 16:45, 86F
→
09/15 16:45, 3年前 , 87F
這也是為什麼專業技術者上來的主管比較好帶人
09/15 16:45, 87F
→
09/15 16:46, 3年前 , 88F
不過作者寫的很棒. 愈往上升. 愈要懂得估算成本就是
09/15 16:46, 88F
推
09/15 16:56, 3年前 , 89F
無論什麼樣的企劃，你都得轉換為成本和收益才能說服老闆
09/15 16:56, 89F
推
09/15 20:58, 3年前 , 90F
先推！統整一下，提出變革的角度可以從老闆的角度出發
09/15 20:58, 90F
→
09/15 20:58, 3年前 , 91F
，做這件事情對公司有什麼利益，而不是以自己的角度覺
09/15 20:58, 91F
→
09/15 20:58, 3年前 , 92F
得這樣比較好做事
09/15 20:58, 92F
推
09/15 23:02, 3年前 , 93F
謝謝大大分享，很有用～～
09/15 23:02, 93F
推
09/16 10:03, 3年前 , 94F
推用心分享好文
09/16 10:03, 94F
推
09/17 18:45, 3年前 , 95F
很用心分享，很多面向過去沒想到，用力推
09/17 18:45, 95F
‣ 更多 UniFish 的文章
文章代碼(AID): #1VN52SxN (Soft_Job)