¿El fin de la Ingeniería de Software como la conocemos?

🧠 ¿El fin de la Ingeniería de Software como la conocemos?

Hace unos días mi amigo Jorge Abad publicó en sus Lecciones Aprendidas un artículo premonitorio, se trata de su De lo complejo a lo simple: Cómo la IA está reinventando el desarrollo de software. En este, Jorge sostiene que la llegada de la inteligencia artificial ha transformado el proceso de desarrollo de software, llevando ciertas tareas de un entorno de alta complejidad –como era tradicionalmente– a un dominio en el que, gracias a la automatización, se puede hablar de mayor simplicidad. Invoca el marco de Cynefin, de Dave Snowden, para clasificar los problemas en simples, complicados, complejos o caóticos, y sugiere que, con la IA, el desarrollo se mueve hacia lo “simple” o al menos hacia lo “complicado” y predecible.

Pueden leer el artículo completo aquí:

Lecciones Aprendidas por Jorge Abad: De lo Complejo a lo Simple: Cómo la IA Está Reinventando el Desarrollo de Software

El artículo sirvió de base para una sesión de Castor sin filtro (del viernes 12 de abril de 2025) con Juan Andrés Ochoa y compañía, donde discutimos animadamente el asunto. Uno de mis puntos de debate fue otra presentación también de hace pocos días de Jan Bosch, director del Software Center, una colaboración estratégica financiada por socios entre más de 15 grandes empresas europeas (incluidas Ericsson, Volvo Cars, Volvo Trucks, Saab Defense, Scania, Siemens y Bosch) y cinco universidades centradas en la digitalización, que diera en The Future of Software Conference celebrada en Londres y donde expuso sus ideas sobre el estado actual y futuro de la ingeniería de software, destacando la rápida evolución de la ingeniería de software y del mundo en general.

Pueden ver la conferencia de Bosch en

The end of Software Engineering (as we know it) | Jan Bosch | Chalmers University of Technology

Pero antes de contarles en qué estoy de acuerdo con Bosch y en qué no, haré un resumen sucinto de su charla. Bosch contrasta el modelo tradicional de ingeniería de software —basado en requisitos, diseño, codificación y despliegue (que suena a cascada)— con una nueva dinámica donde los agentes de IA interpretan intenciones humanas, las traducen en requisitos, arquitecturas y código, reduciendo drásticamente el rol humano en la programación directa. Empresas como la alemana con la que Bosch trabajó ya han reemplazado desarrolladores por arquitectos de software que dirigen agentes de IA.

Bosch critica fuertemente la eficacia actual de la ingeniería de software. Con datos empíricos, aunque antiguos, afirma que entre el 50 % y 66 % de las funcionalidades desarrolladas nunca se usan, representando un despilfarro enorme. Esto era cierto hace más de dos décadas y una observación heurística nos puede mostrar que sigue siendo así o peor. Más grave aún: entre el 70 % y 90 % del presupuesto de I+D se destina a funcionalidades commodity que los clientes dan por sentadas. Bosch ilustra el problema con su modelo de tres capas: funcionalidad commodity, diferenciadora e innovadora. La mayor parte del esfuerzo se destina a la primera, con poco impacto en valor.

La causa central de esta ineficiencia, según Bosch, es la dependencia de "requisitos" en lugar de "resultados deseados". Propone una transición hacia un modelo basado en resultados cuantificables, donde cada funcionalidad se justifique por su impacto en KPI de negocio. Modelos como HYPEX y técnicas como el A/B testing permiten medir el impacto de pequeños incrementos funcionales antes de invertir completamente en ellos.

En paralelo, Bosch propone una madurez progresiva hacia organizaciones guiadas por IA. Describe cinco niveles: desde el uso puntual de herramientas como ChatGPT, pasando por la automatización de procesos, hasta organizaciones completamente rediseñadas con un enfoque "AI-first", donde agentes superan en productividad a equipos humanos enteros. En productos también se refleja esta transformación. Las etapas van desde el uso de IA como soporte, hasta productos completamente autónomos y autorregulados mediante aprendizaje por refuerzo.

