Te encuentras a mitad de un proyecto cuando el responsable del cliente te dice: “Necesitamos que este flujo de trabajo funcione para nuestras tres regiones —cada una con reglas de aprobación distintas— y que la plataforma garantice su cumplimiento”. Es probable que puedas implementar una solución rápida o provisional durante el despliegue, pero también sabes que es el tipo de funcionalidad que el próximo cliente también solicitará.
Esta lección trata sobre cómo identificar el momento en que una petición del cliente deja de ser una tarea de entrega puntual para convertirse en trabajo de desarrollo del producto principal, y sobre cómo tener claro qué responsabilidades siguen recayendo sobre ti como Forward Deployed Engineer (FDE). Un Forward Deployed Engineer (FDE) es un ingeniero que trabaja directamente en el entorno del cliente, traduciendo sus necesidades en tareas de producto e ingeniería.
Antes de decidir qué desarrollar, debes determinar en qué consiste realmente la solicitud. ¿Se trata de “hacer que funcione para esta cuenta antes del viernes” o de “carecemos de una funcionalidad reutilizable y este cliente nos está dando la primera señal clara de ello”?
Analiza la diferencia entre una modificación puntual para un cliente y una funcionalidad reutilizable.
Una solicitud se transforma en estrategia de producto cuando deja de tratarse de la configuración específica de un cliente y empieza a señalar una funcionalidad ausente en el producto. Se percibe cuando el cliente no pide un resultado puntual, sino una regla que la plataforma debe gestionar internamente.
Considere esta situación: el cliente desea que se apliquen aprobaciones específicas por región dentro de la plataforma, no en una hoja de cálculo, ni como un paso manual, ni mediante un script personalizado que solo su equipo comprende. Esto indica que están solicitando algo que requiere diseño de producto, soporte a largo plazo y una definición clara de su comportamiento.
Una forma rápida de distinguir ambos casos es preguntarse qué sucede cuando usted ya no esté presente. Si la solución exige mantener una rama personalizada, un parche privado o un comportamiento especial que nadie puede explicar sin sus notas, está entrando en el terreno del producto, ya que requiere una interfaz oficial y un plan de soporte estable.
Si requiere soporte, requiere diseño En el momento en que un cliente espera que una funcionalidad perdure tras actualizaciones y la incorporación de nuevos usuarios, trátela como parte del producto, no como un truco de implementación puntual.
Aunque algo deba convertirse en una tarea central del producto, usted sigue siendo responsable de mantener el avance del proyecto. Su labor consiste en desbloquear al cliente sin reescribir el producto de forma encubierta durante la implementación.
Esta responsabilidad consta de dos partes.
En primer lugar, usted mantiene el ritmo de la entrega. Convierte la petición en un requisito claro, identifica qué es viable en la implementación actual y propone una solución provisional que sea honesta respecto a las limitaciones.
En segundo lugar, protege la integridad del producto. La integridad implica que el producto se mantenga coherente como una unidad, y no como un cúmulo de comportamientos específicos para cada cuenta que acaban interfiriendo entre sí con el tiempo. En la práctica, esto significa evitar bifurcaciones (forks), evitar indicadores ocultos que solo utiliza un cliente y evitar compromisos que acaben acorralando al equipo de ingeniería más adelante.
En nuestro ejemplo de las aprobaciones, podría implementar un proceso temporal que satisfaga la necesidad de auditoría mientras recopila información para desarrollar una funcionalidad central. No está rechazando la solicitud, sino estableciendo una secuencia adecuada para abordarla.
Lo complicado es que cada tipo de fallo puede parecer, en el momento, una actitud proactiva y atenta a las necesidades del cliente. El coste real aparece más tarde, generalmente cuando usted ya está trabajando con otro cliente.
A continuación, se presentan algunos casos breves que ilustran cómo estos fallos generan costes adicionales a largo plazo.