contratos de insumos y productos entre equipos de subsistemas?

Mi proyecto consta de 5 subequipos y creo que lo que la mayoría de la gente subestima es la comunicación del subsistema.

¿Cree que sería una buena idea que los equipos utilicen (o incluso se vean obligados a hacerlo) contratos entre ellos para especificar datos de entrada, datos de salida y posiblemente protocolos/llamadas de comunicación?

Creo que su pregunta puede necesitar un poco de trabajo. La pregunta es un poco incompleta y posiblemente demasiado técnica para este foro.
Supongo que esta pregunta es un subconjunto de esta: pm.stackexchange.com/questions/8286/…
Posiblemente soy un lector perezoso, pero hasta ahora no he visto ninguna metodología para aplicar un enfoque ágil a los ICD. El problema es, por supuesto, quién va a mediar N(N-1) ICD entre N equipos y cómo va a funcionar...
@allnightgrocery: (bastante) detalles sobre mi proyecto están aquí: enlace
@Tiago Cardoso: sí. Debería haber incluido el enlace..
@Deer Hunter: ejem, ¿te refieres a "documento de control de interfaz"? Primera vez que me encuentro con este término.
@Deer Hunter: bueno, es mejor tener 5*4 ICD que interacciones indefinidas de 40*39 (tamaño del equipo == 40). :-) Afortunadamente, dada la descomposición del sistema, no tendríamos que tener 20 contratos. Sería como 5.

Respuestas (5)

No necesitas contratos. Necesita documentos de requisitos claramente definidos para cada uno de los entregables que se producen. Estos deben ser escritos en colaboración por al menos tres equipos:

  • El equipo que usará el entregable
  • El equipo que producirá el entregable.
  • El equipo que proporcionará la entrada al entregable.

El resultado final debe ser una serie de documentos superpuestos que brinden responsabilidades claras para cumplir con los requisitos y productos necesarios para cada entregable.

Este documento colaborativo debe ser revisado por el PM y su equipo para asegurarse de que no haya ningún proceso de aprobación, que el entregable esté dentro del alcance, que los criterios de calidad y aceptación sean claros, que los roles estén definidos, etc., etc. Un buen ejemplo es la plantilla del paquete de trabajo de PRINCE2. Puede obtener esta y otras plantillas [aquí]. 1

eres una mina de oro! Tengo que decir gracias de corazón! Creo que comienza a unirse (paquete de trabajo, ICD tal vez + kanban + responsabilidad + sastrería y supervisión activa que mencionaste en otro hilo).

La respuesta es un inequívoco sí. Si la entrada provino de un proveedor externo, seguramente tendría un acuerdo en términos de cantidad, calidad, especificaciones, costos, lo que sea. ¿Por qué sería diferente si la entrada viniera de una fuente interna?

Ahora, por contrato, la mayoría asumiría algún tipo de acuerdo en papel con firmas. Algunos equipos podrían requerir tal cosa, por ejemplo, si estuviera cruzando las divisiones de la organización, mientras que otros requerirían un simple acuerdo verbal y un apretón de manos. Muchas cartas de equipo también pueden capturar reglas de compromiso, también, hasta cierto nivel.

De cualquier manera, si no está de acuerdo con los requisitos dentro del equipo, no está administrando el trabajo.

Una muy buena respuesta a una pregunta difícil!
"De cualquier manera, si no está de acuerdo con los requisitos dentro del equipo, no está administrando el trabajo". - Lo has clavado, creo.

Sí, ciertamente debe tener una especificación escrita que describa la interfaz entre los subsistemas. Esto formará el contrato entre los equipos involucrados. Ambos (todos) deben estar involucrados en la redacción de la especificación. Dependiendo de su estilo de documentación, podría ser una página wiki u otro documento en línea.

Algunas de las cosas que cubriría incluyen:

  • Formato(s) de los datos.
  • Método de transmisión (archivo, SOAP, REST, otro).
  • Tamaños de lote si los datos se transmitirán por lotes.
  • Tiempo de respuesta esperado (especialmente para las interfaces a las que se accede para OLTP).
  • Horario de disponibilidad.

Puedo visualizar el problema al que se refiere y estoy de acuerdo en que puede valer la pena resolverlo de manera proactiva. (Las soluciones proactivas implican gobernanza/capital político/gestión de las partes interesadas. En algunos entornos, el capital político y la gobernanza son extraordinariamente costosos, por lo que en realidad puede ser más económico a largo plazo planificar el fracaso y resolver el problema de forma retroactiva).

A primera vista, esto es un problema de calidad o un problema de riesgo. El equipo A alimenta al equipo B; El equipo B debe expresar los estándares de calidad deseados y el equipo B debe planificar para mitigar los riesgos si no se cumplen los estándares de calidad. Como dice @David Espina, si no estás gestionando los requisitos (intraequipo), no estás gestionando el trabajo. Si hablamos de protocolos, entradas y salidas, entonces el deseo común de un resultado excelente nos obliga a compartir información muy detallada sobre las expectativas.

¿Eso implica un SLA formal para los equipos? Eso depende de las relaciones involucradas. Si los equipos son cercanos y cooperativos, entonces un SLA formal en realidad puede inhibir la innovación y la mejora de la calidad. Me pongo nervioso cuando introduces el término "forzado a", porque creo que la cooperación es probablemente más importante que la calidad real de cualquier parte. Si no tienen la intención de cooperar y hacer que el otro se vea excelente, entonces es posible que tenga un problema XY , pero tal vez estoy leyendo demasiado profundamente allí.

La razón por la que estoy pensando en obligar a los equipos a hacerlo es que cuando planteé mi idea llamándola "contrato" (completamente espontáneamente sin leer ninguna información de fondo), la idea fue enviada como un aluvión de críticas que ni siquiera puedo encontrar. las piezas.
Flak en el aire sugiere fuertemente un problema XY. Sospecho que el problema no es la calidad, es el liderazgo. Los equipos parecen percibir que sus intereses están en tensión. Lo que me sugiere que la "fuerza" exacerbará el problema, en lugar de resolverlo. ¡La mejor de las suertes!

Saltando del inquilino ágil de centrarse menos en la documentación y más en las personas, en lugar de buscar un contrato para especificar lo que se necesita, céntrese en establecer un entorno que fomente una comunicación abierta, coherente y precisa.

Aquí hay un problema de "perspectiva interna": incluso con mucha buena voluntad, las personas tienden a considerar que su [formato de datos|API|definición del problema|lo que sea] es correcto y es el otro equipo o persona quien debe cambiar el suyo. Además, cuando los equipos A y B cambian su método de comunicación, tiene un impacto en los equipos C y D y posiblemente en el E. Tenemos un problema desagradable (muchas preocupaciones transversales entre los subsistemas y los dominios del problema).
Su comentario refuerza mi respuesta a su otra pregunta. Parece que necesitas un agente de cambio cultural. [Esta es la pregunta a la que me refiero pm.stackexchange.com/questions/8286/…