Las soluciones IT completas y un ejemplo con infraestructura virtual vSphere

En este artículo cuento cómo en gral. las soluciones "completas" no lo son, y hay que completarlas para que realmente cumplan con el objetivo para el cual fueron pensadas. Hay además comentarios sobre los ámbitos de responsabilidad de provedores IT terceros y la relación de los proveedores IT internos de una organización con su cliente principal (la organización).


Soluciones buenas, pero parciales
Es común ver en infraestructura que al comprar una solución IT, la empresa acuerda el trabajo a realizar, viene a la empresa/organización, realiza el trabajo y luego se va. Dejando garantías vigentes, por un tiempo, bajo ciertas condiciones, etc.

Por ejemplo, la instalación de una infraestructura vSphere: se instalan los hipervisores, se monta el server vCenter, se agrega los hipervisores al vCenter, se deploya algunas máquinas virtuales - probablemente no?, y listo (hasta ahí es el trabajo acordado con el proveedor de servicios IT en este ejemplo). El cliente luego toma la posta desde ahí, administrando todo la infraestructura - virtual ahora. Instalando, migrando sistemas operativos de físico a virtual, etc. etc.

El precio de un trabajo puntual de infraestructura y sus límites son indispensables, sino la empresa proveedora va a hacerse cargo hasta el infinito de cualquier cuestión relacionada con lo que instaló/configuró inicialmente.


Soluciones IT completas
Ahora, el caso de las áreas de sistemas internas en la organización es bien diferente. Cada área IT interna en una organización tiene la obligación de sostener la continuidad de la infraestructura en el tiempo, a largo plazo. 

Lo que es muy diferente de la obligación de proveedor IT comercial, sin embargo es común encontrar el caso de que las soluciones IT internas en una organización se implementan "por única vez", y luego se las abandona "como están" y sin tomar en cuenta la prerrogativa de mantenimiento y mejora contínua (que es en gral. un requerimiento del puesto para los empleados del área IT interna por cierto).

Siguiendo el ejemplo de la infraestructura vSphere, algunos pasos posteriores a la "simple" instalación y configuración de una infra virtual vSphere podrían ser (más o menos en orden de importancia estratégica-técnica): 

1) Implementar backup automatizado de la configuración del vCenter (y su DB de backend)

2) Implementar backup automatizado de la configuración de los ESXi,

3) Deployar (comprar en gral.) una solución de backup virtual (Veem, etc.), para las máquinas virtuales en sí,

4) Implementar chequeo de configuraciones automatizado (extraer toda la configuración de vSphere, volcar a un GIT o similar, y luego ir haciendolo regularmente, para tener un registro centralizado exacto de cada cambio en la configuración), AKA "configuration management".

5) Implementar monitoreo de la infraestructura virtual (hay varias maneras)

6) Deployar un vSphere Update Manager (para mantener todos los hipervisores actualizados/parcheados), 

7) Implementar alta disponibilidad para vCenter (o sea, montar otro server vCenter, de alguna de las varias maneras posibles),

8) Implementar automatización en el mantenimiento necesario para vCenter (tip: la DB de backend necesita atención de a ratos).

9) Cómo proceder, y qué hacer exactamente desde lo técnico para recuperar la caída/cuelgue/fuera de servicio de cualquier componente de la infraestructura virtual vSphere (incluye tener instaladas y configuradas las herramientas necesarias, los planes, y que los que vayan a haber la recuperación, hayan realizado prácticas y pruebas de campo para saber que toda las políticas/procedimientos/herramientas funcionan realmente como deberían).

Etc.


Si se fijan, extrapolando la idea general del ejemplo, cualquier infraestructura necesita básicamente (además de la instalación, configuración y puesta en producción inicial): 

- Backup, 
- Configuration Management, 
- Monitoreo y Optimización/Mantenimiento/Mejora Contínua.
- Añadir redundancia/resiliencia adicional (como parte de la mejora contínua)
- Plan de acción de recuperación de desastres.

Sin todos esos detalles (y varios más no mencionados), la solución puede "estrellarse" con mucha facilidad y dejar de funcionar apropiadamente, y con algo de mala suerte además, inesperadamente (por ejemplo: madrugada de año nuevo, 3 de la mañana, llamada del dueño de la empresa al personal IT, cayendo a las 3.10 cuando el personal que usa el sistema le acaba de avisar de que no anda. "Casos de uso": clínica de guardia, farmacia de guardia, empresa de seguridad, polícia, etc.).


Completar la solución
Si una solución integral no incluye lo anterior, habría que ir preguntando al proveedor cuanto saldría implementar backup, config management, monitoreo, y disaster recovery...o pensar cómo se hace internamente para completar la solución de infraestructura. Normalmente esas tareas tercerizadas implica un precio mayor que la instalación/configuración inicial, ese precio más alto es realmente una mejor aproximación al TCO real de la solución.

TCO:
http://es.wikipedia.org/wiki/Coste_total_de_propiedad

* Esto es cuestión de opiniones, pero para completar más el TCO de la solución, se podría agregar la previsión/estimación de costos futuros del lifecycle management, por ejemplo, previendo una migración de plataforma. 

Siguiendo el ejemplo: preveer un posible/eventual path de migración de Vmware vSphere 5.1 (+ ESXi) hacia Microsoft Hyper-V 2012 + System Center 2012 Virtual Machine Manager .

Por ejemplo: tener que comprar una SAN "ahora":
- aumenta el TCO de la solución vSphere, pero 
- baja el TCO de la - posible a futuro - solución Hiper-V 2012, pero, 
- en gral. hace disminuir el TCO de la solución "Infraestructura Virtual" 
(que es lo que le interesa a la organización en realidad), y por lo tanto genera un "path de migración" aceptable, y se concluye que comprar la SAN "estaría bueno" :-)


Ambitos y tiempos limitados
Las áreas IT internas tienen un ámbito de injerencia y obligaciones para con la infraestructura IT por lejos mucho mayor que casi cualquier solución "llave en mano" que pueda proveer un tercero, ya que inclusive con el mejor presupuesto disponible, el ámbito de injerencia de un proveedor IT tercerizado siempre - pero siempre - está limitado a determinadas tareas y obligaciones, y a un rango de tiempo - contratado - durante el cual le va a responder al cliente. Y luego del cual, ya no va a tener obligación de responderle al cliente. 

El área IT interna por otra parte no está limitada en absoluto de sus obligaciones para con la organización, a la que debe responder por obligación organizacional (o sea, independientemente de quién/es estén integrando esa área como empleados/responsables), de modo contínuo, y tiene la responsabilidad de completar y subsanar cualquier limitación que exista en la infraestructura. 

Siguiendo el ejemplo: el que en la solucion "llave en mano" no haya previsto un mecanismo de backup para los hipervisores ESXi. Si no lo hace el proveedor, es obligación del área IT interna completar la solución.


La obligación contractual del proveedor IT, siempre tiene un límite práctico: el tiempo máximo contratado y qué tanto trabajo se puede hacer durante ese tiempo. Aunque y a pesar de que se suele contratar: 
- "soluciones completas", 
- "soluciones llave en mano", 
- "soluciones integrales", 

y demás buena jerga de vendedor IT, por más que esté "prometido" las soluciones provistas por un tercero nunca van a poder ser integralmente completas, sino solamente van a estar de acuerdo a lo contratado (una lista de tareas que figura en el contrato), cualquier tarea adicional, paga o no, es a discreción y buena voluntad del tercero proveedor. 

...A menos que directamente se los contrate permanentemente para hacer el trabajo del área interna IT...ooops, pero ese contrato también tiene una duración máxima, así que no, no es posible sostener la tercerización ilimitada, siempre va a haber que pagar más o contratar servicios adicionales para poder tener una tercerización ilimitada (por eso es tan buen negocio por cierto :-).


