🤫 En todas las profesiones hay miedos latentes. El mayor miedo de un programador son las fechas de entrega o también llamados Deadlines.
Aunque es una falla en la que todos podemos caer alguna vez, con la intención de que no se convierta en un mal hábito, decidí escribir este post para explicar un poco sobre lo que he estado aprendiendo y cómo se puede mejorar.
Recientemente leí El camino hacia el Lean Startup: Cómo aprovechar la visión emprendedora para transformar la cultura de tu empresa e impulsar el crecimiento a largo plazo de Eric Ries
El Producto Mínimo Viable y su importancia
El producto mínimo viable en el mundo del desarrollo de software (lo que atañe a mi campo de acción), es una versión mínimamente funcional que permite probar una hipótesis o teoría en un modelo de negocio. Básicamente es crear un prototipo para comprobar algo.
Digamos que para que tu producto sea usado y comience a generar dinero, que es lo mínimo que debería hacer tu producto o servicio? Partiendo de esta idea es cuando comenzamos a aplicar la metodología Lean Startup
Personalmente me alejo en lo posible de los proyectos que exigen una fecha de entrega. Y no por esto quiere decir que me voy a tomar una eternidad para desarrollar el proyecto. Al contrario. La metodología que te voy a explicar tomando como base el PMV, te va a ayudar a acelerar en el desarrollo.
Lean Startup en el desarrollo de software
Soy Freelancer, y quizas no soy el mejor ejemplo de aplicar Lean Startup en una compañía. Como freelancer siempre estoy creando productos digitales, soportándolos y experimentando con las metodologías de desarrollo para ser mas productivo. Me gusta lo que hago y por eso siempre estoy en aprendizaje constante.
Si tienes una agencia de marketing o web, tambien puedes aplicar el Lean Startup sin problemas. No hace falta tener una industria específica porque hasta Recursos Humanos en compañías enormes y tradicionales lo han usado.
Entonces, la cuestion es ésta. Imaginemos el proceso desde el principio de como ejecutas tu plan de desarrollo.
Pasos en la construcción con Lean Startup:
El cliente te contacta. Desde el momento del contacto debes decidir si tienes la disponibilidad y el tiempo necesario para atender un nuevo proyecto. Hay que tomar decisiones.
Recolección de información. Cuando ya tomas la decisión de que si puedes trabajar con un cliente determinado, lo más importante es recolectar la información de lo que tu cliente quiere. En este paso es cuando se debe tomar en cuenta la metodología Lean Startup
Debes determinar con tu cliente, cuales son las caracteristicas y funciones mínimas de la tienda o sitio web para que comience a funcionar y/o generar dinero. ¿Qué es lo que debe estar allí presente en la primera versión? Debes incluir lo mas importante que debe salir en el menor tiempo posible. Lo que no entre dentro de ésta lista de prioridades es mejor colocarlas a un lado del Backlog para que no se incluyan en la primera versión del producto. Luego puedes distribuirlas en base a prioridades en las siguientes versiones.
Siempre es conveniente intentar remover el mayor miedo de un programador, que son las fechas de entrega. ¿Cómo nos ayuda el Lean Startup con esto?
Facil. Si logras determinar desde el principio las prioridades y lo que se necesita para salir al mercado cuanto antes, ya tendras la mitad del trabajo realizado. Todo es una cuestión de mentalidad.
Trabaja con tranquilidad
El trabajo de un programador es mental. No es como cualquier otra profesión que requiere actividades repetitivas, de esfuerzo. Mas sencillo, no se puede mantener una conversación fluida mientras el progrmador trabaja en un proyecto xD. El uso y consumo mental cuando está cumpliendo con su jornada es intenso.
Ahora imagina las tensiones, preocupaciones y todas esas cosas que nos hacen mantener dialogos internos demasiado complicados. Deudas, problemas familiares, carencias o fechas de entrega.
Si no sabes gestionar tu mentalidad y colocarla en un estado de concentración y paz, entonces se te acumularán muchas más porque vas en ciclo. Con ciclo me refiero a que una preocupación genera otra por el impacto que produce, y así sucesivamente.
Trabajar en un ambiente calmado tambien es de suma importancia para mi. Evito las cafeterías o lugares muy concurridos. El ruido del ambiente me quita mucha paz mental para terminar los proyectos o simplemente me distrae la mayoría de las veces. Por supuesto todos somos distintos. Puede que prefieras estos ambientes para concentrarte.
No seas dañinamente perfeccionista
Cuando se trabaja desarrollo web obviamente tienes que ser perfeccionista a nivel de precisión de colores, tamaños y pixeles en elementos. Pero con perfeccionismo me refiero a esa tortura de no entregar nunca hasta que lo que estemos desarrollando sea perfecto.
Muchas veces ni siquiera sabemos a qué nos referimos con perfecto. Entonces, por que no hacer lo mejor y necesario con tal de sacar la primera versión de máxima calidad lo mas rapido posible? Lo ideal seria que podamos escalar rápidamente una versión que podamos entregar al cliente, sea analizado y recojamos mas información sobre el avance.
El cliente dinámicamente te dirá qué necesita, te dara su feedback. Me he dado cuenta que muchas veces los clientes encuentran características o funciones que no eran necesarias. Una vez que ven su proyecto funcionando caen en cuenta de lo que realmente necesitan.
Aprende las diferencias entre: Lo que tienes que hacer, lo que podrías hacer y lo que quieres hacer. Esta es la distinción. Si aprendes primero a hacer lo que tienes que hacer (lo mínimo funcional), te encontrarás con mejor disposición para pensar en lo que podrías hacer. Y asi por supuesto agregas lo que quieres hacer al final, que representa esa milla extra. Eso que te distingue del resto por dar más de lo que tienes que dar. Ese profesionalismo que te hace un desarrollador 10X.
Aprende a decir NO
Este es lo mas común del mundo. Queriendo ayudar a todos, terminas ayudando a nadie. No mires el plato de otros o el menu si ya tienes suficiente comida en tu plato.
Hablandole a los clientes potenciales y a los actuales. Ese es el problema de contratar programadores demasiado baratos.
Un programador que cobre USD$15 o menos por hora (en paises occidentales por supuesto porque algunos paises de asia solo necesitan USD$500 o menos al mes para cubrir sus gastos) tendrá una calidad extremadamente deficiente.
Hay cierto precio estandar para crear productos digitales de calidad, y claro, lleva un tiempo. Ahora si un programador o agencia cobra extremadamente barato por un servicio como éste, se encontrará rápidamente en problemas. Para cubrir el déficit tendrá que permanecer diciendo SI a muchos proyectos. ¿Que significa eso? Que para ser rentable tendrá que tener entre 3 a 4 proyectos o mas simultáneos. Esto retrasa a cualquier ser humano que se conozca trabajando en el mundo tecnológico.
Hay una anecdota que me da mucha risa porque eso sucede mucho en mi país con los talleres mecánicos. Siempre se me viene a la cabeza. No se cómo funcionen en otros paises, pero en Venezuela, cuando llevas el carro a un mecánico independiente verás que hay muchísimos carros esperando a ser reparados. Generalmente estos talleres solo tienen 1 o maximo 3 mecánicos trabajando.
La cosa es que tienen 10 o 15 carros pendientes por reparar en el taller, y siguen recibiendo otros que terminan acumulándose en el taller ampliando el número. El desorden impera en estos talleres. Lo interesante es que siempre recuerdan el nombre de los clientes, el carro que les pertenece, etc. Y su frase favorita es «ven la semana que viene».
No busques programadores o agencias baratas. Mejor busca profesionales que tengan un precio accesible, una carga de trabajo bien distribuida y una trayectoria de responsabilidad.
En fin, saber decir NO va a evitarte el mayor miedo de los programadores. Las fechas de entrega.
En el mundo del software siempre habrá problemas, bugs, errores, etc. Es una profesión aún muy frágil. Con lenguajes que son viejos, muy nuevos otros. Cada uno con sus respectivas limitaciones y comportamientos.
Aunque las fechas de entrega pueden hacernos entrar en pánico, lo bueno es que a futuro siempre puedes tomar las medidas necesarias para que no te dejes arropar por ellas.
Lo que quería transmitir tambien como mensaje es una premisa básica. Un mantra en contra del miedo latente a las Deadlines.
Es mejor ser lento, que irresponsable.
Siempre se puede conseguir mas tiempo. Aunque un retraso en la fecha de entrega puede ocasionar retraso e incluso pérdidas a un cliente (arriba te hablo de como evitarlas desde el principio), no queda otra opción que conversar con tu cliente para extender el plazo. Eso si, si ya fallaste la fecha de entrega una vez, ponle corazon y alma a estimar mejor en la nueva oportunidad que se te dé.
No seas mala persona de volver a caer en la misma situación de estimar mal y volver a fallar la fecha de entrega porque eso ya te hace alguien irresponsable. Sé responsable y estima bien. Lee, aprende todo sobre estimaciones y en lo posible, evita proyectos que requieran fechas de entrega. Es mejor desarrollar productos a velocidad de la luz entregando versiones pequeñas como los que se pueden con la metodología Lean Startup
De hecho ya el mundo del software de alta calidad funciona asi. Se intenta escalar versiones pequeñas, que permitan comprobar hipótesis rápidamente y experimentar, conocidos como Metdología Ágil. Son procesos eficientes que no reparo en usar con mis clientes.
El potencial de un desarrollo y soporte constante usando Lean Startup y Agile development son ilimitados, por eso he venido leyendo y aprendiendo muchísimo sobre esto hace un tiempo. Es la fórmula usada para casi cualquier cosa, respecto a optimización de procesos y creación de productos en ecosistemas como Silicon Valley.
Mejor no te ofrezco una única fecha de entrega con los conocidos dolores de cabeza. Mejor te ofrezco un desarrollo constante, cercano, experimentador y rápido, que nos permita sacar versiones, probar, planificar y aprender para seguir añadiendo características. El aprendizaje que se obtiene de esta dinámica es invaluable y seguramente estaré hablando mucho más en algunos próximos posts.
