Formando equipes de TIC de alto desempenho

Este artigo apresenta um resumo do processo de reestruturação da área de desenvolvimento de sistemas da IMA. Sua publicação tem como objetivos contar como foi realizada esta reestruturação e incentivar outras empresas públicas e privadas de Tecnologia da Informação e Comunicação (TIC) a seguir processos semelhantes. 

Tudo começou em fevereiro de 2017. Naquele momento, tentávamos encontrar uma maneira de atender às necessidades tecnológicas da Prefeitura de Campinas, ao mesmo tempo em que buscávamos oportunidades para desenvolver produtos que poderiam ser utilizados por outras prefeituras. Nosso foco principal era desenvolver um modelo de equipes capazes de produzir soluções tecnológicas a partir da identificação de um problema e não produzi-las exclusivamente de acordo com a demanda. Queríamos nos dar a chance de refletir sobre cada desenvolvimento e buscar a melhor solução em cada caso, de forma integrada e definitiva.

Grandes prefeituras possuem estruturas administrativas fortemente "departamentalizadas" (1). Nessas administrações, cada equipe enfrenta seus desafios diários de forma totalmente desacoplada dos demais. Os problemas que surgem, na maioria das vezes, são resolvidos sob a ótica somente de um determinado departamento e não com a visão no todo ou no principal interessado - o cidadão. Isto decorre do excesso de burocracia e da falta de recurso (humano e financeiro) para criação de soluções integradas, que contemplem revisão e automação de processos e reaproveitamento e integração com soluções pré-existentes. Assim, o resultado tende a ser a construção de um novo sistema, que não recebe nem fornece informações para outros sistemas, que é útil somente para um departamento, sem ser aproveitado por outro, e com ciclo de vida curto ou com baixo valor agregado. Desejávamos construir sistemas, de forma diferente.

Conversando com a gerente de soluções da IMA, Daniela Fumes, percebemos que as falhas apontadas acima ocorriam porque a estrutura de desenvolvimento não estava preparada para identificar a causa do problema que estávamos tentando resolver e tampouco estava preparada para resolvê-lo de forma multidisciplinar, ou seja, olhando também para outros departamentos, além daquele que havia solicitado o desenvolvimento da tecnologia. Diante desta análise, surgiu a ideia de criarmos um novo formato de estrutura para a área de desenvolvimento. Demos a ele o nome de S.O. (solution owner), uma evolução do P.O. (product owner). O S.O. seria aquela pessoa responsável por receber uma demanda de desenvolvimento de sistema, identificar o problema que se pretende resolver com aquela demanda e construir uma solução que vai além do desenvolvimento de um produto. A solução criada pelo S.O. envolveria a identificação da causa raiz do problema, através do mapeamento dos processos, ainda que entre departamentos, e o desenvolvimento da tecnologia necessária para solução daquele problema. A solução final poderia ser composta de sistemas e aplicativos, revisão de processos e legislação, reaproveitamento de outros serviços, criação de painéis para acompanhamento da evolução do problema e a integração entre as áreas. Esta última, de extrema importância para a administração pública, uma vez que diminui a burocracia e supera o problema da falta de recurso humano e financeiro.

Criado o conceito do S.O., precisávamos testar nossa hipótese. Montamos uma equipe dentro desta nova estrutura, para solução de um problema específico da prefeitura de Campinas: a necessidade de deslocamento do cidadão até a repartição pública para acesso aos serviços públicos. A equipe, formada por um S.O., um líder de projeto, uma designer e quatro desenvolvedores, identificou que para resolver este problema seria necessária a criação de um aplicativo para acesso aos serviços públicos da prefeitura. Saberíamos que nossa tese estava correta se o S.O. construísse uma solução útil para o usuário final e que superasse o problema da departamentalização da prefeitura. Foi isto que ocorreu. Em 14/07, aniversário da cidade de Campinas, o aplicativo do Portal do Cidadão foi lançado para as plataformas Android e iOS. Seu desenvolvimento agregou serviços integrados de diversas áreas da administração municipal, inclusive serviços de órgãos externos à administração direta. Isto só foi possível porque o S.O. possuía a visão do problema e não ficou focado no desenvolvimento de um sistema para um único departamento. Nossa hipótese estava correta.

Precisávamos expandir este modelo para todas as equipes, com mais de cem pessoas e diversos perfis técnicos, entre eles: analistas, desenvolvedores, DBAs e designers. Entretanto, este modelo estava fortemente relacionado à construção de soluções para novos problemas. Mas ainda tínhamos um legado de cerca de cem sistemas, desenvolvidos ao longo do tempo em plataformas tecnológicas distintas. Estes sistemas estavam em uso pelas secretarias municipais da prefeitura de Campinas, sem previsão de encerramento do seus ciclos de vida. Era necessário, portanto, encontrar uma solução para a manutenção e sustentação dos sistemas em uso. Ao mesmo tempo, o formato de S.O. parecia não se encaixar neste modelo.

