Ampliación de personal o externalización de sistemas heredados

La ampliación de personal, los proyectos externalizados y los contratos donde el proveedor responde por la entrega pueden producir buen software. Fallan por motivos distintos porque venden unidades de responsabilidad diferentes. Uno vende personas, otro vende un paquete de trabajo descrito y el tercero vende un resultado operativo cuya puesta en producción corre a cargo del proveedor.

Los compradores suelen comparar tarifas diarias y fechas de entrega sin expresar esa diferencia. Así es como un contrato que parecía económico en una reunión de seguimiento acaba dejando a un ingeniero interno la decisión de volver a ejecutar un proceso por lotes fallido a las 02:00. La pregunta útil no es qué modelo comercial parece más seguro. Es quién tiene la autoridad, la información y la obligación de tomar la siguiente decisión irreversible cuando el plan deja de coincidir con la realidad.

He visto funcionar los tres modelos y también he visto usar cada uno como disfraz. Se venden manos adicionales como si fueran un equipo. Se llama resultado a un alcance fijo. Un proveedor afirma ser responsable de la entrega, pero obliga al cliente a aprobar cada decisión arquitectónica. Los nombres de la propuesta no resuelven el modelo operativo. Lo resuelven los derechos de decisión, las pruebas de aceptación y el deber de responder ante incidentes.

La ampliación de personal alquila capacidad, no resultados

La ampliación de personal funciona cuando su organización ya sabe dirigir el trabajo. Usted incorpora ingenieros a un equipo existente y sus responsables conservan el backlog, la arquitectura, la decisión de lanzamiento y la responsabilidad operativa. El proveedor le debe personas capacitadas según las condiciones acordadas. Su empresa sigue debiéndose a sí misma un resultado.

Eso puede ser exactamente lo adecuado. Un equipo de producto puede tener un límite de servicio claro y una cola de seis meses de trabajo comprendido. Puede necesitar dos ingenieros de Go con experiencia mientras termina de contratar. El trabajo se puede dividir, revisar y desplegar con mecanismos que el equipo ya posee. En ese contexto, la ampliación aumenta el rendimiento sin inventar otra capa de gestión.

El modelo se rompe cuando al comprador le falta en realidad liderazgo técnico o conocimiento del sistema. Diez contratistas no pueden ejecutar una decisión que nadie está cualificado para tomar. Esperarán, deducirán o crearán respuestas locales. El responsable interno se quejará de que les falta iniciativa, mientras los contratistas observarán con razón que cambiar la propiedad de los datos nunca estuvo dentro de su autoridad.

Fred Brooks formuló la versión de calendario de esta idea en The Mythical Man-Month: añadir personas a un proyecto de software retrasado puede retrasarlo más porque la formación y la comunicación consumen la capacidad que se esperaba añadir. Algunos repiten la ley de Brooks como si aumentar el personal nunca ayudara. Esa lectura es demasiado amplia. Los ingenieros adicionales ayudan cuando el trabajo es divisible, las interfaces son estables y alguien puede absorber la carga de revisión. Perjudican cuando cada persona nueva necesita a especialistas escasos para entender un sistema mal documentado.

La trampa comercial consiste en medir la asistencia porque es lo que el contrato suministra con claridad. Las hojas de horas, la ocupación y la velocidad individual dicen poco sobre si el sistema se vuelve más seguro de modificar. Si sus responsables no pueden definir el trabajo terminado sin mencionar las horas consumidas, ha comprado mano de obra y ha perdido la discusión sobre el valor.

Use la ampliación de personal solo si un responsable interno concreto puede responder todas estas preguntas sin llamar al gestor de cuenta del proveedor: ¿qué backlog prevalece cuando las prioridades chocan? ¿Quién puede cambiar una interfaz? ¿Quién acepta una versión? ¿Quién lleva el busca? ¿Quién retira el acceso de un contratista? Si las respuestas se reparten por un comité, más personas ampliarán la cola frente a ese comité.

La externalización solo funciona con un límite estable

La externalización tradicional funciona mejor cuando el comprador puede describir un servicio delimitado y evaluarlo en su límite. El procesamiento de nóminas, una cola de soporte con niveles de servicio definidos o un componente con un protocolo maduro pueden encajar. El proveedor decide cómo dotar el trabajo y el comprador evalúa los resultados según el contrato.

