post-tittle

Programadores y personal de sistemas: ¿Amigos o rivales?

Por: Reclu IT

23 de junio de 2014

Por: José Antonio Ramírez González

Resulta curiosa la rivalidad siempre existente entre los desarrolladores y los de sistemas. Los primeros se quejan de que los segundos siempre andan poniendo trabas al despliegue o funcionamiento de las aplicaciones, y los segundos, a su vez, siempre echan en cara a los primeros que producen serios problemas de funcionamiento, rendimiento o seguridad que ellos tienen que solucionar.

Juan Quijano, gestor de equipos de desarrollo, programador en C# y especialista en tecnologías Microsoft, afirma que la realidad, en casi todos los casos, es que ambas partes tienen un algo o un mucho de razón, y que cuanto más grande o complejo es el proyecto, más fácil es llegar a conflictos.

Sin embargo, David Marco Palao, senior Java Developer, considera que este en este tipo de situaciones depende más de las personas, que de los departamentos. “Cuando todos son conscientes de las labores y responsabilidades de otros, los proyectos funcionan con armonía al lograrse los resultados o los objetivos propuestos”, manifiesta.

Agrega que es importante, que si bien cada departamento debe conseguir sus objetivos, que el personal de ambas áreas deje de lado sus egos y empiecen a colaborar, definitivamente queda descartado que pudiera existir problema alguno.

Señala que en la organización donde labora como programador, los técnicos de sistemas trabajan casi a la par con sus colegas, mediante una comunicación constante, principalmente cuando se necesita detener la operación de un servidor o cuando se detecta alguna situación conflictiva en el área de sistemas. “Entre todos nos esforzamos para lograr los objetivos”.

Cuando se trabaja en equipo y se depende de otros departamentos/personas está claro que los egos personales y los tópicos no funcionan.

Gabriel Molina, programador dedicado al servicio de consultoría para el desarrollo de aplicaciones con tecnologías Java EE y promotor del uso y desarrollo de software libre, cita el caso específico de lo que ocurre entre los programadores y los Administradores de Proyecto (Project Manager o PM), como un ejemplo muy ilustrativo.

Principalmente porque “la gran mayoría” de éstos (los PM) no tienen los conocimientos técnicos suficientes como para tomar decisiones adecuadas sobre cómo resolver una necesidad de software y, mucho menos, con respecto al tiempo requerido de desarrollo.

“La formación de muchos de ellos no incluye, generalmente, los conocimientos básicos de programación, por lo que se generan complicaciones graves en los tiempos de entrega de los proyectos que son solventadas por las horas interminables de trabajo de los programadores”, expone Molina.

No obstante, señala que para los programadores puedan estar en posición de exigir mejoras en sus funciones con el personal de sistemas y de otras áreas relacionadas, es importante combatir la sensación que muchos programadores tienen de estar en una posición regularmente cómoda o simplemente la falta de entusiasmo en su trabajo.

Estos factores –señala Molina- evitan que muchos programadores busquen una mejora continua o que se mantengan atentos a los cambios tecnológicos que pueden ayudares a tener una mejor perspectiva de las soluciones que como gremio pueden brindar en los departamentos o áreas de sistemas en las organizaciones.

Ante ello no queda más que concluir que tanto el personal de sistemas como los programadores son esenciales en el día-día del trabajo operativo que llevan a cabo en sus organizaciones, ya sea de TI o como usuarias de TI.

La labor que desempañan es importante tanto como para uno y otro y como en cualquier otra área, lo fundamental para conseguir armonía y resultados es el trabajo en equipo, de lo cual sólo la organización, a través de sus directivos y gerencias, serán determinantes para que esto finalmente se logre.

