Así no se hacen las cosas por Ernesto Kiszkurno

El otro día leí por ahí a alguien que decía en el futuro imagino una profesión que sea "Diseñador de Tests para cualquier cosa"  y pensé ¿por qué no?  Hoy, en el marco de la práctica de testing de software, la habilidad principal del tester es la de saber diseñar pruebas . Encuentro un montón de ejemplos y situaciones que, en definitiva, mapean a eso: Plantear una estrategia de pruebas para un proyecto grande. Probar una aplicación sistemáticamente, definiendo casos de prueba, que garanticen cierto cubrimiento. Probar un cambio, minutos antes de pasarlo a producción, en forma intuitiva, utilizando técnicas de smoke testing. ... En forma más planificada o menos, siendo más formales o menos, trabajando en equipo o individualmente, siempre estamos diseñando pruebas. Doy un paso más. Creo que la habilidad de diseñar las pruebas es más importante que la de ejecutarlas. También hoy, en el campo de UX, la habilidad de diseñar pruebas para entender la experienc

A fines del año pasado grabé un video comentando algunos de los cambios que viene sufriendo el rol de gestor de proyecto en esta época de transformación digital. Se los dejo aquí . Seguimos pensando..

J.A.R.V.I.S. es el asistente basado en inteligencia artificial de Tony Stark.  Tiene una interfaz de voz y es capaz de interactuar con diversos dispositivos de la casa y de las armaduras de Tony. Es dueño de un conocimiento científico importante que le permite hacer investigación a la par de su dueño y, lo mejor, posee un sarcasmo muy divertido que lo hace un personaje más o, si prefieren, parte integral de la personalidad de Iron Man. Hecha la descripción del personaje cinematográfico, quiero destacar que a priori, ninguna de las tecnologías y capacidades mencionadas suena a ciencia ficción hoy (salvo por el sarcasmo tal vez). Diría que "estamos ahí de lograrlo". En un reciente artículo de Gartner titulado  Chatbots Will Appeal to Modern Workers  se muestra un diagrama interesante con el siguiente título "de 6 acciones a un pedido" donde se muestra cómo es posible simplificar y agilizar la actividad de los usuarios aprovechando la habilidad, ya disponible

Siempre me gustó la palabra modular.  La conocí en la facultad, cuando hablábamos de diseño y decíamos que una buena cualidad de un sistema era que fuera modular. En ese entonces David Parnas era la referencia obligada para el tema (algo así como el Mick Jagger del diseño de software) y hablábamos de cohesión, acoplamiento y otras cuestiones. Hoy, con beneplácito, la encuentro como una característica deseada de los modelos operativos del futuro según el World Economic Forum, que dice: "To meet market demands in the future, organizations will employ modular capabilities to support various business models. “Modular” is a characteristic that is defined as the ability to develop and deploy a business capability that can be utilized in a flexible, repeatable way across multiple business models with minimal re-design . This is a deliberate, “plug-and-play” approach that is distinctly different from previous eras in business that were focused on driving efficiencies thr

Hace tiempo escribí sobre la sobreplanificación de nuestro tiempo personal . Recordé esto cuando, días atrás, tuve una conversación con un colega que me contaba los múltiples cambios de herramienta de gestión de tareas que había tenido en el último tiempo.  Durante la conversación, no pude evitar pensar en la cantidad de energía que esa persona estaba gastando en pensar acerca de cómo hacer el trabajo, en lugar de sencillamente hacer el trabajo. No en vano David Allen, en su método GTD , procura mantener la infraestructura de tareas en su mínima expresión. Al hacerlo busca minimizar el riesgo de enamorarse de la herramienta. Debemos estar atentos a no dejar que nuestra herramienta de gestión de tareas nos domine y pase a ser nuestro principal tema de preocupación. La herramienta no es un fin sino un medio. Es algo que usamos para vaciar nuestra cabeza  y poder vivir mejor el momento presente. Seguimos pensando..

Del libro Work Rules  de Lazslo Bock (page 193): " Manager quality was the single best predictor of whether employees would stay or leave, supporting the adage that people don't quit companies, they quit bad managers" Seguimos pensando..  

Una forma interesante de entender por qué una organización tiene dificultades para implementar delivery continuo, testing continuo y, en última instancia, una cultura de DevOps más fluida, es fijarse en ciertos anti-patrones. La idea es que en lugar de (o además de) focalizarse en aquellos patrones de trabajo que hay que implementar, nos enfoquemos (también) en esos patrones de trabajo que deberíamos romper. A continuación listo seis anti-patrones muy comunes que deberíamos trabajar para romper, evitar o disminuir: Los ambientes de testing y producción son incongruentes. El testing demora mucho. El testing de regresión y de aceptación se hace en forma manual. Los lead times son largos. La deuda técnica es larga. Los cambios son costosos y lentos. Si dedicamos parte de nuestro tiempo a romper con ciertas rutinas o comportamientos nocivos estaremos mejorando también el ciclo de vida de desarrollo. De hecho, posiblemente encontremos mucha sinergia entre implementar

