project management - significa - ¿Cómo firmó un contrato para un proyecto Agile?(No cómo crees que lo harías, cómo lo hiciste)

que es metodologia agile (7)

Como trabajo principalmente en aplicaciones de intranet, esto no ha sido un gran problema para mí. Sin embargo, a menudo hago aplicaciones para otros departamentos y, a veces, especialmente cuando el proyecto es grande, firmamos un memorando de entendimiento (MOU) con respecto al alcance del proyecto, la duración (prevista) y el costo. Como trabajo de manera ágil, ninguna de esas cosas se soluciona, lo que a menudo es difícil de explicar a otros departamentos que no hayan funcionado de esta manera antes. Normalmente incluiré una descripción del proceso en sí, un par de párrafos, explicando cómo el proyecto es una empresa cooperativa entre ellos y yo, que juntos determinamos cuándo terminamos.

Para cuando se redactó realmente el MOU, ya he invertido varias horas en el proyecto para descubrir cuáles son los requisitos (se manejan a una tarifa horaria estándar). Sobre la base de eso, junto con una estimación de mi velocidad y similitud con proyectos anteriores, doy una amplia estimación de la cantidad de tiempo y el costo de las características requeridas, una vez más explicando que el costo real está determinado por las características que realmente implementamos y cuánto tiempo realmente toma. Esto requiere una gran cantidad de confianza, pero dado que hemos trabajado juntos para desarrollar los requisitos, generalmente tengo eso con las personas con las que estoy tratando directamente. A menudo trato de dejar la estimación real fuera del MOU, pero la incluiré si su gerente insiste. Intento darles un número de presupuesto.

Mi experiencia es que una vez que el proyecto comienza y comienzas a entregar valor al cliente, rara vez son infelices. Por lo general, solicitan (y pagan) más que el alcance original del proyecto. A menudo, ambos acordamos que algunas de las características originales no son necesarias, pero siempre lo espero. Después de todo, realmente no tienen forma de saberlo con certeza hasta que realmente vean las cosas en funcionamiento, qué es lo que realmente necesitan. En la mayoría de las ocasiones, eliminamos algunas características y agregamos otras basadas en el desarrollo real. Supongo que si no lo hiciéramos no tendría sentido usar métodos ágiles.

Creo que el tema clave es la confianza. Sugiero trabajar con un cliente nuevo en proyectos más pequeños o dividir explícitamente un proyecto grande en proyectos más pequeños para desarrollar la confianza. Una vez que ellos y usted saben que pueden confiar el uno en el otro para construir el producto correcto con las características correctas, creo que se minimiza el riesgo (y siempre hay uno) de que el cliente se retire abruptamente.

Para ejecutar un proyecto Agile, primero necesita un contrato. Sin contrato, sin proyecto! Sin proyecto, ¡no Agile, SCRUM o lo que sea!

El contrato, si estamos hablando de proyectos medianos a grandes, debe tener activadores de seguridad bien definidos. Es decir, los clientes quieren estar muy seguros de que si acordamos finalizar un proyecto en tiempo = T, presupuesto = B y alcance = S no terminamos con tiempo = T × 2, presupuesto = B × 3 o alcance = S / 2.

Por otro lado, como empresa que entrega el producto, no queremos que el proyecto finalice inesperadamente. Es decir, si después de una iteración el cliente dice: "Ahora veo que esto es en realidad todo lo que necesitamos. Nos detenemos ahora". y el proyecto fue planeado por otros 2 meses, que tenemos personas sin trabajo planificado. Si 3-6 personas no es un gran problema, 15-25 podría ser un problema real.

Sin embargo, no encontré ningún ejemplo real de un contrato con características de seguridad que permita que el proyecto se ejecute de manera ágil (indicado o no al cliente como tal). El dicho estándar que encuentro en muchos foros: hablar con el cliente, explicarle que esta es una forma de trabajo mucho más productiva, etc. no me convence ni a mí ni a mi gestión. No es que no creamos que Agile sea una mejor forma de hacerlo. Es solo que las brechas en los factores desencadenantes de la seguridad son tan obvias que ninguno de nuestros clientes las compra Y tampoco nos gustan (vacíos, no clientes) tampoco).

POR FAVOR, no "probablemente funcionaría de esta manera ..." - He leído toneladas de eso. Solo interesado en "Para nosotros funcionó de esta manera" . Sin dudas, omita toda la información confiable que contiene.

PD: Hasta donde puedo decir, el enfoque iterativo estándar basado en características sugiere que el cliente pague después de cada iteración (número de iteraciones) y sea capaz de detener el proyecto tanto por el cliente como por el ejecutor del proyecto después de cualquier iteración sin decir mucho sobre las consecuencias, en lugar de diciendo "fallaría de todas formas, cuanto antes, mejor" (lo cual es correcto, pero no muy útil al firmar el contrato).

La forma en que manejamos esto es bastante productiva.

