程序员受访

㈠ 程序员退休年龄

工作到退休这类情况只适合于体制内，为何这样说呢，国企、事业单位、公务员系统都有很严格的人事管理办法，只要你不违法乱纪，不矿工连续超过15日，具体可参照“事业单位人事管理条例”或“公务员法”或国企管理规定，只要你不违反底线，你基本是可以工作到退休的。这也就是大家俗称的稳定。

所以作为国企里的程序员，只要你不触犯底线，你是可以安稳到退休。

话说回来，程序员本身是需要不断学习的职业，需要经常给自己充电，如果还比较年轻，那要多储备知识。毛主席说过，世界终归是年轻人的。

就前景而言，国企相对而言待遇不会太差，但现在国企限薪了，普通员工待遇不会像以前那么高，但相对而言比较稳定，稳定也意味着升职加薪要排队的。如果觉得自己也很年轻有更高的追求，在国企内看不到有更好的升职机会，建议趁早到外面的大企业去，思科、sap等等，这些大企业都很锻炼人，周围都是优秀的职场人士，培训提升的机会多，管理也规范，可以趁年轻考虑一下。

年轻的时候多学习多尝试多努力，不负韶华不负春光！年轻就是用来奋斗的！

㈡ 我的网站站长统计的受访页面数据中为什么有其他网站地址的

1、如果是其他站长因为采集你的站点信息而误采到你的统计代码并显示到他的站点，那么就会在你的统计中显示他的站点，这个比较少见； 2、大多数用户出现此问题都可能是一些站长故意盗用你的代码使用你的统计，从而让你的数据中显示他的站点，让你产生疑惑并回访他的站点，这样会让他的网站增加流量（你一个人回访流量当然不大，但如果很多站长都和你一样被盗用代码并回访的话，该网站流量就大了）； 解决办法：在浏览统计网站中将不属于您的站点添加到黑名单即可。 3、还有一种情况也值得一提，就是网站程序员当初在制作你的网站时，没有使用二级域名进行测试，而是用一个（或多个）顶级域名进行测试的，所以搜索引擎抓取了该域名下的网站信息，当该域名被重新启用时只暂时更新收录了该网站的主页内容，而未能及时删除内页信息。辨别这种情况很简单，就看你网站流量统计中以其他域名为前缀的受访页面（注意是内页）能否正常打开，如果能打开则说明不属于这种情况，如果都不能打开那就放心，不用管它就行，嘿嘿。

㈢ 我需要两个程序员让我采访，就是几个问题而已。

采访吧。给采纳就可以
我不算正式的程序员，是属于计算机竞赛的学生，你有关理论类、算法类都可以咨询
我另外了解一些可视化编程
（但是，网络安全类的问题就免了，问题也不要太多）

采访不需要收费吧。。

㈣ 现在转行做程序员还来得及么求大佬给建议。

现在转行做程序员还来得及的。因为，程序员在计算机语言的学习方面，可以根据自己的兴趣有不同的选择，例如：学习Java、PHP或者python等等。
另外，其实这些语言的学习，是可以分阶段进行学习的。可以根据自己的现有水平和需求，选择相应的学习内容。现在市面上学习IT的机构也比较多，包括线上网授课以及线下面授课两种授课形式。具体可按自己的实际情况而定。如果觉得自身有这个必要去学习的话，建议去实地调查。一般来说，这些培训机构都会有一些体验课程，可以先让你感受下。另外，在选择时你也可以对学习环境、学习费用、师资情况等进行对比。综合考虑后选择自己可接受范围内，比较适合自己的那个。
此外，据2018年国内程序员年薪状况调查，程序员整体收入水平仅次于受访企业中高层管理者。所以说，转行做程序员是可以考虑的。

㈤ 安卓程序员要实现某个功能却不知道用什么代码实现怎么办

