IT 職場求生術:點樣同「乜都話簡單」嘅老細溝通

IT 職場求生術:點樣同「乜都話簡單」嘅老細溝通 「呢個功能好簡單啫,加個掣就得啦。」— 如果你做 IT 嘅,呢句説話你一定聽過,而且聽到火都嚟。 老細或者非技術同事眼中嘅「簡單」,同我哋實際要做嘅嘢,中間隔住十個太平洋。今日就同大家傾下,點樣用IT 職場溝通嘅技巧,將呢啲「簡單」要求變成大家都理解嘅工作。 點解老細成日覺得乜都「好簡單」? 首先你要明,老細唔係有心玩你。佢哋嘅世界觀同我哋唔同 —...

IT 職場求生術:點樣同「乜都話簡單」嘅老細溝通

「呢個功能好簡單啫,加個掣就得啦。」— 如果你做 IT 嘅,呢句説話你一定聽過,而且聽到火都嚟。

👉 延伸閱讀:AI 年代 IT 人生存指南:三個令你唔會被淘汰嘅技能

老細或者非技術同事眼中嘅「簡單」,同我哋實際要做嘅嘢,中間隔住十個太平洋。今日就同大家傾下,點樣用IT 職場溝通嘅技巧,將呢啲「簡單」要求變成大家都理解嘅工作。

點解老細成日覺得乜都「好簡單」?

首先你要明,老細唔係有心玩你。佢哋嘅世界觀同我哋唔同 — 佢哋睇到嘅係 UI 上面一個掣,我哋睇到嘅係背後嘅 database schema、API integration、authentication flow、error handling、edge cases⋯⋯

呢個落差唔係佢蠢或者你解釋得唔好,而係IT 職場溝通本身就存在資訊不對稱。你做咗十年技術,佢做咗十年 sales,你哋嘅「common sense」根本唔 common。

唔好即刻 say no — 用「拆解大法」

最蠢嘅做法係即刻話「唔得」、「好複雜」、「做唔到」。咁樣只會令老細覺得你唔願意合作。聰明嘅IT 職場溝通係咁:

第一步:認同需求。「明,呢個功能對用户體驗好重要。」先表明你理解佢嘅出發點。

第二步:拆解工序。「等我同你拆解下背後要做啲乜:首先我哋要改 database schema 加個新 field,然後 backend API 要加個新 endpoint,frontend 要加新 component,仲要寫 unit test、integration test,最後 deploy 去 staging 俾你試。」

第三步:俾選擇。「如果要做足全套,大概要兩星期。如果想快啲,我哋可以做個 MVP 版本,三日內出到,但係只得基本功能,之後再迭代。」

呢個時候老細通常會有兩個反應:一係「哦原來咁多嘢,咁照你 schedule 啦」,一係「MVP 得啦,出咗先」。無論邊個結果,你都成功將個對話由「得唔得」變成「點樣得」。

IT 職場溝通黃金法則:永遠帶住 solution 去傾

好多 IT 人嘅通病係淨係識得指出問題,唔識俾解決方案。你話「個 server 好慢」,老細淨係聽到「你搞唔掂」。你話「個 server 因為 concurrent connection 太多導致 response time 升咗 300%,我建議加多個 load balancer 同 optimize 下 database query,預計兩日搞掂」,老細聽到嘅係「你有 plan」。

呢個就係IT 職場溝通嘅核心:唔好做問題報告機,要做解決方案提供者。

真實案例:一個「簡單」嘅 export button

我見過有個 junior developer,老細叫佢加個「export to Excel」功能。佢話「好簡單,半日搞掂」。結果呢?

  • Export 出嚟嘅中文亂碼(encoding 問題)
  • 十萬行 data 嘅時候 browser hang 機(冇 pagination)
  • 日期 format 錯曬(timezone 問題)
  • Permission control 冇做(乜人都 export 得)

最後搞咗成個星期先收科。如果當初佢用IT 職場溝通嘅拆解大法,同老細講清楚個 scope,就唔會俾人覺得佢「估錯時間」。

最後忠告:文件化一切

口頭應承嘅嘢係最危險嘅。每次同老細傾完 requirements,send 個簡單 email 總結:「根據我哋剛才嘅討論,以下係 agreed scope:1) … 2) … 預計完成時間:X 日。如有變更請通知我。」

呢個唔係唔信人,而係專業嘅IT 職場溝通。保護自己,亦保護個 project。記住:口講無憑,email 為證。

🔗 參考資料:NVD NIST 漏洞資料庫

下次老細再話「好簡單啫」,你唔使反白眼,笑住同佢拆解啦。

#溝通 #職場 #職場技巧 #IT職場