软件开发管理中的沟通与协调问题研究

　　1问题的提出

　　计算机软件产品的开发是信息技术的一个重要方面，也是构成信息产业的主要部分之一。随着软件产品的规模不断扩大，复杂程度不断提高，软件开发出现了大量问题，被称为“软件危机”（softwarecrisis)[1。Doherty和King等人在对大型软件组织的调查中发现，软件开发中的组织问题和技术问题同样重要，甚至比技术问题还重要。管理是影响软件研发项目全局的因素，而技术只影响局部。

　　在软件开发的各人员与组织因素中沟通与协调问题是影响软件生产效率和可用性的重要问题。沟通(Communication)是指人们分早信息、思想和感情的任何过程。狭义的沟通是指信息的交流，是使信息发挥积极作用和达到目标的手段。Brooks指出沟通是软件开发计划中必须考虑的工作量：人数n的变化，将引起沟通路径n(n—1)/2倍的变化。这使得软件开发中人员与时间两个要素不能相互替换而是呈现出错综复杂的关系。此后，一些实证研究也说明了沟通对软件开发的重要性。Curtis用访谈法研究了17个大型软件开发项目，沟通和协调中断是导致软件项目失败的主要原因之一[Mc?Connell通过文献分析，总结出软件开发的12项典型错误，其中和沟通问题相关的有3项。Sonnen-tag对德国29个软件项目的优秀软件人员必备要素调查中发现，社会技能(主要指沟通能力）仅次于专业技能成为优秀软件人员必备的第二大要素[7。在随后的研究中，Sonnentag对优秀软件人员的行为特征进行分析，结果表明:优秀软件人员的绩效与对沟通活动的投入程度有显着相关。在同事的表述中，优秀软件人员有较高的社交能力，而优秀的软件人员自身也把沟通作为完成任务的重要策略，在他们的实际行动中也更经常地投入到团队磋商和评审会中，并积极从同事那里获得反馈。

　　协调(Coordination)是指和谐地在一起工作的活动[。狭义的协调仅指“对相继的和同时的互依活动的调和过程”即“对完成目标各活动间的相互依赖关系进行管理。Toffolon和Dakhli从软件开发活动背景的复杂性分析其协调活动的必要性，认为:首先，进行软件开发的组织其商业活动是持续变化的；其次，软件开发活动是在一个包含技术、经济、人员和组织等因素的大型环境中进行的;再者，软件开发活动本身是在一系列相互依赖过程的基础上进行的。Brooks指出，软件开发过程是一个熵不断增加的过程。因此，软件开发需要大量的协调活动，从外界导入负熵流。

　　我国的研究人员对上述问题有所涉及，但研究的深入程度不够，尤其是没有针对我国软件组织的管理现状下沟通与协调问题的研究。就方法而言，我国在这方面的研究较多采用规范研究的方法，仍需要进行更为深入的实证研究。

    2.研究设计

     研究设计的常用的沟通与协调活动;探讨沟通协调活动与项目的输出之间的关系。本研究采用问卷调查法获取数据进行实证研究。问卷分四部分，第一部分为对项目特征的调查，包括项目规模、项目所处阶段、项目依赖性和项目不确定性。第二部分为常用沟通与协调方式的调查。沟通技术可分为四类：（1)正式书面沟通，包括:项目文档和备忘录、项目里程碑和交货时间表、需求变更和错误跟踪规程、数据字典、系统分析模型（用例图等)；（2)正式口头沟通，包括:状态审查会、需求评审会、设计评审会、代码评审会、用户测试、项目定期例会等；（3)非正式口头沟通，包括:小组碰头会、与同行讨论、与直属业务领导讨论等；（4)电子沟通，包括:电子邮件、内部BBS等。协调技术包括:资源合理配置、开发步骤有序化，工作目标一致化，提高关心程度，信息的共享等。同时，本研究对项目成员获取帮助的渠道的使用状况和评价进行了调查。第三部分为对项目输出质量的调查，包括：软件产品质量、开发生产率、开发过程质量、客户满意度等。第四部分为控制变量信息的调查，包括企业所有制性质和答卷人角色及所在地。问卷的第一至第三部分米取Likert五点法。第四部分为开放式问卷。