美国的程序员交流网站 Stack Overflow 在去年的开发者调查中想要了解，码农们是否都有大学的计算机专业学位。有 26086 名程序员参与了这项调查，其中有近一半受访者的答案是，没有学位。 大量程序员非科班出身的原因有很多方面。一方面，美国大学的学费正日益高涨。私立四年制大学一年学费平均接近 4.5 万美元，其中还没有包括生活费。另一方面，网上课程和培训班吸引了很多人。有志于成为程序员的人士可以在做中学，而不必浪费几年时间去完成大学学业。 关于非科班出身的程序员，有几点建议可供参考： 闭门造车要不得 编程时的闭门造车会带来几方面问题： 没有人给你答疑。编程时你会面临许多疑问，但却无法找到人给你答疑解惑。解决这类问题的过程通常需要求助于高级程序员，或是将自己的代码与别人的去对比。 软件评审。大型软件公司都会设置软件评审环节，即让同事之间互相评审对方的代码。无论是国外还是国内，数据显示，代码评审能多发现 60% 的错误和漏洞。即使你自己干，也需要找人去评阅自己的代码。 与他人一同工作有助于拓展人脉，在职业生涯初期尤其如此。 目前，国内许多众创空间都在面向小团队乃至个人开放申请。这将会是不错的选择。 多读书，尤其是大学专业内容 大学培养人才的重要之处是训练基本功和思维方法，而不是让你实际参与工程项目。如果没有上过大学，那么这些方面很可能会有缺失。你可能知道如何根据架构师的设计文档去写代码，但却不知道算法为什么是这样。在实际面试中，笔者还曾发现，有许多非专业出身的人士甚至都不能准确解释，什么是面向对象的编程。而这本应是 C++ 的基础。 非科班出身的人士需要通过多读书来补充基础知识，无论是离散数学、算法设计，还是软件测试的基本理论。 另一方面，如果你希望通过网上课程或培训班去学习，那么最好从基础开始学，尤其是在没有编程经验的情况下。 如果你是非科班出身，希望自己干，那么应当采用自底向上的模式。这将帮你弄清许多基本概念。一上手就接触庞大的代码将会令人摸不着北。 多练习，多做项目 对新人来说，多参与项目能帮助积累更多经验，有利于未来的职业发展。而如果想要单干，那么所做的项目将成为简历上的主要经历，是对能力的证明。 个人从事项目最好的选择是开发移动应用。相对于大型软件项目，例如系统软件或企业级应用，移动应用的开发相对简单，很容易出成果，而也会有许多用户提供反馈，相当于免费帮你做测试。移动应用开发使用的语言包括 Swift 或 Objective C（iOS 平台）、Java（Android 平台），以及 C#和 VB（Windows 平台）等等。此外，Phonegap 等通用型技术也可以考虑。 对个人程序员来说，GitHub 是个好工具。GitHub 上有许多开源项目可以参与，也有许多其他程序员可以提供帮助。你也可以自己创建软件项目。这一切都是免费的。 职业发展的选择 非科班出身程序员在找工作时可能会受到局限，因为大公司的招聘中学历是个门槛。许多知名科技公司用大学学历作为条件去过滤求职者。例如，谷歌在招聘初级工程师时就是这样。 相对来说，一些创业公司更看重个人能力，而非学历。对于需要什么样的程序员，什么样的程序员是够格的，它们有自己的标准。在创业公司里找工作时，你不一定需要有大型软件的成功开发经历，通常只要证明你能开发出用得起来的软件。 如果觉得自己的能力稍弱，那么还可以考虑软件公司中的 QA（质量工程师）职位。QA 的工作通常是统计问题，找出趋势，以及建议如何改进。这也是一项程序员的基础能力。而许多公司对 QA 工程师的招聘门槛要低于软件工程师。 简而言之，大学学位，或者说计算机专业的学位，并不是成为程序员的必要条件。但如果这类人群希望成为程序员，那么将要在学习和实践方面付出更多的努力。 编者按：李玮是科技从业者，在多家网站开设专栏。同时他也是为 TC 中国长期贡献稿件的译者之一。

㈥ Python的就业前景怎么样

Python未来的前景怎么样？就业岗位多不多？薪资高不高？今天就来看一下详细分析。

1、为什么这么多人学Python呢？

