project management - tiempo - ¿Cuál debería ser la penalización/respuesta por perder una fecha límite?

project management process groups (30)

He visto a ejecutivos dejar una empresa poco después de que se omitieron algunas fechas límite.Esto cambió todo pero no necesariamente hizo las cosas mejor o peor. He visto algunas obligaciones contractuales, como las reincorporaciones, como una forma de penalizar a alguien por perder una fecha límite que no estoy seguro de qué tan bien funcionan.
Cuando uno cambia por completo lo que se supone que debe hacer un proyecto a la mitad del tiempo asignado para el proyecto que tiende a causar que la trayectoria inicial ya no sea válida, el proyecto fracasará porque es probable que no cumpla con los plazos iniciales dentro de los presupuestos. Volver a planificar el proyecto en breves incrementos de unos pocos meses es una respuesta que creo que es una dirección lógica para llevar a cabo un proyecto y obtener buenos resultados ya que muchos proyectos pueden tener que cumplir requisitos cambiantes que pueden cambiar fácilmente los plazos, el recuento o tiempo trabajado

Al ser relativamente nuevo en la industria del software, me he encontrado con una cuestión de cumplimiento de plazos:

De vuelta en la era idílica de la academia, el plazo era el final del semestre y la pena era una ''F'' bien definida (o equivalente local). Aquí, en el mundo real, necesitamos crear un código con el que nuestros pares actuales y futuros puedan trabajar, me enfrento a la situación en la que llega el plazo, se cumple el plazo y el proyecto aún no está terminado.

¿Ahora que? En un extremo podríamos despedir a todos los involucrados, en el otro podríamos recompensar a todos los involucrados.

¿Qué acciones ha visto aplicadas como "penalización" por la fecha límite incumplida, y cuál de estas resultó en un código más bueno?
¿Qué respuestas de gestión de proyectos hicieron que el proyecto fallara por completo,
¿Qué respuestas restauraron la orden de trabajo y dieron como resultado un código que podría mantenerse después?
¿Qué respuestas dieron como resultado más código malo?

Aunque nunca he visto ninguna acción disciplinaria o despidos, he visto muchas horas extras "obligatorias" y la presión de los compañeros para trabajar más horas.

Casi me despiden como gerente por decirle al equipo que me informó que NO venga los fines de semana y trabaje hasta tarde. Sé que esas cosas son perjudiciales para el proyecto y para la moral.

En general, el "castigo" consiste en hacer que la gente se sienta culpable o ansiosa, pero estoy seguro de que hay lugares que hacen cosas más "oficiales".

El mundo está lleno de idiotas. La administración no es una excepción.

Ciertamente no es una respuesta abreviada. Aquí hay algunas cosas que peso y cosas que hago / animo para asegurarme de que las cosas se hagan a tiempo.

1.) Establecer las prioridades correctamente. Los proyectos siempre tendrán varios grados de finalización. No es un cambio binario "hecho" / "no hecho". Si las cosas de mayor prioridad se hacen primero, es más fácil de tragar. Idealmente, debe llegar rápidamente al punto donde funciona, pero no hace todo lo que necesitamos y no se ve bien. Una vez allí, puede liberarse si es necesario.

2.) He descubierto que la mejor manera de manejarlo es hacer que las versiones sean lo más pequeñas posible. Esto hace que las estimaciones sean más precisas. Si su jefe o "el mercado" dicta que su estimación es inaceptable, considere asignar más desarrolladores a esta tarea si es posible. A veces una tarea no se puede dividir fácilmente, o solo hay una persona familiarizada con el código. Si no es una alta prioridad solo dígale a los poderes que se va a tomar más tiempo. Establecer metas razonables y manejar las expectativas es la clave.

3.) En cuanto a la motivación, las recompensas y el castigo ... hay muchos médicos que han escrito libros completos sobre estos temas. En mi experiencia, dar a los programadores algo que sea desafiante y dejarles un poco de libertad para hacerlo a su manera es un buen comienzo. Escuchar es algo que los gerentes deben hacer bien para tener éxito. Si el desarrollador está experimentado, debería poder explicar el problema y dejar que el desarrollador presente la solución. Si su solución no es tan buena como la que tenía en mente, puede sugerirla e ir desde allí. Simplemente dictar cómo hacer algo, incluso para los nuevos programadores, rara vez es efectivo. Hacer que los desarrolladores piensen sobre las cosas les ayudará a ser capaces de resolver problemas por sí mismos. Esto está relacionado con la delegación, ya que solo funciona si los desarrolladores pueden hacer el trabajo por su cuenta.

