Libro: El despertar de la PYME

pyme

Título: El despertar de la PYME.
Autor: Carlos Delgado Zarco.
Editorial: Carlos Delgado Zarco.

Explicar porqué cogí este libro es complejo, así que simplemente diré que me interesan las empresas, los procesos y los productos. Y siento un gran respeto por las PYMES y los autónomos. Y este libro trata sobre ellos aunque sea para vender formación de Level UP. Vender no es nada malo de hecho es algo bueno para cualquier PYME, pero pienso que hay que ver el libro como una parte de un proceso de transformación más largo y que requiere de tiempo y dinero.

Las 27 historias (más 1 la del autor) que Carlos Delgado incluye están orientadas a inspirar el crecimiento de las personas en el ámbito profesional. Creo que son buenas y cumplen su objetivo, aunque soy de los que piensan que solo se puede convencer a quien ya está convencido. De todos modos, si te sientes estancado en tu vida profesional, tienes una empresa o quieres conocer historias personales sobre ellas, este libro debería resultarte interesante. Además es extremadamente fácil de leer.

Incluyo aquí mi resumen y notas de cada capítulo para poder recordarlos en el futuro, pero el verdadero valor del libro es el de las historias que cuenta. Son inspiradoras y sirven de ejemplo para demostrar que se puede hacer lo que no creemos posible. Ah y cada historia incluye datos de facturación de la empresa y empleados, lo que ayuda a ver las cosas con perspectiva.

Ahí van las notas:

  1. No esperes actos de fe porque el cliente no es creyente. José Luis Guzman. ReforHabit. Tuvo que hacer algunos cambios para que la gente confíase en sus propuestas. Añadir los rostros de la gente de la empresa, hacer la propuesta atractiva, incluir una “bio” de la empresa…
  2. El tiempo ni se crea ni se destruye, solo se aprovecha o se desperdicia. Sarah-Jane Anthony. Smartenglish Creative Language School. Tener muy claros tus objetivos para poder dedicar todo el tiempo a ellas en lugar de a cosas menos importantes. 4 horas diarias pensando en el negocio. Mantener la cabeza clara con un equilibrio entre la vida personal y la laboral.
  3. O consigues una venta o te venden un motivo por el que no compran. Laureano Pérez-Andujar. Enerluz. Centrar la venta en el comprador, no en el producto. Menos datos técnicos y más estética, garantías y sencillez. Emplear los “fracasos” para obtener feedback y mejorar la siguiente oferta.
  4. Rompe las reglas del mercado antes de que el mercado te rompa a ti. Inma Sánchez. La Pastora. Todos los productos pueden evolucionar de formas muy creativas, como el pimentón de La Pastora hizo (caviar de pimentón, café de pimentón…). Lo extraordinario llama la atención. Cambia lo que ofreces, hazlo de forma creativa. Como mínimo llamarás la atención, aunque vendas más de lo mismo.
  5. Estás diseñado para acumular basura mental. Tira de la cadena. Ángel Díez. SoundAndL. Un grave accidente nos muestra que lo creemos y pensamos nos limita y que la práctica de cualquier cosa nos hace mejores en ello.
  6. Se te conceden 3 deseos: que tu talento genere los ingresos para vivir la vida que deseas. Antonio Hernández. Libera tiempo para hacer lo que te apasiona y vende experiencias, no horas o personas. Y haz un plan de negocio por dios.
  7. Negocia por sistema, por mucho que lo temas. Javier Santías. Farmacia Santías. Todo es negociable. Encuentra a la persona que decide y trata de obtener un buen trato para ambos. Y controla tanto lo que entra en caja como lo que sale (ventas vs gastos).
  8. La primera venta es como el primer beso: si triunfas, vendrán muchos más. Gustavo Amorós. Librería Puzzle / Summum Consulting. “El negocio ha de tener dos estrategias diferenciadas […] Por un lado, la creación de visibilidad y captación de clientes. Por otro, la fidelización y el aumento de la frecuencia de consumo.” Y hay que mover el culo en ambas.
  9. Que un lingote de oro no te impida ver la mina de diamantes. Jorge Juan Ortiz. Beltá Frajumar. Identifica a tu cliente ideal, entiende sus deseos y necesidades y obtén margen de él. Y después trata de ver cómo acceder a más y mejores clientes y mercados. Normalmente tendrás que evolucionar tú y tu negocio para hacerlo posible. No te límites a hablar con el cliente. Conecta con el. Entiéndele.
  10. No vivas lo que te suceda. Haz suceder lo que quieras vivir. Ramón Sánchez Paco. One Telecom. Sal a vender y hazlo de forma metódica, con un plan a largo plazo. Usa los medios a tu alcance, como Internet.
  11. La gente no compra productos o servicios, sino la emoción que les provoca. Antonio García. Santa Cruz Arquitectos. Vende emociones. El producto es una décima parte de importante que las emocione positivas que produzca.
  12. Tus ingresos no dependen ni de lo que dices ni de lo que sabes. Dependen de lo que haces. Andrés García. Relaciones Profesionales Estratégicas SL. Menos hablar y más actuar. Enfrentarse al miedo, definir objetivos y dividirlos en tareas.
  13. Reacción en cadena: antes de la venta física, se produce la química. Maria Ángeles Carnicero. Limpiezas Poniente. Sorprende o asusta para captar la atención. Genera deseo en el cliente, conecta con él de forma positiva, de persona a persona. No se trata de las características del producto sino de los resultados positivos que generará.
  14. Haz de tu negocio una máquina de generar dinero… ¡sin que tú estés en él! Raúl Sanchís. Turcafi2006 SLU y TODO Raúl Sanchís. Trabaja para tu negocio, no en él. Intenta ser prescindible, que funcione solo. Intervén solo cuando quieras que vaya mejor o si es imprescindible (debería ser en pocas ocasiones). Automatiza y delega, solo así puedes crecer (escalar), asegurar la calidad de tu producto o servicio y hacerte prescindible. Puede “automatizar” con procedimientos, videos… pero revisa las cosas de nuevo de vez en cuando para adaptar y mejorar.
  15. Convierte a tu equipo en la locomotora de tu cambio. Carlos Soler. Embasana. El trabajo lo hacen personas y las personas necesitan ciertas cosas como comunicación y reconocimiento. Delegar es clave si quieres crecer y para eso se necesita confianza. Algunas cosas concretas pueden ayudar, como: 1) reunión semanal de hora y media con todo el equipo para hablar de problemas, éxitos, resultados…; 2) cualquier persona del equipo debe poder hablar de lo que necesite (personal o profesional) cada día al menos durante una ventana de tiempo; 3) como líder pregunta a las personas como están, si están contentos, obtén feedback con frecuencia.
  16. Tu problema no es la competencia sino la falta de competitividad. Francisco Javier Martín. DecoElx. Comunicar es esencial para que te compren. Los posibles compradores necesitan conocerte para poder comprarte. Hay diferentes formas y canales y los resultados son modestos pero tienes que hacerlo si quieres vender.
  17. Las personas son como un iceberg: lo que ves es mucho menos de lo que no ves. Rocío Vargas. Vilcabamba Tours. Lastre emocional: en lugar de enfrentarnos a los traumas emocionales, los escondemos. Y nuestra mente retuerce la realidad para evitar conectar con ese dolor. La rabia y el rencor nunca van a ayudarte a salir adelante y mejorar. Rodéate de gente buena, que te aporte algo positivo emocionalmente y acepta a las demás por tu propia salud mental. De una forma u otra cada persona trata de hacer lo mejor siempre, pero los contextos y las experiencias de cada persona son diferentes por lo que no los entendemos.
  18. Sorprende, impacta, molesta… y luego pregunta. Luis Iglesias. Look & Find y otras. Para innovar se necesita mucho conocimiento. No se puede gustar a todo el mundo pero es mejor recibir críticas que ser invisible; y es mejor hacer cosas y equivocarse que quedarse parado.
  19. El éxito no está en la idea, sino en la ejecución de la idea. Rocío Márquez. Casaturis. La persona detrás de un negocio es la que hace a diferencia. Por eso Casatauris, a pesar de ser un Airbnb, funciona. La ejecución de Rocío es diferente, innovadora frente a la startup y por eso funciona.
  20. Hazte íntimo amigo de los números. Es cuestión de confianza. Ana Bardají. Siete Semillas. Mide todo, usa los números para averiguar cómo va tu negocio y como tienes que gestionarlo. Es lo único que te permitirá mantener el control.
  21. El día que entiendas que lo malo, lo bueno y lo regular es 100% tu responsabilidad, tu vida cambiará. Alejandra Payá. Yeclaweb. No achaques a causas externas tus problemas, la responsabilidad de cambiar tu propio entorno es completamente tuya. Auto-engañarse es fácil y cómodo pero te mantendrá en un hoyo.
  22. La llave del crecimiento ilimitado: capta nuevos clientes a mayor ritmo del que los pierdes. Marcos Pareja. Runner Soul. Tienes que captar clientes porque siempre perderás algunos largo plazo. Y para ello tienes que ir a donde esté y conocerle a lo largo del tiempo. Así además podrás adaptarte a su demanda.
  23. Objetivo liquidez: tu negocio no existe para vender ni para facturar, existe para ganar dinero. Pablo Soler. Maza Grupo. En cualquier negocio necesitas liquidez. Para ello: 1) desarrolla un buen equipo, 2) automatiza procesos para ahorrar tiempo y dinero, 3) usa indicadores para gestionar y 3) maximiza la liquidez para poder invertir (tener libertad y crecer).
  24. Los placeres externos no llenaran nunca el vacío interior. Mayte Romero. Mayte. Como interpretamos y reaccionamos a los elementos (de personas o situaciones) depende de nosotros. Como lo tomemos y gestionemos es responsabilidad nuestra, al igual que de con quien y cómo pasamos el tiempo. Ser nosotros mismos y no otra persona, una máscara, es la única forma de ser feliz.
  25. Lleva a tu cliente hasta el orgasmo experiencial. Francisco Bernal. CaféLab. El producto es quizá lo menos importante de un negocio. El cliente consume experiencias y puedes conseguir generar una excepcional a base de pequeñas y constantes buenas experiencias a lo largo del proceso de venta, consumo y hasta pago. Eso sí, tiene que ser algo rentable y requiere tiempo más que dinero el conseguir estas mejoras.
  26. No vendas caviar a quien se alimenta de embutido. Alberto Oliver. Karamel Audiovisuales. Un negocio es un negocio, independientemente de las capacidades técnicas , idea, suerte o dinero que inviertas, necesitas entender cómo funciona un negocio para que este sobreviva y prospere. Un buen técnico y empleado metido a empresario necesita entender eso. Elige a tus clientes con cuidado y desecha a los que te generan pérdidas para poder invertir tiempo y energía en los que generan beneficios. Para ello debes conocer a tu cliente ideal y para eso necesitas datos personales o de empresa, dependiendo de quién sea tu cliente.
  27. Sé fiel a tu corazón. Él ya conoce el camino. Ana Cascales. Dear.Coach. Hacer algo que no te gusta y con lo que no estás de acuerdo no es forma de vivir. Busca lo que realmente te gusta y trata de fijarte objetivos para vivir alineado con tus necesidades y creencias.
  28. Tus resultados pasados y presentes no garantizan tus resultados futuros. Pon siempre el 100%. Carlos delgado. Level UP. No te duermas en los laureles. Siguen trabajando con cabeza cada día. Si no mejoras regularmente es que te has estancado.
Anuncios

La horda (equipos)

Hoy pensaba en un patrón de comportamiento de algunos equipos que he observado una y otra vez a lo largo de los años. Lo llamo “La Horda” y es algo que experimentado tanto como observador, como miembro activo u ordo.

