Saber distinguir las obligaciones y limitaciones de cada uno de los roles del equipo ayuda a que el trabajo lo realicen las personas mejor capacitadas para ello, lo que se traduce en mayor calidad. Roles distintos no necesariamente significa personas distintas, sobre todo en equipos muy reducidos. Una persona puede adoptar más de un rol, puede ir adoptando distintos roles con el paso del tiempo, o rotar de rol a lo largo del día. Hagamos un repaso a los papeles más comunes en un proyecto software.
- Dueño del producto
- Cliente
- Analista de negocio
- Desarrolladores
- Arquitectos
- Administradores de Sistemas
Dueño del producto: Su misión es pedir lo que necesita (no el cómo, sino el qué) y aceptar o pedir correcciones sobre lo que se le entrega.
Cliente: Es el dueño del producto y el usuario final.
Analista de negocio: También es el dueño del producto porque trabaja codo a codo con el cliente y traduce los requisitos en tests de aceptación para que los desarrolladores los entiendan, es decir, les explica qué hay que hacer y resuelve sus dudas.
Desarrolladores: Toman la información del analista de negocio y deciden cómo lo van a resolver además de implementar la solución. Aparte de escribir código, los desarrolladores deben tener conocimientos avanzados sobre usabilidad y diseño de interfaces de usuario, aunque es conveniente contar con una persona experimentada para asistir en casos particulares. Lo mismo para la accesibilidad.
Administradores de sistemas: Se encargan de velar por los servidores y servicios que necesitan los desarrolladores.
En el mundo anglosajón se habla mucho del arquitecto del software. El arquitecto es la persona capaz de tomar decisiones de diseño pero además se le supone la capacidad de poder hablar directamente con el cliente y entender los requisitos de negocio. En lugar de un rol,es una persona que adopta varios roles. En el agilismo todos los desarrolladores son arquitectos en el sentido de que se les permite tomar decisiones de arquitectura conforme se va escribiendo o refactorizando código. Hay que resaltar que se hacen revisiones de código entre compañeros. Además, ante decisiones complejas se pide opinión a desarrolladores más experimentados. Recordemos que existe propiedad colectiva del código y fluidez de conocimiento dentro del equipo.
Parece que no son tan complicados los roles... sin embargo, los confundimos a menudo. En nuestra industria del software hemos llegado al extremo de el que el cliente nos dice a nosotros, los ingenieros, cómo tenemos que hacer las cosas. Nos dice que quiere una pantalla con tal botón y tales menús, que las tablas de la base de datos tienen tales columnas, que la base de datos tiene que ser Oracle... ¡y nosotros lo aceptamos!.
Sabemos que la escasez de profesionalidad ha tenido mucho que ver con esto y, el hecho de no tener claro cuáles son los roles de cada uno, hace que no seamos capaces de ponernos en nuestro sitio. Quien dice el cliente, dice el dueño del producto o, llegado el caso, el analista. De hecho, a menudo nos encontramos con analistas de negocio que, cuando hacen el análisis, entregan al equipo de desarrollo interfaces de usuario (pantallas dibujadas con Photoshop o con cualquier otro diseñador) además de las tablas que creen que lleva la base de datos y sus consultas.
¿No habíamos quedado en que el dueño del producto pide el qué y no dice el cómo?. Si la persona que tiene el rol de analista también tiene el rol de desarrollador, entonces es comprensible que diseñe una interfaz de usuario pero entonces no debería pintarla con un programa de diseño gráfico y endiñársela a otro, sino trabajar en ella. Las pantallas no se diseñan al comienzo sino al final, cuando los requisitos de negocio ya se cumplen. Los requisitos son frases cortas en lenguaje natural que ejecuta una máquina automáticamente, ya que tienen forma de test, con lo que se sabe cuándo se han implementado.
Si las pantallas se diseñan primero, se contamina la lógica de negocio con la interpretación que el diseñador pueda hacer de los requisitos y corremos el riesgo de escribir un código sujeto a la UI en lugar de a los requisitos, lo cual lo hace difícil de modificar ante cambios futuros en el negocio. El dueño del producto tampoco debe diseñar las tablas de la base de datos a no ser que también adopte el rol de desarrollador pero, incluso así, las tablas son de los últimos elementos que aparecen en el proceso de implementación del requisito, tal como ocurre con la interfaz gráfica. Es decir, vamos desde el test de aceptación a tests de desarrollo que acabarán en la capa de datos que pide persistencia.
Pensamos en requisitos, implementamos objetos, luego bajamos a tablas en una base de datos relacional y finalmente le ponemos una carcasa a la aplicación que se llama interfaz gráfica de usuario. No al revés.
Si cada cual no se limita a ejercer su rol o roles, estaremos restringiendo a aquellos que saben hacer su trabajo, limitándoles de modo que no les dejamos hacer lo mejor que saben.