Así no se hacen las cosas por Ernesto Kiszkurno

Para hoy les tengo uno largo. Una hora. Perdón! En cualquier caso, creo que siempre es interesante escuchar a uno de los Avengers . De paso comento, la lista de charlas que Google ha ido publicando a lo largo de los años merece ser revisada porque hay algunas que son excelentes. Seguimos pensando..

Hace unos días recibí un comentario de un amigo que me pareció interesante.  Decía que "hay una marcada necesidad en los productos de software (estilo dropbox, facebook, skype, etc) de mostrarse en constante actualización" y también que en muchos casos eso es malo porque hace perder a los usuarios confianza en el producto.   De hecho, a esta altura ya se lo notaba enojado, decía que deberíamos pensar en un consultip que dijera "no actualice en vano" (aquí entre nos, él lo decía de otra manera pero yo elegí copiar a Dolina en la forma de escribirlo). Lo primero que pensé es que no todos piensan así. Por ejemplo, la gente de 37signals piensa tan distinto que en su libro Getting Real , que mencioné en este post, dicen que hay que “construir menos”. Tienen un apartado llamado así donde dicen: Conventional wisdom says that to beat your competitors you need to one-up them. If they have four features, you need five (or 15, or 25). If they’re spending x, you need to spe

Siempre sostengo que la parte más difícil del trabajo en proyectos es interactuar con gente . Cada persona es diferente y lo que sirve en la comunicación con uno, no necesariamente sirva con otro. Si acuerdan conmigo que esto es así, estarán de acuerdo también que cualquier herramienta que nos permita entendernos y comunicarnos mejor con las personas es útil. Dicho esto, les presento DISC . Una herramienta de evaluación que nos permite entender ciertas características generales de las personas de modo de poder hacer más efectiva nuestra interacción con ellos.  Fíjense que me cuido de decir que nos permite clasificar a las personas, no quiero entrar en esa discusión. Mi motivación aquí es bien práctica: cuanta más información tenga sobre cómo relacionarme con alguien, mejor podré hacerlo . El modelo involucra dos ejes y cuatro aspectos de comportamiento a “testear”. Muestro a continuación un buen resumen de la gente de Manager Tools : Y ¿de qué forma utilizo esto en la vida cotidian

Gran regla de Fred Brooks, extraída del libro The Mythical Man-Month . Seguimos pensando.. Todo s  los consultips juntos están  aquí .  Si queres leer el anterior, podes ir  aquí .  Si queres ir al próximo podés ir  aquí .

Les dejo una charla de Mihaly Csikszentmihalyi sobre el "fluir" (gracias Maxi!). Él la encara desde la perspectiva de la felicidad. Digamos desde un costado romántico. Más allá de la felicidad, lograr un estado de fluir permite lograr las tareas con mucho menor esfuerzo. Dejo también una referencia de Peopleware, donde es posible verlo desde una perspectiva más utilitaria, más práctica. "During single-minded work time, people are ideally in a 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 time: "I began to work. I looked up, and three hours had passed." There is no consciousness of effort; the work just seems to, well, flow. You've been in this state often, so we don't have to describe it to you. Not all work roles require that you attain a state of flow in order to be productive, but for anyone involved in

En el libro Code Complete , Steve McConnell dice: Managers of programming projects aren’t always aware that certain programming issues are matters of religion. If you’re a manager and you try to  require compliance with certain programming practices, you’re inviting your programmers’ ire. Here’s a list of religious issues: Programming language Indentation style Placing of braces Choice of IDE Commenting style Efficiency vs. readability trade-offs Choice of methodology—for example, scrum vs. extreme programming vs. evolutionary delivery Programming utilities Naming conventions Use of  gotos Use of global variables Measurements, especially productivity measures such as lines of code per day ¿Están de acuerdo? ¿Descartarían alguno? El libro es de 2004, de modo que algunos se quedaron viejos directamente pero otros son claramente objetables. Hago mi lista de objetables: Indentation style Placing of braces Choice of IDE Programming utilities Naming co

Todos conocemos la triple restricción de un proyecto: Alcance, Costo y Calendario. La teoría dice que cualquier acción sobre uno de ellos, automáticamente se ve reflejada en los otros. También sabemos de la teoría que no hay una única forma de operar sobre ellos y dependiendo del contexto organizacional y del proyecto. Pero no todos están de acuerdo en que la respuesta a cómo operar con la triple restricción es depende . Los fundadores de la empresa 37signals en su libro Getting Real sostienen que lo mejor es “Fix Time and Budget, Flex Scope” En particular sostienen que If you can’t fit everything in within the time and budget allotted then don’t expand the time and budget. Instead, pull back the scope. There’s always time to add stuff later – later is eternal, now is fleeting. Launching something great that’s a little smaller in scope than planned is better than launching something mediocre and full of holes because you had to hit some magical time, budget, and scope window.

Debemos ir al lugar donde daremos nuestra presentación antes.  Eso nos permitirá, entre otras cosas, verificar que el tamaño de letra es adecuado, que los colores van bien con la iluminación, si necesitaremos micrófono, etc. Si no lo hemos visto, corremos el riesgo de tener que presentar incómodos. Seguimos pensando.. Todo s  los consultips juntos están  aquí .  Si queres leer el anterior, podes ir  aquí .  Si queres ir al próximo podés ir  aquí .

