¿Cómo responder cuando se le pide un presupuesto?

A nosotros, como programadores, nos preguntan constantemente "¿Cuánto tiempo llevará?"

Y sabes, la situación es casi siempre así:

• Los requisitos no están claros. Nadie ha hecho un análisis en profundidad de todas las implicaciones.
• La nueva característica probablemente romperá algunas suposiciones que hizo en su código y comenzará a pensar de inmediato en todas las cosas que podría tener que refactorizar.
• Tiene otras cosas que hacer de las tareas pasadas y tendrá que elaborar una estimación que tenga en cuenta ese otro trabajo.
• La definición de 'hecho' probablemente no esté clara: ¿cuándo se hará? ¿'Hecho' como recién terminado de codificarlo, o 'hecho' como en "los usuarios lo están usando"?
• No importa cuán consciente sea de todas estas cosas, a veces su "orgullo de programador" le hace dar / aceptar tiempos más cortos de lo que originalmente suponía que podría tomar. Especialmente cuando siente la presión de los plazos y las expectativas de la gerencia.

Muchos de estos son problemas organizativos o culturales que no son simples y fáciles de resolver, pero al final la realidad es que se le pide un presupuesto y esperan que responda de manera razonable. Es parte de tu trabajo. No puedes simplemente decir: no lo sé.

Como resultado, siempre termino dando estimaciones que luego me doy cuenta de que no puedo cumplir. Ha sucedido innumerables veces, y siempre prometo que no volverá a suceder. Pero lo hace.

¿Cuál es su proceso personal para decidir y entregar un presupuesto? ¿Qué técnicas has encontrado útiles?

Del programador pragmático: del oficialista al maestro :

Qué decir cuando se le pide un presupuesto

Dices "volveré a llamarte".

Casi siempre obtiene mejores resultados si ralentiza el proceso y pasa algún tiempo siguiendo los pasos que describimos en esta sección. Las estimaciones dadas en la máquina de café (como el café) volverán a atormentarte.

En la sección, los autores recomiendan el siguiente proceso:

• Determine la precisión que necesita. Según la duración, puede citar la estimación con diferente precisión. Decir "5 a 6 meses" es diferente a decir "150 días". Si te deslizas un poco en el séptimo mes, aún eres bastante preciso. Pero si te deslizas en el día 180 o 210, no tanto.
• Asegúrese de entender lo que se le pregunta. Determinar el alcance del problema.
• Modelar el sistema. Un modelo puede ser un modelo mental, diagramas o registros de datos existentes. Descomponga este modelo y cree estimaciones a partir de los componentes. Asigne valores y rangos de error (+/-) a cada valor.
• Calcule la estimación basada en su modelo.
• Sigue tus estimaciones. Registre información sobre el problema que está estimando, su estimación y los valores reales.
• Otras cosas para incluir en su estimación son desarrollar y documentar requisitos o cambios en las especificaciones de requisitos, crear o actualizar documentos y especificaciones de diseño, pruebas (unidad, integración y aceptación), crear o actualizar manuales de usuario o README con los cambios. Si 2 o más personas trabajan juntas, hay una sobrecarga de comunicación (llamadas telefónicas, correos electrónicos, reuniones) y la fusión del código fuente. Si es una tarea larga, tenga en cuenta cosas como otro trabajo, tiempo libre (vacaciones, vacaciones, enfermedad), reuniones y otras tareas generales al elegir una fecha de entrega.

La estimación de software es la tarea individual más difícil en ingeniería de software, un segundo lugar cercano es la obtención de requisitos.

Hay muchas tácticas para crearlas, todas basadas en obtener buenos requisitos primero. Pero cuando tu espalda está contra la pared y se niegan a darte mejores detalles, falsifícala:

1. Eche un vistazo a los requisitos que tiene.
2. Haga suposiciones para llenar los vacíos en función de su mejor suposición de lo que quieren
3. Escribe todos tus supuestos
4. Haz que se sienten, lean y acepten tus suposiciones (o, si tienes suerte, haz que cedan y te den requisitos reales).
5. Ahora tiene requisitos detallados que puede estimar.

