Los roles de contraparte

Para tener éxito en una nueva aplicación siempre se requiere
 la motivación y la participación de los usuarios

A veces leemos algunos textos donde se habla del desarrollo de aplicaciones, de las tareas y las personas como si el trabajo de desarrollo fuera un trabajo exclusivamente técnico y fuese posible obtener buenos resultados sin una clara participación de los usuarios en ello. Pero las cosas no son así y sin una participación de los usuarios no se llega a la meta de tener aplicaciones bien hechas, que cumplan con todos los requisitos de diseño, que dejen a todos satisfechos y que entren efectivamente en producción, mejorando el hacer cotidiano en algún lugar. Continuando pues la conversación sobre roles hablaremos hoy de los de contraparte.

A los roles típicos en los equipos de desarrollo que definimos la semana pasada vamos pues a sumar tres roles muy diferentes, del lado de los usuarios. Ellos complementan el trabajo de los desarrolladores: la Contraparte institucional, la Contraparte representante de la unidad informática y la Contraparte representante de los usuarios.

Contraparte institucional
Es la persona que hace el trabajo de representar formalmente a la institución u unidad que se convertirá en usuario de la aplicación que se desarrolla. Es responsable de fungir como contraparte del proyecto en términos contractuales, si el caso involucra una contratación externa. Si el desarrollo es intra institucional es responsable por el lado de la unidad que recibirá el desarrollo, del seguimiento de los acuerdos y de los compromisos contraídos durante todo el ciclo de vida de la aplicación.

Contraparte representante de la unidad informática
Es la persona responsable de validar el cumplimiento de los requerimientos provenientes de la unidad de informática de la institución, entendiendo cuál es el sentido de esto ya que el objetivo final debe ser la satisfacción de las necesidades de los usuarios y no los intereses técnicos de los informáticos.

Contraparte representante de los usuarios
Es la persona responsable de colaborar en la extracción del conocimiento tácito de los usuarios finales de la aplicación. Valida en nombre de ellos el cumplimiento de los requisitos y mantiene permanentemente una comunicación estrecha que proporciona feedbacks de usabilidad a los desarrolladores.

Típicamente se requieren los tres roles en una relación de colaboración muy cercana con quienes trabajan en el diseño y construcción de la aplicación. Un proyecto no se puede realizar sin la participación entusiasta y decidida de los usuarios. No se trata simplemente de encargar, esperar y recibir. El trabajo debe ser conjunto y cooperativo. Cuando no es así, los resultados no son buenos.

Un aspecto muy importante a tomar en cuenta es que la participación de los usuarios genera identificación y motivación y eso se requiere para que haya el interés en los cambios de prácticas que se introducen. Toda aplicación nueva involucra maneras distintas de hacer las tareas cotidianas. Muchas veces se habla resistencia al cambio, pero en realidad, el problema se origina en que desde que se inició el desarrollo no se trabajó con los usuarios y por ello éstos no sienten suyo los resultados de un proyecto que creció sin ellos.

Otro problema típico que se presenta es el que ocurre cuando los usuarios, en cualquiera de los roles definidos arriba, no se involucran como colaboradores sino como jueces. En realidad, las cosas sólo salen bien si hay cooperación en lograr la nueva aplicación. Es muy difícil imponer desde arriba un cambio de prácticas. Es mucho más sencillo y productivo el trabajo colaborativo.