Así no se hacen las cosas por Ernesto Kiszkurno

Según este interesante artículo titulado  Employee Burnout Is a Problem with the Company, Not the Person  hay tres causas principales a la hora de entender los altos índices de rotación por burnout en las empresas. La primera es la colaboración excesiva : "Excessive collaboration is a common ailment in organizations with too many decisio n makers and too many decision-making nodes . It manifests itself in endless rounds of meetings and conference calls to ensure that every stakeholder is heard and aligned." La segunda son los débiles conocimientos en gestión del tiempo : "In most large organizations today, the demand for collaboration has significantly outpaced the development of tools, disciplines and organizational norms to manage it. Most often, employees are left on their own to figure out how to manage their time in ways that will reduce stress and burnout. They have limited ability to fight a corporate culture in which overwork is the norm and even c

El concepto de mínimo producto viable (o MPV) no sólo sirve para productos. Son muchas las situaciones donde aplicar la idea da múltiples ventajas. Una de ellas es cuando debemos elaborar una propuesta de servicios para un cliente.  Si aplicamos la idea de MPV, en lugar de entregar una propuesta terminada luego de la primer reunión, como muchas veces ellos mismos nos demandan, podemos elaborar un enfoque de solución más liviano y conceptual que nos permitirá: Entregar algo rápido . Los clientes valoran siempre una rápida respuesta. Tener nosotros un  feedback temprano que nos diga si estamos alineados en cómo encarar el servicio y si nuestras capacidades alcanzan para cubrir las expectativas del cliente. Que el cliente comente sobre la solución y se sienta parte de lo que estamos co-creando . Validar el interés del cliente en el tema, pues alguien que no nos da feedback es alguien que no tiene el tema entre sus prioridades. Luego de algunas iteraciones el enfoque se tran

En el pasado les he hablado de lo mucho que me gustan las presentaciones de Henrik Kniberg (ver  aquí  o  aquí ). En esta ocasión les dejo un video elaborado por él sobre cambio climático, su siguiente desafío .  Además de ser útil por su contenido, el video también muestra lo bien que maneja el arte de la presentación y la facilitación gráfica . Seguimos pensando..

Todo vuelve, todo gira, todo vuelve a empezar. Hace unos días estuve en una charla introductoria sobre blockchain . Me resultó muy interesante poder preguntar de primera mano algunas cosas que no sabía y entender que, de cierta forma, hay nuevas tecnologías que nos hacen volver a empezar y reutilizar nuestras habilidades. Hablo de volver porque la escritura de smart contracts  en blockchain involucra asegurarse que dichos contratos funcionan bien, es decir, involucra probarlos. ¿Cuál sería el costo de un error o una vulnerabilidad en un contrato de estos? En una nota de mayo de 2016 llamada Testing Blockchain se describen algunos de los problemas por los que está atravesando la práctica de testing en esta tecnología: Mucho Testing Manual Inmadurez en la práctica automatización Múltiples frameworks para automatizar ¿Les suena conocido? En palabras del entrevistado en la nota "The smart contract world has caught up, in a sense, with the traditional software eng

La parte más importante de una conversación es la de escuchar al otro. El problema es que uno, a veces, está tan pendiente de decir lo que tiene para decir que no repara en que del otro lado también puede tener cosas interesantes para aportar también. Cuidarse de interrumpir, tomarse tiempo para responder y pensar en lo que el otro dijo, son algunas de las cosas que deberíamos tratar de hacer. Es difícil pero esas veces en las que uno lo logra, todo sale mejor. Seguimos escuchando..

Decíamos que el concepto de calidad está cambiando de la mano de testear experiencias . Un ejemplo claro de estos cambios es lo que sucede con el concepto de error.  En testing de software reportamos errores que deben ser encontrados y corregidos pero nunca son bienvenidos.  En el nuevo paradigma de la calidad, donde probamos hipótesis sobre la experiencia de nuestros clientes (o usuarios) diseñando experimentos, puede haber hipótesis erróneas, experimentos erróneos y/o errores de ejecución de nuestros experimentos. Aquí la noción de error se hace menos clara (o más flexible). Dado que intentamos seguirle el ritmo a los gustos del cliente y a la tecnología, buscamos equivocarnos rápido y con mínimo impacto . En este nuevo juego los errores son tan buenos como los aciertos porque nos dan información. Seguimos pensando..

La práctica de inteligencia de negocios (o business intelligence o BI para los amigos) tiene muchos años. Inicialmente los proyectos de BI eran faraónicos. Llevaban meses o años, y para cuando el usuario final veía los reportes, la necesidad habían cambiado. El paradigma era que el usuario pedía a TI algo (a veces bastante difuso) y estos se encerraban por meses con sus proveedores para luego volver con un edificio construido. Hoy, gracias al progreso en términos de herramientas, técnicas y tecnología (por ejemplo la nube), ni el usuario queda supeditado a aquel pequeño papel ni TI tiene la responsabilidad de hacer un edificio.  En nuestros días se ha llegado a un punto intermedio. Por un lado, TI es responsable de disponibilizar datos y herramientas . Ya no se trata de que ellos llegue a hacer todos y cada uno de los reportes que el negocio necesita (todo el edificio) porque, sencillamente, el negocio no sabe qué reportes necesita anymore. Por el otro el usuario ahora tiene

