PTT評價

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

看板Soft_Job標題[心得] 為什麼我們提出改變,常常不被上層同意?作者
UniFish
(解夢師Raguhn)
時間推噓37 推:40 噓:3 →:55

好讀 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 留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.164.237.32 (臺灣)
PTT 網址

lonelytea09/12 12:45

sylviami09/12 13:07推推

taikobo09/12 13:11推角色不同,看事情的角度也不同

geniusturtle09/12 13:20推 溝通很重要

jny211709/12 13:29推推 好棒

tay251009/12 13:49推分享

unmolk09/12 14:08推好文

mirtac09/12 14:16

x246libra09/12 14:17追求正確做法,可以被你說成眼光狹隘,是自己世界太簡

x246libra09/12 14:17

x246libra09/12 14:23還是換公司最快,通常這種公司沒在管品質的,能動就好

不同的位置會有不同的視野,我在文中可沒講眼光狹隘吧 我的確也是想著換組織換公司,不過至今還沒換到所謂「正確」的組織和公司 我不需要用我的生命來証明那些公司失敗,我想要讓我想作的事落實而已, 所以我才開始研究如何落實,走到現在我個人感想是比追求正確作法實際多了。 如果用一句話來形容是「考量到現實條件儘可能代入正確作法並落實」

TAKADO09/12 15:26最正規/最正確的做法有時候不一定是最佳解啦,有時候還是

TAKADO09/12 15:26得在現實條件前妥協,尤其是專案類型的公司。

是的,但同樣有自己產品的公司也會有初期先活下來,然後code亂七八糟, 後來整理會整死人的情況,一樣的是在現在條件下找出目前可以執行的解法

frank91013809/12 15:32

B098869808809/12 15:45最近怎麼常有medium的來刷流量

superpandal09/12 17:38專案類型的公司的確是這種 公司都沒什麼話語權更不要

superpandal09/12 17:38說自己 真的好缺十之八九都被人佔走了

st903202xp09/12 18:07

lance7017609/12 18:20做過一陣子類似思路 給推

alihue09/12 18:45不是 medium 的錯,是 ptt 太難寫文章reddit programming

alihue09/12 18:45也都是貼文章鏈結

alihue09/12 18:46難道你要在 ptt 貼 code snippet 嗎?

leo591626709/12 19:00最佳解應該要在歸納需求時就想好最佳需求描述,不然

leo591626709/12 19:00不可能實作出來

理論上是這樣啦,但是業務/PM也是人,也是需要學習的,在成長過程中也是會提出些 不太「正確」的描述法和需求,那麼有沒有人可以協助他們了,沒有的話就是自己出馬 去協助,融合雙方需求定出提需求的規則,就算沒有100%到位 但是從10%提昇到50%,讓雙方都省下些時間,我想很少公司會反對的

wulouise09/12 19:44你貼gitpage上來別人也會說是來騙星星的xd習慣就好

rayway3041909/12 20:26有溝通能力的技術人員才有辦法做這件事

rayway3041909/12 20:26很多技術本位的人根本懶得去花力氣說服別人

airtsubasa09/12 21:36當你的同事是比你資深n年且等著退休的人,要推什麼都

airtsubasa09/12 21:36無法

s00158200009/12 22:12碰到無能主管除了換公司還能怎辦 把他鬥下來嗎

我的心得是作這些事情有沒有在公司推行成功並不是主要目標,而是讓自己培養出能力。 我啊,在之前的公司也是推得很挫折,但因為在那挫折環境下,我研究和嘗試了各種方法 ,累積了知識和一些經驗,換到新環境馬上就派上用場。 而不用等環境准備好,我再來學,我的焦點一直都是自己的成長,那麼主管或資深同事 想不想動就和我想不想動一點關係都沒有。

lazarus112109/12 22:13職場沒這麼複雜,主管口中的視野高度

lazarus112109/12 22:14講白話就是,不要讓我被上面定

lazarus112109/12 22:22我這兩年把好幾十支程式和table都翻掉了,我只跟主

lazarus112109/12 22:22管説,不會有異常,BU不會抱怨,就算出問題也有備份

lazarus112109/12 22:24主管只跟我説,專案不要delay就好,也沒在擋的

triplee09/12 23:01推樓上 有時候反而就是這麼簡單

Ya,主管立場「有人想幫我搞定連我都不想搞定的事,高興都來不及,不要出包讓我得去 背鍋就行

michealx09/13 00:17默默撿垃圾是一種浪漫

沒錯,我最愛默默修東西了

alongalone09/13 02:09感覺有點廢文. 那怎麼不是想辦法讓大家拿到的資訊依樣

mickey9437809/13 02:33推好文

superpandal09/13 03:48有時間要翻掉沒問題 但本文有前提的 除非是好公司

superpandal09/13 03:49或者有強烈的認同感 否則個人是不情願這樣做的

superpandal09/13 03:50基本上你就是要多花精力在這上面

superpandal09/13 03:58拿到的資訊一樣基本上只是理想 如果是工程師那更不可

superpandal09/13 03:58達成摟

superpandal09/13 03:59術業有專攻

