Manejo de estimaciones terribles

Se demostró que el arquitecto subestimó severamente un proyecto reciente en el que trabajé. La estimación fue de al menos un 500%.

Lamentablemente, me llevaron al proyecto después de que la estimación se hubiera firmado con el cliente. Como desarrollador senior, rápidamente me di cuenta de que las especificaciones funcionales y técnicas. contenía algunas lagunas e incertidumbres enormes.

Como resultado, me sentí obligado a convocar una reunión de emergencia con los directores técnicos y comerciales para hacerles saber la realidad. Como desarrollador principal, me pareció una situación muy estresante y difícil. El "negocio" acusó a TI de ser incompetente y ser el mensajero. Recibí algunas "balas".

El cliente amenazó con cancelar la cuenta, sin embargo, hasta la fecha, el proyecto aún no está terminado y ya no estoy directamente involucrado en él.

El arquitecto era un buen tipo socialmente, pero en base a este episodio era simplemente incompetente o había grandes presiones de ventas / negocios que influían en su estimación.

Entonces, como programadores, ¿cuál es su experiencia con este tipo de situación y cómo aconsejarían enfrentarla?

Respuesta larga, pero bueno, tengo un resumen al final, ¡así que salte al resumen si no puede molestarse en leer todo!

Como desarrollador, tuve que lidiar con la situación literalmente en cualquier otro proyecto, pero no fue hasta que me mudé a la gestión de proyectos que aprendí a manejarlo de manera efectiva. Para mí, tratar eficazmente se trata de dos cosas: gestionar las expectativas y comprender cómo funciona la estimación.

Comience con la premisa de que no es ético proporcionar una estimación, comprometerse con una estimación o dar cualquier otra indicación de precisión de la estimación sin ser capaz de llevar a cabo una debida diligencia primero. Otras personas confían en su capacidad profesional para predecir la cantidad de trabajo requerida, dar una indicación falsa les perjudicará a ellos y a sus negocios.

Pero tienes que dar algo, en la vida real te arrastraste a una reunión improvisada o un proyecto tardío y tu superior probablemente dejará en claro que esperan que obtengas alguna cifra de inmediato o que comentes sobre la estimación que proporcionaron. Aquí es donde entra en juego la gestión de expectativas.

Explique que sería incorrecto de su parte dar cualquier cifra o indicación sin comprender el problema y resolver los números por sí mismo. Digamos que sus cifras pueden ser bastante correctas, simplemente no lo sabes antes de realizar el ejercicio de estimación. Y aunque tenga una buena idea de lo que se necesita allí y cuándo, digamos que todavía necesita algo de tiempo para resolver los números. Solo hay una estimación que pueden esperar que usted brinde: cuándo podrá proporcionar una estimación. Por supuesto, proporcione esa cifra.

Como desarrollador, nunca se responsabiliza (ni da indicaciones de que se puede interpretar como aceptación de) las estimaciones de otras personas sin poder revisarlas primero. Como gerente de proyecto, es un asunto totalmente diferente, porque en realidad tienes cierto control sobre el proceso de estimación: la forma en que se obtiene y revisa una estimación y tienes que depender de otras personas para realizar el trabajo real y debes hacer Seguro que están comprometidos.

Nunca haga comentarios sobre estimaciones sin poder hacer la debida diligencia. Esto es ético. Un abogado o un médico dejarán absolutamente claro que no pueden dar ningún consejo a menos que un cliente (o paciente) cumpla con sus reglas y primero realice un procedimiento de evaluación. Del mismo modo, tiene derecho a satisfacer sus preguntas antes de dar su opinión profesional.

La segunda parte trata sobre cómo funciona la estimación. Sugiero investigar varios enfoques para hacer estimaciones y cómo funciona el proceso de estimación, incluidas las industrias distintas del desarrollo de software (fabricación, mercados financieros, construcción). Esto le dará una idea de lo que su jefe o cliente puede esperar razonablemente de usted y, extrañamente, ayudará a hacer predicciones más precisas sobre la cantidad de trabajo. Mejorará su capacidad de defender sus estimaciones y deberá defender las cifras cada vez que sean diferentes de las proporcionadas por un arquitecto o un vendedor.

