Chess - antoniomartel.com

Archivos de Autor: antoniomartel

Contratos a precio cerrado

Hace algunas semanas me preguntaba Antonio, a través de los comentarios de este blog, por el tipo de contrato que tenía en mis proyectos y si estos contratos se realizaban con clientes internos o externos. La negociación sobre el contrato es uno de los asuntos más difíciles con los que nos podemos encontrar en un proyecto y probablemente, dónde puede surgir más fricción entre proveedor y contratante.

Trabajo en el área de administración pública de una empresa de desarrollo de software. Eso significa que, al menos en el 90% de los proyectos en los que trabajo, tengo como cliente a un organismo público. Los contratos vienen normalmente determinados por un pliego de cláusulas administrativas y otro de prescripciones técnicas en los que se detallan los servicios contratados, las características del producto a ser desarrollado y el precio máximo que puede tener la oferta. Se especifican incluso las características técnicas del software y hasta el perfil de los participantes en el proyecto. Todo está muy acotado y delimitado. Es el precio que tiene que pagar la administración pública para evitar arbitrariedades.

Si se ha tenido suerte y se ha podido ganar el concurso público nos enfrentamos luego, tanto cliente como proveedor, con la cruda realidad de los proyectos. Y es que las circunstancias cambian, aparece nueva legislación que afecta al proyecto o lo que se pensó que era correcto unos meses antes se ha podido comprobar que ahora las necesidades son distintas. ¿Qué hacemos? Si adaptamos el producto a todos los cambios que el cliente necesita,  nosotros como proveedores, sufriremos ese coste adicional. Si negamos al cliente cualquier posibilidad de cambio, remitiéndonos siempre al contrato y a los pliegos, corremos el riesgo de entregar al cliente un producto ajustado a un decreto del año anterior o que, por otras causas, ya sabe que no le va a servir a sus necesidades.

La forma de evitar ésto, por lo menos la que mejor me ha funcionado hasta ahora, ha venido dada por la propia forma de trabajar en estos proyectos, usando Scrum. Al inicio del proyecto hago una lista con las funcionalidades que hay desarrollar y le asigno a ellas una puntuación que el cliente conoce desde el principio. Si el cliente quiere incluir dos nuevas funcionalidades le pido que me indique qué otras funcionalidades de similar puntuación sacamos de la lista. Normalmente esta solución le sirve para resolver la situación y no tiene problemas en renunciar a otras funcionalidades que ahora sabe que no son tan importantes. Si todo queda constatado en un acta de reunión y, sobre todo, queda entendido a qué se renuncia y qué se va a obtener a cambio, no suele haber muchos problemas.

Esta es la solución que yo aplico. Como siempre, espero que le pueda servir a alguien.

Revista ITPROIECTUS y las I Jornadas en Dirección de Proyectos

El pasado viernes 29 tuve la oportunidad de dar una charla sobre el Factor humano en la dirección de proyectos en las I Jornadas de Dirección de Proyectos organizadas por la SPEGC y ITPROIECTUS, la empresa de consultoría y formación en gestión de Iván Tejera.

Me sorprendió mucho la buena asistencia que tuvo el evento: acudieron alrededor de 90 personas que prácticamente llenaron la sala. Muchos aguantaron hasta la ronda final de preguntas pasadas ya las 9:00 de la noche de un viernes. Creo que fueron unas jornadas interesantes por la calidad profesional de los ponentes (espero que hayamos estado al nivel esperado por los asistentes) Conocía personalmente a algunos de ellos y muchos suman un montón de años de experiencia dirigiendo proyectos y equipos de trabajo ¡es difícil contarles algo nuevo!

En las jornadas participaron, entre otros, directores de proyecto, responsables de departamentos de desarrollo o de nuevas tecnologías como:

  • Raúl Herranz hablando sobre Metodologías Ágiles en la dirección de proyectos
  • Antonio Dorta sobre la Gestión visual en la gestión de proyectos
  • Mónica Khiani interviniendo para hablar sobre Gestión de Proyectos desde el enfoque de PMI – PMBOK
  • Agustín Tapia que hizo una divertida comparación entre la gestión con Scrum o PMBOK
  • Miguel Quintanilla Eriksson sobre La Dirección de Proyectos en la Administración Local
Además de las charlas, se aprovechó para hacer la presentación del primer número de la revista PROIECTUS en la que, además de los ponentes en estas jornadas, también escribieron Eduardo Gutiérrez Bahillo, Manuel Vara, Juan Carlos Falcón, Davide Mazzanti, Vicente González Medina y Roberto González Yuste. Se incluye también una entrevista a Claudia del Toro Vargas, jefa del proyecto de revisión de la traducción del PMBOK 5 al español.
Les dejo aquí un enlace a la revista en su versión digital y algunas fotos del momento de mi charla. Atentos a http://proiectus.es/ dónde se publicarán los vídeos de las charlas.
Enlace al 1º número de la revista Proiectus
Enlace al 1º número de la revista Proiectus

Factor humano en la dirección de proyectos. Ponencia Antonio Martel
I Jornadas Dirección de proyectos. Ponencia Antonio Martel
I Jornadas Dirección de proyectos. Ponencia Antonio Martel

5 Lessons learned in Project Management

Whenever I finish a project I try to have a look at what went wrong, what worked as a charm, and what I tried but it didn’t work out. Even when I get a final negative balance, the project may has been worth it if I don’t make the same mistakes again.

From some of these balances, I have extracted five of the most important lessons I’ve learned. Some are beginner mistakes, others should have been solved using simple logic but, by then, it wasn’t that evident to me. Here you go:

