Comunicación de los requisitos a los equipos offshore

No hay garantías en este caso, pero esto es lo que intentaría:

1. O no están entendiendo sus documentos o no están haciendo el trabajo y usando los documentos como chivo expiatorio. Es un poco extremo, pero solicite una reformulación de sus documentos junto con su enfoque anticipado. Obtenga esto para el día siguiente como un precursor para que comiencen a trabajar en el sprint. Esto formalizará la lluvia de ideas que quieres que hagan y, dadas las circunstancias, creo que es un paso necesario.

2. Haga una evaluación honesta de sus documentos para ver si están escritos con un nivel de inglés apropiado. El desarrollador más inteligente no puede cumplir con las expectativas si los requisitos del lenguaje van más allá de lo razonable. Es mucho más fácil escribir documentos complicados que simples y requiere un esfuerzo continuo.

3. ¿Parece que no tienes contacto con ellos durante todo el sprint? Si ese es el caso, debe cambiar para que no descubra que las cosas están desviadas 1/2 día antes del final del sprint. Necesita un compromiso diario documentado sobre su progreso y problemas.

4. Dado el nivel de insatisfacción que tiene con sus habilidades técnicas y de comunicación, no parece que esté en posición de terminar la relación. ¿Puede hacer que el cliente lo presione para aplicar recursos más informados al proyecto?

5. Esta situación no puede permitirse sorpresas en los requisitos y alcances. Debe explicárselo al cliente y asegurarse de que simplemente no suceda. Al permitirlo, reduce la probabilidad de que un equipo desafiado entregue y les da algo para usar en su contra.

6. Finalmente, lo más difícil es evaluar honestamente si necesita pedir ayuda a su empleador. Con sprint tras sprint perdido, esto ha estado sucediendo durante un tiempo. Es doloroso admitir que una situación está fuera de nuestra experiencia, pero es mucho mejor que insistir en que podemos hacerlo y luego fracasar.

Estoy totalmente de acuerdo con Michael y Mark. Ambos solucionaron el problema con la solicitud de una reformulación de sus documentos junto con su enfoque anticipado . Claramente no están entendiendo los requisitos. El problema es... ¿están tratando de entender de antemano? Si no están analizando los requisitos y saltando directamente al desarrollador, lo pasarán mal en el futuro.

Una cosa que debe considerar es la diferencia cultural en el lugar. Hay un video increíble de Robert Dempsey AQUÍ que habla sobre las diferencias culturales y destaca un pequeño detalle que puede cambiarlo todo: los indios no están acostumbrados a decir 'no', incluso si no entienden de lo que estás hablando (soy de Brasil y sé que aquí también pueden pasar cosas similares).

Hay otro punto que (si no me equivoco) Brooks menciona en su TMMM : Es poco probable que tengas una pregunta cuando tienes espacio para asumir cosas. Puede estar alineado con el problema original, los requisitos no están claros. Por lo tanto, cuando revise los requisitos con ellos, asegúrese de separar lo que entendieron de los documentos de requisitos y lo que asumieron en base a ellos.

Seguro que tienes un problema. En última instancia, el problema es tuyo, incluso si el equipo está compuesto por holgazanes totales. Usted es responsable de entregar a tiempo; el equipo solo es responsable ante usted. No estoy seguro de que offshore/onshore sea relevante; No estoy seguro de que muchos de los detalles anteriores sean relevantes (excepto que le habríamos preguntado si no los hubiera proporcionado). Lo relevante de POV es que tiene un equipo que constantemente no cumple. ¿Cuáles son las consecuencias de ese fracaso? ¿Cuáles son las consecuencias para el proyecto? ¿Cuáles son las consecuencias para las partes interesadas? ¿Las consecuencias para el equipo? ¿Y cuáles son las consecuencias para ti?

