阅读 41

唠嗑-开发流程的痛点及总结

大家好,我是培训时长N年半的培训生,菜..菜包。
喜欢 ..xx..xx..xx..篮球。
长时间培训,感觉需要写点东西,欢迎指正、交流。

背景

包子进入新公司三四个月了,到目前为止,被划入业务开发组还不到两种,也就是说接触业务还不到两周。
最近三天包子参与的新需刚进入测试,但是让包子感到可怕的是,刚进入测试三四天,开发人员、测试大佬和产品经理就连续熬夜甚至通宵三四天!可怜包子也跟着陪熬了三天,这以前真的是想都不敢想的,这还只是刚进入简单的UI测试阶段!!
今天包子一觉醒来,感觉真的得说点什么才好。这样的效率,对开发人员、对产品经理,甚至对产品本身,都是一种严重的伤害。

从开发到测试,出了什么问题?

那到底是出了什么问题,导致开发、测试、产品这三方人员需要在刚进入测试阶段就连续熬夜甚至通宵??到底是什么原因造成了IT行业那么多单身狗呢??

你以为只是单纯的开发人员一直在写Bug?好吧,还是来看看吧。

  1. 产品说把已上线的一个功能页面位置移动一下,里面内容全都不改,开发组长说代码不用动(是不是很开心?什么都不用做?)。完了到测试阶段测试说数据不对,逻辑是错的!Are you kidding me??一个已上线N久的页面,你现在跟哥说不对?? 问了两波开发过这个页面的开发人员,都说自己是对的?一问开发组长,开发组长开始撸代码逻辑,一顿操作后,说都不对,代码需要重新写!!what??想象下包子脸上的表情....
  2. 接着上面的问题,包子只好重新开发接口。包子平时找产品、找业务开发组长讲业务,大家都说太忙,没时间。那好吧,现在只能在测试阶段重新写代码,业务找你们问清楚问仔细了,除了问业务,还要问涉及到的后端表、字段的设计和用法等等...最后写完这个接口,前前后后居然花了包子快3个小时的时间。。要是以前,这写接口的时间,包子得鄙视死自己。
  3. 好吧,接下来还是和包子相关。测试又给包子提了Bug了。说列表上数据不对,上一步流程执行后,数据流转到包子负责的列表这里时,某些字段数据没改变,所以bug直接就提给包子了。包子一脸懵逼,好吧,只能去找上一步流程的开发人员。包子找到人后,被人家反问了一句,那些状态需要改变吗??额...额。。。额!!!
  4. 终于不是包子了。包子坐着看书的时候,突然旁边争论起来了,是这次业务开发的组长和组员,仔细一听,组员哥们列表的数据好像又有问题,业务开发组长说你查错了,要查表A关联表B,组员说不是的,要查表C关联表D,然后就开始争论起来了......停停停,包子喊了一下,这表当时是谁设计的?好吧,是另外的同事设计的。。有没有讲解??没有,都是靠自己理解。。。好吧,那只能看谁理解对了。。。
  5. ...
  6. ...
  7. ...

归根结底,问题到底出在哪?

像上面列举的几个问题,都只是冰山一角。。
问题总是以你想不到的各种姿势出现,而你总是不知道用什么姿势来配合。

正所谓一个巴掌拍不响,其实也适合描述我们。
以上所有的问题,都不是单单某一方面就能造成的,从业务方、产品经理、开发人员、测试人员都或多或少存在着需要改进的问题,这些问题或许很小,但一旦爆发出来,往往就会出现了很多脏数据,导致业务混乱,从而造成业务方无法正常业务运转,产品人员、开发人员、测试人员没日没夜地加班加点改Bug。

我们可以对以上几点进行简单的分析,很明显可以得到一下四点 :

  1. 开发组长和组员没有详细了解业务流程,产品经理与开发方没有在业务流程上达成统一共识。
  2. 开发组长与组员在系统设计及代码层面没有统一共识,导致不同开发人员对应同一设计有不同理解。
  3. 开发人员对于不是自己设计的系统部分,开发时没有主动寻求多方了解和确认,一股脑地先干了再说。
  4. 开发组长上线前没有review code,功能出问题导致业务数据错误。实际上已经在线上出问题了。

包子的观点?

包子想先表达一下自己的两点持有的观点,不谈解决方案,因为包子暂时还没资格,各位看官若有不同观点,欢迎交流。

  • “任何技术,最后都要回归业务”。

  • “复杂计划,简单执行”。

    针对第一点,包子不是说把技术认为一文不值,而是认为,技术的实现,需要从具体的业务场景出发考虑,才能设计出最大程度适合业务的代码。无论前端开发、后端开发、测试人员甚至UI设计师,都需要认真深入业务场景,走出自己的职业范畴,以业务方的角度看待问题,然后再回归自己的角色,才能设计出最符合业务的代码。如若不然,开发人员基本只会局限于编码的角度考虑问题,无非就是代码性能、简洁性等问题,设计师基本只会局限于页面视觉效果,测试人员只会关注单个功能是否能走通等等。这样的情况下,根本没有考虑业务方实际场景,如操作便利性等等。这样看起来貌似各方都完美完成各自的任务,但如果面对未来快速变化的业务,却显得不堪一击!!

    对于第二点,可能很多看官不理解,其实指的就是有计划得执行各项任务。相信在某些开发团队中,都存在这样一个场景:产品人员PRD人手一份发下来(有时候甚至没有PRD),然后就只跟开发负责人进行简单评审,完了开发负责人直接一套数据库设计直接做完,剩下的就让开发人员自己看PRD和数据库设计开干,说开发过程有问题直接问。其实这是一种很经典的“简单计划,复杂执行”的场景。试想一下,如果开发负责人跟产品人员简单评审后,开发负责人理解了90%以上的业务需求,然后自己设计了数据库满足了自己理解的业务的90%,那么如果全部由开发负责人完成的话,算是满足了90%*90%=81%的业务需求,然而开发人员呢??只会是更低!那么产生的后果就是,顺利的话,开发人员在开发过程中,不停地跟开发负责人确认各种业务和编码层面的设计,开发阶段花费大量时间,最后测试阶段也许产生少许bug;不顺利的话,开发人员根据自己的理解,先干了再说,完了在测试阶段,发现业务的设计和自己理解的根本不一样,只能花费大量的时间修改代码,甚至等待上线后,才发现各种不对,对业务产生巨大损失。

    对此,包子想说,若能在实际开发之前,能多安排时间做出有效沟通,各方之间统一枪口,统一思路,如业务方和产品人员、产品人员和开发人员、开发人员内部等等,其实剩下的就是落地执行的事了。曾经有同事跟包子说“我们这边的需求都是很紧急的,根本没有时间做这样太多的统一沟通”;包子只想说,其实没有时间做统一沟通,到最后,加班熬夜改bug的时间往往比前期统一沟通花的时间要多得多。所以“复杂计划,简单执行”比“简单假话,复杂执行”更适合团队的工作。当然,“复杂计划,简单执行”的有点远远不止这些,如在开发过程中,有开发人员请假,那么这时候团队内的开发人员随时可以无缝对接上,因为大家思想统一,枪口统一。

关注下面的标签,发现更多相似文章
评论