Proyectos Informáticos… el software es una herramienta, no un fin!
Siguiendo con mis comentarios acerca de lo que voy experimentando en mi labor de Asistente Ejecutivo del Centro Microsoft, del 3IE, me ha llamado mucho la atención un par de puntos que suelen dejarse de lado sin querer pero que tienen a cobrar importancia en el camino y puede llegar a hacer fracasar el proyecto en si: los requerimientos del cliente.
Me ha tocado estar en la presentación de algunas soluciones Web, básicamente Sitios y paneles de control de proyectos basados en Web. Los personajes típicos en estas reuniones los componen dos tipos de sujetos: los técnicos (usualmente estudiantes de informática que realizan soluciones tecnológicas) y los ejecutivos (o usuarios finales, quienes utilizan dichas soluciones y que generalmente pertenencen al área de gestión), es decir, los personajes que menos se entienden en una organización.
Pues bien, la tendencia suele repertirse cuando avanza ya la media hora de presentación del producto (software, webpage, más software, más webpage…) y después de mostrar el atractivo del diseño y la belleza de las fuentes en CSS surgue la humilde pero terrible pregunta del ejecutivo: “Se puede crear un sistema que liste los integrantes en orden alfabético???”. Sana pregunta según el ejecutivo y fácil de aplicar, piensa como creyendo que la tarea que en Excel es “de muestra un botón” es similar en este caso. La cara del técnico, acostumbrado a lidiar con preguntas sanas que complican el proyecto ajustando las horas de trabajo (siempre se termina la pega en horas de la noche!), le responde: “mmm, pero mira, esta opción que está acá, te permite mostrar a todos los integrantes en pantalla” poniendo una cara de “esto es lo que necesitas”. El ejecutivo incrédulo, le vuelve a preguntar lo mismo: “si, pero se puede hacer que aparezcan en orden alfabético” y agrega “para no tener que buscar en toda la lista”. Ahi el técnico se aferra de la palabra “buscar” y le señala la posibilidad de buscar al integrante en el flamante buscador interno implementado en el producto. A la cara de impaciente del ejecutivo, se le suman varias similares en la mesa de la reunión… ya varios se impacientaron. El ejecutivo de más alto rango, entiende las diferencias que se están generando y tratando de poner cota a la discusión que se ha extendido más de lo normal, le dice al técnico “no, si ya entendimos que se puede tener a todos los integrantes de una vez en pantalla y podemos además buscarlos, pero se pueden listar haciendo click en la letra de su apellido o que simplemente tengan un orden alfabético” termina como si ya no bastara con repetirlo tres veces.
El técnico un poco más inquieto, pregunta “a ver, mejor díganme cuál es la idea!”. Eso bastó para descontrolar al más sumiso de la mesa. Yo, solo observaba (y aprendía ) El jefe entonces, en un acto ya más motivado por la impaciencia le pregunta tajante “sabes hacerlo, o no!”, el técnico sin alternativa le responde: “sí”, y la respuesta que se veía venir: “entonces se hace”.
Esto es un caso real, y creo que por lo observado que se repite en muchas reuniones entre las áreas de informática y gestión. Los primeros suelen pasarse en vela creando innovadoras aplicaciones tecnológicas y los segundos creyendo que lo que es simple en la práctica también lo es en el desarrollo.
¿Qué sucede? ¿Por qué suele costar tanto trabajo coordinar aspectos que parecieran ser simples, pero terminan siendo EL tema de la reunión? En el caso anterior, se dio que el técnico se negaba a entender lo que quería el ejecutivo, presentando una solución que no era lo que necesitaban sino la que él deseaba entregar. Mientras, el ejecutivo hacia oídos sordos a las respuestas y gestos del técnico cuyo mensaje era claro: listar en orden alfabético me implica un trasnoche!
La comunicación que tenemos día a día en forma verbal, gesticular, etc. siempre se complica cuando los lenguajes e idiomas son diferentes. El lenguaje del técnico definitivamente no es el que habla el ejecutivo y viceversa, por lo que llegar a acuerdos sin traductores de por medio suele ser un desafío.
El problema de la comunicación a menudo se provoca cuando la solución ofrecida se presenta como un fin, es decir, adaptemos nuestros hábitos de trabajo a este software, si no sabes usarlo… te enseño, pero esto no se cambia (y si se cambia, se hará pero superficialmente). Diseñar una solución con este punto de vista, perjudica a ambas caras de la moneda. El técnico se frustra porque lo realizado lejos de asombrar al público quedó como un paquete inflexible. El ejecutivo por su parte se frustra porque no se le consideraron sus requerimientos.
La pasión que involucra un programador en su proyecto, puede llevarlo a un final incierto si no se ajusta a requerimientos solicitados por el cliente final dentro de los límites de capacidad del desarrollador. Y no solo ajustarse al plan conlleva al éxito, sino que también la humildad de aceptar que el usuario es un ignorante en la materia y muchas veces pedirá cosas a las cuales hay que responder con calma : “eso no se puede hacer, te lo dije”. Se debe intentar llegar a la presentación del producto sin encontrarse con sorpresas del público. Esto significa que el usuario ya debe de haber visto por lo menos un prototipo y utilizado en parte, de modo de ajustar en el camino algunas piezas que no calzan. Nunca llegar a la reunión y mostrarle al usuario algo nunca antes visto!!!
Más adelante comentaré otra situación similar, pero que toca otro tema: “las innovaciones tecnológicas vienen siempre de la mano con innovaciones organizacionales y culturales”