　　运用调查数据对问卷进行信度检验，第一、二、三部分Cranbacha系数分别0.712、0.883、0.792都超过了所建议的0.7，本问卷的一致性信度颇高。本问卷设计中，采用组织行为和软件工程研究中比较成熟的理论。在问卷的第一部分，根据软件工程学中项目特征的测量指标进行界定;第二部分关于沟通方式的问题是根据组织行为学和软件工程学的理论，以及SW-CMM和P-CMM等研究成果来设计的;第三部分关于软件开发质量的方面，是根据软件工程学对于软件评价的若干方面进行设计的。因此，本问卷具有良好的内容效度。

　　3调查结果

　　3.1样本状况

　　2003年4月至5月，研究人员采用简单随机抽样的方法，对我国软件企业和软件培训机构发放调查问卷220份，回收有效问卷156份，问卷回收率71%。答卷人单位所在地为北京的答卷占50%.北京以外包括:成都、天津、重庆、杭州、德阳、泸州、齐齐哈尔、深圳、武汉、中山等地占50%。单位属性包括三资企业15.4%、民营企业44.2%、国有企业16.7%、国有科研机构10.9%及其它12.2%。答卷人角色包括：程序员55.8%、设计师/构架师18.6%、项目经理19.2%、高层经理1.3%、测试/配置管理员3.8%及其它1.3%。

　　3.2沟通技术的使用与评价

　　本研究对我国软件组织常用沟通技术的使用状况及其评价进行了调查，结果如图1所示。

    3.3 　项目特征与沟通协调技术

    本研究根据调查数据对项目特征与沟通协调技从表1可知，影响项目沟通技术使用状况和评价的主要因素是项目规模和项目的不确定性。对项目规模与不确定性作相关分析，如表1所示，项目的规模与不确定性不存在显着的相关关系（r=0. 025，p>0.10，N=156)是互为独立的两个变量。

　　3.4沟通技术与项目协调的关系