Conclusión
Es bastante seguro decir, falta de presupuestos infinitos mediante, que eventualmente toda organización/empresa se va a volver a hacer cargo de sus propias necesidades de informatización, y lo mejor es que sea lo antes posible y con el mejor grado de previsión y responsabilidad.

Cómo medir el "cómo" y no el "qué" en performance laboral en IT

Métricas laborales IT

Uno de los problemas más usuales para los laburantes IT cada fin de año se da con la aparición de los resultados de los Performance Management (PM) Processes:

http://en.wikipedia.org/wiki/Performance_management
".. includes activities which ensure that goals are consistently being met in an effective and efficient manner."

"..incluye actividades las cuales aseguran que los objetivos son consistentemente alcanzado de modo efectivo y eficiente."


Performance Management "para la fábrica"
El modo estándar típico de ver qué tan bien labura un empleado, fuera de ámbitos informáticos es variado, una simplificación muy burda y rudimentaria se puede hacer reduciendo todo el análisis de PM a ver si el trabajo de un empleado responde positivamente a la respuesta que espera el "jefe" a la pregunta "¿Tu empleado hace lo que vos querés que haga?".

Es verdaderamente básico y por ende las mediciones típicas incorporan varios criterios más, a los efectos de "salpimentar" un poco de "realidad" el resultado del PM.

Como ven, el análisis PM típico, clásico, tradicional, se enfoca fuertemente en el "Qué", y no el "Cómo".

Es un enfoque de análisis de rendimiento de un empleado que se ha demostrado fuertemente incompatible con resultados que reflejen efectivamente la realidad de qué tan bueno y qué tan bien trabaja un empleado que realiza tareas altamente especializadas y no repetitivas. 

[En constrate positivo, ese mismo tipo de análisis funciona muy bien con tareas no especializadas y repetitivas, básicamente hablamos de "cantidades simples de algo, realizada en base a un plazo" > Cuantos jeans cosió un costurero en el año (desglose por mes), Cuantas chapas cortó un operario por día/semana/mes/año, etc. etc.]


La "fábrica" y los equipos de trabajo IT
Un craso error habitual en la medición de rendimiento de un empleado IT es que RR.HH. asocie "la fábrica" con el modo de trabajo de un equipo IT. Ello suele culminar con la adopción de un proceso de performance management que se orienta a la medición de "qué" hace el empleado, y no en el "cómo".

En el caso de IT, el "cómo" es vital para la mayoría de las tareas de nivel técnico de medio a alto. Por ejemplo: no es lo mismo que un buen developer escriba 20.000 líneas de código por año, de altísima calidad vs. un developer novato que escribe las mismas 20.000 líneas.

Muy similares ejemplos existen en otras especialidades IT complejas: project management, adm. de sistemas, adm. de redes, adm. de bases de datos, management IT, etc.



El problema al medir el "qué" en IT
El problema que suele tener RR.HH. para medir los "cómo" es que si bien la recolección de datos puede ser automatizada y/o sistematizada, la evaluación de performance suele quedar fuera de las áreas IT, es decir, el análisis queda en manos de personas que tienen menos entendimiento real/profesional de las tareas que los mismos empleados IT.

En el caso típico de la "fábrica" y sus tareas simples y repetitivas, no es mayor inconveniente, casi cualquiera de nosotros entiende mayormente los entresijos de cortar una chapa con maquinaria, al menos luego de una mínima introducción.

Sin embargo, es muy difícil - mucho pero muy difícil - que alguien que no escribió nunca un programa de computadora, entienda realmente el valor del código escritor por un developer, comparandolo con otro código de otro developer.

La solución es simple: la persona que evalúa el rendimiento de un trabajo IT especializado debe ser un especialista en ese trabajo, y debe tener un nivel técnico superior al de aquel que está siendo evaluado.

Más o menos es la misma idea de fondo que hay cuando vamos a estudiar un curso en la facultad: el profesor tiene que saber más que el alumno, sino los resultados no son fiables.