Finalmente, concluye que la ingeniería de software actual es poco efectiva y necesita una reinvención radical. Reemplazar requisitos por resultados y adoptar la IA tanto en el producto como en el proceso de desarrollo son, para él, pasos imprescindibles. Más allá del entusiasmo técnico, Bosch hace un llamado a que ingenieros, Product Managers y líderes organizacionales asuman con responsabilidad esta transición urgente.

Puntos de acuerdo

1. El modelo tradicional está quedando atrás

Bosch argumenta que la cadena tradicional —donde se parte de los requisitos para llegar al despliegue— resulta insuficiente ante la velocidad y la incertidumbre del mercado actual.

Acuerdo: Es evidente que en muchos entornos, el enfoque lineal ya no permite responder de manera ágil a los cambios en los requerimientos del negocio ni a la complejidad de los sistemas modernos. De hecho, hace muchos años dejamos de hacerlo así en pro de un enfoque iterativo e incremental, de experimentación y prototipado rápido.

2. La revolución de la inteligencia artificial

La irrupción de herramientas y agentes inteligentes en el desarrollo de software abre la puerta a automatizar tareas que antes eran exclusivamente humanas.

Acuerdo: La utilización de LLM, agentes especializados y técnicas de aprendizaje por refuerzo ya está transformando la manera en la que concebimos el desarrollo, mejorando la eficiencia y permitiendo experimentar con nuevos modelos de negocio. En este sentido ver el artículo Experimentum Entre la eficiencia y el despojo: La inevitable mutación del desarrollo de software por la IA en el que analizo el más reciente reporte DORA sobre el impacto de la Gen AI en el desarrollo de software.

3. Desperdicio de funcionalidades

Según Bosch, una gran parte de las funcionalidades desarrolladas acaba siendo infrautilizada, lo que implica un desperdicio considerable de recursos.

Acuerdo: La realidad en muchas empresas respalda este punto: se invierte tiempo y dinero en features que, en última instancia, no aportan el valor esperado al cliente.

4. El cambio de requisitos a resultados

El enfoque en resultados de valor —o como les gusta a muchos: “outcomes”—, más allá de cumplir con un conjunto predefinido de requisitos, representa un cambio de paradigma fundamental.

Acuerdo: En un mundo donde la agilidad y la medición de impacto son esenciales, orientar el desarrollo hacia objetivos medibles permite alinear mejor las inversiones de I+D con los resultados de negocio.

5. La necesidad de una Ingeniería de Software madura

La transformación digital exige una mayor integración entre tecnología y negocio, elevando el rol de la ingeniería de software a un nivel estratégico.

Acuerdo: La apuesta por modelos iterativos, basados en la experimentación y en la medición de resultados clave, es una tendencia que ha demostrado su eficacia en empresas líderes.

Puntos de desacuerdo o matización

1. La desaparición del código humano

Bosch sugiere que pronto los agentes de IA podrían eliminar la necesidad de codificar manualmente.

Desacuerdo: Aunque la automatización avanza, los agentes aún carecen de un entendimiento profundo del contexto y las implicaciones éticas o sistémicas, por lo que el juicio humano sigue siendo crucial, especialmente en aplicaciones complejas y reguladas.

2. Transformación del rol del ingeniero

El discurso de Bosch tiende a minimizar el rol de los desarrolladores tradicionales.

Matización: Más que desaparecer, el rol del ingeniero se transformará. Los profesionales pasarán a actuar como orquestadores, validadores y supervisores de sistemas automatizados, aportando su criterio en áreas como la ética algorítmica y la experiencia de usuario.

3. Subestimación de los factores culturales y organizacionales

El cambio hacia modelos AI-first implica no solo una actualización tecnológica, sino también una revolución cultural en las empresas.

Desacuerdo: La resistencia al cambio y la necesidad de transformar estructuras organizativas son aspectos complejos que requieren una adaptación gradual y el compromiso de todos los niveles jerárquicos.

4. Enfoque exclusivamente económico

