Pornerse la camiseta

A colación del Diccionario IT

diccionario_Laboral

Anuncios

De un PM y un albañil

Se imagina si las construcciones se administraran como los proyectos informáticos?
pues deteneos en este gráfico hilarante:
construccinformat

Puede parecer gracioso, pero es una realidad diaria, y no solo para quienes desarrollan software, si no que esto algo asi como una pandemia entre las empresas de IT (con o sin outsourcing, con o sin uso de Scrum). A que ya les ha pasado verdad?

Metricas

Como es que no hablamos de las métricas antes?? Las famosas métricas, amadas por los gerentes y odiadas mayormente por los trabajadores, son una excelente herramienta, si se la utiliza adecuadamente. Claro esta, esto no siempre sucede y es donde se generan las…….. Falacias de las Metricas!!!

Falacia de la cantidad

Generalmente se tienen en cuenta la cantidad de tickets que un SA cierra, sin embargo, esto no siempre refleja la cantidad de trabajo que le representa.
Ejemplo: 1 ticket con 200 servidores para reparar o 200 tickets de falsas alarmas que solo hay que cerrarlos

Falacia de la complejidad burocrática

Algunas veces lograr cerrar un ticket (un “change”, o llegar a los requirements de un sprint, para los Developers o en su caso los DevOps), puede significar poco trabajo técnico y mucha burocracia para conseguirlo.
Ejemplo: 2 Meses de meetings y explicaciones para lograr un ticket
Esto no suele verse reflejado en los números por que no es cuantificable!

Falacia del porcentaje

Juan cerró el 75% de los tickets y Pedro sólo el 25%.
Sin duda diriamos que Pedro tiene una mala performance.
Sin embargo, si consideramos que la cantidad total de tickets fue de  4, podemos entender que quizas Pedro no llego a tener oportunidad de trabajar o mostrar su potencial. Por otro lado si la cantidad de tickets fuera alta, revisemos la falacia de la cantidad y/o la falacia de la complejidad burocrática. Claramente el porcentaje no siempre es algo claro. Existen otras situaciones y ejemplos del mal uso del porcentaje, pero lo importante, nuevamente, es mostrar lo medido considerando el contexto para no caer en este error.

Falacia “Strawberry picking”

Si en el equipo de trabajo no existe una distribución de trabajo planeada, puede ocurrir, que se suscite una avivada de tomar los tickets mas fáciles dejando los mas complejos para otros compañeros. Es decir, se comen la frutilla del postre. Esta falacia sumada a las anteriores puede dejar a algunos trabajadores desprevenidos al borde de la guillotina.

 Falacia de las peras y las manzanas

Aunque algunos no lo crean, hay personas que piensan que es lo mismo construir manejar un colectivo (bus) que un auto (automovil), total ambos tienen volantes y pedales. Cuando las métricas comparan trabajo, hay que hacerlo de la manera apropiada, revisando que estamos comparando peras con peras y manzanas con manzanas y no peras con manzanas, por que son cosas distintas.
Una ejemplo de esta falacia, es cuando mes a mes, la forma de medir cambia  (quizás debido a una evolución de la forma de medir, o todo lo contrario), por consiguiente no podemos verificar si hubo un cambio en la cantidad y calidad de trabajo.

Falacia de los “Graphic lovers”

Es de conocimiento general que a los managers/gerentes les encantan los gráficos de torta y columnas. Son como un orgasmo de realización empresarial cuando todo esta en “verde“. Este tipo de gente quiere medirlo todo. Cuantificarlo todo. Y eso es un problema, varios problemas en realidad a saber:
– Crear tickets para cada cosa por mas mínima que sea.
– Sobrecarga de trabajo para realizar los informes:Alguien siempre tiene que preparar los reportes y gráficos, sea el Team Leader o el mismo gerente. De cualquier manera, alguien tiene que gastar tiempo innecesariamente en lugar de hacer algo mas productivo.
– Aumento de probabilidad de caer en cualquiera de las otras falacias.
– Imposibilidad de poner el foco en lo mas importante ya que la cantidad de variables se hace inmanejable.
– etc.

Resumiendo, muchas cabezas han sido cortadas y otras coronadas por errores en las métricas. Si la medición no se hace a conciencia y contextualizada, podemos estar cometiendo graves errores.

metrics

 

Alguna falacia que no hayamos comentado?

ISO, LEAN, SIX SIGMA, ITIL etc

Cada  tanto algún alto manager decide implementar una norma/framework/certificación y empiezan los cursos obligatorios web  (next, next, next) o aveces los presenciales (y por supuesto, las auditorias), para que conozcamos las normas y políticas de la empresa etc etc.  Dependiendo del nivel de adherencia o del tipo de trabajo que hagamos nos impacta mas o menos, lo que si es seguro, es que con el tiempo aprendemos cual es el fin práctico de cada uno:

