Recogida de Requisitos de Proyecto

Hace poco, en un proceso de venta complejo, nos encontramos con un cliente pidiéndonos ser exhaustivos con la trazabilidad en el diseño de la solución. Teniendo un concepto claro de la trazabilidad en nuestro ámbito, respondimos al RFP aportando pruebas sobre cómo nuestro software permite mantener una trazabilidad de los documentos. Para nuestra sorpresa, el posible cliente no quedó satisfecho con lo que le decíamos. Insistía con la trazabilidad y se hizo patente que cuando hablábamos de trazabilidad, el cliente hablaba de una cosa y nosotros de otra. No cuestionamos nuestro concepto de trazabilidad porque lo conocemos bien, pero lo que debimos preguntarnos antes fue: ¿estamos hablando de la misma cosa? El cliente no tiene por qué conocer la jerga técnica de nuestro negocio. No podemos esperar que entienda los conceptos con los que nosotros trabajamos todos los días, porque a nosotros también nos cuesta entender los conceptos de su negocio. No hablamos el mismo idioma, nos guste o no, y nuestro reto está en sacar el mensaje claro más allá de las dificultades del idioma. La recomendación aquí es aparcar los tecnicismos y hablar en un lenguaje plano que las dos partes entendamos perfectamente.

Entender la importancia que ha de tener cada hito desde el punto de vista de negocio tanto como desde el punto de vista técnico.

Cada hito del proyecto tiene un impacto y una importancia diferente en relación con el negocio del cliente. Pero esto va más allá del aspecto técnico. La importancia de la que hablo no se refiere a que algunas tareas tienen otras dependientes y de allí su importancia. No. Estoy hablando de la importancia que la tarea tiene para los procesos del cliente. Con base en esa importancia deberemos ajustar la planificación más allá de un orden puramente limitado por el componente técnico. Si para el cliente hay una funcionalidad que es crítica para uno de sus procesos más importantes, deberemos priorizarla frente a otras que no lo son tanto y que, tal vez, nos resultan más cómodas y fáciles de realizar primero. Esto hace parte de entender las necesidades del cliente, su negocio y lo que espera de nosotros como proveedor tecnológico. La clave está pues en identificar cuáles de los hitos tienen mayor importancia para el negocio del cliente.
 
La importancia de los procesos de consultoría y su relación con la tecnología.

Muchas veces nos presentamos a licitaciones o concursos privados para ofertar soluciones tecnológicas complejas. Cuando nos presentamos, conocemos sólo la punta del iceberg de lo que el cliente realmente necesita. Nuestras estimaciones y propuestas están supeditadas a qué tan exhaustivo fue el cliente en la descripción de su situación actual, necesidades y expectativas en un RFP. El problema es que muchas veces el cliente en sí mismo desconoce buena parte de la información. Por ejemplo, no sabe cuántos usuarios van a interactuar finalmente con el sistema o cuál es la mejor manera de resolver un cuello de botella que tienen en un proceso. Aquí es importante entender que los clientes no nos contratan como vendedores de software, sino con expertos en el software que vendemos. Esperan que tengamos experiencia con empresas como la suya y que nos podamos anticipar a darles las respuestas con las que ellos ahora mismo no cuentan. Para nosotros, llegados al punto de responder a un RFP es una situación dura en la que nos toca todo el tiempo suponer, en base a nuestra experiencia qué solución podría funcionar para el cliente. Sin embargo, entre más complejo el problema o proceso, menos nos podemos permitir tener vacíos de información. Es aquí donde los procesos de consultoría cobran un valor fundamental. La consultoría nos ayuda a entender lo que el cliente necesita, a averiguar detalles que el cliente desconoce, detectar riesgos, y contar con un escenario detallado sobre el que los clientes y nosotros como proveedores estemos de acuerdo antes de enfrentarnos a la fase de desarrollo y customizaciones.