Nuestros clientes básicamente compran iteraciones. Los clientes firman un contrato que dice "X iteraciones de 2 semanas". Hay un proceso de educación del cliente (como es común en todos los proyectos ágiles en los que he trabajado) para ayudar al cliente a acelerar el proceso de planificación y la idea de que lo que realmente obtienen al final del proceso de desarrollo no es concreto. el inicio del proyecto PERO que controlan cuál será el resultado final.

Nuestro equipo ha trabajado en conjunto durante casi seis meses, contamos con una sólida base tecnológica que hemos desarrollado para minimizar los riesgos. Tenemos una comprensión bastante sólida de nuestra capacidad continua en términos de velocidad, esto nos ayuda a hacer predicciones sobre el número de iteraciones necesarias para alcanzar el resultado deseado del cliente.

Lo último que desea en un proyecto ágil es el alcance fijo (generalmente lo que está contenido en un contrato en un proyecto de cascada tradicional). Lo que sí quiere es un acuerdo con un cronograma fijo con un equipo de tamaño fijo que trabaje contra una cartera de pedidos de productos priorizados.

Si fuerza a su socio comercial a definir un alcance fijo durante el inicio, rellenará todo lo que se le ocurra en el contrato. No porque tenga valor, sino porque será difícil hacer cambios más tarde y podrían necesitarlo.

Uno puede proporcionar una estimación de alto nivel para un conjunto de características solicitadas por el socio comercial. Sin embargo, el equipo, compuesto por TI y un propietario de producto, acepta que el alcance y la prioridad cambiarán fácilmente durante la implementación de las funciones. Si se enfoca en trabajar en las características más importantes, primero el equipo se vuelve impulsado por el valor y no por el plan. Si algo cae fuera de la lista, es de menor valor y ha sido desplazado por algo que el equipo aprendió a ser más importante.

Un contrato de alcance fijo bloquea al equipo para que tome una decisión de alcance cuando saben lo de las características. Al enfocarse en la prioridad y permitir que la prioridad y el alcance se flexionen entre las iteraciones, se asegura que lo que se entrega tiene valor.

En lugar de firmar un contrato de alcance fijo con el negocio, asista a un campamento de entrenamiento ágil con su socio comercial. La clase debe describir el proceso ágil y la función del propietario del producto. Si la empresa acepta el enfoque ágil, está listo para comenzar el desarrollo. Cree su cartera de pedidos de productos, establezca prioridades, proporcione un presupuesto de alto nivel, cree un plan de lanzamiento e iteración y comience a ofrecer valor.

La forma en que ejecutamos la relación es primero enviar al socio comercial al campo de entrenamiento ágil. Luego capacitamos al socio comercial para que sea el propietario de un producto. Luego creamos el trabajo atrasado, proporcionamos un estimado de alto nivel y arreglamos el tamaño del equipo y el tiempo en el desarrollo. En dos semanas, se demostró el primer software en funcionamiento. A partir de ese punto, el socio comercial comprendió el valor de hacer cambios a medida que aprendían más. Cualquier discusión sobre un contrato de alcance fijo pronto fue olvidada.

Los únicos proyectos ágiles en los que he trabajado fueron In House, Time and Materials (T & M) o proyectos Pay per Cycle.

El problema es que, como ha señalado, existe el riesgo de que un proyecto falle / finalice temprano. Sin embargo, ¿no es lo mismo que cualquier proyecto? Si acude a T & M, correrá todo el riesgo, si elige el precio fijo, el cliente correrá todo el riesgo. Al ir a Pay Per Cycle, está asumiendo la mayor parte del riesgo, pero le está pasando porciones pequeñas al cliente un ciclo a la vez. Da la casualidad que ni usted ni el cliente quieren correr ningún riesgo, por lo que ha publicado esta pregunta.

El problema es tomar riesgos, de lo que se trata el negocio, cuanto más riesgo tomes, mayor será la ganancia cuando se produzca, pero también mayor será la pérdida si no lo hace. Si el riesgo es demasiado grande para que usted maneje la única solución es encontrar a alguien más que pueda tomar el riesgo de sus manos, pero tendrá que pagarles. Si ni usted ni el cliente están preparados para tomarlo, probablemente haya solo dos respuestas:

Obtener un tonto rico para suscribir el riesgo (es decir, obtener un seguro).
Extienda el riesgo entre un número de personas hasta que el riesgo que cada uno tome sea tan pequeño que sea aceptable.

Creo que esta segunda opción es lo que hace que los contactores sean tan populares. Debido a que son fáciles de eliminar, terminan asumiendo el riesgo de una terminación anticipada del proyecto. Como el riesgo se distribuiría entre varios de ellos, el riesgo se extiende a un nivel aceptable. Le cobrarán más que a un Empleado debido al riesgo adicional, pero eso es lo que obtiene por tratar de evitar el riesgo usted mismo.

