月度归档:2023年12月

你是团队的明灯还是卡点?聊聊项目管理中的角色认知与常见问题

一个技术团队管理者在带团队过程中常常要「通过别人的手拿到结果」,常常要主动去改变一些事情,去完成一些公司或上级的要求,甚至要自己去做一些事情……

仔细回顾一下,有没有出现你的上级绕过你直接找你的下属来处理问题,而你一无所知,只有出了问题的时候才知道?有没有出现你发起了一个事情,任务已经交给下属/其它同事来跟进处理了,到截止时间,结果和你想象中的不一样?有没有出现你实在忍不住,亲自动手把那块代码写了,一边写还一边吐槽,也就十几分钟的事儿,跟他讲的时间都已经上线了……

如此种种,是不是很是亲切,经常会遇到。这到底是哪里出问题了呢?

如果把这些事项都当作一个项目来看的,这些项目中有三个主要角色:发起人(Sponsor)、负责人(Project Manager)和核心成员(Core Team Members)。上面的这些问题大多数是角色错位,职责分工不明确或者项目成员本身对于自己所在角色的认知不清晰导致的。

今天我们就聊聊这三个角色,以及经常会出现的问题。

发起人(Sponsor)

发起人是项目的发起者,他们通常是公司的高级领导人或决策者,有权利和资源来推动项目的实施。他们的主要职责和特点包括:

  1. 确定项目的战略目标,并向所有相关方清晰地传达这些目标,一般不参与具体任务。
  2. 提供必要的资源和资金以支持项目的实施。
  3. 对项目有最终兜底责任,在必要时提供对项目的支持,解决可能对项目产生影响的问题和挑战。
  4. 监督项目的进度,确保其符合预设的目标和期限,在大方向上正确。

发起人通常是关键利益相关方,他们提供项目必要的资源和支持,并在决策中扮演重要角色。然而,如果发起人的角色和职责没有被正确地理解和执行,可能会出现一些「坑」:

  1. 不清楚角色:发起人需要知道他们的角色和职责,包括为项目提供资源、支持、决策和领导。如果发起人对自己的角色不清楚,可能会导致项目的推进中受到阻碍。

  2. 缺乏参与:一般表现为撒手不管,把目标提了就不管了,作为发起人需要积极参与项目的关键决策,以确保项目的成功。如果发起人缺乏参与,可能会导致项目偏离目标,或无法解决关键问题。

  3. 过度干预:与上面的缺乏参与相反,发起人如果过度干预项目的日常运作,可能会导致项目团队的困扰,影响项目的效率。

  4. 缺乏支持:发起人需要提供项目所需的资源和支持。如果发起人不能或不愿提供足够的支持,可能会导致项目的进展受阻或者失败。

  5. 沟通不畅:发起人需要与 PM 和项目团队保持良好的沟通,以确保项目的顺利进行。如果沟通不畅,可能会导致误解和冲突。

在上面的这些问题中,缺乏参与和过度干预是两个常见且严重的问题,这两个问题背后的原因是什么?

发起人可能因多种原因缺乏参与。这些原因可能包括时间和资源的限制,使他们无法深入参与每个项目;对团队的信任,使他们选择让团队自主执行;缺乏特定的技术或领域知识,使他们在技术性项目中保持距离;以及角色定位不明确,使他们不清楚他们在项目中的参与程度应该是多少。无论原因如何,发起人都需要保持对项目的关注,并定期与团队进行沟通和反馈,以确保项目的顺利进行。

发起人过渡干预的原因也有多种,概括起来为以下五点:

  1. 太想要: 发起人对项目结果的强烈期待可能促使他们深度介入每个环节,并且确保结果符合期望。
  2. 太着急: 发起人想快速拿到结果,这可能导致他们过度干预项目的进度,甚至可能在没有充分理解或考虑所有可能影响的因素的情况下,推动项目快速前进。
  3. 不放心: 如果发起人对团队的能力或执行力有疑虑,他们可能会更频繁地插手过程中的工作。
  4. 控制欲: 有些发起人有强烈的控制欲望,希望对每个项目细节都保持控制,这可能导致他们过度参与。
  5. 不知道: 如果发起人对自身在项目中的角色不明确,他们可能会尝试涉足所有任务,而非专注于他们应该完成的职责。