Medir el éxito de cada sprint en términos estrictamente económicos puede resultar reduccionista.

Matización: es muy importante cuantificar el retorno de inversión, pero también debemos tener en cuenta intangibles como la experiencia de usuario, la reducción de la deuda técnica y el aprendizaje continuo, que a largo plazo generan valor y competitividad.

5. Un discurso algo alarmista

La crítica a la “atrocidad” en la eficacia de la ingeniería actual puede resultar desalentadora para quienes trabajamos día a día en mejorar procesos y productos.

Desacuerdo: Aunque es vital reconocer las ineficiencias existentes, es igualmente necesario reconocer los avances que ya se han conseguido y fomentar una cultura de mejora continua, donde los retos se aborden de forma colaborativa y constructiva.

Mis conclusiones

Han pasado dos décadas desde que publiqué mis dos primeros libros Asuntos de la Ingeniería de Software Volumen I y Volumen II, pero tanto el artículo de Jorge, como la presentación de Bosch nos desafían a repensar la forma en que concebimos y practicamos la ingeniería de software. Sus propuestas, basadas en el aprovechamiento de la IA y en el enfoque en resultados, ofrecen una hoja de ruta para transformar radicalmente el sector. Sin embargo, la implementación de estos cambios debe considerar cuidadosamente la responsabilidad permanente del factor humano, la complejidad de las transformaciones culturales y la necesidad de una visión equilibrada que vaya más allá de los criterios económicos.

Comparto la urgencia de evolucionar hacia modelos más ágiles y eficientes, que resuelvan los problemas actuales y futuros de los usuarios (y clientes) y que solucionen de una vez por todas y para siempre los males del mundo, de lo contrario habremos fallado como humanidad; pero también reconozco que la innovación debe ir acompañada de un enfoque pragmático y humano, así que aún debemos afinar la integración de la IA en nuestra práctica diaria para convertirla en ese continuum que necesitamos y no solo reaccionar a los picos virales (“hype”) a los que nos tienen acostumbrados como este último de la “ghiblilización” o el anterior de DeepSeek.

Seguiré creyendo que el inminente final de la ingeniería de software tal como la conocemos no es un cierre, sino el amanecer de una era donde la perspicacia humana se fusionará con la inteligencia artificial: ya no escribiremos software, esculpiremos futuros, transformando lo imposible en nuestra nueva realidad digital. ¿Qué opinas? Déjamelo saber en el foro.

La sobrecarga de la IA: Entre el hype, la desinformación y la infoxicación

 

Atención es todo lo que necesitas. Parece algo de sentido común y además algunos sabrán exactamente a qué me refiero con esa expresión. IA es la sigla del momento y con toda la razón. Era lo que estábamos esperando, algunos de nosotros incluso desde hace décadas.

Pero lo que está ocurriendo es arrollador. Si estás leyendo esto seguramente también estás siendo bombardeado vía redes sociales con titulares como:

“70 ChatGPT prompts para optimizar tu perfil de LinkedIn”

“7000+ cursos de IA GRATIS. ¡Accede ahora!”

“30+ Cheat Sheets definitivas para dominar la IA”

“37 ChatGPT prompts poderosos para ayudarte”

“28 prompts that can save you thousands of dollars”

“20 habilidades de aprendizaje con ChatGPT”

 “La IA no te reemplazará, pero quien sepa usarla SÍ”

También están las llamadas “Cheat Sheets”, infográficos con docenas o cientos de formas, conveniencias, modos, maneras, condiciones, conductas, procederes y tácticas para hacer las cosas con IA. Imágenes extremadamente complejas para el ser humano convencional. (Regresar a ver la portada).

Y no es ciencia ficción. Es nuestra realidad diaria en el mundo digital. La inteligencia artificial (que, a propósito, en español se escribe con minúsculas) está en boca de todos y, lo que es más preocupante, en las publicaciones de todos. ¡Los números son realmente descomunales!

