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.

Anuncios

Cuanto tardaste en estar productivo?

En las grandes ITs suelen tardar en darte acceso a todo lo que necesitas, que la tarjeta de entrada, el mail, la vpn, acceso a distintas cuentas etc etc. En mi caso, en una de las que trabaje, tardaron 3 meses hasta darme todo para que pueda trabajar. Y vos? cuanto tardaron en dejarte productivo?

Esta entrada fue sugerida por Ejecutivo Crítico

update: Esto no sólo pasa en las ITs, pero es irónico que en las empresas de tecnología sea tan lento el proceso.

Horas trabajadas

Como si no fuera poco los sueldos paupérrimos, las exigencias absurdas, los managers incompetentes, y los cursos online que nos obligan a tomar, hay que trackear las horas trabajadas. Evidentemente no se invento la solución definitiva para este asunto, porque no solo que cada empresa utiliza una herramienta distinta (obviamente) si no que utilizan VARIAS HERRAMIENTAS CON LA MISMA INFORMACIÓN!!!!!!
Excel, Claim, Máximo, GTT, Omega, CATW, Proactive, TimeSheet, SAP  etc etc,

Cada una con sus códigos, cada una con su interfaz, y entre todas, no completan una.
Trabajar para varias cuentas puede ser un dolor de cabeza, trabajar para distintos proyectos en varias cuentas es un  #$%”%&&!!!#$%=&!!!
Vos que sistema de traking de horas usas?

 

Los Remeros

Desde el año 2008 se celebra una competencia de remo entre la Inmense Bureaucratic Machine (IBM) y la Tied With Wire Butchers & Groceries (TWW), equipos de dos afamadas empresas de Tecnología con liderazgo local, en una pista neutral para, evitar favoritismos.  
  
Iniciada la competencia, los remeros de la TWW comenzaron a destacarse, y llegaron a la meta rápidamente. El equipo de IBM llego una hora después. De regreso en Catalinas, el comité ejecutivo se reunió para analizar las causas de tan desconcertante e imprevisto resultado.  
  
Conclusiones:  
En el equipo TWW  había un jefe de equipo y 10 remeros.  
En el equipo IBM había 9 DPEs, 1 Team Leader y 1 remero.  
La decisión paso a la esfera del planeamiento estratégico para el año próximo con una restructuración que calaría en lo mas profundo de la delegación.  
  
En 2009 y producida la largada de la nueva competencia, el equipo de la TWW volvió a adelantarse desde el comienzo. Esta vez el equipo Big Blue arribo a la meta 2 horas mas tarde. El nuevo revés, obligo al Comité a realizar otro exhaustivo análisis de la situación.  
  
Conclusiones:  
En el equipo TWW había un jefe de equipo y 10 remeros.  
En el equipo IBM, luego de los cambios introducidos por Planeamiento, la composición era la siguiente:  
1 Team Leader  
1 Dispatcher  
2 Client Specialist  
7 DPEs  
remero  
El remero iniciaba la carrera al recibir el ticket aprobado con la orden de largada, y al finalizar debía registrar su trabajo en el mismo, junto con su análisis de la carrera, para una posterior evaluación que permitiera mejorar aún mas su desempeño. Asimismo debía informar al momento de la llegada al Team Leader y a los DPE. 
  
La conclusión del comité que analizo las causas de los desvíos fue unánime y lapidaria en cuanto a su revocabilidad:  
  
El remero es un incompetente, sentencio….  
  
En 2010 una nueva chance para equipo fue abierta. Con el objeto de tomar el toro por las astas, el análisis del problema fue encargado al C.O.A., el que aplicando el Defect Prevention Process y teniendo en cuenta la Delivery Capability Matrix, elaboró  un plan destinado a mejorar la productividad, introduciendo novedosas modificaciones en la organización que generarían sin lugar a dudas incrementos substanciales de efectividad, eficiencia y eficacia. El resizing eliminaría el desperdicio basándose el las 7 palancas y seria la llave del éxito; y el broche de oro de un trabajo que humillaría al los mismísimos Peter Drucker y Jerry Lewis.  
  
El resultado fue catastrófico. El equipo IBM llego 6 horas mas tarde.  
  
La reunión de comité se realizo esta ves en el salón VIP del Plaza y elaboro las siguientes conclusiones luego de analizar exhaustivamente el informe de una afamada consultora con sede en Nueva York.  
  
Para desconcerto general, el equipo TWW opto por la formación tradicional de 10 remeros y 1 jefe de equipo.  
El equipo IBM  utilizo la formación vanguardista integrada por:  
1 Team Leader  
1 Dispatcher  
2 Assistant Dispatchers  
1 APM  
1 Engagement Manager  
4 Client Specialists  
5 DPE  
6 SDM  
remero  
El remero comenzaría su tarea al recibir en Maximo la W.O. asociada al Ticket de Largada aprobado. Registraría cada una de sus paladas en la Timing Tool, así como las pausas para respirar y cualquier otra actividad que realizara, abriendo un registro en dicha herramienta al momento de iniciarlas, y cerrándolo al finalizar cada una de ellas. Al terminar la carrera debería cerrar también el ticket y la W.O..  
  
