SE

导言

SE 的主要工作拆解

领域内方案¶

新SE调研：了解基础知识、阅读重点文献、总结规律趋势，大致要一个月。
持续跟踪进展: 每天花1小时

客户需求跟踪¶

客户是商业价值的来源，需要

及时直接参会，时刻倾听客户的声音；
关注客户商业实现、需求变更情况。
评估客户的需求（是否重要优先，团队能不能完成）引导客户信赖我们的技术方案，依赖我们的产品；
实现商业共赢。

方案设计（与MDE区分）¶

作为 SE（系统工程师），关于方案设计的详细程度是一个经典的“管理边界”困惑：

如果 SE 的方案写得像“小学生都能懂”的手册，你不仅会累死，还会把下面的 MDE（模块开发工程师）养成不动脑筋的“翻译机”，导致团队失去技术梯队。但如果写得太虚，开发出的东西货不对板，最后背锅的还是你。

在华为或其他严谨的研发体系中，SE 与 MDE 的“颗粒度边界”通常遵循以下逻辑：

1. 管住边界，放开内部¶

SE 的核心交付物是 LLD（系统级/架构级设计），而不是 Module Design（模块详细设计）。你的方案应该详尽到以下三个“必须”：

必须明确“握手协议”（Interface）： 模块与模块之间、前后端之间、硬件与软件之间的接口定义。这部分必须极其详尽（API 参数、返回码、超时机制），因为这是最容易出问题的“地缝”。
必须明确“核心逻辑与约束”（Core Logic & Constraints）： 比如：性能必须在 200ms 内，必须支持 10k 并发，或者某个关键的状态机（State Machine）转换逻辑。
必须明确“风险点与不确定性”： 告诉 MDE 哪里是坑，哪里是技术盲区。

结论： 你的方案应该是“定调子”。如果把代码逻辑写成伪代码给 MDE，那是越权，也是低效。

2. SE/MDE 职责划分¶

你可以用这个模型（界限模型）来评估你的工作量：

维度	SE (System Engineer) 负责什么	MDE (Module Design) 负责什么
视角	外部视角。模块在系统中扮演什么角色？	内部视角。模块内部代码怎么写最高效？
设计逻辑	业务逻辑映射。比如：从 A 点到 B 点需要经过哪几步。	工程实现逻辑。比如：用什么数据结构？怎么处理异常捕获？
详细程度	黑盒定义。定义输入、输出和关键处理原则。	白盒拆解。拆解成类、函数、变量和具体的处理流程。
关键产出	架构图、时序图（交互）、关键指标、接口文档。	模块详细设计说明书、单元测试用例、代码。

3. 工作太多原因¶

（可能的错位原因）

如果你觉得“要做的工作太多”，通常是因为以下两个原因之一：

MDE 承接能力不足： 你的 MDE 经验不够，或者不敢担责，导致他们反向“压榨”你，要求你把方案写得无比详细（即你说的“小学生水平”）。
边界定义模糊： 团队没有明确的 DoD（Definition of Done），即不知道“方案写到什么程度可以算通过评审”。

4. 实操建议¶

为了把自己从繁琐的细节中抽离出来，建议你采取以下动作：

强化的时序图（Sequence Diagram）： 不要写长篇大论的文字，用标准化的时序图。时序图画清楚了，模块间的逻辑就死不了。剩下的模块内部实现，那是 MDE 的尊严，让他自己去写。
推行“MDE 详细设计评审制”： 你只出概要方案。MDE 必须根据你的方案，反向输出一份“详细设计”。你作为 SE，去评审他的详细设计，而不是替他写详细设计。
- 逻辑： 我告诉你我要盖个 5 层楼，每层要住 4 户（SE 方案）。你来画每一户的马桶位在哪里（MDE 详细设计），画完给我看一眼。
抓大放小（80/20 原则）：
- 80% 的常规模块：只给接口和核心指标。
- 20% 的高风险/新技术模块：你可以写得深一点，甚至深入到逻辑细节。

总结¶

SE 的价值不是“写得细”，而是“定得准”。

如果你把所有逻辑都写透了，你其实是在做 MDE 的工作，而你的 SE 核心价值——技术前瞻性、系统冗余设计、全局风险控制——反而会被忽视。

文档交付件？¶

SE不写详细设计文档后，交付件的文档要写什么？

工作量估计¶

客户总是想要你承诺这个事情的交付时间点，但是如果作为SE不了解方案设计细节的话，很难给出合理的工作量预估。经常导致自己估计小了工作量，导致自己团队加班。

该怎么应付客户？以及这个工作量估计要交给谁来做？如果SE可以把详细设计交给MDE，那工作量的时间分析也交给MDE吗？

这是一个非常经典且具有普遍性的痛点：SE 成了“三明治”中间那一层。 客户向上压时间，MDE（模块开发）向下要细节，SE 卡在中间，既怕估少了坑了兄弟，又怕不给时间客户不答应。

要解决这个问题，你需要建立一套“从宏观到微观”的估算防御体系。

