Cómo hace el equipo de Operaciones para detener los problemas en sus vías

Traducción del original:
How the Technical Operations team stops problems in their tracks


Cómo hace el equipo de Operaciones para detener los problemas en sus vías

La semana pasada leías sobre como el equipo de operaciones técnicas de la Fundación Wikimedia ("Ops"), gastó centenares o miles de horas de trabajo para refactorizar y automatizar todos los servicios que provee, para prepararse para la migración de datacenter de Enero. Una recompensa de ese trabajo: nuestros sitios no estuvieron caídos tan a menudo, y cuando lo estuvieron, el downtime fue por buenos motivos.

"Otra cosa que ilustra nuestro crecimiento y madurez es nuestro downtime" dice el ingeniero de Operaciones Peter Youngmeister.

"Algo que es menos visible para la gente fuera de Ops es la clase de downtime que tenemos. Por ejemplo, ya no tenemos más el tipo "Oops, solté un cable" o "Ese server la palmó", porque las cosas son mucho más robustas ahora, mucho más redundantes. Un montón de eso es producto del masivo impulso a la automatización por el que pasamos, el cual nos permite crear redudancia mucho más fácilmente, y nos deja ocupar nuestro tiempo, en vez de estar "apagando incendios".

El ingeniero de la Fundación Wikimedia Roan Kattouw añade "o 'el server DB maestro tiene el disco lleno' - esa ocurrió unas pocas veces años atrás, y ya no ocurre más ahora."

Para arreglar las crisis rápidamente, necesitamos monitoreo: herramientas que automáticamente chequeen por problemas y alerten a nuestros ingenieros cuando algo está roto. En los primeros días de nuestros sitios, simplemente confiabamos en que habría algun sysadmin online y disponible en caso de que alguien notara algun problema y se quejara en IRC. Varios años atrás, comenzamos a usar Nagios para monitoreo y asignamos una rotación de "pagers", para decidir a quien despertar primero en caso de crisis.

Nagios corre test automatizados chequeando el comportamiento de nuestro sitio (como "¿Devuelve el puerto 80 un HTTP 301?"), y chequea ciertos números clave para asegurarse que los valores encontrados están dentro de un rango aceptable (por ejemplo, para testear y ver si nos estamos quedando sin memoria). Si un test falla, Nagios envía alarmas vía emails, IRC y SMS.

El monitoreo nos ayuda a manejar la crisis rápido, pero a menudo no ayuda a resolver el problema en sí.

"Nagios es grandioso para decirte cuando las cosas están rotas, y es basura para decirte por qué", explica Peter. "El trabajo que Asher Feldman ha realizado creando perfilado de datos (data profiling), es más útil".

Como lo explica Roan "Perfilado de datos es el acto de generar datos sobre 'Cuanto tiempo ha gastado la gran tarea X en realizar la subtarea Y' La razón para ello es que:

1) Uno de esos pequeños Ys podría en realidad no ser tan pequeño y ser un problema
2) Por la regla de 80-20, para algunos Ys, la optimización tendrá un impacto mayor, así que hace falta encontrarlos.

El perfilado de datos genera conocimiento acerca del comportamiento de nuestros sistemas, así los ingenieros pueden entender mejor como debería estar funcionando el cluster, y ofrece tips para resolver problemas.

Nosotros usamos dos sistemas de perfilado para obtener datos en tiempo-serie: Ganglia a nivel de host, y Graphite a nivel de aplicación. (conseguíte un login al Labs para ver Graphite). En los pasados dos años, configuramos Ganglia para cubrir muchos más datos, y en 2012 empezamos a usar Graphite. A mejores datos, se vuelve más útil para la resolución de problemas, y el Director de Operaciones CT Wook regularmente revisa el dashboard para ir viendo problemas por venir y alertar a su equipo. Esto reduce los downtimes.

Por ejemplo, en una página de Ganglia, previamente solo teníamos acceso a datos de host: espacio libre en disco, carga, etc. Recientemente añadimos datos específicos de Apache, como request por segundo y número de threads idle. Esta información adicional ayuda a los sysadmins en la resolución de problemas. "Uno puede verlo y hacer mejore deducciones que solo 'Oops, el server tiene mucha carga'," explica Peter.

