软件质量的“奥秘”(二)——质量的层次性(1)

来源:http://blog.csdn.net/KongDong/
作者:fasiondog


续上篇: 软件质量的“奥秘”(一)——虚伪的质量

注:下 面此文中提到的质量的行政与情感色彩,只是温伯格从心理学的角度揭示和探究组织内管理改进的方式,请勿以此来片面的理解“质量”,并作为自己无法开发出高 质量产品的借口。关于质量的客观定义,请参见朱少民老师的文章,建议先读朱老师的文章再读此文,以免对质量产生误解:
质量的定义总会带有政治的和情感的色彩吗?


<meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8"> <meta name="GENERATOR" content="OpenOffice.org 2.0 (Linux)"> <meta name="AUTHOR" content="ljh"> <meta name="CREATED" content="20060711;544900"> <meta name="CHANGEDBY" content="ljh"> <meta name="CHANGED" content="20060731;3282000"> <style type="text/css"> <!-- @page { size: 21cm 29.7cm; margin: 2cm } P { margin-bottom: 0.21cm } H1 { margin-bottom: 0.21cm } H1.western { font-family: "AR PL KaitiM GB", sans-serif; font-size: 16pt } H1.cjk { font-family: "AR PL KaitiM GB"; font-size: 16pt; font-style: normal; font-weight: bold } H1.ctl { font-family: "AR PL KaitiM GB"; font-size: 16pt; font-weight: bold } --> </style>

质量的层次性

传统的质量体系中,质量的层次一般指的是由质量方针、质量手册/组织手册、流程、方法/工具/指导书/标准等构成的经典的质量金字塔模型中的分层等级,不过这个金字塔模型主要表达的是质量管理系统本身的构成,却无法表达和解释出质量系统之所以能够运作并对产品产生影响的原因和系统原理。这里,并不想讨论质量管理系统本身,而是希望能够解释和理解开发高质量的软件产品本后的某些驱动因素,而正是这些因素对一个软件组织能否真正达成“以客户为中心”的目标起着重要的作用。


那么,这里所希望表达的质量的层次性究竟指的是什么呢?前文提到,所有质量的定义背后都隐藏着“行政和情感”的因素,当沿着这种目光向一个开发组织的内部看去,情况就会变得非常有趣。从情感的角度看,任何一个稳定的团队都是由一群拥有某种潜在共同价值观的人们所组成的,这种价值观影响并促成了一个团队独特的质量观,并且在一个团队中,总有某些权威人士的潜在质量观深刻的影响着整个团队的质量观,通常这些人士都是团队的Leader或是技术的权威;从组织的角度看,任何组织都有一定的组织结构,稍微复杂一点的组织,其组成结构都具有一定的层次。正是这种人与人之间的等级关系和组织结构的层次关系,使人们的质量观也构成了某种层次,这种质量的层次性并不是产品本身所体现和具有的客观存在的质量属性,而是由上述两个原因所产生的一种附加属性(或特征)


这种附加的质量层次性,有两个显著的特点:

  1. 团队leader(或团队内的某些权威,后面为了简单起见,都只说团队Leader)对一个团队的潜在质量观起着重要的作用;

  2. 所处环境和地位的影响,对处于不同层次的团队或人员的真实质量观有着决定性的作用,尤其是那些涉及到他们生存和发展的因素。这里最经典而有力的证据就是人们常说的一句话:“屁股决定思想”!(指的是人在什么位置说什么话)


第一个特点,这里没有什么特别需要说明的。关于第二个特点,则不但揭示了不同软件开发方法论选择不同道路的原因以及其背后成功的核心因素,也有助于理解组织结构变革背后的原因和考虑因素。


在早期,典型的软件产品开发组织结构,是以研发团队为核心开发新的软件产品(现在也还有,如新的概念性的产品,这里只是为了说明方面,不用过分计较),并向客户进行推销,如下图所示:

软件质量的“奥秘”(二)——质量的层次性(1)

由于研发人员的质量观(如华丽的界面/新技术的追求……)和实际客户(如带来利润/降低成本/操作维护简单/修复时间短……)有着明显的差别,所以,随着人们逐渐认识到这个问题后,提出“以客户为中心”的观点,要求人们实现充分了解客户的实际期望,于是上面的图可以简单的转化为下图所示。但是,如下图所示,由于研发人员所处的位置并不能真正充分的和客户直接接触,客户的质量观并不能有效的影响研发人员的思想和行动,真正影响研发人员思想的除了研发人员本身的追求和喜好外,更重要的组织实际对研发的绩效要求,如果考核进度,那么牺牲的就是更少的缺陷,如果考核的是过程,那么过程符合的情况会很好,而进度和少的缺陷则往往被丢弃。究竟应该怎么办呢?如何才能让客户的期望,落实到研发中去呢?

软件质量的“奥秘”(二)——质量的层次性(1)



(待续)
注:此部分感觉没有描述得特别清楚,后续可能修改,如有建议欢迎讨论。

上篇: 软件质量的“奥秘”(一)——虚伪的质量

后续的议题:
敏捷方法的解决之道
大型软件组织的结构调整
大型软件组织:“官僚主义“的根本
管理者的质量观影响与目标导向平衡

你可能感兴趣的:(.net,linux,css,敏捷开发,情感)