Andy Stewart
1个月前
以前都给你们讲兵王的故事 今天给你们讲一下将军解决超大规模软件研发的故事 软件工程从本质上来说就是小房子和大厦的区别,很多AI编程的规模都在小房子的范畴,今天将的是大厦的工程量以及超大规模软件工程管理的事情 时间拉回10年前,在上一次创业遇到的最大挑战就是超大软件工程的挑战,那是2015年,我们团队一要做整个桌面环境的重写,还要做国产芯片的底层适配,还要做应用的开发。 我们一年总共的项目超过100多个,看板任务超过3万多个,每天最少要搞定100多个任务才能完成目标。 这里面桌面的后端,比如电源、磁盘、网络、触摸板、输入法、账户、安全、权限等后端,都要面临前端重写和底层后端极限优化,一些在X86上跑得很好的后端和前端,在国产芯片上要慢20倍,X86秒开的场景,国产芯片要等好几秒才有反应。 所以,年初的时候开会,我先聚集公司写代码最厉害的将领,包括技术大牛和丰富研发背景出身的项目经理,大家一起先把大方向讲了,回去和产品经理把所有功能的思维导图画了。 研发管理最重要的就是技术、时间、资源和时间规划,很多做研发不行的原因是脑袋是糨糊,糨糊的原因不是研发不懂逻辑和思考,而是做项目的时候,完全不做任务分解,一个项目到底有多少任务,只有非常模糊的方向,而没有清晰的方向。 我的要求是,思维导图的分解要细到每个任务可以一天完成,这里不光是模块,还有前端、后端的页面和接口,这样要求的前提是这是锻炼研发项目经理最好的机会,一个项目到底多少时间完成,可以清楚的知道一个项目到底有多少任务,每个自己做大概要多少时间,而且在分析的过程中发现如果分解不了,要不就是带头人对需求的理解模糊,要不就是有技术障碍没有攻克不知道怎么分解。 当带头人把任务分解对以后,每个项目都应该像一颗大树一样,非常枝繁叶茂。这时候大家开会对每条任务,没有问题,剩下的事情就很简答,把思维导图导出成看板条目,每天晨会5~10分钟对清楚当天的问题。 上面都是研发管理,今天我想分享的是,这种超大规模的软件工程会遇到很多现实的问题,解决这些问题的方法才是值得学习的。 1. 一个bug的锅在多个团队中转,都转了几圈了还下不来,这种问题一般都是bug的根源是链条型的,需要跨越部门,直接按照项目的方式,把bug的前后“犯罪者”都聚到一起才能解决,解决的根本就是要解决链条的衔接型问题。解决这种问题需要领导的魄力,传统的流程不助于解决这种链条型问题 2. 软件工程有一个特点,他的任务数和bug数不会越开发越少,而是会像正态曲线一样,bug数会爬坡,一般是前后端衔接的问题,更大的问题是有架构设计的问题。如果一个架构设计不够清晰,各个模块都只能用,最后就是💩山越堆越夸张,所以,打仗的时候,要经常把牛逼的人拉到一起去审视项目是否有架构性的问题?而没有超大规模的研发管理会恐惧这个爬坡的过程,只要架构对,这个爬坡是非常正常的,等bug到顶峰以后就会进入质量收敛的过程,越开发越稳了 3. 遇到一些疑难的bug,有时候要跳出局部技术问题看全局,产品能否去改设计绕过?因为不同产品使用方式背后的技术实现难度是不一样的,有时候产品轻微改一下,很多障碍就扫除了 4. 一些中层管理者经常抱怨任务太多,人员不好管理,压力太大,其实这时候不要期望有啥绝招,就是抗。就和健身一样,所有阵痛都是在成长的经历,这些经历才是成长成为帅才的必经之路,轻轻松松的经历就没感觉,也没法成长为独当一面的人 超大研发管理过程中,最重要的是心态,前期的状态基本上就是马蜂窝的状态,bug超级多;中期主要里程碑和架构设计的检查甚至是产品细节的调整,帮助团队扫清楚障碍,让团队的信心可以扛过正态bug峰;后期主要是功能选择,选择局部的功能的取舍和版本的管理,做不完的下一个版本做,因为特定时间完成一个版本比遥遥无期更重要。 好了,喜欢我创业故事的,欢迎点转转发 喜欢我们团队的,欢迎购买懒猫微服支持我们,你们的支持是我创作的动力!
宝玉
1个月前
原推的故事挺有意思,还记得智能手机黎明前夜的诺基亚吗?面对来势汹汹、只有一个Home键的iPhone,这家昔日巨头也急着要拿出自己的“旗舰”来应战。 摆在他们面前的是一个棘手的问题:未来到底是全触屏,还是保留用户习惯的物理键盘? 诺基亚的工程部门做了一个在当时看来“最稳妥”、风险最小的决定:我们全都要。 他们搞了个“双保险”方案:既保留物理键盘,也开发软件键盘(触屏)。这样,既能安抚留恋实体按键的老用户,也能吸引想尝鲜触屏的新用户。听起来,这简直是面面俱到、不会出错的完美方案。 然而,灾难恰恰源于这个“后备方案”的存在。 “后路”如何毒害了“主力”? 这个“双保险”策略,听起来很美,但它在执行中,直接腐蚀了两个团队的决心和执行力。 原文一针见血地指出了一个致命的内部循环: 1. 负责软件键盘(触屏)的团队,在开发时开始懈怠了。他们心想:“我们的触屏体验做得马马虎虎?没关系,反正用户还有物理键盘可以用。触屏不灵敏,他们自然会去用按键,问题不大。” 2. 负责物理键盘的团队,也开始打起了小算盘。他们心想:“为了让手机更薄、成本更低,我们可以砍掉几个不常用的功能键。没关系,反正用户还可以在触摸屏上输入那些符号。” 看到问题了吗? “后路”的存在,让两个团队都失去了“破釜沉舟”、把产品做到极致的动力。每个人都在指望对方能弥补自己的短板。大家都在“赌”对方的方案能为自己的妥协兜底。 结果就是,各自都交出了一份60分的答卷,而不是一份100分的答卷。 最终诞生的,是一个“弗兰肯斯坦”(Frankenstein)——一个由不同部件缝合起来的怪物。它的触屏体验远不如iPhone流畅,它的物理键盘也因妥协而变得蹩脚、不完整。 它试图讨好所有人,最后却被所有人抛弃。当诺基亚终于醒悟,决定“all-in”(全力以赴)时,市场早已没有他们的位置了。 真正的勇气,是敢于“没有B计划” 回头看,我们当然可以说“全力押注触屏”是显而易见的正确答案。但原文也提醒我们,在当时当地,做出这个决定需要巨大的勇气。 “全力以赴”意味着没有退路。它相当于逼着整个团队“在飞行中升级整架飞机”——这听起来惊险万分,困难重重,但这也是唯一能飞出风暴的办法。 当你只有A计划时,你会倾注120%的努力去确保它成功,因为你知道,失败了就一无所有。 而一旦B计划(那个“后备方案”)存在,它就像一个近在咫尺的安全出口,时时刻刻在诱惑你。你开始盘算“万一A计划不行……”,你投入的资源、决心和专注力就开始打折。 最终,这个B计划的存在,恰恰从内部保证了A计划的失败。 也许,有时候,最决绝的策略,反而是最安全的策略。因为当你烧掉所有后路时,你也点燃了唯一的活路。
沉浸式翻译BabelDOC 大更新-BabelDOC 0.5 4 个月,我们憋了这些大招: 1⃣可以翻译表格和矢量图中的水平文字,之前的旧版 BabelDOC 会直接跳过图表和矢量图的文字内容 2⃣公式和表格线条优化,表格和公式里的线条终于得以保留,译文的排版也更接近原始文件 3⃣跨页段落连贯性增强,旧版 翻译 PDF 时,一句话正好跨栏或跨页,就会被拆开翻译,导致译文断裂、不连贯。 0.5版对这类问题进行了优化,能自动识别并合并这些跨页段落,翻译出来顺畅得多。 4⃣术语更加统一:同一个术语在不同的段落中,可能会被翻译成不同的词语。原因是旧版 BabelDOC 中采用的是并行翻译技术,能够加快翻译速度,但缺少统一术语机制。 新版加入了术语提取功能,在翻译时会进行以下步骤: 🌀先扫描全文,识别出重要术语; 🌀给每个术语协商一个唯一的译法; 🌀在翻译过程中自动应用,保证全篇术语一致。 从而尽可能保证术语名词在同一篇 PDF 文档中译文的一致性。 5⃣字号大小更稳定:原文和译文的长度经常会不同。通常来说,从英文翻译为德文可能会产生 20%-30% 的篇幅膨胀,而英文翻译为中文日文等东亚语种则会反过来,出现篇幅缩小。 旧版 BabelDOC 的动态缩放是逐段计算。这就导致了有的段落字很大,有的又很小,看起来不美观。 新版BabelDOC 0.5 版引入了「二阶段排版」技术,先为全文计算一个统一的缩放比例;大部分段落用统一比例显示;只有极少数重排过程中实在放不下的段落,才会继续缩小。这样一来,整份译文看起来就更加整齐,可读性和美观度都有明显的提升 详细更新说明: