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

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

如果把这些事项都当作一个项目来看的，这些项目中有三个主要角色：发起人（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. 核心成员过多： 如果核心成员过多，可能会导致沟通和协调变得复杂，影响项目的推动。合理管理核心成员规模和结构，或者建立有效的大型团队管理策略，可以帮助解决这个问题。

其它坑

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

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

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

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

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

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

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

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

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 小结

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

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

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

这是一个用作宣传的系统，它由客户端，Flash端，服务端三部分组成， 客户端放在客户机器上，实现一些本地的播放及相关操作； Flash端被嵌入到客户端中，调用服务端的数据。 服务端做播放内容的管理及提供数据接口服务。

现在已经有一个1.2的版本在生产环境运行。现在的需求是增加一些功能并且将旧的耦合较多的部分进行重构，以插件的方式提供播放内容。

这三块分别是三个研发部门抽调的开发人员实现，并且开发人员没有换到一个区域办公，人在不同的楼层。 考虑到这是一个不到9人月的小项目，所以在项目估算的时候并没有做基于代码行的估算，而是以一种比较粗犷的工作量估算方法。 在估算过程中，有针对这三块功能进行分别估算，但是在Flash端的估算过程中没有体现出这是一个以细化需求为目的的估算过程。 开发在正常的进行，项目一切正常，然而由于其它项目需要，Flash端的开发人员需要进入其它项目， 于是将此项目的开发工作交接给另一个开发人员，此时Flash端的开发进度就开始脱离了项目经理的掌控。 等到服务端和客户端的开发完成，测试完成，风险时间用完，Flash端的开发工作才基本完成。但是Flash端是客户端和服务端的中转地， 起着至关重要的作用。待开发工作完成后，进行需求确认，发现现有的功能较旧版有较多出入，一部分必须有的功能并没有实现， 实现的功能中还有较多的BUG。于是项目延期……

原因分析

基于项目管理的角度分析整个项目过程，存在以下问题：

1. 估算过程问题
2. 人员变更问题
3. 项目经理进度把控问题
4. 风险识别不充分

估算过程应该是一个细化需求，指导开发人员更了解所开发功能的过程，从而在对需求的理解上对整个开发周期进行估算。 此项目估算过程过于草率，没有体现估算的价值。 人员变更没有在项目管理过程中体现，在人员变更时对于工作的交换及需求学习等活动都不充分，甚至没有。 虽然有一些客观原因，但是项目经理确实没有实时的现场的跟进Flash端开发的进度，过于充分相信开发人员对于进度的描述。 风险识别过程不充分，特别是人员变更及采用工作量估算时，没有对风险有一个充分的识别。

重构对项目的影响和如果可以重来

基于代码开发的角度，主要是Flash端重构的问题。 重新认识下Martin Fowler在《重构》这本书中对于重构的定义：在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。

我们这次重构是有必要的，在需求列表中有将旧的耦合较多的部分进行重构，以插件的方式提供播放内容的需求项。 但是从现状来看，这次的重构已经不再是纯粹的重构了，它变成了一个重写的过程。旧的所有的功能都重写了，并且一些资源的使用都是采用的新的。 没有认清重构的本质，没有定义好重构的范围，这是此次问题的关键所在。 不改变代码外在行为的前提在本次重构中没有体现，并且对于外在行为的定义和识别活动也没有进行，这是一个问题。

如果可以重来，重构前开发人员对于原有代码外在行为的进行需求识别和功能细节识别， 这个可以简单点，开发人员给出一个check list，产品、测试都可以使用这个list, 同样这也是自己重构过程中的指向灯。在给出列表后，产品和测试人员需要对这个列表进行审核， 确认是否和已经的外在行为一致，这些活动在开发前和开发完成后都要进行。

另一些思考

