目前，不少稍上規模的研發團隊都要求員工寫工作日誌，而且推行工作日誌的管理初衷也是五花八門。然而，我們以為，下面的這幾種讓員工寫工作日誌的出發點都不大妥當，讓研發工程師寫工作日誌，最好不要給出下面的4個理由。
一：通過工作日誌，可以讓員工養成良好的工作習慣。
為了支撐這個理由，有些研發主管可能會讓他的員工去學習一下「戴明環」（pdca），也許還會推薦他們去閱讀時間管理大師阿代爾的傑作 《時間管理》，甚至還能給員工引入 「時間管理」的培訓課程！
然而，這一條理由僅對有上進心或自我約束能力強或「比較聽話」的員工是有效的，你卻不能指望你的團隊裡大都是這類員工。因此在面對每天都要填寫工作日誌這件事情上，很難說這個理由能讓他們欣然接受。畢竟，如果僅僅是為了讓員工養成良好的工作習慣，真的沒必要用工作日誌來達到這個目的，因為這個做法的投入產出比實在不高。
二：通過工作日誌，主管可以了解到員工的工作進度。
這的確是部分研發經理們期望推行工作日誌達到的目的，可是，如果乙個經理離開工作日誌就不知道某個員工的工作進度，那麼經理們可以自問一下：我真的不能只關注員工們的工作結果而需要去關心他們的工作過程嗎？如果回答是要關心過程，那麼再問自己乙個問題：下發的任務是否過大或持續時間過長？如果還有別的原因要了解過程，為何不直接與他們坐到一起而要自己獨自呆在自己的辦公室裡看工作日誌呢？
如果第一條理由是主管推薦員工去提高，那麼員工可以很容易針對這個提出反對理由，推薦自己的主管去學習一下scrum開發模式，了解一下何為「以結果為導向」，並研究一下如何建設「自組織的研發團隊」。
三：通過工作日誌，可以促進主管與員工的雙向溝通。
是的，不少公司就是這麼幹的，特別是一些大公司更是如此，多麼官僚的做法！為達到此目的，他們甚至還設計了一套極其複雜的日誌記錄格式。要求員工填寫在工作中遇到的困難，需要哪些幫助？主管們看到員工在工作日誌中的求助，就會盡量去協調解決日誌中提到的問題。筆者在以前的大公司工作時，倒是經常看到員工填寫了大量需要主管協助的事情，但是主管們一點反應都沒有！遇到工作中的困難，為何員工不是主動去找辦法克服，而是讓他們將困難寫到工作日誌中，然後讓他們等待你去幫助協助解決。
溝通首選面對面直接溝通，其次是msn，qq，內部**等實時溝通，最次才是email，**，週報等間接溝通手段。因為填寫工作日誌需要團隊所有成員較大的時間付出這個因素存在，可以說採用工作日誌來促進工作的雙向溝通是最沒效率的做法。通過工作日誌來促進雙向溝通與通過召開會議來了解專案進度是研發管理者最容易犯的兩個錯誤做法。
四：通過工作日誌，有助於更好的開展量化的績效管理。
是的，的確有些團隊在借助於工作日誌搞績效管理，但是這是不恰當的。怎麼可以針對乙個人某天做了某件事情來做績效量化呢？績效考核怎麼是針對過程而不是針對目標所達到的結果來進行的呢？而且作為主管，每天都將時間耗費到對這些瑣碎的事情的評價上而不是把精力放到其他更加重要的地方，這是多麼糟糕的一種情況！
上面四條理由，都不是很恰當，那麼為何我們還要寫工作日誌呢？
未完待續。
20070323工作日誌
11 32 今天先來第一件事就把昨天查詢的開題報告資料copy到電腦上 然後就開始寫開題報告，這個開題報告真麻煩 分開題報告 文獻綜述和任務書三個部分 開始以為有怎麼資料，湊湊copy應該就差不多，後來發現pdf中copy出來的都是imag 根本沒法用，那只好晚上找 找了半天，弄弄，還是沒搞完 頭都...
20070329工作日誌
2007 3 30 10 29 28日後來就寫日誌,一直寫到下班 至於debug fz模組,昨天debug了一下,和tg模組差不多,只是在讀取role配置檔案時有所不同,側重點不同 2007 3 30 10 36 29日就是正常上班 處理了醫療模組中的乙個頁面新增和合管辦的頁面新增 增加了js驗證,...
20070330工作日誌
2007 3 30 10 29 28日後來就寫日誌,一直寫到下班 至於debug fz模組,昨天debug了一下,和tg模組差不多,只是在讀取role配置檔案時有所不同,側重點不同 2007 3 30 10 36 29日就是正常上班 處理了醫療模組中的乙個頁面新增和合管辦的頁面新增 增加了js驗證,...