He estado trabajando en el campo de TI desde los últimos 12,5 años, y he pasado por ambos extremos. Trabajé en proyectos en los que tenía que estar en el trabajo las 24 horas del día, los 7 días de la semana, y luego hubo proyectos de mantenimiento, en los que estaba inactivo la mayor parte del tiempo. No diría que chupar la sangre, demasiado retórica, pero la mayoría de las veces, se convierte en un trabajo de hora punta. Ahora estos son los problemas que siento cuando se trata de administrar proyectos.
- La planificación de proyectos es a menudo bastante pobre. Pero no culparía solo a los gerentes de proyecto por esto. La mayoría de las veces, los gerentes de proyecto preparan los plazos de acuerdo con los comentarios proporcionados por los desarrolladores. Y los propios desarrolladores no están seguros de cuán rápido pueden terminar. La mayoría de las veces, citan una fecha límite, simplemente para estar en los buenos libros del gerente. Al final del día, los gerentes de proyecto culpan a los desarrolladores por no atenerse a los plazos que han otorgado, y culpan a los gerentes de proyecto por apresurarse.
- La mayoría de las veces, la empresa otorga plazos poco realistas, solo para complacer al cliente. El negocio de consultoría es bastante competitivo, casi un perro se come un mundo de perros, y las empresas deben hacer todo lo posible para garantizar que reciben una parte del pastel. Y uno de ellos está dando plazos poco realistas. Pero mi finalización es el final del día, incluso el cliente entiende que el proyecto no se puede entregar en el plazo establecido. Así que la extensión a los proyectos es por defecto.
- Un problema importante que he visto es que la mayoría de las veces, la preparación del medio ambiente y los recursos a tiempo rara vez sucede. La mayoría de las veces, los empleados asignados a un proyecto, tienen que manipular sus pulgares, a la espera de que se les asigne un sistema, o el software no está bien configurado, o las conexiones a la base de datos, LDAP, Servidor de aplicaciones no están en su lugar. En realidad, se pierde mucho tiempo en la configuración del sistema y en la configuración, en lugar de escribir el código real. Este problema es más frecuente en las empresas más grandes que en el tipo de inicio, el primero tiene este sistema burocrático completo, donde hay que esperar para obtener la aprobación, realizar una verificación de antecedentes, solicitar un sistema, aprobarlo. En el momento en que está en el proyecto, ha perdido una cantidad de tiempo preciosa, sin hacer nada. Y luego tienes que hacer un trabajo de hora punta.
- El desarrollo de aplicaciones ahora no se trata solo de escribir código, tiene administración de configuración, administración de bases de datos, administración de respaldo, compilación, implementación y lanzamiento, componentes comunes, marcos, control de calidad. Esencialmente, lo que están teniendo son varios equipos que se unen en la misma plataforma. Y esta es la trampa, el trabajo del gerente de proyecto es generalmente hacer que los equipos se coordinen entre sí, asegurándose de que estén en el mismo plano. Pero para una coordinación técnica efectiva, necesitaría un buen gerente o arquitecto técnico, alguien que pueda hacer que los miembros del equipo adopten tecnologías nuevas para trabajar de manera inteligente. La mayoría de las veces, los desarrolladores tienen que dedicar tiempo a la I + D en la red, para corregir un error. Y esto podría ser para un módulo, que habría tenido una contraparte de código abierto de terceros en algún lugar, así que en efecto lo que estás haciendo es reinventar la rueda nuevamente. Necesitaría un arquitecto técnico o gerente técnico realmente bueno, que pueda sentarse con el cliente junto con el gerente del proyecto y establecer los plazos. Y esta es la trampa, conseguir un buen arquitecto técnico es difícil, hay una gran escasez. Si bien puede tener una docena de desarrolladores de Java o .Net, es difícil conseguir un arquitecto o administrador técnico realmente bueno.
Mi opinión es que la industria de TI todavía es joven, aún está madurando, y tomará tiempo antes de que los procesos se estabilicen. Sin embargo, debe comprender que aquí hay una línea muy delgada, ya que la dependencia de los procesos podría acabar impidiendo cualquier toma de decisiones rápida, y no hay procesos bien definidos, lo que podría significar que la ejecución de su proyecto sea demasiado caótica. También debemos darnos cuenta de que las reglas del juego han cambiado, con todas las herramientas de código abierto, los componentes y los marcos disponibles, no tiene sentido que el equipo vuelva a inventar la rueda. Y aquí es donde el papel del arquitecto técnico es crucial, alguien que tenga una buena idea de las últimas tecnologías, alguien que pueda manejar una pila de tecnología que esté en línea con el requisito del proyecto, pueda garantizar que los plazos sean manejables.