Créditos:
40 horas a la semana. 160 horas al mes. 1760 horas al año. Una persona que tenga la suerte de trabajar desde los 25 hasta los 65 años pasará más de 70.000 horas de su vida en una oficina. Míralo de otra manera: si el día tiene 24 horas y trabajas de 9 a 18:30, estás la tercera parte del día en una oficina. No se a vosotros, pero lo que es a mí, si voy a pasar la tercera parte del día en un sitio espero que sea un lugar agradable donde me lo pase bien. Porque si no, sinceramente, vaya asco.
Nos pensamos que lo de llamar a un bar «La Oficina» se lo inventaron Mortadelo y Filemón (Imagen de SteveInLeighton)
El otro día describí que el ambiente de trabajo en MediaNet era un «entorno joven y dinámico«, y un compañero comentó que con el paso del tiempo «cada vez te hace menos gracia leer entorno de trabajo joven». Así que he adelantado una entrada que tenía pendiente sobre los entornos de trabajo carcelarios para comentar por qué a mí me gusta trabajar en un ambiente «joven y dinámico».
No se de nadie que haya estado en el talego, pero he leído algunos libros y he visto suficientes películas como hacerme una idea de cómo es la vida en una cárcel. Y la verdad es que una cárcel puede tener muchos paralelismos con una oficina. Más de los que imaginas. Y no me refiero a lo de las duchas, que yo respeto todo lo que hacen dos o más adultos de forma consentida.
«Number 47 said to number 3: You’re the cutest jailbird I ever did see» <- EXACTO (Imagen de erjkprunczyk)
Muchas personas trabajan en una cárcel y no lo saben. Echa un vistazo a tu alrededor, sabrás que estás trabajando en un ambiente carcelario gracias a los siguientes síntomas:
Pero si hay una característica definitiva de los ambientes de trabajo carcelarios es el concepto de «favores«. Efectivamente, en el talego tu vida es más sencilla si le haces un favor a alguien. Por ejemplo, puedes conseguir un trabajo en la biblioteca si le das a alguien cigarrillos; o puedes conseguir un retrete con tapa si le haces a alguien un pincho con la patilla de tus gafas; o puedes conseguir una ampliación de memoria o que te cambien el PC si eres amigo del que hace los pedidos.
Yo personalmente odio las organizaciones en la que los procesos funcionan o dejan de funcionar según lo bien que le caigas a la persona que los realiza. No sólo porque no sea efectivo, eficaz o sea injusto; es que dotar a las personas de esa capacidad me parece un síntoma inequívoco de que la empresa no está pensando en grande.
Cada vez que oigo a alguien en un ambiente teóricamente profesional decir la frase «el que no llora no mama» me subo por las paredes. Os juro que me dan taquicardias. Se me hincha la vena del cuello. Supongo que si la sigo oyendo de aquí a un par de años me pondré verde y me arrancaré la ropa, como Hulk.
Ahí les tenéis, tranquilitos esperando a su revisión anual (Imagen de Herkie)
Si para que un profesional arregle un problema, el que sea: un cambio de proyecto; que le mejoren el equipo; que le suban el sueldo; que le den más responsabilidad; me da lo mismo, si alguien tiene que llorar, patalear, cagarse encima y montar el número para que le atiendan, entonces estás trabajando en una guardería. No se cómo decirte que si tienes más de 3 años no deberías estar en una guardería.
Como profesional, no te interesa, la verdad. Tienes que exponer tus necesidades, obviamente. Tienes que usar los canales que tengas a tu disposición para trasladar el mensaje de que tienes una demanda que necesita ser atentida. Exponerla de manera racional, clara y concisa. A ser posible, atendiendo a factores objetivos, contrastables y medibles. Y una vez expuesta, tienes que esperar la respuesta de la empresa y actuar en consecuencia. Creo que esa es la forma en la que los adultos tratan estas cosas.
No confío en las empresas en las que para que solucionen tus problemas tienes que presentar una carta de baja. Es un modelo de gestión reactivo, en el que si no te quejas no existes, en el que sólo arreglo tu problema si pone en peligro los intereses de la empresa. Porque casualmente hay personas adultas que hace muchos años salieron de la guardería. Y no quieren tener que llorar y patalear para que les escuchen: directamente se van a otro sitio. Efectivamente, el ambiente de trabajo de la guardería, donde «el que no llora no mama» favorece los desequilibrios, las injusticias, y sobre todo, favorece la fuga de talento.
¿Qué es para mí un ambiente de trabajo Joven y Dinámico? Desde luego no tiene que ver con que las personas tengan de media 28 años, lleven la camisa por fuera y salgan de cañas los jueves. Menuda chorrada. Sobre todo porque con la edad, uno acaba por meterse la camisa por dentro y querer irse corriendo a casa a estar con la familia.
No es sólo una cuestión de imagen, es una cuestión de confort (Imagen de chrisjagers)
Para mí un ambiente de trabajo Joven y Dinámico es aquél en el que:
Por otra parte, es sencillo definir un ambiente Joven y Dinámico por contraposición a un ambiente Gris. En un ambiente Gris la burocracia mata la iniciativa y la innovación, las personas se centran exclusivamente en sus propios problemas, las cosas son así porque siempre lo han sido, no hay oportunidad para el desarrollo personal / profesional, etc.
Total. Que yo no se a vosotros, pero a mí me gusta trabajar en un ambiente Joven y Dinámico. Por su puesto, cada persona tiene su propia percepción del ambiente en el que trabaja. ¿Estás en el talego? Pues entonces más te vale que intentes escapar. ¿Trabajas en una guardería? Asegúrate de llevar dodotis y polvos de talco. ¿Cuál es tu ambiente de trabajo?
Se conoce como Compañía Easy, a la Compañía E del 2º Batallón del 506 Regimiento de Infantería Paracaidista de la 101ª División Aerotransportada («Screaming Eagles«). Se formó principalmente por civiles voluntarios en 1942, que fueron sometidos a duro entretamiento prácticamente de forma ininterrumpida hasta su primer salto de combate (y bautismo de fuego) la madrugada del 6 de Junio de 1944.
C. Ware y C. Plaudo, del grupo de demoliciones del 506 «Los 13 Sucios», se preparan para saltar sobre Normandía (Imagen del Archivo Nacional de US, de dominio público en Wikipedia Commons)
Durante las campañas de Normandía (Operación Overlord), Holanda (Operación Market-Garden) y Bélgica (Batalla de las Ardenas), la Compañía Easy demostró ser una de las unidades de infantería ligera más efectiva, principalmente por estos tres aspectos clave que veremos a continuación.
Pilotar un bimotor de transporte de tropas en plena noche manteniendo la formación no debe ser fácil. Añade a eso la niebla. Añade volar sobre territorio enemigo. Añade fuego antiaéreo de 20 y 40mm. Multiplica el fuego antiaéreo durante 16 interminables minutos. Y luego mira tu agenda y comprueba que es tu primera experiencia de vuelo en combate. La conclusión es que los pilotos de los C-47 Skytrain hicieron lo que pudieron, pero acabaron dejando a los hombres de la Easy Company dispersos y muy alejados de sus zonas de salto. Y por tanto, muy alejados de sus zonas de reunión.
Para más inri, las bolsas de pierna (unos macutos donde se metía todo el equipamiento del soldado y que se colgaba de la pierna) demostraron ser un fiasco: la mayoría se desprendieron durante el salto, los hombres perdieron sus fusiles, ametralladoras, y munición; así que se vieron a la 1 y pico de la madrugada dispuestos a asaltar la «Fortaleza Europa» con sus armas cortas, carabinas y un puñado de granadas.
Pero uno no llega a ser un soldado de Élite si cuando se enfrenta a una situación adversa se esconde debajo de un puente, o se sienta en una granja a esperar a ver si pasa algún superior que le cuenta qué tiene que hacer. A lo largo de la península de Cotentin, durante el Día Más Largo, todos los paracaidistas demostraron tener gran iniciativa. ¿Por qué? Porque tenían claros cuáles eran sus objetivos y habían sido entrenados para lograrlos. Su misión era hostigar a las fuerzas alemanas; impedir que se organizasen contraataques efectivos; asegurar los puentes y las salidas de las playas donde se realizarían los desembarcos… ¡¡apenas 5 horas más tarde!!
Bob Noody iba al trabajo cargado con 90Kg y nosotros quejándonos de lo que va a pesar el nuevo iPad (Imagen del memorial de Veteranos http://www.costoffreedomveteransmuseum.com)
Todos los hombres de la División, con independencia de su rango, sabían lo que tenían que hacer, y lo hicieron lo mejor que pudieron. Se agruparon en unidades improvisadas, formadas por soldados de diferentes especialidades provenientes de todo tipo de compañías y batallones. Incluso de otras Divisiones que también habían quedado dispersos (algunos tardaron hasta 5 días en reportar en su Compañía) Se crearon de manera improvisada nuevas cadenas de mando. Y se pusieron manos a la obra: defendieron posiciones en cruces de carreteras, realizaron ataques improvisados allí donde encontraban al enemigo, contactaron con la Resistencia francesa, tendieron emboscadas, sabotearon todo lo que pudieron.
Mantuvieron ocupados a los alemanes.
Separados de sus compañeros, desorientados y mal armados, cada hombre trató de sacar provecho de su situación y adaptarse lo mejor posible. Trataron de establecer contacto con sus unidades y sus responsables, sí, ese era la primera parte del Plan. Pero no hicieron del Plan su Misión. No les habían lanzado sobre Normandía para reagruparse.
Es tu obligación como gestor que tu equipo conozca claramente sus Objetivos, qué se espera de ellos y cómo podrán determinar si los han logrado. Es la única manera que hay de Delegar.
Recuerda: cuando gestiones un equipo de profesionales cualificados, nunca les digas cómo tienen que hacer su trabajo, ellos lo saben mejor que tú.
El Asalto que las mermadas fuerzas de la Compañía Easy realizaron a la 6ª Batería del 90º Regimiento de Artillería alemán emplazada en Brècourt Manor se considera un Caso de Estudio de cómo una fuerza de infantería ligera debe asaltar una unidad enemiga en posiciones preparadas. Hay algunas fuentes que incluso afirman que se estudia en Academias militares como West Point (aunque yo no he dado con la fuente original)
La situación era la siguiente. 1 Batería = 4 cañones de 10.5cm, en posiciones preparadas comunicadas por una red de trincheras. La dotación de una Batería era de 5 artilleros, a lo que se suma el equipo de ingenieros que comprobaban las tablas de cálculos de tiro, observadores para cañón, y los oficiales al cargo de la Batería. Pero claro. Estamos hablando del día D a las 8 y media de la mañana. La Batería emplazada en Brècourt Manor tenía una excelente línea de tiro sobre la Playa Utah, así que había sido reforzada por una compañía de Fallschirmjägers, osea, paracadistas alemanes. En general se considera que había entre 50 y 60 enemigos en esa posición.
Esa posición que fue atacada por una docena de chicos de la 101st que llevaban enredando en territorio enemigo más de 7 horas. «Menudo desastre», pensaréis. En efecto.
No, si lo mejor es contarlo en las cañas de después (Imagen de PhotosNormadie)
Para empezar, los hombres que condujeron el asalto llevaron el mínimo equipamiento imprescindible. Se establecieron dos posiciones fijas para que las ametralladoras ligeras dieran fuego de cobertura, parapetadas tras una cerca de piedra. Se crearon dos equipos de flanqueo de 3 hombres cada uno, uno avanzaría por la derecha y otro por la izquierda, quedando éste encargado de atacar con granadas la primera batería. Un tercer equipo sería el que realizaría el asalto frontal ¡atancando desde campo abierto!. Como os podéis imaginar, la dotación del primer cañón, viéndose sorprendida simultáneamente desde 3 direcciones, no tardó abandonar sus posiciones.
Una vez demolida la primera pieza, la fuerza asaltante mantuvo la presión del asalto, aprovechando la ventaja que les daba la red de trincheras para llegar hasta los emplazamientos de las baterías dos y tres, mientras se evacuó a los primeros heridos y comenzaron a llegar refuerzos. El cuarto cañón fue capturado precisamente por una escuadra de refresco que había llegado a ayudar en el asalto.
Una vez que las cuatro piezas de artillería fueron destruídas, después de hacerse con los mapas de las posiciones defensivas alemanas en la Playa Utah, con una docena de prisioneros y tras abatir más de 20 enemigos, el capitán Winters dio la orden de retirada.
El resultado se mide en términos abstractos, como «victoria», «importancia estratégica», etc., y en términos tangibles como entre otros, 1 Cruz de Servicios Distinguidos, 3 Estrellas de Plata, 10 Estrellas de Bronce, y 4 Corazones Púrpura.
Si tienes que hacer una tarea compleja cuya dificultad te desborda, confía en los especialistas.
Cuenta con personas todo-terreno que aportan aire fresco y pueden servir de refuerzo allá donde más se les necesita.
Aprende a determinar cuándo has logrado tu objetivo.
Recuerda: la mayor parte de las veces todo sale bien si las personas hacen lo que mejor saben hacer.
Finalizamos este lote de 3 aspectos claves del Management 101st con la importancia que tiene para un equipo que su responsable sea un ejemplo de comportamiento. Y eso ocurrió claramente en el asalto a Carentan.
Por su ubicación geográfica, Carentan era una ciudad clave para consolidar las cabezas de las Playas Utah y Omaha. Por eso se habían concentrado en ella las tropas de Élite del 6th Fallschirmjägerregiment al mando del Teniente Coronel Von der Heydte. Para que os hagáis una idea, este tipo llevaba en las fuerzas aerotransportadas alemanas desde 1940. Tenía en su palmarés la Operación Merkur (el asalto desde el aire a Creta en 1941), había escapado de la derrota de El Alamein en la mítica Brigada Ramckle (recorrieron más de 300km de desierto en vehículos robados al enemigo)… Era un oficial inteligente y experto, lo que se conoce tradicionalmente como Némesis. Pero aún hay más. La ciudad estaba defendida por unidades de infantería de línea alemana, y en la zona se encontraba el 37º Regimiento de la 17th SS Panzergrenadierdivision «Götz von Berlichingen».
En fin, pensadlo dos veces la siguiente vez que vayáis a usar a la ligera la expresión «meterse en un jardín«.
A veces me pregunto si los reporteros de guerra viajan con niñas rubias con lazos para estos casos (Imagen de PhotosNormandie)
A las 0600 de la mañana del 10 de Junio de 1944, todo estaba preparado en la zona de ataque de la Compañía Easy. Un pelotón a la derecha de la cuneta. Otro a la izquierda. Un tercero de reserva. El cruce de caminos a 50 metros de campo abierto. Y una MG34 alemana en posición de tiro sobre la zona, preparada para triturar a todo el que pasase por delante.
Cuando el Capitán Winters dio la orden ¡Adelante! y el primer pelotón avanzó hacia el cruce, fue sometido a una lluvia de plomo. Sólo 6 de los 30 hombres avanzaron. El resto perdió la compostura cuando empezaron a caer balas del calibre 7,92mm a razón de 900 por minuto. Cosa normal, por otra parte.
Así que Winters se plantó en medio de la carretera diciendo a sus hombres que salieran de la cuneta y avanzasen. Es más, tiró su equipo al suelo y se dedicó a darles patadas en el culo. Recorrió la carretera de izquierda a derecha, diciéndole a los muchachos que tenían que avanzar. Las balas silbaban a su alrededor. Rebotaban por todas partes. Y el Capitán estaba de pie en medio del fuego enemigo diciendo que había que salir de la «zona de confort» y atacar.
Al final a los hombres no les quedó más remedio que salir. Y atacar. Y con todo el folllón, los 6 soldados que habían avanzado en primer lugar tuvieron la distracción que necesitaban para colocar un puñado de granadas y neutralizar la ametralladora. Una hora más tarde, la zona estaba asegurada (por el momento)
Tienes que ser capaz de demostrar al equipo que entiendes lo que les estás pidiendo. Y que tú también serías capaz de hacerlo si ese fuese tu trabajo.
Tus hechos en el campo de batalla inspiran más que tus palabras, y no digamos que cualquier cita motivacional de un tercero, se apellide Einstein o Jobs.
Recuerda: aunque a veces no hay más remedio que pasar a la fase de patadas en el culo, siempre duelen más cuando te las da el cliente.
Hay muchas más lecciones de gestión que extraer de personas que se jugaban su vida y la de los demás con sus decisiones. Hasta aquí estas tres. Espero que os haya gustado este post, conjuga dos de mis temas favoritos, la gestión de personas y la historia militar. También espero que a alguno le sirva de incentivo para ayudarme a definir la Metodología de Desarrollo de Software Blitzkrieg Programming 😉
Avisadme por favor si se os ha hecho un poco largo.
Una imagen vale más que 1.000 Ads
Estoy bastante cabreado, desde el viernes pasado Google ya no me resalta los Ads en los resultados de búsqueda. Sólo me pasa en el Mac de la oficina, pero lo hace en Chrome, Safari y Firefox. En casa de momento no me han aplicado esta «upgrade«. Así que me he instalado la extensión de AdBlockPlus, y he activado la opción de que no me muestren publicidad no intrusiva.
Cómo he podido vivir todo este tiempo sin esto…
Se denomina Blitzkrieg a un estilo de operaciones militares llevadas a cabo por una punta de lanza atacante que se compone de una gran concentración de unidades blindadas, mecanizadas y autopropulsadas, que actúan en colaboración estrecha con su apoyo aéreo.
Una vez que se produce la ruptura del frente enemigo, la fuerza atacante penetra tras sus líneas y procede a la neutralización de los focos de resistencia por medio de la agilidad y maniobrabilidad de las Divisiones, su velocidad y el factor sopresa.
«Vamos a podar el Jira, cambio» (Imagen de German Federal Archive bajo licencia Creative Commons de Wikipedia Commons)
Hay cuatro elementos característicos de una ofensiva Blitzkrieg:
Se me ocurre que podría ser por lo menos curioso definir una metodología de desarrollo que siguiera los principios de la Blitzkrieg:
No se, podría ser una idea. Desde luego a mí el nombre me gusta, jeje 😉 Supongo que requiere alguna revisión, puesta en común, etc. ¿A alguien le apetece definirla conmigo?
PS- no busquéis connotaciones políticas en aquello que sólo tiene connotaciones de estrategia militar, que os conozco
Ojalá me dieran un euro cada vez que escucho que «el proyecto está mal vendido«. Junto con «en mi local funciona» es la segunda frase autocomplaciente más habitual del mundo, forma parte del acervo popular de descarga de responsabilidad. Es curioso, porque a las personas más brillantes que conozco nunca se lo oigo decir, pero bueno. Cosas mías.
A mí me encanta escuchar que un proyecto está mal vendido, y como los que me conocéis sabéis que no me callo, siempre respondo con un habitual «¿y tú cómo has ayudado para que estuviera bien vendido?«. ¡Un momento! Guardiola, ¿no estarás insinuando que los técnicos tienen que participar en el proceso de venta? ¡En absoluto! No lo insinúo, lo afirmo categóricamente.
No le preguntes a Kennedy qué puede hacer por tus proyectos, pregúntatelo a ti mismo
No me lo puedo creer. Técnicos involucrándose en el proceso de venta. ¿Pero no habíamos dicho que los técnicos son los que ejecutan y los comerciales los que venden? También habíamos dicho que los comerciales no tienen ni puta idea de lo que venden, y a lo que se dedican es ir a comer y tomar cafés con gente mientras los demás partimos teclados a base de programar. Tranquilos, en este post no voy a revindicar el trabajo del comercial (sólo faltaba)
No, este post vuelve a tratar sobre cosas que son necesarias para uno mismo, y que tengo que hacer aunque no me gusten, sea como sea, porque me acerca a mis objetivos.
En general un proyecto se vende de dos maneras: o porque alguien te llama y te lo da, o porque tienes que competir con otros para conseguirlo. En casos de proyectos TIC, la cosa va más allá. Estamos en un mundo en el que la calidad del software cada vez pesa menos como factor a la hora de la toma de decisión de compra. Especialmente en el Sector Público, donde se ven concursos en los que la oferta económica es el 60% de la puntuación. Casualmente, los responsables de esos organismos se lamentan de la baja calidad del software que reciben, de lo mal pagados que están los profesionales, de lo mal que está el sector TIC… En fin, todo muy coherente.
Lo mejor es no hacer caso a las voces (Imagen de rocksss)
El caso es que acreditar la capacidad técnica parece que se ha convertido en condición necesaria, pero no suficiente; lo que significa que al final hay que hacer una oferta técnica: demostrar que se ha entendido el problema, plantear una solución que tiene sentido, identificar el equipo que lo va a lograr y poner un precio. Así que señores, si los comerciales no tienen ni puta idea de lo que venden, tendrán que ser los técnicos los que se pringuen y aporten la solución técnica. ¿Y por qué querría un técnico ayudar a conseguir un proyecto? Principalmente por dos motivos, a cual más egoísta que el anterior.
Si no tienes claro que el dueño de tu carrera profesional eres tú mismo entonces necesitas urgentemente un choque con la realidad.
Siempre que he hecho entrevistas a candidatos me ha gustado decirles las cosas claras; y una de ellas es que no les puedo garantizar que los proyectos en los que vayan a participar vayan a ser interesantes. Obviamente, el primero siempre tiene que tener ese punto que haga que alguien deje su trabajo para empezar en un sitio nuevo. Pero una vez acabado… (porque sí amigos, los proyectos acaban) pues no se puede saber. En una empresa de software hay de todo, apuesto que hasta en la NASA tienen tanto proyectos virgueros de microprogramar vehículos de exploración en Marte como mantenimientos evolutivos del sistema de nóminas, y nadie quiere caer en el segundo.
Aparta tus sucias zarpas de mi carrera profesional (Otra imagen de gatitos, esta es de pippy & timmy)
Eso quiere decir, que un programador egoísta que se preocupa por sus objetivos personales tiene que tener claro que no puede dejar en manos de un comercial que no tiene ni puta idea la capacidad de acceder a proyectos interesantes.
Cuarta Ley del Programador Egoísta: Si quieres participar en proyectos interesantes, no te quedes esperando a que te caigan del cielo.
Así que la próxima vez que te pidan ayuda para preparar una propuesta, destierra de tu cabeza los pensamientos autocomplacientes como:
Si no te parece suficiente, aquí viene el segundo motivo. Es todavía más duro que el anterior.
Exacto. No hay mayor muestra de inteligencia (emocional o no): si vas a acabar metido en el proyecto más te vale asegurarte que se va a hacer como crees que debe hacerse, porque al final, el que va a estar metido en la trinchera vas a ser tú. Así que por lo menos, encárgate de decirle al Teniente cómo tiene que ser la trinchera, dónde hay que tender las alambradas, cuántos sacos terreros necesitas para protegerte del fuego enemigo, cómo disponer las Vickers para que tengan mejor campo de tiro, y qué vas a hacer si el enemigo usa Gas Mostaza. Si no lo piensas tú, no te preocupes, otro lo pensará por tí.
Oh My God! Aquí pone que vamos a desarrollar un gestor de contenidos a medida en 3 jornadas… ¡Malditos comerciales! ¿Por qué no habrán metido un Joomla?
En general, como norma de vida, nunca pierdas la oportunidad de definir cómo debe ser cualquier puzzle en el que seas una pieza. Al final, todo el mundo opina sobre un proyecto: precisamente de eso trataba el primer título de este post. Opinar está muy bien, pero las personas con objetivos además de opinar actúan.
Quinta Ley del Programador Egoísta: Aprovecha cualquier ocasión que tengas para que los proyectos se vendan como tú crees que deben venderse.
Esta Ley tiene un Corolario:
Corolario a La Quinta Ley del Programador Egoísta: Si pudiste implicarte en la venta de un proyecto, pero miraste hacia otro lado, a nadie le va a importar lo mucho que te quejes luego.
Porque al final, el mundo de los proyectos se basa en que primero se vende y luego se ejecuta; al contrario que el mundo de los productos. Tienes dos alternativas: trabajar para conseguir llegar a tu objetivo de aprender y trabajar en proyectos cojonudos ( y lograrlo, o no), o confíar en que alguien lo va a hacer por ti (y a ver qué pasa). Sólo en una de las dos alternativas puedes llegar a tener control: espero haber dejado claro que a mí la que me funciona es la primera.
«… we are here to help the developers, because inside every freakie there is a presales trying to get out…» (Imagen de eks4003)
Por último, me gustaría recordar a todos los desarrolladores (egoístas o no) que por encima de las leyes de los programadores, hay una Ley Universal de las empresas de servicios.
Ley Universal de las Empresas de Servicios: La venta nunca se para. Las ofertas se presentan se impliquen o no los técnicos que las van a hacer.
Espero que la próxima vez que os pidan ayuda para preparar una oferta seáis un poco más egoísta, penséis en vuestro propio beneficio, y lo hagáis.
Una de las cosas que más echo en falta en los técnicos es el egoísmo. Se que es una frase fácil de malinterpretar, por eso quiero explicar a qué me refiero.
En general, en el mundo técnico he tenido la suerte de trabajar por norma con personas que se dejan la piel por ayudar a sus compañeros. Siempre he defendido que todos somos muy majos para tomar unas cañas y salir de copas (alguno incluso pagamos una ronda), pero a los compañeros se les conoce bajo presión, cuando las cosas van mal, no funciona nada, empiezan a llover las hostias y entonces se ve quién se arruga y quién tiene lo que tiene que tener.
Da igual que lo llames Scrum o Melé, sigue siendo una metodología ágil (Imagen de John_Scone)
También me parece fundamental, como parte del valor que aporta un profesional a su empresa, la actitud de dejar lo que se está haciendo para echarle una mano a un compañero que necesita ayuda. En MediaNet trabajo con esa clase de personas, igual que antes lo hacía en SATEC.
No entiendo nada, Guardiola, estás hablando de compañerismo y generosidad en un post que trata sobre el gen del programador egoísta; definitivamente se te ha ido la pinza; adiós.
Bueno, es que no me refiero a ese tipo de egoísmo. Me refiero al egoísmo que tiene que ver con hacer cosas que no me gustan, pero que tengo que hacer porque son necesarias para mí mismo. Y del egoísmo que tiene que ver con hacer cosas por las que no me pagan o para las que (creo que) no tengo tiempo, pero que tengo que hacer porque me gustan y si no las hago yo, las harán otros en mi lugar. Me refiero al egoísmo que viene del ego, del yo, de aquello que tengo que hacer sea como sea y cueste lo que cueste porque me acerca a mis objetivos. (Otra vez se repite la frase, acercarse a los objetivos de uno. Es la segunda que vez que la uso en el blog. No será la última.)
El gen del programador egoísta, o mejor dicho, el poco frecuente gen del programador egoísta, se materializa claramente como recesivo en dos situaciones que seguro que todos hemos vivido alguna vez; la primera de ellas la trataré en este post (y la otra la añado a la larga lista de post pendientes)
El gen del programador complaciente se manifiesta dominante frente al egoísta en todo lo que tiene que ver con pruebas e incidencias.
Los proyectos con presupuestos cerrados suelen ir bien hasta la semana antes del paso a producción, da igual que se usen metodologías ágiles o no. Todo va bien, las historias de usuario se completan, se va gestionando el cambio, a los usuarios todo les parece bien, y de repente un día alguien (generalmente el cliente) empieza a hacer pruebas y hay una estampida de incidencias que salen como setas. Por todas partes. Hasta el punto de que empiezan a tambalearse los cimientos, se comprueba con horror que el sistema está cogido con alfileres y no funciona nada.
Pues en mi entorno local funcionaba (Imagen de Drakegoodman)
Cada vez que un desarrollador dice frases como «pues cuando lo probé iba bien» o «en mi local funciona«, Dios mata un gatito. Si dice cosas como «es por un micro-corte de red que hace que se pierda la conexión con la base de datos«, Dios extingue una especie tropical (además de los habituales gatitos).
Si hacemos una encuesta entre 10 personas cualquiera que se ganen la vida desarrollando software, llegaremos a la conclusión de que lo más apropiado es que el aseguramiento de calidad de un sistema lo haga alguien diferente del que lo programó, por varios motivos, entre los que destacan:
Y aunque estoy a favor de que haya departamentos de QA que de manera independiente al desarrollo validen que esté libre de errores (o en su caso los detecten), lo ideal sería que los entregables que reciben estén como los chorros del oro; que se pudiera comer sopitas en ellos.
¿Y por qué no es así? Pues básicamente porque los cuatro motivos de antes se resumen en que el programador es auto-complaciente. Enseguida se convence a sí mismo de que todo está bien hecho, de que ha hecho lo que tenía que hacer, y si algo falla, es por culpa de otro que no hizo su trabajo bien, o no le pasó la información que necesitaba cuando la necesitaba, o que no le explicó detalladamente algo, o que no abrió un puerto en el firewall, o que le cambió una especificación dos días antes de terminarla… He llegado a oir que el error era culpa de la persona que hizo las pruebas, que no prueba bien el sistema y falla. #amazing
A lo que yo digo, vale, ¿y qué? Has hecho un desarrollo que tiene más agujeros que Bob Esponja así que da igual que le hayas echado cientos de hora de tu vida, la mala noticia es que no han sido suficientes porque todavía no has terminado: ahora lo tienes que arreglar.
¿A qué te refieres con eso de Plan de Pruebas, Bob? (Imagen de gspidermac)
La auto-complacencia es uno de los peores defectos que puede tener un profesional, pero se acentúa en el caso del programador. Hay dos situaciones en la que el egoísmo debe ser la clave para sobreponerse ante la auto-complacencia, sobre todo por los devastadores efectos que tiene sobre uno mismo.
Todos los que hemos programado conocemos el problema de la mochila; hay que hacer un algoritmo que permite tomar objetos de un determinado volumen y valor para llenPUES NO. Ese no es el problema de la mochila.
Cuando uno entra a una empresa y empieza a programar, va pasando por proyectos. Algunos serán más largos, otros más cortos; unos serán un reto, otros no tanto, y todos en general formarán parte de su trayectoria profesional. De cualquiera de ellos podrá recibir un día un correo electrónico (o una llamada, según la gravedad) indicándole que tiene que dejar lo que está haciendo porque tiene que resolver una incidencia en uno de los proyectos por los que ha pasado.
Todavía son becarios, y ya tienen sus mochilitas (Imagen de ewar woowar)
El problema de la mochila es una maldición intrínseca de las personas que se dedican al software: cuanto más avanzan en una empresa, mayor es el peso que llevan en su mochila, más posibles incidencias pueden surgir; y por tanto estadísticamente más veces va a tener que dejar de hacer algo, porque la única persona que puede solucionar un problema con garantías suele ser quién lo resolvió la primera vez.
Primera Ley Natural del Programador Egoísta. Las cosas no terminan hasta que terminan. Si quieres salir cum laude de un proyecto encárgate de que todo lo que desarrolles funcione; y cuando falle, arréglalo lo mejor posible para que puedas seguir adelante hacia tus objetivos.
La conclusión es que cuanto más riguroso seas contigo mismo y con tu desarrollo; es decir, cuanto menos auto-complaciente seas, menos peso llevarás en tu mochila.
La segunda derivada de la auto-complacencia en el desarrollo es el temido Síndrome del Proyecto Sísifo. Como todos sabemos, Sísifo era un rey que quería vivir eternamente, engañó a los dioses mientras pudo hasta que le trincaron, momento en el que le condenaron a subir una piedra hasta lo alto de un monte. Lo que pasa es que al llegar a la cima, volvía a caer hasta la base; y así por toda la Eternidad.
Ánimo, otro empujoncito y vaciamos el Jira (Imagen de ChuckSchultz)
En tecnología, llamamos Proyecto Sísifo a ese proyecto en el que salen errores como cucarachas, hasta debajo de las piedras, de forma que se establece un círculo vicioso que es difícil romper: no se sale a producción porque hay errores; al no cumplir los objetivos el cliente dice que ya que estás le haces unos cambios; por la sensación de falta de rigor en el desarrollo e inclumplimiento se termina por perder la capacidad negociadora; con lo que hay que asumir los cambios; por hacerlos deprisa y corriendo para no palmar pasta surgen nuevos errores; y así sucesivamente. Por toda la Eternidad.
Segunda Ley Natural del Programador Egoísta. Si detectas que esto se va a convertir en un Proyecto Sísifo recuerda la Primera Ley Natural del Programador Egoísta.
Que yo sepa, sólo hay 3 maneras de salir del Proyecto Sísifo:
La conclusión es que cuanto más riguroso seas contigo mismo y con tu desarrollo; es decir, cuanto menos auto-complaciente seas, más probabilidades de que el resultado de tu trabajo sea un éxito para tu cliente, para tu empresa, y por tanto, para ti mismo.
Se egoísta: piensa en tí mismo. Ojalá cada vez hubiera más gente convencida de que la auto-complacencia es uno de los mayores enemigos de la realización personal.
Tercera Ley Natural del Programador Egoísta: Si no te das una patada en el culo de vez en cuando, alguien lo hará por ti. Y te va a doler más.
Otro día escribiré sobre otra situación en la que las personas sacrifican aquello que les acerca a su objetivos. Mientras tanto, puedes aprovechar la sección de comentarios para decirme si eres o no un profesional auto-complaciente, si llevas mucho peso en tu mochila o si estás a punto de que la piedra llegue a la cima de la montaña.
La última vez que lo miré, había 18.564 Apps en el canal Medical del App Store, lo que representaba el 2,18% de las más de 850.000 Apps que están disponibles para descargas sólo en el marketplace de Apple. Cada mes, Apple recibe entre 20.000 y 30.000 nuevas Apps para su valoración, casi 1.000 cada día (recordadme que os hable en otro post sobre La Lista Negra de Apple), osea que haciendo la proporción, todos los meses hay unas 500 nuevas Apps de eso que se ha dado en llamar #mHealth En Google Play la cosa va más lenta; aunque el número de Apps en global está equiparado, en el canal Medical hay 7.669 Apps.
Hace ya algunos años, en 2011, un estudio de Juniper Research estimaba que para el 2016 habría 142 millones de descargas de Apps médicas, y a mí en realidad me parece que se han quedado más bien cortos; en Abril de 2013 comScore decía que en US hay 133,7 millones de smartphone, y en los principales países de Europa (entre los que sorprendentemente se considera a España, qué cosas) hay otros 132 millones. Osea, 270 millones de personas con un smarthphone sólo en US y Europa. Me juego bueyes contra pajaritos que en 2016 la cifra de descargas de Apps médicas es absurdamente ridícula.
Bueyes vs Pajaritos, Fight! (Imagen de mikecogh)
Pero no nos liemos. #mHealt. Apps Médicas, subiendo a un ritmo de 500 cada mes a nuestros stores favoritos.
Una preguntilla: ¿alguien se dedica a comprobar el contenido de esas Apps?
¿Estás de coña broma? En Internet nadie comprueba nada, ese es precisamente el valor de Internet, la capacidad de difundir lo que sea a cientos de millones de personas sólo porque te encuentra Google. Y si no lo encuentras en Google no pasa nada, pregunta. En el NewEnglad Center for Investigative Reporting hicieron un estudio a finales de 2012; analizaron 1.500 Apps que había que pagar por descargar y constataron datos tan escalofriantes como que:
En este estudio se citan uno de los casos más terroríficos de lo atrevida que es la ignorancia: AcneApp costaba 1,99$ en iTunes y afirmaba que la luz azulada que generaba, eliminaba las bacterias causantes del Acné si se aplicaba sobre la piel al menos dos minutos al día. No se a vosotros, pero a mí me parece fucking brilliant! La denuncia contra la FDA indicaba que AcneApp tenía sus buenas 11.600 descargas (más de 23.000$, de los que Apple se llevó la tercera parte of course)
Ya te vale, Robin
En un escenario como ese hay dos caminos: el del libre mercado (dejar que sea el propio usuario el que decida lo que se instala en el teléfono y lo que no); o el de la regulación. En esa línea, a finales de 2012 se anunció que la FDA estadounidense lanzaba un proceso de regulación del mercado de las Apps médicas, sin embargo con el tiempo la cosa se ha quedado bastante más light de lo que se preveía. En general, parece que el tema va de que van a estar sujetas a revisión por parte de la FDA aquellas Apps que hagan el mismo trabajo que un dispositivo médico sujeto a revisión por parte de la FDA, o que sean un accesorio del mismo. Los chicos de AcneApp están de suerte, lo pueden volver a intentar.
Por tanto, en ese escenario volvemos al camino del libre mercado; dejar que la cosa se regule por sí misma. Aquellas personas que somos honestas y honradas y no tenemos intención de estafar a nadie necesitamos entonces abrir los ojos garantizar la solvencia del equipo médico que hay detrás de un App; dejar que los usuarios antes de descargarla sepan que los contenidos o la práctica que se genera en esa App no está respaldada por la frikipedia Wikipedia, sino que hay un equipo de profesionales adscritos a un servicio de salud de atención primaria o especialista (con nombre, apellidos, un cv a sus espaldas, y a ser posible un número de colegiado), y qué es exactamente lo que podemos esperar del App.
Quiero desarrollar la línea de Apps sanitarias del Dr. Doom (Foto de Guy Schmidt)
¿Y en España? ¿Qué pasa en España? Menos de lo que debería, como de costumbre. Excepto que la Junta de Andalucía, a través de la Consejería de Salud y Bienestar Social, ha sido pionera en la edición de un catálogo de Prácticas Recomendables, y en la creación de un Distintivo App Saludable que pretende reconocer aquellas Apps que pueden usarse de forma fiable. Las recomendaciones pues en general son las mismas que se podría hacer a cualquier otra App, sea de salud o no, que quiera no sólo ser seria sino parecerlo; pero qué queréis que os diga, ya es un paso importante.
Sin entrar en los detalles, me parece que la JA ha dado un paso que nunca me hubiera imaginado que daría una Administración Pública y menos en materia de tecnología: ha tomado la iniciativa #amazing. No se si los Consejos de Sabios de Europa van a estar moviendo papeles al respecto durante los próximos meses/años, ni si los burócratas de nuestro país van a hacer lo propio cuando los primeros terminen (osea, dentro de meses/años + otros cuantos meses/años) Mientras tanto, ya hay una autoridad «certificadora» que puede servir para que los usuarios puedan distinguir las Apps que tienen su distintivo de las que no lo tienen.
Yo iría mucho más allá; soy un ferviente defensor del concepto de Observatorio de mHealth. Recordadme que en otro post os cuente exactamente en qué consistiría, los beneficios que aportaría a todos los participantes (desde los pacientes a las Administraciones Públicas y todo lo que queda por medio), incluso algunos prototipos aspiracionales; y todo ello por menos de lo que nos cuestan dos o tres de esos asesores puestos a dedo.
En fin. De momento por ahora es suficiente. Espero haber dejado claro por qué creo que es importante contar con un médico a bordo de cualquier proyecto de #appSalud. Este es un tema que me interesa, así que le dedicaré varios post al asunto.
RANDOMIZE USR 0 