软件部门管理(转载)

担任部门经理有一段时间了，但是由于公司一直没有明确、正式的制度颁布，所以部门也没有正式发布一些部门管理和项目管理中的必需制度，基本是在口头上传递一种惯例。
今天心血来潮，一口气把过往的惯例写成了文字。当然里面主要是部门管理的内容，基本不包括项目开发过程的管理，请大家多多给意见：是否有不完善不周到的地方，是否会有适得其反的可能？谢谢！
第一个 《工作日志制度》
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》。其中***为项目名称，日期为例会召开日期。

---

不太喜欢那些量化的东西

---

开发部门不适合搞工作日志，周志好一点

---

当务之急是确保每个程序员能够写出合格的代码。最低标准是每个人都会写断言。
诸如工作日志之类的，不客气地讲都是废话，套话。有没有对软件开发的效率都没有什么影响。
软件开发的管理的关键是*自动化*，尽可能将绝大多数的工作都使用软件自动化。
请参考我的blog
http://blog.csdn.net/redguardtoo

---

多谢3位的宝贵意见！
那么，大家对软件开发人员的工作积累、知识积累有什么看法？
特别是作为部门来说，进行开发过程中技术的积累有何有效的办法。出发点是希望新进的员工能够快速上手，少走一些老员工走过的弯路，不希望人走了，没有留下一点东西。
可能其他一些帖子也提到了这方面的解决办法，但是我还是希望得到大家更广泛的意见。谢谢！

---

细细又琢磨了一下，发现大家思考问题的角度其实是有所不同的，关注的重点也不同。
能够通过大家的角度了解不同的关注重点，也是好事。但是毕竟部门管理者和软件开发人员的看法肯定有所不同，甚至存在冲突。我们需要的不是冲突甚至对立，我们需要的是理解和配合。我想这可以作为大家探讨的一个基点，可能会更有成效一些。

---

我倒是赞同日志。这也是个人的时间管理。关键是怎么推行这个，让大家觉得每天花点时间开始时想想自己要做什么，结束时想想做了什么是对自己有好处的。量化考核在这里会使之流于形式。

---

知识积累是软件开发中的关键问题！
难点在于管理者和程序员对问题的认识有误区。
误区之一是知识的定义！
误区之二是对人的一般态度的判断！
对问题的认识还有误区，就要想当然地给出所谓解决方案，最后当然就是南辕北辙。
这就是为什么我看见很多国内的公司搞了很多日志，周报，晨会，周会，最后连基本的沟通也做的一塌糊涂，更不要说什么知识的积累了。

---

我 的部门现在其实已经是按照我上面的几个制度在执行中，而且同事们都积极配合，也取得了不错的效果。只是一直没有成文而已。大家的沟通也是很顺畅的，氛围也 很好。可以说我现在这个部门已经有了很好的基�>>Ｎ蚁衷谕诳招乃祭纯悸钦庑┪侍猓俏烁庸娣叮唤霰３终庵肿刺夷芄挥欣诓棵拍 谕虏欢系奶嵘筒棵胖兜幕邸�
提出知识积累这个话题，我是希望能够借助工具来实现。工具有很多种，最简单的可以自己部署一个简单的论坛，只要检索功能足够好用，而且大家也愿意执行，按照相对规范（也是为了更好的检索）来填写，就可以做到。
我是想向各位请教有没有实际的经验，或者有更好的办法来实现。
redguardtoo：非常感谢你的热心！能否提出一些比较有建设性的解决办法来呢？呵呵。
再次感谢大家！

---

比如说我遇到一个难题，在Linux开发环境下要让一个共享库能够定义自己的位置。
有两个方案：
1. 使用环境变量来硬编码库的位置。
2. 使用某种开源的库，该库有某种巧妙的方案可以使得共享库找到自己的位置。
针对这个特定的问题，有关环境变量的知识，或者“某种巧妙的方案”可以都认为是知识。
还有一种知识是知道只要google "GetModuleFileName +Linux"就可以最快地找到所有这些方案。
我觉得从商业来讲，应该关心的是最后一种知识，因为最后一种知识和前面的知识的关系是钓鱼的技术和鱼的关系。掌握了钓鱼的技术，就可以举一反三，花一倍的代价，给公司带来三倍的利益。
而且，针对某个特定问题，学习两个关键字的代价要比掌握某种巧妙方案的代价小的多。
以这个例子为例，公司首先要定义的是从“商业角度”来看，什么是知识。从学术角度来说，关于Linux内核的某些尖端技术是非常有趣的，从商业角度来讲，知道如何获得关键字才是最重要的。