La tecnología es cosa de letras

Mucha gente piensa que en el mundo de la tecnología, de Internet y de estas cosas que suenan a chino para la mayoría de los mortales, las cosas suelen ser bastante matemáticas, dos más dos son siempre dos. Lamentablemente esto, aunque sea cierto a un nivel teórico, cuando se lleva a la práctica es bastante complicado de implementar.

Quizás penséis que el bueno de Johnnie Walker está campando a sus anchas por mis venas, pero la verdad es que no. Este pensamiento me viene después de estar cuatro días en cama con un constipado de tres pares de narices. El ejemplo más rápido que os puedo presentar para que veáis lo importante que son las carreras de letras es el siguiente: Cuando tu dices que el proyecto estará para mañana, a que te refieres, ¿al día siguiente a las 8:00 o más bien para el día siguiente a las 20:00?, y es más, cuando tu cliente te pide que esté para mañana, a que hora crees que espera que esté, ¿a las 8:00 o a las 20:00?.

Parece una tontería, pero es la base que genera mucho de los problemas que hay hoy en el mundo de la tecnología, falta de comunicación. No sabemos trasladar los conceptos que tenemos que aplicar a nivel técnico a un idioma para profanos, y al revés, los profanos (lógica y afortunadamente para los proveedores), no saben traducir las peticiones.

Este tipo de tonterías me han llevado a presenciar situaciones de lo más absurdo a lo largo de mi carrera profesional. Las más divertidas, pues aquel que pidió una web que fuera dinámica y después de pegarnos horas con la usabilidad, el diseño y la BD resulta que quería una web con flash y gifs animados que se movieran. O otro más emocionante, que nos pedía una web y cuando le pedimos que estructura conceptual quería darle nos comentó que hasta no tuvieran un diseño gráfico no sabrían decirnos.

¿De quien es el problema?, un psicólogo diría que los dos, el mercado diría que el problema es del proveedor. Si no eres capaz de traducir tus necesidades y como quedará el producto, y si encima no eres capaz de hacer el proceso inverso, uno se va a encontrar con muchos problemas cuando empiece a desarrollar el producto.

Para evitar estas cosas, se sugiere un contrato muy documentado que fije claramente las peticiones y las consecuencias de las peticiones que se hacen, pero claro, esto yo lo he visto en contadas ocasiones y con empresas que ya cuentan con una larga tradición tecnológica. Lo normal es que se haga una contrato en word que ponga cuatro cosas sobre el proyecto, y sobre las especificaciones es algo que queda entre en el aire y entra en vigor el puesto de comercial, preventa, o como se quiera llamar. Esta pobre persona es la que intenta lidiar las necesidades no explicitadas y luego demandadas con que el proyecto al final sea rentable para el proveedor.

Y si esto ocurre entre clientes y proveedores, el espíritu de confianza y por lo tanto de desastre, se incrementa exponencialmente cuando son proyectos para la propia empresa. Necesidades no explicitadas, soluciones no consensuadas, documentos no formalizados, manuales inexistentes, en fin, esas pequeñas cosa que contribuyen a que un proyecto acabe irremediablemente en fracaso y en algún que otro ataque de nervios del equipo de desarrollo o del equipo que espera el desarrollo.

Y por último, que estos desengaños de comunicación también pasa entre gente técnica. Tu pides un servicio y asumes que será prestado de determinada manera, y el proveedor piensa que será prestado de otra distinta, y a veces eso lleva sustos y disgustos.¿Cual es la solución?, básicamente hablar. Hablar y creerse lo que te dicen. Si un cliente te dice que quiere algo, preguntarle sobre que quiere, preguntarle como lo quiere, preguntarle y preguntarle y volverle a preguntar. Y el cliente, por lógica, se ha de fiar que todo este calvario de preguntas es por un fin y para evitar sustos, disgustos, cambios de proyecto, cambio de funcionalidades. En resumen, para evitar sobrecostes en estas implementaciones tecnológicas.