Cómo hacer outsourcing de tu proyecto de software con éxito: 5 recomendaciones útiles

subcontratar de software

Cuando se trata de equipos de desarrollo de software subcontratados, es fundamental que tu enfoque de gestión sea el correcto. Elegir este enfoque correcto puede ayudar a brindar beneficios comerciales clave, como cronogramas de desarrollo acelerados, escalabilidad mejorada drásticamente y costos más bajos (ya sea que estés empleando un aumento de personal o un equipo completamente administrado).

Pero sin el enfoque de gestión adecuado, un equipo subcontratado puede generar riesgos. La falta de comunicación puede generar retrasos. Los cables cruzados en los requisitos clave del proyecto pueden dar como resultado un producto final que no cumpla con la función prevista.

En este artículo, nos enfocamos en algunas recomendaciones prácticas para gestionar una relación de subcontratación que genere el mayor valor posible para tu negocio. Esta guía ofrece una descripción general de alto nivel de la gestión de equipos de desarrollo subcontratados y al mismo tiempo brinda nexos con algunos recursos más detallados sobre temas que se van relacionando a lo largo del camino.

Aquí están las cinco recomendaciones; a continuación, desglosamos cada una con más detalle.

5 recomendaciones para gestionar equipos de desarrollo de software subcontratados:

  1. Establece una propiedad clara del producto
  2. Céntrate en la función y evita la microgestión de los desarrolladores
  3. Implementa prácticas de comunicación coherentes
  4. Implementa un equipo multidisciplinario
  5. Asegúrate de que los equipos mantengan una documentación de proyectos flexible y ágil

Recomendación de outsourcing de desarrollo de software n. ° 1: Establece una propiedad clara del producto

El primer paso es identificar claramente a un “Propietario del producto”, un líder interno con una clara responsabilidad general de los productos que están desarrollando los equipos de desarrollo subcontratados.

Para las empresas más grandes, es probable que este líder tenga como título formal “Dueño de producto”. Para las empresas más pequeñas, esta persona puede ser un CTO, un CIO o incluso un cofundador técnico.

Lo importante es que tengan el tiempo y la perspectiva para funcionar como nexo entre el personal técnico y el de negocios.

El Dueño de producto debe asegurarse de contar con una definición clara de éxito al iniciar el ciclo de desarrollo. A medida que avanza el desarrollo, el equipo debe verificar periódicamente esta definición, un método clave para mantener el proyecto alineado con sus objetivos comerciales finales. Esta definición debe ser lo más concreta posible (por ejemplo, “Queremos que la mitad de nuestra base de usuarios internos use esta aplicación todos los días dentro de las 2 semanas posteriores al lanzamiento.”) para fomentar una consideración cuidadosa sobre cómo desarrollar un producto y una estrategia de producto que sea capaz de hacer realidad esta visión.

Perder de vista el éxito es un riesgo que siempre está presente, pero puede evitarse. Este riesgo aparece con el desarrollo de aplicaciones personalizadas.

Puede leer más sobre la mitigación de algunos de los riesgos más importantes para lograr un desarrollo exitoso en este artículo.

Recomendación para el outsourcing de desarrollos de software n. ° 2: Céntrate en la función y evita la microgestión de desarrolladores

La microgestión excesiva puede impedir que sus equipos de desarrollo hagan el mejor trabajo posible.

Esta microgestión a menudo adopta la forma de especificaciones de proyectos demasiado prescriptivas. Por muy bien intencionadas que sean, pueden limitar la capacidad de los ingenieros de software profesionales de utilizar su propio juicio y creatividad para encontrar el mejor método posible para cumplir los objetivos del producto.

Creemos que los equipos de desarrollo funcionan mejor cuando están capacitados para adoptar un enfoque experimental similar al de I + D para descubrir el mejor camino y lograr los objetivos finales de un producto de software.

