Cómo evaluar el esfuerzo de implementación y los costos en un nuevo proyecto de desarrollo de software

Supongo que comprende que la priorización de funciones no solo se trata de evaluar el esfuerzo, sino también de comprender el valor que cada característica brinda a los clientes. Las características brindan mucho valor a los clientes, es esencialmente comprender qué valor es más importante. Idealmente, deberíamos comenzar describiendo los objetivos del producto. Por ejemplo, si el objetivo es la expansión del mercado, identificar los atributos del producto cuando se agrega al producto puede contribuir a la expansión del mercado. Los atributos son palabras clave del producto que reflejan el valor tangible entregado al producto. El gerente de producto debe comprender qué atributos tienen más valor de mercado objetivo. Cada característica debe evaluarse en función de su capacidad para entregar el valor con respecto a esos atributos. Clasifique la característica en una escala de 1–10 contra cada atributo (generalmente elijo 3–5 atributos). Elaboré esos detalles en mi libro electrónico: Preparación de la hoja de ruta del producto – Traducción de la estrategia en la hoja de ruta del producto.

Ahora, déjame volver a tu pregunta específica. La estimación del costo de la característica se realiza en una escala de 1-100. En primer lugar, el equipo de desarrollo debe identificar semanas-persona o meses-persona para desarrollar cada característica. La estimación de costos se realiza para identificar el costo relativo y no el costo absoluto, por lo que debemos elegir una función que consuma más semanas hombre que cualquier otra función. Asignemos una escala de 100 como costo de característica a esa característica. Suponiendo que la función consume 15 semanas-persona, determinemos el costo relativo de las funciones restantes utilizando una proporción de 15: 100. Ahora suponga que una de las características restantes consume 12 semanas hombre, usando la proporción de 15: 100, el costo de la característica sería 80 (12 * 100/15).

Tomé un ejemplo ficticio de 8 características con valores ficticios para el valor total y el costo total.

Sin embargo, para hacer una priorización real de las características, necesitamos evaluar el costo versus el valor determinando el valor absoluto. El valor absoluto para cada característica se deriva utilizando una relación del valor total frente al costo de la característica, es decir, cuál es el valor absoluto entregado por cada característica para cada unidad de costo de la característica. Después de calcular el costo absoluto, organice las características en orden descendente de valor absoluto para obtener un rango de características de la pila.

El valor absoluto se puede usar para clasificar esas características. Aunque he proporcionado un enfoque más científico. La preparación de la hoja de ruta es más un arte que una ciencia. Utilizo la metodología anterior para determinar el valor que cada característica agrega a los clientes y cómo contribuye a los objetivos del producto. Sin embargo, no lo sigo estrictamente. El otro inconveniente con la metodología anterior es que no tiene en cuenta la deuda técnica.

La deuda técnica se acumula cuando la funcionalidad se implementa de forma rápida y sucia para obtener resultados rápidos. A veces, puede que no sea posible deshacerse por completo de la deuda técnica debido a las presiones de entrega, etc. pero debe minimizarse en la medida de lo posible. Mientras tanto, Product Manager debería analizar conscientemente las implicaciones de lograr un debut técnico. La acumulación de deuda técnica tiene graves consecuencias y tiene un costo asociado. Al determinar el costo de cualquier característica, el Gerente de Producto debe incluir el costo de la deuda técnica, si corresponde, para realizar un análisis de costo versus beneficios para garantizar si vale la pena acumular deuda técnica.

La metodología de la tarjeta de puntaje anterior no logra un equilibrio entre las prioridades a corto y largo plazo. Las características a largo plazo cuando la pila clasificada puede no tener una clasificación más alta debido a su incapacidad para ofrecer un valor inmediato. Finalmente, no vivimos en un mundo perfecto. Siempre habrá presiones de la gerencia y los clientes para priorizar las características que serían una desviación absoluta. El gerente de producto debe decir claramente NO a esas solicitudes. Sin embargo, ciertos aspectos pueden ser poco políticos y los PM deben maniobrarlos diplomáticamente.

Espero que la respuesta anterior ayude. Por favor envíeme un mensaje para más detalles

Hay docenas de libros sobre estimación de proyectos de desarrollo de software, utilizando todas las diferentes metodologías. En mi experiencia, no tiene mucho sentido tratar de identificar realmente el esfuerzo por adelantado. Las cosas surgirán, las cosas cambiarán, las cosas serán más fáciles de lo que esperas y las cosas serán mucho más difíciles de lo que podrías haber imaginado.

Si tiene una idea bastante buena del alcance de la aplicación: la mejor manera de estimar para los propósitos de priorización es sentarse con los desarrolladores que harán el trabajo, dividir el trabajo en algunas piezas de alto nivel (no demasiado detallado), y luego haga que adivinen cuánto tiempo les tomará cada una de esas piezas grandes. Luego infla ese número en un 30%. Luego haz tu priorización.

Luego deseche la estimación y no piense nunca más en ello.