As expectativas sobre lideranças técnicas, ou qualquer pessoa que ocupe um cargo técnico mais alto, tendem a ser bastante implícitas e variadas de acordo com o contexto do time ou da organização. Mesmo as formalizando em documentos ou conversas, sempre vão haver necessidades essenciais a qualquer produto que não necessariamente serão ditas de forma explícita. E nestes dois artigos tento trazer algumas dessas práticas que são quase sempre esperadas, mas nem sempre ditas.
A liderança técnica deve ser uma consequência e não um objetivo, e é ideal que surja de forma natural. Considerar e adaptar as práticas listadas neste artigo nada mais é que uma forma proativa de amadurecer profissionalmente. O que acontecer depois disso é, como mencionado, consequência.
Outro ponto importante é que você não precisa ser a pessoa responsável por tudo isso. Mas precisa sim, como alguém que almeja amadurecimento técnico, priorizar e aplicar essas práticas tendo em vista sempre o momento e a natureza do seu negócio. Não tente trazer todas de uma vez e, depois de iniciadas, não esqueça de garantir que estão sendo revisadas constantemente (não necessariamente por você).
Antes de começar…
Primeiro de tudo, assegure-se de que você já está fazendo o esperado pela sua equipe e líderes diretos. Você está demorando muito para entregar tarefas consideradas medianas pela sua equipe? Está tendo, com certa frequência, dificuldade para realizá-las mesmo em linguagens e tecnologias a qual considera que tem conhecimento?
Se a resposta for sim, não tente adquirir novas responsabilidades. Use esse catálogo para cobrar atitudes das suas lideranças ou das pessoas mais experientes do seu time e, por enquanto, busque proativamente formas de ganhar conhecimento e segurança: pratique pareamento com pessoas da equipe, peça feedbacks técnicos sobre seu código, procure um mentor para te ajudar com as tecnologias envolvidas, etc. É necessário que tanto você quanto às pessoas ao seu redor tenham muita segurança na sua entrega do dia-a-dia antes de arranjar novas atribuições. E se conscientizar disso já é uma grande vitória.
Caso contrário, se você acha que já existe uma confiança na qualidade e velocidade da sua entrega, ainda não siga em frente: certifique-se desse fato. Busque feedbacks técnicos de forma proativa. Além de demonstrar maturidade profissional, você também garante que é uma pessoa pronta para ser responsável por atividades mais desafiadoras.
Agora, é hora de listar algumas atribuições, que nem sempre são explícitas ou formais, esperadas de lideranças técnicas ou pessoas que almejam mais maturidade na área de desenvolvimento. São práticas essenciais que, por quase todas as equipes que participei, tornaram o desenvolvimento do software mais sustentável e fluido, com bem menos atritos, imprevistos e falhas.
1. Priorize e Acompanhe os Requisitos Transversais (ou Não-Funcionais) do seu Produto
Requisitos transversais são aqueles fatores que vão além de tarefas ou histórias de usuário, mas são igualmente importantes para o funcionamento da sua aplicação: performance (tempo de resposta), disponibilidade, acessibilidade, escalabilidade, efetividade, etc. Uma longa lista deles pode ser encontrada nesse link.
Estes requisitos são considerados imprescindíveis, mas se costuma olhar para eles somente em momentos extremos quando já é tarde demais. Exemplo: um longo tempo de resposta, multas governamentais por não respeitar leis de acessibilidade, erros inesperados da aplicação quando sujeita a uma maior quantidade de requisições, etc.
A ideia aqui é priorizar cerca de três destes requisitos dentre os existentes e coletar métricas relevantes relacionadas a eles. Esta é uma quantidade razoável, mas pode variar segundo o momento e a cultura da sua equipe. E sim, todos eles são importantíssimos, mas uns merecem mais atenção que outros dada a natureza do seu negócio. Deixe isso claro para todas as pessoas: despriorizar segurança não quer dizer que não vamos considerá-la em nossas tarefas, mas, dependendo do produto, ter 100% de disponibilidade é mais crítico para o negócio do que criar testes de intrusão (pen tests) ou rodar dinâmicas de modelagem de ameaça (threat modeling) toda semana. Depois de priorizados, mantenha viva no time a cultura de preocupar-se com eles a cada passo dado: adicione novos passos em sua pipeline de entrega contínua, adicione outros tipos de testes automatizados, adicione critérios de aceite às suas tarefas de negócio e até mesmo crie alertas em seu sistema de monitoramento baseados nas métricas coletadas daqueles requisitos.
Precipitar esses problemas e evitar que eles aconteçam vai não só gerar aprendizados para toda a equipe, mas também o avanço de algumas casas na sua trajetória como pessoa desenvolvedora.
Por último, é necessário garantir que estes requisitos estejam sempre sob controle e, para isso, vamos coletar e acompanhar métricas relacionadas. No entanto, pela abrangência e importância dessa prática, é ideal que ela tenha um tópico exclusivo e aprofundado…
2. Colete e Acompanhe as Principais Métricas da sua Aplicação
Todo time ágil deve saber ou ter fácil acesso a certas métricas técnicas de seu produto. Elas podem variar dependendo da sua natureza, mas existem algumas consideradas básicas que precisam de monitoramento contínuo e em tempo real: qual o tempo médio de resposta da sua aplicação e de seus casos de uso? Qual a porcentagem de falhas inesperadas que chegam até o usuário final? Qual a quantidade de requisições ou utilizações do seu sistema e suas funcionalidades?
Uma lista mais completa dessas métricas pode ser encontrada neste link. Mas não se prenda a elas. Algumas que gosto de acompanhar e não estão nessa lista são as coberturas de testes unitários e de testes de mutação: juntas, ambas dão maior garantia de que seu software está sendo construído de forma sustentável e expansível.
Com isso em mente, junte seu time ou faça você mesmo uma priorização do que precisa ser medido dado o contexto da sua aplicação. Analise se possui as ferramentas necessárias para essas medições e, caso negativo, converse com o time para priorizar atividades que tornem essas medições viáveis como, por exemplo, adicionar mais logs no seu código.
Feito isso, crie painéis organizados com elas (geralmente com alguma ferramenta de monitoramento como o Splunk ou Datadog) e, se possível, deixe-os em um lugar visível para todo o time. Dessa forma, qualquer alteração suspeita no valor dessas métricas será mais perceptível e terá sua causa encontrada e corrigida mais rapidamente.
Por último, crie alertas na mesma ferramenta de monitoramento baseado nelas. Não é garantido que vai ter sempre alguém olhando para esses painéis e atento às variações de valores, então os alertas são importantíssimos para garantir ainda mais uma resposta mais rápida a falhas.
Não se esqueça que esses painéis e alertas agora fazem parte do seu produto. E, como uma espécie de documentação, devem ser constantemente atualizados à medida que o time faz novas entregas. Uma boa ideia é considerar essas métricas e alertas durante a criação das histórias de usuário e adicionar, como critério de aceite, a criação de novos ou atualização dos existentes.
3. Mantenha sua Documentação, seus Diagramas de Arquitetura e Desenhos de Casos de Uso Organizados e Atualizados
É de senso comum que todo software precisa de uma documentação clara e sempre atualizada. Mas, quando estamos começando na nossa carreira de desenvolvimento ou trabalhando sob pressão de entregas e prazos, é comum entrarmos num ciclo vicioso de entregar tarefas preocupando-se apenas com seu funcionamento e deixando de lado outras partes tão importantes quanto a própria entrega. Em muitos times que participei, uma dessas partes esquecidas eram as documentações.
Ter suas documentações sempre atualizadas é essencial não só para as pessoas que utilizam seus serviços, mas também para o seu próprio time e organização. É com elas que conseguimos manter uma cadência na velocidade de entrega pois, quando bem construídas e organizadas, temos fácil acesso a diversas informações que servem de base para nossas próximas funcionalidades e para novas pessoas integrantes da equipe. Por isso, quando falo de documentação, não estou falando somente daquele catálogo de endpoints dos seus serviços, mas também dos READMEs dos seus projetos e os diagramas de arquitetura e de casos de uso (ou de fluxo) da sua aplicação.
Não estou querendo dizer que é papel das lideranças técnicas manter esses artefatos atualizados. Sua responsabilidade (como deveria ser a de qualquer outra pessoa do time) é garantir que isso está acontecendo de forma natural e que todo o time entende a importância dessa prática. Caso isso não esteja acontecendo, sugira novos processos ou cerimônias para sua equipe até que, organicamente, todos considerem atualizar as documentações como parte das tarefas de desenvolvimento. Algumas ideias: pontuar nas histórias de usuário qual artefato deve ser criado ou atualizado, criar cerimônias com certa frequência para o time revisar junto as documentações, dar feedbacks para as pessoas que não o fizerem junto com suas tarefas, etc.
E não se esqueça que parte fundamental dessas documentações são os diagramas de arquitetura do seu sistema e dos casos de uso (ou de fluxo) das suas funcionalidades. Elas devem ser capazes de responder a perguntas como: Com quais outros sistemas o meu produto se comunica? Quem são as pessoas, equipe ou empresa responsável por esses sistemas? Qual é a tecnologia desses sistemas? Por quais sistemas uma requisição passa para fazer uma dada operação? E quais informações são trafegadas entre eles?
Ter a resposta para essas perguntas em boas documentações torna-se cada vez mais essencial a medida que seu produto evolui e poupa bastante tempo em diversas situações. Uma sugestão para desenhar seus diagramas de arquitetura é utilizar o modelo C4 com as ferramentas Draw.io ou Miro. Também existe uma prática bastante reconhecida no mercado chamada ADR (Architecture Decision Record): ela serve para documentar as decisões arquiteturais do seu time e responder, sem depender da nossa falha memória, dúvidas do porquê determinada implementação foi feita daquela forma (quem nunca passou por isso?).
Caso sua equipe seja responsável por "APIs" ou qualquer serviço de backend, existem uma série de ferramentas que não só criam e atualizam uma documentação de endpoints de forma automatizada, mas também a torna usável para que pessoas consumidoras possam fazer testes e requisições. Uma dessas ferramentas é o famoso Swagger. Ele é capaz de gerar uma documentação bastante intuitiva e possui plugins, para quase todas as linguagens de mercado, para gerar a documentação dos seus endpoints através do próprio código, sendo possível versioná-la e publicá-la para toda a organização a cada entrega feita pelo time.
Para diagramas de casos de uso, eu gosto muito do PlantUML, um plugin para desenhar diagramas UML utilizando uma linguagem própria de fácil entendimento. Dessa forma, é possível versionar estes diagramas ou até mesmo colocá-los juntos no mesmo repositório da sua aplicação (mais aconselhado).
4. Lide com Dívidas Técnicas (ou Débitos Técnicos)
Dívidas técnicas são consequências de escolher um caminho mais fácil e rápido para alcançar um objetivo, mesmo sabendo que existe um outro melhor e mais aderente aos bons padrões de código e arquitetura. É uma escolha consciente que pode ser feita por falta de tempo, conhecimento ou ferramentas naquele contexto. E não tem nada de errado com isso! O erro está em você não ter uma estrutura na sua metodologia para documentá-lo e nem um processo para priorizar essas dívidas e garantir que, um dia, ela será paga.
Quando se trabalha em times onde sequer existe o conceito de dívida técnica, as consequências são trágicas (por experiência própria): em uma questão de meses, toda a performance do sistema foi comprometida, além do aumento da taxa de falhas e demora crescente para o time entregar novas funcionalidades pela complexidade do código. Não digo que essas dívidas foram as únicas culpadas, mas certamente contribuíram de forma majoritária para chegar nesse caótico cenário. Tudo era deixado pra depois: a refatoração de classes e métodos enormes, a criação testes automatizados básicos, a melhoria no design de alguns componentes do projeto, etc.
Existem algumas formas de lidar com dívidas técnicas que funcionaram comigo quando percebi que esse cenário poderia voltar a acontecer. Uma delas foi primeiramente marcar um encontro com toda a equipe para alinharmos o conceito de dívida técnica. No mesmo encontro, por não termos muitas dívidas mapeadas, fizemos um brainstorm dos débitos técnicos que havíamos acumulado em alguns meses de projeto. Validamos cada um deles e, depois de ter certeza que eram realmente dívidas e que todos entenderam seu contexto, priorizamos cada uma delas em uma matriz de dor (baixa, média e alta) e esforço (alto, médio e baixo). Em nosso backlog, criamos esses débitos dando prioridade aos de esforço mais baixo e dor mais alta e combinamos com as pessoas responsáveis que, a cada iteração, iríamos pagar pelo menos duas dívidas técnicas por ordem de prioridade.
No final da dinâmica, também combinamos um processo para mapear essas dívidas no nosso backlog: sempre que uma pessoa desenvolvedora gerar um débito técnico, ela mesmo o criava e o priorizava dentre os existentes. Além disso, mensalmente, todo o time se reunia para todos terem conhecimento das novas dívidas geradas naquele período e, se necessário, repriorizá-las.
Por último, mas longe de ser o menos importante: assegure-se que todo seu time entende a importância deste tema e, com isso, mantenha viva a cultura de mapear e pagar dívidas técnicas. Adapte o exemplo dado ou crie novas abordagens que você acha que vão funcionar para o contexto e cultura da sua organização e do seu time e que, mesmo em tempos difíceis e de prazos apertados, elas não cairão no esquecimento.
5. Codar
Isso mesmo, codar, nem que algumas horinhas na semana! É muito comum as lideranças técnicas não terem tempo para programar. Porém, desenvolver tarefas é a melhor forma de ficar mais próximo da realidade das pessoas lideradas e conseguir tomar ações mais precisas. Ações essas que não estarão em artigos ou livros pois são extremamente relacionadas com o contexto que seu time está passando naquele momento.
Então, se você é uma liderança técnica ou uma pessoa desenvolvedora e está sem tempo para programar, reveja suas atuais responsabilidades e atividades. Pense no que pode ser delegado ou adiado e assim o faça.
Quando for programar, se possível, tente parear com pessoas do seu time para conhecê-las ainda mais e conseguir até mesmo dar feedbacks mais assertivos. Parear também, como já mencionado, é uma ótima oportunidade para compartilhar conhecimentos adquiridos com o seu provável muito tempo de projeto.
Ainda não acabou…
No segundo e próximo artigo, vamos falar sobre tópicos menos técnicos e mais relacionados à comunicação dentro e fora do seu time. Como qualquer liderança, a forma de se comunicar cativa, influencia e evolui as pessoas ao seu redor e vou listar alguns tópicos a serem considerados para quem quer alcançar esse tipo de papel em uma organização.
Fica de olho que dia 15/11 temos a parte 2!
Quer uma nova oportunidade de carreira com desafios globais? Confira nossas vagas em Engenharia e Produto e conheça mais sobre a SumUp.
Top comments (0)