Pocos encuentran una salida, algunos no la ven, incluso si la encuentran, y muchos ni siquiera la buscan.
De Alicia en el país de las maravillas
El artículo plantea las siguientes preguntas.
- Sobre la inconsistencia de los componentes de la fórmula de outsourcing 'Scrum + Precio fijo'.
- Un posible error (causa raíz) que precede a la elección incorrecta de la herramienta Scrum.
- Sobre una situación en la que realmente hay una cuestión de combinar Scrum y Precio fijo, que requiere un análisis profundo y compensaciones para resolverlo.
El artículo toca un punto muy controvertido que no tiene un punto de vista inequívoco y es objeto de debates interminables. Por lo tanto, mientras lee, tenga en cuenta que su opinión puede no coincidir con la presentada, pero esto no significa en absoluto que uno de nosotros tenga toda la razón, así como el hecho de que alguien esté absolutamente equivocado.
Como se menciona en el artículo "Cómo iniciar pseudo-Scrum en la subcontratación" , en una gran cantidad de proyectos de subcontratación, cuyos equipos combinan (o tal vez ilusiones) Scrum y precio fijo, el ciclo de vida del proyecto (LC) no se identifica correctamente. Aquellos. se cometió un error al elegir entre un ciclo de vida iterativo incremental o flexible. Y, como resultado, se eligió la herramienta de administración incorrecta: el marco Scrum. Y ya una consecuencia de esta elección es la aparición de una serie de problemas, conclusiones erróneas sobre Agile, Scrum e intentos (¿de la palabra "tortura"?) Para combinar estos dos conceptos mutuamente excluyentes.
Mutuamente excluyentes ?!
Ahora discuto.
Se supone que el lector está más familiarizado con los materiales del artículo anterior.
Scrum + Fixed Price – , ?
, , .Al concluir un contrato para la prestación de servicios de outsourcing, el cliente casi siempre insiste en un Precio Fijo (esquema llave en mano). Su deseo es fijar el alcance del producto (o la cantidad de trabajo), ver el presupuesto, los plazos. Quiere ver qué está "comprando". Los clientes rara vez aceptan Time & Material.
“ ”
Por lo tanto, el punto clave: la necesidad del cliente debe fijarse en el contrato, y la necesidad del proveedor de servicios de cumplir con las obligaciones estipuladas en el contrato y garantizar que los parámetros permanezcan sin cambios con un error predecible (debido a cierto grado de incertidumbre y riesgos en las etapas de ventas y conclusión del contrato) después del inicio del desarrollo. La cuestión de reducir el grado de incertidumbre y los riesgos es la cuestión de la viabilidad y la calidad de la fase de descubrimiento (preventa, diagnóstico) en relación con el alcance del producto.
Es bastante obvio que si arreglamos algo (se lo garantizamos al cliente en virtud del contrato), entonces debemos planificarlo y administrarlo de tal manera que se garantice el cumplimiento de nuestras obligaciones. Aquellos. administrar el plan (o las características fijas del triángulo del proyecto).
El precio fijo simplemente nos obliga a priorizar la gestión del plan. De lo contrario, ¿por qué deberíamos arreglar algo, sabiendo de antemano que va a cambiar, y realmente no planeamos gestionarlo? ¿Solo firmar un contrato? Un error crítico en los procesos de venta establecidos: lo arreglamos, sabiendo de antemano que vamos a cambiar, ¡solo para firmar un contrato!
¿Por qué vamos a cambiar? Porque Scrum siempre trata sobre la incertidumbre y su resultado: el cambio. Se trata de la prioridad de la gestión del cambio. Y es posible que aparezcan después del primer sprint. ¿Por qué?
Una digresión sobre los posibles motivos del cambio
¿Cuál podría ser el motivo del cambio? Por ejemplo, puede estar en una fase de descubrimiento (preventa, diagnóstico) mal realizada en una situación en la que el alcance del producto puede definirse hasta cierto punto (por ejemplo, consulte el párrafo 3 del estudio de caso en el artículo ), pero para saber qué por alguna razón esto no se ha hecho. En este caso, este es un problema de fase y procesos internos, y no la razón para elegir Scrum para un contrato de precio fijo, un ciclo de vida flexible en lugar de uno iterativo para compensar el error cometido.
Aunque, para ser justos, observo que en ventas (actividades de preventa de analistas de negocios) en outsourcing (una de las fases más problemáticas desde el punto de vista del producto), no todo es tan simple como en una tienda cuando se compra un producto terminado con propiedades específicas. (funcionalidad). Y la fase de descubrimiento es una actividad difícil de vender de analistas y equipos de negocios. Pero minimizar la incertidumbre en un grado u otro y evaluar los riesgos es una de las tareas principales de un proceso de ventas bien construido. Así como la formación de un entendimiento en el cliente sobre la necesidad e importancia de estas actividades (¡puede ser muy difícil!). Pero para esto hay un número suficiente de técnicas y herramientas. Y se trata de la cuestión de la calidad de los servicios prestados, y no de la venta de un "cerdo en un empujón".
Otra razón puede ser la incapacidad para determinar el alcance y la visión del producto en el momento actual (por ejemplo, consulte la página 2 del Estudio de caso en el artículo ). Y esta es, de hecho, una situación muy difícil y desfavorable para ambas partes, cuando surge una grave contradicción y se plantea la cuestión de combinar Scrum y Precio Fijo en la provisión de servicios de outsourcing. Requiere un análisis cuidadoso, acciones adicionales para formar una comprensión integral del cliente (a menudo técnica e ideológicamente lejos de las realidades de los procesos de desarrollo) sobre posibles dificultades y riesgos, y la búsqueda de soluciones de compromiso.
Entonces, ¿por qué se elige Scrum? ¿Para gestionar los cambios que, por ejemplo, surgen como resultado de una fase de descubrimiento realizada incorrectamente (preventa, diagnóstico) o cuando el alcance del producto no se puede determinar en esta fase? En el primer caso, en mi opinión, esto está mal. En el segundo caso, es difícil de implementar con precio fijo.
La tercera opción posible para elegir Scrum como una herramienta ágil, un ciclo de vida flexible en lugar de uno incremental iterativo en una situación en la que el alcance del producto se resuelve y se fija en la fase de descubrimiento (preventa, diagnóstico) y en el contrato: precio fijo, tampoco es racional en mi opinión: por qué elegir una herramienta para gestionar el cambio (fuera de foco es claramente una cosa más prioritaria: un plan), ¿cuándo se minimiza su probabilidad?
Regrese a la idea principal del artículo.
Pero digamos que se elige Scrum. Una vez más, Scrum es una herramienta de gestión del cambio, cuando el grado de incertidumbre se puede reducir solo en el proceso y solo cuando se utilizan los enfoques adecuados. Y esta disminución es el resultado de este proceso.
¡Pero el contrato de precio fijo da prioridad a la gestión del plan!
Por lo tanto, la 'fórmula' 'Scrum + Precio fijo' se transforma en 'gestión del cambio + gestión del plan simultáneamente'. La tarea del gerente es administrar, en diversos grados, tanto el plan como los cambios, pero solo puede haber una prioridad: el plan o los cambios.
La gestión del plan o la gestión del cambio es una especie de axioma incrustado en los fundamentos de la gestión y el análisis empresarial. Se refleja en los manuales básicos (y no solo) para gerentes (PMBOK) y analistas de negocios (BABOK). Y la clasificación del ciclo de vida (y su identificación en relación con proyectos específicos) se basa en él: hay un ciclo de vida diseñado para administrar el plan (por ejemplo, Cascada, iterativo incremental (IID)) y flexible, ágil para la gestión del cambio. La elección del ciclo de vida (y, posteriormente, las herramientas) se basa en lo que se da prioridad en la gestión.
El ciclo de vida flexible es un tipo de ciclo de vida incremental iterativo para proyectos con ciertas características / características dominantes (en el artículo anterior se proporciona una lista de preguntas de verificación)), lo que le permite identificarlo como un ciclo de vida separado y "dirigir todos los esfuerzos" para cambiar la gestión. Estas características se pueden atribuir: la imposibilidad de "aquí y ahora" para lograr un cierto grado de certeza del Alcance del producto (¡lo más importante!), La búsqueda de una solución comercial (o su entrega rápida al negocio para generar comentarios) que "disparará", la formación de una lista de funciones clave producto (Características clave), iteraciones cortas, variabilidad, experimento, desarrollo gradual de funcionalidad, retrospectivas, mejora no solo del producto, sino también de los procesos para obtener la mejor versión del producto. ¿Es posible en tales condiciones obtener estimaciones adecuadas del presupuesto y los términos?
El diablo está en un solo detalle, o ... se trata del alcance del producto
Todo tiene su propia moral, ¡solo necesitas poder encontrarlo!
De Alicia en el país de las maravillas
¿Qué puede decir acerca de la certeza (la capacidad de establecerla) en relación con el alcance y la visión del producto en la etapa de ventas, la fase de descubrimiento, al comienzo del proyecto de subcontratación?
Si el alcance del producto no puede definirse, evaluarse, fijarse debido a las razones de la unicidad del producto, la idea de una puesta en marcha, la incertidumbre con respecto a la efectividad de las decisiones comerciales tomadas (la necesidad de encontrarlas) y la dificultad de determinar las funciones clave del producto, la presencia de hipótesis que requieren verificación, etc. ... (Ver nuevamente el punto 2 del Caso de Estudio aquí ), entonces, por supuesto, el marco Scrum es la herramienta más adecuada.
Sin embargo, para la subcontratación, esta situación se ve significativamente complicada por el deseo del cliente de utilizar el esquema de precio fijo al concluir un contrato y aparece en una luz desfavorable para ambas partes. Hasta cierto punto, con algunos supuestos, se puede llegar a un compromiso en la contratación y gestión de dicho proyecto. Es importante formar la comprensión correcta y las expectativas correctas del cliente (inversionista), evaluar los riesgos, considerar, si es posible, otros esquemas de interacción financiera y, en el proceso de implementación del proyecto, trabajar constantemente con la lealtad del cliente, etc. No profundizaré en la pregunta, ya que está más allá del alcance del artículo.
En la subcontratación, la mayoría de las veces la cuestión radica principalmente en la conducta competente de la fase de descubrimiento (preventa, diagnóstico) en relación con el alcance del producto y la elección del ciclo de vida correcto. Y si Agile y Scrum se eligen en una situación en la que se puede arreglar el Alcance del producto (y aún más cuando esto no se hizo por algún motivo a tiempo, con la expectativa / suposición de su desarrollo en el futuro), y al mismo tiempo en el contrato - Precio fijo, En mi opinión, se está cometiendo un error que pone en duda el resultado positivo del proyecto.
¡Gracias por tu atención!