Nuestras prácticas de PM todavía están alcanzando el enfoque ágil de entregar software. La mayoría de las veces, al ser cautelosos, el contrato inicial define los objetivos de alto nivel, pero impone limitaciones a la funcionalidad con desafíos técnicos previsibles. Ciertos hitos de entrega importantes, es decir, alfa, beta, final, se definen y se valoran. El alcance adicional se define como solicitudes de cambio que complementan el contrato original. Es una experiencia de aprendizaje a medida que nos alejamos de los enfoques de cascada tradicionales; El problema más grande que he visto es que algunas cosas, como las implementaciones regulares, son difíciles de poner en el precio porque nunca se sabe cuánto tiempo tomará abordar los "comentarios" de una iteración. Hemos tenido "¡esto es increíble, nos estamos moviendo bien!" y hemos tenido "aquí hay una lista de 200 defectos"; hay un grado variable de comprensión de cuál es el propósito de los lanzamientos frecuentes entre los clientes.

Nuestros contratos no han cambiado desde que cambiamos a ágil, el cliente aún desea recibir la construcción en un hito importante y está demasiado lejos como para involucrarse directamente en cada final de carrera. El propietario del producto no tiene que ser la persona al otro lado del contrato, puede ser un gerente ejecutivo. El dueño del producto está en constante comunicación con las necesidades del cliente real, evalúa las necesidades para mostrarlo al cliente. Aún así será mucho más fácil para esa persona comunicarse con el cliente si tiene liberaciones frecuentes.

Yo trabajo en el gobierno

Recientemente realizamos un proceso de adquisición de desarrollo de software y seleccionamos tres proveedores para trabajar en un proyecto Agile. Algunas notas:

Ya estábamos seguros al 75% de que queríamos ejecutar un proyecto Agile porque sabíamos que nuestros requisitos eran ambiguos y porque era un proyecto web público con un elemento de diseño significativo. Así que diría que ayuda mucho si su cliente sabe acerca de Agile y compra desde el principio, incluso si no lo practican internamente. Tenga en cuenta que la aceptación de Agile está creciendo en (algunos) círculos gubernamentales, por lo que esto puede ser más fácil.
Una protección que utilizamos fue contratar a un maestro SCRUM con mucha experiencia (independiente) para que trabaje para nosotros y manejar las tareas de administración de proyectos de software en nombre de nuestro equipo líder / arquitecto / usuario. Pasamos mucho tiempo buscando a esta persona, y los seleccionamos de tres excelentes candidatos. Esto fue costoso, pero vale la pena.
Una vez que seleccionamos a nuestros proveedores y acordamos ampliamente sus roles (diseño, front-end, back-end), armamos un MoU rápido que describe nuestra intención de proceder, el posible presupuesto del proyecto, el tamaño probable del equipo de cada uno proveedor, un compromiso de firmar un contrato completo antes de fin de mes, y un acuerdo de tiempo y materiales entre tanto.
Luego nos sumamos a una sesión de planificación / dimensionamiento técnico y pusimos manos a la obra. No se realizó ningún trabajo o diseño de desarrollo en este momento, pero hicimos una gran cantidad de cálculos y estimaciones de alto nivel.
Al final del mes, armamos contratos para cada proveedor (uno llegó tarde, pero eso estuvo bien). Un proveedor presentó ejemplos de contratos que podríamos usar, uno basado en el pago por tercios del proyecto; el otro al completar los sprints. Creo que al final completamos los sprints (facturados mensualmente), usando parte del lenguaje sugerido por los proveedores en la sección de pagos de nuestra plantilla de contrato estándar.

En general, estábamos de acuerdo con este enfoque (a pesar de reconocer algunos riesgos) porque no creíamos que hubiera una gran cantidad de riesgo técnico real en el proyecto en general, y porque teníamos mucha confianza en el proceso de adquisición y en los proveedores que había seleccionado.

Al final, este fue un proyecto muy exitoso, y desde entonces hemos comenzado a utilizar SCRUM en nuestra empresa para otros proyectos. Creo que tener un gran equipo fue clave. Teníamos confianza en los proveedores, no solo en que podían hacer el trabajo, sino en que eran una buena opción en términos de su actitud para trabajar como un solo equipo, y en términos de que había roles bien definidos para cada uno (es decir, que lo harían). no estar compitiendo por el mismo dinero).

Si nuestros proveedores no hubieran sido tan buenos, habríamos tenido algunas reservas más sobre la celebración de un contrato como este, pero ejecutar la adquisición es casi tanto un arte como una ciencia, y sabíamos que habíamos elegido el equipo con el mejor ajuste. una actitud de un grupo de otros encuestados de alta calidad.

Desde entonces, hemos transferido los tres contratos para un segundo año de desarrollo, aunque diría que esta vez no está yendo tan bien (nuevo maestro de SCRUM, composición de equipo diferente), sigue siendo un gran proyecto en el que participar.

También puede encontrar esto interesante: Outsourcing Agile .