Como la "puppetización", las mejoras en perfilado fueron una inversión del equipo de Operaciones. "Hay un plugin para Ganglia que arma estadísticas de performance de Apache. Me costó horas configurarlo totalmente, Pero, de vuelta, es pensar hacia adelante, una deuda que debemos honrar, en vez de insultarnos a nosotros mismos cuando no esté allí - esa información - cuando la necesitemos. Es un emprendimiento masivo decidir hacer las cosas del Modo Correcto, configurar una plataforma, en vez de hacer millones de cosas de 'una-sola-vez'."

Mientras que la "puppetización", mejora del monitoreo y perfilado, preparaban para la migración de datacenter, el equipo de Operaciones tuvo que diferir otros trabajos no urgentes. "Ops era menos capaz de dar soporte a muchos equipos", dice Peter, "por ejemplo, Recolección de Fondos solo tenía unos cuantos servers y podían hacer con ellos lo que quisieran, a diferencia de cómo es ahora donde Jeff Green (un ing. de operaciones), está trabajando en armar un asombroso sistema, PCI-compliant a tiempo completo. O Análisis era muy independiente/sin respaldo, porque había tan pocas horas/hombre para darles soporte que no estaban siquiera manteniendo el sitio activo..creo que el ensamble del EQIAD (el datacenter de Virginia), es muy demostrativo de la deuda técnica que tenía Ops."

Ahora Peter mira hacia adelante viendo a Wikimedia "instalar más datacenter, dramáticamente más rápido". El equipo de Operaciones está en preparativos para adicionar un datacenter en la costa oeste de Norteamérica. El Site Architech Asher Feldman ve un "arco continuado de refinamiento" en el futuro del equipo, en vez de "desafíos que terminan para ser reemplazados por nuevos desafíos". "Los desafíos en hacer escalar MediaWiki no van a dejar de existir a corto plazo, tampoco la necesidad de modernización incremental de la arquitectura en múltiples niveles". Por ejemplo, Ops necesita continuamente "puppetizar" ciertos servicios; algunos módulos también necesitan manifiestos Puppet tuneados para funcionar, no solo en el site principal, sino también en los Wikimedia Labs.

Podés chequear los objetivos del equipo de Operaciones para 2012-2013 y leer sobre lo que viene a continuación (incluyendo mejoras en búsquedas y seguridad).

Sumana Harihareswara, Engineering Community Manager

Copyright notes: NOLA Hackathon 20 by Ben Hartshorne, under CC-BY-SA 3.0 Unported, from Wikimedia Commons, Eqiadwmf 9045 by Rob Halsell, under CC-BY-SA 3.0 Unported, from Wikimedia Commons

Otro par de cosas a considerar para armar un equipo interno de desarrollo

Contratar un equipo interno IT es parecido a abrir una clínica privada y contratar médicos para que la atiendan, divido los emprendimientos por "tipo":

Tipo 1 - (supongamos que podés abrir una clínica privada y atender pacientes con estudiantes de medicina), podés contratar novatos y que atiendan la clínica. Así va a salir en costo y tiene ciertas - pocas - chances de éxito.

Tipo 2 - Podés contratar médicos egresados, recien terminada la residencia y así le va a ir a la clínica, un poco mejor que en el caso 1).

Tipo 3 - Podés buscar un cardiólogo, un neurólogo, un ginecólogo, una kinesióloga, etc. de años de experiencia práctica y reputación profesional, que casi seguramente van a dejar sus trabajos actuales (mínimamente, bien pagados), para ir a la clínica. Eso va a tener otras - diferentes - chances de éxito y a la vez un costo muy diferente, más alto.


Contratar un equipo de profesionales IT competentes no es diferente a contratar un equipo de médicos, pero en el ambiente IT algunos se animan a "probar" con la opción 1), otros tratan de "formar gente" con la 2).  

La opción 3) no llegué a verla todavía en Corrientes, pero creo que no debo conocer el caso nomás, seguramente en algun lugar hay algun equipo IT altamente competente - alto nivel técnico en serio y no hablo solamente de gente con titulación / suerte / acomodo político y demás posibilidades  - y muy bien pagados 

