Así no se hacen las cosas por Ernesto Kiszkurno

Estoy seguro de que no es necesario explicarle a nadie la importancia de agradecer a las personas por su ayuda . Dar muestras explícitas de agradecimiento a quienes nos dan una mano no sólo es “de buena educación”, sino que también es una forma de que la gente nos siga ayudando. En la web esta buena práctica (la de agradecer la ayuda de los demás) es muy común.   Hay una costumbre twittera muy conocida llamada follow friday que consiste en sugerir a nuestros seguidores la posibilidad de seguir a personas que por alguna razón nos parecen interesantes. Seguramente, todos hemos visto tweets identificados por hashtags como #ff o #followfriday relacionados con este tema. Desde su origen el concepto se fue expandiendo para abarcar otros usos como por ejemplo el del agradecimiento. Cuando alguien nos ha ayudado de alguna manera, le mandamos un #ff para hacer ese agradecimiento (o reconocimiento) público. El agradecimiento en el entorno de trabajo Pero esto que es tan muy común en la

Tengo el honor de haber sido convocado a participar como jurado en la 2da edición 2010 del Concurso de Emprendimientos Innovadores organizado por el Banco de la Nación Argentina y la fundación EMPRETEC. Para más información pueden ir a la página del concurso . Seguimos pensando..

Me encontré hoy con un post en el blog de Mariana Riva llamado Análisis sobre la situación de la oferta de profesionales universitarios donde se muestran datos hard sobre la matrícula de las carreras de informática en Argentina. En contra de lo que he escuchado en varios lugares el post comenta lo siguiente: Si analizamos los últimos 13 años de nuevos alumnos matriculados en carreras de grado y pregrado vinculadas a la informática, vemos que se han mantenido en un promedio de 22.546 ingresantes. La tasa interanual promedio de crecimiento de la matricula es de apenas el 0,1% con dos caídas muy fuerte en 2003 y en 2006. La buena noticia es que no estamos en retroceso como algunos dicen. La mala noticia es que tampoco estamos creciendo. Creo que es tiempo de insistir: Chicos, estudien informática!! Y si no saben donde, esta es mi recomendación. Seguimos pensando (o reclutando) ..

