Como a Tohum AB Transformou os Requisitos Técnicos, Enfrentou a Dívida Técnica e Transformou a Aprendizagem num Motor de Crescimento de Carreira

1. Por Que Escrevemos Esta História

Todas as start-ups acabam por descobrir que a sua tecnologia é apenas metade do produto; a outra metade é o conhecimento dos engenheiros que dão vida a essa tecnologia. Na Tohum AB — a operar a partir de Gotemburgo, Suécia, e Esmirna, Turquia — desenhamos nós de medição de solo prontos para o terreno que combinam um MCU ESP32 com sensores NPK de precisão, baterias Li-ion, painéis solares de alta eficiência, backhaul baseado em SIM e pipelines de dados MQTT. À medida que a lista de funcionalidades crescia, víamo-nos a gerir forks de firmware, revisões apressadas de PCB e um backlog cada vez maior de “coisas que vamos corrigir mais tarde”.

Este artigo é uma retrospetiva sobre como nós:

1. Definimos os nossos requisitos técnicos de forma a equilibrar precisão agronómica, necessidades de consumo ultrabaixo e restrições de fabrico.

2. Auditámos e quantificámos a nossa dívida técnica, de drivers BLE com bugs a esquemas de árvore de alimentação duplicados.

3. Construímos um plano de aprendizagem em matriz de competências que transforma lacunas em oportunidades de crescimento em vez de pontos de stress.

4. Integrámos o desenvolvimento de carreira no nosso ritmo diário de engenharia, para que o futuro de cada colaborador seja tratado com a mesma seriedade do que o futuro de cada produto.

Esperamos que este playbook seja útil, quer esteja a arquitetar o seu primeiro nó sensor ou a escalar uma frota de dezenas de milhares de dispositivos.

2. Enquadrar a Missão — De “Um Gadget Giro” a Resultados Mensuráveis

A nossa visão fundadora era simples: Dar aos agricultores uma visão acessível e rica em telemetria sobre a saúde do solo, para que possam otimizar fertilização e irrigação com precisão científica. Transformar essa visão num backlog de engenharia exigiu uma linguagem que todos os stakeholders pudessem compreender — marketing, agrónomos de campo, engenheiros de firmware e designers de hardware.

Por isso, escrevemos cada requisito de topo como um resultado visível para o utilizador seguido de métricas de engenharia:

• “Um técnico de campo consegue instalar uma sonda e ver dados no dashboard em 5 min.”

  • Provisionamento por Wi-Fi 2,4 GHz ou BLE Soft-AP; fallback para APN pré-carregado para celular.

  • Os valores iniciais de pH do solo, EC e temperatura devem aparecer no Grafana em 300 s.

• “Os nós devem operar sem supervisão durante um inverno nórdico completo sem substituição da bateria.”

  • Consumo médio de corrente ≤ 80 µA ao longo de 24 h; consumo em deep-sleep ≤ 5 µA.

  • Painel de 6 W + 18650 de 3 500 mAh deve cumprir o orçamento energético a 55° N com 2 h de insolação.

• “As falhas de dados causadas por perda de cobertura devem ser preenchidas automaticamente.”

  • Ring buffer LittleFS de 4 MiB; cartão SD opcional.

  • Reenvio MQTT QoS 1 com back-off exponencial ao reconectar.

Com os resultados claros, os trade-offs tornaram-se explícitos: um buffer local maior acrescenta custo à BOM; amostragem mais frequente aumenta a resolução agronómica, mas drena a bateria. Como cada requisito podia ser rastreado até números concretos, evitámos a armadilha de funcionalidades “nice-to-have” se infiltrarem nas placas da revisão A.

3. Decompor a Stack Tecnológica

Em seguida, decompusemos a solução em seis áreas de foco, cada uma liderada por um “tech steward” responsável pelos requisitos, registos de risco e épicos no Jira:

Um “Architecture Canvas” de uma página visualizava as dependências: a placa do sensor de solo alimenta dados I²C ao MCU; o subsistema de energia reporta o SoC via coulomb counter; o modem partilha o barramento UART com depuração RS-485; o motor de regras na cloud distribui os dados para o InfluxDB para o Grafana.