4.) Reduzca el volumen de negocios pagando bien a las personas si lo están haciendo bien. Por lo general cuesta mucho más encontrar buenas personas. Lleva tiempo familiarizarse con una gran base de códigos y el proceso de contratación también puede ayudar a evitar perder tiempo con personas que no pueden cortar la mostaza.

5.) Pregunte (no exija) si un desarrollador puede quedarse hasta tarde / trabajar los fines de semana. Solo haga esto cuando sea algo muy crítico (por ejemplo, una falla de seguridad que le da acceso a los usuarios a datos a los que no deberían poder acceder, una nueva ley / regulación que debe cumplir, etc.). Si dicen que no, no lo retires contra ellos. Probablemente no es su culpa que las cosas no se hayan hecho; e incluso si lo es, es razonable que hayan hecho planes para el tiempo cuando no se espera que estén trabajando. Si están dispuestos a entrar, asegúrese de que conozcan su sincero agradecimiento. Compenalos bien por ayudar cuando no están obligados, comprar almuerzo no cuesta mucho y es un gesto muy agradable. No se acostumbre a esperar que las personas trabajen hasta tarde / fines de semana a menos que sea parte de su contacto / acuerdo (o si les gusta hacerlo).

6.) Comprender por qué las cosas se están ejecutando tarde. ¿Prometiste algo que no era posible (teniendo en cuenta las personas disponibles, la calidad esperada y el tiempo asignado)? ¿Apareció algún otro proyecto y tomó recursos y el plazo no se ajustó? ¿Fue el código simplemente más difícil de lo esperado? Dar tiempo estimado es difícil. Debe planificar todo, tener experiencia y saber cuánto tiempo tomará cada desarrollador para la tarea. Compense los problemas inesperados que probablemente surjan y otorgue al programador un plazo más breve que su jefe o el cliente. Siempre está bien hacerlo temprano. Y si casi siempre se hace temprano o a tiempo, la única vez que se perdió su fecha límite será más comprensible si tiene alguna explicación de algún tipo.

7.) Recuerde, generalmente se reduce a tiempo, calidad y dinero. En general, puede elegir dos, pero el tercero deberá equilibrar la ecuación. Por lo tanto, si debe hacerse rápidamente y con un presupuesto reducido, puede esperar que la calidad sufra. Si lo necesita de manera rápida y de alta calidad, espere pagar mucho dinero, y así sucesivamente.

8.) Diría que lo # 1 que funciona para mí es escuchar. Si sus órdenes de ladrido están demasiado ocupadas, es posible que ni siquiera sepa de problemas con la compañía. Ahora, simplemente porque un desarrollador dice "el código apesta, el diseño es terrible y tenemos que volver a escribir todo si queremos hacer algo de manera oportuna" no significa que vaya a suceder. Pero si oye comentarios como ese y explica que no podemos permitirnos hacer esto o que nos maten en el mercado, sería demasiado caro. Y pregunte qué se puede hacer para asegurarse de que las cosas no empeoren. Pregunte si hay una manera de que podamos limpiarlo con el tiempo. ¿Podemos (re) escribir una clase y construir cosas nuevas basadas en eso? ¿Podemos migrar lentamente a un nuevo diseño de una función / segmento / módulo a la vez? Entiende de dónde vienen y viceversa, probablemente pueda resolver al menos algunos de los problemas. Solo recuerda que comprometer funciona en ambos sentidos.

9.) La reactivación negativa parece dar como resultado una mayor rotación, lo cual es costoso. Tener un grupo de personas que no estén familiarizadas con tu código tampoco ayuda con los plazos. El dinero es un motivador, pero renuncié a un trabajo mejor remunerado para ir a uno donde estoy más feliz antes, y sé que no estoy solo allí. La comida gratis cuando el equipo hace un buen trabajo no es tan caro. No estoy muy interesado en las actividades grupales ya que reducen el tiempo de los empleados o les quitan tiempo de trabajo. A veces funciona, pero reducir el tiempo personal de los empleados para que puedan pasar el rato con sus compañeros de trabajo en lugar de estar con sus amigos no es una gran recompensa. Hacer que todos dejen de trabajar también es costoso ... así que depende del tamaño de la empresa, cultura, etc.

Espero que eso ayude a responder tu pregunta. Las otras respuestas en este hilo también son buenas sugerencias ... el diseño juega un papel importante en la rapidez con la que se escribirá el código.

Como han mencionado otros, antes de hablar sobre las sanciones, comience con "¿cómo determinamos si estos plazos son realistas"?

O como mi jefe dijo una vez: "Nos complacerá trabajar en un plan cuando nos dé un plan que funcione" .

