18、项目成功完成的策略与方法-优快云博客

本文链接：https://blog.youkuaiyun.com/root9/article/details/153301042

项目成功完成的策略与方法

1. 技术项目的完成理念

在技术领域，常有人认为技术项目存在明确的完成节点，但实际上技术的发展是永无止境的。就像在之前的工作中，有人常说 “当网站完成时……”，但事实是网站永远没有真正完成的那一天，它需要不断维护和改进。所以，对于现代化项目而言，明确成功的定义，清楚何时完成现代化工作以及后续行动至关重要。

2. 揭示潜在假设

许多系统出现问题，是因为组织内各部门对自身角色以及如何为整体目标做贡献的理解存在差异。现代化、重构或重新思考现有技术系统是一个长期过程，可能会持续数月甚至数年。因此，团队成员必须能够回答 “如何判断项目是否在变好” 这个问题。

团队不仅要知道长期来看项目变好的标准，还需了解短期内的改善表现。这类工作很艰辛，要做好就必须保持韧性，同时要留意当人们认为项目进展不顺时的行为。管理自身的疑虑已属不易，应对那些因对项目改善的期望与团队其他成员不同而进行破坏的同事则更难。

3. 确定成功标准的方法

3.1 成功标准法

成功并非一蹴而就，那么如何判断项目是否在朝着正确方向前进呢？与团队和关键利益相关者设定成功标准时，首先要确定评估的时间范围。例如，两人都认为发布某个功能是成功的标志，但如果对时间线存在分歧，就可能产生冲突。三个月发布和一周发布的意义截然不同，对于期望一周发布的人来说，延迟发布像是危险信号；而对于认为应在一年后发布的人来说，同样的发布却是一种验证。

如果熟悉目标与关键成果法（OKRs），成功标准与之类似。先定义目标，再明确如何判断是否达到目标。不同的是，OKRs 通常关注目标完成的标志，而成功标准应关注项目朝着正确方向前进的标志。

这种策略的价值在于，所选标准能表明团队将采取的方法，避免人们就方法进行争论。如果成功标准侧重于实现新功能，团队就不太可能优先解决技术债务；如果标准是减少错误数量或加快恢复时间，团队则需专注于改进现有代码。

同一个目标，根据团队模式的不同，成功标准可能大相径庭。例如，咨询模式会关注客户吸收和采用流程及最佳实践的能力，而非部署情况。软件工程师容易陷入认为有效工作就是编写代码的误区，但有时教他人完成工作比自己做更接近预期结果。

以下是一个添加持续集成/持续部署的示例：
- 目标：将服务迁移到独立的部署管道。
- 时间线 ：一个季度。
- 成功标准 ：
- 部署时间缩短 20%。
- 服务团队的任何成员都能发起并管理部署。
- 每周的部署次数增加。

3.2 诊断 - 政策 - 行动法

由 Richard Rumelt 提出的这种方法，与成功标准法使用相同的信息，但呈现方式略有不同。信息分为三个部分：诊断、政策和行动。诊断是对要解决问题的定义；政策是潜在解决方案的边界，即解决方案应包含或不包含的内容；行动是团队在不违反政策的前提下解决问题的步骤。

这种方法更侧重于要做什么以及如何去做。在对成功的定义缺乏共识且没有单一权威来做决策的情况下，这种方法可能更适用。但如果团队在制定路线图方面存在困难，可能会觉得这种方法更具挑战性。

以下是一个升级数据库的示例：
- 诊断：数据库软件落后多个版本，供应商不再提供支持。
- 政策：采用蓝绿部署，绝不一次性关闭一个数据库版本并开启另一个。
- 行动：
- 每次升级前备份数据。
- 在特定日期升级到 3.2 版本。
- 在特定日期更新到 3.3 版本。

3.3 两种方法的比较

在定义成功方面，成功标准法和诊断 - 政策 - 行动法各有优缺点，具体如下表所示：
|方法|优点|缺点|
| ---- | ---- | ---- |
|成功标准法|将现代化活动与可展示的价值更直接关联，为团队工作提供更大灵活性，适合与可能进行微观管理的上级和监督力量合作|当团队对日常工作不确定时，其灵活性会导致混乱|
|诊断 - 政策 - 行动法|更关注具体行动和执行方式，在对前进步骤和顺序更容易达成共识但对改善标志难以达成一致的情况下更适用|过于注重细节，不利于团队向上管理，如果后续需要更改行动方案，团队可能会有所顾虑|