No se trata de que la IA sea una moda pasajera. Es una revolución en marcha, una de las más impactantes de nuestra era, sino la más. Pero la forma en que se nos está vendiendo es, por decirlo de alguna manera, abrumadora. No es que haya 3 herramientas útiles para mejorar tu productividad, sino 50. No son 5 estrategias, sino 1000+. No se trata de aprender con calma, sino de devorar cantidades monumentales de información, como si el simple acto de consumir nos volviera expertos.

La Infodemia de la IA

La sobreexplotación del discurso sobre la IA tiene un efecto claro: genera ansiedad. La avalancha de información, consejos, cursos, prompts, plugins y "secretos" produce un efecto contrario al deseado. En vez de empoderarnos, nos paraliza.

Algunos amigos me han confesado que no pueden dormir debido a ello. Si eres un CEO o similar seguramente tu nivel de estrés haya sobrepasado máximos históricos. Muchos se sienten abrumados, incapaces de ponerse al día con la marea de supuestos conocimientos imprescindibles. La paradoja es evidente: el exceso de información produce desinformación. Con cada nueva "cheat sheet", con cada "curso definitivo", con cada "descubrimiento revolucionario", con cada nueva versión del chatbot de la semana, el usuario promedio queda atrapado en un círculo vicioso de aprendizaje sin aplicación real.

La falacia del experto instantáneo

El otro gran problema es la proliferación de "gurús de la IA". LinkedIn, X y mucho de la Internet que transitamos están plagadas de autoproclamados expertos quienes parecen haber descubierto el Santo Grial de la inteligencia artificial.

¿Han probado las herramientas que promocionan? ¿Han seguido alguno de los procesos que proclaman? ¿O simplemente están repitiendo lo que vieron en otro post viral? Yo no lo sé de cierto, lo supongo. La IA, como cualquier otra disciplina, requiere estudio, experimentación y un profundo conocimiento del contexto. No se trata de memorizar "los 42 prompts definitivos", sino de comprender cómo y por qué funcionan.

Cómo sobrevivir a la sobrecarga de IA

Ante este tsunami informativo propio de tabloides más que de ciencia e ingeniería, te quiero dar algunos consejos esenciales:

1.      Ve a tu ritmo: No intentes absorberlo todo en un día. La IA es una herramienta poderosa, pero su dominio requiere tiempo. Evita los cursos "exprés" que prometen convertirte en experto en "3 minutos al día".

2.      Acompáñate de verdaderos expertos: Busca mentores que hayan recorrido el camino antes que tú, que puedan guiarte con conocimiento real y no con humo digital.

3.      No te agobies: Siempre habrá alguien más adelante y alguien más atrás. Aprende de los primeros y ayuda a los segundos. La IA no es una competencia de velocidad; es una carrera de fondo.

4.      Filtra el contenido con criterio: En un entorno sobresaturado de información, aprender a discriminar fuentes confiables de aquellas que solo buscan generar clics y engagement es crucial. Pregúntate: ¿esta información proviene de una fuente académica o empresarial con respaldo? ¿El contenido tiene profundidad o solo repite lo que otros dicen?

5.      Evita el FOMO (miedo a quedarse atrás): La IA avanza rápido, sí, pero la presión por estar siempre actualizado puede ser contraproducente. Define tu propia cadencia de aprendizaje y enfócate en aquello que realmente aporte valor a tu crecimiento personal y profesional.

Llamado a la acción

El ritmo con el que se está propagando la información sobre IA es avasallador, intimidante, abusivo y, en muchos casos, irresponsable. Quizás nunca estemos a la vanguardia, pero la pregunta es: ¿realmente quieres estarlo?

Piensa en ello antes de dar clic en la próxima lista de "100 herramientas de IA que cambiarán tu vida". Quizás lo que realmente cambie tu vida sea aprender a priorizar lo que importa y avanzar con pasos firmes, en vez de correr sin rumbo en una maratón sin fin.

Del caos a la sinfonía: Armoniza a tu equipo antes de que todo suene mal

Del caos a la sinfonía: Armoniza a tu equipo antes de que todo suene mal

