Cómo Tohum AB Transformó los Requisitos Técnicos, Enfrentó la Deuda Técnica y Convirtió el Aprendizaje en un Motor de Crecimiento Profesional

1. Por qué escribimos esta historia

Toda startup acaba descubriendo que su tecnología es solo la mitad del producto; la otra mitad es el conocimiento de los ingenieros que dan vida a esa tecnología. En Tohum AB —operando desde Göteborg, Suecia, e İzmir, Türkiye— diseñamos nodos de medición de suelo listos para campo que combinan un MCU ESP32 con sensores NPK de precisión, baterías de ion-litio, paneles solares de alta eficiencia, backhaul basado en SIM y pipelines de datos MQTT. A medida que crecía la lista de funcionalidades, nos vimos gestionando forks de firmware, revisiones apresuradas de PCB y una lista de “cosas que arreglaremos después” cada vez más larga.

Este artículo es una retrospectiva sobre cómo:

1. Definimos nuestros requisitos técnicos de forma que equilibraran precisión agronómica, necesidades de ultra bajo consumo y restricciones de manufactura.

2. Auditamos y cuantificamos nuestra deuda técnica, desde controladores BLE con errores hasta esquemas de árbol de potencia duplicados.

3. Construimos un plan de aprendizaje basado en una matriz de habilidades que convierte las brechas en oportunidades de crecimiento en lugar de puntos de estrés.

4. Integrámos el desarrollo profesional en nuestro ritmo diario de ingeniería para que el futuro de cada empleado se tomara tan en serio como el futuro de cada producto.

Esperamos que este playbook sea útil tanto si estás diseñando tu primer nodo sensor como si estás escalando una flota de decenas de miles de dispositivos.

2. Enmarcando la misión: de “un gadget interesante” a resultados medibles

Nuestra visión fundacional era sencilla: dar a los agricultores información asequible y rica en telemetría sobre la salud del suelo para que puedan optimizar fertilizantes y riego con precisión científica. Convertir esa visión en un backlog de ingeniería requería un lenguaje que todos los stakeholders pudieran entender: marketing, agrónomos de campo, ingenieros de firmware y diseñadores de hardware por igual.

Por eso escribimos cada requisito de nivel superior como un resultado visible para el usuario seguido de métricas de ingeniería:

• “Un técnico de campo puede instalar una sonda y ver datos en el dashboard en 5 minutos.”

  • Aprovisionamiento Wi‑Fi de 2.4 GHz o BLE Soft‑AP; fallback a APN precargado para celular.

  • Los valores iniciales de pH, CE y temperatura del suelo deben aparecer en Grafana en 300 s.

• “Los nodos deben operar sin atención durante un invierno nórdico completo sin reemplazo de batería.”

  • Consumo medio de corriente ≤ 80 µA durante 24 h; corriente en reposo de deep‑sleep ≤ 5 µA.

  • Un panel de 6 W + una 18650 de 3500 mAh deben cumplir el presupuesto energético a 55° N con 2 h de insolación.

• “Los vacíos de datos causados por pérdida de cobertura deben rellenarse automáticamente.”

  • Buffer circular LittleFS de 4 MiB; tarjeta SD opcional.

  • Reenvío MQTT QoS 1 con backoff exponencial al reconectar.

Con los resultados claros, los trade‑offs se hicieron explícitos: un buffer local más grande aumenta el costo de BOM; un muestreo más frecuente incrementa la resolución agronómica pero drena la batería. Como cada requisito se podía rastrear hasta números concretos, evitamos la trampa de que funcionalidades “nice‑to‑have” se colaran en placas de revisión A.

3. Descomponiendo el stack tecnológico

A continuación, descompusimos la solución en seis áreas de enfoque, cada una liderada por un “tech steward” responsable de los requisitos, registros de riesgos y Jira epics:

Un “Architecture Canvas” de una sola página visualizó las dependencias: la placa del sensor de suelo alimenta datos I²C al MCU; el subsistema de energía reporta SoC mediante un contador de culombios; el módem comparte el bus UART con la depuración RS‑485; el motor de reglas en la nube distribuye datos a InfluxDB para Grafana.