Agility works

It is difficult to quantify it but since I started using Scrum in my projects, the number of hours spent by functionality went down. Just doing the daily meeting for 15 minutes, maintaining project status chart that tells us if we are going well or not and a delivery every two weeks allowed us to obtain 80% of the benefits of Scrum. In addition, delivering consistently every two weeks, showing client what was agreed two weeks earlier, seemed to bring customers some comfort. In July or August, when meetings were not possible, the weekly delivery of a simple two-page document with the percentage of completion for each functionality and two paragraphs explaining the reason of those percentages, helped to restore credibility in a difficult project (especially in September when they could check that those percentages were real)

Everything is not positive in Scrum

It requires much more dedication of the Scrum Master than it would if you only were playing the role of project manager. Those 15 minutes at the daily meeting will tell you a lot about the difficulties that need to be solved to keep going forward. Trying to solve them will take you the rest of the morning.

On the other hand, having a delivery every 2 weeks can be exhausting. You cannot be sprinting for months and months. After six months you will be ending trotting (hopefully) You need to take this into account since the first planning.

Last but not least, Scrum is not magic. Whatever methodology you use you will need a team able to perform at a good level, willing to pitch in and eager to contribute. Teams like that do not grow on trees. If you already have one of those teams the project manager mission will be to interfere as little as possible.

Adding more workers to the team will slow it down

Well, this is already said for a lot of years in the book The Mythical Man-Month. Yet it is necessary to emphasize this, there are no much exceptions to this rule. No matter how tight the deadlines are: Nine women cannot make a baby in one month.

Who is the owner of all this?

No matter how we call it: identifying stakeholders, designating the product owner or involving the stakeholders. At the end we need to know who will actually validate. And I do not mean who will sign the bill. You also need to know who will use the product. The project will only be successful if after delivering it works and it is useful.

In certain project, the client’s director gave us all the documentation, validated partial deliveries, tested the entire application and congratulated us for the work done. Unfortunately, when his secretary attended the training session a week before sending the product to production, she said: ‘This is not going to help me: that one is not the right template and I need to collect different data than the one showed there’ . This meant a week of overtime and extra effort and the risk of putting into production environment a product that could be unstable.

Minimum Viable Product

If you already have something that may be useful to the user, give it to it, put it into production, take it out for sale. Do not wait until you have completed every single functionality. If you remember the Pareto principle, with only 20% of them you will obtain 80% of uses of your product.

While in production you will begin to get the impressions from its users. They will know more accurately what they really need and you will know what you did wrong and how you can improve it. If you bet on a single final delivery you will have only one bullet to hit the target (to do this would have saved us a lot of problems with the product mentioned in the previous point)

Those are my lessons learned. I hope someone will make the most of them.

3 artículos imprescindibles en el desarrollo de software

De cuando en cuando publicaré una entrada en este blog sobre aquellos artículos que me han parecido importantes y de los que pienso que merece la pena su lectura. Aquí van los tres primeros:

La nueva jerga de la programación en el blog Coding Horror

Jeff Atwood menciona en este post algunos de los términos que se han convertido en populares en la jerga informática desde hace algunos años. Creo que más que populares son sobre todo divertidos. Me gustan especialmente uno de ellos: La funcionalidad por jurisprudencia se utiliza para definir aquel error que lleva tanto tiempo en la aplicación que se convierte en el comportamiento esperado de la misma. Cuando deja de aparecer se solicita al departamento de soporte que ‘lo arregle’

4 signos de que Agile está en declive- La secuela

También me parece muy divertido y sobre todo muy claro este post sobre signos de declive de Agile, postagilismo y los principales errores que debemos evitar en esto de la agilidad. Al final del artículo aparece un listado de cuatros puntos que indica que repitamos como un mantra (muy de acuerdo con todos los puntos):
  1. No hay soluciones mágicas ni un único camino al éxito.
  2. Esto en un proceso de aprendizaje. Los fallos son inevitables y necesarios.
  3. Lo que quiera que sea lo que yo hago no tiene porque ser la clave del éxito para otros.
  4. Estoy dispuesto a ayudar a construir un puente entre desarrolladores y el negocio.

La verdadera calidad software la tienes que ver en los fuentes, en el código. No te fíes de nada más

En esta entrada de su blog Javier Garzás explica que dónde mejor podemos ver la verdadera calidad de un software es acudiendo directamente al código fuente. De él podremos deducir la calidad y el diseño que se ha seguido mejor que de la documentación y pdfs que acompañan cada entrega.
Recomiendo todo el blog de Javier, no sólo este post. Si le echan un vistazo a su historial de artículos podrán ver un montón de posts interesantes sobre el desarrollo de software en España. Seguro que verán reflejados en muchos de ellos su trabajo diario.

Jornada sobre cómo «Adoptar Scrum y sobrevivir al intento…»

El pasado jueves tuve el placer de dar una pequeña charla en el edificio IncubeGC de la SPEGC al departamento de Desarrollo e Innovación Técnológica de www.aidacanarias.com sobre la adopción de Scrum y los problemas que pueden encontrarse al comenzar a implantarlo.

Espero que les resultara de interés. Solo me queda desearles buena suerte en su implementación. No será fácil pero, con todo el empeño y esfuerzo que han puesto Emilio, Alejandro y sus compañeros, seguro que todo les irá bien.

Les dejo con enlace a la presentación en Prezi que utilicé y con algunas fotos del evento:

Presentación Prezi sobre cómo "Adoptar Scrum y sobrevivir al intento..."

Tiempo para preguntas en la charla sobre Scrum a AIDA Canarias