Sigo pensando que debería estar en una camiseta.

Creo que la pregunta en sí misma demuestra una mala comprensión del papel de la gestión y la gestión de proyectos.

Desafortunadamente, hay una percepción común en la mente de muchos con la palabra Manager en su título de que la gestión significa poner la curación a las manos de los trabajadores perezosos. Encaja con aquellos que creen en la Ley de Parkinson también.

No es. Se trata de hacer posible que las obras hagan su trabajo, ya sea el canal de comunicación entre ellas y otra parte de la organización, consiguiendo recursos o interfiriendo (quitando los muebles del camino).

A saber, el PM ya debe saber que el proyecto / tarea va a perder su fecha límite. Deberían hacer preguntas y saber qué está pasando. Tienen el poder de cortar tareas o aumentar / reequilibrar los recursos para hacer el trabajo (o decirle al patrocinador, si no le das los recursos, no se hace a tiempo). Y como tal, la pena va al PM, ya sea que se trate de nada, azote de la lengua, degradación o terminación.

Algunas veces la demora es inevitable. Es por eso que construimos en tiempo de contingencia. A veces, es un riesgo conocido; y siempre que tengas un plan de respaldo, estás bien.

En cuanto a las respuestas, tiene cuatro parámetros: alcance, tiempo, dinero y calidad

Alcance: puede cortar para cumplir el plazo.
Tiempo - es fijo. Es posible que pueda lograr que su personal se retire una semana o dos a las 60 horas, pero su productividad comenzará a empeorar después de eso. Y también cuesta más dinero si los paga de manera justa.
Dinero: puede comprar piezas de otra persona para acelerar el proceso. Incluso podría contratar a más personas, si el trabajo es tan desarticulado que no es necesario que tenga mucha comunicación con el personal existente; consulte la Ley de Brook.
Calidad: los tontos idealistas afirman que nunca se puede escatimar en calidad. Pero puedes. No tiene errores añadidos (una forma de anti-calidad); pero puedes poner menos calidad. ¿Codificas tu función para que pueda manejar cadenas de longitud ilimitada o hay 100 caracteres lo suficientemente buenos para esta versión? ¿Le facilita a la próxima actualización atornillar un nuevo módulo, o lo suelda con autógena y se preocupa por agregar un módulo de complemento cuando realiza la próxima versión?

No hacer estas cosas con la suficiente agresividad (cuando sea necesario) seguramente te llevará a un fracaso.

Depende de si la fecha límite fue posible en primer lugar, tal vez fue un error con la planificación y la estimación de cuánto tiempo hubiera llevado. Asegúrese de saber por qué no se cumplió el plazo antes de decidir el castigo

Depende de si los desarrolladores establecen los plazos en cada solicitud de modificación, o si la administración los ha establecido.

En este último caso, a menos que todos sus desarrolladores estén sentados y jueguen Halo 3 todo el día, una fecha límite incumplida es a menudo un indicativo de un error del equipo directivo o del equipo. Entonces dispararles a todos no resolvería el problema. Puede tener sentido introducir mejores indicadores en su proceso de software para que pueda ver que la fecha límite se perderá mucho antes de que suceda.

Si sus desarrolladores dan estimaciones de tiempo, entonces sería muy cuidadoso al recompensar y penalizar a los desarrolladores por cumplir con los plazos o por perderlos. El resultado de hacer esto podría ser que ajustarían su "factor de dulce de azúcar" en la estimación del tiempo. Se darían demasiado tiempo extra (para cosechar las recompensas), lo que estropea las cosas si son buenas para la estimación. Su objetivo debe ser lograr que brinden estimaciones buenas y confiables, no cambiar la forma en que trabajan para cumplir con estas estimaciones.

En lugar de una sanción, ¿qué hay de las estimaciones realistas y las entregas puntuales gratificantes?

Inspirado por los comentarios a mi respuesta

Tal vez la pregunta debería ser "¿Cómo hago estimaciones realistas?" Para mí, utilizo el historial de estimación de FogBugz y los diagramas de fecha de finalización . Estos me dan datos sobre cuánto tiempo estimé que tomaría una tarea y cuánto tiempo tardó realmente. Esto me ha ayudado a dar fechas de lanzamiento realistas a largo plazo (no sucedió de la noche a la mañana). Me parece que estimar las líneas de tiempo es un proceso interativo:

diseño
estimar
desarrollar
encontrar un déficit en el diseño e iterar.

