Fábula de las ovejas

ovejas

Un granjero tenía 30 ovejas que diariamente debía sacar a pastorear al inicio del día, para devolverlas a su establo por las noches.

Como sólo era él, la mecánica de guardado era la siguiente:

Llegaba con una oveja tirándola con un lazo, la amarraba al lado del portón de entrada del establo, abría el candado del portón, tomaba la oveja y la metía. Cerraba el portón con el candado e iba por la siguiente oveja.

En una ocasión, el granjero debió ausentarse por varios días de su granja por lo que le pidió a su vecino que le ayudara cuidando de sus ovejas en lo que él no estaba. Le explicó detalladamente el procedimiento que debía seguir, y partió confiando en que su rebaño estaría muy bien cuidado.

Durante el primer par de días, el amigo siguió al pie de la letra las intrucciones del granjero, a pesar que pensaba que el proceso que se seguía no era el mejor, ya que el tener que cerrar con candado la cerca por cada oveja que se metía parecía ser una pérdida de tiempo. Así pues, al tercer día decidió optimizar el proceso. En vez de abrir y cerrar el candado cada vez, consiguió lazos un poco mas largos para dejar amarrados a los animales en el interior de la cerca. Así ahorraría movimientos y tiempo.

Funcionó perfecto el día 3 y 4, y el buen vecino estaba feliz.

A poca distancia, un lobo que merodeaba obsevaba este cambio en la rutina que anteriormente se tenía y poco a poco fue acercándose sin que la persona encargada se diera cuenta, hasta que en el atardecer del 5to día y cuando ya muchas ovejas se encontraban amarradas al establo dentro del cercado, entró dispuesto a obtener un suculento botín.

Finalmente cuando el vecino regresó con la siguiente oveja a guardar, se encontró con que habían varios lazos sueltos de las ovejas que, en su desesperación, habían logrado zafarse y huido; varias ovejas heridas y señales de sangre en el suelo indicando el arrastre de una de ellas ya sin vida.


Muchas veces no entendemos para qué están los procesos y porqué están las normas de seguridad. Pensamos que son para evitar que hagamos cosas indebidas, cuando en la mayoría de los casos es para protegernos a nosotros mismos de desastres y ataques. Ante esto,y antes de cuestionar procedimientos y normas, hay que tratar de entender porqué y para qué están ahí.

  • Un proceso engorroso, es mejor que ningún proceso.
  • La seguridad no siempre es para evitar que algo se escape, también es para evitar para evitar que algo entre, y vice versa.
  • Disminuir tiempos de proceso, no significa necesariamente más ganancias o mejorar.
  • Solicitar levantar cualquier norma por comodidad o agilidad, seguro ocasiona problemas .

Sólo por mencionar algunas de las “moralejas” de la fábula. Seguro tendrás otras, adelante con tus comentarios.

Anuncios

Evitando la gripe de TI

Hace algunos días publiqué en LinkedIn una frase respecto a una situación particular, y de como ese tipo de situaciones me hacer sentir.

La frase es:

Cómo me molesta que se atrasen los proyectos y tareas!. Y peor aún que digan “si todos los proyectos se atrasan”

AcusadorCómo podemos ver, no hay calificador de cantidad ni temporalidad. Habla, tal vez de una situación puntual, de manera muy general, que incluso no especifica al actor como primera persona, es decir no se sabe si es una situación propia o de un tercero que es observado por él.

La idea general era provocar alguna reacción  y ver si la sensación se repetía o no dentro del círculo de contactos que en la red mantengo.

Los resultados de esta, a este momento son:

Conformismo Venta de servicios Análisis sin contexto Aporte
8% 18% 56% 18%

Definitivamente no me esperaba ni tanta recepción a este tipo de tema, ni la variedad de situaciones que se dieron. Revisemos algunas de las que más me llamaron la atención.

Conformismo