1. 分工¶

结论是：SE 做“粗估（Top-down）”，MDE 做“细估（Bottom-up）”。

SE 的责任（宏观）： 根据历史项目经验、方案复杂维度，给出一个区间范围。例如：“基于以往经验，这类接口对接通常需要 3-4 周。”
MDE 的责任（微观）： 当你把方案交接给 MDE 后，他必须给出颗粒度到“人/天”的分析。
- 如果你把详细设计交给了 MDE，那么工作量的时间分析也必须交给 MDE。
- 逻辑很简单： 谁的孩子谁抱走，谁的代码谁估时。如果 SE 替 MDE 估了时间，MDE 以后会说：“这是你估的，我做不完很正常。”

2. 应对客户策略¶

面对客户催促交付时间点，SE 应该学会用专业的话术来降低风险: 不要给“死日期”，要给“置信度”

A. “不确定性锥形（Cone of Uncertainty）”¶

在方案初期，由于细节不明，估算的误差可能高达 4 倍。

话术： “目前处于需求分析阶段，基于现有颗粒度，初步评估在 X 月到 Y 月之间。随着下周详细设计评审完成，我会给出一个偏差不超过 10% 的确定日期。”
功能版本 3 ~ 6周，

B. 条件对等法（Conditional Commitment）¶

永远不要只给一个日期，要给“日期 + 前提条件”。

话术： “如果需求范围仅限于方案中的 A/B/C 三项，且环境联调能在下周一就绪，那么我们可以在 X 日交付。”
价值： 客户如果改需求或推迟联调，你之前的承诺自动作废。

C. “三点估算法”（PERT）¶

如果你一定要给一个数字，请在脑子里（或者MDE的反馈里）计算：

\(最乐观时间 (Optimistic)\)
\(最可能时间 (Most Likely)\)
\(最悲观时间 (Pessimistic)\)
公式：\(期望时间 = \frac{O + 4M + P}{6}\)
建议： 永远对客户报 “最悲观时间”，对自己团队留 “管理缓冲（Buffer）”。

3. 合理估算¶

“不了解细节”时做出合理估算？

你不需要知道每一行代码怎么写，但你需要通过 “WBS（工作分解结构）” 快速拆解：

拆功能点： 哪怕没细设计，你也知道要加几个接口、改几个数据库表、做几个 UI 页面。
对标历史： “这个功能和去年做的 XX 功能类似，当时花了多久？”
识别“技术债”与“风险项”： 问 MDE 一个问题：“这个方案里你最没底的是哪块？” 给那块加上 50%-100% 的风险系数。

预估表¶

研发项目计划与工作量评估表(含周换算，1周 = 5个工作日)

阶段	细节事项	负责人	预估时间 (天/周)	累计(最快)	累计(最慢)	是否可并行
1. 需求介入	初步接触客户 & 给出粗估区间	SE	0.5天 (~0.1周)	0.1周	0.1周	否
2. 技术预研	方案调研（不涉及实验）	SE/MDE	1天 (0.2周)	0.3周	0.3周	否
3. 方案交底	SE架构交底，MDE反馈排期	SE/MDE	1-2天 (0.2-0.4周)	0.5周	0.7周	否
4. 内部评审	方案评审及修改（排期审计）	SE	2天 (0.4周)	0.9周	1.1周	否
5. 承诺对齐	Milestone：输出交付计划	SE	0.5天 (0.1周)	1.0周	1.2周	否
6.1 开发准备	模型、数据下载准备	MDE/开发	1天 (0.2周)	1.2周	1.4周	否
6.2 方案选型	可选方案尝试（每个方案半天）	MDE/开发	1天 (0.2周)	1.4周	1.6周	是
6.3 基线跑通	环境配置与Bug解决	开发/外包	2-10天 (0.4-2周)	1.8周	3.6周	否
6.4 逻辑梳理	原仓代码结构/引用跳转梳理	MDE/开发	1-2天 (0.2-0.4周)	2.0周	4.0周	否
6.5 环境准备	目标平台环境搭建	开发/外包	0.5-1天 (0.1-0.2周)	2.0周*	4.0周*	是 (与6.4并行)
6.6 熟悉过程	目标平台逻辑熟悉（针对新手）	开发/外包	1-2天 (0.2-0.4周)	2.2周	4.4周	否
6.7 功能迁移	Milestone：功能打通版本	MDE/开发	1-10天 (0.2-2周)	2.4周	6.4周	是 (包含6.7.x)
└ 6.7.1 软件设计	代码逻辑设计 (子项)	SE/MDE/开发	1-5天 (0.2-1周)	-	-	包含在6.7内
└ 6.7.2 简单实现	Config 硬 Save 实现 (子项)	开发/外包	0-2天 (0-0.4周)	-	-	包含在6.7内
└ 6.7.3 完整逻辑	Config 传递逻辑梳理 (子项)	开发/外包	1天 (0.2周)	-	-	包含在6.7内
6.8 定制开发	客户定制模型集成与调测	MDE/开发	5-10天 (1.0-2.0周)	3.4周	8.4周	是
6.9 精度对齐	精度验证与分阶段对比	MDE/开发	2.5-15天 (0.5-3.0周)	4.4周**	11.4周**	是
6.10 性能优化	热点分析与优化 (并行项)	MDE/开发	5天 (1.0周)	4.4周**	11.4周**	是 (与6.9并行)
7. 代码合入	代码规范整理与合入版本	MDE/开发	2.5天 (0.5周)	4.9周	11.9周	否
8. 测试看护	自动化用例编写与测试	MDE/开发	2.5天 (0.5周)	5.4周	12.4周	是
9. 交付转测	转测及问题单处理	全员	2.5天 (0.5周)	5.9周	12.9周	是

