En el Post pasado vimos la naturaleza funcional de un proyecto. Entendimos cual es la diferencia entre operaciones (ejecución constante, sin fecha final, flujo contante de recursos, repetir el mismo resultado) y proyectos (una única ejecución, con fecha final, presupuesto asignado, resultado único). Si no has leído el post anterior, aquí está la liga:

• Software desde 0 – Proyectos vs Operaciones

Ya que tenemos esto claro, ahora veremos los 2 principales elementos de un proyecto. Ahora si, enfocados completamente en desarrollo de software, esto son: Las personas que integran el proyecto, y los pasos para ejecutar un proyecto.

En este post veremos cómo se clasifican los participantes de un proyecto. Tanto desde el punto de vista de PMI (Project Management Institute, administración de proyectos tradicional), como desde el punto de vista Agile, principalmente siguiendo la metodología SCRUM.

En el siguiente post haremos una revisión rápida de la historia de los proyectos de Software, como empezaron, que metodologías se usaban, que pasos tenían dichas metodologías, y porque surgió el movimiento Agile para solucionar todos los problemas que estas causaban. Y veremos el funcionamiento básico del proceso Scrum.

Las Personas: Interesados, Participantes y Roles

La mejor manera para entender la capacidad de un proyecto es conocer a la gente que lo compone. Un proyecto es las personas que lo conforman. Y el resultado del proyecto es el fruto de la aplicación de su talento, al trabajo. En resume:

“Las personas son lo más importante en un proyecto.”

Interesados en PMI

En PMI se utiliza el termino de Interesados para definir a todas las personas o grupos que participan, o son afectados por la ejecución de un proyecto. Importante hacer la diferencia entre los 2 términos:

• Participante: Son las personas que participan de manera activa en un proyecto. Es decir, personas que tienen roles asignados, y que ejecutan las actividades.
• Afectado: Son las personas o grupos, que, aunque no participan de manera activa en el proyecto, les interesa, o les afectan la ejecución y resultados de un proyecto. No importando si la afectación es positiva, o negativa.

Aunque PMI no es nuestro principal enfoque, la práctica de documentar todos los interesados del proyecto ayuda mucho. Y es importante tener presente el termino de afectado, porque muchas veces en los proyectos hay gente que es afectada por el proyecto, pero nadie piensa en ellos. En proyectos de software es común que esto pase con el usuario final, y esto no debe de pasar.

Roles en SCRUM

Un Rol es una función que uno o muchos integrantes del proyecto toman para la ejecución de las diferentes tareas. Como cualquier función o proceso, es importante conocer los diferentes roles que se necesitan para hacer un proyecto de software. En un proyecto muy grande lo normal es que haya especialistas por cada rol, pero en proyectos pequeños las mismas personas pueden tomar múltiples roles. Lo importante es conocer y definir claramente cuáles son los roles, y quienes los van a ocupar, para facilitar la toma de decisiones y el flujo del proyecto.

En Scrum se utiliza una fábula del Cochino y la Gallina para separar los diferentes roles:

La Gallina le dice a su amigo el Cochino: “Porque no abrimos un restaurante.”

El Cochino le contesta: “¿Como lo llamaríamos?”

La Gallina responde: “Huevos con Tocino.”

El Cochino finaliza: “No gracias. Tu estarías involucrada, pero yo estaría comprometido.”

A continuación, explico la diferencia entre cada uno:

• Roles Gallina: Gente que esta involucrada en el proyecto, pero no está poniendo el pellejo por el resultado. Son las personas que pueden aportar opiniones al proyecto, pero no toman las decisiones finales.
• Roles Cochino: Son la gente que realmente está comprometida en el resultado del proyecto. Los que echan la carne al asador. Son ellos quien definirán como y en que tiempo se puede hacer lo comprometido. Son los principales participantes del proyecto, incluyendo al Dueño del Producto (Product Owner), Scrum Master, equipo de Desarrollo, etc.

Roles en un Proyecto de Software

Los roles más comunes en los proyectos de desarrollo son los siguientes:

PO – Dueño del Producto – Product Owner – Representante de los Usuarios

