工作步入第八年，越来越发现工程能力的重要性。
工程能力是一种持续稳定提供软件产出的能力。有别于高校单枪匹马挑战课程大作业的能力，它需要频繁团队协作；也不是单枪匹马解决算法难题的能力，它需要不断维护迭代。技术能力当然很重要，计算机科学基础知识、编程语言熟练程度、中间件快速应用、系统性能调优等等，这些是工程师岗位的敲门砖，也是迈向新台阶的核心能力。但只追求技术能力忽略工程能力，仍然没法保证研发团队的高效产出。
而这，也成为了我转正述职的子主题。
述职也是一种分享
在上一次开发者大赛后我就再没做过正式的分享了，借这次述职机会，也是对个人工作经历与经验的一次总结。
认真对待分享也是一种优秀的工程能力体现，分享出去的内容首先会是对自己认知的一次梳理，产生观点碰撞，收获新的反馈，建立影响力，实在是再好不过的机会。
这次时间较为匆忙，没有办法准备逐字稿。就先草拟了一份 Markdown 工作履历，突出工作完成情况与价值贡献。借助大模型润色，得到一份更有结构性的 Markdown 文档。再导入到 Gamma 这样的 PPT 生成工具形成演示稿，使用 Napkin 对图画效果做调整。几次修改，一份演示稿就大致完成了。
对于演示稿，我的一贯做法是使用尽量少的文字，尽量简洁的图画，一页一个主题，层层剥开，彰显工程师专业能力与表达能力。并不会就纠结于某个动画效果，就像技术书籍一样，内容远大于形式。每页控制在 2~3 分钟，多练多表达就会有质变。
既然是分享，就要有可以交流的内容，工作汇报写成了设计编码测试这些，泯然众人矣，何谈提前转正呢？表达能力就是认知能力的外化，讲不出来一定是没有认识到执行到。
比如对于遗留系统承接，讲熟悉代码调试线上问题就成了日常工作日志，提炼出业务模型抽象->代码可维护性提升->性能优化与产品体验升级的研发改进策略三部曲就有了一个技术负责人的视野，然后再举例疑难问题处理，有技术实力有职业精神的工程师形象就树立起来了。
再比如对于开发效率提升，讲技术难点项目攻坚就成了项目回忆录，结合软件设计方法就会更有感染力，加速知识传递与应用以及 AI 辅助下的 TDD 循环，提供一些数据支撑这样做的效果比对，彰显项目把控能力之外，还可以体现快速学习快速推进的能力。
评审问题与我的解法
研发提测前会有哪些动作？
研发与测试同学在研发流程中对接频繁的部分也是经常会出问题的一块，我理解更多是想了解研发提测标准。
按照既往经验，提测标准需要研发负责人和测试负责人共同制定，产品迭代从研发角色递进到测试角色，只其中依然是软件知识的流动。研发提供可执行软件知识，测试消费。
如果从整个研发流程来看，知识的大部分传递应该是在需求传递时完成的。但在很多项目紧急时无法兼顾，就会有很多发生在测试阶段，好的做法当然是提前加速知识循环。比如对需求做评审，对开发成果物做冒烟测试。
如果从岗位职责划分来看，研发提供自测用例是最方便的，以开发和测试都可以看懂的方式证明开发是满足条件可以达到进入测试阶段的。提供用例就可以自动化，AI 又可以加速自动化，用例又可以加速开发进度，当然前提是基础设施能跟得上。
如果从产品成熟度来看，遗留系统大多需要花费不少精力搭建测试框架并验证功能可用性，紧急时还是会按照历史方法测试；新建系统没有太多历史包袱可以将可测试性和可观察性作为系统架构的一部分并投入精力完善，单元测试构建就会容易得多，测试用例也更容易构建并传递给测试。
但不管怎么样，涉及多角色多部门合作的，优秀的工程能力需要提供有质量的可传递的知识，测试用例、部署说明、核心流程等都是好的辅助说明方法。消解知识壁垒，加速知识循环。
测试提出超出产品需求的问题如何处理？
这是一个关于产品精益的问题，我理解优秀产品背后是需要一个共同所有产品的团队，也就是产品经理不对产品唯一负责，每个角色（当然包括测试）都有义务打磨更好体验的产品。
测试作为产品质量保障，对产品使用细节明察秋毫，肯定会发现很多设计有改进、体验有提升的地方，超出产品需求范围，可以拉着产品研发一同商讨需求合理性。
对于研发而言，产品也不是需求的唯一来源，以良好的产品体验为目标而不是以需求为目标就会更理性看待测试提出的各项改进意见。
什么样的需求文档是符合上述要求的？
看样子是项目负责人对我讲的知识循环过程产生了浓厚兴趣，产品和测试作为研发的上下游关系是有不同的，按我理解这是关于研发期望的需求传递形态和方式的问题。
这不是一个需求传递问题而是一个工程问题，不同的产品/项目发展阶段、团队工作饱和度、成员认知差异都会有所不同。尤其是最后一点，经验丰富常年磨合同一块业务的团队就不需要详细的需求用例，往往产品描述的几句话，就能根据产品或者项目情况补充出完整的上下文。工程没有普适解，只有根据各种条件求平衡。
那对于新加入项目组的研发同学怎么办呢，还是加速知识循环，借助业务案例反复训练、演示环境反复演练、不断求教产品经理学习业务知识。不理解隐藏的业务上下文就写不出可靠的代码，不理解需求设计的用意也没法推理出代码逻辑。
如果有一种形式的需求文档，可以转换成需求用例，那就是 Given-When-Then 形式的：假设在什么背景下，谁发生了什么操作，就会在系统上产生什么效果，最后贡献了什么价值。
迈过入职甜点位
我在演示文稿最后给出了九个关键字，上强度、提效率、促协同。上强度是加快工作节奏，尽快熟悉业务知识与技术要求，匹配后续常态化工作强度。提效率是借助 AI 工具将研发效能提速，知识传递与消费循环变快，体现工程师价值的立足之本。促协同是将个人能力辐射到团队中，形成协同效应。
入职四个多月，应该是迈过新公司甜点位的时候了。对于公司、岗位、角色、任务的新鲜感过去，接触到更多阳光之下的问题并找到解决方法，于是有了自己的定位。迈过甜点位是企业与个人充分磨合，也就顺理成章是正式入职的起点。