Normalmente, la forma en que funciona es que su estimación se escanea primero en busca de elementos de aspecto extraño o relativamente grandes. Por lo tanto, prepárate para defender cualquier cosa con nombre "no estándar". También divida las tareas más grandes para que todas las tareas tengan el mismo orden de magnitud, es decir, si la mayoría de las tareas demoran 2 días y una sola tarea es de 10 días, prepárese para ser perforado.

Sea claro sobre lo que se incluye en cada tarea, lo mejor es dividir las pruebas de unidad y desarrollo en lugar de simplemente tener un desarrollador y que alguien asuma que también incluye documentación. Obviamente de esta manera necesitará producir una estimación de grano bastante fino.

Luego viene la perforación. Dado que es bastante difícil revisar un desglose de trabajo prolongado, es probable que su cliente o jefe adopte una estrategia diferente: concéntrese en un bit aleatorio sobre el que puedan saber algo y desglose hasta que logren desacreditar la estimación completa o estén satisfechos con su respuestas ¡La credibilidad de la estimación completa puede depender de una muestra aleatoria! Por lo tanto, una vez más, necesita tiempo para prepararlo con cuidado, incluir solo fragmentos relevantes, excluir cualquier extra o moverlos a una sección de "bueno para tener" y pensar cómo va a defender las cifras.

Obviamente, puede ser coherente en su enfoque, es decir, estimar en función de las características, el número de pantallas, etc. o tener una combinación de enfoques, pero en cualquier caso, prepárese para defender por qué seleccionó una determinada forma de estimación. También esté preparado para explicar por qué sus cifras son diferentes de cualquier otro intento de predecir la cantidad de trabajo requerido.

Conozca los signos obvios de estimaciones débiles:

• Lleno de tareas generales, copiadas de la plantilla (las buenas estimaciones son específicas de la tarea en cuestión).

• Estimaciones de grano grueso (es decir, tareas que duran más de un par de días).

• Estimaciones hechas en la etapa inicial de un proyecto o por alguien que podría no tener conocimiento real de los requisitos o el trabajo involucrado.

• Estimaciones compiladas por personas que no sean realistas

• Estimaciones vagas (no está claro qué está incluido e, igualmente importante, excluido).

• Diferencia sustancial en el orden de las magnitudes de la tarea.

Practique evaluando las estimaciones de otras personas y analizando las cifras sin el conocimiento real de los detalles de implementación. Esto ayudará a respaldar su reclamo por un tiempo adicional cuando se le solicite que confirme el cálculo de otra persona cuando no tenga evidencia sólida.

Resumir:

• No se comprometa con una estimación horrible o cualquier otra cosa antes de tener la oportunidad de realizar la debida diligencia.

• Deje en claro desde el principio, no deje que nadie asuma que es de otra manera e interprete su silencio como una señal de acuerdo.

• Sepa cómo funcionan varios métodos de estimación, su aplicación práctica y sus méritos, incluidos estos desarrollos de software externos.

• Prepárate para defender tu estimación.

• Aprenda a evaluar las estimaciones de otras personas para que no tenga que comprometerse con cifras muy inexactas.

Es imposible predecir el futuro. Requerir una predicción ("estimación") es simplemente pedir problemas. Todos lo hacen y todos se equivocan.

Su juicio de "salir en un 500%" es probablemente tan erróneo como la estimación del arquitecto. Después de todo, "... hasta la fecha el proyecto aún no está terminado ..." No hay datos disponibles aquí.

Nadie sabe la respuesta "correcta". Y hasta que esté hecho, nadie lo sabrá.

E incluso después de hacerlo, la estimación "original" (con o sin control de cambios) puede no correlacionarse con nada de lo que realmente se logró.

La estimación es una trampa: es un juego manipulado. no puedes ganar, no puedes alcanzar el equilibrio y ni siquiera puedes salir del juego.

Editar

Tratar con malas estimaciones; Una estimación "heredada" que parece incorrecta .