Qué es y cómo funciona La Horda

La horda en equipos de desarrollo suele producirse cuando sucede algo que se percibe como importante, afecta a todos y además nadie sabe qué está pasando o qué implica realmente. El motivo puede ser variado: un error raro en un entorno de producción, un merge que salió mal y se ha extendido al resto de ramas, o una decisión sobre el código común. En esos momentos, la confusión y el caos se apoderan del equipo y los individuos pierden su identidad para convertirse en una masa, un grupo con mucha actividad y pocos resultados que realiza acciones sin coordinación y de forma más automática y emocional, que meditada.

En este “modo” de funcionamiento, los miembros del equipo no tratan de coordinarse o comunicarse de forma efectiva, sino de imponer su visión al resto, ya sea hablando sin escuchar o tratando de hacerse con el control de la horda (sin éxito dado el estado alterado general). En muchos casos algunos miembros de la horda actúan sin pensar provocando aún más caos. En otros la horda se divide en facciones que solo se comunican, o bien para defender intereses o bien por afinidades personales.

Al final, algo provoca que el tema se apague: el error de código desaparece, la gente se cansa o llega la hora de irse a casa. Entonces la horda se disuelve y vuelve a sus quehaceres. Lo interesante de este punto es que nadie se preocupa de ir más allá: el peligro ha pasado y no se siente la necesidad de dedicar más tiempo al tema. De este modo el origen del problema queda sin resolver, por lo que volveremos a ver una nueva horda en semanas o meses.

No creo que todo esto sea simple desorganización. Es más, tratar de organizar no ayuda, solo empeora las cosas o cabrea a los ordos.

Territorio Horda

Parece más fácil avistar una horda en equipos de desarrollo juniors que cuando hay seniors. Me refiero a veteranos de verdad, no gente con 1 año de experiencia repetido 20 veces. Supongo que esto se debe a que los veteranos están más curtidos y entienden que ciertas situaciones no son tan importantes o urgentes como puede parecer en un principio. También debido a que la experiencia adquirida les da más confianza en resolver el problema más pronto que tarde.

También parece más fácil que se forme la horda en entornos de desarrollo, que en entornos de sistemas. Mi hipótesis es que los equipos de desarrollo son más grandes que los de IT y con más especialistas (front-end, back-end, bases de datos…), dos características que generan problemas para mantener una visión de conjunto del trabajo (el conocimiento está muy fragmentado), aumentando el caos.

Además, tradicionalmente Sistemas no crea o genera cosas, sino que las administra, por lo que tiene más documentación y procesos que ayudan a mantener las cosas bajo control. Esto unido a que tienden a correr menos riesgos, evita que las cosas se pongan feas.

Defenderse de la horda

Creo que el problema de fondo que facilita la aparición de la horda es la falta de ganas de comunicación en el grupo. Es la escasez de tiempo lo que a menudo propicia esa falta, pero hay muchos otros factores que se suman día a día, a lo largo del tiempo, lo que genera hordas de forma cíclica.

Es normal que en un grupo que haya cierta brecha entre las experiencia y conocimientos de las personas y esto provoca que la comunicación requiera esfuerzo, como en el caso de padres e hijos. También es normal que existan diferencias de valores comunes y diversidad de caracteres, lo cual es sano y deseable. Sin embargo, cuando hay falta de interés en la comunicación (de serie o por razones externas), o si las personas del grupo desarrollan celos o rencillas (por sueldos, roles, rumores…), entonces la información tiende a ser, ocultada, distorsionada y se prejuzga con facilidad. Todo esto influye en que la comunicación se resienta, desembocando en hordas más o menos regulares.

La comunicación es algo difícil, requiere esfuerzo constante de todos y, aunque algunas personas puedan facilitarla en ocasiones, suele decirse con acierto que “no hay peor sordo que el que no quiere oír”: cuando alguien no quiere comunicarse, no hay forma de comunicarse y esto es un problema para el grupo muy difícil de resolver.

En mi opinión cualquier estrategia para evitar la formación de hordas requiere de tiempo y esfuerzo constante, y no siempre funcionará o será viable. Pero merece la pena intentarlo siguiendo estos pasos:

  1. Elige la capacidad de comunicación sobre la excelencia técnica en los miembros del equipo. Leer y escribir suelen ser buenos indicadores (no garantía) de que alguien disposición e interés en ello. Otros elementos de comunicación, como la escucha activa, son más complicados de detectar, especialmente en entrevistas. Y por supuesto entrena las capacidades de comunicación, no son algo que se aprende y ya está, hay que practicar, analizar, estudiar y mejorar constantemente.
  2. La paciencia y la experiencia variada ayuda a no caer en el pánico, facilitan la comunicación y el entender situaciones nuevas. Por eso ambas características son interesantes para cualquier grupo. Cuanta más y mejor distribuida, mejor.
  3. Reserva tiempo para comunicar a menudo. Si el equipo está sobrecargado esto se va a resentir. Pero eso no significa que una sola persona o un pequeño grupo sean los únicos responsables de buscar tiempo o iniciar la comunicación. Todos deben hacerlo.
  4. Emplea todos los canales de comunicación disponibles. Hablar es el más básico de los disponibles actualmente y probablemente el peor, porque que requiere poco esfuerzo (tiende a hacerse mucho y mal), solo funciona bien de 1 a 1, necesita que las personas sincronicen agendas, etc. Hace 6.000 años que tenemos escritura y desde hace bastantes décadas podemos grabar y transmitir audio y vídeo, amén de nuevos canales de comunicación escrita (chats, wikis…). Emplear exclusivamente el “sentarse a hablar” es negligencia.

Para acabar, dejo al lector una cita de Wikipedia que encontré leyendo sobre hordas de verdad. Me parece interesante para seguir reflexionando sobre el tema y me invita a pensar que quizá haya espacio para un antropólogo en los equipos de desarrollo. Al menos en los de las grandes ligas como Google, Amazon o Microsoft.

