24 febrero 2007

"Mejorando la planificacón y estimación de tiempos"

Quiero comentar el artículo de Manolo Álvarez "Técnicas de Gestión: Desarrollando un sentido de urgencia en el equipo (Parte 1 de 2)", que expone el podcast orignal "Develop a Sense of Urgency in Your Team (Part 1 of 2)".

Voy a elaborarlo referenciado algunos comentarios del artículo original que crean un balance en el punto de vista. Para una compresión clara, por favor lean los artículos referenciados arriba y las referencias a los comentarios de ManagerTools.

Pointy-Hired Boss
(Comentario en ManagerTools)

Si bien una empresa implementa por ejemplo controles de horario, cámaras de seguridad y métodos de presión es porque la gente entra y sale cuando quiere, hay ladrones en la empresa y los trabajadores no hace lo que deben cuando deben, respectivamente.

Por eso existen los 10 puntos para crear El Sentido de Urgencia
Pero la verdad es que en muchos casos (como lo dice el comentario referenciado) el gerente es un Pointy-Hired Boss (gerente ineficiente del cómic Dilbert).

En mi experiencia como desarrollador he visto mucho esto (con honrosas excepciones). El gerente generalmente solo se maneja con las fechas de entrega. En realidad no tiene una perspectiva clara del ámbito real del proyecto y mucho menos cuánto tiempo toma realizar una tarea determinada. Entonces el gerente tiene dos opciones:

  1. Pedir feedback del programador y que éste, basado en su experiencia sugiera una fecha.
  2. No confiar en la estimación del programador porque lo ha visto chateando (eso obviamente dañará la credibilidad de la estimación). Entonces viene la presión (métodos para crear el sentimiento de urgencia).

Sería ideal manejarse con la primera opción. Hay gente que opina que "si uno no confía en su gente, debería despedirla".

Por otro lado, sí es necesario crear ese sentimiento. Hay gente que trabaja mejor bajo presión y, en realidad, hay cosas que URGEN!

Es aquí donde el balance es la clave porque un exceso de presión puede atrofiar las relaciones laborales, la capacidad del trabajador o terminar creando un sentimiento de decepción. Esto último (la decepción) ocurre cuando, con el afan de crear ese sentimiento de urgencia los gerentes reducen instintivamente las fechas de entrega, los trabajadores entonces aunque sean unas máquinas (como dicen) no completarán nunca la meta deseada en el tiempo requerido. Tras aplicar muchas veces este método las relaciones se dañan y la autorealización del trabajador está por los suelos.


Trabajo en equipo, dependencias y un plan de proyecto realista
(Comentario en ManagerTools)
(Repuesta al comentario por Mark Horstman)

Aquí lo obvio reluce: el problema de muchas empresas (de Desarrollo de Software en especial) radica en la mala planificación del proyecto.

En nuestra empresa llevamos ya un tiempo utilizando SVN integrado con Wiki-TRAC para manejar los Milestones del proyecto y las tareas de la gente y es fabuloso. Sin embargo sin una planificación efectiva, no sirven de nada.

Entre las opciones

  1. Mirá ¿para cuando puede estar esto?
  2. Necesito esto para el martes.
  3. Ticket ya asignado al usuario X con la fecha de entrega implícita.

yo prefiero la tercera, siempre y cuando la fecha de entrega esté respaldada. Y esto precisamente es lo que nunca pasa: un gerente no sabe cuánto toma hacer una migración de datos, un sistema de análisis químico riguroso o agregarle una línea a un archivo de configuración. Los gerentes se olvidan del triángulo Funcionalidad-Recursos-Tiempo. Solo mueven el tiempo, no quieren sacrificar la funcionalidad ni agregar más gente.

Aquí los gerentes generales deben delegar la planificación (utópico: a veces no hay tiempo para planificar, todo es para ayer) a un experto, lo que llamamos el Project Manager.

