背景

一切都要从那次重构说起。

为了适应业务的快速发展，我们一般双周迭代，快速、稳步的向前。产品大佬们的季度规划中，也会有一些「重量级」项目。这些项目无论是开发体量，还是重要性，都是不容小觑的。

这不，我刚刚经历了一场双项目的重构。小程序A+小程序B，同时改换成Taro框架，并采用最新的UI设计。开发前，我预料到会踩Taro的坑，也预料到排期会紧张，但是我毕竟不是郭奉孝，能够算无遗策。

下面我就将这次开发中遇到的问题以及我是如何应对的，一一跟大家道来。

问题清单

先来看一波问题清单，瞧一瞧日常中招了几个。

场景1

叶一一总算把手里这个大项目完成并提测了。第二天，当叶一一哼着小曲进公司后，测试的小伙伴发来了灵魂拷问，APP端的评价功能为什么不好使？

什么，APP端有评价功能吗？

场景2

叶一一前面按部就班，一切进展的都比较顺利，开发周期的第一阶段结束，叶一一甚至想来杯奶茶庆祝一下。但是第二阶段开始之后，叶一一时不时接到其他紧急需求。于是快到提测节点时，发现还有几个页面没有做完，所以有点慌了。

场景3

叶一一最近在搞项目重构，使用了新框架和新UI，排期的时候，掐指算了算自己的速度，发现此事并不难，应该能很快完成，但是等排期发完，拿到设计稿的时候，发现UI大变样，在已定的排期时间内无法完成全部的重构，叶一一发愁了。

场景4

这次的项目，任务重，排期紧，叶一一连续加了几天的班。眼看着明天就要提测了，但是叶一一还有部分功能没有完成，叶一一眼前昏暗暗的，茫然不知所措。

FAQ

上面的四个场景，对应了大型项目开发中遇到的几种问题。针对不同的问题，我以「三十年开发功力」总结出对应的解决方案。

Q：出现功能遗漏怎么办？

A:大项目，需求多，功能复杂，任务点分散。这种情况出现功能遗漏，大多是下面这几种情况：

• 需求没梳理全，造成了开发时功能遗漏。大型的项目，不夸张的说，需求文档和原型的内容加起来可以写本书了。
• 多端开发，各端的功能没有全部拉通，导致某个端上的功能在开发时没有开发全。
• 开发中，因为时间紧张、功能复杂等关系，导致自测的不全面，漏掉了某个功能，自己没有发觉。
• 开发中期，新增需求，邮件漏抄送或者没有邮件，开发者本人不知晓新增了功能。

1、避免需求没梳理全的解决方案

不可能完全克服这种情况，但是它是可控的。一般情况，遗漏的功能，是比较细致的需求。找到对应的需求文档，快速补全功能，这是常见的解决方案。

还有一种，我称之为「超强辅助抄作业方案」。为了避免遗漏需求，我会找个更细心的人抄作业。比我更加细心的人是我的测试同事，通常用例评审过后，我把她的用例要来和自己是设计文档比对一遍。

2、避免多端开发功能没对齐的解决方案

如果是新项目，这种情况反而比较少，我会在功能设计阶段就提出来。

反而是新端扩展，容易出现不对齐的情况。比如早期只有一端，后面开发多端，但是由于业务较多、流程较长、或者开发是新接手项目的种种情况，开发新端时，会遗漏功能的情况，尤其是流程尾部的功能，比如购买流程中的评价功能。

功课做在事前，有备无患。开发前，检查多端的基础功能、主流程是否一致，如果不一致，将问题抛给产品的同事进行确认，尽早提出尽快解决。避免后期补充耗时较长，开发压力也会增大。

常见的基础功能，登录、支付、上传、分享、图表等。仅做参考，可以总结自己项目中的基础功能。

3、避免因开发紧张导致自测不全的解决方案

功能自测是项目开发中很重要的一个环节，它可以帮助开发者发现功能卡顿，又可以提升提测质量。我一般会在排期中，专门留出4个小时的时间进行自测。

4、新需求被漏通知了怎么办？

这种情况，开发无法提前做功课，因为这种情况属于外部作用力。但是可以在项目上线之后，进行复盘时，将问题抛出来，强调一下新增需求的流程。项目复盘就是为了帮助解决项目开发中遇到的问题的，这个时候大家会提高重视。

Q：如何合理开发才能保障项目进度？

A：这类问题，我们在开发较大型的迭代的时候会遇到，前期开发感觉很稳，但是到后面，前期排期时漏掉的功能点+产品新增/修改的功能项，会导致后期开发时间紧张。主要表现为，明明前期感觉时间够，但是越往后越感觉有点做不完。

