在一個項目的實施過程中，工作進度反饋，這是站在員工角度的一種描述。如果站在管理者的角度，是工作進度跟蹤，它的目標(biāo)是為了讓項目進度可控，從而降低項目風(fēng)險。

它的表現(xiàn)形式是日報、周報，工具可能是在線填報、excel表格、甘特圖進度更新、每日郵件、紙質(zhì)表格等等。本來，這個目標(biāo)的動機無可厚非，但進度跟蹤只是讓項目進度可控的一種手段，而絕非目標(biāo)。

但給員工的感覺是，領(lǐng)導(dǎo)在監(jiān)視他，甚至是季度發(fā)獎金的依據(jù)。所以，出于一種本能的自我保護，員工會虛報或謊報。以我?guī)啄甑慕?jīng)歷，以及對其它公司的了解，我基本上沒有發(fā)現(xiàn)有一個團隊時積極主動地配合。

　　對于管理者，填日報或周報的動機，一般有以下幾種：

　　1、了解項目進度，以便及時調(diào)整。

　2、根據(jù)日志記錄的工時，決定本月的薪水。

　　3、觀察項目團隊各成員，看有沒有偷懶的，做績效考核時的依據(jù)。

4、根據(jù)工作日志，了解員工的工作負(fù)載及效率，以便改進績效。

5、根據(jù)日志記錄的工時，以便部門向總公司要人月開支。

以上幾種我都經(jīng)歷過，雖然1和2是比較積極的，但員工的配合意愿還是很弱。

我覺得，最核心的原因是，管理者和下屬之間，并沒有真正建立信任。

對于1，難道只有工作日志這種手段嗎?軟件開發(fā)，不像建筑業(yè)，每天的工作進度，是可以用眼睛來觀察的，并且進度幾乎是線性遞增。軟件開發(fā)，特別是設(shè)計和核心模塊的開發(fā)，一周的工作，很可能是前四天只完成功能進度的40%，后一天完成60%。如果項目經(jīng)理不懂這些規(guī)律，他看到那40%，肯定是心急如焚。

怎么解決經(jīng)理的焦慮呢?也許最好的辦法是，每日及時溝通和下屬主動反饋。但前提是，彼此間的信任。否則，下屬感覺經(jīng)理在催工，或者下屬也沒有反饋的勇氣，因為自己四天才完成40%。

對于2，即使員工每天坦誠反饋，但對于項目經(jīng)理，查看這么多人的日志，工作量很大，加上自己一忙，就忘了，反正也沒人監(jiān)督。但幾周后，員工發(fā)現(xiàn)他寫的日志只是一個擺設(shè)，于是也沒有記錄的熱情了，一兩句話了。

對于3、4、5，就不用說了，員工會徘徊在職業(yè)道德的邊緣。對于工作進度反饋，在敏捷過程Scrum里，有每日15分鐘的站立晨會，這是不用填工作日志的，呵呵。它的目標(biāo)是團隊間工作進度的溝通和協(xié)調(diào)。當(dāng)然，它有敏捷宣言做前提。我覺得，如果生搬硬套也不太靠譜，理由有兩點：

團隊中可能存在一些技術(shù)新手，他們每天完成Scrum M aster的期望進度不太現(xiàn)實，所以壓力會非常大，導(dǎo)致工作時焦慮，而不是Scrum M aster期望的強烈目標(biāo)感。有些工作是無法每天匯報進度的，特別是偏研發(fā)、技術(shù)攻關(guān)型任務(wù)，同樣也會讓某些成員焦慮、浮躁。

大家知道，軟件開發(fā)最好的狀態(tài)是relaxed、relaxed、relaxed?！?/span>

還有一種方法，就是IBM Rational里面的ClearCase和ClearQuest集成，開發(fā)人員每天的工作成果，就是commit自己的代碼，也就是ClearCase的提交操作(類似于CVS/SVN)，而提交時，正好用到