En su maravilloso libro sobre gestión de proyectos - "Deadline" - Tom DeMarco nos cuenta una historia sobre el gerente de proyectos de un mundo occidental que está dirigiendo un proyecto en algún país ficticio postcomunista de Europa del Este (salvaje es un término realmente bueno, porque los ciudadanos son un poco ... incivilizados).
Un día PM descubre que algo salió mal, una parte de su proyecto se perdió dramáticamente el horario poco realista. Previo PM estableció una multa por falta de fecha límite simplemente colgando a la persona responsable en un gancho de carnicero, pero como los horarios no eran realistas, un hombre ya había perdido la fecha límite.
Entonces, la historia nos cuenta acerca de un día en que un PM de estilo occidental es presentado con una persona responsable, y él debe enviarlo a colgar en el gancho del carnicero. PM, como a la mayoría de las personas, le aterroriza la visión de sentenciar a alguien a muerte cruel simplemente porque algunos nunca pudieron terminar su proyecto a tiempo. Y, por supuesto, ahorcar a este pobre hombre no hace avanzar el proyecto. Como se trata de una novela de ficción sobre gestión de proyectos, y no sobre torturas, nuestro héroe cancela la pena.
Pero hay una gran cuestión detrás de esta historia sobre ahorcar a alguien: si establece una fecha límite y establece algún tipo de penalidad por no cumplir este plazo, llegará el día en que probablemente tendrá que castigar a alguien. ¿Y lo harás? No importa cuál sea el castigo: ahorcamiento, pérdida de bonificación, despido, ruptura del trato o alguna tarifa: es posible que tengas que castigar a alguien. ¿Esta penalización servirá para tu proyecto? Tienes que responderlo por ti mismo.
Entonces: no establezca una penalización por perder la fecha límite, no querrá ejecutar ...

Hasta ahora en mi carrera no he visto ninguna penalización real por perder una fecha límite (y me he perdido mucho). Imagino que es diferente para las compañías que crean software o juegos vender en las tiendas donde la compañía ha hecho promesas al público.

Pero en el ámbito del desarrollo de software personalizado, es tan difícil estimar con precisión cuánto tiempo llevará un proyecto. Y muchas veces este hecho es aceptado a regañadientes por las empresas de todo el mundo.

Hay dos posibilidades:

La fecha límite se perdió porque alguien no hizo su trabajo.
La fecha límite no fue realista.

En lugar de pensar en términos de sanciones, sugeriría hacer una autopsia para determinar qué salió mal y encontrar formas de mejorar la próxima estimación del plazo.

Los plazos son parte de una idea fundamentalmente errónea sobre cómo hacer un desarrollo de software. Las personas nuevas o ajenas a la industria del desarrollo de software no entienden esto:

El software está hecho cuando está hecho, ni antes ni después.

Si un desarrollador tiene una tarea y una semana para hacerlo, y parece que llevará más de una semana, no se puede hacer nada para cambiar eso. No importa cuánto más duro trabaje el desarrollador, sin importar cuántas personas se agreguen a la tarea, aún tomará tanto tiempo como sea necesario (de hecho, agregar personas generalmente lo hace tomar más tiempo).

En cambio, lea sobre el proceso de desarrollo ágil. El software debe desarrollarse de manera iterativa, y cada iteración debe basarse en los resultados de la iteración anterior, no en los requisitos externos impuestos.

Edición basada en los extensos comentarios a continuación:

Yo nunca diría que los desarrolladores no pueden esperar a algún tipo de expectativa de entrega. Mi punto es en respuesta a la hipótesis específica que planteó el autor de la pregunta: que la naturaleza del desarrollo de software en los negocios es de alguna manera análoga a la tarea escolar, o cualquier otro tipo de trabajo para el caso. Yo sostengo que definitivamente no lo es. La "fecha límite" implica mucho más que una simple fecha de entrega. Es un punto fijo por el cual se debe completar una cantidad fija de trabajo. El software simplemente no funciona de esa manera. Escribí algunos párrafos más para explicar por qué, pero sinceramente, si todavía no lo crees, nada de lo que diga te va a convencer.

Si está trabajando en un proyecto de software y está claro que no podrá alcanzar su fecha límite, ¿qué puede hacer para rectificar eso? La respuesta es conocida ahora: prácticamente nada. No puedes agregar más personas No puedes "trabajar más rápido". Simplemente no se va a hacer a tiempo. Usted le dice a los interesados, todos se ajustan y siguen trabajando (o no). ¿Qué significaba entonces la fecha original?

Cualquier persona que afirme que el desarrollo de software es análogo a la construcción de puentes o tareas o que los plazos inminentes aún se pueden cumplir si los desarrolladores se juntan y trabajan duro, están profundamente confundidos acerca de su propia profesión.

Muerte. Limpio y simple.