Ahí está. No estás de acuerdo con las estimaciones de otra persona. O bien omitieron algo que crees que es necesario; tenían un alcance de trabajo diferente al que usted tenía, o tenían una tasa de productividad diferente. Además, si la estimación es más que un simple esfuerzo, tienen una base de costo diferente. Todos los cuales son discutibles. Entonces disputa los detalles que conducen a la estimación. No discuta el número general: no hay información real en un resumen. Disputa detalles individuales que sustentan la estimación. Descubre lo que estaban pensando.

Es probable que sus suposiciones sean tan erróneas como sus suposiciones. Igualmente probable.

Cuando se le solicite una estimación .

1. Te vas a equivocar.

   1. Mienten sobre el alcance del trabajo.

   2. No conoces la productividad del equipo.

   3. Cualquier nueva tecnología involucrada se ha tergiversado.

2. No puede simplemente agregar relleno para cubrir estas cosas al azar. En realidad no lo sabes y no tienes una base para "estimar". Es solo adivinar. Superalo.

Regla 1: como solo estás adivinando, adivina en pequeños incrementos.

La pregunta fundamental en cualquier situación de "estimación" no es predecir el futuro. No puede hacer eso con precisión durante períodos de tiempo mucho más largos que una semana o dos. Limite sus predicciones a un horizonte temporal sobre el cual tenga un conocimiento detallado directo e inmediato. Por ejemplo, la próxima versión.

La pregunta fundamental es, generalmente, la toma de decisiones por parte de sus compradores o clientes. La pregunta no es "¿cuánto costará?" Eso está incompleto. La pregunta es "¿valdrá la pena la inversión?" La verdadera pregunta es más similar a "¿cuál es la relación costo / beneficio" y "cuándo deberíamos dejar de gastar porque más inversión no generará más retorno?" Esas son las preguntas reales.

Regla 2: Apoye al tomador de decisiones con información objetiva.

La mayoría de las personas se benefician mejor con un enfoque ágil. El primer lanzamiento, dentro de un mes, tomará 5 personas × 4 semanas y producirá la función X que repara las pérdidas de $ 1m / día y la función Y que repara las oportunidades perdidas de $ 200K / semana. Tiene un conocimiento detallado de lo que está haciendo, por lo que esta predicción tiene sentido. El lanzamiento después de eso es un poco confuso.

El lanzamiento dentro de un año está tan lejos en el futuro que cualquier predicción en solo un número aleatorio. No se preocupe por los detalles de nada más de 6 meses en el futuro, solo use reglas simples.

Cuando preguntan qué es el TCO, debes ser honesto. "El costo total ocurre cuando dejas de pagar por el desarrollo. Hasta que dejas de pagar, siempre incurrirás en costos".

La verdadera pregunta es "¿qué problemas estás tratando de solucionar?" o "¿qué nueva oportunidad estás buscando?" y "¿cuánto vale eso?"

Regla 3: Haga que el software sea menos costoso que el problema que se supone que debe resolver.

Si no conoce muy bien el problema, la estimación se ajustará a la percepción. Intenta evitar esto.

En la probabilidad . Excepto por enfermedades o accidentes debilitantes, ninguna parte del desarrollo de software se rige por las probabilidades reales. Los "riesgos" son simplemente una mala gestión. Generalmente de la forma "no tomamos en cuenta la complejidad de la necesidad comercial A o la tecnología B". Más a menudo de la forma "a medida que aprendimos más sobre el problema o la tecnología, modificamos el cronograma", que se castiga como "alcance del alcance".

No hay probabilidad de aprender cosas y cambiar el alcance. Eso es una certeza.

En la planificación . Hay "planificación" y hay "estimación". Planear qué construir es una cosa, mejor representada como una lista de verificación o un gráfico de dependencia. La "estimación" del esfuerzo requerido se basa en factores desconocidos.

"Planificación" es una buena gestión ordinaria.

La "estimación" requiere un conocimiento incognoscible. Para "estimar el esfuerzo" con precisión, debe tener un nivel de conocimiento del código fuente sobre el producto y debe saber qué persona va a escribir ese código fuente y qué errores cometerá ese individuo. Como no puede saberlo, cualquier estimación debe estar equivocada. Y a menudo equivocado el punto de engaño y por lo tanto inútil.