这样的过度干预可能会导致一系列问题。首先,它可能会打乱团队的工作流程和效率,因为过多的干预可能会导致团队成员混乱或者反复更改方向。其次,它可能会破坏团队的士气,因为团队成员可能会觉得他们的专业能力或决策权被忽视。再次,过度干预会阻碍团队成员的成长,特别是对于 PM,过度干预可能剥夺他们解决问题和独立决策的机会,从而限制他们的职业发展和成长。最后,过度干预可能会阻碍项目的进展,因为发起人可能会过于关注细节而忽视了项目的整体进度。因此,发起人需要找到一个合适的平衡,既要关注项目的进展,也要尊重和信任团队的工作。

负责人(Project Manager)

负责人直接对发起人负责,是项目策划和执行的总负责,是项目团队的领导者。

PM 的主要职责包括以下四个部分:

  1. 全面负责: PM 对项目的策划、执行和成功负有全责。PM 需要领导项目团队,完成全部项目工作,实现项目目标,满足客户需求。

  2. 目标设定与资源分配: PM 需要与项目发起人协商确定项目目标,并平衡项目的资源、时间和风险。PM 需要带领团队制定一个多个达成共识了的项目计划。

  3. 团队建设和沟通: PM 需要组建并领导核心团队,需要保持与团队成员的及时沟通,确保团队成员了解任务的背景和目标,以便高质量地完成任务。

  4. 项目监督和沟通: 在项目执行过程中,PM 需要实时监控项目的进度,提供必要的指导,持续与团队和其他相关方沟通,以确保项目按照计划顺利进行。

对于 PM 来说,要达成上面的目标,必须要有强大的领导力、沟通能力、组织能力和决策能力,以及对项目管理的深入理解和专业知识。

在实际工作过程中,作为 PM,可能会出现以下的一些问题,看看这些问题里面有没有自己的身影:

  1. 视角局限: 一些 PM 可能过于专注于执行任务,而忽视了他们作为领导者的角色。PM 不仅仅是执行者,他们需要负责项目的全面管理,包括规划、分工、监控和调整。解决这个问题的一个方式是提升 PM 的项目管理知识和技能,让他们了解到 PM 的职责远远超过了单纯的任务执行。

  2. 角色误解:  PM 的角色不仅仅是协调者,他们还是项目的领导者和决策者。他们需要对项目的成功负全责,而不仅仅是「拿到一个鞭子到处抽」。PM 需要理解他们的角色,并尊重他们的职责。

  3. 忽视相关方: 项目的成功不仅取决于项目团队的工作,还取决于与项目相关的所有方的合作。PM 需要理解并满足相关方的需求,与他们保持有效的沟通。否则,项目可能会因为没有满足相关方的期望而失败。

  4. 与项目发起人的沟通不足:  PM 需要与项目发起人保持密切的沟通,确保项目的方向和结果符合发起人的期望。如果没有有效的沟通,项目的结果可能会与发起人的期望存在偏差,导致项目失败。

核心成员(Core Team Members)

核心成员向 PM 负责,其职责是对项目目标的实现提供关键支持,通过其专业技能和决策能力,推动项目的成功执行并解决项目过程中的重要问题。其主要职责包括:

  1. 参与规划和决策: 核心成员通常会参与项目的规划和决策过程。可能需要提供专业的建议和意见,帮助 PM 制定计划和做出决策。这个非常重要。
  2. 任务执行: 核心成员负责完成分配给他们的特定任务和工作。这可能包括设计、开发、测试、文档编写等各种任务。
  3. 沟通和报告: 核心成员需要与 PM 和其他相关方进行有效的沟通。需要定期报告工作进度和结果,以便 PM 可以对项目进行有效的管理和控制。
  4. 问题解决: 当项目遇到问题或困难时,核心成员需要积极找出问题的原因,并提出有效的解决方案。
  5. 质量保证: 核心成员需要确保他们的工作满足项目的质量标准。他们可能需要进行自我检查,或参与项目的质量保证活动。

