Así no se hacen las cosas por Ernesto Kiszkurno

.. que no queremos estudiar informática? Leí en estos días una nota en la nación que daba números sobre la cantidad de inscriptos a carreras duras y la verdad es que preocupan. He posteado algo aquí y aquí sobre esto y, a pesar de que se hacen cosas, no hay resultados. Digo que se hacen cosas porque el surtido de carreras terciarias y universitarias se ha ampliado, varias empresas han montado estructuras propias de capacitación especifica y se han implementado diversos programas de becas. Inclusive hay iniciativas de inclusión social relacionadas con el tema como En La Tecla . La ausencia de resultados tiene que ver con que el tema es complejo en si mismo pero también con que son temas que no admiten soluciones inmediatas o de corto plazo. No nos queda otra que seguir pensando...

Como parte de su evaluación en la materia que estoy dando en Exactas, los alumnos tienen completar un trabajo donde debían elegir un proyecto de su vida laboral, analizar su contexto, sus stakeholders, identificar problemas y proponer acciones de mejora. Corrigiéndolos me di cuenta que todos (los 9 trabajos) manifestaban que había problemas en temas relacionados con la comunicación. En un post anterior comenté que, en mi opinión, la comunicación es un factor clave para el éxito de un proyecto . Esto no es secreto y ha sido documentado en un sin fin de lugares. Resulta muy interesante ver una prueba tan clara del hecho, no? Seguimos pensando..

A lo largo de un servicio/proyecto puede generarse mucho material en forma de documentos, imágenes, infografías, videos o sencillamente datos, que debe ser gestionado, con el objetivo de no perder ningún conocimiento. Necesitamos entender de quién es la propiedad intelectual de cada pieza, para poder decidir dónde y cómo guardarlo. Así como también estudiar la política de gestión de la información vigente del cliente, para entender qué cosas deben conservarse y qué cosas deben destruirse. En caso de conservarse además será necesario entender en qué medio (papel, digital,  etc.). Seguimos pensando.. Foto de  mentatdgt  en  Pexels .  Todos los consultips juntos están  aquí .  Si queres leer el anterior podes ir  aquí . Si queres ir al príxomo podes ir aquí .

Extraigo de aquí el siguiente párrafo: "According to the PMBOK (Project Management Body of Knowledge) 3rd edition, A project is defined as a “temporary endeavor with a beginning and an end and it must be used to create a unique product, service or result” . Further, it is progressively elaborated. What this definition of a project means is that projects are those activities that cannot go on indefinitely and must have a defined purpose." Ya sea que estemos ante un servicio con principio y fin o uno de los denominados "continuos" que se mantienen en el tiempo con renovaciones por periodo, se trata de manejar las expectativas de nuestro cliente respecto al resultado a producir. Debemos gestionar expectativas, contexto, alcance y forma de trabajo. Gestionar en este caso también significa comunicar efectivamente cómo vemos las cosas para asegurarnos que el cliente las ve de la misma forma. Seguimos pensando..   Foto de  Anna Shvets  en  Pexels .  Todos los consultips j

El que crea que puede bajar a cero su cantidad de tareas pendientes no entendió nada. Siempre vamos a tener más cosas para hacer, cualquiera sea nuestro trabajo, nuestra profesión o nuestra situación. Más vale acostumbrarse a eso (y rápido).  Como decía en otro post podemos tener un día perfecto en el que hacemos todo lo que nos proponemos pero es eso, un día.  Por lo general siempre nos van a quedar cosas para después. Esto se debe a que, a medida que recorremos el día y vemos que estamos terminando todo lo planeado, nos invade un deseo irrefrenable de hacer más cosas. No basta con lo planeado, queremos más. Es como una ley de Murphy (si no lo es, debería serlo). Algo parecido a “no intente llegar a cero en su lista de pendientes, siempre se agregará algo más” Ok, hay gente a la que eso no le pasa. Bueno, voy a excluir de mi –muy opinable- generalización a esa pequeña e iluminada porción de la humanidad. En este punto la buena práctica es conocida, tratemos de evitar los agregados

Definición: Un día perfecto es un día en el que tachamos todas las tareas que teníamos previstas para él. Hipótesis: El día perfecto son los padres. Seguimos pensando..

Si bien en una contratación time and material la responsabilidad de definir objetivos y tareas es del cliente , eso es pan para hoy y hambre para mañana. Si él no logra lo que quiere estará molesto y nosotros habremos sido parte del problema. Para ser parte de la solución debemos interrogarnos acerca de para qué nos han contratado. Esto nos permitirá entender si las decisiones que el cliente está tomando son buenas y emitir alertas tempranas, dar una milla extra proponiendo ideas superadoras a sus planteos y distinguirnos de la enorme mayoría que sólo se contenta con seguir ciegamente lo que le dicen. Seguimos pensando.. Foto de  SHVETS production  en  Pexels . T odos los consultips juntos están  aquí .  Si queres leer el anterior podes ir  aquí .  S i querés ir al próximo podes ir  aquí .

