掌控项目

掌控项目

• 前言

  • 制订项目仪表盘，定性和定量的度量方式都需要
  • 掌控项目意味着要寻找风险和管理风险，扰乱节奏和可能扰乱节奏的事情都是风险

• 掌控项目的节奏

  • 观察节奏是项目经理的职责，要观察那些实践能否帮助项目建立并维持合理节奏，保证项目成功
  • 项目周期越接近顺序式生命周期，项目的节奏就越可能随阶段发生变化
  • 敏捷生命周期，迭代规划阶段可能有混乱的状态但迭代开始后可以找到节奏
  • 打断项目正常节奏的常见问题，要找到解决的办法
    • 不知道先完成哪些需求
    • 允许项目的需求收集阶段持续时间过长
    • 允许GUI随时发生变化，而GUI相关人员再项目中不知该如何是好
    • 没有框架的整体描述，不知道各个部分如何构成
    • 无法及时向项目中加入必要的人员，使他们很难取得成功

• 举行中途回顾会议

  • 要了解项目发生了什么，同时为未来的项目做规划，回顾活动是出色的一种方式
  • 项目结束时举行回顾，也可以在项目任何时候举办回顾
  • 敏捷生命周期是在每个迭代结束时举行回顾，其他的生命周期一般是在达成了主要里程碑后，如果间隔很长时间，中途回顾可帮助了解工作进展

• 为需求排序

  • 从1 开始，为每个需求分配唯一的数字
  • 排序的方法
    • 两相对比，如果还不好对比，要说明只能有一个第一位优先级的需求
    • 按评判标准排定优先级：两相对比没有进展，需要把需求的价值和优先级明确表达出来。评估的条件并对每个条件分配独一无二相对权重。对应每个条件为每个需求赋一个0-10的值，最后分数可以看出优先级高低。 评估条件如下：
      • 功能对架构的影响
      • 估算的实现时间
      • 该功能对特别重要的客户的重要性
      • 特定人员实现或测试该功能的可行性
    • 制订并维护不断变化的需求日志：产品代办事项列表

• 用时间盒限定需求相关的工作

  • 需求说及分析和定义的时间占用太多导致后续工作无法正常开展
  • 可以设定一个需求获取工作的时间，即使不使用迭代开发
    • 用时间盒限制初始需求的相关活动，并持续收集更多的需求； 用不超过总持续时间的10%时间，收集到最重要的需求
    • 用时间盒限制所有的需求定义活动， 项目团队成员与需求相关人员一同收集整理和细化需求。
  • 将迭代限制在4周或是更少的时间内
    • 迭代的时间越长，项目的节奏就越难保持
    • 短迭代会有更频繁的反馈，直到能够保持节奏为止

• 使用波浪式规划和日程安排

  • 每次规划少量的工作，用迭代的方式反复规划，可以提升项目日程安排的准确性
  • 顺序式生命周期,重新规划项目的时间安排
    • 先定义出顺序式生命周期的阶段或主要的里程碑，以及设定里程碑的验收条件
    • 只规划未来3-4州的详细工作
    • 项目经理要监控项目进度，牢记里程碑的验收条件
    • 项目完成前面一个阶段，就可以为后面的阶段准备更多细节了，并且更新项目规划和日程安排，重新规划里程碑
  • 迭代，增量和敏捷生命周期重新规划：简单多了本身都包含迭代或增量式活动
  • 迭代式日程安排不可避免吗？ 适应情况：知道做什么但不知如何做；面临时间压力且希望利用项目现有进展。 研究型或是项目的研究阶段不在适应范围之中； 如果使用迭代，就得制订出每个时间盒结束时需要提出的问题，然后重新规划下一个时间盒。产品是问题的答案或更多问题而非产品。

• 创建跨职能团队

  • 跨职能团队工作效率更高，有人复查或验证工作质量
  • 跨职能团队具有多样性：测试人员从可测试性方面考虑问题，技术文案跟开发和测试人员一起确认如何表示项目产品的工作方式，分析人员不断细化需求并可能参与构建验收测试

• 根据项目的风险选择生命周期模型

  • 选择何种生命周期模型是项目经理必须先决定的几件事之一，而且会对如何组织项目会有长时间的影响；如无法确定，使用敏捷生命周期模型

• 保持合理的工作时间

  • 人们每天最多只能完成6个小时的技术工作，且不可能长时间加班
  • 长时间加班会扰乱一个人每天的节奏，会把更多时间花在与工作无关的事情上

• 使用小石子避免最后时刻才开始某个任务的工作

• 管理干扰

  • 干扰会导致人们丧失多大40%的时间
  • 两种类型的干扰：其他项目的干扰和其他人的干扰
    • 其他项目的干扰
      • 推迟其他项目的干扰直至当前迭代结束
      • 不知道其他项目的干扰会影响自己的项目，可记录一周发生的干扰，展示这些干扰的影响
      • 以事实为依据，不是责怪别人–项目经理起到教育和通告的职责
    • 他人的干扰：被人的人被问询的人干扰
      • 鼓励大家结对编程（结对制订需求，结对测试）
      • 配备完备的电脑，访问代码库或其他电子文档，共同讨论同一个产出物
      • 回馈给予帮助的人 --小礼物等

• 管理缺陷， 从项目初就开始

  • 前期放任，后期才开始管理 是不行的，缺陷会反过来控制你
  • 如何做：
    * 敏捷生命周期，开发和测试同时；或者增量式生命周期，持续集成和测试
    * 组织缺陷时要分类，定义缺陷的严重程度（技术层面）和优先级（业务层面)
  • 如何影响他人：
    • 问题不是你一个人的。项目经理无需自己必须提供所有的建议和解决方案。项目经理有责任让团队解决问题，而不是强令他们如何解决
    • 思考你能为组织带来的价值。这些价值可以帮你寻求别人的帮助，并给予回报
    • 发现其他人或团队的驱动力，找出特定的激励因素
    • 建议项目经理和负责的人（或团队）共同面对问题，可以让项目经理能够友善开放的接受他人的建议和想法。他们自己寻求答案比直接告之如何做更容易解决问题
    • 倾听团队，了解团队要怎么样才能达到更高的工作效率
    • 在讨论时，给他人思考的时间。推行自己想法时要允许别人认真思考和质疑
    • 不要固执己见，协作方式。 自己过去好的想法可以作为解决某个问题的起点

总结：作为项目经理，要带头考虑使用或调整哪些管理实践； 评估项目的问题，然后根据问题来判断或使用哪些实践；要寻找可以建立和维持项目节奏的实践。