$30 off During Our Annual Pro Sale. View Details »

Request for Proposal: Una guía desde el otro lado

Request for Proposal: Una guía desde el otro lado

No te pierdas esta valiosa guía que te ayudará a sobresalir en el proceso de respuesta a RFP. Aumenta tus posibilidades de éxito y establece relaciones sólidas con organizaciones que buscan tus servicios. ¡Descarga el libro y mejora tus habilidades hoy mismo!

Jose María Flores Zazo

July 17, 2023
Tweet

More Decks by Jose María Flores Zazo

Other Decks in Business

Transcript

  1. Request for
    Proposal
    Una guía desde el otro lado
    José María Flores Zazo

    View Slide

  2. 1
    Licencia CC0 1.0 Universal (CC0 1.0)

    View Slide

  3. 2
    Request for Proposal (Solicitud de Propuesta)
    Una guía desde el otro lado
    A mis padres, quienes con su esfuerzo y dedicación hicieron posible que aquel Amstrad CPC 464
    llegara a mis manos y despertara mi pasión por la informática.
    Este libro es el fruto de su valioso regalo y del amor incondicional que siempre me han brindado.
    Gracias por creer en mí y por impulsarme a seguir mis sueños. Sin vosotros, estas páginas estarían
    en blanco. Con todo mi amor y gratitud, este libro es un tributo a su inmenso amor y sacrificio.

    View Slide

  4. 3
    CONTENIDO
    1 INTRODUCCIÓN .................................................................... 6
    1.1 Request for Information (RFI) y Request for Proposal (RFP) .............................................. 11
    2 LLEGA UNA RPF ................................................................... 13
    2.1 ¿Por qué llega una RFP? .......................................................................................................... 13
    2.2 ¿Cómo deberían llegar las RPF? ............................................................................................. 15
    2.2.1 Planificar una RFP ...........................................................................................................18
    2.2.2 Anatomía de la RPF ........................................................................................................ 20
    2.2.2.1 Visión general e información administrativa ............................................................ 21
    2.2.2.2 Requerimientos técnicos ............................................................................................. 21
    2.2.2.3 Requerimientos de gestión ........................................................................................ 23
    2.2.2.4 Calificaciones y referencias del proveedor ................................................................ 23
    2.2.2.5 Sección para proveedores ........................................................................................... 24
    2.2.2.6 Sección de precios ....................................................................................................... 25
    2.2.2.7 Contratos y licencias ................................................................................................... 26
    2.2.2.8 Anexos ......................................................................................................................... 27
    2.2.3 Actividades de la RPF ..................................................................................................... 27
    2.2.3.1 Actividades Pre-RFP ................................................................................................... 27
    2.2.3.2 Actividades de la RFP ................................................................................................. 29
    2.2.3.3 Actividades Post-RFP ................................................................................................. 30
    2.3 Analizando una RFP: siempre falta algo ............................................................................... 34
    3 DESDE EL OTRO LADO: LA RESPUESTA .................................. 35
    3.1 ¿Cómo debería ser la RPF que tengo que estudiar? ............................................................. 35
    3.2 Guía para responder a una RFP ............................................................................................. 36
    3.2.1 Cubierta ........................................................................................................................... 36
    3.2.2 Resumen ejecutivo .......................................................................................................... 36
    3.2.3 Respuesta a los requerimientos administrativos .......................................................... 38
    3.2.3.1 Anatomía de la sección administrativa ..................................................................... 40
    3.2.4 Respuesta a los requerimientos técnicos ...................................................................... 43
    3.2.4.1 Requisitos .................................................................................................................... 44

    View Slide

  5. 4
    3.2.4.2 Anatomía de la sección técnica ................................................................................. 58
    3.2.4.3 Tablas de resúmenes ................................................................................................... 64
    3.2.5 Entregables ...................................................................................................................... 64
    3.2.6 El Precio ........................................................................................................................... 66
    3.2.6.1 Anatomía de los precios ............................................................................................. 67
    3.2.6.2 Tipos de costes ............................................................................................................ 75
    3.2.6.3 Precio fijo ..................................................................................................................... 77
    3.2.6.4 Time & Materials (recursos dedicados) ..................................................................... 78
    3.3 Evaluación de una RFP ........................................................................................................... 79
    3.3.1 ¿Ofertar o no ofertar? ......................................................................................................81
    3.3.2 Desarrollo preliminar de un punto de venta único/diferenciador. .............................81
    3.3.3 Desarrollo del Diseño del Programa ..............................................................................81
    3.3.4 Desarrollo de la Portada y el Resumen Ejecutivo ..........................................................81
    3.3.5 ¿Cómo debo hacer las preguntas al cliente? ................................................................. 82
    3.3.6 ¿Cómo debo hacer asunciones? ..................................................................................... 83
    3.3.7 Una serie de cuestionarios que te ayudarán ................................................................. 84
    3.3.8 Tipos de estimación y herramientas que ayudan ......................................................... 86
    3.3.9 ¿Cómo debería ser el equipo? ........................................................................................ 88
    3.3.9.1 ¿Qué espero de quien lidera la propuesta? ............................................................... 90
    3.3.9.2 ¿Qué espero de los mánager o gerentes de Áreas Funcionales? ............................. 91
    3.3.9.3 5.10.2.3 Miembros del Equipo .................................................................................... 91
    3.3.9.4 Acuerdos de Consultoría ............................................................................................ 92
    3.3.9.5 Acuerdo de Colaboración ........................................................................................... 92
    3.3.9.6 Especialista en Desarrollo de Propuestas .................................................................. 93
    4 ANEXOS .............................................................................. 94
    4.1 Cliente: cronograma inverso de ejemplo para planificar una RFP...................................... 94
    4.2 Cliente: ejemplo de la organización del equipo ................................................................... 95
    4.3 Cliente: ejemplo de información administrativa.................................................................. 96
    4.4 Cliente: instrucciones para responder a la RFP .................................................................... 97

    View Slide

  6. 5
    “Si conoces al enemigo y te conoces a ti mismo, no debes temer el
    resultado de cien batallas. Si te conoces a ti mismo, pero no al enemigo,
    por cada victoria obtenida también sufrirás una derrota. Si no sabes
    nada ni del enemigo ni de ti mismo, sucumbirás en todas las batallas.”
    ― Sun Tzu, The Art of War
    Notas:
    Punto en el que debes prestar especial atención.
    Consejos basados en la experiencia.
    Exención de responsabilidad:
    • Las marcas registradas mencionadas en este documento son propiedad de sus
    respectivos propietarios.
    • El autor se exonera de cualquier responsabilidad por el uso de las marcas
    registradas mencionadas en este documento.
    • El lector asume toda responsabilidad por el uso y aplicación del contenido del
    libro.
    • El autor no asume ninguna responsabilidad por los posibles perjuicios derivados
    del uso del contenido del libro.

    View Slide

  7. 6
    1 INTRODUCCIÓN
    ¿Para quién va dirigido este libro?
    Para todas aquellas personas que se dedican a responder RFP (Request for
    Proposal), pero también deberían leerlo aquellas otras que se dedican a
    escribirlas para que vean como entre ambas partes podemos ayudarnos.
    Estoy seguro de que aquellas personas que se dedican a escribir la respuesta
    a una RPF han vivido situaciones similares, incluso peores:
    1. A veces, como arquitecto, leyendo una RFP me siento que estoy
    descifrando un antiguo manuscrito en arameo esperando encontrar el
    tesoro escondido del presupuesto.
    2. Otras veces me encuentro en el juego de '¿Dónde está Wally?' cuando
    intento localizar los requisitos clave entre las páginas interminables de
    jerga técnica y cláusulas legales. ¿Quién necesita un pasatiempo cuando
    tienes una RFP?
    3. También espero ansiosamente la sección de 'criterios de evaluación',
    porque aquí es donde me convierto en el Sherlock Holmes de la
    arquitectura. Busco cada pista oculta y pistas secretas que me ayuden a
    descifrar lo que realmente están buscando.
    4. Y como no, al leer una RFP la sensación es de estar en una montaña rusa
    de emociones. Pasar de la emoción de encontrar una oportunidad
    interesante a la confusión extrema cuando me encuentro con un
    requisito absurdo.
    ¿Por qué ocurre esto?
    Siendo conciso y respondiendo a las situaciones anteriores de forma
    concreta:
    1. Complejidad del lenguaje: Las RFP suelen contener terminología
    técnica y legal específica que puede resultar difícil de comprender para
    alguien que no está familiarizado con ella.
    2. Extensión y estructura: Las RFP suelen ser documentos extensos con
    secciones y subsecciones que contienen información detallada.

    View Slide

  8. 7
    Navegar a través de estas páginas interminables en busca de los
    requisitos clave.
    3. Interpretación de los criterios de evaluación: La sección de criterios de
    evaluación es fundamental para comprender qué aspectos son
    prioritarios para los evaluadores. Los licitadores deben actuar como
    detectives, buscando pistas y pistas ocultas para descifrar lo que
    realmente se busca en la propuesta.
    4. Contraste de emociones: La lectura de una RFP puede generar
    diferentes emociones. Por un lado, la emoción de encontrar una
    oportunidad interesante y lucrativa puede ser emocionante. Sin
    embargo, también puede ser frustrante cuando se encuentran
    requisitos absurdos o contradictorios.
    Pero este coctel viene dado por la falta de un guion, un orden de las ideas o
    simplemente por falta de interés de quien la escribe. Si fuera solo una
    variable la que entra en juego, sería todo más sencillo, pero lo habitual es
    que exista una mezcla de variables (si no, todas) que de nuestro trabajo una
    tarea compleja y extenuante.
    Siendo formales, los puntos que habitualmente nos vamos a encontrar son:
    1. Complejidad de los requisitos: Si los requisitos de la RFP son complejos
    y detallados, puede llevar mucho tiempo comprenderlos
    completamente y determinar la mejor manera de abordarlos. Esto
    puede requerir un análisis exhaustivo y la consulta de múltiples
    recursos, lo que puede resultar extenuante.
    2. Ambigüedad o falta de claridad: Si la RFP no está redactada de manera
    clara y concisa, puede generar confusión y ambigüedad en cuanto a lo
    que realmente se espera en la propuesta. Esto puede llevar a la
    necesidad de hacer suposiciones o solicitar aclaraciones adicionales, lo
    que añade complejidad y retrasa el proceso de respuesta.
    3. Volumen de trabajo y plazos ajustados: Si hay una gran cantidad de
    trabajo involucrado en la preparación de la propuesta y los plazos son
    ajustados, el arquitecto de soluciones puede sentirse abrumado y
    presionado. Esto puede requerir una gestión eficiente del tiempo y de

    View Slide

  9. 8
    los recursos disponibles para cumplir con los requisitos en el tiempo
    establecido.
    4. Requerimientos técnicos desafiantes: Si la RFP incluye requerimientos
    técnicos altamente desafiantes o novedosos, el arquitecto de
    soluciones puede enfrentarse a problemas complejos que requieren
    una cuidadosa planificación y diseño. Esto puede llevar a
    investigaciones exhaustivas, pruebas y experimentación, lo que puede
    ser agotador.
    5. Competencia y expectativas altas: Si hay una fuerte competencia entre
    los licitadores y las expectativas de calidad y experiencia son altas, el
    arquitecto de soluciones puede sentir la presión de destacarse entre los
    demás. Esto puede generar un estrés adicional y un mayor esfuerzo
    para asegurar que la propuesta sea competitiva y cumpla con los
    estándares requeridos.
    ¿Por qué escribo este libro?
    El proceso de RFP es fundamental en el mundo empresarial y
    gubernamental, ya que proporciona una oportunidad para que las
    organizaciones busquen soluciones, productos o servicios externos que
    satisfagan sus necesidades específicas. Si bien existen numerosos recursos
    que se centran en cómo redactar RFP, hay un espacio notablemente limitado
    en la literatura que se dedica a ayudar a los proveedores a abordar estos
    documentos de manera efectiva.
    Gracias a este libro tengo la oportunidad de compartir mi experiencia y
    conocimientos como alguien que está del otro lado de la mesa, respondiendo
    a RFP. Espero que sea un recurso valioso para aquellas personas que tienen
    poca o nada de experiencia y quizá para a aquellas otras que es su trabajo
    diario.
    En este libro os guiaré a través de los desafíos y obstáculos comunes a los que
    nos enfrentamos los proveedores, al tiempo que intentaré ofreceros consejos
    prácticos sobre cómo superarlos:

    View Slide

  10. 9
    • Exploraremos las mejores prácticas para analizar cuidadosamente los
    requisitos del RFP, evaluar los riesgos asociados y determinar si una
    propuesta es una buena oportunidad de negocio.
    • Se abordarán estrategias efectivas para investigar a la organización que
    emite la RFP, comprender sus objetivos y alinear adecuadamente tus
    propuestas con sus necesidades y expectativas.
    • Compartiré técnicas para desarrollar una propuesta sólida, que
    destaque entre la competencia y de valor convincente.
    • También examinaremos en detalle cómo estructurar y presentar la
    información de manera clara y convincente.
    Como es imposible usar casos reales debido a las NDA (Non-Disclosure
    Agreement, acuerdo de no divulgación) que tengo firmadas, intentaré
    ilustrar el libro con desafíos y éxitos ficticios que en nada tendrá que ver con
    la vida real de mi carrera profesional. Estos casos prácticos me brindarán la
    oportunidad de mostrar ejemplos concretos que podréis analizar y
    comprender en profundidad, de esta forma tendréis una visión más clara de
    los conceptos y estrategias que presento.
    Al finalizar el libro espero poder aportar una mejora en tus habilidades de
    respuesta a RFP, aumentar tus posibilidades de éxito y establecer relaciones
    comerciales sólidas con organizaciones que buscan tus servicios.
    Espero que este libro sea una valiosa guía y referencia para aquellos que
    desean sobresalir en el competitivo mundo de las propuestas de negocios.
    Y ¿quién soy yo?
    Soy José María Flores Zazo, tengo más de 26 años de experiencia en el
    desarrollo de aplicaciones. He trabajado en diversas tecnologías desde
    Frontend hasta Backend, pasando de monolitos a microservicios,
    aplicaciones de movilidad, escritorio, IoT, AI, etc.
    Durante mi carrera, he estado involucrado en todas las etapas de los
    proyectos, desde la pre-venta hasta la implementación. También he
    trabajado en prototipos, desarrollo de frameworks internos, certificaciones,
    formación e investigación y desarrollo.

    View Slide

  11. 10
    Actualmente, desempeño roles como arquitecto de soluciones y sí, continúo
    desarrollando muchas cosas, me encanta desarrollador y centrarme en el
    software; no me gusta escribir cosas de arquitectura que no sea capad de
    hacer por mis mismo. También soy evangelista de varias tecnologías de
    Microsoft y otros fabricantes, y audito proyectos para garantizar que se sigan
    las mejores prácticas.
    Algunos de los proyectos que he liderado han recibido reconocimiento
    nacional e internacional, como LaundryID, premiado por la Unión Europea,
    y el proyecto NeverAlone del Instituto de Robótica para la Dependencia.
    Recientemente, fui nombrado Microsoft MVP en Azure para el período 2022-
    2023 y soy uno de los 110 Azure Content Hero en el mundo. Además,
    colaboro activamente en la comunidad, dando charlas en eventos, creando
    documentos como el que tienes entre manso, publicando videos en YouTube
    y ofreciendo talleres gratuitos.
    Siempre estoy aprendiendo cosas nuevas y estoy disponible para contactar a
    través de las redes sociales, especialmente LinkedIn y Twitter.

    View Slide

  12. 11
    1.1 REQUEST FOR INFORMATION (RFI) Y REQUEST FOR PROPOSAL (RFP)
    Es algo habitual que en mi sector usemos muchísimos acrónimos, que iré
    desgranando a lo largo del libro. Dos de ellos realmente importantes:
    Request for Proposal (RFP) Request for Information (RFI)
    Propósito
    Obtener propuestas detalladas
    de proveedores
    Obtener información preliminar
    de proveedores
    Requisitos Detallados y exhaustivos Generales y menos detallados
    Evaluación
    Basada en criterios específicos
    establecidos
    Evaluación preliminar y selección
    Nivel de detalle Completa y detallada General y no tan detallada
    Etapa del
    proceso
    Solicitud después de la RFI Solicitud antes de la RFP
    Enfoque Solución y propuesta completa Información general y capacidad
    Precio Una valoración detallada
    Una valoración sobre horquilla
    (valor máximo y mínimo)
    El flujo de un proceso es:

    View Slide

  13. 12
    1. Puede o no existir una RFI, la RFI tendrá una serie de reuniones y
    preguntas que hacen que el proveedor (nosotros) podamos dar una
    buena respuesta.
    2. Si hemos tenido una RFI el siguiente es la RFP, lo cual indica que el
    cliente ha pasado una criba inicial de proveedores. El cliente ya ha
    podido filtrar una serie de proveedores e ideas iniciales del enfoque de
    la aplicación.
    3. Y finalmente tenemos la RFP, que puede ser el paso siguiente desde la
    RFI o directo. Las oportunidades directas suelen recibirse por que ya
    nos conoce como proveedor.
    A parte de estas dos grandes definiciones de los proyectos de licitación,
    existe estas otras que deben sonarte:
    • EOI (Expression of Interest): la EOI es un documento mediante el cual
    un proveedor manifiesta su interés en ejecutar un proyecto y
    demuestra sus capacidades para llevarlo a cabo. Generalmente, este
    tipo de documento se solicita por parte de la administración o entidad
    contratante al inicio de un proceso de licitación, con el propósito de
    recopilar información sobre los proveedores interesados y evaluar su
    idoneidad para el proyecto.
    • RFQ (Request for Quotations): el término RFQ puede tener dos
    significados diferentes en el contexto de procesos de licitación:
    ▪ Request for Quotations: esta solicitud se utiliza cuando los
    productos o servicios ya están definidos, y el factor principal para
    seleccionar al adjudicatario es el precio. El objetivo de la RFQ es
    obtener cotizaciones o precios detallados de los proveedores, que
    luego se utilizarán como referencia en la RFP (Request for
    Proposal) para establecer un baremo de precios preciso.
    ▪ Request for Qualifications: en este caso, la RFQ se utiliza para
    recopilar información sobre las capacidades y cualificaciones de
    los proveedores para proporcionar un servicio o producto
    específico. El objetivo es evaluar las capacidades y habilidades de
    los proveedores y establecer un grupo de posibles proveedores
    que cumplan con los requisitos establecidos.

    View Slide

  14. 13
    • RFT (Request for Tender): el término RFT se utiliza principalmente en
    el sector público para referirse a la Request for Proposal (RFP) en el
    ámbito de las licitaciones. La RFT establece una estructura y formato
    específicos para las respuestas de los proveedores, con el objetivo de
    garantizar la transparencia y objetividad del proceso de licitación. En
    este tipo de solicitud, se proporcionan detalles y requisitos específicos
    del proyecto, y los proveedores deben presentar propuestas detalladas
    que aborden todos los aspectos de este.
    • BAFO (Best and Final Offer): BAFO hace referencia a la etapa de
    selección en la que se eligen las mejores ofertas presentadas durante
    un proceso de licitación. Después de evaluar las propuestas iniciales, se
    solicita a los proveedores seleccionados que presenten su mejor oferta
    final, considerando los aspectos técnicos, financieros y cualquier otra
    consideración relevante. En esta etapa, los proveedores tienen la
    oportunidad de mejorar y ajustar sus ofertas para competir por el
    contrato.
    2 LLEGA UNA RPF
    2.1 ¿POR QUÉ LLEGA UNA RFP?
    La RFP es un punto importante entre el inicio del proyecto y la
    implementación. La RFP nos proporciona la estructura que nos permite
    obtener los requerimientos que vamos a desarrollar en la aplicación. Gracias
    a este documento los clientes nos ofrecen una lista de requerimientos que
    podamos entender y responder.
    La RFP es un punto intermedio, muy importante, del proyecto que nos
    facilita una explicación de como se implementará la aplicación. Si no se
    platea una RFP sólida el proyecto no llegará a buen término.
    La RFP es una unión de los siguientes componentes:

    View Slide

  15. 14
    Este documento debe llevar información desde el presupuesto manejado por
    el cliente (dato que he visto en muy pocas ocasiones), hasta los
    requerimientos pasando por una lista de como califican a los proveedores, es
    decir, a nosotros. ¿Cuántas veces has visto lo que he puesto? Muy pocas, por
    eso una de las cosas que vamos a ver es como se debe crear una buena RFP,
    para que al llegar los puntos que faltan se pregunten sin tapujos, incluso
    antes que cualquier pregunta técnica debemos saber estos datos ya que son
    el marco de juego de nuestra propuesta.
    Nunca, como proveedor, vamos a llegar a presentar una buena respuesta al
    cliente, si este, no sabe como presentar una RPF con la información
    necesaria: “si no sabes a dónde vas, ningún camino te llevará allí”.
    Una buena RFP nos evitará de problemas en el futuro:
    • Una RFP requiere de un equipo que la estudie bien para encontrar los
    problemas y errores antes de enviarla al proveedor.
    RFP
    Proveedores
    Implementación
    Requerimientos
    Presupuesto

    View Slide

  16. 15
    • Una RPF nos forzará (proveedor) a ser competitivos y no solo
    responder a los requerimientos de la RFP si no más allá, nos pondrá a
    prueba para añadir valor adicional a la propuesta del cliente.
    • Las reglas las escribe el cliente, por tanto, no deberían favorecer a un
    proveedor en detrimento de otro, ya que se supone deberíamos tener
    todos los mismo.
    • Gracias a una RFP bien definida, todos los proveedores tenemos todas
    las reglas y por tanto para el cliente debería ser fácil discernir las
    diferencias entre proveedores.
    • Extendiendo el punto anterior, también ayuda al cliente a evaluar las
    propuestas. Esa es la consecuencia de una RFP bien estructurada por
    parte del cliente: la uniformidad a la hora de responder por parte de
    los proveedores.
    2.2 ¿CÓMO DEBERÍAN LLEGAR LAS RPF?
    No voy a salirme del segmento del IT, principalmente por que este
    documento está enfocado estos perfiles.
    Los productos informáticos habitualmente tienen un usuario final, por tanto,
    para escribir la RFP es necesario involucrarlos. Muchas veces ni se les
    consulta, es aquí cuando cualquier metodología en mayor o menor medida,
    ya sea waterfall o agile, falla.
    Mi propuesta es que separemos en tres sectores los perfiles y escojamos una
    buena relación entre ellos a la hora de escribir la RFP:
    • Operaciones y usuarios:
    1. Entendimiento completo de las necesidades: El equipo de operaciones
    y los usuarios son quienes tienen un conocimiento profundo de los
    desafíos y requisitos operativos diarios. Al involucrarlos en la escritura
    de la RFP, pueden proporcionar información crucial sobre las
    necesidades específicas del proyecto, los problemas actuales y las
    expectativas del producto o servicio que se va a adquirir. Esto garantiza
    que la RFP refleje con precisión las necesidades del negocio y las áreas
    clave que deben abordarse.

    View Slide

  17. 16
    2. Identificación de requisitos técnicos y funcionales: El equipo de
    operaciones y usuarios puede contribuir en la identificación de los
    requisitos técnicos y funcionales que son fundamentales para el éxito
    del proyecto. Su experiencia y conocimiento en el campo les permiten
    comprender las capacidades y características necesarias para satisfacer
    las necesidades operativas y los objetivos comerciales. Incluir sus
    perspectivas en la RFP ayuda a definir claramente los requisitos
    técnicos y funcionales que los proveedores deben cumplir.
    3. Validación de la viabilidad y factibilidad: Al involucrar al equipo de
    operaciones y usuarios en la escritura de la RFP, se asegura que los
    requisitos establecidos sean viables y factibles desde su perspectiva.
    Pueden proporcionar información valiosa sobre las restricciones
    operativas, la infraestructura existente, las limitaciones de recursos y
    cualquier otro aspecto que pueda afectar la implementación exitosa del
    proyecto. Esto ayuda a evitar la inclusión de requisitos irrealizables o
    poco prácticos en la RFP.
    4. Aumento de la aceptación y adopción del proyecto: Al participar en la
    escritura de la RFP, el equipo de operaciones y usuarios se siente
    involucrado y escuchado. Esto crea un sentido de propiedad y
    compromiso con el proyecto desde el principio. Además, al asegurarse
    de que las necesidades y expectativas del equipo sean consideradas, se
    aumenta la probabilidad de que el producto o servicio seleccionado sea
    aceptado y adoptado de manera más efectiva por el equipo.
    • IT:
    1. Conocimiento técnico especializado: El equipo de IT posee un
    conocimiento profundo de los sistemas, infraestructuras y tecnologías
    utilizadas en la organización. Al involucrarlos en la escritura de la RFP,
    pueden proporcionar una perspectiva técnica y ayudar a identificar los
    requisitos específicos de IT necesarios para el proyecto. Su experiencia
    y conocimiento técnico permiten redactar requisitos más precisos y
    relevantes relacionados con las soluciones tecnológicas y las
    integraciones necesarias.
    2. Evaluación de la viabilidad técnica: El equipo de IT puede evaluar la
    viabilidad técnica de las propuestas presentadas por los proveedores.

    View Slide

  18. 17
    Pueden analizar la arquitectura propuesta, la compatibilidad con los
    sistemas existentes, la seguridad de la información y otros aspectos
    técnicos críticos. Al involucrar al equipo de IT en la escritura de la RFP,
    se pueden establecer requisitos y criterios de evaluación que
    consideren la capacidad técnica de los proveedores para cumplir con
    los estándares y requisitos de la organización.
    3. Identificación de riesgos y desafíos técnicos: El equipo de IT puede
    ayudar a identificar posibles riesgos y desafíos técnicos asociados con
    el proyecto. Pueden señalar problemas de integración, requisitos de
    escalabilidad, consideraciones de rendimiento, entre otros aspectos
    relevantes. Al tener en cuenta estos factores desde el principio, se
    pueden abordar adecuadamente en la RFP y evaluar las propuestas de
    los proveedores para mitigar los riesgos técnicos potenciales.
    4. Evaluación de la capacidad y experiencia de los proveedores: El equipo
    de IT puede aportar una visión crítica en la evaluación de las
    capacidades y experiencia de los proveedores. Pueden revisar las
    referencias, casos de éxito y competencias técnicas de los proveedores
    para determinar su idoneidad. Su experiencia en el campo les permite
    identificar señales de alerta y seleccionar a los proveedores que mejor
    se ajusten a las necesidades técnicas y estratégicas de la organización.
    • Compras:
    1. Conocimiento de los procesos de adquisición: El equipo de compras
    tiene experiencia y conocimiento en los procesos de adquisición y
    contratación de bienes y servicios. Al involucrarlos en la escritura de la
    RFP, pueden proporcionar orientación sobre los procedimientos y las
    mejores prácticas para asegurar una licitación justa y transparente.
    También pueden ayudar a garantizar el cumplimiento de las políticas y
    regulaciones internas y externas relacionadas con las compras.
    2. Identificación de requisitos contractuales: El equipo de compras puede
    contribuir en la identificación de los requisitos contractuales
    necesarios para proteger los intereses de la organización. Pueden
    incluir cláusulas legales y comerciales relevantes en la RFP, como
    condiciones de pago, garantías, términos de entrega, derechos de
    propiedad intelectual, entre otros aspectos contractuales. Su

    View Slide

  19. 18
    experiencia en la redacción de contratos ayuda a asegurar que los
    términos y condiciones estén adecuadamente reflejados en la RFP.
    3. Evaluación de la capacidad financiera de los proveedores: El equipo de
    compras puede evaluar la capacidad financiera de los proveedores
    potenciales para cumplir con los requisitos del proyecto. Pueden
    solicitar información financiera relevante, como estados financieros,
    referencias bancarias u otras garantías financieras, y utilizarla para
    evaluar la solidez financiera de los proveedores. Esta evaluación es
    esencial para mitigar el riesgo de trabajar con proveedores que puedan
    presentar dificultades financieras durante la ejecución del proyecto.
    4. Negociación y selección de proveedores: El equipo de compras tiene
    habilidades y experiencia en la negociación de contratos y en la
    selección de proveedores. Al involucrarlos en la escritura de la RFP,
    pueden ayudar a establecer criterios de evaluación claros y objetivos,
    así como a diseñar el proceso de selección adecuado. Además, pueden
    participar en la evaluación de las propuestas recibidas, realizar
    negociaciones con los proveedores y recomendar al adjudicatario final.
    Su participación garantiza un proceso de selección imparcial y
    eficiente.
    Una vez tenemos la lista de perfiles que tenemos que buscar, toca ponerse
    manos a la obra para coordinar a estas personas y empezar la fase previa de
    la escritura de la RFP.
    2.2.1 Planificar una RFP
    Como clientes debes planificar, como paso previo para ponerse a escribir la
    RFP, sin planificación, la RFP será un caos. Vamos a evitarlo.
    1. Crear un proyecto de RPF y organizar al personal.
    2. Crear un cronograma de la RFP (Anexo 4.1).
    3. Listado de proveedores, según la tecnología y sector.
    4. Estimación y definición de los límites económicos del proyecto.
    5. Retorno de inversión (ROI) y análisis (si se necesita).
    6. Creación propiamente dicha de la RFP.
    7. Se evalúan las propuestas.
    8. Contratos y adjudicación.

    View Slide

  20. 19
    9. Actividades post-RFP.
    10. Personal del proyecto (Anexo 4.2) y organización para el nuevo
    producto.
    La parte del cronograma tendrá definidas hasta las fechas de respuestas a
    proveedores, así como fechas límites de envío de la propuesta. Debe quedar
    muy claro, si no aparece esta información del cronograma en la RFP que
    enviemos al proveedor, seguramente se relaje y llegue tarde a la entrega o
    bien no la tome en cuenta por qué puede pensar que esto es un tanteo que
    no llevará a ningún sitio.
    Como cliente cuando recibes una propuesta tienes la misión de evaluarla,
    para ello seguir siempre un guion hace el proceso más sencillo y por qué no
    industrializado.
    Por ejemplo, estas acciones son de lo más común:
    1. Revisar los requerimientos técnicos.
    2. Revisar los requerimientos de organización y administración del
    proyecto.
    3. Precio.
    4. Referencias.
    5. Visitas por parte del equipo de proveedor o presentaciones orales.
    6. Si disponen de productos de demo similares.
    7. Revisar en global la RPF.
    8. Y disponibilidad para acometer el proyecto.
    Por ejemplo, la disponibilidad es un tema muy importante, ya que un
    proveedor puede formar el equipo que propone en la RFP inmediatamente o
    bien tardar mucho siendo el proyecto del cliente, de vital importancia para el
    negocio.
    Unos puntos son más complicados de medir que otros y aquí entra en juego
    la subjetividad de quien evalúa la RFP. Siempre que se pueda intenta
    transformar tus medidas cualitativas (son buenos, regulares o malos) a
    medidas cualitativas (3 puntos, 1 punto, 0 puntos), te permitirá poner en
    valor una suma total de puntos ganados por cada proveedor y reducir la
    horquilla de posibles candidatos a la siguiente fase.

    View Slide

  21. 20
    Presta mucha atención a lo que responden los proveedores sobre los
    requerimientos, sobre todo aquellos que son obligatorios. Para que esto sea
    algo sencillo te recomiendo que separes los requerimientos en:
    • Obligatorios, ya que, si un proveedor no responde a todos, tienes una
    razón de peso para descalificarlos.
    • Opcionales, nice to have but not essential, lo que nos gustaría tener, pero
    que no son esenciales.
    Y como proveedor, si no ves la separación entre obligatorios y opcionales,
    puedes o bien preguntarlo en rondas de preguntas o bien tomar asunciones
    al respecto.
    2.2.2 Anatomía de la RPF
    La RFP es una herramienta para quien compra y cada tipo de compra,
    incluso en IT puede ser diferente os voy a proponer una estructura de una
    RFP que puedes tomar como base, quitando o poniendo lo que te interese
    como cliente que emite una RFP.
    Visión general e
    información
    administrativa
    Requerimientos
    técnicos
    Requermientos
    de gestión
    Calificaciones y
    referencias del
    proveedor
    Seccion para
    proveedores
    Sección para
    precios
    Contratos y
    licencias
    Anexos

    View Slide

  22. 21
    2.2.2.1 Visión general e información administrativa
    En esta sección debes proporcionar a los proveedores la información general
    sobre tu empresa y una explicación al problema que quieren solucionar con
    la RFP.
    Detallar lo máximo posible el problema que los proveedores debemos
    solucionar evitando cualquier referencia técnica al problema.
    En la parte de información administrativa vamos a proporcionar a los
    proveedores la siguiente información:
    • Dónde y cuándo enviar la propuesta.
    • Cuando podrán los proveedores ponerse en contacto con el cliente.
    • Fechas importantes en el proceso de licitación.
    • Requerimientos para preparar la propuesta (a veces los clientes nos dan
    un guion de como desean recibir la respuesta, otras veces hasta acceso a
    su plataforma para poder redactarla allí mimos).
    • Cómo van a evaluar la propuesta.
    • Nombres de los contactos y direcciones de las personas involucradas en la
    RFP.
    La información administrativa es muy importante ya que como cliente
    quieres que los proveedores nos pongamos manos a la obra lo antes posible y
    podamos obtener la información que nos hace falta de una forma ordenada
    sin impactar en el cliente que nos solicita ayuda.
    Sin esta información habrá proveedores que no respondan o presenten la
    atención debida a la propuesta.
    Nunca he rechazado una propuesta que venga sin parte de esta información,
    primero por qué habitualmente llega casi todo y segundo por qué es muy
    fácil pedir lo que necesitas de forma educada.
    2.2.2.2 Requerimientos técnicos
    Esta es la parte más importante de una RFP.
    Esta sección debe contener las necesidades que nos permitirá a los
    proveedores responder una RFP. En ella habrá un sumario de los problemas,
    requerimientos o solicitudes de la RFP. Debe haber una visión general que

    View Slide

  23. 22
    proporcione la información respecto a requerimientos de negocio,
    infraestructura, etc.
    Posterior a esta visión general, el cliente debe proporcionar una lista de
    requerimientos que el proveedor debe responder en la propuesta, por
    ejemplo:
    • Objetivos y metas del proyecto.
    • Factores críticos para alcanzar el éxito del proyecto.
    • Especificaciones funcionales actuales.
    • Especificaciones funcionales para el nuevo proyecto.
    • Especificaciones de cumplimiento: SLA, rendimiento, etc.
    • Cloud / On-Premise.
    • Requerimientos del software: herramientas, lenguajes, cumplimiento con
    un departamento de arquitectura, herramientas certificadas por el cliente,
    latencias, etc.
    Esta sección debe estar muy bien documentada y muy completa, cuanto más
    completa esté menos respuestas tendrá el proveedor y más fácil será dar una
    respuesta clara y concisa a las necesidades del cliente.
    Además, si eres el cliente, no te apetecerá estar repitiendo lo mismo a varios
    proveedores. Por eso a veces los proveedores sufrimos alguna que otra
    encerrona por parte del cliente y nos ponen a todos los proveedores en una
    ronda de preguntas conjunta que en muchas ocasiones es incomoda ya que
    no se tienen en cuenta el tiempo dedicado por cada proveedor, se ven las
    confianzas que tiene el cliente con alguno de ellos, etc. que pueden hacer
    que como proveedor no desee continuar con la propuesta por un claro
    tratamiento sesgado por parte del cliente. ¿Por qué sesgado? Por que es una
    forma tendenciosa de decirnos a los proveedores que llevamos tiempo con
    ellos que han puesto la mira en otros más baratos, que responden antes, etc.
    Al final es un juego que debería evitarse. Perjudica al cliente que cree que
    está haciendo una jugada maestra al confrontar proveedores.

    View Slide

  24. 23
    2.2.2.3 Requerimientos de gestión
    En esta sección el cliente nos debe proporcionar la información necesaria
    para desarrollar un plan que cubra la implementación, instalación,
    transferencia de conocimiento, mantenimiento y otros aspectos del
    proyecto. Al definir el cliente sus requerimientos, nos muestran a los
    proveedores que es lo mínimo y suficiente para cumplir y no ser
    descalificados, a partir de aquí es misión del proveedor ofrecer más valor a su
    propuesta.
    Habitualmente debería contener estas secciones:
    • Requerimientos funcionales del proyecto.
    • Requerimientos de personal (en ingles se usa la palabra staffing, que
    posiblemente escucharás mucho cuando hables con consultores).
    • Lista de responsabilidades del cliente y del proveedor.
    • Plan de entrega (delivery) e implantación.
    • Requerimientos de prueba aceptación.
    • Requerimientos para la transferencia de conocimiento (en ingles se suele
    usar KT que es Knowledge transfer).
    • Y requerimientos de documentación.
    Que el cliente detalle esto concienzudamente no es habitual, por eso
    recomiendo a los proveedores que tomen esta lista como un punto de
    partida para completar la RFP que nos ofrece el cliente.
    Si yo fuera el cliente, la detallaría por qué se trata de un mecanismo que
    podría usar para discernir quien cumple con los mínimos que establece y es
    una forma objetiva de descalificación.
    2.2.2.4 Calificaciones y referencias del proveedor
    Simplemente se trata de pedir al proveedor información de su compañía y su
    solvencia. El cliente podría pedir:
    • Un breve resumen de la historia de su compañía.
    • Qué ofrece su compañía (en ingles se suele llamar offering) y que
    capacidades tiene (certificaciones, reconocimientos, etc.).
    • Evidencias de que el proveedor tiene las habilidades, el equipo humano y
    los recursos financieros para poder acometer un proyecto.

    View Slide

  25. 24
    • Una lista de casos de éxito similares a la propuesta pedida por el cliente.
    Habitualmente llamado referencias.
    • Una lista de clientes y que relaciones tiene. Habitualmente la más
    importante es ser partner de [Organización] (que puede ser Microsoft,
    Amazon, Google, SAP, Salesforce, etc.)
    Si esto no es suficiente, lo mejor es que el cliente o el proveedor, contacte
    con su departamento legal o administrativo para que realice una
    investigación para ver si es necesario investigar. Esto es bidireccional, no es
    solo una tarea del cliente al proveedor. Ver si cualifica es algo que se debe
    hacer por ambas partes.
    2.2.2.5 Sección para proveedores
    Aquí el cliente puede poner una serie de cuestiones que pueden ayudar, pero
    que no son estrictamente necesarias, ya que no forma parte de la definición
    fundamental de la RFP.
    El cliente puede desde aportar ideas de como solucionar su problema, puede
    que en el pasado se realizara un assessement (evaluación) que incluyera una
    serie de recomendaciones hasta por ejemplo una serie de soluciones
    aportadas por otros proveedores que optaron a esta RFP en el pasado.
    Desde mi punto de vista, esto como cliente yo no lo aportaría, tiene dos
    lecturas, que el cliente no me de confianza suficiente por este tipo de juegos
    o que el cliente no logra encontrar la solución lo cual indica que es un
    proyecto con algo oculto. Mucho cuidado como proveedor cuando veáis este
    tipo de acciones. Os comento esto por qué lo he visto, que cada uno que
    juzgue la ética como quiera.
    Si usáramos esta anatomía desde el punto de vista de un proveedor para
    realizar una respuesta. Lo que yo pondría como proveedor sería para poner
    temas que yo crea que son relevantes para la RFP pero que no han sido
    discutidas en la parte de la respuesta de la RPF propiamente dicha, esta
    sección suele verse como un Anexo, pero no soy muy partidario de llevarlo a
    la parte de Anexos porque siempre quedan sin leerse y si se está optando por
    una tecnología disruptiva que puede ponerte por encima de otros

    View Slide

  26. 25
    proveedores, no estás haciendo la suficiente fuerza como para que se vea tu
    apuesta.
    2.2.2.6 Sección de precios
    La sección que parece ser la más importante en muchas organizaciones en
    detrimento de una buena solución.
    Como cliente, lo mejor para que me sea sencillo compararlo, es proporcionar
    una tabla al proveedor que contenga:
    • Hardware, sí, en la era Cloud. ¿No existen aplicaciones de movilidad que
    necesitan Tables robustas (ruggerized)?
    • Software de terceros y licencias. Derechos de licencias.
    • Desarrollo del producto. Si alguna parte el cliente ve que es un problema
    importante, debería pedirlo separado; por ejemplo, si la base de datos
    necesita una migración, quizá quite esto dependiendo del precio.
    • Mantenimiento.
    • Formación.
    • Documentación.
    • Administración del proyecto.
    • Integraciones.
    Revisar bien las herramientas SaaS y el cloud que escogen, algunos tienen
    costes ocultos. Puede que un competidor escoja entre AWS y Azure, mucho
    cuidado.
    También tener en cuenta que en la era de Kubernetes cuando se pide ser
    agnóstico, ya que habrá quien te plantee sistemas que al final llevarlo de on-
    premise a cloud te hace pagar dos licencias que son más mucho más caras que
    refactorizar bien tus yaml de deploy para cada entorno.
    Y, para terminar, no olvidemos el locking-vendor que es un coste muy oculto,
    no es tanto en euros o dólares, si no, en bloqueo que supone moverse de un
    sitio a otro y el coste que supone.

    View Slide

  27. 26
    2.2.2.7 Contratos y licencias
    Como arquitecto de soluciones los contratos económicos, acuerdos o
    licencias, no es nuestro cometido. Pero si que quiero hablar desde el punto
    de vista de un cliente ya que si estas liderando la propuesta te tocará ir
    buscando personas que te ayuden con esta sección.
    El cliente debería proporcionaros una guía para responder al cliente con los
    contratos y acuerdos necesarios. A veces los verás asociado a la sección
    anterior de precios o de forma independiente.
    Los contratos, clausulas, acuerdos deben ser estudiados por los proveedores.
    Pensar que, si nos piden un SLA del 100% con una penalización del 1000% de
    un día de media de facturación de su negocio, nos estamos metiendo en una
    trampa mortal. Por eso, entre las distintas entidades del proveedor deben dar
    respuesta a este tipo de cláusulas. Los clientes que proponen RFP con
    personal que trabajó en grandes consultoras pueden llegar a poner unas
    clausulas muy duras (no quiero decir abusivas) por qué conocen bien como
    funcionan estas grandes consultoras.
    Luego están las típicas de pagos a 30-60-90 días o cuanto tiempo tenemos
    que dar para que existan respuestas entre el cliente y proveedor cuando
    están desarrollando el producto, etc.
    Como cliente esto te ayudará a descartar proveedores que no estén
    dispuestos a aceptar tus imposiciones o que ni siquiera estén dispuestos a
    negociarlas. De esta forma puedes hacer un filtro temprano.
    La lista habitual de contratos puede ser:
    • Acuerdo de compra.
    • Contrato de mantenimiento.
    • Período de garantía.
    • Acuerdos de licencia de software, cesión de fuentes del proveedor al
    cliente, etc.
    • Bonificaciones y penalizaciones.
    • Formas de pago.
    • NDA (acuerdo de no divulgación).

    View Slide

  28. 27
    2.2.2.8 Anexos
    Ya lo hemos visto en el punto 2.2.2.5 Sección para proveedores.
    2.2.3 Actividades de la RPF
    Continuamos con el punto de vista del cliente. Esta sección nos ayudará a
    comprender mejor como proveedor a nuestros clientes, si sabemos como se
    realiza el proceso interno de una RFP.
    2.2.3.1 Actividades Pre-RFP
    El cliente se tiene que hacer preguntas como: ¿Quién lidera la RFP?, ¿Quién
    revisará la RFP?, ¿Quién busca a proveedores para la RFP?, ¿Quién redacta la
    RFP?, …
    Ahora es cuando toca investigar solvencias, otros proyectos, etc. y ¿quiénes
    son los mejores perfiles para hacer este tipo de búsqueda?: un perfil
    comercial, ya que debe:
    • Hacer una presentación de la empresa.
    • Buscar la lista de proveedores y personas de contacto a los que hacer
    prospección.
    • Enviar la RFP.
    • Preguntar si están interesados en la RFP los proveedores.
    Si el proveedor está interesado en la propuesta todos esos proveedores
    tendrán los tiempos que marcan la RFP en el cronograma. Un solo punto de
    información y no varios como suele ocurrir cuando el proveedor no da esa
    información directamente en la RFP.
    2.2.3.1.1 Identificar proveedores
    En la actualidad buscar proveedores está a una simple búsqueda en internet
    que consultoras existen en tu región con los filtros que más te interesen. Por
    ejemplo, busca “consultoras que estén certificadas en Kubernetes”:

    View Slide

  29. 28
    Aquí es cuando se puede tener un pequeño dialogo, entre el proveedor y
    cliente sobre aclaran temas como:
    • Precio máximo para el proyecto.
    • Tiempo aproximado en empezar el proyecto.
    • Fecha límite para que el proyecto esté en producción.
    • Que perfiles ayudaran del cliente al proveedor aclarar más dudas
    Lógicamente si el cliente tienes un cronograma, estas preguntas se pueden
    hacer en la ronda correspondiente.
    2.2.3.1.2 Investigar a los proveedores
    Unos criterios habituales para investigar al proveedor suelen ser:
    • ¿El proveedor presenta los conocimientos técnicos para una aplicación
    personalizada? ¿Presenta el producto adecuado usando una
    herramienta de mercado?, ¿Subcontrata parte del proyecto a otro
    proveedor?, ¿Quiénes son estas subcontratas?, …
    • ¿El proveedor tiene la capacidad para gestionar el proyecto?, ¿tiene la
    solvencia adecuada para cumplir los SLA?, …

    View Slide

  30. 29
    • ¿Se construye desde una factoría?, ¿desde un hub local?, ¿cómo se
    trabaja con esa factoría o hub?, ¿es necesario viajar para tener las
    reuniones en local? (sí os sorprendería lo mal que se puede llegar a
    gestionar una externalización en ciertas regiones del planeta, que va
    desde una mala conexión hasta la cultura de cada persona).
    • Si mi aplicación es internacional, ¿el proveedor da soporte
    internacional?,
    • ¿El proveedor puede presentar credenciales similares al proyecto que
    desea el cliente?, ¿más grandes?, ¿más pequeñas?, …
    • ¿Las fuentes será tuyas o serán del proveedor?, ¿a quien le pertenece la
    propiedad intelectual?
    Estas razones son más que obvias y son objetivas, per existen otras que no lo
    son, por eso revisa dos veces y si puede ser con dos personas diferentes la
    información de los proveedores.
    2.2.3.2 Actividades de la RFP
    Ya tienes identificados a los proveedores, has podido tener reuniones
    previas, te han dado sus credenciales, los has investigado. Ahora es el
    momento de escribir la RFP. ¿por qué no antes? Por que no enviarás una
    propuesta en .NET con C# a un proveedor que solo desarrolla en JAVA a no
    ser que este punto sea un tema abierto y se pida como requisito en la RFP,
    muchas empresas se casan con un fabricante a no ser que exista cambio de
    timón en el CTO (que también sucede).
    Lo que deberías incluir en la RFP:
    1 Cronograma de la RFP con todos los hitos del proyecto. Una
    planificación en formato inverso, donde pones primero la fecha de
    finalización de tu proyecto y vas moviéndote para atrás. Y te
    sorprenderás de la cantidad de tareas que tienes que hacer en el tiempo
    que pretendes destinar.
    2 Escribe por qué, la causa y todo lo que se ocurra de esta RFP, no solo el
    líder, si no, cualquier persona que tenga relación con ella. Revísalo varias
    veces y completa los puntos que faltan. Siempre es bueno empezar con

    View Slide

  31. 30
    “donde estamos y donde queremos llegar”, es un hilo conductor para
    explicar bien una RFP.
    3 Crea un esquema de alto nivel de tu RFP y que esté todo el personal de
    acuerdo, si no, las revisiones serán interminables y frustrantes (todo he
    de decirlo).
    4 Una vez que el guion este revisado y aprobado por quienes escriban la
    propuesta, revisa la planificación con ellos para que se comprometan con
    las fechas y se realicen los ajustes pertinentes.
    5 Cuando termines de escribir la RFP, detalla bien los criterios de
    evaluación y como deben responder los proveedores.
    6 Como cliente revisa que que tu importe económico se adecue a lo que
    estás pidiendo. Eres el primero en hacer una estimación económica y
    sobre todo revisa que en tu estimación están todos los requerimientos
    obligatorios.
    7 Establece contacto con los proveedores seleccionados. Asegúrate que el
    contacto del proveedor puede decirte si están interesados.
    8 Publica tu RFP en un sitio donde los proveedores seleccionados puedan
    descargarse el documento, de esta forma al enviar por correo el link
    todos los proveedores dispondrán del mismo tiempo.
    9 prepárate para mantener conversaciones con los proveedores (solos o en
    conjunto) así como las preguntas que van a realizar o el material que van
    a requerirte. Todo debería estar agendado en el cronograma de la RFP.
    10 Debes ser muy cordial con los proveedores ya que primero, pueden que
    no conozcan tu sector en profundidad y pregunta que para ti sean obvias.
    El documento no es pequeño y cosas se pueden pasar por alto. También
    te recomiendo que tengas cuidado con aquellos proveedores que
    conozcan a personas dentro de tu organización por qué esto puede
    pervertir la RFP que presenten al tener información interna y que se
    supone confidencial.
    El líder de la RFP es el responsable de que los tiempos se cumplan y que las
    personas adecuadas estén disponibles cuando se les requiere.
    2.2.3.3 Actividades Post-RFP
    Estas son algunas de las actividades que hace un cliente cuando los
    proveedores hemos enviado la propuesta. Y aquí si no has estado en ambos

    View Slide

  32. 31
    lados, pierdes mucho contexto que los clientes tienen, porque lo habitual es
    que tengan persona que han estado en ambos frentes tiene una ventaja
    táctica muy importante.
    Es raro ver el movimiento de estar muchos años en producto y creando RFP
    como cliente al moverse a consultoría para comenzar a responderla. O que
    clientes finales tengan parte de consultoría y estén en ambos frentes. Son
    raros, pero existen estos perfiles. Lo habitual es que las personas pasen de
    consultoría a producto final.
    Por ejemplo:
    1. Evaluar la propuesta: aquí hacemos un filtro de aquellas que cumplen
    con los requisitos y requerimientos, aquellas que llegan o no en el
    plazo requerido, aquellas que pueden ser susceptibles de problemas
    (precios por exceso o por defecto que no justifiquen los requerimientos
    o en base a un 50% por exceso o defecto), aquellas que están
    pobremente respondidas, etc.
    2. Primera ronda de filtrado de proveedores: envía una respuesta a los
    proveedores y el porqué de su descalificación. También te vendrá bien
    crear un documento donde tengas todo esto explicado por qué te
    servirá para cuando justifiques la propuesta ganadora.
    3. Deja una lista pequeña de proveedores: ahora toca estudiar la
    propuesta que entran procurando dejar como máximo entre 2 y 3
    proveedores final. Es complicado, pero usando un el razonamiento y
    documentando tus decisiones será más sencillo.
    4. Pide una demostración: si la RFP es sobre un producto que necesita
    personalización, como puede ser un CRM, ERP, pide que te lo
    muestren y si puede ser una demo de un caso de uso de lo que pides.
    5. Visita real: a veces tanto que el cliente visite la factoría o empresa del
    cliente o viceversa se produce un análisis que nos muestra que los
    equipo existen, que las persona que nos han asignado están y claro está
    con unos equipos de personas más que con otros se produce un feeling
    que ayuda a engrasar el trabajo entre dos entidades desconocidas, y
    esto puede ser motivo de descarte de uno de los proveedores.

    View Slide

  33. 32
    6. BAFO (Best of final offer): a veces durante la evaluación se puede
    producir una sobre estimación en tiempo o dinero que puedes tratar
    con el proveedor para ver las razones e incluso bajar alguna
    funcionalidad para que todos estemos más cómodos, estas
    conversaciones que no debes tener con más de 2 proveedores
    terminarán por pulir la propuesta final ya que das la oportunidad al
    proveedor para repensar algunos puntos y afinar el precio para
    establecer la oferta final.
    7. Selección del proveedor: considera que este paso final de la RFP es el
    primer paso del proyecto. Si todos hemos realizado nuestros deberes es
    posible comenzar directamente el proyecto (en muy pocas ocasiones lo
    he visto, ya que se debes tener en cuenta la disponibilidad de personas
    que están cerrando proyectos).
    8. Informe de selección del proveedor: posiblemente no tengas que
    hacerlo, pero lo recomiendo, es una buena práctica poner un por qué si
    o por qué no están seleccionados los proveedores. De esta forma el
    informe sirve para poder dejar documentadas las decisiones.
    9. Informes para proveedores descartados: si lo deseas o lo piden, yo
    prefiero hacerlo siempre, es ofrecer feedback del por qué no fue
    seleccionado, esto puede ayudar mucho y genera una buena relación
    entre cliente proveedor para futuras RFP.
    10. No guardes nada pasados 6 meses: borra todas las anteriores RFP, no
    tengas síndrome de Diógenes digital, no te vale para nada tener RFP
    que no valen y es más, incluso puedes estar en una posición que
    incumplas alguna clausula legal. Durante esos 6 meses puede que
    algún punto que detallo un proveedor te venga bien rescatarlo y es
    hasta posible ofrecerle esa parte por qué exista alguna contingencia
    con el proveedor principal. Esto pasa más de lo que piensas.
    2.2.3.3.1 Los contratos
    Esta parte merece una mención muy especial ya que los contratos son los
    que nos permitirán tener una salvaguarda en cuanto una de las partes
    incumple algún plazo, cambia el alcance, etc. Aunque la intención es que
    entre ambos exista una muy buena relación y sea una relación win-win, en

    View Slide

  34. 33
    muchas ocasiones se tuerce un poco la relación, por eso, los contratos son
    nuestras reglas de juego.
    Por muy pequeño que sea el cambio que introduce alguna de las partes,
    impactará siempre en el calendario de entrega. Por tanto, cualquier pequeño
    cambio debe ser tratado con la misma importancia que uno grande.
    Si todo se soluciona amistosamente, perfecto, pero cuando no es así
    comienzan los litigios y cualquier coma mal puesta en un texto es susceptible
    de ser reinterpretado.
    Cuando hemos realizado un diseño de UX/UI que hemos acordado con
    usuarios y Product Owner, pero 2 desarrolladores 1 del cliente y 1 del
    proveedor deciden que ese campo debe ser de otra forma (aunque sea una
    cosa muy inocente), afecta a las pruebas, afecta al trabajo de otras personas y
    provocará reacciones imprevisibles.
    Y aquí para poder ser fehacientes con un cambio de este tipo, quizá por que
    se necesite, la documentación entra en juego, las reuniones y las actas. Es
    una forma de consensuar entre todas las partes y si provoca un cambio de
    alcance todo el mundo estará informado y habrá asumido las consecuencias.
    Documenta, documenta y documenta. Más hoy en día que puede hacer la
    documentación como código:

    View Slide

  35. 34
    2.3 ANALIZANDO UNA RFP: SIEMPRE FALTA ALGO
    Siempre falta algo por parte del cliente o por parte del proveedor, seamos
    ligeramente flexibles ya que ambas partes desean un objetivo común, por eso
    quizá esta sección sea más bien sea una conclusión.
    Escribir y revisar RFP desde la parte de un cliente es una tarea complicada
    que consume recursos de la empresa, a pesar de ser el cliente quien conoce
    mejor el funcional de su aplicación. Por eso cuando se escribe es para que no
    falte nada, que se realice con tiempo y con los actores adecuados, además de
    tener la asignación económica para el proyecto. Ya que muchas veces veo
    que partes se escriben rápidamente y sin consenso, el proveedor puede intuir
    que esto es un mal proyecto o que están apurados, estas cosas pueden tirar
    para atrás a muchos proveedores.
    Cuando alguien crea una RFP esta dando el primer paso para su proyecto,
    debe ser una demostración de que el cliente esta apostando por un cambio y
    así debe ser plasmado en su RFP.
    Como cliente ten en cuenta que los proveedores no estamos obligados a
    responder, por eso no escribas de forma pobre, mal estructurada, con poca
    información o con “falta por concretar”, ya que, como decía antes, como
    proveedor puedo pensar dos cosas: está RFP ya está asignada o esta RFP
    apesta y lógicamente destine mis esfuerzos a algo con mejor aspecto, ten en
    cuenta que los proveedores también debemos ser selectivos y muchas veces
    vamos a algo que podemos o tenemos posibilidades de ganar.
    Para finalizar, a mi me gusta pensar que el proveedor que gana la propuesta
    se convertirá en otro miembro más del equipo del cliente y parte de la
    compañía. Construir una buena relación entre cliente y proveedor debe
    basarse en un mutuo entendimiento y confianza con el objetivo común de
    cumplir con el proyecto para el que nos hemos involucrado todos.

    View Slide

  36. 35
    3 DESDE EL OTRO LADO: LA RESPUESTA
    Como parte proveedora ya habéis visto como debería llegar una RFP y que
    pasos da el cliente para construirla. Ellos han invertido tiempo y dinero en
    hacerla lo mejor posible. Ahora es cuando nos toca ser recíprocos y ofrecer la
    mejor respuesta posible.
    3.1 ¿CÓMO DEBERÍA SER LA RPF QUE TENGO QUE ESTUDIAR?
    A mí me gusta tener todo bien estructurado, es un defecto profesional,
    cuanto mejor este estructurado menos variables quedarán al azar.
    El cliente puede que nos de un guion para responder a la RFP, esto sería lo
    ideal, pero como casi nunca lo veo, lo mejor es que te de un guion sencillo
    con lo que debería pedirte un cliente. Puedes usarlo para comparar lo que te
    llega y así tener las primeras preguntas listas para la ronda inicial de
    cuestiones entre cliente y proveedor.
    Guion Título
    1 Cubierta con el título e información del proveedor
    2 Resumen ejecutivo de la propuesta
    3 Respuesta a los requerimientos administrativos
    4 Solución técnica y descripción
    5 Administración del proyecto
    6 Respuesta a los requerimientos
    6.1 Requerimientos administrativos
    6.2 Requerimientos técnicos
    7 Sección adicional que el proveedor considere importante
    7.1 Metodologías: Waterfall, Agile, DevOps, etc.
    7.2
    Procesos: como se trata un cambio de alcance, como se envían
    incidencias, etc.
    7.3 Soluciones ilustrativas de arquitectura y alternativas contempladas
    7.4
    Pasos que hacemos para diseñar una aplicación: ux/ui, construcción,
    soporte, etc.
    7.5
    Algún añadido técnico muy importante que no debe ir en Anexos
    (muy opcional)
    8 Precio
    Anexos
    a Referencias del proveedor y casos de éxito

    View Slide

  37. 36
    b Calificación financiera e informe de cuentas anual
    c Contratos de compra, legales, etc.
    d Licencias de software y acuerdos
    3.2 GUÍA PARA RESPONDER A UNA RFP
    Como ya os he comentado, puede que el cliente nos de un guion, mi consejo
    es intenta extrapolarlo al guion que os he dado yo para trabajar de forma
    ordenada; si con algún punto no encuentras semejanza y ves que falta
    información importante, intenta colocar lo que falte, con respecto al guion
    que os proporciono, situarlo en la sección que mejor se adecue de la
    propuesta del cliente.
    ¿Cómo debo presentar la propuesta? en Word, en
    PowerPoint, en Confluence, en Markdown, etc. Esto es algo
    que tu organización como proveedor debe darte o bien exigir
    el cliente. En cualquier caso, sea el sistema que sea debe
    tener los logos, las fuentes, las imágenes, iconos, etc. que
    puedas usar, para no incurrir en ningún problema legal con
    tu empresa.
    3.2.1 Cubierta
    A modo ilustrativo una portada debería incluir:
    • Título del Proyecto y subtítulo
    • Logotipo de tu organización y del cliente.
    • Fecha de presentación y versión del documento.
    Una página dedicada a la confidencialidad y NDA del documento
    presentado.
    Y, por supuesto, el guion.
    3.2.2 Resumen ejecutivo
    Habrá quien te diga que no es necesario, que esto suele hacerse a parte o que
    se muestra en la defensa de la RFP. Sí, no lo voy a discutir ya que cada
    organización tiene sus normas, pero siempre he partido de esa base por qué
    la RFP puede llegar a distintas manos y alguien con mucha responsabilidad

    View Slide

  38. 37
    es una persona que tiene el tiempo justo y proporcionarlo directamente en la
    RFP ayuda a que esa persona tenga la idea global.
    Desde mi experiencia debemos tener en cuenta el siguiente guion:
    - Introducción:
    a. Presenta tu empresa y su experiencia relevante en el campo.
    b. Menciona el nombre y número de la RFP a la que estás
    respondiendo.
    c. Resalta la importancia de la RFP y cómo tu respuesta cumple con
    los requisitos establecidos.
    - Visión general del enfoque:
    a. Describe brevemente el enfoque general que tomarás para
    abordar los desafíos y necesidades planteados en la RFP.
    b. Destaca los principales beneficios y valor que tu solución
    aportará al cliente.
    c. Haz hincapié en cómo tu enfoque se alinea con los objetivos y
    valores del cliente.
    - Experiencia relevante:
    a. Enumera y destaca proyectos similares realizados previamente
    que demuestren tu experiencia y éxito en el área relacionada con
    la RFP.
    b. Menciona clientes clave con los que has trabajado y los
    resultados obtenidos.
    c. Resalta cualquier certificación, reconocimiento o premio
    relevante que respalde tu experiencia.
    - Solución propuesta:
    a. Resume los aspectos clave de tu solución y cómo abordará los
    requisitos específicos de la RFP.
    b. Destaca las características y funcionalidades clave de tu
    propuesta.
    c. Explica cómo tu solución se diferencia de las alternativas
    disponibles y cómo beneficiará al cliente.
    - Equipo y recursos:
    a. Presenta al equipo que estará involucrado en la implementación
    de la solución propuesta.

    View Slide

  39. 38
    b. Destaca las capacidades y experiencia relevantes de los
    miembros del equipo.
    c. Menciona los recursos y tecnologías que se utilizarán para llevar
    a cabo el proyecto.
    - Plan de implementación y cronograma:
    a. Proporciona una visión general del plan de implementación de la
    solución propuesta.
    b. Destaca los hitos clave y los plazos asociados.
    c. Explica cómo se gestionará y controlará el proyecto para
    garantizar una ejecución exitosa.
    - Presupuesto y detalles contractuales:
    a. Proporciona una estimación de costos para la implementación de
    la solución propuesta.
    b. Menciona cualquier consideración adicional relacionada con los
    términos contractuales, como garantías, soporte post-
    implementación, etc.
    - Conclusión:
    a. Resume los principales puntos de la respuesta a la RFP.
    b. Reafirma el compromiso de tu empresa para cumplir con los
    requisitos y expectativas del cliente.
    c. Invita al cliente a tomar contacto para discutir más detalles o
    aclaraciones necesarias.
    3.2.3 Respuesta a los requerimientos administrativos
    Si nos lo piden explícitamente los clientes, ellos nos podrán una lista de
    cosas a las que responder, en otro caso, los requerimientos administrativos
    que suelen pedir los clientes son:
    1. Experiencia y expertise del equipo: destacamos la experiencia y
    calificaciones de su equipo, certificados de la empresa, formación de
    los equipos, experiencia laboral relevante y certificaciones
    profesionales. Esto brinda confianza en su capacidad para cumplir con
    los requisitos del proyecto.
    2. Plan de gestión del proyecto: se incluye un plan detallado de cómo se
    gestionará el proyecto, incluyendo la asignación de recursos, el
    cronograma, las actividades clave y la estrategia de gestión del riesgo.

    View Slide

  40. 39
    3. Políticas y procedimientos: documentamos las políticas y
    procedimientos que nuestra empresa tiene en vigor para garantizar la
    calidad, la gestión de riesgos, la seguridad de los datos, la protección
    del medio ambiente y el cumplimiento normativo.
    4. Cumplimiento legal y regulatorio: nos aseguramos de incluir una parte
    donde se indique que cumplimos con todas las leyes y regulaciones
    aplicables en el ámbito del proyecto. Proporcionar una prueba de
    cumplimiento, como licencias, permisos y certificaciones requeridas
    son algo muy favorecedor.
    5. Seguro y responsabilidad: tenemos que indicar el tipo de seguro de
    responsabilidad civil que posee nuestra empresa y el alcance de la
    cobertura. Esto brinda protección tanto a su empresa como al cliente
    en caso de cualquier eventualidad durante el proyecto.
    6. Plan de comunicación: desarrollaremos un plan de comunicación que
    establezca cómo mantendremos informado al cliente sobre el progreso
    del proyecto, los hitos alcanzados, los problemas identificados y las
    soluciones propuestas.
    En algunas ocasiones nos podrán permitir responder de forma alternativa:
    • Estructura del documento de la RFP.
    • Una respuesta alternativa a como realizar la RFP, a veces nos piden
    precio cerrado y podemos proponer un Time & Material o incluso para
    poder hacer lo que nos piden podemos proponer una assessment.
    Siempre que queráis ir por este lado preguntar de formar escrita al
    cliente preguntando si esto nos descalificaría de la propuesta.
    Como cliente me he encontrado que en esta primera reunión el proveedor llega
    sin que esté alguien del equipo de arquitectura, esto es un error muy grave por
    parte del proveedor. Como proveedor esto nunca debe ocurrirte y como cliente
    esto es una bandera roja muy importante.
    Al igual que os pongo lo que suelo ver en esta área, como cliente existen cosa
    que no me gusta ver, es un error común en muchas respuestas: que los
    proveedores incluyan términos o cláusulas de contratos dentro de la sección

    View Slide

  41. 40
    administrativa. Aquí no estamos tratando de condiciones, de contratos o
    términos legales.
    3.2.3.1 Anatomía de la sección administrativa
    Veamos los elementos comunes de una sección técnica. Cuando
    respondemos a la RFP los clientes suelen quedarse en la parte de formatos de
    ficheros, integraciones con terceros, Stack tecnológico de su organización,
    etc. Lo que deberían incluir y casi nunca lo incluyen nos servirá como guía
    para poder responder como proveedor y a los clientes esto os servirá de guía
    para saber cómo afrontar esta sección.
    Los puntos habituales son:
    1. Plan del proyecto: plan detallado del proyecto que incluya los
    objetivos, los hitos clave, las entregas y los recursos necesarios.
    Explicaremos cómo abordar el alcance, los plazos y la asignación de
    recursos para garantizar la finalización exitosa del proyecto.
    2. Cronograma del proyecto: cronograma detallado que muestre las
    diferentes etapas del proyecto, las fechas estimadas de inicio y
    finalización, y los hitos importantes. Utiliza herramientas como
    diagramas de Gantt para visualizar el cronograma de manera clara y
    concisa.
    3. Plan de preparación del sitio y responsabilidades: si el proyecto implica
    la instalación o implementación en un sitio específico, describe cómo
    te encargarás de preparar el sitio. Incluye tareas como la instalación de
    infraestructura, configuraciones técnicas y cualquier requisito de
    preparación previa al despliegue. Asigna responsabilidades claras a tu
    equipo y, si es necesario, a otros proveedores o al cliente.
    4. Requisitos de personal: especifica los recursos humanos necesarios
    para el proyecto, incluyendo habilidades y roles específicos. Define el
    equipo de proyecto necesario, como gerentes, desarrolladores,
    diseñadores, especialistas en calidad, etc. Describe el proceso de
    selección y asegúrate de resaltar la experiencia y las habilidades
    relevantes del personal propuesto.
    5. Diseño, desarrollo e implementación: detalla tu enfoque para el diseño
    y desarrollo de la aplicación informática. Explica cómo trabajarás con

    View Slide

  42. 41
    el cliente para recopilar requisitos, diseñar la arquitectura, desarrollar
    el software y realizar pruebas exhaustivas. Destaca tus metodologías,
    herramientas y enfoques de calidad para garantizar un resultado
    exitoso.
    6. Entrega e instalación: describe cómo se llevará a cabo la entrega y la
    instalación de la aplicación informática en el entorno del cliente.
    Menciona cualquier proceso de migración de datos, configuración y
    puesta en marcha que sea necesario. Asegúrate de abordar los plazos y
    la coordinación necesaria con el cliente y otros proveedores
    involucrados.
    7. Pruebas de aceptación del sistema: explica cómo llevarás a cabo las
    pruebas de aceptación del sistema para asegurarte de que la aplicación
    cumple con los requisitos definidos. Describe los criterios de
    aceptación, las estrategias de prueba y los procedimientos para la
    identificación y resolución de problemas.
    8. Mantenimiento del sistema: describe cómo proporcionarás el
    mantenimiento continuo del sistema una vez que esté implementado.
    Detalla los servicios de soporte, las actualizaciones del software, las
    correcciones de errores y cualquier otro aspecto relacionado con el
    mantenimiento y la estabilidad a largo plazo del sistema.
    9. Capacitación: explica cómo llevarás a cabo la capacitación para los
    usuarios finales de la aplicación. Describe los materiales de
    capacitación, las metodologías de enseñanza y los enfoques de
    seguimiento para garantizar que los usuarios comprendan y puedan
    utilizar eficazmente la aplicación.
    10. Documentación: indica cómo crearás y proporcionarás documentación
    detallada sobre la aplicación, incluyendo manuales de usuario, guías de
    instalación, documentación técnica y cualquier otra documentación
    relevante. Destaca la importancia de una documentación clara y
    concisa para facilitar el uso y el mantenimiento del sistema.
    Muchas veces esta sección se ve afectada una vez ganada la propuesta.
    Quiero decir, que, aunque la propuesta está ganada, muchos clientes añaden
    clausulas al contrato que hacen que el precio y el alcance definido en esta

    View Slide

  43. 42
    área se ve a afectado tanto por como se aborda como por el precio que
    cambia.
    Como podría ampliar esta sección, pues depende del proyecto y lo que
    quieras que llegue a engordar:
    1. Plan de recuperación ante desastres: describe tu enfoque para
    garantizar la continuidad del negocio y la recuperación de datos en
    caso de un evento adverso. Explica cómo identificarás y evaluarás los
    posibles riesgos y amenazas, y cómo desarrollarás estrategias y
    procedimientos para minimizar el impacto de los desastres.
    2. Metodología de gestión de proyectos: explica la metodología que
    utilizarás para gestionar el proyecto. Puedes mencionar enfoques ágiles
    como Scrum o Kanban, así como cualquier otro marco de trabajo o
    proceso específico que hayas desarrollado internamente.
    3. Gestión de riesgos: identifica los posibles riesgos asociados con el
    proyecto y explica cómo los mitigarás o gestionarás de manera
    proactiva. Menciona cualquier enfoque específico que hayas
    desarrollado para la gestión de riesgos, como la realización de
    evaluaciones periódicas y la implementación de planes de
    contingencia.
    4. Comunicación y colaboración: describe cómo mantendrás una
    comunicación fluida y eficaz con el cliente y otros stakeholders del
    proyecto. Destaca las herramientas que utilizarás para facilitar la
    colaboración, como sistemas de gestión de proyectos, plataformas de
    comunicación y reuniones regulares.
    5. Gestión del cambio: explica cómo abordarás los cambios en los
    requisitos del proyecto o las solicitudes adicionales del cliente. Destaca
    tu capacidad para adaptarte a las necesidades cambiantes y mantener
    la transparencia en la gestión de cambios.
    6. Estándares: describe los estándares que seguirás durante el desarrollo y
    la implementación de la aplicación informática. Esto puede incluir
    estándares de codificación, estándares de seguridad de la información,
    estándares de interoperabilidad y cualquier otro estándar relevante
    para el proyecto. Explica cómo cumplirás con estos estándares y cómo
    garantizarás su cumplimiento a lo largo del proyecto.

    View Slide

  44. 43
    7. Transiciones del proyecto (Project Cutovers): si el proyecto implica
    transiciones críticas entre fases o sistemas existentes, explica cómo
    planificarás y ejecutarás estas transiciones de manera eficiente.
    Describe los pasos y las actividades necesarias para minimizar los
    riesgos y garantizar una transición fluida y exitosa.
    8. Problemas y preocupaciones de los proveedores (Supplier Issues and
    Concerns): si tu proyecto involucra a proveedores externos, explica
    cómo gestionarás cualquier problema o preocupación relacionada con
    ellos. Describe tu enfoque para establecer y mantener una
    comunicación clara con los proveedores, así como los mecanismos de
    resolución de conflictos y las estrategias para minimizar los impactos
    negativos en el proyecto.
    La administración del proyecto es un factor clave en la evaluación,
    determinar si somos elegidos o no, mucho antes que la solución técnica, a
    muchos clientes les da igual como estén las tripas mientras el engranaje
    funcione y obtengan el valor que desean con la aplicación. Dependiendo del
    proyecto esta sección tiene mucho más peso que la solución técnica.
    Esta sección los clientes la utilizan para ver la fuerza y debilidades de nuestra
    organización.
    3.2.4 Respuesta a los requerimientos técnicos
    En esta sección nosotros, los proveedores estamos respondiendo a los
    requerimientos, servicios, formaciones, etc. que quiere comprar el cliente.
    Esto es el corazón de la RFP es donde la información que ofrecemos hace que
    un cliente se decante o no por la propuesta, aunque muchas veces mandan
    las variables tiempo y dinero sobre lo bien que está presentada y pensada la
    RFP.
    Aquí no estamos vendiendo un producto o nuestro producto, algunos
    proveedores se enrocan en vender algún producto de los que son socios, y
    cuando este ocurre te tienen que vender una modificación o extensión que se
    adapte a tu negocio. He vivido un memorándum donde la dirección hacía
    hincapié en montar el estándar a toda costa y cambiar los procesos al cliente.
    Por eso no es lo mismo que un cliente te diga “quiero un coche donde entren 6

    View Slide

  45. 44
    personas”, a que te pida “quiero un coche negro con 5 puertas que pueda hacer
    un trayecto de 800Km sin repostar, que consuma menos de 5.4L/100KM y que
    entren cómodamente 6 personas”.
    Y gracias al anterior ejemplo os puedo decir que el cliente podrá encontrar
    100 proveedores que cumplan esos requerimientos mínimos, pero
    seguramente habrá 5 o menos que puedan cumplir la mayoría de los
    requerimientos detallados que el cliente pide. Y por tanto será el cliente
    quien decida que gana y que pierde, si es que ningún proveedor es capad de
    ofrecer todo lo que pide.
    Como proveedor para no perder el norte cuando respondo a la petición de
    requisitos es:
    1. Focalizar que tecnología me puede ayudar a cumplir la mayoría de los
    requisitos obligatorios.
    2. E identificar aquellos requisitos que no puedo cumplir, para buscar
    alternativas o bien para responder directamente que no es posible.
    Como he estado hablando de requisitos, vamos a ver que son, para que
    sepamos identificarlos bien.
    3.2.4.1 Requisitos
    Una RFP es una colección de requerimientos que definen un producto o
    servicio, por tanto, la primera pregunta que nos debemos responder es ¿Qué
    es un requerimiento?
    Los requerimientos se refieren a las funcionalidades, características y
    restricciones que un sistema o software debe cumplir para satisfacer las
    necesidades de los usuarios, los clientes y otras partes interesadas. Los
    requerimientos son descripciones detalladas de lo que se espera que el
    sistema realice o logre.
    Los requerimientos pueden incluir aspectos como las funcionalidades
    específicas que debe tener el sistema, los comportamientos esperados, los
    requisitos de rendimiento, las restricciones técnicas o de recursos, los

    View Slide

  46. 45
    criterios de usabilidad y cualquier otro elemento necesario para definir el
    alcance y el funcionamiento del sistema.
    Los requerimientos son las especificaciones y condiciones necesarias que se
    deben cumplir para desarrollar un sistema de software eficaz.
    Por ejemplo, en una RFP sobre un software de tienda on-line, uno de los
    requerimientos es que la factura se imprima en papel y se adjunte al pedido
    físico. ¿Cuáles serían los requerimientos identificados por el usuario?
    1. Debe debe imprimir junto a la etiqueta de envío y devolución.
    2. El formato de la factura: la factura debe ser impresa en papel normal y
    otra parte es pegatina para las etiquetas, A4, con la fuente corporativa.
    3. El contenido de la factura: debe contener nombre y dirección del
    vendedor, nombre y dirección del comprador, descripción de los
    productos o servicios adquiridos, precios unitarios, cantidades,
    impuestos aplicables, total a pagar.
    4. El idioma de la factura: el idioma en el que debe estar redactada la
    factura impresa es el que indique el perfil del usuario.
    5. Se debe adjuntar al pedido físico: debe existir un mecanismo de
    control que asegurarse que la factura impresa se adjunte físicamente al
    pedido al momento de ser enviado, de manera que llegue al
    destinatario junto con los productos adquiridos.
    6. Debe poder ser enviado en copia digital: además de la versión impresa
    adjunta al pedido físico, nos debe enviar un PDF en un mail y una
    copia en el perfil del usuario disponible para su descarga desde el sitio
    web de la tienda online. Además, el PDF debe ser generado
    automáticamente a partir de la información de la factura y debe incluir
    todos los detalles pertinentes, como el nombre y dirección del
    vendedor, el nombre y dirección del comprador, la descripción de los
    productos o servicios adquiridos, los precios unitarios, las cantidades,
    los impuestos aplicables y el total a pagar.
    7. Cumplimiento legal: debe cumplir con los requisitos legales y fiscales
    aplicables en la jurisdicción correspondiente, incluyendo información
    obligatoria, numeración de facturas, requisitos de conservación de
    registros, etc.

    View Slide

  47. 46
    Los anteriores requerimientos son requerimientos de negocio y técnicos.
    Pocas veces vendrán separados de los requerimientos técnicos y funcionales,
    habitualmente vendrá mezclado como por ejemplo el punto 6.
    Como proveedor una pista que nos indica que estamos ante un
    requerimiento, ya sea técnico o funcional, es que encontremos frases con
    verbos que indican un tipo de intención, como, por ejemplo:
    Debe indica un requerimiento, me aventuro a decir, que en cualquier RFP
    que lo encuentres indica un requerimiento. Por ejemplo, “debe cumplir con
    los requisitos legales …” (punto 7)
    Debería, suele utilizarse para expresar un objetivo a alcanzar. Muchas veces
    parece que no es un requerimiento tal y como se puede usar, pero sí que es
    un requerimiento ya que el cliente esta diciendo que espera algo. Por
    ejemplo, “el programa debería mandar un mail con un pdf adjunto, …”
    Deseo, realizará, … verbos de la familia del “indicativo”, se usa más como una
    intención. Por ejemplo, “deseo que el proveedor pueda incluir una solución
    que permita seguir usando las impresoras que usamos en el almacén…”
    Los anteriores ejemplos nos llevan a realizar un pequeño paréntesis: ¿qué
    diferencia existe entre un requerimiento y una especificación?
    A veces se usan de forma intercambiada, pero existen diferencias sutiles
    entre estos términos.
    Los requerimientos son declaraciones de alto nivel que describen las
    necesidades y funciones esperadas del sistema, mientras que las
    especificaciones son documentos más detallados que proporcionan la
    información técnica necesaria para implementar y construir el sistema de
    software de acuerdo con los requerimientos establecidos. Las
    especificaciones se basan en los requerimientos y actúan como una guía
    técnica para los equipos de desarrollo.
    Debe Debería
    Deseo,
    realizará, ...

    View Slide

  48. 47
    También puedes definir los requerimientos como una suma de
    especificaciones. Las especificaciones se centran en el "cómo" se cumplirán
    los requerimientos. Proporcionan detalles técnicos, descripciones de
    interfaces, reglas de validación, formatos de datos, algoritmos y cualquier
    otro aspecto necesario para implementar y construir el sistema de software.
    Las especificaciones son más detalladas y se utilizan como referencia para el
    diseño.
    Los requerimientos los podemos encontrar definidos en estas categorías:
    Preguntas
    Que vienen a denotar una serie de peticiones ocultas o más bien problemas
    ocultos que los proveedores debemos saber responder. Por ejemplo:
    • ¿El sistema permite a los usuarios registrarse y crear una cuenta?
    • ¿Es posible realizar búsquedas por nombre de producto en la tienda en
    línea?
    • ¿El sistema proporciona un carrito de compras para que los usuarios
    agreguen productos antes de realizar el pago?
    Podéis observar que para cada pregunta podemos escribir cientos y cientos
    de líneas y diagramas, según se nos ocurra. Para no caer en esta “trampa”
    podemos tomar dos decisiones:
    • Responder con asunciones.
    • Hacer preguntas al cliente para que concrete que es lo que necesita.
    las asunciones se refieren a las suposiciones o premisas que se hacen al
    elaborar la propuesta. Estas asunciones son declaraciones que se consideran
    verdaderas o válidas en el contexto de la propuesta, pero que no se pueden
    confirmar o garantizar con certeza absoluta.
    Las asunciones en una propuesta ayudan a establecer ciertos parámetros y
    aclarar los límites o condiciones en las que se desarrollará el proyecto.
    Algunas de las áreas comunes en las que se pueden incluir asunciones en una
    son:

    View Slide

  49. 48
    1. Restricciones técnicas: Se pueden hacer asunciones sobre la
    disponibilidad de tecnologías o herramientas específicas, la
    compatibilidad con sistemas existentes, requisitos de infraestructura, etc.
    2. Restricciones de recursos: Pueden incluir asunciones sobre la
    disponibilidad de personal, habilidades técnicas, equipo necesario,
    capacidad de financiamiento, etc.
    3. Cronograma y plazos: Se pueden realizar asunciones sobre la duración del
    proyecto, las fechas de entrega, los hitos importantes, la disponibilidad de
    recursos clave, etc.
    4. Requisitos legales o regulatorios: Pueden incluir asunciones sobre el
    cumplimiento de ciertas leyes, regulaciones o estándares específicos.
    5. Condiciones del entorno: Se pueden realizar asunciones sobre el entorno
    operativo, el acceso a datos o recursos externos, el nivel de colaboración
    con otras partes interesadas, etc.
    Es importante que las asunciones se identifiquen y se comuniquen
    claramente en una propuesta para que todas las partes involucradas tengan
    una comprensión común de los supuestos en los que se basa la propuesta.
    Esto ayuda a evitar malentendidos y a establecer expectativas realistas
    durante el proceso de licitación y ejecución del proyecto.
    Cuidado con responder con un monosílabo a las respuestas anteriores,
    muchas veces a la pregunta: ¿El sistema permite a los usuarios registrarse y
    crear una cuenta? La respondemos con un sí (categórico) que conlleva a que
    el cliente pida absolutamente todo lo que se le pase por la cabeza: “ahora
    quiero un captcha”, “ahora quiero integración con SSO de Google, de
    Twitter”, mañana querrá “Facebook” así de forma indefinida. Lo ideal es
    responder con una serie de supuestos: te permitimos como máximo un SSO,
    no tendrá opción de cambio de contraseña, solo se permiten nombre de
    usuario y no cuentas de email, etc. etc.
    Declaraciones
    Por ejemplo:
    • El sistema debe ser PCI Compliance.

    View Slide

  50. 49
    • El SLA debe ser de un 99,99%.
    • El sistema de pagos debe admitir pago con tarjeta bancaria y PayPal.
    Para los usuarios registrados también vamos a permitir pagar con
    transferencia bancaria.
    Este tipo de declaraciones pueden llegar provocar una situación incomoda a
    los proveedores, podemos responder sí (categórico) como en las preguntas,
    pero además estamos dando pie a que no nos esforcemos en responder o que
    respondamos con una cantidad innecesaria de información.
    Cuando un cliente nos de este tipo de declaraciones debemos llevarlas a
    nuestro terreno, crear cuanta asunciones veamos necesarias, plantear
    restricciones técnicas o comerciales. Para dejar unas claras expectativas al
    cliente y evitar situaciones incomodas o conflictos en el proceso de ejecución
    del proyecto.
    Descripción narrativa
    Se refiere a una forma de expresar los requerimientos mediante narrativas o
    historias que describen escenarios o situaciones específicas en los que se
    espera que el sistema cumpla ciertas funcionalidades. Por tanto, no permiten
    el uso de declaraciones y preguntas.
    La descripción narrativa ayuda a visualizar y comprender mejor los
    requerimientos en acción, permitiendo a los equipos de desarrollo e
    involucrados en el proyecto obtener una visión más clara de cómo se espera
    que el sistema funcione en situaciones de la vida real. Esto puede ayudar a
    identificar posibles mejoras, detectar conflictos o inconsistencias en los
    requerimientos, y brindar una base sólida para el diseño y desarrollo del
    sistema.
    Las narrativas descriptivas pueden incluir detalles sobre el contexto del
    usuario, las interacciones con el sistema, las acciones realizadas y las
    respuestas esperadas. Por ejemplo, una descripción narrativa podría contar
    una historia sobre un usuario que visita una tienda en línea, navega por los
    productos, agrega artículos al carrito de compras, realiza el pago y recibe una
    confirmación de compra.
    Por ejemplo:

    View Slide

  51. 50
    Mónica, una usuaria registrada de nuestra tienda en línea, desea
    acceder a su cuenta para realizar una compra. Al ingresar al sitio web,
    se encuentra con la página de inicio de sesión, donde se le solicita que
    ingrese su dirección de correo electrónico y su contraseña.
    Mónica ingresa su dirección de correo electrónico asociada a su cuenta
    y luego teclea su contraseña en el campo correspondiente. Después de
    hacer clic en el botón 'Iniciar sesión', el sistema verifica la información
    ingresada.
    Si los datos son correctos, Mónica es redirigida a su perfil de usuario,
    donde puede ver su historial de compras, actualizar su información
    personal y acceder a funciones adicionales. Además, se muestra un
    mensaje de bienvenida personalizado para hacerla sentir valorada
    como cliente.
    En caso de que Mónica ingrese una dirección de correo electrónico o
    contraseña incorrectas, el sistema le muestra un mensaje de error
    indicando que los datos ingresados son inválidos. Además, se le ofrece
    la opción de restablecer su contraseña en caso de haberla olvidado.
    La sesión de Mónica se mantiene activa durante un período
    determinado de inactividad, para que pueda explorar el sitio web sin
    necesidad de iniciar sesión nuevamente. Sin embargo, si Mónica
    decide cerrar sesión manualmente, se le muestra un mensaje de
    confirmación y se redirige a la página de inicio.
    En resumen, el proceso de inicio de sesión permite a Mónica, nuestra
    usuaria registrada, acceder de manera segura a su cuenta,
    proporcionando su dirección de correo electrónico y contraseña. Si los
    datos son correctos, se le redirige a su perfil de usuario con un mensaje
    de bienvenida personalizado. En caso de error, se le notifica y se le
    brinda la opción de restablecer su contraseña. Además, se ofrece la
    opción de mantener la sesión activa durante un período determinado
    de inactividad
    Y los requerimientos que hemos podido extraer de este texto son:

    View Slide

  52. 51
    1. Autenticación: El sistema debe permitir a los usuarios registrados
    ingresar su dirección de correo electrónico y contraseña para
    autenticarse y acceder a sus cuentas.
    2. Verificación de datos: El sistema debe verificar la información
    ingresada por el usuario durante el inicio de sesión para garantizar la
    precisión de los datos y la seguridad del acceso.
    3. Redirección y acceso al perfil de usuario: Después de una autenticación
    exitosa, el sistema debe redirigir al usuario a su perfil de usuario,
    donde puede ver su historial de compras, actualizar información
    personal y acceder a funciones adicionales.
    4. Mensaje de bienvenida personalizado: El sistema debe mostrar un
    mensaje de bienvenida personalizado al usuario una vez que haya
    iniciado sesión, con el objetivo de hacerlo sentir valorado y brindar
    una experiencia personalizada.
    5. Gestión de errores: El sistema debe ser capaz de manejar y mostrar
    mensajes de error adecuados en caso de que se ingresen datos
    incorrectos durante el inicio de sesión, notificando al usuario que los
    datos son inválidos.
    6. Restablecimiento de contraseña: En caso de que se ingrese una
    contraseña incorrecta o se olvide, el sistema debe proporcionar una
    opción para que el usuario restablezca su contraseña, garantizando así
    la capacidad de recuperar el acceso a su cuenta.
    7. Sesión activa: El sistema debe permitir que la sesión del usuario
    permanezca activa durante un período determinado de inactividad, lo
    que evita que el usuario tenga que iniciar sesión nuevamente cada vez
    que realice acciones en el sitio web.
    Cuando nos enfrentamos a una narrativa, los proveedores podemos
    enfrentarnos a una serie de problemas:
    1. Ambigüedad en los requerimientos: Si la RFP está redactada de manera
    narrativa, puede haber ambigüedad en los requerimientos o falta de
    claridad en lo que se espera del proveedor. Las narrativas pueden ser
    interpretadas de diferentes maneras, lo que puede llevar a respuestas
    divergentes y dificultar la comparación de las propuestas recibidas.

    View Slide

  53. 52
    2. Falta de estructura y detalles: Las narrativas pueden carecer de la
    estructura y los detalles necesarios para que los proveedores
    comprendan plenamente los requerimientos y presenten propuestas
    sólidas. La falta de información específica puede dificultar la
    estimación precisa de los costos, los recursos necesarios y los plazos de
    entrega.
    3. Dificultad para cumplir con los criterios de evaluación: Si los criterios
    de evaluación no están claramente definidos en una RFP narrativa, los
    proveedores pueden tener dificultades para comprender cómo se
    evaluarán y se seleccionarán las propuestas. Esto puede llevar a
    respuestas inadecuadas o a una falta de enfoque en los aspectos que
    son más importantes para los solicitantes.
    4. Desalineación de expectativas: Las narrativas pueden dejar espacio
    para diferentes interpretaciones y expectativas entre los proveedores y
    los solicitantes. Esto puede generar discrepancias en las propuestas
    presentadas y dificultar el logro de un acuerdo común sobre los
    requisitos y las soluciones propuestas.
    5. Dificultad para demostrar cumplimiento: Si los requisitos se expresan
    en forma narrativa, los proveedores pueden encontrar desafíos para
    demostrar de manera clara y concreta cómo cumplirán con esos
    requerimientos. La falta de una estructura más precisa puede dificultar
    la presentación de argumentos sólidos y evidencias de que se
    cumplirán las necesidades del cliente.
    Para mitigar estos problemas, es importante que los clientes proporcionen
    orientación adicional, claridad y detalles. Pero como seguramente el cliente
    no nos lo dé así, debemos extraer secciones detalladas para que podamos
    hacer preguntas claras y presentar la propuesta de la forma más precisa y
    alineada con las expectativas del cliente.
    Los requisitos deben cumplir unos mínimos de calidad, sin esto, los
    proveedores tenemos la potestad de decirlo claramente al cliente. Si no ves esto
    en la propuesta del cliente, deberías empezar a pensar mal del cliente.

    View Slide

  54. 53
    Sobre la calidad de los requisitos
    • Los requisitos deben reflejar productos o servicio reales. Los requisitos
    deben reflejar con precisión las funcionalidades, características y
    restricciones que se requieren en el producto o servicio final. Los
    requisitos deben ser realistas y alcanzables, considerando las
    limitaciones técnicas, los recursos disponibles y las necesidades del
    cliente. Al asegurarse de que los requisitos reflejen productos o
    servicios reales, se evita la creación de requisitos excesivamente
    ambiciosos o poco prácticos que no se puedan lograr en la
    implementación. También ayuda a establecer expectativas claras y
    realistas entre los stakeholders, los equipos de desarrollo y los clientes.
    Además, los requisitos que reflejan productos o servicios reales
    brindan una base sólida para el diseño, desarrollo y prueba del sistema.
    Ayudan a garantizar que el producto final cumpla con las necesidades
    y expectativas de los usuarios, y que sea funcionalmente coherente con
    lo que se espera lograr.
    • Los requerimientos no deben ser ambiguos. Significa que los
    requerimientos deben ser claros, precisos y libres de ambigüedad.
    Cuando los requerimientos son ambiguos, existen diferentes
    interpretaciones posibles o falta de claridad sobre lo que se espera.
    Esto puede llevar a malentendidos, problemas de comunicación y
    resultados insatisfactorios. Los requerimientos ambiguos pueden
    dificultar la implementación del sistema, ya que los desarrolladores
    pueden tener dificultades para comprender completamente los
    objetivos y las funcionalidades requeridas. Para evitar ambigüedades
    en los requerimientos, es importante que estén redactados de manera
    clara, específica y sin ambigüedades. Deben ser lo suficientemente
    detallados y preciso para que no quede lugar a dudas o
    interpretaciones erróneas. Además, es importante establecer un
    proceso de revisión y validación de los requerimientos para garantizar
    que se entiendan correctamente y sean consistentes con las
    necesidades y expectativas de los stakeholders involucrados.
    • Los requisitos no deben estar redactados de forma ambigua. Significa
    que, al definir los requisitos, es importante evitar cualquier tipo de

    View Slide

  55. 54
    ambigüedad en su redacción. Esto implica que los requisitos deben ser
    claros, precisos y no dejar lugar a interpretaciones diversas o
    confusiones. La ambigüedad en los requisitos puede conducir a
    malentendidos, dificultades en la implementación y resultados
    insatisfactorios en el desarrollo del software. Cuando los requisitos son
    ambiguos, los desarrolladores pueden tener dificultades para
    comprender exactamente lo que se espera de ellos y pueden tomar
    decisiones incorrectas o basadas en suposiciones incorrectas. Para
    evitar la ambigüedad, los requisitos deben ser expresados de manera
    precisa, utilizando un lenguaje claro y conciso. Deben describir
    claramente qué se espera del sistema, qué funcionalidades o
    características debe tener, qué restricciones existen y cualquier otro
    detalle relevante. Además, es importante que los requisitos sean
    coherentes entre sí y no entren en conflicto. Cuando se redactan los
    requisitos, es útil ser específico y evitar términos vagos o ambiguos. Es
    importante tener en cuenta el contexto y las necesidades de los
    usuarios y las partes interesadas para asegurarse de que los requisitos
    sean comprensibles y abarquen todas las expectativas relevantes. Al
    mantener los requisitos libres de ambigüedad, se facilita la
    comunicación clara y efectiva entre los equipos de desarrollo, los
    stakeholders y los proveedores de software, lo que ayuda a garantizar
    que el sistema se construya de acuerdo con las expectativas y
    necesidades establecidas.
    • Los requisitos deben ser medibles. Significa que los requerimientos
    establecidos deben ser específicos y cuantificables, de manera que sea
    posible evaluar y verificar su cumplimiento de manera objetiva y clara.
    Cuando se establece que los requisitos deben ser medibles, se busca
    evitar ambigüedades y asegurar que se puedan establecer criterios
    claros para determinar si un requerimiento ha sido satisfecho o no.
    Esto implica que los requisitos deben ser formulados de tal manera que
    permitan definir métricas, indicadores o criterios de éxito para evaluar
    su cumplimiento. Al ser medibles, los requisitos se convierten en
    objetivos alcanzables y evaluables, lo que facilita la planificación, el
    seguimiento y la verificación del progreso del proyecto. Además, la
    medición permite realizar pruebas de aceptación para validar que los

    View Slide

  56. 55
    requerimientos se cumplen adecuadamente. Por ejemplo, en lugar de
    tener un requerimiento vago como "el sistema debe ser rápido", un
    requisito medible sería "el sistema debe cargar una página en un
    tiempo máximo de 250 ms ". En este caso, el tiempo de carga se
    convierte en una métrica objetiva que puede ser medida y comparada
    con el objetivo establecido.
    • Los requisitos deben ser significativos. Implica que los requisitos
    establecidos en un contexto determinado deben ser relevantes,
    importantes y tener un impacto significativo en el sistema o proyecto
    en cuestión. Cuando se menciona que los requisitos deben ser
    significativos, se enfatiza la importancia de establecer requerimientos
    que sean relevantes para el objetivo y la finalidad del proyecto. Estos
    requisitos deben contribuir de manera significativa al funcionamiento,
    rendimiento o valor general del sistema que se está desarrollando. Al
    asegurarse de que los requisitos sean significativos, se evita incluir
    elementos innecesarios o superfluos que puedan agregar complejidad o
    costos adicionales sin un beneficio real. Por lo tanto, se busca
    establecer requerimientos que sean esenciales para cumplir con los
    objetivos y satisfacer las necesidades de los usuarios o las partes
    interesadas involucradas. Es importante tener en cuenta que el
    significado de los requisitos puede variar según el contexto y los
    objetivos específicos del proyecto. Por lo tanto, es fundamental definir
    claramente los criterios y métricas para determinar la relevancia y el
    significado de los requisitos, lo que puede facilitar la toma de
    decisiones y la priorización adecuada durante el proceso de desarrollo
    del software.
    • El requisito debe estar completo. Indica que el requisito en cuestión
    debe estar detallado de manera exhaustiva y no debe haber
    información faltante o ambigua. En otras palabras, se espera que el
    requisito esté totalmente especificado, sin dejar cabos sueltos o
    ambigüedades que puedan generar confusiones o malentendidos
    durante el proceso de desarrollo o implementación del sistema de
    software. Al requerir que un requisito esté completo, se busca
    garantizar que todas las partes involucradas tengan una comprensión
    clara y precisa de lo que se espera y que no queden aspectos abiertos a

    View Slide

  57. 56
    la interpretación. Esto es esencial para la correcta implementación del
    requisito y para evitar malentendidos o desviaciones en el desarrollo
    del software. Un requisito completo debe incluir todos los detalles
    necesarios, como las funcionalidades específicas que se requieren, los
    comportamientos esperados, los criterios de rendimiento, las
    restricciones técnicas o de recursos, y cualquier otro elemento
    relevante para definir completamente el alcance y el funcionamiento
    del sistema. Si esto no sucede añade todas las asunciones posibles para
    dejarlo lo más detallado posible por tu parte al escribir la respuesta a la
    RFP.
    • Los requerimientos no deben incluir la solución. Significa que, al
    definir los requerimientos de un proyecto o sistema, es importante
    enfocarse en describir qué se necesita lograr, en lugar de como se debe
    lograr. Cuando se definen los requerimientos, se busca establecer las
    funcionalidades, características y restricciones del sistema de software,
    sin entrar en detalles específicos de cómo implementar esas
    funcionalidades. Los requerimientos deben centrarse en los "qué" en
    lugar de en el "cómo". La razón detrás de esta recomendación es
    permitir flexibilidad y opciones al equipo de desarrollo. Al evitar la
    especificación de la solución en los requerimientos, se da libertad al
    equipo para explorar diferentes enfoques y tecnologías que puedan
    cumplir con los requerimientos de manera eficiente y efectiva. Al
    separar los requerimientos de la solución, también se evita limitar las
    opciones y las posibilidades de innovación. Permite que el equipo de
    desarrollo utilice su experiencia y conocimientos para encontrar la
    mejor manera de abordar los requerimientos, adaptándose a las
    condiciones y restricciones del proyecto.
    • Los requisitos no deben incluir características superfluas e
    innecesarias. Se refiere a la importancia de evitar la inclusión de
    funcionalidades o elementos en los requisitos de un proyecto o sistema
    que no sean realmente necesarios o que no aporten valor significativo.
    En el contexto de la ingeniería de software, los requisitos son las
    descripciones detalladas de las funcionalidades, comportamientos y
    restricciones que se esperan de un sistema o software. Estos requisitos
    definen qué debe hacer el sistema y cómo debe comportarse para

    View Slide

  58. 57
    satisfacer las necesidades de los usuarios y clientes. La frase indica que
    se debe evitar agregar características adicionales o innecesarias en los
    requisitos. Esto significa que se deben incluir únicamente las
    funcionalidades esenciales y relevantes para cumplir con los objetivos
    del sistema y las necesidades de los usuarios. No se deben agregar
    características superfluas que puedan complicar la implementación,
    aumentar los costos, afectar el rendimiento o confundir a los usuarios.
    Al mantener los requisitos enfocados en las necesidades reales y
    esenciales, se busca optimizar el proceso de desarrollo y garantizar que
    los recursos se utilicen de manera eficiente para implementar las
    funcionalidades fundamentales y valiosas para los usuarios finales.
    ¿Requisitos técnicos?
    Son aquellos que los clientes nos cuentan, de forma narrativa (a veces
    acompañada de ilustraciones), lo que hacen y por qué lo hacen.
    Habitualmente vienen expresados como una “necesidad”, por ejemplo:
    • Necesitamos que nuestros clientes puedan ver el stock en tiempo real,
    no queremos hacer esperar a nuestros clientes.
    • Para que la experiencia de compra esté en consonancia con nuestros
    productos deportivos necesitamos que la tienda on-line transmita
    nuestros valores.
    • Necesitamos que el conocimiento técnico tras la ejecución del
    proyecto quede dentro de nuestra organización.
    Como podéis observar, todas las frases están construidas más o menos igual:
    • Necesidad, stock en tiempo real.
    • Objetivo, proporcionar información actualizada al cliente.
    • Razón de negocio, no hacer esperar a los clientes.
    Por lo tanto, esto requerimientos cumplen con un punto importante: que
    sean medibles:

    View Slide

  59. 58
    Requerimiento Objetivo Medición
    ..puedan ver el
    stock…
    Proporcionar
    información
    actualizada al cliente.
    Se pueden usar diferentes
    acciones:
    - Tiempo de respuesta
    del stock.
    - Precisión del stock.
    - Nivel de satisfacción
    del cliente.
    3.2.4.2 Anatomía de la sección técnica
    Veamos los elementos comunes de una sección técnica. Cuando
    respondemos a la RFP los clientes suelen quedarse en la parte de formatos de
    ficheros, integraciones con terceros, Stack tecnológico de su organización,
    etc. Lo que deberían incluir y casi nunca lo incluyen nos servirá como guía
    para poder responder como proveedor y a los clientes esto os servirá de guía
    para saber cómo afrontar esta sección.
    Actual entorno empresarial (funcional)
    Se refiere al contexto y los elementos existentes en la organización
    solicitante antes de la implementación de la nueva aplicación. Es importante
    describir el actual entorno empresarial para que los proveedores de software
    comprendamos los sistemas, las tecnologías y los procesos que ya están en
    uso. Esto permite evaluar cómo la solución propuesta se integrará con el
    entorno existente y cumplirá con los requisitos y necesidades específicas de
    la organización.
    Algunos aspectos que se pueden incluir en la descripción del actual entorno
    empresarial son:
    1. Infraestructura tecnológica: implica describir los sistemas operativos,
    bases de datos, servidores, redes y otros componentes de
    infraestructura utilizados en la organización.
    2. Aplicaciones y sistemas existentes: se deben mencionar las
    aplicaciones de software y los sistemas utilizados actualmente en la
    organización, indicando sus funciones, integraciones y limitaciones.

    View Slide

  60. 59
    3. Procesos y flujos de trabajo: se debe describir cómo se llevan a cabo las
    operaciones y los procesos empresariales en la organización,
    incluyendo cualquier flujo de trabajo, automatizaciones o
    integraciones existentes.
    4. Políticas y estándares: se deben mencionar las políticas y los
    estándares tecnológicos en vigor en la organización, como políticas de
    seguridad, requisitos de cumplimiento normativo u otras directrices
    relevantes.
    Por ejemplo, que podría pedirnos un cliente:
    "[Nombre_Tienda]" nos hemos expandido significativamente en los
    últimos años y hemos experimentado un aumento en el volumen de
    pedidos y la gestión del inventario. Actualmente, gran parte de los
    procesos, como la actualización manual del inventario, el seguimiento
    de envíos y la generación de informes, se realizan de forma manual, lo
    que ha llevado a errores, retrasos y una falta de eficiencia operativa.
    Para abordar estos desafíos, "[Nombre_Tienda]" hemos decidido
    buscar una solución tecnológica que automatice y optimice sus
    operaciones comerciales. Para ello, hemos emitido una RFP para
    seleccionar un proveedor de software especializado en comercio
    electrónico.
    Entre las necesidades identificadas "[Nombre_Tienda]" se encuentran:
    1. Automatización del inventario: La tienda necesita un sistema de
    gestión de inventario que actualice automáticamente las
    existencias y la disponibilidad de productos en tiempo real. Esto
    debe incluir notificaciones automáticas de stock bajo y
    reabastecimiento de productos.
    2. Procesamiento de pedidos: buscamos una solución que permita
    el procesamiento automatizado de pedidos, incluyendo la
    generación de facturas y confirmaciones de envío, así como la
    integración con servicios de envío para generar etiquetas y
    rastrear los envíos.
    3. Informes y análisis: necesitamos una plataforma que genere
    informes y análisis detallados sobre las ventas, el rendimiento del

    View Slide

  61. 60
    inventario y otras métricas clave del negocio. Estos informes
    deben ser personalizables y actualizarse automáticamente.
    4. Integraciones: debemos integrar la nueva solución con su
    plataforma de comercio electrónico existente, así como con otros
    sistemas internos, contabilidad y CRM.
    Como proveedores vamos a responder a esto:
    Después de revisar detenidamente sus necesidades, me complace
    presentar nuestra propuesta. Nuestra solución se centra en abordar los
    desafíos clave que ustedes han identificado:
    1. Automatización del inventario: Proponemos implementar un
    sistema de gestión de inventario que actualice en tiempo real las
    existencias y la disponibilidad de productos. Nuestra solución
    enviará notificaciones automáticas de stock bajo y ofrecerá
    funcionalidades avanzadas de reabastecimiento, asegurando que
    siempre tengan control sobre su inventario.
    2. Procesamiento de pedidos: Implementaremos un proceso
    automatizado de procesamiento de pedidos que incluye la
    generación automática de facturas y confirmaciones de envío.
    Además, integraremos su plataforma de comercio electrónico con
    servicios de envío confiables para generar etiquetas y realizar un
    seguimiento en tiempo real de los envíos.
    3. Informes y análisis: Nuestra solución incluirá un potente módulo de
    generación de informes y análisis. Podrán acceder a informes
    personalizables sobre ventas, rendimiento de inventario y otras
    métricas clave del negocio. Estos informes se actualizarán
    automáticamente, brindándoles información relevante y oportuna
    para la toma de decisiones estratégicas.
    4. Integraciones: Nos aseguraremos de que nuestra solución se integre
    sin problemas con su plataforma de comercio electrónico existente,
    así como con otros sistemas internos, como contabilidad y CRM.
    Esto permitirá una transferencia de datos fluida y una experiencia
    coherente en toda su organización.

    View Slide

  62. 61
    Como podéis observar ya tenéis claro como deberíamos ambas partes
    comportarnos en esta sección.
    Actual entorno técnico
    Se refiere al contexto y la infraestructura tecnológica existente en la
    organización solicitante antes de la implementación de la nueva aplicación.
    En una RFP, es importante describir el actual entorno técnico para que los
    proveedores de software comprendamos los sistemas, las tecnologías y los
    recursos con los que la nueva aplicación debe ser compatible y funcionar de
    manera integrada. Esto nos permite evaluar cómo su solución propuesta se
    alinea con el entorno existente y cumple con los requisitos técnicos y de
    interoperabilidad.
    Algunos aspectos que se pueden incluir en la descripción del actual entorno
    técnico son:
    1. Infraestructura de hardware: Esto implica describir los servidores,
    estaciones de trabajo, dispositivos de red y otros componentes de
    hardware utilizados en la organización, junto con sus capacidades y
    especificaciones técnicas.
    2. Infraestructura de software: Se debe mencionar el sistema operativo y
    las aplicaciones de software utilizadas actualmente en la organización,
    indicando las versiones y las configuraciones específicas.
    3. Bases de datos y almacenamiento de datos: Se deben describir las bases
    de datos utilizadas, como los sistemas de gestión de bases de datos
    (SGBD) y los sistemas de almacenamiento de datos. También se
    pueden mencionar las políticas de respaldo y recuperación de datos.
    4. Integraciones existentes: Si la organización ya utiliza sistemas o
    aplicaciones específicas que deben integrarse con la nueva aplicación,
    es importante mencionar estas integraciones y las interfaces técnicas
    utilizadas.
    5. Requisitos de seguridad y cumplimiento normativo: Se deben
    mencionar los protocolos y las políticas de seguridad implementadas
    en la organización, así como los requisitos de cumplimiento normativo
    que la nueva aplicación debe cumplir.

    View Slide

  63. 62
    Por ejemplo, que podría pedirnos un cliente:
    Somos [Nombre_Tienda], una tienda en línea líder en la venta de
    productos electrónicos. Hemos experimentado un crecimiento
    significativo en los últimos años y hemos realizado esfuerzos para
    digitalizar nuestra operación. Sin embargo, durante los eventos de
    Black Friday y otros períodos de alta demanda, nos hemos enfrentado
    a desafíos significativos en nuestra capacidad para brindar un servicio
    óptimo a nuestros clientes.
    Para abordar estos desafíos y garantizar una experiencia de compra
    excepcional durante los picos de demanda, hemos decidido emitir una
    RFP para seleccionar un proveedor de software especializado.
    Buscamos una solución que nos permita superar las limitaciones
    actuales y mejorar nuestra capacidad para atender a un alto volumen
    de clientes de manera eficiente y sin interrupciones.
    Algunas de nuestras necesidades clave que esperamos abordar a través
    de esta RFP son las siguientes:
    1. Escalabilidad y rendimiento: Necesitamos una solución que nos
    permita escalar rápidamente nuestros recursos de infraestructura
    y garantizar un rendimiento óptimo del sitio web durante
    períodos de alta demanda. Queremos evitar caídas del sitio,
    tiempos de carga lentos y errores en el proceso de compra.
    2. Administración de inventario: Buscamos una solución que nos
    ayude a gestionar nuestro inventario de manera más eficiente
    durante los eventos de Black Friday y otras promociones.
    Necesitamos una visibilidad en tiempo real de las existencias,
    una gestión automatizada del inventario y alertas para
    reabastecimiento de productos.
    3. Procesamiento de pedidos y pagos: Queremos mejorar la
    velocidad y la precisión del procesamiento de pedidos y pagos
    durante los períodos de alta demanda. Necesitamos una solución
    que nos permita manejar transacciones simultáneas de manera
    segura y sin interrupciones, minimizando los errores y

    View Slide

  64. 63
    garantizando una experiencia de compra fluida para nuestros
    clientes.
    4. Atención al cliente: Buscamos una solución que mejore nuestra
    capacidad para brindar un servicio al cliente excepcional durante
    los eventos de alta demanda. Esto puede incluir opciones de chat
    en vivo, gestión de consultas y seguimiento eficiente de los
    problemas planteados por nuestros clientes.
    Como proveedores vamos a responder a esto:
    Nuestra propuesta se basa en el uso de Kubernetes para administrar y escalar
    su infraestructura de manera flexible y dinámica. A continuación, detallamos
    cómo abordaremos sus necesidades:
    1. Escalabilidad y rendimiento: Implementaremos una arquitectura
    basada en Kubernetes que nos permitirá escalar rápidamente los
    recursos de infraestructura según la demanda. Utilizaremos
    autoscaling y orquestación de contenedores para garantizar un
    rendimiento óptimo del sitio web incluso en momentos de alta
    demanda. Además, aprovecharemos las capacidades de balanceo de
    carga de Kubernetes para distribuir eficientemente el tráfico entrante y
    garantizar una experiencia de usuario fluida.
    2. Administración de inventario: Desarrollaremos una solución
    personalizada que integre su sistema de gestión de inventario actual
    con Kubernetes. Esto permitirá una actualización en tiempo real de las
    existencias y una gestión automatizada del inventario en consonancia
    con los picos de demanda.
    3. Procesamiento de pedidos y pagos: Implementaremos microservicios
    en Kubernetes para gestionar el procesamiento de pedidos y pagos de
    manera eficiente y segura. Utilizaremos contenedores aislados para
    cada paso del proceso, lo que permitirá una mayor escalabilidad y
    confiabilidad. Además, aprovecharemos las capacidades de gestión de
    colas y balanceo de carga de Kubernetes para garantizar una
    distribución equitativa y rápida del flujo de trabajo de los pedidos y
    pagos.

    View Slide

  65. 64
    4. Atención al cliente: Desarrollaremos un sistema de atención al cliente
    basado en Kubernetes que incluirá opciones de chat en vivo y
    herramientas de seguimiento de consultas. Esto permitirá una
    comunicación fluida y una resolución eficiente de problemas durante
    los momentos de alta demanda. Además, utilizaremos la
    monitorización en tiempo real de Kubernetes para detectar y
    responder rápidamente a cualquier problema que pueda surgir.
    3.2.4.3 Tablas de resúmenes
    Veamos los elementos comunes de una sección técnica. Cuando
    respondemos a la RFP los clientes suelen quedarse en la parte de formatos de
    ficheros, integraciones con terceros, Stack tecnológico de su organización,
    etc. Lo que deberían incluir y casi nunca lo incluyen nos servirá como guía
    para poder responder como proveedor y a los clientes esto os servirá de guía
    para saber cómo afrontar esta sección.
    Actual entorno empresarial (funcional)
    Se refiere al contexto y los elementos existentes en la organización
    solicitante antes de la implementación de la nueva aplicación. Es importante
    describir el actual entorno empresarial para que los proveedores de software
    comprendamos los sistemas, las tecnologías y los procesos que ya están en
    uso. Esto permite evaluar cómo la solución propuesta se integrará con el
    entorno existente y cumplirá con los requisitos y necesidades específicas de
    la organización.
    3.2.5 Entregables
    La sección de entregables de tu propuesta responderá a la pregunta del
    cliente: "¿Qué voy a obtener?". Esta sección y la sección de precios son a
    menudo donde el cliente potencial presta más atención. El cliente quiere
    asegurarse de que al final del día se entregará el producto esperado al precio
    acordado.
    Tu lista final de entregables debe ser detallada, organizada e incluir
    referencias a los servicios aplicables descritos.
    Para crear tu lista de entregables, debes examinar cada en la respuestas
    administrativas y técnica para ver si puedes responderte a estas preguntas:

    View Slide

  66. 65
    "¿Qué elementos tangibles voy a entregar al cliente durante esta fase del
    proyecto?".
    En una aplicación de software, algunos ejemplos de elementos tangibles que
    podrías entregar como parte de los entregables podrían incluir:
    • Documentación técnica: Manuales de usuario, guías de instalación,
    documentación de API, descripciones de arquitectura, etc.
    • Código fuente: Los archivos de código que conforman la aplicación,
    incluyendo scripts, clases, archivos de configuración, etc.
    • Interfaces de usuario: Diseños de pantalla, maquetas interactivas,
    elementos gráficos, iconos, etc.
    • Base de datos: Esquema de base de datos, scripts de creación y
    población de la base de datos, datos de prueba, etc.
    • Informes y análisis: Informes generados por la aplicación, tablas y
    gráficos de análisis, datos procesados, etc.
    • Integraciones: Conexiones y adaptadores para integrar la aplicación
    con otros sistemas o servicios externos.
    • Herramientas y utilidades: Scripts, herramientas de migración de
    datos, utilidades de administración del sistema, etc.
    • Pruebas y validación: Resultados de pruebas unitarias, pruebas de
    integración, pruebas de aceptación, informes de errores corregidos,
    etc.
    • Capacitación y material educativo: Materiales de capacitación,
    tutoriales, videos explicativos, presentaciones, etc.
    • Soporte técnico: Acuerdos de nivel de servicio, contratos de soporte,
    canales de comunicación para solicitar asistencia, etc.
    Además de los elementos mencionados anteriormente, si has realizado
    análisis UX/UI y temas de infraestructura en el desarrollo de la aplicación de
    software, puedes incluir los siguientes elementos tangibles en tus
    entregables:
    • Diseño de experiencia de usuario (UX): Wireframes, mapas de
    navegación, prototipos interactivos, flujos de usuario, etc. Estos
    elementos representan la estructura y el flujo de la aplicación,
    ayudando a definir cómo los usuarios interactuarán con ella.

    View Slide

  67. 66
    • Diseño de interfaz de usuario (UI): Diseños visuales de la interfaz,
    paleta de colores, tipografía, estilos y componentes visuales. Estos
    elementos dan vida a la apariencia y estilo visual de la aplicación,
    creando una experiencia atractiva y coherente para los usuarios.
    • Arquitectura de infraestructura: Diagramas de arquitectura de la
    infraestructura tecnológica necesaria para la aplicación, incluyendo
    servidores, redes, sistemas de almacenamiento, balanceadores de
    carga, bases de datos, servicios en la nube, entre otros. Estos elementos
    describen cómo se estructura y organiza la infraestructura para
    soportar el funcionamiento de la aplicación.
    • Configuraciones de infraestructura: Documentación y archivos de
    configuración necesarios para implementar y desplegar la aplicación
    en la infraestructura, incluyendo scripts de implementación, archivos
    de configuración del servidor, políticas de seguridad, etc.
    • Optimización y rendimiento: Informes y resultados de pruebas de
    rendimiento, optimizaciones realizadas en la aplicación para mejorar
    la velocidad de respuesta, escalabilidad y eficiencia en el consumo de
    recursos.
    • Seguridad y cumplimiento normativo: Planes y documentación
    relacionados con la seguridad de la aplicación, auditorías de seguridad
    realizadas, certificaciones de cumplimiento normativo, como GDPR o
    HIPAA, y cualquier otro aspecto relacionado con la protección de
    datos y la seguridad de la aplicación.
    Como apreciación personal y para enlazar con los precios, nunca asocies
    entregables con hitos de facturación.
    3.2.6 El Precio
    Las RFP tienen dos hitos importantes:
    • Cumplir con los requisitos que nos pide el cliente.
    • Que nuestro precio entre en el presupuesto del cliente.

    View Slide

  68. 67
    Uno de ellos podemos hacerlo sin problemas y el otro es “nuestro” precio, lo
    que valen nuestros servicios, como arquitecto/a de soluciones, aquí debemos
    dar el precio que nuestra empresa ofrece a los clientes por los servicios que
    vamos a prestar.
    Otro tema que no nos debería concernir y el cual genera fricciones en los
    equipos, es el ajuste por qué la persona que gestiona la cuenta intuye (por que
    sabe el presupuesto del cliente) o por que cree que estamos fuera con X precio.
    En ambas opciones, la respuesta de arquitectura debe ser bajar o eliminar
    elementos que puedan bajar, pero sin comprometer la estructura de la
    aplicación tanto técnica como administrativa.
    Lo que es importante que sepas también, es que esta tendencia a bajar precios
    puede jugar en tu contra. Muchos clientes no se fían de los outlier por exceso o
    defecto. Mucho cuidado con esto.
    Personalmente, me gusta que el precio se presente con un formato consistente y preciso,
    ya que esto me brinda una mayor claridad y transparencia en cuanto a los costos
    asociados con el proyecto. Al recibir una propuesta con un formato uniforme, puedo
    comparar de manera más efectiva las diferentes opciones disponibles y entender cómo se
    distribuyen los costos en cada componente o actividad del proyecto.
    Además, al requerir un formato preciso, puedo asegurarme de que el precio
    proporcionado sea detallado y específico. Esto me permite comprender exactamente qué
    está incluido en el costo y cómo se ha calculado, evitando ambigüedades o estimaciones
    aproximadas. La precisión en la presentación del precio me brinda confianza al saber que
    el proveedor ha realizado un análisis minucioso y ha considerado todos los elementos
    necesarios para ofrecer un presupuesto preciso.
    Como cliente esto te debería interesar mucho; un formato consistente y preciso en la
    presentación del precio, permite evaluar y comparar las propuestas de manera eficiente,
    entender la distribución de costos y tener una imagen clara de los gastos totales. Te
    ayudará a tomar decisiones informadas y a garantizar que el presupuesto sea adecuado y
    acorde con tus necesidades y expectativas.
    3.2.6.1 Anatomía de los precios
    Aquí lo primero es deciros que seguramente vuestra organización disponga
    de una plantilla de EXCEL, MS Project, herramienta interna, etc. que será lo
    que tengas que usar para la estimación del precio.

    View Slide

  69. 68
    Como arquitecto/a de soluciones tendrás tu método para asignar un peso a
    cada tipo de requerimiento. En esto no os puedo ayudar mucho por qué la
    experiencia que tengáis será determinante y sobre todo porque sabéis como
    y cuanto tardan vuestros recursos asignables.
    Tienes que discernir entre dos tipos de información que se pone en
    conocimiento o pide el cliente:
    • Un orden de magnitud, que es una estimación con una horquilla
    máxima y mínima, es una estimación rápida que nos permitirá saber si
    el cliente esta dispuesto a continuar con la RFP y a veces nos lo piden
    en la primera semana. Es una forma de no hacer perder tiempo a los
    proveedores. Aunque esto debería ser siempre una RFP, pero en la
    práctica no suele ser así y nos toca trabajar con la RFP y este tipo de
    reunión con precio preliminar. En otras ocasiones los proveedores,
    aunque lo pidan y luego quieran la RFP ya saben que no te cogerán…
    esto ya entra en la ética de cada empresa.
    • Un precio final cerrado, el cliente quieren el precio final de todo el
    proyecto y bien detallado.
    • Cuando estamos en un Time & Materials, si eres el cliente yo me
    cuidaría mucho de al menos tener bien claro que vamos a entregar y
    cuando, aunque luego existan alcances, pero por lo menos tengas bien
    claro que es lo mínimo que necesitas de esas personas y tiempo para
    hacer una estimación inicial. Muchas veces veo que es un body-
    shopping que afecta siempre al proveedor perdiendo talento por el
    desorden existente en el cliente y el abandono de la consultora. Como
    proveedor existes un plan inicial y un pequeño estudio del proyecto
    darás a entender al cliente y tus empleados que no eres un body-
    shopping, esto además incide en que tus clientes no deberían verse
    afectados tanto con la rotación de personal de estas empresas de
    servicios.
    Por tanto, voy a centrarme más en otros aspectos más cuantificables sin
    entrar en juego en los que tengas en tu organización, pero habitualmente
    tendrás que estimar a:

    View Slide

  70. 69
    Nivel técnico
    • Hardware, sí, lo lees bien, el hardware existe o es que pensáis que todo
    va en el cloud. Por ejemplo, tu aplicación necesita unas ¿HoloLens de
    Microsoft?, ¿necesitas tabletas rugerizadas con impresora portátil?, etc.
    Ves como puedes asignar hardware en una RFP en la era del Cloud.
    • Software de sistema y aplicación. Licencias de terceros para por
    ejemplo usar una VPN o controles que aclararen el desarrollo de una
    aplicación Web o certificados para sitios web o licencias de entornos
    de desarrollo o licencias de sistemas operativos o licencias de
    herramientas de monitorización.
    • Consumibles, pues sí, imagina que tienes que hacer una impresión de
    etiquetas térmicas en las Tablet, pues el papel el los consumibles. O
    haces grabación de tarjetas de RFID, aquí tienes otro consumible.
    • Y por supuesto estimaciones del consumo de recursos Cloud.
    Nivel administrativo
    • Desde la administración del proyecto hasta los servicios gestionados
    (incluyendo personal on/off-site).
    • Integraciones entre hardware y software propietario. En este caso por
    ejemplo coordinar equipos de desarrollo y equipo del propietario de
    ese hardware tan especializado, desde como instalarlo hasta como
    programarlo.
    • Desarrollo de la aplicación a medida.
    • Instalaciones.
    • Test de aceptación.
    • Mantenimiento.
    • Formación y transferencias de conocimiento.
    • Documentación.
    • Asignación de personal.
    • Gestión del cambio y mejoras.
    • Gestión de viajes y dietas.
    • Etc.

    View Slide

  71. 70
    ¿Desarrollo de software a medida?
    Por ejemplo, estas son algunas de las acciones que debes tener en cuenta
    cuando desarrollas software a medida:
    1. Planificación del proyecto: Definir los objetivos del proyecto,
    establecer los plazos, identificar los entregables y determinar los
    recursos necesarios para llevar a cabo el desarrollo.
    2. Creación del equipo de proyecto: Asignar roles y responsabilidades
    dentro del equipo, incluyendo el gerente de proyecto, analistas,
    diseñadores, desarrolladores y especialistas en calidad.
    3. Establecimiento de un sistema de comunicación: Establecer canales de
    comunicación efectivos para garantizar una comunicación clara y
    constante entre los miembros del equipo, los clientes y otras partes
    interesadas.
    4. Seguimiento y control del proyecto: Realizar un seguimiento regular
    del progreso del proyecto, supervisar el cumplimiento de los plazos y
    los hitos clave, y tomar medidas correctivas cuando sea necesario.
    5. Gestión del alcance: Definir y controlar los límites y las
    funcionalidades del proyecto para evitar cambios o desviaciones no
    planificadas.
    6. Gestión de riesgos: Identificar los riesgos potenciales y desarrollar
    planes de mitigación para minimizar su impacto en el proyecto.
    Realizar un monitoreo continuo de los riesgos a lo largo del desarrollo.
    7. Gestión de cambios: Evaluar y gestionar los cambios solicitados por el
    cliente o identificados durante el desarrollo, considerando su impacto
    en los plazos, el presupuesto y los recursos.
    8. Establecimiento de métricas y métricas de rendimiento: Definir
    métricas y criterios para evaluar el rendimiento del proyecto, como la
    calidad del software, el cumplimiento de los plazos y la satisfacción del
    cliente.
    9. Gestión de presupuesto: Establecer un presupuesto detallado y realizar
    un seguimiento de los gastos a lo largo del proyecto. Controlar los
    costos y hacer ajustes si es necesario.
    10. Reportes y documentación: Generar informes periódicos para el cliente
    y otras partes interesadas, brindando actualizaciones sobre el progreso,

    View Slide

  72. 71
    el rendimiento y los hitos alcanzados. Documentar los procesos,
    decisiones y cambios importantes durante el desarrollo.
    11. Gestión de la calidad: Establecer estándares de calidad y realizar
    pruebas y revisiones para garantizar que el software desarrollado
    cumpla con los requisitos y expectativas establecidos.
    12. Implementación y puesta en marcha: Coordinar la implementación del
    software desarrollado, realizar pruebas de aceptación y asegurarse de
    que el producto final esté listo para su uso.
    Tal y como puede observar, el trabajo administrativo es mucho y diverso,
    que cambiará según sea el tipo de tu aplicación.
    ¿Desarrollo de extensión sobre software de producto?
    Por ejemplo, estas son algunas de las acciones que debes tener en cuenta
    cuando desarrollas extensiones para un producto:
    1. Análisis de requisitos: Comprender completamente los requisitos y
    necesidades del cliente o usuarios finales para la extensión. Identificar
    las funcionalidades y características específicas que se deben agregar al
    producto base.
    2. Evaluación de la arquitectura del producto base: Analizar la
    arquitectura y estructura del producto base para determinar cómo se
    pueden integrar y extender las nuevas funcionalidades de manera
    eficiente y coherente.
    3. Diseño y planificación: Crear un diseño detallado de la extensión,
    considerando aspectos como la interfaz de usuario, la integración con
    el producto base y la compatibilidad con las versiones existentes.
    Planificar el cronograma de desarrollo y establecer hitos clave.
    4. Desarrollo de la extensión: Implementar las funcionalidades de la
    extensión de acuerdo con el diseño establecido. Realizar pruebas
    unitarias y de integración para garantizar su correcto funcionamiento y
    su compatibilidad con el producto base.
    5. Documentación: Crear documentación clara y completa que explique
    cómo instalar, configurar y utilizar la extensión. Proporcionar ejemplos
    y casos de uso para facilitar su comprensión.

    View Slide

  73. 72
    6. Pruebas y control de calidad: Realizar pruebas exhaustivas de la
    extensión para identificar y corregir posibles errores o problemas de
    rendimiento. Asegurar que la extensión cumpla con los estándares de
    calidad y satisfaga los requisitos definidos.
    7. Gestión de la versión: Establecer un sistema de control de versiones
    para administrar los cambios y actualizaciones de la extensión. Seguir
    buenas prácticas de gestión de versiones para garantizar una evolución
    ordenada y controlada de la extensión.
    8. Implementación y soporte: Preparar los recursos necesarios y los pasos
    requeridos para instalar y desplegar la extensión en el entorno de
    producción del cliente. Brindar soporte y asistencia técnica para
    resolver problemas o consultas relacionadas con la extensión.
    9. Gestión del ciclo de vida de la extensión: Establecer una estrategia para
    mantener y actualizar la extensión a lo largo del tiempo, incluyendo la
    resolución de problemas, la incorporación de nuevas funcionalidades y
    la compatibilidad con futuras versiones del producto base.
    10. Comunicación con el cliente: Mantener una comunicación clara y
    constante con el cliente o los usuarios finales, informando sobre el
    progreso del desarrollo, respondiendo a consultas y recopilando
    retroalimentación para mejorar la extensión.
    Seguro que se te ocurren más, pero las anteriores tareas conllevan un gran
    trabajo administrativo.
    ¿Servicios gestionados?
    Cuando trabajas con servicios gestionados, hay varias tareas administrativas
    que debes tener en cuenta. Estas tareas se centran en la gestión y supervisión
    de los servicios gestionados contratados. Algunas de las tareas
    administrativas comunes incluyen:
    1. Selección de proveedores: Identificar y seleccionar proveedores de
    servicios gestionados confiables y con experiencia en el área específica
    requerida. Esto implica evaluar las capacidades, la reputación, la
    calidad del servicio y los costos asociados con cada proveedor.
    2. Contratación y negociación: Establecer acuerdos contractuales y
    negociar los términos y condiciones con el proveedor de servicios

    View Slide

  74. 73
    gestionados. Esto incluye definir los niveles de servicio, los plazos, los
    precios, las responsabilidades y cualquier otra cláusula relevante para
    la prestación del servicio.
    3. Gestión de contratos y pagos: Administrar los contratos con los
    proveedores de servicios gestionados, incluyendo la renovación, la
    modificación y la terminación de contratos. Además, realizar los pagos
    correspondientes según los términos acordados.
    4. Supervisión del rendimiento: Realizar un seguimiento continuo del
    rendimiento del proveedor de servicios gestionados para garantizar
    que cumpla con los niveles de servicio acordados. Esto implica
    establecer métricas de rendimiento, realizar evaluaciones periódicas y
    mantener una comunicación constante con el proveedor.
    5. Resolución de problemas y escalación: Gestionar y resolver cualquier
    problema o incidencia relacionada con los servicios gestionados. Esto
    puede implicar la coordinación con el proveedor para solucionar
    problemas técnicos, la gestión de cambios o la escalada de problemas
    cuando sea necesario.
    6. Gestión de la seguridad: Supervisar y garantizar la seguridad de los
    servicios gestionados, incluyendo la protección de datos, la prevención
    de brechas de seguridad y el cumplimiento de regulaciones y
    estándares de seguridad aplicables.
    7. Gestión de cambios: Administrar los cambios en los servicios
    gestionados, incluyendo cambios en los requisitos, actualizaciones
    tecnológicas, implementación de nuevas funcionalidades o ajustes en
    la configuración. Esto implica coordinar con el proveedor y garantizar
    una implementación adecuada y sin interrupciones del servicio.
    8. Reportes y comunicación: Generar informes y comunicarse
    regularmente con el proveedor de servicios gestionados para mantener
    una visibilidad clara del rendimiento, los problemas y las
    actualizaciones relacionadas con los servicios.
    9. Evaluación y mejora continua: Evaluar de forma periódica la eficacia y
    la calidad de los servicios gestionados. Identificar áreas de mejora y
    colaborar con el proveedor para implementar acciones correctivas y
    optimizar la prestación del servicio.

    View Slide

  75. 74
    10. Gestión de la relación con el proveedor: Mantener una relación sólida y
    colaborativa con el proveedor de servicios gestionados. Esto incluye la
    comunicación regular, la resolución de conflictos y la identificación de
    oportunidades para una mayor colaboración y beneficio mutuo.
    ¿Mantenimiento y soporte?
    Al brindar mantenimiento y soporte para un producto o servicio, existen
    varias tareas administrativas que debes considerar. Aquí hay algunas de ellas:
    1. Establecer acuerdos de nivel de servicio (SLA, por sus siglas en inglés):
    Definir los niveles de soporte y los tiempos de respuesta esperados
    para diferentes tipos de solicitudes de soporte. Esto incluye acordar los
    plazos de resolución para problemas críticos, importantes y menores.
    2. Crear un sistema de seguimiento de incidencias: Implementar una
    herramienta o sistema para registrar, asignar y dar seguimiento a las
    incidencias y solicitudes de soporte de los usuarios. Esto permite un
    seguimiento eficiente y una resolución oportuna de los problemas
    reportados.
    3. Asignación de recursos: Asignar personal adecuado y capacitado para
    manejar las solicitudes de mantenimiento y soporte. Esto puede incluir
    técnicos, especialistas, ingenieros o personal de atención al cliente,
    dependiendo de los requerimientos y la complejidad del producto o
    servicio.
    4. Priorización y gestión de incidencias: Evaluar y clasificar las
    incidencias según su nivel de gravedad y su impacto en el usuario.
    Establecer una metodología para priorizar y manejar las incidencias de
    manera efectiva, asegurándose de que los problemas críticos sean
    atendidos de manera prioritaria.
    5. Comunicación con los usuarios: Establecer canales de comunicación
    claros y efectivos para recibir y responder a las solicitudes de soporte.
    Proporcionar actualizaciones regulares sobre el estado de las
    incidencias y garantizar una comunicación clara y transparente con los
    usuarios.
    6. Mantenimiento preventivo: Establecer un programa de mantenimiento
    preventivo para evitar posibles problemas y optimizar el rendimiento

    View Slide

  76. 75
    del producto o servicio. Esto puede incluir actualizaciones de software,
    parches de seguridad, revisión de configuraciones, limpieza de datos,
    entre otros.
    7. Generación de informes de seguimiento: Crear informes periódicos
    sobre el rendimiento del sistema, las incidencias resueltas, el tiempo
    de respuesta promedio y otros indicadores clave. Estos informes
    proporcionan una visión general del estado del soporte y permiten
    identificar áreas de mejora.
    8. Gestión de contratos de mantenimiento: Si existen contratos de
    mantenimiento con los clientes, gestionar los términos, condiciones y
    renovaciones de dichos contratos. Asegurarse de cumplir con los
    compromisos acordados y revisar periódicamente los términos para
    adaptarlos a las necesidades cambiantes del negocio.
    9. Retroalimentación y mejora continua: Recopilar comentarios y
    sugerencias de los usuarios y el equipo de soporte para mejorar
    continuamente los procesos de mantenimiento y soporte. Establecer
    mecanismos para recibir y evaluar la retroalimentación, y realizar
    ajustes en consecuencia.
    10. Gestión de conocimiento: Crear y mantener una base de
    conocimientos con soluciones, procedimientos y recursos útiles para
    resolver problemas comunes de manera eficiente. Promover la
    documentación y el intercambio de conocimientos entre el equipo de
    soporte para mejorar la capacidad de resolución de incidencias.
    3.2.6.2 Tipos de costes
    Debes prestar atención a los costes por su tipo, ya que esto deberá quedar
    reflejado en la propuesta el precio, ciclo de vida, variaciones, etc. A
    continuación, os pongo los más comunes:
    Ciclo de vida
    • Los gastos recurrentes y no recurrentes son dos categorías que se
    utilizan para clasificar los diferentes tipos de gastos que una
    organización o individuo puede tener. Aquí te explico cada uno de
    ellos:

    View Slide

  77. 76
    Gastos recurrentes: Los gastos recurrentes son aquellos que se
    producen de manera regular y se repiten en períodos
    predefinidos, generalmente de forma mensual, trimestral o
    anual. Estos gastos son necesarios para el funcionamiento
    continuo de una entidad y suelen ser parte de las operaciones
    normales. Algunos ejemplos de gastos recurrentes incluyen:
    ▪ Gastos de alquiler o arrendamiento de instalaciones o
    equipos.
    ▪ Pagos de nómina y salarios a los empleados.
    ▪ Gastos de servicios públicos, como electricidad, agua y
    telefonía.
    ▪ Gastos de mantenimiento y reparación de equipos y
    propiedades.
    ▪ Pagos de seguros, como seguros de salud o seguros de
    propiedad.
    ▪ Costos de suministros y materiales necesarios para las
    actividades diarias.
    ▪ Gastos de marketing y publicidad regulares.
    ▪ Pagos de intereses y cuotas de préstamos a largo plazo.
    Los gastos recurrentes son necesarios para mantener las
    operaciones en funcionamiento y, por lo general, se incluyen en
    el presupuesto anual de una organización.
    • Gastos no recurrentes: Los gastos no recurrentes, también conocidos
    como gastos extraordinarios o gastos únicos, son aquellos que no se
    repiten regularmente y suelen ser de naturaleza no planificada. Estos
    gastos suelen surgir debido a circunstancias excepcionales o eventos
    no habituales. Algunos ejemplos de gastos no recurrentes incluyen:
    ▪ Gastos de reubicación o traslado de oficinas.
    ▪ Costos de adquisición de nuevos equipos o tecnología.
    ▪ Gastos legales o de consultoría relacionados con un litigio
    o proyecto específico.
    ▪ Gastos de formación o capacitación especializada para los
    empleados.

    View Slide

  78. 77
    ▪ Gastos de marketing y promoción relacionados con un
    evento o lanzamiento de producto específico.
    ▪ Costos de desarrollo de software personalizado o proyectos
    especiales.
    ▪ Gastos de remodelación o renovación de instalaciones.
    Los gastos no recurrentes no forman parte de los costos
    operativos regulares de una organización y, por lo tanto, no se
    incluyen en el presupuesto recurrente. Estos gastos suelen ser
    planificados y presupuestados por separado, ya que no se
    esperan de forma continua.
    Variación del precio, descuentos, términos de pago, períodos de
    garantía, mantenimiento, etc.
    Son puntos que estas fuera como arquitecto/a de soluciones, pero otros no,
    ya deberías saber por tu experiencia cuales te afectan al presupuesto y cuáles
    no.
    3.2.6.3 Precio fijo
    El precio fijo es un alcance de trabajo establecido con un precio específico.
    Le dices a los clientes exactamente lo que vas a hacer y cuánto les va a costar.
    Mientras los clientes se mantengan dentro del alcance del proyecto, se les
    cobra el precio que cotizaste. En mi experiencia, el precio fijo es la opción
    más comúnmente utilizada en la industria.
    Ventajas para ti: Sabes exactamente cuánto ganarás en el proyecto. Si el
    trabajo te lleva menos tiempo del esperado, obtienes más ganancias.
    Desventajas para ti: Como estás comprometido con un precio, si el trabajo
    te lleva más tiempo del esperado, obtienes menos ganancias (incluso puedes
    perder dinero).
    Ventajas para los clientes: Los clientes saben exactamente cuánto tendrán
    que pagar, siempre y cuando se mantengan dentro del alcance del proyecto.
    Pueden asumir razonablemente que podrán cumplir con su presupuesto
    asignado para el proyecto.

    View Slide

  79. 78
    Desventajas para los clientes: Debido a la naturaleza complicada de los
    precios fijos, es probable que tú debas inflar tu estimación para tener en
    cuenta cualquier desafío imprevisto en el proyecto. Como resultado, los
    clientes podrían terminar pagando mucho más por un proyecto que si se
    hubiera fijado un precio en una estructura diferente. Además, si los clientes
    se salen del alcance en un grado que requiera que les envíes órdenes de
    cambio, pueden frustrarse y sentir que estás tratando de sacarles hasta el
    último centavo.
    Problemas a tener en cuenta: Con los precios fijos, debes definir
    claramente el alcance del proyecto. Si no tienes cada detalle minuciosamente
    definido (entregables, funcionalidad, rondas de diseño, rondas de cambios,
    etc.) en tu propuesta, es muy probable que eventualmente te encuentres en
    problemas con un proyecto de precio fijo.
    Debes intentar ayudar a los clientes a adherirse al alcance definido del
    proyecto. Desafortunadamente, sin importar lo que hagas para detallar
    claramente el proyecto, existe la posibilidad de que los clientes te pidan
    hacer algo que no se incluyó en el alcance. Mantenerlos dentro del alcance
    puede ser una tarea desafiante de gestión de clientes.
    Cuando usarlo: Las estructuras de precio fijo se utilizan mejor cuando los
    clientes saben exactamente lo que quieren que produzcas y exactamente
    cuánto están dispuestos a gastar.
    3.2.6.4 Time & Materials (recursos dedicados)
    Se asignan ciertos empleados a un cliente por un período determinado. Las
    estructuras de recursos dedicados compran personas en lugar de horas. Por
    lo general, se calcula en semanas hombre (man-day). Trabajas con los
    clientes para determinar cuánto tiempo esperas que dure el proyecto y
    dedicas empleados específicos a la tarea. Cuantas más semanas hombre
    compren los clientes, menor será la tarifa que pagan.
    Ventajas para ti: Puede brindarte flujo de efectivo y confianza para
    expandir tu negocio.

    View Slide

  80. 79
    Desventajas para ti: Al reducir tu tarifa, reduces tu margen de beneficio.
    También es posible que debas dedicar algunos de tus mejores empleados a
    un cliente, perdiendo así su participación en otros proyectos.
    Ventajas para los clientes: Los clientes pagan menos dinero por más
    trabajo y pueden construir una sólida relación de trabajo con los miembros
    de tu equipo, ya que colaboran estrechamente en el proyecto.
    Desventajas para los clientes: Durante el período establecido en el
    acuerdo, es como si los clientes emplearan directamente a los miembros de
    tu equipo. Tienen la responsabilidad de mantener ocupados a esos miembros
    del equipo para obtener el máximo provecho de la relación.
    Problemas a tener en cuenta: Asegúrate de incluir una cláusula legal en tu
    acuerdo con los clientes para evitar que contraten a tus empleados. A
    medida que construyen una sólida relación de trabajo con los miembros de
    tu equipo, esto se convierte en un riesgo.
    Cuando usarlo: Esta estructura funciona mejor para compromisos a largo
    plazo donde el alcance y el conjunto de características del proyecto son
    difíciles de determinar al principio.
    3.3 EVALUACIÓN DE UNA RFP
    Esta sección os voy a contar como debemos proceder para evaluar una RFP.
    Y para ello que mejor que tener un flujo de trabajo que te ayude con el
    proceso:

    View Slide

  81. 80

    View Slide

  82. 81
    3.3.1 ¿Ofertar o no ofertar?
    La decisión de gestión más importante que una empresa toma en relación
    con cualquier proyecto dado es si presentarse a la licitación del contrato.
    Una propuesta representa una inversión significativa de los recursos de la
    empresa y solo debe emprenderse si existe una posibilidad razonable de
    ganar el contrato. O puedes decidir aceptar una pérdida en el trabajo si
    deseas establecer tu empresa con un cliente, especialmente si el prestigio del
    cliente animará a otros clientes a contratar tus servicios.
    Este paso consta de dos partes: un análisis de la solicitud de propuesta (RFP)
    y un análisis económico para determinar si el retorno potencial supera el
    costo de preparar la propuesta y completar el trabajo.
    3.3.2 Desarrollo preliminar de un punto de venta único/diferenciador.
    Se trata de la etapa de planificación y diseño de un punto de venta que tenga
    características únicas o distintivas. Esto implica desarrollar conceptos, ideas
    y propuestas para crear un punto de venta que se destaque de la
    competencia y atraiga al cliente de manera efectiva.
    3.3.3 Desarrollo del Diseño del Programa
    El gestor de la propuesta coordina toda la información para desarrollar el
    diseño final del programa. En este paso, nuestra empresa determinará
    exactamente lo que haremos por el cliente, cómo lo haremos, cuánto tiempo
    y dinero necesitará para finalizar el proyecto. Este paso incluye la
    elaboración de estimaciones de tiempo y costes.
    3.3.4 Desarrollo de la Portada y el Resumen Ejecutivo
    Una vez finalizado el primer borrador de la propuesta, la lideres lo revisarán
    y normalmente sugerirá cambios. Cuando los directivos aprueben el
    contenido final, el equipo de la propuesta elaborará la portada.
    La portada de la propuesta incluye la carta de presentación (o de
    transmisión), el índice final, la lista de gráficos y tablas, y el resumen
    ejecutivo. El resumen ejecutivo es una parte clave de la propuesta porque
    describe brevemente las cuestiones principales y las acciones recomendadas
    por su empresa. El resumen ejecutivo sirve como potente pieza de ventas y
    marketing para su empresa.

    View Slide

  83. 82
    3.3.5 ¿Cómo debo hacer las preguntas al cliente?
    Los proveedores debemos tener el derecho a poder realizar preguntas y que
    el cliente las responda. El cliente distribuirá las preguntas que lancemos a los
    actores correspondientes
    Las preguntas que solemos enviar al cliente suelen estar orientadas a
    requerimientos funcionales, no funcionales y procedimientos.
    El cliente debería redistribuir entre todos los proveedores tanto nuestras
    preguntas y las correspondientes respuestas como las que lanzan otros
    proveedores, es un ejercicio de transparencia, no una competición por ver
    quien es más listo y lanza menos preguntas para dar a entender al cliente
    que hemos entendido todo a la perfección. Por supuesto, el cliente debe
    anonimizar de quien es cada pregunta.
    Por ejemplo, esta sería la forma correcta de enviar las preguntas (ya sea en
    un documento de Word o Excel o en un simple correo):
    Nombre Ejemplo
    Nombre del fichero fichero-version-1.0.0.pdf
    Numero de la sección 3.1.1 Requerimiento funciona
    Número del párrafo 4
    Número de la página 36
    Texto o fragmento
    cuestionado
    “…de 15.00h a 15.15h, se cambia el turno y se
    debe cerrar la caja, la aplicación hace uso
    intensivo y muchas veces se queda bloquead…”
    Pregunta sobre el texto ¿De cuantos usuarios estamos hablando en ese
    momento pico?, ¿se hace en todas las regiones
    igual con el horario local a las 15.00h a 15.15h?,
    ¿podría darnos una tabla de dichos picos y
    cuando sucede en cada región?
    Como veis, estamos lanzado una pregunta facilitando al cliente como
    localizar la información. No es habitual que en una RFP te envíen como
    debes formular las preguntas. Con el modelo que os muestro es más que
    suficiente.
    Si estamos trabajando en el cliente en otros proyectos y tenemos algo de
    contexto esto puede ser un problema, ya que la posible respuesta puede ser

    View Slide

  84. 83
    “pregunta a tus compañeros”, esto es una desventaja muy grande y denota una
    falta de empatía por parte del cliente ya que puedes tener o no contacto con
    ese equipo. Mi recomendación es contacta con tus compañeros, obtén esa
    información si es que disponen de ella, en caso contrario deja marcado en la
    pregunta que ya has realizado un sondeo a tus compañeros y o bien carecen de
    esa información o bien su respuesta, que adjuntarás a la pregunta, no es
    concluyente y es necesario la respuesta del cliente.
    A vuestra disposición pongo un listado con más de 2000 preguntas,
    clasificadas para requerimientos no funcionales:
    2000 preguntas para Requerimientos No Funcionales (NFR)
    3.3.6 ¿Cómo debo hacer asunciones?
    Realizar asunciones en respuesta a una RFP es una práctica común para
    abordar posibles lagunas de información o ambigüedades en los requisitos
    establecidos por el cliente. Aquí hay algunas pautas a seguir al hacer
    asunciones en tu respuesta a una RFP:

    View Slide

  85. 84
    1. Identifica las áreas ambiguas: Lee cuidadosamente la RFP y busca
    secciones o requisitos que no estén claramente definidos o que dejen
    margen para interpretación.
    2. Documenta las asunciones: Crea una lista clara y concisa de las
    asunciones que estás haciendo en tu respuesta. Enumera cada
    asunción de manera separada y brinda una descripción detallada de lo
    que estás asumiendo.
    3. Sé realista y fundamentado: Asegúrate de que tus asunciones sean
    razonables y realistas. Basa tus asunciones en tu experiencia y
    conocimiento del dominio en el que estás trabajando.
    4. Comunica las asunciones: Incluye las asunciones en tu propuesta,
    preferiblemente en una sección separada. Explica por qué estás
    haciendo cada asunción y cómo impacta en tu oferta y en la entrega
    del proyecto.
    5. Pide aclaraciones si es necesario: Si hay alguna ambigüedad o falta de
    información en la RFP, considera comunicarte con el cliente para
    solicitar aclaraciones antes de hacer tus asunciones. Esto te ayudará a
    tener una comprensión más clara de los requisitos y a reducir el riesgo
    de hacer suposiciones incorrectas.
    6. Evalúa el impacto de las asunciones: Analiza cómo afectarán tus
    asunciones a la oferta, al alcance del proyecto, al tiempo de entrega y al
    costo. Considera los posibles riesgos asociados a tus asunciones y cómo
    mitigarlos.
    7. Documenta cambios en las asunciones: Si durante el proceso del
    proyecto se descubre que una asunción era incorrecta o requiere
    ajustes, comunica estos cambios al cliente y realiza las modificaciones
    necesarias en la entrega del proyecto.
    Hacer asunciones es una estrategia para abordar incertidumbres, pero
    siempre es importante minimizarlas a través de una comunicación clara con
    el cliente y una comprensión completa de los requisitos.
    3.3.7 Una serie de cuestionarios que te ayudarán
    Esto puede llegar a ser infinito, pero aquí tienes un cuestionario que puede
    ayudarte a evaluar una RFP:

    View Slide

  86. 85
    1. ¿Los requisitos son claros y están bien definidos?
    2. ¿Se proporciona información suficiente sobre el alcance del proyecto?
    3. ¿Los objetivos del proyecto están claramente establecidos?
    4. ¿Se especifica el cronograma y los plazos esperados?
    5. ¿Se detallan los criterios de evaluación y los puntos de referencia para
    medir el éxito del proyecto?
    6. ¿Se proporciona información sobre los recursos disponibles, como
    personal, presupuesto y herramientas?
    7. ¿Se identifican los riesgos y desafíos potenciales del proyecto?
    8. ¿Se establecen claramente las expectativas de colaboración y
    comunicación entre el proveedor y el cliente?
    9. ¿La RFP incluye detalles sobre los entregables esperados y las
    responsabilidades de ambas partes?
    10. ¿Se menciona la experiencia requerida del proveedor y los criterios de
    selección?
    11. ¿Se proporciona información sobre el proceso de evaluación y
    selección de proveedores?
    12. ¿Se incluyen los términos y condiciones generales para el contrato?
    13. ¿La RFP proporciona información sobre el presupuesto disponible para
    el proyecto?
    14. ¿Se especifican los requisitos técnicos y tecnológicos necesarios para el
    proyecto?
    15. ¿Se incluye un resumen ejecutivo que brinde una visión general clara
    del proyecto?
    16. ¿La RFP establece claramente los roles y responsabilidades de las
    partes involucradas?
    17. ¿Se mencionan las expectativas de calidad y rendimiento del proyecto?
    18. ¿La RFP incluye información sobre la propiedad intelectual y los
    derechos de autor relacionados con los entregables del proyecto?
    19. ¿Se mencionan los requisitos de seguridad y privacidad de los datos en
    la RFP?
    20. ¿La RFP proporciona información sobre el proceso de presentación de
    propuestas y los plazos de entrega?
    21. ¿Se incluyen ejemplos o referencias de proyectos similares realizados
    anteriormente?

    View Slide

  87. 86
    22. ¿La RFP establece claramente los criterios de aceptación y las pruebas
    de validación necesarias?
    23. ¿Se mencionan los requisitos de soporte técnico y mantenimiento
    post-implementación?
    24. ¿La RFP incluye información sobre los estándares y regulaciones que
    deben cumplirse?
    25. ¿Se proporciona un plan de comunicación para mantener informadas a
    todas las partes interesadas durante el proyecto?
    26. ¿La RFP menciona los procedimientos de resolución de conflictos o
    disputas contractuales?
    27. ¿Se menciona la disponibilidad de recursos internos por parte del
    cliente para colaborar en el proyecto?
    28. ¿La RFP establece expectativas claras sobre los informes y
    actualizaciones del progreso del proyecto?
    29. ¿Se proporciona información sobre los requisitos de formación y
    capacitación para el personal del cliente?
    30. ¿La RFP incluye detalles sobre la transferencia de conocimiento y la
    documentación final del proyecto?
    31. ¿Se mencionan los requisitos de integración con sistemas existentes o
    de terceros?
    32. ¿La RFP establece las expectativas de disponibilidad y tiempos de
    respuesta para el soporte técnico?
    33. ¿Se incluye un apartado para preguntas y respuestas aclaratorias por
    parte de los proveedores interesados?
    Estas preguntas pueden variar dependiendo del tipo de proyecto y la
    industria. Adaptar el cuestionario según tus necesidades específicas te
    ayudará a evaluar de manera más precisa la RFP y determinar si es adecuada
    para tu organización.
    3.3.8 Tipos de estimación y herramientas que ayudan
    Existen diferentes tipos de estimación que se pueden utilizar para evaluar
    RFPs. Aquí hay algunos de los tipos comunes de estimación y herramientas
    que pueden ayudar en este proceso:

    View Slide

  88. 87
    • Estimación de esfuerzo: Esta es una estimación basada en la cantidad
    de tiempo y recursos humanos requeridos para completar el proyecto.
    Las herramientas que pueden ayudar en esta estimación incluyen hojas
    de cálculo, software de gestión de proyectos y métodos de
    descomposición de tareas.
    • Estimación de costo: Esta estimación se basa en los recursos
    financieros necesarios para llevar a cabo el proyecto. Se pueden utilizar
    herramientas como hojas de cálculo, software de gestión de
    presupuestos y sistemas de contabilidad para calcular y evaluar los
    costos asociados.
    • Estimación de duración: Esta estimación se enfoca en el tiempo
    necesario para completar el proyecto. Las herramientas como
    diagramas de Gantt, software de gestión de proyectos y técnicas de
    programación ayudan a visualizar y evaluar la duración de las tareas y
    el cronograma general del proyecto.
    • Estimación de riesgos: Esta estimación se centra en identificar y
    evaluar los posibles riesgos asociados con el proyecto. Se pueden
    utilizar herramientas como matrices de riesgos, análisis FODA
    (fortalezas, oportunidades, debilidades y amenazas) y técnicas de
    gestión de riesgos para evaluar y priorizar los riesgos potenciales.
    • Estimación de calidad: Esta estimación se refiere a la calidad del
    trabajo entregado al final del proyecto. Las herramientas que pueden
    ayudar en esta estimación incluyen estándares de calidad, procesos de
    control de calidad y métricas de rendimiento.
    Existen diversas herramientas en el mercado que pueden ayudarte a realizar
    estimaciones para evaluar RFPs. Aquí tienes algunas opciones populares:
    • Microsoft Project: Es una herramienta de gestión de proyectos que
    permite crear y gestionar cronogramas, asignar recursos, realizar
    seguimiento de tareas y estimar la duración y el esfuerzo requeridos
    para completar un proyecto.
    • Primavera P6: Es una herramienta de gestión de proyectos
    ampliamente utilizada en la industria de la construcción y la
    ingeniería. Permite realizar estimaciones de tiempo, costos y recursos,

    View Slide

  89. 88
    y ofrece funcionalidades avanzadas para la programación y el
    seguimiento de proyectos complejos.
    • Smartsheet: Es una herramienta de colaboración y gestión de
    proyectos en línea que incluye funciones de estimación y seguimiento
    de proyectos. Permite crear hojas de cálculo interactivas, asignar
    tareas, establecer hitos y colaborar en tiempo real con otros miembros
    del equipo.
    • Jira: Es una herramienta de gestión de proyectos y seguimiento de
    problemas que se utiliza comúnmente en el desarrollo de software ágil.
    Proporciona capacidades para estimar el esfuerzo, asignar tareas,
    realizar seguimiento del progreso y gestionar las dependencias entre
    las diferentes partes del proyecto.
    • Excel: Aunque es una herramienta más básica, Excel puede ser
    utilizado de manera efectiva para realizar estimaciones en hojas de
    cálculo personalizadas. Puedes utilizar fórmulas y funciones para
    calcular costos, esfuerzo y tiempo, y crear modelos de estimación
    adaptados a tus necesidades específicas.
    3.3.9 ¿Cómo debería ser el equipo?
    A veces, solo necesitas asignar a una persona para preparar y escribir una
    propuesta. Pero si el trabajo es grande o técnicamente complicado, es posible
    que necesites juntar a un equipo, por ejemplo:

    View Slide

  90. 89
    Desde mi experiencia existen cuatro elementos claves para tener un buen
    equipo de propuestas:
    • Gerentes (mánager) o coordinadores: estas personas se encargan del
    trabajo diario del equipo que escribe la propuesta. Son necesarios para
    coordinar cosas como la investigación de antecedentes y de mercado,
    recopilación de información sobre la competencia, desarrollo del plan
    del programa y presupuesto, y encontrar a los expertos dentro de la
    empresa y a los miembros del equipo que trabajarán en el proyecto. Y
    mantener la relación con el cliente, debe ser su contacto principal.
    • Un líder que supervise el proceso. Puede ser un arquitecto/a de
    soluciones, de data, de infraestructura, IA, etc. dependerá del tipo de
    proyecto que tengas.
    • Miembros del equipo con las habilidades y conocimientos específicos.
    Provienen de todas las áreas de la empresa o consultores externos o

    View Slide

  91. 90
    empresas que tienen habilidades o conocimientos especializados en
    relación con los requisitos de la propuesta.
    • Un lugar dedicado para el equipo. Puede ser tan sencillo como un
    equipo de Microsoft Teams o si trabajas on-site, una sección de la
    empresa reservada para el trabajo de la propuesta. Un espacio separado
    permite que el equipo trabaje más cerca y mantengan los materiales en
    un solo lugar.
    3.3.9.1 ¿Qué espero de quien lidera la propuesta?
    Debe ser un líder consolidado y la persona que dirige al equipo. Para mi debe
    ser una persona que sea experta en el tema de la propuesta, si no puede ser,
    debería tener suficiente conocimiento para ayudar a dirigir y guiar al equipo.
    Debe ser capaz de motivar a los miembros del equipo y coordinar y organizar
    el trabajo. Es esencial que los lideres debe ser el apoyo necesario para
    terminar el trabajo para cada área coordinada.
    Las tareas principales:
    • Principal contacto con el mánager de la propuesta y poder tener un
    contacto indirecto o directo con el cliente.
    • Reclutar, organizar y dirigir al equipo de planificación de propuestas.
    Esto incluye elegir a coordinadores que dirijan las actividades de los
    diferentes grupos involucrados.
    • Obtener los servicios de consultores y otras empresas (si es necesario)
    y definir sus responsabilidades y funciones.
    • Ayudar al equipo a analizar la solicitud de propuesta (RFP) para
    entender las necesidades del cliente.
    • Establecer el cronograma de planificación de propuestas y asignar
    tareas a los miembros individuales o grupos de trabajo del equipo.
    • Asegurarse de que el equipo se mantenga en el rumbo y siga las pautas
    y metas establecidas.
    • Revisar el material enviado por los miembros del equipo.
    • Mantener una comunicación constante con el mánager de la propuesta
    y los resultados del equipo y solicitar ayuda adicional cuando sea
    necesario.
    • Presentar la propuesta preliminar a los superiores.

    View Slide

  92. 91
    • Construir la propuesta final y ser el enlace con los superiores.
    • Supervisar la producción y entrega de la propuesta al mánager.
    3.3.9.2 ¿Qué espero de los mánager o gerentes de Áreas Funcionales?
    Los coordinadores de áreas funcionales, seleccionados por el líder de
    propuestas, dirigen el trabajo de sus miembros del equipo y reportan al líder
    de la propuesta. Esta estructura ayuda a establecer conexiones fuertes entre
    los diferentes departamentos o divisiones de la empresa, lo cual facilita el
    proceso de la propuesta. En general, a cada grupo se le asigna desarrollar y
    escribir una sección de la propuesta. Los coordinadores se aseguran de que
    las tareas asignadas a cada grupo se completen a tiempo.
    Sus responsabilidades incluyen:
    • Asegurarse de que el grupo comprenda los objetivos generales y el
    propósito de la propuesta.
    • Hacer un esquema detallado de su sección de la propuesta.
    • Asignar tareas de trabajo, establecer límites de páginas y plazos de
    entrega.
    • Usar consultores/subcontratistas u organizaciones colaboradoras
    según sea necesario e integrar sus aportes en el proceso.
    • Revisar borradores y participar en revisiones de la dirección del
    material en borrador.
    • Incorporar los comentarios de la revisión en la versión final de la
    sección y agregarla a la propuesta total.
    • Mantener al líder de la propuesta informado sobre el progreso del
    grupo y solicitar ayuda según sea necesario.
    3.3.9.3 5.10.2.3 Miembros del Equipo
    Los miembros del equipo generalmente son empleados de la empresa que se
    seleccionan por las contribuciones específicas que pueden hacer para
    preparar la propuesta. A veces, es necesario agregar consultores externos o
    empresas al equipo. Puedes agregar personal externo a través de acuerdos de
    consultoría o acuerdos de colaboración.

    View Slide

  93. 92
    3.3.9.4 Acuerdos de Consultoría
    Estos acuerdos se hacen con personas que tienen experiencia especializada, a
    menudo en temas técnicos. El acuerdo generalmente establece las
    condiciones bajo las cuales el consultor trabajará con tu empresa e incluye
    una cláusula que indica que no trabajará para una empresa competidora
    durante el plazo del acuerdo. Si ganas el contrato y el consultor formará
    parte del equipo del proyecto, esto también debería mencionarse en la
    propuesta. Se debe incluir el currículum vitae del consultor junto con el de
    los demás miembros del personal.
    Es importante no engañar al cliente en cuanto a quiénes formarán parte del
    equipo. Algunas empresas les gustan presumir de sus expertos para
    impresionar al cliente, especialmente si pueden mencionar a algunos
    consultores "famosos" de la industria, academia o campos técnicos. Si el
    cliente le otorga a tu empresa un contrato basándose en esos nombres y luego
    descubre que el consultor no trabajará en el proyecto, el cliente puede
    considerar esta acción fraudulenta y podría cancelar el contrato o demandar a
    la empresa.
    3.3.9.5 Acuerdo de Colaboración
    Un acuerdo de colaboración se puede usar para obtener experiencia en la
    preparación de la propuesta y/o para obtener las capacidades de una
    organización externa para trabajar en el proyecto. Esto se conoce como una
    estrategia de "ir juntos y luego separarse". Dos o más empresas se unen para
    completar un proyecto y luego se separan una vez que ha terminado. En este
    caso, las empresas deberían elegir a una sola persona como enlace principal
    con el cliente. De lo contrario, el riesgo de comunicación incorrecta entre el
    cliente y las empresas que presentan ofertas es alto.
    Es posible que tu empresa necesite hacer acuerdos de colaboración con dos o
    tres subcontratistas para obtener todas las habilidades y conocimientos que el
    proyecto pueda requerir. La empresa cliente puede ver este esfuerzo conjunto
    con buenos ojos en comparación con los esfuerzos de tu empresa por sí sola.
    El acuerdo de colaboración es un contrato legal entre tu empresa y las
    organizaciones colaboradoras. Establece las condiciones y restricciones bajo
    las cuales se realizará el trabajo y define las responsabilidades de todas las

    View Slide

  94. 93
    partes. Es mejor que los departamentos legales de todas las partes
    involucradas resuelvan los detalles del acuerdo para evitar problemas en el
    futuro. Al igual que con los consultores, si las organizaciones colaboradoras
    también trabajarán en el proyecto del cliente, esto debería destacarse en la
    propuesta.
    3.3.9.6 Especialista en Desarrollo de Propuestas
    Algunas empresas recurren a especialistas en desarrollo de propuestas para
    ayudarles a preparar propuestas cuando la empresa tiene personal o fondos
    limitados para dedicar a una oferta en particular. Los consultores
    profesionales sirven como líderes de propuestas o como un “equipo” de una
    sola persona que coordina los esfuerzos de la propuesta. Algunas
    organizaciones grandes utilizan equipos de estos especialistas a tiempo
    completo para planificar y desarrollar propuestas en diferentes áreas de
    trabajo con clientes.
    Por ejemplo, las empresas que hacen mucho negocio con el gobierno pueden
    tener especialistas en desarrollo de propuestas que se concentran
    exclusivamente en preparar ofertas para distintas agencias gubernamentales.
    Debido a que cumplir con las especificaciones de las ofertas del gobierno es
    tan complejo y cambia constantemente, a menudo se requiere el esfuerzo a
    tiempo completo de un especialista. Si tu empresa presenta ofertas solo
    ocasionalmente para proyectos gubernamentales, deberías considerar
    contratar a una consultoría externa para que te ayude a preparar la
    propuesta. Si los especialistas actúan como líderes de propuestas o
    coordinadores, cumplirán muchas de las mismas responsabilidades que las
    personas internas de la empresa.

    View Slide

  95. 94
    4 ANEXOS
    4.1 CLIENTE: CRONOGRAMA INVERSO DE EJEMPLO PARA PLANIFICAR UNA
    RFP
    Acción Actividad
    1 Pre-RFP
    2 Identificar la necesidad
    3 Estudio inicial
    4 Pliego para justificar el proyecto
    5 Estimar el presupuesto del proyecto
    6 Aprobación del proyecto de RFP
    7 RFP
    8 Identificar los perfiles y el equipo
    9 Identificar el cronograma y los hitos del proyecto
    10 Identificar los requerimientos de alto nivel
    11 Capacitar a los perfiles de nuestro equipo en las posibles nuevas tecnologías
    del proyecto
    12 Identificar a los usuarios que ayuden en la RFP
    13 Desarrollar los requerimientos técnicos
    14 Revisar los requerimientos con los usuarios
    15 Revisar los requerimientos con los estándares y herramientas de nuestra
    empresa
    16 Finalizar los requerimientos técnicos
    17 Desarrollar los requerimientos administrativos
    18 Revisar los requerimientos con los usuarios
    19 Revisar los requerimientos con los estándares y herramientas de nuestra
    empresa
    20 Finalizar los requerimientos administrativos
    21 Escribir la RFP
    22 Escribir los criterios de evaluación
    23 Escribir el cronograma (desde el final hasta el principio)
    24 Revisar la RFP
    25 Enviar la RFP a los proveedores
    26 Post-RPF
    27 Permite que los proveedores formulen preguntas/respuestas durante un
    periodo de tiempo
    28 Recepción de las propuestas
    29 Evaluar las propuestas

    View Slide

  96. 95
    30 Pregunta a los proveedores, si lo necesitas
    31 Primera criba de proveedores: quédate entre 2/3 proveedores
    32 Establece reuniones con los proveedores (in situ), demos y referencias
    33 Escoge un ganador
    34 Negocia el contrato
    35 Proporciona información a los proveedores descartados
    36 Genera un documento de por que gana un proveedor y por qué los otros se
    descartan
    37 Revisar, borra y almacena como máximo 6 meses las propuestas descartadas
    38 Comienza la Implementación
    Para poder poner las fechas vamos a comenzar por el paso 38, establecemos la fecha
    comienzo del desarrollo/implantación, y vemos moviéndonos para atrás, es decir,
    ¿Cuándo quiero que esté el paso 37?, ¿el 36? Así vamos asignando fechas hasta llegar al
    primer paso. Podrás observar cuanto tiempo te llevará realizar una propuesta.
    4.2 CLIENTE: EJEMPLO DE LA ORGANIZACIÓN DEL EQUIPO
    Tablas, Excel, etc. etc.
    Project
    Manager
    Legal
    Lider
    Ayudante
    Product
    Owner
    Lider
    Ayudante
    Usuarios
    IT
    Lider
    Ayudante
    Compras
    Lider
    Ayudante

    View Slide

  97. 96
    4.3 CLIENTE: EJEMPLO DE INFORMACIÓN ADMINISTRATIVA
    A continuación, un ejemplo de la parte administrativa que podría enviarnos
    un cliente. En este ejemplo he roto las subsecciones para que, en una
    evaluación, como parte proveedora, puedas entender que podría contener
    cada área.
    Información administrativa
    [NOMBRE_EMPRESA] emite esta solicitud de propuesta (RFP) para la modernización
    de nuestro actual ERP. Esta sección proporciona la guía con la información
    administrativa que requerimos a los proveedores.
    A continuación, incluimos los puntos a tratar:
    Cronograma de la RFP
    Actividad Fecha Hora límite
    Emisión de la RFP 01/01/2024
    Interés de licitación +2 días 12:00
    Reunión general con todos los proveedores + 4 días
    Demo del actual ERP + 5 días
    Dudas, fecha límite de envío por parte de los
    proveedores
    + 7 días 15:00
    Envío de respuestas por parte del cliente +9 días 15:00
    Fecha límite del envío de RFP por parte de los
    proveedores
    +15 días 18:00
    Preguntas del cliente a los proveedores +19 días
    Finalización de la evaluación +23 días
    Emisión de un ganador +25 días
    Nota: Si la fecha inicial es 01/01/2024, +15, significa que es el 16/01/2024.
    Estas fechas que os propongo son un ejemplo de lo que podrías proponer. Al
    menos debes dejar 15 días laborables desde que nos envías una propuesta a
    los proveedores hasta la fecha límite de respuesta. Muchas veces nos lo piden
    los clientes en una semana y en una semana en ciertas organizaciones es
    muy complicado dar la respuesta tal y como nos gustaría darla. Y en otras
    que no tienen tanta cadena burocrática, posiblemente en una semana
    tampoco puedan darte una propuesta con la que se sientan cómodos.
    Información del contrato
    Aquí no soy ningún experto, os pongo un poco lo que me suelo encontrar.
    Habitualmente nos ponen una frase como la siguiente: “por favor complete la

    View Slide

  98. 97
    siguiente información de contacto”. ¿Por qué nos lo piden así? Primero por que
    puedes tener un proceso automatizado que al llegar el mail revise el
    documento de Word, PowerPoint o PDF y lo remita a quien toca, otra por
    puro formalismo y comodidad para completar la información en el CRM del
    cliente, etc. etc.:
    [Nombre de tu empresa]
    [Dirección postal completa]
    [Telf. De contacto de la empresa]
    [email de contacto de la empresa]
    Persona de contacto:
    [Nombre Persona de contacto] | [Cargo]
    [email de la persona de contacto]
    [Telf. Persona de contacto]
    Con esta información es suficiente para que el cliente pueda localizar a quien
    corresponda.
    Intención de licitación
    Debe ser algo escueto, digamos: apéndice G
    4.4 CLIENTE: INSTRUCCIONES PARA RESPONDER A LA RFP
    Algo que muchas veces no veo, como ya os he comentado, pero que aquí os
    doy como guía que servirá para el cliente y el proveedor. Espero que pueda
    ayudar y hacer la vida más fácil a ambas partes.

    View Slide