Así no se hacen las cosas por Ernesto Kiszkurno

http://www.flickr.com/photos/nhanusek/   Son varios los autores que confluyen en la idea de que una buena manera de administrar nuestro tiempo es manejar todas nuestras actividades como proyectos. Cuando todo es un proyecto es posible pensar que tenemos una cartera de proyectos donde: nuestras tareas están enmarcadas en proyectos, nuestros proyectos son ejecutados en función de objetivos y nuestros resultados pueden ser medidos y mostrados Pensando en nuestra cartera de proyectos es posible: Evaluar si contiene los proyectos correctos (por ejemplo aplicando técnicas de project portfolio management – muy nerd, no?). Decidir si es interesante para nosotros (desde el punto de vista de nuestros gustos) y también para otros (desde el punto de vista de nuestro Personal Branding ). Analizarla en un marco temporal determinado y sacar conclusiones : proyectos comenzados en el periodo vs. terminados, proyectos de este año vs. proyectos del año próximo, proy

Hay momentos en los que sentimos que la realidad nos supera. Tenemos una gran cantidad de cosas para hacer y no sabemos por donde empezar. Cosas de todos los tamaños, gustos y colores. En esos momentos uno siempre se acuerda del consejo que muchos gurúes de la gestión del tiempo dan: Primero las piedras! Haciendo referencia a la idea de que para acomodar un montón de piedras y arena en un cajón, primero conviene poner las piedras y luego la arena puesto que de esa forma todo se acomodará mejor. Pero lo que en la teoría funciona bien, a veces en la práctica se vuelve difícil de implementar. En medio del baile, las piedras grandes parecen enormes y uno se acobarda de tal forma que termina dedicándose a la arena. Sean fuertes, hagan foco en alguna de las grandes. David Allen dice “piensen cuál es la tarea pendiente que, una vez realizada, les produciría la máxima satisfacción interior y háganla” . Y yo completo. La satisfacción que se siente luego de habernos sacado de encima una tar

Ya van varias oportunidades en las que me encuentro respondiendo a esta pregunta y se me ocurrió que tal vez postearla tenga sentido. Por supuesto que haciendo honor al estilo “bloguero” lo haré en forma de “4 razones”: #1 Escribo porque me gusta Primero que nada escribo para mí. Siempre me gustó escribir pero no tanto mostrar lo que escribía. A partir de eso, escribir era un “some day/maybe” (chiste nerd de GTD) que posponía sistemáticamente hasta que un día encontré que escribir un blog era una forma razonable (en tiempo y neuronas) de “despuntar el vicio”. #2 Escribo para iniciar conversaciones Lo que escribo en el blog es para compartir. Los mercados son conversaciones dice el Manifiesto ClueTraing . A partir de esto decidí probar y realmente se generó algo que al día de hoy no deja de sorprenderme: la gente responde. Algunos tímidos con un mail o un comentario de pasillo, otros que lo son menos en Facebook , en el blog , en Twitter o en Google Buzz . Encuentro sumamen

Es muy común encontrar en grupos de trabajo, organizaciones o directamente en la blogósfera, gente dispuesta a sostener discusiones del estilo “las certificaciones son buenas o malas” o “las certificaciones sirven o no sirven para nada”. A mi entender la discusión, así planteada, no tiene sentido . Estamos pidiéndole demasiado a la idea de certificaciones, buscamos una bala de plata donde no la hay (como muchas veces en informática). Con el objetivo de precisar mi punto de vista, a continuación presento un decálogo de afirmaciones. No garantizan resultados. Malos resultados pueden ser producidos por personas o empresas certificadas. No miden experiencia, miden conocimiento. Son un mecanismo de screening , que intenta resolver la asimetría de información existente a priori entre dos agentes. Sirven para marcar diferencias. No permiten seleccionar al mejor candidato para un determinado trabajo. Tal vez ayuden a encontrar uno suficientemente bueno. No son un mecanismo pe

Me encuentro participando de SCORE 2011, un concurso de ingeniería de software destinado a promover la temática entre las universidades del mundo. Extraigo de la página una breve descripción: ICSE 2011 in Hawaii will see the second finals of the SCORE Software Engineering Contest. Teams from all over the world will take part in a competition that is open to students from undergraduate to master's level. Each team will develop a system chosen from a list and monitored by a committee member. The final deliverable is a report and accompanying system. Evaluation will be based on the quality of all aspects of the software engineering process followed, as well as the outcome. In order to accommodate a wide range of academic calendars, the SCORE 2011 Contest will run from February 2010 to January 2011, with team registration ending in November 2010 and project submission starting in February 2010. A small number of finalist teams will be announced in March 2011. El proyecto que hemos

Tiempo atrás escribí aquí sobre el fenómeno de comoditización que observo en el testing como actividad dentro del desarrollo de software. A continuación enumero 5 indicios que apoyan mi sospecha: #1 Los precios están uniformizándose La selección de un proveedor se realiza vía licitaciones y en ellas se gana o se pierde por una diferencia mínima en lo económico. La aprobación técnica se transformó en una condición de mínima que todos ellos deben lograr para acceder a la batalla por el precio. #2 Los clientes están plenamente informados Conocen el servicio a comprar, cómo evaluarlo y quiénes son los proveedores/jugadores principales del mismo. Ya hay parámetros de calidad mínima (como los llama Enrique Dans en este post de su blog) que indican si un proveedor califica o no. #3 El servicio se ha "indiferenciado" La capacidad que tenían ciertos proveedores para ofrecer "algo distinto" ha disminuido notablemente. Luego de 30 años de maduración, no hay bala

SAP, como cualquier otro producto customizable que se implanta en una organización, requiere actividades de control de calidad. Implementar significa generar código y también configurar el producto de determinada manera. Así, las actividades más comunes de control resultan ser el testing y las revisiones de código. Dejando para otro post el tema de las revisiones de código SAP, me concentro en el testing funcional. Las pruebas más técnicas como ser estrés o volumen no tienen, a mi entender, particularidades surgidas del hecho de que SAP sea el objeto a testear. Cuando hablamos de testing funcional en implementaciones SAP, hay dos estrategias a seguir. La primera es hacer que los analistas funcionales realicen el testing una vez terminada la customización de los procesos. Esta estrategia, como todas, tiene pros y cons. Del lado de los pros tenemos que los analistas Conocen perfectamente la funcionalidad, Conocen a los usuarios y Conocen el ambiente y los datos requeridos para hac