ISO 27001: No compartas tu password
ITIL: Cambios e Inidentes!
CobIT: cosa de managers
QMS: A documentar!!
PMP (PMI): certificar la ineptitud
LEAN: Como hacer mas con menos, a costa tuya.
SIX SIGMA: Como medir que haces.
LEAN SIX SIGMA: Como medir que haces, para pedirte que hagas mas y ganar mas a costa tuya sin retribución

Alguna mas que haya faltado?


Apartado especial de ISO 9000 (in english) sólo para iso-entendidos.

  • ISORE – Eye strain resulting from writing procedures and work instructions.
  • ISOAP – Detergent used to clean up before the Registration Audit.
  • ISO-SO – Not a full blown nonconformance; something that’s just getting by.
  • ISOCIAL – A party thrown to celebrate passing an ISO audit.
  • ISODA – Beverage served at an isocial.
  • ISOB – The shedding of tears resulting from receiving too many audit nonconformances.
  • ISOHAPPY – The pure joy of conformity!
  • ISONO-NO  –  Activity leading to a nonconformance.
  • BISON – Official ISO mascot.
  • ISORRY – Response to a Corrective Action Request.
  • ISOMETRICS – Used to measure quality objectives.
  • ISOLATION – How the management representative feels when introducing the new system.

 

 

 

Diccionario IT

En el dia a dia de nuestro trabajo, utilizamos una jerga, aveces un tanto dudosa.
Clarifiquemosla:

Mandatorio: Palabra utilizada por managers que no pueden pronunciar la palabra obligatorio.
PM: Dicese de la persona incapaz que lleva adelante un proyecto.
El Papa: El que la tiene suficientemente grande como para tomar decisiones sin sentido.
Ticketing tool: Herramienta hecha para retrasar tu trabajo.
Queue: Lugar donde se acumula tu trabajo
Tracking Hours: Sistema para asegurarse de que no tengas tiempo de tomarte un café.
Change management: Dolor de cabeza
Sev one: La tenes adentro
Meeting: Reunión donde se gasta tiempo para justificar el sueldo
Manager: Ser encargado de hablar de cosas que no sabe y exigirte lo que no se puede.
Twon Hall: Reunión (véase meeting) donde se habla de los logros de la empresa (expresada en millones de pesos), de la cuales nunca vez uno.
OOO: Buscate otro a quien joder, por que yo no estoy
ACTION REQUIRED: Porfavor dignate a mirar este mail
Handoff: quitarte un muerto
Handover/Turnover: recibir un muerto
Hands and Eyes: Ser desprovisto de cerebro
ASAP: Expresión de urgencia en un proyecto que viene retrasado por causa de la incompetencia ajena
Busy: 
Estado del IM que refleja cansancio de ser interrumpido todo el tiempo
On-call: chau finde
backlog: acumulación de muertos
SLA: tiempo de resolución de un incidente definido por un contrato hecho por gente no técnica.

Que palabra agregarías?

The Expert

Hace un par de meses fue publicado este video en Youtube, un corto de unos 7 minutos y medio en tono de comedia, les presento, “The Expert”:

Mi mujer no entiende terminologías técnicas al nivel que yo manejo a diario, así que muchas cosas no son “conversables” o puedo llegar a comentar pero no sería un diálogo, ya que muchos términos específicos de la materia, aunque son usados a diario, no son comprensibles. Sin embargo, al ver este video, entendió perfectamente lo que pasamos a diario las personas técnicas encargadas de implementar proyectos diseñados por otros.

Si ven el video, la premisa es sencilla, el proyecto consiste en 7 líneas rojas. Ahondando más en los detalles, resulta ser que todas tienen que ser perpendiculares, algunas dibujadas con tinta verde y otras con tinta transparente.

Básicamente el jefe de la negociación junta del lado de la empresa de servicio al Project Manager (Walter) y al expert. Del lado del cliente tenemos a la persona que hace el requerimiento, y a Justine, la Design Specialist. El cliente ha pedido cualquier fruta, algo imposible de lograr, y al encargado de la compañía no le importa, pero le ha dicho el cliente que no hay inconveniente. El mismísimo PM no demuestra ninguna dificultad en cuanto a la premisa, aunque en este caso, reconozcamos que es bastante entendible.

Anderson, el experto, se siente conmocionado al escuchar lo que están tratando de hacer, lo cual ya se da cuenta que no es posible lograr el objetivo final del proyecto. Incluso, gracias a los esfuerzos de explicación del experto, hasta casi la especialista de diseño se le ilumina un poco. Inclusive, llega a casi lograr la premisa original, simulando que usa tinta transparente, hasta que le piden dibujar una línea con forma de gatito (porque todos adoran a los gatitos).

En medio de todo eso hay un stop, el tipo a cargo mete su bocado, cierra el tema y se van todos contentos (o casi).

“Of course I can, I can do anything, I can do absolutely anything, I’m an expert”. Son las palabras finales de él.

