Cuando la gente piensa en un briefing de desarrollo, suele imaginarse un cuestionario que se envía al cliente antes de que el proyecto entre en fase de desarrollo. Sin embargo, este cuestionario es solo el primer paso del proceso de briefing. La comunicación previa al proyecto con el cliente es tan compleja como importante: si se pasa por alto algún detalle, todo el desarrollo podría salir mal, incluso si los términos de referencia ya se han acordado previamente. Sigue leyendo y te lo ilustraremos con un caso real.
Cada empresa tiene su propio procedimiento para elaborar un briefing. Veamos cómo hemos estructurado este proceso en Toimi.
Preguntas preliminares
Nuestra comunicación con el cliente comienza con un cuestionario que, a diferencia de lo que muchos creen, es solo una parte del briefing de desarrollo. Su propósito es obtener una idea general de lo que el cliente desea.
En esta etapa, es importante recopilar la siguiente información:
- Posicionamiento de la marca y valores de la empresa
- Metas y objetivos que el cliente quiere alcanzar con el producto
- Especificaciones del público objetivo
- Competencia en el mercado y ventajas competitivas deseadas del producto
- Estructura preferida del sitio web
- Diseño que le gusta al cliente: colores, tipografías, logotipo e identidad corporativa
- Características necesarias del sitio web, como pedidos en línea, barra de búsqueda, formularios de contacto, calculadoras, videos y galerías de imágenes
- Si el cliente prefiere un CMS prediseñado o un sitio web único desarrollado con lenguajes de programación
- Requisitos tecnológicos (si los hay)
- Plazos de desarrollo y presupuesto
- Necesidad de mantenimiento del sitio web después del lanzamiento
Luego, el gestor de proyectos analiza el briefing y se prepara para una conversación personal con el cliente para discutir los detalles; por lo general, realizamos varias reuniones. Entre estas iteraciones, el gestor consulta con desarrolladores y diseñadores para entender cómo pueden implementarse los requisitos del cliente, si hay formas más eficientes de hacerlo y cuánto tiempo y dinero requerirá el proyecto. Si los desarrolladores consideran que la tecnología elegida por el cliente no es óptima, uno de ellos puede participar en las negociaciones para proponer una alternativa.
Cuando todo parezca claro, pregunta otra vez
El principal objetivo de un briefing es obtener la mayor cantidad de información del cliente sobre lo que espera del sitio web y los objetivos que quiere lograr. Cualquier detalle que no se aclare desde el principio puede obligarnos a volver al punto de partida.
Por ejemplo, si el cliente necesita un sitio de reservas de hoteles, es importante saber qué quiere hacer con él una vez que esté operativo. Si planea convertirlo en un agregador en el futuro, esto afectará la elección de la tecnología, ya que tendremos que prever la funcionalidad necesaria y futuras integraciones. Por eso, durante la fase de negociación, es fundamental hacer muchas preguntas aclaratorias. Hay una regla importante a seguir: si todo parece estar claro, vuelve a preguntar.
Aquí está el ejemplo real que prometimos: uno de nuestros desarrolladores estaba terminando una maquetación adaptable para un cliente y, justo cuando estaba a punto de finalizar, el cliente cambió repentinamente el diseño del sitio web. Cuando el desarrollador abrió el portal, vio que literalmente todo había cambiado, por lo que tuvo que empezar desde cero. Y aunque se podría decir que fue culpa del cliente, si el gestor de proyectos hubiera sabido desde el inicio que la empresa planeaba un rediseño, este problema nunca habría ocurrido.
Opinión de expertos
Al discutir un briefing, no solo es importante escuchar al cliente, sino también debatir cualquier idea dudosa: nuestra experiencia nos permite hacer sugerencias fundamentadas sobre la mejor manera de implementar ciertas funcionalidades. En otras palabras, un briefing no es solo una entrevista, sino un trabajo en equipo.
Tuvimos un cliente que quería desarrollar una aplicación para aprender inglés, pero no tenía claro cómo estructurarla. Por ejemplo, quería incluir ejercicios prácticos tanto en el bloque teórico como en una sección separada. Durante la discusión, identificamos estos detalles y elaboramos bocetos visuales de los escenarios de usuario. Gracias al trabajo conjunto, logramos encontrar soluciones satisfactorias para ambas partes.
También puede ocurrir que los requisitos del cliente para la funcionalidad del sitio web superen su presupuesto. En lugar de decirle directamente que algo es imposible, el gestor de proyectos debe guiarlo con tacto hacia una alternativa más viable. Por ejemplo, si un cliente quiere desarrollar un portal de anuncios clasificados como Avito, le sugerimos adoptar un enfoque progresivo: empezar con funciones básicas antes de comprometerse completamente. Esto le permite evaluar la viabilidad de sus ideas y, si es necesario, replantear el diseño en función de los desafíos que surjan.
Después del briefing
Tras las negociaciones, estimamos un presupuesto aproximado y elaboramos una hoja de ruta donde describimos cada etapa. En proyectos de gran envergadura, cada fase se convierte en un proyecto independiente: redactamos sus términos de referencia y firmamos un contrato aparte. Esto es necesario cuando el producto es difícil de planificar por adelantado, ya que permite hacer una estimación más realista del tiempo y el presupuesto y desarrollar un ToR después de cada etapa.
Una vez que el cliente aprueba la hoja de ruta, realizamos una auditoría exhaustiva para determinar el costo exacto del proyecto y definir el conjunto específico de tareas, además de desarrollar los términos de referencia. Mientras tanto, trabajamos en los prototipos de las páginas del futuro sitio web para que el cliente tenga una idea clara de cómo se verá una vez terminado.
Finalmente, firmamos un contrato y comenzamos el desarrollo. Y el éxito del proceso dependerá, en gran medida, del trabajo que hayamos hecho en la fase de briefing.