Quando entrei no programa, ele havia passado por diversas tentativas sem atingir a prontidão para produção.
Cada esforço anterior obteve progresso parcial – mas nenhum levou o sistema a um estado que pudesse realmente ser implementado.
Não, a equipe não estava resolvendo os problemas técnicos errados; o verdadeiro problema period a falta de alinhamento a nível do sistema. O programa carecia de uma estrutura compartilhada para alinhar requisitos, integração e propriedade em todo o sistema. Quando fiz o meu próprio diagnóstico, três lacunas estruturais destacaram-se imediatamente.
Primeiro, os requisitos regulamentares nunca foram mapeados de ponta a ponta. Em um ambiente com muita conformidade, esse é um problema basic. As equipes estavam construindo recursos de forma diligente, mas ninguém tinha uma visão unificada de como esses recursos satisfaziam coletivamente as restrições regulatórias. Cada lacuna não mapeada tornou-se um forte bloqueador na implementação.
Em segundo lugar, a entrega foi altamente fragmentada. Cada equipe operava dentro de suas próprias ferramentas, ambientes e processos. A comunicação period inconsistente e informações importantes se perdiam entre as equipes. A propriedade existia no nível dos componentes, mas ninguém period responsável pela experiência de ponta a ponta.
Terceiro, o que tornou as coisas ainda piores foi que os próprios requisitos evoluíram. A equipe não tentou apenas entregar o escopo unique, mas também incorporar novos recursos e expectativas introduzidas ao longo do caminho.
O trabalho estava acontecendo e o progresso period visto. Mas o programa estava a optimizar para a prontidão native e não para a prontidão a nível do sistema e não cumpria a definição de concluído. E tal produto period impossível de enviar.
A recuperação começa com a compreensão da realidade
A primeira coisa que fiz foi uma auditoria completa das integrações – internas e externas – para mapear o que estava realmente funcionando versus o que apenas se supunha que estivesse funcionando. Só isso teve um impacto significativo.
Encontramos integrações em diferentes estados de maturidade, incluindo algumas desatualizadas ou incompletas, bem como outras que evoluíram de forma diferente de como foram refletidas no plano.
A auditoria também expôs dependências reais entre equipas e parceiros externos, e trouxe outras funções para o processo muito mais cedo, incluindo jurídicas, por exemplo, para rever contratos e declarações de trabalho quando necessário.
A partir daí, redefinimos como o progresso period medido. Em vez de acompanhar os marcos no nível do componente, cada ponto de verificação tinha que representar algo de ponta a ponta: totalmente integrado, testável e demonstrável. Não “esta parte está construída”, mas “este fluxo funciona”.
Realizamos demonstrações regulares sobre esses fluxos e coletamos suggestions inicial. Isso nos permitiu detectar problemas mais cedo, refinar a experiência gradativamente e evitar as típicas surpresas do estágio last.
Também introduzimos uma estrutura operacional comum: rastreamento compartilhado, caminhos de escalonamento claros, propriedade definida por componente e check-ins regulares entre equipes
É importante ressaltar que trabalhamos ativamente para revelar e gerenciar dependências, em vez de deixá-las bloquear o progresso posteriormente. Essa mudança por si só ajudou as equipes a passarem do trabalho em silos paralelos para a operação actual como um sistema coordenado.
Depois que as equipes passaram a ter uma estrutura compartilhada, visibilidade compartilhada e propriedade compartilhada, a execução deixou de ser fragmentada e o programa finalmente começou a se mover como um só, conforme planejado.
Simplificando a Execução sem Simplificar o Problema
Em um ambiente com muita conformidade, não é possível simplificar o problema. O que você pode fazer é simplificar a forma como a execução é gerenciada, tornando explícitas as compensações.
Os requisitos regulamentares não eram negociáveis. Os fluxos de transações financeiras tinham de ser à prova de balas. Outras áreas, especialmente partes de UX, tratamos como flexíveis. Também movemos alguns recursos para pós-MVP.
A chave aqui foi o alinhamento: todos precisam entender a hierarquia. Quando as equipes sabem o que deve navio versus o que pode se movem, eles param de debater prioridades sob pressão e começam a executar.
No entanto, ainda houve um momento em que o fracasso parecia perigosamente próximo. Ele ocorreu durante a configuração do ambiente de produção e a validação last. Devido a restrições regulamentares, o acesso a esse ambiente period extremamente controlado – qualquer mudança tinha de ser planeada com semanas de antecedência, totalmente documentada e aprovada por várias partes interessadas. Além disso, apenas pessoal licenciado tinha permissão para operar naquele ambiente, o que limitava significativamente os recursos disponíveis.
Então, acabamos em uma situação em que trabalhávamos com tempo limitado, visibilidade restrita, pequeno grupo de pessoas disponíveis e tolerância zero a erros. Para estabilizá-lo, passamos para um planejamento e coordenação extremos. Cada atividade que levava ao lançamento tinha um proprietário claro, dependências mapeadas explicitamente e um cronograma definido em nível granular. O lançamento em si foi coordenado quase minuto a minuto pelas equipes de engenharia, comercial e advertising.
Todo esse momento reforçou em mim que, em ambientes complexos, nenhuma equipe tem uma visão completa. A única maneira de operar sob esse tipo de pressão é reunir essas perspectivas desde o início e mantê-las unidas. A execução nesse ponto passa a ser menos uma questão de controle e mais de alinhamento sob pressão.
5 conselhos para o líder que herda a bagunça
O instinto, nos primeiros 30 dias, quando você herda um programa com falha, é começar a consertar as coisas imediatamente. Na minha experiência, esse instinto está errado. Seu primeiro objetivo é entender onde a realidade diverge das suposições.
- Audite o sistema como ele realmente existe. Mapeie integrações e dependências. Em sistemas complexos, você pode encontrar componentes desatualizados e ausentes, bem como dependências ocultas. Este passo por si só pode remodelar completamente a sua compreensão do programa.
- Esclareça a propriedade de ponta a ponta em todos os fluxos do sistema. Se ninguém for responsável pela experiência de ponta a ponta, o programa irá paralisar, independentemente da força das equipes individuais.
- Reconstrua requisitos de uma perspectiva de engenharia. Divida-os de acordo com sua intenção. Identifique o que é verdadeiramente inegociável, o que é flexível e o que evoluiu ao longo do tempo. Caso contrário, as equipes irão otimizar para diferentes interpretações de “pronto”.
- Identifique o verdadeiro caminho crítico. Concentre-se nos fluxos que determinam se o sistema pode realmente funcionar. Todo o resto deve ser sequenciado em torno disso.
- Mude a forma como você mede o progresso. Pare de rastrear atividades ou conclusão de componentes. Comece a avaliar se os fluxos de ponta a ponta funcionam, se estão em conformidade e se estão prontos para produção. Essa mudança muda rapidamente o comportamento da equipe.
Nos primeiros 30 dias, seu trabalho é tornar a ambigüidade visível, alinhá-la e gerenciá-la de forma proativa. Depois que a propriedade, os requisitos e a realidade estiverem alinhados, a execução se tornará muito mais previsível.