Son efectivas las estructuras jerarquizadas?

[haron]

Hasta ahora he trabajado en dos empresas.

En ambas empresas, las aplicaciones que desarrollamos estaban formadas por distintos formularios modales, cada uno de los cuales desempeñaba una funcion.

la estructura de trabajo en las dos empresas era la siguiente:

un jefe de equipo y tecnicos programadores a su cargo.

el jefe de equipo te suministraba la documentacion del formulario. esto es: como es visualmente, como se tiene que comportar y que es lo que tiene que hacer.

los tecnicos recogian la documentacion y unicamente se preguntaban como podrian hacer lo que les han pedido (por muy absurdo que pareciese).

LA PREGUNTA ES:

Es efectiva esta forma de trabajo?

en la cual existe un jefe de equipo que comunica a los tecnicos a su cargo que es lo que tienen que hacer y como deben hacerlo?

[[gatosoft]]

En mi empresa pasa lo mismo, pero he tenido la fortuna de conocer tres tipos de jerarquias diferentes en menos de 2 años (en la misma empresa).

1.) Teniamos un jefe que no tenia ni idea de Delphi ni de la BD que utilizabamos, aunque en el pasado habia desarrollado bastante software.

El se dedicaba al análisis y al diseño de un sistema mucho tiempo... decia que la programación no era muy importante. Pasamos mucho tiempo creando una estructura para un macro proyecto y paralelamente hacimos prototipos de software, por que segun el todavia no era tiempo de comenzar a construir... sin embargo, para nosotros (los desarrolladores), el tiempo iba corriendo en los cronogramas que se habian presentado a gerencia. (al final no se pudo cumplir con los cronogramas).

Aunque teniamos participacion en el diseño del proyecto, era el quien decidia la mayoria de las cosas, y este fué un gran error, por su gran desconocimiento de las posibilidades de Delphi (y POO) y de la BD. (PostgreSQL). Su manera de ver las cosas eran muy anticuadas.

2.) Despues de la salida de este jefe, uno de nosotros pasó a dirigir el equipo, y las cosas funcionaron de maravilla... eramos muchas personas aportando con igual autoridad y conocimiento al proyecto, practicamente no existia una jerarquia (al inetrior del departamento de desarrollo). y aunque esto solo duraria poco tiempo, adelantamos bastante en el proyecto.

3). Por ultimo, la direccion de la empresa, contrato a un jefe que no sabia nada de desarrollo de software (Tenia experiencia en manejo de personal...), y dejo abandonado el proyecto a la deriva, pues no podia aportar sencillamente nada. Lo unico que hizo fué asignar un módulo a cada miembro del grupo, fijar un cronograma y decir... nos vemos en 3,4 o 5 meses que durara la construcción....

============================

Conclusiónes:

1. La estructura jerarquica no sirve, si es una estructura simplemente burocratica, la organización de un proyecto de desarrollo debe ser natural, el o los que esten "arriba" debe ser por que tienen capacidad de liderazgo y algún (bien bueno) conocimiento técnico. No deben ser los mas duros en el manejo de las herramientas, pero deben conocerla lo suficiente para poder explotar sus posibilidades y estimar recursos.

2. El director debe decir que hacer (asi parezca imposible), y el programador es el que debe ofrecer las alternativas, presentar al director el "como" y el cuanto (recurso podria consumir). Para que el director decida.

3. Existe siempre uno o varios intermediarios entre el programador y el cliente. (directores, analistas, etc). Y esto es lo que en ocasiones nos confnde, pues desde el punto de vista del programador, estos intermediarios se convierten tambien en clientes.

[Viet]

Hola haron

Te voy a dar mi opinión.

A mi me ha tocado estar de los dos lados y cuando era el programador he tenido un jefe de muy amplio criterio y que sabia escuchar razones, y otro muy distinto que solo pensaba en fechas de entrega y cumplimiento de objetivos, sin medir las consecuencias de casi absolutamente nada.

Por lo general este tipo de personas ejercen presión sobre los empleados manteniendo la cascada de presión que reciben, sin dar ningún tipo de apoyo o defensa del personal que tienen a su cargo.

En mi parecer, un proyecto que tenga mas de una persona, SIEMPRE necesita un leader, aunque este sea en un momento uno y luego otro. Mas aun si pensamos en grupos de trabajo grandes de 8 o 20 personas.

Pero en realidad la tarea(o una de las tareas) del líder es distribuir de la manera mas eficiente el trabajo, motivar a sus empleados y por sobre todas las cosas buscar la comodidad de trabajo de los mismos. Estas ultimas razones se ven claramente por el papel de participación que uno le de a los empleados en el proyecto. Por eso es importante saber ESCUCHAR opiniones y sugerencias del que tiene que realizar la tarea.

Otra razón importante para tener un leader es que alguien se tiene que responsabilizar de los desvíos de un proyecto.

En fin es solo una opinión.

Saludos

[haron]

hola, viet.

tambien creo que al final acaban erigiendose lideres en un grupo de trabajo. pero esto ha de ser un proceso natural en el que el propio grupo de trabajo admita y valore la capacidad de liderazgo de uno o varios de sus compañeros.

quizas el problema viene cuando un 'jefe supremo' dispone sin pedir opinion a nadie a sus propios lideres.

otro problema que he visto es que algunas personas responsables de un equipo de trabajo confunder su trabajo con el de simplemente mandar (uno de los responsables que dispuso el jefe supremo).

quizas creen que por ser el responsable pueden decir a cualquier tecnico no solo lo que debe hacer sino como lo deben hacer y muchas veces (creo que la mayoria) el tecnico tiene mucho mas conocimiento de la herramienta que manejan que el propio responsable, por lo que su comportamiento entorpece su trabajo.

quizas otros responsables, en lugar de 'mandar ' lo que hacen es delegar responsabilidades.

creo que una de las funciones de un responsable es esta.