Shape Up 阅读笔记（5）- Building: 软件项目应该有的样子

项目团队的构成

一般一个实施团队为 1 个设计师和 1-2 个工程师（1 前端，1 后端）

这几乎是效率最高的最小工作单元，能极大的降低协作成本

团队几乎完全异步和远程工作

没有专职的测试人员，测试部分如何权衡留到后文再写

Building 项目流程描述

一个 Building 本质上等同于一个软件研发的项目（而非迭代），输入的需求是一份 Pitch（见前文）

团队进入项目，阅读 Pitch

一般需要开一个启动会议，回答问题，确保理解一致

基于 Cycle 的长度，找到一个有限项目周期内可以落地的方案：

前文提到的：Fixed Time, Variable Scope

在团队自行在项目内逐步创建「Scope」：Scope 一般指的一个一个可独立完成的模块或者功能

在「Scope」内建立自己觉得需要完成的「Task」

Task 分为 Must-Have or Nice-To-Have 两类

随着完成 Task 的过程，更新各个「Scope」的状态：后文会详细写这部分。

判断项目已经完成，结束

完成的意思，不是写完代码，而是真正的上线。测试工作是 Cycle 内的一部分。

注意：项目过程中，Scope 和 Tasks 都是自然生长出来的，而非在项目初期全部建好的。下面是两个阶段的 Scopes 的样子：

Building 实施过程的一些细节要点

团队在实现过程中，应该首先瞄准可以使用和 demo 的部分，在最开始的一周尽快完成

前端后端分离的项目，应该以可以整合的工作作为最小颗粒度，万不可前端和后端各自做到项目后期才联调

因为 Shaping 产生的内容信息量足够丰富，程序员不应该需要等待设计师完成设计才能动手开发，因此团队内的所有人应该可以同时开始实际工作

甚至可以先出一个非常粗糙的 UI，用来 make things work

可视化只在最后交付前重要，项目中不需要作为验收的标准

后端程序员只做最少的 coding 就可以 move on（对依赖的技术组件使用必要的 mock）

例子：一个需要登录后状态的关键功能，应该先做功能，mock 登录部分；而不应该因为有依赖，先做登录，再做关键功能——因为核心功能隐藏的风险更高。

项目只有完成和未完成两种状态，大部分情况下不允许「延期」，团队需要自己对自己选择的方案和结果负责（因和果）

和新功能需要配合的文本工作，市场类工作，通知等运营工作，通常不是 Cycle 工作的一部分。

Building 的核心管理逻辑

Assign Projects，Not Tasks

团队自己创建认为需要的 Tasks

没有人负责 Assign Tasks，像个任务分配员

没有架构师拆解项目，然后等着其他人实现

关键点：信任团队，让团队自己对整个项目负责

关键点：Pitch 的边界给项目的实施提供了足够的自由度，有才能的技术人员不愿意像个 code monkey 一样工作，能更好的激励一线员工工作的积极性和爽度

当每个人只是对 Task 负责，没有人对整个事情有责任感，项目的效果往往会走样。因此 Building 的核心意义是：让团队对一个指定范围内的价值交付（Pitch）端到端负责。

那么，是不是给了团队足够的自由度，并信任他们的自驱力，项目不需要可以管理了呢？

显然不是的，下一篇我们来说 Building 阶段的项目进度，如何监控，预警。