Afortunadamente, los comentarios asociados a cierto nivel de conformismo y resignación a que nada se puede hacer, salvo sólo aceptar que los proyectos que se emprendan se atrasarán y que frente a eso sólo hay que esperar que suceda para decidir que hacer, son la minoría ( debo confesar que esperaba más) lo que me da muchas esperanzas en cuanto al futuro de la gestión de proyectos.

No se trata de no reconocer que hay imponderables que pueden hacer que los tiempos que se plantearon inicialmente se muevan, sino que hay que prepararse siempre lo mejor posible para tratar de evitarlos, en lo posible tener algún “Plan B” para situaciones que en otros proyectos se hayan presentado y nos hayan dado problemas, y que cuando inevitablemente surjan, nos moleste mucho.

Es como la gripe. Sabemos que nos va a dar, pero supongo que nadie le gusta estar enfermo y la mayoría toma las medidas de prevención para tratar de evitarla.

No dejemos que nuestros proyectos se agripen.

Análisis sin contexto

Lo que más me sorprendió es que a partir de dos simples frases se hayan levantado las más disímiles teorías y que se haya, en ocasiones, generado acabados diagnósticos de una realidad supuesta que nadie se tomó el tiempo de sondear o verificar.

Más de la mitad de los comentarios han sido de ese tipo.

Podemos interpretarlos como el genuino deseo de ayudar y colaborar, y trataré de hacerlo así para no juzgar intenciones de otro tipo, que espero sean propias de otro tipo de redes y no de la que se ha estado usando.

De cualquier manera, la desprolijidad evidenciada es preocupante. Más allá del deseo de aportar, hacerlo tomando una cantidad excesiva de supuestos, hace que la conclusión sea errada casi con certeza, y por lo tanto cualquier plan de acción que se pueda derivar conduzca a más problemas de los que se hayan querido reparar.

En ese sentido es preocupante que esta misma manera de conducirse, se pudiera replicar en los ambientes laborales en los que cada uno participa. No sería de extrañar, entonces, que aún exista en estos días, una suerte de “mala reputación” de las áreas de TI, muy difícil de superar.

Por esto mismo, como cabeza de equipos de personas, creo que podemos llevar a cabo algunas acciones que nos puedan ayudar a salir adelante. Primero en un trabajo personal y luego en un trabajo con el grupo humano que nos toca dirigir.

  • Entender de manera plena la situación (y a las personas involucradas).

Esto no inicia en cada proyecto. Es una actitud que se debe  tener permanentemente para poder tomar las decisiones futuras lo más acertadamente que se pueda. Desde el primer día hay que estar en estrecho contacto con cada usuario que nos toca e intentar mirar el negocio desde su punto de vista de modo que, una vez logrado en alguna medida, empatar esto con nuestro propio conocimiento de tecnologías. (ver Primero, lo primero)

  • Realizar las actividades de la manera en que se propusieron y no “acomodando” actividades.

Hay que ser siempre consistentes en nuestro quehacer diario. Cada actividad que hacemos para la compañía para la que trabajamos es importante. No sólo los “Grandes Proyectos”. Cada compromiso que hacemos lo debemos considerar como un juramento con sangre para con nuestros usuarios.

Y para esto es importante considerar siempre TODTetrisO. Las tareas chicas del día a día, tanto como las grandes actividades de los proyectos más visibles para el negocio. Solemos olvidarnos del quehacer diario, pero es justamente ese el que nos termina cobrando nuestro olvido y hace que finalmente terminemos jugando Tetris  con la maraña de actividades que se nos avalancha.

  • No “pretender” ser o hacer más de lo que se puede (desde la primera idea)

Hay que aprender a decir que no. No importa el tamaño del equipo con que contemos, ni si tenemos un enorme presupuesto para proyectos. Los recursos SIEMPRE se acaban, y en ese momento dejamos pendientes compromisos y empiezan las portergaciones.

