Estoy trabajando en una empresa mediana como CTO, el lado comercial de la empresa está enviando un promedio de 5 propuestas por día para estimar en términos de horas de trabajo y costo para cada propuesta.
En esa fase, todavía no sé qué equipo se asignará al proyecto, ya que la fase de firma del contrato puede demorar en promedio más de 5 meses.
El problema que me preocupa desde hace 1 año hasta ahora es el conflicto entre estimar el plazo firmado con el cliente y el plazo previsto por el Product Owner y el equipo que puede variar hasta 2 veces a veces lo que significa pérdida de tiempo, costo, confianza con los clientes
Mi pregunta es, ¿cuál es la mejor práctica para estimar los proyectos al proponer el proyecto a los clientes teniendo en cuenta que el costo y el precio deben estar disponibles en esta fase, ya que son los factores con los que los clientes comparan las propuestas?
Estamos siguiendo una metodología ágil en la empresa, por lo que esto también debe tenerse en cuenta.
Este parece ser un tema de pregunta común últimamente. Recientemente respondí preguntas similares en este hilo y en este hilo .
Hay tres problemas principales que giran a tu alrededor.
Las estimaciones son solo conjeturas: en los años 80 y 90 de alguna manera olvidamos el concepto de " [Cone of Uncertainty][3]" en la estimación. Cuando estima un proyecto por primera vez, tiene suerte si tiene al menos un 50% de precisión. Y si no lo eres, entonces siempre será más tarde. Casi nunca sobreestimará el trabajo a realizar gracias a la Ley de Hofstadter , que básicamente dice "Siempre subestimamos, incluso cuando sabemos que siempre lo hacemos". La única forma verdadera de saber cuándo (basado en el alcance) o qué (basado en el cronograma) entregará para un proyecto es comenzar a hacerlo y luego usar la velocidad para predecir cuándo o qué.
Alcance versus cronograma: Recomiendo mi breve presentación de diapositivas sobre esto. Tengo notas completas del orador incrustadas para explicar cada diapositiva. Es una excelente manera de explicar visualmente el alcance frente al cronograma para que los clientes y los equipos lo entiendan. Mi recomendación personal, basada en años de desarrollo Agile, es optar siempre por un lanzamiento controlado por programación con un MVP que no sea más del 80 % de lo que cree que es su línea de lanzamiento.
Líneas de lanzamiento vs. Líneas MVP : Todos estamos familiarizados con el término Producto Mínimo Viable (o valioso). Sin embargo, veo mucha variación en lo que la gente piensa que es la definición. Por lo general, digo "Si no alcanzamos el MVP, desecharíamos todo el código y no lanzaríamos el producto en absoluto" y "MVP es ¿qué necesita el cliente para que el producto sea útil?". Suelo citar el iPhone original. No tenía BlueTooth, no cortaba y pegaba, no tenía aplicaciones reales de las que hablar. Y, sin embargo, satisfizo exactamente la necesidad del cliente (un teléfono simple y sucio, con una interfaz de usuario a prueba de idiotas que permitiría llamadas telefónicas, correos electrónicos y navegación web básica).
Release Line es un término del que no escuchamos lo suficiente y es lo que hace que nos encontremos con tantos problemas con los proyectos definidos por MVP. Diremos "estas son las características de MVP" del proyecto y "Debemos enviarlo en agosto", sin embargo, rara vez analizamos lo que creemos que la ingeniería realmente puede hacer. En la sección Programación de mi presentación , muestro el peor de los casos en que el equipo entrega menos que el MVP porque el propietario del producto definió el MVP como exactamente lo que la ingeniería pensó que podía entregar.
Nunca hagas eso. Siempre bajo compromiso y sobre entrega. Si cree que puede enviar 10 funciones (estimación de ingeniería), en el cronograma, no se comprometa con más de 6. Esto permite dos cosas muy reales. 1- Usted subestimó la cantidad de trabajo a realizar. 2- Su cliente/propietario del producto cambia de opinión y agrega nuevas funciones durante el desarrollo.
Por último, paciencia y Agile Value 3 : Estamos intentando dar la vuelta a treinta años de mala planificación de proyectos y expectativas de que un presupuesto es un compromiso. No lo cambiaremos de la noche a la mañana. Por lo tanto, siempre tenga en cuenta el valor ágil 3: colaboración con el cliente sobre negociación de contratos. Manténgase en constante comunicación con su cliente y sea totalmente veraz y transparente. Si cree que existe la posibilidad de un retraso, dígaselo de inmediato. En los últimos siete años he usado este modelo. A mis clientes (internos y externos) les encanta la transparencia total y son mucho más tolerantes con los problemas porque me comunico con la misma frecuencia que todos los días. Cuando puede ver cómo se hace la salchicha, está menos preocupado por comer el producto final.
Existe una incertidumbre inherente en cualquier proyecto de desarrollo de software. Las dos razones principales de esto son el cambio de requisitos y el riesgo técnico.
Esta incertidumbre hace que sea muy difícil estimar de antemano y cuanto más largo sea el proyecto, más difícil se vuelve. Esto se describe mediante el cono de incertidumbre .
Tienes un número de opciones:
El enfoque ágil sugiere que la última opción es la mejor: "Colaboración del cliente sobre la negociación del contrato".
Un enfoque es negociar contratos de tipo de tiempo y materiales, donde los clientes pagan sobre la marcha. También están apareciendo algunos contratos ágiles que tal vez desee considerar.
La brecha entre las ventas y la entrega existe en todas partes y nunca desaparecerá. El lado de las ventas de su negocio necesita vender el trabajo y, como es típico con muchas ventas, prometerá demasiado. Además, necesitan fijar un precio competitivo para el trabajo, ya que el precio es un factor importante en la decisión de compra de un cliente. El lado de entrega de su negocio quiere entregar con éxito el proyecto con los recursos que necesitan, el tiempo que necesitan y con un buen margen de contingencia por si acaso, lo que a menudo resulta en una promesa insuficiente. Estos dos objetivos entre venta y entrega son contradictorios.
Necesita tener el lado de la entrega de su casa para tener la autoridad de "nix" el proyecto si el lado de las ventas es demasiado prometedor. Debe tener un proceso de gobierno que busque el consenso antes de entregar una propuesta al cliente. Este proceso debería/puede ayudar a calmar las promesas excesivas del lado de las ventas y al mismo tiempo calmar la costosa asignación excesiva del lado de la entrega y ayudarlo a llegar a un caso de precio y costo que esté más cerca del medio.
Dicho esto, e incluso con un proceso como ese, en mi experiencia, el lado de las ventas generalmente gana (tienes que vender para tener trabajo) y el lado de la entrega se queda con la bolsa. La buena noticia para usted es que no está solo en esta lucha.
danny schoemann
Ewan