Trilha de aprendizagem: responsável pelo produto

A seção responsável pelo produto cobre como esse papel se encaixa no InnerSource.

Abertura

Como é difícil ser a Gerência Média.

Grandes benefícios são construídos no processo InnerSource

Novos papéis e responsabilidades

Recap e Takeaways

Fechando.

Diário de trabalho

Mais de uma resposta pode estar correta em algumas perguntas.

1. Falta de desenvolvedores competentes por causa da forte concorrência no mercado para os empregados.
2. Falta de reconhecimento para o papel do gerente em tornar o projeto bem sucedido
3. Falta de entrada na visão da organização
4. Falta de clareza na alocação de fundos

Por que 1 está errado: competição para pessoal de desenvolvimento qualificado é certamente um problema no campo de informática neste momento, mas InnerSource não pode lidar com isso. Não faz os desenvolvedores surgirem do chão.

O vídeo destacou a invisibilidade de muitas atividades de gestão intermediária. InnerSource dá a esses gerentes uma chance de estarem mais envolvidos em discussões que cruzam fronteiras organizacionais, e seu histórico preserva evidências de suas contribuições.

Por que 3 está correto: os gerentes do meio acham que são responsáveis pela realização de escolhas feitas pela alta gerência, mas não podem influenciar essas escolhas. Em contraste, InnerSource traz os gerentes em comunicação com outras equipes, proporcionando assim uma chance de ampliar sua própria influência e participar mais ativo na formação dos objetivos e visão por trás de seus projetos.

O InnerSource não tem impacto direto no financiamento, então o financiamento não é discutido neste segmento de vídeo. No entanto, a adoção do InnerSource tem um impacto indireto no financiamento, porque agora o trabalho em um projeto é compartilhado por várias equipes, e a gerência deve reconhecer que os recursos são gastos de forma diferente. Especificamente, a quantidade de codificação por membro da equipe irá diminuir ligeiramente em favor da comunicação e documentação, enquanto a produção geral do projeto deve aumentar graças à colaboração.

Mais de uma resposta pode estar correta em algumas perguntas.

1. Um atraso na implementação de uma característica importante porque a equipe responsável atribui-lhe uma baixa prioridade
2. Integração lenta de correções de erros enviadas por estranhos.
3. Uma falha em reconhecer o valor das contribuições dos gerentes intermediários.
4. Conhecimento restrito a alguns desenvolvedores.

Nas organizações tradicionais, só a equipe anfitriã pode mudar seu código. Outras equipes devem apresentar pedidos e esperar até que sua importância seja reconhecida. Com InnerSource, uma equipe externa que precisa urgentemente de uma mudança pode codificá-la, com orientação da equipe anfitriã.

Como InnerSource requer contribuições de diferentes equipes, planos devem ser publicados e compartilhados. Isso não só permite a coordenação, mas destaca as contribuições que um gerente e sua equipe fazem para a organização maior.

InnerSource pede documentação e transparência em código e diretrizes. Se um desenvolvedor chave sair ou estiver ocupado, o conhecimento estará disponível para os outros.

1. Padrões corporativos
2. Processos
3. Documentação
4. Crédito para realizações

Por que 1, 2 e 3 estão corretos: padrões, processos e documentação são elementos importantes de colaboração que permitem que várias equipes produzam código para um projeto compartilhado. Compartilhar padrões, processos e documentação junto com o próprio código os torna explícitos, bem como fáceis de consumir e manter.

Por que 4 está correto: controle de versão, placas de mensagens e outras ferramentas preservam um registro do que aconteceu e quem contribuiu. A transparência e acesso aberto que eles criam garante visibilidade e assim permite crédito adequado para realizações em projetos InnerSource.

1. Uma maior dependência de outras equipes para implementar as características necessárias
2. Abordagens perdedoras para gerenciamento do ciclo de vida da aplicação
3. Mais discussões entre proprietários de produtos em diferentes equipes
4. Vistas divergentes do produto entre diferentes equipes

Cada equipe deve ter a equipe e os recursos necessários para atender suas necessidades. Ao se envolver em InnerSource, uma equipe externa pode implementar um recurso ou correção de bug necessária pela equipe de hospedagem. No entanto, deve ser considerado como uma coincidência de sorte ao invés de parte do plano de produtos da equipe de hospedagem.

Por que 2 está incorreto: definição de requisito, desenvolvimento de código, testes, verificação de código, e implantação – as várias partes do ciclo de vida da aplicação – ainda são tão importantes como sempre foram. Commissores confiáveis garantem que os forasteiros respeitem o ciclo de vida e sigam os padrões da equipe para garantir qualidade.

