Contexto: texto escrito em 2022
Em 2009 eu inicio uma nova jornada. Apoiar na transformação de uma empresa baseada em projetos e diversos nichos, para uma empresa de produto, construindo um produto (que virou uma plataforma) para embarcar estes nichos.
A jornada nunca é simples quando estamos mudando o foco de serviço para produto. A cobrança não é mais baseada em simplesmente horas de serviço e suporte ao que é entregue. Não é mais simplesmente crescer em clientes, com novos projetos. Trabalhar com produtos envolve encontrar o tal encaixe ("fit") entre produto e mercado. Ganhamos a oportunidade de pensar em algumas coisas com mais força. Exemplo, aprender como posicionar o produto no mercado. E não aceitar mais simplesmente "tirar pedidos" ou "fritar pastéis" para adequar a necessidade de clientes com o projeto contratado.
Eu entendi na época que eu precisava construir um perfil de produto, já que meu foco dos 13 anos anteriores era focado em serviços e projetos e consultoria. Também entendi que não teria chance de fazer isso, se não tivesse uma equipe em aprendizado constante.
Construir projetos baseados no puro interesse de um cliente ainda exige pensamento de priorização e entendimento de como fatiar entregas, mas quem define o alvo está dentro do projeto. Não é o caso do pensamento quando estamos atuando com produto. Vamos descobrir ao longo do tempo clientes importantes, que podemos entrevistar e aprender mais e mais sobre o mercado que eles vivem. Clientes que nos inspiram no jogo de entrega de valor. Só que no final do dia, a atividade de aprendizagem sobre o que fazemos e sobre o que queremos melhorar é nossa responsabilidade.
No caso do pensamento de produto, a construção do futuro do produto precisa de aprendizagem. Viveremos constantemente um pensamento entre certezas, suposições e dúvidas, que serão constantemente desafiadas e atuam na nossa convivência com a incerteza. Precisa de uma equipe constantemente questionando como pode fazer o que faz melhor. Envolve entender este processo tanto tecnicamente como em processos para evolução do produto. Isso conecta com foco de mercado, entendimento de negócios.
Pensei em listar aqui atividades que considerei importante ao longo de 2009 até 2022 nesse pensamento de construção de culturas de aprendizagem, que eu considero como sendo uma das minhas habilidades. E também indicando práticas ligadas com o pensamento de evolução e aprendizado técnico, importante neste jogo de produto.
Em abril/2009 DevOps e Lean Startup estavam nascendo
Eu sabia que falhar o mais rápido possível e aprender mais rápido ainda era uma das únicas oportunidades que tinha neste processo de evoluir equipes e produtos. Criar uma estrutura de apoio para a melhoria, com retrospectivas, espaços técnicos para a equipe se desafiar, também.
Já tinha aprendido também com o meu aprendizado sobre eXtreme Programming, que automação de testes ajudaria a equipe a conseguir evoluir constantemente garantindo a tal coragem necessária para modificar código e saber que ele vai quebrar se algo não estiver ok.
Pelo pensamento Lean, eu sabia que precisava melhorar, encontrar maneiras mais fáceis de produzir software e garantir que uma equipe conseguiria dar manutenção e ensinar pessoas novas a fazer o mesmo.
Também sabia que atuar no desperdício da espera era o meu grande trunfo. Se eu melhorar os tempos de repasse de trabalho nas equipes, consigo aumentar o desempenho delas em muitas vezes.
Em abril de 2009, Eric Ries já tinha cunhado o termo Lean Startup, unindo Lean Thinking + eXtreme Programming + Customer Discovery/Customer Development.
Em 2009 uma palestra chama muita atenção, de uma empresa que eu acompanhava desde o ano anterior. O Flickr tinha uma estrutura no blog de código onde avisavam o que estava acontecendo com relação a updates de código e quem estava fazendo isso.
Eu já era fã fazia tempo e mantinha umas imagens desta época (confesso que elas estavam em uma pasta esquecida, mas eu não tinha esquecido)
Essa palestra, apresentada em junho no Velocity 2009, trouxe uma visão para o mainstream do desenvolvimento de software sobre a nossa capacidade de poder entregar software em produção de forma frequente.
Acho interessante que muitas revoluções relacionadas com a engenharia de software aconteceram em empresas que tiveram reviravoltas com o sucesso. O Flickr passou por diversas jornadas, desde aquisição do Yahoo e depois passando por dificuldades e demissões, até hoje em dia ser um produto em busca de significado. Particularmente gosto do serviço e sou assinante faz algum tempo.
Estes movimentos inspiraram diversas empresas e aqui no Brasil posso dizer que fui bastante influenciado por este tipo de movimento. Deploy contínuo era algo impossível de ser alcançado.
Antes da primeira linha de código, tenha princípios!
Desde cedo eu tinha consciência de alguns princípios que precisava colocar em funcionamento. Alguns relacionados a evolução de código fonte para produção e organização de como podemos gerar valor para clientes.
Eu não tinha dinheiro para contratar uma equipe altamente experiente. Eu precisava compor a equipe existente, aprender novas linguagens de programação ou expandir o uso das linguagens existentes. O mesmo com as práticas de engenharia de software. Sabia o que não queria, no caso de construir um produto no estilo plataforma. E somava nisso todos aprendizados que tive no meu passado mantendo códigos de 10+ anos nos dias atuais.
Testes automatizados, e para quem conseguir, desenvolvimento orientado a testes. Desde muito cedo comecei a trabalhar sessões de Coding Dojo, trazendo para as equipes o ritmo de codificar, evoluir e aprender sobre como modelar cenários de teste.
Trunk Based Development, que muito rapidamente envolve permitir que uma base de código possa ser levada para produção quando for de interesse da equipe. E para que isso possa acontecer precisamos garantir que o código "acordado" esteja com testes passando e o código "dormindo" esteja configurado de forma adequada para não afetar o comportamento de produção. Pensa que nesta época ainda não usávamos sistemas como Git, mas mesmo sendo git eu sigo operando no modelo TBD.
O sistema vai cair. Então como organizamos para que saibamos o que precisa funcionar e como podemos colocar para funcionar.
O sistema pode evoluir sem depender do banco de dados. Muito cedo começamos a aplicar Database refactoring, para garantir que eu poderia evoluir o modelo de dados sem depender da sincronia de instalação de código novo. O mesmo valeria para uma necessidade de rollback de um módulo.
O rollback precisava ser rápido, muito mais rápido que o tempo de instalação. Rollback é só mais uma instalação (deploy).
Uma instalação de código não é igual features novas para clientes. Importante ter uma estrutura de toggles, para habilitar que um cliente tivesse acesso a uma determinada funcionalidade antes de outros clientes, para fins de testes.
O cliente não tem acesso a um ambiente de testes. O teste é em produção. Assim como a bateria de testes chegava em um ambiente de produção, os clientes validavam uma funcionalidade também em produção, no seu próprio ambiente.
Alguns destes princípios levaram bons anos para entrar no fluxo da equipe. Mesmo hoje em 2022 ainda preciso explicar os benefícios de trabalhar com TBD para uma equipe que quer avançar e evoluir código. Assim como preciso ainda explicar os valores do manifesto ágil, sobre a importância de comunicação, de entregar software, de adaptar e manter contato próximo com quem demanda novas evoluções de um produto de software. Sempre lembrando que a coisa mais importante é maximizar o trabalho que não precisa ser feito, a tal simplicidade.
O caminho para a cultura de aprendizagem?
Momentos de aprendizagem, por todos os lados. O aprendizado "on the job", na prática, também. Isso vai desde o processo seletivo até o dia a dia evoluindo alguma funcionalidade de produto.
Se for resumir a base deste processo, é poder operar em dois materiais importantíssimos de Nonaka e Takeuchi:
- Transformar conhecimento tácito em conhecimento explícito.
- Entender o novo jogo para desenvolvimento de produtos.
Relaciono aqui alguns destes momentos que considero importantes e relevantes para este processo de construção de conhecimento.
- Coding Dojo.
- Treinamentos internos, palestras e rodas de conversa.
- Ambiente de infraestrutura não adequado.
- Automação de infra e escala.
- Espaços de aprendizagem, criando eventos.
- Processo seletivo com toda a equipe.
- Operar de forma multimídia, com textos, áudio (podcast na época da trevisan), vídeo
O que mudou nisso tudo em 2022?
Muita coisa. Isso falando no problema de formação de pessoas. Vivemos em um mundo cada vez mais desigual. Se queremos um mundo diferente, precisamos ser intencionais.
Isso inclui remover barreiras para conhecer pessoas. Muitas empresas ainda falam sobre suas estratégias para contratar pessoas somente de melhores universidades do Brasil, pessoas em universidades e esquecem da infinidade de pessoas excelentes em cursos técnicos e pessoas que estão na prática mas não participam de processos de educação formal.
As empresas precisam conectar com comunidades de tecnologia e apoiar onde puderem, patrocinando eventos para unir as pessoas, criando espaços, oferecendo tempo das suas pessoas para palestras e mentorias. As oportunidades são diversas.
E não tente ser a melhor ou a única iniciativa.
Não importa quantas iniciativas sejam criadas sobre aprendizagem e formação de pessoas. Nenhuma delas vai ser suficiente.
Em 2010 o problema já era grande. Em 2022 o problema aumentou de tamanho. E agora está afetando empresas que nem pensavam que esse seria um problema lá em 2010.
O que eu ainda considero que pode nos ajudar, como indústria de tecnologia Brasileira, é operar em uma cultura de aprendizagem, para dentro e para fora das empresas, chegando em instituições de ensino, comunidades e outras empresas.
-- Daniel Wildt
Top comments (0)