Comenzar como Experimento
Inicia tu iniciativa InnerSource como un experimento con tiempo limitado para facilitar que los gerentes no familiarizados con InnerSource respalden y apoyen la iniciativa.
Se considera una iniciativa InnerSource pero no se inicia porque la gerencia tiene dudas sobre su resultado y, en consecuencia, no está dispuesta a comprometerse con una inversión.
La empresa está considerando InnerSource para aumentar la eficiencia de la colaboración en proyectos de software. Sin embargo, la mayoría de los gerentes no están familiarizados con el modelo de trabajo de Open Source y, en cambio, están acostumbrados a un estilo de gestión jerárquico y de control de arriba hacia abajo. La idea de InnerSource es muy popular entre los desarrolladores de software de la empresa, porque muchos desarrolladores usan o están desarrollando activamente software de Open Source.
Los gerentes querrán validar las afirmaciones de mejora de la colaboración a través de InnerSource antes de hacer una inversión a largo plazo. Esto generalmente implica medir las mejoras.
Si la iniciativa InnerSource probablemente tendrá una gran aceptación entre los desarrolladores y si muchos proyectos dependerán de ella, una decisión de cerrarla será muy impopular y, por lo tanto, difícil de tomar. La pérdida de control percibida podría disuadir a algunos gerentes de siquiera comenzar con InnerSource.
Implementar modelos de trabajo al estilo InnerSource a menudo es un cambio radical con respecto a los modelos de trabajo practicados anteriormente. Por lo tanto, es probable que los procesos obligatorios existentes ya no sean aplicables y que falten los procesos de gobierno apropiados. Esto podría llevar a operar en un vacío regulatorio, e incluso legal. Ejemplos son las regulaciones relacionadas con impuestos y control de exportaciones en grandes corporaciones con múltiples entidades legales en múltiples países.
Declara la iniciativa InnerSource como un experimento con tiempo limitado. Define y comunica los criterios para que los proyectos se unan al experimento InnerSource. Elige criterios que maximicen las posibilidades de construir una comunidad saludable. Un conjunto de criterios es bueno si los conocimientos generados a partir de él en el contexto del experimento pueden aplicarse intuitivamente a contextos que involucren otros posibles proyectos InnerSource.
Ejemplos de tales criterios son:
Suficiente distribución geográfica de desarrolladores
Suficiente mezcla departamental de desarrolladores
Apertura de comunicación dentro de la comunidad
Trayectoria profesional basada en el mérito dentro de la comunidad
Toma de decisiones democrática dentro de la comunidad
Considera designar el final del experimento como un punto de pivot, cambio o pausa para reevaluar. También considera establecer un Comité de Revisión para aumentar las posibilidades de aceptación de la gerencia a través de la participación. Dependiendo de la cultura de la empresa, podría ser útil acompañar el experimento con métricas apropiadas Primeros Pasos con Métricas. Si los proyectos en el experimento no tienen un impacto directo en los ingresos de la empresa, considera introducir Valoración de Proyectos Transversales para resaltar sus contribuciones de valor.
Los gerentes pueden iniciar InnerSource por las siguientes razones:
La configuración experimental reduce la necesidad de que los gerentes examinen los indicadores del programa InnerSource de la misma manera que lo harían con los proyectos típicos.
La posibilidad de fracaso del experimento se entiende y se acepta. El riesgo personal para los gerentes que apoyan se minimiza.
Incluso en caso de fracaso, la configuración asegura que la empresa aprenderá del experimento.
En caso de éxito, los datos recopilados durante el experimento permitirán a los gerentes comprometerse a largo plazo con InnerSource.
Los participantes en el experimento InnerSource ahora son conscientes de que deben demostrar a la gerencia que InnerSource ofrece los beneficios prometidos. Por lo tanto, ayudará a enfocar el trabajo en aquellas actividades que proporcionen el valor más demostrable, aumentando así las posibilidades de éxito.
Finalmente, comenzar como un experimento facilita mucho eludir las regulaciones y resistencias como las políticas de herramientas y procesos que podrían disminuir las posibilidades de éxito.
Trial Run (del libro Fearless Change)
Robert Bosch GmbH (desarrollo de software distribuido globalmente)
Airbus: la comunidad de ciencia de datos colaboró en librerías compartidas de Python que eventualmente llevaron a un esquema InnerSource en todo el grupo para cualquier software.
Estructurado
Georg Grütter (Robert Bosch GmbH)
Jason Zink (Robert Bosch GmbH)
Diogo Fregonese (Robert Bosch GmbH)
Robert Hansel (Robert Bosch GmbH)
Hans Malte Kern (Robert Bosch GmbH)
Russ Rutledge (Nike)
Tim Yao (Nokia)
Clint Cain (Optum)
2025-04-03 - Traducción Oscar Lobaton S.
2025-04-03 - Traducción Roman Martin Gil