La modernización de software rara vez empieza con tanta claridad. Un conjunto de sistemas heredados oculta comportamiento en calendarios de tareas, costumbres de operadores, restricciones de bases de datos, traspasos mediante hojas de cálculo y consumidores posteriores que nadie incluyó en los requisitos. Un pliego puede fijar el precio y el alcance, pero no puede hacer desaparecer esas incógnitas. Solo decide quién tendrá que negociar cuando aparezcan.

El fallo habitual comienza con un documento de requisitos grueso y una definición de aceptación delgada. El proveedor implementa las pantallas e interfaces indicadas. Más tarde, el comprador descubre que el proceso de cierre trimestral depende de un orden concreto de registros y de un reintento no documentado. El proveedor lo llama petición de cambio porque el documento no lo mencionaba. El comprador lo llama defecto porque producción lleva quince años comportándose así. Ambas posturas se pueden defender y el sistema sigue sin funcionar.

Por eso la externalización transfiere la ejecución con más facilidad que el riesgo. Si la aceptación significa conformidad con el alcance escrito, el comprador posee cada omisión del alcance. Si significa paridad con el comportamiento observado en producción, el proveedor necesita acceso a pruebas representativas y autoridad para cambiar su enfoque cuando esas pruebas contradigan el documento. Son contratos muy diferentes.

La externalización también crea una separación arquitectónica en el límite comercial. El proveedor optimiza el componente que cobra por entregar. Su equipo de plataforma optimiza el conjunto. Si nadie posee la interacción, ambos lados pueden tomar decisiones razonables que produzcan un todo poco razonable: almacenes de identidades duplicados, observabilidad incompatible, dos políticas de reintento o un modelo de datos que filtra supuestos internos entre servicios.

Un límite estable es más que una especificación de API. Incluye la propiedad de los datos, la semántica de los fallos, la independencia del despliegue, el encaminamiento del soporte y los cambios que cada parte puede hacer sin permiso. Si esos hechos no están resueltos, está externalizando una negociación. Ponga precio a ese trabajo de gestión o elija un modelo que sea responsable del descubrimiento como parte de la entrega.

La responsabilidad de entrega mueve el límite del riesgo

Un contrato con responsabilidad de entrega hace que el proveedor responda por un resultado en producción, no solo por un equipo dotado o una lista de tareas. El proveedor debe controlar las decisiones de implementación necesarias para lograr ese resultado y asumir el coste de corregir el trabajo que no cumpla la aceptación acordada. Sin esas dos propiedades, la responsabilidad de entrega es una etiqueta pegada a la externalización.

Este modelo sirve cuando el trabajo tiene un límite de negocio claro, pero una incertidumbre considerable de implementación. Reescribir una aplicación heredada es un buen ejemplo. El comprador puede nombrar los flujos que deben continuar, los sistemas que se deben conectar y las restricciones operativas que no pueden cambiar. Tal vez no conozca cada regla enterrada en el código ni la mejor arquitectura de destino. Se paga al responsable de la entrega para resolver esa incertidumbre y demostrar el resultado.

El modelo cuesta más que la capacidad bruta porque el proveedor pone precio al riesgo. Esa prima solo tiene sentido si el riesgo se mueve de verdad. Lea las exclusiones. Si el proveedor puede tratar cada comportamiento no documentado, retraso de una dependencia y diferencia de entorno como un cambio facturable, el comprador sigue siendo dueño de las incógnitas. Si el cliente debe prescribir la arquitectura, aprobar cada elección técnica y aportar el equipo de lanzamiento, el proveedor no puede afirmar honestamente que posee la entrega.

La responsabilidad real tiene obligaciones simétricas. El proveedor necesita autoridad sobre el método, la dotación y el diseño dentro de las restricciones acordadas. El comprador necesita autoridad sobre las políticas de negocio, el acceso a producción, la tolerancia al riesgo y la aceptación. Cualquiera puede bloquear al otro, por lo que el contrato debe fijar tiempos de respuesta y vías de escalado para las dependencias del cliente. La responsabilidad de entrega no permite que el proveedor eluda el gobierno. Impide que el gobierno siga siendo una cola del cliente que nadie mide.