Si la estimación se redujo en un 500% y el proyecto aún avanzó, ¿qué valor tiene una estimación?

Ninguna. Todo lo que hizo fue hacer que la gente fuera infeliz. Pero el proyecto siguió adelante de todos modos.

Como nadie puede ver el futuro, obtener una estimación correcta no significa nada. Hazlo útil, ayuda a las personas a tomar decisiones.

Mantén el horizonte corto. Entregue valor lo más rápido posible. Cree un plan que permita al cliente cancelar el proyecto en cualquier momento y aún así tener valor.

No permita que el plan se convierta en la única "verdad sagrada" en el proyecto. La funcionalidad entregable es sagrada. Todo lo demás debería cambiar a medida que cambian los entregables.

No permita que el plan supere el valor que está creando.

Si no hay suficiente tiempo, no hay suficiente tiempo. No hay una solución mágica para terminar el proyecto de todos modos. En mi opinión, has hecho lo que podrías estar señalando. Resultó que tenían que averiguarlo por las malas. Así es como suele ser. Esperemos que el arquitecto y la gerencia hayan aprendido de sus errores y no lo vuelvan a hacer. Si esto es lo de siempre, cuando la gerencia es demasiado ignorante para escuchar sus argumentos y tomar las medidas apropiadas, entonces podría ser una buena idea buscar otros proyectos u otra compañía.

"Los desarrolladores son artesanos, y lo peor que puedes hacerle a un artesano es que le entregue un producto malo". Cita famosa de alguna parte, pero no recuerdo de dónde.

La honestidad siempre debe ser honrada. Estaba en el lado receptor de una "visión de arquitecto", y cuando el desarrollador se acercó a mí con la terrible noticia de que la solución completa no funcionaría, fuimos a las unidades de negocios y tuvimos una conversación horrible. Luego, el desarrollador presentó una nueva estimación que comprendía el 80% de la funcionalidad, pero entregó a tiempo y dentro del presupuesto.

Las unidades de negocios fueron conquistadas por el hecho de que el desarrollador les habló con sinceridad, reconoció las fallas de sus compañías y trabajó como un perro para entregar. Hemos tenido a este tipo trabajando para nosotros durante los últimos 7 años porque siempre fue honesto.

Todo el escenario es muy raro: la mayoría de las veces las unidades de negocios piensan que eres un idiota por no poder cumplir. Debe buscar aquellos clientes que no operan de esta manera, ya que a la larga ganará más con ellos de lo que trataría de complacer a los cretinos que solo quieren tratarlo como un idiota.

En lo que respecta a los arquitectos que no conocen su campo, evítelos como la peste. Tuve un mentor que solía reforzar conmigo de una manera dura: "Esto. No es. Para. ¡Práctica!" Él toleraría los errores solo si los cometió temprano, los corrigió y nunca los volvió a cometer. Las empresas que permiten a personas no técnicas e inexpertas en puestos con clientes porque pueden "comunicarse" merecen cerrar el negocio.

Una vez me enfrenté a esta situación. Un proyecto se agotó debido a que el negocio cambió el requisito y había una brecha de comunicación y la alta gerencia quería que el proyecto llegara a tiempo al proyecto. Para empeorar las cosas, un chico que estaba trabajando en este proyecto fue retirado para llenar otro vacío que tenía más prioridad.

Mi equipo pasaba noches para terminar el proyecto. Una noche, alrededor de las 3:00 a.m. de la mañana (estaba trabajando 19 horas seguidas) envié un correo electrónico a mis gerentes para que hicieran algo al respecto.

Al día siguiente tuvimos una reunión (solo los desarrolladores). Todo el equipo llegó un fin de semana y probó el proyecto incluso antes de que se completara. Pocos otros se unieron al equipo para hacer soluciones rápidas. Por fin pudimos entregar el proyecto con el esfuerzo de todo el equipo (no solo del equipo del proyecto). Seguimos el mismo proceso para otros proyectos.

