1樓：吳成鋒
經常是某個情況下leader覺得需要加強管理而增加了每日日誌的需求，本身OK，需要堅持和持續的關注，經常性的是leader過一陣後就放鬆看成乙個可有可無的事項，幾乎不關注，進而流於形式；早會的形式會更好，讓所有人統一時間來交流，增強團隊互動
2樓：牛大寶
很多人認為專案管理的核心是計畫和執行，其實真正的核心是成本，不信的話可以仔細回想一下，專案管理的大部分的工作，其實最終目的都是為了降低成本而做的。
所以說，評估一下工作日誌、週報之類的管理措施，是增加了成本還是降低了成本，就知道為什麼推行不下去了。寫日誌、看日誌、控制日誌的內容質量、保障日誌的按時提交，這些都是要消耗成本的，如果管理者不去做這些事，就只是在辦公室裡等著日誌過來，時間一長會怎麼樣就不言而喻咯。
專案管理最忌教條，要懂得靈活變通，對於5人團隊，小型公司，每天早上開個早會，面對面溝通，效率更高，大家都輕鬆。
3樓：tiannet
在專案管理軟體的任務下寫日誌，說明對任務做了什麼，這樣分配任務的人可以知道進展。同時記錄耗時，這樣最後還可以統計完成任務共花了多久。
單純的寫日誌感覺意義不大。
4樓：小淘
5秒演繹乙個軟體專案的全過程： 「客戶演示 → 開發中槍 → 架構崩潰 → 開發被埋 → 經理跑路」請看圖：http://
dwz.cn/An2b4
5樓：劉磊
我們公司開發的產品就是SAAS的網際網路工作日誌，並且也在要求夥伴們用我們自己開發的軟體，每天寫工作日誌。通過寫工作日誌，已經實現了團隊既定的目標：做一家4點半下班的公司，給大家最大的工作自由度，同時又不影響我們的工作產出和市場競爭力。
首先，說說我們為什麼會開發工作日誌這樣的產品。原因其實很簡單：我們團隊轉型網際網路之前，是做企業外包服務的。
團隊人不多，10來個人，但有同事經常出差。以前我們溝通工作的方式是：開週會。
但發現以週為單位的管控粒度，對於我們這樣的初創企業跨度太大，因為開週會時確實能發現很多問題，但因為溝通或者響應不及時，這些問題已經木已成舟，糾錯成本非常高。所以，公司後來增加了晨會，但晨會的問題是：浪費大家的時間！
似乎每個人陳述自己的工作只需要2-3分鐘，但10來個人加起來就是半小時之多，如果溝通中發現有問題，再掰扯半天，這時間成本就更高了！而且最重要的是：掰扯的問題並不是和所有人都有關係，但卻需要所有人都參加這樣的會議！
再加上，個別同事如果有急事遲到幾分鐘等，溝通問題又需要他知曉，等他不等他，是個問題……糾結！所以，通過晨會溝通工作，貌似科學，但我們實踐的反饋是：效率太低！
所以，我們開始通過工作日誌的方式來溝通工作！但找了word、郵件、QQ空間等等很多任務具，感覺寫日誌都不方便。所以我們一怒之下，自己做了乙個，這是後話。
作為團隊創始人，我同意樓上說的：如果你自己不寫，而且同事寫了日誌你也沒有反饋，那麼請你不要要求大家寫工作日誌！
因為寫工作日誌的目的是：讓團隊的工作資訊快速分享、流動起來！
以前我自己也有個誤區：認為工作日誌是領導檢查員工工作飽和度的手段，所以領導忙可以不寫，但員工要寫。但實際上：
往往這樣的公司實施工作日誌制度一定用不起來，因為出發點就有問題！工作日誌對自己的作用是：幫助自己回顧整理一天的工作；對於團隊的作用是：
讓工作資訊在團隊中快速流動起來。以前，我也經常「怪罪」我們團隊的個別夥伴做事情不夠積極主動：分配的任務你不過問，從來不會主動反饋。
但換位思考，管理者的這種想法其實有問題：因為我們曾經作為基層員工時，也搞不清楚究竟哪些任務對於領導來說是重要的，是值得專門花費時間去找他匯報，而且這種匯報可能還會打斷他的工作！作為基層員工，我覺得實在是不好意思啊！
但現在通過工作日誌這種方式，員工只需要在工作日誌的成果裡面@一下自己的領導就可以了。通過工作日誌這種方式的交流，我覺得最能夠節省團隊的溝通成本。
廢話少說，上圖：我自己寫了5年的工作日誌（以前是用word、郵件寫，後來才用日事清寫）
我公司同事寫的日誌（他是異地辦公，在成都，我們團隊在北京）
每天只需要把日誌@給團隊相關人員即可。
我們採用的是KPTP的模式來落實工作日誌：
K：keep，今天做了哪些工作；
P：problem，遇到了哪些問題；
T：try，計畫如何嘗試解決這些問題；
P：plan，明天的計畫是什麼。
我們開晨會、寫日誌、找別人溝通，不都是為了了解這些資訊嗎？所以，寫日誌只是手段，能夠找到一種適合團隊的方式來做好團隊效率管理，才是最根本的目的。
6樓：狩月
現在有一些人（團隊負責人，專案經理，專案主管），看了一些管理的書，尤其是敏捷相關的書，便開始折騰，早上以來，開站立會，每天下午四點前，寫日誌，更有甚者，每個小時都要寫，徒的其表，未得其神而已。
就日誌而言，完全沒有必要，因為：
1、作為小團隊（5-10）人的負責人，你應該也有責任知道，每個人在做什麼，如果不知道，那是你的失職。
2、專案成員需要向您報告進度，但是這個週期不是以固定的天為單位，而是已開發人員自己的開發進度或里程碑為單位
3、你應該有專案計畫或者專案控制手冊，這上面的週期也是你去主動了解的週期，而不應該是天。
7樓：李會軍
3. 與其讓每人每天提交乙份工作日誌，還不如在下班前來個5分鐘站立會議，一切問題都可以搞定。
廣告相關：上面的截圖來自於我們自己開發的專案管理工具 Worktile 中的日曆檢視， 同時還可以根據任務完成情況自動生成每天的進展，所以不要再讓開發人員提交工作日誌了。
8樓：海綿寶寶
哎，老闆最近也剛出這樣的規定，個人覺得小企業沒必要，每天匯報沒必要，改成每週或每月匯報還行。這樣的規定讓很多員工都會心裡不爽，感覺公司不信任自己，也讓員工有牴觸心理。
9樓：Jessie Dai
每天提交工作日誌這個應該通過部門管理制度加上軟體系統來解決，不能變成某個專案的個別要求。如果其他專案不要求，只有你的專案要求，誰搭理你呀。
10樓：will
如果是五人的小規模團隊，可以從兩方面入手，
一方面是從上而下的為組員分配任務。這個事專案而定，是一周一次還是一月一次。
另一方面是從下而上的追蹤各個任務的進度，這個可以通過每天三十分鐘的會議，讓每個組員匯報下手頭任務的情況，完成度，是否遇到瓶頸即可。
11樓：楊林
我會讓員工自已都寫乙份，是給自已的，今後可以整理自已都有哪些工作與進步。
另外每個月可以將本月的記錄進行部分摘錄，然後通過內部郵件系統抄送所有同事與領導。（抄不抄，抄給誰，寫什麼，都是自願，不強制）。
12樓：姚君林
對於運營中的專案沒太大必要，都是定週期目標，對於急需上線的專案每天下班或者第二天上班開個10分鐘晨會讓每個人通報昨日工作這樣溝通更快更高效。
13樓：
剛開始大家不習慣，以身作則，實踐一段時間，慢慢出來效果就好了。還有啊，要及時糾正日誌的內容，讓大家一起評判寫那些合適，那些對工作有用。調動每個人的積極性，這樣才好推進工作。
14樓：
1. 提出要求的傢伙官癮犯了。
2. 提出要求的傢伙是人力資源部的？
3. 提出要求的傢伙太閒了？
4. 提出要求的傢伙新官上任？
5. 提出要求的傢伙有強迫症？
15樓：風影
這也是近期糾結的乙個問題，其實寫工作記錄很多時候是為了整理思維，提高工作效率，不是為了給領導檢查。怎麼讓團隊成員養成這樣的習慣才是關鍵。
16樓：兔子
如果是大型團隊，這個很有必要，需要讓行政領導和專案領導及時了解進度和負荷。如果是小型團隊，就是扯淡！這些所謂的管理者，真的不清楚每個人的工作及進度？
17樓：徐寶強
挺好的。軟體開發進度總是要管理和控制的，區別就是控制的粒度問題了。每日控制進度，是比較細的粒度，不過一定沒有什麼問題，不管怎麼說，進度匯報都不會是一件繁瑣的事情。
而且如果是採用敏捷的開發方式，每日站會，實際就是一種進度的彙總，已經是比較經典的軟體開發模式了。
而這個對個人的附加好處，也是比較顯見。長期記錄以後，對於個人的時間管理，也會起到很好的輔助作用。
在APP的開發過程中，作為設計師，如何說服程式去實現動效？
Reiki 說服他，我為什麼需要實現這個動效，這個效果可以給產品互動層面或是使用者帶來什麼。最好是可以製作出demo。讓他感受一下有動效和沒有動效對產品使用者體驗上極大的差異化。去拖動RD的開發。 哈哈，前一段時間剛剛實現了讓團隊裡的部分前端從牴觸動態特態到主動要求新增動態特效的過程。你說是不是很有...
遊戲開發程式設計師在開發遊戲過程中是不是就已經達到了該遊戲的職業水準？
magwer 哈哈哈哈哈哈，我就經常被自己玩家虐。所以設計者肯定打不過玩家啊。這問題應該改一下，因為程式設計師只寫邏輯和演算法，一般不去設計規則的。真正設計遊戲的是策劃。題主的意思應該是，遊戲設計者是不是達到職業水準，而不是程式猿。這裡不考慮每個人反應速度和首腦協調性的差異，單說遊戲理解，設計者也是...
遊戲開發過程中，技能與技能之間的關係如何設計比較好？
meta 有互斥 替換 疊加 共存，4種關係 buffID tag列表 互斥ID列表 替換tag 是否可以替換 優先順序 填數值，可以替換時，優先順序數值高的替換優先順序低的 最大疊加數 填1代表不可疊加，大於1時表示最大疊加數 要給host加上buffset B，foreach A in host...