Así no se hacen las cosas por Ernesto Kiszkurno

Hoy en Argentina hay muchas oportunidades de trabajo para los profesionales en informática. Esta situación les permite mejorar sus condiciones de empleo muy fácilmente. Casi sin tener que salir a buscar. En la mayoría de los casos veo que el principal driver para cambiar es el económico. Esto es lógico por supuesto, pero creo que dada la alta demanda, hay otro que debería ser tenido más en cuenta: el de aprendizaje. Haber pasado por ciertas situaciones, ciertos proyectos y/o ciertos lugares nos hace mejores profesionales. Nos posiciona mejor en el mediano y largo plazo de nuestra carrera. Hay momentos en que es caro elegir ir a lugares donde aprender, otros en los que es barato. Cuando la demanda laboral es baja, los salarios bajan y el abanico de alternativas es más restringido. Cuando la demanda laboral es alta y los profesionales escasean y los empleadores están mucho más propensos a seducir. Este es un momento particularmente bueno para elegir pensando en donde vamos a apre

En el libro Personnel Economics , Edward Lazear define al salario como una compensación basada en el input en contraposición al piece rate que se basa en el output. El autor menciona tres puntos importantes relacionados con esta distinción: Los esquemas basados en el input no hacen diferencia entre los trabajadores. Los esquemas basados en el output incentivan a los trabajadores ineficientes a dejar la empresa. El principal factor de decisión entre un esquema y el otro es el costo de medición o monitoreo. Cuanto más costoso sea medir el output, más propensa será la situación para adoptar un esquema basado en el input. Muchos managers prefieren enfocar su energía en controlar que un trabajador está cumpliendo cierta cantidad de horas y/o ciertos horarios. Es decir, pagar por el input. Esto en el mediano plazo es perjudicial cuando hablamos de trabajadores del conocimiento puesto que los buenos tienen a sentirse incómodos, poco valorados y perseguidos. Como managers debemos inten

Este post fue escrito para el blog Mejores Proyectos . ¿No les ha pasado estar liderando o gerenciando un proyecto y encontrarse en una situación problemática o tensa que sienten podrían haber evitado? Un gap de expectativas, un cambio de alcance, un stakeholder disconforme, una mala decisión, etc. A mí me ha pasado y casi siempre, al hacer una retrospectiva del problema, encuentro que de alguna forma lo podríamos haber evitado. Yo se que algunos lectores van a poner la excusa de que "con el diario del lunes todo problema es evitable" pero la verdad es que en algunos casos no es necesario ser clarividente para pisar esas pequeñas bolitas de nieve antes de que se conviertan en una grande. Una de las herramientas clave para lograrlo es la previsibilidad . Esto es mantener a los stakeholders y miembros del equipo de proyecto, avisados, alertados o informados de lo que va a ocurrir y porque. He mencionado aquí el dicho "se pueden dar buenas y malas noticias pero no sorpr

En el libro Creatina a Software Engineering Culture de Carl Wiegers encuentro la siguiente cita de Watts Humphrey: The problems of [software] process change are often complicated by the fact that no one is responsible to make it happen. If [software] process improvement isn´t anybody’s job, it is not surprising that it doesn’t get done! If it is important enough to do, however, someone must be assigned the responsibility and given the necessary resources. Until this is done, [software] process development will remain a nice thing to do someday, but never today. La razón por la que la palabra software está entre corchetes es porque si sacamos esa palabra el comentario sigue teniendo sentido. La cita me hizo pensar en dos cosas que veo muy a menudo en organizaciones, áreas y hasta equipos de trabajo: A pesar de tener claro que los procesos deben ser trabajados o mejorados, se toma la cómoda posición de que en realidad los procesos son un problema de todos y por ende debería habe

¿Que pasaría si alguien viene y pone en duda la forma en que invierten su tiempo? Imagínense que lo hace alguien relevante para nosotros (por ejemplo un jefe o un empleador), que lo hace correctamente y que lo hace con motivos totalmente constructivos. ¿Es razonable enojarse u ofenderse? En mi opinión no. En todo caso es una pregunta valida sobre la que se puede reflexionar para luego responder. Si respondemos bien, convenceremos a la persona de que lo estamos haciendo bien y si no, tal vez el ejercicio nos aporte pistas de por qué está ocurriendo. Pero ¿cómo se responde? La respuesta tendrá que ser en términos de nuestras prioridades y el tiempo que dedicamos a cada una de ellas. Usamos bien nuestro tiempo si le damos más espacio en nuestro calendario a las cosas que son más importantes para nosotros y menos a las otras. Siguiendo con la idea, ¿cómo sabemos a que dedicamos el tiempo? Algunas personas registran sistemáticamente a que dedican su tiempo. Este hábito no es sencillo

En las últimas semanas he sido víctima de la impuntualidad en repetidas ocasiones y en distintos ámbitos. Nada terrible, unos minutos aquí, media hora allá y hasta cuarenta minutos en alguna. Tampoco voy a pararme en el olimpo de los dioses de la puntualidad que nunca llegaron tarde a ningún lado. Si bien suelo ser puntual, a veces puede fallar . Obviamente hay casos en que existe una razón que justifica perfectamente la demora pero en otros realmente no. Por ejemplo puede ser un caso aislado de alguien que accidentalmente se retrasó o puede ser un caso más de alguien que sistemáticamente llega tarde. Podría ponerme a analizar si llegar tarde está bien, mal, justificado o injustificado, pero la verdad es que quería reflexionar un poco en el otro lado:  ¿Qué me pasa a mi cuando alguien con el que tenía una reunión se retrasa (o peor, no viene)? Creo que pensar en el abanico de emociones por las que la víctima pasa (sí suena un poco teatral llamarla así, no?) no sólo le sirve a ella,