El efecto cascada desencadenado por la transformación digital de los negocios ya alcanzó a la gestión de proyectos. Esta transformación está golpeando profundamente el rol de TI   en muchos aspectos. Uno de ellos es su capacidad de ejecución de iniciativas y proyectos . En palabras de Dion Hichcliff, TI debe tener agilidad y escala .  La imagen es elocuente. IT ya no tiene meses para entregar valor. Ahora, a veces tiene días y a veces tiene horas. El paradigma de ejecución cambió abruptamente. Es en este contexto en el que me pregunto cuánto lugar tienen las prácticas tradicionales de gestión de proyectos , o las capacidades típicamente valoradas de la gente que gestiona proyectos, o para el caso las herramientas que usamos para llevar adelante proyectos. Así como lo he dicho para otras prácticas , creo que estamos ante un momento de cambio en la gestión de proyectos también. Seguimos pensando..

Alguno me va a tildar de ingenuo pero la verdad es que me cuesta entender la estrategia de Microsoft para Office 365. Tienen tantas herramientas similares en algunas categorías que siento que lo único que logran es marear al usuario y hacer que se vaya corriendo a buscar algo fuera de su entorno más simple, de uso más fluido y mejor integrado. Tomemos el rubro tareas  por ejemplo. En Office 365 podemos tener tareas utilizando las famosas Tasks de Outlook, podemos tenerlas usando Microsoft Planner , podemos tenerlas usando Wunderlist y ahora podemos también tenerlas usando Microsoft To-Do . Esto sin contar que en OneNote también podemos tener tareas. Si nos vamos al rubro espacios de colaboración  tenemos Yammer, Groups y Teams. Calculo que en algún momento todo esto se simplificará y logrará confluir a unas pocas herramientas, no? Seguimos pensando..

Allá por el año 1997 era ayudante de una materia llamada Ingeniería de Software 1 , en la facultad de Ciencias Exactas y Naturales de la UBA. En ella utilizábamos el caso del robot asesino  para discutir diversos temas (proceso de desarrollo, testing, etc.) y una de las cuestiones clave era cuando el software es  good enough . Era una situación ficticia que servía para desafiarnos a futuro. 20 años después estamos en lo mismo, pero con la sensación de que ahora todo eso está definitivamente entre nosotros. Si no me creen piensen un poquito en casos como el del robot cirujano ( this Robot Completes a 2-Hour Brain Surgery Procedure in Just 2.5 Minutes ) o el de los autos autónomos ( Self-driving cars are already deciding who to kill ). Cuando el software será good enough como para que las personas digan "no, prefiero que me opere el robot y no el cirujano". Seguimos pensando..

Que el impacto del desarrollo tecnológico en el mundo actual nos impone cambios a todos no es una novedad. Por ejemplo, cuando veo notas como esta del Hoffenheim , el equipo 2.0 que utiliza tecnología de punta para potenciar su juego, o estas de Ariel Holan en Defensa y Justicia y Atlas transitando el mismo camino aquí en Argentina, no puedo evitar pensar en cómo deberíamos probar estas cosas y en los desafíos que plantean a las prácticas de testing tradicionales . Por poner un ejemplo, en la nota a Ariel Holan comentan que la solución involucra tener sensores en las medias de los jugadores que transmiten información a un lugar centralizado para que luego, desde una Tablet, el entrenador consuma esos datos de determinada manera.  En este contexto ¿es razonable sentarse a escribir una estrategia de pruebas? ¿será razonable descomponer la prueba en testing de unidades, módulos, interfaces y casos end to end? O ¿será más acertado tener un enfoque más ágil y exploratorio? A

"Los melones se acomodan con el carro andando" dice el dicho, y nunca más cierta que en estos tiempos.  Hoy por hoy no podemos esperar a tener todo resuelto y todo pensado. Necesitamos salir al ruedo con cosas menos terminadas para tener feedback e iterar. "Salir con nuestro mínimo producto viable" dice Eric Ries en su libro Lean Startup . Esto demanda salir rápido pero también salir con un producto, con algo que podamos considerar un producto y que, siendo usado por alguien, nos de información como para enriquecerlo. Salir no es hacer papelones tampoco. La idea detrás de salir rápido es equivocarse rápido y cuando hacemos esto, equivocarnos cuesta menos y corregir cuesta menos. Lo interesante de estos principios es que han trascendido a los productos y los startups para llegar a los servicios y a los procesos. Hay muchas situaciones donde podemos ver que esto sirve.  Por ejemplo, en consultoría, validar entregables tempranamente con nuestro cliente en

Para aquellos interesados en el desarrollo de software, recomiendo esta charla con Sebastián Uchitel en Conversaciones de La Nación. Fueron varios los temas interesantes, pero en particular hubo uno que llamó mi atención: la aplicación de técnicas de analytics y big data para predecir errores . Sí, como lo escuchan. Qué tal si en lugar de encontrar errores, nos ponemos a predecir por dónde vendrán. Sebastián comenta que “tenemos una cantidad enorme de información donde buscar”. Alguna disponible públicamente y otra no tanto, pero con los debidos permisos tendríamos posteos en redes sociales, participaciones en foros, mails, documentos, etc. La hipótesis es que entendiendo mejor cómo piensan los desarrolladores podemos entender dónde se equivocarán y en función de eso actuar. Sería hacer algo parecido a lo que hacía Tom Cruise en Minority Report, no? Aunque nosotros no buscamos arrestar programadores antes de que inserten un bug porque básicamente no quedaría ni uno libre

Encuentro un gráfico interesante en la Agenda del CIO 2017 publicada por Gartner. Muestra qué balance eligen, entre costos y targets de valor para el negocio, los distintos CIOs. Me pregunto cómo será esta distribución aquí en Argentina y si realmente pueden, nuestros CIOs, manejar el BAU ( business as usual ) con tan poca dedicación. Seguimos pensando..