Ninguna penalización. Las "fechas límites" y las estimaciones han sido y continúan siendo una de las partes más difíciles y desafiantes del desarrollo de software.

Es ridículo imponer sanciones a los desarrolladores por este problema.

Oh hombre...

En primer lugar, existen plazos externos y plazos internos, y deberían ser diferentes.

Lo que ocurre con una fecha límite interna es que la frecuencia de la actividad aumenta a medida que se acerca la fecha límite, alcanza un pico en la fecha límite y luego desaparece a medida que la fecha límite se aleja. Así que planifique la fecha límite externa para cumplir con la fecha límite interna por un par de semanas como mínimo.

Luego, asegúrese de que los plazos sean realistas. En parte, puedes hacer eso al involucrar a los desarrolladores en su configuración y al decidir qué se logrará.

Finalmente, he sido en su mayoría un desarrollador, pero una vez que apuñalé a la gerencia, nunca me gustaría llevar la versión más reciente a una conferencia o presentación. Me gustaría tomar una versión que tenía al menos unas semanas y saber dónde estaban los problemas y que podría estar seguro de que no contendría sorpresas desagradables.

Si te estás perdiendo tus fechas límite, corrige tus estimaciones.

Su primera reacción no debería ser qué hacer en respuesta a la fecha límite incumplida, sino analizar por qué se perdió la fecha límite. La respuesta a perder la fecha límite se derivaría naturalmente de eso como consecuencia de la razón.

Por ejemplo, si todos los involucrados no hicieron su trabajo, despídalos.

Pero si hacían su trabajo, y más, ¿por qué todavía se echaba de menos? Demasiadas otras actividades hechas por la misma gente? Alcance demasiado grande para la fecha límite (es decir, fecha límite poco realista). O ... etc.

La razón principal por la que me falta un plazo en mi experiencia es que las personas no pueden trabajar al 100% en el proyecto en cuestión, y por lo tanto, cualquier cálculo que pueda tener, aunque sea preciso por sí solo, no es realmente útil en absoluto. Eso, además de estimaciones y plazos poco realistas.

Tomado desde un punto de vista de desarrollo corporativo ...

Si la fecha límite vino de alguien que no sea la persona que realiza el trabajo, revise la situación para determinar la causa del desbordamiento. En estos casos, a menudo se relaciona con requisitos incompletos, fluencia del alcance, mala gestión, etc. No se debe imponer un castigo por no cumplir un plazo que la persona nunca proporcionó en primer lugar.

Si la persona que realiza el trabajo proporcionó o acordó la fecha límite, esa persona debe explicar los factores que llevaron a la demora. Además, debe recordarse a esta persona que notifique a su supervisor, gerente de proyecto u otra parte responsable tan pronto como tenga conocimiento de que se puede perder una fecha límite. Esta información no debería salir a la luz después de que haya vencido el plazo. Si esto ocurre repetidamente, se debe seguir el proceso disciplinario de su compañía. Esto puede involucrar redacciones, suspensiones o finalización.

Las personas tienden a tomar la propiedad real de los plazos cuando son los que los establecen. Cuando los plazos se colocan en ellos sin su entrada, los plazos tienden a ser insignificantes para la persona que realiza el trabajo.

Una vez que haya llegado al punto en el que la gente ha incumplido el plazo, debe preguntarse (A) cuáles son las consecuencias naturales de eso y (B) cómo puede completar mejor la tarea y mantener algún tipo de movimiento hacia la empresa. objetivos (incluso si no tiene un negocio).

Es improbable que penalizar explícitamente a las personas por soplar la fecha límite ayude a menos que crean que se lo han ganado. Esto no sucederá si la fecha límite no fue realista, si hubo elementos del equipo que fueron los principales puntos de falla, si hubo problemas serios con los requisitos, o si la mayoría del equipo involucrado cree que los factores anteriores son ciertos.

En un caso, yo estaba en un equipo que venció la fecha límite de un pequeño producto por más de tres meses, ¡y la fecha límite original para el envío era de tres meses desde el comienzo! No entendimos los requisitos, no hablamos lo suficiente con el cliente y subestimamos el tiempo involucrado. La gerencia no estaba para nada interesada en asignar la culpa. Esto se debió en parte a que hubiera sido contraproducente terminar el producto, en parte porque ninguno de nosotros era un "empleado problemático", y en parte porque la gerencia sabía que todos estábamos muy motivados para solucionar el problema y satisfacer al cliente. Así que lo hicimos, el cliente estaba tan feliz como se podía esperar, y seguimos adelante con nuestras vidas, con algunas lecciones valiosas sobre cómo evitar la situación en el futuro.