No confunda una garantía con la responsabilidad operativa. Un proveedor puede prometer que corregirá defectos después de la aceptación mientras su equipo sigue detectando incidentes, limitando daños y decidiendo si revierte. Ese acuerdo puede ser válido, pero el riesgo de las 02:00 se quedó con usted. Si espera que responda el proveedor, dele telemetría, procedimientos, acceso y una obligación explícita de guardia. Las expectativas sin acceso producen teleconferencias, no recuperación.

La responsabilidad de entrega es más sólida cuando la aceptación se puede ejecutar. Las pruebas, las reproducciones de tráfico, las salidas conciliadas y los ensayos de recuperación convierten una discusión sobre integridad en pruebas. La opinión de un comité de seguimiento no puede sustituirlas, en especial cuando las personas que aprobaron el alcance duermen durante el primer fallo.

La arquitectura pertenece a quien puede rechazar un cambio

La responsabilidad de arquitectura es la autoridad para aceptar o rechazar decisiones de diseño importantes y vivir con sus efectos operativos. No pertenece a quien dibuja los diagramas. Un arquitecto jefe que puede aconsejar, pero no detener la división de un esquema, no posee esa decisión. Un proveedor que debe pedir permiso para cada elección sustancial tampoco posee la arquitectura.

Reparta las decisiones por dominios en vez de declarar una responsabilidad conjunta imprecisa. El cliente suele tener que poseer las restricciones empresariales: identidad, tratamiento de datos regulados, zonas de red, entornos de ejecución aprobados, límites de los sistemas de registro y costes operativos objetivo. El equipo de entrega debe poseer las elecciones de implementación dentro de esas restricciones: límites de módulos, secuencia de migración, bibliotecas internas, diseño de pruebas y tácticas de refactorización. Las decisiones que alteren una interfaz compartida necesitan un árbitro designado y un plazo.

La idea de Architecture Decision Record de Michael Nygard resulta útil porque recoge una decisión, su contexto y sus consecuencias en un registro breve. Martin Fowler insiste en que una decisión posterior debe sustituir a un registro antiguo, no reescribir la historia. Esto importa en relaciones con proveedores. Un historial limpio muestra si un mal resultado provino de una restricción, una elección de implementación o nuevas pruebas, sin convertir el registro en un libro de culpas.

El registro aún necesita un responsable de la decisión. Una carpeta llena de ADR puede documentar la parálisis con tanta pulcritud como el buen criterio. Añada cuatro campos a cada decisión sustancial: proponente, partes consultadas, responsable de decidir y motivo de revisión. Este último importa porque una elección sensata con diez mil transacciones diarias puede ser errónea después de que una fusión duplique la carga.

Team Topologies propone equipos alineados con un flujo y responsables de extremo a extremo, además de equipos facilitadores que desarrollan durante un tiempo una capacidad ausente. La enseñanza útil para la contratación es que la ayuda debe dejar al equipo responsable más capacitado. Si los especialistas externos se convierten en traductores permanentes entre su producto y su propia plataforma, ha creado una dependencia, no ha capacitado a un equipo.

La arquitectura puede seguir siendo interna con cualquier modelo comercial. Lo que cambia es la carga de gestión. Con ampliación de personal, la arquitectura interna es la situación predeterminada. Con externalización, usted debe vigilar la separación. Con responsabilidad de entrega, define restricciones y deja que el proveedor diseñe dentro de ellas. Mezclar estos acuerdos decisión a decisión es posible, pero cada excepción añade un traspaso que necesita un responsable.

El fallo de las 02:00 lee el contrato en voz alta

Un fallo en producción expone la distribución real de responsabilidades más rápido que cualquier diapositiva de gobierno. Imagine un proceso de liquidación migrado que lee 1,8 millones de registros, escribe asientos contables y publica un evento de finalización. A las 02:07 se detiene después de confirmar la base de datos, pero antes de publicar el evento. El planificador marca el proceso como fallido.

Un operador ve tres acciones posibles. Volver a ejecutar el proceso y arriesgarse a duplicar asientos. Publicar el evento manualmente y arriesgarse a anunciar una ejecución incompleta. Restaurar la versión anterior y arriesgarse a aplicar código antiguo sobre un estado parcialmente migrado. No es principalmente un problema de depuración. Alguien debe conocer el límite de idempotencia, tener autoridad para elegir y cargar con la consecuencia.

Con ampliación de personal, su responsable de incidentes posee esa decisión. Los contratistas pueden diagnosticar y asesorar, pero su modelo operativo los dirige. Si el único ingeniero que entiende el marcador de confirmación pertenece al proveedor y no está de guardia, el contrato de personal ha expuesto una concentración de conocimiento que usted aceptó.