En Scrum es el principal representante de los usuarios. Es la persona que va a tomar las decisiones de; que si se hace, que no se hace, y que prioridad tiene cada funcionalidad.

Es obligatorio que solo exista uno por producto, que participe activamente en el proyecto, y que tenga la autoridad y conocimiento necesario para tomar las decisiones. Cualquiera de estos puntos que no se cumpla pone en serio riesgo el resultado del proyecto.

Usuarios

Este es el único rol gallina que vamos a detallar. Ya que los usuarios son quienes van a usar el software, tienen todo el derecho de participar y opinar en el proyecto, principalmente en aportar conocimiento necesario para el desarrollo. Pero ten cuidado. Los usuarios no deben de tener la autoridad final para la toma de decisiones. Esto solo debe de caer en las manos del Dueño del Producto.

Ten mucho cuidado con los usuarios. Muchas veces tienen ideas preconcebidas de cómo hacer las cosas, ya sea por otro sistema que usaron, o por ideas que tuvieron. Desafortunadamente hacer software no es la especialidad del usuario. En estos casos trata de entender que es lo que realmente se necesita, no como solucionarlo, pero es responsabilidad del equipo de desarrollo ofrecer la solución mas correcta, y del Dueño del Producto tomar la decisión final.

ScrumMaster – Administrador de Proyecto (Project Manager/PM)

La persona responsable de que las tareas se ejecuten en tiempo y forma, para cumplir con los objetivos del proyecto. Es principalmente un Rol de control. También es responsable de que todos los miembros del equipo sepan que tareas tienen que hacer y para qué fecha, y de comunicar o conseguir lo necesario para que tengan toda la información necesaria para ejecutar sus tareas.

En otras metodologías este rol se conoce como Administrador de Proyectos. La realidad es que no importa el nombre, las responsabilidades son las mismas. Aunque es un rol que se considera que no necesita conocimientos técnicos, en mi experiencia siempre es mejor que los tenga, y que tenga experiencia como desarrollador o analista.

Arquitectura

Es la persona encargada de tomar las decisiones de arquitectura del sistema. El diseño lógico y físico de la aplicación. Usualmente son decisiones que involucran una gran parte de hardware y de software, y cada vez mas común la utilización de diferentes servicios Cloud para completar una solución.

Normalmente es el miembro mas Sr. del equipo de desarrollo. Debe de tener la experiencia y el conocimiento suficiente para decidir que arquitecturas se van a utilizar. Estas decisiones se deben de basar en los requerimientos funcionales, no funcionales, y de crecimiento esperado del proyecto.

Diseño – Interfaz de Usuario (User Interface/UI) – Experiencia de Usuario (User Experience/UX)

Es la persona que tomará las decisiones de como se realizará la interacción con el usuario. Son las personas que harán el diseño general, y los flujos del usuario para cada una de las funcionalidades, usualmente con herramientas de diseño. Se deben enfocar en facilitar y agilizar la experiencia del usuario. En algunos casos también participan como desarrolladores de Front-End, apoyando en la aplicación de elementos de diseño.

Aunque lo mas normal es pensar en interacción por medio mouse y teclado, cada vez es mas común la utilización de otros tipos de interfaz con el usuario, como pantallas táctiles (touchscreen), interacción con voz, o interacción con medios especializados como botoneras y controles.

Analista

Es la persona que realiza el análisis, levantamiento y documentación de los requerimientos del cliente, y traduce dichos requerimientos a procesos o flujos dentro del sistema. Este es el primer rol que usualmente es compartido, es decir, lo toman programadores Sr. o Jr. con experiencia. Se trabaja muy de la mano con la gente de Diseño para obtener las soluciones correctas. En mi opinión todo desarrollador Sr. debe ser un buen analista.

Todos los clientes son muy diferentes. Algunos quieren compartir mucho, algunos muy poco, por esta razón, los Analistas deben de tener la experiencia de poder guiarlos en el camino correcto y extraer toda la información necesaria, incluyendo reglas de negocio, requerimientos funcionales y no funcionales. Estos requerimientos se suelen documentar como historias de usuario, y es importante validarlos con los clientes.

