写点什么

如何避免重要需求遗漏?

  • 2019-10-15
  • 本文字数:1895 字

    阅读完需:约 6 分钟

如何避免重要需求遗漏?

避免重要需求遗漏,首先我们需要反问一句:为什么这些紧急重要的需求无法更早预见?同样的,我们需要了解:


  • 具体是哪些外界原因?这些原因是否有共性,有的话,那就针对性处理;

  • 增加的需求有无共性特点?有的话,可以针对性处理;

  • 临时增加有多临时?我们是否有提高或改善响应能力的空间,如果我们可以更快调整和响应,使得这些临时需求对我们产生不了什么影响,那么这个问题也就不再是问题了;

  • 既然是常态,为何我们的流程没有做出调整去应对?是调整过流程或工作方式,还是无法解决问题,还是说不知道该怎么调整流程或工作方式去适应?

具体操作方法

具体操作,可以按照事前、事中、事后各个阶段来采取不同的措施处理。


一、事中的处理


根据具体情况不同,在发现需求遗漏的当时,可以采取如下一些做法:


  • 重要需求遗漏,不紧急:既然不紧急,按照常规做法增加进去即可,但如果经常出现遗漏,就要考虑是否是需求分析和规划的实践做法有问题,才会导致问题持续出现,这种情况,应强化需求结构化管理,从全局出发进行思考和规划,避免因为思考的片面化和局部性导致的遗漏;

  • 重要需求遗漏,紧急:既然是又重要又紧急的需求,那么必然就得调整当前开发工作的顺序,把这个遗漏的重要紧急需求插进去,把工作安排下去;然后就要考虑从需求的优先级和需求的结构化管理两个方面入手复盘,并切实改进,避免类似情况再次发生;

  • 需求遗漏:如果是不太重要的需求遗漏,按照常规做法处理即可;可以根据其紧急程度和影响,决定是否调整工作顺序让这个需求插队;如果这种情况反复出现,那建议可以考虑进行复盘,从需求结构化管理的角度进行分析,并商讨改进措施;

事后处理

事后其实就是复盘,复盘的关键是要基于盘来推演和分析,这个盘就是事前制定的模型和规范。是我们有模型有规范,但执行出了问题?还是说这几个需求情况特殊,模型比较简单没有覆盖到这些特殊情况?还是说模型和规范都没问题,就是人员能力不足,导致判断偏差大?只有找到正确的根因,才能够真正有效的解决问题,所以我们不复盘则已,要复盘就务必要认真严格地进行复盘。


怎么复盘?复盘也是有方法有套路的,业界也有相关书籍可供我们参考借鉴。例如温伯格在《成为技术领导者》中提出的 MOI 模型就可以用作复盘的一种思路。


  • M:激励(Motivation),是不是人们没有动力去做这件事情?

  • O:组织(Organization),是不是无组织无纪律、一片混乱,人们不知道自己或别人该做什么?

  • I:想法或创意(Idea/Innovation),是不是缺少如何解决这些问题的点子或创意,不知道有什么办法解决这个问题?


复盘时要注意,受限于能力或经验以及出问题次数多少的影响,我们可能无法得出一个准确的结论和必然有效的解决方案。此时一方面需要秉持持续改进的心态,我们可以先落实当前已经比较明确的改进措施,后续再观察效果,持续复盘、持续改进即可。另一方面我们也可以先采取一些临时措施。


  1. 预留时间:比如,如果确实很难分析清楚为什么总是会遗漏需求,无法进行非常有针对性的处理时,也可以采取较为模糊应对的方式。可以拉取过去一段时间的工作记录,评估这段时间每个迭代的突发需求所消耗的工作量投入,可以取个平均值,然后在后续进行迭代工作安排的时候,固定的预留出一定量的时间,用于应对极有可能会出现的突发需求。

  2. 需求拆细:当出现突发需求,导致我们需要调整工作顺序时,很有可能会因为需求颗粒度大以至于腾挪余地有限,而难以避免突发需求带来的影响,因而还应该尽可能地采取拆细需求的方式,将颗粒度比较大的需求拆分为较小颗粒度的需求,可以增加调整需求工作顺序时的灵活性;


要确定到底要预留多少时间,可以利用 DevCloud 的 Epic-Feature-Story 结构,把突发需求汇集在一起,便于统计。例如创建一个特殊的 Epic“突发需求”,下一级是为每个迭代创建的 Feature,用来承载各个迭代里面具体的那些突发需求(体现为 Story),并做好工时的记录,迭代结束后,就可以来计算出现了多少个突发需求、投入了多少工作量了。