Durante 37 años he trabajado con o acompañado a cientos de equipos y miles de personas y he tenido la oportunidad de crear con ellos productos asombrosos. Incluso he escrito y publicado libros en los últimos 15 años, una operación que siempre se logra colaborando en equipo. Es bastante satisfactorio cuando entregas al público algo en lo que has sido minucioso y le has dedicado buena parte de tus mejores momentos.

Pero también he estado allí cuando las cosas no han salido bien. No es solo tu desilusión, es la de todo un grupo de personas que se han desempeñado de la mejor manera posible para lograr un objetivo y no ha sido posible. He estudiado mucho este fenómeno de cuando las cosas no terminan bien para un equipo o para una empresa. Después de todo, las heridas físicas y hasta mentales causadas por estas caídas saltan a la vista.

Precisamente, una de las causas más frecuentes, casi endémicas, de tales decepciones es esta de la desalineación de los equipos. Y voy a empezar a explicarte de qué se trata con un ejemplo muy común. Es como cuando intento llevar a cabo un plan de salir a cenar con mi esposa y mi hija. Parece algo sencillo, ¿cierto? ¡No te apresures!

He estado en medio de ambas cuando una lleva soñando toda la semana con comida italiana mientras la otra quiere sushi porque es más digno de Instagram. Yo, en cambio, solo quiero un buen bistec porque he tenido una larga semana y necesito algo más sustancioso. En el debate emergen argumentos de que los ñoquis son un alimento reconfortante, pero hay un contraataque diciendo que el sushi es más ligero y saludable. Ni hablar de cuando trato de ser el pacificador sugiriendo un restaurante de carnes con opciones de sushi, porque te dicen: “¡Eso no cuenta como sushi de verdad!”.

Esto es esencialmente un desajuste de equipo en su forma más evidente. Todos compartimos el mismo objetivo general (cenar juntos), pero las diferentes perspectivas (comida reconfortante versus comida de moda versus comida saludable), objetivos específicos disímiles (satisfacer antojos versus comidas dignas de Instagram) y alcances discordantes (satisfacción inmediata versus experiencia culinaria) convierten todo en un caos.

¿Les suena familiar? Este tipo de desajustes ocurren todo el tiempo en los equipos y, si no se resuelven, pueden hacer que hasta las tareas más sencillas resulten agotadoras. Por suerte, al igual que en mi familia, un poco de empatía, alineación y compromiso pueden salvar el día y tal vez incluso llevar a descubrir el mejor restaurante de cocina fusión de la ciudad.

Tres formas de desalineación en los equipos

Mi historia de la cena malograda captura la esencia de los desajustes que a menudo vemos en los equipos: perspectivas diferentes, objetivos diferentes y alcances diferentes.

Diferentes perspectivas: el “elefante en la habitación”

Surgen diferentes perspectivas porque cada uno tiene su propio "enfoque" moldeado por experiencias, conocimientos y prejuicios personales. Esta es la clásica historia de los ciegos que describen un elefante: uno siente la trompa y dice que es una serpiente, otro agarra la pata y afirma que es un árbol, mientras que el que toca la cola piensa que es una cuerda. Todos tienen razón, pero no están alineados.

Este tipo de desalineación se caracteriza principalmente por:

·       Opiniones contradictorias a pesar de datos compartidos.

·       Desafíos para comprender “por qué” alguien lo ve de manera diferente.

·       Con frecuencia una fuente de frustración es: "¡¿Cómo es posible que no lo entiendan?!"

Es un hecho, las personas estamos programadas para interpretar las situaciones en función de nuestra experiencia y función. Un programador se centra en el código, mientras que alguien de mercadeo ve el impacto en el cliente. Ninguno de los dos está equivocado, pero ambos carecen de una visión completa. Es lo que alguna vez llamé “dicotomía peyorativa”. ¡Todavía recuerdo aquella reunión!

Diferentes objetivos: el tira y afloja

Se presentan distintos objetivos cuando los miembros del equipo priorizan diferentes resultados. ¿Recuerdan lo del sushi o la comida italiana? Es así. No se puede complacer a todo el mundo, a menos que se encuentren puntos en común. Los equipos se enfrentan al mismo tira y afloja cuando los individuos o los grupos tienen objetivos contrapuestos.

