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