精英化的团队是不是能完全解决代码质量的问题战功文化会引入什么样的代码管理问题以下是我对这些问题的思考。
代码之于程序员,就像沙场之于将军。普遍希望完全控制代码,可以自由驰聘、攻城掠地。但对于一个团队合作下的代码,这种行为却隐藏着极大的风险。特别是在一个崇尚战功文化的团队里,在鼓励大家承担更多责任的同时,同时也要注重对代码上的领域限制和约束。在一个较大开发团队中,模块级的代码权限管理仍然是不足的,需要引入代码文件的权限管理。但管理上普遍受到某种认识上的限制。
代码管理上的问题
人的问题也是管理的问题
强调人的态度是咱们的习惯。精神、意愿、态度,甚至人品,都是我们在平时工作中被反复强调的。工作上也讲究树典型,人带人的工作方式。这一切在那个物质缺乏的时代都曾发挥到极致,精神上的引领发挥着很大的作用。但数十年过去,那一切又充满着非议。
人的问题不能被忽视,但不应该在整体范围上去看。就是不能用集体的意志去抹杀个人的意愿。人性的优缺点必须正视,正如人人都会犯错一样。如果犯了一次错,就被扣上个标签,显然是不明智的。
在现实中,中式管理强调主观能动性、系统和整体观,对个体和细节的把握不足。正因为对具体管理方法的无力感,让我们更易于接受从人的角度思考问题,本来的一个具体问题,转变成一个精神指导的问题。事实好办了,定个目标,强调细心、认真、严谨之类的做事态度,再宣传几个典型发挥一下影响。有没有让你想起我们小时候的小红花。我们就是被这样哄大的,我们也都知道,典型也有犯错的时候,一时的典型,绝不代表是永远的典型。
这样的管理方式,就是那种不可说的境界。一切都是混沌的,模糊的,只有方向,一切都在某种不可言明的力量作用下发展。好了,成了,一切尽在掌握中。如果没做好,那只能说是时候未到。于是我们造出了高精尖的科技,但却生产不出令人放人的奶粉。我们创造的技术,一到量产就问题百出。这一切都源自抓大放小的思想。
有没有办法让管理正视细节,正视具体问题关键在于去除不必要的心理负担,建立流程和方法。用流程来约束,用方法来指导。
积极性的辨证
回到代码管理上来,最大的心理障碍是担心影响程序员的积极性。 这里面有两个问题,一是积极性和代码管理的约束是否有真正的联系。第二个积极性的问题是否真得重要到成为管理的障碍。
对于第一个问题,什么是积极性束是否会影响积极性其实取决于大环境下的价值观,而不是个人的态度。是画个圈说明利害,还是等到实际遇到问题,再做抉择做事的时候,相对于不能自由发挥,更怕得不到清楚的定义。所谓计划赶不上变化,变化赶上老板一句话。自己做得很辛苦最后发现方向错了,这不是很悲哀了。
当然约束多了不是件好事,特别是进入到微观管理的状态,那确实很可怕。那还是在流程定义走入了误区。
流程定义要达到的效果是最大化地减少人为的犯错的可能,做前有预期,做时有范围有方法,做后有检查。奖惩是辅助手动,不能把它当成流程定义来使用。
再谈一下战功文化所带来的问题。 积极性显然在战功文化里是非常受到鼓励的。可如何来保护积极性证它能带来好的结果呢个程序员都负责一部分功能,像是一地的诸候,积极经营自己的领地很好,但如果是去管理别人的领土,就有待商榷了。虽说鼓励内部竞争的机制一直就有,也很有帮助。就事论事,在一些复杂的产品研发内部推动就可以引入不必要的危险。判断的条件就是是否能够很好地理解别人的思维和设计。一点误判或者一点信息遗露都可能带来新的问题。这样的积极性需要鼓励,更需要指导和约束。
第二个问题,积极性很重要,但它真得重要到不允许用管理的方法约束它吗显然不是,在这种想法的背后其实还是有了前面提到的心理负担后,认为没有找到一个”适度”的方法。只要问问是公司的前途重要,还是积极性重要,答案就是很清楚了。
这里有些危言耸听了们都知道当代码有了味道(代码大全中的提法),就等于开一个破窗,如果没有果断的改正措施,未来一定会消失在温水煮青蛙的悲剧中。现在那些看起来轻松方便的行为正在引入更大的风险!
方便与有序
我们都爱自由,可是当自由伤害到别人的时候,就是要受到约束。当我们在享受便利的同时,也要承担一定的责任来维护这个环境。一次超车就可能导致大家一起堵上半天,倒不如按顺序来得快。所以方便要建立在有序的基础上的。
问题是如果没有人让我们排队,没有人告诉我们如何排队(显然医院、银行、学校饭堂这些地方的排队方法会有不一样的方法),失序就成了必然事件。失序意味着问题,而不是风险。带来的伤害可大可小。
原本代码管理就有权限一说,但是常常界定在大的模块间,目的通常在于保密。而在一个部门内部,权限是通常不明确的。内部的程序员仍然可以去修改自己觉得不合理的地方,这就是问题所在。
流程建设的重要性
对于一个研发团队而言,让人人享有自由最好的方法就是定义出约束。由标准的流程做为基础形成良性的动力。公司发展节奏越来越快,越容易忽视基础建设。当人人都忙于需求和解Bug时,基础问题会逐渐吸引风险,然后在某个时间引爆。似乎有点做得越多,就会错得越多的意思。当在开发过程开始迁就某个历史设计或者行为时,就表示基础问题已经出现了。
在写代码上,大家都有重构的意识。而在管理上呢,何尝不需要重构!小步慢走进行流程上的重构也是Scrum一个实践。
流程提供的是一个明确的框框和方法,在不同的阶段使用不同的管理方式,也是应对具体问题的策略。如果全以人的问题来视之,多少有些自欺欺人。为什么国外优秀的实践到国内总会变味中国太聪明了,总会用自己的理解和自己习惯的方式来看待问题、解决问题。在这个过程中,无法实实在在的面对具体细节问题,所以结果就会有其形,无其实。
(我们总将程序员的时间限定在编码、做需求、解Bug之类看似直接支撑业务的事情。反而对于基础的生产力提高是依赖于程序员个人的发现和创造。可是如果程序员都已经在忙着做具体的项目,哪有时间做更精细的优化。细想一下,也能在东西方思维的差异上找到答案。想想为什么西方人在基础学科上的成就更大
错的事情,做得再多也是错的! 当然对与错是相对的,但至少要了解我们的问题。
这是我们流程建设方法上的不足!面对实际问题寻找解决方案就是出路所在。
代码责任制
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!