核心成员在项目管理中扮演着非常关键的角色,具体职责可能会根据项目的性质和规模有所不同。在实际的工作过程中,有一些常见的和核心成员相关的问题,如下:

  1. 团队角色和职责不明确: 如果核心成员的角色和职责没有明确,可能会导致混乱和效率低下。核心成员应清楚了解他们在项目中的作用和期望。
  2. 团队成员技能不匹配: 如果核心成员缺乏完成任务所需的技能或经验,可能会威胁到项目的成功。确保核心成员具有执行他们角色所需的技能和知识至关重要。
  3. 团队沟通不足: 如果核心成员之间或者领导者与核心成员之间的沟通不充分,可能会导致误解和冲突。建立开放和有效的沟通机制至关重要。
  4. 核心成员过多: 如果核心成员过多,可能会导致沟通和协调变得复杂,影响项目的推动。合理管理核心成员规模和结构,或者建立有效的大型团队管理策略,可以帮助解决这个问题。

其它坑

对于这三个角色,我们常常会踩一些坑而不自知,或者明知道是坑也忍不住踩了进去。

首先,三个角色「发起人、负责人和核心成员」都有可能面临「不知道自己不知道」的问题。这里最常见的表现是对当前所处的角色不清晰、对角色的职责不清晰,不知道应该是这样。为此,我们需要不断地学习和探索,以增强自己对项目管理的理解和自我认知。

其次,「知行不一」也是一个常见的问题。在认知上没有问题或者问题不大,但是实际执行时却做不到,无法达到预期,可能是自我管理的问题,比如各种原因控制不住自己,一直想插手等等。这就需要我们提高自我管理能力,包括情绪管理、时间管理和责任管理。需要学会信任团队成员,允许他们犯错误并从错误中学习,而不是总是亲自介入。同时,也需要学会管理自己的时间,把宝贵的时间用在最重要的任务上,而不是溜进琐事的无尽轮回中。

第三个问题是「短视」,只想着解决了眼前的问题,搞乱了整个事情,搞乱了机制和整盘棋。这可能是因为过于关注眼前的问题,而忽视了整个项目的大局,或者为了短期内的效益而牺牲了长期的利益。这需要发起人、负责人和核心成员时刻记住,他们的决策不仅会影响到眼前的任务,也会影响到整个项目的运行。需要考虑每个决策的背后,不仅仅是短期的结果还有长期的影响。为此,需要学习并运用项目管理的方法和工具,例如风险评估、影响分析等,以帮助更准确地预测每个决策的可能后果。

对于如何应对这些问题,我们都需要有耐心,用长沙话来说就是「耐得烦」,尤其是在面临困难和挫折时。多反思自己的决策,思考可能的后果,并努力做出最好的选择。此外,还需要在工作中积极合作,通过观察和学习来提升自己的技能和认知。如果能够做到这些,那么项目就成功了大半。

最后,「独木不成林」,一个人能力终归有限,这是对个体力量的客观认识。即使一个人的技能极为出众,他的时间和精力也是有限的。我们需要与他人合作,共享知识,共享经验,共同面对挑战。通过团队的力量,我们可以实现那些单个个体无法达到的目标。

最后思考:如果把工作中这些事情都当作一个个项目来管理,思考一下,在项目管理过程中,你的角色是什么?你这个角色的职责是什么?你把这个角色的本份做到位了吗?

关于复杂系统的思考:从语雀服务中断想到的

在 10 月 23 日,语雀服务出现了一次重大故障,中断时间超过 7 小时。具体来说,这次故障的起因是在执行系统升级操作期间,新的运维升级工具出现了 bug,导致华东地区生产环境的存储服务器被误下线。由于存储系统使用的机器类别过于陈旧,无法直接将其上线,这导致了恢复过程时间延长。尽管语雀的工程师们立刻进行了恢复工作,但由于数据量大,恢复方案有限,恢复过程耗时 4 小时,数据检验耗时耗时 2 小时。这次故障给用户带来了严重的影响,也让我们重新审视关于本次故障带来的思考。

我将整个复盘报告输入给到 chatGPT,其给我的回复如下:

