En los años 50 los ordenadores eran unas máquinas enormes y muy caras que no estaban al alcance de todos los bolsillos. Por ello, las empresas que disponían de ordenadores los colocaban dentro de unas salas gigantescas a las cuales les ponían paredes de cristal. En esa sala sólo podían entrar los que manejaban los ordenadores, que por aquél entonces eran considerados unos bichos raros, y además eran expuestos como tales. Así, cuando venía una visita a la empresa, el jefe siempre lo llevaba a ver la glass house (en España se le conocía por el nombre de “pecera”) como una atracción más.
Gracias a los avances de la tecnología, los ordenadores se hicieron cada vez más pequeños y más comunes en las empresas, y el término glass house evolucionó. Pasó a hacer referencia al departamento de TI de una empresa, un departamento autónomo y aislado del mundo, donde los mortales usuarios finales no osarían jamás entrar ni a preguntar siquiera sobre las proezas que ahí se llevaban a cabo.
Pero entonces, no solo la tecnología, sino que los modelos de negocio de las compañías así como la forma de interactuar con el cliente evolucionaron, y los profesionales de TI tuvieron que salir de su burbuja y relacionarse con el usuario final.
Sin embargo, parece que algunos programadores llevan imbuido en sus genes los viejos comportamientos de los antiguos habitantes de las glass houses. Si quieres ser un buen profesional y crear una buena relación con tus clientes deberías desterrar tales prácticas de tu trabajo y seguir los siguientes consejos:
1- NO DEJES SIN ACOTAR LOS LÍMITES DEL PROYECTO
A no ser que los requisitos del proyecto estén perfectamente establecidos desde el inicio del mismo, todo proyecto es susceptible de ser mejorado mientras está en curso. El hecho de añadirle nuevas características con las que no se contaba al inicio, repercutirá en los plazos de entrega y en la calidad del mismo si estos no se modifican. El culpable de esto siempre será el desarrollador, pues es quien no ha cumplido los plazos, nadie se acordará de que el usuario (cliente) ha decidido a última hora añadir nuevas funcionalidades.
No lo permitas. Insiste en que cada tarea conlleva un tiempo ("aunque solo sea poner un botón", como te diría el cliente o incluso el comercial de tu empresa, que en principio debería estar de tu lado :O) y por lo tanto esto afectará a los plazos y si el cliente insiste en no modificarlos, afectará a la calidad del resultado.
2- NO SEAS INACCESIBLE
Este punto lo podríamos dividir en dos partes. Por un lado debes tomarte esta frase de forma literal. Es decir, no hay nada más frustrante para un cliente que el hecho de no poder ponerse en contacto contigo. Resulta inaceptable que tardes días o incluso horas en darle al cliente una respuesta, aunque sea un simple “En cuanto pueda te digo algo”.
La otra forma de ser inaccesible es utilizar palabras que el usuario no comprende. Esta parte quizás sea la que más te cueste, ya que estás todo el día leyendo y empleando dicho vocabulario. Pero si le dices a tu cliente, por ejemplo, “Para resolver esa situación usaré las capacidades de inserción de dependencias de ASP.NET Core 1.0 para refactorizar una solución EF7 con el fin de aprovechar un contenedor IoC que facilite la inserción de instancias de objeto”... Después de la palabra inserción ha dejado de escucharte. Así que, deja la jerga para cuando regreses a tu pecera, e intenta ponerte en el lugar del cliente. Háblale como si tuvieras delante a alguien que lleva 30 años durmiendo y acaba de despertarse en este siglo. Con esto lograrás tres cosas muy importantes:
- Que haya entendimiento entre ambas partes, lo cual favorecerá la ejecución del proyecto.
- Que el tiempo de reunión se reduzca al mínimo necesario.
- Que se establezca una buena relación entre el desarrollador y el usuario.
3- NO TOMES DECISIONES SIN PEDIRLE AL USUARIO SU OPINIÓN
Obviamente no nos referimos a cuestiones técnicas de funcionamiento interno, ni por supuesto a ninguna que tenga que ver con el back-end del proyecto. Pero, cuando estás creando una aplicación orientada al usuario final, éste sí debería involucrarse en la definición de la interfaz, las características y funciones que debe incluir la aplicación, la política de recolección de datos, etc. En estos casos, el programador nunca debería tomar decisiones de forma unilateral.
En algunas ocasiones te encontrarás con osados usuarios que te dan su opinión cuando NO se la has pedido. Cuando sea así, procura NO actuar con arrogancia ni con condescendencia. ¡Quién sabe!, puede que sea una gran idea que jamás se te habría metido pues estás tan metido en el día a día que te resulta imposible aislarte y verlo con otros ojos. Aunque la mayoría de las veces serán sugerencias sin sentido; en cuyo caso debes hacerle entender en cristiano por qué su propuesta no es viable.
Y cuando no puedas más, acuérdate de que siempre hay alguien que está peor que tú:
Sabemos que es difícil, que lo que más te gusta en este mundo es programar y que además no tienes mucho tiempo. Pero quizás no deberías olvidar, que desarrollar tus habilidades de comunicación es una parte de tu trabajo que a la larga te traerá importantes beneficios.
Nota: La imagen de la cabecera "Good Advice, Redlands Alleys 10-27-13ze" es de Don Graham bajo la licencia CC by 2.0
Fecha de publicación: