保证失败的 7 个因素

不要欣赏员工、低估复杂性或依赖神话。 如果考虑到这些和其他因素，您的项目肯定会失败。

你知道吗？ 在数周和数月的时间里，项目经理都会报告他的项目。 当然，经典的状态灯也不能少。 这一直是绿色的：一切正常。 但是有一天，红绿灯突然变红了！ 因此，对于那些负责的人来说，一个非常不愉快的处理过程开始了。 大多数情况下，第一个问题适用于罪魁祸首，第二个问题适用于原因，然后一个仅用于可能的解决方案。

以下是几乎注定失败的 7 个典型因素。

因素一：忽视人为因素

作为开发人员、项目经理、教练和危机管理人员多年，我发现人际关系紧张是实施 IT 项目的最大障碍。 相反，员工之间的化学反应是正确的，并且存在开放、容错的氛围，可以找到解决所有困难的方法——即使是在危急情况下。

避免冲突是人的本性。 因此，如果人们（例如项目经理）完全忽视或将目光移开太久，这是很自然的。 但冲突通常不会自行化解。 研究是必需的，作为适度和至少对变化或解决方案的看法。

有时是小事产生大影响，例如员工的新工作。 但是往往需要更大的开销，比如团队的重组，才能让项目重新归于平静。 然而，最糟糕的选择是无视人为因素。

因素 2：想太多或做得太小

一些公司接管了一个项目。 他们低估了复杂性、风险以及巨大的人力和物力。 无论成本如何，我的组织是否能够管理一个拥有 100 名员工的项目？ 我们是否有足够的工作岗位、会议室、网络容量、开发服务器等？

公司是否能够满足大型敏捷开发团队对包括持续集成/交付在内的开发和测试轨道的要求？ 预测到此类问题，商业案例应该是经过实际计算的。 我曾多次看到，在一个巨大的项目开始前不久，人们才清楚地意识到，最终的系统实际上并不需要，因为它不适合公司的商业模式。 不幸的是，之前没有人注意到这一点。

另一个可识别的模式：主角绝对想实现一个 SW，例如出于声望原因或利用员工，并且计算成本可以忽略不计。 如果后来的项目经理不够强大，无法在决策机构的背景下提出差异，这就会产生很高的危机潜力。

因素 3：100% 依赖估计和计划

一个广为流传的神话是估计和规划的可靠性。 该项目的概念由其独特性定义。 也许已经有类似的项目，但原则上，公司的每一个项目都在进入新的领域。 这意味着估计只能与创作者的经验和他们对当前项目的适应能力一样好。

但是，计划永远不能包括自发事件、需求、技术方面的变化或非预期风险的进入。 归根结底，估计和基于估计的计划无非是对未来的赌注！ 接受这个事实是向前迈出的第一步。 纪律、勇气和制度有助于预防或缓解可能出现的危机。

因素 4：神奇的 PM 三角形一直被忽视

学习计算机科学，第一学期，第一堂课项目管理： “神奇的 PM 三角形” 。 对管理任务感兴趣的人很早就了解了这个三角形的规律。 这些表示三个参数之一的变化不可避免地导致至少一个其他参数的后果。

然而，这些法律在实践中非常乐意忽视。 正如在估算和规划的背景下已经提到的，一个项目在某种程度上是独一无二的，并且计划外影响的可能性非常高。 这就是为什么迟早有必要让负责人对这些影响作出反应的几乎每个项目。 但是，如果所有参数都是固定的，即客户继续要求遵守时间、预算和内容，那么失败只是时间问题。

因素 5：一切的文档

贝肯鲍尔之后免费： “我们称之为经典！” 尽管越来越多的公司依赖于敏捷程序（主要是 Scrum），但仍然可以找到组织和项目，它们赋予广泛的文档比要创建的软件更重要的意义。 这是一个高风险，尤其是在大型项目中。 通常，顾问和部门专家在数千页上的搜索通常会工作数月甚至数年，随后将由 SW 中的另一个团队翻译。

文档越广泛，实现时间越长，软件越不可能符合用户的实际需求。 对市场变化的反应是不可能的，或者只有付出巨大的努力和暂时的让步才有可能。 文档提供了可以删除产品的基础。 不幸的是，所写的不一定清楚，结果与最初的想法不同。 多少次我听到部门人员和最终用户的一句话： “哦，我想象的很不一样！” .

因素 6：没有平衡的项目组织

一个由 20 名开发人员和 1 名技术联系人组成的团队？ 无需专业知识即可认识到此构造迟早会失败。 在一个项目开始的时候，不管是瀑布式还是敏捷式，都可能还行，因为开发人员忙于框架或搭建环境。 但很快员工就会提出问题——需要密集的专业支持。

一个单一的学科专家永远无法承受这种时间和情感上的压力，需要在人员和实施过程中得到支持。 然而，以通信限制来应对人员瓶颈是一个非常糟糕的主意。

这也是一个流行的想法，也是典型管理错误规模的最前沿：一名员工收集开发人员的问题，与技术联系人讨论，然后返回答案。 通过这种方式，您创造了一个卓越的瓶颈，引发了极高的错误率，并显着延迟了开发。

因素 7：慢慢加热青蛙

你知道这个故事吗？ 如果你把一只青蛙放在一个装有水的平底锅里，并不断地把它加热到煮熟的程度，青蛙就不会试图逃跑。 如果你直接把它扔进热水里，它会立刻跳出来。

我最近几年对我最重要的了解之一是IT项目的员工随着盲目性的增加而到期。 一旦建立的流程可能会在回顾中受到质疑，但很少真正是激烈的。 人们对变化做出反应的能力会随着项目的持续时间而消失。

因此，之前未参与的外部顾问建议（大型）项目进行零星照明（健康检查），以发现泄漏的潜在非目标路径。 最迟在认识到全面危机之后，仅靠现有员工几乎不可能扭转局面。

所以这是可能的

所描述的典型管理错误只是我个人行为模式命中列表中的一小部分，它阻碍甚至阻碍了SW开发项目的顺利完成。 从远处看，可能会产生这样的印象，即在项目的早期阶段很容易发现问题并加以纠正。 但据称不可动摇的框架条件和提到的盲目性往往使做出正确的决定变得困难。 开头所说的Standish Group的统计数据表明，这一年是一年又一年。

如果项目遇到麻烦，强烈建议外部危机管理人员能够客观地分析和采取行动，不受敏感性和项目历史的影响。 在项目中听取人们意见的专家的唯一参与已经可以产生积极的影响。 选择合适的措施也能实现转型，最终实现扭亏为盈。