从语雀的这次事故中,我们可以学到以下几个关键的教训:

  1. 重视运维工具的测试和质量保证:在这次事故中,新的运维升级工具的 bug 是导致故障的主要原因。这说明,即使是运维工具,也需要进行足够的测试和质量保证。在实际使用之前,应该在相似的环境中进行充分的测试,确保其稳定性和安全性。
  2. 灾备和恢复系统的重要性:即使有了数据备份,恢复仍然可能需要花费大量时间,这会导致服务中断时间过长。因此,除了定期备份数据外,还需要建立有效的灾备和恢复系统,以便在灾难发生时,能够快速恢复服务。
  3. 灾难恢复演练的必要性:定期的灾难恢复演练可以帮助我们在真实的灾难发生时,更快地恢复服务。通过演练,我们可以发现并解决恢复过程中可能存在的问题,提高恢复的效率。
  4. 高可用架构的重要性:高可用架构可以保证在部分系统组件发生故障时,整个系统仍能继续运行。在这次事故中,由于存储系统的故障,导致了整个服务的中断。如果有高可用架构,即使某个组件发生故障,也可以通过其他的组件提供服务,从而减少服务中断的可能性。
  5. 灾难通信的重要性:在灾难发生后,应该及时向用户通报情况,说明故障的原因,修复的进度,以及预计的恢复时间。这样可以增加用户的信任度,减少用户的不安。在这次事故中,语雀做了很好的灾难通信,及时向用户报告了故障的详情,以及修复的进度。
  6. 持续改进和学习的重要性:每次故障都是一次学习的机会。通过分析故障的原因,我们可以找出问题,改进系统,避免类似的故障再次发生。在这次事故中,语雀提出了一系列的改进措施,这表明他们有持续改进和学习的意识。

但是从复杂系统的角度来看这个事件:复杂系统的性质使得它们在面临故障时,能够以我们意料之外的方式表现出来。尽管我们可能已经在设计和实施阶段做了很多工作来确保系统的稳定性,但是在实际运行中,仍然会出现我们没有预见到的问题。

高尔在讨论复杂系统时提到:「具备故障防备能力的系统出故障的原因恰恰就是故障防备能力的失灵」。这是因为在设计防备系统时,我们往往会基于我们对系统的理解来设计,但是实际上,系统的行为可能会超出我们的理解范围。当系统的行为超出我们的预期时,我们的防备措施就可能会失效。

这与这次语雀服务故障的情况非常相似。尽管语雀设计了一套备份恢复机制,但是在实际的故障中,由于对系统的理解不足,这套机制并没有发挥出应有的效果,反而延长了恢复时间。

在许多情况下,一些复杂系统的故障并不是单一的、孤立的事件,而是由一系列的因素相互作用、相互影响的结果。这通常包括了系统设计、运维策略、人为错误等多个方面。

具备故障防备能力的系统,其设计和运营目标是提供连续、稳定的服务,即使在面临内部错误或外部攻击等影响时也能持续运行。这种系统通常包含冗余的组件、自动故障切换机制、灾难恢复策略等措施,以保证系统的正常运行。

然而,这些故障防备能力本身可能成为系统故障的源头,原因可能有以下几点:

  1. 复杂性故障防备能力会增加系统的复杂性,复杂性本身就可能带来故障。例如,冗余的组件需要保持同步,如果同步机制出现问题,可能导致数据不一致,进而产生故障。

  2. 人为错误故障防备能力的维护和操作需要人工参与,人为操作错误可能导致防备能力失灵。如语雀故障案例中,运维工具的 bug 就是人为因素导致的。

  3. 预期和实际的差距:故障防备能力的设计和实施都是基于对可能故障的预期,但实际发生的故障可能超出了预期,导致防备能力无法应对。

面对一个每天都在演化的复杂系统,我们应该做些什么呢?

面对复杂,我们第一个能想到的原则应该就是 KISS 原则了。

「KISS」 原则是 「Keep It Simple, Stupid」 的缩写,这是一种广泛应用于工程、设计和决策过程中的设计原则。其最主要的理念就是保持事物的简单性。

KISS 原则主张:

  • 避免不必要的复杂性
  • 优先选择简单、清晰和直观的解决方案
  • 不要添加不必要的特性或功能
  • 简单的设计更易于维护、理解和修改

这个原则并不是说所有的事物都必须以最简单的方式来完成,而是鼓励我们在设计和决策过程中,优先考虑最简单和最直接的方法,除非有充分的理由去选择更复杂的方案。

简单性是一个非常重要的设计目标,因为它可以降低错误的可能性,提高系统的可靠性,减少维护的难度,提高效率,以及其他许多好处。

