¿Por qué y cuándo elegir FFF? Echemos un vistazo.
1. Tres combinaciones
Cada uno de los enfoques de la gestión de proyectos es esencialmente diferente en que fija o no fija los siguientes valores: presupuesto, alcance del trabajo, marco de tiempo y calidad interna del sistema.
Una combinación específica crea ciertas condiciones de trabajo, tiene pros y contras:
- Precio fijo
- Se fijan tres puntos del triángulo del proyecto: tiempo, dinero y cantidad de trabajo.
- Los principales riesgos son asumidos por el contratista y, como resultado, estos riesgos se reflejan en la evaluación. Además, se crean riesgos para el cliente, escribí sobre esto en el artículo 12 problemas al trabajar en una asignación técnica en un producto de TI .
- Una gran ventaja de este enfoque son los parámetros del proyecto predefinidos antes del inicio del trabajo. Muy a menudo, la empresa / gobierno necesita especificar el plazo, el dinero y la cantidad de trabajo en el contrato.
- . , . , .
- .
- Time and Materials (T&M)
- , - .
- .
- , .
- , . , , .
- .
- ( , Product Owner'), , , , .
- Fix Time and Budget, Flex Scope (FFF)
- : , .
- .
- , , .
- , .
- , , . .
- : , / , .
- , .. . , , , , , , .
– , . , «», , , . . , , SonarQube. Podlodka.
2.
¿Por qué se forman estas tres combinaciones? ¿Por qué no podemos arreglarlo todo? Después de todo, lo más simple es fijar el presupuesto, el alcance del trabajo, la fecha de lanzamiento y la calidad interna del sistema, firmar un contrato (si el cliente es interno, luego pasar por el procedimiento de aprobación con las partes interesadas) y hacer el trabajo con un acierto preciso en los cuatro valores. Pero, como muestra la práctica, hay un problema fundamental que no facilita pasar este camino sin distorsión.
Nadie tiene problemas para calcular el presupuesto, es bastante fácil calcular la fecha de lanzamiento y hay muchas métricas y listas de verificación para establecer un nivel específico de calidad para un producto de TI. Todo es simple si puede estimar con precisión el alcance del trabajo. En otras palabras, si hay una lista detallada de tareas y una estimación precisa de esta cantidad de trabajo, las otras tres cantidades se calculan fácilmente. Por el contrario, si no hay una estimación exacta, el resto de los valores también serán inexactos, porque se basan en una estimación de la cantidad de trabajo.
Estimar el alcance del trabajo siempre es un problema, porque no existe una metodología de estimación única que funcione con una precisión aceptable. Todos los métodos se basan en la experiencia previa de un equipo que hizo cosas similares, lo que en última instancia significa inexactitudes, porque las personas son inexactas: emocionales, optimistas, olvidadizas. La falta de un método de evaluación preciso es el primer factor que nos impide entrar en la evaluación de la cantidad de trabajo.
Escribí más sobre este tema en el artículo Satisfacción del cliente para programadores: todos los programadores son optimistas . Hay un enlace al informe 36 de Vadim Makishvili, donde sugiere simplemente multiplicar el puntaje por 3. Usando la metáfora de colocar y caminar la ruta, está escrito en el artículo ¿Por qué los proyectos de TI toman 2-3 veces más de lo planeado? ...
En el curso del trabajo en un producto de TI, cambian: la lista de tareas que deben realizarse, la profundidad de su elaboración, el enfoque del diseño del sistema. Esto sucede bajo la influencia del entorno externo: cambios en el mercado, cambios en la estrategia de la empresa, cambios en las políticas dentro de la empresa, retroalimentación de los usuarios, nuevos insumos de quienes callaron en la etapa de análisis y luego decidieron hablar, etc. Nuestra incapacidad para influir en las influencias externas es el segundo factor que nos impide entrar inicialmente en la evaluación.
El tercer factor es que no existen criterios para determinar el logro de la integridad al describir el alcance del trabajo. La escritura de los conocimientos tradicionales no se puede terminar, solo se puede detener. Escribí sobre esto en detalle en el artículo ¿ Cuándo es el momento de dejar de escribir los Términos de Referencia ?
Debo hacer una reserva de que todo esto es cierto si se trabaja en un área bastante compleja: según el marco de Cynefin, estas son las áreas Complejas y Complicadas. Si su proyecto se vuelve obvio y al mismo tiempo es bastante corto, lo más probable es que calcule la cantidad de trabajo con mucha precisión.
En total, tenemos que la raíz del problema radica en una estimación inexacta del alcance del trabajo y la imposibilidad práctica de hacer esta estimación precisa, por lo tanto:
- Los proyectos de precio fijo sacrifican la calidad interna del sistema, porque es casi imposible obtener una estimación con tres picos fijos. O, en los mismos proyectos de precio fijo, vuelven a presupuestar tantos riesgos para cubrir cualquier inexactitud en la evaluación, lo cual es ineficaz.
- T&M , . Product Owner'.
- FFF , , « » , T&M.
3. ?
Si es imposible estimar el alcance del trabajo con suficiente precisión, ¿tal vez no? Existe ese movimiento #NoEstimates. En resumen, organizamos el proceso de desarrollo de tal manera que podamos realizar las tareas de la manera más eficiente posible desde la etapa de la idea hasta la puesta en producción y al mismo tiempo mantener una alta calidad interna. Ofrecen organizar el proceso usando Kanban con seguimiento de métricas de procesamiento de flujo y atención especial para mejorar el proceso de entrega de nuevas funciones. Las evaluaciones prematuras se consideran perjudiciales, evaluar y arreglar el trabajo atrasado es una pérdida de tiempo.
Dónde obtener más información sobre #NoEstimates:
- David Anderson habla mucho sobre esto, por ejemplo, en su charla The Alternative Path to Enterprise Agility .
- Askhat Urazbayev habló en AgileDays en su discurso #NoEstimates: Desarrollo no evaluativo .
- Ron Jeffries escribió sobre esto en el artículo Some Thoughts on Estimation .
- Denis Stebunov escribió sobre esto en Habré en el artículo Sobre estimaciones de términos en el desarrollo de software .
Estoy a favor de este enfoque. Me gusta como ingeniero y como líder. Pero la vida está organizada de tal manera que los propietarios del presupuesto necesitan una estimación, al menos en las primeras etapas del trabajo, al menos aproximada. En Byndyusoft, a veces pasamos a #NoEstimates, pero solo después de una relación bastante larga con el cliente y esto no siempre sucede.
4. FFF: equilibrio entre flexibilidad y previsibilidad
Aunque las calificaciones estropean la vida y son una pérdida de tiempo, es difícil empezar sin ellas. Sin embargo, está claro que ninguna estimación será precisa. Resulta que la mejor opción es fijar el plazo y el presupuesto para que la empresa pueda vivir con él y dejar flotando el volumen de trabajo. Además, el cliente y el contratista deben estar de acuerdo en que en cada momento el equipo se dedica solo a las tareas más importantes y necesarias, y el cliente dedica tiempo a monitorear la dinámica de la elección de prioridades.
La primera vez que vi la descripción de FFF fue en Getting Real by 37signals en el capítulo Fix Time and Budget, Flex Scope . En este momento en mi empresa, este es el enfoque de trabajo más popular, tanto los clientes como nosotros estamos contentos con él.
5. Calidad interna del sistema
Como escribí anteriormente, trabajar en FFF es posible si la empresa cuenta con desarrolladores competentes que puedan garantizar una alta calidad interna del sistema. Esto generalmente se logra automatizando todo y a todos, creando listas de verificación de mejores prácticas, revisando constantemente el código y la arquitectura, todo tipo de pruebas y, lo más importante, reclutando a las personas adecuadas para el equipo.
¿Por qué no olvidarse de la calidad interna ?, escribe el blog de Martin Fowler, ¿Vale la pena el costo del software de alta calidad? ... Escribí sobre esto en el artículo Cómo determinar el fracaso de un proyecto de TI... En definitiva, con FFF se asumen cambios en la dirección del desarrollo del producto, y esto implica suficiente flexibilidad del sistema. Si la calidad del sistema es baja, entonces cada "giro" ralentizará el desarrollo y aumentará su costo, hasta detener completamente el proyecto.
Si desea trabajar de acuerdo con FFF, coloque los criterios de calidad en el contrato para corregirlos con seguridad.
6. Motivación del cliente y del contratista
El trabajo de FFF proporciona la motivación adecuada por parte del cliente y del contratista. A diferencia del precio fijo, donde el cliente y el contratista se comunican a través de la interfaz del contrato, y a diferencia de T&M, donde el cliente puede perder límites y gastar más de lo necesario; en FFF todo el mundo tiene que invertir en comunicaciones y “vivir” en el proyecto para hacer lo más importante y al mismo tiempo cumplir con los términos del contrato.
7. Elija FFF
El precio fijo y T&M tienen sus ventajas en determinados contextos:
- Si participa en una licitación y se compromete a completar un trabajo específico dentro del tiempo y dinero acordados, mientras que la comunicación se construye principalmente a través de un contrato, lo más probable es que el precio fijo sea la mejor opción.
- Si el cliente sabe exactamente lo que necesita y sabe cómo construir de manera efectiva el proceso de trabajo, entonces solo necesita comprar recursos de T&M y deshacerse de ellos a su propia discreción.
Sin embargo, en igualdad de condiciones, intentamos elegir FFF. Este enfoque parece ser el más equilibrado: reduce los riesgos del cliente y del contratista, crea la motivación necesaria en ambos lados y cuida la calidad interna del sistema.
Enlaces:
- Cómo y qué términos de referencia escribir cuando se trabaja en Agile .
- El principio de gestión de proyectos en la oficina de diseño de Artyom Gorbunov.