El cliente no necesita conocer la solución preparada
El cliente contrata a un especialista, entre otras cosas, porque por sí mismo no sabe cómo resolver mejor su problema. El propietario de la empresa puede notar que la página no genera consultas, que los empleados pierden tiempo copiando datos manualmente o que la marca parece menos profesional que la competencia. Sin embargo, no tiene por qué saber si necesita una reestructuración del formulario, una nueva arquitectura de la información, una integración con el CRM, un reposicionamiento de la marca o una solución completamente diferente.
Esperar que el cliente prepare una especificación completa y correcta a menudo puede ser irrealista. Es un poco como si un mecánico esperara que el conductor, antes de la visita, diagnosticara por su cuenta la avería e indicara las piezas que requieren sustitución. El cliente debería ser capaz de describir los síntomas, el contexto y el resultado esperado. La tarea del especialista es ayudarle a pasar de esa información a la solución adecuada.
Sin embargo, eso no significa que el freelancer tenga que idear por sí solo todo el proyecto a partir de una sola frase. Descubrir las necesidades requiere colaboración. El cliente aporta conocimiento sobre la empresa, el público, las limitaciones y experiencias previas. El proveedor aporta conocimientos del sector, la capacidad de hacer preguntas y la evaluación de la viabilidad de las soluciones propuestas.
El cliente no tiene que saber cómo construir la solución. Sin embargo, debería participar en la definición de qué problema estamos resolviendo y cómo sabremos que el proyecto ha tenido éxito.
Briefstreak
¿Por qué el cliente no puede determinar sus necesidades?
Los requisitos poco claros no siempre se deben a una falta de preparación. A veces, el proyecto simplemente se encuentra en una etapa muy temprana. El cliente percibe el problema, pero aún no lo ha analizado. En otros casos, conoce el resultado que desea, pero no comprende las opciones disponibles ni las limitaciones técnicas.
Conoce el problema, pero no conoce las posibles soluciones
El cliente sabe que demasiadas personas abandonan la compra, pero no puede señalar la causa. Puede asumir que necesita una nueva tienda online, aunque el problema sea un formulario de entrega complicado. Puede pedir una aplicación móvil, a pesar de que a su público le bastaría un panel web que funcione bien.
Es natural que el cliente describa la necesidad a través del prisma de la solución que conoce. Tu tarea no es rechazar automáticamente su idea, sino averiguar por qué precisamente pensó en ella y qué efecto quiere lograr gracias a ella.
En la empresa no hay una única versión de las necesidades
La persona que encarga el servicio puede representar solo un punto de vista. El propietario quiere aumentar las ventas, el marketing quiere publicar contenidos fácilmente, el departamento de atención al cliente espera menos preguntas repetitivas y los usuarios necesitan un proceso más sencillo. Todas estas necesidades pueden ser correctas, pero no siempre son compatibles entre sí.
Si el proyecto tiene varios interesados, no basta con preguntar a una sola persona qué necesita. Hay que determinar quién utilizará la solución, quién la aprueba, quién financia el proyecto y cuyo trabajo diario cambiará.
El cliente no puede separar las prioridades de las ideas
Durante la conversación, el cliente puede mencionar varias decenas de funciones, inspiraciones y conceptos sueltos. Esto no significa que todas sean requisitos. Parte es un intento de imaginar el proyecto, parte es una adición para el futuro y parte es una idea escuchada a la competencia.
Si todo se trata como igualmente importante, el alcance rápidamente se volverá demasiado grande y costoso. Por eso, las necesidades deben ordenarse según su importancia, su impacto en el objetivo y las consecuencias de renunciar a un elemento dado.
El cliente teme dar el presupuesto
Algunos clientes evitan dar respuestas concretas porque creen que el contratista aprovechará cualquier información para subir el precio. No quieren indicar el presupuesto, el alcance esperado ni la importancia de cada elemento. Esperan recibir primero una propuesta completa y solo entonces decidir qué es lo que realmente necesitan.
En tal situación conviene explicar que los mismos objetivos pueden alcanzarse en distintos niveles. El presupuesto no sirve para fijar automáticamente el precio, sino para elegir una solución realista. Sin esta información puedes preparar una propuesta totalmente inadecuada a las posibilidades del cliente.
El cliente nunca había pedido antes un servicio similar
La persona que encarga su primera página web, identidad visual, campaña publicitaria o sistema informático puede no saber qué decisiones tendrá que tomar. No conoce el proceso del sector, las etapas típicas ni los elementos que influyen en el precio.
En lugar de evaluar una consulta así como poco profesional, hay que guiar al cliente a través del proceso. Las buenas preguntas deben ser comprensibles sin conocimientos especializados y referirse sobre todo a la empresa, los usuarios, los problemas y los resultados esperados.
El problema aún está demasiado poco reconocido
A veces ninguna de las partes conoce la respuesta al principio. No se sabe por qué los clientes abandonan el formulario, qué procesos consumen más tiempo ni si los usuarios necesitan la función planificada. Las respuestas requieren análisis de datos, conversaciones con usuarios, una auditoría, un taller o la creación de un prototipo.
En un proyecto así no se debe fingir que el alcance es conocido. El primer producto de la colaboración debería ser una mejor comprensión del problema, y solo el segundo la solución adecuada.
Primero separe la necesidad de la solución propuesta
Uno de los elementos más importantes de discovery es distinguir entre lo que el cliente realmente necesita y lo que propone construir. La frase «necesitamos una aplicación móvil» describe una solución. No explica quién la usará, en qué situación, qué problema debe desaparecer ni por qué las herramientas existentes no son suficientes.
Lo mismo ocurre con la solicitud de un nuevo logotipo, el rediseño de la página web, una campaña en las redes sociales o la automatización del proceso. Cada una de estas ideas puede ser acertada, pero antes de comenzar su implementación hay que conocer la razón que hay detrás de ella.
No empieces con la pregunta: «¿Qué debemos crear?». Empieza con la pregunta: «¿Qué debe cambiar después de finalizar el proyecto?».
Briefstreak
Es útil reformular la respuesta del cliente. Si dice que quiere una nueva página web, puedes resumir: «Entiendo que el problema principal es el pequeño número de consultas de clientes empresariales, y que el objetivo del proyecto es aumentar el número de contactos valiosos. La nueva página web es actualmente una de las formas que se están considerando para lograr este objetivo». Una frase así deja espacio para comprobar si realmente es necesaria una reconstrucción completa de todo el sitio.
Empieza por la situación actual, no por la lista de funciones
Cuando el cliente no puede definir sus necesidades, la pregunta «¿Qué funciones debe tener el sistema?» normalmente no ayudará. La respuesta será muy general o basada en inspiraciones aleatorias. Es más fácil hablar de lo que está ocurriendo actualmente.
- ¿Cómo se realiza actualmente este proceso?
- ¿Quién participa en él?
- ¿Qué pone en marcha todo el proceso?
- ¿En qué lugar aparecen la mayoría de los problemas?
- ¿Qué ocupa más tiempo?
- ¿Qué errores se repiten con más frecuencia?
- ¿Qué herramientas utiliza hoy el cliente?
- ¿Qué funciona bien en la solución actual y debería conservarse?
- ¿Qué soluciones provisionales utilizan los empleados o usuarios?
- ¿Qué sucede cuando el problema no se resuelve?
La descripción del proceso real aporta mucha más información que una lista abstracta de expectativas. El cliente puede no recordar que necesita la exportación de datos, pero al describir su trabajo mencionará que cada viernes transcribe manualmente los resultados a una hoja de cálculo. Precisamente en esos detalles suelen ocultarse con frecuencia los requisitos más importantes.
Determina lo que el cliente intenta lograr
El proyecto debería conducir a un cambio determinado. La mera creación de un sitio web, una película, una identidad o una aplicación es la entrega de un producto, pero no explica su propósito. Para elegir bien el alcance, hay que entender para qué le será necesario al cliente la solución.
Es útil pensar en términos de la tarea que el cliente o su destinatario intenta realizar. El usuario no necesita un formulario por el simple hecho de tener un formulario. Quiere obtener un presupuesto rápidamente. La empresa no necesita un panel de control solo porque se vea profesional. Quiere detectar antes las caídas en las ventas y tomar decisiones más acertadas.
- ¿Por qué se necesita este proyecto justo ahora?
- ¿Qué problema debe resolverse?
- ¿Quién siente más este problema?
- ¿Cómo lidian actualmente los usuarios con él?
- ¿Qué debería volverse más fácil, más rápido o más barato?
- ¿Qué decisión o acción debe ayudar a tomar la solución?
- ¿Qué será posible después de la implementación que no se puede hacer hoy?
- ¿Cuáles son las consecuencias de dejar la situación actual sin cambios?
Define el resultado, no solo los entregables
El resultado del proyecto debe incluir tanto lo que entrega el contratista como el cambio que espera el cliente. El material puede ser una nueva página web. El resultado esperado es encontrar información más fácilmente y un aumento del número de consultas valiosas. El material puede ser la automatización. El resultado es acortar el proceso de dos horas a una docena de minutos.
No se puede garantizar todos los resultados. Un freelancer que diseña una tienda no tiene control total sobre el número de ventas, porque también lo influyen la oferta, el tráfico, los precios y las acciones de marketing. Sin embargo, aún se pueden definir indicadores sobre los que el proyecto debe influir, así como las condiciones que permitan evaluar su calidad.
- ¿Por qué reconocerá el cliente que el proyecto ha tenido éxito?
- ¿Qué comportamiento de los usuarios debería cambiar?
- ¿Qué proceso debería durar menos?
- ¿Qué errores deberían ocurrir con menos frecuencia?
- ¿Qué información debería estar más fácilmente disponible?
- ¿Qué resultado mínimo justifica la realización del proyecto?
- ¿Cuándo y de qué manera se evaluará el resultado?
Pregunta por situaciones concretas del pasado
Las preguntas sobre el futuro a menudo conducen a declaraciones y deseos. El cliente puede decir que el sistema debería ser «intuitivo», «moderno», «escalable» y «sencillo». Cada uno entiende estas palabras de manera diferente. Mucho más útiles son las preguntas sobre eventos concretos.
- ¿Cuándo apareció este problema por última vez?
- ¿Qué ocurrió exactamente entonces?
- ¿Quién intentó resolverlo?
- ¿Cuánto tiempo llevó?
- ¿Qué herramientas se usaron?
- ¿Qué fue lo más frustrante?
- ¿Cómo terminó esa situación?
- ¿Ocurre este tipo de problema regularmente?
Un ejemplo concreto permite ver el contexto, el orden de las acciones, los participantes y las limitaciones. A menudo también revela la diferencia entre lo que la empresa considera su proceso oficial y cómo es el trabajo en la práctica.
No preguntes únicamente qué quiere el cliente
La pregunta directa sobre las expectativas es necesaria, pero no puede ser el único método. Las personas omiten actividades que les parecen obvias, no recuerdan todas las excepciones o proponen soluciones basándose en un conocimiento limitado.
Según el tipo de proyecto, vale la pena complementar la conversación con un análisis de los materiales existentes, datos, formularios, procedimientos, mensajes de los clientes, grabaciones de conversaciones, estadísticas del sitio web o herramientas utilizadas. Al diseñar procesos, también puede ser útil observar el trabajo real de los usuarios.
El cliente puede decir que su empleado realiza la tarea de una manera sencilla. Solo la observación revelará que entre las etapas utiliza una hoja privada, copia datos de los mensajes y comprueba manualmente algunas excepciones. Estas acciones pueden tener una importancia clave para el proyecto, aunque no aparecieron en la descripción original.
¿Cómo hacer preguntas para obtener respuestas útiles?
Haz una pregunta a la vez
Una pregunta que contiene varios hilos suele llevar a responder solo uno de ellos. En lugar de preguntar al mismo tiempo por el público, el objetivo, el presupuesto, las funciones y el plazo, divide la conversación en partes más cortas. Así será más fácil notar las ambigüedades y hacer una pregunta complementaria.
Evita la jerga del sector
El cliente puede asentir, aunque no entienda la pregunta sobre arquitectura de la información, webhooks, personas, embudo, key visual o entorno de staging. Usa un lenguaje que describa acciones y resultados. La terminología técnica se puede introducir más adelante, cuando realmente sea necesaria.
Pide ejemplos
Cuando el cliente dice que el proyecto debería tener un aspecto profesional, pregunta qué materiales concretos considera profesionales y qué es exactamente lo que le gusta de ellos. Cuando espera una facilidad de uso, pide una descripción de la tarea que el usuario debería realizar sin ayuda.
Pregunta por la causa
No se trata de repetir mecánicamente la pregunta «¿por qué?» después de cada respuesta. Sin embargo, vale la pena comprender el motivo que está detrás del requisito. Si el cliente quiere inicio de sesión a través de redes sociales, pregunta qué problema pretende resolver. Tal vez los usuarios olvidan las contraseñas, el registro tarda demasiado o la empresa quiere obtener un tipo concreto de datos.
Resume con tus propias palabras
Después de la parte más importante de la conversación, presenta tu propia comprensión de la situación y pide confirmación. No repitas solo las palabras del cliente. Intenta ordenar las relaciones entre el problema, el público, el objetivo y el alcance propuesto.
Entiendo que el mayor problema no es la cantidad de mensajes en sí, sino que llegan a distintas personas y no se sabe qué consultas ya han sido atendidas. Por lo tanto, la prioridad es un lugar común para gestionar las solicitudes, y las respuestas automáticas por ahora son solo un complemento. ¿Lo resumo bien?
Resumen de ejemplo
Determina quién realmente utiliza la solución
La persona que compra el servicio no siempre es su usuaria. El propietario encarga un sistema para los empleados, el departamento de marketing una página para los clientes y el gerente un informe para la junta directiva. Cada uno de estos grupos puede tener objetivos, limitaciones y nivel de conocimiento diferentes.
Si los usuarios no participan en la definición de las necesidades, el proyecto puede responder a las expectativas de la persona que toma las decisiones, pero dificultar el trabajo diario. No siempre es necesario realizar grandes investigaciones. A veces basta con una breve conversación con algunas personas que realizan un proceso determinado.
- ¿Quién utilizará la solución con mayor frecuencia?
- ¿Quién toma la decisión de compra?
- ¿Quién aprobará el resultado?
- ¿Quién proporcionará los materiales y el conocimiento?
- ¿De quién cambiarán las responsabilidades después de la implementación?
- ¿Quién mantendrá la solución tras la finalización del proyecto?
- ¿Son compatibles entre sí las necesidades de los distintos grupos?
Convierte las descripciones generales en criterios
Palabras como «moderno», «simple», «premium», «rápido», «flexible» o «intuitivo» todavía no son requisitos. Son una dirección que hay que precisar.
Si la página debe ser rápida, determina si se trata del tiempo de carga técnico, de la facilidad para encontrar información, de un proceso de compra breve o de una gestión de contenidos eficiente. Si el sistema debe ser simple, define qué tareas debe realizar el usuario y qué errores comete actualmente.
- ¿Qué significa exactamente esta expresión en este proyecto?
- ¿Qué ejemplo cumple esta expectativa?
- ¿Qué ejemplo claramente no la cumple?
- ¿Quién evaluará este elemento?
- ¿Cómo sabremos objetivamente que el requisito se ha cumplido?
Ayuda al cliente a establecer prioridades
Cuando la conversación va bien, la lista de necesidades suele crecer. Eso todavía no es un problema. El problema surge cuando todos los elementos se consideran obligatorios, a pesar del presupuesto y el plazo limitados.
Las prioridades se pueden establecer preguntando por el impacto de renunciar a un elemento dado. Si un proyecto sin una función concreta sigue resolviendo el problema más importante, probablemente no sea indispensable en la primera versión.
- ¿Qué debe incluirse absolutamente en la primera versión?
- ¿Sin qué la solución no cumplirá el objetivo básico?
- ¿Qué elementos aportan el mayor valor?
- ¿Qué se puede hacer manualmente al principio?
- ¿Qué se puede trasladar a la siguiente etapa?
- ¿Qué requisitos se derivan de la ley, la seguridad o los contratos?
- ¿De qué renunciaría el cliente primero con un presupuesto menor?
Una buena manera es dividir en elementos necesarios, importantes, opcionales y dejados para el futuro. El mero hecho de asignar etiquetas no basta: cada decisión debe derivarse del objetivo del proyecto y de las limitaciones disponibles.
Muestra la solución con un ejemplo antes de construir todo
No todas las necesidades se pueden precisar solo con una conversación. El cliente puede darse cuenta de lo que falta, de lo que sobra o de cómo debería ser el flujo de información solo después de ver un ejemplo.
Según el proyecto, pueden ser útiles bocetos, maquetas, moodboards, contenidos de ejemplo, prototipos, muestras, mapas de proceso o pequeñas versiones de demostración. Su objetivo no es realizar gratuitamente parte del proyecto, sino comprobar rápidamente los supuestos importantes antes de una ejecución costosa.
El prototipo debe responder a una pregunta concreta. Puede comprobar si el usuario entiende la disposición del formulario, si el sistema puede integrarse con los datos existentes o si el estilo propuesto encaja con el posicionamiento de la marca. No hace falta diseñar toda la solución para verificar el riesgo más importante.
¿Cuándo debería ser de pago el discovery?
Una breve cualificación antes de la oferta suele ser parte del proceso de ventas. Puedes hacer gratuitamente algunas preguntas, evaluar el encaje y establecer el alcance básico. El límite se cruza cuando el cliente necesita trabajo analítico real: una auditoría, consultas con varias personas, análisis de datos, talleres, mapeo de procesos o la preparación de un concepto detallado.
Esta etapa tiene un valor independiente. Al finalizarla, el cliente debería comprender mejor el problema, las prioridades, los riesgos y las posibles soluciones, incluso si encarga la ejecución a otra persona. Por eso, el discovery puede ser un servicio independiente y no un complemento gratuito a la cotización.
- El proyecto es complejo y abarca muchos procesos.
- Los requisitos de varios interesados son contradictorios.
- No se sabe qué solución es viable.
- Hay que analizar el sistema existente o la documentación.
- Una estimación precisa requiere preparar un concepto.
- El proyecto será costoso, y unas suposiciones erróneas pueden generar grandes pérdidas.
- El cliente espera un taller, una auditoría, investigaciones o una recomendación detallada.
¿Qué puede surgir como parte del discovery pagado?
- Descripción del problema y del objetivo del proyecto.
- Mapa del proceso actual.
- Lista de interesados y usuarios.
- Requisitos ordenados.
- Prioridades de la primera etapa.
- Suposiciones y restricciones.
- Lista de riesgos y desconocidos.
- Variante recomendada de la solución.
- Arquitectura preliminar o maqueta.
- Plan de ejecución y estimación más detallada.
No prepares un precio fijo cuando el alcance todavía es desconocido
Uno de los errores más arriesgados es dar un precio vinculante solo porque el cliente lo espera. Si no se sabe exactamente qué debe hacerse, cada cantidad concreta se basa en suposiciones ocultas.
El contratista puede asumir una versión simple y el cliente una más avanzada. La diferencia sale a la luz solo durante la ejecución. Aparecen pagos adicionales, conflictos y la convicción del cliente de que el freelancer intenta cambiar las condiciones anteriores.
Cuando el alcance no está claro, se puede proporcionar un rango orientativo, presupuestar la fase de discovery o cobrar la primera parte por horas. El precio por proyecto tiene sentido solo cuando las partes entienden qué resultado, alcance y nivel de responsabilidad abarca.
En esta etapa solo puedo proporcionar un rango de 15 000–30 000 zł neto, porque todavía no conocemos la cantidad de integraciones ni las reglas del flujo de datos. Propongo comenzar con un taller de pago y un análisis. Después de esta etapa recibirán un alcance recomendado, un plan y un presupuesto detallado de la realización.
Respuesta de ejemplo
Documenta los supuestos, no solo los acuerdos
En proyectos con una gran incertidumbre, es importante dejar por escrito no solo lo que las partes han acordado, sino también en qué supuestos se basa el alcance. Si el precio asume que el cliente proporcionará contenidos terminados, acceso a un sistema determinado o la participación de una persona con capacidad de decisión, esto debe indicarse claramente.
La suposición puede resultar posteriormente falsa. Esto no significa automáticamente que alguien haya cometido un error. Es importante que las partes puedan evaluar el impacto de la nueva información en el alcance, el precio y el calendario.
- ¿Qué consideramos actualmente verdad?
- ¿Qué información ha sido confirmada?
- ¿Qué datos siguen faltando?
- ¿Qué decisiones deben tomarse más tarde?
- ¿Qué puede cambiar significativamente el alcance?
- ¿Quién es responsable de verificar las distintas suposiciones?
¿Cómo terminar el descubrimiento con un resumen concreto?
La conversación no debería terminar con la vaga sensación de que ambas partes más o menos entienden el proyecto. Vale la pena preparar un breve resumen y pedir al cliente que lo confirme.
- Describe la situación actual.
- Nombra el problema más importante.
- Indica los usuarios y las partes interesadas.
- Define el objetivo principal del proyecto.
- Define el resultado esperado.
- Enumera el alcance de la primera etapa.
- Anota los elementos fuera del alcance.
- Presenta las suposiciones y riesgos más importantes.
- Indica los materiales necesarios y las decisiones del cliente.
- Define el siguiente paso.
El resumen no tiene que ser una especificación larga. Sin embargo, debe permitir al cliente notar si el contratista ha entendido correctamente su situación. Si ya en esta etapa aparecen diferencias, es mucho más barato aclararlas antes de comenzar la ejecución.
¿Qué no hacer cuando el cliente no conoce sus necesidades?
No adivines por el cliente
Puedes formular hipótesis y recomendaciones, pero deben estar claramente marcadas. Si asumes por tu cuenta lo que necesita el cliente y luego construyes toda la oferta sobre esa base, corres el riesgo de preparar una solución para un problema que no existe.
No conviertas la conversación en un interrogatorio
Una larga lista de preguntas hechas sin contexto puede abrumar al cliente. Explica por qué se necesita cierta información, reacciona a las respuestas y omite las preguntas que no son relevantes para el proyecto concreto.
No des la respuesta demasiado pronto
La pregunta «¿Necesitan una aplicación con un panel de administrador y notificaciones automáticas?» dirige al cliente hacia una solución concreta. Primero es mejor preguntar quién gestiona la información, cómo lo hace actualmente y cuándo debe ponerse en contacto con los usuarios.
No trates la inspiración como una especificación
El cliente puede mostrar una página de la competencia o un proyecto de ejemplo y decir que quiere algo parecido. Hay que determinar qué elementos son importantes para él y por qué. La inspiración puede referirse al estilo, la estructura, las funciones o la impresión general, pero rara vez describe los requisitos completos.
No prometas un resultado que aún no se puede evaluar
Si no entiendes el problema, no puedes garantizar de forma responsable que la solución propuesta producirá el efecto esperado. Puedes comprometerte a realizar un análisis, preparar recomendaciones o llevar a cabo un alcance concreto, pero no finjas tener certeza allí donde todavía existen incógnitas importantes.
¿Cuándo es mejor rechazar la cooperación?
Las necesidades poco claras en sí mismas no son una señal de alarma. El problema es la falta de disposición para descubrirlas juntos. Si el cliente no conoce el alcance, pero responde a las preguntas, comparte materiales y acepta la fase de análisis, el proyecto puede ser una muy buena colaboración.
El riesgo aumenta cuando el cliente, al mismo tiempo, no puede definir sus necesidades, se niega a participar en el discovery, espera un precio fijo inmediato y quiere una garantía total del resultado. En tal situación, el contratista asume la responsabilidad por decisiones para las que no ha recibido información suficiente.
- El cliente no quiere responder a preguntas básicas.
- No facilita los materiales necesarios para el análisis.
- No se sabe quién toma las decisiones.
- Cada parte interesada espera algo diferente, pero nadie quiere establecer prioridades.
- El cliente exige un precio fijo sin definir el alcance.
- Exige la preparación gratuita de una estrategia o concepto completo.
- No acepta ninguna limitación en el número de cambios.
- Quiere que el contratista garantice un resultado que depende de muchos factores externos.
Ejemplo: el cliente quiere «un sitio web moderno»
El cliente se pone en contacto con una solicitud de preparación de una página corporativa moderna. No sabe cuántas subpáginas necesita, qué funciones deberían aparecer en ella ni qué significa exactamente para él la modernidad.
En lugar de preguntar de inmediato por el estilo preferido, el freelancer determina por qué la empresa está considerando un cambio. Resulta que el sitio web actual se creó hace ocho años, funciona mal en los teléfonos y presenta una oferta desactualizada. La mayoría de los clientes llega por recomendación, pero al entrar en el sitio se pone en contacto principalmente para preguntar por los servicios más baratos. La empresa quiere conseguir contratos B2B más grandes.
La conversación posterior muestra que lo más importante no es solo modernizar el aspecto. El sitio debe explicar la oferta para empresas más grandes, presentar proyectos realizados, responder a las preocupaciones habituales y dirigir a los clientes potenciales al formulario adecuado. La empresa, en cambio, no necesita un blog, una tienda ni un panel de cliente avanzado.
Un eslogan ambiguo se ha convertido en un objetivo concreto, un grupo destinatario, un alcance y una forma de evaluar el proyecto. Solo en este momento se puede hablar de manera responsable sobre la estructura, el plazo y el precio.
Ejemplo: el cliente quiere una aplicación para gestionar una empresa
La consulta inicial es muy amplia: la empresa quiere una aplicación en la que los empleados gestionarán clientes, tareas, documentos e informes. Intentar valorar todo el sistema en esta etapa sería una suposición.
Durante el discovery resulta que el mayor problema no es la falta de un sistema, sino la transferencia manual de datos sobre nuevos pedidos entre el departamento de ventas y la ejecución. Los errores en este punto provocan retrasos y reclamaciones.
En lugar de empezar con una aplicación extensa, la primera etapa puede ser organizar el formulario de pedido, la lista central de realizaciones y la asignación automática de la persona responsable. Las demás funciones quedan registradas como posibles etapas de desarrollo, pero no aumentan el coste de la primera versión.
¿Cómo aprovechar el brief cuando las necesidades no están claras?
El brief no debería exigir al cliente conocimientos especializados ni una lista cerrada de soluciones. Si el formulario empieza con preguntas sobre tecnología, formatos, funciones y estructura detallada, una persona en una etapa temprana puede abandonarlo o dar respuestas aleatorias.
Un brief mejor conduce al cliente desde la información que ya conoce hasta la que requiere una aclaración conjunta. Primero pregunta por la empresa, el público, la situación actual y el problema. Luego por el objetivo, las prioridades, las limitaciones, los materiales, el plazo y el presupuesto. Las preguntas sobre la solución aparecen solo más tarde.
Vale la pena permitir al cliente elegir la respuesta «no lo sé» o «necesito una recomendación». La falta de certeza es una información importante. Gracias a ello, el freelancer sabe que un área determinada requiere una conversación, un análisis o la presentación de opciones.
Orden de ejemplo de las preguntas en el brief
- ¿A qué se dedica la empresa o el proyecto?
- ¿Quién utilizará el resultado?
- ¿Cómo estáis resolviendo actualmente este problema?
- ¿Qué no funciona en la solución actual?
- ¿Por qué queréis abordar esto precisamente ahora?
- ¿Qué resultado será un éxito para vosotros?
- ¿Qué elementos son los más importantes?
- ¿Qué materiales y recursos ya están disponibles?
- ¿Cuál es el plazo previsto?
- ¿Qué presupuesto o rango de presupuesto está previsto?
- ¿Quién participará en la toma de decisiones?
- ¿En qué áreas esperáis recomendaciones del contratista?
¿Cómo ayuda Briefstreak a organizar consultas ambiguas?
En Briefstreak se puede preparar un brief separado para un servicio concreto y guiar al cliente a través de preguntas en un orden lógico. Gracias a respuestas de una sola y de múltiples opciones, campos de texto, archivos adjuntos, preguntas sobre la fecha límite y lógica condicional, el formulario puede adaptarse a la situación del cliente.
Una persona que apenas está buscando una solución no tiene que responder a las mismas preguntas detalladas que un cliente con una especificación ya preparada. Puede primero describir el problema y el resultado esperado. A partir de estas respuestas, el freelancer decide si puede preparar una oferta, si necesita una conversación adicional o si debería proponer un discovery de pago.
Un brief ordenado no sustituye el pensamiento ni la conversación. Sin embargo, limita el intercambio caótico de mensajes, revela la información que falta y ayuda a ambas partes a ver qué decisiones ya se han tomado y cuáles todavía requieren trabajo.
Proceso paso a paso
- No le exijas al cliente una especificación lista.
- Establece por qué el proyecto es necesario precisamente ahora.
- Pide una descripción de la situación actual y un ejemplo concreto del problema.
- Separa la necesidad de la solución propuesta por el cliente.
- Identifica a los usuarios, a la persona que toma las decisiones y a las demás partes interesadas.
- Define el resultado esperado y la forma de evaluarlo.
- Analiza los materiales, datos y procesos existentes.
- Convierte las formulaciones generales en criterios concretos.
- Establece las prioridades y el alcance mínimo razonable.
- Anota las incógnitas, las suposiciones y los riesgos.
- Si es necesario, propone un discovery o un prototipo de pago.
- Solo después de precisar el alcance prepara un presupuesto vinculante.
- Envía al cliente un resumen y obtén su confirmación.
- Trata la nueva información posterior como un cambio de supuestos que hay que evaluar conscientemente.
Resumen
Un cliente que no puede precisar exactamente sus necesidades no tiene por qué ser un cliente difícil ni mal preparado. A menudo se encuentra simplemente en una etapa en la que entiende mejor el problema que las posibles soluciones. Precisamente entonces es cuando más necesita a un especialista que le ayude a ordenar la situación.
Sin embargo, no se debe rellenar todos los vacíos con suposiciones propias. El discovery eficaz es un proceso compartido: el cliente aporta conocimiento sobre su empresa y sus usuarios, y el proveedor ayuda a convertir ese conocimiento en objetivos, prioridades, requisitos y un alcance realista.
Lo mejor es empezar por la situación actual, los problemas concretos y el cambio esperado. Solo después vale la pena hablar de las funciones, el aspecto, la tecnología y los materiales a entregar. Así, la solución surge de la necesidad y no de la primera idea que apareció durante la conversación.
Si la definición de las necesidades requiere una auditoría, talleres, análisis de datos o la elaboración de un concepto, debería convertirse en una etapa separada y de pago. El freelancer no tiene que resolver gratuitamente un problema complejo solo para poder dar un precio.
El objetivo no es eliminar cada incógnita antes de empezar. En muchos proyectos esto será imposible. Se trata de reconocer las suposiciones más importantes, limitar conscientemente el riesgo y establecer un proceso gracias al cual las decisiones posteriores no se tomen al azar.
