Así no se hacen las cosas por Ernesto Kiszkurno

Podría ser más duro y decir que toda reunión de trabajo debe minutearse pero sé, por experiencia propia, que eso es muy difícil de cumplir. Por eso me voy a quedar con algo un poco más sencillo.  Tomemos nota de lo que pasó en la reunión.  Aunque más no sea para nosotros mismos. Luego, cuando reflexionamos sobre nuestro día podremos recordar qué pasó, a qué nos comprometimos y qué tareas tomaron otros.  Si van a hacerlo digitalmente, avisen y pidan permiso. Hay gente que podría ofenderse por escuchar el ruido de nuestro teclado en la call o ver que estamos mirando a la computadora mientras nos reunimos, cuando es presencial. Podrían sentir que no estamos prestando atención. Si lo hacen analógicamente, traten igualmente de no sumergir la mirada en sus notas y cada tanto hacer contacto visual. 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  Judit Peter  en  Pexels .

En estos días llegó a mis manos un estudio sobre estimaciones en el que se muestra cuán influenciables somos a la hora de estimar. Thomas, quien publicó el estudio en su blog el próximo paso , cierra su post con la siguiente conclusión: En resumen, si queres que tus proveedores estimen menos horas, mandale una especificación corta, diciendo que el sistema a reemplazar se desarrollo con muy poco esfuerzo y tirándoles expectativas de esfuerzo y duración muy bajos ;o) Conociendo a Thomas, sé que es un comentario irónico, pero me preocupa que alguien tome en serio el consejo. En Teoría Económica y Outsourcing hablé de fenómeno de selección adversa y del peligro que corren los compradores de servicios de desarrollo al momento de establecer las condiciones de contratación para sus proveedores. Como clientes, tendremos los proveedores que nos merecemos sería la conclusión allí (ver también el post Descuento ). El truco de "influenciar negativamente” las estimaciones de nuestros pr

"Quién hace qué para cuándo". Hace años aprendí esta frase en algún lado, ya no recuerdo donde, y me ha servicio siempre. No sólo para el ámbito de la consultoría. Sirve para ordenar una reunión, para ordenar una crisis o para coordinarnos en cualquier equipo que nos toque formar.  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  Startup Stock Photos  en  Pexels .

(este post es parte de una saga que comenzó aquí y siguió aquí ) La estimación y el plan no son lo mismo . Creer que sí es un error común a la hora de planificar un proyecto de software. Son temas muy relacionados pero no son lo mismo. Mientras la idea de estimar es entender cuánto cuesta, en términos de esfuerzo, construir un determinado software, el objetivo del plan es mostrar la forma en que cumpliremos un determinado objetivo . Por ejemplo el de entregar (en producción funcionando) un determinado software, para una determinada fecha y con un determinado nivel de calidad. El plan compromete fechas, la estimación no. El plan necesita una estimación sobre la que basarse pero hay tareas que no tienen que ver con construir el software y que muchas veces el equipo de proyecto desconoce o subestima [1]. Es por esta razón que muchas veces, además de la mirada de desarrollo, se requiere una mirada que vaya más allá. Si el líder del proyecto la tiene, excelente; y si no, hay que comple

Saqué el término slideuments de un libro de Nancy Duarte llamado Slide:ology  (2008) sobre el que hablé aquí  y aquí , aunque creo que el término originalmente es de Garr Reynolds. El slideument es una presentación que tiene tanto pero tanto texto que en realidad parece más un documento.  Está bien escribir documentos, sirve el resultado de ese proceso (lo escrito) y también el proceso en sí mismo (pensar en qué escribir). El problema está en que lo que es útil para una cosa, no siempre es útil para otra. Los documentos tienen detalle, son exhaustivos y necesitan ser leídos. Si además son piezas técnicas necesitamos concentrarnos y no nos sirve que alguien hable encima.  Si lo que queremos es presentar una idea hablándole a cierta gente, queremos que la presentación ayude y complemente lo que decimos. Por eso reducimos la cantidad de detalles y usualmente tratamos de usar más imágenes que texto. Tengamos el objetivo antes y decidamos en función de eso qué necesitamos. Seguimos pensando