En la reunión de cierre el CEO tomo la palabra y con voz quebradiza anuncio que la empresa no iba a abandonar su tradicional política de busqueda de la excelencia basada en la calidad de sus recursos humanos y la dedicación de la empresa para con ellos, que fueron, son y siempre serán su capital mas importante.  
  
Por el momento, el C.O.A. sigue reunido, analizando que mas puede agregarse a la estructura para revertir la performance. En su autismo, nadie se percata del lugar vacío en una punta del bote. Ya no queda nadie que quiera empuñar los remos.  
  
Mientras tanto, se rumorea que el equipo TWW contará con 11 remeros para la próxima temporada. Sin embargo, no habrá competencia. El equipo del Big Blue no será invitado a participar. Ya nadie quiere poner plata por un espectáculo tan triste y un rendimiento tan pobre.

Manager Expectations

Lamentablemente a veces tenemos que atender esas meetings o reuniones online,  con un teléfono y algún otro soft que nos brinda la posibilidad de ver unos slideshows de un documento Powerpoint que alguna persona con escaso conocimiento técnico ha realizado durante unas dos semanas (justifica tal vez medio sueldo, piensenló).

En esas reuniones se habla mucho, uno 80% de cosas que no nos interesa, porque realmente no tenemos la oportunidad de darle bola, porque estamos haciendo otra cosa de trabajo, o porque simplemente justo era la meeting a la hora de almorzar y cuando nos íbamos a despejar un cacho de la miseria diaria, nos avisan QUE HAY MEETING Y ES MANDATORIA.

Asistimos a la meeting, donde gente que está a muchos miles de kilómetros muestra sus gráficos de torta, barritas de métricas y trata de medir constantemente cosas que no son medibles, o que si bien se pueden llegar a medir, distan mucho de ser una realidad cuantitativa.

En medio de toda la sarasa vemos un slide de PowerPoint con este texto:

Availability

Es curioso, porque se supone que la empresa tiene un programa de Wellness, que está preocupada por nuestra salud y quiere que vivamos en familia, que tengamos una vida además del trabajo, pero la misma gente de la empresa fomenta en cierta forma el AntiWellness.

Está bien que uno tenga que terminar algo necesario por una fecha específica (que alguien más dispuso), o que querramos terminar algo para estar en tema porque venimos bien (e inclusive a veces no sabremos si al día siguiente funcionará el citrix con el usuario adentro de la vpn adentro del openconnect con el que entramos por medio de un práctico RSA), pero este pensamiento es casi militar.

Uno estudia, tiene tiempo de viaje, practica alguna actividad física afuera del trabajo IT, o tal vez simplemente quiere volver a su casa para seguir haciendo sus cosas, lavar platos, ropa y colgarla, ordenar un poco la casa, ver la tarea de los chicos, además de preparar las cosas para cenar mientras ellos se bañan casi solos desperdiciando el shampoo, la crema de enguaje y mojando todo el piso del baño (que con tanto esfuerzo mamá lo lavó el sábado, a pesar de haber trabajado toda la semana).

En la sociedad de hoy el tiempo no alcanza. Así como hacemos malabarismos en nuestros hogares, estamos también malabareando en el trabajo. Trabajando con varios clientes en simultáneo, sesiones de putty, ventanas de varios navegadores (porque no hay nunca uno compatible con todo), aplicaciones de Office (hasta tuvimos que instalar la mierda del Visio porque algún ingeniero hace dibujitos con él, y no los exporta a GIF, nos manda un .VSD que pesa 10 MB).

Señores managers, sabemos que la empresa quiere ganar más plata, con menos costo, y que si el día tuviera 40 horas trabajaríamos 16 por lo menos, que si hubiera un día Osvaldo probablemente lo terminaríamos trabajando también. Pero nosotros los muchachos de IT tenemos una vida, para tirarnos un pedo en el sillón mientras jugamos al Portal 2, tomarnos un rato probando la nueva distribución Linux, cocinando, o simplemente desenchufarnos.

La frase del JPG de arriba es un parafraseo de “Asegúrense de que nosotros podamos disponer de su tiempo 7×24“. Y lo peor del caso, es que hay empresas que no pagan ni extras ni guardias.

Proyectos para ayer, managers incompetentes, normas, ISOs, estándares, procesos, team leaders y todo eso que te hace el trabajo mas complicado de lo que debería ser, lo vas a encontrar entre un mar de opiniones super subjetivas y un container de quejas en DORK IT!