Una vez que un proyecto llega tarde, no hay mucha "gestión" (buena, mala, bien intencionada o maliciosa) que pueda hacer, que no dará como resultado que el proyecto sea más tarde.

... la única excepción posiblemente sea la eliminación / evitación de distracciones exteriores.

Usted pregunta "¿cuál debería ser la penalización ...". Parece que está preguntando desde la perspectiva de "dentro de la empresa".

En la vida real, las sanciones son a menudo rápidas y severas: pérdida de negocios, demandas judiciales, mala reputación en la industria. Estas son las penalidades REALES impuestas por clientes a quienes se les prometió algo en una fecha determinada que no se cumplió.

Internamente, a menudo puedes hacer lo que quieras. Pero una vez que empiezas a involucrar a los clientes que pagan, la administración de esos clientes se convierte en una parte fundamental del trabajo en general.

Las sanciones como las que describí a menudo se pueden evitar (o reducir) mediante la comunicación "en la parte superior" con el cliente. Si el cliente desea que se agregue algo (lo que se conoce como fluencia de características), se debe responder de inmediato con el impacto que estos cambios tendrán en el proyecto (cuesta más, se entrega más tarde, lo que sea). Se debe alentar al cliente a que clasifique todas las solicitudes en función de los plazos y los costos proyectados (es decir, deje que el cliente administre el rastreo de características, no usted).

Si otras cosas cambian el tiempo de entrega, tan pronto como sepa que habrá un deslizamiento, debe informar al cliente. Si se hace temprano, los clientes están notablemente dispuestos a trabajar con usted. Pero si no dices nada hasta que sea demasiado tarde, es menos probable que lo perdonen ... especialmente si descubren que sabías mucho tiempo antes y no se lo dijiste.

Aclamaciones,

-Ricardo

¿Cuál debería ser la penalización para establecer un plazo de desarrollo irrealmente corto frente a todos los consejos de los desarrolladores y sus clientes potenciales?

Casualmente, esto parece ocurrir casi tan a menudo como los equipos de desarrollo pierden fechas de envío.

Flogging

Los desarrolladores nunca deberían ser penalizados por los errores de la Administración.

Es como si un padre castigara a un niño porque el padre tuvo un mal día.

Razonamiento:

Las fechas límite son un hecho de la vida. La gente quiere saber cuánto tiempo llevará algo. Lo mejor que podemos hacer es estimar / adivinar. El papel de la gerencia es tratar de resolver esta conjetura mágica, nunca correcta. Cuando crean una fecha límite, necesitan usar las herramientas correctas (experiencia, PEDIR AYUDA A LOS DESARROLLADORES, abogados, hora, etc.)

Sin embargo....

La pena por no cumplir un plazo no debe recaer sobre los trabajadores. Es culpa de la gerencia por la falta de fechas límite. Deberían haber dicho que no, deberían haber reducido el proyecto o deberían haber motivado mejor a los trabajadores.

En un equipo de construcción, si orinas a los trabajadores, comienzas una pelea. En mi compañía, si pasamos por alto los plazos, la administración se mete en problemas. No los trabajadores. El trabajo del gerente es controlar el proyecto y lo que se hace. Los trabajadores solo hacen lo que pueden. Los gerentes están a cargo de asignar roles y tareas.

No digo que la calidad de los trabajadores no sea un factor, ¡pero la gerencia debe SABER eso! No hace falta ser un genio para saber que un proyecto no está bien pensado o bien controlado. Pregúntele a alguien si su gerente tiene alguna idea de lo que está pasando y encontrará el problema.

Dejamos de perder tantas fechas límite cuando los gerentes se dieron cuenta de que era su culpa establecer / aceptar los plazos.

</rant>

Re: Las preguntas:

1. ¿Qué acciones ha visto aplicadas como "penalización" por la fecha límite incumplida, y cuáles de ellas realmente hicieron las cosas "mejores"?

El gerente tiene menos responsabilidad. Esta persona no recibe ascensos ni agradecimientos públicos. Lo más probable es que esta persona sea trasladada a un proyecto "menos crítico".

2. ¿Qué respuestas de gestión de proyectos provocaron que el proyecto fallara completamente, y qué respuestas restauraron la orden de trabajo y dieron como resultado un código que podría mantenerse después?