Dicen por ahí que no tiene sentido gestionar el tiempo, sino que lo que hay que hacer es gestionar las prioridades . Yo comparto. Es bastante inocente pensar que en algún momento vamos a lograr terminar todos los pendientes. Tal vez en alguno de esos días raros logremos bajarlos a cero (ESE día), pero en el mediano largo plazo, no hay chances. Lo que sucede usualmente es que llegamos a un punto en el que estamos conformes con lo logrado ese día y bajamos la cortina hasta el siguiente. El punto de cierre del día . La idea de manejar prioridades es entender de antemano cuales son las cosas en las que debemos estar trabajando y trabajar en ellas principalmente (o exclusivamente), dejando que todo lo demás se filtre en los huecos que quedan. Gestionando prioridades, creo yo, llegamos a ese punto de conformidad sobre lo realizado en un determinado período más fácilmente. En lugar de dejar librado a la suerte cada día si lograremos hacer todo lo que “debemos” hacer (llegar al punto de c

El problema de estar en septiembre de 2021 completando con explicaciones consultips que escribí hace tanto tiempo (abril de 2012) es que se nos hace muy evidente el paso del tiempo. En aquella época había un contraste todavía marcado entre las empresas más "formales" que imponían el traje (o por lo menos el saco) y las más "modernas" que permitían una vestimenta más casual. En realidad todas decían que te permitían ir más casuales, pero en la práctica eso no ocurría. En un banco, por ejemplo, si ibas demasiado informal te miraban mal, la gente iba siempre de traje. Hoy esa discusión quedó obsoleta. En realidad ahora, pandemia mediante, ya no se discute cómo ir vestido a la oficina, sino que se pone en tela de juicio algo todavía más fundacional: ¿hay que ir a la oficina? Dicho todo esto rescato la idea de entender quienes son nuestros stakeholders (o interlocutores) para saber cuál es la mejor forma de relacionarse con ellos : virtual o presencial, presencial formal

(Update: Este post es parte de una saga que comenzó aquí ) Encontré en estos días un interesante post llamado Why you suck at estimating – a lesson in psychology que menciona 6 efectos que potencialmente podrían presentarse al momento de estimar: The “halo” effect Framing effects Overconfidence Attribute Substitution Base-rate neglect Anchoring Algunos están alineados con lo que se menciona en Cuando estimas, sos influenciable como por ejemplo el primero: The “halo” effect is defined as “the influence of a global evaluation on evaluations of individual attributes”. What this means in the realm of software development estimation is that you are likely to estimate the individual parts of a project with a bias towards how you feel about the overall project. De esto hablábamos al mencionar el campo de distorsión de la realidad aunque por ahí no quedó claro que nosotros mismos podemos generar las distorsiones (efectos 1, 3, 4, 5 y 6). Una conclusión que saco luego de leer e

Sabemos que el trabajo no sólo debe procurarnos incentivos materiales, se ha escrito mucho sobre esto. Además del dinero y los beneficios, hay otras variables en la ecuación como por ejemplo el clima laboral  y las oportunidades de crecimiento (es decir la posibilidad de ascender a puestos de mayor importancia o responsabilidad). Un tema más sutil, que no siempre se tiene en cuenta a la hora de pensar cuánto nos satisface nuestro trabajo, es el del desarrollo profesional . Es decir si el trabajo en el que estoy me permite mejorar, incrementar o perfeccionar mi arte, especialidad o conocimiento en general. Este punto es particularmente importante en las etapas tempranas de la carrera, donde buscamos explorar alternativas y formar una base de conocimiento.  Es común ver gente que acepta trabajar en peores condiciones de las que podría obtener en otros lugares con tal de "tener la experiencia de trabajar en" .  En el mercado laboral actual creo que no es necesario "tener qu

Queda "cool" decir que uno está pasado. Muchos lo toman como una muestra de "status". Yo en la mayoría de los casos lo veo como falta de capacidad para gestionar el trabajo que a uno le toca. Es cierto que podemos tener momentos de la vida laboral de mucho trabajo, en los que nos sentimos pasados, pero no podemos estar TODO EL TIEMPO pasados. O vamos camino a estrellarnos por estrés o estamos “posando”. Ninguna de las opciones es alentadora. Si nos escuchamos repetidamente diciendo "estoy pasado", reflexionemos. Seguimos pensando..

La matriz de Eisenhower es un marco de trabajo simple para priorizar las tareas y administrar la carga de trabajo. Es ampliamente conocido en el mundo de la productividad y fue ideada, obviamente, por  Dwight Eisenhower , ex presidente de los Estados Unidos. La traigo a colación en los consultips  porque en la vida del consultor es necesario priorizar constantemente . En nuestro día a día estamos permanentemente demandados por múltiples clientes y proyectos que no nos permiten aislarnos y mantener el foco en una única cosa por periodos muy largos de tiempo. Después de todo, estamos en el negocio de construir relaciones  y nos interesa mantener contacto con nuestra red . Si quieren una explicación más detallada de por qué es útil y cómo se usa, les recomiendo ir a esta nota en castellano de Dropbox . Seguimos pensando.. Todos los consultips juntos están  aquí .  Si queres leer el anterior podes ir  aquí .  Si querés ir al próximo podes ir  aquí .  Foto de  Brett Jordan  en  Pexels .

Estoy leyendo con mucho interés el libro de Walter Isaacson Steve Jobs . Como comentario general debo decir que me impresiona como una persona puede generar tantos sentimientos encontrados en simultáneo. Puntualmente hoy leí sobre un concepto llamado campo de distorsión de la realidad [1] que me pareció aplicable a las discusiones sobre estimaciones que he tenido con algunos colegas en las últimas semanas. Según Bud Tribble, Jobs era propenso a generar (o caer) en estos campos: “En su presencia, la realidad es algo maleable. Puede convencer a cualquiera de prácticamente cualquier cosa. El efecto se desvanece cuando él ya no está, pero hace que sea difícil plantear plazos realistas” Creo que cuando hablamos de estimaciones (y por consiguiente de planificación) en proyectos de desarrollo de software, esto ocurre [2]. Siempre aparece un stakeholder que arrastra al equipo de proyecto hacia uno de estos campos provocando sub-estimación de los tiempos y problemas. Esto a su vez empeo

Ver el post Compromisos . Re-Post en el Blog del consultip publicado en Twitter.

¿Por qué los desarrolladores de software complican tanto los diseños? He escuchado comentarios del estilo "Lo voy a hacer bien paramétrico. El modelo tendrá una meta-meta-meta estructura que va a permitirme controlar hasta..." y luego respuestas del usuario parecidas a "pero yo quiero algo simple y rápido, lo necesito para...". Al ser un diseño tan complejo, ¿No complica el mantenimiento? ¿No complica el entendimiento? ¿No complica la explotación de la información del sistema? Algo que siempre me ha gustado de Apple es su búsqueda de lo simple. Se puede leer en el libro de Walter Isaacson, Steve Jobs , que era algo premeditado. Sí, ok, es cierto que posiblemente lo que se ve simple desde afuera, no lo fuera tanto dentro pero aún así la idea de simplicidad en diseño es importante. Tal vez no es que complican tanto los diseños sino que no diseñan en lo más mínimo. En Why software sucks , Scott Berkun puntualiza el dilema entre construir y diseñar. Good arch

A veces no podemos o no sabemos cómo para ayudar a un cliente. Tenemos una relación con él y es importante para nosotros ayudarlo pero sabemos que no podemos. En esos casos es mejor hablar francamente y decirlo. Ya habrá oportunidades de trabajar juntos. Seguimos pensando.. Todos los consultips juntos están  aquí . Si queres leer el anterior podes ir  aquí . Si querés ir al próximo podes ir aquí . Foto de  cottonbro  en  Pexels .

Siguiendo la saga que comenzó aquí , hoy quiero dar una lista incompleta de los problemas derivados de la sobre-estimación y de la sub-estimación. Sobre-Estimación Se asignan y usan más recursos de los necesarios. El proyecto cuesta más de lo que debería. Se pierden oportunidades de poner recursos en otros proyectos. “Toda tarea se expande hasta ocupar el tiempo asignado a ella” (Ley de Parkinson). Goldratt’s “Student Syndrome” (Goldratt 1997). McConnell: ”If developers are given too much time, they’ll procrastinate until late in the project, at which point they’ll rush to complete their work, and they probably won’t finish the project on time”. Sub-Estimación: Se dimensiona mal el equipo de trabajo (y genero sobre esfuerzo). Tenemos menos tiempo para temas de QA y QC. El cronograma resulta corto, poco creíble y pierde sentido a medida que el proyecto avanza y los hitos no se van cumpliendo. Resiente la motivación del equipo. Puede resultar en una base técnica pob