4. 标记时间的重要性

明确成功的定义有助于让团队成员达成共识，但由于成功标准法和诊断 - 政策 - 行动法将挑战分解为小的成就，还需防止团队成员对这些小成就的意义失去信心。如果团队觉得所取得的成功不值得投入的时间，那么成功定义的有效性就会降低。

人们对时间的感知和对风险的感知一样具有可变性。标记时间就是要让人们摆脱日常的挫败感，关注项目的整体情况。一种有效的标记时间的方法是使用子弹日记。每天记录要完成的五件事以及预计所需时间，完成任务时进行标记，并记录重要细节。在工作缓慢时，还可以在页边涂鸦或用贴纸装饰页面。

通过标记时间，能重新调整对事情进展的情感认知。记录工作内容和时间，团队就能轻松回顾项目进展。项目管理工具通常一次只展示一项工作流，而标记时间能更全面地呈现人们生活中的某个特定时刻。

5. 成功案例的事后分析

对于软件工程师来说，事后分析通常是在系统故障后进行的，旨在详细探究故障的时间线、促成因素和最终解决方案。通常会加上 “无责” 前缀，强调其目的是理解问题所在，而非指责犯错的个人或团队。

但事后分析并不局限于失败案例。如果现代化计划是借鉴其他成功项目的经验，不妨对该项目的成功进行事后分析。人们往往认为失败是运气不好，成功是技能使然，认为成功的原因简单直接，但实际上成功和失败一样复杂，应采用相同的方法从成功中学习。

5.1 事后分析与回顾的区别

有人可能认为组织进行的成功回顾就是事后分析，但实际上两者存在差异。冲刺后或发布后的回顾会提出与事后分析类似的问题，但在实践中，回顾更随意，通常不会生成供他人阅读的报告，也很少有组织将回顾内容公开。行业内往往更注重对失败的研究，而对成功的反思不够深入。如果要借鉴其他团队或组织的成功经验，就应该花时间研究其成功的原因。

5.2 运行事后分析的方法

在技术组织中，传统的事后分析有一些特点，如描述故障影响、讨论并记录哪些方面做得好、哪些做得不好以及哪些地方靠运气等。通常会包含详细的事件时间线，不直接提及人员姓名以避免指责，最后会提出改进的可操作步骤。

运行事后分析通常通过审查通信记录和采访团队成员来完成，然后召开最终审查会议向整个团队展示并验证收集到的信息。

在对成功项目进行事后分析时，由于时间跨度可能长达数月，获取详细信息需要投入大量时间和精力，可能会变得繁琐和官僚。传统的事后分析由响应事件的软件工程师编写，这些人更适合从事软件开发而非撰写报告。

因此，对成功项目的事后分析应像回顾一样轻松进行，但要按照传统事后分析的理念进行记录。事后分析的价值不在于细节程度，而在于知识共享。它能帮助未参与事件的人避免犯同样的错误，最好的事后分析还会在组织外部分享，以建立信任。

事后分析能记录实际发生的事情以及具体行动如何影响结果，它不是记录失败，而是提供背景信息。对成功项目的事后分析也应如此，要围绕 “组织如何执行原策略、策略如何变化、何时发生变化以及触发变化的原因” 等问题构建时间线。

即使是最成功的项目也存在可以改进的挑战和靠运气解决的问题，记录这些内容有助于他人评估该方法是否适用于自己的问题，并最终复制成功经验。如果确信其他组织的策略适用于自己的问题，不必等待他们进行事后分析，可以通过与相关人员喝咖啡交流来收集所需信息。可以使用以下关键问题进行采访：
- 哪些方面做得好？
- 哪些方面可以做得更好？
- 哪些地方靠运气？

5.3 两个作战室的故事

在确定策略之前，需要审视促成成功的因素，因为有些组织可能会从成功中吸取错误的教训。例如，有一个项目严重滞后，团队成员不仅没有明确的结束日期，也不清楚项目延迟的原因。该项目需要多个组织部门合作并共享信息。而另一个咨询团队刚完成一个面临类似挑战的成功项目，他们让各部门代表在同一房间工作，形成了一个类似开放式办公空间的作战室。

