系统质量问题不是不爆,时候未到

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

01


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

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

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

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

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

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

02


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

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

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

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

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

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

03


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

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

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

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

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

04


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

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

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

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

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

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

05


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

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

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

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

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

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

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

06


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

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

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

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

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

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

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

07


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

相关文章
|
存储 数据采集 数据挖掘
质量追溯系统方案
质量追溯系统方案
629 1
|
前端开发
uView Tabs 标签页
uView Tabs 标签页
397 0
|
安全 Linux Shell
【内网安全-CS】Cobalt Strike启动运行&上线方法&插件
【内网安全-CS】Cobalt Strike启动运行&上线方法&插件
2762 0
【内网安全-CS】Cobalt Strike启动运行&上线方法&插件
|
SQL 安全 Java
一篇文章彻底理解 HIVE 常见的三种 AUTHENTICATION 认证机制的配置与使用
一篇文章彻底理解 HIVE 常见的三种 AUTHENTICATION 认证机制的配置与使用
|
9月前
|
自然语言处理 算法 搜索推荐
《当NLP邂逅GIS:跨界融合的无限可能》
自然语言处理(NLP)与地理信息系统(GIS)的融合正开启全新应用大门,带来智能地理信息检索、地理知识图谱构建、灾害预警优化及智能导航等创新。通过NLP理解复杂语义并转化为GIS指令,降低了用户门槛,提升了效率。然而,数据异构性、语义理解复杂性、计算资源瓶颈及复合型人才短缺等问题仍待解决。尽管面临挑战,未来NLP与GIS的深度融合将为各行业带来更多变革与发展机遇。
191 12
|
Docker 容器
Docker自建仓库之Harbor高可用部署实战篇
关于如何部署Harbor高可用性的实战教程,涵盖了从单机部署到镜像仓库同步的详细步骤。
622 15
Docker自建仓库之Harbor高可用部署实战篇
|
11月前
|
传感器 消息中间件 人工智能
一套基本的具身智能技术流程是如何实现的
Embodied Intelligence作为一种将感知、决策与执行相结合的前沿技术,正在引领机器人技术迈向新的高度。具身智能不仅要求机器人具备理解和处理复杂环境的能力,还需赋予其自主决策和执行任务的能力。本文将深入探讨如何将LLM和多模态大模型与机器人技术相结合,构建一套完整的具身智能技术流程。本文参考了同济子豪兄的部分工作,TsingtaoAI团队对整体构建做了一部分拓展和延伸。
1423 3
|
编解码 缓存 算法
Three.js如何降低3D模型的大小以便更快加载
为加快600MB的3D模型在Three.js中的加载速度,可采用多种压缩方法:1) 减少顶点数,使用简化工具或LOD技术;2) 压缩纹理,降低分辨率或转为KTX2等格式;3) 采用高效文件格式如glTF 2.0及draco压缩;4) 合并材质减少数量;5) 利用Three.js内置优化如BufferGeometry;6) 按需分批加载模型;7) Web Workers后台处理;8) 多模型合并减少绘制;9) 使用Texture Atlas及专业优化工具。示例代码展示了使用GLTFLoader加载优化后的模型。
1734 12
|
Linux iOS开发 MacOS
如何查看你的Python版本?
在命令行中查看Python版本很简单。在Windows上按Win+R,输入powershell;在macOS上通过Finder→Applications→Utilities→Terminal;在Linux上打开终端。然后输入`python --version`或`python -V`。输出显示如"Python 3.8.3"。使用`python -VV`可获取更多详细信息。在Python脚本中,可通过`sys.version`或`platform.python_version()`检查版本。确保使用Python 3,因为Python 2自2020年起已停止更新和支持。
1678 5