Por que 3 está correto, contribuidores, compradores de confiança e donos de produtos mantêm mais discussões sobre projetos InnerSource para colaborar em encontrar soluções. A entrada de outros donos de produtos incorpora conhecimento valioso sobre seus usuários, a história de seus projetos, pedras de tropeço para observar, e outras coisas. Isso faz a comunicação extra valer a pena.

InnerSource promove comunicação entre equipes para que todos tenham uma visão consistente do que precisa ser feito. Embora as equipes possam ter objetivos diferentes e trabalhar em um projeto para atingir esses objetivos, eles devem ser unificados em sua visão do produto.

1. É menos necessário porque as equipes compartilham uma base de código
2. Pode exigir treinamento e orientação para que os líderes do projeto façam uma colaboração eficaz.
3. Leva a mais empoderamento de gerentes intermediários.
4. Deve estar na forma escrita o máximo possível.

Colaboração e negociação se tornam mais importantes do que nunca em InnerSource. Contribuidores explicam o que querem mudar e por quê. Commissores confiáveis trabalham com eles para garantir que o projeto seja bem sucedido e funcione bem na base de códigos.

Os técnicos geralmente saem da faculdade ou outros programas de treinamento com habilidades em programação, e talvez engenharia e gerenciamento de projetos. Mas tais programas raramente reconhecem ou ensinam o valor do treinamento e da orientação, que são fundamentais para InnerSource. As empresas deveriam considerar preencher a lacuna com seu próprio treinamento.

Porque os gerentes intermediários podem participar, e ajudar na moda, a decisão de outras equipes, eles podem alcançar os objetivos de sua equipe mais facilmente.

Por que 4 está correto: as pessoas não podem participar de um objetivo compartilhado se não tiverem as mesmas visões de objetivos e maneiras principais de prosseguir. Documentação ajuda a garantir que todos concordem antes de começarem as tarefas e procedimentos importantes.

Mais de uma resposta pode estar correta em algumas perguntas.

1. Deixando os contribuintes saberem no que devem trabalhar.
2. Garantindo que todos os pedidos de contribuição entrem no produto.
3. Garantir que sua equipe use os mesmos processos que os outros.
4. Convidando colaboradores externos para escrever padrões de codificação e padrões UI/UX.

InnerSource depende de contribuidores para decidir no que trabalham com base em suas próprias necessidades. Embora o dono do produto possa decidir para sua própria equipe o que trabalhar em seguida, contribuidores InnerSource auto-selecionam para trabalhar com base em seus próprios critérios. Compromissores confiáveis podem encorajar contribuintes a trabalhar em projetos específicos, mas a decisão de fazê-lo depende do contribuinte.

Por que 2 está errado: contribuidores InnerSource possuem seu próprio destino até o fim do trabalho. Enquanto o dono do produto pode concordar com o trabalho que deve ser feito, cabe ao contribuinte fazer o tempo, fazer o trabalho, e responder a qualquer feedback confiável para que o trabalho possa se tornar uma parte do produto da equipe anfitriã.

Por que 3 está incorreto: equipes diferentes podem usar processos diferentes porque seus produtos pedem isso, porque escolheram diferentes ferramentas ou linguagens de programação, ou por razões históricas ou culturais. Diferenças nos processos não impedem que as equipes trabalhem juntas de forma InnerSource. No entanto, cada equipe deve documentar seus processos e aprender os processos de outra equipe ao trabalhar no código dessa equipe. Forasteiros também podem ajudar a documentar os processos de uma equipe, padrões de codificação e padrões de UI/UX.

Por que 4 está correto: forasteiros costumam trazer perspectivas importantes, tanto sobre as necessidades do usuário quanto sobre métodos robustos para atender essas necessidades. Eles podem rever os padrões da sua equipe, e até mesmo contribuir para eles. Donos de produtos e compradores confiáveis devem solicitar contribuições aos padrões.

1. Ajuda a estimar as necessidades de recursos e prazos.
2. Criar interface de usuário ou experiência de usuário (UI/UX) documentação
3. Duplicar trabalho sendo feito em outras equipes
4. Escreva seus conselhos quando treinar os contribuintes.

Por que 1 está incorreto, os commissores confiáveis podem fornecer informações valiosas para determinar as necessidades e prazos de recursos, porque eles entendem bem o estado do código e as capacidades dos contribuintes.

Por que o 2 está incorreto, comutadores confiáveis também devem entender as necessidades do usuário final para criar código que atenda a essas necessidades. Então, pode ser razoável para comitentes confiáveis trabalharem na documentação UI/UX.

O objetivo do InnerSource é reunir todos os interessados em uma característica, para que possam colaborar na criação do código necessário em um único lugar. Duplicação é má arquitetura, e é um desperdício.

