Así no se hacen las cosas por Ernesto Kiszkurno

En otra época instalar pocas veces en producción era un mérito. Se buscaba minimizar la cantidad de veces que se ponían cosas en producción, como forma de minimizar los riesgos. Hoy las empresas necesitan poner continuamente software en producción. Obviamente, la necesidad de minimizar riesgos permanece, la diferencia es que ya no es posible esperar y espaciar las instalaciones. Cuando una organización entiende esto, cae en la necesidad de planificar e implementar estrategias de continuidad para el Testing, el Delivery o para la Integración de su código . Seguimos pensando..

A medida que vamos acumulando “años  de experiencia”, comenzamos a tener momentos deja vu. Es decir, reediciones de problemas y soluciones del pasado, en el presente. Uno de esos temas es el de BPR y RPA. El BPR (Business Process Reingeneering) de hace 20 años no es tan distinto de lo que sucede  hoy con RPA (Robotic Process Automation). La gran diferencia está en las herramientas de las que disponemos actualmente para hacer nuestra organización más ágil. Tomemos como ejemplo el tema de la automatización de actividades de escritorio (RDA -  robotic desktop automation), donde el objetivo principal es estandarizar, automatizar y agilizar las actividades de un usuario final en su desktop. El objetivo es el mismo de hace años, la diferencia es que hoy tenemos un sinfín de herramientas para facilitarle el trabajo al usuario o para que él mismo automatice parte de su trabajo. La sensación de deja vu viene cuando entendemos que lo que estamos tratando de hacer, una vez más, es au

Escuché por ahí que todos nos creemos mejores de lo que realmente somos en muchos temas. Nosotros los consultores no estamos ajenos a esto y en particular tenemos este problema con la escucha.  Creemos que escuchamos mejor de lo que realmente lo hacemos o sencillamente, creemos que escuchamos, cuando no lo hacemos. Les dejo un video corrido de Kelly Decker que nos sugiere enfocarnos en quien escucha para ser efectivos en nuestra comunicación . Una perogrullada, no? Seguimos pensando..

Es cada vez más difícil encontrar información de calidad en Twitter y Facebook. Las “líneas de tiempo” de estas aplicaciones están llenas de cadenas, peleas, noticias falsas (o sesgadas) y cosas por el estilo. Solo es posible leerlos si nos los tomamos en joda, como pasatiempo o con algún calmante. Tal vez, sería mejor hacer algo parecido a lo que decidió hacer Joel Spolsky : “ My new year’s resolution was to give up on reading Twitter and Facebook. I gave up on the feeds because they were making me angry. A lot of times I was angry because of politics, but even on non-political things, the feeds seemed like they were full of conflict and stress.” Por lo pronto, encuentro mejores resultados en el viejo y querido Feedly para mantenerme al dia con ciertos temas.  Twitter y Facebook son má s “un postre” para ciertos momentos de ocio. Seguimos pensando..

Desde siempre las empresas de software han logrado hacer parecer normales situaciones totalmente antinaturales. Me acuerdo de los disclaimers que decían “la empresa XXX no se hace responsable de los daños que pudieran ocurrir al usar el software YYY”, o la situación actual donde las empresas cambian “los términos y condiciones” como quieren y cuando quieren. Encontré un artículo interesante en The Economist   que sugiere la idea de que las principales firmas de internet, que se enriquecen con nuestros datos, nos paguen.  Dice que el arreglo actual no es justo y que nosotros, que somos los que laboriosa y sistemáticamente generamos esos datos, deberíamos recibir algo a cambio.  Sugiere hasta la formación de un sindicato para tener más fuerza a la hora de negociar.  No parece mala idea, no?  Lo podríamos llamar SIGEDA (Sindicato de Generadores de Datos), aunque habría que pensar bien como elegimos a nuestros representantes. Del otro lado de la grieta (una más y van...), en los c

Algún detallista habrá notado que estamos más remolones con los posteos esta semana. A no preocuparse es el efecto vacaciones. En otras épocas me mataba para dejar todo publicado antes de irme. Esta vez me lo tomo con más parsimonia. El tiempo dirá si es mejor o peor, por lo pronto el relax cae bien. Seguimos pensando..

Uno de los múltiples problemas que tiene usar WhatsApp para el trabajo es el Out of Office cuando nos vamos de vacaciones.  Todos siguen escribiéndonos por allí, pues no saben que estamos de vacaciones, y nosotros nos vemos en la obligación de contestar.   Podemos colgar el cartel de aviso en el estado pero eso sería algo demasiado general (muchos no quieren publicar por todos lados cuando no están) y poco efectivo porque las listas de trabajo siguen funcionando y nosotros recibiendo mensajes. Es por eso que fomento poco, y casi nunca recomiendo, el uso del WhatsApp para el trabajo. Se hace difícil lograr el quiebre de la rutina diaria , tan necesario en vacaciones para relajarse y descansar.  Además hay otras aplicaciones que resuelven mejor este y otros problemas sin perder la universalidad que WhatsApp tiene. Con esto no digo que debemos prohibir el uso de WhatsApp para el trabajo, pero si mantenerlo acotado a ciertas prácticas. Buscamos no caer en lo fácil que es us

