软件开发组织批判

　　是何种原因造成了软件公司需求人员对“需求”概念的理解偏差呢？他们为何会存在对于企业需求的不敏感呢？要了解产生这种现象的原因，必须观察一下软件公司现有的组织与结构的构造方式和与这种构造相配的组织职责。

　　开发组织断带

　　国内许多的软件公司都已经走过了创业阶段，已经从过去的三、四十人发展到现在的五、六百人，甚至数千人。公司的销售渠道在加强、开发队伍在加强、实施队伍也在建立和完善之中，公司完整的组织体系慢慢地建立起来，过去许多原有的工作的方式方法，随着机构的建立，逐步的消失了，在消失的东西之中，同样存在着许多好的工作作风与方法，这些东西已经无法再找回来了，软件设计人员对于企业需求的感觉在这个变化过程中几乎消失殆尽，由于这种消失，逐步地使软件公司背离了面向用户的宗旨，使这一宗旨成为了说教。那么促成这种现象的快速演变的核心本质的组织体系究竟是怎样的呢？为了把这个病灶的根源说清楚，在这里给大家展示一下现在国内大、中型软件公司的常用结构示意图和在开发工作方面的职责。　　

　　这是目前软件公司常用的组织体系结构。在这里之所以使用“体系”二字，是为了消除某个体系下可能存在多种不同类型的部门：如多个行业部门、如多个产品部门，在这个结构中有三个体系涉及商品化软件建设，第一个体系就是渠道和销售部门，他们的基本职责是使用商品化的软件获取客户，同时向实施体系和开发体系传达用户的核心需求。第二个体系就是实施部门，他们在第一阶段实现客户需求的调研，并将用户现实需求传达到开发体系，当然在部分软件公司中，偶尔会派出开发体系下的需求分析部门的人员参与需求调研工作；而另一个方面在软件交付给实施部门后，实施部门将根据企业需求的调研结果，开始软件的实施工作。第三个体系就是开发部门，他们实现需求分析与定义，实现商品化软件概要设计与向详细设计，实现软件代码的编制，实现商品化软件的测试，直到软件测试通过、并提供软件交付。

　　在这种结构中有两个层面和两个断带，第一个层面是渠道体系、实施体系的需求调研过程，接下来是一个明显的断带，通过这个断带转入到第二层开发体系的需求分析阶段。最后经过商品化软件测试后的交付，又通过第二个断带将软件传递给第一层实施体系的实施过程，直到完整交付为止。通过这个过程可以明显感到信息传递的错位与断裂，在这种状况下所实现的商品化软件必然会导致在适应企业实际需求方面的不足。并且目前这种现象，如果不在其它方面实现有效调节，必然会导致更大的断带，和人员能力的急剧衰退。

　　从图中可以看出一个正常的开发运作方式应当是相当平滑的，首先是只有一个层次，而且也不存在断带，在第二层中的无字虚框就是要将第一层次的内容牵引下来，只有这样的开发结构才是真正懂得企业现实需求的商品化开发结构。

　　软件的基础能力

　　这种方式的产生是由于软件产品规模化生产所带来的弊端，这个弊端在这种体系建立之初并没有被软件公司的管理层所注意，但当发生软件产品与解决企业现实管理问题不相匹配的时候，一切都已经积重难返。这是一种商品化软件公司常用的结构，如果要实现软件公司的规模化运作，必须制造出标准的商品化软件，如果没有软件公司的规模化，中国的企业也就无从看到今天众多的知名管理软件公司的存在。但是在规模化的过程中，却忽视了对于企业需求的完整传递。

