Quienes me conocen saben que me considero un friki de los viajes al espacio. Hace unos días tuve la suerte de ver una entrevista a Elon Musk, con un acceso total a la Starbase de Spacex en Boca Chica, Texas, a través del canal Everyday Astronaut. Una entrevista de algo más de 2 horas, concedida por Elon a Tim Dodd.
En dicha entrevista, sobre todo en la primera hora, Elon nos explica de primera mano, cómo funciona lo que él define como un proceso de 5 pasos. En la misma, nos dice que intenta que sean implementados en sus empresas de manera rigurosa y los detalla a través de algunas analogías y ejemplos de su experiencia corporativa, en Tesla y en Spacex. Considero que se pueden aplicar a cualquier proceso de desarrollo de Software, sin hacer demasiadas variaciones.
Acá mi resumen de sus cinco pasos:
- Examina y limita los requerimientos, que sean lo más tontos posibles.
- Cuestiona los requerimientos porque, aunque la persona que solicita es brillante, todos se equivocan.
- Deben tener nombre y apellido, es decir, son personales, no de un departamento. Puede pasar que un requerimiento sea de alguien que ya no está ni en la empresa y que el departamento no esté de acuerdo.
Cuántas veces en nuestra vida profesional nos encontramos con la pregunta de ¿quién ha pedido esto? y nadie del equipo lo sabe. En muchos casos nos encontramos procesos enteros, diseñados a la medida de alguien que ya ni siquiera pertenece a la organización. Esto pasa de manera frecuente, cuando se pone de lado la funcionalidad real, respecto a la satisfacción de un cliente particular, aunque el mismo sea parte de la organización.
- Elimina procesos y simplifica.
- Si el 10% del tiempo no vuelves a agregar algo que pensabas que no necesitabas, no estás simplificando lo suficiente.
Este escenario es muy típico de modelos de datos amplios para funcionalidades corporativas. En los mismos, siempre encontramos tablas en las que no existe ningún valor almacenado o segmentos de código fuente donde solo se encuentran esbozadas ideas que nunca se llevaron a cabo, están por ahí diseminadas en todas partes, pero que nadie se atreve a tocar o a eliminar, porque puede afectar “algo”
En este punto creo que el enfoque de MVP (Minimun Value Product o Producto Mínimo Viable) nos ayudarían a minimizar estos elefantes blancos. Funcionalidades enteras desarrolladas de las cuales solo se usa una pequeña parte. El enfoque debe ser, funcionalidad mínima necesaria y luego, si es necesario, se puede ampliar.
- Optimiza el resultado.
- El error más grande en ingeniería es optimizar cosas que no deberían haber existido en un primer momento.
Creo que poco o nada más queda por agregar. Se pierden cientos de horas corrigiendo piezas de software que nunca han debido existir. Existe una frase que se me grabó hace mucho tiempo, automatizar el error y eso es algo que ocurre en la mayoría de las organizaciones.
- Acelera el tiempo del ciclo, presiona en el tiempo.
- Solo después de completar todo lo anterior entonces se puede acelerar producción.
Acá podríamos abarcar muchas líneas analizando esto. Es bastante común encontrarnos líderes de equipo, project managers y organizaciones en general, presionando para que las aplicaciones estén listas antes de tener claro los requerimientos y al menos la mayor parte de las funcionalidades definidas. Sobre esto haré una ampliación sobre lo que considero que es el punto más difícil en todo proyecto de software, vender tiempo.
- Pruebas completas de funcionalidades, hacía el final, en lugar de pruebas individuales.
- Hay partes que probadas solas pueden funcionar, pero se descartan piezas que realmente no están mal y que igual funcionan una vez instaladas.
- Se hacen pruebas que no obedecen al requerimiento real y que solo se entiende o descubre cuando se prueba el conjunto.
He visto mucho software que se programa para pasar los casos de prueba, pero que al llegar a las pruebas funcionales o de integración simplemente no funcionan. Por esto es que todos deben entender cuál es el fin de la pieza que se está realizando, lo importante de entender el contexto. En dicha entrevista, nos da algunas ideas bastante interesantes de cómo involucrar al personal, por ejemplo, todos los ingenieros son ingenieros jefes, en el contexto de Spacex, esto es necesario para que entiendan el fin de lo que están realizando y se den cuenta de cuando están haciendo una mala optimización. Si bien en otras áreas o empresas, se puede aplicar a levantar el nivel de todos los desarrolladores, llevarlos a que puedan considerarse seniors, en el sentido de involucrarse en los proyectos y logren internalizar la funcionalidad.
Y a manera de epilogo, para Elon, automatizar es la última etapa.
A continuación, las 3 partes de la entrevista.