质量问题不是不爆，时候未到

没有质量，哪来效率，谈什么成本；

$$01$$

最近大半年，团队以极其曲折的方式，将一个支离破碎的应用从重构的边缘给拉了回来，最终项目回到了正常迭代的节奏中；

年初的时候，运营系统相关人员离职，然后经过决策层考量之后，统筹到一个业务线维护；

问题的关键在于，这套运营系统刚开发完成，还没有全面进入使用阶段，到底有多少坑在前面闷着谁都不知道；

以维护的定调将任务安排过来，通常意味着既不能影响负责的业务线开发，同时还要保证这套新的运营系统正常运转；

还好队友对此事都能勉强理解，没有过多评论，不然会显得没礼貌了；

再来回顾这件事本意并不在于吐槽，而是复盘一下这套系统从垮掉到最终支棱起来的全过程，总结一下复杂问题的解法；

$$02$$

运营系统进入使用阶段后，符合预期成功垮掉，短短半个月的时间，产品和项目经理就收到了过百条的使用问题，优化迫在眉睫；

经验老道的队伍中：轻易不提系统级的重构二字！老底掀翻了也说是优化；

好消息，运营系统名义上已经开发完成了；坏消息，运营系统刚开始进入全面的使用阶段；

好消息，没有突破队伍刚接手时的心里预期；坏消息，运营系统名义上确实开发完成了；

跳坑不问原因，如果能绕开谁都不跳；挖坑不看深度，挖的人知道自己不走回头路；问题已经明显的摆出来了，最好的办法就是尽量一次彻底的解决它；

那么矛盾点就来了，在不过度影响主线业务的前提下，用什么方式来解决运营系统的问题，这就很考验管理和协作的流程；

$$03$$

显然在开发主线业务的同时，随意穿插运营系统的问题，这样很容易导致两边都吃力不讨好，整个队伍会更加被动，先看看应对方式；

首先使用方将问题全部对接给产品和项目经理，做好问题的优先级定性，并且在优化池文档中做好主流程与模块化维度的分类管理与场景描述；

然后将问题交由测试人员进行开发环境的复现，并简单输出一些问题的原因和异常日志，同样需要在优化池中做好整理记录；

最后由开发同学进行问题解决，再提交到测试验收的环节，问题解决后发布上线，上述流程中问题已经有了一份比较详细的描述文档，所以协作的效率很高；

从整体的流程看，与常规的协作差异并不明显，那是如何处理过程中的矛盾与时间冲突的，此时就很依赖管理策略了；

$$04$$

解决运营系统主流程的问题会集中在一个周期相对较短的高强度版本中，人力投入也很全面，以此保证系统前期的稳定和可用性；

需要优化但相对边缘的问题，采用宽松的方式推进，主线业务的研发周期中，安排在开发和测试相对空闲的时间段内；

如果出现流程中断的问题需要紧急处理时，会将主线的排期时间适当推后；解决完再回归到主线开发，并且会占用晚上和周末的时间来尽量避免延期；

因为运营系统而额外加班的队友，空闲节奏中会安排休假；过度忙碌会导致队伍的状态和情绪低落，部门经费上给到福利倾斜，毕竟人间烟火气最抚凡人心；

当然，在问题解决的过程中，并没有再次引起关联的问题，这与队伍的整体素养偏高有最直接的关系；

最终在历时六个月之后，整个运营系统实现服务的稳定可用，并且没有对业务主线产生明显的进度影响，后续的维护和开发落到版本排期即可；

$$05$$

有个三五年开发经验的同学都会遇到类似问题，躺平的老六以离职的方式甩出一个坑坑洼洼的系统，接手的队友秒变大冤种；

站在项目管理的角度来看，质量、时间、成本是需要平衡的，但从实践经验所得，没有质量，时间与成本确实无解；

对于产品研发部门来说，到底如何定义质量的标准，在原则上退好多步来说：稳定、少出错；

有几年开发经验的同学，尤其是后端，都深刻的知道系统的稳定和少出错，在实际研发中是多么有难度的要求；

很多隐藏的问题，或者逻辑不严谨，虽然在当时没有显露，但是这些麻烦就像水杯中的沉淀物，稍微晃一晃，就会原地起飞；

问题轻则甩锅大戏，问题重则离职一片，在质量问题上有多少挖坑的老六，那埋起来的大冤种只会远大于挖坑的老六；

质量问题随着产品迭代的推进，是会产生裂变的，如果出现数据层面的问题，那就是核裂变，而且不会挑选爆发的时间；

$$06$$

版本求快可以理解，因为很多业务都是有时效性的，即要快又要高质量也能接受，毕竟需要所谓的竞争力；

追求质量的门槛并不高，团队可以多码点人或者排期多给点时间，流程把控严谨是可以实现的；

但是成本与时间都不想付出，这就多少有点不懂理了；时间、质量、成本的三角形想要实现真正平衡，这绝非易事；

在研发管理中，经常出现排期紧急，应付式的开发一下，等出现关联问题时，再考虑下个应付的方法，持续性挖坑，间歇性摆烂；

等到问题多到无法应付时，可以换个地方接着玩，这可能或多或少都成为过职场生涯的跳槽原因，最终结果是没有赢家；

被迫躺平摆烂的搬砖者，主动或被动的在各个平台和产品线中不断横跳，顿悟后就会发现，哪里的代码都一样并不分高低贵贱；

任何工程中的代码出现问题，都会快速的从使用端传递到研发端，解决完还要再次通知使用端，这其中的成本完全是可以计算的，原因是可以分析的，能否避免是值得反思的；

$$07$$

很认同的一个观念是：把事情一次性做好，就是最低的成本和最高的效率；所以需求再多，也要质量为王；如果因为产品的体验差影响业务，那么用户、平台、研发谁才是真正的大冤种？

$$END$$

Gitee主页： https://gitee.com/cicadasmile...