función de arrastramiento: el administrador sigue agregando más cosas en la lista. <- luchar contra esto con una lista de tareas ordenadas por prioridad. Cuando agrega cosas a la lista, compare su prioridad con las cosas que le rodean. Haga las cosas nuevas más difíciles de configurar como "máxima prioridad".
demasiados errores en el código: el administrador debe exigir pruebas (al menos crítico) y automatización. Las compilaciones deben ser estándar y automáticas. Los usuarios reales necesitan ver el código antes de que esté "terminado".
código no legible: revisiones del código de pares del instituto. Si alguien tiene un código sucio, pídale a alguien que lo "ayude" con un proyecto.
Si tiene el problema del vendedor, donde el vendedor promete funciones que no existen / funcionan: la administración debe intervenir y explicar el problema a ese vendedor. Además, a veces esto no ayuda a la afirmación pública del vendedor por un trabajo bien hecho.

Su pregunta es inherentemente defectuosa : asume que el castigo es la mejor forma de manejar a las personas. En general, las personas no responden bien al castigo o amenazas de castigo; saca a relucir los peores comportamientos, hace que la motivación sea externa y distrae de la motivación interna. Las recompensas y sobornos (amenazas de recompensa) son la otra cara de la misma moneda, y no lo hacen mejor.

Sin embargo, estas fuerzas están incorporadas para trabajar por contrato, por lo que nunca obtendrás el mejor trabajo creativo de tus programadores, pero no tienes que empeorar castigándolos cuando pierden una fecha límite.

En su lugar, medite en el proceso creativo, en el caos de varias personas que realizan trabajos creativos y en las herramientas eficaces para manejar el caos.

Para administrar cualquier sistema caótico, haga muchas mediciones y esté preparado para cambiar de rumbo rápidamente. En el caso de la programación:

Tome los pasos más pequeños posibles. No "divida la tarea en pequeños pasos", ya que perderá mucho tiempo planificando los pasos que no funcionarán como planeó. Caos, ¿recuerdas?
Elija los pasos más pequeños que ofrecen el mayor valor .
después de un corto período de tiempo, reevaluar su plan de acuerdo con lo que ha aprendido
Entregue el software en funcionamiento a clientes reales y reales lo antes posible, para que puedan decirle lo que realmente debería estar haciendo.

Puede reconocer esto como el pensamiento detrás de SCRUM.

Dos preguntas obvias vienen a la mente cuando faltaba una fecha límite:

¿Fue la fecha límite factible?
¿Los factores externos afectaron el rendimiento?

Obviamente, si alguien le presenta una fecha límite que no tiene sentido, entonces no debería haber ninguna penalización por perder la fecha límite. Además, si alguien pierde una fecha límite debido a que fueron llamados a un servicio de jurado, tampoco deberían ser retenidos contra ellos.

En el caso de que esas preguntas no se apliquen, lo siguiente es averiguar qué salió mal. Si basa su estimación de cuánto tiempo tomaría algo, y por lo tanto la fecha límite, en la estimación de los desarrolladores de cuánto tiempo les tomaría escribir el código, entonces tal vez fueron demasiado optimistas en sus respuestas.

Esta no es realmente una pregunta de programación, sino más una cuestión de gestión.

Las fechas límite perdidas rara vez son culpa del desarrollador. Como desarrollador, debes hacer tu mejor esfuerzo para hacer el mejor trabajo posible, pero al final todos son capaces de hacer tanto. Si los desarrolladores hicieron un esfuerzo honesto y, a pesar de esto, se perdió la fecha límite, significa que el plazo no era realista para empezar.

Tratar con los plazos es responsabilidad de los gerentes. Existen diferentes enfoques, pero ninguno de ellos incluye "penalizar" a los desarrolladores por hacer su trabajo. Algo importante de entender aquí es el llamado triangle gestión de proyectos . Lo que significa es que el proyecto de software puede ser bueno (es decir, cumplir los requisitos, buena calidad), rápido (cumplir los plazos) y económico (recuentos, herramientas). El problema es que solo 2 de estas 3 propiedades pueden ser elegidas.

Entonces, si la gerencia quiere algo bueno y rápido, no va a ser barato.

Si la gerencia quiere algo bueno y barato, no será rápido.

Y, por último, si la gerencia quiere barato y rápido, adivina qué, no será bueno.

Entonces, la respuesta correcta a la fecha límite no cumplida depende del escenario elegido. Lo bueno y rápido requiere agregar algo de ayuda adicional, mejores herramientas, inversión en desarrolladores superiores a la media y más.

Por definición, lo bueno y lo barato supone que los plazos se van a perder (Blizzard, los creadores de World Of Warcraft son un buen ejemplo de este enfoque).

Y finalmente, barato y rápido generalmente significa cortar características y liberar errores.

El objetivo principal de la gestión de proyectos es planificar cómo se va a construir una aplicación, a tiempo. No debe comenzar el desarrollo de su proyecto si no tiene un cronograma que muestre lo que va a hacer cada día que dure el proyecto.

