La dirección nos ha pedido que dediquemos un período de tiempo muy breve a "dimensionar" un proyecto de software, es decir, que les demos un margen de tiempo muy amplio para implementarlo todo.
Hay tres componentes principales (backend, ios, android), cada uno de los cuales será responsabilidad de un desarrollador con experiencia en el dominio. A cada persona se le ha dado treinta minutos para llegar a un número.
Hemos recibido un documento de requisitos de una página, hemos extrapolado algunas historias de usuarios generales y un documento de flujo general. Somos desarrolladores, no gerentes de proyecto, y no hay un Propietario del proyecto ya que nuestra empresa está en preventa de este proyecto y quiere darle al posible cliente un número suelto.
Como desarrolladores, nos sentimos incómodos dando números sobre una base tan limitada. Durante el desarrollo, generalmente hacemos Scrum (historias, puntos, sprints, standups, velocidad, etc.), por lo que una vez que estamos trabajando en un proyecto, nuestras estimaciones son fáciles y tienen cierta base en la realidad. Sin embargo, en este caso, todavía no hay ningún proyecto y no estamos seguros de cuál es la mejor manera de proceder.
¿Cómo debemos manejar esto? Y en el futuro, ¿cómo podría nuestra empresa hacer mejor las cosas?
He trabajado con muchos desarrolladores y directores de desarrollo que son muy reacios a dar un presupuesto con información y tiempo tan limitados. Han sido mordidos demasiadas veces en el pasado. La razón principal es que incluso si las personas que solicitan dicha estimación comprenden los riesgos y aseguran que se utilizará con cuidado, cuando pasan esos números a otros, a menudo tienden a malinterpretarse como un compromiso de entrega de precio fijo.
Por otro lado, la gerencia no invertirá el tiempo y el esfuerzo para desarrollar una estimación más precisa si no existe una oportunidad comercial potencial aquí. Aún más importante, el cliente no invertirá el tiempo para brindarle requisitos más detallados si el costo del orden de magnitud no está dentro del rango de los rendimientos potenciales.
¿Cómo se rompe este punto muerto? Si su empresa tiene que hacer negocios, todos deben encontrar una manera de salir de este punto muerto.
No hay bala de plata. Aquí hay algunas sugerencias:
Haga su estimación con el mayor rigor posible con la información disponible.
Al hacer la estimación, mencione cualquier suposición que haga explícitamente para llegar a la estimación.
Usa otros proyectos que hayas hecho para compararlos con este. Si este se siente más grande que otro proyecto que hizo, revise la estimación hacia arriba en consecuencia.
Prevea cambios en el diseño y las funciones: algo así como: "A medida que aprendemos más sobre la aplicación, surgen nuevos requisitos. Por lo general, habrá algunas funciones recortadas o ampliadas. Se descubrirán y agregarán nuevas funciones". Agregue, digamos, 20% a la estimación para cubrir tales cambios.
Proporcione el extremo superior del rango: por lo general, la gente de finanzas del cliente probablemente usará esto para obtener la aprobación presupuestaria. Si da un número más bajo, será muy doloroso para todos volver a la Junta y pedir más dinero. Pero, si ahorra algo de dinero más tarde, todos estarán felices.
Utilice una terminología aproximada: algo así como "Con un equipo de 3 desarrolladores a tiempo completo, un probador a tiempo completo y un diseñador a medio tiempo, Scrum Master y Product Owner compartidos con otro equipo, podemos ofrecer una versión funcional mínima en 2 trimestres. Más allá de eso, las siguientes 2 características principales tomarán una cuarta parte cada una".
Haga recomendaciones de elección de características y diseño que, si se aceptan, ahorrarán dinero de las estimaciones altas.
En primer lugar, no estás haciendo una estimación. Estás haciendo conjeturas . Este es un artículo de wiki sobre este término.
Guesstimate se define como una estimación realizada sin utilizar información adecuada o completa, o, más fuertemente, como una estimación a la que se llega por medio de conjeturas o conjeturas.
En otras palabras: obviamente, la estimación es algo entre adivinar y estimar. Tienes que confiar más en la intuición cuando estás haciendo estimaciones.
El punto principal (como se dijo en otras respuestas) para que los gerentes sepan que es una estimación. Ni siquiera es una estimación (como dijo WBW), ¡es más como un pronóstico! Como el pronóstico del tiempo. Con la misma precisión ;-)
Recuerde que es una estimación, no un compromiso.
Recomendaría las siguientes preguntas sobre la estimación:
- ¿Por qué se le está dando información/tiempo tan limitado para proporcionar la estimación? - ¿Para qué se utiliza la estimación que está proporcionando? - ¿Quién es responsable de la exactitud de la estimación? -¿Quién es responsable de la exactitud de la estimación?
Ahora a la estimación en sí. Proporcione una medida de confianza junto con su estimación para comunicarle a la persona que usa la estimación el riesgo que implica usar un solo número para tomar una decisión. Podría ser algo como...
"Bueno, dado que tenemos un documento de 1 página y 30 minutos para pensar en esto, estimo que el tiempo requerido para completar este trabajo es un promedio de 60 días más o menos 30 días. Me reservo el derecho de revisar mi estimación si es nueva. la información está disponible o si la información existente cambia".
Por supuesto, también es justo retroceder y no proporcionar una estimación si legítimamente siente que tiene muy poca confianza en la estimación que proporciona. Después de todo, una estimación con confianza 0 es solo una suposición.
El propósito del dimensionamiento del software suele ser proporcionar los datos en el proceso de análisis de costos y beneficios para que los equipos de toma de decisiones (es decir, los clientes) puedan elegir. Es mejor saber cuáles son las ofertas de otros competidores para que el equipo pueda proporcionar la propuesta ganadora. La estimación debe ser más como un enfoque de fase, ya que el equipo de desarrollo sabe más sobre los clientes. El ejemplo es el siguiente: por lo general, el marco de tiempo podría estar en línea con cada trimestre pendiente en el ciclo de entrega del equipo...
Fase I - Prototipo:
Fase II – Prelanzamiento
Fase III – Gran – Apertura
Fase N – Revisión - Lista de funcionalidades - Tamaño de usuarios - Plazo objetivo
(dependiendo de si los desarrolladores están asignados a múltiples tareas, como pruebas de control de calidad o soporte de producción, se debe agregar al menos un 20 % de tiempo adicional además de la estimación real del desarrollador)
MCW