Como parámetro para buscar un equipo IT "Tipo 3" tengo: un médico de prestigio - 10-20 años de experiencia y alto nivel de actualización - en una clínica privada de Ctes. (Argentina), de éxito está en sueldos mensuales de cinco guarismos fácilmente, y siendo socio pueden llegar muchas veces a beneficios de 6 guarismos en algunos meses (en invierno típicamente, o en verano si hablamos de clínica especializadas en maternidad).

Volviendo al ejemplo de las clínicas privadas, normalmente los médicos contratados por las clínicas privadas (cuando no son socios directamente), responden en gral. al ejemplo 3) (hay excepciones como en todo). Y de ahí vemos el nivel de éxito que tienen esos "casos 3)", profesional y económico.

Un par de cosas importantes a considerar para armar un equipo interno de desarrollo

IMHO, "cosas importantes a considerar para un equipo interno de desarrollo" (van a ver que lo pueden aplicar a "cosas importantes a considerar para un equipo IT" en gral.):

- Capacidad Técnica
- Capacidad Humana
- Excelente Administración de los RR.HH.


* Capacidad Técnica
La gente que labure en un equipo tiene que tener la capacidad técnica para resolver el trabajo que es responsabilidad de ellos. Si no saben hacer el laburo para el que les pagan, y la empresa necesita que lo hagan "ya o ya mismo", entonces la empresa va a tener montones de problemas.

Cabe la posibilidad de darles tiempo de aclimatación/training previo, antes de poner el equipo en producción, pero ese tiempo debe estar bien administrado (y claro, alguien va a tener que "cubrir" el servicio no provisto por el equipo a la organización mientras se "aclimatan"). Cabe señalar que la "falta de capacidad técnica actual con opción a training" solamente está "permitida" para los miembros del equipo, los jefes de equipo (o alguien, cualquiera), debe tener capacidad técnica desde el día 1 (uno), para dirigir el aprendizaje del equipo y manejar bien ese tiempo de preparación dado al equipo antes de entrar a producción.

En mi experiencia, en los equipos donde todos los miembros (o casi todos), carecen de capacidad técnica efectiva para el trabajo que les encomendaron, no importa el tiempo de training que se les de, normalmente las cosas no funcionan bien. El motivo es que un equipo así es una "gallina sin cabeza" (si me disculpan la métafora brusca), porque corren para todos lados, y no tienen cómo pensar a donde van yendo.

En este caso, Ojo, darle a un equipo "un tiempo" para que "acostumbren", para "formarlos" no quiere decir darles 2 años para que aprendan cómo trabajar, especialmente si durante esos dos años los errores van a costarle mucho dinero/recursos malgastados/tiempo a la organización. 

IMHO, alguien tiene que saber "algo", desde la práctica profesional no se puede armar un team de 100% novatos y querer formarlos a todos "on the job", mientras hacen el trabajo (que no saben hacer recordemos). 

Más o menos es mandatorio - por puro y simple sentido común - que la persona que "sepa" tenga que ser el jefe del equipo, por contraste, imaginen un jefe que no tiene capacidad técnica y dirige a miembros de equipo que no la tienen, y tiene uno o dos miembros que sí tienen capacidad ¿Cómo termina el cuento?


* Capacidad Humana
Estos tipos tienen que saber laburar bien (o como dije antes, alguno debería ya tener experiencia), "ponerse la camiseta", como dicen los jefes habitualmente, frase que está un poco sobre-utilizada, pero es aplicable a este caso.

El laburo IT tiene esto de tener que quedarse fuera de hora a veces, o ir la "extra mile" (la "milla extra"), para lograr los objetivos. Los miembros de un equipo tienen que estar al tanto de eso.

También tiene que haber un convencimiento común de que están laburando para algo, útil si es posible, con un objetivo. La capacidad de liderazgo debe estar presente para que esto ocurra, como ya dije y redundo aquí, alguno tiene que "saber algo" (saber cómo ser un buen líder de equipo cuenta como "saber algo").