Lo que he visto que ocurre incluye:

·       Desacuerdos sobre lo que es "más importante".

·       Prioridades mal alineadas conducen a un desperdicio de energía.

·       La gente tira en direcciones opuestas, por ejemplo: “¡Necesitamos velocidad!” versus “¡Necesitamos calidad!”.

De primerísima mano sé que los objetivos están influenciados por los roles de los miembros del equipo, los incentivos y las definiciones individuales de éxito. Sin una visión compartida, las prioridades personales se imponen. He visto Product Owners presionando para que se lance un producto rápidamente, mientras que el equipo de desarrollo aboga por que se realicen más pruebas. Es el clásico debate de "rápido versus impecable".

Diferentes alcances: el efecto zoom

Los alcances definen cuán estrecha o amplia es nuestra perspectiva de una situación. He conocido personas que se obsesionan con los pequeños detalles mientras que otras los desestiman como si "no fueran gran cosa". De hecho, ahora que lo pienso, yo mismo he estado en ambos lados del disco. Los equipos experimentan esto cuando los individuos operan en diferentes "niveles de zoom": algunos piensan estratégicamente, otros tácticamente.

Eso es una desalineación del alcance. Si te has encontrado con algunas de estas escenas, también has estado allí:

·       Alcance limitado: "Vamos a solucionar este error".

·       Amplio alcance: "¿Cómo encaja esto en nuestro roadmap anual?"

·       Tensiones entre la corriente o dirección táctica y la estratégica del equipo o de la empresa.

El alcance también depende de las prioridades y la responsabilidad. Un desarrollador tiene la tarea de solucionar el problema de hoy, mientras que el CEO tiene en mente la participación de mercado del próximo año.

¿Y la solución?

Tengo que admitir que soy mejor resolviendo desajustes de equipos de trabajo que los emocionantes y románticos conflictos  familiares tipo sushi versus espagueti. Igual me divierto con estos y me hacen muy feliz.

Pero primero buscamos la causa raíz. ¿Qué tienen en común estos tipos de desalineación de equipos? En general, se deben a:

·    Brechas en la comunicación: con frecuencia, las suposiciones reemplazan las conversaciones reales.

·   Falta de contexto compartido: las responsabilidades y la experiencia de las personas determinan lo que consideran relevante.

·    Naturaleza humana: somos naturalmente centrados en nosotros mismos y se necesita esfuerzo para ver más allá de nuestra propia perspectiva. Esta es la raíz más compleja de todas.

Hay más orígenes, pero estos son los más comunes. En ocasiones, vas a necesitar acompañamiento para resolver estos trances, pero para ir del caos a la cohesión puedes empezar:

Creando un entendimiento compartido: incentiva a las personas a compartir sus perspectivas abiertamente. Ayuda a que todos vean el problema en su conjunto, no solo sus partes. Por ejemplo, en las reuniones, utiliza la regla “¿cuál es tu opinión?”, donde cada uno comparte su punto de vista antes de llegar a las conclusiones.

Alineándolos en torno a un objetivo común: facilita debates para identificar objetivos compartidos. Una "estrella del norte" sólida alinea las prioridades en pugna. Aquí, por ejemplo, los OKR (objetivos y resultados clave) juegan un papel fundamental para que los objetivos finalmente sean explícitos y visibles para todos.

Aclarando los alcances: aumenta y reduce la perspectiva entre todos. Analiza las prioridades inmediatas (logros a corto plazo) y cómo se relacionan con los objetivos más extensos (visión a largo plazo). Y,

Fomentando la empatía: adquiere el hábito de tener en cuenta las responsabilidades y las prioridades de los demás. Esto disminuye los juicios y fomenta la colaboración. Me ha ido bien con las dinámicas tipo “ponerse en los zapatos del otro” durante las retrospectivas o en cualquier otra sesión necesaria.