Jared Diamond define algunas características propias a las organizaciones sociales de los seres humanos en hordas:

  • Son las sociedades más pequeñas, entre 5 y 80 personas, estrechamente emparentadas;
  • Carecen de muchas instituciones como leyes, policía y tratados para resolver conflictos;
  • No tienen base de residencia;
  • Sociedad «igualitaria». Liderazgo informal;
  • Todos los humanos presumiblemente vivieron en hordas hasta la adopción de la agricultura;

Developer Timeline 1996-2016

pope-john-paul-ii-and-fidel-castro-watching-time

Hace unos meses intenté convencer a algunos desarrolladores de que necesitaban aprender Git. Algo que desde mi perspectiva parecía obvio y urgente se tornó, pese a mis esfuerzos por argumentarlo, en imposible. Desde entonces he estado dándole vueltas al tema de la obsolescencia de las herramientas, técnicas y servicios que los desarrolladores usamos a diario y a como alternamos entre lo malo conocido y el hype del momento.

Esto me llevó a pensar en cómo “de-mostrar” a determinados perfiles técnicos de la necesidad de actualizarse, lo cual me condujo a confeccionar una “línea de tiempo” o mapa de tecnologías y herramientas de desarrollo .NET para poder observar el avance en determinados ámbitos como el control de versiones de código.

Gracias al intercambio de ideas de los Meetups en SwCraftersCLM GDG Toledo y los ánimos que me han dado desde esta comunidad para publicar el “timeline de desarrollo”, he terminado una versión 1.0 1.2 que he colgado en Google Sheets para uso y adaptación de otros equipos de desarrollo, incluso de otros stacks tecnológicos. O aprovechando que acabamos el año, para pararse a pensar qué aprender en 2017 2018.

El Excel es el siguiente: Developer Timeline 1996-2017

¿Para qué sirve?

La idea es poder usar la hoja como herramienta de 4 formas diferentes para varios objetivos:

  1. Para poder revisar en qué punto estamos de actualización técnica y ayudarnos a decidir si aprender o no una tecnología en concreto.
  2. En grupos de desarrollo. Para poder argumentar con datos objetivos frente a nuestros compañeros sobre la necesidad, o no, de reciclarnos tecnológicamente. Como mínimo debería facilitar el diálogo sin caer en el flame.
  3. En charlas. Para poder hacer una introducción simpática para todos los públicos sobre determinadas tecnologías como Core o SharePoint Framework añadiendo un contexto tecnológico más amplio que facilite el entendimiento de los problemas que resuelve.
  4. En organizaciones. Para poder establecer el nivel de actualización de una organización (la nuestra u otras) de una forma más o menos objetiva. En última instancia podría ayudarnos a decidir si embarcar en una empresa o desembarcar de la actual.

¿Qué contiene?

La hoja contiene varias categorías (eje vertical) y eventos relevantes para cada una de las categorías, repartidos por año (eje horizontal).

Me pareció adecuado empezar en 1996 por tener un intervalo amplio y “redondo”: 1996-2016. El año 1996 sirve además para poder establecer una línea base de “desarrollo viejuno”.

La información que contiene está orientada por mi experiencia y entornos de trabajo a lo largo de los años por lo que hay bastante de Microsoft, pero he tratado de mantenerlo flexible para poder adaptarlo a otros entornos aglutinando la mayoría de elementos específicos de Microsoft en su propia categoría.

Sobre las categorías, los datos y la selección

Hay muchos elementos que podría haber metido pero que finalmente he eliminado por claridad (versiones, irrelevancia…) y simplicidad.

Muchas fechas son aproximadas y en algunos casos discutibles. En general he tratado de tomar las más importantes como por ejemplo productos release en lugar de beta.

Hay bastante tecnología Microsoft debido a mi propio background y el público al que lo he enfocado, pero he tratado de mantenerlo flexible para otros stacks.

Este documento no pretende ser canónico, sino una herramienta ilustrativa de la evolución y periodos que vivimos los desarrolladores de software. Está pensado para ser modificado de forma sencilla por lo que he desistido (de momento) de hacer un gráfico SVG interactivo con D3 y JSON.