Con una externalización convencional, la respuesta depende del alcance del servicio. Si el proveedor opera el proceso con un nivel de servicio basado en resultados, su responsable puede dirigir la recuperación. Si solo construyó y entregó la aplicación, su equipo se ocupa del incidente e invoca después el proceso de defectos. Un número de soporte en el contrato no decide quién puede modificar datos de producción.

Con responsabilidad de entrega, las obligaciones deben seguir la fase de aceptación. Antes de aceptar la producción, el proveedor suele poseer el diagnóstico y la corrección, mientras el cliente controla la autoridad sobre producción. Durante una transición observada conjuntamente, nombre a un responsable de incidentes y a un aprobador de negocio. Después de la aceptación, las obligaciones pueden pasar al cliente o seguir con el proveedor, pero la transferencia debe incluir pruebas de recuperación, no solo un procedimiento.

Ponga el acuerdo operativo en una forma que los ingenieros puedan probar. Este ejemplo no es una norma, sino un anexo contractual compacto que evita la ambigüedad más cara:

incident: settlement-batch-partial-commit
detection_owner: customer-operations
incident_commander: delivery-supplier
data_mutation_approver: customer-finance-platform
diagnosis_sla_minutes: 20
allowed_without_approval:
  - pause-downstream-consumers
  - capture-logs-and-state
forbidden_without_approval:
  - rerun-batch
  - publish-completion-event
  - restore-database
exit_evidence:
  - ledger-count-reconciled
  - duplicate-check-passed
  - downstream-event-confirmed

Ensaye el acuerdo antes del lanzamiento. Inyecte un fallo entre la confirmación y la publicación en un entorno similar al de producción y observe quién puede ver la alerta, obtener las pruebas y aprobar la siguiente acción. Si el ensayo se atasca por falta de acceso o autoridad, cambiar una frase del contrato después del lanzamiento no acelerará la recuperación.

El conocimiento se queda donde se toman decisiones

La transferencia de conocimiento falla cuando se trata como un entregable final. Un repositorio documental puede guardar hechos, pero los ingenieros aprenden un sistema tomando decisiones, viendo fallos y cambiando el diseño. Si el proveedor toma todas las decisiones relevantes mientras el personal interno asiste a demostraciones semanales, el proveedor se marchará con el razonamiento.

La ampliación de personal puede conservar bien el conocimiento porque los ingenieros externos trabajan dentro del equipo, el proceso de revisión y las herramientas del cliente. También puede hacer lo contrario. Si los contratistas reciben todo el trabajo heredado poco atractivo mientras los empleados construyen la nueva plataforma, se convierten en los únicos que entienden el comportamiento del que dependen los ingresos. El tipo de contrato no causó esa división, sino la asignación del trabajo.

La externalización suele generar artefactos explícitos porque el límite comercial los exige. Su punto débil es el contexto. Un paquete de entrega describe lo que existe al final, mientras el equipo del proveedor recuerda por qué fallaron las alternativas descartadas. Exija que los ingenieros internos participen en revisiones de diseño y ensayos de incidentes, no que se limiten a aceptar documentos. Esa participación consume capacidad durante la entrega y ese coste compra independencia para después.

El trabajo con responsabilidad de entrega crea una tensión mayor. Contrata al proveedor porque puede resolver la incertidumbre deprisa, de modo que obligar a una aprobación interna para cada decisión destruye el modelo. Sin embargo, una separación total deja a su equipo sin capacidad para operar o ampliar el resultado. La respuesta no es compartir la responsabilidad de cada elección. Dé a los ingenieros internos una responsabilidad concreta: una interfaz, un conjunto de pruebas de paridad, una ruta de despliegue o un ensayo operativo. Aprenden al responder por una parte real.

Mida la transferencia mediante acciones independientes. ¿Puede un ingeniero interno explicar por qué un límite está donde está? ¿Puede el equipo diagnosticar una reproducción fallida sin preguntar al proveedor dónde mirar? ¿Puede hacer un cambio pequeño y demostrar la paridad? El número de documentos y la asistencia a reuniones miden entradas. Un cambio independiente que funciona es una prueba.

