Fatos e aprendizados do meu período como CTO na Guiando

Agora em fevereiro, depois de 18 meses, fechei meu ciclo como CTO na Guiando para integrar o conselho consultivo da empresa.

Aqui, gostaria de compartilhar algumas lições aprendidas (afinal, são as cicatrizes que contam a história do guerreiro. Certo?), momentos importantes e conquistas. Trata-se de recortes de ideias. Antes de começar, entretanto, gostaria de externar meu profundo agradecimento a toda a empresa, com especial carinho ao meu time.

Ingressar como executivo na Guiando foi um grande desafio e uma ótima oportunidade. Depois de anos trabalhando para desenvolver a indústria moveleira nacional, tive a honra de ajudar a “fazer melhor” na empresa referência brasileira no fornecimento de soluções para gestão de custos faturados.

Como me tornei CTO na Guiando

Ao longo dos anos, tive a oportunidade de acumular alguma experiência como executivo de tecnologia – essa foi a base para que eu pudesse vislumbrar a possibilidade de ocupar a posição de CTO.

Com a Guiando, especificamente, comecei em um processo regular de consultoria. Em bem pouco tempo, entretanto, ventilamos a possibilidade de buscarmos um formato de trabalho diferente.

Segue depoimento (no meu Linkedin) do Rodrigo Schittini, CEO da empresa.

Fui apresentado ao Elemar quando ele veio prestar uma consultoria de tecnologia pontual na Guiando. Ele chegou com fortes credenciais técnicas e nossos desenvolvedores ficaram absolutamente extasiados por poderem usufruir de seus conhecimentos.

Em poucas conversas percebi o quanto ele conseguia trazer sua profunda visão técnica de tecnologia para discussões de negócio e estratégia, e isso caiu muito bem para nós. Na verdade considero este seu maior diferencial (a despeito de ser um dos mais respeitados desenvolvedores do país). Tanto que em menos de três meses estávamos fechando acordo para que se tornasse nosso CTO.

CTO, mas com prazo de validade

Desde o primeiro momento, acertamos que seria CTO na Guiando em um período determinado. Minhas metas eram:

  1. Ajudar a empresa a superar alguns desafios na área de tecnologia;
  2. Preparar meu sucessor (um dos sócios da empresa)

Cumprimos ambos os desafios!

São sempre pessoas…

Minha primeira ação como CTO foi conversar, individualmente, com todos os integrantes do meu time. Foram dezenas de ótimas discussões onde compartilhei algumas ideias, mas, acima de tudo, fiz questão de ouvir.

Genuinamente, queria saber o “momento” de cada membro do time. Queria saber o que estava agradando e o que poderia ser melhorado. Queria entender para onde estavam olhando e entender se a direção era a mesma que eu buscava.

Surge o Núcleo de Inteligência de Dados

Durante as entrevistas, tive a grata surpresa de encontrar, ali, no meu time, um grupo maduro de cientistas de dados. Gente com formação academica invejável e com uma vontade de trabalhar única!

NOTA: Tenho constatado e confirmado que o “caminho” para a transformação digital é, no mínimo, pavimentado por ciência de dados.

Meu primeiro movimento prático foi ajudar a empresa a “oficializar” o grupo e tangibilizar resultados através de automações, padronização e insights.

O núcleo de inteligência de dados conseguiu, em bem pouco tempo:

  1. Padronizar e aprimorar significativamente a qualidade as análises de oportunidades de economia que fornecemos a nossos clientes;
  2. Automatizar processos operacionais e táticos de tomada de decisão (sem que ninguém percebesse, passamos a ter inteligências artificiais tomando decisões que, até recentemente, eram exclusividade de inteligências humanas).
  3. Concebemos modelos alternativos de análise ampliada de mercado, com potencial de gerar benefícios em série para todas as cadeias.

Análise aumentada de dados na rotina

Um impacto indireto da formação do núcleo de inteligência de dados foi a formação de um data warehouse consolidando informações e habilitando análises ainda mais avançadas.

Acredito e tenho buscado implementar práticas de análise aumentada. O que antes eram consultas complexas se converteram em análises de dados em cubos.

Paz entre áreas técnicas e de negócios

Uma das reclamações recorrentes, quando assumi a diretoria técnica, estava, na dificuldade de estabelecer um cronograma organizado de trabalho. Resultado:

  • Time de negócios insatisfeito porque prazos e acordos não eram cumpridos
  • Time de tecnologia insatisfeito porque as prioridades mudavam todo o tempo.

O que eu fiz? Para começar, transferi a responsabilidade de priorizar atividades para a área de negócio (Se uma demanda ganha prioridade, é importante que a área de negócios entenda que outra demanda está perdendo). Além disso, blindei o desenvolvimento de interrupções.

Outra ação importante: Rompemos com a cultura dos “puxadinhos” (soluções baratas, frequentes, com baixo custo de desenvolvimento e alto custo de manutenção).

Entre mortos e feridos, todos sobrevivemos. E estamos melhores!

