第1章项目启动与需求分析

1. 项目启动与需求分析：理解SOC算法项目背景、干系人识别、需求收集方法、需求优先级排序

大家好，我是你们的老朋友。今天咱们聊聊SOC算法项目的第一步——启动与需求分析。说实话，这一步做不好，后面全是坑。我在芯片行业摸爬滚打十几年，见过太多项目因为需求没理清，最后算法推倒重来，甚至流片回来发现功能对不上。嗯，今天就把我的经验掰开揉碎了讲给你听。

先说说项目背景。你想想看，一个SOC算法项目，它从来不是凭空冒出来的。它一定是为了解决某个具体问题——比如让摄像头在暗光下也能清晰成像，或者让语音助手在嘈杂环境中准确识别你的指令。

我个人习惯，拿到项目第一件事不是看代码，而是搞清楚三个问题：

我在项目中遇到过一件事：有个团队花了三个月优化一个图像降噪算法，结果发现客户真正需要的是低功耗模式下的实时处理，而不是极致画质。说白了，方向错了，努力白费。

核心要点：项目背景分析要回答"为什么做"和"为谁做"，而不是"怎么做"。这是所有后续工作的基石。

干系人识别，说白了就是搞清楚谁说了算、谁有意见、谁要用你的东西。别小看这一步，我曾经因为漏掉一个关键干系人，导致算法接口改了四版。

一个典型的SOC算法项目，干系人通常包括：

我的经验：干系人识别不是一次性的。项目推进过程中，新角色会不断出现。我建议在项目启动时画一张干系人地图，每周更新一次。别嫌麻烦，这能省掉你后面80%的沟通成本。

需求收集，这是最考验功力的环节。你想想看，客户说"我要一个低功耗的AI加速器"，这句话背后藏着多少信息？

用户故事是我最喜欢用的工具。它不啰嗦，直击要害。格式很简单：

作为 <角色>，
我想要 <功能>，
以便 <价值>。

举个例子，一个语音唤醒算法的用户故事：

作为 手机用户，
我想要 在嘈杂环境中也能唤醒语音助手，
以便 开车时不用分心操作手机。

你看，这样写出来，算法团队就知道：哦，重点是"嘈杂环境"和"低延迟唤醒"。而不是"我要一个语音算法"这种模糊需求。

我在项目中遇到过，有人把用户故事写成技术方案——"我要一个基于CNN的语音分类器"。这其实已经跳过了需求阶段，直接进入设计了。记住，用户故事只描述"要什么"，不描述"怎么做"。

用例图是UML里最实用的工具之一。它帮你把系统边界、参与者、功能点画得清清楚楚。

一个SOC算法项目的用例图，通常包含：

举个例子，一个图像处理SOC的用例图可能包含：

参与者：摄像头传感器、显示控制器、用户应用程序

用例：
  - 采集原始图像数据
  - 执行去马赛克算法
  - 执行白平衡校正
  - 输出YUV格式数据
  - 配置算法参数
  - 上报处理状态

画用例图有个小技巧：别贪多。一张图控制在8-12个用例，多了就拆成子图。否则画出来没人看得懂。

避坑指南：我曾经见过一个团队，用例图画了50多个节点，最后连自己都理不清。记住，用例图是沟通工具，不是艺术品。够用就好。

需求收集完了，问题来了——资源有限，先做哪个？这时候MoSCoW法则就派上用场了。

MoSCoW是四个单词的缩写：

我个人习惯，在项目启动会上，拉着所有干系人一起过一遍需求列表，每人发三个红点、三个黄点、三个绿点。红点代表Must have，黄点代表Should have，绿点代表Could have。然后统计投票结果，争议大的需求重点讨论。

你可能会问：那Won't have怎么定？其实很简单，没被选上的自然就是Won't have。但要注意，Won't have不代表永远不做，只是这个版本不做。我建议在文档里注明"计划在V2.0中考虑"，给客户一个交代。

我的经验：MoSCoW排序最怕的是"全都是Must have"。如果出现这种情况，说明需求还没真正理清。我会让产品经理给每个Must have需求打分——"没有这个功能，客户会退货吗？"如果答案是"不会"，那它就不该是Must have。

好了，今天的内容就到这里。项目启动与需求分析，说白了就是搞清楚三件事：背景是什么、谁说了算、要做什么。别急着写代码，先把这些理清楚。我见过太多项目，需求分析只花了一周，后面调试花了三个月。嗯，你想想看，哪个更划算？

下一章咱们聊聊算法选型与可行性分析，到时候我会分享一些具体的评估方法和踩坑经历。咱们下次见。