A maioria das comunicações entre portadores de confiança e contribuintes é escrita e assíncrona, porque muitas vezes estão em locais diferentes. Além disso, a comunicação escrita permanece como um registro do que foi feito e por quê. Pode ser útil para treinar futuros contribuintes. Há muitas maneiras além de e-mail para gravar comunicações escritas, mas e-mail continua sendo um meio popular e útil.

1. Administração superior.
2. Contribuidores externos.
3. Mestres Scrum.
4. Compromissos confiáveis.

A gerência superior pode definir prioridades estratégicas para o negócio, mas geralmente não estão envolvidas na implementação no solo através do InnerSource.

Uma vez que um contribuinte é encontrado, o comitente confiável tem a responsabilidade principal de apoiá-los em uma contribuição bem sucedida para o projeto.

Scrum pode ou não ser usado em projetos InnerSource, e pode não funcionar bem em equipes (especialmente equipes geograficamente remotas). O processo crítico InnerSource envolve apoio a indivíduos motivados, não um esforço de equipe como Scrum.

Por que 4 está correto, compadres confiáveis fazem InnerSource trabalhar no solo. Eles são fundamentais para facilitar as mudanças que outras equipes fazem na base de código de uma forma que funcione para ambas as equipes.

1. Eles precisam de uma atualização em seu projeto para que seu próprio projeto prossiga.
2. Eles veem como seu projeto é importante para a empresa e querem ajudá-lo.
3. A contribuição permite que suas habilidades de engenharia cresçam fazendo trabalho em uma nova área técnica.
4. Seus projetos de equipe se sobrepõem aos seus e sua contribuição é uma maneira de juntar os recursos de ambas as equipes para conseguir mais.

Por que 1 está correto: quando um recurso em seu backlog não é importante para o projeto geral, mas muito importante para uma equipe em particular, uma contribuição InnerSource é uma ótima maneira dessa equipe tirar o item do seu backlog e entrar no seu projeto.

Todos estão ocupados com seu próprio trabalho. Mesmo que o trabalho em seu projeto seja crítico para o sucesso da empresa, é improvável que ganhe ajuda adicional de outros apenas por altruísmo.

Na verdade, trabalhar em uma nova tecnologia é a melhor maneira de aprender. Engenheiros precisam aprender novas habilidades, e fazer isso via contribuição InnerSource é uma ótima maneira de ajudar a empresa ao mesmo tempo.

Por que 4 está correto: InnerSource economiza custo de desenvolvimento permitindo que equipes com projetos redundantes ou sobrepostos colaborem em um único código baseado em vez de silos de engenharia duplicados.

Mais de uma resposta pode estar correta em algumas perguntas.

1. Coloque a responsabilidade pela saída da sua equipe em outras equipes.
2. Ganhar mais controle sobre um projeto
3. Reduza as interações demoradas com outras equipes.
4. Realizar mais tarefas, e fazê-las mais rapidamente, aproveitando a entrada de outra equipe

Uma equipe continua responsável pelas tarefas que lhe são atribuídas. InnerSource ajuda outras equipes a atualizar sua base de códigos para atender suas necessidades, mas eles não assumirão suas tarefas.

Quando sua equipe contribui para a base de código de outra equipe, você pode implementar um recurso que você precisa no período de tempo que você precisa, investindo qualquer tempo de desenvolvimento é necessário. Quando outra equipe contribui para a sua, você abandona um pouco de controle sobre como um recurso é implementado, mas pode empregar a ajuda externa para atender linhas do tempo para sobrepor necessidades de forma mais eficaz.

Interações com outras equipes aumentarão significativamente depois de adotar InnerSource. O aumento do tempo gasto na interação valerá a pena enquanto as equipes atendem suas necessidades de forma mais eficiente.

Por que 4 está correto: InnerSource dá uma saída para equipes com demanda reprimida ou tempo para contribuir para o seu projeto de uma forma que lhes dá o que precisam enquanto avançam as características do seu projeto.

1. Negociar com outros donos de produtos.
2. Vender o projeto da equipe para outras partes da empresa.
3. Apoie o papel de comitente confiável.
4. Adote práticas de planejamento aberto.

InnerSource capacita os donos de produtos a negociar diretamente para estabelecer contribuições de uma equipe para a outra.

Por que 2 está correto: os contribuintes nem sempre afluem a um projeto só porque é declarado “aberto”. Sair e encontrar pessoas que poderiam estar interessadas em contribuir e dizer-lhes por que seria uma grande idéia fazê-lo.

Uma vez que uma contribuição está alinhada, o papel de committer confiável é fundamental para garantir que o código submetido realmente preencha a necessidade de ambos os times convidados e hospedeiros.

O planejamento aberto facilita a colaboração com os outros. Como as decisões e informações estão abertas, a política organizacional é reduzida e as pessoas podem focar no trabalho que precisa ser feito e como realizá-lo.