识别和避免日程安排游戏

识别和避免日程安排游戏

• 给我一块石头

  • 出资人总希望项目能更早完成。 有时出资人不会认同提出的每一个截止日期–总是离期望值很遥远
  • 当出资人希望项目能更快交付但不告诉何时需要或为什么的时候就会玩 给我一块石头的游戏。
  • 应对策略：
    • 先提问：喜欢短日程或长日程？更多还是更少人？少实现几个功能会如何？先知道什么是最重要的会帮项目经理产生更加合理的解决方案
    • 找出什么原因促成了他们期望的截止日期。探寻出项目的战略原因，并搞清楚成功的真正含义
    • 让出资人明白所做的选择以及背后的原因
    • 为提供的日期说明信心范围
    • 提供日期时要说明发布条件，通过提一些问题，了解对于发布版本的质量和功能的要求
  • 项目发生这种状况，可以如下实践
    • 制定排好优先级的产品待办列表
    • 逐个实现功能，让出资人了解更多的项目进程,就不会纠缠截止日期了
    • 使用短小的时间盒（持续时间小于四周），出资人可以看清项目进程，有价值的进展，截止日期就没那么重要了

• 希望时我们最重要的策略

  • 仅有希望，不足以交付一个成功的项目
  • 对于全新的复杂项目，如下方式帮助成功：
    • 识别风险并记录下来，包括技术（新的语言，平台），日程安排等
    • 不要万不得已，不要采用瀑布式生命周期。没有数据支撑瀑布式所需的前期计划过程。可以用迭代进行原型化，或通过迭代开发几个功能
    • 可以用 哈德逊湾式起动，帮助团队了解所做的东西，揭示些尚未发现的风险
    • 确保大家具备相关的技术能力，还有解决问题必备的领域知识。有必要可进行培训
    • 考虑所有工作采取迭代的方式进行，特别是项目规划和日程安排
    • 缺少经验和专业知识，可以寻求相关的帮助和信息，跟团队一起商量如何让他人了解工作进展
    • 指定里程碑条件（里程碑也可是迭代的），在管理层复审会议上审查这些条件
    • 使用时间盒限制迭代，所有人都可以看到项目进展
    • 使用速度图展示项目进展，大家都很明白的看到进展

• 拒绝女王

  • 当告诉完成困难时，老板不愿面对现存困难或潜在的问题。拒绝是因为害怕项目无法在截止日期前完成或是鼓励团队
  • 应对：
    • 找出管理层表示拒绝的原因，尝试用一些与上下文无关的问题，如怎样才算成功
    • 写下项目风险及其潜在影响。用高中低来讨论严重程度和暴露程度而不要用数字
    • 展示你能所做到的事情，并测量团队在项目中的实际开发速度。速度图表可以告诉项目真实状况
    • 保证参与项目工作的每个人都有相关领域的专业只是
    • 如果管理层认为拒绝是鼓励团队，建议他采取其他的鼓励技巧。或将他注意力转移到其他项目
  • 只要项目经理能够接受现实，最终不一定造成灾难。当管理层看到真正的现实后，项目经理要有部分可以工作的产品，可以展示的数据。可以后续讨论能做什么，可以不做什么。
  • 展示实际进展： 使用有限的时间盒限制迭代；制定排定优先级的产品代办事项

