软件项目失败的心理原因

阅读量：3530 次

发布时间：2019-05-20

本文共 8833 字，大约阅读时间需要 29 分钟。

这是一篇有关软件工程领域中事务状态的评论文章。它讨论了程序员的实际挑战和实际职责。它把程序员分为四个类别：聪明、强盗、无助和愚蠢，另外两个类别是天真和无知。它讨论了程序员必须如何熟悉特定领域，不仅能够编码，而且实际上可以创建解决方案。它涉及到敏捷软件开发的失败。

免责声明

本文是我对软件工程领域中事务状态的个人看法。这并不是要成为科学论文，因此有许多陈述是故意加粗和直接的，以使文章简短。我尽力根据自己的观察和可用的资料指出软件项目失败的心理原因，但是我既不是专业的心理学家，也不是统计学家，而且我很可能完全错误。此外，我没有数据支持这些陈述，因此请持怀疑态度。

“我们真正的发现来自混乱，到了看起来错误愚蠢的地方。”
― Chuck Palahniuk

无休止的焦油坑

软件项目的失败定义为错过最后期限、预算超支、缺少功能和故障，这在软件行业中很普遍。关于这种情况的，已经写了很多文章，归咎于不切实际的项目目标，对所需资源的估计不正确，需求定义不清，报告不完善，风险未得到管理，沟通不畅，技术不成熟，开发实践松懈，项目管理不善，利益相关者政治或商业压力。其中大多数把重点放在开发过程的管理方面，正确地将其确定为导致这些失败的原因。我认为，基于多年的观察，这种苦难的另一个因素几乎完全被忽略或有意忽略了——程序员自己。

在本文全文中，我将使用“程序员”一词来表示软件开发人员，同时也表示技术负责人，架构师和需求/领域分析师，这些人都负责软件开发过程的技术部分，并且同样负责软件项目的成功或失败。

“聪明的”程序员

整个社会以及程序员社区之间的共同信念是，“程序员很聪明”，他们是从社会中最聪明的部分招募的。我相信这是基于错误的假设，即对机器进行编程很困难。我敢于不同意这个假设，因为实际上，编写代码并不比编写适当的烹饪食谱困难（两者都是关于如何做某事的明确指示）。本质上，计算机是非常简单的机器，它们基于基本的数学概念，例如变量，算术，向量，以及一些现实世界的概念，例如条件执行，重复和委托。这些概念是如此基础，以至于我们要么直观地了解它们，要么在小学阶段正在接受有关它们的教导。编程确实需要一定程度的读写能力，排除了不合适的个人，但声称某人“聪明”是因为他能够做到平均12岁的孩子能够做的事情，这是一个很夸张的说法。由于人类智力的分布是由，程序员的智力分布是用相同的钟形曲线给出的，图中左侧没有。

图1.假定的程序员智能分布。

根据说法，一个完成了1至3年大学教育的人的智商至少为104，我怀疑这是“24小时自学Java”类型的程序员的最低要求。这意味着，按照自然分布，有相当数量的。

挑战的本质

编码不是挑战。实际上，代码是任何人都愿意付出的最后一件事（尽管，具有讽刺意味的是，代码是最终产生的最重要的东西）。程序员的真正挑战和职责就是解决客户面临的问题，最有可能是代码，但不是必须的。这些问题通常只是部分“技术”问题，常常是社会问题，经常是复杂问题，经常是。随着问题复杂性的增长，解决问题所需的精力、智力、知识和奉献精神也随之增长，有时甚至成倍增长。认识到复杂性，对其进行限制并使其最小化是程序员的最终目标。这将门槛提高到很高，以至于普通人可能无法表现出工作所需的足够的个人素质，结果变得相对愚蠢。

正如：“我听到人们自豪地宣称他们已经建造了许多大型复杂系统。我试图提醒他们，如果他们在“前端”设计上花费更多的时间，则可以通过一个小型的简单系统来完成这项工作。大尺寸和复杂性不应视为目标。”

4 + 2模型

有必要在编程的上下文中明确定义愚蠢性。

“愚蠢的程序员会给软件产品带来复杂性，从而对其他程序员、客户或整个公司产生负面影响，而从这一事实中得不到任何好处，甚至可能对自己产生负面影响。”

