Gestión de expectativas (II de II)

En la primera parte de este post señalaba los errores más comunes en el desarrollo de un proyecto tecnológico (afortunadamente, todos juntos no se suelen dar). Para evitarlos no hay receta infalible, únicamente nuestra experiencia. Sólo a través de ella lograremos adquirir la capacidad suficiente para, unas veces plantear esos problemas al cliente de forma directa y sin ambages, y otras para anticiparnos a los mismos tomando medidas preventivas mucho antes de que se presenten.

conocimiento tecnológico

Esta suposición, basada quizá en un exceso de confianza del cliente respecto del conocimiento de la tecnología, suele de ser de los obstáculos más complicados de salvar, pues implica hacerle ver que no sabe tanto como cree y convencerle que su proveedor tecnológico está de su parte y no sólo pretende “sacarle el dinero”. En todo negocio hay “piratas”, pero partimos de una relación comercial profesional basada en la buena fe y en la que esos piratas, por referencia o por intuición deben haber caído en las primeras cribas. Actitudes sinceras por parte del proveedor acerca de la segura necesidad de su ayuda y asesoramiento, en la mayoría de los casos y tras el rechazo inicial, cimentan esa confianza que será imprescindible en todo el desarrollo del proyecto.

vosotros “sabéis de esto”

Al cliente que demuestre un conocimiento limitado sobre la tecnología y las posibilidades de la misma, hay que hacerle ver que va a necesitar una persona de su confianza con un perfil técnico tal que sea capaz de comprender los pormenores del proyecto. Si en su entorno (o compañía) no existiera ese perfil siempre se lo podemos debemos proporcionar nosotros, para lo cual nos plantearemos como una fase más de la preventa el ganarse su plena confianza mirando siempre por los intereses del cliente tanto como si se perteneciera a la propia compañía. La persona designada deberá hacer un análisis de los procesos que se lleven a cabo en la compañía, nomenclaturas y lenguaje utilizado para conocer esos detalles como si de un empleado más se tratara, integrándose en los mismos como uno más (esto, también, lleva aparejado un rechazo inicial por parte de los verdaderos empleados) En definitiva, el nivel de implicación de esa persona no sólo debe ser percibido por el cliente, debe ser real. Sin embargo, sólo en un último caso y para los clientes más inquietos, ilusionados y con ganas de implicarse, se puede plantear un plan de formación básica acelerada que le permita comprender por sí mismo las fases del proyecto y analizar las posibles soluciones a problemas de integración con su compañía que pudieran surgir durante el desarrollo.

es-pe-ci-fi-ca-ción

No nos asuste extendernos en la definición de los requisitos. Esta etapa es crucial y así debe transmitírsele al cliente. Tengamos cuantas reuniones que sean necesarias, intentemos conocer al detalle todas las operaciones o procedimientos que tengan que ver con el proyecto por escasa que creamos que sea su importancia. Con el primer enfoque o conjunto de los mismos no nos aventuremos en dar una fecha de inicio y menos aún, una de finalización. La van a pedir, desde luego, pero, como mucho, podremos dar una estimación de lo que ésta primera fase va a ocupar. Dividamos la recogida de datos del proyecto en los módulos funcionales de la empresa, no en los que podrá tener el desarrollo terminado, pues aunque éstos podrán coincidir lo más seguro es que no sea así. Demos plazos reales y establezcamos frecuentes hitos intermedios. De esta manera es mucho más sencillo atajar y resolver los posibles puntos de conflicto. Llegar con el tiempo justo a un objetivo demasiado ambicioso, provoca, cuando no lleguemos. precipitación lo que hace que se eleve el número de fallos en la implementación.
Measure twice, cut once
.(siempre me ha encantado esa frase)

recalcular vs. parchear

