El arte de la gestión técnica de la deuda

Administrar la deuda técnica es una habilidad crítica cuando se desarrolla un nuevo producto. En este post, estableceré cómo lo veo, en estas cosas no existe un bien o un error, sino un enfoque equilibrado, así que compartiré cómo trato de equilibrar.

Esta publicación se centra en las startups donde la gestión técnica de la deuda es una cuestión de vida o muerte. Todo se aplica a negocios establecidos también, excepto el precio del error.

Ciclo de vida del nuevo producto

Tomé esta definición después de escuchar a Steve Blank en algunas conferencias, encuentro que simplificar las cosas está bien.

En la publicación, me referiré principalmente a los clientes de su producto (es decir, Ventas) , pero se aplica (más o menos) a la adquisición del usuario si los clientes de su producto no son sus usuarios (por ejemplo, FB o Google).

Ciclo de vida del nuevo producto

Desarrollo MVP

Usted tiene una idea y va a cambiar el mundo, MVP es el producto mínimo que aporta el valor de su idea a sus clientes o usuarios. Su mercado MVP es pequeño, súper pequeño porque solo unos pocos pueden llevarse bien con capacidades mínimas y seguir usando el producto.

Definir su MVP no es tan simple y requiere una gran cantidad de trabajo de validación del cliente, una vez que se define, todo se trata de postularse para una primera versión.

Esta fase trata de I + D en la mayor parte.

Ajuste del mercado del producto

Así que su primera versión está disponible, es hora de conocer a sus clientes. En esta fase, está estableciendo su mercado de productos y su modelo de negocio:

¿Sus clientes están dispuestos a pagar?

¿Cuánto margen te ha dejado?

¿Cuál es el costo de adquisición de su cliente y su valor de por vida?

Sin entrar en detalles, para entonces al final de esta fase tiene un POC de su máquina de dinero (o adquisición de usuarios), una receta que una vez repetida (y puede repetirse) traerá un flujo positivo de ingresos o nuevos usuarios a su producto.

Esta fase es una mezcla de I + D y ventas.

Escala

Aquí es donde las ventas y el marketing se aceleran, esta es la fase en la que realmente demuestras que tu modelo es repetible y escalable.

Esta fase de I + D se centra en el soporte, el éxito del cliente y las características críticas de incorporación de nuevos clientes.

Acordamos el objetivo

En mi opinión, el objetivo es simple: construye algo que aporte valor a las personas y hazlas felices devolviéndole valor. El objetivo no es:

Escribiendo / Diseñando hermosos SW / HW

Tener ciclos rápidos de liberación

Tener una pequeña cantidad de errores

Uso de los últimos y mejores frameworks / idiomas / características

Tener una gran interfaz de usuario, paneles, gráficos e informes

Tener el mejor rendimiento

En una palabra, ventas. Su producto morirá tarde o temprano si no realiza ventas.

¿Qué importa al final del día?

Debe probar que alguien está dispuesto a pagar por el valor que ofrece su producto, más de lo que le cuesta generar este valor con buenos márgenes de ganancia (no discutiendo aquí qué significa el bien).

Las ventas son difíciles y las personas técnicas tienden a subestimar lo difícil que es, cuando se desarrolla un nuevo producto es la parte más difícil. Esta es la línea entre soñadores y cambiadores. Con esto está la mente, desarrolle su producto frente a su desafío # 1 desde el día 1, las ventas.

Entonces, ¿qué tiene que ver con la deuda técnica?

¿Por qué la deuda técnica es crítica para administrar?

Tienes que moverte rápido. Debe responder a las oportunidades de mercado, solicitudes de clientes y ofertas en la mesa.

¿A su cliente le importa este código es una pesadilla y no debe ser tocado? ¿Le importa a su cliente si está usando NodeJS o Ruby?

En la mayoría de los casos, su cliente no se preocupa por su funcionamiento interno, este es su problema. Las ventas han prometido un valor y usted como desarrollador / investigador debe ofrecer ese valor. Si no puede entregar el valor, su producto acaba de perder un trato y obtiene un cliente insatisfecho. Peor resultado, luego cualquier problema de código o circuito que pueda considerar crítico para resolver. Sus clientes son la razón por la que está haciendo ese trabajo. Si se van, pueden seguirlo.

Tus clientes son la razón por la cual tu trabajo existe

Los dos tipos de deuda técnica

Como todas las deudas, su endeudamiento del futuro para usar en el presente. A diferencia de la deuda financiera, en la que presta dinero para su futuro en deuda técnica, presta I + D y, como todos los préstamos, pagará más en el futuro por el consumo presente.

¿Cómo se ve desde 30k pies? Usted codifica / diseña, súper rápido, mientras descuida muchos casos que volverán a perseguirlo en el futuro.

TB tipo I

Esto es lo que la mayoría de los desarrolladores consideran deuda técnica, implica estos comportamientos:

  • Sin arquitectura SW / Ad hck, muchas piezas de código funcional.
  • Sin usar pruebas, control de calidad débil.
  • Sin CI / CD o automatización.
  • Sin configuraciones de entorno, instale recetas.
  • Sin documentos o manuales (o no actualizados).
  • Código frágil / espagueti.
  • Código húmedo
  • Y más…

TB tipo II

Estas son las partidas de deuda técnica más grandes. En muchos casos, no se perciben como deuda hasta que la escala o el mercado de productos se ajusten, implica estos comportamientos:

  • Seleccionar el chip incorrecto para un producto.
  • Usando el protocolo / método de comunicación equivocado.
  • Seleccionar mal marco, no un lenguaje de codificación adecuado.
  • Usando fuentes abiertas muertas (no mantenidas).
  • Usar tecnologías inestables para construir encima de.
  • Y más…

El balance "correcto"

Las personas técnicas fuertes son muy sensibles al Tipo I pero no están inmunizadas contra el Tipo II. La deuda de tipo II es mucho más peligrosa, mientras que el tipo I ralentizará su escala y el ajuste del mercado de productos, el Tipo II puede matar fácilmente a su producto / TTM.

En mi opinión, no se moleste en tratar con el Tipo I hasta que esté realmente seguro de que su planilla de Tipo II está limpia. Por supuesto, no deberías ignorar por completo los problemas de tipo I, pero deberías ser mucho más indulgente. ¿Hasta cuando?

Siempre y cuando no tenga confianza en el ajuste de su mercado de productos, debe ignorar (con cuidado) los problemas de tipo I (¿Su asombrosa unidad de prueba le ayuda cuando necesita cambiar su marco o protocolo)?

Una vez que obtenga una base sólida para creer que su tecnología y la arquitectura lo harán, es hora de enfocarse más en los problemas de tipo I.

No hay día de transición

Obtener confianza y pasar gradualmente de resolver el tipo I en lugar de II es un proceso; cuantos más clientes e implementaciones reciba, mayor será su confianza, y mayor será el precio que pagará por la deuda del Tipo I.

En dataloop lo estimamos cada pocas semanas, las cosas que creemos que son más sólidas en las áreas de Tipo II y pasando por el refactoreo y la limpieza de los problemas de tipo I. Este es un proceso lento y equilibrado que es fundamental para nuestro éxito. Especialmente si eres un startup y el fracaso no es una opción.

Así que asegúrese de reducir la velocidad para hacer las cosas bien desde el primer día, mientras que el producto aún se define a sí mismo, tenga cuidado con la tecnología rápida y sucia desde hace mucho tiempo en la casa de su cliente.