正文
我们是否遇到过这样的问题：
1、需求评审时有些疑问，不知道从何问起；又或者好像听着明白，开始做的时候就有些困惑？
2、技术方案设计时无从下手，感觉整个需求比较杂乱，就是一些逻辑堆叠而成；
3、在需求开发过程中，记不清楚具体的需求过程，需要频繁回顾产品需求文档；
4、需求提测之后，自己感觉问题不多，结果QA测试出来很多Bug；在bugfix的时候解了BugA，又漏出来BugB；
如何来减少这种问题的出现？下面分享一些敏捷开发的经验。
需求开发流程
产品经理分析、调研用户需求以及整体市场环境情况，对于某些功能产生预期收益，就计划如何去做来拿到收益，把具体事情整理成方案之后就形成了需求文档。
需求到了研发这边，当我们接触需求之后，可能就会开启一系列流程：需求细评、工作量评估、技术方案评审、需求排期、需求开发、需求自测、需求提测、问题修复、版本灰度、线上发布、数据跟进。
将上述流程整理、简化成开发视角下的过程：
PM是产品经理，RD是研发，UI/UE是设计，DA是数据，QA是测试。
1、需求评审
这是PM主导的评审，对齐需求目标和预期收益，较为复杂需求会有UE同学讲解交互；负责开发的需求会先参与需求细评，中间会涉及的具体细节；可以提前做好功课，先看文档以理解产品逻辑，因为会议时间往往不长，最好是用来确定核心述求和讨论一些疑惑点，避免去对需求细节的解释。
在会议结束之后，研发将需求进行拆解，可以按照客户端同学最熟悉的页面维度去拆分，大致描述每个界面的核心要素；也可以按照产品需求文档，从业务逻辑的角度去拆分，描述该需求的产品逻辑要素；也可以从数据流的角度去拆分，从数据产生（用户操作，后台产出）、数据接收（接口请求）、数据消费（界面展示、用户交互）、数据上报（埋点上报）等，来描述该数据层面上的变化。
核心点就是有一个思路来贯穿整个需求，将一个需求拆解成树形的结构，以便于我们去评估需求复杂度和完整了解整个需求。
2、方案设计
由需求开发RD主导，输出整个需求的技术方案。这时候前面的需求拆解就非常重要，因为方案设计的前提就是需求的整体理解，将复杂的需求进行拆解，再借由一些通用的程序设计思想进行组合，将前面拆解出来的需求整理成一个方案。
方案设计出来之后，会有相关的RD同学一起进行review，针对方案的扩展性、稳定性等进行讨论，也会根据已有业务评估方案的影响点，尽可能在方案设计时暴露出来风险点。
3、逻辑开发
现在对需求有全面的了解，同时也有完备的技术方案，接下来就是按图索骥把方案实现出来；一个稍复杂的需求在实现过程中，RD既需要专注在代码实现，还要记住需求细节，保证最终实现出来与之前设计一致，这并不是很简单的事情。
此时，前面两个环节沉淀出来的需求拆解文档和技术方案文档就非常重要。我们先按照技术方案的设计，从某些模块入手；实现过程中，按照需求拆解文档进行一步步实现；在实现完部分模块之后，再回顾技术方案，开始下一步的模块；如果实现过程中，发现方案设计有些欠缺考虑点，则先停下来代码实现，优先考虑如何修改方案设计，再继续按照方案去实现。
4、五方验收
需求开发完成之后就需要自测：回顾需求文档看看是否遗漏的实现点，对着设计稿看看界面实现是否偏差，检查交互文档特别注意里面的小字说明，跑一遍测试给出的case，保证埋点验收能看到所有的埋点。
自测完成之后，就可以进入验收环节。PM会检查功能实现是否符合预期，UI会进行像素级别对比，UE会体验产品细节交互，DA会验收所有埋点细节并记录，QA则会用各种无法预期的操作去测试。
经过多方锤炼之后，需求终于可以合入。
5、灰度上线
在正式上线之前，会进行多次灰度。RD会打开AB实验、下发settings配置，灰度期间再看看功能的问题反馈。如果灰度发现问题则要追本溯源，确定问题出现的真正原因，修复完成跟下一次灰度。
直到整体质量稳定之后（达到准出标准），才会进行正式版本的发布。
开发过程的建议
一些提高工作效率的注意点：
1、信息传递的及时性，尽量少用IM工具消息去确认紧急的事情，当面沟通更加高效，也可以减少文字的信息传递误差，语音会议也是很好的选择；
2、阶段性做事，在前面提到的各个环节中处理对应的事情，特别是前期的流程，确保自己在需求评审完之后理解需求，方案设计之后清楚怎么实现；
3、合理安排时间，在安排时间的时候要特别注意几个节点：
埋点就绪时间，现阶段在需求评估工作人日的时候，往往没有具体的埋点，需要关注埋点什么时候出来，并且出来之后看一遍是否有较难实现的埋点；
UI就绪时间，由于目前设计人力短缺，往往排期时同样没有UI稿，在UI搞产出之后，需要和之前方案进行对比，考察后续实现是否存在难点；
需求自定义里程碑节点，一个较为复杂的需求（我们可以定义为排期超过3天的需求），可以自行分配时间，并按照1~2天定一个里程碑节点，自己关注在对应节点的时候是否能够如期完成；（如果没有，是否应该和其他人沟通）
自测时间点，自测是为了提高需求的完成度，避免验收的时候爆发非常多的问题，这需要预留一点时间；
验收时间点，有时候验收时间会和开发时间重叠，及时留意trello和bug单，集中性解决验收问题；这也是为什么要进行自测的原因之一，如果验收过程中出现非常多的问题，会压缩下一个需求的开发时间；
合码时间点，注意版本的合入截止时间，但是不要卡在最后时间点才合入；代码越早合入，则会越少出现冲突；
版本deadline带来的压力是硬性压力，延期造成的影响比较大；而我们定义的节点属于软性压力，很重要但是有时会被大家忽视，带来的结果就是一个压力不断积累和风险不断扩大，最终在版本末期集中爆发。
技术如何参与团队决策
1、需求可行性的判断
这是从技术的角度，来分析需求的可行性。产品的思维非常发散，有时候会提出一些天马行空的想法，比如说根据手机壳颜色调整手机主题色。这些也有可能不是奇思妙想，如果手机具有识别颜色的传感器，这需求也可以实现；或者说采用降级方案，通过手机先对手机壳照相，提取手机壳颜色，再根据提取出来的颜色进行主题色适配。
先尝试从技术的角度去评估可行性，有实现的可能，才能讨论具体收益和实际投入。
2、丰满理想下的骨感现实抉择
PM/UI/UE在考虑功能设计的时候，往往希望产品功能完善、体验极致，但是每个双月的时间又是那么短暂，技术可以对需求进行理性评估，拆分出来需求各个模块的投入人力，进行后面的一些决策：在保证核心收益的前提下，如何快速完成该需求并上线进行验证，如果预期收益合理再进行下一步改进，如果和预期不符，则快速调整需求，或者及时放弃以止损。
3、数据化的重要性
有时候功能上线之后，用户反馈和产品直觉不一定相符合，此时用数据来量化收益就非常重要。技术会帮助产品将这个过程量化，除了关注需求的具体内容，也可以关注需求的前因后果。数据化能帮助团队优先做一些有收益的事情，而不是一些看起来应该做，但是目前拿不到太大收益的事情。
4、趋之若鹜的AB
PM为了更好量化需求收益，往往都会在需求中添加实验，甚至一些文案、toast的修改都想加一些实验来衡量收益，是否实验就是需求上线的保障？数据化是非常重要的，但是万物皆AB明显是存在不合理的地方。AB并不是万能的，有些需求甚至有可能因为正向收益不大，受到实验随机波动导致实验组负向。
合理AB应该是将收益数据化，看到要做事情的价值，辅助进行决策。
思考🤔
经常到一种言论：技术决定业务门槛，产品决定业务发展，真的是这样吗？
这句话其实忽略了技术的很多价值，也是一种不完整的认识。
在一个团队中，每个人都是构成项目的一部分。我们可以觉得自己只是一个打工者，不去太操心项目的走向；也可以只关注自己的工作内容，自扫门前雪。但是还有一种可能：尝试去理解自己负责的内容在整个产品的作用，还有未来发展方向以及原因，尽自己的努力去完成目标和提出改进的建议。或许会徒增一些烦恼，但是会多一些影响团队、项目、产品走向的机会，也会多一些主人翁精神带回来的成就感。
以上内容来源于日常版本迭代的简化，实际情况会比更加复杂。
