在軟體項目開發過程中，要求開發人員每天提交一份工作日誌合理嗎？
公司屬於小型個人企業，主營生產製造軟體開發。
開發人員5人。出現的情況是：開發人員提交的工作日誌經常是斷斷續續的或者就是很長時間乾脆就不寫了。監管：老闆。我在想是否可以只要求每天早晨寫一份to do list的計劃解決？
我們公司開發的產品就是SAAS的互聯網工作日誌，並且也在要求夥伴們用我們自己開發的軟體，每天寫工作日誌。通過寫工作日誌，已經實現了團隊既定的目標：做一家4點半下班的公司，給大家最大的工作自由度，同時又不影響我們的工作產出和市場競爭力。
首先，說說我們為什麼會開發工作日誌這樣的產品。原因其實很簡單：我們團隊轉型互聯網之前，是做企業外包服務的。團隊人不多，10來個人，但有同事經常出差。以前我們溝通工作的方式是：開周會。但發現以周為單位的管控粒度，對於我們這樣的初創企業跨度太大，因為開周會時確實能發現很多問題，但因為溝通或者響應不及時，這些問題已經木已成舟，糾錯成本非常高。所以，公司後來增加了晨會，但晨會的問題是：浪費大家的時間！似乎每個人陳述自己的工作只需要2-3分鐘，但10來個人加起來就是半小時之多，如果溝通中發現有問題，再掰扯半天，這時間成本就更高了！而且最重要的是：掰扯的問題並不是和所有人都有關係，但卻需要所有人都參加這樣的會議！再加上，個別同事如果有急事遲到幾分鐘等，溝通問題又需要他知曉，等他不等他，是個問題……糾結！所以，通過晨會溝通工作，貌似科學，但我們實踐的反饋是：效率太低！
所以，我們開始通過工作日誌的方式來溝通工作！但找了word、郵件、QQ空間等等很多工具，感覺寫日誌都不方便。所以我們一怒之下，自己做了一個，這是後話。作為團隊創始人，我同意樓上說的：如果你自己不寫，而且同事寫了日誌你也沒有反饋，那麼請你不要要求大家寫工作日誌！
因為寫工作日誌的目的是：讓團隊的工作信息快速分享、流動起來！以前我自己也有個誤區：認為工作日誌是領導檢查員工工作飽和度的手段，所以領導忙可以不寫，但員工要寫。但實際上：往往這樣的公司實施工作日誌制度一定用不起來，因為出發點就有問題！工作日誌對自己的作用是：幫助自己回顧整理一天的工作；對於團隊的作用是：讓工作信息在團隊中快速流動起來。以前，我也經常「怪罪」我們團隊的個別夥伴做事情不夠積極主動：分配的任務你不過問，從來不會主動反饋。但換位思考，管理者的這種想法其實有問題：因為我們曾經作為基層員工時，也搞不清楚究竟哪些任務對於領導來說是重要的，是值得專門花費時間去找他彙報，而且這種彙報可能還會打斷他的工作！作為基層員工，我覺得實在是不好意思啊！但現在通過工作日誌這種方式，員工只需要在工作日誌的成果裡面@一下自己的領導就可以了。通過工作日誌這種方式的交流，我覺得最能夠節省團隊的溝通成本。
廢話少說，上圖：我自己寫了5年的工作日誌（以前是用word、郵件寫，後來才用日事清寫）
我們採用的是KPTP的模式來落實工作日誌：
K：keep，今天做了哪些工作；P：problem，遇到了哪些問題；T：try，計劃如何嘗試解決這些問題；P：plan，明天的計劃是什麼。 我們開晨會、寫日誌、找別人溝通，不都是為了了解這些信息嗎？所以，寫日誌只是手段，能夠找到一種適合團隊的方式來做好團隊效率管理，才是最根本的目的。俺就要求寫這個，古人說日三省吾身，俺只要求省一次，不會很過分吧。其實這東西對寫的人自己最有幫助，俺自己每天寫，過幾周或幾個月再拿出來看，就會發現很多問題，如果不是當時記下來，那些事情肯定是想不起來的。另外，俺的日誌抄送給所有員工，俺也要求每個人都抄送給俺，同時給他同組的所有同事包括組長，組長要看過同組所有人的日報並在自己的日報里總結整組的工作情況。俺對日報寫成什麼形式不強求，寫得認真的俺能看得出來，俺自己有固定的格式，大部分人都照俺的格式寫，如果有人有更好的形式，俺也會學過來放在俺的日報裡面，作為一種肯定和推廣的手段。日報不認真，沒條理的，俺也不會直接去批評，但是長期這樣的話，會給俺留下不好的印象，升職的機會會比較少。以俺的經驗，日報的質量與實際工作能力、成長速度有一定正相關。
如果你這天真的做了什麼，那就寫就是了，要什麼緊。這是一種控制項目進度的簡單有效的方法。
剛剛在公司推行jira，要求工程師每天log work，監督每個工程師有沒有做滿8小時的工作，想請教下各位國外IT界大牛是否有必要，是否有這樣做的優秀的IT公司？這個問題里做了類似的回答，這裡複製過來。
題外話：沒做過量化管理的人就不要回答這樣的問題了，題主的公司很明顯在進行量化管理制度的建設，如果是組建個敏捷團隊靠高薪弄一幫經驗豐富的人來，大家也不關心團隊性能細節，糊弄糊弄就混過去了，你們真的有管理經驗來秀么？
-----------------------------------------------------------------------------------------------------------
之前在一家美國公司做的時候推行過這樣的管理制度。
從管理的角度來說，記錄工作日誌這種事情毫無違和感，如果不需要你記錄工作日誌，而讓你寫工作日報，難道你就感覺舒服一些了？
這是兩條管理規則一起推動的結果，所以工程師認為記錄工作日誌是額外的工作。
我們公司當時是，先要求提交詳細的工作日報，精確到問題、小時，這樣執行了兩個多月，員工最初怨聲載道，後來逐漸麻木習慣，然後告訴大家一個好消息，在JIRA里直接記錄工作時間，一天只要湊7個小時就可以了！
這樣，只要誰還覺得在JIRA里記錄工作麻煩的，就讓丫自己去寫工作日報去。
JIRA進行時間管理，通過三個方面提高大家的工作效率：
- 總體工作時間要求：每周40小時；
- 每問題工作時間要求：平均問題解決時間，疑難問題識別
- 問題對工作內容的覆蓋率：任何超過一小時的工作都應創建問題
第一條要求工程師事無巨細都必須上報，第二條要求上報內容真實可靠。硬性要求總體時間後，工程師必須想盡辦法湊時間進去，而第二條，例如我當年，要求每問題平均解決時間為3小時，凡是超過3小時的必須寫明問題原因。這樣，工程師不敢在一個任務上面謊報大量時間，同時，靠這個辦法發現了大量平時掩蓋的問題，集中解決後效率提高不是一星半點。
配合Fisheye插件集成SCM工具，你可以看到，一個號稱花費了40小時的任務，到底有多少代碼變更。直觀的就可以識別出工作效率問題。這種證據是可以用在辭退工程師上的。
當年實施下來，有數名工程師離職，坦白說，都是濫竽充數的。有的離職時直接跟我說，本來就是圖個清閑，現在忙成這個樣，不幹了；有的是因為，幹了幾十個小時的任務，只有個位數的代碼變更。我們不是什麼研究演算法的團隊，這種事兒就是他娘的混。而真正有效率的工程師，勤懇的工程師，馬上就可以看出來。
管理者通過JIRA進行管理也同樣是要求很高的。最後一條是套在管理者頭頂的魔咒。管理者不能是渾渾噩噩的混子，而是應該對自己的團隊工作範圍有明確的定義，對團隊工作進度有良好的管理，這樣才能將所有的工作內容都使用不同類型的問題覆蓋。經常有這種實施失敗的案例，最大的問題並非工程師沒有執行，而是管理者水平太爛，和稀泥，於是就流於形式。
不說別的，如果問題能夠對工作內容實現完整覆蓋，很容易回答的一個問題是，團隊的生產時間佔總體比例是多少？如果回答不了這個問題，那是個什麼雞巴管理者就一眼看出來了。
Atlassian是什麼樣的公司，JIRA以及他們家的一大堆產品設計如何，在行業內的地位和水平都是無須諱言的。那麼，TEMPO插件火成這個樣子，難道老外都鹹的蛋疼？麻煩
這也是近期糾結的一個問題，其實寫工作記錄很多時候是為了整理思維，提高工作效率，不是為了給領導檢查。怎麼讓團隊成員養成這樣的習慣才是關鍵。
沒有必要，並且不僅耗時耗力，而且會將員工本來著眼於目標的努力轉移到著眼於應付考核、交出漂亮的答卷。
沒必要。我一般要求周報即可。
但也有一種情況要求日報：即有非常重要且上線時間緊迫的項目，需要進行嚴格的精細化管理的。要求開發人員每天提交一份工作日誌，我本人是很不喜歡這種做法的。
1. 如果做好了項目管理工作，每位成員每天的工作內容作為管理者應該是知道的，你都不知道自己的成員在幹什麼，說明你的管理出現了問題。難不成要等看了工作日誌才知道每位成員每天做了什麼？2. 作為項目管理者，始終應該有一副這樣的視圖放在你面前，並且該視圖可以按成員進行篩選，這樣就能準確知道團隊中每天該做什麼事，每個成員每天該做什麼事。
5秒演繹一個軟體項目的全過程： 「客戶演示 → 開發中槍 → 架構崩潰 → 開發被埋 → 經理跑路」請看圖：http://dwz.cn/An2b4
很low的做法時髦一點的做法是隔幾天看一下commits log, comments亂寫的罰做俯卧撐
周報還可以，有些模塊一天搞不定，連續幾天答「在做XX模塊」有意義嗎
to do list外加執行結果即可，畢竟小團隊，沒必要管理太過細
其實可以參照Scrum的方式，每天早上開個10分鐘的站會，每個人自己彙報一下。
現在有一些人（團隊負責人，項目經理，項目主管），看了一些管理的書，尤其是敏捷相關的書，便開始折騰，早上以來，開站立會，每天下午四點前，寫日誌，更有甚者，每個小時都要寫，徒的其表，未得其神而已。就日誌而言，完全沒有必要，因為：1、作為小團隊（5-10）人的負責人，你應該也有責任知道，每個人在做什麼，如果不知道，那是你的失職。2、項目成員需要向您報告進度，但是這個周期不是以固定的天為單位，而是已開發人員自己的開發進度或里程碑為單位3、你應該有項目計劃或者項目控制手冊，這上面的周期也是你去主動了解的周期，而不應該是天。
對於運營中的項目沒太大必要，都是定周期目標，對於急需上線的項目每天下班或者第二天上班開個10分鐘晨會讓每個人通報昨日工作這樣溝通更快更高效。