La medición del "cómo"

Las metodologías modernas de medición de rendimiento basada en el "cómo" se hace un trabajo (en vez de "qué" se hace en el trabajo), nacieron en los 70' de mano de algunas técnicas que fueron evolucionando y se diversificaron, justamente para adecuarse a los campos de especialización con los que estaban tratando.


Sabermetrics
http://en.wikipedia.org/wiki/Sabermetrics

Fue una de esas metodologías, y nació para ser utilizada para medir la performance de jugadores de equipos de beisbol. Al momento ya fue adaptada para medir la performance de practicantes de otros deportes ( http://en.wikipedia.org/wiki/APBRmetrics ).

La base de las metodologías de evaluación de performance basadas en el "cómo" es establecer cuales son las características deseables en un empleado. Esta parte es clave, se enfoca directamente en el "cómo" debería hacer algo idealmente un empleado, obviando sistemáticamente el "qué" hace el empleado.

Otra cuestión clave es detallar el mayor número posible de características deseables relativas al trabajo. La simplificación y la reducción de características están fuertemente contraindicadas, hay que intentar aumentar al máximo la clasificación en características especializadas que son deseables para el trabajo del empleado a la vez que se pone un especial énfasis en incluir características que no están exactamente relacionadas con el trabajo del empleado.

Un ejemplo burdo
Por ejemplo, en un developer C#, una característica "no relacionada" podría que fuera muy bueno configurando e instalando switches Cisco L2/L3, o que fuera muy buen pen-tester web en seguridad IT.

[Como ven, el listado de características deseables no se sale del marco de trabajo IT en gral., pero sí se sale completamente del centro habitual de considerar solo las características deseables propias del puesto de trabajo donde se desempeña el empleado específicamente (que es algo obligatorio de hacer en las metodologías tradicionales focalizadas en el "qué").]

Una vez que están definidas todas esas características, se puede realizar valoraciones numéricas con un tope, del 1 al 10 en cada característica. Luego, se busca correlacionar las puntuaciones individuales entre características complementarias según el marco de trabajo del empleado:

Por ejemplo, si un empleado conoce mucho de instalación de servidores Windows, y a la vez es buen developer C#, y a la vez se encarga de trabajar con un cliente que tiene pobremente configurados sus servidores Windows (y/o que está buscando actualizar la versión de los mismos, o migrar a una arquitectura más compleja/mejorada, etc.). Entonces este empleado se convierte en un "jugador valioso".

En contraste un buen developer (tan bueno en C# como el anterior), trabajando para el mismo cliente, no tiene tanto valor como jugador para el equipo...pero podría tenerlo en otro contexto!


La clave de las mediciones de performance por "cómo" vs. "qué" está en eso, encontrar las relaciones ocultas entre capacidades (skills), altamente especializadas, el contexto de trabajo y obtener información detallada y puntual que permita re-ordenar y re-asignar posiciones buscando lograr los mejores resultados.

Y eh aquí el objetivo: Las sabermetrics, usadas en el contexto del beisbol, permitieron cambiar de posiciones a jugadores, buscando optimizar las capacidades combinadas - sumadas - de todos los jugadores para obtener el máximo resultado posible para cada característica deseable necesaria en el trabajo del equipo.

Es decir, una vez que se obtiene los datos, se puede reorganizar la producción y las tarea del equipo IT, de modo tal que - por ejemplo - al colocar en una hoja de cálculo, de modo horizontal, de izq. a derecha...

Nombre de Empleado - Característica 1 - Característica 2 - Característica 3

...se obtenga el máximo posible en cada característica. 

De esta manera, si aparece por ejemplo un cliente con infraestructura basada en servers Linux y necesita developers C# y nuevos servers Windows, pero a la vez no va a dejar Linux, el equipo de trabajo disponga de todos los skills primarios - developers C# - y accesorios, tendientes a lograr los mejores resultados posibles en la asignación.


Recién luego de disponer de todos estos componentes para el análisis: características deseables, valoraciones por característica, y organización/contexto de la tarea del empleado (y posibles planes de reasignación/reoptimización de tareas), se podrá obtener una valoración real de los skills y del desempeño de un empleado en un equipo IT.

Por ejemplo, si tenemos un empleado A, administrador Windows, y lo ponemos a trabajar instalando aplicaciones para un cliente que usa servidores Linux, de seguro que su rendimiento va a ser bastante bajo. Si tenemos un empleado B, administrador Linux y lo ponemos a instalar aplicaciones para ese mismo cliente, va a descollar. 

La asignación es "instalar aplicación XXX en el cliente", a igual nivel de skills para instalar la aplicación XXX, el empleado B va a tener mucho más éxito y mejor performance que el empleado A.

Ahora si tenemos al empleado A trabajando con servers Linux, podríamos buscar ponerlo a trabajar en algun cliente que tuviera servidores Windows, y veríamos como despega su performance.

Traducción: "Los buenos managers lideran a través del equipo"

Consideramos la habilidad de manejar un equipo tan importante que, en un libro reciente, la hicimos uno de los "3 Imperativos para convertirse en un gran líder".

"Manejar tu equipo" - el primer imperativo - se trata de crear un equipo real y manejarlo. Para el registro: los otros dos imperativos son "Manéjate a ti mismo" - lo cual es acerca de construir relaciones basadas en la confianza, no en la autoridad - y "Maneja tu red", lo cual es acerca de conectarse y colaborar con aquellos que no controlas.

"Manejar tu equipo" podría parecer claro y directo. Incluso cuando hablamos de ello, encontramos a menudo que no es un concepto intuitivo para muchos managers y para algunos incluso va en contra de lo que piensan que deben hacer como jefes.

Tal vez el modo más fácil de explicar el problema, tal como lo entendemos, es través de la frase que usamos arriba, manejar "a través del equipo". Por ello queremos decir que deberías usar las dinámicas sociales del equipo para manejar a los miembros individuales, en vez de manejarlos primariamente uno-por-uno. Esto es una diferencia crítica que muchos managers no ven. A pesar de alabar los beneficios del trabajo en equipo, insisten manejar sus equipos individuo por individuo. Así, virtualmente se aseguran que sus grupos nunca se volverán verdaderos equipos.

Cualquier grupo no es un equipo. Muchos grupos no son equipos de hecho, y por eso es bueno comenzar con una definición: un equipo es un grupo de personas que hacen un trabajo colectivo y que están mutuamente comprometidos a un propósito común de equipo, y a objetivos desafiantes relacionados a ese propósito.

Los equipos son más productivos e innovativos que los meros grupos de trabajo. Los equipos producen resultados que exceden lo que los grupos de individuos - a través de la simple cooperación y coordinación - logran. Tales resultados reflejan el "efecto equipo": los miembros rinden mejor cuando se sienten parte de un equipo. La raíz de este beneficio es el compromiso mutuo fuerte de los miembros hacia su trabajo conjunto. Este compromiso crea lazos emocionales y sociales entre los miembros del equipo, quien llegan a pensar en que "nosotros" vamos a tener éxito o fallaremos juntos, y que nadie puede tener éxito individualmente si el equipo falla. En cada equipo, "nosotros" triunfa sobre "yo". A menos que te sientas parte de un equipo tu mismo, es difícil entender los alcances de lo que este sentimiento de "nosotros" puede llegar a lograr.

Este compromiso mutuo, este "nosotros", el poderoso lazo interpersonal entre los miembros del equipo, viene de dos fuentes relacionadas:

1) un sentido mutuo de propósito: Cada equipo de alto rendimiento cree que existe por una razón de peso y que el mundo será mejor por lo ellos hagan. Su propósito no es la tarea o el trabajo que hacen, sino los beneficios que ello brinda. Hay una diferencia entre "Limpiamos los pisos del hospital" y "Prevenimos que las infecciones se propaguen". Esto es lo que une a la gente y los hace sentir parte de algo más grande que ellos mismos.

2) Objetivos tangibles basados en ese propósito. El propósito debe ser concreto o pronto se diluirá. Para sostener su sentido de propósito, cada equipo necesita apuntar a  logros específicos y reales que proveerán a ese propósito.