Debo reconocer que el título del artículo me intrigó:  Why COOs Should Think Like Behavioral Economists . ¿Por qué el COO debería pensar de esta forma? Pero la verdad es que el autor tiene razón.  Parte de s u trabajo es generar un ambiente donde los empleados puedan decidir mejor o sencillamente trabajar mejor. Perdón por la palabra que voy a usar pero el COO debe transformarse en el arquitecto del entorno de trabajo y la cultura de la organización .  Podemos pensarlo también como una cuestión de supervivencia. Si la cultura y el entorno no ayudan, sólo nos quedan los paquetes de compensaciones como forma de atracción y/o retención de empleados. Seguimos pensando..

En este  capítulo de The Big Bang Theory Sheldon se convierte accidentalmente en un vendedor de electrónica excepcional. A consecuencia de haber ido a una tienda de electrónica se cruza con personas que le hacen preguntas sobre productos que quieren comprar y él, gracias su conocimiento técnico, responde y se va ganando el lugar de vendedor experto.  La escena termina cuando Sheldon es arrastrado por un vendedor y Penny fuera del local y Sheldon se despide de su cliente diciéndole "Good luck". Todos los fans de la serie sabemos que si de parecerse (como humanos) a robots se trata, Sheldon es lo más cercano que podemos encontrar a ellos. Esta escena nos muestra un poco el camino que está transitando el retail hacia un mundo en el que el rol de "vendedor" tal y como lo conocemos irá desapareciendo. En un artículo llamado The days of the retail clerk are over , Doug Stephens explica por qué cree que los vendedores irán desapareciendo.  Por un lado, debido a

Hace un tiempo di una charla  en la que hablaba del futuro del testing y por donde podrían los testers ampliar sus horizontes.  En ese entonces decía que la gente que trabaja en testing no debía preocuparse mucho por la pérdida de puestos de trabajo a manos de la robotización y hablaba, por ejem plo, de usar las capacidades de testing en todo lo que tiene que ver con probar la experiencia de cliente . Hoy pensando en lo mismo, les traigo otra punta: RPA ( robotic process automation ). La idea detrás de RPA es entrenar a un robot para hacer acciones sobre una o varias aplicaciones, emulando lo que haría un humano.  Los beneficios de hacer algo así son los imaginables: optimización de las operaciones, reducción de costos, mejora en la experiencia del cliente, etc. Pero lo interesante, para la gente acostumbrada a hacer automatización de pruebas es que  Las habilidades necesarias para automatizar procesos en este nuevo contexto (RPA), son muy parecidas .  Deberemos p

Leo Piccioli en este post  mencionó un video de  #WHYGAMES llamado  Assassin's Creed Origins  que me pareció muy interesante. Primero por lo bien logrado que está el story telling , es entretenido verlo. Una muestra más de que con pocas cosas se pueden contar buenas historias. Segundo porque muestra que jugar a ciertos juegos puede ser educativo o productivo  también (mi hijo chocho con esta parte). Algo que algunos sospechábamos pero no decíamos en público para no perder definitivamente la atención de las criaturas de corta edad. Tercero deja claro el cambio que deberíamos (o estaríamos) viviendo en la forma de enseñar. En realidad, no sólo en la forma de enseñar, sino también en la forma de capacitar (palabra clave usada por las empresas para hablar de enseñar), en la forma de presentar y en la forma de convencer (vender ideas, productos y servicios por ejemplo). Seguimos pensando.. PD: El antiguo Egipto siempre ha sido uno de mis temas favoritos de historia

En los 70s, en una planta japonesa había 12 clases de trabajos. En una planta en EEUU había 67 clases de trabajo. Además el trabajador japonés tenía 10 veces más horas de capacitación que el americano.  El trabajador japonés era más versátil y podía desempeñar una mayor cantidad de roles. Esa versatilidad era acompañada con una actitud flexible para aceptar hacer distintos tipos de trabajo.  Como resultado de esto, la diferencia de productividad entre plantas resultaba enorme. Sería interesante traer ese concepto a nuestra realidad de hoy y ver cómo estamos: ¿Cuán v ersátiles somos? ¿Cuán flexibles somos para desempeñar distintos roles? Si todos podemos y estamos dispuestos a hacer de todo, los tiempos ociosos disminuyen y po r consiguiente la productividad aumenta. Seguimos pensando..

Leyendo sobre la historia de Lean y cómo la productividad de la industria japonesa empieza a opacar a la norteamericana en los 70 me encuentro con una métrica interesante: Sugerencias por Empleado.  Me pregunto: Si en nuestras empresas tenemos un buzón de sugerencias. Si vemos que hay allí en algún momento. Si implementamos algunas de las sugerencias que allí se hacen. Si revisamos si analizamos los resultados de haberla implementado. ¿Produjo ahorros? Si premiamos a la persona, cuya sugerencia fue implementada exitosamente y produjo ahorros. Si no hacen estas cosas, no se pregunten por qué sus procesos no mejoran y, menos aún, por qué sus buzones están vacíos. Es bastante claro. Seguimos pensando..