Cómo vivimos el desarrollo del software repercute directamente en nuestra satisfacción tanto laboral como personal.Soy licenciado en Informática y trabajo como programador desde 1998. Durante este tiempo he participado en múltiples desarrollos de programas de gestión, tanto para clientes privados como públicos.
Siempre me ha sorprendido la dificultad de conseguir desarrollar un programa basado en unas especificaciones concretas, y más de una vez me he quejado de cuánto cambian dichas especificaciones. Al principio arrancas con un plan, empiezas a construir el programa y a mitad de camino te cambian algo. Vuelta a planificar, vuelta a construir, probar, etc... ¡Es el cuento de nunca acabar! y efectivamente, nunca acabas del todo el programa.
Lo más habitual es que este problema provoque retrasos en la fecha de entrega y al final se ponga en producción un programa con bastantes errores y que no cumple las espectativas del usuario.
La mayoría de las veces, la solución que intentamos dar a este problema es lo que llamamos Death March, que consiste en hacer todas las horas extra que sean necesarias con la esperanza de que algún milagro haga que salgamos a producción dentro del plazo y con absolutamente todo lo que debe contener el programa en cuestión. A veces sale bien (aunque yo no recuerdo ninguna). Por desgracia, lo que se suele conseguir es aumentar los costes y la frustración del equipo y retrasar aún más la entrega. Además, el usuario pierde confianza en la profesionalidad del equipo de desarrollo.
Mucha gente confunde horas extra con compromiso y dedicación, cuando en la mayoría de los casos lo que se consigue con las horas extra es reducir la eficiencia del trabajador mediante el agotamiento. James Shore, en su artículo Crunch Mode, explica muy bien los costes reales de las horas extra, y en How to Turn Smart People Into Ordinary People trata, en mi opinión con mucho acierto, sobre los efectos de la presión en los equipos de desarrollo de software.
No hay nada de malo en hacer horas extra cuando son necesarias, pero tristemente, una vez que empiezas suelen convertirse en habituales, y lo que es más, empiezan a esperar de ti que las hagas.
En 2007, la empresa en la que trabajo nos dio a un grupo de trabajadores un curso para programar en Java. En uno de los manuales, y totalmente de pasada, se mencionaba el artículo The New Methodology de Martin Fowler, que para mí supuso toda una revolución. Descubrí que había una forma de entender la programación que permitía sacar adelante proyectos de forma predecible mientras las especificaciones van cambiando. De hecho se espera que el usuario las cambie para adaptarse lo mejor posible a lo que realmente necesita.
Desde entonces he leído mucho (especialmente sobre Programación Extrema) y he experimentado mucho en distintos lenguajes, incluso en algunos que no parecen muy preparados para TDD, como SQLWindows.
A día de hoy me resulta más sencillo enfrentarme a nuevos desarrollos sabiendo que puedo partir de un diseño más o menos general y llegar a algo utilizable en poco tiempo y con la seguridad de que por el camino podré adaptar ese diseño conforme voy aprendiendo más acerca de la solución al problema que intento resolver.
Al aprovechar mejor el tiempo que dedico a mi trabajo, rara vez necesito hacer horas extra. Esto repercute directamente en mi vida familiar, lo que mejora mi estado de ánimo y me aporta energía para afrontar mejor mi trabajo, creando así un ciclo retroalimentado que se potencia a sí mismo.
Lo mejor que he hecho en los últimos años ha sido pasar de vivir para trabajar a trabajar para vivir. O dicho de otra manera, por mucho que te guste tu trabajo, no deja de ser el modo de financiar tu vida. No dejes que se convierta en toda tu vida.
No hay comentarios:
Publicar un comentario