Aplico algunas de estas prácticas con mi esposa y mi hija cuando se trata de salir a divertirnos o decidir dónde cenar. En la historia que les compartí, después de un entretenido tira y afloja, ¡terminamos eligiendo comida de mar! Es algo que conecta con nuestras raíces y que siempre nos ayuda a encontrar un punto en común. Si esto es posible en mi familia—donde las decisiones a veces parecen un cónclave de las Naciones Unidas—créanme, también es posible alinear a tu equipo de trabajo.

Llamado a la acción

No es más por esta vez. Los desajustes son naturales, pero no insalvables. Fomenta la comunicación abierta, la alineación en torno a objetivos armónicos y el equilibrio de alcances. Con esto, los equipos pueden transformar la fricción en combustible. Ya sea que se trate de una sencilla cena familiar o de un proyecto de trabajo, la magia ocurre cuando todos reman en la misma dirección. Y, si todo lo demás falla, ¡siempre hay hamburguesas para cenar!

Planificación empírica de productos

 

Mi serie de artículos sobre los errores de los [nuevos] Scrum Masters despertó interés en algunos otros temas. La cuestión más recurrente que me llegó fue esta de la planificación empírica de productos. Es un descuido común. Lo decía en el primero de los tres artículos, mismo que encuentras aquí:

Siete errores comunes de los nuevos Scrum Masters al servicio de los Product Owners – Lucho Salazar

Pues bien, sobre este asunto ya escribí hace algunos años, así que para entenderlo mejor, empieza por aquí:

Nuestro Scrum empírico de todos los días - Gazafatonario IT

Específicamente, establecer una planificación empírica de productos para un entorno complejo significa tomar decisiones relacionadas con el producto basadas en datos, observaciones y evidencias reunidas a lo largo del proceso de desarrollo, en lugar de confiar en suposiciones, planes a largo plazo o predicciones. Y una advertencia en este apartado: hay que ser cuidadosos con ese “a lo largo del proceso de desarrollo”. En ocasiones no es bueno ir tan atrás.

En entornos complejos, donde las condiciones del mercado, las preferencias de los clientes y la tecnología cambian rápidamente, raya en lo imposible predecir con certeza qué le dará más valor al producto. Es allí donde aprovechamos el enfoque iterativo e incremental de Scrum para hacer planificación empírica de productos, recopilando retroalimentación con frecuencia y adaptándonos en función de lo que observamos y aprendemos.

Trataré de dilucidar al respecto.

Paso a los entornos complejos

Ya basta de Cynefin o de cualquier otro modelo que intente explicar los distintos entornos donde nos movemos. En la práctica, un entorno complejo se caracteriza por la gran cantidad de variables y factores desconocidos con las que los equipos lidian al intentar predecir de manera confiable el mejor curso de acción. Ejemplos de esto incluyen:

·       Tendencias de mercado cambiantes.

·       Necesidades inciertas de los clientes.

·       Evolución de la competencia o cambios regulatorios.

·       Avances tecnológicos rápidos.

En escenarios de esta clase, los planes a largo plazo basados en supuestos fijos no arrojan los resultados esperados. El éxito del producto depende de un aprendizaje constante vía experimentación, retroalimentación y adaptación.

Implicaciones de la planificación empírica de productos

La planificación empírica de productos requiere de transparencia, inspección y adaptación: los tres pilares de Scrum.

Transparencia: todos los involucrados en el desarrollo del producto tienen visibilidad sobre el progreso, los riesgos y el estado del trabajo. Esto requiere que los elementos del Product Backlog estén claros y actualizados, así como una comunicación continua.

El Product Backlog es compartido abiertamente y visible para todos los interesados. Alguien como el Product Owner lo actualiza regularmente en función de los últimos datos proporcionados por los usuarios, el mercado, regulaciones o descubrimientos técnicos. Ese 50 % del tiempo que el Product Owner no pasa con el equipo, lo debe transitar en el entorno del producto. Indaga. Profundiza. Se proyecta. Se anticipa, por ejemplo, a asuntos regulatorios por venir.