* Excelente administración de los RR.HH.
Ninguna de las dos anteriores se va a dar - o va a durar poco - si no existe una buena base (o sea esto es "fundamental", en el estricto sentido literal de "fundamental"), laboral. Las retribuciones/sueldos/condiciones de trabajo para la duración del proyecto en el que el equipo va a trabajar tienen que estar de antemano acordadas. Eso incluye sueldo, horario, vacaciones ("esto" de las vacaciones es MUY importante para los empleados por cierto, más que los aumentos de sueldo típicamente), aumentos de sueldo y su criterio exacto (el por qué y cómo van a conseguir aumentos de sueldo, y no olvidarse de la inflación), objetivos laborales a cumplir, un buen manejo de los cambios en la relación laboral(recordemos que los cambios en la relación laboral deben ser de común acuerdo), por ejemplo, si le agregan responsabilidades a un miembro del equipo, hay que preguntarle primero y luego proponer un ajuste apropiado en la retribución, etc. Básicamente, debe haber no una buena, sino una excelente administración de los 
RR.HH.

Un ejemplo negativo: si la empresa/organización le da más responsabilidades a un miembro del equipo, unilateralmente (y se tiene que quedar más horas a laburar, o peor), y aparte no le mejoran la retribución. ¿Qué es lo más probable que haga ese miembro del equipo? 

"That's Why" dicen los americanos para estos casos, "Ese es el por qué", en jerga local sería "Aaaah, por eso era". Por eso hablo de necesitar "excelente administración".

Sin ese nivel de excelente administración de los RR.HH. (para con el equipo), la inversión de la organización, corre un altísimo riesgo de perderse y/o malograrse. Olvídense de que el equipo tenga éxito a corto plazo, lo contrario es más probable que ocurra (y si no se corrije, ese mal desempeño persiste a mediano y largo plazo).

Recordemos que los individuos tienen una flexibilidad de acción mucho mayor que las organizaciones (un tipo renuncia y a los dos días/dos meses ya está laburando en otro lugar), una organización pierde un miembro de equipo con dos años de experiencia y training, y lo recupera a duras penas, con un alto costo económico en gral. (el nuevo miembro de equipo típicamente "le sale" más caro, por simple actualización por inflación y de sueldo promedio de mercado, que es bastante mayor que los aumentos anuales típicos), y se pierde todo el expertise especializado en la organización que tenía el miembro de equipo saliente. Si la organización no dispone de los medios económicos para solventar la diferencia de precio en el costeo del recurso (el nuevo empleado), no se recupera el recurso perdido hasta tener la plata (así de simple suele ser).

El training IT inutil

De vuelta, les traigo una temática IT del día a día del IT guy; tambien comentada en el sentido que van a llegar a encontrar - lamentablemente y si no lo pueden evitar - luego de algunos años de trabajo en el ambiente IT. Encontré raro que estas nociones sean discutidas abiertamente en charlas IT, y aunque que no sean abiertamente comentadas, no implica que no sea una realidad laboral habitual en muchas organizaciones.




Intento de training
A veces una organización IT intenta "entrenar" a su personal en una tecnología nueva utilizando cursos/training audio/visual, ya sea presencial, como no presencial, incluyendo casi siempre breves sesiones prácticas; más o menos, en proporciones, este tipo de training dedica un 80% del tiempo en teoría, y un 20% en prácticas.


Por ejemplo en 100 horas de training, se realiza 20 horas de prácticas.


Luego de un exitoso entrenamiento de 80 horas en una tecnología que requiere esa cantidad de horas para ser explicada - en muchos casos solo básicamente - ¿Qué sucede si luego deviene una espera de 2 a 6 meses antes de implementar esa tecnología en el día a día, en el trabajo diario? y ¿si además los empleados entrenados se dedican el 100% del tiempo a trabajar en OTRA/s tecnología?


Sucede que el entrenamiento se vuelve inútil. Es inútil asignar 80,100,200 horas de training a un empleado, realizados durante las horas de trabajo (con la consiguiente pérdida de productividad e inversión económica implícita), si luego no se va a utilizar o se utiliza muy poco la tecnología en la que se entrenó a esas personas.




Las consecuencias (las reales)
El resultado típico de la inutilidad del entrenamiento es que luego de 2 a 6 meses (o un AÑO o dos) de terminado el training, la organización espera que al momento de entrar en contacto diario con la tecnología en la que los empleados están "capacitados", se produzca un salto cognitivo de 0% a 100% en entender, recordar y poder aplicar el "entrenamiento". El salto productivo esperado es el mismo, se espera un 100% de productividad.


Es aún mucho peor el resultado de esperar 2 a 6 meses (o más de un año), y luego intentar introducir la tecnología "de a poco", pidiendoles a los empleados que trabajen con ella una o dos horas, cada varios días; o durante medio día cada dos semanas, o - sustancialmente peor - un día o dos mes de por medio.