我们如果应用了以下的一些建议,应该可以往 KISS 原则靠近一些:

  1. 明确需求:首先明确我们试图解决的问题是什么。这有助于避免在设计和实现过程中添加不必要的功能或复杂性。

  2. 简化设计:在设计过程中,始终问自己是否可以把事情做得更简单。避免过度设计,只实现真正需要的功能。

  3. 模块化:把大问题分解成小问题,每个小问题都可以用简单的方式解决。这样,每个模块都保持简单,而整个系统则由这些简单模块组成。

  4. 避免不必要的优化:过早的优化可能会增加复杂性。除非确定优化会带来显著的好处,否则最好先实现功能,然后再考虑优化。

  5. 使用已有的解决方案:如果有已经存在的工具或库可以满足我们的需求,那就使用它,而不是从头开始创建。这样可以降低复杂性,同时节省时间。

  6. 代码和设计的清晰性:代码应该易于理解,设计应该直观。这不仅提高了可维护性,也让其他团队成员更容易理解你的工作。

  7. 定期回顾和重构:随着时间的推移和需求的变化,我们可能需要调整或简化现有的设计。定期回顾我们的代码和设计可以帮助我们找出可以简化的地方。

作为一个技术管理者应该作些什么呢?我认为最应该做的是拒绝那些让系统变得复杂的不合理需求,守好技术实现的大门。

面对复杂系统,我们需要对系统有深入的理解,尽可能地简化系统,避免不必要的复杂性。通过模块化设计,将复杂系统分解为相对独立的部分,每个部分都可以单独理解和测试。并且设计出健壮的错误处理和恢复机制,同时也需要进行持续的监控和回顾。只有这样,才能提升系统的稳定性,减少服务中断的可能性。

最容易被忽视却意义重大的立项

我们经常会发现工作中会出现很多重点项目,很多事情忽然就来了,问就是老板需求,却没有一个过程来告诉大家前因后果和价值。这往往会导致大家感到迷茫,因为没有获得足够的信息和时间来理解和准备这些项目。这个过程从项目管理的角度来说是缺少立项,而立项往往是最容易被忽视的。

当没有明确的立项过程时,目标模糊、资源浪费、沟通困难、出现项目风险等问题都会时有发生,从而影响整个项目的实施效果和公司的业务发展。

1 什么是立项

立项是一个组织或公司决定开始一个新项目时的决策过程,这个过程涵盖了对项目需求的明确、项目目标的设定、可行性的评估、资源的分配和风险的识别及管理等关键步骤。通过立项过程,组织能确保每个项目有明确的目标、适当的资源分配、风险控制措施以及一个清晰的执行计划,从而提高项目的成功率和效率。

立项的本质是一个综合的决策过程,其中项目的各干系方对目标、方案、成本、风险和里程碑等重要预期进行对齐,以便做出是否启动项目并如何分配资源的决定。

2 立项的作用

立项就像是给项目开个「导航」,帮助我们明确要去的目的地,规划好路线,分配好需要的人和物,预防可能的风险,确认能否按计划到达,并让所有人都了解这个「旅行计划」,以提高我们的旅行效率和成功率。具体一些,包含以下六个作用:

  1. 明确目标:立项过程有助于明确项目的目标和期望结果,使所有参与者对项目的方向和目标有共同的理解。如我们在开发一个新的移动应用的立项过程中,项目组会明确这个应用需要解决的用户问题,预期的用户量,以及市场的目标定位等。

  2. 资源分配:立项过程可以帮助组织确定项目的所需资源,包括人力、物力、时间和资金,并有效地进行分配。如我们在进行一次大型的在线活动的立项过程中,会确定需要多少开发人员来构建和维护活动页面,需要的市场推广预算是多少,以及活动的时间表等。

  3. 风险管理:立项过程中的风险评估和管理,可以帮助识别和处理可能影响项目实施的风险,并提前制定应对策略。如在立项过程中,可能会识别到政策、数据隐私等风险,并提前规划相应的风险应对措施。

  4. 确保项目的可行性:通过立项过程中的可行性研究,可以确保项目在技术、收益、时间等方面的可行性,避免投入大量资源后发现项目无法实现。如最近比较火的 AIGC,在立项时会进行技术可行性分析,以确保所需的算法能力和数据在现有条件下可行。

  5. 提升效率和效果:有了明确的立项过程,可以提高项目管理的效率,减少不必要的错误和返工,提高项目的成功率。

  6. 增强沟通和协作:立项过程有一个关键动作是对齐,当目标对齐后,每个人都清楚自己的角色和任务,也明白项目的整体方向,这有助于增强项目各方的沟通和协作。

3 立项流程

立项流程可以分为三个阶段,准备阶段,决策阶段、对齐阶段。

3.1 准备阶段

准备阶段是立项中花费时间最长的阶段,是立项的主体工作。

