No hay que esperar a que un problema termine por explotar

Si se actúa con previsión, si se levanta la vista del suelo, es posible que la mayor parte de posibles problemas que puedan existir en una organización, en un departamento o en un proyecto, puedan ser atajados a tiempo o como mínimo ver minimizados su impacto.

Sin embargo, el miedo a tomar decisiones, un mal análisis de la situación presente y una mala previsión de la futura, una mala elección de prioridades, el inmovilismo, el hacer oídos sordos a quien conoce de primera mano un problema, son responsables de que un problema termine por materializarse y lo que es peor, que termine por explotar y tenga un impacto importante.

Cuando el usuario cree que sabe sobre desarrollo de software

Partiendo de la base de que proyectos donde el usuario pasa de ti están abocados, salvo contadas ocasiones, al fracaso y que esa es una de las peores situaciones posibles, existe otro tipo de proyectos que resultan complicados de gestionar y son aquellos donde el usuario o usuarios principales creen que saben sobre desarrollo de software.

No es un problema que el usuario sepa de desarrollo de software, antes al contrario, si sabe, probablemente entienda muchas de las contingencias que se producen en el proceso de desarrollo y será consciente de que su participación en todo el ciclo de vida del proyecto resulta esencial para intentar conseguir un producto acorde a sus necesidades. También es cierto que este tipo de usuarios será por regla general bastante exigente y tendrán base suficiente para evaluar si por tu parte como director técnico y/o por el equipo de desarrolladores se está manejando bien el proyecto y si se está dedicando la suficiente atención. Por mi parte no veo mal esa exigencia siempre y cuando se base en unos criterios objetivos y justos.

El problema está cuando el usuario cree que sabe, pero en realidad no tiene ni idea o tiene una idea demasiado superficial, cuando esto sucede te pondrán en demasiadas ocasiones en tela de juicio decisiones que hayas tomado relacionados con la gestión o del proyecto o incluso en algunos aspectos técnicos como el diseño físico de datos (de esto último he tenido experiencia directa con usuarios que han trabajado con bases de datos ofimáticas y modelos de datos desnormalizados o incluso las hayan construido y mantenido), esto en sí no sería perjudicial si realmente las opiniones del usuario estuvieran basadas en un conocimiento del proceso de desarrollo de software y sus técnicas, es más sería beneficioso porque nadie es infalible y se pueden cometer errores y cuanto antes se detecten estos mejor. Estos usuarios pensarán (es una generalización) que todo es más fácil de lo que parece, que las incidencias en el proceso de desarrollo son excusas y compararán continuamente el sistema que se desarrolla con aquel o aquellos que conoce, aunque no tengan absolutamente nada que ver.

El cliente y sus objetivos en los proyectos de desarrollo de software

Cuando se contrata un proyecto de desarrollo de software no sólo es suficiente con entregar un producto que funcione y en plazo, sino que la realidad es algo más complicada que eso, por ese motivo es muy importante identificar los deseos, expectativas y objetivos que tiene el cliente respecto al proceso de desarrollo del proyecto que se ha contratado, así como del resultado final que se obtenga del mismo.

Es cierto que es muy importante que funcione y que esté en plazo, pero también hay otros aspectos que son evaluables como por ejemplo la calidad del código, de la documentación, el seguimiento de estándares de desarrollo de la organización, la usabilidad, el rendimiento, cómo se han ido solucionando los diferentes problemas que se han producido durante el proceso del desarrollo, cómo ha sido el trato con el director técnico del cliente y/o con los usuarios, etc, etc…

Mantener una relación duradera con un cliente implica no sólo hacer las cosas bien, sino además llegar a conocerle. Esto no es sencillo, requiere tiempo y sobre todo tener conciencia de la importancia que tiene esto, a lo que hay que sumar que cada persona o cada cliente es un auténtico mundo y que para lo que uno es algo excepcional, para otro puede ser algo realmente pésimo.

No intentar entender lo que el cliente quiere o quedarse sólo con lo que interesa es ir a ciegas en un proyecto, ya que lo mismo se piensa que se están haciendo las cosas bien, cuando lo mismo se está yendo en la dirección opuesta a lo que se quiere.

Un cliente no es un objeto inmóvil y si algo no le gusta lo terminará diciendo, no obstante y como cada uno es diferente, lo podrá decir de diferentes formas y en diferentes fases del proyecto. Si no se detecta a tiempo que el camino no es el correcto, el proyecto correrá un riesgo importante de que fracase o se vaya en costes e incluso si el proyecto no fracasa, lo mismo sí se ha fracasado con el cliente.