Vigile los incentivos cerca del final. Un proveedor que factura tiempo se beneficia de que las preguntas continúen. Uno con alcance fijo se beneficia de que la entrega termine deprisa. Un responsable de entrega puede optimizar la aceptación y dejar una operación débil si la prueba de aceptación no la incluye. Los contratos no hacen que los proveedores sean poco fiables. Vuelven ciertos atajos económicamente atractivos. Sus controles deben apuntar a esos atajos.

El control y la responsabilidad deben ir juntos

La distribución del riesgo se vuelve ficticia cuando una parte soporta la responsabilidad, pero otra controla la decisión que la crea. Un proveedor no puede garantizar una fecha de lanzamiento si el cliente añade requisitos sin mover la aceptación. Un cliente no puede poseer la disponibilidad si solo el proveedor controla el despliegue y la observabilidad. Los contratos suelen crear estos desajustes porque personas centradas en preocupaciones distintas negocian cada cláusula por separado.

Sitúe el control junto a la consecuencia. Si el proveedor elige la secuencia de migración, debe corregir a su costa los defectos de esa secuencia. Si el cliente obliga a usar una base de datos concreta o bloquea el acceso a pruebas de producción, debe asumir el riesgo de retraso y compatibilidad que crea esa restricción. Si ambos aprueban una interfaz compartida, nombre a la persona que rompe un bloqueo. «Acuerdo mutuo» describe una reunión, no un mecanismo de decisión.

Los límites de responsabilidad económica no dicen a los ingenieros qué hacer durante un incidente. Resuelven parte de la disputa financiera después del daño. El riesgo operativo necesita mecanismos más rápidos: acceso, alertas, autoridad de decisión, criterios de reversión y una ruta ensayada hasta la persona que puede aceptar el impacto empresarial. Trate las indemnizaciones y el mando de incidentes como capas separadas. Los remedios legales importan, pero no concilian un libro contable antes de que abra el negocio.

El control de cambios merece la misma precisión. Hay al menos cuatro sucesos distintos que los equipos llaman cambio:

• El cliente pide un comportamiento nuevo que nunca tuvo el sistema anterior.
• El descubrimiento revela un comportamiento existente omitido del alcance escrito.
• El proveedor cambia su diseño porque el primer enfoque no puede cumplir la aceptación.
• Una dependencia externa cambia después de que ambas partes fijaran la referencia.

Esos sucesos no deben compartir el mismo tratamiento comercial. Un comportamiento nuevo suele cambiar el precio, el tiempo o ambos. Un comportamiento existente, pero no documentado, pertenece a quien aceptó el riesgo de descubrimiento. Un enfoque fallido suele pertenecer a la parte que controlaba el diseño. Un cambio externo sigue los supuestos de dependencia escritos en la referencia. Un único proceso de solicitudes deja que el poder comercial decida lo que deberían decidir las pruebas técnicas.

El gobierno debe revisar las pruebas al ritmo en que aparece el riesgo. Una reunión mensual sirve para el presupuesto y las decisiones ejecutivas, pero es demasiado lenta para elecciones de interfaces que bloquean el trabajo diario. Cree una ventana breve para excepciones arquitectónicas y dependencias del cliente. Cuando venza, el contrato debe indicar si el trabajo se detiene, se aplica una opción predeterminada o el asunto escala a un responsable nombrado. El silencio debe tener un efecto definido.

Las métricas también pueden mover el riesgo en la dirección equivocada. Pagar por tickets cerrados premia los tickets pequeños. Pagar por líneas convertidas premia la transliteración y penaliza la eliminación. Pagar solo al aceptar todo puede animar al proveedor a ocultar la incertidumbre hasta tener un sistema que parezca completo. Los hitos deben corresponder a riesgo reducido: comportamiento trazado, interfaces demostradas, tráfico reproducido, despliegue recuperable y operación independiente. El pago puede seguir esos resultados sin fingir que todos exigen el mismo esfuerzo.

La prueba práctica es la simetría. Para cada obligación, pregunte si la parte obligada posee la información y la autoridad necesarias. Para cada derecho de aprobación, pregunte si quien aprueba soporta el retraso que puede causar. Para cada riesgo transferido, pregunte qué prueba demostrará que el proveedor lo asumió. Una obligación sin control se convierte después en exclusión. El control sin consecuencias produce de inmediato un gobierno descuidado.

Compras debe probar el modelo operativo

