這篇文章是在一場冗長而毫無意義的會議上寫的嗎?
當然不是!
……或者並非如此? 👀
首先聲明:我入行十多年了,見過各種各樣的開發人員——包括那些典型的內向開發人員,他們寧願重構遺留程式碼也不願與人交流。
然而,我至今還沒有遇到一個開發者(無論多麼內向)說過:
“我寧願花一個小時在聊天軟體上解釋一些事情,也不願意只打5分鐘的電話。”
(對於上班族:請將「打電話」改為「走到某人的辦公桌前」。)
所以,不——我們並不討厭人或談話。恰恰相反!
對於任何開發者來說,簡短而高效的通話都彌足珍貴。 💎
我們憎恨的東西完全是另一回事。
你一定知道我說的是哪種:
*️⃣ 也可能是一封電子郵件。
*️⃣ 同一個話題重新提起第十次了。
*️⃣ 一半的與會者根本不知道自己為什麼會來這裡。
*️⃣ 總是會有人分享螢幕,然後連續講30分鐘。
作為高級開發人員/技術主管,你可能會完全陷入會議。
在我之前的公司裡,我發現自己總是逃避複雜的任務——不是因為這些任務很難,而是因為開會會讓這些任務花費的時間比當天沒有電話的初級開發人員多一倍。
同時,有些「會議達人」因為安排了一次與「許多重要人物」的通話而感到成就感滿滿。 🎉
我也不是無辜的。有一次我安排了一個12人的電話會議…結果對方團隊的技術負責人卻說:
“嗯,我們看看吧。我們需要核實一下。”
僅此而已。這就是這次會議的全部價值。
至少我為浪費大家的時間感到羞愧。 🙃
有些人──通常是非技術人員──認為開很多會也沒什麼不好,因為:
“你可以在後台做點別的事情。”
不,並非如此。那個說法上個世紀就被科學駁斥了。
根本不存在“多任務處理”,只有情境切換——而這會瘋狂消耗腦力。
所以你要嘛:
完全置身事外,專心做自己的事(既然如此……為什麼會被邀請?)
試著傾聽,因為隨時都可能有人會說:“說說你的想法。”
結果:你只能做一些簡單、輕鬆的任務——或者,如果你沒什麼事可做,那還不如寫篇部落格文章。 😉✍️
人們往往不了解軟體開發的本質。
真正的進步需要高度專注。而當這種專注持續足夠長的時間後,你就會進入著名的心流狀態-在這種狀態下:
✅ 事情終於說得通了
✅ 問題出在“已載入到記憶體”
✅ 進展變得快速且令人滿意
直到日曆通知彈出:
“我們不妨花 45 分鐘通話,討論一下我們已經討論過三次的事情,只是為了把它正確地記錄在電子表格中。”
或者:
“我們邀請 20 個人來集思廣益,討論一下我們可能在 2028 年實現的功能。”
一個開發人員如果開了三個一小時的會議,就沒有剩下的五個小時可以完全有效率地工作了。
會議結束後,你會感到精神疲憊,需要時間重新整理工作的整體思路。
那不是懶惰。那隻是大腦的運作方式。 🧠⚙️
研究表明,人們在完成任務切換後,平均需要23分15秒才能重新投入先前的任務。 ( Monitask )
據某訊息來源稱,上下文切換會使生產力降低20% 到 80% ,具體數值取決於切換次數和切換類型。 ( trunk.io )
據估計,上下文切換每年對全球經濟造成約4500億美元的損失。 ( atlassian.com )
一份報告發現,員工花費在管理和參加會議的時間,平均每年會對雇主造成每位員工29,000美元的成本損失。 ( WorkLife )
倫敦政經學院的研究發現,約35%的商務會議效率低下,光是在美國,低效率會議每年就會造成企業約2,590億美元的損失。 ( lse.ac.uk )
只有約 30% 的會議被認為是有效率的,只有約 37% 的會議會積極使用議程。 ( Notta )
簡短。目標明確。人員合適。產出大於對話。
以下是一些你可以藉鏡的實用技巧👇
✅首先問問自己: “我們真的需要開會嗎?這可以透過評論、工單更新或三條訊息的聊天記錄來解決嗎?”
✅只邀請真正需要參加的人。非必要參加者 = 非同步記錄。
✅用一句話概括目標。如果做不到,那就表示你還沒準備好安排會議。
✅**預設時長設定為 15 分鐘。**僅在需要時延長。
✅先陳述事實,而不是編故事。 “問題在於此。解決方案在於此。”
✅會議結束時必須做出決定並確定負責人。如果沒有做出決定,則會議失敗。
✅會後發送一份三點式總結。這樣就沒人需要「以防萬一」而參加了。
額外提示:
如果必須進行腦力激盪,請使用非同步預處理,以便呼叫從解決方案層級開始,而不是從追趕層級開始。
💬 這週你因為開會損失了多少工作效率時間?請留言——我們一起來計算開會的實際成本。
原文出處:https://dev.to/sylwia-lask/the-real-reason-developers-hate-meetings-its-not-time-31do