Empieza por una tarea que tu equipo tenga que completar. Explica qué la pone en marcha, quién se encarga, cómo sería un buen resultado y dónde surgen las dificultades. Así tendrás algo concreto de lo que hablar con un desarrollador, incluso antes de saber qué construir.
«Necesitamos un sistema de reservas mejor» es un punto de partida perfectamente razonable. La siguiente pregunta útil es qué ocurre cuando alguien intenta reservar.
Antes de hablar por primera vez con un desarrollador, describe una tarea desde que llega la solicitud hasta que se obtiene el resultado. Incluye también la parte complicada. Puedes explicarlo con palabras corrientes, aunque todavía no sepas cómo debería construirse el software.
Imagina una empresa de formación ficticia. Un cliente escribe para pedir dos plazas en un curso. Una persona del equipo comprueba la disponibilidad, responde al cliente y registra la reserva. Si el curso está completo, alguien tiene que decidir qué ofrecerle.
Eso basta para iniciar un documento útil. «Construir un portal con un panel de control» deja muchas más cosas a la interpretación del desarrollador: quién lo usará, qué necesita terminar y cuándo se considera hecha una reserva.
La guía del Gobierno británico para entender un problema antes de construir un servicio recomienda examinar a los usuarios, su recorrido completo y las limitaciones. Su proceso de desarrollo público pertenece a ese contexto. Para nuestra empresa de formación, la pregunta inicial es más sencilla: ¿qué hace falta para apuntar a este cliente a un curso?
Pide a quien realiza la tarea que te cuente un caso reciente paso a paso. Anota lo que hayas observado. Después describe qué quieres que funcione de otra manera. En nuestra empresa ficticia, las notas podrían ser así:
La persona coordinadora consulta la hoja de cálculo del curso, responde por correo y añade al calendario una reserva aceptada. En este ejemplo, se ofreció una plaza mientras seguía pendiente otra respuesta.
La persona coordinadora debería ver qué solicitudes siguen esperando respuesta y decidir si ofrecer una plaza. Todavía tenemos que acordar cuándo se considera ocupada una plaza.
La primera parte describe el trabajo actual. La segunda propone un cambio y deja una decisión pendiente a la vista. La distinción importa cuando el personal tiene hábitos distintos: una persona puede reservar plazas mientras espera una respuesta y otra puede mantenerlas disponibles. Documenta ambas formas de trabajar antes de pedir al desarrollador que convierta cualquiera de ellas en una regla.
Para la consulta sobre el curso, un esquema práctico podría incluir estas notas:
Son notas propuestas para el ejemplo, no reglas establecidas para todas las empresas de formación. Pregunta qué significa «reserva acordada» en la tuya. ¿Una plaza queda ocupada cuando se ofrece, cuando el cliente acepta o cuando paga? Una pregunta por escrito se puede resolver entre todos.
Añade un pequeño ejemplo con datos inventados: en el Curso A del 12 de mayo queda una plaza; la Solicitud B pide dos. Muestra el resultado que esperarías e indica quién toma la decisión. Así el desarrollador puede preguntar sobre algo concreto.
Usa nombres y registros inventados cuando ayuden a explicar el trabajo. Si compartes ejemplos reales, envía solo aquello para lo que tengas autorización, elimina los datos personales o confidenciales innecesarios y acuerda una forma adecuada de facilitarlos.
Requisito: quien coordina debe poder ver las solicitudes que aún esperan respuesta. Explica por qué: de lo contrario, alguien tiene que buscar el trabajo pendiente en la bandeja de correo compartida.
Idea para hablar: los clientes podrían elegir otra fecha de curso por sí mismos. Déjala como posibilidad hasta valorar el trabajo necesario y a quién ayudaría.
Pregunta abierta: ¿cuándo se debe reservar una plaza y quién puede liberarla? Señala a la persona responsable de formación como quien puede decidirlo, en vez de dejar que el desarrollador establezca esa regla de negocio sin consultarlo.
Incluye también las limitaciones reales. Quizá haya que mantener el calendario actual, solo cierto personal pueda ver los datos de los clientes o un curso concreto deba estar disponible antes de una fecha conocida. Di qué límites son firmes y por qué. Si una fecha o un presupuesto son todavía una preferencia, indícalo.
«Más fácil de usar» necesita un ejemplo. En esta empresa, quien coordina debería poder seguir una solicitud hasta su respuesta y encontrar todas las que siguen pendientes. Usa la reserva normal y el caso en que solo queda una plaza para hablar de lo que el trabajo terminado debe demostrar.
También puedes anotar un problema actual que quieras medir, como la frecuencia con la que el equipo busca una solicitud sin responder en varias herramientas. Distingue lo que has observado de lo que queda por comprobar. Acordad cualquier objetivo después de establecer el punto de comparación.
Comparte el documento con quienes hacen ese trabajo antes de enviarlo. Pueden señalar un paso que falta o explicar por qué un atajo aparente causaría problemas. Deja las cuestiones pendientes en el documento, con una persona responsable de responder cada una.
Desarrollamos software empresarial a medida. Si quieres hablar de un proyecto con nosotros, trae una tarea como esta: qué sucede ahora, qué quieres cambiar, un ejemplo y las preguntas que todavía tienes. Después podremos hablar del alcance y las condiciones comerciales en función del trabajo. Este documento inicia la conversación; aún hará falta investigar y diseñar la solución técnica.
Puedes empezar describiendo la tarea, las personas que la realizan, las herramientas que usan y el resultado que necesitas. El diseño técnico puede venir después de investigar el trabajo. Si conoces una limitación técnica real, anótala y explica por qué importa.
Describe las variantes que hayas observado y pregunta a las personas implicadas por qué son distintas. Indica qué diferencias son necesarias y cuáles requieren una decisión. Nombra a alguien que pueda tomarla.
Escribe la pregunta, lo que ya sabes y quién puede ayudar a responderla. Por ejemplo: «¿Cuándo se considera ocupada una plaza: al ofrecerla, al aceptarla o al pagarla?». Mantenlo separado de los requisitos acordados.
Último boletín: ganar más con un sitio o app de suscripción que ya tienes.
El anterior: cómo distinguir las tonterías de la IA de los casos de éxito reales.
¿Te interesa?
Semanal O dinos y lo ajustamos para ti. ¿Suena bien?
