La construcción de un sistema de información, de un desarrollo de software, pasa por una fase inicial de especificación de requisitos. No importa demasiado la metodología (aunque las Agile introducen importantes matices) esta fase siempre se produce.
Esto es así, al menos en empresas grandes con cierto tamaño y con un departamento de TI capaz de de construir sus propias aplicaciones o bien en el caso de integradores trabajando para otras empresas.
La especificación de requisitos recoge las necesidades que las unidades 'usuarias' precisan del nuevo sistema. Y esa especificación constituye una guía para el equipo de análisis y construcción,una guía de lo que tiene que hacer y una guía para la estimación de esfuerzos y tiempos.
De esta forma, la especificación se constituye en una suerte de contrato entre el área usuaria, que actúa de cliente (interno o externo), y el equipo de TI (propio o integrador).
Dicho así, la cosa parece correcta, ajustada a metodología, ajustada a derecho, controlada, documentada, planificable.
¿Si?
No
Realmente no.
No sé si se trata de una característica (una limitación) de la cognición humana, no sé si es incomprensión de lenguajes lejanos como son los del negocio frente a TI, no sé si es falta de rigor, interés, tiempo o qué, pero la experiencia enseña, al menos la mía lo hace, que una unidad de negocio no es capaz de expresar completamente lo que necesita de un sistema de información por adelantado, que no es capaz de concretar todas y cada una de sus necesidades de forma totalmente coherente y completa y que no siempre es capaz de imaginar cómo será el sistema que está demandando una vez construido.
 |
| El error: simplemente tomar nota |
Por eso, cuando la unidad peticionaria ve por primera vez el sistema, o un prototipo de pantallas, o cuando en el transcurso del trabajo el equipo de TI le hace entender mejor lo que están haciendo, se producen decepciones, cambios de opinión, sustos, nuevas peticiones o enmiendas a las ya realizadas. Y eso hace daño al propio área peticionaria como al equipo de TI, un daño que se traduce en sobrecostes y retrasos... y en un coste emocional.
Por eso, los ciclo de ingeniería software son cada de vez de naturaleza más iterativa, y por eso el auge de las metodologías agile que llevan casi al límite esa iteración e integración continua.
Pero, metodología aparte, esa realidad creo que exige de los equipos de TI, muy especialmente de los business analysts, o de los analistas funcionales, una actitud mucho más honrada y proactiva, mucho más servicial, mucho más cercana a su cliente interno o externo.
He visto, por desgracia, utilizar los requisitos como salvoconducto. Argumentar que el área usuaria pidió eso como consta en el documento de requisitos... y hacer pagar a ese área usuaria por su error. Pagar en el sentido económico y en la vergüenza de reconocer un error.
Desde un punto de vista estrictamente formal, puede que el equipo TI tenga razón...pero es un gravísimo error como unidad.
Hace ya mucho tiempo escuché la frase (no recuerdo donde) que decía:
No vale la pena tener razón contra tu cliente
Lo mismo aplica a este caso. No le vale de nada al integrador o equipo de TI tener razón, en lo formal, frente a su cliente interno o externo, frente a las áreas usuarias porque, como decía el gran James Rumbaugh.
If the system does exactly what the customer asked for, but that does not meet the customer real needs, you will be blamed anyway.
A corto plazo, paga el cliente con euros, tiempo, impacto en su actividad y vergüenza.
Pero a medio plazo paga la organización de TI o el integrador en forma de desconfianza, desprestigio y búsqueda de alternativas que la esquiven.
 |
| El modelo: la venta consultiva |
Creo que, por honestidad, pero también por su propia supervivencia, los equipos de TI deben dejar de usar los requisitos como un salvoconducto frente a sus clientes. Deben aprender a entender a éstos sus clientes, y guiarles hacia la consecución de unos requisitos que realmente recojan las necesidades del negocio.
Y creo que el modelo podría ser el de la venta consultiva. Al igual que cuando se intenta vender productos complejos a grandes cuentas, el vendedor se convierte realmente en un consejero, un orientador de su cliente, de la misma forma los analistas deben ayudar a su cliente, el área usuaria, a elegir los requisitos que realmente necesitan. Todos los requisitos que necesitan y sólo los requisitos que necesitan y haciéndoles entender perfectamente lo que están pidiendo.
Así, hacen un favor a sus clientes... y, de paso, se hacen un favor a sí mismos.
No hay comentarios:
Publicar un comentario