在这个阶段,项目团队需要深入理解项目的需求,研究市场环境,评估项目的可行性,以及预测可能的风险。所有这些工作都需要大量的时间和精力。

这些工作最后落地的交付物是项目提案,可能是一份文档,也可能是一堆文档,项目提案中包括项目的目标、预期结果、工作计划、预算、资源需求等。

项目提案将为项目的后续执行提供清晰的指导,也将为项目的评估决策阶段提供关键的信息。准备阶段是整个立项过程中最为关键的阶段,也是决定项目能否成功的重要因素。

项目提案主要是用来回答下面的问题:

  • 为什么要做?可不可以不做?可不可以少做?可不可以晚点做?
  • 要做什么?
  • 有没有能力/资源做?
  • 什么样叫做好了?成功的标准是什么?
  • 怎么做?有哪几步?里程碑是怎样的?
  • 有什么风险?

一个提案可能是一个正式的文件、一份演示文稿 PPT、甚至是一封简单的电子邮件。但是提案结构一般都会包括以下几个主要部分:

  1. 概述:包括项目的名称、目标、主要利益相关者以及总体的项目描述。

  2. 背景:解释为什么提出这个项目,包括市场需求、商业机遇或问题解决等。主要明确现状、剖析问题并给出建议解决方向。

  3. 项目目标和范围:详细描述项目要达到的具体目标和定义项目的范围,包括项目要做的事情以及不包括的事情。落地过程一般是提炼需求、总结项目方向、项目可实现价值等。

  4. 调研及可行性分析:针对上面的问题,需求,结合组织内外的因素,评估项目的技术可行性、经济可行性、法律可行性和运营可行性等。

  5. 成功的标准:定义项目的成功标准。这可能包括在指定的时间和预算内完成项目,以及用户对新功能的满意度等。

  6. 项目计划:包括项目的主要阶段、关键里程碑、预期成果和详细的时间表。细节呈现可以有一个时间轴之类的图。

  7. 项目团队和资源:描述项目团队的结构和成员,以及项目所需的其他资源,如资金、设备和技术。

  8. 风险评估:识别和评估可能影响项目成功的风险,以及应对这些风险的策略。风险可能来自许多不同的来源,包括政策要求、法律法规、技术、预算、进度、人力等。

每个项目提案的内容可能会有所不同,具体取决于项目的性质和复杂性,以及组织的要求和偏好等。

3.2 决策阶段

在项目决策阶段,项目提案会被提交给负责决策的人或团队进行审查。根据组织结构或者提案的重要程度,这可能是公司的高层领导团队,部门领导团队或者是专门的审查团队。以下是在决策阶段可能涉及的内容:

  1. 项目提案审查:决策者会仔细阅读项目提案,理解项目的目标、计划、预期的收益和风险等。他们可能会寻求专家的意见,或者进行附加的研究以验证提案中的信息。

  2. 问题和澄清:决策者可能会对提案中的某些部分有疑问,或者需要更多的信息。这可能会通过与项目团队的会议、电子邮件或其他形式的通信来解决。

  3. 项目比较和优先级设置:如果有多个项目提案,决策者可能需要比较他们的优点和缺点,以决定哪个项目应该优先进行。这可能会涉及到对项目的潜在收益、风险、对公司策略的贡献等方面的评估。

  4. 决策:最后,决策者会根据提案和他们的评估做出决定。他们可能会批准项目,拒绝项目,或者请求更多的信息或修改。

  5. 反馈和沟通:无论决定如何,都应该把它及时和清晰地传达给项目团队和其他相关的利益相关者。如果项目被批准,那么就需要开始实施项目计划。如果项目被拒绝,应该提供反馈,以便项目团队可以了解原因并在将来改进他们的提案。

根据项目的重要程度,适用范围,决策通常涉及以下几个层次:

  1. 战略级决策:这是最高级别的决策,也可以称之为公司级决策,通常由公司的最高管理层进行。他们会评估项目提案是否符合公司的整体战略,是否有助于公司的长期发展,以及是否值得投资。可能会考虑一系列的因素,如市场趋势、竞争环境、公司的资源和能力等。

  2. 部门级决策:这些决策通常由部门的领导们进行。他们会评估项目提案是否符合部门的目标和计划,是否有助于部门的发展,以及是否符合部门的资源和能力。他们可能会考虑一系列的因素,如部门的策略、人力资源、预算等。

  3. 项目级决策:这些决策通常由项目经理或项目团队进行,属于常规决策。我们会评估项目提案的具体细节,如项目的目标、任务、计划、预算、风险等。也可能会需要修改提案的一些细节,以确保项目的可行性和成功率。

