一、立项会议：一张没有日期的排期表
网店要上一个"会员日大促"，王姐给了三周时间。技术部开了立项会，气氛热烈：功能列了一黑板——会员价、专属优惠券、积分翻倍、短信通知、活动页、数据分析……
小陈很兴奋："师傅，这么多功能，三周没问题吧？"
老周看了一眼黑板，问了三个问题：
- "这些功能哪些是必须的？哪些是可以砍的？"（→ 第二章的 MoSCoW）
- "每件事谁来做？"
- "什么顺序做？先做什么，后做什么？"
小陈愣住了："这个……大家先干起来呗？"
老周叹气："这就是典型的'没有项目管理'。没有排期、没有负责人、没有顺序的团队，就像没有指挥的乐队——每个人都在演奏，但合起来是噪音。 这一章，我教你两样东西：怎么定节奏（项目管理），怎么让人协作（团队协作）。"
二、第七层：项目管理——从瀑布到敏捷
2.1 瀑布模型：一步做完，再做下一步
"先讲最古老的模型：瀑布（Waterfall）。"老周画了一条线：
需求分析 → 设计 → 编码 → 测试 → 上线
每个阶段全部做完，才进入下一阶段。
"优点：计划性强，文档齐全，适合需求明确、很少变化的项目（比如给银行做核心系统，需求定死，一写写两年）。"
"缺点：太僵了。 等测试阶段才发现需求理解错了？前面全白干，返工成本爆炸。对云间书店这种'需求天天变'的电商，瀑布就是灾难——王姐三周内改五次需求，瀑布直接崩盘。"
2.2 敏捷宣言：拥抱变化
"于是 2001 年，17 位软件大师写了《敏捷宣言》，核心就四句话："
敏捷宣言（价值观）：
个体和互动 高于 流程和工具
可工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
"翻译成大白话：别憋大招，小步快跑；多沟通，少写没人看的文档；需求变了就变，别硬撑。"
老周说："敏捷不是'没有计划'，而是把大计划拆成小计划，每两三周交付一点能用的东西，随时根据反馈调整。这就是下面要讲的 Scrum。"
2.3 Scrum：敏捷最流行的落地框架
老周在白板上画出 Scrum 的骨架：
Scrum 三大角色：
- 产品负责人（PO） ：代表业务方，负责"做什么"（王姐的代言人）
- Scrum Master（SM）：负责流程顺畅，帮团队扫障碍（老周兼职）
- 开发团队 ：6-9 人，自己认领任务（技术部）
Scrum 的核心节奏（一个 Sprint = 2 周）：
① 冲刺计划会：从需求池挑这个 Sprint 要做的任务（M 优先级）
② 冲刺开发 ：两周内全神贯注做这些事，不接新需求
③ 每日站会 ：每天 15 分钟，每人说三句话（昨天做了啥/今天做啥/有啥障碍）
④ 冲刺评审 ：给王姐演示做出来的功能，拿反馈
⑤ 冲刺回顾 ：团队内部复盘，哪些做得好/哪些要改进
↓ 循环，进入下一个 Sprint
云间书店的一次每日站会（15 分钟）：
小陈：昨天完成了结算页优化，今天做满减配置接口，没障碍。
阿杰：昨天会员模块测出 2 个 bug，今天修复，需要小雯帮忙看个数据。
大刘：昨天库存同步有点慢，今天查，障碍：需要 DBA 权限，还没申请。
小雯：昨天报表改版评审通过，今天合并发布，没障碍。
...
"每日站会的意义：信息同步 + 暴露障碍。 谁卡住了，当场有人帮；谁走偏了，当天就纠正。15 分钟，站着开——因为坐久了会啰嗦。"
2.4 看板：更轻的另一种选择
"Scrum 适合固定节奏；如果需求是持续流动的（比如客服工单、零散小需求），用看板（Kanban）更合适。"老周画了三列：
待办（To Do） → 进行中（Doing） → 已完成（Done）
8 个任务 3 个任务 4 个任务
看板核心规则：
1. 所有任务可视化（贴卡片）
2. 限制进行中数量（WIP Limit）：每人同时最多做 2 件事
3. 任务从右往左"流"，只许前进，不许跳级
"看板的精神：可视化 + 限制并行。 一眼看清团队忙不忙、哪块堵了。WIP Limit 很重要——同时做 5 件事 = 5 件事都做不完。"
三、第八层：团队协作——让"一群人"变成"一伙人"
3.1 一场没人记得结论的会
"工具和流程都有了，但团队协作还有一个老大难——信息丢失。"老周说起上周的事：技术部开了一个小时的架构讨论会，热烈讨论，结束时大家拍屁股走人。三天后，阿杰问："那个支付方案咱们定了吗？"
全场沉默。没人记得结论。
"一场没人记录的会 = 白开的会。"老周说，"信息同步是团队协作的地基。我们有四件套："
团队信息同步四件套：
1. 会议纪要：每次会议 5 分钟记录"结论+待办+负责人"，发群里
2. 决策记录（ADR）：重大技术决策写进文档，写明"为什么这么选"
3. 知识库（Wiki）：常见问题、部署手册、约定规范，沉淀成文档
4. 异步沟通：重要信息用文字写下来（群/文档），别只靠口头
3.2 结对编程：两个人一起写代码
"还有一种高强度的协作方式——结对编程（Pair Programming）。"老周说，"两个人一台电脑：一个人写（驾驶员），一个人看（领航员），随时换。"
"好处：即时评审（写一行看一行）、知识共享（新手快速上手）、减少低级错误。代价：两个人同时只干一件事，看起来'浪费'了一倍人力。"
"但研究数据表明，结对编程只增加约 15% 的开发时间，却减少大量 bug 和返工——对关键复杂模块，非常划算。 我们不强制，但推荐：复杂功能、新人入职、疑难 bug，都可以结对。"
3.3 文档与知识库：把"人脑里的经验"变成"团队的记忆"
"最容易被忽视、最值得投资的事：文档。"老周打开团队的 Wiki 页面：
云间书店技术部 Wiki：
├── 新人指南（环境搭建、代码规范、发布流程）
├── 系统架构图（每个模块是什么、在哪）
├── 部署手册（流水线怎么跑、怎么回滚）
├── 常见问题（FAQ：支付超时怎么办、库存对不上怎么办）
└── 决策记录（为什么用 MySQL 不用 PostgreSQL？答案在这）
"文档是团队的长期记忆。 老员工离职，经验留在 Wiki 里，不在他脑子里。新人入职，看 Wiki 就上手，不用缠着老人问。投资一小时写文档，省下团队一百小时的重复问答。"
3.4 代码所有权与"巴士因子"
"最后一个团队协作概念，有点扎心：巴士因子（Bus Factor）。"老周说，"指团队里'有多少人知道某个模块的细节'——如果知道的人被巴士撞了（离职/休假），项目就瘫痪，这个数字就是巴士因子。"
"我们的目标是巴士因子 ≥ 2：每个关键模块至少两个人懂。"老周说，"实现方式：代码评审让不同人参与、关键模块结对、定期'轮岗'（这周你帮我看库存，下周我帮你看支付）。"
"别让团队变成'离了某个人就转不动'。 这不是那个人太重要，是团队协作没做好。"
四、章末：老周的第七、八层总结
第七层：项目管理
├── 瀑布 → 需求固定时用，计划强、太僵
├── 敏捷宣言 → 小步快跑、拥抱变化、可工作的软件
├── Scrum → 2 周一个冲刺：计划会/站会/评审/回顾
└── 看板 → 可视化 + WIP 限制，适合持续流动需求
第八层：团队协作
├── 会议纪要 → 没记录的会=白开
├── 知识库 → 团队长期记忆（Wiki/ADR/FAQ）
├── 结对编程 → 即时评审 + 知识共享
└── 巴士因子 → 每个关键模块至少 2 个人懂
"小陈，到这一章，我们的技术部终于'像一支队伍'了：有需求流程、有版本控制、有质量防线、有自动化流水线、有项目管理节奏、有团队协作机制。"
老周靠在椅子上，长舒一口气，随即又皱起眉："但是，我发现一个更隐蔽的问题。前阵子为了赶大促，我们疯狂加班，留下了好多'先用再说'的代码——临时方案、硬编码、跳过测试……你猜这些'先欠的债'，什么时候还？"
小陈有种不祥的预感："该不会……利滚利吧？"
"何止利滚利。技术债，是下一章的主角。还有度量——你知道咱们团队现在到底快不快、好不好吗？不知道。下一章，我们面对现实。"