Roles en el servicio de digitalización

La captura digital puede requerir equipos especiales, pero la digitalización
 de volumen de miles, o centenares de miles de páginas,
es un proceso complejo que requiere el concurso de diferentes roles
cuyo trabajo se suma para obtener un resultado de calidad

Muchas nuevas soluciones de gestión digital de información implican resolver la transición al espacio digital de la información que antes se manejaba en papel. Esto puede significar la captura digital de miles o centenares de miles de páginas. Son tareas adicionales, casi completamente paralelas al desarrollo y a la implementación de la nueva solución y un trabajo especializado de un tipo diferente y por ello requieren de nuevos roles, que definiremos en este post para complementar las conversaciones recientes sobre los roles en los equipos de desarrollo y los roles de contraparte.

Cuando el proyecto en desarrollo incluye la digitalización de un conjunto significativo de registros se requiere una actividad de captura digital estructurada, esto implica personas que digitalicen, que cataloguen, que transcriban, que clasifiquen, que aseguren la calidad de la digitalización y de la transcripción y que coordinen el servicio. Particularmente importante para el éxito de un proyecto de digitalización de volumen es la planificación del proceso y el diseño de las normas de digitalización.

Los roles típicos son, así pues, los siguientes:

Coordinador de Servicios de Digitalización/ Transcripción
Es la persona que funge como responsable en forma integral de la ejecución del servicio de Digitalización/ Transcripción. Es un rol comprometido con la ejecución de la actividad en todos los aspectos involucrados: tecnología, procesos y gente.

Analista de procesos de digitalización
Es la persona que debe analizar las necesidades particulares del proceso de digitalización, definir el proceso específico requerido y escribir las normas de digitalización.

Digitalizador
Es la persona responsable de la captura digital, del convertir los documentos originales en el formato digital convenido en las normas de digitalización.

Catalogador/Transcriptor
Es la persona responsable de registrar los campos de información acordados, usando las herramientas definidas en el proyecto: Una aplicación desarrollada, una hoja de trabajo genérica, una Plataforma o Manejador de Información y/o Documentos, etc.

Clasificador
Es la persona responsable de la valoración y clasificación de registros que son sometidos al proceso de digitalización. Debe tener criterios claros para que el resultado de su actividad sea adecuado.

Aseguramiento de la calidad de la digitalización/ catalogación/  transcripción
Es la persona responsable de asegurar los compromisos establecidos en el proyecto sobre la calidad de la información digitalizada, catalogada y transcrita.

Aseguramiento de la calidad de la clasificación/indización
Es la persona responsable de asegurar los compromisos establecidos en el proyecto sobre la calidad de la clasificación/indización de la información procesada.

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.

Los roles en los equipos de desarrollo

Un rol es una definición de una papel que debe desempeñarse. Hay roles
que típicamente son necesarios cuando se desarrolla una aplicación de
teleinformación

La semana pasada entramos en el tema de los roles y mencionamos como es importante entender los que son necesarios cuando se desarrolla una aplicación de teleinformación y se quieren hacer las cosas bien con el objeto de lograr un resultado que sea una solución de excelente calidad, que cumpla con todos los requisitos planteados. Continuando esa conversación presentamos en este post alguna definiciones sucintas de un poco más de una docena de roles típicos en los equipos de desarrollo. Dejamos para otra oportunidad los roles de contraparte.

Líder de Proyecto
Responsable de la gestión del proyecto, de los acuerdos formales e informales, del cumplimiento de fechas, de la comunicación entre los equipos involucrados y la actualización del sitio Web del proyecto durante todo el ciclo de vida de la aplicación.

Gerente de cuenta
Responsable de la relación institucional entre las contrapartes durante la vigencia de los acuerdos que las vinculan.

Planificador del Proyecto
Responsable de la planificación del proyecto. En particular, de las estimaciones preliminares de recursos.

Revisor de la Planificación del Proyecto
Responsable de revisar la planificación del proyecto y su conformidad con la experiencia acumulada en las ejecuciones previas.

Especificador de requisitos
Responsable de recabar toda la información pertinente, organizarla, hacer la especificación detallada de los requisitos de la aplicación, determinar los casos de uso.

