「組織在導入新做法（如 DevOps）時，一定要重新思考激勵措施」——《駕馭組織DevOps六面向》

開發部門的 KPI 是？是這一季要上線多少功能嗎？

維運部門的 KPI 是？是 SLA？是 MTTR 嗎？

測試部門的 KPI 是？抓出多少 Bug 嗎？

你覺得這三種不同的 KPI 可以和平共處嗎？

當不同的部門被硬是湊在一起，大家都很認真做自己該做的事，然而實際的成果卻是彼此處處互相卡死，難以運轉。

更慘的是，就算你願意釋出善意幫助他人，那份付出也不會出現在任何人的 KPI 裡。

於是做了不加分，萬一害得自己的進度因此落後，反倒還被扣分。（哭）

沒辦法，績效考核的世界就是這麼無情，你又怎麼能責怪那些關心自己考核成績的人呢？

因此在企業內如果實踐一項新的工具、流程、方法，其實還要留意，會不會有一張躲起來的考績表，默默的在造成阻礙。

明明是新的工作方式，卻依然搭配舊的 KPI 規則，那人們當然還是會走回原本那條舊路。

你們在實踐 DevOps 時，會看重哪些 KPI？

你們有哪些激勵措施是真的在鼓勵協作、交付頻率與軟體品質的呢？