这些决策级别并不是严格的分割,而是相互影响和交织。如一个项目提案可能需要在战略级和部门级之间进行多次的审查和修改,以确保它既符合公司的战略,又符合部门的需求。同时,项目级的决策也会影响到项目提案的内容和形式,从而影响到上级的决策。

3.3 对齐阶段

对齐阶段是在项目提案被初步接受后,各相关部门或团队就项目的具体执行细节进行协调和确定的阶段,是一个信息同步对齐,节奏同步对齐阶段。

在项目立项过程中的对齐阶段,形式、内容、范围和后续机制的具体设定通常会因项目的特性和组织的需求而变化,以下是一些常见的实践:

形式

  • 会议:这可能是最常见的对齐形式,包括面对面的会议和在线会议。会议可以让所有相关的人员在同一时间讨论项目的各个方面,及时解决问题和疑问。

  • 邮件和文档:对于一些需要详细记录或者不需要立即回复的问题,邮件和文档可能是更好的选择。它们可以让人们有更多的时间来思考和回复,也可以方便地保存和查阅。

  • 即时消息(IM)群聊:使用企业微信,钉钉等工具创建的项目群组。这样的群组可以让团队成员进行实时的沟通,快速解决问题,同时也可以记录下来所有的对话,方便后期查阅。

  • 公司通知/公告:这是非常正式的方式,如果项目的内容需要通知到整个公司,或者特定的部门或角色,可以通过公司内部的通知系统来发布相关信息。这可以是公司的内部网站、邮件列表、公告板等。

  • 项目管理软件:如 Jira,Tapd 等可以用于管理项目的工具,可以让团队成员查看项目的进度,分配任务,跟踪问题等。

范围

  • 内部范围:涵盖公司内部所有相关的部门和团队,包括项目团队、销售团队、营销团队、财务部门等。
  • 外部范围:如果项目涉及到外部的合作伙伴或供应商,他们也可能需要参与到这个过程中。

内容

  • 项目目标和战略对齐:确认项目的目标和战略与公司的整体战略是否一致,是否有助于实现公司的长期目标。
  • 资源分配:讨论和决定项目需要的各种资源,包括人力、资金、设备等,以及这些资源如何分配和使用。
  • 风险评估:识别和评估项目可能面临的各种风险,以及如何预防和应对这些风险。

后续机制

  • 定期的跟进会议:为了确保项目的执行按照计划进行,可以设置定期的跟进会议,如每周或每月一次,让所有人都能及时了解项目的进展和可能的问题。
  • 评估和反馈机制:在项目执行过程中,需要一个系统的评估和反馈机制,以便及时发现和解决问题,调整计划和策略。这可以通过定期的项目审查、员工反馈、客户反馈等方式实现。

在对齐阶段,关键的一点是保持良好的沟通和协调,确保所有相关的人都明白项目的目标和计划,以及他们在其中的角色和责任。

4 立项常见问题

从上面立项流程的三个阶段来看,每个阶段都有可能会出现一些问题:

4.1 准备阶段常见问题

