Envíe unidades de software más pequeñas y limite el tamaño de sus sucursales locales de alojamiento

En la última década al frente de HackerNoon , he trabajado con muchos desarrolladores de software talentosos y, al principio de su mandato, normalmente termino diciendo lo mismo: enviar unidades de software más pequeñas y limitar el tamaño de sus sucursales locales de alojamiento. ¿Por qué? Aquí están las dos razones clave y un gran pero:

1. Los usuarios obtienen más beneficios de su trabajo y le brindan comentarios sobre él mientras usted continúa trabajando para completar el proyecto.

Si tiene un proyecto que requiere 6 meses de trabajo y no se pone en marcha durante 6 meses, son 5 meses y 30 días en los que los usuarios no obtendrán ningún beneficio de su trabajo. Sólo cuando esté activo el resto de Internet podrá tener la oportunidad de beneficiarse de lo que usted envía. E incluso entonces, es justo cuando comienza la enorme y cuesta arriba batalla por la adopción. Si, en cambio, enviaras parte del proyecto cada semana, los usuarios comenzarían a ganar valor a lo largo del ciclo de vida del proyecto.

Dane Lyons , mi antiguo colega, me dijo una vez que “deberíamos seguir añadiendo unidades atómicas de valor y realizar tantas liberaciones como sea necesario. Fácilmente podríamos tener 10 lanzamientos de [funcionalidad] antes de que estemos contentos con ello y listos para seguir adelante”.

Como director ejecutivo, a menudo juzgo a los nuevos empleados por el tiempo que les lleva convertirse en contribuyentes rentables. En ventas, esto es más sencillo, ¿sus ventas excedieron su compensación? Por supuesto, hay otras cosas a considerar, como los costos marginales en marketing, infraestructura, etc., pero como sea que se mire, es más difícil medir cómo un desarrollador de software impacta el resultado final que un vendedor. Si está ascendiendo a un nuevo rol como desarrollador de software, le recomiendo que intente unir con éxito sencillos antes de intentar conseguir jonrones.

En el juego del desarrollo de software, no existen reglas universales sobre cuál es la puntuación. Seguro que algunas personas asignan sistemas de puntos y otras definen KPI, pero al final del día, son las personas que utilizan su producto quienes determinan si está creando valor o no y cómo. Al enviar antes, recibirá comentarios antes. Las personas que utilicen su software dejarán más claro cómo construir y no construir la próxima unidad atómica del proyecto.

2. Cuanto más se desvíe su sucursal de la realidad de la producción, más difícil será para los compañeros de equipo contribuir a su proyecto y hacer avanzar los proyectos adyacentes.

Las externalidades de no enviar la versión más actualizada pueden ser más difíciles de ver al principio. Todo está conectado. En un producto como HackerNoon, por ejemplo, la página de perfil y la página de historia no existen en el vacío; existen como páginas conectadas dentro de un producto. Si se producen cambios en el funcionamiento de una página, afectará el funcionamiento de todas las páginas conectadas a ella.

Si su sucursal local es muy grande, otros cambios que ocurran en las páginas o funciones conectadas a ella a menudo no funcionarán una vez que su sucursal obesa finalmente entre en producción. Esto rompe cosas. Esto crea errores. Esto obliga a la necesidad de rehacer el trabajo. Esto crea el deseo de que tus compañeros de equipo no quieran trabajar contigo. Esto podría incluso crear una experiencia de producto peor que la que ya tenía antes de todo el trabajo que dedicaba a su sucursal local.

Al realizar cambios más pequeños con mayor regularidad, está empoderando a otros para que contribuyan. Sienten que lo que envían también funcionará porque ambos ya están de acuerdo en cuál es la línea base de producción. Incremental es tu mejor amiga. Te conecta con la realidad. Si los cambios incrementales están afectando negativamente al producto, ¿qué le hace pensar que cambios más grandes en la misma dirección afectarán positivamente la experiencia del producto?

Y el gran pero es: no tengas miedo de los proyectos audaces que pueden convertirse en ramas demasiado grandes porque eres un mal idiota que es capaz de marcar la diferencia en cómo funciona esta maldita cosa para la gente.

Algunos proyectos simplemente tienen que ser grandes sucursales. Por ejemplo, cosas con dependencias masivas, como nuevas bases de datos, pueden estar tan arraigadas en el uso existente que es mejor retroceder el tiempo y abordar el proyecto como una versión 2.0 anual local. Y otras tecnologías innovadoras, como ChatGPT, tardaron tanto en desarrollarse que simplemente no tendría sentido adoptarlas para lanzar una versión UX de mierda, incompleta y sin capacitación de la nueva tecnología. Haz grandes cambios. Cuando tengas la pista. Cuando tengas el equipo a bordo. Pero no seas grandioso. La mayoría de las veces el desarrollo de software no es reinventar la rueda. Se trata simplemente de enviar la siguiente unidad atómica.