在一定规模的软件研发团队内, 经常出现的情况是对同一个问题领域, 会有多个人或多个者团队蒙头再重复做系统或方案来解决相同问题.
甚至, 在一些团队内, 技术人员为了职位晋升, 会通过重复建设相关的系统来展示其能力, 并名其名曰面向晋升编程.
对于个人来说, 重复造轮子其实是人之本性, 特别是对于优秀的研发工程师来说, 自己的方案和代码永远都是最好的, 别人的都是垃圾.
对于研发团队最高负责人而言, 就需要认真思考重复建设的对整个团队是否是问题, 以及问题产生的原因是什么?
对于中小型团队, 在研发资源有限的情况下, 系统的重复建设其实一个比较严重的问题, 反映出组织内部可能出现了一些不太好的征兆:
团队信息共享机制缺失
例如, 组织内 A 团队在 Q1 构建了一个解决配置信息管理系统, 并且已经自己内部使用的很好了, 解决了很多问题, 提高其研发效率, 6 个月后, 另外一个 B 团队因为需要解决类似的问题, 自己又投入资源搞了另外一套系统, 还可能会出现 C 团队, D 团队等等.
同样的问题, 为什么出现两套系统, 背后反映的整个研发团队内部信息共享机制的缺失. A 团队在做之前如果可以和整组织内的其他团队共享一下问题, 大家共享问题, 共同建设一个共享系统, 或者 A 团队做完的系统使用后, 在组织内部做一些宣传推广, 让有同样问题的兄弟团队来直接使用呢.
好的共享机制和文化, 可以减少不必要的重复建设, 将节省的研发资源投入到更加重要事情上, 从而产生更大的价值.
团队内部职责不清
从管理的视角看, 重复建设的背后是不是因为团队内部的分工不合理导致. 一些可预期的多个团队都会用到的基础能力, 是不是有独立的团队去负责建设这些体系, 从横向上支撑整个研发团队, 这样来提高整体的效率.
一般上一点规模的研发团队, 都会建立一个共享能力建设的团队, 从研发组织全局视角去承接一些可复用的研发工作, 从而避免团队各自为战的情况出现.
常见共享团队, 例如中间件团队, 数据团队, 以及去年大火的中台团队.
共享基础设施缺失
如果两个团队正在构建相同的基础设施来解决类似的问题, 那么它应该是一个共享服务或能力. 基础设施的统一建设, 长远看会为组织降低很多成本, 同时也会大幅度提升研发团队的效率. 高效统一的基础设施的好处主要有:
系统层面可以高度复用
专业的团队解决专业的问题, 避免低水平重复建设
可以带来人员内部的横向调动学习成本大幅降低
团队全局意识不够
因为两个团队针对同一个问题提出了相似的解决方案, 这表明团队中高级别的员工的全局意识不足. 如果做这样事情的人员还因为或的晋升, 这样会降低团队的整体的格局.
例如, A 团队已经做了一个方案, B 团队的经理至少应该知道这个问题已经是一个共同的问题, 应该更高的维度上来考虑问题:
B 团队在自己做之前应该寻求组织内部的资源, 如果已经有了就可以考虑直接使用
或者 AB 团队共同建设, 并推广到全组织内使用
A 团队自己使用不错时候, 就可以积极推广到全组织内, 为全研发团队带来效能的提升.
总结
从管理的角度看, 在一个组织内一些公用的系统能力重复建设, 就是对组织资源的严重浪费. 如果是组织必须的能力体系, 最好的解决方案就是从全局出发, 重点投资, 投入足够的资源来建设到位. 重复建设不可取, 低水平的重复建设更不可取.
轮子小造怡情, 团队内大造轮子就需要慎重考虑了, 特别是中小型团队而言.
对于优秀的工程师个人而言, 造一些轮子来自我实现是必须要途径, 如果能在组织内横向跨团队推动一批人来一起造一个不错的轮子, 对个人和集体而言都是一个不错机会.
本组织构建的每个资产管理管道都是浪费精力, 本应该在更高的级别进行投资.
来源: https://www.cnblogs.com/peida/p/12768630.html