Negócio > Produto > Tecnologia

Digo e repito: De nada adianta código bom e produto ruim. De pouco adianta ter um ótimo produto e um péssimo negócio.

Em meu período como executivo na Guiando, iniciamos e aprimoramos diversos processos de gestão de negócios digitais. Esse passo foi fundamental para que as prioridades fossem bem definidas (custo de não ter, como aspecto mais relevante).

Kanban > Scrum

Não quero iniciar aqui um embate ideológico. Entretanto, quando assumi a Guiando encontrei uma empresa que era fiel a práticas do Scrum, mas não tinha sucesso.

Ando dizendo que estou ficando mais velho e mais “cansado” de complexidades. Há algum tempo, achava Scrum uma maravilha. Porém, de uns tempos para cá, tenho o achado “pesado demais”. Na Guiando, resolvemos adotar Kanban e tenho grande orgulho de contar com relatos do Fernando Paiva (novo CTO da Guiando) sobre nossa experiência nesse processo.

Outro ponto de imenso orgulho é que vimos Kanban se espalhando pela empresa.

Adeus, time de Sustentação!

A Guiando possuia dois times de tecnologia. Um para cuidar do desenvolvimento de features, outro para corrigir bugs e manter o sistema funcionando! Acabamos com isso!

Sempre percebi times de sustentação como “baldes de processo” (um dia eu conto essa história em um post). Se alguém criou um bug, que o corrija.

Essa medida gerou um ruído gigante nos primeiros dias. Nossos indicadores de produtividade foram para o piso! Quase fui demitido! Mas, … superamos.

No pain, No gain!

Na Promob, os maiores saltos de qualidade na ferramenta ocorria quando alguém das lideranças técnicas resolvia fazer um “projetinho” para um cômodo da casa. Por causa disso, vi com muito bons olhos quando resolvemos, por indicação do CEO, assumir um dos processos críticos da Guiando. ideia foi que sentíssemos a “dor” gerada por nossas ferramentas em um dos processos mais críticos (e com maior impacto no dia-a-dia da organização). Funcionou!

Melhoramos processos e ferramentas. Nossos indicadores operacionais nessa atividade são considerados, hoje, em nível de excelência.

Testes! Testes! Testes Continuamente

Quando assumi a Guiando, tinhamos menos de 1% do código coberto por testes de unidade. Hoje temos pouco mais de 20% (ainda pouco), mas temos muito menos relatos de bugs (o que me leva a acreditar que começamos a testar as coisas certas). Além disso, nosso build passou de otimizado para contínuo.

Essas duas ações, associadas com a adoção do Kanban, reduziu muito o intervalo em que fazemos Deploys.

Acredito que em pouco tempo conseguiremos Deploy contínuo também.

Pés no chão, olhos no futuro

As soluções da Guiando estão bem a frente do mercado. Mas, sabemos e queremos fazer muito mais.

Uma das ações de minha gestão foi iniciar o processo de desenvolvimento da nova geração de produtos da empresa.

Buscamos três pilares:

  1. UX incrível
  2. Orientação a fluxos de trabalho
  3. Uso sólido de inteligência de dados

Acredito seriamente que, em breve, a Guiando vai dar seu próximo passo rumo ao crescimento exponencial fundamentada nessa nova geração de produtos.

OKRs

Pessoas! Sempre pessoas! Entendo que elas precisam de metas. Aliás, concordo com professor Falconi que define liderança como “Bater metas, com o time, fazendo o certo”.

Gosto dos OKRs por eles nos ajudarem a olhar para frente, sempre, e de forma alinhada.

Iniciamos alguns pilotos com OKRs na nossa área. Nesse ano, a prática está espalhada por toda organização, sendo ferramenta fundamental, inclusive, de conexão do conselho com a operação.

Mais envolvimento com a comunidade

Instituímos a prática de organizar Meetups regularmente compartilhando o que aprendemos em gestão de negócios digitais, desafios tecnológicos e análise de dados para toda a comunidade de Juiz de Fora. Acreditamos que uma comunidade forte deixa a empresa ainda mais forte.

Finalizando

Essas são umas poucas notas de muitas iniciativas (com acabativas) que tivemos na empresa no período em que tive o privilégio de estar a frente do time técnico da empresa. Tudo aqui ocorreu porque tive apoio de muita gente competente e esforçada. Tive também todo o apoio que precisei do CEO e das demais diretorias.

Sou profundamente grato a Guiando por me permitir adicionar algumas novas (ótimas) cicatrizes. Agora, minha missão, como já disse, é colaborar com a empresa como membro do conselho.

Obrigado, Guiando! 2019 é ano de superar metas e de gente mais que feliz!