　　软件要实现商品化，必须要满足60%以上的同类企业需求覆盖率，如果没有达到这个比例，那么这种软件可以说几乎没有太多的用户和市场(在这里提请读者注意：商品化软件是一种根据不同企业要求的细分性市场，简单可以把管理软件划分成适合于“迷你型”企业的超小型管理软件，适合于小型企业的小型管理软件，适合于中型企业的中型管理软件，适合于大型企业的大型管理软件，读者不难看到这个市场对于软件公司而言是比较庞大的，同时也无法做到一种软件可以适合于不同规模的企业，因此这里谈到的60%，是以一种企业规模为基准的)，所以小于60%覆概率的软件，可以认为无法满足企业管理的基本需求，而商品化软件为了赢得企业市场的需求之外，为了竞争需要还必须建立超越现实企业需求的一部分功能，这种功能，对于管理先进的企业可以尝试使用，对于常规企业它的价值只是锦上添花。软件公司为了达到既满足60%以上的现实需求，又满足未来可能的需求，必须要建立强大的需求分析与需求定义队伍。这支队伍要承载企业调研所获得的企业各种需求的同时，还要承载将这些需求汇总、分析、定义之后向系统设计人员的转达。所以他们的责任对于软件公司而言是重大的。

　　人员能力的警告

　　在研究了国内许多商品化软件公司之后，现实会告诉你，这是一件非常遗憾的事情，目前还很难找到这样一支训练有素的需求队伍，这是因为大部分的成员还没有完全理解企业的需求、也没有理解需求对于商品化软件的重要性，产生这种现象的一个直接原因、就是这些人员由于现有软件公司的开发结构所至，使他们很少有机会与企业直接交流，久而久之，慢慢地习惯于钻研西方管理软件的流程设计方法、控制方法，还有更加喜欢的是、对西方软件的结构研究，他们喜欢在软件结构上创造完美，而忽视了对于国内企业现实的管理研究，这就造成了对于企业管理需求的不理解，最终导致了慢待企业需求，渐渐地把自己打扮成为一个技术专家的角色。在后来一次偶然的机会我见到了上面所谈到的那位技术总监，他的工作方法证实了我的判断，那时他正在这家企业开展需求调研。

　　“你们原来做过类似的系统吗？你们准备调研几天，有没有调研提纲”我问道。“我们是提供商品化软件的公司，以前我们很少到企业去作调研工作，只是在实施阶段由实施人员根据企业的一些具体情况，做一些非常简单的调研和了解工作。而这个系统对于我来说是一个新系统，与我们原来所做产品有很大不同，过去我们总是在学习和模仿外国公司的一些管理软件，那些软件对于我而言，只是理清他们的设计思路，选择一些比较重要的和我认为比较基于国内现实的内容，柔和起来做成需求，我们同时还比较一些西方软件在软件设计结构方面的异同，比如那种语言、那种操作系统、是基于局域网的(C/S结构)、还是基于互联网(B/S结构)，如何实现制造过程与制造成本管理等等这类问题。我们计划在这里调研3、5天，到今天已经是第3天了，明天我们打算回去。调研提纲，在来之前我们没有，我们调研的时候主要是和不同部门的管理人员谈一谈，了解一些基本情况，另外我也在介绍一些计算机方面的基本功能，总体上感觉调研很不轻松，确实令我感到无从下手”。

　　对于他的回答我很惊讶，我又接着问道：“你原来参加过企业信息系统建设吗、今年多大了、其它软件需求人员有比你大的吗”？他的回答让我彻底明白了国内软件公司在企业信息化建设过程中由于操作能力造成失败的原因。

　　“今年28、9左右，其它需求人员都比我年轻。这是我第一次与企业管理与业务人员面对面的打交道，原来没有调研的经历，这次如果我不来，我们公司更不会有其它人能够出来了，这次只是因为我公司的软件是我设计、也是我组织开发的，所以别人不会比我更加的了解软件整体功能”。