也可以采用“模块”字段来辅助记录和统计突发需求的数据。例如,新建一个模块,取名“突发需求”,所有突发需求都标注为这个模块,那么后续就可以基于模块进行筛选或查看报表等方式来统计突发需求所消耗的工作量了。


事前处理

事前的处理放到最后来介绍,是因为之所以会出现问题一般都是因为事前没有做好,但已经出现了问题就需要在当时尽快处理,所以先介绍了事中的处理。但当我们处理完问题也完成了事后复盘,就需要考虑未来的事前,尽可能的避免问题发生。


简单来讲,事前的话,就是要做好需求的结构化管理和需求的优先级管理,以及做好相关规范的宣导、人员的动员和能力的培养,这样就能够有效的避免或减小突发需求带来的影响了。


2019-10-15 16:372523

评论

发布
暂无评论
发现更多内容

ChatGPT入门案例|商务智能对话客服(三)| 社区征文

TiAmo

openai ChatGPT

迷恋管理是一种病

虎妞先生

搞懂Druid之连接创建和销毁

小小怪下士

Java 程序员 后端 Druid

前端标准化之旅

京东科技开发者

前端 代码规范 京东云 京东技术

擅用瓴羊Quick BI报表分析工具,数据分析事半功倍

夏日星河

假如面试官问你Babel的原理该怎么回答

loveX001

JavaScript

基于飞桨PaddleClas完成半导体晶圆图谱缺陷种类识别

飞桨PaddlePaddle

paddle 开源 飞桨

在统信UOS上二进制安装GreatSQL

GreatSQL

MySQL UOS 统信 greatsql greatsql社区

vivo版本发布平台:带宽智能调控优化实践-平台产品系列03

vivo互联网技术

版本发布 CDN带宽

关于微服务架构的思考

HummerCloud

微服务 云原生

疑似45亿条递信息泄露,“三类主体”如何应对?

极盾科技

数据安全

令人头秃的js隐式转换面试题,你能做对吗

loveX001

JavaScript

责任链和策略设计模式-基于Java编程语言

京东科技开发者

Java spring 代码规范 京东云 京东技术

「读源码」为什么注册路由时没有传入上下文,在接口方法中却能取到?

王中阳Go

Go golang 高效工作 学习方法 程序员

瓴羊Quick BI即席分析工具:创设数据分析捷径

巷子

瓴羊Quick BI为企业决策者提供可视化分析服务

小偏执o

面试了20+前端大厂,整理出的面试题

loveX001

JavaScript

腾讯前端必会面试题(必备)

loveX001

JavaScript

有爱相伴,宠爱有家,皮皮App发起关爱流浪动物主题公益活动

联营汇聚

Java 集合中的排序算法浅析

京东科技开发者

jdk 后端 Java、 排序算法 企业号 2 月 PK 榜

Python设置显示屏分辨率

Python 分辨率

Percona 8.0.30中show engine innodb status导致coredump排查及分析

GreatSQL

MySQL MySQL 高可用 :MySQL 数据库 greatsql greatsql社区

开学季,5门优选好课助你在新学期狂飙!

博文视点Broadview

ModStartBlog v6.7.0 后台管理优化,页面宽度调整

ModStart

最初设计时就会避开钽电容,这是为什么呢?三大理由告诉你原因

元器件秋姐

元器件 电容 钽电容

unittest使用parameterized参数化后如何调用添加到测试套件中

Python 单元测试 自动化测试 unittest 测试套件

吃透阿里2023版Java性能优化小册后,我让公司系统性能提升了200%

程序员小毕

数据库 程序员 JVM 架构师 Java性能优化

文盘Rust -- 本地库引发的依赖冲突

京东科技开发者

后端 Clickhouse 本地计算 rust语言 企业号 2 月 PK 榜

BeyondCampus-护航高校网络安全

权说安全

网络安全 零信任

Prompt Learning: ChatGPT也在用的NLP新范式

Baihai IDP

人工智能 自然语言处理 nlp ChatGPT 企业号 2 月 PK 榜

ChatGPT风口下的技术“狂飙”,天翼云荣登ZeroCLUE榜首

天翼云开发者社区

如何避免重要需求遗漏?_文化 & 方法_华为云容器服务团队_InfoQ精选文章