Sebastián Lendínez, Author at MTP España

En cualquier proyecto digital se toman decenas de decisiones cada semana: Aprobar o aplazar un despliegue. Priorizar una incidencia. Aceptar un riesgo. Modificar el alcance. Validar una entrega. Determinar si una aplicación está preparada para producción. Aunque estas decisiones suelen abordarse en comités de seguimiento y reuniones técnicas aparentemente basadas en datos, las personas no siempre analizamos la información de manera completamente objetiva. Nuestras conclusiones también están condicionadas por experiencias previas, expectativas, presiones organizativas y atajos mentales. Estos mecanismos reciben el nombre de sesgos cognitivos. Idea clave En un proyecto digital, una decisión basada en una interpretación incompleta puede generar retrasos, sobrecostes, deuda técnica, defectos en producción o pérdida de confianza. Desde una perspectiva de Quality assurance, mejorar la calidad de las decisiones es tan importante como garantizar la calidad del producto digital. ¿Qué es un sesgo cognitivo? Un sesgo cognitivo es una desviación sistemática en la forma en la que una persona interpreta la información, evalúa una situación o toma una decisión. Nuestro cerebro utiliza atajos mentales para procesar rápidamente una gran cantidad de información. Estos atajos son útiles, pero también pueden llevarnos a: Conceder demasiada importancia a ciertos datos. Ignorar información que contradice nuestras expectativas. Sobrevalorar experiencias recientes. Seguir la opinión mayoritaria sin cuestionarla. Mantener decisiones que ya no se ajustan a la realidad. Un sesgo cognitivo no implica falta de conocimientos o capacidad. Los profesionales más experimentados también pueden verse afectados, ya que la experiencia genera patrones, expectativas y respuestas automáticas. Sesgo cognitivo y distorsión cognitiva: ¿son lo mismo? Aunque están relacionados, son conceptos diferentes. ConceptoDefiniciónÁmbito habitualSesgo cognitivoTendencia sistemática que influye en la interpretación de información y en la toma de decisiones.Decisiones personales, profesionales y organizativas.Distorsión cognitivaPatrón de pensamiento exagerado o poco ajustado a la realidad.Percepción personal y emocional. En términos sencillos, los sesgos cognitivos ayudan a explicar por qué podemos tomar decisiones poco objetivas, mientras que las distorsiones cognitivas están más relacionadas con cómo interpretamos emocionalmente una experiencia. ¿Cuántos sesgos cognitivos existen? No existe una cifra única y universalmente aceptada. Dependiendo de cómo se clasifiquen, algunos modelos recogen más de un centenar. En los proyectos digitales no es necesario memorizar todos los tipos de sesgos cognitivos. Lo importante es reconocer aquellos que pueden afectar a: La estimación y la planificación. La evaluación de riesgos. El análisis de incidencias. La priorización del backlog. La elección de soluciones técnicas. La validación de entregas. La interpretación de métricas. La aprobación de despliegues. Principales sesgos cognitivos en proyectos digitales 1. Sesgo de anclaje Cuando la primera información condiciona el análisis El sesgo de anclaje aparece cuando una persona o un equipo concede demasiado peso a la primera información recibida. Puede manifestarse en: Una estimación inicial de esfuerzo. Una fecha comprometida al comienzo del proyecto. La primera hipótesis sobre una incidencia. Una valoración preliminar de un riesgo. Un presupuesto calculado con información limitada. Ejemplo Una incidencia crítica comienza a investigarse bajo una hipótesis inicial incorrecta. Aunque aparecen evidencias que apuntan a otro componente, el equipo continúa centrando el análisis en la primera explicación. La Ingeniería de requisitos ayuda a reducir este riesgo al transformar necesidades, restricciones y supuestos en requisitos explícitos, verificables y trazables. 2. Sesgo de confirmación Buscar pruebas de que tenemos razón El sesgo de confirmación consiste en valorar principalmente la información que refuerza una creencia previa e ignorar los datos que podrían contradecirla. En proyectos tecnológicos aparece cuando: Se intenta demostrar que una solución funciona, en lugar de comprobar cómo podría fallar. Se seleccionan únicamente métricas favorables. Se interpretan resultados ambiguos como una validación. Se descartan opiniones críticas. Se prueban únicamente los flujos esperados. Las pruebas funcionales permiten combatir este sesgo al verificar tanto el comportamiento esperado como las condiciones en las que el sistema podría incumplir los requisitos. Pregunta para el comité ¿Qué evidencia demostraría que nuestra hipótesis es incorrecta? 3. Conformidad grupal Confundir silencio con consenso La conformidad grupal aparece cuando los participantes priorizan la armonía del equipo o evitan contradecir a perfiles con mayor autoridad. Suele producirse cuando: Las opiniones de los perfiles sénior tienen un peso excesivo. La persona que dirige la reunión expresa primero su posición. Existe presión por alcanzar un acuerdo rápido. El desacuerdo se interpreta como un conflicto. Los participantes creen que sus aportaciones no serán valoradas. El resultado es una falsa sensación de consenso que puede ocultar riesgos importantes. Un QMO puede reducir este problema mediante procedimientos de gobernanza, criterios objetivos y puntos de control independientes de la opinión dominante. 4. Sesgo de autoridad Aceptar una propuesta por quién la expresa Este sesgo se produce cuando una afirmación obtiene mayor credibilidad por la posición, experiencia o prestigio de la persona que la formula. Puede suceder cuando una decisión procede de: La dirección del proyecto. Un arquitecto de software. Un proveedor estratégico. Una persona experta. El perfil con mayor antigüedad. Un cliente con gran capacidad de influencia. La experiencia aporta valor, pero no sustituye a las evidencias. Cómo reducirlo Recoger las opiniones antes de que hable la dirección. Utilizar votaciones preliminares anónimas. Solicitar que cada propuesta incluya datos y riesgos. Aplicar los mismos criterios de evaluación a todas las alternativas. 5. Sesgo de disponibilidad Sobrevalorar lo reciente o memorable Este sesgo nos lleva a considerar más probable aquello que recordamos con facilidad. Después de una caída de producción, por ejemplo, un comité puede destinar demasiados recursos a evitar que se repita exactamente el mismo problema. En sentido contrario, si un fallo no se ha producido recientemente, puede llegar a subestimarse. La experiencia debe contrastarse con: Datos históricos. Frecuencia de los defectos. Impacto potencial. Cobertura de pruebas. Tendencias de calidad. Contexto de la nueva versión. 6. Exceso de confianza Sobreestimar lo que sabemos El exceso de confianza suele aparecer en afirmaciones como: «Ese componente nunca falla». «El cambio es demasiado pequeño para probarlo». «No necesita revisión porque lo ha desarrollado una persona sénior». «La plataforma soportará la carga». «Ya conocemos perfectamente a los usuarios». Este sesgo puede provocar que se reduzcan los controles precisamente en los cambios considerados más sencillos. La revisión de la calidad de código introduce criterios objetivos relacionados con mantenibilidad, complejidad, duplicidad, vulnerabilidades y cumplimiento de estándares. 7. Sesgo del statu quo Preferir no cambiar El sesgo del statu quo describe la tendencia a mantener la situación actual porque cualquier cambio se percibe como una fuente de riesgo o esfuerzo. Puede llevar a una organización a: Mantener procesos manuales poco eficientes. Evitar la modernización de una arquitectura obsoleta. Continuar utilizando herramientas inadecuadas. Retrasar controles automáticos. Rechazar una mejora porque «siempre se ha hecho así». La automatización de pruebas no debe adoptarse únicamente por tendencia, pero tampoco descartarse por inercia. La decisión debe valorar la frecuencia de ejecución, el mantenimiento, la criticidad del proceso y el retorno esperado. 8. Falacia del coste hundido Continuar por todo lo que ya se ha invertido Este sesgo aparece cuando una organización mantiene una iniciativa porque ya ha invertido tiempo, dinero o esfuerzo, aunque existan evidencias para replantearla. Algunos ejemplos son: Mantener una herramienta que no cumple sus objetivos. Continuar una funcionalidad con poco valor porque ya está avanzada. No sustituir una solución técnica para no «perder» el trabajo realizado. Prolongar una estrategia de pruebas que no detecta los riesgos relevantes. La pregunta correcta no es cuánto se ha invertido, sino qué alternativa aporta más valor a partir de ahora. 9. Sesgo de supervivencia Analizar únicamente los casos de éxito Este sesgo aparece cuando estudiamos proyectos, productos o estrategias que funcionaron e ignoramos aquellos que fracasaron. Esto puede llevar a copiar una metodología o arquitectura sin considerar: Los proyectos en los que no funcionó. Las condiciones necesarias para el éxito. Los costes ocultos. Los riesgos asumidos. Las diferencias entre organizaciones. En QA, las pruebas no ejecutadas, los defectos descartados y los datos no disponibles también proporcionan información sobre la calidad del proceso. 10. Sesgo de resultado Juzgar una decisión únicamente por su desenlace Una buena decisión puede producir un resultado negativo debido a factores imprevisibles. Del mismo modo, una decisión poco rigurosa puede obtener un buen resultado por casualidad. Por ejemplo, que un despliegue sin suficientes pruebas no genere incidencias no significa que la decisión fuera adecuada. Solo significa que el riesgo no llegó a materializarse. Para evaluar una decisión deben analizarse dos dimensiones: ResultadoProceso de decisión¿Qué ocurrió?¿Qué información estaba disponible?¿Se alcanzaron los objetivos?¿Se valoraron alternativas?¿Se produjeron incidencias?¿Se documentaron los riesgos?¿Cuál fue el impacto?¿Los criterios estaban definidos? Ejemplos prácticos en proyectos digitales Aprobación de un despliegue El responsable del proyecto comienza la reunión afirmando que la versión debe desplegarse porque la fecha ya se comunicó al negocio. A partir de ese momento, el comité deja de analizar si el producto está preparado y comienza a buscar argumentos para justificar una decisión que parece tomada. Sesgos implicados: Anclaje. Autoridad. Confirmación. Conformidad grupal. Investigación de una incidencia El primer diagnóstico atribuye el problema a una actualización reciente. El equipo concentra toda la investigación en ese componente, aunque las evidencias posteriores no confirman la hipótesis. Sesgos implicados: Anclaje. Confirmación. Exceso de confianza. Evaluación del rendimiento El equipo considera que la aplicación funcionará correctamente porque las versiones anteriores no presentaron problemas. Sin un proceso de Performance Testing adaptado al volumen, la concurrencia y la arquitectura actuales, la ausencia de fallos históricos no garantiza el comportamiento de la nueva versión. Sesgos implicados: Disponibilidad. Statu quo. Exceso de confianza. Validación de una aplicación móvil El producto funciona correctamente en los dispositivos utilizados por el equipo y se asume que ofrecerá la misma experiencia a todos los usuarios. Un enfoque de Mobile Testing permite evaluar diferentes sistemas operativos, resoluciones, fabricantes, permisos, condiciones de red y versiones. Sesgos implicados: Exceso de confianza. Confirmación. Supervivencia. Migración a la nube La organización presupone que trasladar una aplicación a una infraestructura cloud resolverá automáticamente sus problemas de disponibilidad y escalabilidad. El Cloud Testing permite comprobar la resiliencia, la elasticidad, la seguridad, las integraciones y el comportamiento ante fallos. Sesgos implicados: Efecto halo. Confirmación. Autoridad. Cómo reducir los sesgos cognitivos Eliminar completamente los sesgos no es posible. Sin embargo, sí pueden diseñarse procesos que reduzcan su influencia. 1. Separar hechos, opiniones e hipótesis Antes de debatir una decisión, conviene clasificar la información disponible. Tipo de informaciónEjemploHechoLa respuesta tardó 2,8 segundos.InterpretaciónEl rendimiento parece aceptable.HipótesisLa latencia procede de la base de datos.SupuestoEl volumen de usuarios no aumentará.Dato desconocidoNo conocemos el comportamiento con 5.000 usuarios simultáneos. Esta separación evita que una opinión se presente como un hecho. 2. Definir los criterios antes de conocer el resultado Los criterios de aprobación deben establecerse antes de ejecutar las pruebas o revisar las métricas. Una adecuada gestión de pruebas permite definir anticipadamente: Alcance. Prioridades. Criterios de entrada y salida. Cobertura necesaria. Riesgos aceptables. Evidencias requeridas. Responsables de la decisión. 3. Escuchar antes de concluir En muchas reuniones, los participantes preparan su respuesta antes de haber comprendido toda la información. La escucha activa exige analizar los datos, el contexto y los argumentos antes de emitir un juicio. Técnica práctica Pedir a cada participante que resuma el argumento contrario antes de defender su propia posición. 4. Evitar que la persona con más autoridad hable primero Cuando la dirección expresa su opinión al comienzo de una reunión, puede condicionar el resto de las intervenciones. Para evitarlo: Recoger valoraciones individuales previamente. Utilizar estimaciones simultáneas. Realizar una votación inicial anónima. Solicitar primero la opinión de los perfiles más cercanos al problema. 5. Asignar el papel de abogado del diablo Una persona puede asumir formalmente la responsabilidad de cuestionar la propuesta dominante. Su función es formular preguntas como: ¿Qué podría hacer que esta decisión fuera incorrecta? ¿Qué información estamos dejando fuera? ¿Existe una explicación alternativa? ¿Qué riesgo estamos normalizando? ¿Qué diría alguien que no está de acuerdo? Este papel debe rotar entre los participantes. 6. Buscar evidencias contradictorias No basta con reunir información que respalde una propuesta. También es necesario buscar datos capaces de refutarla. La gestión de datos de prueba ayuda a construir escenarios diversos, representativos y controlados, evitando que las conclusiones se basen únicamente en datos favorables. Preguntas útiles ¿En qué condiciones podría fallar? ¿Qué perfiles de usuario no están representados? ¿Qué combinaciones no hemos probado? ¿Qué dependencias podrían alterar el resultado? ¿Qué ocurriría con datos incompletos o inesperados? 7. Incorporar perspectivas externas Los equipos que trabajan durante meses en un mismo producto pueden normalizar problemas que una persona externa detectaría rápidamente. El Crowdtesting incorpora diversidad de dispositivos, ubicaciones, perfiles y contextos de uso, reduciendo una visión interna excesivamente homogénea. 8. Registrar las decisiones Cada decisión relevante debería documentar: El problema que se intenta resolver. Las alternativas consideradas. Los datos disponibles. Los supuestos aceptados. Los riesgos identificados. La persona responsable. La fecha de revisión. Las condiciones que obligarían a reconsiderarla. Este registro permite evaluar la calidad del proceso sin depender únicamente del resultado. 9. Realizar un premortem Un premortem consiste en imaginar que la decisión ya se ha ejecutado y ha fracasado. Han pasado tres meses y la iniciativa no ha cumplido sus objetivos. ¿Qué ha ocurrido? Cada participante responde de forma independiente. Esta técnica ayuda a reducir el exceso de confianza y hace visibles riesgos que podrían quedar ocultos en una conversación convencional. 10. Tratar las decisiones como hipótesis En entornos complejos, pocas decisiones deberían considerarse definitivas. El proceso puede estructurarse de la siguiente manera: Decidir → Documentar → Medir → Revisar → Corregir Se decide con la mejor información disponible. Se documentan los supuestos. Se definen indicadores. Se monitorizan los resultados. Se revisa la decisión. Se corrige el rumbo cuando es necesario. Modificar una decisión ante nuevas evidencias no es una señal de debilidad, sino de madurez organizativa. Checklist para decisiones de calidad Antes de cerrar una decisión relevante, el comité puede revisar estas preguntas: ¿Qué problema concreto intentamos resolver? ¿Qué hechos conocemos? ¿Qué elementos siguen siendo hipótesis? ¿La primera información recibida está condicionando el análisis? ¿Qué evidencias respaldan la decisión? ¿Qué evidencias la contradicen? ¿Hemos analizado una alternativa real? ¿Todas las personas han podido expresar su opinión? ¿La jerarquía está influyendo más que los datos? ¿Qué riesgos podríamos estar ignorando? ¿Cómo mediremos el resultado? ¿Cuándo revisaremos la decisión? El papel del Quality Assurance El Quality Assurance no debería limitarse a ejecutar pruebas al final del desarrollo. También debe mejorar la calidad de la información utilizada durante todo el ciclo de vida del producto. Su aportación incluye: Definir criterios verificables. Garantizar la trazabilidad. Introducir evidencias independientes. Identificar supuestos no validados. Medir la cobertura real. Comunicar la incertidumbre. Facilitar decisiones basadas en riesgos. Revisar el propio proceso de decisión. Esta perspectiva también es esencial en sistemas basados en inteligencia artificial. El aseguramiento de IA permite abordar riesgos relacionados con los datos, la robustez, la explicabilidad, el comportamiento de los modelos y la aparición de resultados sesgados. La IA no elimina automáticamente los sesgos humanos. Puede reproducirlos o amplificarlos cuando los datos y criterios utilizados para desarrollarla ya contienen desviaciones. Conclusión Los sesgos cognitivos pueden afectar a la planificación, la gestión de riesgos y la validación de entregas. Separar hechos de opiniones, cuestionar las hipótesis, buscar evidencias contradictorias y revisar las decisiones permite reducir su impacto. En los proyectos digitales, mejorar la calidad de las decisiones es también una forma de mejorar la calidad del producto. Para contextualizar esta relación, es importante comprender qué es el Quality Assurance y cómo contribuye a introducir criterios verificables, trazabilidad y evidencias objetivas en la toma de decisiones.

Acerca de Sebastián Lendínez

Entradas de] Sebastián Lendínez

¿Qué es un sesgo cognitivo y cómo afecta a las decisiones en proyectos digitales?

Autor del archivo de: Sebastian Lendinez

Acerca de Sebastián Lendínez

Entradas de] Sebastián Lendínez