Los fallos en la definición y en los requerimientos recogidos en la mayoría de los casos son responsabilidad nuestra. No caigamos en el error (el cuarto) de utilizarlo como pretexto para justificar retrasos en los plazos. Así mismo, si en alguna ocasión hubo verdaderamente una modificación de los mismos durante el desarrollo del proyecto, es tarea nuestra haber modificado los plazos de forma escrupulosa y no tratar de encajarlo “como sea” en la planificación previa. Eso lo único que hace es restar valor y seriedad a nuestro trabajo. Todos estamos ya acostumbrados a que nuestro GPS recalcule ruta, estimación de duración del viaje y de la hora de llegada cuando nos pasamos la calle o la salida por la que teníamos que haber girado ¿porqué iba a ser diferente este caso?. Es tentador en este punto el parchear para llegar a las fechas, esta solución estaría bien si fuera el proyecto que nos hará multimillonarios y luego hiciéramos las maletas a un paradisíaco destino. Como no será el caso y queremos mantener una intachable reputación profesional y un nivel ético adecuado (recordemos que los piratas cayeron en la primera criba), la solución pasa por un replanteamiento rápido de la situación para llegar a la fecha con sólo las funcionalidades principales, pero sin penalizar el nivel de calidad. Planifiquemos para más adelante la finalización del resto, pero no sacrifiquemos la calidad con el pretexto de cumplir con los plazos. A la larga será contraproducente y costoso para ambas partes. Menos es más… a veces…

hasta luego, cocodrilo

Si hemos llegado a este punto es fundamental hacer una planificación también del periodo de mantenimiento, separando lo que es realmente mantenimiento y resolución de incidencias, de lo que serían procesos o funcionalidades que no se terminaron a tiempo. Asumiendo que el coste de la finalización, si no hicimos la replanificación por cambio en los requisitos, irá por nuestra cuenta. Tratemos de encajarlo en los posibles huecos que la resolución de incidencias nos deje. Tratemos de recuperar la confianza del cliente con un compromiso en los tiempos de respuesta y resolución de las incidencias y, sobre todo, en la finalización de las funcionalidades.

definición, planificación, implicación, confianza, responsabilidad

De los puntos anteriores podríamos sacar un par de conceptos clave por nuestra parte: definición y planificación; y otro par por parte del cliente: implicación y confianza.

Nuestro par, que pueden parecer obviedades, conviene decir que deben ser iterativos en cada fase o hito del proyecto. Debemos tener claro que en los entregables definidos pueden surgir nuevas cuestiones o elementos a desarrollar que, o se nos pasaron en la fase inicial o sencillamente, surgieron nuevas necesidades intrínsecas al proyecto y al funcionamiento de la compañía cliente. Esto es evitable en la medida de la eficiencia e implicación de la persona designada por la misma para hacer de interlocutor o de lo que conozcamos dicha compañía a través la persona designada por nosotros, que llevará aparejado un esfuerzo adicional el hecho de tener que adquirir ese conocimiento de forma acelerada. No debemos temer replantear el proyecto y/o modificar sus fases según éste vaya mutando. Tanto el comunicarlo en cuanto sea detectada la necesidad, como la manera de hacerlo hará crecer la confianza en nosotros del cliente, por transparencia y capacidad de reacción. Esto no quiere decir que la especificación inicial pueda ser tan somera que esté sujeta a cambios en cada hito/fase. Y sin darnos cuenta, vemos cómo los dos primeros conceptos se apoyan directamente en los segundos, que aún perteneciendo al cliente, es tarea nuestra alimentarlos y mantenerlos.

Debemos asumir los errores cometidos, pero ser firmes con la especificación. Esa exigencia dual, siempre funcionará en nuestro favor si somos meticulosos en la fase de definición. Sólo si no lo hemos sido será cuando, sin pegas ni quejas (=modificaciones de presupuesto) tendremos que hacernos cargo de los errores, seguramente, manteniendo el plazo. Algo fundamental en este caso es que la resolución de estos errores sea inocuo para el desarrollo del proyecto cara al cliente, pues lo contrario le generará inquietud y desconfianza.

La música elegida para hoy espero no sea premonitoria de los proyectos que afronteis/afronte en un futuro,

Happy ending, de Mika

0 comments ↓

There are no comments yet...Kick things off by filling out the form below.

Leave a Comment

Security Code: