Así no se hacen las cosas por Ernesto Kiszkurno

Ya decía yo que había que ser curioso pero según el libro The Pragmatic Programmer , aparentemente, este pibe Benjamín Franklin lo estaría diciendo también. Seguimos pensando..

La calidad de video no es buena y el subtitulado en inglés es peor pero no pueden perderse estos 15 minutos de charla entre dos próceres de la tecnología. Seguimos pensando..

El arquitecto hoy debería ser como el Chief Programmer de Mills de hace 40 años. Alguien que con su experiencia multiplica el trabajo de los demás. Los capacita, los ordena, los orienta, inclusive se sienta a programar las partes sensibles del desarrollo si es necesario. En definitiva, alguien que hace mejor a todo el equipo. Desgraciadamente a veces te encontras con que el arquitecto es un ser oscuro que sólo opina sobre todo lo que otros están haciendo mal o sobre lo que “debería haberse hecho”, sin poner un dedo en el teclado. Seguimos pensando..

No existen los entregables que sólo verán pocas personas o por lo menos no podemos asumir que eso ocurrirá. Cuando generamos un entregable debemos pensar en el peor caso y asegurarnos que tenga todo lo necesario para sobrevivir. Sólo por nombrar algunas cosas debería estar bien escrito (tanto la sintaxis como el contenido), tener un propósito claro, cuidar la estética y tener una estructura razonable. Aún en los casos en que es una versión preliminar o un borrador para discusión debemos aclararlo. De forma tal de que si el entregable viaja a manos que no tienen contexto, el documento podrá defenderse aclarando que en realidad fue una versión preliminar, armada en 15 minutos, en notepad y con una sola mano. Seguimos pensando..

Por un lado, es conocido el hecho de que hay importantes diferencias de productividad entre las personas que desarrollan software. Se han hecho diversos estudios que lo demuestran [1]. Por otro lado, tenemos una discusión instalada desde hace años entre los que piensan que desarrollar software tiene más que ver con lo artístico, lo artesanal o lo innovador, que con lo ingenieril y lo exacto. A los fines prácticos, a mi me alcanza con decir que no da lo mismo quien le pega al teclado a la hora de desarrollar software. No es lo mismo martillar que saber dónde martillar . Entonces, y aquí va mi pregunta, ¿por qué las empresas todavía contratan software por valor hora? ¿Por qué sabiendo que desarrollar software es una actividad en la que importa quién lo hace y cómo lo hace, se empeñan en nivela para abajo y elegir por precio? ¿Serán las áreas de Compras las culpables? Seguimos pensando.. [1] Para aquellos que quieran conocer un poco más sobre diferencias de productividad, pueden arran

Extraído de Busy is an Addiction : “As an industry, we’ve created an impressive amount of institutionalized drama around getting things done. In large companies, we’ve got armies of people whose job it is to make sure that we understand the importance of that critical deadline. We’ve got leadership motivating us by telling us someone is going to eat us , so we better hurry . There are important people who’ve invested their money and are eager to see a return on their investment. We are surround by stimuli built to drive us harder and faster. My advice is not that we should eagerly and fervently build the next thing, my advice is to constantly take the time to stop and understand the true nature of your busy.” Seguimos pensando..

La tecnología facilita muchas cosas pero también nos pone en peligro. Así puede verse en esta ingeniosa publicidad de Volkswagen. Seguimos pensando..

Dijimos que una de las razones por las que se contrata consultoría es desconocimiento . De hecho, uno de los principales argumentos de venta del consultor es yo ya lo hice en (o lo conozco de) otro lado. Si esto es cierto, no entiendo por qué tantos consultores arrancan de cero a trabajar en sus proyectos. Saltan directo de la propuesta al cliente sin paradas previas. El consejo es tomarse el tiempo de recolectar internamente material relevante para el servicio y entrevistar gente que pudiera tener pistas de cómo encargar el proyecto/servicio con menor incertidumbre. A veces esto no es posible porque el proyecto es realmente nuevo, pero en mi experiencia la mayoría de las veces hay cosas ya pensadas, personas que ya tuvieron ese problema y enfoques validados. No nos perdamos la oportunidad. Seguimos pensando..

Creo que todos podemos estar de acuerdo en la colaboración a lo largo y a lo ancho de la organización es cada día más importante en el mundo de los negocios. Inclusive, la colaboración no termina en los límites de nuestra organización, sino que sigue hacia afuera, con nuestros clientes y proveedores. Dicho esto, ¿hay alguien en su empresa pensando en esto? ¿Hay alguien preocupado por hacer más fluidas las interacciones entre áreas, proyectos, procesos e individuos?  Debería haber un CCO, no? HBR piensa que sí . Alguien así en la organización podría: Pensar qué herramientas facilitarían las interacciones. Definir o redefinir protocolos entre áreas. Precisar procesos ambiguos, poco claros o inexistentes. Evaluar periódicamente si el status quo es el adecuado. Trabajar con diferentes equipos para ayudarlos a resolver sus cuellos de botella. Etc. La colaboración debería ser una responsabilidad de todos pero como decía Humphrey en Managing the Software Process : “The problem

En algún lugar del mundo, un diálogo así podría estar ocurriendo: - Hola quería reunirme con vos por una situación que está dándose en estos días. Tu empresa está internalizando a uno de los consultores que nosotros hemos puesto para darte servicio. --dice el proveedor. - Sí, es cierto. Estamos internalizando a Juancito. Es alguien muy capaz. Ustedes son muy buenos seleccionando gente. --dice el cliente. - Es una de nuestras fortalezas, encontrar gente con la actitud correcta y potenciarla con inversión capacitación y formación. Se nos hace muy difícil mantener el nivel de servicio cuando ocurren estas cosas. - Bueno, es política de nuestra empresa incorporar, cuando hay vacantes, a aquellas personas que nos parece que pueden sumar dentro de la compañía. Seguramente sigamos haciéndolo. La situación descrita deja mucha tela para cortar y analizar: ¿Está bien que el cliente haga eso con el personal del proveedor? ¿Debería avisar antes de contratar? ¿Qué protocolo debería segui

Un producto muy interesante para aquellos amantes de la tecnología y el medio ambiente. La nota de color es que el producto fue diseñado por gente de córdoba . Les dejo el video de promoción. ¡Me mata que se lockea cuando uno se aleja de la bici! Seguimos pensando..

A veces los clientes creen que los proyectos o servicios no marchan bien. Tienen la sensación de que no estamos aportando suficiente valor, tienen dudas, tienen comentarios, tienen objeciones. En esos casos es nuestro deber escuchar y tratar de mejorar lo que está funcionando mal o de explicar lo que no se entiende bien o de comunicar mejor los “por qué” de lo que hacemos. No obstante, a veces no es suficiente y el cliente sigue insatisfecho. En esos casos se impone ofrecer el fin de proyecto . No inmediatamente, no por cualquier cosa, no como método sistemático para contrarrestar los comentarios. Ofrecer el fin de proyecto da la posibilidad al cliente de poner en perspectiva sus objeciones. Si son de fondo, el fin de proyecto es lo mejor para ambos. Si la relación entre ambos es madura y a largo plazo, cerrar un proyecto que no va a buen puerto es una forma de cuidarse mutuamente. Seguimos pensando.. Todo s  los consultips juntos están  aquí .  Si queres leer el anterior, podes ir

Es difícil sobrevivir, a mediano o largo plazo, al frente de un área de TI, sin trabajar el proceso de gestión de la demanda. No obstante, son pocos los CIOs que lo trabajan rigurosamente. Más bien van reaccionando a lo que los “usuarios” piden. Trabajarlo rigurosamente involucra abarcar varios ejes, orgánicamente y alineando a todos los interlocutores internos al área de TI y externos (negocio, proveedores). Va aquí un diagrama que los muestra. No es una tarea sencilla pero cuando se logra, todos lo agradecen pues el nivel de estrés y angustia disminuye notablemente. Seguimos pensando..

No tengo muchos recuerdos relacionados con "figuritas" de mi niñez. Seguramente debo haber coleccionado bastantes pero pocas han quedado en la memoria. Las que sí recuerdo son las de "El Regreso del Jedi". Recuerdo jugar en el patio (chupi, tapadita, ...), recuerdo el "pilón" que había ganado y recuerdo seguir cambiando aún luego de haber completado el álbum. Será por esos recuerdos que acompañé a mi hijo a cambiar figuritas. Tal vez con la esperanza de revivirlos o tal vez con la necesidad de completar ese maldito álbum de una vez por todas. Sea como fuere, me encontré con que ahora no es como era. Los chicos no cambian tanto figuritas. Ahora piden que les compren paquetes o piden que les compren las que les faltan. Sí, ahora se puede comprar una figurita en particular al precio de un paquete.  El amor al deporte por parte de los niños se está perdiendo, claramente. Los que sí cambian todavía, porque les divierte, porque no conocen otra forma o, simplemen

Gentileza de un alumno de UADE. Más allá de que la publicidad es buena, no estoy seguro de que proyecte la mejor imagen para una empresa de consultoría. Seguimos pensando..

Es difícil convencer a un desarrollador de que hay restricciones para su desarrollo. Usualmente quieren trabajar como espíritus libres sólo guiados por “las buenas prácticas”, sin ataduras de fechas y sin tener que pronosticar cuando terminarán. A lo largo de los años he mantenido muchas discusiones respecto a que, cuando desarrollamos software para una organización, las restricciones existen (tiempo, costo, funcionalidad, …) y debemos tomarlas en consideración . La discusión más común es lograr llegar a un compromiso respecto a cuánto deberíamos invertir en un determinado desarrollo. Pensando en ello podría decirse que tal vez, parte del problema, es plantear el tema en términos de estimaciones . Hoy me encontré con un post llamado Drive development with budgets not estimates en Signal Vs. Noise del cual podemos sacar un enfoque más productivo para esa discusión. No pensemos en el juego de me das una estimación, negociamos una rebaja y luego cerramos un compromiso de fechas . Pen

Hay lugares a los que la gente va a trabajar porque sabe que eso luego habilita otras oportunidades (ofertas de trabajo, experiencia, contactos, etc.). Tanto las empresas/organizaciones como las personas saben que esto ocurre y actúan en consecuencia. Cada cual juega sus cartas y la mejor mano gana. No hay mucho que hacer al respecto, así es el juego. Generalmente la mejor estrategia es tratar de jugar las cartas de forma tal que nadie pierda y ambos ganen. Seguimos pensando..

Los consultores deben disfrutar lo que hacen pero aceptando que hay ciertas premisas que no pueden cambiarse. En este artículo llamado Ahora es el trabajo el que va con uno , Alejandro Melamed habla de los trabajadores nómadas. No pude evitar trazar un paralelismo con la vida del consultor. 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í .