Las categorías en que he agrupado los eventos son las siguientes:

  1. Papas: Los papas de la Iglesia Católica Apostólica y Romana que hemos tenido desde el 96. Me parece interesante mostrar que hasta las organizaciones más antiguas y tradicionales experimentan más cambios que algunas personas o empresas.
  2. Efemérides: Evento de relevancia nacional o mundial. Permite replantearse la cantidad de tiempo que ha pasado entre tecnologías y los grandes cambios que han sucedido en la sociedad.
  3. Películas: Estrenos de cada año. Me parece un detalle simpático para tratar de poner en contexto el tiempo que ha pasado, en particular entre fans de Marvel como yo, y la cantidad de proyectos que pueden llevarse a cabo en 5 o 10 años.
  4. JavaScript: Aun hay gente que no quiere saber nada de JavaScript o quiere quedarse en la versión del ’99. Visibilizar la cantidad de hitos que ha tenido debería facilitar el NO poder ignorarlo.
  5. Autenticación y Autorización: Todavía tengo que explicar las diferencias entre autorizar y autenticar. En el panorama actual y dado que es necesario conocer estos temas para realizar cualquier aplicación moderna, me parece grave y por eso le he dado su propia categoría.
  6. Servicios web: Esta categoría trata de servicios web y trata de poner de manifiesto que la diferencia entre SOAP y REST en realidad son pequeñas y que deberíamos mirar más allá del hype al evaluarlas. También pone en el mapa los webhooks, que parece que son grandes desconocidos a pesar de su utilidad y antigüedad.
  7. Formatos de datos: Me pareció apropiado añadir esta categoría tras la de servicios web para señalar que son dos cosas independientes y que ya va siendo hora de aprender a usar JSON. O usar Markdown en lugar de HTML en según que contextos.
  8. Front End: Esta categoría podría ser una hoja aparte, pero he tratado de incluir estándares de facto y orientarme a desarrolladores back o full stack. He añadido asteriscos a temas de W3C para recordar que… “es complicado” asegurar en qué estado están.
  9. Gestión de código: Esta es la razón por la que comencé a confeccionar el Excel y por eso tiene un componente “fuerte” de productos Microsoft, pero dejando claro que el estándar a día de hoy es Git. De hecho, es importante mencionar que Microsoft lleva años migrado todo su código abierto a Github.
  10. Servicios de terceros: Incluyo una lista de servicios de terceros relevantes para perfiles técnicos. Estos deberían contrastar con la antigüedad de algunas de las herramientas de algunos técnicos. Si, por ejemplo, alguien usa Dropbox (2008) o Google Drive (2012), no podrá argumentar que Git es demasiado moderno (2005).
  11. Microsoft Stack: categoría específica para los que usan el stack de Microsoft, por lo que en adaptaciones a otras empresas debería adaptarse. El “baseline” es Outlook porque me pone nervioso ver que no se sabe usar a nivel básico (carpetas, convocatorias, respuestas automáticas…) y es una herramienta que todos usamos a diario para trabajar en empresas, en particular con el stack Microsoft.
  12. S.O.: Sistemas operativos desde el ’96. Con especial detalle en el ámbito Windows, claro. Porque todavía hay quien quiere volver a W7 por pura resistencia al cambio.
  13. Dispositivos Móviles: He tratado de sintetizar el panorama en dispositivos móviles. Al estar tan unidos hardware y software he mezclado ambos elementos. Evidentemente Windows Phone/Mobile se queda fuera.
  14. Lenguajes: Es interesante ver que los lenguajes de back-end son bastante estables, pero no inmutables.
  15. Entorno de ejecución: Parece que todo es alguna variedad de la máquina virtual de Java o el que tiene que funcionar sobre el CLR de .NET y no solo no es así, sino que el panorama parece que va a cambiar cada vez más. Estuve tentado de introducir Docker también, pero los contenedores son otra historia y aun me parece pronto para añadirlos, quizá el año que viene o quizá en otra categoría de DevOps.

Como nota curiosa no he notado nada interesante en 2003 pero si muchos eventos importantes en 2009: el embrión de Azure y Office 365 (BPOS), Android 2.0 (la primera versión buena), Windows 7 (el más querido), ECMAScript 5 (el JavaScript de la nueva web), Bitcoin (y la explosión del blockchain), GO (del que Javier nos dará una charla pronto) y Node JS (¿el nuevo Java/PHP?) del que vimos como se usaba en producción en las Lambdas del AWS de BrainSINS en el último Meetup.

En resumen

Como decía el personaje de Will McAvoy en The Newsroom: El primer paso para resolver un problema es reconocer que hay uno (minuto 5:00, pero el speech completo es impresionante).

Mi intención inicial era mostrar como Git es una herramienta indispensable para el desarrollador de .NET de hoy, comparándola con eventos relevantes del pasado reciente de forma objetiva y amigable.

Aunque parece que he conseguido construir esa herramienta, creo que he generado algo más potente, una especie de minicuadrante de Gartner del desarrollador .NET (y en general) que podría servir para animar a algunos técnicos a reciclarse, y que me ha ayudado a ampliar mi visión estratégica para 2017 así como a mejorar mi planteamiento como arquitecto de soluciones y líder técnico. O como mínimo me ha aclarado panorama bastante ahora que parece que todos andamos perdidos de stack en stack y de framework en framework especialmente en el mundo Microsoft.

Para terminar

Al revisar mis propios artículos me parece reconocer que en el universo Microsoft, 2016 es una repetición de 2012. Da para otro artículo, pero si estás más o menos al día creo que podrás ver las semejanzas entre el panorama actual (Azure, Office 365, Hololens, ARM, Open Source…) y el que describí en 2012 en: El desembarco de Normandía.

Y si te ha interesado este artículo, es muy probable que te interesen mis artículos: Breve historia del desarrollo de software de 2012 y mi predicción sobre el futuro de Blackberry, iPhone y Palm en 2007: La muerte de Blackberry.

Las dos palabras que todo profesional debería usar más

Hace unos días, Manuel de la Peña twiteó un texto que comentaba una vieja historia (más bien fábula) de monos, jaulas, preguntas y procedimientos.

Eso me trajo a la memoria pequeño artículo que leí en Hardvard Business Review sobre el arte de hacer preguntas. Un artículo que en su momento me invitó a pensar en la importancia no tanto de las técnicas de hacer preguntas, como de lo esencial que es conocer el “por qué” de las cosas (y para lo que se necesita hacer preguntas, claro).

También me recordó este otro artículo sobre qué hacen las personas que son buenas escuchando y que en mi opinión es una consecuencia de interés genuino en entender los “por qué“.

La falta de interés y esfuerzo en tratar de entender las cosas, sus objetivos y contextos (esto es, el “por qué“) es un tema que me da mucha rabia observar (incluso en mi) y del que hace tiempo que tenía pendiente quejarme un poco en público. En público, porque tiene relación directa con todos los procesos que se realizan en cualquier empresa; también con las buenas prácticas (best practices) que parece que muchas personas se emperran en recomendar o exigir sin entender que dependen del contexto. Y por supuesto porque tiene que ver con los que critican (y criticamos) decisiones de terceros a nivel personal, de negocio o político casi a diario.

Hay por supuesto profesiones en las que en general se necesita hacer preguntas básicas constantemente de forma directa o indirecta, como en medicina (¿le duele aquí?, ¿puede caminar?), donde cada prueba médica es una forma de pregunta y cada mirada o toque está orientado a obtener una respuesta (el ojo clínico). Supongo que haber tenido un padre médico ayuda a ver ciertas cosas de cierta manera.