　　Koonz在《管理学》第十版中指出“协调是管理工作的核心”，同时又指出“沟通是把所有组织的活动统一起来的手段”[17。因此，分析沟通技术与项目协调的关系，将有助于人们了解软件开发中的协调活动。对沟通技术和项目协调进行相关分析，如表2所示。

　　3. 5项目协调与项目输出质量

　　软件开发团队采用上述协调活动的最终目的是为了软件开发能够有一个良好的开发质量。对项目协调与开发质量做相关分析，如表3所示。

　　表3项目协调与沟通技术相关分析(N=156)

　　3.6软件开发沟通与协调模型

　　对软件开发协调各变量进行逐步回归分析，剔除条件为:当某变量的为F显着性概率大于0.1时，从回归方程式中剔除该变量。各变量回归系数如表4所示。

　　根据逐步回归分析，可建立软件开发协调的回归，如图2所示。弧线上标注的数据为标准回归系数Beta值。

　　4讨论

　　4 1沟通技术

　　各沟通技术可根据使用状况及技术人员对其的评价分为四个区域:高评价低使用率、高评价高使用率'低评价低使用率、低评价高使用率。从散点图1中伴

　　知，在被调查的软件项目开发过程中，“电子邮件”、“内部BBS”、“与同行讨论”和“小组碰头会”等非正式沟通技术使用频繁程度较高同时被认为有较高价值;其中“电子邮件”使用频繁程度最高同时被认为在沟通中最有价值。这说明，总体说来，我国中小软件组织在开发过程中经常使用非正式沟通来交换信息，且被认为非常有效。非正式沟通的信息源在物理上比较容易接近，沟通成本较低、在沟通过程量个性化信息，信息较丰富同时，从图1可知，“状态审查会”、“代码评审会”、“需求评审会”、低且被认为价值较低。“设计评审会”等正式口头沟通方式使用频繁程度较

　　发沟通与协调模型本研究的结果表明，非正式口头沟通是我国中小软件组织最常使用且被认为效果最好的沟通技术。这与Kraul对美国某软件开发公司所作的调查研究观察到的现象有较大区别[18。在Kraul的研究中，“项目文档”、“项目里程碑时间表”和“错误跟踪规程”等正式书面沟通技术落在高使用率高评价区域内，同时非正式口头沟通技术“与同行讨论”使用频繁程度最高且被认为最有价值。说明美国软件项目开发过程采用的沟通技术较为多样化，正式和非正式沟通、口头沟通与书面沟通同时使用。我国中小软件项目开发过程更多靠开发人员的非正式沟通来完成信息的传递，对结构化较强的正式沟通技术重视不够。都表明用户在软件项目开发过程中的重要性。在Kraul[18的研究中，对“用户测试”价值的评价被排在第二位，仅次于“同行讨论”，且使用频繁程度处于中等水平。而在本研究中，“用户测试”的价值评价和使用频繁程度都处于较低水平。这表明我国中小软件开发组织和作为软件产品使用者的用户对于“用户”这一角色在软件开发中的作用都没有充分的认识。

　　42项目特征与沟通协调技术

　　(1)项目规模与项目沟通项目的规模主要由两个方面来衡量，一是参与项目的人数，一是项目周期。项目规模与沟通技术的相关分析如表4所示。

　　字的方式保存下来，以便在项目进展过程中不断对以前的信息进行追溯，并和当前信息进行对比，从而做出决策。因此，正式书面沟通的使用与项目周期的关系更密切。

　　表4的数据显示，正式口头沟通方式的使用频繁程度也主要随项目周期的增加而增加。Walz,Curtis等人的研究表明随着项目的进展，开发人员关注知识的侧重点逐步发生变化。这些知识依次是:软件应用领域的知识，软件需求的知识和实现方法的知识：21]。本研究讨论的正式口头沟通方式是各种评审会和测试会。在这些会议上，需求分析员、系统工程师、构架师、程序员、测试员和用户等担负不同职责的人员可以通过结构化的方式，运用大量语言和非语言信息对相互的工作发表各种不同的意见，分享各自对知识的理解。从而使信息充分沟通。降低开发风险。同时，这些会议还有一个功能就是对上一阶段的开发活动做出结论，从而把开发团队的焦点转移到下一个需要关注的知识点上。因此，周期越长的项目，越需要通过这种正式的沟通方式对项目的时间资源进行分配和管理。因此，正式口头沟通的使用与项目周期的关系更密切。

　　上述的正式沟通技术（包括正式书面沟通和正式口头沟通)在周期较长的开发项目中使用频繁程度较高，还有一方面的原因在于，正式沟通技术的成本一般都较高;正式书面沟通需要撰写相应的正式文件，并且需要一定的审批流程才能确定沟通所需的输入信息；正式口头沟通需要相关人员处于同一时间空间内，沟通之前要进行充分的准备。这些成本更多地体现在时间跨度上，而非人员投入上。因此，周期较长的项目相对于周期较短的项目更能够承担这样的时间成本，从中获得沟通的收益。

　　表4的数据还显示，项目周期和项目人数都对电子沟通的使用频繁程度有显着影响。电子沟通作为非正式的书面沟通方式主要特点在于:信息的传递和接收不受时间和空间的限制，同时由于具有非正式色彩，形式比正式沟通更灵活，沟通成本更低。从表2的分析可知，随着项目规模的扩大，电子邮件和BBS等电子沟通方式的使用频繁程度也显着增加。对项目参与人数、项目周期和项目成员接触的公司内部人数、接触的公司外部人数进行相关分析，如表5所示。

　　从表5的分析可知，随着项目参与人数增加，公司内部沟通的数量显着增加。随着项目周期的增加，一方面公司内部沟通数量在增加，另一方面项目成员与公司外部人员的沟通数量也在更为显着地增加。Wallace对网络语言的研究表明，电子邮件和BBS论坛使用的语言在某种程度上与公开的言语访谈风格类似。同时，编辑工具提供的表情符号和传递情感的语言形式也被广泛采用，含有大量非语言信息。因此，电子沟通在一定程度上可以实现人际沟通需要的信息传递，完成公司内部的人员沟通。同时，和口头沟通相比，电子沟通因其不受时间和空间限制的特点更适应与公司外人员进行有效沟通。

　　从表4的分析可知，项目规模的变化主要影响项目成员对正式沟通技术(正式书面沟通和正式口头沟通）的评价。项目规模越大，人们越倾向于认为正式沟通技术，尤其是正式的口头沟通技术具有更大的价值。因为项目的规模越大，尤其是项目参与人数越多，保证信息在项目中的正常流动显得越重要。和非正式沟通技术相比，正式沟通技术具有更好的规范化结构化，更能保证信息在项目中正常流动，因此其价值与项目规模更密切。

　　(2)不确定性与项目沟通

　　同其它制造业相比，软件项目开发不确定性较高。软件设计所支持的外部世界不断发生变化，开发人员对软件产品应用领域的知识了解不够充分，人员的流动都会影响软件项目的不确定性。项目不确定性与沟通技术使用状况的相关分析如表6所结合表1和表6的数据可知，项目应用领域知识的不确定性对正式沟通技术（正式书面方式和正式口头方式）和电子沟通的使用状况有显着影响。项目应用领域的知识越精晰，项目文档、需求变更和错误追踪规程的使用明显增加，同时各种评审会议的召开频繁程度也明显增加。反之，上述正式沟通技术的使用频繁程度则明显下降。这种现象的出现有以下两个原因。首先，正式沟通技术的功能是通过规范化结构化的语言和规程保证信息在团队和组织中正常流动，避免信息的损失。当应用领域知识较清晰，不确定性低时，团队会更多使用正式沟通技术来保证信息的传递。但当应用领域的知识不清晰，不确定性高时，开发团队面临的主要问题不再是如何保证信息流动的通畅，而是如何获得更多的正确信息。团队更多地需要激发成员的创造力，而不是更强调成员的规范化。另一个原因在于，在应用领域知识不确定性高时，开发行为是一种探索性的活动，失败的风险较大，沟通行为的收益没有保证。而正式沟通技术需要花费较多的时间编写文档、执行规程，召开会议，成本较高。因此，在这种情况下，项目组更倾向于采用成本较小的非正式沟通方式来完成必要的信息交换任务，从而规避风险。

　　如表6所示，从对沟通技术评价的角度来看，项目应用领域知识的不确定性越高，项目成员对正式口头沟通技术的价值评价越低。这是因为在应用领域知识不清晰的情况下，进行的评审会等正式口头沟通缺乏广泛认可的标准，结论不具有权威性，信息沟通的价值不大。同时，从表4还可知，需求的不确定性越高，对正式和非正式口头沟通技术的价值评价越低。这是因为，软件需求是项目开发活动的依据，需求的变更将会引起后续项目开发计划和成本的变化。在需求的不确定性高的情况下，口头沟通技术难于保证信息在时间上的可追溯性。

　　(3)不确定性与项目协调

　　从表6可知，项目的不确定性是影响项目协调的重要因素。同其它制造业相比，软件项目开发不确定性较高。软件设计所支持的外部世界不断发生变化，开发人员对软件产品应用领域的知识了解不够充分，人员的流动都会影响软件项目的不确定性。项目的不确定性越高，项目协调的难度越大，需要投入的精力就更多。项目不确定性的各方面与项目协调各方面之间的相关分析如表7所示。

　　从表7可知，领域知识和项目需求的不确定性对步骤有序化、目标一致化和成员关心程度有显着影响，项目需求的不确定性还会影响信息共享的协调活动。这是因为，对于领域知识和项目需求不确定性高的项目，开发是一种探索性的活动，形成一致目标较困难，也难以使开发有序进行;并且，由于领域知识和项目需求不确定，项目失败的风险较大，成员对项目的关心程度较低。需求不确定性高的项目，项目成员之间的沟通意义不大，项目成员与用户之间的沟通不畅，因此以信息共享为目标的协调活动难以形成有效成果。人员流动率高的项目，成员对项目关心程度较低，信息共享程度也较低，难以进行人力资源的备份或冗余配置。

　　4.2项目协调与沟通技术

　　从表2可知，正式沟通技术对协调活动有较大影响。其中正式沟通对于开发步骤的有序化和项目信息共享有较大影响。正式的口头沟通还有助于目标的一致化。这是因为，正式沟通技术是一种规范化结构化的沟通方式，对于保障信息沟通、明确开发目标和完善开发过程有较强的作用。此外，正式口头沟通是一种信息双向交流的方式，更有利于目标的澄清。正式口头沟通除传递言语信息外，还可以通过表情、语气、手势等传递非言语信息，有利于达成目标的一致。因此，正式沟通，尤其是正式口头沟通具有一定项目协调的功能。

　　4.3项目协调与项目输出

　　软件开发团队采用上述协调活动的最终目的是为了软件开发能够有一个良好的开发质量。从表3可知，项目协调的各方面与开发质量的各方面存在显着的正相关关系。这说明良好的项目协调对于开发质量有显着的影响。

　　从回归模型图2可知，项目某些协调活动将有助于其他的协调活动的开展。重要资源的良好配置将有助于信息共享的顺利开展和提高成员对项目的关心程度。提高信息共享和成员关心程度的协调活

　　有助于步骤有序化。同0寸，项目的协调活动有助于提高项目输出的质量。提高成员对项目关心程度的协调活动将有助于提高开发过程中成员对项目信息的获知程度，对产品的质量也有直接影响。信息共享的协调活动最直接的效果就是提高成员对项目信息的获知程度，同时对项目的生产率和用户满意度都有直接的影响。开发步骤有序化的协调活动有助于改善开发过程的质量。

　　从回归模型图2还可知，就项目输出质量而言，成员对项目信息的获知将影响开发过程的质量，甚至会直接影响产品质量。开发过程的质量将会影响产品质量，生产效率和用户满意度。同时产品质量和生产效率最终将影响用户满意度。

　　5结论与建议

　　通过上述分析研究可知：（1)总体而言，非正式口头沟通是我国中小软件组织最常使用且被认为效果最好的沟通技术;项目成员在获得帮助时，更倾向于选择在地理上最易获得，且协调难度小的渠道。

　　(2)项目规模和不确定性是影响项目沟通与协调技术的使用频繁程度和评价的主要项目特征。（3)正式沟通技术对项目的协凋活动有直接影响。（4)沟通与协调技术对项目输出质量有显着影响。