[En mi experiencia, el management suele esperar justo lo contrario, que empezar a trabajar "de a poco" en sistemas en producción, "funcione" Y que los IT guys al estar "entrenados" cometan cero (0) errores al operar sobre sistemas en producción. Ambas cosas que nunca he visto suceder a lo largo de mis años de experiencia.]




Entrenamiento vs. Implementación
El training IT típico y sus correspondientes horas de práctica son en general y por si mismos inutiles como capacitación para administrar ese software en un ambiente de producción real. Es muy diferente aprender sobre las capacidades de un software versus implementarlas, adaptarlas para su uso en un ambiente informático real (con sus requerimientos).




Ambiente de testing: el único modo en que funciona
El modo en que un training "funciona" y las horas y dinero invertidos por la empresa resultan efectivos es introduciendo el uso de la tecnología planificadamente, en un ambiente de testing, planeando una curva de aprendizaje práctico que repita las condiciones de la práctica del training pero ya ajustadas a las realidades de implementación puntual de la tecnología dentro de la organización.


La falta de un ambiente de testing real, o incluso el desalentar - como política informal - a los empleados de utilizar tiempo durante las horas de trabajo en realizar práctica en un ambiente de training - resulta desastroso; la práctica real se termina realizando - forzadamente - sobre sistemas en producción, obviamente, cometiendo muchos errores, dañando la funcionalidad del sistema en producción o implementando configuraciones ineficientes o defectuosas en grado sumo. 


Adelantandonos un poco: IT guy experimentado va a notar la falta de sentido común, y NO va a invertir horas de su tiempo libre en corregir la brecha creada por una mala política de capacitación, efectivamente afectando mayores horas de trabajo - forzosamente - al re-entrenamiento, ello se dará luego de sucesivos fallos durante el trabajo directo con sistemas en producción (importantes porque además de entrenar, hay que reparar los sistemas dañados).




La NO efectividad de exigir
Si en las condiciones de training explicadas, el management exige a IT guys experimentados el 100% de efectividad y productividad, lo que - siempre - ocurre es que la respuesta es un "sí, se puede", dado el obvio desbalance de poder en la relación y la obvia falta de sentido común en la exigencia de un 100% de productividad y efectividad, que es, desde el punto de vista del empleado, muy clara.



En cambio, los IT guys novatos suelen confundirse y suponer que las diversas consecuencias:

- El no alcanzar el 100% de productividad/efectividad, 
- Los posteriores errores y fallas que terminan dañando los sistemas en producción
- Las malas arquitecturas que se concretan en sistemas inefectivos o con malísima performance (respecto de las buenas capacidades reales del software, obviamente esperadas).
- Etc.


..son su responsabilidad y que realmente debería haber memorizado palabra por palabra un training de 80 horas, y no haber tomado notas detalladas y paso a paso de las 20 horas de práctica. En el siguiente training, hacen eso (memorizar todo y tomar notas detalladas de las prácticas), y luego, se terminan dando cuenta de cómo funcionan las cosas realmente.


Reclamar
La respuesta típica a los cuestionamientos de "training IT inutil" es que "hay que reclamar". El reclamar que se dirima esta cuestión en base al sentido común cuando personas racionales, gerentes IT típicos intentan hacer "que llueva para arriba", ya conlleva una circunstancia al menos inusual. 
También es habitual que los "reclamos" suelan resultar inutiles - "caer en saco roto" - al chocar de frente con bajadas de línea desde altos niveles gerenciales que - obviamente - no van ser explicadas por un gerente  de nivel inferior a sus empleados. Esas exigencias desde el alto nivel gerencial - tal como son, así de razonables y contraproducentes para la economía de la organización - suelen crear un marco muy limitado dentro del cual los gerentes tienen que "bailar al son de la canción que les ponen".
De todos modos es recomendable, si se encuentran en una circunstancia de "training inutil", expresar sus inquietudes a quien esté a cargo.




Conclusiones
Estoy bastante seguro que dedicandole cierto tiempo podría encontrar los fundamentos que la psicología y el estudio de recursos humanos puede brindar al respecto de este tipo de esta modalidad educativa y su nivel de efectividad cuasi-nulo, por lo pronto simplemente les puedo transmitir que estas conclusiones se relacionan un par de miles de horas de training pérdido por empleadores durante años, en lo que es mi experiencia.