Y hay que aprender a decirnos que NO a nosotros mismos. Cuando un equipo humano funciona bien, y las actividades avanzan, es fácil caer en la tentación de intentar materializar esas innumerables ideas que rondan nuestra cabeza y con que saturamos a nuestro equipo para hacerlas realidad. La proactividad incluye el auto control, y si no queremos retrasos es de suma importancia mantener el equilibrio permanentemente.

Aportes y Ventas

Se agradece que también haya un porcentaje no despreciable de aportes. Ideas que generan debate (en el buen sentido) y que provocan evolución y crecimiento.

Junto con esto están quienes directamente intentan vender algún servicio, basados en la poca información que se les dió. Es completamente válido y honesto el hacerlo directamente sin rodeos (aunque me temo que basan su prospección en premisas no muy claras, del mismo modo que el punto anterior).

 


No podemos permitir que los atrasos sean lo normal en lo que sea que nos involucremos. Si lo hacemos estaremos sacrificando la principal premisa en que se basa la tan mencionada Transformación Digital: La rapidez. El Cliente quiere sus productos ya. Y para eso hay que implementar la tecnología que apoya de manera ágil y rápida, hay que disminuir el “time to Market” del producto, hay que asegurar la disponibilidad de las plataformas.

Con atrasos, nada de eso es posible.

Vuelvo a agradecer todos los comentarios ya que cada uno de ellos ha dado pie a reflexiones y me ha hecho ver que aún hay algunos conceptos un poco revueltos. Confundimos trabajo colaborativo con trabajo en equipo; disciplina con imposición; disentir con falta de respeto; libertad con libertinaje.

En fin, creo que es el signo de los tiempos que corren.

Éramos libres

Imagen1A veces sucumbo a mi obsesión de cuestionar las realidades que se me presentan como ciertas y/o a algunas frases hechas que pretenden filosofar sobre algún aspecto de la vida, y que se dan por ciertas sin mayor análisis.

Entiendo que la mayoría sólo pretenden divertir de una manera liviana, más que invitar a divagar sobre el tema. Me disculpo de antemano ante quienes les parezca que hacerlo no corresponde.

Sin embargo mi obsesión sigue ahí, y en particular es el caso de la imagen que acompaña este texto.

En ella se indica:

Cuando el teléfono estaba atado con un cable, los Humanos eran libres

Depende de lo que se defina como libres.

Recuerdo que en mis inicios profesionales, cuando no existía el uso que hay hoy con los teléfonos móviles, haber tenido que quedarme largas horas de guardia en la oficina esperando que sucediera algún incidente que afortunadamente nunca sucedió. Perdiendo valioso tiempo de vida familiar o simplemente de ocio recreativo. Hoy en día la mayoría de las guardias pueden hacerse de manera remota, lo que implica que puedo realizar las actividades personales que necesite, mientras no se presente efectivamente un incidente. Si no se presenta he ganado ese tiempo para mí.

Otra arista de este cambio tecnológico se refiere a las juntas. Antes de la movilidad, cuando había que reunirse también sólo era de manera presencial, obligando a desplazarse a todas las personas involucradas al lugar acordado para ello, con la consiguiente pérdida de tiempo en este movimiento. Hoy en día puedo estar en reuniones desde cualquier localidad con señal, y mi tiempo dedicado a la reunión sólo es lo que se demore ésta, ganando para mi los tiempos asociados a desplazamiento.

Sólo por dar dos ejemplos.

Sé que también podrán dar ejemplos en contrario, y los invito a hacerlo y a conversar acerca de este tema. Por mi parte estoy disponible a pesar que parezca un poco grave, ya que entiendo que la imagen no pretende pasar de ser un meme.

Mismos que no existían antes de la movilidad actual.

Push or Wait — Being CIO

I’ve read somewhere that luck doesn’t exist, that is actually the result of the combination of preparation plus opportunity. And while in a way it’s right, and those who complain of “bad luck” I think it’s often that they haven’t had enough preparation to take the opportunities that present themselves along the way, I’m also […]