El departamento de compras puede distinguir los tres modelos pidiendo a los ofertantes respuestas a casos concretos de fallo y decisión. Las presentaciones genéricas premian a los equipos comerciales pulidos. Un escenario corto obliga a cada proveedor a mostrar qué cree poseer, qué necesita de usted y qué excluye.

Pregunte quién paga cuando el comportamiento grabado de producción contradice los requisitos escritos. Pregunte quién elige entre conservar el comportamiento y mejorar la arquitectura. Pregunte quién estará en la primera ejecución, quién puede aprobar una reversión y cuándo cambia de manos la guardia. Ponga después las respuestas en el anexo comercial. Si se quedan en notas de reunión, perderán ante el texto de responsabilidad.

La comparación de precios también debe incluir el trabajo retenido por el cliente. Una tarifa diaria baja puede exigir gestión de producto, arquitectura, ingeniería de calidad y operaciones internas a tiempo completo. Un precio fijo externalizado puede generar un presupuesto de cambios alrededor del comportamiento no documentado. Un precio con responsabilidad de entrega incluye riesgo, pero aún puede depender de especialistas del cliente, acceso al entorno y aprobaciones rápidas. Compare el esfuerzo operativo total, no solo las facturas del proveedor.

Use puertas de aceptación que correspondan al riesgo:

1. Defina el comportamiento observable y las tolerancias antes de empezar la implementación.
2. Registre las restricciones arquitectónicas separadas de los diseños preferidos.
3. Reproduzca casos representativos de producción y concilie las salidas.
4. Ejecute un ensayo de recuperación con responsables de decisión nombrados.
5. Haga que un ingeniero interno realice y verifique un cambio pequeño sin intervención del proveedor.

Es una cadena de pruebas, no cinco hitos administrativos. Un proyecto puede pasar la revisión de código y las pruebas funcionales, pero fallar el ensayo de recuperación porque nadie posee el estado parcial. Puede demostrar paridad, pero fallar el cambio independiente porque todo el conocimiento sigue fuera. La aceptación debe exponer esas diferencias antes que la factura final.

No exija precio fijo, alcance fijo y fecha fija para un trabajo dominado por comportamiento desconocido y después finja sorpresa cuando el proveedor se proteja con exclusiones. Elija qué variable puede moverse o pague a alguien para asumir el riesgo del descubrimiento. La certeza comercial creada al redefinir cada descubrimiento como cambio es contabilidad, no certeza de entrega.

El modelo adecuado sigue a la incertidumbre

Elija ampliación de personal cuando el trabajo se entiende, su equipo posee la arquitectura y las operaciones, y el cuello de botella son manos capacitadas. Elija externalización cuando el límite es estable, las salidas son fáciles de inspeccionar y acepta gestionar la interfaz. Elija responsabilidad de entrega cuando el resultado es claro, la implementación es incierta y un proveedor puede controlar suficiente método para cargar con esa incertidumbre.

Distintas partes de un programa pueden utilizar modelos diferentes. Puede ampliar el equipo de plataforma, externalizar una cola de limpieza de datos bien especificada y dar a un proveedor la responsabilidad de entregar una reescritura heredada. Trace los límites alrededor de decisiones y modos de fallo, no de categorías de compra. Una persona debe poseer la integración entre ellos.

No use la responsabilidad de entrega para evitar tener un responsable interno. El cliente sigue siendo dueño de la política de negocio, la aceptación del riesgo y la larga vida del sistema. Ningún proveedor puede decidir qué diferencia financiera es tolerable o qué flujo de clientes puede cambiar. Un buen responsable de entrega elimina incertidumbre de implementación. No sustituye el criterio ejecutivo.

En reescrituras heredadas, el comportamiento suele ser el límite más difícil de especificar solo con documentos. CodeHero lee todo el código, moderniza la arquitectura y comprueba el resultado con un sistema de paridad frente al tráfico de producción grabado, con entrega en menos de 30 días. Esa propuesta solo tiene responsabilidad de entrega si el cliente aporta también las pruebas de tráfico, restricciones, acceso y responsables necesarios para verificar el resultado.

La selección debe superar una última prueba. Escriba un fallo plausible a las 02:00, la persona autorizada para actuar, las pruebas que verá y quién paga por corregir el sistema. Si alguna respuesta es «conjuntamente» o «por acordar», el contrato aún no ha distribuido el trabajo. Ha aplazado la discusión hasta que el sistema esté caído.