Para los equipos de desarrollo de software, ¿cómo puede saber si no está enviando el producto lo suficientemente rápido?

Con mucho, el mejor punto de partida es el juicio cualitativo de los miembros del equipo experimentados y / o más talentosos. Los desarrolladores principales y los gerentes de producto técnicamente versados ​​deben tener una muy buena idea de si el equipo se está moviendo tan rápido como deberían.

Un error común es saltar directamente a “métricas” y basar el juicio en algo como “velocidad”, que a menudo los gerentes inexpertos interpretan mal. No se puede confiar en la velocidad como punto de partida, porque no es una medida absoluta; Es una medida de la capacidad de un equipo para progresar en relación con sus predicciones. Como tal, es una aproximación que es tan buena como la capacidad predictiva de un equipo.

Si bien la predicción es una habilidad valiosa, ya que ayuda enormemente a la compañía a planificar sus funciones, es auxiliar para el desarrollo de productos en la mayoría de los casos, y es algo que se puede mejorar con el tiempo. Cuanto más nuevo sea el equipo, el producto y el mercado, las cosas menos predecibles serán. Pero, las personas con experiencia aún pueden hacer buenos juicios cualitativos y pueden abordar los problemas que están ralentizando al equipo. Si un equipo no cumple sus objetivos, pero la razón es que se toparon con algo inesperado (e impredecible), como suele suceder con los nuevos productos, eso no debe contarse como un fallo. Siempre que el obstáculo se aborde de manera conveniente, solo debe considerarse como desconocido durante la planificación. Si, por el contrario, una falla se debe a la falta de diligencia, el tiempo / pensamiento inadecuado dedicado al diseño, o algo similar, ese es un problema que debe abordarse.

A medida que los productos y los equipos maduran, la previsibilidad aumenta, tanto porque la base del código es más estable, modelada y comprendida, como porque el equipo simplemente mejora. En ese punto, puede usar las métricas de manera más efectiva, ya que la brecha entre su medida relativa y la realidad absoluta de la implementación se reduce. Ahora será mucho más fácil para ellos cumplir constantemente un cronograma, y ​​ese cronograma debe ser uno que intente maximizar su producción (de manera sostenible).

Realmente no desea que su empresa entre en el patético estado “bajo promesa y sobre entrega” que las grandes organizaciones a menudo sufren. Como resultado, primero debe confiar en un liderazgo fuerte y personas altamente motivadas, y otras medidas en segundo lugar. De hecho, en ausencia de esos, es casi seguro que irás muy lento de todos modos.

2 cazadores, Jack y Henry, caminaban por una jungla cuando se encontraron con un oso enojado. El oso comenzó a correr tras ellos. Ambos corriendo.

Jack: no podemos escapar del oso
Henry: no estoy tratando de escapar del oso
Jack: ¿Qué quieres decir? El oso te matará
Henry: estoy tratando de escapar de ti

Un equipo de desarrollo de software necesita enviar el producto más rápido que la competencia. Si eres capaz de superar a la competencia, entonces estás a salvo.

Netflix, por ejemplo, obtuvo una gran ventaja sobre el alquiler por correo y videos en línea. Entraron al mercado antes de que nadie se diera cuenta de que había un mercado. Sin embargo, su negocio es tal que casi cualquier persona puede hacerlo. La forma en que sobreviven es adelantándose a otra persona. Han diseñado su empresa para enviar rápidamente. Pueden lanzar código a producción cientos de veces al día. Sin embargo, eso no significa que el código pase de la idea a la producción instantáneamente. Una vez que una pequeña idea es refinada, definida y escrita en una “solicitud de función”, podría llegar a la producción en un día más o menos. Sin embargo, las grandes características pueden llevar más tiempo. El envío del producto en un día es lo suficientemente rápido para Netflix. Digamos que Comcast sueña con una función de “asesino de netflix”, la lanza. Netflix puede replicarlo y lanzarlo al día siguiente. Eso es lo suficientemente rápido.

Uno de mis clientes trabaja con uno de los 10 principales bancos de EE. UU., Y al banco no le importa recibir lanzamientos después de 6 meses. Esto se debe a que existen enormes barreras de mercado que protegen al banco. Los bancos más pequeños pueden crecer lo suficiente como para amenazarlo, pero necesitan años para hacerlo. Están más preocupados por la seguridad de los datos. Para ellos, un lanzamiento cada 6 meses es lo suficientemente rápido

Solo necesitas correr más rápido que la competencia.

Contrariamente a la creencia popular, no existe una única “regla de oro” sobre qué tan rápido debe enviar el producto. Algunos productos están en ciclos de 1 año (piense: teléfonos celulares, computadoras portátiles, etc.). Otros productos se actualizan casi todos los días (piense en Facebook, Twitter, etc.).

Dicho esto, hoy en día debería enviar el producto lo más rápido posible y conducir constantemente para minimizar el tiempo de retraso sin desasociar su producto de sus usuarios.

Mis objetivos personales para casi cualquier producto:

  • Las correcciones de errores deben publicarse tan pronto como se realicen en un entorno SaaS, o empaquetarse como un paquete de servicio / actualización mensual para instalaciones locales.
  • Las nuevas funciones deben lanzarse tan pronto como estén listas para los usuarios en un entorno SaaS, o empaquetarse como una actualización trimestral para las instalaciones locales.
  • Las actualizaciones que cambian significativamente el comportamiento deben comunicarse con anticipación (la duración depende del delta) y publicarse tan pronto como su base de usuarios esté preparada en SaaS o como parte de una actualización mensual / trimestral para las instalaciones.

No creo que la mayoría de los productos de software puedan permanecer “saludables” y durar más de una cuarta parte sin una actualización significativa. Todos los productos que he visto hacer esto terminan estancándose y luchando a medida que el nuevo código se acumula y hace que el riesgo y la regresión crecientes salgan por la puerta. Una vez que pasa ese cuarto de línea, comienza a ingresar un ciclo de retroalimentación desagradable de regresión que causa cambios que causan regresión que causan cambios …

Respuesta rápida de Reid Hoffman:

“Si no está avergonzado por la primera versión de su producto, ha lanzado demasiado tarde”

Respuesta más larga:

  • ¿Tiene características que se están eliminando constantemente ya que los desarrolladores o la administración quieren que sea perfecto desde el principio? Hay una señal reveladora.
  • ¿Le parece que construyó un producto que al momento del lanzamiento, está desactualizado y no satisface las necesidades del cliente? ¿Si hubieras lanzado algo antes, habrías recibido los comentarios necesarios para cambiar? Hay otra señal.