很多初学者都听说python很火，可是为啥要学Python，下面谈谈我的感悟。

Python语言是我目前为止用的最爽的语言，因为它真的很优美。虽然C、C++、Java也非常的强大和伟大，但是每一种语言伟大的背后都是有一定的时代背景。

Python被广泛的用在Web开发、运维自动化、测试自动化、数据挖掘等多个行业和领域。

一项专业调查显示，75%的受访者将Python视为主要开发语言，反之，其他25%受访者则将其视为辅助开发语言。

将Python作为主要开发语言的开发者数量逐年递增，这表明Python正在成为越来越多开发者的开发语言选择。

那么未来10年到底哪种语言会独领风骚，笑傲江湖，我不得而知，但是未来10年一定是人工智能，万物互联的时代，现在AI、VR、无人驾驶汽车、无人机、智能家居离我们越来越近了。

未来10年将是大数据，人工智能爆发的时代，到时将会有大量的数据需要处理,而Python最大的优势，就是对数据的处理，有着得天独厚的优势，我相信未来的10年，Python会越来越火。

2、Python岗位需求量10万

从职友集最新Python招聘岗位需求来看，Python工程师的岗位需求量巨大，并且岗位需求量还在呈现上涨的趋势。

全国Python岗位需求量接近10万；

北京岗位需求量居首位为20890个占比21.17%，

上海Python工程师岗位需求量居第二位为12843个占比13.02%，

其次是深圳、杭州、广州等一线城市合计占比16.53%。

从下图可知，Python 相关职位的需求量，依然集中在三大经济圈，特别是在北京、上海、深圳这几个城市。

以上为Python各方向薪资

因为Python在大数据和人工智能领域的爆发性发展， 导致Python方向岗位的薪水在水涨船高，从数据分析来看，月薪在20K-50K不等。

学习Python的程序员，除了能从事Python开发工程师、人工智能工程师、数据分析师、Python自动化测试外，也能够朝着Python游戏开发工程师、SEO工程师、Linux运维工程师等方向发展，发展方向较为多元化。

说这么多之后，你会发现，Python的发展前景十分广阔。并且Python是一门真正意义上的全栈语言，即使目前世界上使用最广泛的Java语言，在很多方面与Python相比也逊色很多！

㈦ 我学记者采访过很多程序员，和有才华的优秀小说作家，他们都共同表示，脑力劳动很心累！抑郁症活得很痛苦

没办法的事情吧。人要工作才有饭吃吧。现在买房买车娶媳妇压力太大了吧

㈧ 程序员证书和国家计算机二级证书哪个含金量高

如果你想从事程序员工作，当然考程序只资格证书。因为全国计算机等级考试是比较普遍。但程序员资格证书是从事这行业的证明。

㈨ 女程序员到底有没有被歧视

