System Enginner系统工程师成长思考

在软件人员职业发展过程，从模块开发人员，到模块责任人，然后就会面临两条路：
一条 是 偏技术路线，往System Enginner系统工程师发展，从项目层级 到 产品线曾经 到 商业部门层级。
一条 是 偏管理路线，往Project Manager项目经理发展，从项目层级 到 产品线曾经 到 商业部门层级。
各个公司的实际运作情况 或者 叫法都有所差异，当前是总结自己所在情况，做阶段性总结，方面后续打磨成长。

一、System Enginner岗位概述与理解

1. 一句话描述工作—做技术决策，选择走什么路

如果只用一个词描述系统工程师的工作，就是决策。拆分开 就是从 需求收集管理决策要做什么，从竞争力与实现维度决策怎么做，从关键问题维度决策分析路径。根据项目复杂度，有的项目需要多名系统工程师，分别管理 整体架构、功能领域、关键特性、或 维护问题解决，复杂度低的项目也可以由一个人完成。

2. 岗位职责—需求竞争力分析/设计过程管理/设计团队领导/关键问题分析

1）项目要做什么？----需求与竞争力分析
做任何产品都要围绕商业成功为目标，从研发角度就是要推出一个具有竞争力的产品。这里面包含两个重要的方面：
a. 需求分析。充分理解产品市场定位与客户需求，管理好需求与其价值评估，无遗漏的落地产品，在没有明显短板的产品 才能聊竞争力。
b. 竞争力分析。时刻清楚产品核心竞争力，持续做技术规划和挖掘，要看清楚未来1~2年上市产品方向（成本、关键指标、差异化功能）。
2）项目技术上要怎么做？----管理全设计生命周期
管理设计生命周期的目的是为了让需求符合预期的落地。每个公司都有自己的一套项目管理流程 和 相关过程设计文件标准，来管理项目的设计生命周期，这些设计管理最关键的责任人就是系统工程师。常见涉及 需求分解管理、测试策略分析、系统设计、关键特性设计、模块方案设计、测试用例表单，需要团队人员协同完成。
3）项目如何协同团队落地？----领导设计技术团队
项目一定是依赖团队而不是个人完成。系统工程师需要领导好技术团队保障项目实施，包括 引导团队技术方向，引入合适的设计工具与方法，明确模块划分，解决内部技术争议，总结技术经验 与 推动知识分享。
4）项目关键问题怎么解决？----DFX设计与思路判断
方案交付过程 必然会存在各种技术问题，问题解决是保证项目计划节点达成关键要素。这里包含两方面：a. 前期DFX设计（可测试性、可维护性、可扩展性等），狭义讲就是提前把问题界定和定位手段落地到各个模块，并持续推动优化。b.关键问题分析，难界定&影响关键节点的问题（特备是跨系统&兼容性&低概率类型），系统工程师需要作为攻关关键角色，管理问题分析思路和收敛节奏。

3. 岗位导向—技术与商业并重，关注综合能力，持续提升影响力

1）有产品思维&关注商业导向。不唯技术论，持续深入对行业和产品的理解，主动去和客户交流获取行业认知，通过竞争力的产品 牵引客户，最终达成技术和商业成功目标。
2）有技术追求&有全局思维。有探索欲望，持续打磨自己交付相关技术能力，做需求和问题判断有全局思维，决策果断。
3）注重沟通表达&能抗压。能把事情讲清楚说明白，有抗压能力敢于讲真话，敢于挑战权威，给团队传递信心。
4) 有一定项目管理能力。为了保证从团队落地设计目标和计划，没有项目管理相关意识和知识是不行的，你要清楚各个人员的定位，技术团队和外部团队配合界面，运作配合逻辑，这些是必须的。

4. 岗位关键能力—技术规划、软件实现实施、架构设计、技术团队管理