En contraste, los empleados no pierden nada en usar 100 horas de trabajo en un training, y luego tener que usar otras 100 horas para re-aprender y/o adaptar el conocimiento a las implementaciones locales, sino que al contrario, el nivel de especialización se suele volver mayor. Sin embargo ello no deja de ser típicamente una gran pérdida de dinero y tiempo para los empleadores.

Proyectos IT fallidos

No hay nada como participar de un proyecto IT que falla para aprender qué es lo que se hace mal en IT, a veces sin querer inclusive y con todo el training y la buena predisposición personal+laboral. Plus, se aprende que en IT, a veces el camino más corto de A a B no es una línea recta, y que ni un presupuesto gigante garantiza el éxito.

Lo que garantiza el éxito o fracaso de un proyecto IT, son las personas.


Algunas perlas de mi expertise-box personal de proyectos (es un pastiche, muy focalizado desde la visión de proyecto relacionados con Operations, y algo de sysadmin también):

- Software opensource y propietario, ambos deben ser evaluados para soluciones, si todavía no lo sabés, en algun momento te vas a dar cuenta (viendo de cerca los deadlines y la cuenta de presupuesto vaciandose).

- No importa qué tan caro sea un software, puede fallar, tener bugs, ser inusable (sí,esto quiere decir que habiendolo pagado, no se lo va a implementar finalmente), etc.

- Si el software es propietario, lo anterior sigue valiendo, más allá de lo que digan los sales engineer.

- No importa qué tan caro y propietario sea un software, qué tantos kg. de documentación incluya, y qué tantas horas de training se pueda hacer/obtener, puede ser increíblemente malo en el diseño/arquitectura, e imposiblemente difícil de deployar (implica un TCO - oculto - mucho más alto de lo esperado teniendo soporte (tel./mail)+documentación+cursos/training).

- Cuando la documentación de un software es inmensa, y todo el tiempo escuchan que el software es "fácil de instalar y administrar", sepanlo, no es fácil para nada, y al contrario, puede ser mucho más difícil de lo usual para otras opciones del mercado.

- Lo que vale de verdad respecto del soporte no es la palabra-promesa de los sales engineer en las reuniones de ventas, sino lo que dice el support agreement (leanlo con atención).

- No importa qué tan grande, fastuosa, vieja (X años/décadas de experiencia y demás sanata), popular ("tenemos de clientes a fulano"),  sea la empresa vendedora del software, todo lo anterior sigue siendo válido.

- Nada de lo que no esté supported por el vendor va a ser soportado de forma "extra", "favor de amigos", etc. por el reseller local. Hay honrosas, escasísimas excepciones y siempre son por tiempo limitado, y sin hacerse responsables - desde lo legal - de lo que pueda o no arreglarse (o romperse), en ese support no oficial.

- Si no tenés un especialista en un campo, no esperes que tu "recurso" (el tipo que va a hacer el trabajo), se convierta en un experto en 1 mes, no va a pasar, y si lo pedís de jefe a empleado, te van a decir que sí, pero después tampoco va a pasar :-) true story. Lo real es planificar una curva de aprendizaje realista, que involucre no solo lectura de documentación, sino implementaciones en escenarios de testing (claro, hace falta agregar más tiempo al proyecto para hacer esto).

- (casi redundando) Los trainings no crean expertos, sino la práctica+experiencia, si tenés gente entrenada, no son expertos, sino personal capacitado. La diferencia es el tiempo: cuanto tiempo va a tardar en hacer X trabajo una persona capacitada, vs. lo que tardaría un experto.

- (redundando) Si los "recursos" ya tienen práctica, igualmente no son expertos, les falta la experiencia. Siguen sin llegar al skillset level de los expertos, hay que tenerlo en cuenta.

- (más redundante todavía) No le pidas peras al olmo: Un jr. de lo que sea, no es un experto, la inteligencia puede adelantar camino rápido (a tenerlo en cuenta si ves un jr. con muchas luces), pero no puede ganar experiencia sin haberla vivido (más o menos en realidad). Conclusión: ambigüa, hay Jr. increíbles, que se convierten en Sr. de una semana para la otra, pero hay que tener precauciones extras al basar cualquier proyecto esa presunción. Los Jr. son Jr. en gral.

