Shape Up 阅读笔记（6）- Scope on Hills: 抛开现象看本质的项目进度管理

Scope on Hills: 抛开现象看本质的项目进度管理

即使是高度自驱，高度自由的项目，仍然需要管理进度。

但没有人喜欢「被管理」。

被理解的项目节奏

理解项目初期，会有静默期，团队需要时间消化 Pitch 里的内容，需要设计和思考，因此项目刚开始的几天，没有任何进度会是常态。

理解任何的工作的本质，都会经过「探索」，「排坑」，「确定」，「完成」这样的过程。

理解任何的「探索」阶段，因为存在不确定性，这时候讨论「进度」都是没有意义的。

理解没有称职的经理，愿意追问团队「进度」和「更新」。

理解没有任何工程师，喜欢被人追问「进度」和「更新」。

你我都清楚的知道，从任何实操来说，Number of Completed Tasks / Number of Total Tasks 作为项目完成百分比，是多么傻逼。

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

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

对任何一块工作，我们把他比喻为一个爬山的过程，分为两个阶段：爬坡 Up Hill 和下山 Down Hill。

爬坡 Up Hill：研究怎么做，如何做，验证是不是真的能做，重点在于对抗一切不确定性（这个阶段任何试图百分比量化都是毫无意义的）

山顶：所有不确定都已经解决的瞬间。

下山 Down Hill：明确事情可以完成，剩下主要是对时间去实现和最终完成。

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

一般上山阶段再分成三部分来管理

0%：还没开始

33%：首先是脑子里想好了应该怎么做

66%：已经简单验证过了

100% 山顶：已经实际做的足够我确认不会有什么未知风险了

一般下山阶段则可以用剩余的 Tasks 数量来标记进度。

被理解的本质，工作和人

很多时候，人们并不愿意主动承认自己「卡住了」，而花了太多时间独自解迷；一般只有到死线将至，工程师才愿意主动「举手投降」，揭示风险，往往却太晚了。——项目经理需要通过对项目进度的观测，判断风险，主动介入。

很多时候，Scope 状态卡住，也可能是因为 Scope 定义的不合理。——项目经理可以介入去帮助拆分得更好。

也有时候，有的工程师会「回退」原本已经到了「山顶」的 Scope。

一般来说，很可能是因为有人只是在脑子里「攻克」了问题，没有上手实践。

一切风险在没有动手做之前，都不应该被低估。

鼓励工程师们，总是先去爬最难的山，最不确定的山，这样会大大降低项目整体的风险。