Agile para proyectos tercerizados: decisiones claras y visibles

Tercerizar parte del desarrollo de software agrega una frontera entre organizaciones. Un desarrollador puede terminar un ticket mientras el equipo de producto todavía espera una funcionalidad utilizable. Una demo puede resultar convincente aunque sigan pendientes el despliegue, los permisos o el soporte.

Si eres CTO o responsable de ingeniería, la pregunta útil es cómo hacer visibles las prioridades, las decisiones y la evidencia a ambos lados de esa frontera. Los principios del Manifiesto Ágil destacan el software funcional que aporta valor, la colaboración y los ajustes periódicos. Aplicarlos a un proyecto tercerizado exige acuerdos concretos sobre el trabajo.

Asigna autoridad para definir prioridades

Mantén un backlog compartido y designa a una persona de tu organización que pueda decidir qué sigue. Los ingenieros externos necesitan entender el problema del usuario, las restricciones y el motivo de cada prioridad. Una lista de tareas sin contexto no alcanza.

Antes de comenzar, acuerden un resultado útil para la siguiente revisión. Si aparece un pedido urgente, hagan explícita la decisión: qué se posterga, quién lo decide y cómo cambia el resultado esperado. Distingan los pedidos de los compromisos para que varios interesados no generen prioridades contradictorias sin advertirlo.

El modelo de trabajo también importa. En staff augmentation, tu organización conserva la dirección cotidiana. Si el proveedor asume un proyecto definido, documenten quién puede tomar decisiones y quién acepta el trabajo en ese acuerdo.

Define qué significa terminado antes de implementar

Cada tarea necesita criterios de aceptación que describan un comportamiento observable. Acuerden también las condiciones de ingeniería para darla por terminada: revisión de código, pruebas adecuadas, preparación para el despliegue y documentación necesaria para operar el cambio.

Incluyan los requisitos de seguridad de la funcionalidad. Por ejemplo, quién puede utilizarla, qué datos expone y cómo se comprueban los permisos. Una función que anda con una cuenta de administrador puede fallar para el usuario al que está destinada.

La incorporación al equipo es un requisito previo. Asignen responsables para el acceso al repositorio, el entorno de desarrollo, los datos de prueba y una primera recorrida del sistema. Registrar estas dependencias evita confundir un problema de acceso con un problema de desempeño técnico.

Revisa software funcional con quienes lo usarán

Organiza las revisiones alrededor de una parte utilizable del flujo de trabajo. Muestra el software en el entorno acordado e incluye a quien puede aceptar su comportamiento. Las presentaciones y los reportes explican el contexto; la comprobación requiere utilizar la funcionalidad.

Registra el feedback como decisiones o cambios en el backlog, siempre con un responsable. Distingue un defecto respecto de los criterios acordados de un pedido nuevo. Ambos necesitan atención, pero afectan de distinta manera el alcance y las prioridades.

Si el trabajo todavía no se puede demostrar, identifiquen la dependencia o la pregunta pendiente. La revisión debe ayudar a resolverla. Un porcentaje de avance no aclara una incertidumbre sobre cómo debería funcionar el producto.

Comparte las decisiones y el conocimiento del sistema

Usa repositorios y herramientas de seguimiento a los que tu organización tenga acceso. Documenta las decisiones técnicas relevantes junto al trabajo: la restricción, las opciones consideradas, la decisión y quién debe revisarla si cambia el contexto.

Define responsables para revisar código, publicar versiones y atender producción. Procura que más de una persona pueda explicar los componentes críticos. Los ingenieros externos necesitan contexto del producto y tu equipo interno necesita conocimiento suficiente para continuar después de una transferencia o un cambio de personas.

Acuerda horarios de trabajo y escalamiento

Confirma dónde trabaja cada persona y cuál es su jornada real. Define la coincidencia horaria necesaria para revisiones, trabajo conjunto y decisiones urgentes, además de la respuesta esperada fuera de ese horario. Utiliza un calendario que contemple los cambios de hora locales. La comparación entre onshore, offshore y nearshore ayuda a plantear esas condiciones de colaboración.

Deja las actualizaciones rutinarias por escrito y usa el tiempo compartido para decidir. Cuando una dependencia bloquee el trabajo, comunica qué está detenido, su impacto y quién puede resolverlo. Revisen los bloqueos recurrentes y asignen una mejora concreta.

Antes de elegir un socio, aprovecha la primera conversación para contrastar estos acuerdos con una tarea real. Si estás preparando un equipo externo, conversa con un ingeniero sobre el resultado que necesitas, las decisiones que conservarás y las condiciones de entrega que tu equipo puede sostener.