7 Consejos para trabajar con equipos de TI

Este no es solo un pecado de los profesionales de Tecnologías de Información, también es compartido por gerentes y por cualquier profesional que participa de forma esporádica en los proyectos. En parte es comprensible, las obligaciones no desaparecen al cerrar la puerta de la sala de reuniones y muchas veces las tareas impuestas por el proyecto son vistas como carga adicional a la jornada normal.

Para evitar esto en la relación con TI se debe integrar a los profesionales desde el comienzo e interactuar con ellos para que te identifiquen como un igual. Como conocemos del tema, podemos hablar en su misma jerga y desde ahí tratar de entender su forma de pensar.

Además, es fundamental cerrar las reuniones con ideas claras y concretas para asegurarse de que todos los participantes entendieron lo mismo. Porque si dejas cabos sueltos es muy probable que debas explicar por correo o teléfono asuntos que dabas por finiquitados.

La jornada laboral normal tiende a estructurar la forma de pensar y actuar en el trabajo, sobre todo en cargos y profesiones que llevan años realizando las mismas tareas y repitiendo las mismas soluciones. En cambio, las exigencias de la Web se orientan a las ideas innovadoras y en constante evolución, lo que causa extrañeza entre los empleados.

Por esto es muy común que algunas ideas disruptivas sean rechazada con el argumento de que “no es posible hacerlo” o “no es viable”. Si demuestras que te manejas en el tema tendrás autoridad para decir lo que es posible y lo que no. Investiga cuál es el problema real, muchas veces no quieren aceptar propuestas porque estas les exigen mucho esfuerzo o tiempo, algo que se puede negociar si aclaras cada punto en conflicto.

Tal como describíamos en el punto 1, las jornadas laborales no se reducen al aparecer un nuevo proyecto en la agenda de los profesionales de una empresa. Junto a la poca atención en las reuniones también se presenta un desequilibrio en los tiempos de implementación desde TI, lo que puede salirse de control.

No todos se demorar lo mismo en hacer algo y por esto es necesario definir con claridad los tiempos y costos. Para evitar confusiones es recomendable distinguir entre horas de trabajo y plazos de entrega, y medir las jornadas en horas hombre tasadas en UF.

Los equipos de TI tienden a ser una cofradía cerrada, con rutinas propias y casi nula relación con otros departamentos de la empresa. Además, este aislamiento repercute en la poca estima que presentan a la preocupación por el usuario y cliente, donde las tareas que apuntan a mejorar estos aspectos se ven como un trabajo inútil o poco provechoso.

Cuando estás trabajando con otro equipo quizás no sea muy agradable tener que explicar todo y a veces incluso hacerlo más de una vez, pero esto nunca debe ser percibido como tiempo perdido. Si entregas un buen servicio y les enseñas lo que no manejan bien, te evitarás problemas futuros. Instruir a alguien siempre será más rentable que tener que hacer el mismo trabajo varias veces.

Toda profesión construye su identidad a través del lenguaje técnico que domina. Esta característica crea roces al elaborar proyectos multidisciplinarios, obligando a quienes lideran estas acciones a buscar puntos de acuerdo para evitar malentendidos.

Dependiendo de la formación que tengan los desarrolladores, el léxico usado puede variar y crear confusiones. Para evitar esto debes usar siempre palabras de uso general, incluir descripciones y apoyar tu comunicación con imágenes.

No todos gozan de una buena redacción y ortografía, menos cuando están escribiendo apurados un email o no se trabaja elaborando textos todo el día.

Por esto, pon especial atención al leer y no trates de adivinar o asumir cosas. Es mejor mandar un correo de confirmación que tener que corregir los problemas causados por un malentendido.

Siempre hay más de una forma de hacer las cosas y es común que no se coincida en las prácticas usadas. Para solucionar este problema debes crear una documentación correcta y fácil de entender, que transparente además los beneficios de hacer las cosas como las haces.

Si el otro equipo quiere hacer modificaciones a algún elemento del código, deben tener claro las secciones y las relaciones entre ellas para que puedan hacer cambios con conocimiento. Lo peor es cerrar la posibilidad a cualquier modificación, lo que causa frustración y puede causar problemas mayores.