1. 配置管理是管理的一部分
UCM的前提是公司管理规范,井井有条,可是天底下去那里找这么好的小公司呢?哪个小公司的老板不是唯利是图?那个小公司的员工不是被公司压榨的毫无尊严?这种情况下不会有人考虑去规范公司的管理的,出力不讨好不说,还减少了浑水摸鱼的机会。
没有规范的管理,最直接的表现就是责权不清晰、计划混乱、计划无人跟踪细化、不知道向谁汇报、不知道谁在做什么、做错了也不会被追究责任、做得多也不会得到任何多余的好处......UCM是基于活动的,活动来源于计划,计划做不好,职责也不清楚,自然不可能用UCM了。
2. 培训成本太高
CC&CQ 的操作稍显复杂,开发人员会对很多操作不理解。这一方面是因为配置管理的观念没有深入人心,另一方面 CC&CQ 的界面也不是特别友好,开发人员也不会花心思去研究这个东东,所以很多对熟手来说非常简单的操作到了别人那里却很难实施。这种情况下,必然要求对员工进行很多配置管理的培训。可是实际情况是,小公司总是事比人多,哪个都耽误不起,怎么培训?
3. 员工素质一般不高
尤其是与人合作的素质、软件工程方面的素质
4. CC&CQ很多功能对一般企业来讲,根本用不上
一般的企业只要能够做到基本的版本管理也就够了,而CC&CQ的卖点并不在这最基本的功能上。比如配置审计、个人空间、多服务器......对小公司来说就是杀鸡用牛刀,不仅是成本上的浪费,而且也不可能充分发挥其效率。
倒是VSS和CVS以其小巧,更容易成为开发人员手中的配置管理利器。
5.性能不佳
实际使用的时候经常出现莫名其妙的慢,导致开发人员产生厌烦心理
6.管理和维护的成本
一个20人的开发团队,至少得有一个全职的CC&CQ配置管理员和若干的配合人员,不然根本别想用。
7.总结
看来选择任何工具之前,对工具的定位是很重要的,但也是很难确定的,尤其是对于一个没有经验的团队来说,首先要做的应该是优先选用便宜简便的工具,而不应当被一些产品的花里胡哨的功能和指标所迷惑,往往这些指标都是在一定规模下才会产生效益的。
工具永远不能代替管理方式,人的观念转变是第一位的,这个时候关键要看团队和领导的决心。如果没有决心,就不可能完成转变,那样的话啥啥都是空话...
UCM的前提是公司管理规范,井井有条,可是天底下去那里找这么好的小公司呢?哪个小公司的老板不是唯利是图?那个小公司的员工不是被公司压榨的毫无尊严?这种情况下不会有人考虑去规范公司的管理的,出力不讨好不说,还减少了浑水摸鱼的机会。
没有规范的管理,最直接的表现就是责权不清晰、计划混乱、计划无人跟踪细化、不知道向谁汇报、不知道谁在做什么、做错了也不会被追究责任、做得多也不会得到任何多余的好处......UCM是基于活动的,活动来源于计划,计划做不好,职责也不清楚,自然不可能用UCM了。
2. 培训成本太高
CC&CQ 的操作稍显复杂,开发人员会对很多操作不理解。这一方面是因为配置管理的观念没有深入人心,另一方面 CC&CQ 的界面也不是特别友好,开发人员也不会花心思去研究这个东东,所以很多对熟手来说非常简单的操作到了别人那里却很难实施。这种情况下,必然要求对员工进行很多配置管理的培训。可是实际情况是,小公司总是事比人多,哪个都耽误不起,怎么培训?
3. 员工素质一般不高
尤其是与人合作的素质、软件工程方面的素质
4. CC&CQ很多功能对一般企业来讲,根本用不上
一般的企业只要能够做到基本的版本管理也就够了,而CC&CQ的卖点并不在这最基本的功能上。比如配置审计、个人空间、多服务器......对小公司来说就是杀鸡用牛刀,不仅是成本上的浪费,而且也不可能充分发挥其效率。
倒是VSS和CVS以其小巧,更容易成为开发人员手中的配置管理利器。
5.性能不佳
实际使用的时候经常出现莫名其妙的慢,导致开发人员产生厌烦心理
6.管理和维护的成本
一个20人的开发团队,至少得有一个全职的CC&CQ配置管理员和若干的配合人员,不然根本别想用。
7.总结
看来选择任何工具之前,对工具的定位是很重要的,但也是很难确定的,尤其是对于一个没有经验的团队来说,首先要做的应该是优先选用便宜简便的工具,而不应当被一些产品的花里胡哨的功能和指标所迷惑,往往这些指标都是在一定规模下才会产生效益的。
工具永远不能代替管理方式,人的观念转变是第一位的,这个时候关键要看团队和领导的决心。如果没有决心,就不可能完成转变,那样的话啥啥都是空话...