如何挽救失败的软件项目

引言

在本文中，我将讨论一些关于扭转项目并使其免遭失败的场景和情况。我还会讨论那些机会渺茫或根本不存在的情况。最后，我将讨论一些可能的解决方案和陷阱。警告一下，这不会是关于感人的故事，事后人们可能也不会唱“ kumbaya ”。

项目的失败与成功可以有很多种定义方式，这取决于您是在一家产品公司、服务公司还是开发内部项目的非科技公司。第一种情况，成功可能定义为达成目标（业务和/或技术）并按时完成；在服务公司，成功是按时按规格为特定客户或客户交付；在后一种情况，成功意味着按时交付，满足内部利益相关者的要求。我知道……在定义成功方面，这些说法都很模糊。

虽然成功并非唾手可得，但失败却可能早早地露出丑陋的面目。当错过截止日期、预算像火柴一样烧尽、出现大量 Bug 显示出技术缺陷时。随着问题的不断积累，人们开始感到焦虑，声誉受到威胁，有时甚至公司的未来也岌岌可危。当项目濒临失败时，就需要改变方向，换一位新船长来掌舵。

抛开航海比喻，在压力下的项目经理就像一名足球队教练，他被聘来避免球队降级（没错，体育比喻）。有些教练擅长扭转局面，但这并非一份令人愉快的工作。通常，这会给团队成员带来后果，一些球员在过程中会留下终身健康问题。

但项目管理并非在竞争激烈的体育赛事环境中运作，项目也不是需要赢得一场场比赛才能获胜的系列赛，中间的胜利可能对利益相关者来说是看不见的，而且定义成功不像查看比分那样容易。

最佳情况场景

失败以多种形式出现，有时是由于外部原因，比如关键人物去世、经济意外衰退、某个中间件产品停产，这些都可能严重影响成功的几率。很多原因是内部的，比如在选择经理和团队成员时的错误决策、公司文化以及其他人为因素。根据我的经验，技术问题通常比人为问题更容易解决。尤其是当需要更多时间来掌握学习曲线时。而人为问题则可能导致大量戏剧化和肥皂剧式的重演，只不过没有额外的戏剧性音乐。

当您面对一个失败项目的困境时，您所处的最有利的情况是：

• 高层管理人员致力于项目的成功（有点绝望也好，但不要太过分）。
• 前项目经理已经离开了公司（稍后会详细介绍）。
• 团队成员并非都是平庸之辈，并拥有足够的技能来完成工作。
• 预算没有捉襟见肘。
• 公司的文化不是那种阴谋诡计的类型。

您首先需要做的是了解项目的目标、范围、时间表、技术架构和技术依赖关系。之后，与团队会面，了解每个人的角色，观察他们的互动和仪态，不要根据第一印象做出判断。讨论团队迄今为止所做的工作，如果可能，进行一对一的会谈，检查团队会议和个人互动中的信息是否相互一致。以及，团队提供的信息是否与高层管理的反馈一致。

如果可能，在与客户或第三方利益相关者互动之前，了解前任项目经理是否撒谎、歪曲事实、欺骗或以任何方式编造故事来塑造他们对项目状态的看法。如果答案是肯定的，那么要小心……人们在听到事实时常常会非常激动，所以先收集一些关于这些第三方的信息，并且不要在第一次与他们见面时就进行任何揭露。

在与您的同事和直属上级进行的首次会谈中，讨论一些小的入职问题并观察他们的反应，同时评估他们对与项目和公司相关的少量信息请求的响应。在这些会议中，观察每个人的行为，判断是否存在容易发脾气或欺凌其他人的管理者。观察其他管理者在感到压力时的反应。这将有助于评估公司内部奖惩制度的应用程度以及通常会招聘哪种类型的管理者。

在初步了解团队、同事和第三方之后，进行初步评估，确定谁能帮助您，谁是中立的，谁会阻碍您。这种评估不是静态的，而是一个持续的循环，直到项目完成。因此，当您实施一项举措时，您将监控反馈和响应，重新评估您的立场，并在下一次迭代中进行纠正性更改。

需要快速评估的一项内容是团队的整体构成，识别表现不佳的成员和制造“熵”的团队成员。那些对贡献的代码量贡献不大，但缺陷率很高；或者频繁导致构建失败且不听取其他团队成员反馈的成员，应该尽快、尽可能无痛地将其移出团队。如果可能，寻找内部替代人选，优先选择有良好业绩记录且知道自己在做什么的开发人员。如果您需要招聘或外包，优先选择您认识且合作过并符合上述条件的人——保持与过去表现良好且仍能帮助您或推荐合适人选的开发人员的联系。