Los propietarios de productos deben centrarse en la planificación y supervisión de alto nivel. Durante las reuniones diarias y las demostraciones / revisiones de sprint, los propietarios de productos pueden proporcionar el mayor valor al evaluar el progreso del desarrollo desde una perspectiva funcional del usuario final. Por lo general, no deberían centrarse en decisiones de codificación específicas, sino en las historias de los usuarios, las tareas clave que los usuarios deben poder realizar. Las revisiones periódicas deben incorporar un prototipo funcional en un dispositivo real, incluso si sigue siendo una estructura alámbrica en blanco y negro, para ayudar a proporcionar un punto de evaluación tangible.

El objetivo es evitar especificaciones demasiado específicas del método y centrarse en la función última del software. Esto brinda a los desarrolladores el mayor espacio posible para ser creativos e implementar una solución eficiente. Este enfoque maximizará la efectividad de sus desarrolladores y preservará su cordura.

Los detalles de la ejecución deben quedar en manos de un “Propietario del proceso”, ya sea un Gerente de proyecto, un entrenador de Agile, un Scrum Master o un Dueño de soluciones. Si bien el Propietario del producto suele ser una figura interna, el Propietario del proceso a menudo forma parte de un equipo de desarrollo subcontratado.

El Propietario del proceso debe proporcionar el mejor entorno de desarrollo posible para mantener al equipo altamente productivo, eficiente y bien alineado con los objetivos finales. Su trabajo es detectar y eliminar el desperdicio, planificar las tareas, mantener las mejores prácticas y asegurarse de que las herramientas necesarias estén en su lugar. Necesitan un amplio conocimiento de los diferentes procesos de desarrollo para poder elegir el más adecuado en función de las restricciones organizativas relevantes.

Recomendación para el outsourcing de desarrollos de software  n. ° 3: Implementa prácticas de comunicación coherentes

No es necesario que sean demasiado formales, pero su equipo necesita algunos procedimientos bien definidos para comunicarse durante el transcurso del proyecto. El propósito subyacente de esta comunicación es garantizar que el trabajo de desarrollo diario se mantenga lo más alineado posible con los objetivos del producto.

Las reuniones diarias son una gran práctica, por ejemplo, para mantener al equipo en la misma página. Los controles frecuentes, por breves que sean, ayudan a evitar el desperdicio de esfuerzos y evitan sorpresas para los propietarios de productos: reciben una actualización todos los días.

También es eficaz mantener reuniones retrospectivas después de cada sprint, conocidas coloquialmente como “sprint retros“: estas retrospectivas son un buen momento para identificar problemas persistentes, discutir posibles mejoras de productos y considerar cualquier cambio que pueda ayudar a que el proceso de desarrollo funcione mejor para el siguiente sprint.

La comunicación constante es una de las formas más poderosas de eliminar el riesgo del desarrollo de nuevos productos.

En este enlace, analizamos en profundidad los errores de comunicación y cómo pueden dañar la eficacia de su relación de subcontratación.

Recomendación para el outsourcing de desarrollos de software  n. ° 4: Implementa un equipo multidisciplinario

En la actualidad, el lanzamiento de un producto de software efectivo requiere experiencia multifuncional y un equipo compuesto por personas de diferentes áreas funcionales del negocio, incluidos diseñadores de UI, especialistas en UX, desarrolladores de back-end y front-end, ingenieros de control de calidad e incluso analistas de negocios y marketing. Algunas empresas tienen un hábito cultural arraigado de crear equipos “aislados” que ocasionalmente interactúan entre sí o “traspasan” el proyecto completo entre las fases de desarrollo.

Según nuestra experiencia, es mucho más eficaz organizar un equipo verdaderamente multifuncional que pueda colaborar en el producto a diario.

