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