毕业一年的玲珑邪僧曾经在某家娱乐文化为主的大型公司面试前端时，在等候的过程中听到了隔壁有人说:“看到那个来面试前端的女生了吗，一看就不会写代码。”听得她喜忧参半。
就像“胸大无脑”这个词本身存在性别歧视的意味一样，“长得漂亮的女生一定是花瓶”也成为了大多数人对漂亮女生的直观印象。
女程序员想在工作能力上得到男性的认可，往往需要经过时间的验证。
高莹回忆起刚参加工作时，领导分配给她的都是团队里难度最低的任务。当时公司里有个男同事无意间瞟了一眼她写的代码，评价道:“写得不咋地，重构没意义，没有技术含量”。
几个月后她的能力得到了领导认可，也开始写一些有技术含量的代码，这时这个男同事对她的评价也随之发生了改变: “没想到你的代码水平不错，在女生里算写得比较好的了”。从这句话可以听出，他并没有把男女程序员的代码水平放在同一标准上进行比较，内心深处还是认为女生的代码能力不如男。
100offer让几位男程序员对女程序员的代码水平和工作能力做出了评价，他们的回答普遍比较正面。
虽然Tim认为女程序员一开始独立性差点，但是很快就能调整过来，她们的代码水平普遍和男程序员差不多，工作能力挺强。
徐风则说虽然女程序员调bug的时候也会骂脏话，但工作起来非常仔细认真，很是靠谱。
但当问到是否会对女程序员进行特殊照顾，比如不把难度大的工作交给他们时，大多数男程序员给出的答案都是:会。
男程序员在工作时会尽量不把难度高、工作量大、加班多的工作交给女程序员。一方面出于女性体质比男性弱的考虑，另一方面他们觉得这是对女性的一种出于本能的照顾。
那么，女程序员们是怎么看待自己的代码水平和抗压能力的呢?
iOS高级工程师张丹荔认为，女程序员里确实有代码写得差的，在占比上比男程序员大，但并不是全部。就像大学里很多计算机系的女生会找男生帮忙做作业一样，她们不是做不好，而是不感兴趣。如果真正喜欢技术的话，她相信女程序员的代码水平不会比男程序员差。
另一方面，男程序员有时宁愿自己加班也不愿把工作分配给女程序员，很大一部分原因是他们认为女生抗压能力差。关于这点，玲珑邪僧认为这并不是码农界特有的现象，相反，互联网圈是一个相对公平的领域，女程序员想要反驳这些说法、证实自己的能力并不难。
她认为相比于外界对女程序员的偏见，女程序员对自己的错误定位与消极评价才是更为最致命的。面对偏见，部分人会在潜意识里认同外界的说法，认为自身确实不抗压、能力弱，久而久之萌生放弃退却的念头。
所以，女性程序员应当正确客观地意识到自己的优势和不足，一定要拒绝裹足不前。
从采访可以看出，外貌、性别等外在因素容易被作为评判女程序员代码水平好坏的标准之一，这种现象在初入职场的新人身上尤为显着。

㈩ 你如何认识冲突、沟通与协调在当前我国企业的现状你认为应当如何改造

论着选摘

软件开发组织的沟通与协调

杨昆 王二平

中国科学院心理研究所 北京 100101

中国科学院研究生院 北京 100015

【摘要】在对软件开发中人员与组织问题进行回顾的基础上，该文首先就软件开发组织沟通与协调的重要性进行分析，然后对软件开发组织中的沟通与团队结构、沟通与项目成员、沟通频次分布、沟通方式等问题，以及整体协调、外部协调、内部协调等问题进行阐述。最后就今后软件开发组织沟通与协调问题可拓展的研究方向进行了讨论。

【关键词】沟通，协调，软件开发，组织心理学

1人员与组织因素

计算机软件产品的开发是信息技术的一个重要方面，也是构成信息产业的主要部分之一。随着软件产品的规模不断扩大，复杂程度不断提高，软件开发出现了大量问题，被称为“软件危机”(software crisis)。从组织心理学的角度来看，软件开发是一种典型的聚合型作业——成员虽然形式上独立完成分配的作业，但最后聚合为完整的作业。最终作业对各部分作业的技术标准和完成时限有要求，形成成员活动的相互制约。因此，软件开发的组织心理因素显得尤为重要。Ewusi-Mensah和Przasanyskid对开发失败的软件项目进行研究表明，管理是影响软件研发项目全局的因素，而技术只影响局部。Doherty和King等人在对大型软件组织的调查中发现，软件开发中的组织问题甚至比技术问题更为重要。

