¿Problemas en TI?

Algunos indicios

Usualmente los problemas empiezan cuando somos los últimos en enterarnos de los cambios en la estrategia del negocio.

Los usuarios dejan de quejarse –porque han optado por el shadow IT, la organización está implementando mecanismos alternativos de soporte a usuarios, mecanismos alternativos de operación y, luego, posiblemente, ocurran despidos y rotación o traslado de personal.

Los usuarios dejan de llevarnos sus grandes ideas. Esto podría deberse a que el gerente de TI no fomentó una cultura de colaboración y experimentación, a una falta de madurez o mucho ego.

Ya no es copiado en los correos institucionales –mejor pensamos, las reuniones eran improductivas.

Seguramente hemos comenzado a ver personas extrañas circulando por la empresa, o se nos han asignado “ayudantes” para apoyarnos con la carga de trabajo.

Expectativas no aterrizadas sobre el ritmo esperado del cambio, o resistencia burocrática al cambio producto de un estancamiento de la organización a nivel alto.

No se evidencia una articulación con la estrategia. Se pide conexión con los clientes y generar ingresos, a la vez que se debe reducir costos y mejorar las eficiencias operativas.

Pero seguramente nosotros mismos somos parte de la ecuación –y lo negamos, ya sea consciente o inconscientemente

La deuda técnica y/o la obsolescencia técnica probablemente nos mantengan realizando los mismos trabajos, o resolviendo los mismos problemas, una y otra vez.

Nos escudamos en la falacia del costo perdido, del costo hundido, cuando la mejor solución es deshacerse de los viejos sistemas problemáticos y comenzar de cero con otros nuevos, capitalizando el conocimiento aprendido de esa [mala] experiencia.

De alguna manera estamos cautivos de algún proveedor. Tal vez nos encandiló una funcionalidad aún no [suficientemente] explotada, porque no estamos preparados para capitalizar esta funcionalidad [y, peor, tal vez nunca lo estaremos]. O porque buscamos [obtuvimos] el precio más bajo [CAPEX], sin considerar el [OPEX]. O porque era más fácil gestionar al proveedor que implementaba la “solución”, que [realmente] conocer dicha solución.

Consideramos que, como se habla de nubes híbridas, la nube puede ser una extensión de nuestro centro de datos. Debemos detenernos y considerar –bastante- que hay diferentes SLA (¿o la nube no nos cuesta diferente a nuestro centro de datos?).

Preparamos un caso de negocio “técnicamente sólido”. Pero perdemos de vista el objetivo –y, peor, no utilizamos el lenguaje- del negocio.

Aplicar metodología ágil a los sistemas centrales. Querer ser una bimodal 2.0 cuando tenemos que evaluar primero nuestra posición como bimodal 1.0. Tal vez si realizamos una evaluación previa y logramos acotar el alcance o conveniencia, con el correcto balance entre agilidad y estabilidad…

O los clásicos que argumentamos

Decir sí a todo –o a casi todo, sin buscar ser asertivo, para darnos tiempo de  realizar las evaluaciones correspondientes. Manejamos proyectos ¿verdad?

Pretender esconder los problemas, creyendo que se podrán resolver antes que nuestro superior se entere. Gestionamos las comunicaciones, y los cambios, como parte de la gestión de proyectos y de la gestión de servicios ¿verdad? O utilizando la técnica del oscurantismo.

Contratar [o no contratar] (por ego) o promover (por conveniencia) al candidato equivocado. Olvidar que la destreza ganada a través de la experiencia importará menos que la habilidad de aprender otras nuevas destrezas.

Mantener el dilema ético de ser juez y parte –y saber gestionar [sobrellevando y asumiendo] lo que viene después.

No identificar y menos ejecutar las acciones correctivas necesarias.

Conflictos de poder.

La tecnología es [siempre, o casi siempre] la culpable –pero no buscamos una real solución.

Esbozar que la innovación o búsqueda de la mejora continua no está en el manual de funciones por las que fuimos contratados.

Realizar tareas sólo por cumplimiento normativo, regulatorio, legal, ya sea local o internacional, dependiendo del ámbito de actuación de la organización.

Falta, pero empecemos por lo siguiente

Debemos sentirnos cómodos con abrazar el fracaso. Debemos enfrentarlo (somos profesionales) -y aprender (es nuestra habilidad innata).

De igual manera, debemos aceptar los resultados de una [real] auditoría de TI –y definir y ejecutar las acciones correctivas necesarias.

Evitando que sea el usuario final el que nos reporte un incidente.

Asegurar los SLA comprometidos.

¿Me comentas?