LogoLogo
Contribute to InnerSource PatternsJoin the community
🇪🇸 Español
🇪🇸 Español
  • Introducción
  • Tabla de Contenidos
  • Explorar Patrones
  • Contribuir a este libro
  • Patrones
    • Casos de uso del Gestor de Tareas (Issue Tracker)
    • Colaborador Contratado
    • Comenzar como Experimento
    • Comité de Revisión
    • Documenta tus Principios Rectores
    • Documentación Base Estándar
    • Equipo Central (Core Team)
    • Extensiones para un Crecimiento Sostenible
    • Garantía de 30 Días
    • Grupo de Soporte
    • Herramientas de Comunicación
    • Licencia InnerSource
    • Líder de Comunidad Dedicado
    • Mercado de Gigs
    • Modelo de Madurez
    • Portal InnerSource
    • Proceso Estándar de Publicación
    • Puntuación de Actividad del Repositorio
    • Reconocimiento a los Participantes
    • Requerimientos Comunes
    • Servicio vs Librería
    • Toma de Decisiones Transparente Entre Equipos usando RFCs
    • Trusted Committer
    • Valoración de Proyectos Transversales
  • Apéndice
    • Plantilla de Patrones
    • Glosario
    • Extras
      • Plantilla de README
      • Plantilla de CONTRIBUTING
      • Plantilla de COMMUNICATION
      • Plantilla de RFC
  • Recursos
    • Este libro en GitHub
    • InnerSource Commons
Con tecnología de GitBook
En esta página
  • Title
  • Patlet
  • Problema
  • Contexto
  • Resistencias
  • Solución
  • Contexto Resultante
  • Patrones Relacionados
  • Instancias Conocidas
  • Estado
  • Autor
  • Agradecimientos
  • Histórico de Traducciones

¿Te fue útil?

Editar en GitHub
Exportar como PDF
  1. Patrones

Comenzar como Experimento

Title

Comenzar como Experimento

Patlet

Inicia tu iniciativa InnerSource como un experimento con tiempo limitado para facilitar que los gerentes no familiarizados con InnerSource respalden y apoyen la iniciativa.

Problema

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.

Contexto

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.

Resistencias

  • 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.

Solución

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

Contexto Resultante

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.

Patrones Relacionados

Instancias Conocidas

  • 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.

Estado

  • Estructurado

Autor

  • Georg Grütter (Robert Bosch GmbH)

Agradecimientos

  • 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)

Histórico de Traducciones

AnteriorColaborador ContratadoSiguienteComité de Revisión

Última actualización hace 2 meses

¿Te fue útil?

Considera designar el final del experimento como un punto de pivot, cambio o pausa para reevaluar. También considera establecer un 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 . Si los proyectos en el experimento no tienen un impacto directo en los ingresos de la empresa, considera introducir para resaltar sus contribuciones de valor.

Trial Run (del libro )

2025-04-03 - Traducción

2025-04-03 - Traducción

Comité de Revisión
Primeros Pasos con Métricas
Valoración de Proyectos Transversales
Fearless Change
Oscar Lobaton S.
Roman Martin Gil