软件开发人员与组织因素的研究始于20世纪70年代。Weinberg认为软件编程既是个体活动也是社会活动。作为个体活动的编程行为包括：智力、问题解决能力、动机、经验等问题；作为社会活动的编程行为包括编程群体、团队和项目的组成与协调沟通等问题。Brooks认为软件的复杂度、不一致性、可变性和不可见性是软件的本质困难，导致人员沟通困难、产品瑕疵、成本超支和进度延迟。鉴于此Boehm提出“软件生产率改进机会树”(software proctivity improvement opportunity tree)，将人员和组织因素列为提高软件生产率的首要机会，包括人事安排、工具配备和管理三个要素。1976年Newman以《人件系统》为名探讨了软件开发中的人员风险，第一次提出与软件、硬件相对应的“人件”(Peopleware)概念。1987年DeMarco和Lister出版了《人件：富有成果的项目和团队》，引起业界对这一概念的重视。作者指出，知识工人需要思考，每个人都是独特的和不可替代的；强调工作环境对软件生产率有重大影响；提倡团队成员的互补性，认为给知识工作者以自由和信任最有可能形成优秀的团队。此后，Constantine扩大了“人件”概念，将软件的使用者也包括进来。卡内基梅隆大学软件工程研究所(SEI／CMU)综合软件开发人员与组织问题研究成果，推出软件能力成熟度模型(Software Capability Maturity Model，SW-CMM)和人员能力成熟度模型(People Capability Maturity Model，P-CMM)[13,14]对软件开发过程和人员管理活动进行规范。

2沟通与协调的重要性

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

协调(Coordination)是指“对相继的和同时的互依活动进行调和的过程”。狭义的协调仅指“对完成目标各活动间的相互依赖关系进行管理”。通用领域常见的依赖关系有以下几种：先决条件；资源共享；同时性。Toffolon和Dakhli从 软件开发活动复杂的背景分析其协调的重要性，认为：首先，软件开发组织从事的商业活动是持续变化的；其次，软件开发活动是在一个包含技术、经济、人员和组织等因素的大型环境中进行的；再者，软件开发活动本身是在一系列相互依赖过程的基础上进行的。McConnen通过文献分析总结出的12项软件开发典型错误中，与协调问题相关的有3项：(1)软件开发没有明确的目标和动机(2)随意取消开发的上游活动，如为了增加编码时间而压缩甚至取消设计活动(3)软件质量保证(SQA)部门协调能力薄弱。Brooks指出，软件开发过程是一个熵不断增加的过程。因此，软件开发需要大量的协调活动，从外界导入负熵流。

3沟通问题

3.1沟通与团队组织结构

Schneider man将软件开发团队概括为三种类型：传统团队、无我开发团队和主程序员制团队。这三种团队的沟通形式如图1所示(双向箭头表示信息的沟通)。Schneiderman认为，上述三种开发团队结构在沟通方面各有千秋。传统团队只允许必要的人际沟通，比较适合于项目本身就是层次结构的大型开发项目。无我的团队成员沟通十分充分，这种团队被认为适合于研制时间长、开发难度大的项目。而主程序员制团队突出主程序员的领导，属于集中领导形式，主程序员是沟通的核心，能否取得好的效果，很大程度上取决于主程序员的技术水平和管理才能。

随着对软件产品可用性(Usability)的重视，用户成为日益受到关注的信息源。Castka和Bamber在总结软件开发的团队策略时指出最好的创意通常来自客户或用户，他们认为Kidd在1994年提出的“人机综合制造”结构(Human And Computer Integrated Manufacturing，HCIM)，正是考虑了与客户沟通的因素实现快速制造范例的团队策略。“人机综合制造”结构如图2所示，这样的结构能够使企业实现组织内部围绕流程形成自然群体，并提供了将企业外部的用户、客户、供货商包含进来的空间。HICM结构强调了这些群体之间的沟通(人员和技术沟通总线)，同时描绘了人员与技术之间的接口。

3．2沟通与项目成员

Brooks认为“向进度落后的项目增加人手，只会使进度更加落后”，增加的沟通工作量可能完全抵消任务分解所产生的效率。Curtis通过对某个开发项目19次项目会议的持续观察，发现了符合“Brooks法则”的现象。该项目开发的后期，有两位分析员加入到被研究的项目中来，但对团队的绩效没有起到明显的效果，也没有提出新的设计方法。Curtis认为，在项目之初团队处于学习阶段，沟通和协调较活跃。如果一个新成员在项目的学习期结束后才加入团队，他带入的新知识对团队产生的作用是十分有限的。如果这些新的成员必须加入团队，项目经理应当更多地加强团队内部的沟通，确保新成员带入的知识能够与团队现有的想法综合在一起。

