为了保质保量、提升开发效率、良好的团队协作，我总结了一套个人工作SOP，能更好的适应互联网职场环境 有一个自己的工作标准流程，就能保证在繁杂压力下做到有条不紊、从从容容
分为技术设计、排期、开发、联调、自测、提测、Bug跟测、发布
一、技术设计
产品角度
- 如果是B端，产品是否漏考虑C端也需要修改
- 确认开发范围
- 例如经常有新老版本，老版本不维护，只维护新版本，因此要跟产品确认好
- PRD有疑问，通过列个文档记录下来，或者直接在prd进行评论，约会议或者直接让产品在文档一一解答，通过群聊太散，效率低下
- 当需求比较模糊时，提出a、b、c理解让产品选，注意沟通，不要质问、要求等让人不舒服的语气
- 明白权力结构，不要直接硬钢，有冲突可以先找自己的领导协调
- 觉得不可能实现之前先穷尽所有办法，包括跟领导沟通，再跟产品沟通，否则产品找组长，组长又说能做，显得很不专业，尽可能多查查，谷歌、gpt，因为自己并不拥有全部知识，所以不代表就不可能实现
后端角度
- 是否限制文件大小
- 如果文件太大，是否需要配置超时时间
测试角度
技术需求当影响面较广时，可以采取分批上的原则，降低影响面
开发角度
如果用三方库，先在本地做个demo
技术设计模版
可以通过以下七个大点来进行参考，发给测试进行同步，如果需求太大可以拉会
- 背景，通常是prd、接口文档等
- 前端需求整理，这个可以方便ai更精准的开发，减少返工，如果已经实现harness模式能让ai自己分析需求，则可以忽略，此模块建议通过另一个文档来梳理
- 与prd有出入的需求梳理，通常会有一些疑义需要产品解释或者需求改动，可以在设计阶段就跟产品确认好，写在文档上，可以方便测试进行查阅，避免后期提bug造成误判
- 技术设计，通常是一些有技术难度的地方
- 接口设计，如果有bff层，可以列出来
- 估时
- 面向测试影响面
二、排期SOP
- 按照半天为单位估时
- 凡是没做过，都有可能卡时间
- 如果后端估时不合理，影响自己，及时提醒
- 如果跟某个后端没合作过，先多估点，该后端有可能bug较多，影响自己
- 如果是复制或者重构原来的代码，先把原来的逻辑梳理清楚
- 如果自己有同时多个需求，在定联调、提测时，需要多留时间
- 如果发现自己超过10pd可能降低开发质量，要多估
- 涉及到不熟悉的api，需要多估，因为有学习时间
本月人力
为了更好的多任务排期管理，建议建一个本月人力文档，分为多任务需求记录和月排期
| 需求 | 进度 | 卡 | 备注 |
|---|---|---|---|
| 上传迁移 | 待测试 | 测试下个礼拜介入 | - |
这样做以后，即便是自己手头有10个需求同时跟进，一点都不慌
三、开发SOP
- 以PRD文本为准，视觉稿样式为辅
- 每一行代码需要明白为什么，防止有坑
- 新增/修改的每一行代码是否有不可抗力的理由（最小化修改原则）
- 每次提交之前务务必先自我review一遍
- 别人的帮写代码注意全面测试，不可认为是不需要改的代码
- 用不太成熟的三方组件或者别人的组件多测测，容易有坑
四、联调SOP
- 注意看表格的每个item是否正常展示
- url是否正确
- 传参是否正确
- 参数变更，需再重新自测一遍相关逻辑
- 多场景测试，测试联动模块
五、自测SOP
这部分是重中之重，关系到你的开发质量，因此单独放一篇文章：juejin.cn/post/763121…
六、Bug 跟测 SOP
- 仔细阅读tapd的文字内容，有可能一个bug包含多个错误信息
- 复现 没复现挂起，等之后复现再改
- 修改范围（举一反三）
- 需要考虑是否其他类似的场景没改全
- 例如有个校验bug，需要检查其他所有表单项的校验
- 例如有个弹窗样式，需要检查所有弹窗的样式
- 例如某个文字跟设计稿不对，需要检查一遍所有文字跟设计稿是否对得上
- 需要填写原因、反思
- 逻辑bug需要列相关逻辑自测case，避免出现重新打开
- 本地自测通过、测试环境自我验证再流转给测试
