1. 资源分配基础：什么是资源分配、资源类型与核心原则
大家好，我是老张。今天咱们开始这门课的第一章。
先问个问题：你手头有多少项目是因为「人不够」、「时间来不及」、「预算超了」而搞砸的？
我猜，十个里面至少有六七个。剩下的那几个，表面上是技术问题，深挖下去，还是资源没配好。
资源分配，说白了就是——把对的东西，在对的时间，用对的量，交给对的人。听起来像废话？但我在项目里见过太多反面案例了。
1.1 什么是资源分配
资源分配，不是简单的「分猪肉」。它是一套决策机制。
你手上有多少资源？每个任务需要多少？谁先谁后？遇到冲突怎么调？
我个人的习惯是，在项目启动的第一周，就把资源分配表拉出来。不是那种糊弄领导的Excel，而是真正能指导干活的东西。
核心定义：资源分配 = 在有限资源约束下，将资源匹配到任务优先级的过程。目标是最大化项目产出，最小化浪费和风险。
举个例子。你团队就5个人，要同时做A、B两个功能。A是核心业务，B是锦上添花。你怎么分？
很多新手会「一人一半」。结果两边都做不好。正确的做法是：集中优势兵力打歼灭战。先搞定A，再腾出手做B。
1.2 资源类型：你手里到底有什么牌？
很多项目经理只盯着「人」。其实资源远不止人力。我把它分成四大类：
| 资源类型 | 核心特征 | 常见误区 | 我的经验 |
|---|---|---|---|
| 人力 | 技能、经验、带宽、稳定性 | 只数人头，不看能力 | 一个高级工程师顶三个初级，但别让他干杂活 |
| 时间 | 不可再生、有截止点、有依赖链 | 盲目压缩工期，不考虑质量 | 时间是最硬的约束，别跟它讨价还价 |
| 预算 | 可量化、有上限、需要审批 | 前期大手大脚，后期没钱收尾 | 留出15%-20%的应急储备，别问我怎么知道的 |
| 设备/工具 | 测试机、服务器、许可证、环境 | 以为随时能用，结果排队等资源 | 提前预约，尤其是CI/CD环境和压测机器 |
避坑指南：我曾经接手过一个项目，团队说「人够了」，结果一查，三个初级工程师在啃一个需要十年经验才能搞定的底层模块。人力不是数量，是有效产能。你想想看，让一个刚毕业的去写核心调度算法，那不是培养人，那是给项目埋雷。
1.3 资源分配的核心原则
原则这东西，听起来虚。但真正吃过亏的人，都懂它的分量。我总结了四条：
原则一：优先级驱动
资源永远不够。所以你必须先回答：什么最重要？
我习惯用MoSCoW法则来排优先级：
- Must have：没有它，项目就黄了
- Should have：很重要，但可以晚一点
- Could have：有了更好，没有也能活
- Won't have：这次不做，下次再说
记住：先保Must，再谈Should，Could和Won't直接砍掉。别心疼，你心疼资源，资源就会让你心疼。
原则二：匹配度优先
把合适的人放到合适的任务上。不是谁有空就派谁。
举个例子。一个模块需要高并发经验，你派了个做CRUD的哥们去搞。结果呢？代码写出来能跑，但一上线就OOM。返工的成本，比一开始就派对人大得多。
小技巧：我每次分配任务前，会先画一个「技能-任务匹配矩阵」。横轴是任务，纵轴是人，交叉点标出匹配度（高/中/低）。高匹配度的优先分配，低匹配度的要么培训，要么换人。这招帮我避免了好几次「用人不当」的坑。
原则三：留有余地
别把资源用满。永远留出10%-20%的缓冲。
为什么？因为计划永远赶不上变化。需求会变，人会生病，服务器会宕机。你把资源用满了，一旦出点意外，整个项目就崩了。
我见过最惨的一个项目，预算精确到每一分钱，人力排到每一小时。结果客户一个紧急变更，整个计划全乱套。最后延期两个月，团队累垮了一半人。
原则四：动态调整
资源分配不是一锤子买卖。它是个持续的过程。
我建议每周至少做一次资源审视：
- 当前资源使用率是多少？
- 有没有任务提前完成，释放了资源？
- 有没有任务卡住了，需要加人？
- 优先级有没有变化？
别等到月底才发现资源失衡。那时候黄花菜都凉了。
1.4 知识体系总览
下面这张图，把本章的核心逻辑串起来了。你可以把它当成一个思维导图来用。
这张图你看懂了吗？从上到下，从左到右，其实就是一条逻辑链：先搞清楚什么是资源分配 → 再盘点你手里有什么资源 → 然后遵循四条原则去分配 → 最后避开那些常见的坑。
嗯，这就是本章的全部内容。别小看这些基础，后面每一章都会用到它们。你先把地基打牢，后面盖楼才稳当。