通过说复杂性，我的意思是要么无法通过使用所谓的“蛮力”解决方案来降低软件所解决问题的内在复杂性，要么实际上是引入偶然的（通常是技术性的）复杂性，如果更多地考虑和解决，则可以避免这种情况。小心解决方案。

通过负面影响，我知道工作量增加、效率降低和成本增加。

继工作之后，程序员可以分为四类：聪明、强盗、无助和愚蠢，另外还有两类天真和无知。重要的是要记住，所提供的模型是动态的，每个人都倾向于根据各种内部和外部因素在类别之间迁移，但是似乎成熟的程序员通常在大多数时间都倾向于一个类别。

图2. 6种类型的程序员。

一个聪明的程序员能够制定问题和解决方案，从而降低他的大块工作和其他人的大块工作的复杂性。一个示例就是具有简化、一致功能的软件模块，以及易于实施、测试和集成的定义明确的接口。通过将思想放到要解决的问题的更广泛范围内，聪明的程序员可以为他本人、部分/整个组织以及客户实现积极的净效果。这些程序员通常被称为“10x程序员”，因为他们自己可以超越整个团队。

另一方面，一个强盗程序员主要集中在自己的任务上。他的首要任务是以他人为代价来优化自己的表现。这样的程序员通常不会攻击问题本身，而是会努力限制任务的范围（以减少工作量或获得更多时间），从而影响其他人的任务。另外，这样的程序员为了长期获得收益而牺牲了灵活性、性能、可测试性等代码质量，以期获得面向管理认可的短期收益。这样的人通常从自私的角度看待整个产品。他们的行动的净效果可能是正面的，也可能是负面的，这取决于个人是聪明的还是愚蠢的。此外，这些人经常表现出过度自信和表面上的专业精神来支持他们在组织中不劳而获的职位(暴露出一种傲慢）。这些人通常被称为“牛仔程序员”。

一个无助程序员是通常致力于公司成功的人，并称赞团队合作胜过个人主义。他通常与强盗具有相同的才智，但目标指向相反，因此他尽自己的全力为组织提供支持，但要付出自己的时间和绩效。他倾向于通过引入实际上可以避免的复杂性来折衷自己的设计和代码质量，以使事情“更容易为他人使用”，尽管这可能会给他带来更多问题。他倾向于不加补偿地修改他人的密码，加班无偿工作或贡献自己的空闲时间。他通常乐于教育他人，以期使他们或整个组织受益。这些行动的最终结果取决于个人是聪明的还是愚蠢的。这样的人通常在组织中保持低调。他们可能会被直接经理认可为他们的投入，但是由于他们对工作表现的负面评价（由于他们乐意引入的可避免的复杂性而导致的），因此很少因工作而获得回报。

一个愚蠢的程序员是有史以来最糟糕的一种。这是一个通常不知道自己在做什么的人，除了熟悉编程语言外，通常缺乏编程所需的任何技能。这样的人通常只能提供权宜之计，无法解决所要解决的问题。通常，缺陷的数量超过实现的功能的数量，代码很难甚至根本无法测试，并且会在整个组织中造成负面的连锁反应。他的工作质量低下（或缺乏）对组织和他自己都有负面影响，因为他经常花费大量的无偿加班费来解决自己遇到的问题。这些人通常占据组织的某些角落，在管理的视线范围内保持低调。他们从不进步，总的来说很高兴找到工作。愚蠢的程序员和无知的程序员只会被薪水所吸引。这些程序员有时被称为“1/10程序员”，因为他们可以让整个团队的表现达到极限。他们最终获得认可时通常并不十分丰富，但是他们所遭受的伤害与他们的人数不成比例。

另外两种类型的人是天真的和无知的。

一个天真的程序员专注于自己的工作，而不关心全局。一个天真的程序员在他的工作中投入了相当高的质量，但通常对任务之外的任何事情都不感兴趣。从组织的角度来看，他是隐形的。他往往朝九晚五地工作，很少进步。他暴露了工厂生产线工人的心态，易于管理，但是如果没有适当的管理，他的业绩可能会停滞不前，如果他在垂直轴上的位置接近于零。

最后一类包括无知的程序员。无知的程序员最明显的特征是“我不在乎”。他对自己的所作所为毫无兴趣。他只提供足够的质量不被解雇，没有考虑到其他人的任务或组织的目标。他通常不合作，对他的同事反应迟钝，造成整个组织的负面影响。另一方面，他可能会要求其他组织成员的帮助而造成干扰。他暴露了工厂生产线工人的心态，认为自己是一种“有机编译器”，可以将一组工件转换为代码而无需花费很多精力。他坚持要遵守开发流程，而不是完成实际工作。他对缺陷的态度通常是“我会在下一个冲刺中修复它”。可以管理他，但尽管管理努力，他可能不能创造价值，甚至补偿他的工资。他可能会暴露。我个人认为这一类别最为常见。

聪明和奉献只是这幅图的一部分，这幅图将在下面的段落中全面展现。

门口的野蛮人

世界上程序员的数量每五年翻一番。如果我们大胆地假设10年的经验可以让一个人成为专业人士，而普通人则可以工作40年，那么这意味着只有四分之一的程序员有足够的经验来实际地正确执行工作。与更稳定的学科相比，这个数字令人恐惧。在这些学科中，可以期望四分之三的人是经验丰富的专业人士，而其中只有一个人是学徒。更糟的是，我敢于进一步挑战这一点。

教育的苦难

首先，我想挑战学位具有相当大价值的说法。程序员的指数级增长意味着对计算机科学教师的需求呈指数级增长，这意味着经验丰富的计算机科学教师与新手的比例再次为1比3。这意味着大多数计算机科学专业的学生都是由年龄不大的人教书的，他们通常完全没有实践经验（通常是博士生）。我怀疑这种教学很少超出“遵循本书”的范围。这样做的结果是，CS毕业生能够编写代码并且仅此而已，因为没有人教实际上意味着什么。当然，只有在每位老师的学生人数多年来保持不变的前提下，这才是正确的（否则，教育质量下降得更快）。

无尽的无知之海

另一个重要事实是大学教授的知识与行业需求之间的不匹配。许多大学教授而行业则要求技能。问题是，工程技术往往不可能教，他们只能通过“”学习。这意味着，要成为软件工程专业人士，需要花费其职业生涯的前10年进行尝试、失败，从中学习并自己学习。这需要真正的兴趣、奉献精神和某种激情。假设这些质量在毕业生中的分布遵循钟形曲线是有道理的。如果是这样，那么只有大约20％的毕业生在职业生涯的前10年中会花在有意识的学习上，其中60％的人会在此过程中获得一些知识，而20％的人几乎不会学习。这意味着10年后，只有20％的程序员成为软件工程专业人士。这对业界形成了更可怕的看法，真正的专业人才仅占5％。如果我们假设强盗、无助和天真的人数是50％，

钟形曲线的谬误

2.5％的数量与钟形曲线分布相一致，其中距离平均值较两倍标准差更远的值的数量占2.1％，但假设程序员的能力分布由标准钟形曲线给出（可以假设在任何稳定的工程领域中都是错误的。考虑到三分之二的人口或多或少缺乏经验，而其余50％的职业水平低于平均水平，因此程序员之间实际的能力分配严重偏向于无能（见图2）。

图3.程序员的能力分布（红线）与预期分布（蓝线）的比较

巨大的误解

程序员是面向技术的。他们由于技术偏见而被计算所吸引。他们的工作不是写代码，就像他们通常认为的那样，他们的工作甚至不是创建软件。他们的工作是解决客户的问题，而软件只是解决问题的手段之一。可悲的是，他们很少设法理解这一点。

解决客户的问题需要的不仅仅是编写代码。它主要需要获得领域知识才能与客户进行交流。它需要深入客户的世界才能了解他的需求。熟悉特定领域的程序员不仅能够编码，而且实际上可以创建解决方案。否则，他是盲人。作为领域专家的程序员效率更高，因为他自己可以回答更多的问题。大多数程序员对领域一无所知。他们对此没有兴趣。他们故意将自己简化为“有机编译器”，因为它更容易。他们不明白公司和他们自己为此付出了代价。

书呆子文化

程序员经常从的学生中招募，他们表现出社交技能的不足。正如 “社会心理学家告诉我们，有不同的人格类型[…]。在一般人格特质中，有一项是根据三个“维度”来衡量的——一个人是“顺从”，“好斗”还是“超然”。合规型的特点是喜欢“与人合作并乐于助人”。积极进取型想要“赚钱和声望”，而独立型想要“留给自己，有创造力”。

现在，每个人都包含了这些属性的混合体，但是大多数人在一个方向上的倾向要大于其他方向。毫无疑问，当今的大多数编程人员都倾向于“独立”的方向，这既取决于个人选择，也因为程序员的招聘政策通常旨在寻找这类人。”

许多将来的程序员选择与计算机而不是与人互动，因为在这种关系中，他们是下达命令的人，而计算机通常不反对（除非代码不编译，但这是非个人的）。他们是那些受欺负的瘦男孩，最终找到了一个可以控制和支配的人。随着时间的流逝，他们会保持同一个书呆子，只是年龄越来越大。

正如温伯格先生：“程序员最容易识别的人格需求之一就是少量的“整洁”，这是一种轻微的强迫使自己的论文井井有条的[…]。另一个基本因素是[...]少量的“谦卑”，以防止“程序员学习一些简单的技术，觉得自己是专家，然后被计算机不可抗拒的力量压垮了” […]。谦卑硬币的另一面是“自信”或性格力量。程序员的工作是完成任务，有时候完成任务有时需要绕过障碍，越过障碍或将其击倒。”

在我的整个职业生涯中，我发现这些障碍中的大多数不是技术性而是社会性。他们要求挑战他人，迫使他们离开自己的舒适区，然后说“对管理者而言，换句话说，它需要勇气。许多程序员不知道如何处理冲突，所以他们宁愿避免冲突(天真和无助)，把自己的那部分加到最终的失败中。

无知者的信心

尽管我先前曾估计该行业中有许多非专业人员，但我看不到程序员人数会大量减少。我没有遇到过很多程序员仅仅因为意识到自己不适合编程而每年换工作的情况。我认为，这样做的原因（当然是薪水除外）是“，“这是一种认知偏见，其中能力低下的人具有虚幻的优势，并错误地评估了其认知能力。虚幻的优越感的认知偏差来自于能力低下的人无法认识到他们缺乏能力。没有元认知的自我意识，低能者将无法客观地评估其能力或能力。”换句话说，非专业的程序员无法认识到他们缺乏专业精神，因为他们不知道其构成是什么。他们表现出。此外，他们无法充分判断自己的非职业同龄人。这意味着，由于缺少真正的专业人员，因此，有很多团队完全由对他们自己有很高评价的非专业程序员组成，只是因为团队中没有人能够认出自己的低级职位。我不敢在此发表明确的声明，但我怀疑这种影响在无知和愚蠢者中最为普遍。

无能的领导者

在另一种能力范围内，还有另一种肮脏的野兽，称为。这种心理现象与达到最高水平的有天赋的人有关——。这是一种心理模式，在这种模式中，个人怀疑自己的成就，并持续地内在地害怕被暴露为“欺诈”。尽管有外部证据显示他们的能力，但经历这种现象的人仍然坚信他们是欺诈，不应该得到他们所取得的一切。冒名顶替的人错误地将自己的成功归因于运气，或者由于欺骗他人而认为自己比自己认为的自己更聪明”。这意味着，一部分顶级专业人才（如果假设正常分配，则为20％）不能仅仅因为他们认为自己不是专业人才而无法成为技术领导者。这些人认为成功解决的问题是如此简单，以至任何人都可以做到，包括无能的人。他们没有意识到同龄人的无能或没有透露自己的无能，从而维持了现状，最终影响了他们。我怀疑这种现象主要涉及无助和天真，以及一些倾向于无助的聪明人。

内驱动的发展

众所周知，程序员对所处理问题的复杂性过于乐观。实际上，最不现实的项目目标（）是最常见的项目失败。许多人试图回答如何提高程序员的。另一方面，我试图攻击“为什么”。程序员过度承诺的第一个原因是在要求他们提供估算值时对问题没有充分的了解。正如大卫·帕纳斯（David Parnas）：“人们倾向于低估任务的难度。过度自信解释了我看到的大多数可怜的软件。正确地做是艰苦的工作。快捷键会将您引向错误的方向，并且通常会导致灾难。”这是一个完全合理的原因，但在我看来，还有一个心理原因。感到内疚。

每个人都无法兑现。业余选手10次中有8次失败。专业人士10次中有2次失败。程序员在职业生涯初期不可避免地会失败。失败会引起罪恶感，这就是恶性循环的开始，其运作方式如下：

程序员对管理做出乐观的承诺。

程序员无法兑现承诺。

程序员会做出另一个过分乐观的承诺，以弥补之前的失败。

他再次失败，循环重复。

如果没有任何改善，则整个程序员的整个职业生涯都会重复进行。这就是愚蠢和无助的结局（尽管由于不同的原因）。这就是导致缺乏信任的原因。这就是导致微管理的原因。

有两种方法可以摆脱这种情况。首先是自我完善。一旦技能发展，任务就变得更加容易和可预测。人们还学会更好地预测可能会出现的潜在障碍。这就是聪明的处理它的方式。第二个是通过降低承诺来缓解风险，这是因为估计值远远超出了执行任务所需的实际值。这就是强盗和无知者的最终结果。这就是导致停滞的原因，因为每一项进展都被视为代价过高。

敏捷的必然失败

已成为的既定方法，但事实证明，它并不能很好地履行其诺言。我深信这是因为敏捷软件开发只有在真正对客户领域感兴趣的、有才干的、聪明而勇敢的程序员执行时，才有机会发挥作用。在敏捷软件开发宣言指出它明确地列出它的：

“在整个项目中，业务人员和开发人员必须每天一起工作。”——需要客户的领域兴趣；

“围绕有积极性的人建立项目。为他们提供环境并支持他们的需求，并相信他们能够完成工作。” ——需要动力和激情；

“持续关注技术卓越性和良好的设计可增强敏捷性。” ——需要能力和智力；

“简单——最大化未完成工作量的艺术——是必不可少的。” ——还需要能力和智力；

“最好的架构，需求和设计来自自组织团队。”——需要能力、智慧和勇气。

敏捷软件开发的失败是不可避免的。假设该行业中智能程序员的数量约为2.5％（1/40），并且团队的最大规模为9人，那么平均每个SCRUM团队由至少一个聪明的人组成的可能性小于25％。如果团队仅由无助、天真、强盗、无知和愚蠢的人组成，那么效果几乎不会是积极的。

面对敏捷软件开发的失败，公司回到，这是用“工厂生产线工人”心态的程序员实现任何目标的唯一途径。或者，他们假装“敏捷”并在顶部进行瀑布处理。两者都以巨大的过程开销为代价，而这些开销通常会使项目瘫痪。公司没有意识到的是，您不能用人才、知识、智力、奉献精神和关心来代替流程。这是一种失败的情况，因为实际上无法成功应用任何进程，因为无法管理糟糕的程序员以使其成功。

不能不做的苦事

我从戴维·帕纳斯（David Parnas）找到了这个启发性的

软件工程中最常被忽视的风险是“无能的程序员”。据估计，在美国所需的程序员数量超过200,000。这完全是误导。这不是数量问题；我们有质量问题。一个糟糕的程序员一年可以轻松创建两个新工作。雇用更多的不良程序员只会增加我们对他们的需求。如果我们拥有更多优秀的程序员，并且能够轻松地识别他们，那么我们将需要更少而不是更多。”

如果项目推迟了，最好解雇糟糕的程序员，而不是雇用更多的程序员。至少，他们不会妨碍好的人。

不解雇程序员是一个大问题，因为这个行业没有责任感。演员在每部电影后都会被解雇，因此每次演出都感到压力。具有人为创造的需求的程序员每次都不会感到压力，因为他们可以在情况变糟之前工作（），从而表现出较高的性能。这会加剧无能和愚蠢。

第十三原则

遵循敏捷的12条原则，我还要添加另一条原则：“不要雇用愚蠢的程序员。”

不要与图2中对角线下方的程序员打交道，因为它们会产生负的净价值，并且必然会导致软件项目失败。确定并解雇他们。表现最好的组合包括天真的和无奈的，这可能是一些聪明-强盗，如果你能抱紧他们（前提是他们有一些有价值的能力,超过成本的微观管理,如图形设计,硬件设计,亲密的领域知识,等等）。此外，要提防太多的无助，因为他们的无助最终会打击您。

新希望

上面的文字可能表明我是一个虚荣的自我的高级程序员，试图判断那些不幸的同行，但是事实并非如此。我希望本文能阐明一些软件项目失败的原因，我认为这些原因尚未得到足够的调查。我希望它可以帮助开发人员在我描述的多维空间中定位自己，并找到改进的方法。我希望它可以帮助管理人员识别团队的缺陷，并采取适当的纠正措施。它无疑有助于我更好地理解事物，在周围的混乱中找到更多的秩序，我希望它也能为每个读者服务。