写在前面
经过前两讲的铺垫，我们解决了 “做什么” （MVP范围）和“怎么做” （敏捷模式）的问题。然而，这些都是纸上谈兵。
真正的考验，从今天开始。你看着手里握着的团队人员配置：
| 角色 | 理想配置 | 现实情况 | 缺口 |
|---|---|---|---|
| 产品经理 | 1人 | Linda（1人） | 0 |
| UI设计师 | 1-2人 | 与公司其他项目共享，每周最多支持3天 | 0.5人 |
| 前端开发（Web/H5） | 2人 | 小王（1人） | 1人 |
| iOS开发 | 1人 | 无 | 1人 |
| 安卓开发 | 1人 | 无 | 1人 |
| 后端开发 | 2-3人 | 老张 + 小李（共2人） | 0-1人 |
| 测试工程师 | 1-2人 | 无 | 2人 |
| DevOps/运维 | 0.5人 | 老张兼任 | 勉强覆盖 |
你要用这个“残阵”，去完成一个对标行业巨头的任务。
如果这是你接手的项目，你的第一反应是什么？
A. 崩溃，找老板辞职
B. 硬着头皮上，车到山前必有路
C. 开始系统性地盘点、重组、求援
选C的人，恭喜你，你有了项目经理的基本素养。但接下来才是真正的考验：如何把一副公认的“烂牌”，打出至少能上牌桌的效果？
互联网项目，特别是初创公司，常态就是资源永远稀缺。作为项目经理，你面临的不是资源优化，而是 “生存战”。
能摸到好牌是可遇不可求的，大多数时候，我们手里都是烂牌。如何把手上的烂牌打好，才是真正考验一个PM的战略眼光和资源整合能力。
一、 摸清家底：“人员与能力”盘点
几乎所有项目管理教科书都会告诉你：先组建团队，再启动项目。
但在真实的互联网世界里，这句话要反过来：先有项目，再有什么用什么，最后在过程中把“一群人”变成“一个团队”。
我们的第一个思维转变必须是：忘掉标准的岗位配置，用“能力清单”代替“职位头衔”。
巧妇难为无米之炊。所以在考虑如何争取资源之前，你必须知道自己手里的“米”到底有多少，以及这“米”的质量如何。
1. 资源核算：从自然月到“净工时”
老板给的时间是“3个月”。但PM必须将其翻译成 “净工时”。
- 团队配置： 4人（2后端、1前端、1UI）。
- 总工时： 人天。
请立刻进行 “工时折损计算”：
| 折损项 | 折损比例（预估） | 损失工时 |
|---|---|---|
| 基础折损（会议、行政、HR流程） | 10% | 约 26 人天 |
| 敏捷开销（站会、评审会、回顾会） | 15% | 约 40 人天 |
| 技术债/返工（老张经验、新手前端） | 15% | 约 40 人天 |
| 突发状况（老板插队、服务器宕机） | 5% | 约 13 人天 |
| 净工时 | 55% | 约 145 人天 |
结论： 3个月的窗口期，你的实际开发净工时只有145天。平均到每人，只有36天的深度开发时间。这个数字必须成为你所有排期和谈判的基准。
2. 能力盘点：警惕“单点瓶颈”
另外拿出一张白纸，开始画一张完全不同的表格。我不再问“我们缺什么职位”，而是问“要完成V1.0，我们需要哪些具体的能力”：
| 能力领域 | 具体能力 | 谁有？ | 熟练度（1-5分） |
|---|---|---|---|
| 移动端开发 | iOS原生开发 | 无人 | 0 |
| 安卓原生开发 | 无人 | 0 | |
| React Native/Flutter跨端 | 小王（了解） | 2 | |
| 前端开发 | 管理后台前端 | 小王 | 4 |
| H5活动页面 | 小王 | 4 | |
| 后端开发 | API设计与开发 | 老张、小李 | 5、3 |
| 视频处理服务 | 老张（有经验） | 4 | |
| 推荐算法基础 | 老张（理论） | 2 | |
| 测试与质量 | 功能测试 | 无人 | 0 |
| 自动化测试 | 无人 | 0 | |
| 性能测试 | 无人 | 0 | |
| 运维与部署 | 服务器部署 | 老张 | 4 |
| 监控与告警 | 无 | 0 | |
| 产品与设计 | 交互设计 | Linda + UI设计师 | 3、4 |
| 视觉设计 | UI设计师 | 4 | |
| 需求细化 | Linda | 3 |
这张表一出来，形势反而清晰了：
- 移动端是最大的黑洞：完全空白
- 测试是第二大黑洞：完全空白
- 后端是相对优势：老张能撑住，但独木难支
- 我们有的，和我们需要的，严重错配
面对这样的能力地图，传统思维会告诉你：赶紧招人，把坑填上。
但在互联网公司，在三个月必须上线的死命令下，这个思路行不通。因为：
- 招聘至少需要一个月，新人熟悉项目最少需要半个月
- 领导不会给你额外的人员编制
- 就算招到了，也不一定合适
所以，我们必须换一种思路：不是“缺什么补什么”，而是“有什么用什么，实在没有的，换个方式实现”。
2. 补短板，还是扬长板？
资源盘点更重要的是要好钢用在刀刃上，你需要将团队成员的能力进行“解耦”。
| 角色 | 能力特点 | 潜在瓶颈 | 应对策略 |
|---|---|---|---|
| 老张（资深后端） | 架构能力强，代码质量高。 | 单点瓶颈。 核心架构/部署必须由他负责。 | 让他主要负责架构搭建和核心接口，避免陷入 CRUD 业务。 |
| 新手后端 | 热情高，经验少，但可塑性强。 | 缺乏经验，容易产生 Bug，需要老张大量指导。 | 负责次要业务和文档工作，从老张那里接手非核心CRUD。 |
| 前端（会Vue） | 熟悉Web，但对原生App开发经验为零。 | 技术栈切换成本高。 如果选原生，学习成本巨大。 | 必须选跨平台框架，利用其现有Web经验，快速上手。 |
| Linda（产品） | 经验少，但执行力强，对老板意图理解深。 | 需求文档深度不足，容易被老板带跑。 | 必须兼任PO（产品负责人） ，严格遵守迭代锁。 |
团队组建核心原则： 我们的目标不是组建完美的团队，而是组建一个 “最小可行性团队（Minimal Viable Team, MVT）”，保证每项核心任务都有人负责，且关键节点不会因为某人离职而瘫痪。
二、 技术取舍：用“烧钱”买“时间”（兼答作业）
在资源匮乏的项目中，PM的战略价值体现在：敢于做痛苦的取舍，特别是“自己搞 VS 花钱”的决策。
先考虑清楚这三个问题：
- “我们的目标用户大部分用什么手机？是iPhone 13 Pro Max还是红米9A？”（答案是后者，千元安卓机）
- “我们的核心指标是什么？是极致的60帧流畅度，还是‘能用、不卡、能看视频’？”（答案是后者）
- “我们愿意用多少性能损失，换取开发速度翻倍？”（需要技术评估）
结论：“如果用React Native，配合一些原生模块优化视频播放，在低端机上应该能达到‘勉强可用’的水平。比原生差，但比没有强。”
这就是资源受限下的核心决策逻辑：不是追求最好，而是追求“在约束条件下的最优解”。
对于关键的技术决策点，作为项目经理，你不需要懂具体的技术实现，但你必须引导团队做出风险可控的选择。
1. 技术架构取舍——为什么选择跨平台？
决策： 必须选择跨平台框架（如 Flutter 或 Uni-app）。
| 对比维度 | 原生开发 | 跨平台开发 | 结论 |
|---|---|---|---|
| 时间成本 | 6个月+（两套代码） | 3个月（一套代码） | 跨平台是唯一能在3个月内完成的方案。 |
| 人力成本 | 2名前端（iOS+Android） | 1名前端 | 节省50%的人力开销。 |
| 性能考量 | 最佳 | 良好，但渲染会有损耗。 | 可接受。 “抖腿”的核心是搞笑和流畅度，而非极致的3D性能。 |
| 团队适配 | 0% | 80%（前端有Vue基础） | 利用前端现有的Web经验，快速形成战斗力。 |
PM结论： 在资源受限时，速度和效率永远优先于理论上的完美性能。
2. 功能取舍——为什么“烧钱”也要买服务？
| 功能 | 自研成本 | 第三方 SaaS 成本 | PM决策 |
|---|---|---|---|
| 视频转码/存储 | 需要大量服务器、带宽、编解码经验（老张无法兼顾）。 | 按量付费，即插即用（阿里云/腾讯云）。 | 必须购买。 自研成本高昂且耗时，会占用老张大量时间，延误核心架构。 |
| 内容审核/风控 | 需要AI/图像识别经验，政策风险高。 | 按条数付费，专业服务商（易盾/内容安全平台）。 | 必须购买。 这是法律风险。自研不仅耗时，一旦出事，公司可能直接被封禁。 |
“粮草先行”的道理： 互联网创业，时间就是命。自研非核心技术（转码、审核）是一种对时间的巨大浪费，也是对专业风险的漠视。在关键时刻，烧钱买服务，就是买时间、买专业、买合规。
三、 团队组建：三位一体与跨职能
在小团队里，没有冗余的职位。每个人都必须扮演多个角色。
1. PM的“三位一体”
在“抖腿”项目组，你不再是一个单纯的PM。你必须身兼三职，缺一不可：
- 项目经理（PM）： 负责排期、进度管理、资源协调。
- Scrum Master (SM)： 负责保障流程（迭代锁）、消除障碍（解决研发老张遇到的问题）。
- 产品负责人（PO）： 负责需求的最终决策（与产品共同承担）和Backlog的优先级排序。
PM的价值不再是“管理”，而是 “粘合剂”和“过滤器”。
2. 组建“功能团队”而非“组件团队”
-
错误做法（组件团队）： 前端团队只负责前端，后端团队只负责后端。
- 问题： 协作成本高，一个功能需要跨越多个团队，容易互相等待。
-
正确做法（跨职能团队）： 将所有人按功能划分为一个整体（如：“Feed流交付团队”）。
- 结构： 老张 + 新手后端 + 前端 = “战斗小组” 。
- 优势： 团队的唯一目标是交付完整的功能。沟通效率最高，责任划分最清晰。
四、 资源争夺战：会哭的孩子要“有理有据”
“会哭的孩子有奶喝”——这句职场哲理的真正含义是：你的需求必须是基于价值和风险的，而不是基于情绪的。
在项目启动之初，PM不应该立刻向老板哭穷。而是要：先证明自己能用烂牌打出成绩。
1. 资源申请的“三步走”策略
你不能说“给我加人”，你要说“为了实现X目标，我们需要Y资源”。
第一步：战术自救（自证能力）
- 动作： 跑完第一个迭代（两周），成功交付一个Demo。
- 目的： 用成果（而不是抱怨）来证明团队的效率和方案的正确性。
第二步：数据化提需（合理谈判）
- 时机： 跑完第一个或第二个迭代，有了清晰的燃尽图（Burndown Chart）数据后。
- 谈判重点： 提出 “资源置换”。例如：“老板，我们用4人团队在第一个月完成了20%的MVP核心功能，证明了敏捷是有效的。但按照当前进度，要在3个月内实现V1.0的全部功能，必须额外增加2名资深后端，或者将上线日期延后一个月。”
第三步：资源优先级梯队
在谈判桌上，不能只给老板一个选项。你要准备好一个优先级梯队：
| 优先级 | 资源类型 | 目标价值 | 谈不成就做什么？ |
|---|---|---|---|
| A级（必须争取） | 外部 SaaS 服务（转码/审核） | 购买专业度，规避法律和技术风险。 | 只能进一步砍掉功能，V1.0无法上线。 |
| B级（强烈建议） | 1名资深前端或UI | 消除单点瓶颈，提高用户体验。 | 前端UI必须降级，用户体验风险增加。 |
| C级（争取时间） | 上线日期延后2周 | 换取回旋余地，提高测试质量。 | 只能通过牺牲测试时间来赶工。 |
核心： 资源申请，本质上是风险和价值的再分配。你不是在要钱，你是在将 “无法完成的风险” 推给决策者。
五、启动：第一次迭代规划会议怎么开？
团队组建完毕，但如何让大家真正成为一个“团队”，而不是“各自为战的人”？
答案在于第一次会议。这不是普通的任务分配会，而是一次建立共识、明确规则、点燃斗志的启动会。
会议议程只有三项：
第一项：共同理解我们要做什么
- 不是读文档，而是一起分析竞品（抖音、快手）
- 重点讨论：“它们第一个版本是什么样？我们比它们差在哪里可以接受？”
- 得出共识：我们的V1.0，就是一个“能刷搞笑视频”的极简App
第二项：共同制定游戏规则
在会议上约定好四条团队公约：
- 迭代内需求冻结：这两周定好的需求，天王老子来了也不能加
- 每日站会不超过15分钟：只说三件事：昨天做了什么、今天做什么、遇到什么障碍
- 问题不过夜：遇到阻碍，当天必须提出，大家一起解决
- 尊重专业，但可以挑战：技术听老张的，产品听Linda的，但任何人都可以提出质疑
第三项：认领第一个迭代的任务
第一个迭代目标：做出一个能安装、能播放5个预设搞笑视频的App原型。
把任务贴出来，让团队自己认领。
- “React Native环境搭建” - 小王认领
- “视频播放组件开发” - 小王+外部顾问
- “后端视频列表API” - 老张认领
- “5个测试视频准备与上传” - Linda认领
- “App基础UI框架” - UI设计师认领
关键细节： 让每个人在认领时，当场估算需要多少小时。不是为了考核，而是为了让他们自己感受到任务量，学会量力而行。
会议结束时，提出最后一个问题：“各位，我们现在这个团队配置，比大厂差远了。但你们觉得，我们有没有可能，用三个月时间，做出一款至少能让100个人笑出来的产品？”
沉默了几秒。小王先开口：“试试呗，反正最坏也就是做不出来。”
老张推了推眼镜：“技术上，有希望。”
Linda眼睛发亮：“我会准备好后面的需求！”
六、 总结：PM的价值是“化腐朽为神奇”
项目经理的价值，从来不是将完美的计划完美地执行出来。
真正的PM，是在没有资源、没有时间、没有完美方案的情况下，找到一条最低成本、最高速度的生存路径。
“抖腿”项目，是一个典型的 “烂牌”项目。我们已经通过前三讲的梳理：
- 明确了方向： 轻量级搞笑App（V1.0章程）。
- 选定了模式： 敏捷（迭代锁）。
- 盘点了资源： 确定了 MVT 结构（解耦），并通过购买服务将核心技术资源最大化。
我们手里依然是烂牌，但我们已经有了打牌的章法。接下来，就是卷起袖子，进入残酷的执行阶段了。
【第3讲·实战作业】
现在，你已经将团队组建为一支敏捷战斗小组。 下一步，你需要带领团队进行第一次迭代规划：划分任务、明确目标。
请思考：
- 迭代目标： 第一个 Sprint（两周）的目标是什么？（不要说“把App做完”，要说 “一个可验证的最小功能集”）。
- 研发的任务： 在第一个迭代中，你认为研发（资深后端/架构师）最主要的任务是什么？（什么任务是不可替代的？）
- 验收标准： 第一个迭代结束时，你的 “验收标准（DoD）”是什么？（不能只看代码，要看用户价值）。
下集预告： 团队开始运转，你却发现大家在站会上只会说“我昨天在写代码，今天继续写代码”。
- 如何让站会真正发挥作用？
- 如何让产品经理和开发人员说同一种语言？
- 如何把“做一个点赞功能”这样的模糊需求，拆解成团队真正可以执行的任务？
- 如何进行高效的用户故事梳理？
敬请期待敏捷第4讲：用户故事拆解——别把“点赞功能”写成几千字文档，学会用卡片说话