Así es como logré pasar todos mis CDs a iTunes.. No sirve para cualquier tipo de proyecto, pero para algunos sirve. Seguimos pensando..

Hay gente a la que llamo "enablers". Es gente que facilita las cosas, que permite mantener el ritmo del proyecto o de la tarea en cuestión. La interacción con ellos siempre te vigoriza. El ritmo de trabajo se mantiene o inclusive se incrementa. Hay otro tipo de gente a la que llamo "stoppers". Estos ponen peros, objeciones. Lo hacen todo el tiempo y por ello suelen drenar energía en cada interacción. Con ellos el ritmo se corta permanentemente. Definidos ambos grupos, es obvia la elección. Es preferible trabajar con enablers y no con stoppers. Pero a veces la cosa no es tan fácil. La gente no es 100% de una forma o de otra, tiene momentos matices, etc. Seguramente todos tenemos algo de stoppers, estemos atentos. A veces es difícil romper ciertos estereotipos una vez que están instalados. Lo digo por experiencia.. Seguimos pensando..

En un interesante artículo llamado Culture Clash: When Corporate Culture Fights Strategy, It Can Cost you , donde se presentan los resultados de la investigación de Angelo Kinicki, se definen 4 tipos de culturas pensando en dos ejes de trabajo: Foco Externo o Interno Flexibilidad vs Estabilidad y Control A continuación el resumen de las características de cada uno: Internally focused Externally focused Flexibility and Self-discretion "clan" culture Colaboración y trabajo en equipo. Inversión en el desarrollo del empleado. Como resultado los empleados tienen un alto nivel de moral y compromiso. "adhocracy" culture La meta principal es crear. Se alienta la adaptabilidad, la creatividad y la agilidad. Como resultado se logran altos niveles de innovación. Stability and Control "Hierarchy" cultures Foco en el control. Esto se logra mediante una fuerte orientación a proceso y resultado. &q

No es posible sobrevivir en una organización sin adaptarnos a los rituales y estilos que ella tiene.  Les pongo un ejemplo, si estamos en una organización donde se hace un uso intensivo del mail (para comunicar cosas, pedir o encargar tareas, discutir y hasta tomar decisiones), no podemos darnos el lujo de no responderlos o no leerlos. Básicamente estamos quedándonos aislados y eso, tarde o temprano, nos va a perjudicar. Seguimos pensando.. Todo s  los consultips juntos están  aquí .  Si queres leer el anterior, podes ir  aquí .  Si queres ir al próximo podés ir  aquí .

Buen discurso. Un poco de humor, un poco de seriedad. No lo tenía a Bernake en este tono. Seguimos pensando..

No me gusta el término Analista Programador ( Analista Funcional sí, ya lo dije). Más bien me irrita. Me parece que se queda a mitad de camino. Lo veo como  una cruza incompatible en realidad.  En mí experiencia, cuando hablamos de gente trabajando en proyectos informáticos, podemos clasificar a las personas en dos grandes grupos. El primero es el de las personas que tienden a pensar el software desde el punto de vista más funcional. El segundo es el de las que lo hacen desde el punto de vista técnico. La gente con tendencia funcional (si podemos llamarlos de esa forma) tiende a pensar naturalmente las reglas de negocio que el software implementa, a capturar rápidamente el lenguaje apropiado para ese dominio del problema y se entiende con los usuarios de maravilla. La gente con tendencia técnica , por el contrario, se inclina hacia el equipo de desarrollo, maneja -o adquiere- la jerga del equipo técnico y es propensa a desarrollar capacidades (skills) relacionadas con la programación

El 23 de mayo empecé a dar clases en UADE. Se trata de la materia Desarrollo de Sistemas en la Maestría en Dirección Estratégica de la Información (CIO). Muy contento con la convocatoria y el desafío de volver a dar clases en posgrado. Seguimos pensando..

El otro día encontré este post en el blog de Lucas Limbrunner . En particular me gustó este párrafo: “Existen muchas técnicas que podemos utilizar para salir del aburrimiento laboral y comenzar a amar lo que hacemos. “A nadie le gusta sentirse inútil o emplear su vida entera en algo que no le interesa en absoluto” señalan Rothlin y Werder. Se puede engañar a los demás, pero el punto crucial es cuando uno mismo asume que no quiere seguir frustrándose en interminables horas de tedio improductivo todos los días. Un acto de afecto hacia uno mismo es comenzar a buscar una salida y empezar a desarrollarse profesionalmente buscando desafíos que estén a la propia altura. ” Seguimos pensando.. Todo s  los consultips juntos están  aquí .  Si queres leer el anterior, podes ir  aquí .  Si queres ir al próximo podés ir  aquí .

Un interesante resumen de uno de los pasajes de su último libro . Así como House decía “todos mienten”, Dan Pink dice “Todos vendemos, aunque no nos demos cuenta”. Seguimos pensando..