Curtis还发现，在开发团队中各成员对沟通活动的参与程度是不同的。在对17个大型项目的研究中发现项目早期的沟通是由少数个体占踞的，而对某个开发项目19次会议的持续观察也发现10个团队成员中有3人(一个客户代表，两个设计人员)似乎支配着整个项目，成为沟通的中枢。Curtis对这些项目的实际领导者的背景进行分析发现，这些人员同其他人员相比拥有更广的知识和经验领域，而不是在某个领域经历的时间更长。Sonnentag对德国和瑞士的29个软件开发项目的研究也发现类似的现象，积极沟通、绩效优秀的项目成员比平庸者从事过更多项目，掌握更多种开发语言，而不是有更长的工作年限。这表明，知识和经验的广度比资历更能预测成员在团队沟通中实际扮演的角色和他的绩效。

Clegg通过访谈研究发现，最终用户和项目经理这两个角色在软件开发沟通中的作用未得到发挥。大部分受访者强调，最终用户是系统开发的关键性角色，尤其在需求分析和应用领域知识的沟通方面。但在传统的开发过程中，最终用户只是参与需求获取和确认测试阶段，结构化方法和工具限制了用户专家发挥其角色的作用。在大部分访谈中，开发人员仍然被认为是软件开发的主体力量，即使对管理和新系统运行负责的客户经理也经常被认为缺少对项目的影响力。大部分受访者还强调，高层经理较缺乏对新技术及其长远影响的理解，成为技术沟通的瓶颈；项目经理缺乏对系统中人员和组织方面的重视，导致内部沟通不畅。

Steven和Henry根据Belbin的团队角色模型，对软件开发团队中“培养者”角色进行了实验研究。Belbin曾经提出，有效决策团队的核心由八个重要角色组成，其中“培养者”(Plant)角色是指团队中能够洞察行为过程、提出进一步建议和新思维的角色，其特点在于个人主义、思考严肃、有见识、非正统、智慧。Steven和Henry的结果表明，全部由“培养者”组成的团队在完成软件开发任务的时间上明显少于对照组。同时，通过观察发现，这样的团队有较强的沟通能力，他们不但自己能够产生创新的思想，而且能够很快理解队友的新想法。

3．3沟通的频次分布

软件开发中的沟通不仅限于团队内部，而是涉及整个组织内部和外部。Curtis通过现场研究，给出一个软件组织沟通的分层结构。如图3所示，共有五个层面：(1)个人层面(2)团队层面(3)项目层面(4)公司层面(5)商业环境层面。

该模型指出，软件开发的正式沟通最常发生在团队成员之间；同一项目的不同团队之间沟通相对较少，有一定合作关系的群体之间沟通更少，群体与外界的沟通最少。跨越不同层面之间的沟通渠道经常会过滤掉很多信息或对所传递的信息的意义产生曲解。除了正式的沟通结构引起的障碍，沟通的困难还在于地理上的分隔，文化差异和环境因素等。

Dutoit和Bruegge通过现场观察发现，成效良好的软件开发组织，其团队之间的沟通频次高于团队内部的沟通频次。另一方面，从时间坐标上来看，开发成效良好的团队在需求和联机调试两个阶段的沟通频次明显高于开发效果不佳的团队。Gopal，Mukhopadhyay和Krishnan对离岸软件开发的沟通问题进行了研究。离岸开发(offshore development)是指不在美国本土进行的软件开发。印度目前是美国最大的离岸软件开发承接国。研究者对34个在印度开发的软件项目进行问卷调查，结果表明成功的项目经理与软件提供商的沟通频次和与最终用户的沟通频次保持平衡。

3．4沟通的方式

在软件开发项目中，沟通的方式因沟通者处于软件组织的不同层面，开发项目处于不同阶段以及开发采用不同的方法而各不相同。Curtis在软件组织沟通分层结构中(图3)指出，不同层面的内部和群体之间的具有不同的沟通方式。(1)个人层面，正式沟通主要靠文档，并存在多个跨越组织边界的个人网络。(2)团队层面，文档沟通效果不佳，经常靠建立一种正规程序来促进沟通。(3)项目层面，最有效的沟通手段是正式评审，一个或多个项目成员横跨几个团队也有助于项目团队的沟通。(4)公司层面，非正式的人员接触比公司的评审程序更有利于沟通。(5)商业环境层面，最重要的是与各个客户洽谈，开发出一致认可的需求。