Inspección: todo el equipo, especialmente el Product Owner con ayuda del Scrum Master, inspecciona con regularidad el producto y el progreso hacia los objetivos. Recopilan retroalimentación con frecuencia a través de Sprints de corta duración, revisiones y pruebas.

Por ejemplo, al final de cada Sprint, el equipo Scrum revisa el trabajo completado y busca la retroalimentación del cliente. Además, inspeccionan métricas como el compromiso de los usuarios, los datos de rendimiento del producto en producción o las funcionalidades más usadas, entre otras.

Adaptación: en función de las observaciones durante las inspecciones, los equipos adecúan sus planes, prioridades y enfoques. En lugar de seguir una hoja de ruta fija, se ajustan para reflejar nuevos conocimientos. Es cuando la “magia” ocurre. Por ejemplo, si el Product Owner nota una disminución en el compromiso de los usuarios, con el equipo ajusta el Product Backlog, priorizando funciones que mejoren la experiencia del usuario en lugar de seguir el plan ya establecido.

Planificación empírica de productos en acción

En la planificación empírica de productos no creamos planes elaborados a largo plazo. En cambio, usamos un enfoque de onda continua, donde proyectamos en detalle para los dos o tres sprints siguientes a la vez que mantenemos el trabajo futuro flexible.

También hacemos planificación empírica cuando, en lugar de construir una funcionalidad basada en suposiciones sobre el comportamiento del usuario, lanzamos una versión básica después de uno o dos Sprints. A partir de allí, observamos cómo los usuarios interactúan con ella, aprendemos qué funciona y qué no y ajustamos los planes futuros.

Además, cuando adoptamos una mentalidad donde las funciones y mejoras son realmente experimentos, estamos haciendo planificación empírica de producto. Establecemos hipótesis, las probamos rápidamente y utilizamos los resultados para guiar nuestras próximas decisiones. Después de todo, de eso se trata el “ser” ágil: de experimentar.

Las cosas así, los beneficios no se hacen esperar. Mitigamos riesgos, porque evitamos perder tiempo y recursos en funciones que no aportan valor. Nos centramos en el cliente, ya que los ciclos frecuentes de retroalimentación aseguran que el producto esté en constante evolución para satisfacer sus necesidades. Y somos flexibles, esto es, respondemos rápidamente a cambios en el mercado o nuevas oportunidades.

La responsabilidad del Scrum Master en la planificación empírica de productos

No hay otra forma de decirlo: el Scrum Master debe asegurarse de que el Product Owner y el equipo en pleno adopten la planificación empírica de productos. Este es el quid de la cuestión.

·       Fomenta ciclos de planificación más cortos: promueve pequeños pasos incrementales en lugar de planes a largo plazo.

·       Facilita los ciclos de retroalimentación: se asegura de que las Sprint Reviews sean significativas y conduzcan a ideas accionables.

·       Enseña pensamiento adaptativo: ayuda al Product Owner y al equipo a centrarse en la toma de decisiones basada en evidencias, en lugar de planes rígidos basados en antojos o cábalas.

·       Impulsa la inspección y adaptación: facilita que el equipo e interesados inspeccionen el progreso con regularidad y adapten su enfoque según lo que aprenden.

Pensamiento final

Solo quiero enfatizar que el desempeño pasado no es garantía del desempeño actual y mucho menos de futuro. Son solo eso, predicciones, pronósticos, hipótesis en el mejor de los casos, unas fallarán, otras no.

Es un hecho, la cantidad de incertidumbre en un pronóstico aumenta a medida que miras hacia el futuro. Perentorio.

Tres cosas que se necesitan para ser un líder ágil y lean estratégico

Evidencia tres de los principios que todo líder ágil y lean estratégico debe dominar para guiar a su organización en tiempos de cambio y complejidad. Inspirado en la visión transformadora de Satya Nadella, estos pilares de claridad, energía colectiva y soluciones creativas son la clave para liderar con impacto y conectar propósito y quehacer en cada decisión.

[Nuevo artículo] en Experimentum.

Tres cosas que se necesitan para ser un líder ágil y lean estratégico | Experimentum - LinkedIn