• 把灰扫到地毯下：掩盖问题(本文主要指低优先级的花了很多时间）， 如何避免的方法

  • 使用产品代办事项，功能按业务价值排序；使用有限的时间盒限制迭代

• 幸福日期：组织的不一致，只想彼此安慰避免冲突

  • 管理层说服项目经理和团队，相信他们可以满足管理层对梦想时间或幸福日期的要求
  • 与拒绝女王有联系但不完全相同：幸福日期是双方都愿意，团队想抚慰干系人，干系人也愿意得到安抚；拒绝女王是项目干系人希望得到安抚，但团队坚持告诉现实
  • 应对：
    • 说明日程安排的范围，特别是不使用迭代生命周期
    • 使用迭代生命周期，并说明会通过信心范围实现哪些功能
    • 使用敏捷生命周期和经过排序的代办事项列表
    • 即使采用分阶段交付的生命周期，也要使用短小的时间盒
    • 不要仅仅以里程碑日期作为项目的衡量标准

• 屁股着火： 多项目，多任务

  • 管理层害怕或无法一次将精力集中到一件事情上， 原因可能是技术人员曾延迟，公司没有战略规划，或者规划没有分解成足够详细的具体工作规划
  • 应对：
    • 小时间盒的迭代进行规划
    • 按功能逐个实现，
    • 将采用某种策略的成本告诉管理层，选择要解决时间危机还是付出经过计算的时间成本
    • 策略确定后，帮助公司检查相应的具体措施
    • 项目经理可以调整估算方法，让团队更容易达到最初的估算日期
    • 觉得客户还不需要目前的产品，想让所有人去做其他项目。这样的情况要让大家以短迭代方式工作，且在启动时就要知道是否存在会导致项目推迟的原因，还要确保管理层已制定项目组合方案且一直在管理
    • 单一项目的工作环境还是成功的保证

• 分散注意力

  • 多项目，多任务
  • 行动：
    • 一周一个迭代，且每个迭代结束时可以发布产品，一周内集中关注在一个项目
    • 无法迭代，按功能逐个实现，按阶段交付
    • 成本管理告诉管理层，时间危机和付出额外成本之间进行权衡
    • 确保已经对需求进行了优先级排定，而且可以赶紧完成一些工作
  • 集中注意力意味着只在一点上集中

• 日程等于承诺

  • 讨论项目后面的驱动因素，约束和浮动因素, 截止日期之前，哪些功能必须交付，质量标准如何。如果未有项目日程，功能集合，缺陷水平进行讨论，任何关于日程作为承诺都太早
  • 用信心水平来沟通，两个信心水平之间要做的事情，帮助深入了解日程作为承诺意味着什么
  • 交付日期渐进法：季度-》特定月 -》特定日
  • 有时间盒限制的迭代，用按优先级排序的代办事项列表
  • 不要只能诺一个日期

• 到了之后，就会知道身在何方

  • 项目目标多变，就会失去目标
  • 和给我一个石头不同，此要求是项目目标改变，项目日期不变；
  • 建议：
    • 确定有书面的项目愿景，项目目标和发布条件，并就此达成共识
    • 如果管理层不愿定义愿景，项目经理担起责任，完成公布并坚守这个目标
    • 如果项目持续很长时间，迭代来组织。每个迭代完成后评估项目进度。如目标已完成就结束项目

• 日程安排工具总是对的，梦幻时间日程

  • 决策层不了解项目，认为关键路径保持不变。因为他们看到的报表是已完成的数据
  • 漂亮的甘特图会掩盖事实：日程安排只是猜测
  • 建议：
    • 制定波浪式规划：只需前几周的详细计划还有主要的里程碑，后续的会在完成前面的之后提供详细的计划
    • 使用低技术含量的日程安排计划，要去决策层复查项目日程
    • 提供带有信心水平的估算而不是甘特图
    • 使用有时间盒限制的迭代，且每次只规划一个迭代能做的工作
  • 工具没错，关键是使用工具的人对其过于相信

• 必须有这个功能，否则就完蛋了

  • 额外新的功能加入，按日程及时交付没可能
  • 应对：
    • 改变功能集合，拿走不需要的
    • 要求更多的时间
    • 要求更多的资金
    • 使用有时间盒限制的迭代，按实现功能的优先级逐个实现

• 不能说不， 面对额外加的功能

  • 解决方案：
    • 询问队员，针对额外添加的功能制订计划
    • 如果选择加班完成，建议使用时间盒限制加班时间并衡量加班效果和可持续性。比如加班一周
    • 可以加入额外的人来做更多工作，需对产品或团队了解的人； 布鲁克斯法则
  • 项目经理要有勇气说不，用数据说话–速度图表和迭代内容图标

• 日程小鸡： 都说按日程安排进行，实际却非如此

  • 等别人先说
  • 除非太晚，否则没人承认自己错过了项目进度安排
  • 应对：
    • 避免逐个进行的进度报告会议
    • 将任务分解为更小的任务，每人每天都能交付一小块任务最多两块
    • 按功能逐个实现，定期看到产品各个部分集成到一起，看到项目进展
    • 迭代特别是敏捷生命周期

• 90% 完成状态

  • 以为完成90%，实际上还有90%未完成
  • 消除方法：
    • 帮助大家定义出自己的小石子
    • 让大家把自己的工作进度展示，可能会揭示代码潜藏的问题，风险列表，测试用例列表
    • 教给大家如何跟踪自己的估算
  • 短迭代开发，以更小粒度来估算和实现，更准确

• 马上会变得更快: 盲目乐观

  • 开发速度没有达到预计效果，但团队盲目乐观
  • 解决方案
    • 与项目团队成员讨论进展速度，收集乐观的原因
    • 测量估算质量因子
    • 测量团队所做的每一件事情，确保做当前交付的任务
    • 如果涉及硬件，要测量其挣值，看是否能按进度计划进行
    • 测量开发速度时，前三个迭代中，任何整体速度数值都有可能

• 令人恍惚的日程： 确定赶不上日程

  • 创建项目仪表板，再测量进度
    • 剩下的项目分解成迭代，短迭代
    • 每个迭代集中精力，每日站会会对此有帮助
    • 如果还没准备好，按功能逐个实现
  • 通过使用游击队式敏捷，短迭代按功能逐个实现

总结：日程安排的游戏总是发生，项目经理要识别它们，管理项目，让项目成功； 绝大数情况，游戏的发生不是出于恶意； 即使没有恶意，日程安排游戏还是会拖项目后退