Todo el equipo (incluso si no están involucrados en el proyecto) probó la aplicación y ayudó a solucionar rápidamente los errores.

Nota: Mi equipo consta de unas 25 personas que nuevamente tenían sub equipos trabajando en diferentes proyectos.

Mi único consejo sería "Hable con el gerente. Dígales con firmeza que el proyecto no se puede entregar a tiempo. También déles una alternativa. El gerente siempre espera que el bebé sea entregado a tiempo sin importar qué :)"

Si bien a las empresas no les gusta la verdad de que las cosas tardan mucho más de lo esperado, prefieren ser atadas aún menos. Cuanto antes le hagas saber a alguien cuánto tiempo realmente va a tomar, más rápido todos podrán planificar las circunstancias. Si bien esto puede ser inicialmente un momento difícil, a la larga será más fácil. Simplemente hazlo bien la segunda vez y crea contingencia.

Permítanme enfatizar un punto clave al tratar con su gerencia: los gerentes aprecian las soluciones.

Si tiene que acudir a su administración con un problema (por ejemplo, la estimación es muy poco realista), trabaje con anticipación para incluir alternativas sobre cómo abordar la situación. Por ejemplo, podría hacer un análisis de Pareto (la regla 80/20) para comprender el valor del sistema, podría presentar un caso prioritario para las funciones de corte (al menos desde una primera versión) para concentrarse en aquellas con el máximo valor comercial, podría buscar alternativas (proyectos de código abierto, etc.) que sean reemplazos adecuados para partes personalizadas del sistema, etc.

No hay duda de que una bolsa de cinco libras no contendrá veinticinco libras de arena, pero parte de ayudar a su gerencia a absorber su mensaje desagradable es ofrecer evidencia de que es un aliado comprometido.

Es posible que le interese este artículo de IEEE sobre el que he blogueado antes. Aquí están los aspectos más destacados.

• Uno de los principales impulsores del fracaso del proyecto son las estimaciones demasiado optimistas.
• Una de las principales razones por las que las estimaciones son demasiado bajas es la presión excesiva de la parte superior para entregarlas temprano.
• El otro es el desplazamiento del alcance durante la implementación sin volver a visitar las estimaciones.

En primer lugar, hablaría con el arquitecto en cuestión, de manera informal, y revisaría una lista de sus problemas con su estimación, y trataría de convencerlo de dónde están los problemas y la diferencia de tiempo que tomarían resolver.

Luego intentaría ir a su gerente de línea / gerente de proyecto y discutirlo con él / ellos.

Al final del día, el arquitecto dio ESTIMACIONES, por lo que están sujetas a cambios, y a veces en grandes cantidades, siempre que se den cuenta de ello, para que puedan hacer planes alternativos, como lanzar un producto en fases, reduciendo su funcionalidad u otros medios.

Al final del día, una vez que haya hecho lo anterior, ya no es su responsabilidad.

Definitivamente no debe ir directamente al cliente, o al jefe de arquitectos, esto solo promueve los malos sentimientos, y casi invariablemente obtendrá parte de la culpa.

Lo mejor que puede hacer es aprender de sus malas estimaciones (no las suyas personalmente, en este caso). Una cosa que debe aprender es que nunca permita que otra persona que no sea la persona que implementa las ideas calcule cuánto tiempo llevará. Las velocidades de los programadores pueden variar en un orden de magnitud, por lo que estimar a otra persona es casi imposible.

