março 15, 2024
Por mais de 100 anos, fabricantes de automóveis de todo o mundo desenvolveram e produziram autos. Milhares de funcionários desses fabricantes trabalham no desenvolvimento dos modelos de veículos atuais por três ou quatro anos. Esse é um longo período em que esses funcionários precisam colaborar entre si.
O software muda tudo
Os fabricantes de automóveis têm de gerir a transformação digital se quiserem sobreviver. Carros não são mais apenas carros. Atualmente, entre 50% e 70% dos custos de desenvolvimento são destinados ao desenvolvimento de software. Em um mundo cada vez mais digital, é necessário oferecer inovações em ciclos de desenvolvimento curtos. Idealmente, os fabricantes de automóveis de hoje gostariam de atualizar o software de um carro mesmo depois de vendido.
O desenvolvimento de carros não trata mais apenas de mecânica, hardware, aço e chapas. Com o software, seus processos de desenvolvimento se tornam cada vez mais complexos. Portanto, os fabricantes de automóveis buscam novos modelos de trabalho que os preparem melhor para o futuro. Um futuro baseado em software em vez de hardware.
Agilidade empresarial com o Scrum
Esta é a razão pela qual as empresas procuram modelos de trabalho alternativos que abordem essa complexidade no software muito melhor do que as práticas tradicionais de engenharia.
Os frameworks de escalabilidade ajudam a organizar a empresa em direção a uma maior agilidade empresarial. Os suspeitos usuais são SAFe, LeSS, Nexus, DAD ou Scrum@Scale, sendo o SAFe o framework escolhido pela maioria das empresas para sua transformação.
Com muitas opções para escolher
Qual estrutura é a certa a escolher? Os gerentes automotivos geralmente decidem com base em sua experiência anterior no setor. Eles não podem mais ignorar a disrupção evidente baseada em software assumindo o controle do que o mercado precisa. É hora de pensar fora da caixa.
SAFe é amado rápido demais
A indústria automotiva muitas vezes escolhe o Scaled Agile Framework (SAFe) para sua nova forma de trabalhar com desenvolvimento de software. Em muitos casos, a introdução da SAFe não leva ao sucesso desejado. Três possíveis razões explicam sua decisão a favor da "SAFe" e por que sua implementação não é bem-sucedida.
Razão #1: Do complicado ao complexo
Quando um fabricante de automóveis constrói um novo modelo, o caminho para todas as etapas necessárias para desenvolver é claramente definido. Muitas peças devem se encaixar, exigindo que todos os funcionários envolvidos sejam muito organizados em seu processo de desenvolvimento. A organização interna de todos os fabricantes de automóveis é praticamente a mesma, e seus processos também.
Tais processos de desenvolvimento são complicados, mas bem definidos e maduros. Os engenheiros da indústria automotiva estão acostumados com esses processos há décadas, está dentro de seu DNA.
Exceto por algo chamado software. Desenvolver software não é complicado, mas complexo. Pode chegar a um ponto em que seria impossível conhecer e entender tudo isso. Embora a mudança de software seja fácil de fazer, os efeitos de tais mudanças não podem ser previstos uma vez que o software tenha crescido até um certo tamanho.
Por ser tão fácil mudar de software, sua direção pode mudar muito rapidamente e, ao contrário das mudanças no hardware (ou seja, automóveis), pode mudar muito mais rápido. Essa grande diferença de abordagem exige um modelo de trabalho diferente, que lide muito melhor com a complexidade.
A estrutura Cynefin
"A estrutura classifica os problemas enfrentados pelos líderes em cinco contextos definidos pela natureza da relação entre causa e efeito. Quatro delas - óbvias, complicadas, complexas e caóticas - exigem que os líderes diagnostiquem situações e ajam de maneiras contextualmente apropriadas. O quinto – transtorno – se aplica quando não está claro qual dos outros quatro contextos é predominante."
– Dave Snowden e Boone (2007)
O Scrum aborda isso com ciclos de desenvolvimento curtos e controle empírico do processo. No Scrum em larga escala, é essencial que as equipes colaborem entre si em hierarquias com o mínimo de transferências. A SAFe oferece muito disso, mas não muda uma organização existente em direção a mais simplicidade e, assim, ganhando mais transparência e flexibilidade. Em vez disso, na SAFe, os gestores são levados a acreditar que hierarquias transbordantes não são seu principal desafio.
Para que uma organização seja capaz de mudar de direção rapidamente, ela tem que ser desdimensionada e simples em seus níveis hierárquicos. É preciso trazer mais responsabilidade para as equipes. O PI-Planning no SAFe é feito para as próximas oito a 12 semanas e as capacidades são planejadas de acordo. Se as equipes se deparam com mudanças imprevistas, geralmente não precisam se planejar no esforço extra para superar essas mudanças. Isso leva à pressão de tempo e a problemas normalmente vistos em projetos tradicionais: equipes carregando trabalhos inacabados de um sprint para o próximo e, eventualmente, para o próximo PI. Como consequência, a confiança nas equipes diminui, o controle de fora aumenta. Exatamente o contrário do que se pretendia. E, em última análise, você está apaixonado pelo errado.
Razão #2: A situação é feita por Taylor
No final de 1800, Frederick W. Taylor defendeu um sistema de gestão científica para melhorar o desempenho dos trabalhadores, dividindo cada trabalho em seus movimentos individuais e eliminando aqueles considerados desnecessários e dando incentivos para o bom desempenho. Os princípios de Taylor não são projetados para resolver problemas complexos. A indústria automotiva ainda está infectada por essas ideias, levando a um pensamento falso sobre como abordar os problemas e, novamente, como se organizar.
O taylorismo leva à otimização local e a projetos organizacionais complexos. Isso impede que as equipes colaborem umas com as outras e, assim, impede que sua organização se torne mais flexível.
O SAFe como uma estrutura ágil de grande escala com seus vários níveis (Produto, Solução, Portfólio) dá aos gestores uma sensação de segurança de que é possível iniciar formas ágeis de trabalho em larga escala sem adaptar sua organização de linha. Em vez de manter hierarquias desnecessárias ou dimensioná-las, os gerentes devem identificar um modelo organizacional que facilite a colaboração entre as equipes e elimine a necessidade de gerenciar dependências. Quanto mais hierarquias você implementar, mais você se afastará de princípios como Customer Centricity e Adaptiveness.
Razão #3: Controlar o fornecedor como antes
Hoje, a maior parte do desenvolvimento para veículos é feito com e por fornecedores. Enquanto isso, os engenheiros das montadoras estão agindo mais como gerentes de projeto controlando o trabalho dos fornecedores do que fazendo eles mesmos.
Tradicionalmente, há essa vontade de controlar (também porque há um contrato entre os fabricantes de automóveis e seus fornecedores) levando a papéis e organização correspondentes. Com seu papel multinível e conceito organizacional, a SAFe dá aos gerentes automotivos uma impressão errada: eles acham que funções de coordenação apropriadas para gerenciar prestadores de serviços fazem sentido para garantir a entrega bem-sucedida de seu fornecedor.
Lean Software Development é principalmente sobre a eliminação de "desperdícios" porque eles limitam severamente a flexibilidade e adaptabilidade de uma organização de desenvolvimento.
Vários desses "desperdícios" estão em foco com os fornecedores: Hand-Off, Espera/Atraso e Processo Extra. A SAFe como framework não aborda uma organização tão enxuta evitando esses "desperdícios". Em vez disso, os gerentes são tentados a colocar os fornecedores em suas próprias ARTs e, em seguida, controlá-los em vez de passar parcialmente o controle para o fornecedor.
Conclusão
Em conclusão, a SAFe parece ser uma escolha óbvia para os Gestores Automotivos pelos motivos explicados acima. Pode ser, se os princípios básicos do Lean, juntamente com o design organizacional, forem considerados para qualquer mudança feita com base no SAFe, por exemplo:
- Concentre-se nos principais objetivos organizacionais dentro da organização: flexibilidade e adaptabilidade.
- A complexidade não pode ser tratada com práticas conhecidas do mundo complicado. Requer uma abordagem diferente para uma solução de software e, portanto, uma organização diferente.
- Prefira eliminar desperdícios na organização em vez de construir vários níveis organizacionais. O desdimensionamento de uma organização não está previsto na SAFe, mas ajudará muito a atingir as metas organizacionais.
- Transfira a responsabilidade para as equipes, a fim de apoiar a verdadeira colaboração e, portanto, reduzir a necessidade de coordenar ou mesmo controlar as equipes.