Este canvas tornou-se o índice de todos os documentos de design subsequentes, evitando pensamento em silos e garantindo que cada engenheiro sabia a quem recorrer quando uma especificação mudava.

4. Quantificar a Dívida Técnica — Transformar Anedotas em Números

Como muitas start-ups, tínhamos acumulado atalhos do tipo “corrigimos isto depois do demo day”:

• Firmware

  • APNs hard-coded em três árvores de código diferentes.

  • Rotinas de ADC copiadas e coladas com constantes de escala mágicas.

• Hardware

  • Três alterações de valores de resistências corrigidas com blue-wire no lote piloto.

  • Sem convenção de nomenclatura consistente para test points.

• Processo

  • Scripts Bash pontuais para gravar 50 unidades na linha de produção.

  • Conhecimento tribal sobre que commit do SDK funcionava com que revisão de placa.

Adotámos uma auditoria em três passos semelhante à metáfora da dívida técnica de Ward Cunningham:

1. Inventário – um “safári da dívida” com toda a equipa produziu 126 itens numa página do Confluence.

2. Gravidade e Taxa de Juro – cada item pontuado de 1 a 5 em impacto e de 1 a 5 em custo de corrigir mais tarde.

3. Estimativa de Principal – horas necessárias se corrigido imediatamente.

O resultado ficou assim:

Os itens com pontuação alta foram promovidos aos backlogs de sprint. Os mais baixos permaneceram no “snow-bank”, mas com datas de expiração explícitas. Esta lente quantitativa despersonalizou as discussões: os números decidiam a prioridade, não a voz mais alta.

5. Mapear Competências ao Produto — A Matriz em T

Em paralelo com a auditoria da dívida, percebemos que parte da “dívida” era na verdade um défice de competências. Reutilizámos o framework de cinco níveis que viu anteriormente (Principiante Absoluto → Especialista) e listámos 25 competências (C/C++, ESP-IDF, FreeRTOS, Git, PlatformIO, Linux CLI, Unity Test, CI/CD, Jira/Confluence, Eletrónica, design de PCB, orçamento de energia, gestão de bateria, comunicações celulares, protocolos IoT, TLS, calibração de sensores, data logging, OTA, teoria de controlo, Python/Bash, dashboards cloud, conformidade regulamentar, ferramentas de documentação).

Cada engenheiro fez uma autoavaliação e um tech lead moderou para calibração. Os resultados formaram um heat map:

Name   C/C++ ESP‑IDF LTE  PCB  MQTT Cloud ...
Ali      4      3      2    5    4     2
Elif     2      2      4    3    3     5
Mert     5      4      1    2    3     2

Chamamos a isto a Matriz em T — todos profundos numa especialização, amplos nos fundamentos. Destacou de imediato o risco: se o Ali (LTE nível 2) fosse de férias, problemas de celular podiam paralisar um sprint. Também iluminou caminhos de crescimento: a Elif podia ser mentora de cloud enquanto aprendia ESP-IDF com o Mert.

6. Construir o Plano de Aprendizagem — De Lacunas a Objetivos

Um plano de aprendizagem só é credível se estiver ligado às necessidades do produto e à motivação individual. Tomámos três passos concretos:

1. Baldes de Competências Alinhados aos Marcos do Roadmap
   Q3: secure boot e encriptação de flash → todos até ao Nível 3 em mbedTLS.
   Q4: lançamento de delta-OTA → dois programadores de firmware até ao Nível 4 em data logging e design de partições.

2. Prática Integrada
   – Sessões de pair programming duas vezes por semana, rodando mentor/mentorando.
   – “Friday Spike”: sandbox de 4 horas para experimentar qualquer coisa relacionada com o tema da semana — maquetas de filtros de Kalman, diagramas de placas em PlantUML, etc.

3. Métricas de Progresso Visíveis
   – Lightning talks mensais de “mostra o que aprendeste”.
   – Quadro de Goals no Jira com épicos pessoais como “Elif sobe ESP-IDF para 3: exemplo OTA entregue.”

