背景
一切都要从那次重构说起。
为了适应业务的快速发展,我们一般双周迭代,快速、稳步的向前。产品大佬们的季度规划中,也会有一些「重量级」项目。这些项目无论是开发体量,还是重要性,都是不容小觑的。
这不,我刚刚经历了一场双项目的重构。小程序A+小程序B,同时改换成Taro框架,并采用最新的UI设计。开发前,我预料到会踩Taro的坑,也预料到排期会紧张,但是我毕竟不是郭奉孝,能够算无遗策。
下面我就将这次开发中遇到的问题以及我是如何应对的,一一跟大家道来。
问题清单
先来看一波问题清单,瞧一瞧日常中招了几个。
场景1
叶一一总算把手里这个大项目完成并提测了。第二天,当叶一一哼着小曲进公司后,测试的小伙伴发来了灵魂拷问,APP端的评价功能为什么不好使?
什么,APP端有评价功能吗?
场景2
叶一一前面按部就班,一切进展的都比较顺利,开发周期的第一阶段结束,叶一一甚至想来杯奶茶庆祝一下。但是第二阶段开始之后,叶一一时不时接到其他紧急需求。于是快到提测节点时,发现还有几个页面没有做完,所以有点慌了。
场景3
叶一一最近在搞项目重构,使用了新框架和新UI,排期的时候,掐指算了算自己的速度,发现此事并不难,应该能很快完成,但是等排期发完,拿到设计稿的时候,发现UI大变样,在已定的排期时间内无法完成全部的重构,叶一一发愁了。
场景4
这次的项目,任务重,排期紧,叶一一连续加了几天的班。眼看着明天就要提测了,但是叶一一还有部分功能没有完成,叶一一眼前昏暗暗的,茫然不知所措。
FAQ
上面的四个场景,对应了大型项目开发中遇到的几种问题。针对不同的问题,我以「三十年开发功力」总结出对应的解决方案。
Q:出现功能遗漏怎么办?
A:大项目,需求多,功能复杂,任务点分散。这种情况出现功能遗漏,大多是下面这几种情况:
- 需求没梳理全,造成了开发时功能遗漏。大型的项目,不夸张的说,需求文档和原型的内容加起来可以写本书了。
- 多端开发,各端的功能没有全部拉通,导致某个端上的功能在开发时没有开发全。
- 开发中,因为时间紧张、功能复杂等关系,导致自测的不全面,漏掉了某个功能,自己没有发觉。
- 开发中期,新增需求,邮件漏抄送或者没有邮件,开发者本人不知晓新增了功能。
1、避免需求没梳理全的解决方案
不可能完全克服这种情况,但是它是可控的。一般情况,遗漏的功能,是比较细致的需求。找到对应的需求文档,快速补全功能,这是常见的解决方案。
还有一种,我称之为「超强辅助抄作业方案」。为了避免遗漏需求,我会找个更细心的人抄作业。比我更加细心的人是我的测试同事,通常用例评审过后,我把她的用例要来和自己是设计文档比对一遍。
2、避免多端开发功能没对齐的解决方案
如果是新项目,这种情况反而比较少,我会在功能设计阶段就提出来。
反而是新端扩展,容易出现不对齐的情况。比如早期只有一端,后面开发多端,但是由于业务较多、流程较长、或者开发是新接手项目的种种情况,开发新端时,会遗漏功能的情况,尤其是流程尾部的功能,比如购买流程中的评价功能。
功课做在事前,有备无患。开发前,检查多端的基础功能、主流程是否一致,如果不一致,将问题抛给产品的同事进行确认,尽早提出尽快解决。避免后期补充耗时较长,开发压力也会增大。
常见的基础功能,登录、支付、上传、分享、图表等。仅做参考,可以总结自己项目中的基础功能。
3、避免因开发紧张导致自测不全的解决方案
功能自测是项目开发中很重要的一个环节,它可以帮助开发者发现功能卡顿,又可以提升提测质量。我一般会在排期中,专门留出4个小时的时间进行自测。
4、新需求被漏通知了怎么办?
这种情况,开发无法提前做功课,因为这种情况属于外部作用力。但是可以在项目上线之后,进行复盘时,将问题抛出来,强调一下新增需求的流程。项目复盘就是为了帮助解决项目开发中遇到的问题的,这个时候大家会提高重视。
Q:如何合理开发才能保障项目进度?
A:这类问题,我们在开发较大型的迭代的时候会遇到,前期开发感觉很稳,但是到后面,前期排期时漏掉的功能点+产品新增/修改的功能项,会导致后期开发时间紧张。主要表现为,明明前期感觉时间够,但是越往后越感觉有点做不完。
先来看看我日常怎么规划自己的开发节奏
节奏类型 |
节奏方案 |
时间节奏 |
前紧后松 |
开发顺序 |
先主流程,后覆盖细节 |
功能卡点 |
1、遇到功能卡点,及时提出问题点在哪里,一般是功能的可行性、流程卡顿等问题,及时和产品确认,一般都能将问题解决; 2、遇到问题难点耗费一定时间还没有解决,考虑可行性。如果可行性没有问题,可先暂时跳过,开发其他功能。 |
无论开发多么稳当,前期设计多么完整给力,长周期迭代的过程中,总会有各种情况出现,比如线上紧急bug、临时上线等,都会将阻断开发,可能导致延期风险。
有经验的开发者会对于可能出现的开发状况进行预判。但是,成长中的开发者们,建议有备无患,前期将开发激情调动起来,提升开发速度,后期还能充足的时间查漏补缺和功能自测,保量又保质。
Q:UI还原怎么评估才是合理的排期?
A:较小体量的迭代,UI还原的时间会评估的很准确。对于整个项目的重构,要把UI重构结合实际页面的功能。一般情况下,设计稿是开发之后的中期左右给到前端,而开发排期是开发前就要做好的。这个时候,UI还原的排期要结合页面难易程度,合理计划,不要拘泥于以往的短期还原中,真实的评估需要多长时间。
另一种是项目迁移,页面不需要重构,这个时候看似没有UI的开发量,但是坑就在哪里等你跳下去。新框架和新UI组件都有可能导致页面和设计稿有出入,把UI检查的时间评估上,才是一个比较合理的排期。当然,这个检查的排期一般比较短。
Q:项目延期该怎么办?
A:前面讲了合理开发保障进度发方案,如果还是发生了项目延期的事情了,这个时候怎么办呢?
首先,要弄清楚导致延期的主要原因,才能「对症下药」。
延期原因一:主流程卡顿
主流程卡顿,主要场景是本应该完整的流程无法达到流程终点。
以购买流程为例,当用户选择微信支付的时候,用户会跳转到第三方支付页面,这个时候已经脱离了我们的流程,所以需要等保司返回支付结果我们才能继续进行下一步,但是等待第三方处理支付需要耗费一定的时间。
这段时间,我们的系统是无法感知客户没有完成支付是因为没操作付款,还是因为第三方没有处理完返回结果,流程就卡住了。
于是我在梳理了种种情况之后,去找产品同事讨论合理的支付流程和交互,最后产品同事将支付按钮放到了列表上通过支付结果进行展示控制,方便用户再次进行付款操作。(重复支付的问题,第三方已经做了幂等。)
「对症下药」
这种情况,要及时通知产品卡顿的具体点,而不是卡到提测的最后时间点导致提测延期。一般拉通研发和产品,把问题抛出来,共同讨论,都能找到比较合理的解决方案。
延期原因二:复杂功能无法实现或者有兼容性问题
这里场景多发于移动端开发中,因为框架或者浏览器版本兼容的问题,导致功能无法实现或者某些型号的手机下的问题无法解决。
「对症下药」
这个时候需要做这几件事情:
1、拉通所有人,告知风险点是什么,可能导致的结果,比如功能无法完成、花费更长的时间导致其他功能无法完成等;
2、将问题难点描述清晰,难点在哪?为什么解决不了?自己有没有思索其他解决方案?其他的解决方案为什么不适用;网上有没有好的解决方案?网上提供的解决方案为什么不适用?
3、给出备选方案,拉通之前,需要思考有没有备选方案提供给产品,最好给出一个或者多个备选方案。
延期原因三:第三方不支持
我们在项目中会引用一些第三方的插件,有时候因为第三方没人维护等原因,新增的功能第三方插件无法支持,但是开发前没有将这种情况考虑进来,等发现的时候已经到开发的中后期了,这个时候新写功能来不及了。
「对症下药」
第一:确定第三方是否确实不知道新增的功能;
第二:评估新功能开发时间,如果不影响主流程,看能否在提测周期中搞定;
第三:如果在提测周期中搞不定,看能不能开发出低配的版本;
第四:如果上述尝试都做了之后,结果还是搞不定,就需要拉通所有人,如实告知情况以及上面做过的所有努力。
总结
比较常见的延期原因,在开发前或者开发过程中就可以尝试规避这些因素。
但是,对于刚出「新手村」没多久的新人,不一定每次都能全部避开上面提到的或者没提到的问题,亦或是次次都能如期提测。
我虽然常常戏称拥有「三十年开发功力」,也确实工作多年,还是会有预料中或者意料之外的状况出现。毕竟离「满级」还有很大一段距离。
所以遇到问题无法解决,而导致了开发卡壳,记得要及时提出来。比如在每日例会上,将问题抛出来。“集众思,广忠益”,自己闷着,解决不了问题,也无法得到他人的帮助。
遇到问题一定要及时提出,不必不好意思或者害怕说自己做不出、做不到,毕竟我们都是人,不是机器。