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
- Pedir feedback del programador y que éste, basado en su experiencia sugiera una fecha.
- 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).
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)
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
- Mirá ¿para cuando puede estar esto?
- Necesito esto para el martes.
- Ticket ya asignado al usuario X con la fecha de entrega implícita.
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.
Satanización del Desarrollador de Software
(Comentario en ManagerTools)
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:
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
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.
Publicar un comentario