最近在弄個舊系統的功能搬移，也就是把舊系統的功能在新系統上重新開發。
會要進行功能搬移就是對舊系統有些不滿，有些功能整個設計上就很有問題(無論是使用的順暢度上還是技術上)，這會開發者產生兩種選擇：
1.把舊功能的問題修正甚至重新設計。
2.就照搬啊，能不改盡量不改。
照理說使用者會比較希望開發者選擇前者，但公司也正在推行績效考核與目標管理之類的東西。以公司的管理與評估方式是目標訂了，時間到了就要有結果，過程甚麼都不管。那這樣會產生甚麼樣的結果呢？這裡舉個例子：
舊系統對於下拉選單的撰寫上常常都是用把選項寫死在頁面的做法，包括一些有可能會增加種類的選項，例如合作廠商。今天只要合作廠商增加了，選項就可能會增加。當時間久了以後，有些合作廠商的選項可能根本不會再有被使用的機會，但選項還是會存在。也就是選項的內容是需要開發者直接改頁面來控制的。
我想碰過多點資訊系統的人可能會很直覺的問說「為什麼不做個維護功能，或者以自動的方式來管理選項的內容呢？」。使用者常常不曉得技術能做甚麼？需求的提出也可能會被技術擋掉。我自己是認為在技術上這是做得到，在使用上也是比較好的事情，但是功能的搬移有目標有時程，這樣做就是增加開發完成所需的工時，最後的考核評估不會因為這樣做而變好，反而可能因為你花了較多的時間而認為動作太慢。
最後結果：
開發者提供一個比較容易實現的解決方案，對於使用者最好的解決方案直接說「這不可能，技術上做不到」，之後也不會去實現最好的解決方案，因為當初就說做不到了，之後怎麼可以做。之後完成的系統就會有很多其實技術上可以改善的問題但是不會被改善。
這算誰的錯呢？
提出需求的單位一定會認為開發就該實現我的需求啊，怎麼可以這樣混過去，這樣會影響我業務的進行。
開發者一定會認為自己為了實現上面訂的目標，配合公司的管理規定，這麼做也只不過是依照公司要求辦事，盡可能在時間內達成當初的目標，而不超出時間做得更好。
管理者則會認為開發者本來就該多提出些技術的解決方案，但目標也是要實現的，沒實現依照規定就不對，目標管理也有存在的必要，否則那些工程師可能就會偷懶打混啊。有的可能會說做不完就加班啊(但加班費可能會推)。有問題的話就該提出啊(但不一定會處理)。
那問題的根源在誰那呢?
我個人是認為是管理者的問題，但管理的可能會認為這都是工程師的問題，又或者乾脆乾脆放大絕說「有些事情本來就沒辦法啊，屬下本來就該接受，不然不要做啊」(我是不認為開發者走了，問題就會消失)
我認為KPI與目標管理本身沒錯，錯的是使用的人。就像我認為責任制本身也沒錯，有些事情不該只有工作時間才做，只是被濫用，把工作量增加到工作時間都肯定做不完的程度來讓人免費加班。
這樣產生結果是：對於責任制我聽到會怕，對於KPI我聽到也怕，因為亂用的太多了。
我對於管理的期望是讓底下的人往正向的方向(例如：把系統開發得很好用)能有好的成果，這樣對我而言，才會有更多動力讓我努力做更多對公司有好處的事情。
但如果公司採用一些評估方式影響了我讓公司更好所能得到的回報，那麼這些方式將得到當初目的的相反結果...。
留言列表