No obstante, la mayoría, durante la mayor parte del tiempo observa, juzga y condena sin conocer el “por qué” de una decisión. Pocos se molestan en hacer preguntas la mayor parte del tiempo. Mucho menos una tan básica como “¿por qué?“. Y desde luego nunca seguida de otro “¿por qué?” como en el método Toyota-Lean-Kaizen-Six Sigma de los 5 por qué para la mejora de procesos.

Me temo que hemos cogido miedo a hacer preguntas básicas, las más importantes, por miedo a parecer ignorantes y menos valiosos en nuestro entorno personal y puesto de trabajo, e irónicamente eso nos hace más ignorantes y menos valiosos.

Pero no acaba ahí el problema: como nadie hace preguntas para entender un contexto todos acabamos dando por sentado que este no importa y/o que todos tenemos la misma idea en la cabeza, lo que provoca errores y dificultad en la comunicación. Un desastre.

En fin, que las dos palabras que creo que todos deberíamos usar más son evidentemente “¿por que?”. Aunque hay otro par de palabras que, si se usasen con sentimiento real, también deberíamos usar más y mejoraría mucho nuestras vidas: “por favor”. Porque es sorprendente lo bien que responden algunas personas a un poco de interés y educación y como redunda eso en un win-win de libro.

Así que tras quejarme un poco y habiendo dejado algunos enlaces (espero) interesantes, solo puedo cerrar este post invitando a todos a preguntar más y mejor. Con inocencia y abiertos a escuchar.

7 Indicadores no convencionales en las oficinas

WP_20160425_19_43_36_Pro

El otro día estuve hablando informalmente sobre ciertos detalles que pueden usarse como indicadores de la salud de un equipo de trabajo, sobre el estado de motivación o burnout de las personas de un equipo de trabajo, lo que me llevó a pensar en indicadores informales o no convencionales en entornos de trabajo y finalmente a escribir este post.

El fondo de la cuestión es que al igual que existe un lenguaje corporal que todos hablamos en mayor o menor medida, existen ciertas señales que se producen en grupos de trabajo, particularmente oficina. Estas señales pueden ser detectadas e interpretadas si las conocemos y estamos atentos.

Por supuesto, como en cualquier comunicación, se necesita un contexto para poder interpretarlos correctamente y siempre hay detalles adicionales que nos perdemos y confusiones. De ahí que los trate como indicadores, no como una regla ciega. No todo el mundo entiendo esto (la incertidumbre) así que es importante recalcar que un indicador de cualquier tipo no reemplaza a la realidad, solo ayuda a visualizarla parte desde otro ángulo, con más facilidad y fiabilidad cuanto mejor sea el indicador y cuantos más indicadores tengamos. Parafraseando al ejercito suizo: el mapa no es el territorio y en este caso las señales son solo una ayuda.

En mi caso he visto que los siguientes indicadores son bastante fiables y son los que suelo comprobar de vez en cuando, pero dependiendo del tipo de trabajo y de organización hay muchos otros o algunos pueden no ser válidos:

1. Barbas. La aparición de barbas en la oficina, refiriéndonos no a la barba larga y cuidada de un hipster, sino la descuidada de “paso de afeitarme” o “no tengo tiempo ni energía para esto”, es un indicador muy claro de la carga de trabajo en momentos puntuales o de moral baja en ciertas épocas. La gente está demasiado saturada y agotada como para siquiera decidir arreglarse. La solución no pasa por ordenar a la gente que se asee, sino por reducir las cargas de trabajo y tratar de animar a la gente de alguna manera.

2. Material de oficina. Aquí me refiero tanto a equipos de trabajo como a cosas más básicas como pizarras, rotuladores, bolígrafos o tóner. La ausencia o falta de calidad de los mismos indica despreocupación al nivel de la organización sobre detalles que marcan la diferencia en el largo plazo. Es un poco como la alimentación: una persona en forma o preocupada por su salud no suele comer poco y mal. Suele indicar una cultura del “vamos tirando y ya es mucho”.

3. Equipos informáticos. Aunque esto forma parte del material de oficina, merece además un trato específico, pues conozco ciertas personas que se fijan en los equipos informáticos de los comerciales y técnicos para evaluar a los proveedores. Un equipo malo o doméstico es visto con una mala señal dado que apunta a una predilección por lo barato sobre la calidad, algo que no se desea en un entorno profesional.
4. Rotación. Este es un clásico pero lo considero “no convencional” dado que cualquier persona puede verlo sin necesidad de un informe: cuando la mayoría de la gente lleva poco tiempo en la empresa (quizá menos de 2 años) se puede predecir que no se valora demasiado a la gente (precisamente la parte más crítica en cualquier empresa) o cosas peores como gente y organizaciones tóxicas de las que acaban generando cárteles y otros comportamientos poco éticos.

5. Frameworks, librerías y procesos. La existencia de uno o varios frameworks o librerías de código reutilizable o de procesos empresariales definidos (y usados) puede significar varias cosas, pero claramente indica que la empresa se dedica a hacer lo mismo una y otra vez, lo que puede ser bueno o malo dependiendo de si se mueve en un área madura o en evolución y de su antigüedad. Es un caso de indicador que cambia de significado completamente dependiendo del contexto. La ausencia de, por ejemplo, un proceso para vacaciones puede ser bueno (confianza y sana responsabilidad individual) o malo (caos, falta de planificación y falta de eficiencia).

6. Trajes. La existencia de trajes puede venir obligada por el tipo de negocio de la empresa (abogacía, auditoría…), pero suele significar un énfasis en lo comercial, en vender algo o una búsqueda de uniformidad. Esto no tiene por qué ser algo malo, pero es bueno recordarlo cuando se avista una corbata y crucial si una oficina técnica, que no debería estar vendiendo nada, está llena de ellas.

