Inicie como um Experimento
Comece a sua iniciativa InnerSource como um experimento com limite de tempo para tornar mais fácil para os gestores que não estão familiarizados com o InnerSource endossar e apoiar a iniciativa.
Uma iniciativa InnerSource é considerada, mas não é iniciada porque a gestão está incerta sobre o resultado e, como resultado, não está disposta a comprometer um investimento.
A empresa está considerando o InnerSource para aumentar a eficiência da colaboração em projetos de software. No entanto, a maioria dos gestores não está familiarizada com o modelo de trabalho de código aberto e está mais acostumada com o estilo de gestão hierárquica e de controle de cima para baixo. A ideia do InnerSource é muito popular entre os desenvolvedores de software da empresa, não apenas porque muitos desenvolvedores usam ou estão desenvolvendo ativamente software de código aberto.
- Os gestores vão querer validar as alegações de melhoria na colaboração por meio do InnerSource antes de fazer um investimento de longo prazo. Isso geralmente envolve medir as melhorias.
- Se a iniciativa InnerSource provavelmente terá uma grande adesão entre os desenvolvedores e se muitos projetos provavelmente dependerão dela, a decisão de encerrá-la será muito impopular e, portanto, difícil de ser tomada. A perda de controle percebida resultante pode desencorajar alguns gestores a sequer começar com o InnerSource.
- A implementação de modelos de trabalho no estilo InnerSource muitas vezes representa uma ruptura radical em relação aos modelos de trabalho praticados anteriormente. Portanto, é provável que processos obrigatórios existentes já não sejam aplicáveis e que processos de governança adequados estejam faltando. O resultado pode ser que seja necessário operar em uma zona de vácuo regulatória, às vezes legal. Exemplos são regulamentos relacionados a impostos e controle de exportações em grandes corporações com várias entidades jurídicas em diversos países.
Declare a Iniciativa InnerSource como um experimento com tempo limitado. Defina e comunique os critérios para os projetos ingressarem no experimento InnerSource. Escolha critérios que maximizem as chances de construir uma comunidade saudável. Um conjunto de critérios é bom se as percepções geradas a partir dele dentro do contexto do experimento puderem ser intuitivamente aplicadas a contextos envolvendo outros potenciais projetos InnerSource.
Exemplos de critérios são:
- Distribuição geográfica suficiente de desenvolvedores
- Mistura departamental suficiente de desenvolvedores
- Abertura da comunicação dentro da comunidade
- Caminho de carreira baseado em mérito dentro da comunidade
- Tomada de decisão democrática dentro da comunidade
Considere designar o final do experimento como um ponto de pivot, mudança ou pausa para reavaliação. Também considere estabelecer um Comitê de Revisão para aumentar as chances de aceitação da gestão por meio da participação. Dependendo da cultura da empresa, pode ser útil acompanhar o experimento com métricas apropriadas Primeiros Passos com Métricas. Se os projetos no experimento não fornecerem um impacto direto na receita da empresa, considere introduzir Avaliação de Projetos entre Equipes para destacar suas contribuições de valor.
Os gerentes podem dar início ao InnerSource pelos seguintes motivos:
- A configuração experimental facilita a necessidade dos gerentes analisarem os números do programa InnerSource da mesma forma que fariam para projetos típicos.
- A possibilidade de falha do experimento é compreendida e aceita. O risco pessoal para os gerentes de apoio é minimizado.
- Mesmo em caso de falha, a configuração garante que a empresa aprenderá com o experimento.
- Em caso de sucesso, os dados coletados durante o experimento permitirão que os gerentes façam um compromisso mais duradouro com o InnerSource.
Os participantes no experimento InnerSource agora estão cientes de que devem provar à gestão que o InnerSource oferece os benefícios prometidos. Isso ajudará a focar o trabalho nas atividades que proporcionam o valor mais demonstrável, aumentando assim as chances de sucesso.
Finalmente, começar como um experimento torna muito mais fácil evitar regulamentos e forças, como políticas de ferramentas e processos, que poderiam diminuir as chances de sucesso.
- Trial Run (from the book Fearless Change)
- Robert Bosch GmbH (globally distributed software development)
- Structured
- 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)
- 2023-08-20 - Tradução Eneri Junior
- 2023-08-20 - Tradução Humberto Zilio