Muchas empresas lo están logrando, otras están en vías de hacerlo y en su organización, amigo lector, ¿están implementando acciones para una adecuada armonía en el trabajo en equipo de sus áreas de sistemas con sus programadores?

  • Omar Vázquez dice:

    Yo no le llamaría rivalidad, es una especie de enfrentamiento por que unos son inconscientes del trabajo del otros. El personal de soporte siempre quiere operar los sistemas de la misma manera, y cuando hay un cambio no quiere hacer ningún esfuerzo extra, o incluso desconoce las nuevas configuraciones. Por otro lado, los programadores al querer innovar no siempre ponemos cuidado en cómo se opera en la actualidad y muchos no previenen situaciones derivadas de la interacción del sistema con los usuarios actuales y otros sistemas. Cuando alguien de un lado u otro reclama mucho, se evidencia la falta de competencia y preparación de quien siempre se queja.

    • Reclu IT dice:

      Hola Omar,

      Muy buenos puntos los que nos ofreces, como comentas se trata básicamente de ir, un poco más, allá de las funciones que se nos dan, para poder visualizar la situación de nuestros compañeros de trabajo. Además si es algo que podemos solucionar nosotros mismos, deberíamos hacerlo sin echar tantas quejas.

      Saludos.

  • Ricardo Madiedo dice:

    Es muy prematurio que viertas tu opinión estableciendo divisiones o “rivalidad” donde no las hay.
    Es cierto que en muchos proyectos hay conflictos, pero se debe necesariamente al desempeño de todo el equipo.
    He tenido la fortuna de trabajar en varios proyectos (algunos más difíciles, otros menos) que se colabora como un equipo.
    “Cada quién habla de la feria como le va en ella”

    • Reclu IT dice:

      Hola Ricardo,

      Gracias por enriquecer el post con tu experiencias y demostrarnos un ángulo que no se consideró en el artículo. En una futura entrega se podría ahondar en las acciones que hacen un equipo de trabajo de éxito.

      Saludos.

  • Deja tu comentario

    Tu dirección de correo electrónico no será publicada.

    Campos obligatorios(*)
    post-tittle

    Programadores y personal de sistemas: ¿Amigos o rivales?

    Por: Reclu IT

    23 de junio de 2014

    Por: José Antonio Ramírez González

    Resulta curiosa la rivalidad siempre existente entre los desarrolladores y los de sistemas. Los primeros se quejan de que los segundos siempre andan poniendo trabas al despliegue o funcionamiento de las aplicaciones, y los segundos, a su vez, siempre echan en cara a los primeros que producen serios problemas de funcionamiento, rendimiento o seguridad que ellos tienen que solucionar.

    Juan Quijano, gestor de equipos de desarrollo, programador en C# y especialista en tecnologías Microsoft, afirma que la realidad, en casi todos los casos, es que ambas partes tienen un algo o un mucho de razón, y que cuanto más grande o complejo es el proyecto, más fácil es llegar a conflictos.

    Sin embargo, David Marco Palao, senior Java Developer, considera que este en este tipo de situaciones depende más de las personas, que de los departamentos. “Cuando todos son conscientes de las labores y responsabilidades de otros, los proyectos funcionan con armonía al lograrse los resultados o los objetivos propuestos”, manifiesta.

    Agrega que es importante, que si bien cada departamento debe conseguir sus objetivos, que el personal de ambas áreas deje de lado sus egos y empiecen a colaborar, definitivamente queda descartado que pudiera existir problema alguno.

    Señala que en la organización donde labora como programador, los técnicos de sistemas trabajan casi a la par con sus colegas, mediante una comunicación constante, principalmente cuando se necesita detener la operación de un servidor o cuando se detecta alguna situación conflictiva en el área de sistemas. “Entre todos nos esforzamos para lograr los objetivos”.

    Cuando se trabaja en equipo y se depende de otros departamentos/personas está claro que los egos personales y los tópicos no funcionan.

    Gabriel Molina, programador dedicado al servicio de consultoría para el desarrollo de aplicaciones con tecnologías Java EE y promotor del uso y desarrollo de software libre, cita el caso específico de lo que ocurre entre los programadores y los Administradores de Proyecto (Project Manager o PM), como un ejemplo muy ilustrativo.

    Principalmente porque “la gran mayoría” de éstos (los PM) no tienen los conocimientos técnicos suficientes como para tomar decisiones adecuadas sobre cómo resolver una necesidad de software y, mucho menos, con respecto al tiempo requerido de desarrollo.

    “La formación de muchos de ellos no incluye, generalmente, los conocimientos básicos de programación, por lo que se generan complicaciones graves en los tiempos de entrega de los proyectos que son solventadas por las horas interminables de trabajo de los programadores”, expone Molina.

    No obstante, señala que para los programadores puedan estar en posición de exigir mejoras en sus funciones con el personal de sistemas y de otras áreas relacionadas, es importante combatir la sensación que muchos programadores tienen de estar en una posición regularmente cómoda o simplemente la falta de entusiasmo en su trabajo.

    Estos factores –señala Molina- evitan que muchos programadores busquen una mejora continua o que se mantengan atentos a los cambios tecnológicos que pueden ayudares a tener una mejor perspectiva de las soluciones que como gremio pueden brindar en los departamentos o áreas de sistemas en las organizaciones.

    Ante ello no queda más que concluir que tanto el personal de sistemas como los programadores son esenciales en el día-día del trabajo operativo que llevan a cabo en sus organizaciones, ya sea de TI o como usuarias de TI.

    La labor que desempañan es importante tanto como para uno y otro y como en cualquier otra área, lo fundamental para conseguir armonía y resultados es el trabajo en equipo, de lo cual sólo la organización, a través de sus directivos y gerencias, serán determinantes para que esto finalmente se logre.

    Muchas empresas lo están logrando, otras están en vías de hacerlo y en su organización, amigo lector, ¿están implementando acciones para una adecuada armonía en el trabajo en equipo de sus áreas de sistemas con sus programadores?

  • Omar Vázquez dice:

    Yo no le llamaría rivalidad, es una especie de enfrentamiento por que unos son inconscientes del trabajo del otros. El personal de soporte siempre quiere operar los sistemas de la misma manera, y cuando hay un cambio no quiere hacer ningún esfuerzo extra, o incluso desconoce las nuevas configuraciones. Por otro lado, los programadores al querer innovar no siempre ponemos cuidado en cómo se opera en la actualidad y muchos no previenen situaciones derivadas de la interacción del sistema con los usuarios actuales y otros sistemas. Cuando alguien de un lado u otro reclama mucho, se evidencia la falta de competencia y preparación de quien siempre se queja.

    • Reclu IT dice:

      Hola Omar,

      Muy buenos puntos los que nos ofreces, como comentas se trata básicamente de ir, un poco más, allá de las funciones que se nos dan, para poder visualizar la situación de nuestros compañeros de trabajo. Además si es algo que podemos solucionar nosotros mismos, deberíamos hacerlo sin echar tantas quejas.

      Saludos.

  • Ricardo Madiedo dice:

    Es muy prematurio que viertas tu opinión estableciendo divisiones o “rivalidad” donde no las hay.
    Es cierto que en muchos proyectos hay conflictos, pero se debe necesariamente al desempeño de todo el equipo.
    He tenido la fortuna de trabajar en varios proyectos (algunos más difíciles, otros menos) que se colabora como un equipo.
    “Cada quién habla de la feria como le va en ella”

    • Reclu IT dice:

      Hola Ricardo,

      Gracias por enriquecer el post con tu experiencias y demostrarnos un ángulo que no se consideró en el artículo. En una futura entrega se podría ahondar en las acciones que hacen un equipo de trabajo de éxito.

      Saludos.

  • Deja tu comentario

    Tu dirección de correo electrónico no será publicada.

    Campos obligatorios(*)

    Política de privacidad de www.recluit.mx

    Para recibir la información sobre sus Datos Personales, la finalidad y las partes con las que se comparte,
    contacten con el Propietario.