7. Fight or fly. Cuando una persona decide irse, suele reducir la comunicación y el contacto con el resto de sus compañeros, más o menos de golpe. No siempre es así y a veces el cambio es sutil, pero cuando alguien deja de comer con el resto de compañeros o deja de “quejarse”; en general, cuando alguien deja de hacer algo que hacía normalmente, podemos encontrarnos ante un signo de rendición y huida, que puede desembocar muy fácilmente en un abandono, y por tanto en una cifra a sumar a la rotación. Es uno de esos indicadores que pueden predecir cambios en otros. Supongo que como seres sociales que somos, la no comunicación es una comunicación en sí misma.

Como nota final, el tema de los indicadores informales me ha recordado un post de David Bonilla sobre como dar los buenos días con una especie de berrido, para comprobar el estado de ánimo del equipo. Ese sí que es poco convencional.

Analogías y desarrollo de software III (fin)

Crónicas de Islandia I: GPS

Llegamos la última parte de esta serie sobre analogías e informática. En este post voy a exponer las metáforas y modelos mentales que suelo encontrar asociados a sistemas informáticos y su evolución. Esta es la parte más “avanzada” de la serie así que si no te interesa el mundillo como profesional, probablemente puedes ahorrarte el ladrillo.

Paso a producción como proceso explosivo

Este modelo mental trata las entradas a producción de un sistema como algo inmediato y de alto impacto. Eso significa que seguramente estamos ante un proyecto waterfall (en cascada) que incluye montones de elementos nuevos y poco o nada probados (procesos, sistemas, integraciones, herramientas…).

Entre los sinónimos encontramos “Big Bang“, lo cual resulta irónico al pensar en la astronómica cantidad de tiempo que se necesita dejar transcurrir entre un Big Bang y un Universo habitable. Y eso sin pensar en los ajustes.

Normalmente este proceso falla en proyectos grandes. A veces incluso antes de llegar a intentarse, dado que impacta en demasiadas áreas a la vez como para que todo el mundo esté de acuerdo en una fecha y funcionalidad. Por eso aunque este modelo se usa, acaba mutando a un proceso de paso a producción incremental o algo intermedio, pero en cualquier caso mucho más humilde en el impacto producido.

La ventaja de este modelo es que todo el mundo está encantado con la idea de no tener que hacer nada hasta un día concreto: nada de formación, evolucionar el producto, recabar feedback, pensar… Por eso es fácil que el cliente lo acepte (o exija) y el proveedor lo ofrezca. Y por eso es fácil que fracase: no es una solución, es una patada adelante a un conjunto de problemas que acabarán apareciendo igualmente.

Seguramente ahora estés pensando que has visto una buena entrada en producción de este tipo y que estoy exagerando. Puede que tengas razón, pero deberías pensar si ese proyecto que recuerdas no habría tenido mucho mejor resultado si se hubiese abordado como un desarrollo incremental, iterativo, con mejoras continuas de los procesos y usuarios involucrados en aprender y dar feedback. De eso va la agilidad, el Lean, los MVP… así que vuelve a pensar.

El entorno tecnológico como ecosistema

Hace unos años pensaba que este modelo mental estaba más extendido pero he podido comprobar que aunque se usa mucho por parte de técnicos, no parece tan habitual entre otros perfiles de la profesión.

La idea es que, al igual que una selva o una cueva son sistemas con ciertas características, límites, fauna y flora, los sistemas informáticos son entidades vivas de un entorno con ciertas características y límites que funcionan unidos. Lo más interesante de este sistema es que instintivamente se entiende que hay que mantener un equilibrio entre las partes para que el ecosistema no se derrumbe. Y que cualquier modificación del mismo requiere ciertos cuidados y no pueden realizarse a gran escala y de una sola vez si queremos conservar el ecosistema.

Podemos ver las diferentes piezas de hardware, software y servicios como elementos de ese ecosistema y podemos entender fácilmente la necesidad de vigilarlo y cuidarlo, interviniendo regularmente para mantenerlo sano.

El único “pero” que le veo a este modelo es que se le puede coger cariño al ecosistema o pensar que es un ente endeble que no debe cambiar. Y eso puede hacernos difícil ver cambios necesarios. Por ejemplo, aunque vivamos en un desierto y estemos perfectamente adaptados al mismo, quizá sería bueno evolucionar a algo diferente. Y aunque estemos muy cómodos en nuestro bosque, deberíamos empezar a cambiar algo para adaptarnos a la glaciación que viene.

Evolución y versiones de software

La Evolución es una idea que apenas tiene 300 años, y en mi opinión el público en general aún tiene (y seguirá teniendo) problemas para entenderla debido quizá a que los seres humanos tenemos capacidades muy limitadas para entender los efectos acumulativos, los periodos mayores a un puñado de años y las matemáticas.

Aun con esa falta de entendimiento la idea es seductora, potente, y se emplea para hablar de modelos de desarrollo incrementales, MVP (mínimo producto viable) y versiones de producto.

La idea es que una evolución del software, una nueva versión, un… evolutivo, es una versión diferente, mejor y más adaptada del software que tenemos en manos actualmente. En realidad la idea es fácil de transmitir y en general creo que funciona bien. Sin embargo la analogía no es correcta del todo y eso puede llevarla por un mal camino.

Se supone que la Evolución se produce poco a poco a lo largo de mucho tiempo, mientras que los desarrollos evolutivos son conjuntos de cambios normalmente bastante mayores en relación y que se introducen a saltos. Me recuerda mucho a la disputa sobre la que leía hace casi 2 décadas en los libros de Richard Dawkins acerca de si la evolución era “continua” apoyada por él mismo o si era “a saltos” apoyada por Stephen Jay Gould.

En resumen, aunque creo que la idea está bien, no parece que realmente llegue muy lejos por los problemas que tiene entender la Evolución, con lo que aunque se usa mucho esta analogía, me temo que su utilidad es muy limitada si no tenemos un interlocutor adecuado.

Selección sexual y testing A/B