Andres Neuman, en un podcast de Aprender de Grandes , comenta que una de las cosas que aprendió fue a desaprender y define el término como desprenderse de cosas que creíamos que sabíamos.  Me gustó la idea de desaprender.  La relacioné con mi  seguir pensando  ya que también requiere poder cambiar de opinión y me pareció que hacerlo regularmente era  difícil  porque significa tomar la decisión de ponernos en el lugar de cuestionar cosas que  pensamos que son verdades inmutables. importante  porque si no estás dispuesto a hacerlo, no vas a poder aprender cosas nuevas. Días atrás hablé de que para cambiar se necesita un slack . Si no desaprendemos, no generamos ese slack. necesario porque el mundo esta cambiando y lo que nos trajo hasta aquí no nos va a servir para lo que se viene. A vos que te parece? Seguimos pensando..

Terminé de leer Slack de Tom DeMarco . Un libro con algunos altibajos pero que te deja mensajes interesantes. El más fuerte es que si una organización no tiene slack, no va poder a cambiar, mejorar o innovar. Y lo muestra con un lindo ejemplo: ¿Recuerdan ese juego? Es el que hay que mover los cuadrados para ordenarlos correctamente, sólo que en este caso el espacio en blanco se utilizó para sumar otro número (el nueve). Así la empresa usa todo el espacio disponible pero pierde la capacidad de cambiar. "The open space represents what I call slack, the degree of freedom required to effect change. Slack is the natural enemy of efficiency, and efficiency is the natural enemy of slack. And there's the rub: There are things you can do to make an organization more efficient that interfere with its ability to change and reinvent itself later." Otro que también me dejó pensando (dado mi background y natural tendencia hacia "eficientizar todo") es este: &qu

Primer acto el cliente nota un incremento sostenido en sus facturas a lo largo del tiempo y se queja. La empresa pone una excusa muy pobre. Segundo acto el cliente se queja nuevamente y avisa que estará buscando mejor servicio en otro lugar. La empresa encuentra un error involuntario en la facturación y "corrige" en la cuenta del cliente. Tercer acto el cliente se queda pensando en eso de que ¿si un árbol se cae en el bosque pero nadie lo escucha, hace ruido ? o mejor dicho "¿si el cliente no se quejaba, se encontraba el error?" ¿Cómo se llama la obra? Esa no es la experiencia de cliente que estamos buscando! Seguimos pensando..

Es difícil negar que la práctica de testing, y en particular el rol del tester, está cambiando. La ola (o tsunami) de cambios tecnológicos que vivimos impacta también en dichas costas. El miedo existente en mucha gente, a ser reemplazados o quedar obsoletos por dicha ola, está patente en el mundo del testing. Pero ¿hay motivos? ¿Los testers deberían estar preocupados por los cambios que hay? ¿Los testers son una raza en extinción? Mi respuesta rápida es NO. El mundo consume cada vez más tecnología y por consiguiente cada vez más software. Esto, indefectiblemente hace que necesitemos seguir haciendo testing. El problema está en qué entendemos por testing cada uno de nosotros y aquí sí hay gente que debe preocuparse. En un interesantísimo artículo de 2013  (sí, de hace tiempo!), James Bach hace una distinción fundamental entre "checking" y "testing" que transcribo a continuación: "Testing is the process of evaluating a product by learning about i

Me encuentro muy seguido con gente que piensa la calidad como un firewall que limita todo lo que pasa hacia producción, en lugar de pensarla como un proceso continuo en el que hacemos las cosas cada vez mejor, colaborando a lo largo de la cinta infinita de la imagen. Mejorar la calidad es movernos por esta verdadera cinta de Moebius  cada vez más rápido y en forma más fluida (sin detenernos). Cuando entendemos esto es que, por ejemplo, empezamos a apostar por otras formas de automatización que van más allá de lo obvio o empezamos a pensar en el next step as a customer  para facilitar las cosas. Seguimos pensando..

Digresión: Iba a titular este post como  el éxito de los testers los lleva al fracaso  pero me pareció un poco melodramático y lo cambié. Perdón. Imagino que muchos de ustedes estarán familiarizados con la llamada  "ley de los rendimientos decrecientes"  tan importante en Economía. Para los que no, dejo un link  aquí  y transcribo a continuación una breve explicación: "En economía, la ley de los rendimientos decrecientes es la disminución del incremento marginal de la producción a medida que se añade un factor productivo, manteniendo los otros constantes. Afirma que en todos los procesos productivos, añadir más de un factor productivo mientras se mantienen los otros constantes dará progresivamente menores incrementos en la producción por unidad.​" Mejor un ejemplo. Supongamos que tenemos un software que probar. Piensen en el esfuerzo que nos toma, como testers, encontrar errores en él. Al principio cuesta menos encontrar problemas. La propia inmadurez

Los brindis no se hacen en piloto automático, para cumplir o para "tachar la tarea". Los brindis se hacen para festejar,  para arengar , para desear felicidad a los demás o para compartir las ganas de hacer más . Sí, ya sé que en un blog llamado así no se hacen las cosas  esto puede sonar disonante pero es fin de año y se supone que todos estamos más permisivos y bondadosos. Sea bueno querido lector! Si le aguanta su mala prosa al autor de este blog, ¿qué le cuesta aguantar también este torpe intento de agradecimiento por sus horas dedicadas a leerlo? Me tomo este post para festejar el hecho de que las visitas y los retuits siguen creciendo, para arengarlos  a que sigan leyendo y comentan más, para desearles felicidad al leer el blog y para compartir mis ganas de que esto siga.  Gracias totales y  Seguimos pensando..