sk系統(tǒng)和Portal系統(tǒng)的支持，前者是跟需求寫在一起的，后者是部門的一個知識管理平臺，里面有產品任務表文檔，個人工作記錄文檔等。當小A完成了這個Ticket的開發(fā)之后，會把代碼打包并寫好發(fā)布文檔上傳至Helpdesk上面，然后在TFS上面Check in代碼，通知發(fā)布人員獲取最新代碼。然后是測試發(fā)布人員去Review小A的代碼，發(fā)布到開發(fā)環(huán)境和用戶測試環(huán)境，通知用戶測試，完成自己的工作之后Log自己的工時進Helpdesk系統(tǒng)。如果用戶測試沒有問題，那么sa會關閉這個Ticket，整個需求的開發(fā)就完成了。這個過程中一般都會涉及到以上所說的四種角色，每個參與人員都必須有工時記錄，并統(tǒng)計自己的有效工時來換算成自己的績效得分。
接下來說說個人工作日志的問題，園子里面前段時間也有人說道寫工作日志的好處和壞處。個人認為好處還是蠻多的，至少它是進行績效管理的有效手段。但績效管理的依據并不是工作日志，而是Ticket所需的有效工時。個人平時的工作任務類型一般分為以下幾種，其中有Ticket、Runtime、Issues、study等。由于我們的開發(fā)成本是要用戶分攤費用的，而能向用戶收取費用的只有Ticket，所以說一個Ticket預估工時的工作非常重要，SD要盡量考慮項目組內成員的開發(fā)水平和需求實際花費的時間，盡量預估的和實際的開發(fā)時間相靠近。而Team內成員的工作日志中的任務類型一般應該以Ticket為主，當然，Team一般都會在每周有至少兩次例會，開會時間每周大概四個小時，這個部分算作Runtime。如果你本周確實沒有Ticket來做，那你可以做更多的Study工作，但這個一般不算作有效工時。因此，以上統(tǒng)計有效工時的做法督促項目組內的成員都爭取Ticket來做，盡量使自己本周之內的績效得分高一些。
最后說道一下我們推行以上做法過程中遇到的一些問題。做這種績效管理開始的時候要經常有人督促Team內成員維護個人的工作日志，督促sa和sd管理好本小組成員的任務分派問題，及時關閉完成的任務，安排好本周和下周的事情等。還需要注意的是，怎么拆分好大的任務為小的任務，盡量讓每個人本周之內都能獲得有效工時而不是周績效分為零。另外，個人認為這套管理方法還是有些小問題的，特別是任務不多的時候，大家相對比較清閑的時候，一般SD人員會參與比較多的開發(fā)任務，下面的開發(fā)人員就有可能分不到任務，長期以來，SD的績效分遙遙領先，經常領不到任務的和做事效率比較低的人的績效分則不到最高人員的五分之一。但反過來想，這也算是一種激勵機制，所謂多勞多得嘛。