Es como mi madre solía amenazar cuando era un niño "¡Date prisa y elige algo de ropa, o te la recogeré!"

Desarrollé un desarrollo para un tipo que era muy inflexible acerca de querer estimaciones precisas. Lo que decidimos, que funcionó muy bien, fue esto:

• Facturaba todo el tiempo que pasaba estimando. Llegó a alrededor del 20-25% de lo que facturé.
• Hice un examen extremadamente detallado de las tareas. No disparar desde la cadera. Entré en el código, descubrí qué líneas debían cambiarse, qué otras partes del programa afectaría, cuántas pruebas tendría que hacer para asegurar que las cosas aún funcionaran. Estimaría cada pieza en unidades de .1 horas (6 minutos).
• Le envié mi estimación para cada tarea junto con ese desglose detallado.

20-25% de la facturación parece mucho.

Pero me pidió que hiciera el cambio XYZ, pensando que tomaría aproximadamente 2 horas. En 1 hora de estimación detallada, determinaría que tomaría 8.5 horas. Entonces él decidiría si valía 8,5 horas de pago. Si no, ahorró 7.5 horas más de lo que le habría costado si lo hubiera hecho sin una estimación.

Y si se quiere invertir las 8,5 horas, el trabajo de detalle que hice para la estimación era un trabajo que me he tenido que hacer de todos modos.

Descubrí que con este método pude llevar la mayoría de las tareas a tiempo o incluso antes, sin tener que sobrestimar demasiado. Debido a que el tiempo se descompuso tan minuciosamente, pude saber desde el principio si estaba resbalando. Si llego a un obstáculo para que después de 3 horas pueda decir que mi tarea de 8,5 horas tomará 12, podría hablar con él antes de que pase más tiempo para que pueda reevaluar y eliminar la función si le preocupa el costo .

¿Se estaba volviendo loco? No, lo vi como dejarlo que aplicara su dinero donde vio el mayor beneficio. Y me alegraba tener experiencia en la estimación, algo en lo que siempre había sido terrible.

A menudo se nos pide una "estimación aproximada" durante las reuniones donde se nos dan ideas muy amplias y vagas de lo que les gustaría hacer. Siempre digo, "si quieres una respuesta hoy, es un año y un millón de dólares. Si quieres darme muchos más detalles y algo de tiempo para revisarlos, entonces puedo refinar esos números por ti".

Casi siempre captan el punto.

Depende de para qué es la estimación.

Para una estimación inicial de alto nivel para un caso de negocio, las cosas clave son:

1. Velocidad. Cualquier método que use debe ser rápido. El punto es que las partes interesadas no están seguras de si vale la pena hacer el proyecto, razón por la cual necesitan los números para el caso de negocios. Si el caso de negocios fuera sólido, no necesitarían sus estimaciones. La mayor parte de estos proyectos no se llevará a cabo, por lo que es importante que no se dedique demasiado esfuerzo al proporcionar la estimación.
2. Dar un rango. Hazlo amplio. No ha tenido tiempo para analizar requisitos, realizar talleres con partes interesadas, validar supuestos. Una amplia gama informa al destinatario de la estimación "Los proyectos de software son naturalmente complejos y riesgosos; si desea una estimación adecuada, debe darme más detalles y más tiempo". El problema con dar un solo número o un rango estrecho es que te pinta en una esquina al establecer expectativas antes de que se realice un análisis real.

Encuentro la mejor técnica para elegir un proyecto comparable que "sienta" lo mismo. "Feel" es completamente subjetivo, pero con este tipo de estimación, mi experiencia me dice que no encontrará medidas objetivas. Luego proporcione una amplia gama. He leído algunos libros que dicen que un rango de -50% a + 100% es bueno pero depende de muchos factores.

Para una estimación detallada de bajo nivel:

1. Necesitas una línea de base. Si la línea de base no es estable, la estimación no tiene sentido.
2. De abajo hacia arriba es lo mejor. Obtenga un desglose detallado del trabajo, calcule cada componente y luego enrolle en un número mayor. Creo que la planificación del póker es una gran técnica aquí.
3. Documento de contingencia. Deje en claro dónde se agrega cualquier contingencia (si corresponde). ¿Se agrega a cada línea de pedido? ¿O en general? ¿O a riesgos específicos? ¿O no hay ninguno?
4. Expresa tus suposiciones. Validar tantos como sea posible dado el marco de tiempo.
5. Indique explícitamente qué se incluye y excluye en la estimación. Por ejemplo, ¿se incluye la revisión? ¿Están incluidos los retrasos técnicos?

Algunos consejos del lado oscuro de alguien que aprendió por las malas.

Los requisitos no están claros. Nadie ha hecho un análisis en profundidad de todas las implicaciones.

No haga una estimación en este momento. Uno no estima cuántos soldados se necesitan para ganar una batalla sin tener idea de los números enemigos. La estimación se realiza después de explorar. Esto es a menos que ya hayas luchado contra este enemigo.

La nueva característica probablemente romperá algunas suposiciones que hizo en su código y comenzará a pensar de inmediato en todas las cosas que podría tener que refactorizar.

Es su responsabilidad tener en cuenta a menos que espere que otros tengan la experiencia sobre esta área.

Tiene otras cosas que hacer de las tareas pasadas y tendrá que elaborar una estimación que tenga en cuenta ese otro trabajo.

Igual que el anterior, incluso para el trabajo no anticipado creado por un compañero de equipo descuidado junto a usted con un procedimiento de prueba casi inexistente que hace que su código falle y que no puede predecir perfectamente por adelantado. Es un pronóstico del tiempo.

La definición de 'hecho' probablemente no esté clara: ¿cuándo se hará? ¿'Hecho' como recién terminado de codificarlo, o 'hecho' como en "los usuarios lo están usando"?

Comprenda el requisito de usuario final aquí, piense como un usuario. No haga lo que hacen sus compañeros si estiman que algo está "hecho" simplemente porque algunas funcionalidades básicas con un flujo de trabajo básico que ningún usuario puede tolerar es lo que consideran "hecho" . Piénselo desde el punto de vista del usuario, porque eso es todo lo que el cliente para el que realiza la estimación generalmente lo entenderá. Calcule los requisitos completos del usuario final, no los requisitos técnicos básicos. Y tenga en cuenta que sus clientes que soliciten presupuestos serán totalmente inexactos aquí sobre cómo redactan las cosas y entienden los aspectos técnicos de lo que usted dice.

No importa cuán consciente sea de todas estas cosas, a veces su "orgullo de programador" le hace dar / aceptar tiempos más cortos de lo que originalmente suponía que podría tomar. Especialmente cuando siente la presión de los plazos y las expectativas de la gerencia.

¡No hagas esto! Suenas como un trabajador duro y motivado y posiblemente uno que cede fácilmente a la coerción.

El problema aquí es este: digamos que usted y Joe hicieron estimaciones de tiempo para la misma tarea (pero entre dos empleados separados, sin darse cuenta de ambas estimaciones al mismo tiempo). Estima valientemente, "una semana" . Está bien, piensa, trabajará más de 100 horas a la semana, horas extras no remuneradas. Ahora llegas tres días tarde.

Mientras tanto, Joe estima 5 meses. Piensas que esto es ridículo, crees que puedes lograrlo en una semana. ¿Cuánto trabaja Joe? 10 horas a la semana? ... excepto que termina a tiempo en exactamente 5 meses.

Adivina quién se percibe como el burro? Así es usted. Joe parece un gran trabajador, ahora pareces poco confiable. No importa tanto que haya logrado un resultado aún mejor en ~ 7% del tiempo que Joe tomó. Lo que importa es que tenía 3 días de descanso de una estimación de una semana.

