Tem alguma coisa mais alusiva a controle do que essa imagem? Precisamos falar sobre controle, sobre governança para ser mais preciso.
Faz algum tempo, o Gartner tem falado bastante dos “Fusion Teams”: times multidisciplinares que combinam especialistas das áreas de negócio e especialistas de TI para entregar soluções mais rapidamente. Apenas recapitulando, a grande diferença dos “Fusion Teams” em relação a outras gerações de times multidisciplinares que sempre existiram nas organizações é o fato dos times serem liderados pela área de negócio. O negócio planeja, constrói, entrega e mantem as soluções criadas pelos “Fusion Teams”, e essa responsabilidade inclui atingir metas de resultado e metas de tecnologia também.
Segurança, escalabilidade, qualidade, alinhamento arquitetural, são, sim, responsabilidade dos “Fusion Teams”.
É fato também que os especialistas de TI nos “Fusion Teams” não são mais exclusivamente alocados pela organização de TI. Muitas áreas de negócio já vem contratando profissionais de TI (colaboradores ou prestadores de serviço terceirizados) no mercado.
Muitos clientes no Brasil já operam com esse modelo de entrega distribuído, utilizando rótulos variados, mas com essa mesma missão: entregar o mais rápido possível, ser flexível e ajustar rapidamente ao contexto, construir soluções o mais perto possível de onde elas serão consumidas.
Digamos, então, que trabalhar com “Fusion Teams” não é mais uma grande novidade. A questão agora é como sair dos pilotos iniciais e escalar esse modelo de entrega, levar a todas as áras de negócio, multiplicar a quantidade de times.
Como assegurar que as soluções entregues pelos “Fusion Teams” estão atendendo a padrões de arquitetura, segurança e compliance?
Essa foi a questão mais recorrente nas nossas interações com CIOs neste mês. Vale lembrar que esses riscos sempre estiveram (e sempre estarão) presentes. Por muito tempo, inclusive, foi a justificativa que dávamos para operar com uma TI centralizada, e para condenar o que muitos ainda se referem como “Shadow IT”: aquelas pessoas que desenvolviam (desenvolvem) soluções nos departamentos sem a anuência oficial de TI.
Nem tanto ao céu, nem tanto a terra.
Primeiramente, é preciso desmistificar essa ideia de times autônomos. Já falei sobre isso no primeiro post que fiz aqui no blog (vide “A ascensão e queda do modelo Spotify“). Não existe autonomia total, mas também não podemos insistir num modelo onde tudo é absolutamente controlado e construído pela TI central. Vamos à figura abaixo:
No lado esquerdo, a “autonomia total” nos expõe perigosamente a alguns riscos, a saber:
- Desalinhamento de prioridades na empresa, redundâncias, descontrole de gastos.
- Inconsistências importantes na forma como a experiência do cliente é entregue, seja cliente final ou cliente interno.
- Questões de compliance, privacidade (lembram da LGPD?), vulnerabilidades de segurança.
No lado oposto, a “ditadura de TI” onde o excesso de comando-controle traz:
- Uma burocracia insensível às necessidades do negócio.
- Uma tomada de decisão unilateral e opaca.
- Controles e padrões desatualizados, que podem não acompanhar a velocidade com que tudo está acontecendo no negócio.
Vejam que tanto num extremo quanto no outro, a geração de valor é impactada. Por caminhos e motivos diferentes, a “autonomia total” e a “ditadura de TI” não ajudam a gerar valor.
Como muitas coisas na vida… (meu momento aristotélico), a solução está no equilíbrio, no caminho do meio.
Quando falamos em governança adaptativa estamos indicando uma abordagem estratificada, com diferentes estilos de governança, cada um adaptado aos diferentes contextos que encontramos nas organizações.
“O conceito de Governança Adaptativa traz consigo duas ideias fundamentais: adaptação ao contexto (e não abordagens do tipo “one-size-fits-all”) e co-criação (e não modelos e regras impostas por TI)
A Governança Adaptativa visa entregar:
- Maior velocidade e agilidade.
- Soluções arquitetonicamente sólidas, seguras, e escaláveis.
- Decisões colaborativas e transparentes.
Vejam a figura abaixo:
Cada contexto será aplicado conforme a complexidade/criticidade dos processos de negócio suportados e a maturidade dos times envolvidos na execução.
Processos “core” muito provavelmente permanecerão sobre gestão centralizada de TI na grande maioria das organizações, no estilo “Control“. É o caso de sistemas de ERP, por exemplo. Times que estão evoluindo plataformas de relacionamento com clientes se encaixam bem no estilo “Outcomes“. Times que estão construindo novas jornadas de experiência podem eventualmente trabalhar numa camada com um pouco mais de liberdade, no estilo “Agility“. Times de inovação, onde existe um alto grau de experimentação, certamente precisarão de um estilo “Autonomous“. Times que alcançaram maturidade, medida pela adoção gradual das melhores práticas definidas pela área de TI em cada campo de conhecimento, podem ter mais autonomia.
Governança adaptativa funciona com base em métricas que devem ser definidas nas quatro dimensões de performance de times ágeis: velocidade, valor, qualidade e efetivividade organizacional. Peter Drucker sempre dizia: quem não mede, não gerencia.
Governança adaptativa funciona com controles permanentes e controles temporários. São os indicadores em cada dimensão de performance que sinalizarão a necessidade de ativar ou desativar controles. Ou seja, “Fusion Teams” trabalhando numa mesma “tribo” podem estar sob controles diferentes em função do status de seus indicadores de performance.
- Indicadores indo bem, tudo certo, você tem maturidade para trabalhar com mais liberdade.
- Indicadores com tendência preocupante, sinto muito, você vai ser mais controlado e vai, sim, perder velocidade nas suas entregas.
Com grandes poderes vêm grandes responsabilidades.
Os estilos serão descritos de forma diferente em cada organização por um motivo óbvio: não existem organizações iguais. O que é comum são as definições que precisam ser feitas, ou seja, o que está em jogo? Quais decisões poderão ser tomadas em cada contexto? Quais os limites de atuação dos diferentes times (TI central e “Fusion Teams”)?
Quando vocês começarem a identificar os diferentes contextos na sua organização e associar aos diferentes estilos de governança, tenham em mente os seguintes temas:
- Decisões de investimento: qual a alçada do time? até quanto cada time pode gastar? quais instâncias deverão ser acionadas caso o time não tenha autonomia de decisão? qual é o processo de aprovação que deve ser seguido?
- Risco: que tipos de risco, que tamanho de risco, o time pode decidir? qual o “apetite a risco” permitido?
- Contratação: os time podem fazer contratações de recursos e/ou serviços? quais? em quais situações? o que devem fazer caso não tenham autonomia para contratar?
- Seleção de tecnologia: os times podem decidir sobre qual tecnologia usar? em quais situações? podem fazer POCs? como proceder caso apareça uma necessidade não coberta pelas tecnologias adotadas na organização?
- Alinhamento arquitetural: os times têm a liberdade de criar arranjos arquiteturais que não estejam alinhados com as arquiteturas de referênca definidas pela TI? quais são os limites dessa liberdade?
- Fronteiras funcionais: que tipo de funcionalidades podem ser criadas pelos times? qual o limite entre o que deve ser feito pela TI central e o que pode/deve ser feito pelos times distribuídos? como proceder caso apareça uma necessidade que envolve funcionalidades que são suportadas/mantidas pela TI central?
Faz sentido pra vocês? Comentem, perguntem, participem.
Abraços a todos,
Mangi.
The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.
Comments are closed
2 Comments
Mangi faz muito sentido o modelo exposto, no entanto, gostaria de sua explanação quanto a ausência dos critérios citados para implementação desse modelo. Como poderíamos endereçar essa visão se a organização não tiver a clareza qto a complexidade/criticidade dos seus processos de negócio e os times envolvidos na execução não tiverem a maturidade esperada?
Olá Suenia! Obrigado pela participação!
Em organizações com baixa maturidade, muito provavelmente você terá que começar com estilos de governança mais conservadores. Ou seja, mais controle. Mas é importante começar a pavimentar o caminho para que o modelo de entrega seja flexibilizado e distribuído. O primeiro passo é iniciar uma jornada de transformação Ágil e avaliar continuamente o progresso através dos indicadores que mencionei no post.
Quanto à falta de clareza sobre a complexidade/criticidade dos processos de negócio, trata-se realmente de uma questão preocupante. Essas definições são essenciais para a definição do plano de continuidade do negócio, para gestão de risco. Isso vai além da discussão sobre governança. Muitas empresas enfrentam esse problema, e na maior parte das vezes TI acaba tendo que tomar a frente nessas definições. Muita coisa importante depende disso, além do plano de continuidade de negócios: definição dos níveis de serviço, estratégias de aplicação, governanca, alocação de recursos, gestão de orçamento e performance.