Kraul和Streeler对65个软件项目群体内部的沟通实践进行调查，从使用频率和价值评价两个维度考察常用的沟通技术。调查结果表明，由于需求评审、设计评审和客户测试等沟通方式允许担负不同职责的个人(需求分析员、系统工程师、构架师、程序员、测试员和客户)通过结构化的方式，对相互的工作发表各种不同的意见，因此其价值评价明显高于其使用频率所暗示的价值，其中同行讨论是最常用且评价最好的沟通技术。根据统计数据，被调查者对正式沟通的评价显着低于其使用频率所暗示的价值。这里所说的正式沟通既包括规范化的当面人际交往进行信息传递(代码检测、状态审查)也包括非当面的沟通(项目文档、源代码检查、里程碑时间表、错误跟踪等)。计算机辅助开发管理工具(CASE)则是使用频率最少且评价最低的沟通技术。

4协调问题

4.1整体协调

Toffolon和Dakhli指出软件开发活动要协调四个方面的依赖关系：股东／客户(S)、使用者(U)、软件构架师(A)和开发人员(D)，并提出全局软件模型(global soft waremodel)，如图4所示。研究者认为软件开发活动由四个空间组成的：问题空间、方案空间、建造空间和操作空间。问题空间(problem space)主要是定义股东／客户需要解决的问题及其组织解决方案，对股东／客户、使用者和构架师进行协调；方案空间(solution space)主要是针对问题的计算机解决方案，对软件构架师、股东／客户和开发人员进行协调；建造空间(construction space)主要是解决方案的实现，对开发人员、构架师和使用者进行协调；操作空间(operation space)主要是从最终用户的角度评价软件的可用性，从而也验证产品竞争力，对使用者、开发人员和股东／客户进行协调。

4.2外部协调

Toffolon和Dakhli还指出，软件开发的依赖关系可分为两类：外部依赖(又称为纵向依赖)和内部依赖(又称为横向依赖)。对应这些依赖关系的协调也可分为两类，即外部协调和内部协调。

软件开发的需求分析阶段是外部协调出现频次较高的阶段。Curtis等人在对大型开发项目的现场研究中发现，确定需求的过程中，需要对外部的市场影响和公司自身的实力进行协调，同时还要考虑一些潜在的影响，如图5所示。

Crowston和Kanunerer在对需求过程中协调与信息搜集活动的研究中指出，需求分析包含四种相互依赖关系：生产者—客户依赖、任务—子任务依赖、任务-成员依赖和需求之间的依赖。针对生产者-客户依赖的协调，研究者建议采用原型产品标准化、询问客户输入信息和使用者卷入开发等协调方式。针对任务—子任务依赖的协调，研究者指出，需求分析实质上是一项任务计划活动，分析人员必须了解哪些任务已完成，并选择那些已经完成或已存在的低端任务来实现高端任务。针对任务—成员依赖的协调，研究者指出，需求分析阶段的协调应当更侧重于明确执行特定任务所需资源的类型，从而协调任务与人员的关系。针对需求之间依赖的协调，研究者指出应当对这种依赖进行分类，采取措施针对可能对开发活动产生不良影响的依赖进行抑制。

4.3内部协调