注：
6.9 与 6.10 默认为并行工作，累计时间取最长者。
关于 6.3 基线跑通：这个环节最容易出意外。如果原仓代码在目标平台有严重的兼容性问题，1.2 周可能都不够。建议在这个节点设置一个“方案再评估”点。
以上估计很理想，没考虑下面情况：
机器被挤占(折扣系数 70%): 无机器使用空窗+数据迁移+环境搭建时间。
人员空缺：请假；
没有全身心投入(非全投入折扣 50%): 有其余工作并行，工作上下文切换导致开销更大。
沟通管理时间(折扣系数 80%-): 对齐信息、开例会。

里程碑¶

T+1.0周： 确定合同/承诺日期。
T+2.4~6.4周： 拿到第一个可以跑通功能的版本。
- 最快路径（方案简单、基线能跑）：约 2 周。
- 最慢路径（方案不明、基线bug多、遇到复杂重构）：约 6 周。
T+5.9~12.9周： 最终交付转测。
- 最快路径（一切顺利且并行度高）：约 6 周。
- 最慢路径（遇到复杂重构与精度坑）：约 13 周。

风险把控¶

基线跑通（6.3）的波动： 这里的预估从 2 天到 10 天，波动极大。如果基线在 1 周内跑不通，建议 SE 立即介入检查是否需要更换开源仓或修改技术路线。
精度对齐（6.9）的“长尾效应”： 这是项目中最难量化的部分。建议您在 6.7 功能打通后，立刻要求 MDE 输出一份中间值对比计划，以防精度问题拖到第 12 周才爆发。

草稿表

把下面工作项整理成markdown可复制表格，表头包含，阶段、细节、负责人、预估时间、预估累计时间(最快)，预估累计时间(最慢)，是否可以并行人力加速：

初步接触客户： SE 给出粗估区间（基于历史），并明确告知客户“待详细方案评审后刷新”。
(SE/MDE)方案调研（只是了解有什么方案，不用尝试， 1天）
方案交接： SE 将架构方案交底给 MDE，MDE 在 1-2 天内反馈详细排期。
内部对齐： 方案评审及修改时间: 审核 MDE 的排期是否合理（有没有偷懒或过于乐观）（2 天）
正式承诺： SE 向客户输出最终交付计划。Milestone
(MDE/开发/外包)软件开发(包括功能打通、精度对齐、性能优化)
从头开发（一般是写算法、论文的人为主）
已有方案迁移/近似拓展（开源仓，开源算法代码）
1. 模型、数据下载准备(1天)
2. 可选方案尝试和选型（软件架构设计）：看能不能跑通原仓/已有方案，遇到bug为止（每个方案1天）能并行
3. 基线原仓跑通(由平台兼容性/bug数量决定，配置环境1天，解决1_{3个bug一天，0}1周)
4. 原仓代码逻辑梳理(一般由对象结构复杂度决定，引用跳转数量决定，一般1~2天解决)
5. 目标平台环境搭建(0.5-1天)
6. 目标平台逻辑梳理(如果是新手，需要熟悉1-2天)
7. 代码迁移(功能打通，Milestone：出功能版本)
  1. 非复制迁移(如果是继承拓展，需要1-2天；范围重构 0.5~2周)
  2. config 硬save实现（由对象结构复杂度和代码量决定，1-2天）
  3. config 传递逻辑梳理（1天）
8. 客户定制模型：环境搭建、集成迁移和调测（1周~2周）
9. 精度对齐(0.5~3周)
10. 性能优化(1周)
(MDE/开发/外包)代码整理合入版本(0.5周)
(MDE/开发/外包)增加测试样例看护(0.5周)
(MDE/开发/外包)转测以及问题单处理(0.5周)

能否并行(取决于工作粒度能不能再拆分)：

功能打通并行（这取决于，打通的功能能不能被拆分为细粒度）
精度对齐和性能优化并行 (在大功能验证接入正常后，精度问题往往是些细节没对齐，性能可以并行优化; 这样大粒度并行)
1. 精度对齐并行：如果精度对齐很紧急，也是可以并行的，把前向拆分多部分，save/load中间值来分阶段对比；
2. 性能优化并行：性能开箱后的热点，拆分给不同的人负责。