Este canvas se convirtió en la tabla de contenidos de todos los documentos de diseño posteriores, evitando el pensamiento en silos y asegurando que cada ingeniero supiera a quién contactar cuando cambiaba una especificación.

4. Cuantificando la deuda técnica: de anécdotas a números

Como muchas startups, habíamos acumulado atajos de “esto lo arreglaremos después del demo day”:

• Firmware

  • APNs hardcodeados en tres árboles de código fuente diferentes.

  • Rutinas de ADC copiadas y pegadas con constantes de escalado mágicas.

• Hardware

  • Tres cambios de valor de resistencias parchados con cable azul en el lote piloto.

  • Sin convención de nomenclatura consistente para puntos de test.

• Proceso

  • Scripts Bash one‑off para flashear 50 unidades en la línea de producción.

  • Conocimiento tribal sobre qué commit del SDK funcionaba con qué revisión de placa.

Adoptamos una auditoría de tres pasos similar a la metáfora de deuda técnica de Ward Cunningham:

1. Inventario – un “debt safari” con todo el equipo produjo 126 elementos en una página de Confluence.

2. Severidad e interés – cada elemento se puntuó de 1 a 5 por impacto y de 1 a 5 por costo de arreglar más tarde.

3. Estimación del principal – horas necesarias si se arreglara inmediatamente.

El resultado lucía así:

Los elementos con puntuación alta se promovieron a los backlogs de sprint. Los de menor puntuación permanecieron en el “snow‑bank” pero con fechas de caducidad explícitas. Esta lente cuantitativa despersonalizó las discusiones: los números decidían la prioridad, no la voz más alta.

5. Mapeando habilidades al producto: la matriz en T

Paralelamente a la auditoría de deuda, nos dimos cuenta de que parte de la “deuda” era en realidad un déficit de habilidades. Tomamos prestado el marco de cinco niveles que vimos antes (Absolute Beginner → Expert) y listamos 25 competencias (C/C++, ESP‑IDF, FreeRTOS, Git, PlatformIO, Linux CLI, Unity Test, CI/CD, Jira/Confluence, Electrónica, Diseño de PCB, Presupuesto de potencia, Gestión de baterías, Comunicaciones celulares, Protocolos IoT, TLS, Calibración de sensores, Registro de datos, OTA, Teoría de control, Python/Bash, Dashboards en la nube, Cumplimiento normativo, Herramientas de documentación).

Cada ingeniero se autoevaluó y un tech lead moderó para calibrar. Los resultados formaron un mapa de calor:

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

Llamamos a esto la Matriz en T —todos profundos en un pico, amplios en lo básico. Destacó el riesgo al instante: si Ali (nivel 2 en LTE) se iba de vacaciones, los problemas celulares podrían bloquear un sprint. También iluminó rutas de crecimiento: Elif podía mentorizar en la nube mientras aprendía ESP‑IDF de Mert.

6. Diseñando el plan de aprendizaje: de brechas a objetivos

Un plan de aprendizaje solo es creíble si se vincula a las necesidades del producto y a la motivación individual. Tomamos tres pasos concretos:

1. Buckets de habilidades alineados a hitos del roadmap
   Q3: secure boot y cifrado de flash → todos a Nivel 3 en mbedTLS.
   Q4: despliegue de delta‑OTA → dos desarrolladores de firmware a Nivel 4 en registro de datos y diseño de particiones.

2. Práctica integrada
   – Sesiones de pair programming dos veces por semana, rotando mentor/mentee.
   – “Friday Spike”: un sandbox de 4 horas para experimentar con cualquier cosa relacionada con el tema semanal —maquetas de filtros de Kalman, diagramas de placas en PlantUML, etc.

3. Métricas de progreso visibles
   – Charlas relámpago mensuales de “muestra lo que aprendiste”.
   – Tablero de Jira Goals con épicas personales como “Elif sube ESP‑IDF a 3: ejemplo de OTA enviado.”

Asignamos el 10 % de la velocidad del sprint explícitamente a tareas de aprendizaje. Finanzas inicialmente cuestionó el coste de capacidad, pero los números de retención mejoraron: la rotación voluntaria bajó al 0 % en 18 meses.