Unos años atrás, mientras cursaba mi MBA, un profesor nos contó una anécdota de una "prestigiosa universidad americana" que estaba perdiendo terreno en los rankings de escuelas de negocio. El motivo de la caída era que sus egresados no estaban obteniendo contratos de trabajo suculentos al salir de allí y eso por supuesto es algo malo ya que los postulantes eligen a qué escuela irán en base a los rankings. La dinámica de ese sistema resultaba en un círculo vicioso: Mal ranking implica menos estudiantes. Menos estudiantes implican menos "buenos" estudiantes. Menos "buenos" estudiantes implican menos contratos suculentos. Menos contratos suculentos significan una mayor caída en el ranking. El desafío era hacer girar la rueda en el sentido contrario y transformar el círculo en uno virtuoso. Luego de cierto análisis, la conclusión a la que llegaron fue que el problema no estaba en el proceso (en las materias, en el método de

¿Qué pasa cuando las personas pierden la motivación por lo que hacen? ¿Cuando ya no están interesadas por su trabajo? Yo solía pensar que cuando esto sucede, usualmente la gente elije uno de estos tres caminos: Cambiar de trabajo para tratar de encontrar la motivación perdida en otro lado. Quedarse en la empresa pero culpándola de la situación y quedándose en la queja y la catarsis. Quedarse en la empresa tratando de cambiar la situación, sin culpar a nadie. Seth Godin , en un interesante post llamado I quilt , plantea una 4 opción. Como es cortito lo transcribo todo abajo: When you've had enough, can't tolerate your job any longer and are ready to quit, perhaps you could try one last thing. Quilt instead. You've got nothing to lose, right? I mean, you're going to quit anyway, so what's the worst that could happen to you? So quilt. Spend hours every day integrating the people you work with into a cohesive group. Weave in your cust

El otro día en la charla que di en ITBA hice un paralelo entre el buen fútbol y la calidad de software. Sí, efectivamente. Me metí en un tema ríspido como el fútbol para hablar de otro tema ríspido que es “calidad de proceso vs. calidad de producto”. Para ello mostré el siguiente cuadro donde se ven 4 escenarios típicos del fútbol: El eje de las X simboliza buenas y malas decisiones de estrategia por parte del director técnico y el eje de las Y simboliza buenas y malas implementaciones de la estrategia por parte de los jugadores. No estoy hablando aquí de jugadores estrella, sino de buenos o malos implementadores de la estrategia. Y respecto a ellos, hay dos puntos clave a mencionar antes de revisar los escenarios: Si tenés malos jugadores, estás fuera del campeonato. Podes ganar algunos partidos pero en el mediano-largo estás frito. Si tenés mal equipo, tu primer problema no es la calidad. Tu primer problema es lograr el resultado. Dicho esto, si tuviera que dar un orden a l

Mañana estaré dando una charla en una Jornada sobre Gestión de la Calidad de Software organizada por ITBA. Hablaré sobre Control de Calidad de Productos de Software en Argentina. Seguimos pensando..

Ese es el título de uno de los ensayos del libro Peopleware de Tom DeMarco y Timothy Lister [1]. En este interesante ensayo se menciona un concepto importante que cualquier profesional del conocimiento (por ejemplo un consultor) debe tener presente: the flow . During single-minded work time, people are ideally in state that psychologists call flow. Flow is a condition of deep, nearly meditative involvement. In this state there is a gentle sense of euphoria, and one is largely unaware of the passage of the time [..]. There is no consciousness of effort; the work just seems to, well, flow. En contraposición con ese estado está el No-Flow, es decir el tiempo en el que nos es imposible trabajar puesto que sufrimos interrupciones . Un día con suficientes de ellas, estratégicamente distribuidas durante las 9 y las 18 horas, será un simple y sencillo desperdicio. Al igual que la sensación de “se me fue el tiempo trabajando” que experimentamos cuando tenemos momentos de fluidez, todos hem

Parece haber un consenso generalizado respecto de la conveniencia de realizar actividades proactivas de testing sobre los sistemas críticos desarrollados ad-hoc. Si un sistema será usado por muchos usuarios y/o por usuarios importantes y/o intervendrá en procesos críticos de la compañía y/o la cantidad de horas previstas para la implementación supera cierto umbral, es considerado crítico y por consiguiente digno de testearse . Siguiendo con esa idea, el proyecto asociado se vuelve estratégico . El gran esfuerzo requerido suele venir tanto del área de TI como de las áreas usuarias. Y esto no ocurre solo durante el periodo de implementación, sino también luego de ella (durante el mantenimiento). Se trata de proyectos que impactan “a lo ancho y a lo largo” de toda la compañía y por ende requieren también una gestión muy ordenada. En este contexto el concepto de "actividades de testing proactivas" incluye 2 cuestiones fundamentales: La elaboración de una estrategia de tes

Buscando información sobre técnicas ágiles aplicables a testing descubrí una charla que Cem Kaner y James Bach dieron en Star West del 2001 llamada Exploratory testing in pairs . La charla tiene sus años y el concepto no es nuevo (¿quién no ha testeado con alguien al lado tratando de reproducir un error escurridizo, no?). Sin embargo me gustó el resumen de la técnica que dan y la lista de beneficios asociados a utilizarla. La técnica Los autores definen pair testing como una actividad de testing exploratorio que llevan a cabo dos testers en una máquina. Generalmente, uno de ellos tiene la responsabilidad formal de la prueba y para llevarla a cabo recluta a otro tester que lo ayudará en la tarea. Durante la actividad el teclado pasa de un tester al otro según se prefiera. El tester que no tiene el teclado sugiere ideas, hace preguntas y propone pruebas adicionales. Las sesiones duran a razón de 60 minutos y los objetivos de la prueba son planteados a priori. Los beneficios Se