外包驻场开发如何做好需求沟通、任务管理和工作复盘前言作为一名外包驻场开发平时经常会遇到这种情况甲方安排的任务比较零散一会修改接口一会查数据一会处理配置同时对接多个不同的人有些需求只是口头说明没有完整文档当时感觉自己听懂了真正开始做时又发现有些细节不清楚再次去询问时对方可能会觉得已经说过了从而产生不耐烦。我自己也遇到过类似问题。后来我发现很多时候并不是技术能力不够而是缺少一套固定的工作流程。如果没有做好需求记录、需求确认、任务拆分和完成后的检查即使每天很忙也容易出现遗漏、返工和重复询问。下面整理一套适合外包驻场开发人员使用的日常工作流程。一、外包驻场开发容易遇到的问题1. 工作内容比较零散外包驻场的工作不一定都是完整项目有时可能是修改一个接口字段查询一条异常数据调整一项配置帮其他同事部署项目配合前端联调修改数据库脚本处理测试环境问题临时排查线上日志。这些任务看起来都不大但数量一多就很容易混乱。如果全部靠脑子记很可能出现忘记任务搞错优先级做了一半被其他任务打断忘记向需求方反馈结果。2. 需求没有一次理解完整有些需求是别人站在旁边口头说的。当时可能觉得自己已经听懂了但真正写代码时才发现原来的接口要不要保留历史数据要不要处理新增字段是否允许为空哪些模块会受到影响最终由谁验收什么时候必须完成。如果这些问题没有提前确认后面就会反复询问。询问本身没有问题但如果同一个问题问了多次或者每隔一会问一次对方就可能觉得沟通成本很高。3. 只记录了任务名称没有记录细节例如只记录修改订单接口过几个小时再看时可能已经不知道具体要修改什么。更完整的记录应该是任务修改订单详情接口 需求人张三 需求内容增加付款时间字段 注意事项原来的字段不能删除 完成时间今天下午5点 验收人张三记录不是为了写得好看而是为了避免自己忘记。4. 完成后没有认真检查一些问题不是不会写而是提交前没有检查例如代码文件遗漏数据库脚本没有提交配置文件被误修改target目录被提交测试环境配置提交到了代码仓库只测试了正常场景没有测试异常场景修改公共方法后没有检查其他调用位置。这些问题重复出现后会影响别人对自己的信任。二、接收需求时应该怎么做1. 先听完不要急着回答当别人安排任务时不要对方刚说一句就马上回答好的明白了。因为有时候只是听懂了大概并没有真正理解细节。可以先说好的你先说我记录一下。然后把对方说的关键信息记下来。2. 重点记录七个内容每次接收需求时至少确认以下内容谁提出的需求具体要做什么为什么要做涉及哪些系统或模块哪些内容不能修改什么时候完成最终由谁验收。可以使用下面的模板## 任务名称 - 提出人 - 提出时间 - 具体需求 - 需求目的 - 涉及模块 - 注意事项 - 完成时间 - 验收人员 - 当前状态3. 对方说完后立即复述需求沟通结束后不要只说我知道了。最好把自己的理解重新说一遍。例如我确认一下这次是修改订单详情接口 增加付款时间字段旧字段继续保留 改完后先部署到测试环境 今天下午5点之前发给你验收对吗复述的好处是可以及时发现双方理解不一致减少后面重复询问防止写完后大面积返工给需求方留下认真负责的印象。三、遇到不懂的需求应该怎么问1. 不要想到一个问题就问一次比较容易让对方不耐烦的提问方式是这个字段要不要加过一会又问历史数据要不要处理再过一会又问旧接口还要不要保留这样会不断打断对方。更好的做法是先自己分析几分钟把问题统一整理出来。例如我整理后还有三个地方需要确认 1. 原来的接口是否继续保留 2. 历史数据是否需要补充新字段 3. 完成后由前端验收还是由你验收。一次集中问清楚比反复询问效果更好。2. 提问时带上自己的理解不要只问这个应该怎么做可以改成我看了一下原来的代码目前有两个方案。 方案一是在原接口上增加字段对前端改动比较小 方案二是重新增加一个接口影响范围更小。 我倾向使用方案一你看这样处理是否合适这样对方会感觉你已经做过思考只是在确认方案而不是把问题全部推给他。3. 同一个问题问完后立即记录对方给出答案后要立刻记录下来。例如确认结果 旧接口继续保留 历史数据不处理 新数据从本次上线后开始记录。不要只听完点头否则过一段时间还是可能忘记。四、开始开发前需要做什么1. 不要拿到需求就立即改代码正式修改前先检查这是公共方法还是私有方法是否被其他模块调用是否涉及数据库字段是否会影响旧接口是否需要兼容历史数据是否需要前端同步修改是否需要增加日志是否需要处理异常情况。尤其是修改公共方法时不能只看当前功能。2. 使用IDE查看影响范围在Java项目中可以通过IDE的“查找引用”功能检查哪些地方调用了这个方法哪些接口使用了这个对象哪些模块依赖了这个字段修改返回值后会影响哪些代码。例如在 IntelliJ IDEA 中可以使用Alt F7查看方法或字段的引用位置。在修改旧代码前先搞清楚这个方法是做什么的 谁在调用它 修改以后会影响谁 有没有更安全的扩展方式3. 把任务拆成小步骤例如修改一个接口可以拆分成1. 阅读需求 2. 查找相关接口 3. 查找业务实现类 4. 确认数据库字段 5. 分析调用范围 6. 编写代码 7. 本地测试 8. 检查日志 9. 提交代码 10. 部署测试环境 11. 通知需求方验收 12. 记录处理结果。任务拆分后更容易知道自己当前做到哪一步也不容易遗漏。五、开发过程中如何避免混乱1. 建立统一的任务清单不要把任务分散记录在微信聊天窗口纸上临时记事本脑子里。最好固定使用一个地方例如Markdown文档Excel飞书文档OneNoteNotion每日工作日志。任务状态可以分为待处理 处理中 等待确认 等待他人配合 待测试 待验收 已完成示例任务提出人优先级截止时间状态修改订单接口张三高今天17:00处理中查询异常数据李四中明天上午待处理部署测试环境王五高今天15:00等待权限2. 同时收到多个任务时先确认优先级不要所有任务都直接回答好的我马上处理。如果当前正在做其他事情可以这样说我现在正在处理订单接口预计下午3点完成。 这个新任务也需要今天完成吗 如果两个都比较紧急我应该先处理哪一个让需求方明确优先级可以避免最后所有任务都延期。3. 遇到阻塞及时反馈不要一个问题卡半天也不说。正确的反馈应该包含当前完成了什么卡在什么地方需要谁协助下一步准备怎么做。例如订单接口代码已经完成 目前卡在测试环境数据库权限 暂时无法完成联调。 我已经联系了运维人员 权限开通后继续测试。这比只说“还没做完”更清楚。六、任务完成后如何检查1. 功能检查提交前确认是否符合需求正常流程是否正确异常流程是否处理空值是否判断参数是否合法是否影响原有功能是否处理重复请求是否需要添加日志。2. Git提交检查提交代码前重点检查1. Git状态中是否有遗漏文件 2. 红色文件是否需要提交 3. 是否误提交target目录 4. 是否误提交本地配置 5. 是否误提交日志文件 6. 数据库脚本是否遗漏 7. pom.xml是否有必要修改 8. 是否包含调试代码 9. 是否包含无关格式化内容。对于Java项目通常不应该提交target/ .idea/ *.iml *.log 本地临时文件 个人环境配置应该通过.gitignore进行排除。3. 提交信息要写清楚不要使用这种提交信息修改代码可以写得更具体fix: 修复订单支付时间返回为空的问题或者feat: 订单详情接口增加支付时间字段清晰的提交信息方便以后查询修改记录。七、交付任务时应该怎么说不要只说已经好了。可以说明完整结果订单详情接口已经修改完成。 本次增加了支付时间字段 原来的字段保持不变 本地测试和测试环境验证均正常。 代码已经提交到测试分支 可以开始验收。如果存在注意事项也需要一起说明目前只处理了新产生的订单 历史订单暂时不补充支付时间 这个方案之前已经确认。八、发生问题或被批评时怎么处理1. 不要急着解释对方生气时如果马上解释因为你之前没有说清楚。或者我最近任务比较多。很容易让矛盾继续扩大。可以先说不好意思这次是我记录和确认得不够完整 确实耽误你时间了。然后说明补救措施我现在重新整理需求 整理完成后先发给你确认 确认没有问题后再继续修改。2. 不要只道歉要让对方看到改变真正有用的不是一直说“对不起”而是后续做到需求开始记录沟通结束后主动复述不确定的问题集中询问完成后先自查同样的问题不再重复发生。别人对你的评价最终还是来自后续的工作表现。3. 是否需要请吃饭或者买奶茶适当维护同事关系是可以的例如对方帮助解决了重要问题团队共同加班一个阶段任务完成平时偶尔请大家喝饮料。但是不要把请客当成解决工作问题的主要办法。如果每次犯错后立刻请奶茶可能会让人感觉是在用东西弥补错误。比较自然的方式是前几天麻烦大家帮我确认了不少问题 今天给大家点点喝的感谢大家。最好是请整个小组不要过度针对某一个人。真正重要的人情世故是尊重别人时间 沟通表达清楚 别人帮助后及时感谢 答应的事情按时完成 同样的问题不要重复出现。九、每天上下班应该做什么1. 上班前检查每天上班后先花十分钟确认1. 昨天有哪些任务没有完成 2. 今天有哪些截止任务 3. 哪些事情正在等待别人回复 4. 今天最重要的三个任务是什么 5. 是否需要主动向别人同步进度。不要上班后完全等别人安排。2. 下班前复盘每天花十分钟记录今天完成了什么完成订单接口字段修改 完成测试环境部署 完成前端联调。今天遇到了什么问题需求没有一次确认清楚 修改公共方法前没有查看引用 提交代码时遗漏数据库脚本。问题出现的原因不要只写“粗心”。应该写具体原因没有进行需求复述 没有使用提交检查清单 同时处理多个任务导致遗漏。下次怎么避免需求沟通后立即文字确认 提交前固定检查Git状态 公共方法修改前先查找引用。十、每周进行一次工作总结每周可以总结以下内容1. 本周完成了哪些任务 2. 哪些问题重复出现 3. 哪些知识点还不熟悉 4. 哪些工作流程需要优化 5. 下周重点改善哪个问题。每周只重点改善一两个问题。例如本周重点解决需求重复询问问题那么下周所有需求都执行先记录 再复述 集中提问 文字确认。持续一段时间以后就会慢慢形成稳定的工作习惯。十一、工作之外也需要注意1. 不要反复内耗工作中被说了以后很多人下班后会一直想他是不是讨厌我 我是不是能力很差 我是不是不适合这份工作可以进行复盘但不要无限反复回想。建议给自己规定下班前用十分钟记录问题和改进方案 记录完成后今天的工作暂时结束。有解决方案的复盘叫总结没有解决方案的反复思考叫内耗。2. 保证睡眠和休息长期睡眠不足会导致注意力下降记忆力下降理解能力下降情绪容易紧张更容易听漏需求。工作时每隔一段时间应该起身活动远眺放松眼睛喝水调整坐姿避免长时间盯着屏幕。十二、外包驻场开发日常工作标准流程以后每天可以按照下面的顺序执行第一步上班查看任务清单 第二步接收任务时立即记录 第三步对方说完后进行复述 第四步不确定的问题集中整理 第五步开始开发前分析影响范围 第六步把任务拆成小步骤 第七步遇到阻塞及时汇报 第八步完成后进行功能自测 第九步提交前检查Git文件 第十步交付时说明修改结果 第十一步等待需求方验收 第十二步下班前记录和复盘。十三、最重要的五条工作原则原则一不要依赖记忆要依赖记录人的记忆很容易受到任务打断。重要的需求、结论和时间都应该留下文字。原则二不要做完再确认要在开始前确认开始前多确认一分钟可以减少后面几个小时的返工。原则三不要零散提问要集中提问先自己思考和整理再一次性向对方确认。原则四不要只道歉要改变工作流程道歉只能解决当时的情绪新的工作方式才能真正解决问题。原则五工作靠谱是最好的人情世故请客、奶茶和吃饭只能起到辅助作用。真正让别人愿意和你合作的是沟通清楚 及时反馈 按时完成 主动检查 出了问题能够负责 同样的错误不重复发生。总结外包驻场工作任务比较零散沟通对象也比较多因此更需要建立自己的工作流程。遇到不懂的需求并不可怕真正需要避免的是不记录不确认假装听懂反复询问做完以后才发现理解错误同样的问题多次重复出现。只要坚持做到接收需求有记录 沟通结束有复述 开始开发有分析 开发过程有反馈 任务完成有检查 每天结束有复盘。工作会逐渐变得更加清晰别人也会慢慢觉得你做事越来越可靠。