Aún así el Project Manager promedio no hace un estudio riguroso del tiempo de cada tarea, simplemente la estima (basado en su experiencia, en la de otros o talvés en el sesgo creado por la presión del gerente – o cliente-).

Parece que vamos llegando al fondo de esto. A mi parecer, hay que reforzar mucho la creación de un cronograma confiable, que tome en cuenta posibles atrasos y que a la vez que cumple con las fechas del cliente, promueve la confianza y las buenas relaciones con los trabajadores.

¿Cómo hacer esto? La mejor respuesta es “Métricas del Software”. ¿Es posible medir el tiempo y el esfuerzo exacto que requerirá hacer un software?, ¿será como estimar el tiempo y esfuerzo de hacer un pastel? Pues para “Métricas del Software” es posible, y bastante exacto. He leido acerca de esto hace algún tiempo (libro del tema, revisen unos ejemplos). Lástima que en mis clases de Análisis de Sistemas y Desarrollo de Software nunca mencionaron esto :(, al igual que para muchos Project Managers y desarrolladores (y no lo digo yo, solo hay que ver para darse cuenta). De hecho nuestra cultura, nuestros planes de estudio, los métodos de desarrollo en las empresas y el profesionalismo de los docentes de universidades dejan mucho que desear.

En este punto yo concluyo que el balance es lo adecuado. Pero éste no se logra sin investigación, planificación, realismo. Si no se logra planificar adecuadamente, lo mejor es irse a un extremo.

Satanización del Desarrollador de Software
(Comentario en ManagerTools)

Por último, y en mi humilde opinión (respetando la experiencia y el análisis del autor) me parece un poco radical el artículo y las opiniones de Mark Horstman. Aunque tiene mucha razón en algunos puntos, creo que el tema (por lo menos en la empresa de Desarollo de Software) siempre será subjetivo hasta que haya un respaldo en la planificación del proyecto.

Ya se habló la primera parte de "cómo crear el sentimiento de urgencia"... me gustaría de verdad ver más temas como esté, por ejemplo "cómo consolidar a los empleados", "quality assurance in software development", etc....


Felicidades por abrir el tema Manolo. Aunque desde el punto de vista gerencial, es un debate sano que debería de tomarse para mejorar la calidad de las empresas de Guatemala. Gracias por dejarme comentarlo.

2 comentarios:

Anónimo dijo...

Me parece que, estimar el tiempo es básico para cualquier actividad. En el caso de asignar actividades a terceros, involucra factores importantísimos que algunas empresas, seguramente especulan: el talento-darle la herramienta a la persona indicada, disciplina-hacer que ésta lleve un ritmo adecuado si no lo tiene.

Y qué de los proyectos sorpresa, bien, falta de organización y tiempos adecuados por parte de la cabeza del proyecto. Lo curioso es que, en el caso de trabajar bajo presión, ésto también parece funcionar, es decir, cada cual trabaja a su propio ritmo y disciplina y no les va mal del todo. Del todo porque logran su objetivo, se entrega lo solicitado; absolutamente no es el mejor camino, porque se logra un solo objetivo pasando por encima de muchos otros, como comentaban... las relaciones laborales, no que deban pulirse, pero no deben descuidarse... asimismo la calidad de entrega de un proyecto, puede perjudicar a la empresa. Insisto entonces, no es el mejor camino, por lo que estoy de acuerdo con tu artículo.

me

Anónimo dijo...

Como decís David, faltan artículos de consolidación de empleados: por quedar bien con los clientes se estropea el capital humano de la empresa (frustración, roces, renuncias, etc.).
Soy programador de hace ratos y nunca me he topado con un Project Manager que no carezca de ese profesionalismo para calendarizar entregas. Básicamente el parámetro de referencia siempre es "para cuándo lo quiere el cliente" y rara vez se estudia si dá tiempo o si se necesita más gente.
Estoy de acuerdo, el tema es totalmente subjetivo porque aún no hemos tomado en serio la administración adecuada de un proyecto de software.