project management - programacion - ¿Cómo maneja la programación/fechas límite alrededor de los programadores?

programacion android pdf 2018 (8)

¿A los programadores les gusta crear plazos? Soy un desarrollador web, y los horarios / plazos están por todas partes en mi campo. Pero he trabajado con algunos ingenieros / programadores de software que odian los plazos, ¿hay alguna forma de evitarlo?

Bueno, estoy bastante satisfecho con la fecha límite si esa fecha límite se ha determinado a través de un proceso de estimación bien pensado con la aportación de los gerentes y los ingenieros, y los requisitos para lo que se supone que se entregará en dicha fecha límite están bien definidos.

Creo que depende de cómo se crean los horarios. El desarrollador debe tener un papel importante en la elaboración del cronograma. De lo contrario, ¿cómo sabrá si es razonable o no?

Si alguien en la alta gerencia simplemente dicta que "La característica X debe ser hecha por Y" sin tener una buena idea de cuánto tiempo tomaría en realidad (algunas cosas son mucho más complicadas de implementar de lo que suenan) entonces eso es malo Cosa. Sin embargo, si trabajan con los desarrolladores para estimar la cantidad de esfuerzo realmente requerido y equilibrar eso con el resto de las necesidades de la compañía, entonces generalmente funciona bastante bien.

En primer lugar, debe distinguir entre plazos y estimaciones.

Los plazos vienen de fuentes externas, por ejemplo, "Feature X necesita estar listo para la feria".
Las estimaciones provienen de fuentes internas, por ejemplo, "La característica X tardará N semanas en completarse".

En general, los programadores deben crear estimaciones, y las ventas / marketing crearán plazos.

Los problemas ocurren cuando los dos no se pueden resolver, si la fecha límite es más cercana que la estimación.

Consejos útiles para el desarrollador (clientes potenciales):

Deje que la persona que hace el trabajo cree el presupuesto.
Asegúrese de que las estimaciones se basan en tareas pequeñas, cada una no más de un día o dos.
Use un ciclo de retroalimentación para que los desarrolladores mejoren sus habilidades de estimación.
Las habilidades de estimación precisas le permiten presionar con más fuerza contra las demandas de plazos.

Consejos útiles para los creadores de marketing / deadline:

No anule una estimación con una fecha límite.
Si una fecha límite entra en conflicto con una estimación, las únicas opciones reales son (a) los desarrolladores trabajan horas extras, (b) los requisitos para la fecha límite se recortan, o (c) la fecha límite se pierde.
Explique por qué la fecha límite es importante y cuál es el objetivo de la fecha límite (el "cliente X firmará un contrato de seis cifras").
Comprenda que las personas que sienten que no pueden cumplir con los plazos agresivos no estarán motivadas.

Las revisiones regulares son cruciales:

Enumerar los principales hitos y entregables
Divídalo en trozos más pequeños
Crear una colección de estimaciones más pequeñas
Haga los plazos razonables

Debe tener fechas límite, pero igualmente esos plazos deben ser realistas y mensurables. Mover las especificaciones va a molestar al desarrollador, puede ser inevitable, pero no tenga miedo de mover cosas (después de las discusiones).

Las fechas límite y las estimaciones de trabajo nunca serán particularmente precisas, pero las técnicas básicas de Gestión de proyectos deberían significar que las personas son conscientes de que las echan de menos y por qué sucedieron.

Los únicos ingenieros / desarrolladores de software que he conocido que odian los plazos se sienten así por una de estas dos razones:

Están completamente desorganizados, y saben que no cumplirán con la fecha límite, por lo que no les agradan porque cuando pierden la fecha límite los hace quedar mal.
No tienen problemas con los plazos, siempre y cuando alguien que entienda el trabajo involucrado establezca la fecha límite. Los peores plazos los hacen los gerentes que intentan vender un proyecto y dicen "¿3 semanas? ¡No hay problema!" y luego decirle a su equipo de desarrollo que tienen 3 semanas para producir una versión funcional de MS Office y recrear Internet para el niño pequeño del CEO.

Los desarrolladores deben participar en la creación de los plazos. Si son arbitrarios y se crean sin la participación de los desarrolladores, entonces tienen derecho a quejarse. Los proyectos legítimamente obtienen restricciones de tiempo de las empresas, pero los recursos y las características deben ajustarse para compensar. Esos ajustes no se pueden hacer sin la participación de los desarrolladores (sin mencionar BAs, QA y gente de operaciones).

Tradicionalmente solo puedes ajustar la calidad, las características o el tiempo, siendo la última la fecha límite. Calidad con la que realmente no quiere perder el tiempo. Entonces, mientras el proceso que está utilizando le permita calibrar las características para alcanzar los plazos, estoy bien.

¡Los programadores ODIAN las fechas límite por muy buenas razones!

Es casi imposible estimar con precisión cuánto tiempo tardará una pieza de código en diseñar, escribir y depurar hasta que lo haya hecho.

Desde mi experiencia personal, pasé más de una semana trabajando en un guión de shell "simple" que habría estimado en aproximadamente una hora. Por otro lado, tomó aproximadamente una semana escribir un analizador sintáctico para las definiciones de datos COBOL (incluyendo todos los INCREÍBLES COMP COMP-3 OCCURS redefinen el SYNC y los bytes slack) que había estimado en aproximadamente dos meses.

El otro gran problema es que, ante unos plazos ajustados, los programadores omiten las mejores prácticas y comienzan a piratear. De este modo, se ahorra aproximadamente el 50% del tiempo de codificación, pero se agrega un 300% al tiempo de prueba y depuración.