Alocámos 10% da velocidade do sprint explicitamente a tarefas de aprendizagem. As finanças questionaram inicialmente o custo de capacidade, mas os números de retenção melhoraram: a rotatividade voluntária caiu para 0% ao longo de 18 meses.

7. O Ciclo de Desenvolvimento de Carreira — Engenharia Primeiro, Não RH

Os ciclos tradicionais de avaliação pareciam inadequados. Substituímo-los por um Career Kanban leve:

Os engenheiros movem os cartões ao seu próprio ritmo; os leads intervêm apenas para desbloquear ou celebrar. Esta fluidez espelha a forma como os pull requests funcionam — aprender é apenas mais um branch.

8. Resultados no Terreno — Menos Paragens, Agricultores Mais Satisfeitos

Doze meses após o lançamento do framework:

• O backlog de bugs diminuiu 48%.

• A cadência de lançamentos de firmware melhorou de trimestral para mensal.

• A autonomia da bateria excedeu a meta original de inverno em 18%.

• Os tickets de suporte por falhas de celular caíram 60%.

Mais revelador: o tempo de especificação ao primeiro protótipo validado passou de oito semanas para 4,5. Os engenheiros atribuíram-no à formação cruzada: o designer de PCB que atingiu o Nível 3 em Python escreveu um script de calibração que poupou uma semana de trabalho na bancada de testes.

9. Cuidar do Futuro — Por Que a Aprendizagem Faz Parte da Nossa Carta ESG

Posicionamos a aprendizagem contínua não apenas como um benefício de RH, mas como um imperativo ambiental e social:

• Ambiental – Firmware melhor desenhado significa menos visitas ao terreno e menor pegada de CO₂.

• Social – Colaboradores com mais competências tornam-se embaixadores tecnológicos locais, impulsionando a inovação regional.

• Governance – Matrizes de competências documentadas e promoções transparentes reduzem enviesamentos e reforçam a conformidade.

A cada trimestre publicamos um “Learning Impact Report” interno que mostra correlações entre horas de formação e OKRs-chave (densidade de bugs, eficiência energética). O conselho revê-o lado a lado com os números de receita — prova de que as métricas de pessoas merecem igual tempo de antena na sala de reuniões.

10. Lições Aprendidas e Dicas para Outras Equipas

1. Escreva primeiro requisitos orientados a resultados; as escolhas tecnológicas seguem naturalmente.

2. Quantifique a dívida técnica para que os argumentos se tornem matemática, não emoção.

3. Matrizes de competências visuais revelam estrangulamentos de talento mais depressa do que organogramas.

4. Aloque tempo focado (escolhemos 10%) para tornar a aprendizagem credível.

5. Ligue a aprendizagem a código real — um PR mergeado ensina mais do que qualquer MOOC.

6. Celebre pequenas vitórias; lightning talks vencem slide decks na partilha de conhecimento tácito.

7. Ligue publicamente a aprendizagem aos KPIs do produto para conquistar patrocínio executivo.

11. O Que Vem a Seguir para a Tohum AB

O nosso roadmap de 2026 inclui conectividade dupla NB-IoT + LoRa, previsões de nutrientes orientadas por IA e um invólucro robusto v6 com alvo IP69K para operações agrícolas com lavagem de alta pressão. Cada fronteira gera novas colunas na matriz de competências — ML de consumo ultrabaixo, deep dives no MAC do LoRaWAN, laboratórios de ingresso de alta pressão. O framework continua vivo: repetiremos o ciclo requisito-dívida-aprendizagem a cada salto.

12. Uma Palavra Final Sobre Pessoas

Os chips de silício envelhecem; os painéis solares degradam-se; até o solo mais rico acaba por precisar de reposição. O único ativo que acumula valor indefinidamente é o potencial humano. Ao desenharmos o nosso processo de aprendizagem com o mesmo rigor que aplicamos a esquemas e código, descobrimos um ciclo virtuoso: produtos melhores financiam mais aprendizagem, que gera carreiras melhores, que por sua vez produzem produtos melhores.

Se retirar uma coisa da nossa história, que seja esta: invista nos seus engenheiros como investe na química das suas baterias. Ambos armazenam energia, mas só um consegue inventar o futuro.