Desastres organizacionales, cómo ocurren y cómo prevenirlos.

En mi experiencia como sysadmin ví explotar literalmente proyectos de toda escala presupuestaria, que quedaron inconclusos, penando las consecuencias de los recursos ya gastados sin haber conseguido los objetivos, por ello me volví afín al estudio de las causas sociológicas de los desastres organizacionales, leyendo material como el de abajo; que considero una buena introducción.

Lo de abajo me parece una muy buena noción inicial, es el primer párrafo del paper (traducido):

"Cuando pensamos en desastres organizacionales mayores, como el colapso de una corporación o un accidente en una planta química, tendemos a hacer dos suposiciones: que la falla fue causada por un error humano o por una falla de máquinas/equipamiento, y que la falla ocurrió súbitamente con poca o ninguna advertencia. De hecho, la investigación de desastres organizacionales sugiere que ambas suposiciones son incorrectas o al menos incompletas. Mientras el error humano o de máquinas/equipamiento puede ser el evento que precipita el desastre, tal error yace al final de una cadena de otros factores causales. Incluso más, muchas organizaciones incuban desastres durante largos períodos de gestación durante los cuales, los errores y llamadas de atención se acumulan. Aunque estas señales de alarma son doloramente claras en retrospectiva, ¿por qué es tan difícil para las organizaciones detectar, reconocer y actuar sobre estas condiciones precursoras antes de que se vuelvan una tragedia? Este estudio sugiere que las señales de alarma no son reconocidas y no se actúa por impedimentos en la circulación de información que causa que las organizaciones ignoren las señales de advertencia lo que permite a los errores crecientes y problemas escalar, llevando eventualmente a un quiebre a gran escala. Identificamos tres tipos de impedimentos de información derivados de la investigación teórica y de análisis de casos de desastre organizacional: puntos ciegos epistémicos, negación de los riesgos, e impedimentos estructurales."

http://www.researchgate.net/publication/235275618_Organizational_disasters_why_they_happen_and_how_they_may_be_prevented?ev=pub_cit_inc

Playbook para la buena gestión de servicios informáticos en una organización

La primer página del playbook ("Libro de Jugadas") para la gestión de servicios informáticos para una organización (incluye administración de infraestructura y soporte a usuarios por ejemplo), que estuvimos manejando en 2012 y 2013 con el equipo de trabajo del que formo parte hoy, es esta:

El Playbook (Libro de Jugadas)

Regla 1: Atender todos los pedidos de soporte y ayuda de los usuarios.
 
Regla 2: Atender los pedidos lo más rápido posible.

Regla 3: Atender los pedidos de cualquier importancia. No importa si es un usuario que no sabe cómo subrayar un título en un documento, un cartucho de impresora vacío o un switch que no funciona y deja sin conectividad a 20 usuarios. Hay diferentes prioridades, pero todos los pedidos de atención son atendidos.


Regla 4: Simplificar la arquitectura organizativa publicando - internamente - servicios de atención: X se encarga de soporte, X se encarga de gestión , X atiende servers & redes, X coordina y gestiona recursos con la organización, etc. Se evita la confusión, y los usuarios saben qué persona está manejando su problema, y trabajando para resolverlo.

 
Regla 5: Automatizar la gestión operativa, implica:
 
- Gestión de sistemas (trabajo de adm. de redes y servidores): Todas las tareas automatizables en la infraestructura deben llegar a ser automatizadas, a medida que se incrementa la automatización, se incrementa el tiempo disponible de adm. de sistemas que se puede re-utilizar en optimización/mejoramiento y en nuevos proyectos.
 
- Gestión organizativa (apoyándose en la Regla 4): Se evita al máximo la duplicación de tareas, por ende cada elemento del equipo puede realizar sus tareas más eficientemente (completa más tareas en igual tiempo que antes tomaba hacer menos cosas).

Regla 6: Aprovechar las oportunidades únicas de la "nube":
La adopción de tecnologías de virtualización nos permitió adquirir una flexibilidad muy alta para la rápida adaptación a los desafíos y requerimientos cambiantes en la gestión y administración de la infraestructura, tendientes a mejorar la prestación de servicios informáticos; siempre interactuando y unificando esta idea con los conceptos de las demás Reglas.

La Gestión organizativa puede ofrecer así a la organización, un nivel inusitado de posibilidades disponibles de inmediato para nuevos servicios y soluciones que se necesite, gracias a que la Gestión de sistemas va a poder absorber bien nuevos requerimientos, inclusive inesperados.

Muchos pasos cortos pueden completar un camino largo

La gente se acostumbró a ver el éxito en términos de la filosofía "jolibudense" de pocas, grandes acciones con resultados espectaculares, cuando en realidad son casi siempre, muchas pequeñas acciones, con poco brillo propio, pero que sumadas llevan una idea a concretarse.

Consolidar y desagregar/distribuir servicios en infraestructuras virtuales

Ayer en la Hackathon Express 2013, estaba conversando con un par de  IT guys y les comento que estuve trabajando con un cliente familiar para ellos, y que pasamos de unas pocas máquinas físicas a varias decenas de máquinas virtuales en producción, esto causó cierta sorpresa, principalmente porque la cantidad de servicios en producción permaneció más o menos igual, pero la cantidad de servidores virtuales parecía un poco elevada..en otras palabras, tal vez haría falta "consolidar".

Consolidar

Había hace un tiempo la tendencia a "consolidar": incluir la mayor cantidad de servicios posible de correr por servidor físico y por sistema operativo. Esta noción brinda ciertos beneficios por sobre tener muchos servidores y servicios en cada uno.

Sin embargo no es una visión correcta para ser aplicada en un entorno de infraestructura virtualizada. El fundamento detrás de "consolidar" se basa principalmente en limitaciones propias del hardware físico, que no existen más en las infraestructuras virtuales.

La idea principal de "consolidar" se daba cuando un servidor físico se iba haciendo "viejo", y se acerca al fin de garantía o ya lo superaba e iba en camino a ser descontinuado por el fabricante, aquí se buscaba "consolidar", concentrando la mayor cantidad de servicios posibles en servidores físicos que aún tenían garantía o que se encuentraban aún plenamente soportados - en partes y respuestos - por el fabricante.

Otra noción importante devenía del mejor aprovechamiento de recursos además del hardware con garantía: los mismos recursos del hardware (ram, procesador, disco, etc.), los recursos externos (alimentación, disponibilidad de conectividad, etc.). Al consolidar, los servicios se ubicaban de modo tal de poder acceder a un conjunto de ciertos recursos que tal vez no estuvieran disponibles en otro hardware (un server viejo fuera de garantía idealmente), o inclusive, accediendo a facilidades de recursos solo disponibles en el lugar físico donde se iba a reubicar - consolidar - los servicios (por ejemplo: algún link de fibra óptica más cercano al backbone y/o core de la organización, brindando al servicio potencial mayor conectividad hacia la red interna).

Es decir, si pensamos la idea de "consolidar" basándonos en infraestructuras puramente basadas en servidores físicos, y en gral. en recursos físicos, consolidar tiene mucho sentido.

Distribuir, desagregar

Las infraestructuras virtuales crean una "capa intermedia" de administración y gestión de recursos (hipervisores y sus dispositivos virtuales, manejadores de hipervisores), que son luego entregados a servidores virtuales.

Esos servidores virtuales consumen los recursos entregados por la capa de virtualización, incluyendo procesador, ram, discos, conectividad, etc.