Siento tu dolor ... No estoy seguro de cómo manejar toda esta frustración :(

https://stackoverflow.com/questions/541873/developing-on-for-a-moving-target

En el pasado tuve que tratar con gerentes de proyecto que recortaron las estimaciones para cumplir con una cifra que el departamento de ventas pensó que el cliente pagaría. El gerente opinaba que era mejor pedir perdón que pedir permiso.

Es por eso que los desarrolladores han aprendido a rellenar sus estimaciones, porque saben que sus gerentes las cortarán. Entonces, si duplica la estimación y agrega un 30%, tiene una buena posibilidad de obtener un cronograma razonable.

Los clientes siempre quieren que sea más barato, y si acude a ellos con una estimación razonable, lo rechazarán y le exigirán que reduzca el costo o caminen. Pero, si sube demasiado, simplemente caminarán sin discusión ("Lo consideraremos y le responderemos").

Es un juego de expectativas manejadas.

El problema no era que las estimaciones originales estaban fuera, sino que la gerencia no te creía.

La mejor manera de lograr que la gerencia tome una decisión es:

1. Resuma el problema con evidencia que lo respalde; y
2. Proporcione múltiples soluciones para que puedan elegir (en orden de menos preferible a más preferible).

Para (1) implementar Scrum y rastrear datos reales contra las estimaciones dudosas funciona bien para respaldar sus reclamos.

Para (2) una de mis opciones sería "Desarrollar una lista de funciones priorizadas con el cliente (también conocido como Backlog del producto en términos de Scrum)". Esto sería complicado en organizaciones de precio fijo o altamente burocráticas, pero es posible .

¡Espero que ayude!

Yo (como estoy seguro de casi todos los que codifican) empatizo. Mi última compañía fue bastante terrible sobre esto: los vendedores vendrían y venderían un proyecto, y luego entrarías, verías las estimaciones y solo te reirías.

Como mencionó Tomh, solo hay tanto tiempo en un día. Incluso si no duermes.

Tres cosas, creo.

La mayoría de las veces solo tiene que gestionar las expectativas del cliente y ser transparente . Sea directo con lo que puede hacer y demuestre lo que ha hecho, todo. Esto es especialmente cierto si se le entregan requisitos que son demasiado gruesos (como mencionó Totophil). Si pueden ver la cantidad de trabajo que ha tenido que hacer, pueden ver cuán mala fue la estimación. Si ven productividad y progreso, eso es más importante que cualquier otra cosa en mi experiencia.

Creo que, además de gestionar las expectativas y ser transparente en su carga de trabajo, la otra gran cosa es la gestión del alcance . Hay una gran área entre ser anal / ofensivo en ser un alcance nazi y cubrir tu propio final. Cuando alguien quiera esta característica o funcionalidad adicional, ¡acéptelo! Y luego deles una estimación relativamente precisa de cuánto tiempo se agregará al proyecto (o al próximo lanzamiento). Lo bueno de esto no es solo no concentrarse en otras 80 horas a la semana, sino que también puede obtener algo de esa estimación para posiblemente ponerse al día con el otro.

¡Buena suerte!

Nunca tome nada sin verlo o entenderlo. Si el cliente, o su propio administrador no está dispuesto a pagarle tanto, no lo están preparando para tener éxito.

Esto fue (y a menudo es) un fracaso para comprender los detalles, los datos y cómo interactúan a lo largo de la aplicación que se está creando. Se hacen suposiciones en lugar de hacer preguntas, encontrar respuestas y aclararlo todo.

Una cosa que a menudo les digo a mis clientes es que si me van a colgar, al menos déjenme colgarme con mi propia cuerda o dispararme con mi propia pistola y balas, no con alguien más.

Tener una puerta giratoria de personas que intentan resolverlo será mucho peor al final para ellos.

La planificación poco realista y poco realista y la falta de previsión pueden ser señales de un problema de toda la organización, en cuyo caso es mejor que se acostumbre o siga adelante.

Primero, considere la posibilidad de que esté sobreestimando el alcance del proyecto. Los vendedores y arquitectos tienden a exagerar sus soluciones. No los tome al pie de la letra; probablemente esperan que se te ocurra menos de lo que prometieron al cliente.

Lo que haría aquí es tomar la cantidad de tiempo que tengo y gastarlo lo más sabiamente que pueda. Averigüe las prioridades del cliente y cumpla con ellas. Nueve de cada diez veces, el cliente estará feliz de que se hayan cumplido sus principales prioridades y pasará por alto el 80% del trabajo que no se ha realizado.

Lo último que quiere hacer es convocar reuniones de emergencia y acusar a las personas de ser malvadas. Tu dices:

"hazles saber la realidad"

¡pero la realidad es solo una opinión! Relájate, haz tu trabajo y gasta tu capital político en cosas que te importan . Como, promoción, más dinero, más vacaciones.

Su jefe intercambiando una promoción para usted trabajando muy duro en el cliente tiene sentido. Usted se vuelve loco en nombre de un cliente no.

Una cosa para recordar es que las estimaciones no incluyen el alcance del alcance o los retrasos inevitables (o problemas basados ​​en que el cliente no le dio lo que dijeron que harían, como un archivo de información en un formato particular).

Hemos aprendido a retrasar tanto la estimación como la fecha de vencimiento cada vez que sucede una de estas cosas. Agregue una nueva función, obtenga una nueva estimación y una nueva fecha de vencimiento. Si no proporciona la información necesaria en la fecha acordada, obtenga una nueva fecha de vencimiento. Proporcione la información pero hágalo incompleto o incorrecto o de cualquier otra forma que no sea la prometida, envíe una nueva estimación y fecha de vencimiento, cambie los requisitos de las características acordadas, obtenga una nueva estimación y fecha de vencimiento. Deje de trabajar en el proyecto porque el cliente quería que trabajara en una prioridad más alta, enviara una nueva fecha de vencimiento (y posiblemente una nueva estimación debido a que habrá tiempo de recuperación si el proyecto está en espera por mucho tiempo).

Si la estimación original provino de fuera del grupo de desarrollo y no se les consultó, entonces, cuando la obtenga, prepare una estimación propia (en un nivel detallado de todas las tareas que cree que tendrá, en un nivel mucho más alto de detalles que la estimación que le dieron) e inmediatamente proporcione la cadena y pregunte qué debe recortar para cumplir con la estimación que le dieron.

Si la respuesta es nada, insista en que se informe al cliente de la nueva estimación, ahora que hemos analizado el asunto con mayor profundidad. Si la gerencia aún insiste en que el cliente solo pagará X horas, pregúntele quién pagará el resto de las horas de desarrollo porque el trabajo que se le describe no puede hacerse por menos de lo estimado. Podría resultar que la compañía está dispuesta a recibir el golpe y pagar las horas ellos mismos.

Si no están dispuestos a sacarlo de sus ganancias y no le dicen al cliente que necesitan más horas y la compañía no respaldará las estimaciones detalladas del personal de desarrollo sobre las ventas ", creemos que el cliente buscará para ganar el proyecto ", estás en un proyecto de marcha de la muerte y tu mejor opción es salir lo antes posible. Puede señalar que el cliente estará más feliz sabiendo que el proyecto tomará más tiempo tan pronto como sea posible cuando pase las 50 horas que acordó pagar y ni siquiera está cerca de terminar con las 500 que realmente necesitaba. Recuérdeles que las estimaciones demasiado optimistas son uno de los mayores predictores de fallas del proyecto. No funcionará con este tipo de empresas, pero tal vez eventualmente se absorberá si lo repite suficientes veces.

También tendría en cuenta el refinamiento estimado. Quiero decir "como lo veo ahora, este proyecto tomará X horas hombre". Después del 20-30%, volveré a estimar y así sucesivamente.

Después de todo, ¿cómo hace una estimación un descargador de archivos? Lo refina constantemente.

Creo que no hay suficientes estimadores que no pongan suficiente énfasis en los hechos de "La estimación es que me estás pidiendo que haga cálculos matemáticos y adivinanzas para predecir el futuro de una manera útil" y "El compromiso que hacemos está completamente separado de los cálculos que hacemos para haga la estimación; Podemos aceptar hacer estúpidas cantidades de trabajo, aceptar cosas que vemos que probablemente no podemos terminar, pero ninguna de estas realmente cambia la matemática de la solución "y" Podemos hacer metodologías de desarrollo que no sean gigantes el lote de características A se realizará en la fecha B que hace que la falla sea mucho menos probable

Para muchas estimaciones se expresan en el lenguaje de la negociación. Deben expresarse en el lenguaje de las matemáticas y hablar sobre las incertidumbres de las matemáticas .

El estimador no puede hacer nada para que la realidad se doblegue a la voluntad de los empresarios que lo negocian. Su único trabajo es hacer que dejen de intentarlo.