1. Aunque crea que ha comunicado las historias de los usuarios de manera clara y efectiva (y ciertamente parece que ha hecho todo lo correcto), la comunicación no es efectiva a menos que se reciba. Lo primero que haría en su lugar es encontrar una manera de probar si los destinatarios perciben que "cada requisito es claro y el alcance también está bien definido". Cierra ese ciclo de retroalimentación durante esa reunión de sprint inicial. Cree un circuito de retroalimentación que los obligue a producir un producto medible. ¿Quizás hacer que produzcan las pruebas unitarias para las historias de usuario dentro de las 24 horas posteriores a la sesión informativa inicial? Algo que les impide alegar requisitos poco claros más adelante.
2. Claramente, el sprint de 2 semanas es un marco de tiempo ineficaz para Team India. Necesitan una supervisión más cercana. Hasta que puedan producir un sprint exitoso, se les debe exigir que informen el progreso incremental diariamente. (Semanalmente estaría bien, pero soy escéptico). Tú y el equipo de India comparten un problema y tendrás que compartir la responsabilidad de la respuesta.
3. Métrica. El valor ganado es tu amigo. Usted y Team India comparten la responsabilidad de identificar y corregir el problema de comunicación al principio del sprint. La comprensión compartida del proceso de desarrollo, la identificación de obstáculos y la eliminación de obstáculos son la ruta para salir de esa trampa en particular.
4. La consecuencia para el proyecto es que estás cada vez más tarde. Escalaría esto rápidamente; comience a informar hacia arriba que las fechas del proyecto se están deslizando rápidamente.
   

   "Nuestra fecha de envío ahora está 4 semanas más allá de nuestra línea de base; a menos que Team India pueda entregar en el sprint 7, esa fecha se retrasará dos semanas más. Si el retraso llega a las 8 semanas, el riesgo de que todo el proyecto no se entregue es del 50 %. Si queremos mitigar ese riesgo, podemos contratar a otro equipo de desarrolladores para que se haga cargo del trabajo que actualmente está planificado para Team India".

Antes de comenzar, debo mencionar que he manejado equipos de la India de hasta 180 en más de 100 proyectos en los últimos 10 años y he pasado exactamente por los mismos problemas. Es fundamental en cualquier proyecto hacer coincidir el conjunto de habilidades correcto con el proyecto en cuestión, pero es 10 veces más crítico en la India debido a la cultura, la comunicación, las diferencias horarias, etc.

Otros carteles han señalado los principales problemas;

• La cultura india es significativamente diferente a la estadounidense. La cultura es de naturaleza muy jerárquica y la autoexpresión, el espíritu empresarial, el pensamiento 'fuera de la caja' es bastante raro. Para el 90% de los desarrolladores de la India, si las instrucciones/requisitos están incompletos de alguna manera, es muy probable que no se realice ningún trabajo.
• La calidad del desarrollador en la India es general, he experimentado algunos desarrolladores fantásticos, pero en su mayoría desarrolladores promedio/deficientes. Fuera de la escuela, son extremadamente verdes y generalmente requieren una inversión sustancial en capacitación. Es muy inicial para obtener un buen retorno de la inversión. Es posible que sea necesario ajustar sus expectativas si aún no están bien capacitados y no tienen un gerente/mentor local que los guíe de manera efectiva.
• Comunicación, aunque India requiere el inglés como idioma principal desde una edad relativamente temprana, generalmente solo se habla en el trabajo. Como tal, encontrará un nivel de competencia bastante variado.

Lo que he hecho que funciona es encontrar al menos un desarrollador (o gerente) de la India para liderar el equipo, la comunicación es la principal preocupación, luego la competencia técnica. Sin ese mánager será muy difícil triunfar. Mientras tanto, se levantará de 11:30 p. m. a 3 a. m. o de 6 a. m. a 9 a. Tu otra alternativa es documentar el ???? de todo, asuma que no saben casi nada sobre nada y documente apropiadamente. Puede sonar duro, pero es la realidad. Luego tendrá que revisar todo el resultado constantemente. De cualquier manera, para un equipo de 14, será un trabajo de tiempo completo. Otra opción es contratar a un contratista que esté acostumbrado a trabajar con equipos de la India para liderar el esfuerzo, es un arte trabajar con los recursos de la India de manera efectiva.

Encontrar a ese gerente/desarrollador superior, esa es otra cuestión...