　　通过上述分析，本研究对我国软件开发项目的协调活动提出几点建议：

　　(1) 加强对正式沟通的重视。本研究表明，我国软件项目开发过程更多靠开发人员的非正式沟通来完成信息的传递，对结构化较强的正式沟通技术重视不够。但正式沟通技术尤其是正式口头沟通方式对于提高成员对项目信息的获知最为有效。对于规模较大，不确定性较高的项目，更应加强正式沟通活动的使用。

　　(2) 针对项目规模调整沟通技术。本研究表明，

　　公司内部沟通的数量随着项目参与人数增加而增加。项目成员与公司外部人员的沟通数量随着项目周期的增加而增加。项目参与人数越多，电子沟通以其不受空间和时间限制的优点在团队沟通方面越丨51能发挥重要作用。项目周期越长，越应当加强正式的书面与口头沟通，保证信息的正常传递。 丨

　　(3) 加强对项目不确定性的重视。本研究表明，项目不确定性对项目开发的沟通与协调状况都有影(4)逐步建立对沟通与协调活动的监控与管理机制，本研究表明，我国软件项目开发过程更多倾向于回顾人际协调，而靠研究书面信息获得帮助。这种方式是被动的，缺乏组织的监控和管理。组织不能实现根据不同情况调整协调活动的能力。人员能力成熟度模型P—CMM建议组织首先收集内部沟通与协调活动的数据，从而监控组织的沟通与协调活动，进而逐步建立对沟通与协调活动的监控与管理机制，值得我国中小软件组织借鉴。

　　本研究虽然得出了一定的结果，但也存在不足和今后需要继续研究之处。首先，由于研究的规模所限，本研究获得的样本中，大型项目的样本量相对较少，中小型项目的样本较多。因此，本研究的结论更适用于中小型开发项目。这虽然较符合我国软件组织的现状，但就理论而言在一定程度上降低了结论的可推广程度。在今后的研究中应选取更多的大型开发项目研究，使得研究结论更具生态效度。再者，本研究采取问卷调查的方式，其研究结果只是描述和分析了问题，为解决问题指出了方向，下一阶段还应进一步作干预性研究，对该问题做更深入的探讨。