Al igual que cualquier “cosa” en el mundo de la tecnología, la “gestión de la evolución y creación” de la misma, por llamarlo de alguna manera (no se me ocurrió otra más extraña), no deja de evolucionar. No ha dejado de hacerlo nunca. Esa evolución no siempre ha ido por los mejores caminos o, quizá, lo que pasó es que aquellas maneras que en tiempos fueron más idóneas y populares… resulta que ahora, en estos tiempos, funcionan menos.
La agilidad, como idea de unos valores, una cultura y unos principios es algo ya bastante maduro (como idea digo, para dejar fuera el hacer uso de la misma, que no está al mismo nivel de madurez), demasiado hablado. No en vano, las ideas ágiles llevan aquí muchos, muchos, años. Aunque gran parte del sector se haya puesto con ellas hace relativamente poco tiempo.
Incluso aquellas primeras ideas, de hace años, sobre agilidad, sobre otras maneras de hacer las cosas, han ido evolucionando con el tiempo, se han ido madurando, han aparecido evoluciones e ideas nuevas.
Con esa evolución ha ido cambiando en el sector la mentalidad de cómo ver el Testing, como ver la relación desarrollo – Testing – operaciones, ese DevOps, plantearse el papel de las estimaciones, ese #noestimates (¿Tiene sentido estimar? Quizá no deberíamos estimar proyectos #NoEstimates), etc. Y, por supuesto, ha ido cambiando en el sector una idea que antes se escuchaba sólo en pequeños foros… la de si tienen sentido los proyectos en tecnología.
Cada vez se siente más de cerca que uno de los próximos saltos “evolutivos” en la manera de gestionar proyectos en tecnología, será la muerte del concepto “proyecto”. Entiéndeme cuando digo “próximo salto”, me estoy refiriendo para el el “gran publico”, porque la idea del problema de gestionar software por proyectos lleva aquí ya muchos años.
De hecho, si te unes a la idea no vas a ser un pionero innovador, ni aunque lo hagas desde una empresa grande, recuerda sino como hace años en Spotify incluso sacaron el eslogan de la cultura “unproject”.
La idea del peligro de enfocar todo el desarrollo, evolución y creación de tecnología por proyectos (que es lo que ha hecho, y hace, casi todo el mundo desde siempre), puedes verla desde varios ángulos.
Uno de ellos es que esconde que el verdadero foco es potenciar los equipos más que los proyectos. Si no te habías parado a pensar nunca en la diferencia de enfocarse a equipos frente a enfocarse a proyectos quizá te lleve a reflexionar sobre ello un rato. Quizá necesite más posts. Pero no es lo mismo definir proyectos (con sus Gantts, fechas inicio y fin y sus correspondientes estimaciones) y luego buscar personas para los mismos (y digo loS mismoS) que potenciar equipos que hacen cosas (que incluso, retorciendo todo para que me entiendas, esas cosas podrían ser de diferentes proyectos).
Hay quien a la anterior idea la llama “enfocarse a productos en vez de a proyectos”, pero a mí, me parece más difícil de entender y con posibilidad de caer en error, frente a “enfocarse a equipos en vez de a proyectos”.
Otra idea para entender todo este movimiento, planteamiento e ideas es que el proyecto tiene fechas, inicio y final, y eso hace que encaje de manera poco natural en algo como el software que tiene inicio… pero, entre comillas, no tiene final.
Y es por ello que la idea del #noprojects o el #beyondproyect (nombre que le puso, si no me equivoco, Allan Kelly) esté ganando cada vez más seguidores.
Si trabajas de siempre por proyectos, has caído en este post de casualidad, o no pasas mucho por este blog, quizá, después de leer lo anterior tengas ideas en la cabeza del tipo a “esto cambiaría el sector”, “pero como se factura esto”, “como puedo saber fechas de entrega”, “esto mata el modelo de negocio de las empresas que se dedican a proveer horas de desarrollador”, etc.
Casi todo lo anterior ya lo hemos hablado en post anteriores, hemos reflexionado de ello y desmitificado lo que había que desmitificar. SI no llegaste a leerlo te invito a que lo hablemos en la sección de comentarios.
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.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Hola Javier. A causa de la lectura de tu post de las lecturas de verano, llegué a esta publicación más antigua. Me hace muchísimo sentido lo que planteas; sin embargo, lamentablemente soy de aquellos que ha trabajado toda su vida profesional (8 años) orientado a Proyectos y no a Equipos.
Por lo mismo, me he quedado con las dudas que indicas en los últimos 2 párrafos. Agradeceré si nos puedes compartir los links de las publicaciones que hacer referencia a cómo se deben abordar preguntas como: “pero como se factura esto”, “como puedo saber fechas de entrega”; en el marco del #NoProjects.
Gracias y saludos desde el sur del mundo (Chile)!
Buenas!
Acabo de terminar el curso de Miríadax «Agilidad y Lean», por eso he llegado hasta este artículo.
¿Cómo se factura?¿Fecha de entrega?
Creo que simplemente tienes «X» cantidad de presupuesto y el equipo desarrolla todo lo que puede en el mínimo tiempo para obtener el mayor valor.
El cliente se fía del equipo de desarrollo y … fin. 🙂
» algo como el software que tiene inicio… pero, entre comillas, no tiene final.»
Cuando el cliente tiene lo que quiere o quería hay un final ¿No?. Y lo que viene después se llama mantenimiento y se factura por horas o paquetes. O ampliación si quiere más.
¿No serviría está forma de ver las cosas para seguir haciendo proyectos sin ser oscuro ni rasgarse las vestiduras?
Sí desarrollas electrónica e incluye hardware + firmware + software (app/web) ¿Al entregar algo físico como en la construcción ya puedo llamarlo proyecto?