Desarrollador

Creo que es el mas obvio, y el mas normal dentro del blog. Son las personas que escriben el código para generar el software. Dependiendo del tipo de proyecto, de la tecnología y de la arquitectura puede que existan muchos tipos de desarrolladores en el proyecto.

Clasificaciones comunes entre los desarrolladores son por experiencia, Jr. y Sr., por arquitectura, Front-end, Back-end o Full Stack, o por tecnología, Web, Móvil, Base de Datos, etc.

Ingeniero de Base de Datos – Database Engeenier

Aunque era más común cuando todo era SQL, y aunque es un puesto más operacional, es posible que el proyecto necesite un Ingeniero de Base de Datos, especialmente cuando se trabaja con bases de datos ya existentes. Independientemente, todo desarrollador debe de tener los conocimientos mínimos para hacer modelado de datos, y entender cómo funciona el modelo de Base de Datos utilizada, ya sea relacional (SQL), Objetos, Documentos, Archivos, etc.

Probador – Testers – Quality Assurance (QA)

Son la persona, o grupo de personas encargadas de probar las nuevas funciones, y asegurarse que cumple con los requerimientos definidos por los analistas. Se aseguran de realizar pruebas funcionales y de integración de todo lo desarrollado, y de aprobarlo antes de ponerlo en producción.

Esto puede ser un punto de discusión muy fuerte, pero creo que el rol de Tester debe de aparecer únicamente en proyectos muy complejos, o en empresas tipo startup de software. Cuando los proyectos son sencillos, con 6 o menos integrantes o con integraciones externas sencillas, los mismos programadores deben de cumplir con rol de Tester, y asegurarse que lo que hicieron funcione correctamente.

Dev-Ops / Sistemas

También es un rol usualmente relacionado más con las operaciones, sin embargo, con la popularización de la Integración Continua (Continuous Integration / CI) o Entrega Continua (Continuous Delivery / CD), es cada vez mas común integrar este rol en los proyectos de desarrollo. Básicamente son las personas responsables de poner en marcha el sistema la primera vez, y realizar la actualización cada vez que hay una nueva versión.

La práctica más común actualmente es automatizar la puesta en marcha. Esto se hace por medio de procesos automáticos que se encargan de, revisar el repositorio por versiones nuevas, bajar la nueva versión, compilarla, ejecutar los sets de pruebas (unitarias, funcionales, integración), y si todo está bien, actualizar la aplicación, ya sea en un servidor, y en un repositorio de actualizaciones, como los App Stores.

Resumen

Con esto llegamos al final del Post, donde vimos que no hay nada mas importante en un proyecto, que la gente que lo compone. Vimos que PMI llama a todas las personas de un proyecto Interesados, y que los divide en Participantes, gente que participa activamente en el proyecto, y Afectados, gente que no participa, pero es afectada por la ejecución o resultado del proyecto.

Por otro lado, Scrum separa sus roles en Cochinos y Gallinas. Los roles Cochino, son los que participan activamente en el proyecto, que están comprometidos. Son los que toman todas las decisiones del proyecto. Los roles gallinas son los que tienen interés en el proyecto y pueden opinar, pero no participan de manera activa y no participan en las decisiones.

Al final, vimos que roles existen en los proyectos de Software, los cuales fueron Dueño del Proyecto, Usuarios, Scrum Master, Arquitecto, Diseño, Analista, Desarrollador, Ingeniero de Base de Datos, Tester y Dev-Ops.

Finalmente, el acordeón del post:

• Lo mas importante en un proyecto son las personas.
• En PMI, los interesados son todas las personas que participan, y que son afectadas por el proyecto. Es buena práctica documentarlos.
• En Scrum los roles se clasifican en roles cochino, y roles gallina.
• Los roles Cochinos, son quienes participan activamente en el proyecto. Son los que están comprometidos. Son los que toman decisiones.
• Los roles Gallina son la gente que participa, pero no de manera activa. Están involucrados, pero no comprometidos. Pueden opinar, pero no toman decisiones.