研究者还对软件开发团队内部结构的协调职责进行了分析。传统的开发团队是由一个高级程序员指导若干初级程序员的工作，有经验的高级程序员作成项目领导者，指导若干成员或团队，而初级程序员对其编程软件负责，报酬是通过提升体现出来的。在这样一种层峰结构的开发队伍中，协调的工作量非常大，成本非常高。针对传统开发团队中程序员对其编程产品高度卷入和以提升作为承认程序员工作价值的唯一方式的状况，Weinberg提出“无我编程”(Egoless programming)的概念。他根据Festinger的认知失调理论，认为程序员由于对自己的编程产品高度卷入，会认为编出的程序是自己个人的产品，从而害怕别人发现其中的缺陷和错误，害怕暴露自己对任务的不胜任，不愿接受对其程序的改进建议。这不利于软件开发中的协调活动。因此，Weinberg建议成立“无我开发团队”(Egolessteam)，强调个人的成功和失败都被看作是团队共同努力的结果，鼓励合作而不是竞争。如果一个团队成员执行任务遇到困难，提倡其他成员贡献出自己的力量。Baker提出主程序员团队的模式。这种模式类似于外科手术的团队，主程序员是主要的设计者，编写重要的代码段落；后援程序员实施重要的操作，并为必要时接替主程序员做好准备；程序员在设计规范可实施的阶段加入团队。主程序员团队协调团队成员间的合作，提供了一个与医疗行业中围绕主治医师进行协调的相同的工作模式。

Levesque, Wilson和Wholey等人对软件团队是否会形成共同心智模式(shared mental model)的问题进行了实验研究。结果表明，并不是所有开发团队都会随着时间的推移形成共同心智模式。复杂项目的不同分工将导致成员和群体在知识上的差异。这种差异有时是功能上的，因此通过召开会议建立团队的共同心智模式成本很高。以共同心智模式作为协调手段所获得的效益将随项目规模的增加而不断降低。研究者同时指出，以共同心智模式作为协调手段最适合于团队成员具有相近技巧和能力的情况；而团队中某些成员的技巧和能力高于其他成员的情况下，更适合通过项目经理的工作进行协调；对于任务简单明确的情况，更适合把其他成员的工作视为黑盒，采用严格的规范进行协调。

5今后研究可拓展的方向

综上所述，西方学者对软件开发的沟通与协调问题进行了较为深入的研究。这些研究使 我们对软件开发中沟通的组织结构、频次分布、沟通方式等问题，以及软件开发组织的整体 协调和外部内部协调等问题有了一定的了解。今后研究可拓展的方向主要包括：

(1)软件开发组织的沟通协调行为与软件生命周期关系的研究。软件从孕育到衰亡的 生存过程称为生命周期(1ife cycle)。一般把软件生命周期分为：软件计划、需求分析、软 件设计、软件编码、软件测试和运行维护等六个阶段。不同的开发框架又可形成不同的生命 周期模型。以往涉及软件生命周期的沟通与协调行为研究多集中在前期的几个阶段。既然软 件开发活动是随生命周期的增长而熵不断增加的过程，今后的研究应当拓展到软件生命周期 的全程，尤其应加强对软件生命周期后期的沟通与协调问题研究。

(2)软件开发组织与用户的沟通与协调研究。以往对用户这一角色的沟通协调研究仅局限于需求分析阶段，随着市场对软件产品可用性的重视，开发过程日益强调全程的用户参 与(user involved)，今后应当对软件组织与用户的沟通与协调行为在软件生命周期各个阶段 的方式和作用进行更为广泛的研究。

(3)虚拟开发环境下的沟通与协调行为研究。技术的进步使得以虚拟团队的形式进行 软件开发成为可能。在虚拟环境下，软件开发组织中沟通与协调的动机、认知过程以及行为 过程会发生哪些改变是一个需要深入探讨的问题。

(4)西方沟通与协调问题研究成果对我国软件开发组织的适用性的研究。我国软件组织规模较小，管理水平相对较低，开发过程缺乏层次较为混乱。我国对软件开发的人员与组 织因素重视程度不足，目前仅有少量规范研究，尤其缺乏对软件开发组织沟通与协调问题的 实证研究。我国学者除了需要关注上述的研究拓展方向，还需要考察西方已有的软件组织沟 通与协调问题研究成果(如SW—CMM模型、P—CMM模型中关于沟通与协调的规范)是否 适合我国软件开发的组织环境。从而尽快形成适合我国软件开发组织的沟通与协调规范，促 进软件开发生产率和产品可用性。

【参考文献】（略）

文章选自《心理科学进展》（2004.6）