5 Comentários
  1. Fabio Silva Lima

    Parabens Elemar, mudancas de mindset, organizacao e metas atingidas.

  2. Raffaello

    Excelente artigo. Só acho que poderia ser um pouco mais realista mostrando dificuldades e aprendizados. Tá um pouco conto de fadas de felicidade.

    1. Elemar Júnior

      Antes de qualquer coisa, muito obrigado pelo feedback honesto.

      TL;DR – No final das contas, todos os desafios estão relacionados com a capacidade de trabalhar com gente. Aliás, essa é a grande lição. Um CTO é, acima de tudo, alguém que trabalha com gente objetivando os melhores resultados.

      Tenho tendência de ser “posisitivo” e entendo que os percalços são parte do processo (Recomendo que veja meu post sobre PDCA)

      Mas, atendendendo a pedidos, vamos a um pequeno compilado de dificuldades.

      Nas entrevistas
      Além de encontrar um time incrível de cientistas de dados, identifiquei duas grandes dores de cabeça.

      1. Gente “comprometida demais”, disposta a longas jornadas de trabalho, algumas vezes invadindo a madrugada
      2. Apoio incondicional e unânime a gestão imediata

      Por que isso é um problema? Porque tive que gastar algum tempo para convencer as pessoas que trabalhar horas demais não significa (e, na prática, não estava significando) resultados. Além disso, como diria uma de minhas mentoras, gestor com aprovação unânime geralmente indica algum “lack” de cobrança (e foi na prática).

      Nas entregas do time de inteligência de dados
      Padronizar e automatizar processos de valor para o negócio implica em mudar a rotina das pessoas. No nosso cenário, as mudanças aconteciam em áreas onde eu não tinha controle.
      Durante um bom tempo, enfrentamos algumas resistência na adoção das soluções que estávamos desenvolvendo. Foi necessária uma boa dose de paciência e foco nos resultados para levar o projeto adiante.

      Aproximação entre áreas técnicas e de negócios
      Fazer o time de negócios priorizar foi um ENORME desafio. Primeiro, porque tive que “aculturar” o time técnico a falar a língua do negócio. Segundo, porque o time de negócios, embora esforçado, não costuma ser tão disciplinado.

      Em uma primeira tentativa, trouxemos a “gestão de produto” para dentro da área técnica. Houve desgaste em demasia. Algumas relações ficaram bem difíceis e foi necessário um bocado de política e persistência para prosperar.

      Adotar Kanban
      Um dos meus imediatos era absolutamente fã de Scrum e foi extremamente resistente a mudança. Mais uma vez, o segredo foi focar em números e cobrar consistentemente por resultados.

      No final, a ideia de um fluxo de entrega contínua acabou sendo um argumento insuperável. ‘

      Adeus sustentação
      Aqui as dores foram enormes e foi o momento mais delicado da minha gestão. O volume de bugs era tão alto durante essa fase que chegou a travar a inclusão de features novas.

      Houve uma ocasião, em especial, que fui chamado para um “jantar” na casa do CEO para explicar o que, de fato, eu tinha em mente.

      Mais uma vez, o segredo foi um bocado de persistência e método. Indicadores ajudam, sabe?

      Testes!
      Demorei quase um ano para conseguir trazer o time para a cultura dos testes. O fim da área de sustentação acabou me ajudando nessa iniciativa.

      Planejar o futuro
      A “rotina come a inovação”. Essa frase é muito verdade em todos os cenários. Na Guiando, não era diferente. Até eu sair ainda não tinha conseguido sensibilizar todos de que os projetos dos produtos novos precisam ter precedência sobre o que está em produção.

  3. Fernando Freitas Alves

    Gostei muito de ouvir sua experiência. Você poderia dar mais detalhes sobre como foi acabar com a cultura dos puxadinhos ? Já passei por isso, mas até hoje me parece um fantasma que a qualquer momento volta pra me assombrar.

  4. Eduardo

    Mais uma vez, parabéns Elemar!

    Se lembrar de mais algo que leve a escrever “FATOS E APRENDIZADOS DO MEU PERÍODO COMO CTO NA XPTO II, III, etc” sempre é muito bem vindo e agregador o conteúdo.

    Um dos pontos que achei mais interessante foi a questão da eliminação de um time específico para “sustentar”/corrigir bugs. Recentemente fizemos algo parecido, não existem mais duas áreas (como era o caso da Guiando) e sim agora uma área de produto, com times completos. No entanto, ainda assim dentro da área de produtos os times responsáveis por produtos hora temos gente trabalhando em uma inovação e hora em uma manutenção, uma espécie de rodízio, o que sinceramente não gosto, mas é dessa forma que estamos trabalhando neste começo e estamos aprendendo.

    Dos times de rodízio dentro das squads, temos um grupo que inova através sprint e ao concluir esse grupo passa um tempo mantendo, até que seja feito o rodízio novamente.

    Mas sinto que o que fizeram na Guiando foi algo mais radical. Tentando entender melhor, se temos um caso em que temos x chamados de bugs vencendo nas próximas 3 semanas e, além disso, tem também que trabalhar em uma implementação nova, como fazem? Encaixam os chamados dentro da sprint/kanban para ser feito em conjunto com o que deve ser entregue?

    Fico muito agradecido por compartilhar suas cicatrizes, realmente isso ajuda e muito!!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *