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

De El programador pragmático: de Journeyman a Master :

  

Qué decir cuando se le pide un presupuesto

     

Dices "Me pondré en contacto contigo"

     

Casi siempre obtiene mejores resultados si retrasa 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 cotizar 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, todavía eres bastante exacto. Pero si se desliza en el día 180 o 210, no tanto.
• Asegúrese de que entiende lo que se está preguntando. Determine el alcance del problema.
• Modelar el sistema. Un modelo puede ser un modelo mental, diagramas o registros de datos existentes. Descomponer este modelo y construir estimaciones a partir de los componentes. Asigne valores y rangos de error (+/-) a cada valor.
• Calcule la estimación según su modelo.
• Seguimiento de sus estimaciones. Registre la información sobre el problema que está estimando, su estimación y los valores reales.
• Otras cosas que debe incluir en su estimación son el desarrollo y la documentación de los requisitos o los cambios en las especificaciones de los requisitos, la creación o actualización de documentos y especificaciones de diseño, pruebas (unidad, integración y aceptación), la creación o actualización de 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 combinación de código fuente. Si es una tarea larga, tenga en cuenta cosas como otro trabajo, tiempo libre (vacaciones, vacaciones, tiempo de 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 la ingeniería de software, un segundo cercano es la obtención de requisitos.

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

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

Es como si mi madre solía amenazar cuando yo era un niño "¡Date prisa y escoge algo de ropa, o yo te lo hago por ti!"

Hice un desarrollo para un tipo que estaba muy convencido de querer estimaciones precisas. Lo que decidimos, que funcionó muy bien, fue lo siguiente:

• facturé por todo el tiempo que pasé estimando. Llegó a alrededor del 20-25% de lo que facturé.
• Hice un examen extremadamente detallado de las tareas. No hay disparos desde la cadera. Entré en el código, descubrí qué líneas había que cambiar, a qué otras partes del programa afectaría, cuántas pruebas tendría que hacer para garantizar que las cosas siguieran funcionando. Estimo cada pieza en unidades de .1 horas (6 minutos).
• Le envié mi estimación para cada tarea junto con el detalle detallado.

20-25% de la facturación suena como mucho.

Pero él 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. Así que él decidiría si valía 8,5 horas de pago. De lo contrario, ahorró 7,5 horas de lo que le hubiera costado si lo hubiera hecho sin una estimación.

Y si quería invertir las 8.5 horas, el trabajo detallado que hice para la estimación fue el trabajo que habría tenido que hacer de todos modos.

Encontré que con este método pude llevar la mayoría de las tareas a tiempo o incluso temprano, sin tener que sobrestimar demasiado. Debido a que el tiempo se desglosó tan minuciosamente, pude ver desde el principio si me estaba escapando. Si llego a los obstáculos para que, después de 3 horas, me diera cuenta de que mi tarea de 8,5 horas iba a tomar 12, podría hablar con él antes de que pasara más tiempo para que pudiera reevaluar y rechazar la función si estaba preocupado por el costo .

¿Él era de cinco centavos? No, lo vi como permitir que él aplicara su dinero donde veía el mayor beneficio. Y me alegré de tener experiencia en la estimación, que siempre había sido terrible.

A menudo se nos pide una "estimación aproximada" durante las reuniones en las que se nos dan ideas muy amplias sobre 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 más tiempo para revisarlos, entonces puedo refinar esos números por ti".

Casi siempre consiguen 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 utilices debe ser rápido. El punto es que las partes interesadas no están seguras de si vale la pena realizar 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 continuarán, por lo que es importante que no se dedique demasiado esfuerzo a la estimación.
2. Dar un rango. Hazlo amplio. No ha tenido tiempo para analizar requisitos, talleres con partes interesadas, validar suposiciones. Una amplia gama le dice al destinatario de la estimación "Los proyectos de software son naturalmente complejos y arriesgados; si desea una estimación adecuada, necesita darme más detalles y más tiempo". El problema de dar un solo número o un rango estrecho es que te pone 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 "siente" lo mismo. "Sentir" es completamente subjetivo, pero con este tipo de estimación, mi experiencia me dice que no encontrará medidas objetivas. A continuación, proporcionar 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. la parte inferior es la mejor. Obtenga un desglose detallado del trabajo, calcule cada componente y luego enróllelo en un número mayor. Me parece que planificar el póker es una gran técnica aquí.
3. Documento de contingencia. Deje claro dónde se agrega cualquier contingencia (si existe). ¿Se agrega a cada artículo de línea? ¿O a toda la estimación? ¿O a riesgos específicos? ¿O no hay ninguno?
4. Indique sus suposiciones. Valide tantos como sea posible dado el marco de tiempo.
5. Indique explícitamente qué se incluye y excluye en la estimación. Por ejemplo, ¿está incluida la revisión? ¿Se incluyen retrasos técnicos?

"¡Dos semanas!"

En serio. Mi primera estimación es siempre dos semanas. Porque tengo una especie de extraño bloqueo mental que me hace pensar que todo parece que son dos semanas.

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

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

Algunos consejos del lado oscuro de alguien que aprendió de la manera más difícil.

  

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

No hagas una estimación en este punto. Uno no calcula 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 la exploración. Esto es a menos que ya hayas luchado contra este enemigo.

  

La nueva función probablemente romperá algunas suposiciones que hiciste en tu   código y empiezas a pensar inmediatamente en todas las cosas que podrías   Hay que refactorizar.

Esta es su responsabilidad de tener en cuenta a menos que espere que otros tengan experiencia en esta área.

  

Usted tiene otras cosas que hacer de asignaciones anteriores y tendrá que   elabore una estimación que tenga en cuenta ese otro trabajo.

Igual que el anterior, incluso para el trabajo no anticipado que fue creado por un compañero de equipo slob a tu lado con un procedimiento de prueba casi inexistente que hace que tu código falle y que no puedas predecir perfectamente de antemano. Es un pronóstico del tiempo.

  

La definición de "hecho" probablemente no esté clara: ¿cuándo se hará?   'Hecho' como acaba de terminar de codificar, o 'hecho' como en "los usuarios están   usándolo "?

Comprenda el requisito de fin de usuario aquí, piense como un usuario. No haga lo que hacen sus compañeros si estiman que algo se "haga" simplemente porque alguna funcionalidad básica con un flujo de trabajo de barebones que ningún usuario pueda tolerar es lo que consideran "hecho" . Piénselo desde el punto de vista del usuario, ya que ese es el único cliente por el que está haciendo la estimación y que comprenderá. Calcule hacia los requisitos completos de usuario final, no hacia los requisitos técnicos de barebone. Y tenga en cuenta que sus clientes que solicitan estimaciones serán totalmente inexactos aquí acerca de cómo expresan las cosas y entienden los aspectos técnicos de lo que usted dice.

  

No importa cuán consciente seas de todas estas cosas, a veces tu   El "orgullo del programador" te hace dar / aceptar tiempos más cortos que tú.   originalmente supongamos que podría tomar. Especialmente cuando sientes la presión.   de plazos y expectativas de gestión.

¡No hagas esto! Pareces un trabajador muy motivado y posiblemente uno que cede fácilmente a la coacción.

El problema aquí es el siguiente: digamos que usted y Joe hicieron estimaciones de tiempo para la misma tarea (pero entre dos empleados separados, sin conocer ambas estimaciones al mismo tiempo). Usted estima valientemente, "una semana" . Piensa que está bien, trabajará más de 100 horas a la semana, horas extra sin pagar. Ahora llegas tres días tarde.

Mientras tanto, Joe estima 5 meses. Si crees 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 es percibido como el burro? Así es, usted. Joe parece un gran trabajador, ahora pareces poco confiable. No importa tanto que podría haber logrado un resultado aún mejor en aproximadamente el 7% del tiempo que Joe tomó. Lo que importa es que tenías 3 días libres de una estimación de una semana.

Nunca errar en el lado de la estimación más estricta. Err en el lado de la estimación más flexible. Hay una reputación que construir en su empresa y no se basará en la longitud de sus estimaciones, sino en la exactitud de sus estimaciones. Es fácil ser preciso con una estimación demasiado larga, solo tienes más tiempo para resolver el problema y resolverlo mejor. Un cálculo demasiado corto no deja espacio para respirar, lo satisfaces desesperadamente o estás jodido.

Hay una entrada de blog que describe cómo mantener un registro de la precisión de su versión anterior. las estimaciones se han ido, y luego, la próxima vez que le digas a alguien "serán dos semanas", puedes mirar tu historial anterior y ver cuánto tiempo tardaste en hacer la última vez que dijiste "serán dos semanas".

No lo he probado yo mismo, pero me gustaría, para ver qué tan exactas son mis estimaciones.

Depende de la organización y de cómo se utilicen 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 según mi experiencia. Muchas veces incluiré cualquier incertidumbre o posibles variaciones con la estimación junto con la forma en que los cambios pueden afectar otras áreas del sistema y el alcance de las pruebas de regresión requeridas.

Si la estimación se utiliza para cualquier cosa contractual o en un escenario donde se requiere una sincronización más precisa, realizo un análisis 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 se encuentra con algo inesperado, hágalo saber en el momento en lugar de esperar hasta la fecha límite. Si los requisitos no están claros, asegúrese de documentar su comprensión de los mismos y la funcionalidad que planea ofrecer. Esto también es útil con cualquier suposición que hagas. Y en cuanto a las prioridades en competencia, cuando una pieza de trabajo golpea a otra, tenga claro cómo afectará eso al calendario.

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

Lo último que hago rara vez, pero luego simplemente adivino, agregue un poco, pida al administrador que agregue un poco y lo convierta en un rango, con una pequeña nota al lado que indique que lo anterior es una suposición.

Tareas pequeñas - Poker de planificación Me parece que funciona muy bien (no es perfecto, algunas tareas 1pt han costado mucho más tiempo y algunas tareas de 5 puntos tomaron minutos, pero todo se nivela al final).

Presente un rango basado 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 según lo que sabe. Una vez que tenga un tamaño de muestra suficiente de la cantidad de trabajo que recibe cada semana, proporcione un intervalo de confianza del 90% para que lo que le queda le proporcione un intervalo de fechas cada vez más estrecho a medida que el proyecto avanza y la cantidad de trabajo restante (con suerte ) se encoge.

Con confianza. No puedo decirle cuántas veces fracasé en una reunión inicial con un cliente al no poner profesionalismo al dar una estimación. Incluso si estás perdiendo números de la nada, asegúrate de mantener siempre una estimación aproximada. Dicho esto, ten cuidado de no estimarte en un agujero. Diferentes cosas requieren diferentes cantidades de tiempo, esfuerzo y recursos para juntarlos. 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 enorme desafío para usted y su equipo, especialmente cuando estamos hablando 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
• servicio estimado
• estimación de características
• estimación componencial

Por supuesto, esos tipos son distintos. Ballpark es lo que a menudo se denomina "guesstimate". Por lo tanto, es un número o rango aproximado que da una idea general del costo. y eso puede ayudar a un prospecto a decidir si les gustaría continuar con la discusión.

Como regla general, los clientes necesitan una cifra aproximada al inicio del proyecto. Y nuestro consejo es: la discusión del proyecto y la provisión de cifras aproximadas deben ser pasos para recibir estimación de componentes (que es flexible, se puede usar la estimación de tipo de componentes para todo el proceso de desarrollo. No es necesario para volver a estimar desde cero cuando desee agregar, eliminar o reemplazar funciones, servicios, etc.).

Todos deben tener en cuenta los riesgos que conlleva la estimación del desarrollo de software: subestimar, sobreestimar, el escenario de falla épica total, etc.

¡Puedes leer más en nuestro blog!

enlace

¡Espero que esta información te ayude!

Primero, si me asignaran alguna tarea, la dividiría en subtareas. Estimaría el tiempo para cada una de ellas y, probablemente, con las subtareas podría encontrar el área problemática y, por lo tanto, podría pronosticar cómo Cuánto tiempo llevaría 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

  

Siempre termino dando estimaciones que luego me doy cuenta de que no puedo cumplir. Ha ocurrido 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 administrar los compromisos de manera confiable, esto realmente ayudará a su credibilidad y carrera.

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

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

Si realiza muchos proyectos para el mismo jefe o cliente, puede tratar de estimar en grandes rasgos de complejidad en lugar de semanas o meses, posiblemente en el tamaño de una camiseta. Identifique algunos proyectos anteriores y asigne los tamaños S, M, L, XL.

Y luego pregúntate: ¿qué proyecto suena similar al de alcance? Y luego, en lugar de responder con "2 meses", puedes responder con "suena como una L para mí" (o lo que resulte ser tu 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, puedes decir "ese cambio hace que suene más como un XL".

Un poco tarde, pero cuando estaba en el ejército nos ordenaron usar PERT para determinar las estimaciones. Requiere alguna 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 complejos y equipos de comunicaciones por satélite), donde cualquier número de cosas puede ser incorrecto o encontrarse y debe repararse durante el mantenimiento de rutina. Las estimaciones fueron importantes porque otras unidades pueden estar inoperables hasta que reciban su equipo de comunicaciones. Una que he usado es esta Calculadora PERT en línea gratuita