Luego de un primer post sobre el tema, sigo desarrollando. En el libro Software Estimation (Demystifying the black art) , Steve McConnell plantea una distinción crucial que de hecho ha despertado discusión con algunos colegas en Google Plus: “Here is a dictionary definition of estimate: 1. A tentative evaluation or rough calculation. 2. A preliminary calculation of the cost of a project. 3. A judgment based upon one’s impressions; opinion. (Source: The American Heritage Dictionary, Second College Edition, 1985.)” … “Strictly speaking, the dictionary definition of estimate is correct: an estimate is a prediction of how long a project will take or how much it will cost. But estimation on software projects interplays with business targets, commitments, and control .” Según el autor un objetivo es “..a statement of a desirable business objective.” Y respecto a un compromiso: “While a target is a description of a desirable business objective, a commitment is a promise to deliver

Foto de  Ann H  en  Pexels Hemos dicho que lo importante es crear relaciones ( consultip 9 ). Comprometernos con un servicio que no vamos a poder dar, atenta contra esa relación. Es preferible dejar pasar una "oportunidad" en pos de mantener la relación sana y la confianza intacta. Los clientes se van a acordar de esas veces que les dijimos que NO, lo sé por experiencia. La relación se construye sobre la base de NO oportunos y sinceros. 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í .

El objetivo de este post es contestar la pregunta ¿por qué necesitamos fechas en un proyecto de desarrollo de software? Y empiezo por dar los tres motivos principales por los que desarrollamos software: un grupo de usuarios lo necesita, una organización pretende comercializarlo o para nosotros mismos (que podría ser pensado como un caso especial del primero). Es decir que desarrollamos software para satisfacer una necesidad de alguien y por consiguiente ese alguien va a querer saber dos cosas. La primera es cuánto costará hacer el software y la segunda es cuándo estará disponible. Ambas informaciones están íntimamente relacionadas y para obtenerlas necesitamos hacer un ejercicio de estimación. De esto se desprende que estimar no es un fin en si mismo, sino un medio para poder establecer cuánto y cuándo. Pero ¿por qué el que necesita el software quiere saber cuánto y cuándo? Pues para poder tomar decisiones del estilo ¿Vale la pena construirlo o compro algo hecho? ¿Le pido a XX o a

Mi post sobre compromisos causó algo de revuelo en Google Plus. Bienvenido! Por un lado la conversación se deslizó hacia una discusión sobre "los que piden" y los que "hacen". Como si los que piden nunca debieran hacer y los que supuestamente hacen nunca pidieran. Se quiso plantear una discusión del estilo patrones/empleados o burócratas/técnicos. Este no era el espíritu buscado y sinceramente, en el tema compromisos, no creo que tenga sentido plantearlo de esa manera. La única persona que he visto que tiene un trabajo sin compromisos es Wally (el de Dilbert), todos los demás trabajamos en organizaciones donde cumplimos un rol y tenemos derechos, obligaciones y responsabilidades. Por otro se planteó el dilema sobre si es posible, en desarrollo de software, estimar con precisión y comprometer fechas respecto a las entregas de cierto software . Este sí es un tema interesante para debatir y pretendo aquí iniciar esa discusión. En lo que a mi respecta, si bien soy

Foto de  fauxels  en  Pexels Tenemos varias maneras de marcar hitos en nuestros proyectos. Podemos enviar correos, hacer llamados y hasta manejar la presencia física en oficinas del cliente, pero no hay como las reuniones de inicio o fin de proyecto. Quedan registradas en el calendario y por consiguiente grabadas en la memoria de una manera distinta. Son verdaderos momentos de verdad que tienen otra tensión y otro registro. Muchos consultores viven esos momentos como un problema o un obstáculo. Para mi son una herramienta para comunicar, pasar mensajes y mostrar ciertos resultados o análisis. 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í .

