El jueves.nullpointer.exception
Para los más jóvenes del lugar, el contrato cerrado, también conocido como “llave en mano”, es ese tan usado en países como España, y que consiste, básicamente, en que el cliente redacta, siempre antes de comenzar el proyecto, un documento llamado “pliego de condiciones” que, principalmente, contiene los requisitos que debe implementar el software, o el sistema de información.
Redactado el “pliego de condiciones”, con sus requisitos, este se expone a las empresas candidatas a llevarse el proyecto, las cuales, tomando como base esos requisitos, le dicen al cliente por cuánto dinero están dispuestas a hacer el proyecto y en cuanto tiempo.
Por último, el cliente selecciona una empresa de desarrollo, normalmente basándose en la que menor precio oferta y menor tiempo dice. Lógico. Y, normalmente, añade al contrato las llamadas penalizaciones: si la empresa se retrasa en tiempo se le paga menos, y a más retraso menos se le paga.
Visto lo anterior, te puedes imaginar, si no lo has vivido, o puedes rememorar, si llevas en este mundo del software algún tiempo, lo explosivo, por llamarlo de alguna manera, que es el modelo.
¿Qué por qué?
Veamos a cámara lenta que pasa en la realidad….
1 – El cliente, redacta unos requisitos en un momento, tan temprano, que muchas veces escribe solo ideas poco concretas e incompletas de lo que se supone necesita que haga el software, y que normalmente, cuando avanza el proyecto, difieren de lo que realmente necesitaba, lo cual acaba sabiendo cuando recibe la primera entrega.
1.1 Esto sucede porque muchas veces hasta que no se ve un primer prototipo no se sabe bien lo que se necesita, o sucede porque se toman mal los requisitos, o sencillamente porque el mundo cambia y lo que creí necesario hoy mañana puede no serlo.
2 – El proveedor, en base a esos requisitos (como dijimos, la mayoría de las veces poco concretos, o que difieren de lo que realmente se necesita) hace una estimación del tiempo de desarrollo. Pero normalmente usa el popular método de estimación software llamado “estimación dirigida por lo que el cliente quiere oír”.
2.1 – En el proveedor hay unos señores (o señoras) llamados comerciales, cuyo objetivo es ganar el proyecto, y una vez ganado ya veremos que hacer.
2.2 – Esos señores saben que lo ganará, normalmente, quien menos tiempo y precio de. Más en estos tiempos de crisis y competencia… el negocio es el negocio.
3 – Comienza el proyecto. Objetivo del proveedor, terminar en plazo… como sea, sino… penalización. De lo cual se derivan los siguientes:
3.1 Como, según lo anterior, normalmente, se habrá estimado menos tiempo del necesario… a los que desarrollan les van a tocar trabajar a destajo y quedarse más de un sábado.
3.2 Al proveedor le preocupa entregar sólo lo que dicen los requisitos del pliego y no entregar un software que cumpla las necesidades de los usuarios (que no siempre es lo mismo).
3.3 – Si a lo largo del proyecto alguien piensa (el cliente, por ejemplo) que han cambiado, o eran erróneos, etc., da igual. Esos requisitos están firmados y hay penalización por incumplimiento. No hay cambio de requisitos.
3.2 El software se entregará en fechas como sea (recuerda, hay penalización por retraso). Por ello, ríete tu dejar tiempo para calidad software, metodologías ágiles, prototipos con usuarios, etc.
Terminando…
Con mayor o menor dramatismo, el anterior algoritmo simplificado ocurre día tras día en el 90% de los proyectos software.
¿Existen otras maneras de trabajar? Sí, pero puede que el mundo aún no esté preparado para ellas. Otras maneras son el pago por prototipos, o por tiempo de trabajo, o según ciclos de vida ágiles, o ciclos de vida iterativos (que no siempre son ágiles, ojo), etc.
Pero en estas otras maneras de trabajar, con solo su mención, aparece un gran temor, que llega incluso a oscurecer la mente de cualquier cliente: que ahora él esté en manos del proveedor, y esté, desde el lado oscuro, se las ingenie para alargar y alargar, meses y meses, el desarrollo software (y con ello el presupuesto). Y eso, con el contrato cerrado… no pasa.
Así que, por ahora, podemos seguir hablando de las decenas y centenas de buenas prácticas que el desarrollo software debiera tener, que mientras nuestra cultura contractual no cambie… no dejaran de ser llantos en las conversaciones de café que tenemos los informáticos (las conversaciones que tienen los informáticos que no están inmersos en un proyecto cerrado, claro, porque los que si lo están… no van a tener tiempo para cafés).
Hasta el próximo jueves.nullpointer.exception !!! (y si quieres ayudarme a difundir el conocimiento, tuitea, comparte y comenta)
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
es usted un maestro.
… en la Universidad Rey Juan Carlos. 😉
Enorme Javier
Pingback: Bitacoras.com
Suscribo esto totalmente, 100% de acuerdo. Así trabajamos todos si existe una relación cliente/proveedor. Otra cosa es si eres una empresa con equipo interno de desarrollo.
Felicidades por el post
Yo recuerdo el anterior proyecto en el que trabajé, que tenía que cumplir un pliego que Hacienda validaría. Dejamos visible el frontend para que Hacienda viese que cumplía con los requisitos (y así fue), pero por otro lado estuve más de un año trabajando con una metodología más o menos ágil (por aquel entonces desconocía su existencia) con el cliente en el despacho de al lado, con una comunicación directa y comprometido, por lo que el cliente quedó muy satisfecho cuando me fui. Hace 3 meses me llamó para decirme que había pasado a Producción y para darme las gracias por todo.
¡ Un saludo y sea bueno el sábado en el examen !
Siempre soy bueno 🙂
Se te olvidó mencionar la subvención. Lista de requisitos para cumplir con lo descrito en la subvención solicitada y fecha de entrega determinada por lo que la subvención dice. Añádele los trucos necesarios para sacarle más provecho a ese dinero gratis y tendremos un reflejo más cercano a la realidad. Al menos, a mi realidad.
Precisamente esto mismo está ocurriendo en el proyecto en el que estoy trabajando ahora mismo. El cliente redactó en el pliego una serie de mejoras que consideraba necesarias y ahora resulta que no todas se ajustan a las necesidades de los usuarios. Cuando nos reunimos con éstos para la toma de requerimientos se quejan amargamente de ello, ya que las mejoras del pliego no las consideran relevantes y por el contrario tienen otra serie de peticiones que sí lo son.
Desde la dirección del proyecto saben perfectamente que la calidad del servicio mejoraría notablemente si realizáramos las tareas que los usuarios finales nos solicitan pero estamos atados a un contrato sobre el que luego nos pedirán explicaciones por lo que todas las tareas del pliego deben estar finalizadas, sean relevantes o no.
De todas formas estamos intentando ser lo más flexible posible, si la herramienta no se ajusta a las necesidades de los usuarios finales puede que perdamos la renovación de mantenimiento del proyecto.
Por cierto, el proyecto es para la administración pública y os puedo asegurar que se podrían haber currado bastante más el pliego de prescripciones técnicas y así se habría evitado llegar a esta situación que no es la deseada ni para los usuarios ni para nosotros.
Por cierto, enhorabuena por el blog, te leo diariamente desde hace unos meses 😉
Muchos ‘por cierto’ he puesto yo para ser mi primer comentario en tu blog xD, ¿no se pueden editar los comentarios?.
Completamente de acuerdo contigo Javier. Una de las alternativas que estamos adoptando en nuestra administración para poder evitar pliegos de llave en mano es hacer un pliego de bolsa de horas donde se requiere implementar las historias de usuario que se mencionan, dejando el remanente de horas (si fuera el caso) para incorporar nuevas historias de usuario. Si al contrario faltasen horas al final del proyecto, se estudia el caso y se oferta una ampliación solo para completar las historias de usuario que faltan en aquel sprint. Los criterios de adjudicación tienen en cuenta la experiencia previa demostrable de aquellas empresas que ya han trabajado en otros proyectos scrum y que apuesten por cubrir todo el product backlog que se ofrece. Hasta ahora parece que funciona bastante bien y encaja jurídicamente con el nuevo texto refundido de la LCSP.
Un saludo y muy buena entrada.
Que buen escrito y que cierto es lo que mencionas… Gracias!
Muy buen artículo Javier, enhorabuena por el blog.
No hay que confundir un ciclo de vida con la malas prácticas de algunos roles o los vicios comerciales que los pervierten.
Lo mal que van muchos proyectos, yo lo he sufrido como casi todos, ha provocado en algunos una «sobrereacción agile» que simplifican descaradamente los errores al igualar «Cascada = Proyecto marrón», y por supuesto «Scrum = proyecto exitoso».
Las cosas por su nombre. Buen artículo, de nuevo.
Alex Ballarin
Hay de todo sí, eso de Scrum bueno lo demás malo, lo he visto mucho.
En nuestra administración sufrimos igualmente estas malas prácticas, estamos obligados por la LCSP, a usar pliegos de prescripciones técnicos. Hemos ensayado varias opciones, incluso la bolsa de horas, pero esa solución se convierte en una trampa para el contratante, “se cobra hasta por respirar delante del analista” y finalmente no se consiguen unos objetivos mínimos.
Tras muchas pruebas lo único que nos ha servido es trabajar en profundidad el pliego, en realidad no el pliego, sino un documento de especificaciones técnicas anexo al pliego, en el que tras haber realizado un pre-análisis propio, ya es posible contar una visión mucho más cercana a las necesidades de los usuarios. Y por supuesto entrar desde el principio a participar en el plan de pruebas.
Convencer a nuestros responsables de la necesidad de analizar, junto a los usuarios, las necesidades y los detalles antes de contratar es complicado. El esfuerzo por convencer y conseguir la complicidad de éstos es importante, pero cada día más vamos ganamos confianza, a la vista de mejores resultados alcanzados.
Finalmente comentar, que los que nos responsabilizamos de contrataciones software, o hacemos de todo, o el tiempo pasa y la garantía finaliza sin que el usuario haya asumido su responsabilidad en la pruebas.
Maribel,
sin duda los procedimientos de compra en las grandes empresas y la LCSP son un impedimento, más allá de allí donde se hace mal sin poder responsabilizar al procedimiento.
Jeff Shutherland está trabajando hace un tiempo en identificar como la administración podría usar contrataciones ágiles como alternativa a los pliegos grandes y férreos. En esta página muestra un informe de impedimentos, algunos comunes con los que comentas.
http://scrum.jeffsutherland.com/2012/08/gao-report-on-agile-practices-in.html
¡Saludos!
Àlex Ballarin
Cynertia Consulting
¡Muy bueno el post!
Yo creo que es muy difícil salir bien parado en tales situaciones. Se me ocurre que se debe estimar sobre los requerimientos solicitados, los que se desprenden de los primeros en forma inmediata y aclarar bien en el contrato que todo aquello que no está mencionado será analizado y presupuestado aparte. También se debe indicar que el hecho de agregar requerimientos modifica las condiciones del proyecto (tiempos y costos). De este modo se puede presentar una oferta competitiva y a la vez trabajar sin apuros innecesarios.
El problema es en gran parte por el cliente, le importa solamente el precio sin darse cuenta que a medida que se avanza siempre se quieren hacer más cosas, todos los programadores sabemos que muy pocos clientes saben exactamente lo que quieren o necesitan. Pocos clientes se dejan asesorar en ese sentido, creen que su idea es completa y no necesitan más y ya cuando hablamos de dinero la cosa se complica mucho más. Es prácticamente imposible dar un pecio «orientativo» porque no te lo aceptan (en un 98% de los casos).
Buenas, aunque coincido en lo general en el artículo, por mi experiencia (mayoritariamente en la administración pública) es la que han comentado más arriba, que existen también las ampliaciones de contrato, algo que al al tratarse de dinero suele tratar el gerente de la cuenta.
La casuística en estos casos es espantosamente enorme, y para cada ejemplo hay un contraejemplo.
No creo que el problema sea sólo por parte del cliente, pues más de una vez las empresas hacen bajas temerarias para llevarse el proyecto. Y en última instancia, haciendo una analogía, pocas personas se comprarán una barra de pan por 3€ cuando la tienen por 50 céntimos, por muy buena que te digan que es la barra de 3€. Esta parte del problema me parece difícil de atajar, salvo que el cliente haya trabajado ya con alguien y sepa cómo trabaja, aunque eso no es exclusivo de la informática, pasa en todos los trabajos.
La solución empieza porque el cliente se siente a ver qué necesita realmente, algo que en ocasiones es sencillamente imposible por el tamaño de la empresa, sigue porque las empresas no hagan planificaciones que muchas veces se ponen a sabiendas de que no se cumplirán, y no se sabe donde se acabará solucionando….
Buenos días. 100% de acuerdo. Para mi el gran problema de los contratos es que cuando hay que presupuestar un proyecto existen dos trabajos a realizar y que deberían de cobrarse independientemente. Uno es el de la consultoría/análisis del proyecto, con un pliego de especificaciones técnicas detallado. Luego, con estos documentos se debería de pedir presupuesto para el desarrollo.
A nosotros nos ha pasado que ( somos muy pequeñitos pero queremos ser serios) para hacer un presupuesto, hemos hecho una consultoría , pliego de especificaciones, diseño y presupuesto de desarrollo. El cliente ha cogido y ha dicho «Eso es muy caro». Coge la consultoría y se va a otra empresa donde ya no tienen que hacer ese trabajo.
El modelo a seguir sería el de los arquitectos. Alguien me hace el plano y la casa me la hace otra empresa.
Buenos días,
Totalmente de acuerdo, el enfoque que comentas (habitual en los arquitectos), puede ser clave para una posible mejora de la situación.
Un saludo!
PD: Por cierto Javier, muy buen blog.
Excelente post. Ese es un problema en nuestra industria por años. Muy bien explicado y es una realidad latente pero…
Como podemos solucionar esto entonces?
Se nota que es la cultura del recateo aplicada a las negociaciones de software, es decir un problema cultural, como cambiar las raíces de estos malos hábitos que impiden que se haga una buena ingeniería en los proyectos?
Excelente post! Es una descripción perfecta de lo que sucede el 99% de las veces en los proyectos.
Es difícil poder complacer a todos los involucrados, Cliente, Comercial, Desarrollador, etc.. pero estas gestiones lamentablemente generan cierto desgaste en las personas que impacta directamente en el/los proyectos, con lo cual a la larga es probable que la calidad de los productos ofrecidos sea menor, lo que entre otros aspectos puede hacer mas difícil el cumplimiento de los objetivos de la empresa y su crecimiento.
Me encanta leer tus artículos, que compartas tus conocimientos y opiniones! Así crecemos todos.
Gracias.
Saludos.
Real como la vida misma
Magnífico artículo, retrata de cuerpo entero un conjunto de concepciones, lamentablemente muy extendidas, que son la razón de muchos fracasos e inconformidades en el desarrollo de proyectos. Felicitaciones por el Post.
Magistral, formato de tu blog! ¿Cuanto tiempo llevas bloggeando? haces que leer en tu blog sea divertido. El uso total de tu web es currado, al igual que el material contenido!
Saludos
Gracias!
Excelente artículo Javier, veo que fue escrito en el 2013, y aún hoy, al menos en Argentina, 7 años después, se sigue manifestando, en menor medida pero se sigue manifestando.
Saludos