项目团队的构成

• 一般一个实施团队为 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）端到端负责。