Así no se hacen las cosas por Ernesto Kiszkurno

Creo que no hay una mejor manera de empezar una reunión con un potencial cliente.  Estar sentándote en la reunión y que una de las personas con las que te vas a sentar a presentar tu empresa te diga "yo leo tu blog" no tiene precio.  Que te digan eso significa que el esfuerzo de mostrar tus ideas redunda en resultados. Seguimos pensando..

El mundo gira a una velocidad difícil de seguir en diversos planos de nuestra vida y los negocios no son la excepción. Esta velocidad aumentada  le está trayendo más de un problema a las empresas y en particular a IT, que por supuesto viene acostumbrada a vivir del lado previsible del abismo . La lucha se ve a diario. Por un lado, el negocio tratando de ponerse a tono de los nuevos clientes que demandan una experiencia diferente y de que IT sea parte de la solución. Por otro, IT tratando seguir el paso del negocio y de los clientes con esquemas de trabajo obsoletos, poco ágiles y caros. Una ola de renovación recorre las cabezas de los CIOs. Bimodalidad, agilidad y cloud, son algunos de los términos que los analistas del mundo IT repiten. Pero a esto debemos sumarle también la disrupción provocada por nuevas generaciones que están entrando a la fuerza laboral, con características muy distintas a las anteriores.  La tormenta perfecta es fuerte y para peor, no parece ser

Se hace en todas las industrias. En algunas es tan simple como ir y probar (si competis contra un restaurante, tan sólo tenes que ir a comer allí), en otras tal vez es más complicado (¿cómo probar [realmente] un servicio similar al tuyo si se da puertas para adentro en los clientes?). Pero de algo sí podemos estar seguros y es que tenemos que mirar qué están haciendo, cómo lo están haciendo y a qué precio lo están haciendo . Esto, que parece de perogrullo , es algo que muchas empresas de servicios no hacen [sistemáticamente]. Tal vez si hoy estuvieras mirando el blog de un competidor tuyo te darías cuenta de que están hablando desde hace tiempo de temas que vos mencionas como novedad. Quien sabe. Seguimos pensando..

Hay cosas en la vida que son inevitables. Podemos negarlas, resistirnos, luchar contra ellas, etc.. Sin embargo, tarde o temprano, nos daremos cuenta de que es inútil y las aceptaremos. Una de ellas, mis queridos amigos, es la rotación en servicios basados en personas . Las personas cambian de gustos, de anhelos, de necesidades, ..., y también de trabajo. A veces tenemos algo que ver, nosotros los clientes o nosotros los empleadores, y otras no. No es nada personal (o a veces sí y sigue siendo inevitable). El problema es que hacemos con la situación. Es por eso que en servicios que pretenden ser de larga duración debemos tener una estrategia de gestión del conocimiento y rotaciones programadas que nos permita mitigar los impactos de la rotación. Tal vez con un poco más de incomodidad en la diaria, pero con la certeza de lo que va a ocurrir. De otro modo, el servicio estará [demasiado] sumido en la incertidumbre de lo que las personas quieran hacer de sus vidas.  Segui

He notado que algunos tienen la fantasía  de que, si trabajan duro e invierten, lograrán tener una biblioteca de casos automáticos que podrá ejecutarán por los siglos de los siglos, ahorrándose un montón de trabajo manual. Pues bien, tengo una buena y una mala noticia. Empezando por la mala, la verdad es que no siempre lo lograrán.  He visto muchas situaciones donde por distintas razones el reuso de los scripts se hace muy difícil y debemos estar siempre encima de ellos (arreglándolos, manteniéndolos/ajustándolos, descartándolos, agregando nuevos, etc.). A veces tiene que ver con la aplicación (que cambia mucho, no madura o simplemente no anda), a veces con la arquitectura en la que trabajamos, con las herramientas que utilizamos (no sólo la de automatización), a veces con el tiempo que nos damos para automatizar (hacer las cosas más genéricas lleva más tiempo), a veces es por las personas que están automatizando, etc. Siguiendo por la buena noticia, hay un montón d

Cuando del rol del CIO hablamos, mirar hacia el futuro está muy bien. Debemos saber lo que se viene, estar preparados y listos para imaginar formas de aplicar la tecnología a los negocios.  Esto además debe hacerse en dos modalidades: Una primer modalidad más estilo soporte que se da cuando "el negocio" viene con requerimientos o demandas que deben ser interpretadas desde nuestro conocimiento de la tecnología; Una segunda que nos tiene como protagonistas, tomando la iniciativa, y llevando novedades, ideas o usos de la tecnología que podrían impactar positivamente en el negocio. Dicho esto, el CIO tiene desde siempre una responsabilidad operativa centrada en el ahora. Es imposible imaginar el futuro si el ahora no está controlado. El ahora es la base para poder pensar más adelante. Cuanto mejor resuelto y controlado este, más adelante podremos proyectarnos. Seguimos pensando..

