Como NO desarrollar un sistema de información - Parte IV

Coordinacion y planificacion de las actividades, un tema que no habiamos tocado en las entregas anteriores porque, por el simple hecho que soy un programador, me centré en la programación/implementación del sistema; pero la planificación es (en serio, no es jodiendo, y sí, en mayúsculas) IMPORTANTE, tan importante que se escriben libros, manuales y estándares sobre ella, así que hoy nos vamos a concentrar en como NO planificar un sistema de información.

Lo primero que dicen los libros sobre la planificación de un proyecto es hablar con el cliente y preguntarle cuales son las características deseables en el sistema, la gente que sabe más que yo sobre esto llama a este paso "Gestión de Requerimientos", pero como en realidad nuestro sistema es lo más arrecho que se ha inventado desde el papel de aluminio, simplemente obviamos esta parte y le entregamos al cliente un sistema que hace lo que (a nuestro parecer) en realidad necesita, lo que el cliente quiere en realidad no es tan importante porque el no sabe de programación ni mucho menos de implementación de sistemas.

Como el cliente nunca sabe lo que quiere siempre van a existir momentos parecidos a esto:

Cliente: "Ah, se me olvidó decirles, necesito para ayer una nueva funcionalidad con lazos rosas y que me cante en la noche"
Desarrolladores: "Perfecto, como es un nuevo requerimiento, vamos a pasar el mensaje al líder de proyecto"
Cliente: "¿Escucharon la parte que lo necesito para ayer?"
Desarrolladores: "Sí, pero no podemos tomar la decisión así de fácil"
Cliente: "Bueno, apuren eso porque en serio es urgente"

A los que le sigue algo asi:

Desarrolladores: "El cliente quiere una funcionalidad X con rapidez Y"
Líder de proyecto: "Pero eso no se había acordado"
Desarrolladores: "Bueno, lo quiere para ayer en la mañana"
Líder de proyecto: "Entonces hay que cuadrar una reunión"

A lo que le sigue un día de reuniones y masturbación mental entre cliente, líder de proyecto y gerentes, donde el cliente elogia el trabajo realizado hasta ahora, los gerentes no hablan porque tienen que simular que están trabajando y el líder de proyecto trata de convencer al cliente que lo que el pide no es necesario o extremadamente difícil de implementar para comprar tiempo y así cuadrar otra reunión.

Después de la reunión simplemente el líder de proyecto le avisa a los desarrolladores que la nueva funcionalidad si se va a implementar, que en serio es urgente y que no pueden ni ir al baño porque eso tiene que estar listo ayer.

Al otro día/mes/semana el cliente vuelve a llamar y se repite el ciclo.

Después que se medio sortea el problema con los requerimientos (existentes,nuevos y los que existen pero no sabemos todavía), se empiezan a presentar los problemas con los tiempos de entrega, porque como siempre los tiempos de entrega son importantísimos (quizás hasta más importantes que determinar los requerimientos del sistema) y además son usados por los gerentes y jefes de división para masturbarse unos a los otros diciendo que los equipos de desarrollo son lo mejor que existe.

Ah pero eso no es todo, todavía hay más, para mantener un registro del avance del proyecto nada mejor que una cadena laaaaaaaaaaaaaarga de emails, donde cada desarrollador describe el problema que solucionó o el parche que implementó en la línea 1915 del código, así no hay documento, ni registro de los cambios y evolución del sistema, porque eso es demasiado trabajo para un líder de proyecto y además el espacio en los discos duros no es gratis, crear documentos inútiles es un gasto innecesario.

Y para "finalizar" (porque si sigo escribiendo voy a tener que buscar una editorial) no hay nada mejor que planificar las actividades por finalizar en una reunión corta los viernes por la tarde, así los desarrolladores tienen que pensar el fin de semana y nos olvidamos de ese pesar de reunirse los lunes por la mañana cuando nadie quiere trabajar.

Continuará.... (debería convertir esto en una novela o película)