Revisor de las definiciones de requisitos
Responsable de revisar la consistencia formal y semántica de las definiciones detalladas de los requisitos y casos de uso.

Analista de procesos de información
Responsable de analizar la información recabada y los requisitos para, a partir de allí, conceptualizar el problema de gestión de información que se quiere resolver.

Diseñador de la base de información
Responsable de traducir la solución planteada al problema de gestión de información en los términos del modelo preliminar de la base de información.

Revisor del diseño de la base de información
Responsable de revisar la consistencia formal y semántica del modelo preliminar de la base de información.

Desarrollador de la Aplicación
Responsable de traducir el modelo preliminar de la base de información en un prototipo ejecutable.

Coordinador del desarrollo
Responsable del equipo de personas a cargo de la implementación del prototipo y de asegurar que se cumple con los objetivos del diseño y se satisfacen todos los requisitos planteados.

Revisor del desarrollo
Responsable de revisar la implementación del prototipo y el aseguraramiento de que se satisfacen los procedimientos de verificación establecidos.

Diseñador de la experiencia del usuario
Responsable de conceptualizar la experiencia del usuario con el sistema: usabilidad, navegación y estética.

Revisor de la experiencia del usuario
Responsable de revisar la experiencia del usuario con la aplicación y contrastarla con las buenas prácticas en el área.

Documentador del sistema
Responsable de escribir la documentación específica que será entregada con la aplicación.

Revisor de la Documentación del Sistema
Responsable de revisar la documentación específica que será entregada con la aplicación.

Asegurador de la calidad
Responsable de garantizar que la calidad de proyecto está alineada y se gestiona de acuerdo con las buenas prácticas y los procesos organizacionales de aseguramiento general de la calidad de la organización que desarrolla y que, de acuerdo con ello, cada proyecto contribuye al mejoramiento continuo de los desarrollos emprendidos.

Roles

Los proyectos los realizan personas que se articulan
con distintos roles. Todos son necesarios e importantes.

Una de las cosas que es conveniente tener claro cuando se participa de equipos de desarrollo de soluciones con Arquitectura de información son los roles, ya que hay un conjunto de ellos que deben estar siempre presentes cuando se quieren hacer las cosas bien. Cuando no están explícitamente definidos estos roles suele haber problemas. Algunos responsables y participantes de proyectos confunden roles con personas. No es lo mismo. Una persona puede ejecutar varios roles. Lo que hay que estar conscientes es que algunos de ellos son incompatibles con otros y en esos casos hay que tomar en cuenta que una misma persona no puede tener dos de esos roles incompatibles.

En lo que sigue listamos algunos de los roles que típicamente se hacen presente en el desarrollo de aplicaciones de teleinformación.  Estos roles tiene asociados responsabilidades y por tanto tener un rol en un proyecto es tener un compromiso

También hay que observar que para poder cumplir cabalmente con las actividades implicadas en un rol se requiere un cierto perfil de formación.

Existen ciertas tareas que siempre tienen que ser revisadas y hay que tomar en cuenta que, por definición, una persona no puede ser su propio revisor, porque en ese caso la revisión pierde parte de su funcionalidad. Una persona puede verificar su trabajo, pero no ser oficialmente su revisor dentro de un proyecto.

Roles típicos de proyectos de desarrollo de soluciones (enumerados sin que esto implique un carácter taxativo) son los siguientes:

1. Líder de proyecto
2. Gerente de cuenta
3. Planificador del proyecto
4. Revisor de la planificación del proyecto
5. Especificador de requisitos
6. Revisor de las definiciones de requisitos
7. Analista de procesos de información
8. Diseñador de la base de información
9. Revisor del diseño de la base de información
10. Desarrollador de la aplicación
11.  Coodinador del desarrollo
12. Revisor del desarrollo
13. Diseñador de la experiencia del usuario
14. Revisor de la experiencia del usuario
15. Documentador del sistema
16. Revisor de la documentación del sistema
17. Asegurador de la calidad

En un próximo post continuaremos con más detalles y aspectos vinculados con los roles.