a través de Push or Wait — Being CIO

Contenedores | Containers

Un Artículo práctico que deja muy claro el concepto de contenedores.

Tecnologías de la Información y Procesos de Negocios (BPM)

Los Contenedores –Containers– son una solución al problema de cómo hacer que el software se ejecute confiablemente cuando se traslada de un entorno informático a otro. Esto podría ser desde la computadora portátil de un desarrollador a un entorno de prueba, desde un entorno de transición al de producción, y tal vez desde una máquina física en un centro de datos a una máquina virtual en una nube privada o pública [1].

Los Contenedores son un método de virtualización de un sistema operativo que permite ejecutar una aplicación junto con sus elementos dependientes, en un ambiente aislado e independiente. Los Contenedores permiten empaquetar fácilmente el código, las configuraciones y las dependencias de una aplicación en bloques fáciles de usar que ofrecen consistencia ambiental, eficiencia operativa, productividad para el desarrollador y control de versiones.

Los Contenedores pueden ayudar a garantizar que las aplicaciones se implementen de manera más rápida…

Ver la entrada original 1.629 palabras más

Sala de Urgencias (ER)

SalaDeEmergenciasEntiendo bien que la medicina lleva mucho más tiempo que las áreas de Tecnología evolucionando y aprendiendo como hacer más eficiente su trabajo. Más aún, entiendo que trabajar con las vidas humanas es infinitamente más delicado que lo que nos toca hacer con los sistemas de una empresa.

Sin embargo, también estoy convencido de que siempre es bueno mirar a otras áreas del que hacer humano para sacar lecciones y aprendizajes, para que sus mejores prácticas puedan ser adaptadas de modo que podamos evolucionar hacia brindar el mejor servicio posible.

Una de las lecciones que la medicina nos puede dar es la diferenciación clara entre las diferentes formas de atender a los pacientes dependiendo de las circunstancias. Es decir, no es lo mismo atender a un paciente sano en la consulta para un chequeo preventivo, que a una persona con algún síntoma que quiere saber que tiene para tratarse, o a alguien que llega a urgencias con compromiso de su vida.

En el símil con la tecnología, para las dos primeras tenemos más o menos un esquema a seguir, pero para la segunda no he encontrado que haya algún procedimiento estándar para hacer las cosas.

Hace unas semanas se complicó una liberación y se tenía el riesgo de dejar sin servicio al área que se estaba atendiendo. Los consultores a cargo insistieron en que había que seguir el mismo procedimiento que utilizaban para cuando hacen una revisión preventiva de los sistemas. Es decir: recopilar la información, llevársela para analizar, elaborar un diagnóstico y debatir los caminos a seguir. Esto tomaría varios días, y demostraron ninguna sensibilidad hacia sus clientes o usuarios que estaban imposibilitados de realizar sus labores normales con el consiguiente perjuicio que esto provocaba en todos. Había que actuar con extrema rapidez y eficacia, y los consultores no entendían que esto requería una manera de proceder distinta.

Esta escenario lo he visto repetido demasiadas veces, y en general con casas consultoras. En mi opinión muchas veces se debe a que no se establece un compromiso entre el producto que estas entregan y el negocio al que quieren llegar. Es por eso que es necesario establecer un procedimiento para “revivir” sistemas y actuar eficaz y eficientemente en este tipo de emergencias. No se trata de una restauración desde un respaldo, se trata de evitar tener que llegar a eso en determinado momento.

Para esto creo que es de utilidad establecer los siguientes 3 criterios:

Anticipa posibles escenarios

¿Qué puede fallar?. Habitualmente quién nos vende un producto intenta por todos los medios hacernos creer que es prefecto y sin fallas. Esto nunca es cierto y hay que prepararse para lo que vaya a surgir. Para eso hay que revisar y entender lo mejor posible el sistema que se va a incorporar, y ver los posibles escenarios de falla que pueda presentar. Aunque revisarlo internamente es complicado, en la integración con los demás sistemas y el dimensionamiento de la infraestructura, si nos podemos preparar. Y mucho.

