Escribe una vez el Framework (el marco) de tu estudio y arranca cada cliente a partir de él. El alcance vive en una spec por entregable, con su sección Out of Scope (fuera de alcance) en cada una; una solicitud de cambio es una decisión que confirma el aprobador del cliente, y lo que aprobó es una versión con nombre que puedes abrir un año después.
Gratis para macOS, Windows y Linux. Sin cuenta, sin suscripción.
¿Te suena?
El contrato de trabajo está firmado y congelado. El alcance real se mueve en llamadas, correos y tickets.
Cada pequeño extra tenía sentido en la llamada. Juntos se comieron el margen, y al final nadie se pone de acuerdo sobre qué entraba en el alcance original.
Cinco personas del lado del cliente pueden pedir cambios y ninguna tiene la última palabra. La respuesta está en un hilo de correo, o en la cabeza de quien estuvo en la llamada.
Cada proyecto copia la plantilla del año pasado, que se desvía un poco cada vez. Quien pasa de un cliente a otro vuelve a aprender la estructura, y lo mismo cada nueva sesión de un agente.
Cómo encaja
Parte del Framework de software y conviértelo en el de tu estudio: los frames (los encuadres) que pide tu brief, las secciones que toda spec debe tener, tus roles. Después, cada proyecto de cliente nuevo parte de él, en el repositorio de ese cliente.
Lo que más vas a usar
Las colecciones, plantillas, propiedades y roles con los que trabaja tu estudio, instalados en cada proyecto de cliente nuevo con un comando o un clic.
Registra una versión que nombra el commit que aprobó el cliente, con su etiqueta en el repositorio. Abre la raíz tal como estaba en ese momento cada vez que vuelva la pregunta.
Una decisión de tipo Scope por cada cambio, asignada al aprobador del cliente. Al confirmarla, su nombre y la fecha quedan en la decisión y en la spec.
Una pregunta sobre un criterio es un hilo en ese criterio, no un correo. Ciérralo cuando esté respondido; queda en el archivo.
Tareas en un tablero, cada una con la spec que entrega, exportadas a CSV o Excel para el informe al cliente.
Un desarrollador que se suma al proyecto, o su agente de código, lee las specs y las decisiones en lugar de un mes de correos.
Lo que aprobó el cliente
Cuando el cliente aprueba, registra una versión: un nombre para ese commit, con una etiqueta en el repositorio si la quieres. La propuesta, la fase uno y cada solicitud de cambio se vuelven filas a las que puedes señalar, y la revisión te avisa si una etiqueta se aleja alguna vez del commit que nombraba.
eidos version record
Out of Scope, por escrito
Out of Scope es una sección de la plantilla, no algo de último momento, y las decisiones tomadas para una spec aparecen en la propia spec. «Yo pensaba que eso estaba incluido» se encuentra con una línea que dice que no, y con el nombre de quien lo aceptó.
Un Framework, todos los clientes
Guarda el Framework en un repositorio propio e instálalo desde ahí en cada proyecto de cliente, o parte de la configuración del último cliente sin nada de su contenido. Para compartirlo, publícalo en el Registro: un pull request al Registro en GitHub, un manifiesto que apunta a una raíz con etiqueta, y cualquiera lo instala como @your-studio/name.
$ eidos install your-studio/delivery@v3 --path framework
$ eidos install ../northwind/Blueprints --setup-only
$ eidos install @your-studio/deliveryEmpieza aquí
Frames para el brief y specs para los entregables, con Out of Scope en cada plantilla. Dale forma en Ajustes del Framework hasta que se lea como tu estudio, publícalo, y desde entonces cada cliente parte del tuyo.
Una app, un servicio o un sistema
Frames (los encuadres) de arquitectura, audiencia, criterios y mercado, y specs agrupadas por dominio.
$ eidos install @BuildableWorks/softwareEn la app: configura una raíz nueva y elígelo de la lista.
Descarga Eidos MD, convierte el Framework de software en el de tu estudio y registra la primera aprobación como una versión.
Gratis para macOS, Windows y Linux. Tus archivos siguen siendo texto simple en una carpeta que es tuya.