第一个 《工作日志制度》
1.工作日志制度的目的是形成严格的工作跟踪和积累习惯，要求部门中项目负责人以下人员按要求每日记录。
2.工作日志是部门员工的工作记录载体，起到部分绩效考核和浮动工资的确定依据的作用。
3.工作日志的格式见VSS***，包含每日计划和完成情况，每日工作始终时间，每日工作饱和度（5为最高，1为最低，如为请假，请注明“事假”或“病假”），次周计划，以及问题、意见和建议。
4.工作日志严格要求每日填写，绝不允许在上交前统一填写。
5.填写时注意清空原有内容。如发现某些栏目多周雷同的情况，将进行警告。
6.每日工作内容如无特殊情况，至少需要写3条以上。叙述工作内容要求尽可能说明清楚。不允许简单的如“修改错误”的描述。
7.工作日志严格要求在次周上午10:00前提交。不提交工作周报将按以下方式进行惩罚：N从0开始累计，每少提交一次，则N增加1，当月的浮动工资扣除“浮动工资额×10%×N”（元）。当月N不清零，转月后N方清零。对于未提交日志的人员，部门经理保证当周内口头通知。
8.工作日志以Email形式提交给部门经理和项目负责人。部门经理收到后保证第一时间进行回复，并依此进行考核。
9.文件名格式：《***工作日志（200*年*月*日）.doc》。其中***为员工姓名，日期为提交日期。

第二个 《项目月报制度》
1.项目月报制度是保证项目顺利推进的一种阶段性总结和计划载体的机制。
2.项目月报由项目负责人负责拟定。
3.项目月报应根据实际情况包含本月计划、完成情况（含计划的偏离情况）、成果和不足、突发事务及其解决情况、项目组成员工作情况、客户反馈情况、下月计划，以及问题、建议和意见等内容。
4.项目月报由项目负责人于每月第五个工作日以前，通过Email提交给部门经理，经部门经理审订后发布到Vss的项目月报文件夹中。
5.部门所有成员可以查阅已发布的项目月报。
6.项目月报的文件名格式为《***项目月报（$$$，200*年*月*日）.doc》。其中***为项目名称，$$$为项目负责人姓名，日期为提交日期。

第三个 《部门例会制度》
1.每月第一个周一上午10:30在公司会议室召开，部门所有人员（含参与部门人员为主导的项目并起核心作用的其他部门人员）参加。
2.会议由部门经理召集，并由部门经理主持。
3.会议议程：
a)各项目负责人回顾上月工作情况、成果和不足，以及当月的大致工作计划。
b)部门经理总结上月工作，对不足的问题提出解决办法。
c)部门经理宣布公司近期动态和相关事项。
d)部门经理做出工作方面的安排。
e)部门人员畅所欲言，提出问题、想法、建议与意见。大家讨论。
f)部门经理解答部门人员的问题，并做出总结。
4.部门人员轮流做会议记录，并在会议结束后第二天内整理并在Vss中发布。文件名格式：《软件二部200*年*月*日例会（***整理）.doc》。其中日期为例会召开日期，***为会议记录整理人的姓名。

第三个 《项目例会制度》
1.每周五下午在部门会议室召开，具体项目的所有参与人员参加。
2.会议由项目负责人召集并主持，部门经理根据实际情况列席。
3.会议指定固定人员做会议记录，并在第二周周一上午9:30前整理并通过邮件发送给项目负责人。
4.项目负责人修改并认可会议记录后，在第二周周一上午11:00前在Vss中发布。文件名格式：《***项目组例会（200*年*月*日）.doc》。其中***为项目名称，日期为例会召开日期。

诸如工作日志之类的，不客气地讲都是废话，套话。有没有对软件开发的效率都没有什么影响。

软件开发的管理的关键是*自动化*，尽可能将绝大多数的工作都使用软件自动化。

那么，大家对软件开发人员的工作积累、知识积累有什么看法？
特别是作为部门来说，进行开发过程中技术的积累有何有效的办法。出发点是希望新进的员工能够快速上手，少走一些老员工走过的弯路，不希望人走了，没有留下一点东西。

可能其他一些帖子也提到了这方面的解决办法，但是我还是希望得到大家更广泛的意见。谢谢！

一般会议是因为以下三个原因而开的：
1 显示权威（比如一个新的管理者来了，开个会，就是为了这个目的）
2 需要频繁，快速的决策（设计讨论会等等，管理例会，沟通交流部门协调等等）；
3 宣灌或者广而告之（做为一个改变或者一个启动，或者某一个消息让全部人员知道）

别搞了，没有人真的如此管理部门的……这种小事情都抓这么紧，你要让大家把注意力都集中在这些点上干什么？一个人能够干好的事情就那么几件，小事情就不要猛下重手管理了。你的管理精力也跟不上啊……
太累……而且效果也不好。

嘿嘿，你说部门管理不是软件管理，这一点实在很正确。但是你是用软件SCM的方式来进行部门管理，这恐怕不成吧……

管理者首要的两个能力是：平衡能力（在两个极端之间平衡），关键事务获取能力。一个部门，只要你愿意，每天都可以找到10个不足，但是这些不见得就是你现在必须解决的，和应该下手的。如果你认为这项工作最大影响了你的业绩，才需要下重手来整顿的，而且要精选不超过3个事务来推进，而且需要讲究推进步骤和此许，而不是这么一写，然后让大家执行。这种根本不是管理，如果这种也叫管理的话，我找一个大学讲授高级管理学的老师，给他配一个秘书就可以当管理者了，要我们干什么？

你需要找到对于你部门来说的关键业务，你不会真的认为通过这几个工作，你的业绩就会大幅度上升吧？我们只有一个情况下，进行了这种类似的要求，比如外出客户谈判的人员或者工程人员在和客户频繁交流的过程中，由于和总公司缺少联系，而且某些时候，做出了一写承诺，后期缺乏对承诺的监控，所以需要进行工作日志的提交。这件事我们是先和市场，产品，研发，过程人员一起设计了文档模板，然后交付给一个项目组使用，使用一个月后，进行过程修正。如果日志没有提交，我们仅仅是跟一份邮件而已，催一下这份邮件。不做更多的规定。

非常刚性的流程会导致很多问题，比如你说，晚于10:00提交，就扣工资。如果我出差在外，我一天都在联通本部和客户谈需求，我如何发？你该说了，这没有关系，回头给我发呗！那么其他被扣工资的人就一定是故意的？其实何苦来呢？一个简单的规定更容易执行啊……

累……累……你干得累，我也写得累……再举一个例子吧……

我们也开部门例会，也写会议纪要，但是从来不做你那种规定，在会议前指定一个人员为会议纪要者，然后，会议完毕以后，最多发一份提醒邮件，在2天里面写出来就是了。哪里值得絮絮叨叨搞这么多规定啊……比如我们的公司管理例会，每周都会各个部门协调一次，指定一个人写，然后下周会议的时候，我们会参考上周的Action point，如果那时候你拿不出来，就很难看。这样看起来没有硬性规定，但是实际上已经有了类似规定，不用什么10:00以前提交，你还真的去检查我的Checkin时间？看来你的精力还真的很充沛。至少我没有精力来管这些事情。

部门例会还搞得有固定话题，你就一定要用这个部门例会来介绍这种情况？这种工作汇报，和工作分配，难道你们就不能私下里整了他？别人的汇报和工作安排管我什么事情？我何苦要去听别人的工作任务，于是一个会议，和我有关的就是5分种，其他时候，就是歇着。这种成本巨高的会议，就没有其他方式解决了？就不能讲一些更有价值的东西？

看来你还真的是刚开始做管理者啊……