Así no se hacen las cosas por Ernesto Kiszkurno

El otro día escuché por ahí "Como no podíamos cobrar lo que realmente vale el producto, entonces ...", donde en los puntos suspensivos se detallaba una nueva estrategia de venta que, en teoría, aumentaría las ganancias. Todavía hay gente que cree que el precio de un producto de software o un servicio consultivo se fija unilateralmente pero la verdad es que el precio siempre está en un punto intermedio entre lo que el comprador está dispuesto a pagar y lo que el vendedor está dispuesto a aceptar por él . Son pocos los casos en los que uno de los puede forzar, y cuando lo hace seguro está afectando la relación Seguimos pensando..

Hace muchos años ('98) le escuché decir en una conferencia a Boris Beizer que no hay m ejores prácticas , sino buenas prácticas . Luego con los años aprendí que sólo hay buenas prácticas en contexto . Rescato algunos párrafos que hablan sobre esto del post Six heresies for business intelligence . Primero un mensaje contundente: "There are no best practices for business intelligence, only appropriate ones" Luego, hablando de Business Intelligence, un buen consejo respecto a cómo tomar las prácticas importadas de otros lugares: "A deeper issue is that much of the knowledge pertaining to best practices is tacit – that is, it cannot be codified in written form. Indeed, what differentiates good business intelligence developers or architects from great ones is not what they learnt from a textbook (or in a training course), but how they actually practice their craft.  These consist of things that they do instinctively and would find hard to put into words. So, ins

Cortesía de Damián Donia . Sólo para que sepan/recuerden que este blog es sponsor oficial de ACDC. Seguimos pensando..

Si bien es sabido que los riesgos en proyectos de desarrollo de software existen, veo todo el tiempo equipos subestimándolos. Hay una mezcla de "a mí no me va a pasar" con "eso es para otro tipo de proyectos" increíble. Así como el otro día decía que veo a mucho equipos más preocupados por temas de gestión que por temas técnicos , también veo que este –aún siendo tema de gestión- no es un tema que preocupe casi nunca. Pocas veces he visto que los equipos de desarrollo encaren la tarea de hacer una análisis de riesgos a conciencia que les permita entender por dónde van a venir los tiros . Es como si flotara en el aire una sensación de perfección tal que no permitiera ver que las cosas en desarrollo de software rara vez salen bien y tenemos que responder a riesgos materializados todo el tiempo. ¿Alguien puede decirme por qué es esto? Seguimos pensando..

El otro día se dio una conversación interesante en Google Plus sobre el uso de las prácticas de gestión y técnicas por parte de los equipos de desarrollo de software. Gracias a una referencia de Lorenzo Jorquera , encontré un interesante artículo llamado FlaccidScrum de Martin Fowler, en el que se mencionaba algo que pienso desde hace un tiempo. Hay mucha más preocupación de los equipos de proyecto sobre temas de gestión que sobre temas de ingeniería. Están tan preocupados por temas de organización y prácticas de comunicación –que son importantes obviamente- que dejan de lado temas cruciales de ingeniería. Estas ideas tienen origen en esta cita de Mary Shaw referenciada por Santiago Ceria : “Software has engineering challenges aplenty, and mislabeling management and process issues as “engineering” diverts attention from the equally important technical issues of creating a systematic, scientific basis for an engineering discipline. Our prospects would be better if we’d recognize

Cada cliente tiene sus costumbres. Algunos usan mucho el mail, otros el celular o los SMSs. Debemos respetar estas costumbres y tratar de acompañarlas si queremos facilitar la comunicación. No obstante, debemos ser conscientes de los riesgos que corremos. Si usamos mucho el celular tal vez generemos la impresión de que cualquier momento es válido para hacer un llamado. Si usamos SMSs para todo alguno puede creer que ese es un mecanismo válido para formalizar acuerdos. Seamos cuidadosos. Seguimos pensando..

Les dejo un video muy breve de Ward Cunningham donde explica el origen del término deuda técnica . Seguimos pensando..

En el post Los clientes no quieren hablar de Germán Gómez encontré una interesante pregunta para hacernos antes o durante las interacciones comerciales con clientes: ¿Qué va a aportar a mis clientes la conversación que yo deseo mantener? El post menciona dos obviedades. La primera es que debemos conversar con los clientes y la segunda es que los clientes no quieren hablar con sus proveedores . La clave es en lograr tener conversaciones comerciales relevantes . Si no hablo de temas relevantes para el cliente, este no querrá hablar. Si no hablo , no se acordará de mí. Si no se acuerda de mí, difícilmente dure como su proveedor. Seguimos pensando..

Del post de Seth Godin Thinking lifetime (don't break the chain) : “Support is not a cost center, it's a profit center. Treating customers with urgency and clarity and respect (maintaining the chain) is more urgent than ever. But companies are busy measuring time on the phone or cost per hour of support people instead of even trying to measure customer churn.” Seguimos pensando..

Encontré la palabra "siloistation" en un post llamado What is this devops thing, anyway? . La traducción tal vez podría ser siloificación, no? :-) El post describe el concepto/problema de la siguiente forma: "On most projects I’ve worked on, the project team is split into developers, testers, release managers and sysadmins working in separate silos. From a process perspective this is dreadfully wasteful. It can also lead to a 'lob it over the wall' philosophy - problems are passed between business analysts, developers, QA specialists and sysadmins. Furthermore, we see a replication of this silo structure within the teams - it’s not uncommon to see dedicated database and network people in the same system team, alongside sysadmins. Often the larger silos aren't in the same office, the same city, or in sometimes not even in the same country. The result is an ‘us and them’ mentality - groups of people who are simultaneously suspicious of and afraid of each othe

Me resulta sumamente interesante conocer cómo funcionan las empresas de tecnología. ¿Cómo se organizan? ¿Cómo es su cultura? Etc. Les dejo un video que llega a mi vía el blog de Henrik Kniberg . Muy interesante. Seguimos pensando..

Gracias al amigo Santiago Ceria llego a un interesante artículo de Aldo Ferrer del cual rescato 3 párrafos para pensar: El primero, en el que menciona el rol del estado: “No hay nada genético, en el ADN del EA, cuando privilegia la especulación sobre la producción o cede el protagonismo a las filiales de empresas extranjeras, en vez de asumir el liderazgo de la industrialización. Si se trasplantaran al país los empresarios más innovadores del mundo en desarrollo, por ejemplo, los coreanos, al poco tiempo tendrían el mismo comportamiento que los argentinos. Y, como me fue señalado por el vicedecano de la Facultad de Ciencias Económicas de la Universidad del Litoral, si los argentinos se radicaran en Corea, se comportarían como los coreanos. El Estado tiene la responsabilidad fundamental de crear los espacios de rentabilidad y el contexto que orienta a la iniciativa privada al proceso de transformación. El EA es, en definitiva, una construcción política.” El segundo, que contiene la

Me encuentro muy seguido con consultores que hacen un excelente trabajo cotidiano pero reparan poco en los entregables que lo acompañan. Conocen del tema que tienen entre manos, se relacionan bien, tienen un buen nivel de análisis, entienden el contexto del cliente y/o del proyecto en el que se mueven, etc. Cuando uno los ve trabajar no puede evitar decir que son buenos consultores. No obstante, estos mismo consultores serían muchísimo mejores, hasta sobresalientes, si pusieran más cuidado en los entregables que respaldan dicho trabajo. Cuando hablo de calidad en los entregables hablo de varios ejes: El contenido, es decir lo que decimos, cómo lo decimos, a quién se lo decimos. La estética, que tiene que ver con el formato que elegimos , la presentación que damos , la longitud, etc. La vigencia, que tiene que ver con que el entregable tiene que estar en el momento en el que fue pedido. No sirve entregar un informe anual 6 meses después de terminado el año, aún cuando este e

Una de las funciones más importantes del área de Compras es desarrollar un conjunto de proveedores que este a la altura de las necesidades de su compañía. Para ello debe trabajar con cada una de las áreas de la empresa para entender necesidades y restricciones. No se trata solamente de "despachar licitaciones", de "traspasar pedidos" o de conseguir "el proveedor más barato". El área de Compras que hace eso no agrega valor y si esto ocurre no tiene demasiada razón de ser. En el caso de servicios relacionados con TI en particular Compras debe trabajar codo a codo con el CIO.  Este último no puede desentenderse de lo que ocurre entre Compras y sus proveedores (los del CIO). Si lo hace puede perder algunos importantes y tal vez mucho tiempo también, ya que desarrollar proveedores consume tiempo y energía. He visto en más de una ocasión que este trabajo en conjunto no ocurre y he visto las consecuencias que ello trae aparejadas luego. Frases como "si el u

De New Management 3.0 Workout articule Project Credits de Jurgen Appelo “Recruiters know that many people can easily be convinced to take on a job with low pay as long as the job title is impressive. And for those already in a job, additional qualifiers such as “Senior”, “Lead”, and “Master” communicate a level of performance that em-ployees feel they deserve. Research says that happiness is achieved when people make progress [Haidt, The Happiness Hypothesis]. Nice titles help people feel progress, and be happy.” Seguimos pensando..

Un lindo video de IAE Business School. No puedo evitar pensar este tipo de sesgos “módulo” desarrollo de software. Cuando estimamos software cometemos estos errores y muchos otros también. Seguimos pensando..

Allá por el 2009 escribí por primera vez sobre los planes de carrera (cómo pasa el tiempo!). Decía entonces que era bastante improbable poder elaborar un plan y seguirlo sin pensar. Ya en 2010 opinaba que debíamos tener un esquema menos rígido , que nos permita acompañar el dinamismo que las empresas tienen hoy. La metáfora de los surfers de 2012 muestra que tenemos que poder reaccionar al contexto externo que tenemos enfrente y repensar nuestras movidas en la carrera, también, en base a eso. Ya no sólo pensamos en el dinamismo de la empresa, sino también en los cambios de contexto a los que esa empresa está sujeta. Hoy me encuentro con este interesante post de Jurgen Appelo que me ayuda a pensar un poco más en el asunto. Paso algunas reflexiones: Primero, interesante lo que dice de las jerarquías y de las evoluciones : “She showed me the suggested career paths that software developers could have in our organization. To my horror I saw, if I remember well, that Software Tester

Cuando hablamos de liderar gente resulta difícil transmitir reglas claras que sirvan para cualquier situación. Trabajar con gente nunca es sencillo y siempre que creemos haberle encontrado la vuelta al tema, aparece una nueva situación en la que otra vez debemos hacer prueba y error. No obstante hay algo que me atrevo a decir sin dudas, hay una regla que sirve siempre y es indiscutible: Si queremos tener un buen equipo debemos dedicarle tiempo. Dedicarle tiempo significa escuchar, hablar, comunicarse, relacionarse. Una de las formas más efectivas de hacerlo son los 1:1 (o one on one's). Se trata de reuniones periódicas mano a mano, con cada colaborador que nos permitirán establecer este vínculo del que hablo. Les dejo aquí un post de Rands donde describe la forma en que él los hace. Creo que es un buen punto de partida para entenderlos. Seguimos pensando..