先来看看我日常怎么规划自己的开发节奏

无论开发多么稳当，前期设计多么完整给力，长周期迭代的过程中，总会有各种情况出现，比如线上紧急bug、临时上线等，都会将阻断开发，可能导致延期风险。

有经验的开发者会对于可能出现的开发状况进行预判。但是，成长中的开发者们，建议有备无患，前期将开发激情调动起来，提升开发速度，后期还能充足的时间查漏补缺和功能自测，保量又保质。

Q：UI还原怎么评估才是合理的排期？

A：较小体量的迭代，UI还原的时间会评估的很准确。对于整个项目的重构，要把UI重构结合实际页面的功能。一般情况下，设计稿是开发之后的中期左右给到前端，而开发排期是开发前就要做好的。这个时候，UI还原的排期要结合页面难易程度，合理计划，不要拘泥于以往的短期还原中，真实的评估需要多长时间。

另一种是项目迁移，页面不需要重构，这个时候看似没有UI的开发量，但是坑就在哪里等你跳下去。新框架和新UI组件都有可能导致页面和设计稿有出入，把UI检查的时间评估上，才是一个比较合理的排期。当然，这个检查的排期一般比较短。

Q：项目延期该怎么办？

A：前面讲了合理开发保障进度发方案，如果还是发生了项目延期的事情了，这个时候怎么办呢？

首先，要弄清楚导致延期的主要原因，才能「对症下药」。

延期原因一：主流程卡顿

主流程卡顿，主要场景是本应该完整的流程无法达到流程终点。

以购买流程为例，当用户选择微信支付的时候，用户会跳转到第三方支付页面，这个时候已经脱离了我们的流程，所以需要等保司返回支付结果我们才能继续进行下一步，但是等待第三方处理支付需要耗费一定的时间。

这段时间，我们的系统是无法感知客户没有完成支付是因为没操作付款，还是因为第三方没有处理完返回结果，流程就卡住了。

于是我在梳理了种种情况之后，去找产品同事讨论合理的支付流程和交互，最后产品同事将支付按钮放到了列表上通过支付结果进行展示控制，方便用户再次进行付款操作。（重复支付的问题，第三方已经做了幂等。）

「对症下药」

这种情况，要及时通知产品卡顿的具体点，而不是卡到提测的最后时间点导致提测延期。一般拉通研发和产品，把问题抛出来，共同讨论，都能找到比较合理的解决方案。

延期原因二：复杂功能无法实现或者有兼容性问题

这里场景多发于移动端开发中，因为框架或者浏览器版本兼容的问题，导致功能无法实现或者某些型号的手机下的问题无法解决。

「对症下药」

这个时候需要做这几件事情：

1、拉通所有人，告知风险点是什么，可能导致的结果，比如功能无法完成、花费更长的时间导致其他功能无法完成等；

2、将问题难点描述清晰，难点在哪？为什么解决不了？自己有没有思索其他解决方案？其他的解决方案为什么不适用；网上有没有好的解决方案？网上提供的解决方案为什么不适用？

3、给出备选方案，拉通之前，需要思考有没有备选方案提供给产品，最好给出一个或者多个备选方案。

延期原因三：第三方不支持

我们在项目中会引用一些第三方的插件，有时候因为第三方没人维护等原因，新增的功能第三方插件无法支持，但是开发前没有将这种情况考虑进来，等发现的时候已经到开发的中后期了，这个时候新写功能来不及了。

「对症下药」

第一：确定第三方是否确实不知道新增的功能；

第二：评估新功能开发时间，如果不影响主流程，看能否在提测周期中搞定；

第三：如果在提测周期中搞不定，看能不能开发出低配的版本；

第四：如果上述尝试都做了之后，结果还是搞不定，就需要拉通所有人，如实告知情况以及上面做过的所有努力。

总结

比较常见的延期原因，在开发前或者开发过程中就可以尝试规避这些因素。

但是，对于刚出「新手村」没多久的新人，不一定每次都能全部避开上面提到的或者没提到的问题，亦或是次次都能如期提测。

我虽然常常戏称拥有「三十年开发功力」，也确实工作多年，还是会有预料中或者意料之外的状况出现。毕竟离「满级」还有很大一段距离。

所以遇到问题无法解决，而导致了开发卡壳，记得要及时提出来。比如在每日例会上，将问题抛出来。“集众思，广忠益”，自己闷着，解决不了问题，也无法得到他人的帮助。

遇到问题一定要及时提出，不必不好意思或者害怕说自己做不出、做不到，毕竟我们都是人，不是机器。