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?
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 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
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.
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:
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í.
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.
allnightgrocery
Tiago Cardoso
Cazador de ciervos
mrkafk
mrkafk
mrkafk
mrkafk