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.
Todavía no he podido leer el artículo de Antonio, pero sí estoy de acuerdo en muchos de los comentarios que haces, aunque en algunos discrepo un poco.
En cuanto a la captura de requisitos, es cierto que a medida que se desarrolla el proyecto surgirán nuevos requisitos y otros cambiarán, pero aún así, es nuestra responsabilidad intentar poner el empeño máximo en que la captura inicial sea lo más completa posible, para que estos cambios o nuevos requisitos sean realmente cambios o nuevos, y que no sean requisitos que estaban ahí desde el principio pero que no hemos sido capaces de encontrarlos.
El cliente irá descubriendo sus necesidades según avance el proyecto. Eso es muy cierto, pero tb podemos ayudar nosotros a que éstos salgan en fases inciales, por ejemplo, presentando maquetas o prototipos que puedan servir para validarlos. En muchas ocasiones, en cuanto se ve un pequeño prototipo empiezan a surgir nuevas ideas para el cliente. Y si en lugar de hacer esto….y si hacéis tb…
Una máxima que debemos tener siempre presente es que todo proyecto debe estar preparado para el cambio y si no lo está fracasará. No siempre se tiene claro esto y así salen las cosas.
Por otro lado, al tema de las estimaciones y del cumplimiento de plazos yo sí le daría más importancia. Para el cliente es muy importante contratar un software que le sea entregado en tiempos, con calidad, y que cubra sus necesidades. Hay veces que de la llegada de ese software dependen muchos intereses. Nada más empezar no podemos decirle que el proyecto podrá durará unos 3 meses, pero que sepa que esto es una estimación y que puede tardar 6 meses.
Cierto es, que lo que sí tiene que tener muy claro el cliente, y hay que transmitírselo así, es que cosas como los cambios y los nuevos requisitos afectarán al proyecto y a los tiempos de entrega del mismo. Muchas veces se pide, se pide y no se da cuenta que en lugar de 3 meses se va a tardar 6. Me recuerda al albañil que empieza a hacer una obra y da un presupuesto. A medida que hace la obra su cliente le pide X cambios pidiendo mejoras, y luego se lleva las manos a la cabeza cuando la obra se dispara de precio.
Las preguntas que comentas me hacen tener esta reflexión. Cómo está el mundo del software y cuántas compañias mediocres hay por ahí que hacen verdaderas chapuzas!! Ya sé que esto es algo ideal, pero casi todo lo que comentas debería ser algo que el cliente diese por supuesto, ya que nosotros debemos ser los profesionales y actuar en beneficio del cliente, llevando los proyectos a buen término.
ILM me llama especialmente la atención el parrafo en el que dices:
«Nada más empezar no podemos decirle que el proyecto podrá durará unos 3 meses, pero que sepa que esto es una estimación y que puede tardar 6 meses.»
Lo que no podemos decirle al cliente, porque es mentirle, es que de antemano sabemos con certeza que es lo que necesita y que se lo vamos a entregar en 6 meses, por que es mentirle. Otra cosa es que queramos mantener esa falsa ilusión, porque es más facil comunicarsela al cliente. Una regla básica de estimación es comunicar nuestras estimaciones en rangos. Debemos tener en cuenta que muchos estudios avalan que tendemos a ser muy optimistas.
Otro tema, yo no hablo de no realizar una captura de requisitos, sino de que estos: sean los minimos posibles para poder entregar en un corto plazo una parte del sistema que el cliente pueda comenzar a usar, para aprender sobre sus necesidades y descubrir nuevos requisitos, para ver que nuestra empresa no es lo que necesitas (pe. porque lo entregado sea de muy mala calidad), o simplemente para que su inversión empieze a tener retorno. De nada sirver consumir un motón de recursos en generar documentación sobre requisitos que nadie va a leer, que nadie va a utilizar y que en 1 mes va a estar totalmente obsoleta. Las historias de usuario son una aproximación suficiente.
Los prototipos tienen una pega, no tienen calidad suficiente para implantarse, el cliente no nos puede juzgar ni conocer como va el proyecto viendo prototipos, solo viendo software que sea entregable.
Como ya sabes, desde mi modesta opinión y experiencia, comparto tu forma de entender esta «industria» (que poco me gusta este nombre). El caso, es que al hilo de lo que comentas sobre los sistemas de gestión/aseguramiento de la calidad, me gustaría contar algunas cosas.
Para mi, hoy en día, contratar una empresa informática certificada ISO no es garantía de nada, es más, en cierta forma me provocaría desconfianza. Me he encontrado, no una ni dos, muchas empresas que presumen de certificacion de calidad ISO, pero que ni siquiera son capaces de definir su ciclo de vida, su metodología, pruebas, calidad del código… En la mayoría de los casos la certificación de calidad no tiene más objetivo que conseguir el sello, da igual si mejoramos o no… «total antes de que venga el auditor apañamos un poco los registros y listo» (esto es real). Por eso me provocaría desconfiaza una empresa de nuestra «industria», que como uno de los principales motivos para confiarle un proyecto se escudase en su certificación de calidad, en vez de en cosas como las que comenta Rodrigo.
Creo que el concepto de certificación de calidad esta irremediablemente devaluado por querer hacer negocio de la calidad. La calidad no debería ser un argumento comercial, para mí, la calidad debería ser una necesidad interna… Una forma de descubrir nuestros fallos, de ayudarnos a mejorar, y en definitiva de ser unos excelentes profesionales. Prefiero mil veces utilizar como argumento comercial a clientes satisfechos, proyectos en plazo superior al estimado pero que realmente han supuesto una innovación y han demostrado ser un beneficio para el cliente, etc… que una triste certificación de calidad.
Un Saludo
El «nada más empezar» no era lo más adecuado. Yo no digo que desde el minuto 0 le vas a poder decir el tiempo del proyecto pero algún momento le tendrás que decir algo, porque el tiempo que lleve tb influirá en el coste y esto sí que es una cosa que valora mucho el cliente. Al principio de proyecto es una solución muy válida el tema de estimar en rangos, pero a medida que avanza el proyecto, cuando se tienen más claros los requisitos, se debería poder ajustar más.
Cierto es que en la mayoría de las situaciones se suele ser optimista. Cuando un tarea está al 80% es que todavía le falta otro 80%. ( no es algo así..) Pero como esto ya lo sabemos, vamos a intentar poner medidas 🙂
En cuanto a los prototipos, yo si suelo ser partidarios de ellos, siempre que se entienda que son el producto final y que son simplemente eso, prototipos; usar y tirar. Lo veo una buena manera de validar requisitos y obtener nuevos, ya que se ve «algo funcionando». El principal problema que veo, que se puede pensar que es casi el producto final y que el fin de proyect está cerca. Tb depende del proyecto, porque no para todo tipo de proyectos viene bien.
Cuando comentas que lo mejor es recoger una serie de requisitos mínimos para poder entregar algo a corto plazo. ¿ no sería como hacer un prototipo ? Si haces algo para seguir capturando más requisitos y que el cliente vea algo…En esta situación es más que posible que surgan nuevos requisitos que te harán tirar la aplicación.
Por matizar, cuando comentaba que la captura de requisitos debería ser completa, no estoy diciendo que hay que construir montañas de documentación. Todo en su justa medida. Podría valer con un simple listado, en una hoja excel, para ir teniéndolos localizados.
Hola a todos,
Me prece interesantisima la conversación que esta dando lugar este post. Para comenzar expongo de antemano que mi punto de vista es el de un desarrollador que se dedica a realizar su trabajo lo mejor que puede y le dejan, no la de un proyect manager. La sensaciones que te llebas al cabo de los años es que los clientes saben de sus necesidades pero desconocen como cubrirlas. En este punto se tendría que hacerse valer la figura del consultor pero en la mayoría de los casos el cliente no esta dispuesto a amoldarse a los cambios necesarios en su forma de trabajo para poder implantar una nueva solución tecnológica.
Si algo he visto con mis propios ojos es que las empresas cereen que un sistema informático hara que ese empleado completamente inútil, que no ha visto un ordenador en su vida, sea el elemento más productivo de la historia. Total que aunque le hagas el mejor programa que puedas al final siempre hay un técnico, externo o interno (cuando no uno mismo), haciendo el trabajo de este elemento. Todo esto acaba siempre con un cliente pidiendo y pidiendo mas requerimientos y un consultor aceptando y aceptando más cambios dentro del proyeto.
Mientras tanto al final de la cadena hay un desarrollador encerrado en un proyecto que nunca acaba y que siente que su labor nunca satisface realmente las necesidades del cliente por mucho esfuerzo y pasión que le heche. Eso si el dueño de la empresa informática se hace más y más rico gracias a las horas que se le han facturado de más al cliente haciendole creer que están justificadisimas por la extremada complejidad de sus necesidades.
Por otro lado, pienso como Rodrigo que entregar reducidas funcionalidades completamente finalizadas, que hacen poquito pero lo hacen bien, al cliente es mucho mejor que presentarle prototipos que al fin y alcabo no son realmente productivos para una empresa que, al fin y al cabo, es para lo que nos paga.
Saludos.
Rodrigo, que lindo tema que has tocado. No he leido el articulo, pero me hago una idea de la linea
Rodrigo, gracias por tocar estos temas más que interesantes.
Yo tampoco he leído el artículo de Antonio, pero me hago una idea de la línea que sigue. Como la parte trillada ya las has enfocado muy bien vos y la han completado con los comentarios; sólo agregaría que para darnos cuenta de la mejor forma de gestionar/administrar/coordinar un proyecto, simplemente veamos como han evolucionado las metodologias para esta tareas. No por nada, las metodologias ágiles (las de moda) restan importancia a la «burocratización» de los proyectos. El problema suele estar, en que las grandes consultoras (las muy grandes) siguen defendiendo sus logros con certificaciones ISO, CMMI nivel 5, etc. Pero (y esto lo vivo cada tanto) luego en sus proyectos no cumplen/aplican nada de lo que prometen, porque la dinámica de los mismos se los impide. ¿Esto está mal? en parte sí (que es lo que hablamos hasta ahora) pero por otro lado, se ven obligados a adaptarse; es grato ver que de a poco tienen q ser mas ágiles, mas moldeables, pero que tienen un dinosaurio interno que no les deja evolucionar.
Algunos pensarán, el tiempo dirá quien tiene razón; yo prefiero pensar que los clientes ya están eligiendo calidad antes que espejitos y cuentas de colores 😀
Saludos.
Vuelvo a leer aAntonio Quiros explicando su visión sobre la gestión de proyectos, en el
E La columna que viene escribiendo Antonio Quirós en la indispensable revista dotNetmania, me viene sirviendo
La columna que viene escribiendo Antonio Quirós en la indispensable revista dotNetmania, me viene sirviendo
Yo creo que hay que tener en cuenta cuatro puntos:
1. Que los recursos que van a integrarse en el equipo tengan nombres, apellidos, y curriculums con experiencia previa, que sean buenos profesionales, con experiencia contrastada.
2. Cerrar con el cliente que es lo que va a querer y dejar claro que se está abierto a cambios pero eso si pudiendo impactar a fechas de entregas y costes (parece mentira, pero si trasladaramos un proyecto de IT a la compra de un coche, tendrías a un cliente pidiendo extras … aire acondicionado etc… por el mismo precio que pago por un modelo base).
3. Que el cliente sea parte del equipo, esto es planificar entregas semanales a modo de «Sprints» con el que client pueda ver en todo momento el avance del proyecto y evitar el efecto «tunel», dejarle claro que si no colabora se tomara su silencio como aprobación del desarrollo realizado.
4. Establecer algunos métodos formales, sin llegar a matar de burocracia el desarrollo: realizar actas de las reuniones es vital para evitar malosentendidos y olvidos, realizar informes de progreso es muy importante, poniendo especial hincapie en riesgos y problemas que aparecen (en este aspecto hay que pensar en positivo, mejor decir los problemas cuanto antes para darles solucíon a tiempo, que no callarnos y esperar que cuando sea demasiado tarde nos reviente esto en la cara).
Como resumen, algunos puntos de lo que comenta el artículo de Antonio no están mal, pero es cierto de que el capital humano no se valora con tests o formulas matemáticas, son personas que deberían de ser evaluadas por empresas externas para ver si cumplen con la calidad esperada o no.
Estimado Rodrigo,
Agradezco mucho tus comentarios con referencias al artículo. Está claro que siempre puede haber opiniones variadas al respecto de la calidad, y no veo necesidad de entrar en debate sobre la validez de metodologías como CMMi, ITIL u otras que actualmente existen en esta industria.
Lo que si me gustaría es puntualizar ciertas cosas que comentas, que a mi opinión, se salen un poco de que podría denominarse «el sentido común» en la gestión de proyectos.
Un procedimiento es por definición una serie de pasos que nos permite hacer un proceso repetible. Seguir un procedimiento demostrado válido para gestionar proyectos nos da más garantías que no seguirlo. ¿Preferirias que te operace un medico siguiendo un procedimiento aprobado mundialmente? o por el contrario ¿prefieres la lotería y cruzar los dedos para que la forma de trabajar del cirujano, su sentido común y experiencia le digan como tiene que operar?. Esto es así, sobre todo teniendo en cuenta que todavía existen empresas que le dan categoría de Jefe de Proyecto a personas sin una certificación o acreditación suficientes.
Tocando el tema de los requisitos e involucración del cliente. Todos los que hemos trabajado en un proyecto sabemos que los errores que se producen en la captura de requisitos son los más costosos de solucionar. La captura y análisis de los requisitos es fundamental para evitar distintas interpretaciones, eliminar incoherencias y diseñar la solución que más se ajuste a lo que el cliente solicitó. Estoy de acuerdo en que un proyecto es algo vivo y que el cliente puede aportar más requisitos pero una buena gestión desde el principio, es la diferencia entre un cambio de alcance aprobado, entendido por el cliente y por lo tanto cobrado o una pelea sobre «yo queria decir y tu no me has entendido».
Tu frase «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», creo que desprende mucho de demagogia y poco de conocimiento acerca de las certificaciones ISO. Para que entiendas el ejemplo, si pongo los ingredientes de una paella en la mesa y a diez personas delante, la probabilidad de que salga una buena paella será más alta si junto a los ingredientes pongo una receta que si no la pongo. Creo que a buen entendedor.
El cliente y los desarrolladores juegan un papel en el equipo y el procedimiento tambien, esto no es tirar un balón al aire y que todos lo sigan como en el colegio. por lo tanto el éxito de un proyecto es la suma de todos a partes iguales, sin que el deltantero sea más importante que el defensa o al revés.
En fin Rodrigo, no tengo tiempo para contestarte más en profundidad, pero espero que tu afán por llevar la corriente no te impida ver la lógica de mis razonamientos.
un abrazo.
Este post comenzaba su vida como un comentario en respuesta a otro comentario de Antonio Quiros en un
Este post comenzaba su vida como un comentario en respuesta a otro comentario de Antonio Quiros en un
Hola Antonio:
Lo primero decirte que yo fui el primero que ‘pique’ como un bobo con el supuesto comentario tuyo.
Quiero pedirte disculpas y comentarte que los comentarios en mi blog no están moderados y que poco puedo hacer para evitar la situación.
Si se repite, estoy dispuesto a poner una nota aclaratoria en todos los comentarios o lo que haga faltar, pero creo que de momento tu comentario deja clara la situación.
El hecho de que hayas registrado tu nombre de usuario y el otro sea anónimo también deja claro que comentario es el fiable.
De todos modos, cualquier situación que tú me sugieras para aclarar la situación o evitarla en el futuro, la llevaré a cabo. Yo soy el primer interesado en que mi blog sea un sitio respetado.
Un saludo.