Errores clásicos en desarrollo de sistemas informáticos

Este post nace a propósito de un libro que me gusta mucho, cuya portada pueden apreciar aquí.

"Rapid Development" o "Gestión de proyectos de Software" que es como lo he encontrado en español(parece que los nombres en español los pone el mismo tipo que le pone nombres en español a las películas y alos remedios).

Este libro de Steve McConnell(Dios salve a McConnell), del año 1996 no inventa el fuego o la rueda pero explica como mirar la rueda y el fuego de un modo diferente y con la distancia suficiente como para darnos cuenta si la rueda está con una excentricidad anómala o si nos podemos quemar.

McConnell presenta una lista de 36 errores clásicos en el desarrollo de software. Es impresionante el ver y contar cuantas veces sonríe un programador al ver la lista y recuerda cuando cometió uno u otro, ya sea por acción, misión o desconocimiento. Y es que en el desarrollo de software no todo es código y sintaxis que es el fuerte de los programadores e informáticos en general, hay mucho mas que solo bits, hay administración, en el sentido mas amplio, desde la dirección de equipos de trabajo, la sana distribución de horas diarias destinadas al trabajo, la gestión de la documentación, estrategias de venta, control de gastos, control de tiempos de desarrollo, cumplimiento de fechas y metas, correcta estimación de fechas y metas, etc.

Con el presente post, espero conseguir 2 cosas, que usted lea el libro(cosa un tanto dificil quizas) y por otra parte ponerlo al tanto de algunos de los errores citados en el libro, al menos los que yo he visto con mayor recurrencia de modo que si usted está evaluando el desarrollo o compra de un sistema esté atento a si las señales que se puedan generar en el proceso acusan uno de estos vicios.

1 - Política predomina sobre substancia:Muchas veces, las decisiones en el como y cuando implementar o desarrollar un sistema pasan por decisiones entre las cúpulas de la empresa cliente y la empresa proveedora del software sin consideración de las necesidades reales sino que prima el acuerdo comercial, la discusión sobre los beneficios y condiciones del negocio mas allá del por que o para qué y qué se compra o vende.

Recuerde, mas que una opción económica y pronta es necesaria una solución real y oportuna aunque pueda no ser tan económica ni pronta en primera instancia.

Habitualmente los recortes de tiempo y presupuesto terminan produciendo el efecto contrario, sobre todo si el recorte se da en la etapa inicial(análisis y diseño) pues al no tomarse todas las salvaguardas ni considerarse todas las implicancias la posterior modificación de los sistemas generan mayores costos, pérdidas de tiempo, datos e imagen.

2 - Falta de feedback de usuarios a desarrolladores: como mencioné en un post anterior, los programadores son expertos en herramientas informáticas, no necesariamente son expertos contadores, administradores, logistas, químicos, aeronautas, etc. si bien algunos tiene profundos conocimientos no siempre es así y es importante que nunca se pierda el contacto entre el equipo de desarrollo del software y los usuarios finales de la herramienta que estos crean para ellos pues lo que para un programador de 25 años, recien egresado de ingeniería, que nació con un computador al lado de la cuna puede parecer obvio y sencillo no lo será para un usuario de 50 años que quizás puede ser un excelente contador auditor o director de escuela pero a quien la cosa de la computación le complica . Es obvio, pastelero a tus pasteles.

3 - Aceptación de mas características a cambio de mas tiempo: Pasa, es cierto que pasa. Muchas veces los desarrollos se atrasan. Lamentablemente, muchas veces, quienes gestionan los acuerdos comerciales, a fin de no perder una venta ofrecen el oro y el moro aceptando desarrollar mas herramientas de las consideradas inicialmente a cambio de mas tiempo y paciencia. Es cierto, a esa altura, cualquier cliente espera una compensación por la paciencia que en ocasiones hay que tener con los equipos de desarrollo, pero(por favor: créame) habitualmente termina siendo una espada de Dámocles, pues al agregar características que no estaban consideradas desde un principio generalmente inestabilizamos los sistemas pues las modificaciones necesarias pueden atravesar a todo el sistema.

4 - Síndrome de la bala de plata o panacea: No, no y no. Los sistemas informáticos ni son infalibles, ni son 100% estables, ni son 100% confiables, ni son eternos, absolutos e invariables en el tiempo. Los sistemas informáticos son, a fin de cuentas, simples y meras herramientas para gestión de información.

No pierda esto de vista. Si un vendedor le dice lo contrario puede estar pasando una de 2 cosas:

a - Le están mintiendo descaradamente con tal de vender.

b - Le estan mintiendo por ignorancia.

Es mucho mejor un sistema claramente acotado y con limitaciones conocidas que en una versión futura concreta o incluirá esto y esto otro antes que un posible PanaceaWare que hará de todo en un par de meses que está en ajustes y sin un control de versiones claro.

Ya que este post quedó algo extenso, seguiré con otros errores típicos mañana para que la lectura sea algo mas sencilla.

Saludos

Manuel Gatica Holtmann