團隊協作

部門文化建立需要管理層微小的強制與鼓勵

部門文化建立需要管理層微小的強制與鼓勵

這篇文並不是要批評現職,並不是要此地無銀三百,而是這篇文是早上搭公車上班時想到的,然後我就很興奮(?)的分享這些議題給同事與 LINE 技術社群的朋友,在經過一些多方對話後,我再把一些討論後的內容汲取出來並加上自己心得。 關於團隊文化的議題,有時候我們會聽到一句話: 部門文化不能強迫建立,尤其是技術分享,強迫是沒意義的。 這句話乍看是沒錯的,但真的完全正確嗎?其實文化建立需要一點微小的強制力推動(或者說提醒),就舉個我們部門的例子來看: 例子:開會中在白板上畫圖溝通 在平常工作會議中,常看到某些 Sr 工程師或主管,會議討論主動用白板畫圖,不管是流程圖、時序圖還是概念草圖,這樣的行為幾乎已經變成習慣。 觀察一下就會發現,除了 Sr 或主管以外,真正主動在開會中用白板的人還是極少數。 如果 Jr 工程師不懂流程、UI 或架構就算了,大部分狀況下 mid 工程師們其實知道,只是可能害羞的關係(?),大家習慣口說而不敢拿筆用視覺化方式溝通,反而劈哩啪啦一直講,這過程很容易產生溝通誤會。 多數情況下要由 Sr 或主管對同事開口說:「要不要你來畫一下?
SimonAllen
晉升 Senior 後:三明治主管影響力與技術債之我見

晉升 Senior 後:三明治主管影響力與技術債之我見

本文並非批評任何人,而是嘗試從組織運作與職位差異的角度出發:在拿到 Senior Title 後我對於辦公室政治與決策議題更有興趣了,而這篇文就是紀錄我目前觀察到中層技術主管們在企業內如何建立影響力。 畢竟每個職級、每個部門都有其任務與立場,我認為這都沒有對錯,只是台灣中大型企業日常運作的一部分。 首先定義什麼是「三明治」,這裡的三明治是泛指在台灣公司體制「 CXX」某某長之下、基層員工之上的所有夾在其中具管理職的員工。 中層主管如何在企業內建立存在感與影響力? 對於身處公司「三明治」的中層技術主管而言,上有高層期待績效與可見成果,下有工程團隊承擔技術落地與維運負擔,要在這樣的夾縫中求生存,最常見的做法之一,就是主動解決跨部門的「痛點」問題。 這類專案看起來像是流程改善、內部工具開發,甚至某種戰略功能的 MVP,其實本質是向平行部門經營關係、向高層展示價值的一種方式:透過這些專案提升部門能見度,也讓中層主管在公司中建立了影響力。 然而這些更高層主管「看得見」的成果,往往會帶來「看不見」的技術債。中層主管們或許心知肚明,但在績效與人事評估的現實考量下,這些隱藏成本多半被選擇性
SimonAllen
你就是「沒有人」的謬誤

你就是「沒有人」的謬誤

前言 在軟體社群、開源貢獻圈,甚至許多商管文章中,我們常會聽到一句話: 當你覺得沒有人去做這件事,你就是那個「沒有人」。 這句話原意是鼓勵主動貢獻。但我投入軟體工作這麼多年,待過好幾間公司,常常看到這句話被拿來當作「擋箭牌」。 這篇文章不是為了反對主動貢獻,而是想談談:這句話被錯用後,會出現哪些謬誤與危險的職場文化。 發現問題 ≠ 有解法的人 提出問題,不代表那個人就知道該怎麼解。這是非常基本的邏輯。但在某些文化中這層認知被扭曲了。 有些主管聽到下屬說:「我們這流程有點卡。」、「這個效能很差」 反應卻是:「那你就來想個方案」 這樣的回應本質上是:你提出問題,就等於你要解決問題,但這其實非常不合理。 一來,每個人手上任務與時間不一樣,問題提出者可能根本沒有額外時間去研究解法。二來,有些問題本來就需要跨部門協作或主管授權,根本不是基層員工能單打獨鬥完成的。 提出問題,不是情緒宣洩 我聽過很扯的是直接和我說:如果你沒提出解決方案,那就只是在情緒宣洩。 有些人會說:「不要只會提問題,應該帶著解法來。」這句話乍聽很有道理,甚至在某些商管書籍中被當成黃金法則。但我認為
SimonAllen
工程師們需要建立自提需求清單

工程師們需要建立自提需求清單

平常在開發上,RD 們可能會產生除 PM/PO 需求之外,自己注意到或想做之事,例如: * 專案環境設定、程式碼或套件版本升級 * RD 自己注意到的 bug * RD 自提需求 * ..etc 某些 RD 導向的需求,PM 會不太理解其對 Project 的幫助(例如程式語言的版本升級,短期對專案不會有助益),有的則是 RD 自己對 Project 的新想法,想要增加某些功能時,這時 RD 們就會傾向先自行開單紀錄。 然而 RD 們的自提單號優先度往往很低,常常開了放在那邊長灰塵,一忙起來大家就忘記有這個需求。 雖然鼓勵團隊成員自行開單(再通知 PM 排後續開發時間),但每個人開了自己的單號,很容易產生重複開單或者沒有統一單號管理的問題。 具體做法建議 * 在任務發單系統建立一張主票、母票或主任務為「某某 Team
SimonAllen
Git Commit 請加上任務單號

Git Commit 請加上任務單號

我在部落格這頁設定的置頂圖片就是很常見的情境,在大型專案中開發,我們能從 Git Message 知道做了什麼動作,卻無法知道是「為了什麼情境」而做這些動作。 在軟體開發中,如果是 VS Code 使用者,通常都會安裝 GitLens 擴充套件(或者其他你習慣的 Git 擴充套件),好看到程式碼該行最後的 commit message。 而 Git Commit 的 message 流派不少,我認為 Web Frontend 在多人協作需要做到最基本、最大前提的一件事情 - 帶上開發的「任務單號」! 不論團隊用什麼任務發單管理系統,如 Redmine 或 Jira,在新增任務開票、開單後,該任務都會有一個系統自動產生的號碼或編號「任務單號」 理解修改的 Context 情境比知道改了什麼還重要 當開發者覺得某段
SimonAllen