在这个阶段,应集中精力明确项目的目标、需求、预期结果和实施方式。其常见问题如下:

  • 需求定义不明确:在项目提案阶段,对项目的需求和目标应该有明确的定义。如果在这个阶段需求和目标定义模糊,可能会导致提案内容与实际需求不匹配,或在后续阶段引发混乱和效率低下。清晰、准确的需求定义是项目成功的关键。

  • 提案不完善:在项目提案阶段,提案应该充分考虑项目的所有关键方面,包括预期的时间表、预算、人力资源需求,风险等。如果提案中缺乏这些关键信息,可能会在项目评估决策阶段造成项目被拒绝。一个全面、详尽的提案可以帮助评估者更准确地理解项目的需求和潜在价值。

  • 项目产投不合理:指的是项目预期的产出(如产品、服务或其他结果)与投入(如时间、资金、人力等资源)之间的比例不合理。如果投入过大而产出有限,那么项目可能不会为组织带来足够的收益,这可能会导致项目在评估决策阶段被拒绝。

  • 项目资源投入不聚焦:指的是项目的资源被分散投入到许多不同的任务或活动中,而不是集中在关键的任务或活动上。这可能会导致项目的效率低下,或者关键任务因资源不足而延期。

  • 提案权错配:提案是整个项目立项的主体内容,它的权力错配严重时会导致整个项目的失败。提案权错配可以分为两种:跨部门的错配和层级的错配。跨部门错配一般发生在提案的制定和执行由不同的部门负责,如 A 部门负责制定提案,但 B 部门负责实施提案。这种错位可能导致沟通困难和理解差异,因为制定提案的部门可能对执行提案的部门的能力和限制了解不足,反之亦然。为了避免这种错位,可能需要更紧密的跨部门合作,或者建立一个跨部门的团队来共同提出和实施提案,或者执行类似于「谁主张主举证」的原则,谁提案谁执行,谁干活谁提案。层级错配一般发生在高层领导制定提案,而实际工作团队负责实施时。这可能导致提案与实际工作的脱节,因为高层领导可能对实际工作的具体细节和挑战了解不足。为了避免这种错位,可能需要更多的底层参与及权力下放。

4.2 评估决策阶段常见问题

在这个阶段,主要任务是评估项目提案是否可行、价值、收益、风险以及对资源的需求。可能出现的问题包括:

  • 评估标准不明确:在项目评估决策阶段,评估标准应该尽可能地清晰和公正。如果评估标准不明确或者不公正,可能会导致优秀的项目提案被忽视,或者不合适的项目被接受。此外,如果项目的评估标准不公正,可能会引发团队冲突,影响项目的整体执行和效果。

  • 决策过程不透明:在项目评估决策阶段,决策过程应该尽可能地透明。如果决策过程不透明,可能会导致团队成员或其他利益相关者对决策的公正性和合理性产生疑虑。这种疑虑可能会导致与项目相关的人员的信心下降,影响他们的工作效率和项目的最终结果。

  • 项目可行性评估不准确:在项目评估决策阶段,项目的可行性是一个重要的考虑因素。如果对项目的可行性评估不准确,可能会导致项目在实施阶段出现大量的问题,或者项目无法实现预期的收益。

  • 收益预期过高或者过低:在项目评估决策阶段,对项目的收益预期应该尽可能地准确。如果预期过高,可能会导致项目在完成后无法实现预期的收益;如果预期过低,可能会导致项目在评估决策阶段就被错误地拒绝。

  • 风险评估不足:在项目评估决策阶段,应该对项目可能出现的风险进行充分的评估。如果对风险的评估不足,可能会导致在项目实施阶段出现意外的问题,从而影响项目的成功。

4.3 对齐阶段常见问题

在这个阶段,主要任务是确保所有的利益相关者都对项目的目标、进度、责任和期望有相同的理解。其常见问题包括:

  • 沟通不足或者误解:在项目对齐阶段,所有的利益相关者都应该对项目的目标、进度、责任和期望有清晰的理解。如果在这个阶段没有进行充分的沟通,或者存在误解,可能会导致在项目执行阶段出现混乱和冲突。

  • 角色和责任不明确:在项目对齐阶段,应该明确每个团队成员和利益相关者的角色和责任。如果角色和责任不明确,可能会导致一些工作被遗漏,或者一些任务没有被正确地完成。

  • 期望管理不当:在项目对齐阶段,应该对项目的预期结果进行明确的设定和沟通。如果项目的预期结果没有被正确地理解或接受,可能会导致项目在执行阶段出现问题,因为实际的结果可能无法满足一些利益相关者的期望。

5 小结

前面我们全面地探讨了项目立项的重要性、含义、作用、流程,以及可能出现的问题。立项不单是一个项目开始的决策过程,而是一个综合性的决策过程,涉及目标设定、资源分配、风险管理等多个环节。立项的本质是项目各方对目标、方案、成本、风险和里程碑等重要预期进行对齐,以便决定是否启动项目并如何分配资源。

立项可以帮助明确目标,合理分配资源,提前识别和管理风险,确认项目的可行性,提升效率和效果,增强沟通和协作。立项过程包括三个阶段:准备阶段、决策阶段、对齐阶段。每个阶段都有其关键工作,并可能出现一些常见问题,如需求定义不明确、评估标准不明确、沟通不足或误解等。

总的来说,立项是确保项目成功的重要环节,需要得到足够的重视和正确的处理。