Los derechos de los programadores

Para que un proyecto tenga éxito, el primer paso a tomar es hacer que cada una de las partes tenga respeto por los derechos de los demás. En la última entrada vimos los derechos del cliente. Hoy vamos a ver los derechos de los programadores.

#1 Conocer los objetivos del proyecto y tener unas prioridades claras.

Efectivamente, nuestra vida sería mucho más fácil si nos proporcionaran al principio (o lo antes posible), los objetivos priorizados.

#2 Conocer en detalle el producto a construir y aclarar y definir sus detalles si es necesario.

Por supuesto, los detalles del producto han de conocerse de forma suficientemente anticipada (podéis ver cómo lograr esto en mi serie de entradas sobre cómo hacer una toma de requisitos).

#3 Tener acceso al cliente, gerente, comercial o cualquier otra persona que tenga responsabilidades sobre la funcionalidad del producto.

Cuántas veces, las personas que toman decisiones funcionales están totalmente alejadas del equipo de desarrollo. Suele ocurrir que dicho equipo se ve bombardeado por cambios, funcionalidades, y se siente completamente alejado de la toma de decisiones. No es tanto tomar decisiones de forma activa (aunque tampoco estaría mal), sino simplemente poder participar en las decisiones y tener acceso directo a las personas que han definido las funcionalidades o son sus responsables, para aclarar dudas, conceptos y poder corregir definiciones incoherentes.

#4 Poder trabajar en cada fase del ciclo de vida de una forma técnicamente responsable (y especialmente no ser forzado a picar código desde el minuto cero).

¿Cuántas veces nos habremos visto obligados a escribir código desde el primer minuto? Esto, que es tan frecuente, es a la vez tan absurdo como una de mis frases favoritas:
- "Tú ves corriendo, que cuando sepamos hacia adónde hay que ir, te lo diremos"

Esta frase, tan frustrante como poco ilusionadora, es el pan de cada día en el desarrollo de software durante los últimos...¿50 años?

#5 Aprobar estimaciones de esfuerzo y entrega para cualquier trabajo que se le asigne. Esto incluye el derecho de tener el tiempo necesario para hacer estas estimaciones, y poder revisar dichas estimaciones si se producen cambios durante el proyecto.

Pues sí, es necesario cada vez más involucrar a los programadores en estimar o en aprobar y asimilar las estimaciones realizadas. Es estúpido hacer que los analistas o responsables estimen, y se aparte de esta tarea a los programadores, porque llega el día en que un programador es ascendido a analista...y tenemos un nuevo problema: no es capaz de estimar porque nunca se le ha dejado, y encima hemos quitado de programar a una persona que estaba muy preparada (¿porque le hemos ascendido al ser  bueno, verdad?)

Aunque se está volviendo al paradigma de tener equipos de desarrolladores de alto nivel, que toman también decisiones funcionales, ha habido una época en que se prefería una segmentación diferenciada entre programadores, analistas técnicos y analistas funcionales (u orgánicos). Por encima de ellos, los arquitectos tomaban decisiones de alto nivel, estructural (y cuántos arquitectos de boquilla aprovechaban para limitarse a decisiones obvias que aportaban poco a los problemas existentes, y eran totalmente inoperativos cuando tenían que enfrentarse a problemas reales...sobre esto creo que también tenemos para escribir otro día).

#6 Reportar el estado de mi trabajo de forma detallada a mis responsables y clientes.

Ya que somos responsables de nuestro trabajo, permitidnos informar y transmitir clara y detalladamente la situación. No hace falta hablar directamente con el cliente, pero al menos sí elaborar los correos o informes de estado, que además, nos prepararán para el siguiente nivel de nuestra carrera profesional.

#7 Trabajar en un entorno productivo, libre de interrupciones frecuentes y distracciones, especialmente durante las fases más críticas del proyecto.

Mmm esto, que también sería digno de otra entrada, es una causa frecuente del fracaso de los proyectos. ¿Acaso no recordamos la típica situación cuando vamos en el coche con nuestros hijos?:
- "Papá, hemos llegado ya?"
- "No, cariño, pero falta poco"
- (a los 2 minutos) "Papá, hemos llegado ya?"
- "Que no, cariño, que falta poco"
- (a los 2 minutos o menos) "Ya? Papá, ya?"
- "¡Que no, que te he dicho que no!"
- (a los 30 segundos...) "¿Papá, hemos llegado ya, ahora si verdad?"
- (Aquí el padre, ya está a punto de estampar el coche, asesinar a su hijo, vamos, le da todo igual)

Pues esta misma situación, pero cambiando al padre por el programador, y al hijo por el responsable/gerente/cliente, es el pan de cada día. Las empresas tienen comunicados internos, los proyectos tienen reuniones, informes, comités...Pero hay que definir períodos y horarios claros para ser productivos y sin interrupciones. Hagamos las reuniones, y comunicaciones internas (correos, preguntas, etc) en unos horarios establecidos (y mejor al final o al principio del día).

¿Y tú, estás de acuerdo con estos 7 derechos fundamentales de los programadores?