Uno de los desafíos más grandes a la hora de llevar adelante grandes proyectos de construcción de software es lograr integrar fluidamente las distintas partes en las que seguramente hemos dividido su construcción. Hace muchos años me encontraba formando parte de un equipo de desarrollo numeroso que estaba abocado a construir un sistema en Java destinado a manejar la actividad “core” de la empresa. La construcción del sistema se estaba haciendo, obviamente, por partes y el responsable de todo el desarrollo había repartido entre distintos equipos la construcción de los módulos funcionales.  Mi rol no era de desarrollo sino que estaba manejando temas de gestión del proyecto y testing.  En un determinado momento, la construcción aislada de cada uno de los "silos" iba sobre ruedas (o inclusive más rápido de lo previsto) pero yo comencé a preocuparme por la integración de todas esas partes. Veía demasiado ensimismados a los grupos de trabajo y prestando muy poca atención a cómo ib

"Cuando hay aviso, no hay traición" dice la sabiduría popular. Los servicios se diseñan a medida que se van dando. Eso, que en cierto sentido es un problema, también puede ser una bendición. Cuánto más y mejor comuniquemos por donde vamos, antes sabremos si el cliente no está conforme y necesitamos cambiar algo. 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  Andrea Piacquadio  en  Pexels .

Siguiendo con la saga de lo obvio.. aquí va un pequeño feedback para alguno de por ahí. Cuando te comprometes con X a hacer algo para cierta fecha (que vos definiste) y no cumplís, lo que pasa es que X pierde confianza en vos. Si X es alguien que vos lideras, su motivación y compromiso van a caer. Si X es un par, cuando la cosa sea al revés no te va a ayudar. Si X es tu jefe, bueno ... tampoco va a ser algo bueno. Seguimos pensando.. PD. Primero este post tuvo una segunda parte  que vale  pena leer porque la cosa se puso picante. Segundo, para los que vengan de los consultips. 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  fauxels  en  Pexels .

Hoy hay una competencia feroz por nuestra atención en diversos órdenes de la vida. Tener la capacidad de resguardarnos de ese mundo y concentrarnos en lo que tenemos que hacer es casi un superpoder. Nos permitirá entrar en un estado flow  que no sólo nos hará llegar más rápido al resultado deseado sino que nos hará más felices en el camino. Una de las formas de resguardarnos es apagar cualquier notificación que tengamos en la computadora y/o el teléfono. 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í .

Hoy, como todas las semanas, me llegó un mail de LinkedIn con los artículos “top” de la semana. Uno de ellos, 5 Reasons You Need to Meet in Person , me hizo reflexionar. ¿Recuerdan la escena de la película Wall-e donde las personas de la nave estaban a un metro y se comunicaban mediante pantallas? Luego de haberlo leído no me quedaba claro si preocuparme por el hecho de que todavía sea necesario explicarle a la gente que es mejor verse en persona que virtualmente (no es obvio?) o ponerme contento por el hecho de que esta nota tenga tantas lecturas (es decir que más gente pondrá en práctica el consejo). Seguimos pensando.. PD: Respecto al artículo puedo decir que comparto 4 de las 5 razones (la 4ta razón tiene que ver con “impresionar” al cliente usando una valija rosa).

No sé ustedes pero por aquí, en casa, hay mucha gente viendo Masterchef Celebrity Argentina. Una situación desafortunada para mí obviamente porque he tenido que verlo. Pero como en la vida "nada se pierde, todo se transforma", hay enseñanzas para la consultoría inclusive allí. Una de las cuestiones importantes en el programa es la presentación de los platos. "Emplatar" es todo un tema y, más allá de si está rico o no lo que cocinaste, que este bien presentado es crucial para el jurado. Es parte de la evaluación. En la consultoría pasa lo mismo. Los entregables sí importan y vigilar su presentación es crucial.  Cómo decimos lo que decimos o cómo presentamos las cosas, son cuestiones sobre las que debemos prestar atención. Hallazgos importantes mal comunicados pueden ser lapidarios para nuestra evaluación final. Quedarnos sin tiempo para "emplatar", es decir, trabajar adecuadamente la presentación de nuestros resultados, es un error grave de planificación. I