Haz tareas en paralelo

Sin embargo, a pesar de que se haya hecho un trabajo meticuloso de preparación, siempre pueden haber contingencias que surjan en el momento o, peor aún, mucho más adelante cuando el sistema ya está plenamente operativo. En este sentido es cuando trabajar organizadamente y en paralelo, nos da una ventaja en cuanto al tiempo total de caída o de problema.

Ubica los parámetros adecuados que hay que revisar de inmediato lo más independiente del sistema en cuestión. Por ejemplo, revisar la estabilidad de la red alrededor del punto de conflicto (Latencias, cortes, etc.); o disponibilidad de servidores satélites de los que depende el sistema (disponibilidad del active directory si la autenticación está ligada a este, por ejemplo). Cada uno de estos parámetros se leen inmediatamente en cuanto un problema es reportado y se coloca el resultado en un grupo de colaboración en cosa de minutos. El efecto que se logra es similar a cuando en urgencia te monitorean los signos vitales y se los dicen al médico tratante. En este caso cuando el analista entra a revisar, ya no tiene que preguntar por cada uno de ellos, sino que los tiene a la vista y puede actuar con estos antecedentes en la cabeza. Con esto se ganan minutos y a veces horas con respecto al hacer las mismas revisiones sobre pedido y de manera serial.

¿Que habrán revisiones redundantes que tal vez no incidían en el problema?, SI. pero es la forma de trabajar colaborativamente y es lo mismo que cuando te miden el pulso o te toman la presión, son los signos vitales que te ayuda a tener un panorama completo y evitar suposiciones que conducen generalmente a malas decisiones.

Mantener la calma no es lo mismo que ir lento

Generalmente los procedimientos en “Tiempos de paz” van a un ritmo que en una emergencia no es aceptable. Sin embargo actuar rápido no significa no actuar reflexivamente. Para eso también es importante que se hayan previamente establecido los procedimientos para lograr lo mejor posible los dos puntos anteriores. Si hay un equipo que ya me dio todas las posibles variables que se deben revisar, al analista sólo le queda enfocar todo su tiempo y esfuerzo a sólo una cosa: unir todas las variables que tiene en frente para llegar a la mejor conclusión, y si sólo hace una cosa, los minutos con que se cuenta son aprovechados al máximo y con la calma requerida para la reflexión, sin que por eso se pierda tiempo.

Con este esquema, he constatado que al menos se rebajan a la mitad los tiempos de solución que originalmente se tenía sin él.

Sin embargo, la tarea más pesada que me toca realizar es la de estar haciendo notar la diferencia a los consultores con que me toca trabajar, no todos, pero si la gran mayoría. Sinceramente espero que esto mejore y que no parezcan lo que hoy: mercenarios de la tecnología.

A mi manera

AMiManera

Establecer un hilo conductor común, que sea el sello del trabajo de un CIO, cualquiera sea la empresa o industria en la que se desempeñe no es fácil. Cada compañía, incluso si pertenecen a la misma industria, tiene sus particularidades, propias de una organización que, al ser formada por personas, está en permanente cambio tanto en su cultura organizacional como en sus procesos, sobre todo en la actualidad en que el entorno exige una adaptación a él, rápida y constante.

Así las cosas, a lo largo de mi vida laboral he ido encontrando aspectos que deben ser cuidados e incrementados, en cuanto a la dirección y liderazgo de nuestros equipos, que debemos realizar, y que deben ser parte de las buenas prácticas de un CIO.

1. Escucha a tu Usuario (Cliente)

Se debe ser siempre “el mejor amigo” de las personas a las cuales les estás dando el servicio. Sobre todo porque el espécimen llamado “Usuario” tiende a llegar a nosotros con una solución en mente que, en mi experiencia, habitualmente no es lo que realmente necesita. Hay que buscar debajo de todo lo que dice cuál es su verdadera necesidad y encontrar la forma de satisfacerla de la manera más ágil, simple y concreta posible.

