Talleres ínterdepartamentales en el desarrollo de aplicaciones de software

Introducción

Este artículo trata sobre la realización de talleres donde participan personas de diferentes departamentos de una misma empresa. El objetivo de estos talleres es participar en la creación y evaluación de aplicaciones de software para uso interno, por ejemplo gestores de contenidos para intranets corporativas, aplicaciones de logística, sistemas de facturación, aplicaciones de ERP en general.

Equipos transversales

Entendemos como un equipo transversal a un grupo que se reúne en momentos concretos de un proyecto de desarrollo de software y está capacitado para tomar decisiones que afecten al desarrollo del mismo.

Tomemos como ejemplo el desarrollo de un software para PDA que será utilizado por los representantes comerciales de una marca de patatas fritas. Los representantes utilizarán este software para la venta de productos a tiendas minoristas.

El grupo transversal para el desarrollo de este software podría estar formado por los siguientes departamentos:

• Logistica: necesita que la aplicación de PDA se comunique con el back-end de la empresa y que sea posible hacer un tracking de pedidos.
• RRHH: se ocupará de la formación de los representantes.
• Sistemas informáticos: corre con los gastos de desarrollo y mantenimiento de la aplicación y se ocupa de la integración de la misma en sistemas existentes.
• Contabilidad: la aplicación genera informes que se utilizan para posterior facturación.
• Marketing: posibilidad de por ejemplo promocionar un determinado producto u ofrecer descuentos especiales
• Usuarios finales

Los usuarios finales pueden provenir de departamentos que no estén directamente involucrados en el desarrollo del software. En cualquier caso es fundamental contar con estos usuarios finales, vale la pena recordar que los usuarios finales no son jefes de área sino usuarios normales.

Equipos transversales en desarrollo de software: DSDM

Los talleres se utilizan en diferentes metodologías de diseño y desarrollo informático. Una de ellas es el DSDM (Dynamic Systems Development Method), un marco de desarrollo enfocado a llevar a cabo proyectos de acuerdo al planning establecido entregando productos de calidad. La realización de talleres durante el desarrollo del proyecto es uno de los aspectos esenciales del DSDM.

El objetivo del DSDM es desarrollar soluciones que logren alcanzar los objetivos de negocio en el tiempo establecido. Bien realizado, el DSDM satisface las necesidades de todos los participantes del proyecto: desde managers hasta usuarios finales.

Una premisa fundamental en este marco de desarrollo es que nada se desarrolla a la perfección la primera vez, pero que un 80% del sistema propuesto que sea útil y usable puede ser desarrollado en un 20% del tiempo que tomaría llevar a cabo una solución total perfecta.

Esto se logra manteniendo el foco del proyecto en las necesidades establecidas y no en las posibilidades percibidas. El criterio fundamental para decidir la aceptación de los entregables es la adecuación de los mismos a los objetivos de negocio.

Selección de principios fundamentales de DSDM:

• La participación activa del usuario es imperativa
• El equipo de trabajo debe tener la capacidad de tomar decisiones
• Los tests están integrados en el ciclo de vida
• La colaboración y cooperación entre todas las partes es esencial

Talleres en DSDM

La utilización de talleres es una técnica esencial utilizada para tomar decisiones de forma rápida, efectiva y eficiente. Los talleres son una herramienta útil para promover cambio y rápida aceptación en una organización.

Existen aspectos de DSDM que pueden oponerse (al menos de manera aparente) a ciertos principios de la usabilidad (por ejemplo la falta de investigación de campo con usuarios reales o los requerimientos que deben formularse de modo muy general) y por ello pueden resultar controversiales.

Un tratamiento detallado de DSDM y de estos aspectos controversiales excede el tema de este artículo. Para mayores detalles visiten: http://www.dsdm.org/tour/

Talleres en la definición de objetivos y requerimientos globales

Enfoque común

Una manera corriente para la captura de requerimientos para el diseño y construcción de software es la siguiente: uno o más analistas de sistema realizan una serie de entrevistas y vuelcan los resultados de estas entrevistas en un informe, el cual se distribuye para ser comentado. Luego de varias rondas de comentarios se definen los requerimientos finales para el software a desarrollar.

Vale la pena comentar que existen otros enfoques, el diseño-centrado en el usuario por ejemplo, que tiene otros métodos de recolección de requerimientos, sin embargo el método más corriente sigue siendo la recolección de requerimientos llevada a cabo por un analista o arquitecto de sistema por medio de entrevistas.

Este enfoque presenta varios problemas:

