第四章：研发阶段管控：敏捷开发流程、任务分解与排期、每日站会、代码审查机制

研发阶段，说白了就是项目从「纸上谈兵」到「真枪实弹」的关键时期。很多硬件产品经理觉得研发是工程师的事，自己插不上手。我告诉你，这种想法很危险。研发阶段的管控，直接决定了产品能不能按时、按质、按预算交付。

我个人习惯把研发阶段比作「搭积木」。你想想看，如果积木本身歪歪扭扭，搭出来的城堡能稳吗？所以，这一章我们重点聊聊四个核心管控手段：敏捷开发流程、任务分解与排期、每日站会、代码审查机制。

4.1 敏捷开发流程：别让「敏捷」变成「乱搞」

敏捷开发在软件圈已经玩得很溜了，但在硬件领域，很多人觉得「硬件没法敏捷」。嗯，这里要注意，硬件确实有它的特殊性——比如打样周期长、物料采购慢、测试验证耗时。但这不代表我们不能用敏捷的思路。

我在项目中遇到过这样的情况：团队按传统瀑布流做，需求文档写了三个月，结果一开发发现市场已经变了。后来我们引入了硬件敏捷的变体——Scrum + 硬件冲刺。

核心做法是这样的：

• 冲刺周期（Sprint）：硬件项目建议2-4周一个冲刺。太短了，打样都来不及；太长了，又失去了敏捷的意义。
• 冲刺规划会：每个冲刺开始前，团队一起确定这周要完成哪些「用户故事」。注意，这里的用户故事要拆得足够细，比如「完成电源模块的原理图设计」，而不是「完成整机设计」。
• 冲刺评审会：冲刺结束时，展示可工作的成果。硬件上可以是「一块能点亮的PCB」，或者「一个能跑通基本功能的固件版本」。
• 冲刺回顾会：这个很重要。团队坐下来聊聊，哪些做得好，哪些需要改进。我曾经带过一个团队，每次回顾会都变成吐槽大会，但吐槽完之后，效率确实提升了30%。

4.2 任务分解与排期：把大象装进冰箱

任务分解，说白了就是把一个看似不可能完成的大目标，拆成一个个可执行的小任务。我经常跟团队说：「如果你觉得一个任务需要超过3天才能完成，那说明你拆得还不够细。」

为什么会这样？因为人天生对「大任务」有畏难情绪。你想想看，如果告诉你「三个月内完成一款智能手表」，你可能会觉得压力山大。但如果告诉你「今天完成心率传感器的驱动调试」，是不是感觉轻松多了？

我建议用WBS（工作分解结构）来做这件事。举个例子，一个智能门锁的研发任务可以这样拆：

排期的时候，我习惯用关键路径法。先找出哪些任务是「串行」的——比如必须等原理图完成才能开始Layout。这些任务就是关键路径，决定了项目的最短工期。然后，把「并行」的任务塞进去，尽量让资源不闲置。

4.3 每日站会：15分钟解决大问题

每日站会，很多人觉得是形式主义。我刚开始也这么想，直到有一次项目出了大问题——两个工程师在接口定义上各搞各的，直到联调才发现。如果每天站会沟通一下，这个问题早就能发现。

站会的核心就三个问题：

1. 昨天做了什么？——不是让你汇报流水账，而是说「完成了什么可交付的成果」。
2. 今天打算做什么？——明确今天的优先级。
3. 遇到了什么阻碍？——这个最重要。如果有问题卡住了，站会结束后马上拉相关人解决，不要拖。

我建议站会控制在15分钟以内。站着开，别坐着。站着的时候人不容易走神，而且会不自觉地加快语速。嗯，这里要注意，站会不是汇报会，更不是批斗会。如果有人没完成昨天的任务，不要当场追问原因，会后单独聊。

4.4 代码审查机制：别让Bug「潜伏」到量产

代码审查，说白了就是「互相找茬」。很多工程师不喜欢被审查，觉得是对自己能力的质疑。我理解这种感受，但作为项目经理，你必须推动这件事。

为什么会这样？因为人写代码的时候，很容易陷入「思维定势」。自己看自己的代码，怎么看都觉得没问题。但换一个人来看，可能一眼就发现逻辑漏洞。我在项目中遇到过最惨的一次——一个固件工程师写了个死循环，自己测试了三天没发现，结果产线烧录了1000片才发现。那损失，啧啧……

我建议的代码审查流程是这样的：

• 审查时机：每次提交代码前，必须经过至少一个人的审查。不要攒了一堆代码再审查，那样谁也看不进去。
• 审查工具：用Git的Pull Request功能，或者Gerrit、Phabricator这类专业工具。审查记录要留档，方便追溯。
• 审查清单：我习惯列一个简单的清单，审查者逐项检查：
  • 代码风格是否符合规范？
  • 有没有明显的逻辑错误？
  • 边界条件有没有处理？
  • 有没有内存泄漏或资源泄漏？
  • 注释是否清晰？

举个例子，一个简单的嵌入式代码审查：

// 原始代码
void led_toggle(void) {
    static uint8_t state = 0;
    if (state == 0) {
        GPIO_SetBits(LED_PORT, LED_PIN);
        state = 1;
    } else {
        GPIO_ResetBits(LED_PORT, LED_PIN);
        state = 0;
    }
}

// 审查意见
// 1. 静态变量在多任务环境下可能有问题，建议加互斥锁
// 2. 没有考虑GPIO初始化失败的情况
// 3. 建议用位操作代替if-else，提高效率

好了，研发阶段的管控，说到底就是「把过程管好，结果自然好」。敏捷开发让你灵活应对变化，任务分解让你心里有数，每日站会帮你扫清障碍，代码审查让你少走弯路。这四招用好了，研发阶段基本不会出大乱子。

下一章，我们聊聊测试验证阶段——怎么确保你的产品「经得起折腾」。