　　这次交流时间并不长，在与这位技术总监的交谈过程中，他总是自觉与不自觉地把话题转入到技术的方面上去，也许这已经成为了习惯，我那时隐约感到他们无法完成需求，这是因为他们都太技术化了。果然，在看到了他们提供给企业的需求报告之后(企业提供给我，希望帮他们把一下关)的感觉是：不看还好，看了之后有说不出的苦涩，他们对于需求的概念不但理解上不够，而且对于企业的管理看来也缺乏必要的了解，好像他们从来没有到企业调研过一样，一切都没有企业的特点和内容，更象是一份给开发人员看的需求，企业的人员拿到这样的需求报告是无法读懂的。后来我没有办法，只好把我原来做的一份需求提供给这家企业，让他们转交给这位技术总监，要他们再对企业作一次调研，并且按照我所提供的需求报告方法把这家企业的需求写出来。后来几经多次修改，终于算是完成了这份需求报告。

　　在这个例子中所谈到的不仅仅是这家公司，国内的商品化软件公司中或多或少都存在这种现象，软件公司的管理者在设计这种结构时，基本的依据是社会化大生产方式下的流水作业，读者们都没有忘记流水作业对于工人技能的提升是非常有害的，每个人只能够长期不间断地完成着一种工作，没有多少人去关心上一道工序的情况、也没有人去关心下一道工序的情况，如果这种现象在商品化软件业中重现，那将是一种灾难，这种方式在短期内对于推动软件开发是有效的，长期却只能够处于低效状态。

　　人员能力导致软件能力低下

　　这是否能够让我们去思考一个问题，工业品制造的流水过程如果要改造成软件制造的流水过程，流水的方式是否也需要做出相应的调整，答案是肯定的，必须有一个核心群体控制着每一个环节，他们负责需求的传递、知识的传递、技能的传递，那么对于这个群体能力的要求是很高的，目前在软件公司中，实际上极为缺乏这种人才(几乎平均一家公司很难找出1个这样的人)，因此说这种流水的结构没有高水平人员的加盟，事实上是很难有太大作为，在这种人才结构下，做一些简单的管理软件是可以的，但如果要开发中、大型管理软件将会遇到没有核心人员的苦恼。

　　遗憾的是，这种结构本身也无法培养出优秀的软件需求人员、设计人员，在我们看到了这种流水方式之后，这个结论已经可以下了，由于没有高层次人员所作的传递工作，软件公司必然会发生开发结构层次的错位与需求传递的断带，所以造成了需求人员不但缺乏企业管理需求经验、也缺乏从事开发性项目的经验，他们只能够参考管理技术方面的书籍和西方的管理软件去模仿和微缩西方管理软件的一些功能，以此来满足企业的需要。在这种状况下，软件公司的需求人员，与其说是与企业客户打交道，不如说是在与西方的管理软件打交道、在与软件详细设计人员打交道，他们已经丧失了与客户交流的能力，他们的需求文档不是与客户交流的工具，反而成了与软件设计人员交流的工具，他们不会用用户的语言去表达事务，反而只会用计算机的语言去表达，他们已经忘记了需求人员的职责，而似乎在从事着产品假设性的定义(忘记了实际情况)。由于软件与实际的脱离，在实施的时候势必造成企业信息化管理的不理想、甚至失败。所以我们必须注意：

　　1.企业需求不是对西方软件研究结果的模仿与微缩

　　2.企业需求不是对管理技术性书籍的囫囵吞枣，必须与现实结合

　　3.企业需求必须来自于现实的工作需要，并将这些需求传递到开发的全过程，并在需求定义阶段完善并提升需求内涵

　　4.需求人员必须修炼自身与企业人员的沟通能力、需求写作能力，要向企业人员提供能够看得懂的需求报告

　　5.详细的分工协作这种流水性的传递工作方式，必须建立在经验丰富的开发管理团队的基础上，没有这个基础，软件制造过程将没有灵魂。

　　这种结构存在如下弊端：组织细分带来职责细分，最终导致人员职责细分，体系是为实现商品化软件服务，所以与其说是需求分析、定义还不如说是产品定义与分析，需求的直接面向不在是企业用户，而是公司内部的开发人员。