Ahora que se ha puesto de moda el testing A/B, estoy empezando a ver el uso de la analogía con la selección sexual. Si entiendes como funciona esta técnica y qué es la selección sexual, verás la relación evidente y podrás anticipar que es una técnica interesante para evolucionar el software (ver analogía anterior: Evolución). En otro caso, me temo que no tengo espacio suficiente en este artículo para tratar sobre ambos conceptos por lo que recomiendo unas horas de navegación y estudio.

En resumen, la idea del A/B testing es que si entiendes cómo funciona la selección sexual (organismos compitiendo entre sí por reproducirse con una pareja y producir descendencia de características similares) puedes ver como conecta eso con la idea de poner 2 versiones diferentes de un mismo software con características similares y pequeñas diferencias para que compitan por un mismo grupo de usuarios. Al cabo de algún tiempo y muchos usuarios, tendremos una tendencia clara (en el mejor de los casos) que nos indicarán qué característica merece sobrevivir y evolucionar en nuestro software.

Esta analogía no suele ser necesaria para explicar los conceptos, pero si para explorar las limitaciones de la técnica. Lamentablemente requiere de conocimientos sobre Evolución, que como he comentado no son demasiado comunes, por lo que esta analogía y sus críticas solo la estoy viendo en entornos profesionales de discusión sobre la técnica, no en comunicaciones cliente – proveedor.

Como nota adicional es interesante ver que esta técnica se ha copiado de otro contexto, el de márquetin de productos si no he entendido mal, lo que resulta irónico: alguien entendió la similitud entre ambos mundos y decidió emplear la técnica, como Henry Ford en su día con la cadena de montaje…

Y hasta aquí llegamos con esta serie de artículos sobre analogías y software.

Analogías y desarrollo de software II

Crónicas de Islandia IV: Consejos a viajeros

En el post anterior comentaba algunas analogías comunes en informática. En este post voy a comentar algunas un poco más avanzadas sobre desarrollo de software pero también muy comunes.

Desarrollo de software como construcción de objetos físicos

Aunque insisto en que el desarrollo es un proceso de diseño y no de construcción, esta analogía es un clásico y te encuentras la idea en casi todos lados.

Se considera que construir una aplicación es una actividad similar a construir un edificio o un avión. Se necesitan arquitectos, montones de documentación y maquetas, ingentes cantidades de dinero y numerosas cuadrillas y material especializado. Además se considera que el diseño es barato y la construcción cara. Por último este modelo mental invita a pensar en soluciones que permanecerán más o menos invariables a lo largo de muchos, muchos años.

Lo más importante que hay que decir sobre este modelo es que está completamente equivocado. Si lo veo asomar en un proyecto, sé que vamos a tener problemas, que el producto será inferior a lo que podría ser y que va a costar mucho más de lo que debería. Pero al menos es un modelo que puedes usar para comunicarte con el cliente. Y si demuestras que sabes más de construcción (estilos, historia, materiales, anécdotas sobre grandes obras…) que el interlocutor y haces una intensa labor de comunicación y pedagogía puede que consigas sacar el proyecto adelante en unas condiciones decentes. Pero en cualquier caso es un modelo terrible.

Desarrollo de software como viaje

En este modelo mental, el desarrollo es como un viaje. Sabes de donde sales, marcas un destino y estableces un presupuesto, tiempo y recursos a emplear. Con esos parámetros estableces los parámetros del viaje: Bussines, low cost, escalas, duración, fechas, extras…

Lo bueno de este modelo es que se entiende que cambiar de ruta o destino puede ser costoso o barato en diferentes etapas del viaje. Que un medio de transporte (tecnología, recurso) puede ser necesario en algunos casos. Que habrá retrasos en algunas etapas y eventos inesperados (tormentas, retrasos acumulados, accidentes). Pero creo que lo más interesante es que ofrece la posibilidad de aprender durante el viaje y cambiar de rumbo o quedarse en una etapa concreta si el cliente lo considera útil.

Lamentablemente este modelo mental no es muy común y tiende a despreciarse al parecer menos “definido” (lo cual es una mera percepción, pero es difícil convencer a alguien sin experiencia de esto), pero puede dar mucho juego si entendemos que algunos clientes quieren un viaje al África salvaje (grandes riesgos, incógnitas, mucho que ganar, caro…) y otros meramente quieren un crucero con todo pagado por el Mediterráneo (barato, en masa…). Con esta analogía entendemos que diferentes proyectos deben gestionarse, venderse y realizarse de manera radicalmente diferente. Que no hay una bala de plata.

Desarrollo de software como guerra

En este modelo mental el cliente es el enemigo y cada proyecto es una campaña militar que solo puede acabar en victoria o muerte. Es habitual encontrar este modelo en muchas grandes empresas, tanto como cliente, como proveedor. Y en esos entornos hostiles (las grandes empresas tienden a convertirse en reinos de taifas, grupos de presión e interés, cada uno con sus rencillas) es fácil transmitir esta visión y creérsela.

Lo interesante de este modelo es que es divertido. Me explico: Poder lanzar una ofensiva bélica contra el frente enemigo y conquistar cada una de las ciudades importantes en tiempo record y sin bajas, es mucho más interesante que poder entregar el módulo de gestión de inventario de una factoría de tornillos en tiempo y coste. Cada paso a producción produce héroes y gloria en lugar de trabajadores quemados y resultados mediocres. Y el fin de proyecto significa la vuelta a casa con medallas y desfile, en lugar del papeleo de cierre de esa web de abogados que acabamos de terminar.

La verdad es que este modelo solo me parece útil para motivar a la gente a continuar trabajando, o como forma de tratar con un cliente/proveedor realmente malo. Por eso, si necesitas recurrir a él significa que, o bien estas en un contexto de trabajo pésimo, o bien te estas convirtiendo en un sociópata muy competitivo que busca ganar por encima del resultado a largo plazo del proyecto. En cualquier caso, el uso de este modelo es una señal bastante clara de que deberías buscar otro lugar de trabajo lo antes posible.

Continuará…