刚毕业，进公司还不到一年，CM作为我人生的第一份工作，个人定位是——拼了！！！
   面对傲慢又“刚烈”的新进菜鸟们，反复地不认真写注释、下班不签入、上班乱签出、版本混乱、文件重命名、自己乱建视图、随便删除……实在是忍无可忍！
                             我要发威！    我要发威！！！    我要发威！！！！！
   恳请大家来帮帮忙！！！！！
   冲击第一波：我想在新员工培训中充分阐述“配置管理对软件生命周期的重要性”！
   先晒晒自己弱弱的答案：
          忽视软件配置管理可能导致的混乱现象：标识混乱；版本混乱；不能协同工作；已经解决的缺陷再次出错；找不到最新更新的源程序；找不到修改程序的责任人。
   由于并没有亲身经历过失败案例，所以上面的话对他们没威力、没气势、更没说服力！
   请大家各舒己见、畅所欲言！！！帮帮我吧！

你描述的这些，大部分都是CM自己的责任

和公司高层，或项目经理沟通，在他们的支持下制定一个cm的规范，什么时候要做什么，什么事情一定要做。
这样的事情只有形成规范和制度才能有效彻底的执行。

某些同志不要自己不知道怎么办，就随便发威啊！！！
从理论角度说服研发人员，配置管理的重要性！！！

我认为要先搞定老员工，而不是新员工。 如果老员工都是“守规矩”的，那么你只需要对新员工培训CC操作及注意事项。新员工都会跟老员工学样。就不需要发威了。
如果老员工都不“老实”，新员工再怎么培训都没用。只有上层出面，才可能整顿“环境”。

2::" />
有个部门就是这样！！！由于是核心部门，所以很“牛”！老人“牛”，新人就会有样学样！
“发威”的重点对象可以确定为老员工啦！呵呵！
其实没什么“发不发威的”？就是给自己增加点底气！

重点还是希望大家提出点自己积累的理论知识，我学习一下，并且把自己体会到的“关于配置管理重要性”合理地传达给执行者——研发人员！

光告诉别人怎么做才好其实没意义，大家都是聪明人，你说的那些道理其实很少有人确实不懂的，人家不按照规矩使用CC通常是有他自己的原因的（这些原因可能是方便，觉得照你定的规矩做麻烦），问题大多数时候在于：人家不按你说的做对人短期没有伤害（没有处罚），而又对人比较方便，所以很多人就不会遵守规矩了。
就好比开车超速，但凡司机都明白超速危险（LZ想发威的不外乎告诉研发人员这么做不对），毕竟开车时间越久，见到事故就越多，见到血淋淋的情况就越多，但是，为什么在没有超速摄像的路段依然有不少人超速呢？关键在于超速的司机认为：他那会超速不会有问题。而更关键的在于：那个路段没有超速摄像头！换句话说，他违反了规矩但没有受到制裁，这才是问题的核心。
换到CM上面来说，就在于研发人员不遵守你定的规矩（千万别说那个规矩不是你定的，如果这个规矩只有你在乎的话，这个规矩哪怕是其他人写的，哪怕经理在上面也签字了，都不管用，只能算做你定的规矩）而不会受到处罚，所以，要想办法让研发人员遵守他们的规矩，记住，是“他们”的规矩，也就是说，遵守研发人员们在乎的规矩。至于怎么达到这一点，多数时候需要从研发人员的领导去考虑，如果研发人员的上级支持你，你说的规矩其实就很容易推行了。
我经历过一个公司，老板很反感在开会的时候手机响起来，所以，公司里的所有人手机都是震动，新来的员工用不了几天全这么做了，原因是什么，很简单，如果你不想让老板不开心，就照他要求的去做。
至于研发队伍里的老人，我个人觉得当然要争取，可以起到表率作用，在某些时候还能代替你教新人怎么适当的使用CC。但其实最有效的，还是解决领导问题。或者，自己变成领导。呵呵，当然，如果你已经是领导了，那会你会怎么看你现在认为非常必要的规则，这个还就真难说了。

[ 本帖最后由 魔术师约翰逊 于 2008-4-25 20:11 编辑 ]

其实再说句打击LZ积极性的话，我仔细看了LZ的介绍（LZ毕业还不到一年），如果一个公司招聘到的CM是不到一年工作经验的人（没有轻视LZ的意思啊），公司就未必真正在乎CM工作，所以，大可不必太在意。
关键的问题在于多积累经验，知道那些想“发威”的东西就够了，适当的时候说一下，如果研发人员不听，领导也睁一只眼闭一只眼，LZ也就别在乎了，万一得罪了同事，没那个必要。
呵呵，这是一个工作超过10年人的经验之谈，LZ工作久了自然就明白这些道理了

[ 本帖最后由 魔术师约翰逊 于 2008-4-25 20:19 编辑 ]

大家都针对人来说这个事情。这个是很重要的一方面，领导对于CM的支持是必需的。另外，我就对事来说，关于工具本身如何去规范大家。
我假定楼主是用CC的。
对于开发人员的随意性，你提到
反复地不认真写注释、下班不签入、上班乱签出、版本混乱、文件重命名、自己乱建视图、随便删除……实在是忍无可忍！
1 到底哪些东西是可以让开发人员自由去做的。哪些是要限制起来的。
2 如何用工具去限制他并且又让效率提高。

那就针对你所列的情况，举些例子。

反复地不认真写注释
可以使用trigger做限制。你可以规定comments必须大于多少个单词或者字符才可以通过。否则拒绝checkin。

下班不签入（另外，请斟酌这个事情，除非你们做daily build）
貌似你作为管理员可以写个脚本帮助他们签入。内容正确与否，还是开发人员自己负责。

上班乱签出
貌似这个没有比较好的办法，但是对于特定目录和版本的东西，可以用Config spec或者trigger限制。随意签出其实问题不大。

文件重命名、随便删除
可以用权限来限制，只有admin才可以做这些事情。

自己乱建视图
也有一些限制部分的办法，但是没办法完全限制住。但是，如果一个开发人员能绕过你的限制，基本上他知道怎么用CC。那就不会出什么问题了。

版本混乱
貌似这是流程定义和你的问题了。

总之，建议前期限制的死一点，等习惯了再慢慢开放，提高灵活性。

流程和规范做好的同时也要把cm的服务提高上去！一些限制和帮助程序员做的脚本要到位！