La capa de virtualización se encarga de proveer servicios avanzados de gestión de recursos, por ejemplo, permitiendo tener servidores virtuales, cuya suma total de memoria ram virtual asignada es mayor que la memoria ram física disponible en la capa física (en el servidor en el que corre el hipervisor en gral.). Similares características se encuentra en cuanto a procesadores, espacio en disco, conectividad, etc.

Entonces, si de repente tenemos un solo servidor virtual con 3 servicios que consumen X cantidad de ram, y los separamos en 3 servidores virtuales, en algún punto no estamos desaprovechando la memoria ram física en realidad. Una parte mínima de memoria adicional será ocupada para mantener tres sistemas operativos diferentes funcionando al mismo tiempo (3 kernels y poco más), y la memoria individual que ocupa cada servicio será muy similar en cada server separado, respecto de lo que ocupaba cada uno cuando estaban "consolidados" en un solo server virtual.

Las ventajas que obtenemos al desagregar servicios, al distribuirlos en varias máquinas virtuales en vez de consolidarlos es que nos hacemos de piezas más pequeñas para manejar, servidores que ocupan menos memoria ram (algo que es barato, pero no siempre está disponible en demasía), y si necesitamos mover una máquina virtual de un hipervisor a otro, casi seguramente lo podremos hacer.

Hay otras ventajas evidentes de la desagregación: si un kernel falla, los otros dos servicios siguen funcionando, si un servicio tiene una brecha de seguridad, los otros dos permanecen - en lo inmediato - sin ser alcanzados, etc. etc.

Cualquier "cosa" que le suceda a un servicio (en un servidor virtual), a nivel de software y hasta el nivel del mismo sistema operativo que lo está corriendo, continúa sin afectar los otros dos servicios, que si son independientes del servicio afectado, van a continuar operando normalmente mientras la capa de virtualización funcione normalmente.

Consolidar y desagregar servicios en servidores, pero en un contexto pertinente

Como ven "consolidar" es una noción, no "prehistórica" ni poco útil en la actualidad, sino perfectamente útil y pertinente en un contexto específico: infraestructuras de servidores físicos.

Los beneficios de la desagregación de servicios en varios servidores virtuales - en entornos virtualizados - inclusive suponen, como estrategia de gestión de recursos de infraestructura, un número mucho más elevado de ventajas respecto de lo que se obtiene "consolidando" al trabajar con servidores físicos. 

Además de simples ventajas prácticas (el mencionado incremento de resiliencia de servicios gracias a que cada uno corre en sistemas operativos diferentes, por ej.), hay diferentes posibilidades exclusivamente disponibles en entornos virtualizados se hacen disponibles a los administradores al desagregar servicios .La migración live de máquinas virtuales sería casi lo más útil:

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

http://www.vmware.com/products/datacenter-virtualization/vsphere/vmotion.html
http://blogs.citrix.com/2012/08/24/storage_xenmotion/
http://docs.openstack.org/trunk/openstack-compute/admin/content/configuring-live-migrations.html

Subutilizando recursos con infraestructura virtual, un ejemplo

Al contrario, cuando se tiene servidores "consolidados" en entornos virtuales, nos encontramos con grandes consumidores de recursos, que tienden a replicar la misma situación de sub-utilización o poco óptima utilización de recursos que había previo a la virtualización, pero agregando en el medio una capa de hipervisores.

Por ejemplo, sin virtualización, en un servidor físico dado, se corría un Linux con 3 servicios críticos, ahora, con un hipervisor corriendo sobre el servidor físico, se tiene de vuelta un Linux con los mismos 3 servicios críticos, y al ocupar estos tantos recursos, no dejan "lugar" para incluir más servidores virtuales en el mismo hipervidor.

Puede ocurrir que uno de esos servicios críticos se use a la mañana, otro a la tarde y un tercer servicio es de backup y está funcionando toda la noche, entonces en ningun momento del día se tiene realmente libres los recursos físicos disponibles, si hubiera mínimas cantidades libres de alguno, la criticidad del uso del servicio activo al momento o que otros recursos estén siendo ocupados al máximo al momento (mucho procesamiento/ram a la mañana en una base de datos, mucho storage por la tarde en el volcado a disco de datos, y mucha conectividad a la noche cuando se hacen los backups).

Desagregando los 3 servicios en 3 servidores virtuales, podríamos encontrar que a la tarde, en un hipervisor diferente de donde corren los 3 servidores virtuales, hay suficiente "tranquilidad" como para que el servicio que es intensivo en storage corra, así que lo podríamos mover allí, de ese modo la tarde queda libre para poder correr diagnósticos sobre el servidor virtual que se encarga del backup a la noche, y cuando llegue el momento de hacer backups, tenemos de ante-mano cierto stock de pre-diagnósticos del sistema, y si hay alguna falla inclusive podríamos tener un pre-aviso antes de que ocurra la falla.

Si hubiéramos tenido los el servicio intensivo en storage a la tarde y el de backup intensivo a la noche, consolidados en un mismo server, esa situación de prevención de errores tal vez no hubiera sido posible de alcanzar por falta de recursos (no se podía "molestar" al server a la tarde mientras estaba ocupado en otra cosa).

La psicología de la marginación los super-colaboradores de comunidades y/o equipos.

"Ninguna buena obra queda sin castigo"
Los que intentamos postear cosas útiles, intentamos dar una mano, escribimos tutoriales, etc. estamos muy familiarizados con la "mala onda" que eventualmente aparece, y algunos individuos empiezan a desconfiar (¿de qué?), inferir intenciones ocultas en el comportamiento generoso / caritativo (¿cuales exactamente?), y por ende empiezan a "opinar mal" de las colaboraciones / posteos útiles, y del tipo que pone su tiempo para hacerlas.

Me ha pasado, le pasa a casi todo blogger y colaborador que ande suelto por Internet. Le pasa a los pibes/as que dan charlas en eventos ("quién se cree este/a"), o - un clásico - cuando un "don nadie" tiene el "atrevimiento" de corregir - correctamente inclusive - a un "entendido / experto" en alguna temática (aunque sea durante un intercambio en público).

Ese comportamiento - sumamente predecible por cierto - antisocial y contra la colaboración en equipo, tiene una explicación en psicología que muchos desconocen, pero pueden leer muy bien explicada en el link del artículo de Arstechnica de más abajo.

La causa

La causa del "descontento" > las reglas socioculturales imperantes típicamente hacen que la persona que está "disconforme" con el tipo que colabora lo "perciba" como:

- Alguien que quiere auto-proveerse méritos (sea que los tenga realmente o no)

• ¿Una especie de "Síndrome de la Llama que llama" :-D, "lo más de Zamora" jajaja?

- Alguien que quiere hacer quedar mal a los demás (una alternativa: "destacar lo mal que trabajan los demás", sea cierto o no claro).

Por ende su respuesta psicológica casi automática es "estar en desacuerdo" con todo lo que opine / postee / escriba su colaborador voluntario de turno y además, creer que hay "algo malo", detrás de ese comportamiento generoso y colaborativo.

Traduzco un párrafo muy interesante, referido a cómo se margina a los "super-colaboradores" de una comunidad o equipo de trabajo:

