進度落後不是開發者的錯,工作流程可能才是兇手!

評論
評論

「為什麼趕不出來?」

專案錯過死線的時候,管理者總覺得就是開發團隊的錯。不過真的是開發者動作太慢嗎?

專案管理服務 Sprintly 的產品行銷經理, Justin Jackson 在 部落格 內說,他們利用 Sprintly ,追蹤開發人員執行各項工作的時間,並依種類和大小細分,得到了以下結論。

有什麼共通點?

第一點就是,開發人員表現非常平均。根據軟體搜集的資料,75% 的開發週期都在 175 小時左右。

第二,在 ticket 開始前變數最大,這就是廠商開出規格和安排工作的時間,也就是當 ticket 從出現到安排作業所需的時間。這個階段浪費了很多時間。

variability

第三,從「完成」轉換到「測試完並準備好分配」對團隊而言也很困難。

進度落後的原因?

如果不是你的開發人員特別慢,那為甚麼開發會逾期?答案可能是:你的流程有問題。

需求不明

確定技術規格很重要。如果開發者不懂一項功能的目的,那他要怎麼開發這功能?

絕大多數的技術規格開出來時,沒經過審慎思考,通常等到我們開始設計或開發,就會碰到一堆麻煩,因為很多規格都有漏洞。

— eagerMoose on Stack Exchange

廠商太常開出自己沒仔細想過的功能,所以開發者一定要去了解,為什麼使用者需要這個功能、這個功能是做什麼的、要怎麼用。你可以用固定的格式來描述使用者情境。

user-story-on-dashboard-cropped-1024x373

使用 Sprintly 時,你得用這個格式來寫:我是一個 ___,我想要 ___,所以 ___。(要把事情做對)一定得這樣。

— Darren Rogan, the Hack and Heckle podcast

這個形式為特定功能設定了方向,也維持小規模的情境設定,不會過度展開。

不斷變更需求

開發者第二大抱怨主因就是,專案開始後,不停變動的技術規格。Hacker News 的一位使用者 形容 得很貼切:

開發者:「我們把屋頂和牆都裝好了!」

廠商:「我們現在想要把所有的牆都移開。」

這大部分是安排工作前沒有好好規劃功能,所產生的症狀。

避免在流程中途變更需求的方法之一,就是在真正開始開發前,先做互動模擬。我們用靈活的方式工作,不代表我們可以隨時變更規模。最理想的情形是,你在過程中得到的點子,都該立刻紀錄下來,並考慮日後放進更新。

progress
另一個防止變更需求及規模的方法就是盡可能預測進度。Sprintly 內有項功能,就是根據進度,預測完成一項功能還須多少天。

切換工作

eye roll_0
影集 Mazel tov, Dummies! 劇照

Justin Jackson 提到,流程中最後一塊絆腳石,大概就是工作的切換,而這可能有以下幾種常見形式:

  1. 開發者已經完成 A 工作的一半,此時你走到他的辦公桌旁,要求他切換到 B 工作。
  2. 開發者已經完成 A 工作的一半,此時你走到他的辦公桌旁,要求他同時處理 B 工作。
dev-who-switches-contexts1
舉例來說,Sprintly 的開發主任時常需要檢查程式碼、幫員工分組、開會、緊急狀況出來救火。

開發主任不斷分心做其他事,導致他完成一項工作的時間要比其他人來得長。

當管理者讓開發人員中途切換到新工作,就會產生問題,而如果工作時程一直在變,將讓團隊付出重大代價。

Stack Overflow 的 CEO,Trello 共同創辦人 Joel Spolsky ,也在 部落格 中提到切換工作的傷害:

從這些事件中你會學到,別讓人同時處理兩件工作,並確定他們清楚工作內容。優秀的管理者會承擔責任,替人移除障礙,讓他們專心於一件工作並完成它。若有緊急事態,在打擾全心沉浸於專案的工程師前,先看看你能不能自己處理。

擔起責任

管理者的工作就是提供一個環境,讓開發者能成功完成專案。在指責開發人員,要他們為延遲行程負責前,應該先檢驗你自己。

這裡提供一些簡單的步驟,可以檢查看看你有沒有拖累團隊:

  1. 讓你的團隊了解目標:和你的團隊一起定義,如何讓使用者的生活更好,搞清楚使用者需要的結果。讓開發者接受與否很重要,對功能的熱情程度,會大大影響開發速度。
  2. 設計使用者情境要有明確規範。每項工作都使用同一個模板創造,除非充分敘述工作細節,否則開發者都有不接這項工作的權利。
  3. 減少切換工作成本,不要打擾你的開發者!寄 email 或提出任何要求前,先衡量一下對生產力造成的影響。

重點是,怪罪開發人員「太慢」前請三思,很有可能是你的工作流程拖累了他們。

相關文章

評論