Estas son cosas con la que las personas encargadas a implementar proyectos de IT en empresas grandes suceden a diario:

  • El cliente pide cualquier fruta (tipo 110% de uptime en sus servidores)
  • El proveedor del servicio dice que su empresa puede hacerlo, y en ese momento no importa cómo realmente, y sabemos que el precio es bajable, lo importante es adquirir el negocio, ganarle al competidor. Luego se verá cómo se hacen las cosas.
  • El PM no tiene idea en absoluto de los requerimientos que se están barajando, simplemente lo pusieron de intermediario.
  • El “experto” es el que tiene que descular cómo tratar de implementar lo que le ha llegado en el diseño de ingeniería.

A lo largo de mis años en el mundo de la informática he recibido requerimientos que eran imposibles de lograr, y más de una vez he tenido que ponerme al teléfono a tratar de explicar a alguien que no tiene un mínimo nivel de idea de lo que se está hablando. Pero por más que no se tenga idea, tiene que haber una relación entre el PM y el Expert en la cual se confíe en lo que el otro plantea.

Si vieron el video, en una parte Anderson plantea, “estoy casi absolutamente seguro que es imposible dibujar líneas rojas con marcador verde”, y el otro le retruca diciendo momentos después “esto está todo mal, porque estás tratando de usar la tinta equivocada”. O sea, no sólo lo descalifican por algo que no tiene nada que ver (está dibujando líneas perpendiculares), sino que en son de ir adelante con la tarea lo aparta, no le da la razón y sigue con la suya.

Cuando explicamos en nuestro trabajo que algo no se puede hacer porque la ingeniería está mal, lo primero que se plantea es que estamos equivocados nosotros, que el requerimiento no puede estar mal, y que hay un rechazo por parte de nuestra parte a hacer el sencillo pedido que se nos hizo, al fin y al cabo se supone que nosotros sabemos, porque somos especialistas, pero a la primera de cambio dudan de nuestra capacidad.

“flaco me pediste un file system de 3 MB, cómo carajo querés que haga eso

Ir a plantear algo así, implica 2 cosas, saber que probablemente el texto lo completó alguien que no sabe del tema, que en realidad se quería poner GB probablemente. Y el feedback será tipo “pelotudo no te das cuenta de lo que quiso poner. Y especifiquemos ya que estamos, esta sería una recreación:

  • Expert: – Pidieron un file system de 3 MB, no puedo crear eso, es muy chico
  • PM: – Cómo lo podemos corregir, qué hacemos ?
  • Expert: – Probablemente sea un error de tipeo, quizás es GB en vez de MB
  • PM: – Bueno, crealo de 3 GB
  • Expert: – No sería correcto, yo tengo que hacer lo que dice el documento
  • PM: – Vos hacelo mientras, yo contacto al que hizo el diseño
  • Expert: – Pero tampoco puedo, el de storage me dio discos de 3 MB
  • PM: – Y cuál es el impedimento?
  • Expert: – No puedo crear un file system de 3 GB en un disco de 3 MB
  • PM: – Y qué hacemos entonces?
  • Expert: Fijate que también hay que volver a pedir los discos, los tamaños no están bien
  • PM: – No podés crear los file systems con todo el espacio que tenés en el disco y luego lo agrandás?
  • Expert: Se podría pero no tendría sentido en este caso, ya que terminaría teniendo 2 discos para 3 GB, uno de 3 MB y otro de 2.97 GB eventualmente.

Esta conversación de arriba es totalmente improductiva. El PM no entendió nada de lo que le planteaste, pero probablemente le quede la idea de que vos no querés hacer lo que se te pide, y no le estás poniendo voluntad al asunto, y no sólo eso, sino que estás poniendo piedras.

Créanme, no todos los PMs son iguales, he tenido la oportunidad de toparme con 2 ó 3 PMs que eran excelentes, pero me sobran los dedos de una mano. Yo no soy un super especialista, pero al menos tengo idea de que 7 líneas entre sí no pueden ser perpendiculares, o tener que dibujar cosas rojas con tinta verde es algo imposible de hacer.

Y es altamente probable que nos terminen mandando a hacer otra cosa que nada que ver con el objetivo del proyecto (inflar el globo de color rojo).

Parafraseando al experto Anderson, podría decir que yo también puedo hacer cualquier cosa, te puedo hacer que un disco físico pertenezca a dos volume groups, crear discos con block size impar o definir 5 rutas default en el mismo server (y por diferentes placas de varios colores primarios). Total, sepa hacerlo, pueda hacerlo o no, el resto de la gente de mi equipo probablemente NO TENGA IDEA.

Un saludo especial a Orion Lee (el actor que encarna a “the expert“) ya que tuvo la amabilidad de responder un par de tweets que hice al respecto.

Nos leemos pronto.

BTW: El tipo que hizo el script, Lauris Beinerts, es un capo.