被理解的项目节奏

• 理解项目初期，会有静默期，团队需要时间消化 Pitch 里的内容，需要设计和思考，因此项目刚开始的几天，没有任何进度会是常态。
• 理解任何的工作的本质，都会经过「探索」，「排坑」，「确定」，「完成」这样的过程。
• 理解任何的「探索」阶段，因为存在不确定性，这时候讨论「进度」都是没有意义的。
• 理解没有称职的经理，愿意追问团队「进度」和「更新」。
• 理解没有任何工程师，喜欢被人追问「进度」和「更新」。
• 你我都清楚的知道，从任何实操来说，Number of Completed Tasks / Number of Total Tasks 作为项目完成百分比，是多么傻逼。
  
  

被观测的软件开发工作本质

Shape Up 把项目管理的重点，从一般实践里的「完成」vs「未完成」，重新定义成了「不确定」和「已解决」。

• 爬坡 Up Hill：研究怎么做，如何做，验证是不是真的能做，重点在于对抗一切不确定性（这个阶段任何试图百分比量化都是毫无意义的）
• 山顶：所有不确定都已经解决的瞬间。
• 下山 Down Hill：明确事情可以完成，剩下主要是对时间去实现和最终完成。
  
  

组合 Scope 和 Hill 的概念，就有了对项目状态最合理的表达：每个 Scope 在山上的位置，本质上才是整个项目的进展情况，工程师标记每个 Scope 的 Hill 位置，整个项目就是可观测并且准确的。

• 一般上山阶段再分成三部分来管理
  • 0%：还没开始
  • 33%：首先是脑子里想好了应该怎么做
  • 66%：已经简单验证过了
  • 100% 山顶：已经实际做的足够我确认不会有什么未知风险了
• 一般下山阶段则可以用剩余的 Tasks 数量来标记进度。
  
  

被理解的本质，工作和人

• 很多时候，人们并不愿意主动承认自己「卡住了」，而花了太多时间独自解迷；一般只有到死线将至，工程师才愿意主动「举手投降」，揭示风险，往往却太晚了。——项目经理需要通过对项目真实进展的观测，判断风险，主动介入。
• 很多时候，Scope 状态卡住，也可能是因为 Scope 定义的不合理。——项目经理可以介入去帮助拆分得更好。
• 也有时候，有的工程师会「回退」原本已经到了「山顶」的 Scope。
  • 一般来说，很可能是因为有人只是在脑子里「攻克」了问题，没有上手实践。
  • 一切风险在没有动手做之前，都不应该被低估。
• 鼓励工程师们，总是先去爬最难的山，最不确定的山，这样会大大降低项目整体的风险。