¡Enhorabuena! ¡Acaba de entrar un proyecto multimedia interesante! ¡Tienes un equipo de 3 o 4 personas y unos 4 o 5 meses para desarrollarlo y podría ser tu primer proyecto gestionado de manera ágil!
La gestión ágil en proyectos de software está empezando a ser muy popular entre las empresas debido a los buenos resultados que experimentan: reducción importante de esfuerzo inútil y horas extra, una reducción enorme del sufrimiento y desgaste del equipo, clientes más contentos y fidelizados…
Y es que desde unos años atrás, venimos gestionando los proyectos de software de una manera muy similar a esta:
1. Todo empieza en una conversación entre el cliente y una persona de negocio, habitualmente comercial, el cual no suele saber cuánto cuesta construir lo que vende, pero hace una oferta del software que el cliente necesita, e incluso de una fecha, tiempo y coste aproximado.
2. Esta persona del área de negocio, le explica las necesidades que él ha entendido que el cliente tiene. Después de este punto, el comercial no suele volver a aparecer
3. Con lo que el funcionalista ha entendido que el cliente necesita, le envía un análisis funcional. Habitualmente un auténtico libro de 150 páginas, que el cliente raramente entiende. A penas se lo lee y sólo pregunta pocas cosas del estilo “¿Las ventanas van a quedar como en los diagramas? ¿Tendrán colores, no?”. Y, por supuesto, se lo hacemos firmar.
4. Con este montón de documentos firmados, el funcionalista envía a un técnico su análisis, que lo lee y lo interpreta. De su interpretación, el técnico genera un informe técnico donde se pretende sintetizar todo el producto en un solo documento: cómo se va a programar y cuántas horas va a llevar. De ese documento, que probablemente sea copypaste de otro anterior, se saca un resultado de varios cientos de horas necesarias para construir el producto.
5. Todo este análisis técnico llega al equipo de desarrollo, con la intención de que sólo sea ir leyendo el documento técnico e ir picando código sin necesidad de pensar.
Todo esto suponiendo…
- Que la tecnología no cambia.
- Que todos se entienden entre ellos a la perfección y no hay errores de interpretación.
- Que tu equipo de desarrollo no necesita aprender nada, lo sabe hacer todo de inicio a fin de proyecto.
- Que tu comercial no se ha sobre-comprometido sin saberlo.
- Que las necesidades de cliente no cambian, y no se va a despertar un día dándose cuenta que acaba de entender mejor su problema.
- Que el cliente no necesita ver el producto hasta que termina, y es entonces cuando recibe exactamente lo que él quería.
- Que los documentos, emails, etc. Son la mejor manera de comunicarse, y no se pierde información entre fases de desarrollo.
Han pasado 2 meses y acaba de llegar el análisis técnico al equipo de desarrollo, ¡nos hemos comido medio plazo de entrega!
…Y de repente, oyes cosas del estilo:
… Y de repente llama el cliente:
Van pasando las semanas y todo son nervios y estrés. El proyecto se alarga, las cosas no eran como se pensaron, había cosas no especificadas y otras muy detalladas que ahora resulta que no hacen falta.
Y ayer salió una red social nueva que lo ha petado y el cliente quiere conexión con ella!
¿Y recuerdas ese registro de usuarios tan seguro y complejo de implementar donde el diseño técnico se centró y todo gira alrededor de ese concepto? Pues que al final van a hacer login en la aplicación mediante Facebook
¡… Y más miedos!:
- A tu técnico estrella le va a tocar la lotería.
- Tu comercial se ha equivocado y el proyecto es realmente para Junio y no Julio.
- Te das cuenta que tener medio equipo distribuido en la India no era tan buena idea.
- No llegamos a todo.
- ¡¿Los programadores dicen que quieren cobrar las horas extra?!
- Y ahora resulta que hay bugs…
Si esta situación te suena, sigue leyendo y alégrate: como hemos dicho al principio del artículo, tienes suerte: Aún puedes hacerlo de manera ágil. Lo cual, para simplificar lo reduciremos a 3 conceptos básicos:
1. Acepta (de una vez) que no puedes acertar en las estimaciones a más de 1 mes vista
Debido a ello, desarrolla piezas enteras de tu producto. No puedes estimar (y acertar) en alcance, tiempo y dinero con El Proyecto, pero igual sí puedes con La Gestión de Productos, El Registro de Usuarios, El Super-Espectacular Ranking de Usuarios, La Conexión con Twitter…
Estima el trocito de Proyecto, consturyelo entero y sólo ese trozo y muéstraselo a tu cliente.
Documenta si lo necesitas, no es malo, pero SÓLO ESE TROZO DE PRODUCTO. Ah! Y “trozo de producto entero” significa desde la interfaz de usuario hasta la persistencia de los datos: todo lo que la funcionalidad requiera para estar terminada.
¡En 3 semanas, el cliente puede llegar a tener su primera pieza de proyecto terminada!
… Y 3 semanas después del inicio del proyecto, si pide cambios no son traumáticos, ¿verdad?
2. Obtén feedback de tu cliente
Necesitas obtener información de él para estar seguro que el próximo trozo de programa que construyas es el correcto: es decir es el más prioritario para él. En la gestión ágil de proyectos siempre hay que construir primero lo más urgente para el cliente.
Gracias a esta comunicación permanente, conseguirás un cliente involucrado en el proyecto, proactivo e interesado en que las cosas vayan bien.
3. Las comunicaciones más efectivas son las que se producen cara a cara
¿Realmente crees que son óptimos los cientos de mails que se envían y reciben? En algún momento de la historia de la producción de software se decidió que nada sería hablado y todo por mail. Probablemente debido a la necesidad de tener todo por escrito, y poder justificarse y defenderse con un mail de alguna fecha pasada, y así poder desentenderse de cualquier imprevisto.
¿No resulta frustrante que cuando surge un problema se gaste mucho mas tiempo en buscar culpables y excusas que en solucionar el problema?
Reduce las comunicaciones lo máximo que puedas, tanto en numero (cantidad de mails/documentos) como en distancia (el equipo de desarrollo enviándose mails con el equipo de testing, el cual se sienta ¡dos mesas más adelante!).
Esto se consigue cultivando equipos multi-funcionales. Es decir, un único equipo con todas las habilidades necesarias. Un único equipo que pueda hacer frente de inicio a fin un proyecto: capacidad de programación, de testeo, de diseño, de UX…
Junta a tu EQUIPO A en una misma mesa.
Y por supuesto, deja que se comuniquen con el cliente. Quizá necesites alguien que haga de intérprete entre el cliente y el equipo (Un Product Owner) o quizá no. Si sigues este consejo verás como de forma autónoma y casi mágica tu equipo se vuelve auto-organizado, cuyo trabajo estará siempre visible (recuerda que han de entregar trocitos de proyecto cada X semanas) y siempre apuntarán a una excelente calidad (ya que sus errores serán visibles por el cliente cada 3 semanas).
Y esto obviamente no es todo. Pero sí un punto de partida para picarte la curiosidad y leer mucho sobre Agile. Te recomiendo el libro The Agile Samurai donde se explica de manera divertida y entendible qué es esto de Agile, la web de Agile Scout donde encontrarás un montón de artículos interesantísimos. Y, por supuesto, el grupo de discusión de Agile Spain y Agile Spain Barcelona donde siempre se organizan eventos formativos.
Ahora quizá encaras ese proyecto que acaba de entrar de otra forma.
Cita recomendada: BERMEJO, Marcos. Breve introducción a Agile en la gestión de proyectos multimedia. Mosaic [en línea], junio 2012, no. 98. ISSN: 1696-3296. DOI: https://doi.org/10.7238/m.n98.1226.