De esta forma, puedes detectar que llegarás tarde, siempre y cuando sigas la evolución del proyecto de manera regular (semanal si no diaria). Y cuanto antes lo sepas, antes podrás actuar en consecuencia.

Por lo general, tiene dos opciones:

Ponerse al día (al contratar trabajadores adicionales, trabajar más o eliminar funciones).
Dígale a su cliente que algo salió mal (incluso mejor: qué salió mal ) y que va a necesitar más tiempo.

Para la segunda opción, no estoy diciendo que nunca habrá penalizaciones. Pero desde mi experiencia personal, siempre y cuando el cliente esté informado con antelación y se le ofrezcan soluciones (preferiblemente tres: dar más dinero para trabajadores adicionales / eliminar funciones para ahorrar algo de tiempo / aceptar que el proyecto se retrase), estarán abiertos a la negociación . Lo cual siempre es mejor que los conflictos :)

Me despidieron por perderme una fecha límite, el 98% había terminado con el producto, las fuerzas externas y las fechas límite que son firmes no permiten que el software se desarrolle correctamente. Incluso puedo admitir que escribí un código pobre bajo las circunstancias, pero también escribí un buen código de mantenimiento. No se tuvo en cuenta el deslizamiento de características, de hecho, no se detallaron por adelantado las especificaciones técnicas y se requirió la adaptación de la funcionalidad, ya que las versiones limitadas y defectuosas del software estuvieron disponibles para la revisión de la administración. Pude haberme comunicado mejor, pero cuando lo comuniqué, se hizo hincapié en que los plazos no son negociables.

Quizás la mejor pregunta es si los plazos son significativos frente a estimaciones inexactas. Las empresas hacen un pésimo trabajo de estimación de software, eso es un hecho. Tanto la gerencia como los desarrolladores juegan un papel en esto y ninguno de los dos parece estar dispuesto a asumir su responsabilidad en este problema.

Pero para responder a sus preguntas específicas:

1. ¿Qué acciones ha visto aplicadas como "penalización" por la fecha límite incumplida, y cuál de ellas resultó finalmente en un código más bueno?

La ''penalización'' que he visto por las fechas límite incumplidas para gerentes y desarrolladores varía desde nada, a promoción, a transferencia simple. Las sanciones más severas que presencié personalmente fueron que un gerente "se transfirió" a un proyecto menos importante y que la unidad comercial perdió un bono financiero.

La única vez que vi despedir a alguien por una fecha límite incumplida fue cuando el empleado ya iba a ser despedido; la fecha límite le dio a la empresa una razón legal para despedir al empleado.

2. ¿Qué respuestas de gestión de proyectos hicieron que el proyecto fallara por completo?

Esta es una discusión separada por sí misma ... pero hay un sesgo inherente en esta pregunta: la gestión del proyecto tiene la culpa .

Las tres cosas principales que personalmente he visto son las de los PM que sabotean un proyecto (por orden de gravedad):

Ignorar datos / recomendaciones / advertencias de su personal técnico.
Solicite estimaciones al principio del proceso de desarrollo. Esto da como resultado estimaciones con una barra de error de 10x (tardará un mes, más o menos diez meses).
Rechace / modifique / solicite estimaciones de software para que se ajusten a un presupuesto y un programa arbitrarios. Esto no significa que los Desarrolladores deban ignorar las demandas del negocio, sino que las demandas del negocio deben establecerse por igual tanto los Desarrolladores como los No Desarrolladores.

3. ¿Qué respuestas restauraron la orden de trabajo y dieron como resultado un código que podría mantenerse después?

Aún no he visto una organización de desarrollo de software funcional. Así que la solución suele ser mucha sangre, sudor y lágrimas de un par de desarrolladores heroicos que trabajan con un PM altamente capacitado que sabe cómo defenderse de la política dentro de la empresa (es decir, desviar BS de su personal).

4. ¿Qué respuestas dieron como resultado más código incorrecto?

Gritante. MaldiciendoInsultos (Lamentablemente, esto todavía sucede en algunos lugares de trabajo)
Más "gestión de proyectos", ya sea a través de personas, reuniones o informes de estado.
Obteniendo estimaciones de software más temprano en el proceso para que "podamos planificar mejor". Las estimaciones deben llegar más tarde cuando su personal tenga más datos y una mejor comprensión del problema.
Cocine a los desarrolladores (no es tu culpa, el gerente la fastidió).
Codificando a los gerentes de proyecto (no es tu culpa, los desarrolladores se equivocaron).
Agregar personal adicional no calificado al proyecto.