En pocas palabras, propósito y objetivos relacionados son el pegamento que mantiene unido a un equipo. Un propósito sin objetivos concretos, es un solo un sueño. Objetivos sin un propósito, son actividades sin sentido.

Pero, aunque sean críticos, propósito y objetivos no son suficientes. Un equipo también necesita claridad. En particular, los miembros de un equipo necesitan:

- Responsabilidades y roles para cada miembro, no todos pueden hacer todo.

- Procesos de trabajo que importen, el modo en que el equipo hace su trabajo, como por ej. tomar decisiones.

- Valores, normas y estándares que definan qué se espera de los miembros del equipo, por ej. cómo se deben manejar las personas en un conflicto.

- El tipo de métricas y feedback necesario pare medir si hay progreso en el trabajo.

Puede haber más detalles finos sobre aspectos de infraestructura de un equipo, pero son necesarios para mantener el flujo de trabajo funcionando bien y para minimizar los conflictos destructivos.

Cuando todas las condiciones antes mencionadas estén presentes y el grupo se vuelva un verdadero equipo, sus miembros rendirán a un alto nivel no porque su jefe lo demande, sino porque sus colegas de equipo esperan que así sea. Los miembros trabajan duro para apoyarse mutuamente y no fallarle al equipo.

En efecto, luego de eso, el equipo se está manejando a sí mismo. Si un miembro del equipo falla en su rendimiento, los demás miembros se lo harán saber. Así, el rendimiento está dado por los vínculos sociales y emocionales entre los miembros, no por las expectativas de su jefe. Cuando esto ocurre, el manager está manejando a través del equipo usando los vínculos entre los miembros para darle forma al comportamiento del equipo.

