写在前面
你是不是接需求后手足无措？是不是天天忙碌，但又效率不高？是不是需求沟通前后不一致，导致重复修改？几年前刚踏入职场生活的我，对此深有体会。经过沉淀，终于搞明白怎么高效开发，高效会议，总结这几点经验：和产品做朋友、需求对齐和排期、需求方案设计与发布上线、事故与复盘。从此高效工作，早早下班。
树立正确的观点
阅读之前，不妨问问自己，工作的目的是啥？
也许每个人有不同的观点。有人觉得事情永远都干不完，不如慢慢做，自己也更轻松。但有种高级的思维方式是：尽自己努力做好每件事情。因为只有好好对工作，升职加薪才会好好对你；只有对工作表现出热情，老板才会对你有信心，才更可能在职场激烈的竞争中脱颖而出。
和产品做朋友
产品是一群有想象力，能把抽象的事情具体化的人。他们不仅有许多新颖的点子，还能迅速的 get 到你说的想法。和产品同学做朋友不仅能更加顺利的合作，还能开拓视野，增长见识。比如和产品一起坐电梯，他们可能会想为什么要装镜子，而你会想电梯系统是怎么实现的。在不同角度看同一件事情不仅十分有趣，还能扩展更多可能，不妨试试看。
第一手需求
和产品做朋友，能比别人更快的拿到第一手需求。
产品的需求并不是凭空而来，它可能是从竞品、客户需或老板提出的，产品往往是把需求具体化的人。他们更多的关注是需求是怎么实现的。以及联动的功能和异常场景。而开发则会把具体的需求通过编码实现。
当然，正因为产品的角度更多的是怎么实现需求，也更容易过于关注需求实现，而把原本用户诉求无限放大，忽略了需求本身。
开发拿到第一手需求最好的方式是如何实现需求出发，可以通过哪些方式来解决。也许需求可以不用开发，只需换个角度看问题就能轻松解决。
核心思想: why
需求对齐和排期
需求宣讲
需求宣讲是产品与开发、测试把方案内容输出的主要途径。一份需求的宣讲过程，大致可分为需求宣讲前、需求宣讲中、需求宣讲后。遵循一套流程能有效避免踩坑和高效率会议。
需求宣讲前：
亚马逊的高管会议，会在开会前半小时阅读会议内容，再根据梳理的疑问进行讨论。
阅读需求文档是必不可少的过程。有效的阅读文档，能在需求宣讲时更能提出自己的疑问与观点，能避免前期因为准备不足，导致的会议效率低下。这样的高效工作方式更值得作为打工人的我们借鉴。需求宣讲前可以从：
- 看需求：了解需求的背景，和类似场景其他产品怎么实现的
- 提疑问：融合 Why、How、What 去思考
- 给方案：对现有的技术给需求的方案
- 给排期：给出大概的排期，以 人/天 为单位进行估算
需求宣讲中：
需求宣讲中主要是对齐方案，解决疑惑。作为开发者期望的是对所有异常场景与方案有大概的了解，且高效会议，一次通过。需求宣讲中围绕：
- 提出疑问：提出会前准备的疑问，并发散出新的疑问
- 确认需求：和产品、测试方沟通对齐表现和异常场景，最好有录屏作为证据
- 一次通过：有不确定的点会中立马拉上相关同学对齐，争取一次性通过会议，不开第二次
- 确认 deadline: 与估算的 人/天 进行匹配，有疑问可向负责人提出
需求宣讲后：
会议后通常需要结论的沉淀。这样的好处是在不记得需求细节时可以翻看存档来确认细节、防止产品甩锅等。宣讲内容沉淀的方式：
- 录像回放：有问题可将录像回放，找到讨论的地方
- 会议纪要：将本次的结论、需要跟进的点写下来，发群里，并艾特相关同学
会议纪要常用模版：
经过与产品方、xx方的沟通，有以下结论与跟进事项：
结论：
1、xxx
跟进事项：
1、 xxxx @xxxx 同学
辛苦 @xxxx 关注并确认
核心思想: How
目标拆解与甘特图
有了具体的需求后，就来到了排期缓解。产品同学希望越快越好，而 PM（Project Manager） 会根据版本的时间点排期。也正因为二者的目标不同，会存在 PM 的排期与产品期望时间并不是相同时间点。为了保证需求不因为自己 delay，合理的人力估算和目标拆解变得必不可少。
目标拆解
好的目标拆解通常会以大目标和小目标来进行拆分。大目标包括需求评审时间、开发时间、联调时间、测试时间、code review 时间、发布时间，以时间节点为颗粒；小目标包括开发进度、联调进度，以每天的事件为颗粒。
评估做不完需求该怎么办？
- 需求上：迭代处理，分成本期必保、本期冲刺、本期不做的几种类型
- 人力上：评估加人能否解决
- 时间上：deadline delay 还是需求 delay
需求拆分的小 tips
将开发、联调事件拆解，细分到每周、每天的工作。让每天的进度可控，按时完成工作，按时回家。出现进度不可控则周末适当调整下。
对目标拆解到具体内容：
- 需求 deadline 倒推出需求开发完成、提测、发布时间点
- 根据时间点定具体开发内容，每周目标、每日目标
小目标拆解后，甘特图就更能显示工作内容和进度了。
甘特图
甘特图能清晰的知道工作进度。个人使用甘特图能清晰的定好每天的目标，高效工作；多人合作使用甘特图能划分每个人的工作内容以及进度同步。
使用甘特图的好处很多，它不仅能直观、定量的看到进度，还能知道预期目标和实际产出的差值，能有效知道进度快、慢的原因。更重要的是有沉淀，有利于需求完成后的回顾，及时几年后看到自己画的甘特图，也能很快的回忆起当时做需求的问题与困难，充当需求快照的作用。
核心思想: When
从方案设计到发布上线
从方案设计到发布上线，基本属于开发和测试的工作。方案设计能具体量化需求方案，也能有效保证开发进度，这一环节必不可少。开发和测试的有效沟通也能帮助开发找到代码漏洞，避免发布上线后带来的事故，这些环节十分重要。
方案设计
方案设计有多香，体验过的人都知道。它的好处在于全局的思考需求，比较容易给出全局最优，而不仅仅是局部最优。方案设计不仅在开发阶段起着举足轻重的作用，还对后续维护有很大的便利。方案设计可以围绕这几点写：
- 时间人物：标注需求关键的时间节点和参与方
- 业内方案：例如业内实现和竞品分析等
- 方案设计：方案的具体逻辑，包括设计稿、流程图、库表字段等
- 其他：流程卡点、自我反思或结论留底等
处理 bug 的规矩
产品是开发的上游，测试是开发的下游。测试同学对产品形态的表现甚至比产品还更关心，多和测试同学沟通，也能让产品有更良好的发展。要和测试做朋友，从来一杯奶茶做起。当然立好规矩也能避免在需求测试过程中增加沟通成本。 - 提单前：先沟通到底是开发原因还是其他原因，定好责任方与优先级
- 提单时：必须包含复现路径及截图，最好包含账号信息和录屏
- 提单后：非必要场景沟通能否降低优先级，不好解决的问题能否转成需求单
发布条例
流程的建立很大程度上是对人的保护，遵循流程能有效程度上保护自己。 - 发布计划：列好发布计划，从 MR、代码到配置，使用发布标记记录每个发布时间点
- 发布透明：需要发的功能、bugfix和压测接口明确知会
- 做好灰度：发布的功能遵循一定规则灰度
- 立刻验证：发布后的第一时间线上验证，保证发布功能正常
- 留守保障：留守一定的时间，保证发布后无明显波动，方便有问题及时响应
核心思想: 规矩
事故与复盘
在需求发布过程中，事故难免会发生。及时、正确的处理事故，在职场上是对自己的保护。同样能帮助自己更快的成长，减少相同错误的发生。
透明原则
事故发生后第一时间向上级汇报，并定时汇报进度，即便是自己闯出来的。遇到事故建议处理方式：
- 事故发生时：
1、大群里艾特相关同学及上级，并同时电话上级，确认信息同步完全
2、能恢复立刻恢复
3、每隔几分钟向上汇报，即使没有进度
4、向上级寻求帮助，直到问题解决 - 事故发生后：反思与沉淀
处理事故的五要素
- 定义问题：能不能量化指标，比如出现路径、指标数据灯
- 发现问题：能不能有监控，及时和准确的告警
- 分析问题：能不能有工具辅助，提升分析问题的效率
- 解决问题：能不能第一时间修复，为用户解决问题
- 预防问题：能不能补充相关case，保证犯过的错误不再犯
最后
写到这里基本完成了，每个点笔者都亲身经历过也实践过。从“年轻”到“老”程序员，磨平了很多冲动与莽撞，沉淀了各个流程的“最佳实践”。如今带小朋友一起干活，对我而言，也是个全新的阶段。这篇文章也算为上阶段的思考做沉淀吧，也希望帮助到有需要的人。
感谢你阅读到这里。