密切关注那些不断质疑您行动的“键盘侠”，在您展示成果之前，他们尤其可能造成麻烦，并会影响他人和高层管理人员的态度。

在项目方面，您需要严格管理范围，识别并专注于核心可交付成果至关重要，避免被次要功能分散注意力。与利益相关者重新协商范围，让他们同意一组首要的可交付成果。此时，提前知道前任经理是否过度承诺或谎报项目状态非常重要。范围需要在每次迭代中协商，并且需要符合团队的能力和技能，过度承诺或过度承诺不会使您的项目按时按规格完成。

为了评估项目状态，您需要定期与团队成员会面，无论是站会、冲刺会议还是讨论项目问题的会议。如果可能，单独会面，以检查关键进展，评估仍需要哪些工作，以及是否存在任何障碍。坚持采用持续发布系统，至少包含一套健全性测试，以尽早发现问题。验证 QA 团队的反馈，检查缺陷数量的变化趋势，并验证单个团队成员是否需要帮助来解决任何缺陷。优先考虑稳定性而非功能，团队成员需要在开始新工作之前修复缺陷。

在 QA 方面，倾向于采用数据驱动的方法，建立一个流程，将团队开发的软件项目的测试结果与产品旧版本、客户或公司数据、或由 QA 团队或业务分析师开发的业务场景进行比较。还可以使用方法生成噪声数据，以验证软件如何处理边界条件和错误。这将提供一个进展的基准，有助于获得利益相关者的信任。

警惕那些开始破坏您构建的软件依赖项，跟踪它们的版本，并与团队一起判断何时回滚到旧版本，何时修复不再与新版本库兼容的代码。将这项工作安排在交付工作周围，避免在截止日期临近时进行。此外，避免出于任性原因切换软件库的诱惑，只有当有明显优势且时间允许返工时才这样做。

尽可能地自动化，不要陷入“没时间自动化”的陷阱。从一开始就通过识别合适的候选人来开始自动化，并识别具有最多重复模式的工作。通过这样做，您可以创造足够的缓冲时间，用于缓解因意外事件、遗漏的需求或修复缺陷而产生的额外返工。

发布清晰而频繁的报告，说明已达到的里程碑，但要注意不要听起来过于乐观。这可能会促使高层管理人员在关键工作完成之前开始削减资源、预算或缩短截止日期。此外，它还可能造成夸大的期望，这些期望可能会被未知的未知因素所打破。所有这些都会增加不必要的压力，并可能对您自身声誉构成风险。

在团队达到困难的里程碑时，寻找奖励团队的方法，这是表明其努力得到认可的重要信号。在与他们沟通时，要直率而清晰。如果因为利益相关者的想法改变而有项目被取消的风险，请告知他们。与团队讨论这些风险，以及正在采取的可以减轻风险的行动。

在这种情况下，成功的扭转局面仍然是艰巨的任务，但您仍然需要管理与第三方利益相关者的关系。需要让他们对可交付成果的质量感到满意，并让他们觉得项目范围能为他们带来价值。如果他们觉得不然，他们可能会试图取消他们的参与或取消项目。

基于这种情况，我已经提供了一个模板，将在接下来的不那么乐观的案例中进行扩展。

项目失控 II

在这种情况下，您将面临艰巨的任务。这里出现问题的风险增加，主要是由于人为因素。在这种情况下，项目已经显现出压力的迹象，并且有额外的因素会增加风险，例如：

• 高层管理人员要求快速出成果，但并未投入太多新资源或支持。
• 团队不平衡，缺少足够的高技能开发人员。
• 预算取决于目标的达成，因此取消项目是 constant 威胁。
• 前任项目经理仍在组织内工作。

在这种情况下，您需要迅速确定哪些开发人员足够优秀可以继续工作，并确定您需要尽快替换哪些人。您还需要核实团队领导者是否是问题的一部分，以及您是否需要寻找新的领导者。在这种情况下，作为内部人士实际上是有益的，您可能已经认识团队中的人员以及公司里谁可以被分配过来。这样您就可以重组团队以满足项目需求。而一个外来者将很难快速了解谁能出成果，谁在刷 Facebook 假装忙碌。

另一个问题是了解前任项目经理为什么离开了项目但仍然保住了在公司的职位，其原因将表明这是否会成为您的问题。