Es un más efectivo método de administración porque crea mayor compromiso y esfuerzo de parte de los individuos involucrados.

Pero no es obviamente un modo confortable de hacerlo para aquellos jefes que necesitan "estar a cargo" y quieren creer que su equipo tendrá éxito debido a su influencia directa como jefe. A este tipo de jefes en particular no les gusta el hecho de que crear un equipo requiera un modo tan "indirecto", como cuando un jugador de pool hace un tiro hacia un borde en vez de tirar directo hacia una esquina. No se dan cuenta que el modo "directo" que ellos prefieren muy probablemente garantizará que su grupo de trabajo no se convierta en un equipo de verdad.

Los equipos de verdad emergen espontáneamente cuando las condiciones correctas están presentes; un equipo no puede ser creado por decreto. El jefe no puede dictar un propósito unificador, los miembros el equipo deben elegir uno por sí mismos (aunque ciertamente pueda ser uno que el jefe ha sugerido y el equipo ha discutido).

Así que, en vez de imponer y dar directivas, tu, como líder de equipo, tienes que sugerir, apoyar, definir, enfocar, hablar al respecto, tener expectativas, contratar para ello, liderar discusiones al respecto y evaluar el rendimiento vs. las condiciones que fomentan la formación espontánea de un equipo. Tu autoridad formal puede ser útil para dirigir el tiempo y atención de la gente hacia los temas y condiciones correctas.

Al final solo los miembros de tu grupo pueden volverse ellos mismos un equipo al sentirse libremente comprometidos ellos mismos con un propósito común.

Tu trabajo como líder de equipo es fomentar y luego sostener las condiciones que ayudan a que lo anterior pase. Puede que tu no te sientas completamente cómodo con tal método indirecto, pero así es como funcionan los equipos."

Traducción libre del original

Good Managers Lead Through a Team