Así no se hacen las cosas por Ernesto Kiszkurno

¡Cómo pasa el tiempo! ¿Habré dicho eso antes? Prefiero no revisar para atrás. Parece que fue ayer cuando escribí el aniversario anterior. O ante ayer cuando en julio de 2009 (la foto es de esa época) pensaba en abrir este espacio. La vida es eso qué pasa entre aniversarios del blog, no? Pasó de todo en estos últimos 12 meses. Tal vez ustedes, queridos lectores, no han visto tanto por aquí pero por debajo, a los costados y por arriba, … pasó de todo. No es el estilo de este espacio hacer recuentos muy personales, por aquí hablamos de temas relacionados con la profesión (y qué difícil es explicar cuál es mi profesión en estos días, casi tanto como pensar cual querría o debería ser). Volviendo al Blog, 1628 entradas ya. Es cierto, desde hace algunos años, a otro ritmo pero todavía mostrando cosas (los consultips por ejemplo siguen saliendo semanalmente). Antes forzaba la marcha, la regularidad lo era todo. Disciplina espartana. Ahora estamos más humildes, dejamos que la cosa fluya y cuan

No, no me refiero a Leonard Hofstadter . Estoy hablando del amigo Douglas, que en un rapto de brillantez, enunció una ley muy útil para nosotros los consultores, tecnólogos e impacientes de este mundo:  It always takes longer than you expect, even when you take into account Hofstadter's Law. Como dice por  aquí , el bueno de Brooks fue quien comentó sobre esta utilidad en  The mythical man-month  ya hace bastante tiempo. Debo confesar que yo no recordaba esto, así como tampoco recordaba que ya había escrito sobre esta y algunas otras leyes por aquí . Todo esto viene a cuento de alguna conversación que tuve con colegas días atrás. Esta gente tenía la esperanza de que cierto proyecto termine antes de lo que todos preveíamos y yo les decía que no, que iba en contra de la ley (de Hofstadter!).  Seguimos pensando..

Escuché por ahí un dicho que me pareció interesante para adoptarlo como consultip: “Si crees que un experto es caro, trata de contratar a un amateur”. A priori contratar a alguien más capacitado o con más experiencia puede parecer más costoso, pero eso es solo porque no nos detuvimos a hacer la cuenta del impacto que podría tener poner a alguien inexperto a resolver nuestros problemas más críticos. Seguimos pensando.. T o dos los  cons ultips juntos están  aquí .  Si queres leer el anterior podes ir  aquí .

Empezó como la solución a todos nuestros problemas. No necesitábamos pensar más en hacer interfaces o integraciones entre nuestros sistemas, tampoco necesitábamos grandes proyectos de meses, sino que con semanas alcanzaba. Para algunos con RPA solo era cuestión de "grabar lo que hace el usuario y listo" pero lo cierto es que no.  Construir un robot es escribir software y como todo software, lleva tiempo. Debemos programarlo, testearlo y definitivamente mantenerlo. De más está decir que cuánto más robusto o complejo lo queramos, más código necesitaremos y a más código significa más costo (errores, dinero, tiempo). Muchas personas le piden a RPA que sea bueno, bonito y barato pero lo cierto es que no lo será nunca si la solución es sofisticada. Cuando complejizamos lo que el robot debe lograr, combinando múltiples sistemas, accediendo a sitios que cambian todo el tiempo o tratando de hacerlos más inteligentes que las personas, mayor probabilidad tendremos de tener problemas.  C

Alguno habrá escuchado la frase "el consultor vende confianza" pero lo cierto es que la confianza no se vende, se genera. Una formula simple pero poderosa para lograr eso es cumplir con lo que nos comprometemos y gestionar lo que incumplimos . La primera parte no requiere mayor explicación, es casi una regla de vida. La segunda es más sutil. Se trata de manejar correctamente esas situaciones donde no podemos cumplir lo acordado (¡siempre tendremos alguna!). La mala noticia es que no hay un método único. La forma dependerá de la situación, el contexto y los recursos que tengamos. Seguimos pensando.. Foto de Saime Dal . T o dos los  cons ultips juntos están  aquí .  Si queres leer el anterior podes ir  aquí .  Si queres ir al próximo podes ir  aquí .

Hace muchos años, trabajaba con un banco en la implementación de su nuevo core, me tocaba liderar un equipo de testing dentro del proyecto. Como parte del gobierno teníamos reuniones gerenciales periódicas donde se comunicaba el avance y los problemas que iban surgiendo. A mí me tocaba explicar cómo iba el testing y si el nivel de calidad era el adecuado. Me tocaba decir algo incómodo. Recuerdo las miradas ansiosas cuando comentaba la evolución en la cantidad de errores abiertos y sus criticidades. Habíamos sido contratados para eso y todos los stakeholders del proyecto lo sabían. Al venir de afuera, el consultor tiene una mirada despejada y sin tantos condicionamientos. Esto le permite muchas veces decir cosas más duras que tal vez alguien de adentro no puede o prefiere no decir. Hay casos distintos al antes mencionado, en los que nos toca decir lo incómodo, pero nuestros stakeholders no están tan preparados para escucharlo. Estos casos son más difíciles y deben ser manejados con más