"Cuando hablamos del interés propio, este comportamiento es completamente contra-intuitivo; parece absurdo sancionar a estos super-colaboradores y querer expulsarlos del grupo. Después de todo, su generosidad incrementa las posibilidades de éxito de los demás, generalmente a expensas de las suyas propias. Pero la adherencia de los humanos a la conformidad es fuerte, y cuando las apuestas no son altas (N.del.Traductor > por ende no hace falta ayuda del super-colaborador), las normas sociales pueden ganarle al interés propio."

Publicidad profesional

Un clásico de la queja contra la gente que colabora en la red es "Se hace publicidad a sí mismo/a".

Y la respuesta es: Por supuesto

La publicidad profesional, siempre necesaria es una resultante natural de los posteos públicos referidos a una cuestión / tema que es de interés laboral, y es parte del "rédito no económico", que se lleva el blogger / posteador por tener la buena onda de tomarse su tiempo para buscar / escribir / postear / responder, y todo sin ganar un mango en general.

Aunque tampoco está mal si hay algo de auspicio económico: que es más que nada ads -en muchos blogs - y algun auspicio de bajo monto en la mayoría de los casos, excepto contadas excepciones; que de vuelta, no implica nada malo - sobre todo si los auspiciantes figuran a plena vista en el sitio, en los posteos., etc.

Utilidad para el gerente y/o líder de equipo
Lo explicado arriba son nociones importantes a tener en cuenta la próxima vez que tengas un "super-colaborador" en tu equipo y por ejemplo tenerlo en cuenta al momento de las "peer-review"  (lo que opinan los compañeros del super-colaborador), que obviamente pueden resultar desastrosas para el "super-colaborador".

O como alternativa (no muy productiva), se puede promover un ambiente de performance "promedio", donde nadie se destaque del resto; más o menos la noción - o prerrogativa en los equipos menos productivos - anti-productiva conocida como "el clavo que sobresale recibe el martillazo".

Ahora bien, imaginemos que vamos en el sentido inverso y buscamos formar equipos compuestos al completo por super-colaboradores, vas a tener una especie de dream-team.

[Una alternativa más realista: crear equipos con la mayor cantidad de super-colaboradores posible Y circunstancias que desalienten las acciones contra los super-colaboradores.]

Por ejemplo es lo que se busca en empresas como Valve, GitHub, etc.

Links

Why good deeds don’t go unpunished

Being overly generous can get you punished as a nonconformist.

http://arstechnica.com/science/2013/07/why-good-deeds-dont-go-unpunished/

La confusión: bajo nivel jerárquico no implica bajo nivel de expertise técnico

Miraba la noticia del link de abajo y pensaba, "es un malentendido, capaz se confundieron con el tipo". Es decir, lo subestimaron en vez de evaluar objetivamente el nivel de amenaza que representa un especialista de alto nivel técnico, muy experimentado. Es un error organizacional bastante común, muy explotado por los mejores hackers (esos que no salen por ningún diario).

Explico: cuando un administrador de sistemas experimentado de buen nivel empieza a trabajar en una organización muchas veces arranca en posiciones de bajo nivel jerárquico, más allá del nivel de remuneración y el nivel técnico del laburo que haga.

El bajo nivel jerárquico del administrador en una organización puede ser malentendido por las personas en otros cargos jerárquicos superiores de áreas no informáticas (gerenciales típicamente), como "este tipo/a no tiene suficiente currículum / experiencia / conocimiento para hacer el trabajo de sus jefes técnicos, el de los  líderes técnicos, ni el de otros puestos importantes"

La realidad es que mucho laburo se acepta de lo que hay disponible, y las mejores posiciones, las mejor pagas, con mayor responsabilidad ya suelen estar ocupadas cuando un nuevo administrador llega a una organización.

¿Eso significa que la persona no podría hacer el trabajo de cualquiera de sus compañeros de equipo y jefes técnicos hasta el nivel más alto? En muchos, casos probablemente la respuesta es "no":

Un buen administrador de sistemas, experimentado y capaz probablemente podría sentarse en la silla del jefe, tanto como la del líder técnico, tanto como la de otros administradores (DBA, Networking, Seguridad, etc.), sin mucho problema y haciendo un trabajo bastante bueno, inclusive mejorando sustancialmente las decisiones de la persona que esté ocupando la posición en ese momento; tal vez, simplemente llegó luego de que se "repartieron" todos los puestos importantes.

Entonces, cuando ves un/a adm. de sistemas, redes, DBA, un developer con mucha "calle", etc. trabajando en una posición de bajo nivel jerárquico, ello no implica que la persona no pueda agarrar todos los sistemas de la organización (redes, servidores, bases de datos, etc.etc.), y administrarlas y gerenciarlas él/ella mismo/a.


http://www.washingtonpost.com/world/national-security/edward-snowden-bradley-manning-and-the-risk-of-the-low-level-tech-savvy-leaker/2013/06/11/f5e3ad72-d2c7-11e2-a73e-826d299ff459_story.html

¿Pedir consejo / opinión sobre soft libre / opensource a vendedores de soft propietario?

Parece obvio, pero..pedirle consejo / opinión a un vendedor de soft propietario / pago sobre lo buenas / malas que pueden ser las soluciones basadas en software libre / opensource > ¿Qué creen que va a responder?

El negocio IT es un negocio, y los consultores / empresas de soft propietario hacen su negocio, lo que está totalmente bien.

Si Uds. fueran vendedores de soft propietario y en el marco de una posible oportunidad de negocios - vender software - alguien les preguntara por un software que Uds. no venden, que no pueden vender (por acuerdos y lealtad comercial con los fabricantes de soft propietario), del que no pueden vender soporte (razón, idem anterior), que se descarga gratis de Internet, etc... de vuelta  ¿Qué responderían Uds.?

Escribo esto porque hace poco, por enésima vez escuché de al menos un par de IT guys, y al menos dos empresas / organizaciones que les piden consejo sobre la calidad / fiabilidad / utilidad de software opensource / libre a vendedores de software propietario.  y ¿Cuál creen Uds. que pudo haber sido la respuesta?

"El tipo que sabe"
La fundamentación de por qué se pregunta a un vendedor de soft propietario sobre soluciones basadas en soft libre / opensource suele ser "Es un ingeniero / licenciado / tipo con mucha experiencia, trabajó mucho en X e Y especialidades, de mucho nivel técnico", etc. Además de eso, ahora está actuando como vendedor / empleado / socio de su empresa de IT que vende soft propietario. Cuando se le pregunta, se plantea un conflicto de intereses, que éticamente el vendedor / profesional, está habilitado de resolver a favor de su conveniencia comercial.

Así que, más allá de lo buen profesional que sea el vendedor, no se discute la cuestión técnica, sino el interés comercial. El vendedor, la mayoría o en todos los casos en que se le pregunte, va a terminar respondiendo que él - personalmente inclusive - implementaría una solución propietaria.

Conclusión
Como responsables de IT de organizaciones / empresas no solo es una responsabilidad conseguir las mejores respuestas, también hay que saber hacer las preguntas correctas y saber a quien/es preguntar sobre qué temas.

Correcciones, bienvenidas.

¿Conviene guardar información sensible de organizaciones en Internet?

En vista de las noticias (ver el link al final de este artículo)  - altamente fidedignas por cierto - de acceso masivo a información privada (les dejo la política del tema para leer/discutir en otros posteos), la pregunta a hacer desde el punto de vista de seguridad de la información (que incluye a la seguridad informática), es si una organización que requiere asegurar - garantizar contra toda duda - la privacidad de sus datos debería optar por usar  y guardar información sensible en los diferentes servicios (correo, espacio de almacenamiento en Internet, aplicaciones, virtualización de infraestructura, etc.), en la nube que ofrecen muchos proveedores sospechados.

