Estaba pensando por que demonios escribir software es tan difícil. Digo que es difícil porque hasta los supuestos expertos tienen un alto porcentaje de fracasar en entregar software estable, facil de usar, documentado y a tiempo.
Para que se den una idea, el 60% de los proyectos(en general, no solo de software) fracasan, todos hablan de eso en publicaciones como peopleware y varios artículos de intertet, solo hay que preguntarle al tío google para tener un puñado de ejemplos. De hecho, es el argumento de venta de Microsoft Project.
Por mas años de experiencia que uno tenga, por caras que sean las herramientas, por mas experiencia que el personal tenga sobre las herramientas, parece imposible hacer que un sistema nuevo salga bien “de una”. ¿Como puede ser que, teniendo gente que conoce perfectamente la tecnología con la que está trabajando y, no pueda hacerse un sistema que cumpla con las expectativas del cliente al primer intento? Ni hablar de tener un porcentaje de fracasos del 60%!. Y todo esto solo teniendo en cuenta proyectos en los que se decide no continuar. ¿Que hay de los sistemas que son construidos pero nunca son utilizados porque se descubre que representan un estorbo para el procesos que se deseaba agilizar?
Parece una locura que, en una civilización con una fuerte dependencia por el software, no seamos capaces de dominar completamente la construcción de este. La respuesta reside en el hecho de que los sistemas son hechos y usados por personas, por lo tanto, están sujetos a la mecánica de las relaciones humanas y, por ser el producto de un dialogo entre dos o mas grupos humanos, son especialmente vulnerables a la falta de comunicación entre las partes.
Por lo anterior, llegamos a la conclusión que aparece como punta de lanza del libro peopleware:
“Los factores que causan el fracaso de proyectos informáticos son de índole sociológico, no tecnológico.”
La complejidad del software reside en la especificación, diseño y testeo de la construcción conceptual, no en decidir como se llamaran las funciones y variables, el formato de los comentarios o la plataforma que se utilizará(aunque esto último no es tan trivial como suena en lo que acabo de decir).
¿En que cambia que una aplicación este hecha en .NET, Java, RUBY o .TXT si no se comprende cual es el objetivo que persigue y que necesidades trata de satisfacer?
El profesional en sistemas debería poner igual énfasis en conocer la herramienta en la que se está especializando que en dominar el arte de la comunicación. Tomemos como ejemplo a Linux. El famoso Sistema Operativo open source no sería lo que es si Linus Torvalds no hubiera sido capas de transmitir sus ideas en un por escrito, convocando a la cantidad de personas que convocó para participar del desarrollo.
Estudios realizados indican que dos de las habilidades más importantes que buscan las personas encargadas de contrataciones son las técnicas de comunicación oral y las aptitudes interpersonales(Goleman, 1998, pp 12-13). Aun en campos tan técnicos como la ingeniería, 72% de los encargados de seleccionar personal indicó que la facilidad de palabra era un factor muy importante(Darling y Dannels, 2003, p. 12).
Es importante indicar que por “técnicas de comunicación oral” o se esta hablando de pararse frente a un auditorio para protagonizar un monologo. También consiste en aprender a escuchar y a almacenar los datos que resultan de las entrevistas con el cliente. Es decir, aprender a tomar apuntes.
¡Cuan importante es esto!. Aprender a hacer cuadros sinópticos, plasmar taquigráficamente los requerimientos, características del workflow…en fin, toda la voluminosa cantidad de detalles que puede llegar a contener un sistema. A veces, un buen diagrama puede resultar mas esclarecedor que todo un cuaderno lleno de palabras.
Estas disciplinas no son mas complicadas que aprender cualquier lenguaje que ande dando vueltas por ahí, y los considero herramientas esenciales a la hora de encarar el análisis de un sistema para llevarlo al código.
Para más información acerca de los componentes sociológicos del desarrollo de los proyectos aconsejo leer el libro titulado peopleware, de donde tomé varias de las reflexiones expuestas aquí. Material valioso puede sacarse también del libro ¡Comunicate!
, también disponible en castellano.