airtsubasa09/13 07:11翻掉了…業務輪調交接時,接你的人會感謝嗎?

同上面所說,做這些事情主要是培養自己的能力,公司剛好受惠。 也不是為了別人感謝我而作。

KKFN09/13 07:37最怕的是你以為自己重構的好棒棒結果根本是爛Code。

tsai161809/13 09:47

dias383909/13 09:48

lazarus112109/13 11:48如果能做出公式解把義大利麵換掉,應該不會雷到哪去

lazarus112109/13 11:50怕的是重構後還是一樣死,新需求一來又開始違建

lazarus112109/13 11:53我反而覺得開發者的高眼界,是在開發時就想到未來擴

lazarus112109/13 11:53充需求的可能性

說實在的,就算開發者設計架構超級厲害,也很難確保未來有沒有需求脫離這架構外的。 我追求的70% / 30%,是要兼顧架構、易讀性、擴充性所作的務實且妥協辦法。

JasperChang09/13 12:11悠哉過小生活?重構納入kpi年終有變多嗎?

看你怎麼跟公司談 XD 同上面所說,做這些事情主要是培養自己的能力,如果你在意年終有沒有變多的話 不做也行啦。

sky4028009/13 13:06

kika6509/13 14:03推好文

superpandal09/13 15:49有能力重構的應該不至於太爛 只是成本要自行吸收

superpandal09/13 15:49別人確實也不會多給一毛錢

peter9s3b09/13 19:43老闆要給時間啊!老闆只懂你未來一個月沒產出,跳腳說

peter9s3b09/13 19:43不行,也沒法重構練功啦

jeff861109/14 00:42推魚大

KeGun09/14 11:12推推

jlhc09/14 12:22有分享還是給推, 但寫的很多其實沒啥內容...

jlhc09/14 12:22能引起討論我覺得還是好事, 但你這些其實根本就是不透明

jlhc09/14 12:23如果你是其中一角色又能有權利改變 拜託把透明化跟溝通做好

jlhc09/14 12:23什麼叫做視野不同 視野還不是人給的...

skizard09/14 12:44樓上說的對 要讓開發知道大家在同一條船上

skizard09/14 12:45把人當可有可無 只給部分資訊 當然做出來的不符合所需

有的人給他透明的資訊他還不想看呢,只想專注在自己認為的「對」 而拒絕接受現況繼續要求環境要改變,這還蠻可惜的呢。 但我的經驗是大部份工程師都願意為自己成長而作些想法和作法上的改變, 成為和我站在同一陣線一起打拼的小團隊呢。

GoGoJoe09/14 16:15功高蓋主,動嘴皮子的工作給你做,了,叫主管吃素嗎?要

GoGoJoe09/14 16:15不等一陣子讓他以自創名義重提,要不就一開始以引導方式

GoGoJoe09/14 16:15讓主管領悟,總之要把發想的風采歸主管。

shooter55509/14 18:11要求上層改變等同賞他們巴掌讓他們沒面子

lastpost09/14 23:25工程師跟老闆之間有溝通的機會嗎

h123456788209/15 00:16很好的文章,還是有酸酸,實在是不大懂....

h123456788209/15 00:21就思考的層次上,原 Po 完全走出自我的思考領域,並

h123456788209/15 00:21設身處地為其他單位、老闆著想,光這件事情就是許多

h123456788209/15 00:21人做不到的,想到要處理這麼複雜、多的單位與人,以

h123456788209/15 00:21同級數的技術總監們可能連想都不敢想。感覺大大又不

h123456788209/15 00:21斷的往上升級了呢!

azzc103109/15 01:12這篇不錯

viper970909/15 01:44看的出來原po是不錯的主管,可惜這種人不多...

blackdiz09/15 07:37感覺其實這問題一直以來處理方法都差不多,跟交往一樣

blackdiz09/15 07:37,遇到還能溝通的就相互包容多替彼此的立場設想,遇到

blackdiz09/15 07:37無法溝通的就只能忍耐或走人,如此罷了。

※ 編輯: UniFish (59.127.82.251 臺灣), 09/15/2020 13:53:29

fowei09/15 16:45其實當你由工程師升到主管.沒有換個位置換個腦袋就不對了

fowei09/15 16:45而且是換腦袋後.懂得怎麼把之前的感受轉換成工程師語言

fowei09/15 16:45這也是為什麼專業技術者上來的主管比較好帶人

fowei09/15 16:46不過作者寫的很棒. 愈往上升. 愈要懂得估算成本就是

odahawk09/15 16:56無論什麼樣的企劃,你都得轉換為成本和收益才能說服老闆

freshlemon09/15 20:58先推!統整一下,提出變革的角度可以從老闆的角度出發

freshlemon09/15 20:58,做這件事情對公司有什麼利益,而不是以自己的角度覺

freshlemon09/15 20:58得這樣比較好做事

sagiters09/15 23:02謝謝大大分享,很有用~~

lnyan09/16 10:03推用心分享好文

cotbel09/17 18:45很用心分享,很多面向過去沒想到,用力推

cory824909/25 00:40

HZYSoft10/05 22:23大推,這篇寫得超好!

peiigreen10/06 21:51推好文