总结一下系统工程师的关键能力，如下。
1）技术规划。 掌握需求分析与技术规划方法，从 技术趋势、市场、客户、竞争对手等方面持续做好产品的技术规划，周期性刷新和论证纠偏。没有谁能做对每个决策，但我们要持续磨练自己技术规划能力，选对技术方向是系统工程师的核心。
2）软件实现实施。 要掌握需求分析，需求变更，方案设计、工作量评估、代码开发调试、测试能力。系统工程师都是从优秀的模块开发人员成长过来的，只有这样我们才能指导好技术开发过程，处理好技术冲突，关键时刻能顶得上。
3）架构设计。 熟悉软件架构设计和方法论，熟练运用软件4+1视图，论证和描述自己的架构设计。注意 始终围绕两点，能给团队其他人讲清楚，能支持论证架构可行性，不要为了描述而描述。
4）技术团队管理。 优秀的系统工程师要引导技术团队共同成长，才能发挥团队的价值，通过团队去成功，而不是依靠个人成功。你需要 提升沟通协调的能力，做好技术赋能，培养骨干人员，解决技术冲突，做好团队知识管理。

二、System Enginner常见面临问题与个人思考

1. 工作定位不清晰，杂事缠身----新领域先趟泥 再持续找界面

某种意义上对项目结果负责的在团队内部 第一是项目经理，第二是 系统工程师。两者要形成配合关系，前者重点在项目计划与资源管控，后者在 技术判断。因此实际运作过程，凡是和技术决策相关，无论是需求收集评估、方案设计讨论、技术冲突协调、问题界定攻关，都可以和系统工程师相关，并且做到什么程度界面很模糊。特别是系统工程师往往都是从模块开发人员成长起来，也存在一定执行相关的思维惯性。经常性疲于版本交付和节点达成，没有精力做好技术规划、技术管理、团队成长。
个人思考：进入新领域先趟一趟泥是必要的，总是高高在上 只想收割不想担责 一定无法在团队建立影响力，最终你各种竞争力规划会难以落地。要弄清楚相关领域真实运作情况，困难在哪里？利益在哪里？在配合过程 持续细化这个界面，抓关键控制点，最终通过策略模板化+传递能力 来释放自己的工作。

3. 产品流程复杂，文档冗余----围绕业务实质多思考

每个公司都有一套自己的项目管理流程，包括关键交付件要求和各种节点评审。这套规则不是为了某一个产品，而是普遍性产品覆盖规则。因此经常出现 很多看上去和你所在产品完全不需要的流程和交付件细节，并且呈现越来越复杂的趋势。背后逻辑很好理解，从公司层面希望项目成功 脱离对特定能力人强耦合，转为通过通用流程去保证，自然会出现持续熵增。但是落到一个项目中，人力成本基本无法达成匹配关系，有些类似软件领域 没有银弹的概念。如果按照通用方式去做，你的人力成本和项目周期根本不可能同友商PK。
个人思考：做事情要围绕业务实质，弄清楚哪些是 关键、重要，哪些是流程性的可灰度的，哪些是红线不要轻易挑战。先弄清楚大家怎么玩的，再围绕项目成功为目标多思考，必要时要敢于突破。

2. 绩效难以量化，如何判断做得好坏？---- 以影响力为标准

系统工程师的产出相对难以量化。如果是模块开发人员 可以 开发了多少需求、出来多少设计文档、多少量级的代码、出了多少问题为主。维护人员用处理了多少问题。项目经理用项目计划达成情判断。但是系统工程师最终要的是 收集准确需求 纠正错误需求信息，管控好技术架构不要腐化，做好技术管理 和 关键问题支撑，很难直白的说 这个项目成功你在里面起了多大的作用。
个人思考：通常情况 项目是以项目商业成功为评价导向，我个人建议是围绕影响力来判断，需求和方案讨论你能否说服客户？竞争力能不能在推动落地？技术冲突时你能否搞定？关键问题大家是否相信你的判断方向？ 这些都是在平时每次需求方案讨论、问题分析与结果验证 过程积累的口碑。如果你能搞定客户，搞定团队人员，大家信任你相信你，愿意按你的决策执行，项目成功了，你就一定是一个优秀系统工程师。