La información sensible es por ejemplo, la que maneja un estudio de abogados que tiene la representación de una persona con actividad política intensa (un diputado, senador, concejal, ministro, etc.).

Ese tipo de actividades puede convertir al representado en una persona de interés a monitorear por algún posible elemento oponente, y por ende sus comunicaciones privadas (correos electrónicos, documentos de texto, hojas de cálculo, etc.), podrían ser un objetivo de vigilancia, y el acceso ilegal a ellas podría ocurrir con más facilidad si su información sensible se guarda en "la nube" y/o en servicios de "nube" en Internet.

Costos

El costo de mantener la información sensible segura es un tema diferente a la necesidad de mantener la información segura.

Un servicio de nube puede ser más barato, más fácil de mantener seguro por casi nada de costo (el proveedor mantiene la seguridad), etc. Una infraestructura propia va a ser más cara en muchos casos (hay que comprar servidores, pagar sueldos, etc. etc.), pero en muchos casos, solamente con una infraestructura propia se podrá responder a requerimientos, reglamentaciones, disposiciones internas y leyes que dictaminen que los datos guardados por una organización deben ser privados.

En Argentina, la Ley 25.326 prescribe que los particulares que formen bases de datos que no sean para un uso exclusivamente personal deberán registrarlas (artículo 24), a la vez explicita  ciertos derechos de las personas que figuran en la base de dato y obligaciones de quien/es crearon la base de datos, algunas de esas obligaciones podrían no poder estar cubiertas en caso de accesos no autorizados de terceras partes a la base de datos. 