7. El ciclo de desarrollo profesional: ingeniería primero, no RRHH

Los ciclos tradicionales de evaluación se sentían inadecuados. Los reemplazamos por un Career Kanban ligero:

Los ingenieros mueven las tarjetas a su propio ritmo; los leads intervienen solo para desbloquear o celebrar. Esta fluidez refleja cómo funcionan los pull requests: el aprendizaje es solo otra rama.

8. Resultados en campo: menos tiempos de inactividad, agricultores más satisfechos

Doce meses después de lanzar el marco:

• El backlog de errores se redujo en un 48 %.

• La cadencia de releases de firmware mejoró de trimestral a mensual.

• La autonomía de la batería superó el objetivo original de invierno en un 18 %.

• Los tickets de soporte por caídas celulares cayeron un 60 %.

Lo más revelador: el tiempo de especificación a primer prototipo validado pasó de ocho semanas a 4,5. Los ingenieros atribuyeron el mérito al cross‑training: el diseñador de PCB que alcanzó Nivel 3 en Python escribió un script de calibración que ahorró una semana de trabajo en el banco de pruebas.

9. Cuidar el futuro: por qué el aprendizaje es parte de nuestro compromiso ESG

Posicionamos el aprendizaje continuo no solo como un beneficio de RRHH, sino como un imperativo ambiental y social:

• Ambiental – Un firmware mejor diseñado significa menos visitas de campo y menor huella de CO₂.

• Social – Los empleados con mayor capacitación se convierten en embajadores tecnológicos locales, impulsando la innovación regional.

• Gobernanza – Las matrices de habilidades documentadas y las promociones transparentes reducen el sesgo y fortalecen el cumplimiento.

Cada trimestre publicamos un “Learning Impact Report” interno que muestra correlaciones entre horas de formación y OKRs clave (densidad de errores, eficiencia energética). La junta lo revisa junto con los números de ingresos: prueba de que las métricas de personas merecen el mismo tiempo de sala de juntas.

10. Lecciones aprendidas y consejos para otros equipos

1. Escribe primero los requisitos orientados a resultados; las elecciones tecnológicas siguen naturalmente.

2. Cuantifica la deuda técnica para que los argumentos sean matemáticos, no emocionales.

3. Las matrices de habilidades visuales revelan cuellos de botella de talento más rápido que los organigramas.

4. Asigna tiempo enfocado (elegimos el 10 %) para que el aprendizaje sea creíble.

5. Vincula el aprendizaje a código real —un PR mergeado enseña más que cualquier MOOC.

6. Celebra las pequeñas victorias; las charlas relámpago superan a las presentaciones para compartir conocimiento tácito.

7. Conecta públicamente el aprendizaje a KPIs del producto para ganar patrocinio ejecutivo.

11. Qué sigue para Tohum AB

Nuestro roadmap para 2026 incluye conectividad dual NB‑IoT + LoRa, predicciones de nutrientes impulsadas por IA y una carcasa rugged v6 dirigida a operaciones agrícolas de lavado a presión IP69K. Cada frontera genera nuevas columnas en la matriz de habilidades —ML de ultra bajo consumo, inmersiones profundas en la capa MAC de LoRaWAN, laboratorios de ingreso de alta presión. El marco sigue vivo: repetiremos el ciclo de requisitos‑deuda‑aprendizaje con cada salto.

12. Una palabra final sobre las personas

Los chips de silicio envejecen; los paneles solares se degradan; incluso el suelo más fértil eventualmente necesita reponerse. El único activo que acumula valor indefinidamente es el potencial humano. Al diseñar nuestro proceso de aprendizaje con la misma rigurosidad que aplicamos a esquemas y código, descubrimos un ciclo virtuoso: mejores productos financian más aprendizaje, que genera mejores carreras, que a su vez producen mejores productos.

Si te llevas una sola cosa de nuestra historia, que sea esta: invierte en tus ingenieros como inviertes en la química de tus baterías. Ambos almacenan energía, pero solo uno puede inventar el futuro.