- No le pidas peras al olmo 2: un experto no siempre es un experto, a veces solamente es alguien que tiene "trayectoria". La trayectoria, hace cuantos años se recibió, cuantas empresas fundó (teniendo éxito o no), hace cuantos años trabaja en IT, etc. No (NO), es una garantía ni reaseguro del skillset. Es una señal positiva únicamente ("podría ser que tuviera tanto skillset como dice tener"). Los RR.HH. lo saben, ahora vos lo sabés. En la pista se ven los pingos (más o menos tambien / en Argentina "pingo" es un apodo para un caballo).

- Me acordé, "en la pista se ven los pingos" es la muletilla nacional de RR.HH. para cotizar - a la baja - sueldos ("retribución" en jerga), de expertos IT. En lo personal la escuché en 5 provincias diferentes (so far). No (NO), es la "posta", escatimar sueldos para pagar expertos cuando se los necesita. No, la sumatoria de X cant. de Jr. (baratos y jr.-jr, no pibes excepcionales), no constituye el skillset de un experto. Este tip es universal, si no lo seguís, el proyecto "te lo hace saber" debidamente, sin importar en qué parte del mundo estés o qué idioma estés hablando (no es una amenaza, es una promesa).

- Debido a todo lo anterior, una buena estimación rápida de la relación bueno/fácil-de-implementar del software suele ser pedirle al sales engineer que explique la arquitectura de la solución, "cortito, en 10 minutos". Es una (mala)señal si te replica pidiendo una meeting de 2 horas (o peor), que invites a TODOS tus ingenieros (así entre todos logran "entender cómo funciona"), cañon, notebook para pasar slides de powerpoint, pizarrón, marcadores, etc.

- Si de todos modos tenés que usar ese soft (el de las 2 a 4 horas de explicaciones "básicas"), hay que hacer importantes previsiones respecto de la necesidad de expertos, training para Jr., etc.

- Un PM (project manager) de un proyecto IT debería tener un excelente background técnico respecto del campo puntual del proyecto (Networking, Adm., Desarrollo, DBs, etc.).
- Los PM sin background IT tienen el potencial de crear situaciones y circunstancias inverosímiles durante un proyecto IT ("no puede ser que en 2 años, con un proyecto tan chico y habiendo gastando X millones no se haya terminado", de hecho sí se puede).

- FTE. Este concepto parece extraterreste en muchos lugares (sería una mala señal darse cuenta de eso en un proyecto a realizar ahí). Me refiero a la idea (la sigla puede ser otra, según la especialidad, carrera, universidad, país donde se esté). FTE es la cantidad de laburo que puede hacer una persona por año. La ausencia de la consideración de FTEs suele ser una señal de que el tipo "a cargo" (gerente o lo que sea), no tiene mucho background de administración de organizaciones (ni se preocupó en adquirirlo tal vez, luego de cambiarse al campo gerencial).

http://en.wikipedia.org/wiki/Full-time_equivalent

Etc.

Y por supuesto, (casi) todo es relativo, el contexto exacto, el escenario puntual siempre tiene mucho que ver, o todo.

Van a leer mucho (un montón), de material sobre cómo se "hace bien" un proyecto IT, y hay muchísimo material bibliográfico. Lo que se "hace mal" no suele estar muy presente en las conversaciones, hay buenos libros, pero muy pocos sobre malas prácticas en proyectos IT.


Hay muchos más tips de los anteriores en mi box, pero les dejo estos otros (ajenos), para hacer el contraste:

http://spectrum.ieee.org/riskfactor/computing/it/queensland-health-payroll-system-one-of-the-worst-it-projects-ever
http://spectrum.ieee.org/riskfactor/computing/it/conclusion-of-uk-firecontrol-final-post-mortem-extraordinary-failure-of-leadership
http://spectrum.ieee.org/telecom/security/napolitano-cancels-the-us-1-billion-sbinet-virtual-fence-project
http://spectrum.ieee.org/riskfactor/computing/it/saic-agrees-to-forfeit-500-million-for-citytime-project-debacle
http://spectrum.ieee.org/riskfactor/computing/it/queensland-health-payroll-problems-just-go-on-and-on

Sldos.

yaco