人件

 很粗略的浏览了一遍《人件》,发觉里面每个主题都很深入的反映了目前很多软件项目碰到的问题。里面提的很多的例子也确实在自己经历过的项目发生过。

书中提到软件开发中相应的知识可以分为3类:软件技术,软件人文,软件过程。软件技术我们不需要解释,软件人文强调的是人是软件项目中最重要的部分,人才是公司最重要的资产,而这一点在《人件》里面又得到充分的体现。软件过程说的是在软件开发过程里面如何里面CMM,ISO等标准规范应用到项目的管理,当然采用这些标准规范进行管理是非常正确的,但是在国内,很多企业确过度的追逐,从而走上了极端,在人与过程中间,他们更强调的是过程,而由于国内软件环境的不成熟,很多项目都是需求变化大,项目周期短,在这种情况下,他们往往就会牺牲人这一个最重要的资产。在《人件》里面有非常多的例子是这样说的!很万幸,我今天能处在一个以人为本的有良好的企业文化的公司!

结合目前的工作环境,《人件》给我感触最深的不是里面提到的如何以人为本,如何不能通过加班来促使项目的完成,相反,我觉得下面的主题使我进行了一些思考!

1.         错误限额

人非圣贤,孰能无过”,中国的先知们很早就给我们提了一个醒。人不是圣人,不可能是十全十美的。每个人都有自己的缺点,也自然会有自己的优点。一个人犯错误是难免的,其实犯错误本身并不是罪过,相反,对犯错误的看法确会导致这个罪过的加深。

   在一个软件的开发过程中,很多设计方面本质上就会有些缺陷的倾向,那么我们如何对待这种默认就会存在的错误倾向呢?我想《人件》里面提到的“应该丢弃而不应该是修补”这里体现的就是我们“有错就过”的原则,我想这个也是为什么RUP软件工程方法论里面强调的迭代式开发的根本思路吧!

   在软件团队的管理过程中,人是团队里面最重要的因素,人犯错的机会也是非常多的,一次的犯错误,我们不能就一棒子打死,因为这一棒子下去,他可能就真的“死”了,有错误就改正,改了以后,他依然是一个好孩子嘛!但是在现实中,确实存在类似的看法,很多项目经理因为团队的某个成员因为一个设计,一个想法是错误的,从而就认为这个人能力就不行了,也就认为这个人所有的一切都是不行的。其实这样的想法反而会对整个团队的团结带来影响。孰不知,换一种思路,通过亲切的询问下属走进过怎样的死胡同,纠正错误的根源,也许这样,能带来“柳暗花明又一村”的效果,其实,人们犯错误时,我们应该祝贺他们,因为他们从错误中,他们已经获得了进步的经验!!

2.         质量是免费的,但是只是对那些愿意为此付出巨大代价的人而言

质量控制是软件开发过程一个至关重要的环节,然而,在我们中国的大多数企业,在“质量”与“数量”上却更趋向于后者。《人件》书中提到这么一段话“在日本不存在质量与价格之间的交易,相反,高质量导致成本降低的思想却普遍为人所接受.”

我想通过这段话我们可以看出为什么日本的电子产业,日本的经济能在战争取得飞速发展的一个原因吧。当然,之前也曾经在CSDN里面看到很多在华的日本软件产品外部里面说过,日本人在开发一个软件项目的时候,由于对质量的过分要求,而导致项目的进度一再拖延的问题。可见,软件开发过程非常忌讳“过度“。

 质量是免费的,但是只是对那些愿意为此付出巨大代价的人而言。我想这句话是非常正确的。在我们实际的项目实施过程中,我们不难发现,用户最关心的是什么,那就是质量,一个软件产品的最终使用者是用户,而不是开发者本身,用户在使用中当然不希望产品到处存在BUG,到处出错。但是我们开发者本身却往往忽略了这种感受。他们把开发当成了一种艺术,当成是体现自己技术水平的一个练兵场。他们会为实现简单的功能而采用高深的技术,也许这一方面体现了你的技术,但是也许高深的技术带来的效应就是牺牲了用户的可操作性。或者是软件运行的效率。所以我觉得软件质量的控制不能光靠一个测试组的把关。也许,作为软件开发者本身,我们是否也需要进行深刻的思考呢?

   当然,由于项目的开发周期短,开发资源有限,很多人都会埋怨“我也想开发高质量的软件呀!”,从这一点,我们国内的很多公司都应该进行反省,但是我觉得,质量应该形成一种文化,只有一个公司,一个部门,一个团队真正形成了崇拜质量的文化,那么我们才能确实有效的保证我们产品的质量,才能确实的降低成本!!

3.         胶冻团队的概念

胶冻团队是形容一群紧密结合在一起的人,其整体大于部门的总和。我们在软件开发过程中到处都在强调我们是一个软件的团队,那么既然提到我们是一个团队,我们不妨检验一下。“一个团队的目的不是达到目标而是向着目标看齐”,《人件》里面提到一个胶冻的团队的最终标志是:人们在工作中“显而易见的快乐”,胶动团队是健康的,成员之间的相互交往是容易的,相互信任的,有共同目标的,并且充满热情的“,团队不同于“私党”,虽然他们表面上是一样的,但是“私党”代表着威胁,而团队代表着动力和快乐!对比一下,你的团队达到这个目标了吗?

4.         “送走”策略

“送走”策略在《人件》里面是送给管理者和监督者的。我想这个做法是非常对的。“送走”代表的是信任,是授权。书中说到,如果你招到一个适当的人做你的手下,那么要提高他们的成功机会,除了必要的一些交流外,你可能什么都不需要做,任何在空间上分开的任务都是一个美好的机会。

软件开发不同其他的生产过程,它是靠人们智慧的发挥和激情的迸发来完成的。直接的监督对开发人员来说会是一个笑话,他们会感觉跟犯人一样给限制,思维给限制了,自然生产出来的产品也就会给限制了!“送走策略”代表着管理者对开发团队的信任,对项目经理的信任,对开发人员的信任,而这种信任会激发他们的灵感,发挥他们的创意!同时,“送走”也代表着开发团队的完全自治,这样的工作时段给了他们改善的机会,也是他们能形成我们上面说的“胶动团队”,

如果你是管理者,你觉得对吗?很庆幸,我现在也处在一个具备这样信任的企业,我为我的企业骄傲!

     当然,还有很多的主题都分析得非常透彻,但是时间有限,主要就挑选以上的4点进行一个总结

 

原文地址:https://www.cnblogs.com/snowball/p/136277.html