1,265
社区成员
发帖
与我相关
我的任务
分享请大家探讨软件开发部门管理的一些制度
担任部门经理有一段时间了，但是由于公司一直没有明确、正式的制度颁布，所以部门也没有正式发布一些部门管理和项目管理中的必需制度，基本是在口头上传递一种惯例。
今天心血来潮，一口气把过往的惯例写成了文字。当然里面主要是部门管理的内容，基本不包括项目开发过程的管理，请大家多多给意见：是否有不完善不周到的地方，是否会有适得其反的可能？谢谢！
第一个 《工作日志制度》
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. 工作日志的格式见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》。其中***为项目名称，日期为例会召开日期。
...全文
请发表友善的回复…
发表回复
isrose 2005-05-24
- 打赏
- 举报
写工作日志,还是写工作周报,还是由自己决定,如果自己不想浪废时间,应该在每天的下班之前,总结一下自己的一天做了些什么?如果你不是这种人,那就随波逐流把
jyy7751 2005-05-24
- 打赏
- 举报
工作日志没必要，有周工作计划和周工作总就行了
caishihu 2005-05-23
- 打赏
- 举报
看了一半看不下去了，无语。。。
同意 wolfhe(城墙) 的观点
同意 wolfhe(城墙) 的观点
fita 2005-05-23
- 打赏
- 举报
很明显，这是一个无所事事的经理，为了给自己一个“部门全在我管理之下”的感觉，制定的一个骚扰员工正常工作的制度。一个无用的制度，有以下几个特征点：
1、这个制度完全是为管理人员服务的，对员工一点用处也没有。比如工作日志，好的工作日志是为了帮助员工总结经验，提高工作效率用的，可是管理人员只关心他的形式，并不关心它的内容。
2、制度只规定了员工应该干什么，对管理人员自己没有任何限制。员工不按时提交周报会被罚款，部门经理呢，不看员工填写的周报好像也没什么大不了的。部门经理只要每天看看email,做做paper work，就可以安然拿你的高薪了。
3、即使现在公司没有任何业务可做，这份制度仍然可以让员工处于忙碌之中，虽然大家都知道这些事情带不来任何收益。
伙计，这不是管理！废除这些制度吧，程序员们会感谢你的
1、这个制度完全是为管理人员服务的，对员工一点用处也没有。比如工作日志，好的工作日志是为了帮助员工总结经验，提高工作效率用的，可是管理人员只关心他的形式，并不关心它的内容。
2、制度只规定了员工应该干什么，对管理人员自己没有任何限制。员工不按时提交周报会被罚款，部门经理呢，不看员工填写的周报好像也没什么大不了的。部门经理只要每天看看email,做做paper work，就可以安然拿你的高薪了。
3、即使现在公司没有任何业务可做，这份制度仍然可以让员工处于忙碌之中，虽然大家都知道这些事情带不来任何收益。
伙计，这不是管理！废除这些制度吧，程序员们会感谢你的
Blackwings2005 2005-05-22
- 打赏
- 举报
项目在危机时刻，每天写日志也是一种好方法，因为日志本身对每个人也是一种鞭策。
但不能总是这样，大家压力过大，容易疲惫。
我觉得领导最需要作的一件事情就是给大家定好高压线，在高压线以内很安全，可以自由发挥，
但碰了高压线必死无疑。 所以高压线制定的尺度要合适。
因为不了解楼主的团队是什么样的性质，所以不敢乱下结论。 如果是生产性质的，不用作
日报，因为通过每天生产出来的产品就能看出来进度。 如果是创造性质的，有日报也看不出进度来
，因为花了时间也不一定就有成果。
但不能总是这样，大家压力过大，容易疲惫。
我觉得领导最需要作的一件事情就是给大家定好高压线，在高压线以内很安全，可以自由发挥，
但碰了高压线必死无疑。 所以高压线制定的尺度要合适。
因为不了解楼主的团队是什么样的性质，所以不敢乱下结论。 如果是生产性质的，不用作
日报，因为通过每天生产出来的产品就能看出来进度。 如果是创造性质的，有日报也看不出进度来
，因为花了时间也不一定就有成果。
lxf_1976 2005-05-20
- 打赏
- 举报
对于日志的一点小意见：
两种方式：
1. 如果大部分员工适应自己写日志并提交，就这么做；这样Leader或PM会轻松一些，但员工多一项工作。
2. 如果大部分员工不适应或抵触自己写日志，就Leader或PM辛苦一点，主动了解并记录日志；这样的结果就是一个人辛苦，其他人能轻松一些，至少不必关心何时要写日志了，怎么写今天的日志等问题。
结论：了解每天的工作情况是对项目负责的一个基本条件！
两种方式：
1. 如果大部分员工适应自己写日志并提交，就这么做；这样Leader或PM会轻松一些，但员工多一项工作。
2. 如果大部分员工不适应或抵触自己写日志，就Leader或PM辛苦一点，主动了解并记录日志；这样的结果就是一个人辛苦，其他人能轻松一些，至少不必关心何时要写日志了，怎么写今天的日志等问题。
结论：了解每天的工作情况是对项目负责的一个基本条件！
yohomonkey 2005-05-18
- 打赏
- 举报
个人感觉：制定还是来规范工作，不要过多对人进行束缚，这样才有效；因为管理的目的在于达到组织的目标、其次再是优良的员工。
建议楼主去掉工作日志中对条数的限制，留个空间给你的员工去发挥，有责任心的，日志自然清楚明了；日志都作不好的，多少都有原由的，要靠你去发现问题。这样不是很好吗？都限制死了，大家都一样了，反而看不到了问题。
建议楼主去掉工作日志中对条数的限制，留个空间给你的员工去发挥，有责任心的，日志自然清楚明了；日志都作不好的，多少都有原由的，要靠你去发现问题。这样不是很好吗？都限制死了，大家都一样了，反而看不到了问题。
hoopp 2005-05-13
- 打赏
- 举报
开发部制度：
1、不允许超过两天的不来上班又不跟部门主管打招呼。
2、不允许超过半天不见人又不跟周围的人打招呼。
3、不允许在核心工作时间玩游戏，同时不允许在非工作时间影响别人玩游戏。
4、不允许上网闲逛被公司董事会的人看到。
5、不允许完不成交给的开发任务。
6、不允许不动脑，什么都要别人指点清楚，只会做明确的事。
1、不允许超过两天的不来上班又不跟部门主管打招呼。
2、不允许超过半天不见人又不跟周围的人打招呼。
3、不允许在核心工作时间玩游戏，同时不允许在非工作时间影响别人玩游戏。
4、不允许上网闲逛被公司董事会的人看到。
5、不允许完不成交给的开发任务。
6、不允许不动脑，什么都要别人指点清楚，只会做明确的事。
yjr332533 2005-05-12
- 打赏
- 举报
楼上说的有道理。
wolfhe 2005-05-12
- 打赏
- 举报
我觉得楼主簿要费那么多心思在制定制度上，你得有些制度实际很苛刻，制度的目的是为了完成更好的工作。完成工作的最好手段是让手下自愿自觉的去做事，所以挖掘他们内在的潜力和主动性尤为重要。当然必要的制度也是需要的，但是我看你的很多东西过于苛刻和古板。
cocosunshine 2005-04-25
- 打赏
- 举报
不太赞同几位的说法，很多大公司都要求日志，我觉得这个都是具体的细节制度，必须量化到一定程度。。不然就是虚无缥缈的东西，根本没有办法执行，其实楼主要做的不是花太多心思在制定制度上，而是在了解员工对制度的想法，以及如果让员工能够充分理解你所定的制度上。
thundersoft 2005-04-18
- 打赏
- 举报
mark
loveisbug 2005-04-15
- 打赏
- 举报
我倒是赞同日志。这也是个人的时间管理。关键是怎么推行这个，让大家觉得每天花点时间开始时想想自己要做什么，结束时想想做了什么是对自己有好处的。量化考核在这里会使之流于形式。
BigSamuel 2005-04-15
- 打赏
- 举报
细细又琢磨了一下，发现大家思考问题的角度其实是有所不同的，关注的重点也不同。
能够通过大家的角度了解不同的关注重点，也是好事。但是毕竟部门管理者和软件开发人员的看法肯定有所不同，甚至存在冲突。我们需要的不是冲突甚至对立，我们需要的是理解和配合。我想这可以作为大家探讨的一个基点，可能会更有成效一些。
能够通过大家的角度了解不同的关注重点，也是好事。但是毕竟部门管理者和软件开发人员的看法肯定有所不同，甚至存在冲突。我们需要的不是冲突甚至对立，我们需要的是理解和配合。我想这可以作为大家探讨的一个基点，可能会更有成效一些。
BigSamuel 2005-04-15
- 打赏
- 举报
多谢3位的宝贵意见！
那么，大家对软件开发人员的工作积累、知识积累有什么看法？
特别是作为部门来说，进行开发过程中技术的积累有何有效的办法。出发点是希望新进的员工能够快速上手，少走一些老员工走过的弯路，不希望人走了，没有留下一点东西。
可能其他一些帖子也提到了这方面的解决办法，但是我还是希望得到大家更广泛的意见。谢谢！
那么，大家对软件开发人员的工作积累、知识积累有什么看法？
特别是作为部门来说，进行开发过程中技术的积累有何有效的办法。出发点是希望新进的员工能够快速上手，少走一些老员工走过的弯路，不希望人走了，没有留下一点东西。
可能其他一些帖子也提到了这方面的解决办法，但是我还是希望得到大家更广泛的意见。谢谢！
redguardtoo 2005-04-15
- 打赏
- 举报
当务之急是确保每个程序员能够写出合格的代码。最低标准是每个人都会写断言。
诸如工作日志之类的，不客气地讲都是废话，套话。有没有对软件开发的效率都没有什么影响。
软件开发的管理的关键是*自动化*，尽可能将绝大多数的工作都使用软件自动化。
请参考我的blog
http://blog.csdn.net/redguardtoo
诸如工作日志之类的，不客气地讲都是废话，套话。有没有对软件开发的效率都没有什么影响。
软件开发的管理的关键是*自动化*，尽可能将绝大多数的工作都使用软件自动化。
请参考我的blog
http://blog.csdn.net/redguardtoo
beipiao 2005-04-15
- 打赏
- 举报
开发部门不适合搞工作日志，周志好一点
loveisbug 2005-04-15
- 打赏
- 举报
不太喜欢那些量化的东西
redguardtoo 2005-04-15
- 打赏
- 举报
比如说我遇到一个难题，在Linux开发环境下要让一个共享库能够定义自己的位置。
有两个方案：
1. 使用环境变量来硬编码库的位置。
2. 使用某种开源的库，该库有某种巧妙的方案可以使得共享库找到自己的位置。
针对这个特定的问题，有关环境变量的知识，或者“某种巧妙的方案”可以都认为是知识。
还有一种知识是知道只要google "GetModuleFileName +Linux"就可以最快地找到所有这些方案。
我觉得从商业来讲，应该关心的是最后一种知识，因为最后一种知识和前面的知识的关系是钓鱼的技术和鱼的关系。掌握了钓鱼的技术，就可以举一反三，花一倍的代价，给公司带来三倍的利益。
而且，针对某个特定问题，学习两个关键字的代价要比掌握某种巧妙方案的代价小的多。
以这个例子为例，公司首先要定义的是从“商业角度”来看，什么是知识。从学术角度来说，关于Linux内核的某些尖端技术是非常有趣的，从商业角度来讲，知道如何获得关键字才是最重要的。
有两个方案：
1. 使用环境变量来硬编码库的位置。
2. 使用某种开源的库，该库有某种巧妙的方案可以使得共享库找到自己的位置。
针对这个特定的问题，有关环境变量的知识，或者“某种巧妙的方案”可以都认为是知识。
还有一种知识是知道只要google "GetModuleFileName +Linux"就可以最快地找到所有这些方案。
我觉得从商业来讲，应该关心的是最后一种知识，因为最后一种知识和前面的知识的关系是钓鱼的技术和鱼的关系。掌握了钓鱼的技术，就可以举一反三，花一倍的代价，给公司带来三倍的利益。
而且，针对某个特定问题，学习两个关键字的代价要比掌握某种巧妙方案的代价小的多。
以这个例子为例，公司首先要定义的是从“商业角度”来看，什么是知识。从学术角度来说，关于Linux内核的某些尖端技术是非常有趣的，从商业角度来讲，知道如何获得关键字才是最重要的。
BigSamuel 2005-04-15
- 打赏
- 举报
我的部门现在其实已经是按照我上面的几个制度在执行中，而且同事们都积极配合，也取得了不错的效果。只是一直没有成文而已。大家的沟通也是很顺畅的，氛围也很好。可以说我现在这个部门已经有了很好的基础。我现在挖空心思来考虑这些问题，是为了更加规范，不仅保持这种状态，而且能够有利于部门内同事不断的提升和部门知识的积累。
提出知识积累这个话题，我是希望能够借助工具来实现。工具有很多种，最简单的可以自己部署一个简单的论坛，只要检索功能足够好用，而且大家也愿意执行，按照相对规范（也是为了更好的检索）来填写，就可以做到。
我是想向各位请教有没有实际的经验，或者有更好的办法来实现。
redguardtoo：非常感谢你的热心！能否提出一些比较有建设性的解决办法来呢？呵呵。
再次感谢大家！
提出知识积累这个话题，我是希望能够借助工具来实现。工具有很多种，最简单的可以自己部署一个简单的论坛，只要检索功能足够好用，而且大家也愿意执行，按照相对规范（也是为了更好的检索）来填写，就可以做到。
我是想向各位请教有没有实际的经验，或者有更好的办法来实现。
redguardtoo：非常感谢你的热心！能否提出一些比较有建设性的解决办法来呢？呵呵。
再次感谢大家！
加载更多回复（1）