Nunca errar en el lado de la estimación más ajustada. Errar en el lado de la estimación más floja. Hay una reputación que construir en su empresa, y no se basará en la longitud de sus estimaciones tanto como en la precisión de sus estimaciones. Es fácil ser preciso con una estimación demasiado larga, solo tiene más tiempo para trabajar en el problema y resolverlo mejor. Una estimación demasiado corta no deja espacio para respirar, o la encuentras desesperadamente o estás jodido.

"¡Dos semanas!"

Seriamente. Mi primera estimación es siempre dos semanas. Porque tengo algún tipo de bloqueo mental extraño que me hace pensar que todo suena como si fueran dos semanas.

Trato de solucionarlo, trato de pensar realmente cuánto tiempo creo que tomará algo, tratando de identificar todos los posibles puntos problemáticos y bits que parecen demasiado negros para que pueda estimar con precisión. Y trate de reconocer que si mi respuesta es "¡Dos semanas!", Probablemente no lo haya hecho.

Casi todos los buenos gerentes que he tenido han aprendido a reconocer "¡Dos semanas!" como respuesta que requiere una leve cachetada verbal en respuesta.

Hay una entrada de blog que describe cómo mantener un registro de cuán precisas han sido sus estimaciones anteriores, y luego la próxima vez que le diga a alguien "serán dos semanas", puede ver su historial anterior y ver cuánto tiempo en realidad tomó la última vez que dijiste "serán dos semanas"

No lo he intentado yo mismo, pero me gustaría ver qué tan precisas son mis estimaciones.

Depende de la organización y de cómo se utilizan las estimaciones.

Si la estimación es solo para proporcionar una idea general sobre cuándo estará lista, generalmente puedo hacer una estimación rápida basada en mi experiencia. Muchas veces incluiré cualquier incertidumbre o posibles variaciones con la estimación junto con cómo los cambios pueden afectar otras áreas del sistema y el alcance de las pruebas de regresión requeridas.

Si la estimación se usa para algo contractual o en un escenario donde se requiere un tiempo más preciso, hago un desglose completo del trabajo. Esto es más trabajo y requiere una reflexión más profunda sobre el diseño y los cambios en el sistema, pero es mucho más preciso, especialmente para trabajos más grandes.

En cualquier caso, la comunicación continua es clave. Si te encuentras con algo inesperado, hazlo saber en ese momento en lugar de esperar hasta la fecha límite. Si los requisitos no son claros, asegúrese de documentar su comprensión de ellos y la funcionalidad que planea ofrecer. Esto también es útil con cualquier suposición que haga. Y en lo que respecta a las prioridades en competencia, cuando un trabajo golpea a otro, tenga claro cómo eso afectará el cronograma.

¿Estimaciones para qué? Pequeñas tareas o soluciones completas.

Raramente hago esto último, pero luego solo adivino, agrego un poco, haga que el gerente agregue un poco y lo convierta en un rango, con una pequeña nota al lado que indica que lo anterior es una suposición.

Pequeñas tareas: planear el póker que he encontrado que funciona muy bien (no perfecto, algunas tareas de 1pt han tomado mucho más tiempo y algunas tareas de 5pt tomaron minutos, pero al final todo se iguala).

Presente una gama basada en lo que sabe hoy. Use el Cono de incertidumbre para proporcionar el rango alrededor de sus estimaciones iniciales.

Cada semana calcule cuánto queda por hacer, vuelva a estimar en función de lo que sabe. Una vez que tenga un tamaño de muestra suficiente de la cantidad de trabajo que realiza cada semana, proporcione un intervalo de confianza del 90% para lo que queda para dar un rango de fechas (generalmente) cada vez más estrecho a medida que avanza el proyecto y la cantidad de trabajo restante (con suerte ) se encoge.

Con confianza No puedo decir cuántas veces arruiné una reunión inicial con un cliente al no ponerme profesional al dar una estimación. Incluso si está volando números de la nada, asegúrese de mantener siempre un cálculo aproximado. Dicho esto, tenga cuidado de no estimarse en un agujero. Las diferentes cosas requieren diferentes cantidades de tiempo, esfuerzo y recursos para organizarse. Aquí hay una buena manera de hacerlo:

Ellos: ¿Cuánto costará?