Los beneficios clave de un equipo de desarrollo de software multifuncional incluyen lo siguiente:

  • Eliminación de prioridades e incentivos en conflicto: en lugar de que diferentes equipos presionen para cumplir con sus plazos, los miembros del equipo tienen un horario y un conjunto de prioridades compartidos.
  • Comunicación muy mejorada: un equipo de trabajo cercano es menos propenso a tener problemas de comunicación, mientras que todos los miembros del equipo obtienen una visión más integral del producto para el que están trabajando.
  • Cronogramas de productos más rápidos: los equipos multifuncionales pueden evitar los cuellos de botella departamentales e iterar nuevas versiones de manera más rápida y con mayor capacidad de respuesta.
  • Desarrollo centrado en el usuario: las contribuciones diarias de expertos en UX, diseño y gráficos ayudan a alinear las decisiones de desarrollo con los objetivos finales del usuario.

Recomendación para el outsourcing de desarrollos de software  n. ° 5: asegúrate de que los equipos mantengan la documentación de proyectos flexible y útil en Agile

No existe una única forma correcta de realizar la documentación del proyecto, pero el enfoque correcto puede ayudar a garantizar el éxito y evitar el trabajo de documentación innecesario y que requiere mucho tiempo.

La documentación eficaz ayuda a mantener tu proyecto dentro del tiempo y el presupuesto estipulados mientras actúa como un recurso para incorporar nuevos desarrolladores y preservar el conocimiento sobre las decisiones clave de desarrollo para el futuro.

Incluso en un entorno ágil, la documentación no debe ignorarse. Es un paso vital para maximizar el valor de su software a largo plazo. Y es una herramienta esencial para mantener un enfoque estricto en los requisitos dinámicos del proyecto.

Recomendamos este artículo si deseas obtener una visión mucho más detallada de un enfoque práctico y basado en valores para la documentación de proyectos de software en Agile.

Emplear un enfoque de outsourcing que refleje los desafíos de su negocio

Es fácil concentrarse demasiado en crear el proceso “perfecto“. ¿Debería ser Scrum? ¿Debería ser Kanban? ¿Debería ser Kanban para equipos que trabajen en Scrum? ¿LeSS? Scrum de Scrums?

Mientras tanto, intentar perfeccionar los detalles del desarrollo de la planificación de procesos puede transformarse en una tarea igual de abrumadora.

¿Cuántas personas deberían formar parte de un equipo? ¿Qué pasa si el equipo no puede ser multifuncional debido a restricciones organizativas? ¿Qué pasa si tenemos varios equipos y varios productos interdependientes?

En definitiva, cada equipo subcontratado es diferente. Es por eso que no existe una fórmula “según el libro” para cada uno. El mejor enfoque es adoptar un enfoque experimental para aprender qué funciona mejor para su equipo: prueba el proceso que parezca más apropiado para el contexto y cambia según sea necesario.

Distillery apoya a clientes con modelos que van desde el aumento específico de personal hasta equipos de proyectos subcontratados completamente administrados (puedes leer más sobre cómo elegir el modelo de subcontratación adecuado para tu negocio aquí).

Creemos que es más eficaz alejarse de los procesos abstractos y centrarnos en evaluar los objetivos y los recursos disponibles.

En muchos casos, estamos personalizando nuestras prácticas de gestión de proyectos para reflejar un equipo mixto único compuesto por recursos internos y externos.

Nuestro objetivo final es crear un equipo que funcione como una extensión natural de la organización de nuestro cliente.

Si desea conversar con Distillery sobre cómo podemos crear un equipo que esté listo para trabajar en tu proyecto de software, puede ponerse en contacto con nosotros aquí.

About the author

El entrenador en Agile, Roman Blazhko se especializa en ayudar a los clientes a lanzar sus negocios. Para cumplir con este objetivo, apoya a sus equipos en el proceso de desarrollo de productos, ayudándolos a seleccionar y establecer marcos, prácticas y herramientas adecuadas para maximizar la eficiencia y el valor tanto para los usuarios como para el negocio. Roman es un practicante certificado de LeSS, Propietario de producto Scrum certificado y Scrum Master certificado. Tiene una gran experiencia en el trabajo con equipos de desarrollo de juegos móviles y equipos de productos / servicios financieros. En su tiempo libre, le encanta hacer viajes por carretera, tanto para descubrir nuevos países, lugares y culturas como para asistir a eventos deportivos automovilísticos.