He puesto algún comentario más acerca de esto en el artículo “Primero lo primero” (click aquí)

Siempre hay que tener en mente que la “Experiencia de Usuario” (UX) no se debe referir sólo al producto final que se le puede entregar, sino que al proceso completo que va desde el primer contacto hasta la satisfacción de su necesidad. En este sentido es útil pensar en ellos como nuestros Clientes, tal cual como si nosotros fuéramos una consultora y necesitamos que ellos nos compren la solución que estamos dando.

2. Lo importante es el negocio (información) NO la Tecnología

¿Le hablarías por teléfono a una persona que está sentada al lado tuyo?

Supongo que no (aunque alguna vez si lo vi hacer). Es mucho más efectivo darse vuelta y hablarle directamente de la forma tradicional y análoga, mirándole a la cara.

¿Y si está un pasillo más allá? ¿Y si está más lejos?… lo más probable es que la respuesta ya sea “depende” y entren a relucir distintas variables como la inmediatez con que se necesita la respuesta, si es posible desplazarnos o no de lugar, e incluso factores climáticos para decidir en qué momentos se hace necesario el uso de la tecnología (teléfono).

Lo importante es que la tecnología que se elija esté en función de las necesidades que se deben resolver y para eso hay que tener claro algo que nos cuesta mucho asumir: La tecnología no es el fin de nuestra función, es sólo la herramienta.

Y es en este sentido que en los últimos años se ha avanzado en la concientización de los que encabezan las áreas de tecnología en que sus funciones ahora son más estratégicas que operativas. Es necesario saber quién es tu cliente (del negocio y de sistemas), qué quiere y qué necesita (son dos cosas distintas).

Puede ser muy atractivo entrar en proyectos de Inteligencia Artificial con Big Data para establecer interfases con el público objetivo, pero si el problema es que Logística no cuenta con las herramientas que necesita pero que son más tradicionales (por lo tanto menos desafiantes), de nada nos servirá la tecnología de punta en el front-end.

La Tecnología sólo por la Tecnología, en un negocio no sirve para nada.

3. Cuida a tu equipo

Todo lo que se realiza es a través de otros, que forman parte, permanente o temporal, del equipo de trabajo. El equipo debe poder saber exactamente qué es lo que se espera de cada uno de ellos y hay que dejar que hagan lo que saben hacer. Lo que debemos siempre tener presente en este punto, es que si ya llevamos un tiempo trabajando en un sector, el equipo que tenemos es el que uno ha formado y decidido que nos colaboren, así que si no podemos tener confianza en lo que harán, el problema no reside en ellos sino en quien los eligió.

Pero también hay que estar atento a sus motivaciones y necesidades, si bien no se pueden satisfacer todas al mismo tiempos, he constatado que el saber que pueden tener logros personales a través del trabajo colaborativo o en equipo, los mantiene permanentemente queriendo demostrar lo que pueden lograr.

Así mismo, hay que ser agradecidos. El equipo son nuestras manos y hay que constantemente estar reconociéndolo. El pensamiento de “Sólo hacen su trabajo por el que se les paga” es el peor veneno que puede haber para lograr las sinergias que harán que el área de Sistemas sea un verdadero aporte para el negocio y no solamente unos cargadores de equipos.


Independientemente de donde haya estado, he intentado respetar estas tres directrices y ha funcionado en mayor o menor medida, me lo he ido encontrando de a poco en el camino y han pasado a formar parte de lo que hago cada día.

Eso si, los detalles y el “peso” que se le da a cada una en determinado momento depende del ambiente en que uno se encuentre, la cultura puntual de la organización y de la “intuición” de cada uno de nosotros, ahí es dónde hay que encontrar el equilibrio adecuado, y como cada vez es diferente sólo queda hacer las cosas a la manera de cada cual. En mi caso: A mi manera.