Em 26/05, uma sexta-feira, por volta das 19h, surgiu uma ideia: dividiríamos as equipes de desenvolvimento em duas novas equipes. Uma seria responsável pelo desenvolvimento de novos produtos, utilizando o formato do S.O., e a outra seria responsável pela manutenção e sustentação dos produtos. Toda nova demanda de desenvolvimento de sistema seria avaliada e desenvolvida por uma nova equipe de S.O., criada especialmente para identificar qual problema se pretendia resolver com aquela demanda. Ao término do desenvolvimento e consequente solução do problema toda a tecnologia criada passaria a ser suportada pela segunda equipe, com estrutura tradicional de desenvolvimento e gestão de projetos de TIC. Este desenho nasceu durante uma ligação telefônica entre eu e a Daniela Fumes e o fim de semana foi cheio de novas ideias, trocas de mensagens e vontade de apresentar este novo modelo para todos na IMA.

Durante o fim de semana, fizemos um esboço de como ficaria esta nova estrutura, para apresentar para a diretoria já na segunda-feira. Estávamos muito empolgados e queríamos colocar tudo em prática o quanto antes. Com a aprovação da diretoria, envolvemos no processo o gerente de infraestrutura - Rodolfo de Santi - que ficaria responsável pela continuidade dos sistemas, e apresentamos para ele nossa proposta, a qual foi aprovada também. Com os dois gerentes confiantes de que o modelo fazia sentido, partimos para a ação. Ainda precisávamos definir tudo, desde os nomes da novas gerências até a composição das equipes.

Em 07/07, dia da Festa Junina da IMA, enquanto a música tocava no estacionamento e as barracas começavam a perceber a movimentação dos funcionários, eu, Daniela Fumes e Rodolfo de Santi nos reuníamos para definir a estrutura das duas gerências. Chegamos à conclusão de que haveria necessidade de termos uma área específica cuidando de padronização e garantindo a qualidade de tudo que fosse construído dali em diante, precisaríamos também de uma área trabalhando com técnicas de inteligência artificial, para desenvolvimento de soluções com alto valor agregado, uma equipe focada em usabilidade, que passamos a chamar de CX (citizen experience, ou seja, experiência do cidadão, em referência ao termo UX comumente utilizado na computação), além das equipes de desenvolvimento e hospedagem. Com isto, chegamos à definição final de como ficariam os times.

Dentro da gerência de soluções, definimos um time de arquitetura, responsável por definir padrões de desenvolvimento de produtos; capacitar as equipes de desenvolvimento a utilizar os padrões definidos; para cada novo projeto, definir tecnologias e métodos de desenvolvimento; pesquisar tecnologias que melhorem o desempenho das áreas de desenvolvimento; gerenciar o patrimônio digital; avaliar oportunidade para participação das equipes em seminários, cursos e treinamentos; definir ferramentas para uso interno das equipes; definir e implementar padrões de identidade visual e usabilidade dos produtos; e definir e implementar ferramentas de suporte ao ciclo de desenvolvimento e provisionamento dos produtos. Ainda dentro da gerência de soluções, definimos um time, que na verdade seriam vários times de S.O., criados sempre que houvesse necessidade de resolver um novo problema, responsável por pesquisar e implementar recursos de inteligência artificial nos produtos; desenvolver painéis analíticos; criar ferramentas para simulação e otimização de modelos de gestão; realizar levantamento para definição de requisitos de desenvolvimento dos produtos; desenvolver, testar e documentar os produtos; e capacitar equipe de sustentação e equipe de suporte a dar continuidade ao produto, durante seu ciclo de vida.

Para a gerência de sustentação, definimos um time de manutenção e evolução de sistemas, que assim como o time de S.O. seriam vários times, entretanto divididos por assuntos da administração pública, responsável por realizar levantamento para definição de requisitos de evolução dos produtos; corrigir de forma ativa e reativa erros encontrados nos produtos; definir roadmap de evolução do produto; desenvolver, testar e documentar os produtos; capacitar equipe de suporte em relação às evoluções produzidas; disponibilizar evoluções para publicação; capacitar usuários na utilização dos produtos; realizar suporte técnico e operacional aos usuários; criar mecanismos que permitam os usuários realizarem auto-atendimento; e disponibilizar métricas de suporte para as equipes de desenvolvimento. Por fim, também na gerência de sustentação foi definido um time de hospedagem, responsável por implantar novos produtos e atualizações; garantir a disponibilidade dos produtos e sistemas dentro das características e SLAs especificados; garantir a segurança dos produtos e dos seus dados; ajustar a infraestrutura para suportar as variações de demandas sazonais e/ou ao volume de crescimento (especialmente em nuvem); acompanhar e identificar as origens de notificações e mensagens de erro; analisar continuamente o desempenho para identificar gargalos de sistemas e de infraestrutura; interagir com equipes de desenvolvimento para sugestões de evolução; e atualizar a plataforma tecnológica, com adaptação de scripts, testes de carga e testes funcionais de novas versões.

