#超大规模软件工程

3天前

以前都给你们讲兵王的故事今天给你们讲一下将军解决超大规模软件研发的故事软件工程从本质上来说就是小房子和大厦的区别，很多AI编程的规模都在小房子的范畴，今天将的是大厦的工程量以及超大规模软件工程管理的事情时间拉回10年前，在上一次创业遇到的最大挑战就是超大软件工程的挑战，那是2015年，我们团队一要做整个桌面环境的重写，还要做国产芯片的底层适配，还要做应用的开发。我们一年总共的项目超过100多个，看板任务超过3万多个，每天最少要搞定100多个任务才能完成目标。这里面桌面的后端，比如电源、磁盘、网络、触摸板、输入法、账户、安全、权限等后端，都要面临前端重写和底层后端极限优化，一些在X86上跑得很好的后端和前端，在国产芯片上要慢20倍，X86秒开的场景，国产芯片要等好几秒才有反应。所以，年初的时候开会，我先聚集公司写代码最厉害的将领，包括技术大牛和丰富研发背景出身的项目经理，大家一起先把大方向讲了，回去和产品经理把所有功能的思维导图画了。研发管理最重要的就是技术、时间、资源和时间规划，很多做研发不行的原因是脑袋是糨糊，糨糊的原因不是研发不懂逻辑和思考，而是做项目的时候，完全不做任务分解，一个项目到底有多少任务，只有非常模糊的方向，而没有清晰的方向。我的要求是，思维导图的分解要细到每个任务可以一天完成，这里不光是模块，还有前端、后端的页面和接口，这样要求的前提是这是锻炼研发项目经理最好的机会，一个项目到底多少时间完成，可以清楚的知道一个项目到底有多少任务，每个自己做大概要多少时间，而且在分析的过程中发现如果分解不了，要不就是带头人对需求的理解模糊，要不就是有技术障碍没有攻克不知道怎么分解。当带头人把任务分解对以后，每个项目都应该像一颗大树一样，非常枝繁叶茂。这时候大家开会对每条任务，没有问题，剩下的事情就很简答，把思维导图导出成看板条目，每天晨会5~10分钟对清楚当天的问题。上面都是研发管理，今天我想分享的是，这种超大规模的软件工程会遇到很多现实的问题，解决这些问题的方法才是值得学习的。 1. 一个bug的锅在多个团队中转，都转了几圈了还下不来，这种问题一般都是bug的根源是链条型的，需要跨越部门，直接按照项目的方式，把bug的前后“犯罪者”都聚到一起才能解决，解决的根本就是要解决链条的衔接型问题。解决这种问题需要领导的魄力，传统的流程不助于解决这种链条型问题 2. 软件工程有一个特点，他的任务数和bug数不会越开发越少，而是会像正态曲线一样，bug数会爬坡，一般是前后端衔接的问题，更大的问题是有架构设计的问题。如果一个架构设计不够清晰，各个模块都只能用，最后就是💩山越堆越夸张，所以，打仗的时候，要经常把牛逼的人拉到一起去审视项目是否有架构性的问题？而没有超大规模的研发管理会恐惧这个爬坡的过程，只要架构对，这个爬坡是非常正常的，等bug到顶峰以后就会进入质量收敛的过程，越开发越稳了 3. 遇到一些疑难的bug，有时候要跳出局部技术问题看全局，产品能否去改设计绕过？因为不同产品使用方式背后的技术实现难度是不一样的，有时候产品轻微改一下，很多障碍就扫除了 4. 一些中层管理者经常抱怨任务太多，人员不好管理，压力太大，其实这时候不要期望有啥绝招，就是抗。就和健身一样，所有阵痛都是在成长的经历，这些经历才是成长成为帅才的必经之路，轻轻松松的经历就没感觉，也没法成长为独当一面的人超大研发管理过程中，最重要的是心态，前期的状态基本上就是马蜂窝的状态，bug超级多；中期主要里程碑和架构设计的检查甚至是产品细节的调整，帮助团队扫清楚障碍，让团队的信心可以扛过正态bug峰；后期主要是功能选择，选择局部的功能的取舍和版本的管理，做不完的下一个版本做，因为特定时间完成一个版本比遥遥无期更重要。好了，喜欢我创业故事的，欢迎点转转发喜欢我们团队的，欢迎购买懒猫微服支持我们，你们的支持是我创作的动力！

#超大规模软件工程 #研发管理 #Bug解决 #国产芯片适配 #团队协作