Leo en el numero 29 de la excelente revista dotNetMania, un artículo de opinión Antonio Quiros, que no puedo dejar de comentar aquí. En este artículo, el autor defiende que existen ciertos parámetros que nos permiten seleccionar aquellas empresas a las que debemos confiar los proyectos importantes, y que estos parámetros tiene una expresión externa visible: la madurez. En un enfoque muy CMMI, Antonio, propone que aquellas empresas 'más maduras' son las que debemos seleccionar para nuestros proyectos. Antonio solo propone explicitamente que seleccionemos este tipo de empresas cuando nos enfrentamos a grandes proyectos o proyectos importantes. Para mí esto es decir siempre, porque no hay diferencia sustancial en cuanto a técnicas de gesitón entre proyectos pequeño y grandes, por lo menos no a nivel esencial, y para quien nos contrata su proyecto siempre es el más importante.
Si estoy hablando de este artículo, es porque no comparto la visión de la industria del software que transmite. Que nadie me mal interprete, no es que no valore la importancia de las técnicas de estimación, de la gestión de requistos, de la preocupación por la calidad o la gestión de riesgos, pero sin olvidar que son técnicas no valores. Cualquiera que haya asistido a algunos de las decenas de cursos de gestión de proyectos de software que he impartido saben el hincapié que hago en esos aspectos. Eso no quita para que abogue por otro tipo de filosofia de gestión de proyectos y de empresa, que la que defiende el articulo de Antonio Quiros.
En el artículo, Antonio Quiros propone una encuesta ,que nos permite seleccionar la empresa idonea. Siguiendo esta lista no hay duda de que vamos a seleccionar una empresa madura. ¿Pero seleccionaremos la empresa que nos conviene? Puede ser que no, y voy a comentar el por qué.
Atonio Quiros aboga por empresas certificadas, con varias cetificaciones sobre calidad, madurez y demás aspectos. Pero todos hemos sufrido esas certificaciones y sabemos el relativo valor que tienen y como se fuerza que se auditen solo ciertos proyectos o ciertos departamentos. Para el auditor somos el cliente, es dificil que nos suspenda. Ni una sola empresa que se proponga certificarse se queda en el camino y el proceso se suele plantear solo con un fin, obtener la certificación. El fin rara vez es mejorar. Sin duda las certificaciones y las metodologías pesadas son atractivas porque nos eximen de responsabilidad: si el proyecto falla, siempre podemos autoengañarnos con la idea de que lo que fallo es la metodología, no el jefe de proyecto. Además nos permite protegernos del cliente tranfiriendole los costes a el. En lugar de estar haciendo su proyecto innovador, y proporcionarle un clara ventaja competitiva, estamos haciendo su proyecto mediocre pero sin riesgos. El mensaje es: vale esto que te entrego quiza no valga lo que has pagado, pero yo al menos te he entregado algo. Lo mismo se aplica a los desarrolladores, es facil pasar un examen de certificación a base de empollarse respuestas a preguntas y sin tener un profundo conocimiento.
Sin duda asegurar la madurez es un proceso caro. Exige un carga extra de trabajo y burocracia que nuestro cliente tiene que asumir. Sin duda esto reduce los riesgos, son muchos los proyectos que fallan, y evitar los riesgos en en muchas ocasiones vital. Pero existe otra manera mucho más barata de reducir el riesgo y asegurar que un proyecto triunfa: involucrar al cliente.
Otro tema que no comparto es la ilusión de asumir que los requisitos se pueden conocer de antemano. Los requisitos cambian, y luchar contra ese cambio, les cuesta muchos recursos a las empresas 'maduras', que se empeñan en evitarlo. Debemos asumir que esos cambios existen, vivir con ellos y comprender que los cambios surgen porque el cliente gana conocimiento sobre sus necesidades. Y eso debería ser bueno para nosotros, un cliente que descubre sus necesidades y la ve cubiertas por nuestro software, es un cliente satisfecho. Antonio Quiros dice que la principal diferencia de nuestra industria es "la dificil plasmación en lenguaje formal claro de los requisitos funcionales", en mi opión la diferencia es que en nuestra industria, no se pueden plasmar esos requisitos, con un coste razanable, de antemano. Sobre todo usando UML como sistema de Ingeniería de Producto, sea lo que quiera que signifique esta frase, pues no llego a comprender como un lenguaje puede constituir un sistema. Usar UML no es garantia de nada, más bien lo contrario, desde mi punto de vista. Es como proponer que por usar C# o JAVA vamos ha hacer mejor software.
Pensar en garantizar la calidad del software a través de la implantanción de una certificación ISO es como pensar que estudiar literatura te garantiza ser un buen escritor. La norma ISO solo dice que debes establecer un proceso de calidad, pero nada dice sobre como es ese proceso. Puedes certificar en ISO un proceos de calidad del software que sea totalmente ridiculo.
También me parece chocante que cumplir plazos sea algo tan valorado, con ser importante. De nada sirve cumplir plazos, si no entregas valor al cliente. Solo el software que sirve al cliente es medida de avance del desarrollo de software. Entregar en plazo algo que no sirve al cliente, que no cubre sus necesidades y que no se adapta al proceso de descubrimiento de requisitos que surge a lo largo de todo proyecto es algo sin valor. Sin duda yo prefiero gastar los recursos en que el cliente quede satisfecho, no en asegurarme que recibie algo. Entregar algo debería estar asegurado de antemano y no debería costarle dinero al cliente. Yo quiero que el cliente reciba algo que le ayude en como hace su negocio de manera radical, algo imposible si trato de protegerme de el cliente, y no logro su colaboración.
Por todos estos motivos yo propongo una lista alternativa a la que propone Antonio Quiros para evaluar empresas a contratar:
1] ¿Le ha explicado la compañia a contratar que las estimaciones solo son estimaciones y que estas solo se aproximaran a la realidad según avance el proyecto?
2] ¿Es la compañia a contratar capaz de mostrarle software que otros clientes usan y llevarle a ver como lo usan?
3] ¿Es la compañia a contratar consciente de que los planes fallaran y de que habrá que actuar con agilidad replanificando?
4] ¿Le proporcionará la compañia a contratar software a menudo para que usted pueda juzgar por sí mismo si la calidad es aceptable?
5] ¿Le proporcionará la compañia a contratar software a menudo para que usted pueda juzgar por sí mismo si cubre sus necesidades?
6] ¿Le informará la compañia a contratar de los riesgos para que usted sea quien decida si dedicar recuros a atajarlos o asumirlos?
7] ¿Le proporcionará la compañia a contratar documentación generada directamente desde el código fuente?
8] ¿Es de calidad el código fuente que la compañia a contratar le proporcionará y le puede mostrar el código de otros proyectos?
9] ¿Exigirá la compañia a contratar que usted entienda los requisitos iniciales y se los presentará en un lenguaje natural para usted?
10] ¿Comprende la compañia a contratar que solo conocerá sus necesidades cuando el proyecto vaya avanzando?
11] ¿Me proporcionará la compañia a contratar software ejecutable con regularidad en el que usted pueda basar el proceso de descubrimiento de sus necesidades?
12] ¿Me proporcionará la compañia a contratar software ejecutable con regularidad que me permita ir amortizando mi inversión durante la vida del proyecto?
13] ¿Son los profesionales de la compañia a contratar gente reconocida y respetada en la comunidad de desarrolladores y técnicos?
14] ¿Van a divertise los desarrolladores de la compañia mientras desarrollan mi software?
15] ¿Me garantiza la compañia a contratar que los profesionales que van a llevar a cabo el proyecto son de primera línea y están vinculados a ella?
16] ¿Cuenta la empresa a contratar con desarrolladores que escriben código que prueba su código?
17] ¿Cuenta la empresa a contratar con especilistas en calidad del software integrados en el equipo de desarrollo?
Evidentemente habrá clientes que se sientan más comodos con la lista del Antonio Quiros, pero, hay que tener en cuenta que esa lista no nos separá mucho del enfoque que nos ha llevado a un altisimo porcentaje de proyectos fallidos en los últimos años y que ignorá todos los avances realizados en el campo de la gestión de proyectos de software en los 15 últimos años. Ya he abogado con anterioridad por la elección de los clientes. Y además he visto despues que no soy el único.
En cierto modo, la lista de Antonio Quiros, a mi modo de ver, es seguir tropezando en la misma piedra: poner el proceso por encima de clientes y desarrolladores.
No es la primera vez que abordo estos temas en mi blog, si te interesá lo aquí comentado te sugiero que leas: "No les vamos a volver a engañar", que trata temás similares.
Antonio Quiros, nos comenta que va a ir desgranando sus ideas en proximos números de la revista. Yo no creo que pueda resistir la tentación de ir comentando en paralelo mi punto de vista.