• es posible que no todas las partes implicadas se vean involucradas desde el inicio del proyecto,
• a menudo, las diferentes partes tendrán visiones encontradas sobre los requerimientos, lo cual resulta en discusiones asincrónicas, que pueden costar mucho tiempo,
• puede suceder que se recopilen requerimientos contradictorios, estos requerimientos contradictorios pueden descubrirse recién en las fases finales del proyecto, lo cual es un gran riesgo. O pueden no descubrirse hasta finalizada la construcción.
• este enfoque conlleva una visión de â??nosotros y ellosâ?, lo cual puede ser muy perjudicial para las partes involucradas y para el producto final. La consecuencia de este enfoque son acusaciones y querellas internas.

Enfoque transversal

Una solución para resolver estos problemas directamente es la realización un taller donde participe un equipo transversal. Por medio de este taller

• se asegura que todas las partes implicadas estén presentes desde el inicio y que puedan llevarse a cabo discusiones sincrónicas, más ricas y más eficientes.
• se posibilita una sensación de propiedad compartida sobre el proyecto, tanto entre diferentes departamentos entre si como con los desarrolladores (internos o externos).
• se reduce el tiempo necesario para definir o revisar requerimientos.

En este taller deberá definirse:

• El mission statement de la aplicación
• Los objetivos de la aplicación, desde los cuales se desprenderán las funcionalidades.
• Los criterios de evaluación para saber si se han alcanzado los objetivos
• Las prioridades para los objetivos y las funcionalidades. Estas prioridades, obtenidas de manera consensuada, se pueden utilizar posteriormente para resolver potenciales conflictos o problemas que puedan surgir.

Los talleres pueden reemplazar o complementar el uso de otro tipo de investigaciones (por ejemplo entrevistas o investigación etnográfica) para recolección de requerimientos.

Definición de prioridades

Para la definición de prioridades existen varios métodos. El enfoque más común en DSDM llamado MoSCoW (Must have, Should have, Could have and Want to have) es problemático ya que cada persona tiende a pensar que su prioridad es muy importante. Por eso puede resultar más conveniente utilizar prioridades numéricas expresadas a través de votos.

Se llevan a cabo dos rondas de votos, las cuales generan un resultado que determina prioridades para cada objetivo o funcionalidad.
Los votos pueden ser:

• Primera ronda: desde el punto de vista personal
• Segunda ronda: desde el punto de vista de la empresa

Es importante realizar dos rondas de votos a partir de puntos de vista diferentes (cliente/usuario podría ser otro enfoque para los votos). Es posible que una persona determinada tenga privilegios y cada voto suyo tenga más valor que el de los demás (doble por ejemplo).

Talleres en la evaluación de entregables

En estos talleres puede evaluarse todo tipo de entregables: requerimientos, propuestas conceptuales, diseños, prototipos, etc en diferentes momentos del proyecto. Al estar basados en entregables, estas reuniones pueden claramente verse como momentos clave en el proyecto.

A partir de escenarios de uso se pueden llevar a cabo talleres de evaluación donde todas las partes implicadas participan de manera sincrónica. De esta manera se aportan diferentes perspectivas (las del negocio, las de los desarrolladores y las del usuario) al revisar entregables.

El equipo interdepartamental generará una lista consensuada de comentarios, esta lista incluirá prioridades para solucionar los problemas encontrados. La determinación de prioridades estará basada en los objetivos planteados anteriormente y se lleva a cabo de la manera anteriormente expuesta.

Este tipo de reuniones:

• focaliza las críticas y los pedidos de solución,
• reduce el choque que podrían experimentar las partes al encontrarse con el producto terminado, ya que todas las partes participan activamente del desarrollo del mismo,
• hace que las discusiones sean más objetivas ya que se utilizan los objetivos de negocio planteados anteriormente y no los gustos personales,
• evita que se realicen pedidos de funcionalidades que no estén basadas en objetivos de negocio,
• evita retrasos debidos a falta de respuesta y/o pedidos tardíos.

Conclusión

El uso de grupos transversales puede ofrecer beneficios significativos en un proyecto, tanto directos como indirectos. También existen algunos aspectos negativos potenciales.

Beneficios

• Toma rápida de decisiones: tanto en la fase de requerimientos como durante la revisión de entregables.
• Alta aceptación de los resultados finales debido a la constante participación de los diferentes grupos.
• Promoción del espíritu de grupo, cooperación y entendimiento.
• Mayor entendimiento de los usuarios finales: gracias a la participación activa de los usuarios durante el diseño se limitan el espacio para especulación acerca del comportamiento de los mismos.
• Definición objetiva de prioridades consensuadas: debido al sistema de votos puede llegarse de manera consensuada a definir prioridades aceptables para todas las partes implicadas.

Riesgos

• En cierto tipo de organizaciones el espíritu cooperativo puede no llegar a desarrollarse.
• En ciertas organizaciones muy jerárquicas este modo abierto de decisión puede no ser aceptado.
• Los usuarios finales pueden no ser representativos.