1. 基于不同的技术的项目，可能项目经理对这些领域不了解，但是可以看到实际的产出，在一些功能实现完成后，尽量到开发人员的位置上确认其描述。
2. 对于跨部门的项目，虽然推动其它部门的人做事有一定的难度，但是事是必须要做的，需要更多的关注和协调。
3. 如果可以，项目组成员集中在一个区域是最好的，不过有时候也只是想想而已。

Scrum敏捷项目管理读书笔记

由于最近的工作从开发转到了项目管理，所以需要了解一些项目管理的知识。

然后去公司的图书馆借了这本《Scrum敏捷项目管理》，并花了一周的工作之余的时间把它看完了。

总体觉得书有较多的案例，对一些知识点的解释比较到位，也容易理解。只是在工作中用不太到，因为整个公司的项目管理环境是CMMI，最多在本部门小范围的实施一些带点敏捷思想的东东。

【读书摘抄】

不同的项目可能需要不同的管理方法

应以项目成果为导向而非过程为导向

衡量项目成功与否，要看项目成果的商业价值与投资回报，而非仅仅看其有没有超支、延时或按原定计划行事

20/80法则，最大可能满足利益关系人的核心需要

尽可能让核心关系 人参与 并及早展示项目的进展和成果，及时作出必要的调整，以确保更高商业价值的交易。

Scrum只定义了高层次的信息系统开发项目的管理流程，并不涉及具体开发方法或者人员的有效沟通技巧。

其管理文化植根于“帮助他人完成目标”这一概念

Scrum是经验性过程控制

Scrum是围绕着一个迭代、增量的过程骨架展开

Scrum方法中有3个角色：产品负责人（Product Owner）、团队和ScrumMaster

产品负责人代表项目中每位利益相关者的权益，并为项目产出的软件系统负责

团队的责任是开发软件功能，实现自我管理

ScrumMaster对Scrum过程负责，确保所有项目相关人员遵守Scrum规则

项目成员==草场上的羊

ScrumMaster==牧羊犬

产品负责人的职责是提升项目的投资回报

Scrum使项目事项具有可视性

自管理 、涌现机制、可视性和检查/适应循环的根本原则

三个问题：

1、自上次Scrum简会后的一天里我做了什么？

2、从现在到下次Scrum简会的一天时间里我准备做什么？

3、在工作中遇到了哪些障碍？

Scrum是可能的艺术

ScrumMaster的职责：

1、排除产品开发和产品负责人之间的障碍，确保产品负责人直接推动开发工作

2、教授产品负责人如何实现投资回报最大化，以及如何利用Scrum达成目标

3、激发创造力和放权，从而改善开发团队的环境

4、千方百计提高开发团队的生产力

5、改善工程实践和工具，确保每个功能增量都具备潜在可交付性。

6、向各方面确保团队工作进展实时更新并高度可视

“限定时间”可向团队灌输“可能”的艺术，避免过分追求完美；

“增量交货”的举措可改进工程实践；

“放权”和“自组织”能够激发创造力，提升员工满意度

Scrum计划涉及3个问题的解答：

1、项目投资人希望项目结束时能取得哪些成果？

2、每个sprint应做出哪些进展？

3、如何使项目投资人相信该项目是有价值的投资，以及项目申报者有能力将会艰苦收益？

给客户做选择题，给领导做选择题

成功的开发需要不断的检查和调整

只有在全部事项对频繁检查和调整可视的情况下，Scrum才能有效运作。

Scrum的生产力源于：首先选择正确事项，然后高效完成选定事项。在Scrum中，团队自行寻找生产力最大化的方法，计划和执行任务完全由团队完成。

两个或以上Scrum团队同时开发的项目称作“扩展项目”，协调这些团队工作的机制称作“扩展机制”

Sprint计划会议限时8小时，分为两部分，各4小时。第一部分挑选产品Backlog;第二部分准备Sprint Backlog。

Sprint限期为30个连续日历日。

Sprint评审会议限时4小时

评审会议开始后，全体团队成员回答两个问题：

1、上一个Sprint有哪些成功方面？

2、下一个Sprint应做哪些改进？