Por qué registrar una Base de Datos (sitio 
http://www.jus.gob.ar/datos-personales/registro/por-que-registrar-una-base.aspx


Ley 25.326
http://www.infoleg.gov.ar/infolegInternet/anexos/60000-64999/64790/norma.htm

"La Ley 25.326 y la difusión masiva de datos personales"
www.bcra.gov.ar/pdfs/eventos/Delitos_Pres_Pablo_Segura.pdf‎


Conclusiones

Claro que la respuesta a la pregunta del título es "NO".

Si tu organización maneja información sensible, lo ideal es que tengas infraestructura propia, ejemplos de org. que manejan información sensible: un banco, una aseguradora, un supermercado, una clínica, una obras social, un consultorio médico, un estudio de abogados / contadores / escribanos.

Ciertamente, la noticias de los últimos días vuelven irrecomendable - desde el punto de vista del profesional IT - el uso de cualquier servicio en la nube para guardar información sensible (APIs, mails, storage, servidores virtuales, etc.). La lista de clientes/organizaciones que no deberían usar servicios en la nube prácticamente incluye a cualquier organización que no sea un pequeño comercio (las grandes empresas tampoco deberían guardar sus datos en la nube).

Links:

Edward Snowden: the whistleblower behind the NSA surveillance revelations

The 29-year-old source behind the biggest intelligence leak in the NSA's history explains his motives, his uncertain future and why he never intended on hiding in the shadows

http://www.guardian.co.uk/world/2013/jun/09/edward-snowden-nsa-whistleblower-surveillance

Kanban, el secreto devops de muchos sysadmins

El secreto devops de muchos sysadmins top, para lograr hiperproductividad sin trabajar horas de más, es Kanban.

"¿Qué es el método Kanban para la gestión de proyectos?"
http://www.javiergarzas.com/2011/11/kanban.html

 La clave de todo es el límite de “trabajo en curso”, que te permite focalizar la atención y los recursos en un número limitado de tareas/problemas, sabiendo con certeza que ellos son suficientes para poder completarlas/resolverlos en el tiempo planificado.

Es común que bajo una sobrecarga absoluta de trabajo, esté la opinión de que es imposible "limitar tareas". No lo es, simplemente es que habiendo 20 cosas para hacer, y con plazos/recursos para terminar 10, la realidad es que 10 tareas no se van a completar sino hasta después de los plazos límites. Hay que elegir cuales, y si la sobrecarga lleva a falta de satisfacción en los clientes (internos/externos), hay que resolver como evitar esa sobrecarga, o continuar fallando en los plazos de entrega de tareas y a los clientes.

Mi abuela sabía esto ya en 1984 cuando me explicaba que no hay que tratar de meter más huevos de los que entran en la canasta, sino se caen y se rompen. Y en realidad, es más o menos, así de simple.


Ojo, no es que las organizaciones/empresas no sepan esto, es que a veces están intentando "extraer más jugo de la naranja" (metafóricamente, la naranja sería el empleado), y lo sobrecargan de trabajo para ello.



James Turner de Oreilly ya nos comentó - diplomáticamente - sobre estos chantas en:


"

A Commencement Speech for Graduating 2013 CS Majors"

http://programming.oreilly.com/2013/05/a-commencement-speech-for-graduating-2013-cs-majors.html

"Si sos apasionado, vas a hacer el trabajo que te pidan que hagas, y más, pero no dejes que tu empleador abuse de tu entusiasmo. Uno de mis principios en la vida fue "la falta de planificación de su parte no constituye una emergencia de mi parte". Habrá tiempos en su vida en los que tendrán que resolver verdaderas, imprevistas emergencias, y quemar aceite hasta la medianoche. Pero si se te pide que lo hagas regularmente, solo porque tu compañía no dispuso los recursos suficientes para hacer el trabajo, te están tomando el pelo."

Profesionales IT no egresados III: un testimonio de la realidad, no una opinión

Me parece muy buena la opinión amablemente expresada por un lector y obviamente difiero, sin embargo más allá de nuestros puntos de vista discordantes, no creo que cambie la realidad donde las organizaciones y el mercado laboral (local e internacional), se manejan de modo indiferente a las titulaciones.

Como decía, la realidad se ve en la calle, más allá de las opiniones, escribí el artículo contando lo que veo en la calle ahora y hoy, al salir y hablar con la gente que trabaja por varias provincias de Argentina, y al conversar con contactos y amigos que están trabajando en Latinoamérica y en otros continentes; y mayormente, lo escrito ahora y en los dos artículos anteriores es un testimonio en un 99%, y mi punto de vista en un 1%.


Por ejemplo comentario:

"Una cosa es un programador, otra un técnico en hardware por ejemplo, y otra cosa alguien que estudió sistemas de información o informática. "

Se refiere tal vez - es un poco ambigüo - a una persona clasificada 100% o como técnico/programador o como persona que estudió sistemas.

En la realidad, en la calle, en Argentina, tenés gente con perfiles similares a este: estudió 3-4-5 años de una carrera, que luego estuvo 10-15 años en el mercado laboral, habla 3 idiomas, ya fue team leader en 4 empresas, gerente (manager) para múltiples clientes internacionales, etc. y sigue subiendo en la estructura gerencial IT de las organizaciones.

A esos tipos no los puede clasificar como "técnicos" o "programadores" (si trabajan en infraestructura o en desarrollo, respectivamente). De hecho, cuando alguien con ese perfil va por un cuarto a la mitad de su carrera laboral/profesional, ya hace tiempo que no es clasificable como mero "técnico" ni como mero "programador", en gral.

Es una realidad que supera las clasificaciones "todo es blanco o negro", y está fuertemente definida por el tremendo nivel profesional en IT que alcanzan los (ex) estudiantes no recibidos y autodidactas (que nunca estudiaron formalmente sistemas/informática), y el mercado laboral que les da la bienvenidad a puestos de altos perfiles técnicos y gerenciales en IT. Una mirada a cualquier lista de contactos medianamente grande en Linkedin basta para confirmar esto (de cualquier idioma/país, por cierto, pero especialmente en Argentina).

Y sí, claramente, muchos de esos tipos van a poder responder sin mucho pestañeo por qué una orden de compra es necesaria en una empresa.

Hay muchos lectores del blog que son - como yo - oriundos de la zona del nordeste de Argentina, que tiene un efectivo retraso en la adopción masiva de IT, de tecnologías de la información, respecto de lo que se puede encontrar en otras regiones de Argentina y en muchos otros países del mundo.

Por ello lo explicado en el artículo, inclusive se está empezando a producir recién en el nordeste de Argentina, o no se está produciendo en muchas organizaciones directamente, y así a los profesionales IT ex-estudiantes sin egresar y audidactas, típicamente se los clasifica informalmente como "técnicos" y se "asume" (presume), que no manejan mucha teoría de sistemas y/o informática, y sus habilidades están totalmente enfocadas y limitadas a hacer trabajos meramente técnicos (instalación y configuración de software y hardware, soporte técnico y helpdesk, programación, etc.).

Sin embargo, lo explicado en el artículo es palpable a flor de piel en el resto de Argentina (mayormente), e internacionalmente: dado un cierto nivel de currículum (de acuerdo con el nivel profesional requerido para el puesto de trabajo), y antecedentes, muy pocos potenciales empleadores van a preguntar siquiera si el candidato egresó de alguna universidad o no (hay excepciones claro, y eso está reflejado en el artículo también).

Respecto de:
"Las buenas prácticas ITIL son un sistema de información."

En la ciudad de Cba., cuando estaba trabajando, los profesionales no egresados y autodidactas que tenían varias certificaciones en ITIL se contaban por cientos (lo veía literalmente a diario en decenas de correos recibidos de toda Argentina y de Cba., ya que los profesionales titulados acostumbran a firmar con "Ing." o "Lic." y los profesionales no egresados y autodidactas son simples "Sr" "Sra." o "Srta."). 

De hecho "en la calle" (en la conversación típica de oficina o de after-office), ITIL en todos su niveles - hasta los más complicados - se consideraba en general una las certificaciones más fáciles de rendir y aprobar, justamente porque involucra casi puro "blablablá" no técnico. Otras certificaciones consideradas fáciles por todos son cualquiera que no involucre cuestiones técnicas: de Auditorías varias, Project Management, SCRUM y metodologías varias en gral. 

En cambio, poder rendir una certificación en adm. de storage, un RHCE, MCSE, o varias de las certificaciones Java. .NET (no me refiero al programa público de Microsoft, sino a las certificaciones oficiales), sí requieren entender cuestiones mucho más complejas y claro, había mucha menos gente certificada en esas cosas (egresados, no egresados y autodidactas).

Profesionales IT no titulados: la informática es como la profesión gastronómica

Los gremios y asociaciones de profesiones existieron y siguen existiendo para actividades que no tienen una base de educación formal "necesaria e indispensable" para poder afiliarse y/o conseguir empleo.


La informática en ese sentido es muy similar a la gastronomía.

Sí, hay escuelas de gastronomía, hay personas con estudios; pero sí, también es correcto que cualquiera puede aprender a cocinar muy bien, en su casa y/o como aprendiz de cocina recorriendo cocinas célebres (es común que los cocineros noveles hagan "tours" de capacitación por varios países y/o restorans destacados, para aprender o mejorar su habilidad), y finalmente se vuelva un cocinero/a muy capaz 

Es posible para esos cocineros/as llegar a conseguir empleos muy importantes ("Chef" == "jefe de la cocina", tener sus propios programas de televisión, etc.), realizar emprendimientos propios grandes (restorans, empresas de catering, academias, etc.), y es rutinario que lleguen a ser reconocidos por sus pares (titulados o no), como eminencias en su trabajo.

Muchísimo - aunque no todo - del campo total de conocimiento de la informática puede ser hoy estudiado y aprendido fuera de cualquier institución académica, y además, como lo prueba la cantidad de empleo otorgado a profesionales IT sin titulación  (y más probablemente la estadística de permanencia en el puesto de trabajo), se puede aprender la profesión informática tan bien fuera, como dentro de las instituciones académicas.


La realidad es que muchas carreras universitarias de sistemas e informática incluyen hoy (tal vez necesariamente o no), muchos materiales y campos formativos que se puede leer, estudiar, aprender, practicar sin necesidad de asistir a una universidad, nunca o casi nunca.


La circunstancia intermedia
Muchos tenemos compañeros de trabajos y/o jefes inclusive que fueron estudiantes avanzados de carreras de sistemas e informática, pero no llegaron a recibirse. Algo similar ocurre con profesionales titulados de otras carreras (ingeniería en telecomunicaciones, electrica/electrónica, lic. en física, matemáticas, etc.).

Estos profesionales informáticos sin titulación son punto intermedio real, concreto y presente entre los audidactas completos que nunca asistieron a una universidad (que en muchos casos no los hace ni siquiera mínimamente menos capaces en muchos campos técnicos de informática que un ingeniero en sistemas o licenciado en sistemas), y los profesionales egresados de carreras universitarias.

¿Se puede razonar como correcto que NO es un profesional de sistemas/informática un estudiante de ingeniería en sistemas que cursó y aprobó 3 años de la carrera de ingeniería en sistemas de información (ISI), y tiene bajo su brazo 10 a 15 años de trabajo profesional, trabajando de igual a igual con profesionales egresados, y hoy dirige eficaz y efectivamente un equipo de 5 a 30 personas (algunos de ellos profesionales egresados)?  De hecho, dado un profesional y colega IT como el de la pregunta anterior, ¿hay algún profesional titulado que se llegue a animar a manifestar que ese colega NO es un profesional de la informática/sistemas? Y si hay alguno, ¿hay alguien que en realidad lo crea? (mucha manifestaciones de ese tipo son en gral. resabios de un intento de "tapar el sol con las manos").

Entre mis colegas conocidos cuento al menos 15 personas - excelentes profesionales IT por cierto - de 4 provincias diferentes de Argentina, otros 5 de dos países fuera de Argentina que están - ahora, ya - exactamente en esa situación, y no tienen a la vista seguir estudiando ni recibirse, ni a corto plazo ni a futuro, de hecho, en este punto, ya no les es necesario ni para su trabajo (para conseguir empleo), ni para su profesión (ya conocen más de la profesión de lo que podrían haber aprendido al completar sus estudios formales). 

[Ninguno de ellos, que sepa, tiene en mente dejar de estudiar y seguir aprendiendo, como norma gral. cuando converso con alguno, siempre le pregunto qué está estudiando en estos días.]

Un razonamiento (hacernos la misma pregunta), muy similar se puede hacer respecto de ingenieros en telecomunicaciones, lic. en física, matemáticas, ingenieros en electricidad, electrónica, etc. 

[ Que como mencioné en otras oportunidades, inclusive - en Argentina - suelen trabajar en informática especializándose en campos de muy alto nivel técnico/teórico en IT, y es más habitual encontrarlos a ellos que a ingenieros en sistemas/informática o lic. en sistemas/informática en posiciones altos requerimientos de conocimientos de ciencias duras aplicadas a la informática.]


Conclusiones
Volviendo a la similitud de la informática con la gastronomía, es una situación presente y actual. 

Sin embargo no quiere decir que no se pueda eventualmente instituir social, legal o económicamente una estructura de adecuada convivencia, interrelación y efectiva cooperación económica entre profesionales IT con titulación y profesionales IT sin titulación. 

Un ejemplo de esto, de la actualidad, sería planteando un esquema organizativo (legal y social), similar al de la industria de la construcción, donde hay muchísimo personal profesional sin titulación, gremios, y profesionales titulados - ingenieros, arquitectos, maestros mayores de obra, etc. - conviviendo (no sin conflictos, es verdad), en una actividad económica que funciona efectivamente por norma general (un cliente que busca y necesita casi nunca deja de encontrar albañiles, o arquitectos/ingenieros, o capataces y todos ellos se integran a proyectos de construcción).

Profesionales IT no egresados de carreras informáticas: la nueva realidad

Originalmente empecé a escribir un artículo intentando dejar expresadas las justificaciones para este punto de vista, sin embargo, no es necesario, para ver qué tan real es, solamente tenés que mirar a tu alrededor.

Algo de historia

Resulta que lo que conocemos como "mercado laboral IT" cambio radicalmente en los últimos años - desde el 2000 al 2008-2010 y muchísimas posiciones IT a nivel mundial están ocupadas - y efectivamente atendidas - por especialistas autodidactas y más específicamente, por personal que no tiene titulaciones formales obtenidas en universidades.

Es la realidad del presente, no es precisamente que ello sea del favor de las empresas y organizaciones, las que sin embargo han contribuído grandemente para la consolidación de esta situación a nivel nacional e internacional.

Es cierto, el mercado IT explotó en los primeros 10 años del siglo XXI y había relativamente pocos técnicos y especialistas en informática para atender la intensa demanda de personal informático en casi cualquier lugar.

De todos modos, las organizaciones en general forzaron la situación empleando a cualquiera que pudiera demostrar habilidad técnica razonable para realizar un trabajo para el cual querían cubrir una posición, empezando primero por estudiantes avanzados de carreras informáticas, siguiendo luego con estudiantes con los primeros años cursados y luego directamente con estudiantes recien ingresados a las carreras de sistemas (para "formarlos"). 

Luego de esto, los autodidactas en general, tuvieran o no antecedentes relacionados al campo técnico-informático, empezaron a ser aceptados para entrevistas y poco después - dado que muchos demostraron ser muy capaces de realizar el trabajo de un técnico "de verdad" - fueron aceptados para trabajar en posiciones técnicas relativas a IT.

Oferta y demanda de personal IT

El mercado, la oferta y la demanda hizo el resto del trabajo: dado que es prácticamente imposible en la realidad y en la práctica que la cantidad de alumnos egresados de carreras informáticas (de cualquier país), profesionales IT con educación formal, puedan igualar en cantidad al total de estudiantes de carreras de sistemas/informática - contabilizandolos desde los recien ingresados a las carreras, hasta aquellos que están cursando las últimas materias - y además a los técnicos/especialistas autodidactas e ingresados al campo de conocimiento de la informática desde otras carreras (matemática, física, ingeniería electrónica/eléctrica, ing. en telecomunicaciones, etc.etc.), al poco tiempo - unos años, desde 2000 al 2004 aproximadamente - los sueldos pagados a profesionales de sistemas/informática recién egresados y/o con relativamente poca experiencia cayeron en picada.

O sea, los sueldos para los egresados de las carreras IT no "cayeron", simplemente se adecuaron a la nueva realidad donde un recién egresado de carrera informática o un profesional con varios - pocos - años de experiencia tiene una habilidad laboral similar a equivalente al de un estudiante de carreras de sistemas/informática moderadamente talentoso y/o a la de un autodidacta capaz.

Estos dos grupos de potenciales personas empleables para posiciones técnicas en informática suelen tener la tremenda ventaja de no tener que dedicar cuantiosas cantidades de tiempo - meses a años - a estudiar las temáticas abarcativas-no-técnicas de las carreras de sistemas, aquellas temáticas que están destinadas - en las carreras de ingeniería y licenciaturas - a brindarle al profesional un "panorama amplio" del campo técnico informático y en menor medida, a dotarlo de habilidades no relacionadas con lo técnico-informático - pero necesarias para muchas funciones y tareas como profesional. 

Por ejemplo: materias destinadas a capacitar en administración de proyectos, gerencia en general y en particular orientada a informática, a crear extensivas y concienzudas habilidades en matemática, física, química, etc. etc.

El grueso de dichas temáticas son, en la práctica, fútiles para la mayoría de las posiciones técnicas en informática, donde no se espera que el técnico ejerza funciones gerenciales ni supervise proyectos, o desde el punto de vista técnico, desarrolle un nuevo protocolo, optimice un algoritmo estándar del mercado, desarrolle un nuevo lenguaje de programación, desarrolle/optimice el código de un compilador para elevar la performance de los binarios compilados, etc. etc.. De hecho, la mayoría de las organizaciones cuenta con un - muy reducido - plantel de especialistas para las tareas de supervisión, organización y administración en general de informática para la organización (personas que pueden o no ser profesionales de sistemas / informática). Más adelante veremos respecto de las tareas de alto nivel técnico en IT.

La consecuencia directa de esto es que la retribución económica a largo plazo esperable para un profesional de sistemas/informática recién egresado y/o con pocos años de experiencia y bajo nivel de habilidades técnicas y de experiencia práctica real, es relativamente baja respecto de lo que se esperaría de un nivel de preparación superlativo como el que se obtiene luego de cursar, estudiar, y aprender una carrera de sistemas/informática.

La posibilidad de egresar y abrir una empresa propia, como alternativa a bajos sueldos, está también muy limitada por la falta de capacitación y habilidades técnicas reales, concretas...y vendibles de los recién egresados típicos, incluso de los profesionales egresados ya con varios años de experiencia. Esto en parte es responsabilidad de un exceso de abstracción en las temáticas técnicas enseñadas en las carreras de sistemas/informática.

La situación general en el empleo informático quedó configurada como se da hoy: los profesionales IT egresados de carreras informáticas compiten mano a mano con una cantidad muy superior - en razón de miles a uno - con profesionales IT no egresados de carreras informáticas (estudiantes, autodidactas y profesionales egresados de otras carreras técnicas).

La expectativa de bajos niveles de retribución económica y altos niveles de competencia ha creado una situación en la que en los primeros años de cursado de las carreras, muchos estudiantes ya se dan cuenta que van a tener que mejorar sus probabilidades de éxito trabajando al mismo tiempo que cursan sus estudios formales, creando un feedback, una retroalimentación efectiva que sigue potenciando la realidad laboral IT actual, a nivel mundial inclusive.

Gerentes IT egresados de carreras informáticas

Los profesionales que egresen de carreras informáticas/sistemas y a la vez trabajen y obtengan capacitación efectiva y experiencia práctica van a adquirir el "full-pack": la experiencia y habilidad técnica de los profesionales IT no egresados de carreras informáticas, y la titulación de la carrera informática que están cursando (junto a la capacitación en temáticas formativas no técnicas que brinda el estudio de esas carreras).

Estos profesionales serán mayormente los futuros líderes de las organizaciones IT, ya que sumarizan el total de habilidades necesarias - indispensables - para liderar, dirigir, organizar, y administrar las infraestructuras informáticas complejas de las organizaciones.

"Mayormente" implica a su vez que no serán únicos. Los profesionales IT no egresados de carreras de carreras informáticas tienen una característica común: el afán por el estudio, y un afán implícito - sino necesario e indispensable, la necesidad de constante actualización y expansión de sus campos de conocimiento y especialidad*.

* Es una necesidad que va de la mano con la alta competitividad del mercado y con la necesidad de poseer efectivamente un nivel de habilidades técnicas superior a la que puede ofrecer un profesional IT egresado de carreras informáticas.

Gerentes IT no egresados de carreras informáticas

Así que muchos profesionales IT egresados van a ver como a corto plazo en el futuro, muchas tareas gerenciales informáticas son asumidas - efectivamente - por profesionales IT no egresados de carreras informáticas.

Ello de todos modos no es una situación desconocida para el grueso de las organizaciones, especialmente aquellas muy nuevas (de menos de 10 años de existencia), y para aquellas muy viejas (más de 20 años de existencia). 

Gerentes IT en organizaciones nuevas

Las organizaciones muy nuevas "nadan" cómodamente en un mercado de profesionales IT indiferenciado en la práctica y en la realidad; disponen así de miles de potenciales candidatos a cubrir cualquier necesidad técnica y de gobierno relativa a la informática en la organización. Desde gerentes de sistemas a pasantes que cambian cartuchos de impresoras y dan sus primeros pasos en alguna especialidad IT.

Los gerentes IT - y otros cargos gerenciales - no egresados de carreras informáticas no son extraños para estas organizaciones.

Gerentes IT en organizaciones muy viejas

Por otra parte, las organizaciones muy viejas ya estaban largamente acostumbradas hace una década atrás a mantener estructuras gerenciales completas de áreas informáticas organizacionales, completamente ocupadas por profesionales no egresados de carreras informáticas.

Esto claro, con la salvedad de que gerentes y administrativos que no tenían - tienen en el peor de los casos - conocimientos técnicos reales en informática (de ninguna alguna clase), solían - suelen - llevar a las organizaciones a verdaderas catástrofes gerenciales en informáticas, claro, con sus costosas e inevitables consecuencias económicas y desarreglos organizacionales que terminan afectando al grueso de la organización, no solo a las áreas informáticas.

De estas últimas organizaciones, muchos gerentes IT no egresados de carreras informáticas, fueron y son egresados de una diversidad de otras profesiones y campos: escribanos, contadores, abogados, médicos, lic. en X campo de conocimiento, etc. etc.

En mi experiencia, una minoría de ellos pudo desempeñar sus funciones efectivamente, sin pasar antes por grandes eventos organizacionales "negativos", con origen en el área informática de la organización.

Entonces, ¿es útil estudiar carreras IT hoy?

La utilidad práctica de estudiar y conseguir una titulación formal en sistemas en informática sigue presente para muchos campos IT, sin embargo son aquellos que demandan altísimos niveles de preparación técnica (desarrollo de lenguajes/compiladores, desarrollo e implementación de nuevos algoritmos, desarrollo de complejos proyectos técnicos multi-especialidad, etc. etc.); dicho nivel de preparación efectiva está hoy ausente del 90% de las facultades y universidades a nivel mundial, siendo muy pocas las instituciones que siquiera tienen un plantel docente capaz de enseñar ese nivel de habilidades. De todos modos, la necesidad de tal nivel de especialización técnica se da en campos de trabajo sumamente específicos, en general ausentes en muchos países (empresas/factorías de componentes electrónicos avanzados, empresas de telecomunicaciones que desarrollan productos, empresas de informática que desarrollan productos/software avanzado o altamente especializado, etc. etc.). Redundando tal vez, en general, la capacitación de base necesaria para poder abarcar ese tipo de trabajos IT no se puede adquirir en una universidad y carrera informática típica, y es muy común que los encargados de ocupar esas posiciones sean profesionales de otros campos (ingeniería electrónica, física, telecomunicaciones, etc.), que si suelen tener en sus programas de estudio el suficiente nivel de base de ciencias duras aplicadas necesario para ocupar posiciones IT con requerimiento de niveles de conocimiento técnico/científico muy elevados.

Más allá de lo anterior, la utilidad real de las carreras informáticas hoy es la de introducir a los futuros profesionales egresados y no egresados a los campos de conocimientos de la informática. Muchas personas no tienen las características propias de la educación autodidacta y van a encontrar en la universidad el nivel - básico al menos - de enseñanza y capacitación que les va a permitir ir más allá y formarse como profesionales de informática, sea que quieran o no concluir la carrera que eligieron.

Por otra parte, la salvedad más importante se da también en el presente: muchas organizaciones - y la gente de recursos humanos y gerentes en especial - no están al tanto de la realidad actual, y no están o no se sienten presionados para obtener personal de informática altamente especializado y capaz, sumamente escaso en general. Por ende recaen en prácticas de reclutamiento y administración de recursos humanos propias de otra realidad, obteniendo en general malos resultados (personal no capacitado o por debajo del nivel técnico necesario).

Esto último cuenta para profesionales egresados; que pueden no llegar a tener experiencia/capacitación técnica suficiente, por ser recién egresados o haberse "dormido en los laureles" de la titulación.

Y también cuenta para profesionales no egresados; aquellos que se iniciaron en la informática, pero no dieron el salto de capacitación técnica y de adquisición de base teórica necesario para convertirse en verdaderos profesionales de IT, capaces de interactuar de igual a igual con profesionales egresados.

Conclusiones

La realidad presente es concreta: vamos a encontrar miles de especialistas IT no egresados de carreras informáticas, simplemente poniendo un aviso de trabajo en Internet. Muchos - no todos -de ellos hoy, serán efectivos, eficientes y capaces profesionales de sistemas e informática, sin tener una titulación de ninguna carrera de sistemas o informática. 

Ello que no implica que no sean profesionales titulados en otros campos; y/o no que tengan preparación formal efectiva: varios años de estudios formales cursados y aprobados en universidades y en carreras de sistemas/informática; y todos en general, efectiva habilidad técnica y en especial, mucha experiencia aprovechable/rentable. 

Muchos de ellos también ya han superado la mera capacitación y experiencia técnica y ya poseen habilidades completas equivalentes a las obtenidas por un estudiante de carrera informática que completa sus estudios. Estos últimos hoy, son los más desaprovechados por las organizaciones "viejas", y rápidamente incorporados y aprovechados por organizaciones nuevas.

La cantidad de profesionales de sistemas e informática egresados de carreras universitarias podrá incrementarse o disminuir en el futuro cercano o lejano, ello depende de muchos factores; sin embargo la cantidad y calidad de los profesionales de informática no egresados de carreras universitarias va aumentar consistentemente a corto plazo, y si tenemos que analizar lo ocurrido en los últimos 10 años, a mediano plazo se dará de igual manera.

Como dije al principio, si querés apreciar la realidad de este punto de vista en general, solamente hace falta mirar alrededor, ver quienes trabajan con vos, qué personal informático es habitual encontrar en organizaciones y empresas que conocés.

Las soluciones rápidas y fáciles en infraestructura IT

No existe la magia en infraestructura informática, en redes y servidores, más allá de la - tal vez amplia y muy válida - experiencia y nivel técnico de los administradores y consultores, no hay soluciones rápidas ni fáciles, el camino fácil como norma general, no suele ser posible ni viable en la práctica. 

Si cualquiera te promete una solución "fácil y rápida" es algo que no va ocurrir en gral. ; Si cualquiera está esperando obtener soluciones fáciles y rápidas, son expectativas demasiado optimistas al respecto, en general.

En cambio, si cualquiera te explica que lo van a ver, analizar, planificar y ver cómo se implementa algo, estás escuchando - al menos - acerca una posiblemente efectiva y real solución de infraestructura informática.

Consultoría técnica IT: donde hay que dejar de ofrecer consejo técnico gratuito

Llega un punto en que tenés que dejar de ofrecer consejo de consultoría, si se requieren tus servicios, tienen que pedírtelo, si necesitan que proveas una solución, tienen que decirte "Necesito que me soluciones esto" + "vení y encargate vos de este tema".

¿Por qué? Hay un por qué y muy importante:

Los consejos intermedios, las respuestas fáciles, buscadas por los clientes son una cuestión que surge de bajos presupuestos y otros factores, no se puede culpar al cliente de buscar soluciones rápidas y baratas (incluso si intentan evitar contratar al consultor); lo que pocos clientes saben es que tales "soluciones rápidas", "consejos simples para solucionar el problema" suelen ser contraproducentes para la organización y a la vez, para el consultor.

Si vos como consultor decís - comunicás tu criterio técnico - que una solución posible sería hacer "X", en realidad estás diciendo que vos podrías llevar adelante e implementar la solución "X". Si un tercero intenta implementar "X" bien puede ocurrir que no funcione, que el o los terceros no sepan cual es el enfoque - en detalle - que hay que darle a uno o varios componentes de la solución.

Asímismo, si recomendás "implementen X que les va a ir bien", y los tipos prueban y no les funciona "X", pocos dicen "YO no pude implementar bien X", y muchos van a optar por explicar "El consultor Fulano nos recomendó hacer X, pero no funciona muy bien".


Así que la conclusión es simple, como consultor, limitate a dar consejos técnicos puntuales a los colegas, a los clientes se les vende soluciones, y si quieren consejos gratis, hay que evitarles el dolor de cabeza de que intenten implementar soluciones que desde un principio, no sabían/no entendían/no tenían tiempo para  estudiarlas/trabajarlas/implementarlas, y para lo que fueron a buscar ayuda fuera de la organización.

Vos sos la ayuda, no les des más problemas dándoles consultoría técnica gratuita que no van a poder implementar sin tu ayuda, de todos modos.

Howto: Evitando el desmanejo en áreas IT

Poco felizmente, la temática que describo abajo es muy común de encontrar en muchas organizaciones / empresas / clientes, es conocida en el ambiente informático, pero pocas veces tratada en público, por ende los novatos y recién ingresados al campo laboral IT conocen poco o nada de esto.


Mejoras

El otro día charlaba con unos amigos de cómo se va viendo algunos cambios en áreas IT en Corrientes (AR), lentos, pero ahí están, esos cambios son claros en una cosa: 

Profesionalizar el funcionamiento de áreas IT evitando y previniendo el (des)manejo resultante de rumores e influencias, apuntando en cambio a profundizar políticas IT reales (escritas y avaladas por las instituciones/empresas), y otras nociones de formalización de reglas organizacionales (procesos internos puestos por escrito, etc.).

El manejo de un área IT en una organización ligado a la manipulación, falsos rumores, lisas y llanas mentiras, el "serruchado" de piso, se va asociando lentamente con lo que siempre fue, un desmanejo, una falta de gestión real y por ende una falta de cumplimiento de las funciones de los que participan/ban, voluntaria o involuntariamente de ese desmanejo, de "puterío", como se conoce en la calle.

Dos nociones importantes para desempeñarse seriamente como profesional IT son las de "ir a la fuente" y "mantener la distancia".


Ir a la fuente

No hay nada peor para un área IT que las opiniones recibidas "en confianza", de supuestos amigos / conocidos / colegas / contactos "de confianza", ya que a veces, y en presencia de importantes intereses enfrentados (especialmente si son económicos y de competencia - "contra" otros colegas - en la carrera laboral), esa confianza se ve traicionada y lo único que se recibe en confianza, como confidencia, es información falsa y/o datos erróneos, opiniones parciales sino fuertemente no veraces sobre personas, hechos, lugares y circunstancias, donde quien recibe esos datos, no tiene conocimiento certero qué fue lo que pasó, excepto por la información - falsa/manipulada - que está recibiendo.

Al obviar y/o minimizar cualquier rumor, confidencia que se escuche, el panorama cambia para quien escucha, y se puede intentar conocer y acercarse realmente a las personas, lugares y circunstancias, sin pre-juicios. Y habrá muchos casos donde vamos a ver que rápidamente verificamos que un "dato" recibido "en confianza", era falso en realidad.

Por eso, lo mejor es ir a la fuente, conversar y dialogar con las personas que estuvieron ahí, sin prejuicios basados en información posiblemente falsa.


Mantener una sana distancia del desmanejo

Lo siguiente es obvio, y está muy ligado a lo anterior:

Mantener la distancia del desmanejo consiste en guardar la debida duda respecto de la veracidad de cualquier "dato" o "confidencia" recibida en el marco de probables fuertes intereses - personales, institucionales, de negocios, etc. - contrapuestos.

Es difícil mantenerse al margen del desmanejo cuando se está inmiscuído en un área IT total o parcialmente fuera de control (esa es la real y objetiva circunstancia de áreas IT que "funcionan" en base a manipulación, influencias, y "puterío" en gral.) >

Pero, como se suele decir en arquería "mantener una línea de visión despejada es vital para alcanzar el blanco", es decir, mantener nuestra opinión y puntos de vista sanamente imparciales, ayuda mucho al objetivo de proveer la mejor calidad de trabajo IT posible (que puede no ser la más alta si lo impiden las circunstancias, inclusive).


Intereses económicos contrapuestos

Hacéte una pregunta simple y razoná la respuesta:

¿Qué empresa / consultoría va a decir públicamente que ellos ganaron un trabajo con un cliente, pero que no eran la mejor oferta disponible?


Intereses laborales contrapuestos

Hacéte otra pregunta simple y razoná la respuesta de vuelta:

¿Qué empleado/jefe "ganador" de una posición laboral importante va a decir que los otros competidores eran mejores profesionales IT, pero ellos ganaron en base a otros criterios que no fueron calidad de trabajo real y objetiva (incluyendo ética profesional, nivel técnico, desempeño laboral, buena voluntad/predisposición, etc.)?

Y especialmente, cuando la "victoria" se dió en base a desmanejo: mentiras, manipulaciones, rumores, falsas acusaciones, influencias importantes - que pudieron haber sido manipulados y engañados a su vez - y demás "puterío".


Conclusiones

"Ir a la fuente" y guardar una sana distancia e imparcialidad - especialmente en presencia de intereses económicos y laborales contrapuestos - y una visión libre de prejuicios basados en rumores, crea una real actitud profesional IT. 

Además brinda la posibilidad de lograr contactos y aliados reales y valiosos, a nivel de carrera IT en gral. y laboral ahí mismo en esa organización/empresa, con ese cliente (inclusive en medio del desmanejo); propulsa y eleva la calidad del trabajo informático que se provee y brinda a quienes pagan por él, sea una organización/empresa o clientes.


Lecturas Recomendadas

Material de la cátedra "Ética Profesional" (UTN FRSF - Ing. en Sistemas de Información)

http://www.frsf.utn.edu.ar/matero/visitante/index.php?id_catedra=291&ver=4