Muchos están preocupados desde hace tiempo por hacer que cada vez más gente programe . Esto tiene que ver, entre otras cosas, con que la gente entienda cada vez más de tecnología, siendo que esta está cada vez más presente en la vida cotidiana de las personas. Paralelamente deberíamos también pensar en difundir cuáles son las virtudes y limitaciones del desarrollo de software y en particular del testing de software . Entender hasta dónde podemos llegar en temas como aseguramiento y control de la calidad, seguridad y/o auditabilidad es casi tan importante como saber programar. A partir de esto, me permito recomendar este artículo de El gato y la caja llamado Vot no , donde se explican tres principios clave: 1. El objetivo del testing es   incrementar confianza/disminuir riesgos "El testing es la disciplina informática encargada de probar una pieza de software buscando incrementar la confianza que se tiene en que opera como debe. Funciona así: uno prepara una batería

Encontré esta joyita en el timeline de Vala Afshar. Se trata de Steve Jobs hablando sobre ¿quién debe dirigir una compañía (la gente de "marketing/ventas" o la gente de "producto")? Tiene de todo. Un tema para la reflexión. La decisión sobre cuánto lugar (poder) y reconocimiento se le da a la gente de producto, frente a la gente de marketing o ventas tiene profundas implicancias para una compañía. Por ejemplo, y nombrando rápidamente solo 3, en la formación de capacidades diferenciales en innovación y oferta, en el posicionamiento hacia el mercado o en la atractividad (hacia futuros empleados). Una mirada interesante del personaje.  Lo que dice de empresas como IBM o Xerox, más preocupadas por los números de corto y mantener monopolios, que por lograr productos extraordinarios, pinta de cuerpo y alma cómo pensaba y de qué lado estaba. Momentos divertidos. Cuando habla de los "toner heads" y tiene que explicarle al entrevistador que es u

Cuando alguien se forma una opinión [equivocada] y empieza a hablar sin tomarse el trabajo de constatar lo que "se le ocurrió" tenemos dos opciones. Podemos ponernos a discutir de igual a igual, en un esgrima que podríamos llamar "tu opinión contra la mía" o podemos buscar números que nos den la razón. La segunda opción suele ser más efectiva. Esto es especialmente cierto con los generalizadores , esos que de un caso puntual arman un comportamiento sostenido. Para detectarlos sólo hay que prestar atención a juicios como "ustedes siempre ..." o "nunca consigo que ...". Seguimos pensando..

Gran gif de www.RobBomb.com sobre Teamwork  que debía reproducir aquí.  Me hizo acordar a un post sobre el camello  de Daniel Rabinovich  en el que citaba a Perón ("si quieres que algo no funcione, crea un comité") y a Steve Jobs en el mismo artículo. Seguimos pensando..

Es lindo testear. Tiene un no sé qué  que lo vuelve disfrutable (al menos para mi).  Por un lado nos dan una licencia para romper y por otro, resulta divertido eso de encontrar caminos en el software que otros no encontraron o no pensaron.  Como testers contribuimos creativamente a robustecer la aplicación, ya sea pensando desde el punto de vista del analista (situaciones de funcionamiento que la aplicación debería manejar) o desde el punto de vista del desarrollador (situaciones de error que también deberían contemplarse). El problema, para muchos, viene cuando la gestión invade la tarea específica . Cuando hacer el reporte y cubrirse de cada posible ataque de otras personas en el equipo de proyecto, se vuelve más importante que encontrar errores en el software. No matemos al testing, no le pidamos al equipo de testing hacer algo para lo que a veces no está preparado y para lo que nunca está motivado. Seguimos pensando.. 

Seguimos pensando..

Ningún correo electrónico donde digas algo del estilo "si hay algún problema con todo lo que estoy imponiéndoles sin preguntarles por favor escálenlo inmediatamente" puede ser parte de una cultura organizacional sana. Hoy leía un interesante artículo donde justamente hablaban de generar espacio  para trabajar mejor y así poder aportar valor: "Employees operating with some slack, Ms. Ton explained, add value that those pushed to the limit cannot. They feel better, have more time to spend with customers, keep closer track of inventory, make fewer mistakes and feel more highly engaged and committed at work." Seguimos pensando..