面临失败的组织在未与咨询团队交流、也未深入了解作战室运作方式的情况下，就照搬了这一策略。他们预订了一个大会议室，让代表们在里面工作了一个月，但最终效果不佳。这说明不能简单地复制成功模式，而要深入理解其背后的原因。

综上所述，要确保项目成功完成，需要综合运用确定成功标准、标记时间、进行事后分析等方法，同时避免盲目复制成功经验，深入理解成功背后的因素。

graph LR
    A[项目启动] --> B[揭示潜在假设]
    B --> C[确定成功标准]
    C --> C1[成功标准法]
    C --> C2[诊断 - 政策 - 行动法]
    C --> D[标记时间]
    D --> E[子弹日记记录]
    E --> F[事后分析]
    F --> F1[传统事后分析]
    F --> F2[成功项目事后分析]
    F --> G[避免盲目复制经验]
    G --> H[项目成功完成]

6. 不同方法的适用场景分析

在实际项目中，选择合适的方法对于项目的成功至关重要。下面通过具体的场景来分析成功标准法和诊断 - 政策 - 行动法的适用情况。

6.1 成功标准法适用场景

当团队对项目的整体目标有清晰的认识，但对于达成目标的具体路径存在多种可能性时，成功标准法能发挥很好的作用。例如，在开发一个新的移动应用时，目标是提高用户活跃度和留存率。但具体是通过增加新功能、优化用户界面还是改进营销活动来实现并不明确。此时可以设定以下成功标准：
- 用户活跃度提升 ：在上线后的第一个月内，日活跃用户数增长 10%。
- 用户留存率提高 ：新用户次日留存率达到 50%，7 日留存率达到 30%。

这种方法给予团队足够的灵活性，让他们可以根据实际情况选择最合适的行动方案。团队可以同时进行多个方面的尝试，根据成功标准来评估哪些行动是有效的，从而及时调整策略。

6.2 诊断 - 政策 - 行动法适用场景

当组织内部对问题的解决顺序存在争议，需要明确具体行动步骤时，诊断 - 政策 - 行动法更为合适。例如，一家传统企业进行数字化转型，面临多个问题，如老旧系统的兼容性问题、业务流程繁琐等。不同部门对哪个问题应该优先解决有不同的看法。此时可以采用该方法：
- 诊断：老旧系统无法与新的业务系统兼容，导致数据传输延迟和错误，影响业务效率。
- 政策：优先解决系统兼容性问题，不影响现有业务的正常运行。
- 行动：
- 在一个月内，完成对老旧系统和新业务系统的技术评估。
- 第二个月，制定系统对接方案。
- 第三个月，进行系统对接测试和优化。

通过明确问题、解决方案的边界和具体行动步骤，能够减少组织内部的争议，使项目顺利推进。

6.3 方法选择的决策树

为了更直观地展示如何选择合适的方法，以下是一个决策树：

graph TD
    A[项目面临的情况] --> B{对成功定义是否有共识?}
    B -->|是| C{是否明确行动步骤?}
    B -->|否| D[诊断 - 政策 - 行动法]
    C -->|是| E[成功标准法]
    C -->|否| D

7. 标记时间的其他方式

除了子弹日记，还有其他一些标记时间的方式可以帮助团队更好地关注项目进展。

7.1 里程碑标记

在项目计划中设定明确的里程碑，每个里程碑代表项目的一个重要阶段。例如，在软件开发项目中，可以设定以下里程碑：
- 需求分析完成
- 设计方案评审通过
- 代码开发完成
- 测试完成并上线

当团队到达一个里程碑时，进行庆祝和总结，回顾从上个里程碑到现在所取得的成果。这样可以让团队成员感受到项目的阶段性进展，增强成就感。

7.2 时间轴可视化

使用时间轴工具将项目的关键事件和时间点进行可视化展示。可以在墙上张贴大型的时间轴海报，或者使用在线工具创建交互式时间轴。时间轴上标注每个事件的预计时间和实际完成时间，通过对比可以清晰地看到项目的进度情况。例如：
|事件|预计时间|实际完成时间|
| ---- | ---- | ---- |
|项目启动|2024 年 1 月 1 日|2024 年 1 月 1 日|
|需求调研|2024 年 1 月 1 - 15 日|2024 年 1 月 18 日|
|设计方案完成|2024 年 1 月 16 - 31 日|2024 年 2 月 5 日|