Algo que ocurre con bastante frecuencia en los proyectos de software subcontratados es que el proveedor subestima la complejidad o la curva de aprendizaje asociada con una declaración de trabajo acordada y quiere aumentar el costo a la mitad del proyecto cuando se da cuenta de que lo subestimó.
Mi pregunta es: ¿existe una manera justa de decidir cuándo el proveedor debe "comerse" el nivel de esfuerzo imprevisto y cuándo el cliente debe, de hecho, pagar más?
Las disputas contractuales son una forma de administrar el riesgo financiero para la empresa, no el riesgo de programación. Como cuestión puramente práctica, realmente no se puede transferir el riesgo de cronograma a través de medios contractuales, sin importar lo que diga el contrato.
A corto plazo, sus opciones inmediatas estarán basadas en un análisis comercial de las necesidades y alternativas de su empresa. Además, tenga en cuenta que es más probable que la opción seleccionada se base en decisiones políticas de la alta gerencia que en cualquier otra cosa.
Identifique las opciones y los costos asociados, y preséntelos a la gerencia para que tome una decisión. Luego concéntrese en arreglar sus procesos para el futuro.
¿Existe una manera justa de decidir cuándo el proveedor debe "comerse" el nivel de esfuerzo imprevisto y cuándo el cliente debe, de hecho, pagar más?
Si bien algunas respuestas pueden abordar esto de manera legalista, o discutir los beneficios del principio ágil de colaboración con el cliente sobre la negociación de contratos , en el fondo simplemente está haciendo la pregunta incorrecta.
La pregunta pragmática en cualquier disputa de este tipo debería ser: ¿Necesito el resultado más de lo que necesito el acuerdo original o las condiciones de pago? Al final del día, si bien ambas partes pueden culpar, atribuir responsabilidades o abogar, ninguna de estas cosas realmente funciona. Incluso si está dispuesto a abandonar su relación con el proveedor, se enfrenta a decisiones difíciles sobre quién hará el trabajo, qué tan pronto pueden entregarlo o si puede obtener el resultado final que necesita. .
La Ley de Brooks a menudo se aplica aquí, porque es probable que su proyecto ya esté retrasado. Disputar contratos, cambiar de proveedor o buscar soluciones alternativas en este punto puede retrasar su proyecto aún más. Si esto es aceptable o no desde un punto de vista comercial es, en última instancia, una decisión estratégica o de gestión de riesgos, en lugar de una decisión estrictamente contractual.
Realmente no puede deshacer el daño en este punto, porque todas sus opciones costarán más, reducirán el alcance o la calidad, o retrasarán la entrega de su producto. Tal vez todo lo anterior. Sin embargo, puede analizar la falla del proceso y apuntar a hacerlo mejor la próxima vez.
En la mayoría de estos casos, el problema no es realmente contractual. El problema real es que la empresa no se enteró de un problema hasta que fue demasiado tarde. Los procesos ágiles abordan esto a través de la colaboración continua, la transparencia y los ciclos estrictos de inspección y adaptación.
Por lo general, es mucho mejor implementar controles de proyecto rápidos para que pueda ajustar el proyecto o terminarlo antes de incurrir en costos irrecuperables excesivos o encontrarse frente al dilema de perseguir o no los costos irrecuperables. Cualquier falla en el proceso o control que permitió que el proyecto llegara a esta coyuntura sin muchas advertencias de que su presupuesto o las fechas objetivo estaban en riesgo tiene fallas y debe ajustarse.
Al final del día, incluso si la empresa "tercerizó" el trabajo en su proyecto de software, alguien interno de la empresa sigue siendo responsable de la entrega de ese proyecto. Hablando pragmáticamente, si esa persona rompe el proyecto, se queda con las dos mitades.
Si realmente quiere fijar el precio, y todavía hay poca confianza entre usted y el proveedor, entonces necesita documentar su Alcance y su precio junto con su proveedor, lo más detallado posible. En tal caso, será mucho más fácil juzgar si todo lo comprado se entrega o no al final.
Por lo tanto, un buen enfoque es tener una fase de elaboración breve (también conocida como Sprint Zero ) durante la cual su proveedor (o su empresa) pueda especificar los requisitos y también mitigar los principales riesgos técnicos (los resultados de la mitigación también se le deben entregar en forma de prototipo o documentación de análisis). Para un proyecto de $ 100k $ 10-20k Elaboración es bastante ($ 100k en total).
Además, durante la fase , debe estar preparado para trabajar mucho con el equipo todos los días (porque es breve): aclarar requisitos y ayudar a resolver riesgos (encontrar compromisos sobre soluciones técnicas y opciones de alcance, por ejemplo).
Y durante el proyecto , debe solicitar demostraciones frecuentes (cada 2 semanas como mínimo), donde debe verificar qué entregan los muchachos. No solo mirar rápidamente su pantalla compartida, sino también ir al servidor donde está instalado y verificar minuciosamente que todo esté bien y que el progreso sea bueno. Y refinando el resto del alcance, pero tratando de no agregar una nueva funcionalidad en el Alcance (lo que siempre sucede), sino encontrando características de Producto Mínimo Viable realmente.
Los inconvenientes del enfoque de la fase de elaboración son los siguientes:
Entonces, no es una bala de plata. Pero sigue siendo un instrumento útil para obtener acuerdos iniciales en formato escrito. Además, permite que el proveedor se relaje un poco y produzca una estimación más precisa, es decir, asumir la responsabilidad y comprometerse con ella.
Si el primer proyecto tiene éxito y el proveedor se gana su confianza, Discovery puede ser aún más económico para sus futuras fases, o puede pasar al modelo T&M para reducir la burocracia y sus propios costos para el proyecto.
Acerca de la mitigación de riesgos, véase también "The Rational Unified Process Made Easy" , excelente libro sobre el equilibrio de los enfoques Waterfall y Agile.
Esto es más una cuestión de negociaciones, por supuesto, debe haber una comunicación constructiva sobre los costos y el alcance, intente comprender los puntos de vista del proveedor, asegúrese de que comprenda el suyo, intente aprender de él, no intente implementar todo durante el proyecto. -- estar preparado para grandes recortes de funcionalidad. ¡Y todo debería estar bien al final!
Infiero de su pregunta que el tipo de contrato en este contexto es un modelo de precio fijo fijo. Si es así, el vendedor está obligado a completar el alcance del contrato sin importar la pérdida financiera que experimente el vendedor, excepto cuando se hayan cumplido los criterios explícitos de limitación de pérdidas en el contrato. Si el lenguaje de stop loss estaba mal escrito o no existía, entonces no hay un disparador que un vendedor pueda usar para que el comprador regrese a la mesa.
Dicho esto, la realidad es que si el vendedor se encuentra en una situación de pérdida grave, el trabajo o su calidad están en peligro y nadie gana realmente. Lo mejor para el comprador es volver a sentarse con el vendedor y llegar a un acuerdo más razonable para mantener el proyecto en marcha y que todos ganen. El riesgo aquí es que el comprador pueda perder la confianza y detener el trabajo por causa, posiblemente litigar por daños y arruinar la reputación del vendedor en la industria.
Entonces, la mejor solución es, al estimar un trabajo que es bastante desconocido o con grandes riesgos o un FoAK (el primero de un tipo), usar un tipo diferente de modelo de contrato, como Tiempo y materiales o Costo más tarifa.
Esto suele suceder cuando el documento de alcance del proyecto no está bien preparado. Como ingeniero de software, a veces nos olvidamos de poner funcionalidades importantes y surgen como imprevistos. Y es muy necesario trabajar en subrutinas/funciones que subyacen a las especificaciones de software dadas.
Pida al vendedor que:
Después de todo esto, paga más solo si tiene sentido para usted.
No debe pagar si hay algún error o retraso en la entrega de la funcionalidad previamente documentada .