Um aspecto interessante desta estrutura, especificamente dos times de manutenção e evolução dos sistemas, dentro da gerência de sustentação, é que eles foram agrupados de acordo com assuntos de interesse da administração pública e não por departamentos ou tecnologia, como se faz tradicionalmente. Os assuntos elencados foram: Administração Pública; Arrecadação e Fiscalização; Gestão de Pessoas; Social; e Transformação Digital.

Concluídas as definições dos times, passamos a definir as habilidades técnicas necessárias em cada time. Para tanto, foi construído um formulário eletrônico, com cerca de 100 perguntas, que cada funcionário preencheu conforme sua experiência profissional. As perguntas avaliariam o conhecimento de cada um em diversas áreas, como programação, banco de dados, usabilidade, gestão de projetos, entre outras. Cada pergunta deveria ser respondida com uma das seguintes respostas alternativas: gostaria de aprender; já fiz alguma coisinha; me viro mais ou menos; manjo razoavelmente bem; e domino quase tudo. As respostas seriam livres e sem necessidade de provar que a pessoa tinha realmente aquela experiência.

O formulário ficou disponível por cerca de duas semanas e ao final os dados contendo as respostas de todos os funcionários foram exportados para avaliação. Ao iniciarmos a avaliação das respostas, verificamos que realizar a distribuição das equipes de forma manual, tendo que casar o perfil técnico de cada um com as habilidades necessárias de cada time, seria um processo muito trabalhoso e sujeito a erros. Tivemos a ideia, então, de construir uma ferramenta automatizada, que leria as respostas dos funcionários, compararia com as habilidades necessárias e faria a distribuição da equipe. Com isto, aceleraríamos o processo e faríamos dele um processo transparente e justo.

Depois de realizar a distribuição de forma automatizada, teríamos ainda, que escolher os coordenadores das quatro áreas. Naquele momento, tínhamos a pretensão de continuar a reestruturação das equipes da mesma forma que tínhamos conduzido até aquele momento: com objetividade, lógica e sem privilégios. A forma de escolha dos coordenadores não poderia ser diferente do restante do processo. Novamente surgiu a ideia de seguirmos um caminho diferente do habitual. É comum que os chefes escolham quem assumirá uma posição vaga dentro da sua equipe. Optamos por inverter esta lógica e permitir que as quatro equipes escolhessem quem seriam seus líderes, sem nenhuma intervenção da gerência e diretoria. Para garantir que este modelo funcionaria adequadamente e que no final tivéssemos boas escolhas do ponto de vista da liderança, envolvemos a área de recursos humanos e pedimos para eles nos ajudarem. Edna Zague e sua equipe sugeriram que a seleção dos coordenadores fosse realizada após apresentação de conceitos de liderança, para que no momento da escolha do líder, as equipes levassem em consideração quais características seriam importantes para alguém ocupar aquela posição.

Em 17/07 reunimos todos os funcionários das áreas de desenvolvimento e data center no teatro da IMA para apresentar os resultados deste trabalho. Naquele momento eles não sabiam que haviam sido alocados nas equipes de acordo com o perfil que haviam preenchido no formulário e não sabiam que escolheriam seus líderes. Começamos a apresentação monstrando a importância e os objetivos da mudança. Ainda, contamos como ocorreu todo o processo. Seguimos apresentando as áreas e suas responsabilidades. Na sequência entregamos um formulário com os nomes dos funcionários alocados nas áreas e pedimos para que eles votassem naquela pessoa que considerasse a melhor para liderar a área em que cada um estava alocado. A votação ocorreu de forma tranquila e os quatro novos coordenadores foram selecionados pela própria equipe, de forma democrática e transparente.

Enfim, concluímos a primeira etapa do processo de transformação da IMA, mais precisamente da forma como a IMA desenvolve tecnologia para o setor público brasileiro. Iniciaremos em breve a segunda etapa da mudança, que será a definição do processo de avaliação de desempenho. Pretendemos desenhar um modelo de avaliação mais objetivo, que valorize características individual e coletiva. Ainda, que nos permita enxergar quais deficiências precisaremos trabalhar junto as equipes, de forma que elas construam soluções tecnológicas inovadoras e de alto valor agregado. Queremos também que a avaliação de desempenho ocorra com mais frequência, de forma que as deficiências sejam rapidamente identificadas e corrigidas.

Temos muito trabalho pela frente, mas não descansaremos enquanto houver oportunidade de aumentar a eficiência da IMA para que ela disponibilize para Campinas e para todo o país serviços integrados e com foco na principal razão da sua existência: o cidadão.

REFERÊNCIAS

(1): Bruna Puga. Estrutura e Organização da Administração Pública. Fonte: https://brunaazzari.jusbrasil.com.br/artigos/321543632/estrutura-e-organ...