|
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.
|