• 生病或倦怠，这可能表明他/她承受了巨大的压力。
• 请假，这可以用来避免职业生涯受损的事件，并将责任推给别人。
• 前任项目经理有一个强大的保护者，为了避免因失败而声名扫地，找到了新的职位。在这种情况下，要非常小心。
• 只是放弃了项目并协商了新的职位。

前任项目经理也可以成为搅局者，以防您的表现比他/她好，为了避免显得不好，他/她可能会觉得有必要影响其他管理者对您的看法。因此，了解他/她的性格以评估这种风险是很有好处的，可以从其他与他/她共事过的人那里悄悄地获取一些参考。

了解是否有其他管理者干预或试图改变项目方向以满足他们的需求。检查他们的影响力和他们在权力等级中的地位。检查他们是否可以被拉拢，或者是否可以说服他们退出并保持观望。否则，您可能不得不使用策略让他们出局。警告：使用这些手段会让您树敌，他们会在时机成熟时毫不犹豫地惩罚您。

与利益相关者沟通，了解他们目前的承诺水平以及他们对项目的总体情绪。还要检查是否有迹象表明他们正在联系或已经与其他公司或团队建立了合作关系来完成类似的工作。

解决部门间利益冲突的任何问题。例如，QA 是一个独立的团队。检查 QA 负责人有多大程度地希望获得更大的可用预算份额。以及，QA 团队是否采用最大化测试时间或资源的策略。这可能是，例如，在每次发布前一天找到关键缺陷。始终检查激励这种行为的因素，以及它如何损害开发和 QA 团队之间的信任。

在识别出内部和外部政治风险的来源后，制定应对这些风险的策略，并减轻它们，以便开发团队能够免受这些问题的影响，并在相对平静的条件下继续工作。

努力保持对项目状态的有效控制循环，尽早跟踪问题，不要陷入“魔幻思维”的陷阱。设计巧妙的方法，从可用的跟踪工具中获取信息，以便您可以自动化部分流程。

密切关注激励问题，如果团队成员变得 unresponsive，或者两个团队成员之间存在未声明的冲突。或者更糟的是，团队分裂成派系。努力尽快解决这些问题，不要让它们恶化。因为您的成功将取决于让他们作为一个整体协同工作。

在这些情况下，挑战将是处理办公室内部的政治局面，维持外部利益相关者的承诺，以及解决项目团队的任何问题，同时一开始处于不利地位。而且很可能有很多坎坷的路要走……

绝望的情况

并非所有项目都可以挽救，有时您应该考虑放弃这些“发展机会”。您需要能够识别出何时出现这些情况。因为有些人可能想把责任推给您或其他人。为了避免被愚弄，您需要读懂信号，例如：

• 高层管理人员和/或外部利益相关者对项目没有任何承诺。
• 没有预算，只有模糊的关于新预算分配的承诺。
• 团队充满了平庸之辈。
• 公司是办公室政治的温床。

例如，您可能会被告知您将接替一位备受瞩目的项目的前任项目经理，而这位经理将被提升到新的职位。在您进行一些尽职调查后（或者您已经知道），您会发现该项目只不过是前任项目经理的一个“占位符”，而这位项目经理已经得到了快速的晋升，但需要一个“水份”项目来证明这次晋升的合理性。现在，该项目从未打算产生结果，但现在需要关闭它，而不会损害前任项目经理的声誉。在这种情况下，您就是指定的替罪羊，对您来说没有任何好处。即使您能够展示成果，高层管理人员也可能积极地破坏项目以保护前任项目经理。尽量找一个好借口不接受这种情况，或者找一份新工作。

避免卷入那些所有人都期望“最后一搏”来拯救局面的项目。如果它带有绝望的味道，快跑！

如果开发团队充满了前任项目经理或其他管理者的朋友，并且对工作态度散漫。而您只能依靠团队中的这些人，并且无法招聘新人来替换他们。不要愁白了头，找个新职位。避免与那些您不信任工作或承诺的人共事。

结论

扭转项目并安全地将其导向成功是一门艺术，正如您所见，我并没有过多地谈论技术方面，而是更多地关注人为因素。我相信大多数失败的项目通常是由于人为干预而陷入那种境地的。技术方面和掌握学习曲线所需的时间一样令人生畏，并且需要大量的资源才能完成。除非您在当时的技术手段和概念下试图做不可能的事情。

项目通常会因为以下原因而失败：范围管理失败、团队成员技能不均衡、未能妥善管理团队与利益相关者之间的关系、高层缺乏充分的承诺，以及未能管理办公室政治。

要取得成功，您需要找到自己处理这些问题的方式。一个好的建议是，找到并留住您的盟友。您会需要他们，因为没有人能够独自完成所有事情。