Yo: Depende de lo que quieras que haga. En general, comienzo este tipo de proyecto en alrededor de $ X.

A veces, la estimación se convierte en un desafío enorme para usted y su equipo, especialmente cuando hablamos de la estimación de proyectos de software.

Una vez que decidimos compartir nuestra experiencia y nuestro conocimiento sobre el proceso de estimación de software y definimos cuatro tipos distintos de estimaciones :

• figura de estadio
• estimación de servicio
• estimación de características
• estimación componencial

Por supuesto, esos tipos son distintos. Ballpark es lo que a menudo se llama una "estimación aproximada". Por lo tanto, es un número o rango aproximado que da una idea general del costo y que puede ayudar a un prospecto a decidir si le gustaría llevar la discusión más allá.

Como regla general, los clientes necesitan una cifra aproximada al comienzo del proyecto. Y nuestro consejo es: la discusión del proyecto y la provisión de cifras aproximadas deberían ser solo pasos para recibir una estimación componencial (que es flexible, uno puede hacer uso de la estimación del tipo componencial para todo el proceso de desarrollo. No es necesario volver a estimar desde cero cuando desea agregar, eliminar o reemplazar funciones, servicios, etc.

Todos deberían tener en cuenta los riesgos que conlleva la estimación del desarrollo de software: subestimación, sobreestimación, escenario de falla épica total, etc.

¡Puedes leer más en nuestro blog!

http://blog.lemberg.co.uk/project-management/software-estimation-process/

Espero que esta información te ayude!

Siempre termino dando estimaciones que luego me doy cuenta de que no puedo cumplir. Ha sucedido innumerables veces, y siempre prometo que no volverá a suceder.

Parece que te piden un compromiso, no una estimación. Estas son cosas diferentes, pero si puede gestionar los compromisos de manera confiable, realmente ayudará a su credibilidad y carrera.

Algunos consejos basados ​​en mis ~ 10 años de experiencia:

• Siempre proporcione un rango (es decir, límite inferior y superior). Esto comunicará tu nivel de incertidumbre
• Si tiene una gran incertidumbre, solicite un aplazamiento (por ejemplo, 1 día para hacer el análisis y luego proporcione un rango más ajustado)
• Si la tarea es demasiado grande, divídala y proporcione un rango para cada pieza

Primero, si me asignaron alguna tarea, la dividiría en subtareas, estimaría el tiempo para cada subtarea y probablemente con subtareas podría encontrar el área problemática y, por lo tanto, podría pronosticar cuánto tiempo duraría tomar hasta cierto punto.

Pero aún así toda la planificación ayudaría solo hasta cierto punto. Solo cuando comienzas a codificar puedes encontrar los problemas exactos

Si realiza muchos proyectos para el mismo jefe o cliente, puede intentar estimar en grandes rasgos de complejidad en lugar de semanas o meses, posiblemente en tamaños de camisetas. Identifique algunos proyectos anteriores y asígneles los tamaños S, M, L, XL.

Y luego pregúntese: ¿a qué proyecto suena similar en alcance? Y luego, en lugar de responder con "2 meses", puede responder con "suena como una L para mí" (o lo que resulte ser su calibración para el proyecto).

Esto es bastante fácil de entender, y también está claro que hay mucha incertidumbre en esas conjeturas.

Luego, cuando cambian los requisitos, puede decir "ese cambio hace que suene más como un XL".

Un poco tarde, pero cuando estaba en el ejército se nos indicó que usáramos PERT para determinar las estimaciones. Requiere algo de experiencia en su campo y la tarea en cuestión. Fue sorprendentemente preciso al determinar el tiempo estimado de finalización al mantener y reparar dispositivos electrónicos (radios complejas y equipos de comunicaciones satelitales), donde cualquier cantidad de cosas pueden estar equivocadas o encontradas y deben repararse durante el mantenimiento de rutina. Las estimaciones fueron importantes porque otras unidades pueden no funcionar hasta que reciban de vuelta su equipo de comunicaciones. Una que he usado es esta calculadora PERT gratuita en línea