Así no se hacen las cosas por Ernesto Kiszkurno

 Hoy leí un artículo de Paul Graham titulado Taste for Makers  que me encantó y me dejó pensando. Me encantó porque está bien escrito y habla de diseño en un sentido amplio (abarcando múltiples campos como ser software, escritura o arte). Me dejó pensando en que los consultores también debemos desarrollar [buen] gusto. Buen gusto es lo que decimos, lo que escribimos, lo que presentamos y cómo lo presentamos. Todo lo que hacemos tiene que tener buen gusto. Alguno podrá querer empezar una discusión sobre lo que es buen gusto y lo que no. Cuando quieran y donde quieran, pero antes les pido leer el artículo para tener una base común. Habrá otros que no necesitarán lectura o explicación. Esos seguro ya han empezado a cultivar ese ojo crítico para distinguir el buen gusto. ;-) Seguimos pensando.. T o dos los  cons ultips juntos están  aquí .  Si queres leer el anterior podes ir  aquí .

Dejo aquí 3 newsletters que estoy siguiendo actualmente: The 3-2-1 Newsletter de James Clear. Viejo Smoking de Cecilia Absatz NessLabs de Anne-Laure Le Cunff Hay muchos otros pero los dejo para otra ocasión. Seguimos pensando..

¡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.. Todo s  los consultips juntos están  aquí .  Si queres leer el anterior, podes ir  aquí .  Si queres ir al próximo podés 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...