Conoce cómo se trabaja antes de comprometerte.

• Un producto completo que construir: alcance, interfaz, backend, integraciones, despliegue y entrega, asumidos de principio a fin.
• Un producto existente con una parte que bloquea al resto, donde la parte bloqueante llega por debajo de la capa de aplicación.
• Una superficie de IA o de automatización que tiene que resistir el uso real: límites en las herramientas, evaluación y un camino definido cuando falla.
• Herramientas internas y software operativo sobre los que de verdad funciona un negocio, y no una prueba de concepto.
• Una reconstrucción donde el sistema actual se entiende lo bastante bien como para decir qué debe sobrevivirle.

• El problema, no la solución

  Qué está roto, lento, bloqueado o ausente, descrito desde fuera. La solución que propones sirve más adelante; la restricción es lo que da forma al alcance.

• Quién lo opera

  Quién usa el sistema y qué intenta terminar. Una superficie de producto diseñada sin eso es una conjetura con un sistema de diseño por encima.

• Lo que ya funciona

  El stack actual, dónde se aloja y qué no puede cambiar. Las restricciones existentes dan forma a la arquitectura mucho más que las preferencias.

• La fecha límite real

  Lo que de verdad marca la fecha: un lanzamiento, un contrato, una migración, una auditoría. Una fecha con una razón detrás se puede planificar.

• Límites de acceso y de cumplimiento

  Todo lo que regula quién puede tocar producción, dónde pueden vivir los datos y qué hay que firmar antes de empezar a trabajar.

• Cómo se toma la decisión

  Quién firma, qué rango de presupuesto es realista y qué más se está evaluando. Acorta todo lo que viene después.

También puedes leerlo directamente. Los cuatro modelos están comparados lado a lado en la página de servicios, y los siete pasos desde el primer contacto hasta la entrega están más abajo en esta.

Este es el camino que sigue un encargo, publicado como el compromiso que se adquiere y no resumido a posteriori. Es el proceso cuyo cumplimiento podrías exigirnos.

1. 01

   Contacto

   Un brief o una llamada. El brief encaja con un alcance cerrado; la llamada, con un problema que aún está tomando forma. En ambos casos llegas a la persona responsable de definir el alcance del trabajo.

2. 02

   Descubrimiento

   Una o dos sesiones de trabajo sobre restricciones y no sobre funcionalidades: qué funciona hoy, dónde duele, qué riesgos importan primero y qué tiene que ser cierto al final. Todavía sin compromiso por ninguna de las dos partes.

3. 03

   Alcance por escrito

   El problema tal como se entiende, lo que se construirá y lo que no, las etapas, los supuestos de los que depende y los criterios de aceptación de cada etapa. No se factura nada hasta que esto se acuerde, y si muestra que la empresa equivocada se está quedando con el trabajo, lo dice.

4. 04

   Propuesta

   El alcance con precio según uno de los modelos de contratación, con el calendario de pagos, los supuestos que cambiarían la cifra y lo que queda explícitamente fuera. Un precio dado antes de entender el alcance es una conjetura con traje.

5. 05

   Construcción por etapas

   El trabajo se entrega en incrementos revisables sobre el alcance acordado. Cada etapa entrega algo utilizable y se comprueba contra sus criterios de aceptación, en lugar de acumularse hacia una única entrega al final.

6. 06

   Aceptación

   Una etapa está terminada cuando cumple los criterios escritos para ella, no cuando se declara terminada. Lo que no pasa la aceptación se corrige dentro de la etapa, y lo que se descubre que nunca estuvo en el alcance se convierte en una decisión explícita y no en trabajo extra hecho en silencio.

7. 07

   Entrega

   El código fuente en tus repositorios, la infraestructura en tus cuentas, las notas de arquitectura, los runbooks, las decisiones y las alternativas descartadas, y las limitaciones conocidas. La prueba es si un ingeniero que no estuvo en el desarrollo puede retomarlo sin negociar.

• Por escrito por defecto

  Avances, decisiones y bloqueos por escrito, con un ritmo acordado al arrancar. Las llamadas son para lo que la escritura hace mal: el desacuerdo, la ambigüedad y el diseño.

• Un punto de control programado

  Una llamada periódica en tu zona horaria, además de lo que el trabajo necesite. El punto de control existe para que un problema nunca espere al siguiente informe de estado.

• Revisión de etapa

  Cada etapa se revisa contra sus criterios de aceptación a medida que llega, de modo que la calidad se comprueba de forma continua y no se descubre al final.

• Decisiones registradas

  Las decisiones de arquitectura se escriben cuando se toman, con las alternativas que se descartaron. Ese registro forma parte de lo que pagas.

• Se puede firmar un acuerdo de confidencialidad antes de hablar de ningún detalle. Envía el tuyo, o pídelo y se te facilita uno mutuo.
• Eres dueño del código y de la propiedad intelectual producida durante el encargo. Eso se dice en el documento del encargo, no se da por supuesto.
• El acceso sigue el mínimo privilegio y se limita al trabajo en curso, se pide por sistema en lugar de concederse de forma amplia al arrancar, y se devuelve al terminar.
• Las credenciales se quedan en tu almacén de secretos. Nunca en el código fuente, nunca en un hilo de chat, nunca en un ticket.
• La infraestructura se ejecuta en tus cuentas y el código fuente vive en tus repositorios, así que revocar el acceso es algo que puedes hacer sin pedirlo.
• Cuando un desarrollo necesita de verdad a un especialista, esa persona se nombra durante la definición del alcance, la apruebas tú y se limita a esa parte del proyecto bajo el mismo acuerdo de confidencialidad y las mismas reglas de acceso. Sin externalización, sin traspaso a una agencia, sin intermediarios de plataformas, y con un único responsable de principio a fin.
• La facturación es por hito según el calendario acordado, en tu moneda cuando los canales de pago lo permiten.
• En remoto como norma y global. El solapamiento de horarios de trabajo se acuerda al arrancar y no se da por supuesto.

• Trabajo cuyo precio se basa sobre todo en ser la opción más barata. La ingeniería que hace que un sistema dure no sobrevive a esa restricción.
• Un precio fijo sobre un alcance que nadie ha escrito todavía. Definir el alcance va primero, y es un trabajo real.
• Ampliación de plantilla por horas sin un resultado definido, donde el encargo es un puesto y no un resultado.
• Cualquier cosa que exija una fecha límite que el alcance no puede sostener. Una fecha que solo se cumple saltándose las partes que hacen que aguante no merece acordarse.
• Trabajo donde nadie de tu lado puede tomar una decisión. Un encargo sin una contraparte que pueda decir sí se atasca en la primera bifurcación.

• PáginaConfianza y datosLas respuestas para una evaluación de proveedores: los subencargados del tratamiento detrás de este sitio y lo que guarda cada uno, cuánto tiempo se conserva un envío y los datos de la entidad registrada que pide un alta de proveedor.
• PáginaSeguridadLa ingeniería detrás del marco comercial: mínimo privilegio, dónde viven las credenciales, qué puede tocar un agente o una integración y cómo informar de una vulnerabilidad.
• DocumentosEjemplos de entregablesLos documentos mencionados justo arriba, publicados como formatos reales: qué registra cada uno, en qué momento de la secuencia llega y el riesgo que elimina.