Featured image of post 程序员如何快速验证业务需求?

程序员如何快速验证业务需求?

作为一个程序员,听着攒劲的小曲,写着优雅的代码,加班加点终于写完了迭代中分配的模块需求。然后你跟别的同事一联调,却发现各种问题...

前言

设想一个场景:

你作为一个程序员,听着攒劲的小曲,写着优雅的代码,加班加点终于写完了迭代中分配的模块需求。然后你跟别的同事一联调,却发现各种问题。

你跟同事A说:“你得在这种情况下给我数据A。“

同事A一脸懵逼:“这种情况需求也没写啊,在这种情况下我也没有数据A啊!“

然后你和同事A一起顺着业务流程,找到了负责上层模块的同事B。

同事B一脸懵逼:“这个迭代中我没有这个模块的开发需求啊,这种情况下我也没有数据A啊!”

然后你和同事A、同事B一起顺着业务流程,找到了负责上层模块的……

最后,你和同事ABC…一起找到了产品,产品一脸懵逼:“那没办法,就改需求吧……”

你眼看着所剩无几的迭代时间,生无可恋地掏出手机,发个微信取消了这周末的相亲…

不知道程序员xdm有没有经历过这样的场景,如果各位程序员xd没有经历过这样的场景,那真的是恭喜你了,且行且珍惜!从毕业后参加工作开始,我是真的经历太多了,太痛了!

我之后不断学习各种方法,尝试去破解这样的困局。虽然说,工作中的问题很多,但是能解决一个是一个,后面再慢慢跟各位分享其他问题中我的解决方案。

所以,本篇文章将分享一波关于这类问题我的解决方案。谨代表个人主观观点。

痛点

需求是用户的痛点,但是在这个场景下,是程序员的痛点…

那么,仔细分析一下,这个场景下的痛点,到底是什么呢?我认为是如下两点:

  • 产品给到的需求无法自洽,且场景覆盖不够
  • 开发团队的技术评审和技术文档不到位
  • 开发各自按照模块开发,忽略外部环境,仅仅当各自开发完成后联调时候才会组装应用,发现问题

当然,可能有程序员xd会疑问:这种问题不是靠严谨的开发流程就可以避免吗?

理论上来说是这样的,但是以我个人经历而言,不管是大团队还是小团队,总有很多不稳定的因素,比如说迭代周期、协作流程的规范性等等。

特别是在创业团队,或者有些项目特别着急的时候,经常是没有足够的时间给到团队的各个角色去充分准备的,甚至为了赶时间,会精简一些环节甚至直接去掉。这种时候出现这种问题导致改需求,往往是非常可怕的,后果也往往是开发团队加班。

解决方案

我目前发现且实践后效果较好的方案,就是“曳光弹式开发”。

什么是曳光弹

经常关注军事的小伙伴儿,应该了解,曳光弹是一种运用于军事场景的特殊子弹。

我们都知道武器发射时需要瞄准,比如枪就通过照门和准星来瞄准,而坦克和装甲车以及飞机都有专用的瞄准具,非常复杂。对于轻武器来说,一般攻击距离都比较近,使用自带的机械瞄准具或者外加的光学瞄准镜都足够,但是在距离稍远的时候瞄准镜显然不够。而对于飞机和战斗机来讲,在空中飞行时飞行姿态变化多样,有时候进攻的时间很短,需要快速射击并且调整弹道,这时候就需要可以发光的曳光弹。

曳光弹正如其名,可以发光而且指示弹道。曳光弹的结构比一般子弹更加复杂。子弹的弹壳部分和一般子弹一样,前半部分是钢心或者铅心的弹头,但是在后部有一个空腔,一般称作曳光管,里面填充着曳光剂。曳光剂的成分还比较复杂,一般来说主要成分是镁粉和铝镁合金粉,用来燃烧,除此之外还有硝酸锶。这样一来,燃烧的时候硝酸锶就会发出红光。大家平时看到的很多曳光弹还有黄光和绿光,加入钠盐就会发出黄光,而加入铜盐就会发出绿光。除此之外还在表面加入一层过氧化钡,以保证曳光剂被点燃。

对于机枪手来说,如果射击距离较远,自然不能选择过于精确的设计方式,也就是说不能靠瞄准具来射击。而一般的机枪主要起压制和面杀伤作用,加入曳光弹就是机枪手更加快速方便的控制弹道,随时变化攻击的方向。如果没有曳光弹的话,射手根本无法发现自己的子弹弹道,也就很难去调整弹道。毕竟枪械射击温度升高之后,弹道会有所变化,不同的弹药不同的枪管也都会改变子弹的弹道,如果仅仅依靠枪械自身的瞄准具去调整反而会适得其反,而曳光弹就很好的解决了这个问题。

在开发中的作用

理解曳光弹本身在军事中的作用后,我们再来看曳光弹式开发如何在开发中起作用。

开发团队在接手到产品给到的业务需求后,特别是构建一些以前从未做过的东西时,对这个产品/功能的最终成效是模糊的。

程序员就像坦克上的机枪手一样,在尝试在黑暗中击中目标。但是如果像文章一开始的时候,大家先埋头写自己的模块,然后再联调,最终发现问题,感觉就像一上战场,大家都朝着各自理解的方向拼命清空弹夹,击中目标的寥寥无几,最后受伤的还是自己。

所以,此时,就需要先使用几颗曳光弹,去击中目标,在黑暗中划出轨迹,开发团队再调整方向,对着目标集中火力。

如何应用

非常简单!步骤如下:

  1. 找出级别最高的需求
  2. 以完成最基础的完整功能为目标,从前端到部署,开发一个可以运行的骨架
  3. 最后上相关需求的测试案例

这样,射出一颗曳光弹,穿透客户端、后端、数据库、运维、测试等不同层面。一旦击中目标——即符合用户需求,后续的任务便大都是搬砖的活儿,去丰富这个骨架。

曳光弹并不是总能击中目标的,中途若是发现未能击中目标,便可在前期以极小成本去调整曳光弹的方向,继续发射曳光弹。

如果你要问,什么是“最基础的完整功能”,那么可以这么说,那么举个例子:前端不要任何样式,直接能够满足比如表单功能即可,后端不用任何校验,能够处理和传递数据即可。

总结

为了解决文章开头的问题,需要使用曳光弹式开发,先开发一个骨架,确认满足需求后,即可继续丰富骨架,完成产品。

作为团队的一员,团队的每一个角色都很重要,程序员跟产品也是需要紧密协作,互帮互助,才能使得产品更好,也使得业绩更好。

Licensed under CC BY-NC-SA 4.0
最后更新于 Dec 05, 2023 15:56 UTC