技术眼里的敏捷开发

时间:2021-7-21 作者:qvyue

正文

我们是否遇到过这样的问题:
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应该是将收益数据化,看到要做事情的价值,辅助进行决策。

思考🤔

经常到一种言论:技术决定业务门槛,产品决定业务发展,真的是这样吗?
这句话其实忽略了技术的很多价值,也是一种不完整的认识。
在一个团队中,每个人都是构成项目的一部分。我们可以觉得自己只是一个打工者,不去太操心项目的走向;也可以只关注自己的工作内容,自扫门前雪。但是还有一种可能:尝试去理解自己负责的内容在整个产品的作用,还有未来发展方向以及原因,尽自己的努力去完成目标和提出改进的建议。或许会徒增一些烦恼,但是会多一些影响团队、项目、产品走向的机会,也会多一些主人翁精神带回来的成就感。

以上内容来源于日常版本迭代的简化,实际情况会比更加复杂。

声明:本文内容由互联网用户自发贡献自行上传,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任。如果您发现有涉嫌版权的内容,欢迎发送邮件至:qvyue@qq.com 进行举报,并提供相关证据,工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。