El blog de Ernesto Kiszkurno

Serie consultip en Twitter

2012-02-11T08:00:00.000-03:00

Desde hace un tiempo estoy publicando tuits bajo el hashtag #consultip. La idea de la serie es muy simple: Enunciar “tips” relacionados con servicios de consultoría.

Y en el sentido más amplio (desde cómo brindarlos hasta cómo contratarlos). El hecho de hacerlo en Twitter le pone un condimento especial dado que además deben entrar en 129 caracteres (pues hay 11 ocupados por el hashtag).

Espero que les guste, la sigan y, eventualmente, hasta aporten cosas.

Seguimos pensando..

Vacaciones de escritura

2012-02-07T18:56:00.001-03:00

He llegado a la conclusión de que que uno puede aprovechar las vacaciones para intentar ponerse al día con la lectura pero no con la escritura.

La sensación que tengo es que estoy en una sintonía distinta. Intento pero no logro. Parece como que tengo permanentemente arena en las manos.

Otros años logré “estockearme” de posts antes de irme y generar la sensación de que “no estoy de vacaciones”. Este año fracasé rotundamente.

Dicho esto no se asusten si el blog está más callado que de costumbre..

Sigan pensando..

Desperdicios

2012-01-26T09:49:00.001-03:00

"Después de la prueba el reverendo O’Hara me dijo que un solista como yo cantando en un coro era un verdadero desperdicio. Y que él tenía por norma… ¡deshacerse de los desperdicios!"

Yoghurtu Nghé, Les Luthiers.

Simpatizo mucho con la idea de Lean de deshacerse de los desperdicios.

La filosofía Lean es "diseñar sistemas de producción donde se convierten los requerimientos de cliente en entregas en el menor tiempo posible a través de la eliminación de los desperdicios". Por su parte desperdicio" es cualquier elemento dentro del proceso de producción (incluyendo áreas de servicio y administrativas) que añade costo sin añadir valor".

De las formas de desperdicio siempre mencionadas hay 3 que me parecen especialmente relevantes cuando hablamos de servicios/proyectos. Tenerlas en mente y controlarlas resulta fundamental para cumplir fechas, costos y calidad:

El tiempo de espera. Hay diversas situaciones durante la prestación de un servicio o la ejecución de un proyecto en las que las esperas se prolongan más de lo debido. Por ejemplo correos que quedan en un inbox mail más tiempo del que deberían, validaciones de documentos que no llegan y no permiten avanzar en el trabajo, problemas de falta (o mala) comunicación entre las personas.
El retrabajo. Especialmente en desarrollo de software, el retrabajo es el enemigo número uno a combatir. En este sentido realizar actividades de control en etapas intermedias de los entregables disminuye la probabilidad de retrabajo posterior (hay que recortar la "ley del x10"). Pero retrabajo no es sólo rehacer cosas que se hicieron mal, también tiene que ver con tardar más de lo necesario debido por ejemplo a interrupciones.
El sobreprocesamiento. Este concepto tiene que ver con hacer más de lo que el cliente no está dispuesto a pagar. En software por ejemplo es muy común encontrarnos con "features" desarrollados que en realidad nadie pidió. Pero no sólo al generar código ocurre este desperdicio, también ocurre al escribir un documento (más largo o más profundo de lo que debería ser) o al convocar a una reunión (con más gente de la que realmente se necesita para tomar la decisión).

¿Qué desperdicios podrías eliminar hoy?

Seguimos pensando..

Frases hechas

2012-01-21T08:00:00.000-03:00

Me dijeron por ahí

“A mí me interesa más la programación que el testing. Soy más ‘constructivo’ que ‘destructivo’”

Y yo automáticamente pensé

“La mentalidad del tester no es de destruir software sino de construir calidad”

Seguimos pensando..

Riesgo y Madurez

2012-01-18T09:20:00.001-03:00

Cito del capítulo 26 del libro Peopleware:

All the projects that carry real benefit carry real risks along with them. It is the project that has some novelty, some innovation or invention, that might grab the customer's imagination and wallet. It's even possible your company's most famous disaster project—the one that came in a year over schedule, at 3.5 times the cost, had loads of problems getting through system test, and still needs engineers standing around with code defibrillators just to keep it running—is still the best project your organization has done in years.

One of the strongest justifications for the CMM is that it will raise quality and productivity while decreasing risk. The [model] suggests that the same work can be undertaken at higher levels with lower risk. But there is another interpretation that strikes us as more likely: Organizations become more and more averse to risk as they "mature." An organization under the gun to demonstrate increased CMM level is not going to go looking for real challenge.

Dos pensamientos a partir de estos párrafos:

Madurez organizacional necesariamente tiene que ver con entender mejor los riesgos que corremos y no correr menos riesgos.
Las certificaciones pensadas como metas (ej. ser nivel 3 para fin de año) tienden a desvirtuar la cultura de mejora continua que siempre es bueno tener en nuestra organización/equipo.

Seguimos pensando..

¿Y qué hicieron todo este tiempo?

2012-01-14T11:18:00.001-03:00

Si estás dando servicios de consultoría a un cliente y te hacen esta pregunta las cosas van mal. Días atrás escribí en Twitter la siguiente frase:

"La consultoría es un juego de gestión de expectativas donde lo pedido y lo ofrecido van acercándose durante el servicio"

La idea es que durante el servicio el alcance y las expectativas se gestionan. Si bien hay una expectativa inicial y un alcance inicial, el cliente va a ir modificando su percepción de lo que necesita por razones diversas (información nueva, cambios de contexto, etc.) o arbitrariamente. Realmente no importa por qué lo hace, lo que importa es que esto es dato. En un punto la disyuntiva es parecida a la discusión entre modelo cascada y métodos ágiles que se da(ba) en ingeniería de software.

El impulso natural es a plantear el servicio con un alcance inamovible y rígido, pero muchas veces la realidad del cliente no nos lo permite y nos sentimos como si tratáramos de acertarle a un blanco móvil.

Es aquí donde podemos perder el rumbo y llegar al punto donde nos hacen la pregunta "¿y qué hicieron todo este tiempo". Y dado que lo mejor es prevenir la situación y no tener que repuntarla una vez que ocurrió, menciono 3 tips que mitigan el riesgo de que la pregunta ocurra:

Hacer un ejercicio serio de definición de alcance y planificación al inicio del proyecto. No hay que dar la propuesta (o el contrato) por obvio y menos que menos arrancar el servicio sin conocerlo.
Hacer un ejercicio periódico de revisión del avance con el cliente. Esto debe hacerse mínimamente mediante un entregable que explica lo hecho hasta el momento, el avance real que tiene el proyecto y lo que se hará en el siguiente periodo. Idealmente debe hacerse también una reunión de 45 minutos donde “nos ponemos todos en la misma página”.
Hacer un ejercicio (también) periódico e interno de revisión de lo hecho vs el alcance inicial. Y si hay desvíos comunicarlos en la siguiente reunión de avance con el cliente.

Cuando las cosas van bien todo esto puede ser visto como “burocracia” pero cuando las cosas van mal este tipo actividades pueden ayudarnos a revertir la situación o por lo menos explicarla.

Seguimos pensando..

Descuento

2012-01-11T21:57:00.001-03:00

Gran parte de mi tiempo laboral esta dedicado a la actividad comercial. Es decir que debo relevar necesidades de clientes, diseñar propuestas para satisfacerlas y costearlas (en tiempo y esfuerzo).

Esto me pone en situación de tener que recibir pedidos de descuento en el precio. Es algo normal, que se acostumbra. El problema a mi se me genera es cuando el descuento que me piden es alto. El pedido, con variaciones menores, se expresa así:

"Revisamos la propuesta y nos parece Ok, pero necesitamos que nos hagas un descuento de 20% en el precio porque nuestro presupuesto es acotado"

Como proveedor uno siempre está preparado para hacer un descuento. Algunos se preparan para hacer el 20 y otros no.

¿Es razonable contratar a un proveedor que está dispuesto a hacer un 20% de descuento en un servicio sin modificar el alcance?

Aclaración importante: Estamos hablando de servicios profesionales, no de productos. Estamos hablando de un descuento sin modificación de alcance.

Seguimos pensando..

Cambio de hábito

2012-01-07T10:23:00.001-03:00

¿Internet no les cambió el hábito de la lectura?

Sí, lo sé. Posiblemente ya hay mucho escrito sobre el tema pero tuve una revelación banal que decidí hacer pública.

Desde el bum de internet, las redes sociales, los blogs y gReader mis hábitos de lectura cambiaron sustancialmente y lo percibo en dos ejes:

El mix es distinto. Ahora dedico más tiempo de lectura a internet y eso ha disminuido el tiempo de lectura tradicional (es decir libros).
La paciencia es menor. La gimnasia de leer cosas cortas ha menguado la paciencia para leer cosas más largas y complejas.

Todavía no llego a entender si estos cambios son buenos o malos. Algunos me han dicho que no hay que juzgarlos sino que hay que hacerse a la idea de que son dos "soportes" distintos, con reglas distintas.

No sé.. por lo pronto la sensación que sí tengo es que leo menos. Técnicamente esto no es cierto porque el tiempo de lectura parece ser el mismo. En realidad, siendo más precisos, debería decir que leo menos libros.

¿A ustedes les pasa lo mismo?

Seguimos pensando..

Ejemplos del costo de la calidad

2012-01-04T22:07:00.001-03:00

En el segundo cuatrimestre del 2011, en la dictada de la materia que estuve dando en Exactas pedí a los alumnos que presenten un caso, documentado en internet, de pérdida de dinero por problemas de software preferentemente de no más de 5 años de antigüedad. La idea era tener evidencias concretas sobre el costo de la calidad. Los casos elegidos fueron:

El proyecto de implementación de un sistema de Administración de Impuestos por EDS para el Reino Unido (Abril 2003). Más.
La falla en el sistema de los planes de vuelo de la Federal Aviation Administration (FAA) de Estados Unidos, ocurrido el jueves 19 de noviembre de 2009. Más.
La pérdida de datos sufrida por el correo electrónico de Google en Febrero de 2011 que afectó al 0.08% de sus usuarios. Más.
El problema del año 2010 también conocido como Y2K+10 que afectó a múltiples sistemas como Windows Mobile, la PlayStation o los chips de tarjetas de crédito en Alemania.
El problema producido con el uso del software CATIA (Computer Aided Three-dimensional Interactive Application) en el diseño del cableado del Airbus380 en octubre de 2006. Más.
El problema que tuvo RIM con sus celulares el 10 de octubre de 2011. Más.
El problema que tuvo SONY por una mala implementación del algoritmo de encriptación de su PS3 en diciembre de 2010.
El incendio en el metro de la ciudad de Washington DC el 8 de abril del 2007 producido por el fallo de un sensor y la falla del software de control de sensores. Más.
Los problemas del software para la nueva terminal 5 del aeropuerto de Heathrow en Londres abierto el abril de 2008. Más.

La verdad es que todos resultaron interesantes y variados.

Seguimos pensando..

¿Dónde martillar?

2011-12-31T10:18:00.001-03:00

(como no podía ser de otra manera, aquí va un post navideño)

El otro día en casa tuvimos un problema con la caldera. Básicamente y de un momento a otro, dejó de funcionar cortándose el suministro de agua caliente. Todo mal, era 24 de diciembre a las 13hs.

Obviamente (o no tanto) la caldera es una caja negra para mi. Es decir un artefacto que cuando se rompe no sé que hacer para que vuelva a funcionar. He probado, en repetidas oportunidades, distintos métodos pero la cosa siempre termina igual: llamado al técnico.

Como era de esperarse el 24 no trabajaba pero combinamos para el lunes siguiente, por la mañana. Cuando vino miró la caldera, movió 2 perillas y listo, la caldera comenzó a funcionar. Magia, no había pasado un minuto desde su llegada que ya se iba cobrando por el "arreglo".

En este tipo de situaciones varias emociones se mezclan en mi interior: admiración (por ver como alguien puede resolver en segundos algo que yo no pude ni diagnosticar), enojo/frustración (por tener que pagar por esa pavada) y vergüenza (por creer que en realidad era simple y lo podría haber resuelto). Poco importa toda la infraestructura que el técnico tiene que tener montada para poder dar ese servicio rápidamente y con calidad: experiencia, disponibilidad, medio de transporte, materiales (que eventualmente podría tener que usar), infraestructura, etc., etc..

Digamos que estamos ante un caso más de esos donde se paga por saber y no por esforzarse. O como dice el chiste, uno no le paga al técnico por ese minuto de trabajo que estuvo sino por ese minuto sumado a los "n" años de experiencia (estudiando, resolviendo cosas parecidas, etc.).

Estoy seguro que si les doy un minuto para pensarlo, van a preferir un técnico experto que responde a nuestro llamado, llega a tiempo y da un servicio de calidad (diagnostica rápido, ajusta 2 perillas en un minuto y soluciona) a otro que es difícil de encontrar y da un servicio de baja calidad (tarda 2 horas en diagnosticar, desarma la caldera completa para lograrlo y, en el mejor de los casos, soluciona el problema).

Por eso señor cliente, y (me) digo esto con todo respeto, la próxima vez que evalúe cuánto le cobra su consultor/técnico amigo piense por qué le está pagando.

Seguimos pensando..

Next Operation As a Customer

2011-12-28T08:00:00.000-03:00

El concepto de "next operation as a customer" o NOAC tiene su origen en el campo de la mejora de procesos y la calidad total. La idea, aparentemente acuñada por Ishikawa, es que cada operación debe ser pensada como un proveedor y cliente a la vez. Se busca producir con esto un mayor cuidado en las operaciones intermedias y por ende un nivel de calidad mayor en el producto final.

Karl Wieggers en su libro Creating a Software Engineering Quality Culture sostiene que para mejorar la calidad del software es necesario introducirlo dentro de la cultura del desarrollo de software. No solo coincido en el approach sino que pienso también que el desarrollo de software tiene mucho que aprender de otros procesos de producción industrial todavía.

Pero también veo lo mismo cuando hablamos de las organizaciones y sus procesos. Es común ver en el día a día un sin fin de oportunidades para aplicar el concepto. Mi sensación es que el cambio en productividad y efectividad sería inmenso con tan sólo un pequeño esfuerzo de las partes involucradas. Por ejemplo, si empezamos con nosotros mismos: (a) cuando estamos elaborando un documento que otra persona tendrá que leer, analizar, evaluar o controlar (b) cuando estamos escribiendo un correo electrónico para que alguien más decida algo (c) cuando estamos haciendo un encargo a alguien.

Desgraciadamente parece ser que sólo cuando "el cliente real" va a recibir el producto de nuestro trabajo está clarísimo que debemos pensar el siguiente paso como un cliente, en otros momentos no.

Supongo que la moraleja es que cuando formamos parte de un proceso junto con otras personas, ponerse en los zapatos del siguiente pensando cómo hacer que su operación sea más fácil es una práctica esencial.

Seguimos pensando..

Detalles

2011-12-24T08:00:00.000-03:00

"El diablo esta en los detalles" dicen por ahí. Y es cierto, a veces la falta de cuidado en los detalles arruina los proyectos más interesantes y/o mejor planificados. Van 10 ejemplos de "detalles" que empeoran o comprometen el éxito de los proyectos:

Perder el ritmo en las reuniones de seguimiento, cambiando el horario, el día o directamente suspendiéndolas.
Dejar que el plan de proyecto se desactualice perdiendo la noción del gap entre la línea base y la realidad.
Dejar que los stakeholders del proyecto tengan que preguntar como va el proyecto, en lugar de decirlo nosotros proactivamente.
Ir dejando el recupero de los atrasos para el final del proyecto.
Dejar para el mail lo que puede comunicarse personalmente.
Olvidar revisar (y actualizar) los objetivos del proyecto periódicamente.
Dejar para mañana problemas que podrían resolverse hoy.
No validar con el usuario periódicamente los requerimientos y/o pedidos, confrontándolos con el impacto que estos tienen en los plazos y los pesos del proyecto.
No gestionar correctamente los cambios (análisis, comunicación y documentación).
Olvidar quien es el sponsor/cliente confundiéndolo con otros stakeholders.

Como decía Fred Brooks “los proyectos se atrasan un día a la vez” y siempre por detalles que parecen insignificantes.

Seguimos pensando..

El nuevo contrato social entre la empresa y el empleado

2011-12-21T08:00:00.000-03:00

Extraigo un nuevo párrafo del libro La tierra es plana (de Thomas Friedman) sobre el que comenté en “Trabajo de por vida versus Empleabilidad” y “Los Intocables”.

Si hubiera hoy un nuevo contrato social implícito entre empleadores y empleados, debería ser éste: tú me das tu trabajo y tu esfuerzo y yo te garantizo que mientras trabajes aquí te daré todas las oportunidades (tanto en mejora profesional como en formación) para tener más salidas laborales y hacerte más versátil.

Seguimos pensando..

PD: Nuevo es un decir, el libro de Friedman es del 2005.

Trabajo de por vida versus Empleabilidad

2011-12-17T08:00:00.000-03:00

En el libro La Tierra es Plana, sobre el que ya escribí en otra oportunidad, se describen con cierto detalle los cambios positivos ocurridos en IBM al asumir Lou Gerstner allá por el año 1993.

Uno que me pareció particularmente interesante fue el de cambiar el concepto de trabajo de por vida por el de empleabilidad de por vida. El primero tiene que ver con la idea de que que las personas entraban a trabajar en un lugar y permanecían allí toda su vida laboral. El segundo se refiere a la capacidad de un individuo de obtener la máxima rentabilidad de su perfil.

El trabajo de por vida tiene más que ver con lealtad [1], es un concepto más romántico. La empleabilidad de por vida tiene que ver con productividad y es un concepto más práctico. En la medida en que a ambos (empleado y empresa) les sirva estar juntos, lo están.

Por desgracia del lado empresario tiene a pensarse que la empleabilidad beneficia sólo al empleado pero esto no es correcto.

Es cierto que alguien que tiene alta empleabilidad tendrá más chances de mantener el trabajo actual [2], menos dificultades para conseguir otro y también mejores remuneraciones, pero como dice este artículo, también se beneficia la empresa. Y lo hace, citando al artículo antes mencionado, en dos aspectos: productividad y gestión.

¿Por qué en su productividad? Mejorar la empleabilidad de los trabajadores hace que los que tenemos tengan más oportunidades y capacidad para marcharse, pero también significa que la empresa podrá encontrar gente con mayor capacidad de adaptación, capacidad operativa y mayor potencialidad. Puntualmente la productividad en determinada área puede resentirse a corto plazo, dependiendo de la complejidad de la tarea, de los recursos, etc. (el periodo de adaptación, coger carrerilla...) pero nos quedaríamos en la anécdota si consideráramos esto como un perjuicio para la empresa.
¿Por qué en su gestión? Cuando se tiende a una gestión cada vez más atomizada, cuando se fomenta tomar las decisiones a pie de obra como quien dice, la empleabilidad también va a facilitar el incorporar gente más preparada para ello, para realizar con eficacia y asumir mayor responsabilidad sobre diferentes funciones de gestión.

La reflexión final tiene que ver con que independientemente de si nuestro plan de carrera es quedarnos toda la vida en la misma empresa o no [3], siempre tenemos que pensar en nuestra empleabilidad.

Seguimos pensando..

[1] Ojo, la lealtad es algo muy valorable en los empleados (y en las empresas) pero mal entendida puede ser muy perjudicial (para ambos) pues genera lazos negativos y difíciles de romper.

[2] Antes se pensaba que si entrábamos a la empresa X, listo, no había que volver a capacitarse, entrenarse o actualizarse. Bueno, esos días han terminado tiempo atrás y sino, pregúntenle a los japoneses.

[3] Este tema da para una larga discusión.. que no entra en este post.

A veces 1+1 es 0

2011-12-14T08:00:00.000-03:00

El que mucho abarca poco aprieta, te quedaste sin el pan y sin la torta, ...

Frases de la sabiduría popular que nos alertan sobre la imposibilidad de hacer todo al mismo tiempo. Típicamente las recordamos en esos momentos donde nos encontramos metidos en demasiadas cosas. En esos momentos de sufrimiento e impotencia que queremos largar todo y tener una vida trivial.

Mejor pensar antes de meternos en "un tema más", no? ...pero es muy difícil resistir la tentación. Es lindo hacer, estar activo, poder elegir qué hacer y a la vez eso cansa mucho.

Seguimos pensando..

PD: Ah! Hay una cosa peor y es cuando alguien más nos mete en demasiadas cosas y nos cuesta decirle que no!

Cuidado con enamorarse de los números

2011-12-10T18:44:00.001-03:00

Es bueno "tener números", ayuda a entender mejor. Pero también, a veces, dan una falsa sensación de seguridad y control.

Hay 2 clases de números. Los números que uno puede calcular objetivamente (los datos) y que sirven para argumentar o anclar la discusión sobre bases sólidas y los números que uno puede proyectar a partir de supuestos, ideas o razonamientos.

Esta segunda clase de números es peligrosa porque puede llevarnos a conclusiones o decisiones equivocadas. Muchas veces, inmersos en un mar de números, caemos en el error de tomarlos a todos como dato y quedarnos tranquilos que tenemos todo claro.

Como decían por ahí "es preferible estar vagamente en lo cierto que equivocado con toda precisión” (John M Keynes).

Seguimos pensando..

Más libre

2011-12-07T20:00:00.000-03:00

El otro día mientras leía el número uno de Orsai caí en la cuenta de que ando demasiado preocupado por "el tono y el contenido del blog" [1]. Es un blog profesional, entonces tiene que tener cosas "profesionales". No puede tener pavadas "en origen" [2].

Pero en realidad eso no termina de ser bueno porque es como viajar con el freno de mano puesto. Enfocarse de esa manera puede estar matando "en origen" ideas y pensamientos que podrían disparar conversaciones interesantes.

Voy a ver si en el futuro puedo contenerme menos y largarme más...

Seguimos pensando..

[1] Por pudor no voy a describir la cadena de razonamientos y elucubraciones que me llevaron a esa conclusión. Imagino que fue leer sobre su estrategia de anti-marketing y anti-negocios o algo más complicado que eso o algo tremendamente más lineal.. no sé.

[2] Pavadas en origen se refiere a que no puede tener cosas que el autor considere pavadas antes de publicarlas. Tranquilamente usted, lector, puede considerar que las cosas del blog son pavadas (pavadas en destino).

En un servicio factorizado.. ¿Importan los nombres?

2011-12-03T08:00:00.000-03:00

Cuando un cliente compra un producto no pregunta quién lo construyó. Tampoco pide que el empleado XX se ocupe personalmente de construírselo. Lo que pide es que el producto cumpla con lo que se espera de él y punto.

En los servicios factorizados (como por ejemplo los de “fábrica de testing”) sí se piden las cosas con nombre y apellido, produciéndose así contradicciones tanto para el cliente como para el proveedor:

Si pedimos servicios con nombre y apellido estamos pidiendo servicios personalizados. Pero no podemos pedir servicios personalizados a una fábrica. En una fábrica no hay personalizaciones, o si las hay son pocas.
En una fábrica se tratan a todos los productos producidos de igual forma, no hay casos especiales. El lugar donde se trata cada caso como único es el taller artesano. Es la diferencia entre un traje a medida y uno que no lo es.

Pensando en esto podemos concluir que un servicio factorizado puede estar basado en las personas o basado en los procesos y resultados.

Los clientes tienen cierta tendencia a basarse en las personas. Se me ocurren dos razones por las que los clientes prefieren saber el nombre de quien hace el trabajo:

Les inspira más confianza. Hablamos con alguien concreto que nos contesta y, eventualmente, rinde cuentas. Esa persona, con virtudes y defectos, tiene cara y eso es mucho. Cualquiera que haya llamado a algún centro de atención para quejarse sabe lo que esto significa.
Les permite cambiar sobre la marcha. Cuando uno compra un auto rojo no puede arrepentirse a los 20 días y pedir un cambio de color. O puede, pero casi siempre aceptando algún costo extra en tiempo o dinero. En servicios esto no ocurre. Saber el nombre le permite al cliente hablar con la persona y pedirle algo distinto sin penalidades. Total ¿qué cuesta hacer la tarea X en lugar de la tarea Y?

Por su parte los proveedores también tienen razones para ir por ese lado:

Es más fácil de vender. Es un servicio más simple, más fácil de entender y más barato. Comprar una foto linda de la torre Eiffel es más fácil que comprar un cuadro pintado a mano. ¿Le salió igual? ¿Por qué es más caro? ¿Cuánto vale un cuadro?
Hay menos riesgo. Si el cliente acepta a una persona y esta resulta menos productiva, en principio, el proveedor no es responsable. ¿No?

Sin embargo estas ventajas de corto plazo se contraponen con algunas desventajas de largo plazo puesto que la dinámica del servicio entra en un círculo vicioso:

Dependencia de las personas/Confianza en los que están. Cada vez que hay un cambio de personas el cliente tiene la sensación de que la calidad de servicio se deteriora. Hay casos en los que tiene razón y otros en los que no. Se hace muy difícil trabajar en ~~"independizar el servicio de las personas"~~ “hacer el servicio más resistente al cambio de personas” en un servicio personalizado. Por su parte, y en la misma situación, el proveedor se las ve en figuritas para poner “alguien igual a fulanito” porque fulanito es único [1].
Falta de gimnasia en otros ejes. Al estar acostumbrados a trabajar basados en personas y tenerle confianza a los que están, ni el cliente ni el proveedor ejercitan los músculos necesarios para trabajar basados en procesos y resultados.
Falta de escala. La falta gimnasia hace que el volumen de servicio sólo pueda crecer al ritmo en el que el cliente y el proveedor pueden generar "personas de confianza para el servicio". Y este ritmo es lento porque las tareas y/o procesos no están claros (se hace lo que se necesita en ese minuto).
La paradoja del costo. Al tener poca gimnasia y poca escala el servicio basado en procesos y resultados, visto desde el servicio basado en personas, siempre parece más caro. Es como cuando queremos bajar de peso para el verano. Si venimos bajando de a poco todo el año, llegamos. Cuando tratamos de hacerlo en los dos meses previos, la tarea nos parece faraónica.

A modo de cierre, no hay mejores modelos, hay modelos. El punto importante es entender qué modelo necesitamos y actuar en consecuencia aceptando sus limitaciones.

Seguimos pensando..

[1] Algunos quisieran vivir en el mundo feliz de Huxley.

Todavía uso Firefox

2011-11-30T08:00:00.000-03:00

El tema de tener monopolios en mi software de uso corriente siempre me ha preocupado.

En su momento el problema era que estaba demasiado inclinado hacia el lado Microsoft. Hoy me veo demasiado inclinado hacia el lado Google.

Aunque la dependencia de hoy tiene un agravante. El nivel de información que Google tiene sobre mí es mucho más grande y potencialmente más riesgoso. Hábitos de búsqueda, de lectura (greader), información de correos (gmail), mis gustos (Google+), etc. No está bueno también agregar navegación (Chrome).

Este post no es para detallar las implicancias de esa dependencia pues ya se ha escrito mucho sobre ese peligro. Este post es solo para explicar porque uso de Firefox. Digamos que es una pequeña barrera en contra del monopolio.

Seguimos pensando..

PD: Esta imagen fue buscada con Google Images.

¡Basta de planillas!

2011-11-26T08:00:00.000-03:00

La planilla de cálculo es uno de los inventos informáticos más importantes de todos los tiempos, sin lugar a dudas.

En particular el Excel de Microsoft es fantástico. Nos permite modelar y analizar situaciones de las más diversas en cuestión de minutos. Nos permite estructurar información y hasta mostrarla en forma muy comprensible. Podemos "pensar" en la planilla! (cosa que no se logra en otras herramientas como Powerpoint).

No obstante, todo tiene un límite. Una planilla de cálculo no es una base de datos, no es un data warehouse, no es una plataforma de colaboración, ....

Un error muy común de las organizaciones es no darse cuenta de que hay cierta información que no puede estar en Excel y tiene que estar en un "sistema".

Van aquí algunas pistas para darnos cuenta de que en realidad la planilla de cálculos dejó de servirnos:

Hay más de 7 personas accediendo a los mismos datos y en forma recurrente (por ejemplo mensualmente).
Hay actualización distribuida de la información y hay riesgo de que alguien toque lo que no debe.
Hay restricciones de visualización (no todos pueden ver todo).
Empezamos a tener el mismo dato en más de una planilla (data quality).
Empezamos a repetir cálculos en varias planillas.

Seguimos pensando..

Agendar tiempo para nuestros proyectos

2011-11-19T08:00:00.000-03:00

El otro día escuché un consejo muy piola en Manager Tools: agendar tiempo para trabajar en nuestro proyecto.

Allí comentaban que un error muy común relacionado con la gestión del tiempo es usar la agenda solamente para las reuniones. Lo demás (tareas, proyectos, prioridades y/o deadlines) suele caer en nuestra lista de tareas en forma de cosas para hacer.

La buena práctica es usar la agenda también para alocar tiempo para nuestras tareas, proyectos y prioridades, aunque sea tiempo solos. Como dijimos aquí, la regla es que si nuestra agenda no refleja nuestras prioridades, estamos haciendo las cosas mal.

Por el otro lado, si nuestro proyecto es lo más importante de nuestro trabajo, ¿no es natural que ocupe la mayor cantidad de nuestro tiempo?

Seguimos pensando..

Entusiasmo

2011-11-16T18:00:00.000-03:00

Todo libro nuevo genera expectativas. Lo empezamos con la idea de que nos entretenga, nos enseñe o nos agregue valor. Tenemos entusiasmo y está bien que ese sea el estado mental.

Dependiendo del libro la sensación se mantiene o se desvanece. La reflexión viene por el lado negativo: si el entusiasmo se va, dejen el libro. Ya habrá tiempo para retomarlo si nos arrepentimos. Hay demasiado por conocer como para perder el tiempo allí. La pila de libros para leer es infinita. Se los digo y me lo digo.

¿A qué otras cosas es aplicable este razonamiento?

Seguimos pensando..

Reglas para usar efectivamente el chat

2011-11-12T08:00:00.000-03:00

El "chat" está totalmente instalado en el ámbito laboral como herramienta de comunicación. Algunas organizaciones lo tienen incorporado como herramienta corporativa, otras sólo a nivel informal y por medio de sus empleados.

En cualquier caso, como toda herramienta, debe aprender a usarse efectivamente. Van aquí algunas reglas de supervivencia que podrían hacer tu vida más fácil (o la mía):

1. ¿Conviene usar el chat?

¿No es un tema para hablar personalmente, por teléfono o directamente mandar un correo electrónico? Aplicar la regla de los 3 por qué y preguntarse 3 veces por qué es necesario usarlo.

2. Primero decir "Hola"

Un “hola” o un “buen día” son siempre una buena forma de empezar. Salvo que estemos continuando una conversación previa, es parte de la etiqueta.

3. Ir directo al grano

Dado que el chat es una herramienta sincrónica debemos ser respetuosos del tiempo del otro. En ese sentido en el ámbito laboral el chat no es para hacer sociales. Resulta conveniente ir lo más directamente posible al punto que requerimos del otro haciendo “la” pregunta o pasando la información que queremos pasar. También es importante ser concreto y no extenderse en grandes razonamientos.

Un “tip” importante es no entrecortar nuestro discurso a medida que lo damos. Escribir todo lo que queremos decir antes de que la otra parte conteste y luego pasar la palabra. Por favor no hagan el clásico:

[Yo] Hola, quería

[Yo] comentarte que ayer el evento

[Yo] salió muy bien. Gracias por tu ayuda. ¿Me podes ayudar en el próximo?

(esperar)

Siempre es preferible algo como:

[Yo] Hola. Quería comentarte que ayer el evento salió muy bien. Gracias por tu ayuda. ¿Me podes ayudar en el próximo?

(esperar)

4. Una vez dicho lo nuestro, esperar respuesta o confirmación.

Decimos lo que queremos decir y esperamos. No repetimos, no repreguntamos, no escribimos el clásico “tas?”. Si no hay respuesta, asumimos que el mensaje no fue pasado. Por favor sumate a la campaña “no al tas?”. Si recibís un Tas? + (espera), por favor no respondas!!

5. No enojarse si no hay respuesta

Si nos piden hablar en otro momento o si no nos responden, no enojarse. Podría pasar que estén ocupados, fuera de la computadora o alguna otra cosa.

6. Estamos grabando

Debemos asumir que nuestras conversaciones por este medio son tan públicas como el correo electrónico. Debemos en todo momento cuidar el lenguaje puesto que aquí también mostramos la clase de profesional somos.

Seguimos pensando..

Effective Software Testing

2011-11-10T09:09:00.001-03:00

No se trata de formalizar por formalizar o de generar una biblioteca gigante de casos por el simple hecho de saber que la tenemos.

Se trata de instaurar un proceso de testing que sea efectivo. Es decir que disminuya la probabilidad de errores en producción.

Pensando las cosas de esta manera el método pasa a un segundo plano. En algunos casos convendrá escribir casos formalmente, en otros convendrá no hacerlo y practicar testing exploratorio. Como en tantas cosas de la vida .. depende.

Es por eso que las discusiones entorno a la formalidad de la prueba (o no) me parecen menos relevantes. Como ya dije en otra oportunidad los casos no son un fin en si mismo.

Seguimos pensando..

PD: Fijense que hable de efectividad y no de eficiencia. Esa es otra historia que tendrá que ver con cómo testeo lo mismo con menos esfuerzo.

In God we trust; all others must bring data

2011-11-05T08:00:00.000-03:00

Hay muchas situaciones de la vida profesional en las que debemos dar nuestro punto de vista sobre un tema, interpretar una situación determinada o acordar con alguien con la idea de tomar acción. Me vienen a la mente diálogos como:

Usuario: "Esta aplicación anda lenta"
Desarrollador: "No anda bien"

O también:

Comprador: "Este aumento es muy alto"
Vendedor: "No, es mínimo respecto a los aumentos de costos que tuvimos"

En casos como estos el problema no es que cada uno tenga su propia visión del mundo real sino que no hay datos que permitan a ambas partes avanzar hacia un lugar común y de entendimiento.

Sin datos es imposible discutir constructivamente. Ángel "Java" López sostiene en su post Bases para una discusión que las afirmaciones deben sustentarse con argumentos. Y la conocida frase de Edward Deming, "in God we trust; all others must bring data", nos da la pauta de que los datos generalmente son un argumento convincente.

La próxima vez que se encuentre en medio de una discusión piense en esto y vea cómo puede hacer para llevar datos que confirmen su punto de vista.

Seguimos pensando..

6 razones por las que todos debemos saber de gestión de proyectos

2011-10-29T11:46:00.001-03:00

Como decía Hegel, hay momentos para la tesis, momentos para la antítesis y momentos para la síntesis. Van aquí 6 razones por las que creo que, si trabajas en el mundo empresarial, es bueno que sepas cómo se gestiona un proyecto.

1. Están por todas partes

Si somos profesionales trabajando en el mundo de la empresa no podemos escapar a los proyectos, todas las organizaciones los tienen. Y aún en el caso de que nosotros no debamos "empujarlo", saber de proyectos nos permitirá atravesar mejor la experiencia.

Están siempre al acecho buscando la hora de cruzarse en nuestro camino.

2. Todo puede pensarse como proyecto y eso podría ser bueno

Pensándolo en un sentido general, todo lo que nos propongamos hacer puede ser pensado como un proyecto. Desde organizar un asado para nuestros amigos o planificar una cita romántica, hasta "poner un hombre en la luna en esta década". Conocer cómo se gestionan nos permite aplicar técnicas conocidas de organización y gestión que podrían ahorrarnos esfuerzo, costos, dolores de cabeza, etc.

3. Usted está dentro

Aunque usted no lo crea, en este preciso momento, usted está dentro de un proyecto, estoy seguro. Todos tenemos tareas asignadas en nuestro trabajo y por consiguiente tenemos que rendir cuentas y reportar avance sobre ellas. Esas tareas (uno, dos o varios niveles arriba) se encuentran dentro de un plan o contempladas en un objetivo de alguien. Es decir que están dentro de un proyecto y por consiguiente usted también.

Saber de gestión de proyectos nos permitirá saber cómo descomponer nuestro trabajo en tareas más chicas y estimar el tiempo requerido para ellas. Luego con esto podremos rendir cuentas.

4. La gente quiere proyectos, no tareas

Las personas funcionan mejor con contexto, con explicación de por qué las cosas son necesarias. Eso las motiva y les permite tomar decisiones alineadas con los objetivos del proyecto, área u organización. Organizar las actividades en términos de uno o varios proyectos permite comunicarse mejor las personas que trabajan para nosotros y de esa forma aumentar la probabilidad de que las cosas salgan como uno quiere.

5. Los clientes también necesitan contexto

Los clientes también entienden mejor cuando ven el contexto general. No sirve presentarles una lista de tareas. Ellos quieren ver hitos, entregables, resultados.

6. Y nuestro jefe tampoco quiere tareas

Una buena hipótesis de trabajo con los jefes es asumir que su tiempo siempre es más valioso que el nuestro. Partiendo de allí, no es eficiente que él/ella tenga el mismo nivel de detalle en nuestras tareas que nosotros. Típicamente él estará un nivel menos (o más) de detalle respecto de nuestro trabajo.

Organizar nuestro trabajo como uno o varios proyectos con hitos, entregables y resultados nos permitirá "resumir" nuestro trabajo y así presentarlo más eficaz y eficientemente a nuestro jefe.

Si no les gustan estas razones, no importa. Tengo más.. ¿y ustedes?

Seguimos pensando..

Buenas prácticas de negocios

2011-10-21T20:27:00.000-03:00

¡Qué importante es tener clientes con buenas prácticas de negocios!

Realmente es una ventaja porque todo se logra más fácil (pasar los malos momentos, multiplicar los buenos, hablar claramente, encontrar el mejor esquema para ambos, etc.).

También es un mérito porque los clientes se elijen al igual que se elijen los proveedores. “Uno tiene los clientes que se merece” escuché por ahí. Si tengo malos clientes

Y por último tenerlos resulta ser una obligación puesto que hay que estar a la altura de la confianza depositada.

Seguimos pensando..

PD: También hablé de este tema aquí y aquí.

No te relajes, estamos cerrando..

2011-10-18T09:16:00.001-03:00

Alguna vez escuché por ahí que el 90% de los proyectos están, el 90% del tiempo, al 90% de su avance. Es como si algunos equipos de trabajo quisieran rápidamente llegar a la etapa de cierre de proyecto para poder sentirse relajados y con el fin cerca. Hay situaciones donde la ansiedad es inevitable pero es importante trabajar sobre este punto pues corremos el riesgo de cometer dos errores críticos.

El primero es apurarnos por estar en un lugar distinto al real. Los proyectos deben ser vividos etapa por etapa. Cada una tiene su propia importancia, dinámica y razón de ser. Siempre digo que es conveniente empezar los proyectos con cierto sentido de urgencia pero de ahí a ser atolondrados hay cierta distancia.

El segundo es querer estar en el final para poder relajarnos. Estar en el cierre de un proyecto no significa "aflojar". La tensión de proyecto debe seguir. El foco debe mantenerse e inclusive incrementarse. El proyecto no se termina hasta que se termina, es decir, hasta que el o los stakeholders nos dan un ok formal al cierre (pregúntenle a los escoceses luego del partido con los pumas!).

Para cerrar les doy 3 pistas para darse cuenta si están "demasiado relajados" en el final de un proyecto:

Están pensando en liberar parte del equipo porque creen que no lo van a necesitar.
Ya están trabajando en el nuevo proyecto para ganar tiempo.
Corrieron algunas fechas y han pospuesto algunas tareas que consideran triviales dada la altura del proyecto.

Seguimos pensando..

El difícil arte de decidir quien está peor

2011-10-11T08:00:00.000-03:00

No pude evitarlo.

Dejo un pequeño hallazgo para aquellos que muchas veces se sienten atrapados en un trabajo que no pueden cambiar y creen que el resto del universo está mucho mejor.

Recomiendo leer esto y esto también, para equilibrar un poquito…

Seguimos pensando..

Breve aparición en Clarín

2011-10-08T19:22:00.001-03:00

Ejecutivos que dan clases: lo que hay que saber para ser docente. Argentina - 02/10/2011 - Clarín - Pág. 16/iEco - Tiempo de Lectura: 3' 31''

CARRERAS DE NEGOCIOS
Las universidades los buscan porque aportan experiencias concretas.
Pero, ¿alcanza con eso para ser un buen docente de negocios?

Aunque es imposible considerar la práctica disociada de la teoría o un hacer que prescinda del pensar, la demanda de programas y carreras "aplicables" recorre todo el espectro de la formación universitaria. En el caso de las carreras de negocios, y aún más en la formación ejecutiva, que los profesores desarrollen su práctica en los ámbitos corporativos es altamente valorado. Por eso, las universidades buscan ejecutivos que transmitan sus experiencias en las aulas.

Pero, ¿alcanza con la experiencia para ser docente universitario? Tanto los académicos como los propios ejecutivos sostienen que no. La cuestión es cómo se forman los profesores que provienen del mundo de la empresa y que carecen del recorrido habitual de quienes se dedican tiempo completo a la academia.

Alberto Franichevich, profesor full time del IAE, identifica tres aspectos que los ejecutivos necesitan desarrollar a la hora de pasar a las aulas: ampliar su perspectiva, para no transferir únicamente un tipo de experiencia (la propia); desarrollar la escucha activa, para poder preguntar y desafiar a los estudiantes, y hacer el ejercicio de encontrar a los alumnos en el punto donde ellos se encuentran para tratar de moverlos desde ahí hacia la reflexión.

"El IAE tiene un proceso de mentoría y observación de sus profesores: los acompaña, los observa y les da feedback, lo que los ayuda a corregir muchos aspectos de su práctica", dice Franichevich.

Mantenerse actualizado y sumar conocimientos son tareas básicas del ejecutivo docente. "No alcanza con leer un manualcito y decir que sabés de tal tema", sintetiza Ernesto Kiszkurno, socio en Pragma Consultores y docente en Exactas de la UBA.

En el mismo sentido, Facundo Echebehere, director de Asuntos Corporativos de Danone y docente en Economía para la toma de decisiones del MBA de la UADE, enfatiza que "es importante que el profesor le dedique tiempo a su formación: que aprenda cómo trabajar casos, cómo hacer presentaciones efectivas y que actualice su conocimiento".

En la escuela de negocios de la UADE, el 60% de los docentes son los llamados practitioners, es decir, ejecutivos que dan clases. "Lo que hacemos es utilizar los dos tipos de profesores en la misma materia: el que llamamos "académico" es el que la organiza y el practitioner es muchas veces el ejecutivo que fue protagonista del caso que se analiza en el aula y que da algunas de las clases del curso", explica Jorge del Aguila, rector de la UADE.

"El practitioner está acostumbrado a decidir", agrega el rector. "Maneja la misma información que el académico pero la evalúa en forma diferente. Eso le da adrenalina a la clase porque pone al alumno frente a los casos concretos".

"Tener ejecutivos como docentes es el mejor de los problemas que uno puede tener, especialmente cuando se trata de executive education ", dice Alejandro Bernhardt, director de la sede argentina de la escuela de negocios ESADE.

"Nuestros profesores hacen lo que enseñan y enseñan lo que hacen".

Para el directivo, es más fácil lograr que un ejecutivo de empresa sea un buen docente que darle a un académico la experiencia concreta. "En la carrera docente, con coaching, con cursos y con cierta habilidad natural, el ejecutivo adquiere las habilidades necesarias con relativa rapidez", asegura.

De todas maneras, advierte que la vivencia práctica no sustituye la formación académica. "Tendemos a que los docentes tengan una sólida formación teórica o científica y una rica experiencia en el área en la que enseñan también", dice.

Rubén Malvitano, socio de la División de Impuestos de Ernst & Young, es profesor regular en Económicas de la UBA. "Lo más interesante es que podemos transmitir en el aula lo que estamos desarrollando en el plano profesional. Es la mejor forma de mostrarles a los alumnos que lo que les estamos enseñando en la carrera es real", señala.

Gabriela Samela
«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
Por qué enseñan
*CASOS
*
"Dar clases me mantiene actualizado. También es un aprendizaje para mí, por lo que traen los alumnos", dice Facundo Etchebehere, director de Asuntos Corporativos de Danone y docente en la UADE.

"Si trabajás todo el tiempo, ir a la academia te genera la necesidad de revisar modelos y actualizarte. En mi caso, necesito que la materia sea demandante y entretenida para mí. Como exige tiempo y esfuerzo, lo más recomendable es dar clases en la materia y en los lugares donde uno encuentre satisfacción en hacerlo", señala Ernesto Kiszkurno, socio en Pragma Consultores y docente en Exactas de la UBA.

¿Agendamos una reunión o un espacio de trabajo?

2011-10-05T22:28:00.001-03:00

Un par de meses atrás, mientras estábamos sumergidos en uno de esos twisters laborales (periodos de mucho trabajo, a gran velocidad, donde no hay ni tiempo para encontrarse u ordenarse) que cada tanto aparecen, un compañero de trabajo y yo decidimos agendar un espacio de trabajo juntos.

El objetivo de ese espacio – que nosotros definimos como quincenal - era tener un momento de coincidencia física y espiritual, que íbamos a aprovechar para informar al otro sobre algún tema, trabajar sobre algún proyecto o sencillamente pensar/reflexionar.

Y la verdad es que la idea funcionó muy bien. Por un lado mejoró la calidad de nuestra interacción. Como era un momento esperado íbamos mejor preparados para tomar las decisiones o trabajar los temas. Por otro, el nivel de interrupción y la necesidad de interacción fuera de esos espacios disminuyó. Como teníamos ese momento fijo, había cosas que sencillamente esperaban.

Luego de algunas iteraciones se conformó una rutina muy sana. Logramos un algoritmo que nos permitía pasar por todos los temas en común velozmente. E inclusive, si no teníamos temas, nos sentábamos juntos a trabajar cada uno en lo suyo, aprovechándonos para otro tipo de consultas o intercambios.

La idea de ponerle un nombre distinto a algo que otro podría haber bautizado como una reunión de seguimiento, fue precisamente que no queríamos transformar ese momento en una reunión más. Queríamos generar reglas nuevas para esos encuentros que nos permitiesen pensar base cero la forma de interactuar y colaborar.

Seguimos pensando..

Muchos lugares donde trabajar, pocos donde aprender

2011-09-29T08:00:00.000-03:00

Hoy en Argentina hay muchas oportunidades de trabajo para los profesionales en informática. Esta situación les permite mejorar sus condiciones de empleo muy fácilmente. Casi sin tener que salir a buscar.

En la mayoría de los casos veo que el principal driver para cambiar es el económico. Esto es lógico por supuesto, pero creo que dada la alta demanda, hay otro que debería ser tenido más en cuenta: el de aprendizaje.

Haber pasado por ciertas situaciones, ciertos proyectos y/o ciertos lugares nos hace mejores profesionales. Nos posiciona mejor en el mediano y largo plazo de nuestra carrera.

Hay momentos en que es caro elegir ir a lugares donde aprender, otros en los que es barato. Cuando la demanda laboral es baja, los salarios bajan y el abanico de alternativas es más restringido. Cuando la demanda laboral es alta y los profesionales escasean y los empleadores están mucho más propensos a seducir.

Este es un momento particularmente bueno para elegir pensando en donde vamos a aprender más, creo que no tiene sentido desperdiciarlo. Entonces, si estás buscando donde trabajar, subile la prioridad a esos lugares donde hay gente de la que se puede aprender algo.

Seguimos pensando..

PD: Ah y por favor no seas desprolijo a la hora de decir que no pensando en que igual hay muchos otros lugares a donde ir, uno nunca sabe.

Hay que pagar por el output

2011-09-25T13:12:00.001-03:00

En el libro Personnel Economics, Edward Lazear define al salario como una compensación basada en el input en contraposición al piece rate que se basa en el output. El autor menciona tres puntos importantes relacionados con esta distinción:

Los esquemas basados en el input no hacen diferencia entre los trabajadores.
Los esquemas basados en el output incentivan a los trabajadores ineficientes a dejar la empresa.
El principal factor de decisión entre un esquema y el otro es el costo de medición o monitoreo. Cuanto más costoso sea medir el output, más propensa será la situación para adoptar un esquema basado en el input.

Muchos managers prefieren enfocar su energía en controlar que un trabajador está cumpliendo cierta cantidad de horas y/o ciertos horarios. Es decir, pagar por el input.

Esto en el mediano plazo es perjudicial cuando hablamos de trabajadores del conocimiento puesto que los buenos tienen a sentirse incómodos, poco valorados y perseguidos.

Como managers debemos intentar siempre buscar formas de pagar por output pues eso nos permitirá enfocarnos en los resultados, que en definitiva es lo que debería importarnos.

Seguimos pensando..

La previsibilidad es clave en la gestión de un proyecto

2011-09-21T08:00:00.000-03:00

Este post fue escrito para el blog Mejores Proyectos.

¿No les ha pasado estar liderando o gerenciando un proyecto y encontrarse en una situación problemática o tensa que sienten podrían haber evitado? Un gap de expectativas, un cambio de alcance, un stakeholder disconforme, una mala decisión, etc.

A mí me ha pasado y casi siempre, al hacer una retrospectiva del problema, encuentro que de alguna forma lo podríamos haber evitado.

Yo se que algunos lectores van a poner la excusa de que "con el diario del lunes todo problema es evitable" pero la verdad es que en algunos casos no es necesario ser clarividente para pisar esas pequeñas bolitas de nieve antes de que se conviertan en una grande.

Una de las herramientas clave para lograrlo es la previsibilidad. Esto es mantener a los stakeholders y miembros del equipo de proyecto, avisados, alertados o informados de lo que va a ocurrir y porque. He mencionado aquí el dicho "se pueden dar buenas y malas noticias pero no sorpresas" y en este caso aplica también.

Cuando logramos previsibilidad en un proyecto, evitamos sorpresas. Las cosas suceden naturalmente y, si bien puede haber contratiempos, todos sabemos que podían ocurrir, que ocurrieron, por qué ocurren y que perjuicio - relativo al proyecto general - tenemos a partir de ellos.

A continuación listo 5 formas concretas de aumentar la previsibilidad de un proyecto:

Cerrar las reuniones con un checkout para que todos sepan lo que se llevan y lo que tienen que hacer. Resaltar la importancia de aquellas acciones o tareas que son clave.
Confeccionar un reporte de avance que todos puedan leer rápida y periódicamente. Por ejemplo diciendo lo hecho, los que se va a hacer y los issues/riesgos actuales. Nadie puede poner la excusa "yo no estaba enterado".
Mantener reuniones breves con los stakeholders clave del proyecto (stoppers y facilitadores) para mantenerlos cerca del estado actual del proyecto y tener su feedback. Con aquellos más influyentes, redoblar el esfuerzo de mantenerlos informados.
Cumpliendo y haciendo cumplir las fechas comprometidas. En caso de no lograrlo, informando antes de vencido la fecha límite.
Marcando, en su justo término, los hitos importantes del proyecto. Por ejemplo informando sobre el cumplimiento exitoso de determinadas tareas o avisando de los problemas realmente importantes y de la forma en que se los está abordando.

Para terminar les dejo una imagen.

Piensen que van por la ruta a alta velocidad en un día soleado. No están llegando tarde, pero tampoco les sobra el tiempo. De repente ven que adelante hay un congestionamiento. Como está lejos por ahora no se preocupan. Luego, a medida que se van acercando, van desacelerando hasta llegar al congestionamiento en una velocidad ideal para maniobrar y no correr riesgos. Ahora piensen en la misma situación pero en un día con neblina.

¿Qué otras formas de aumentar la previsibilidad de los proyectos usan?

Seguimos pensando..

Trabajar en mejora de procesos tiene poco glamour, qué lástima!

2011-09-17T13:57:00.001-03:00

En el libro Creatina a Software Engineering Culture de Carl Wiegers encuentro la siguiente cita de Watts Humphrey:

The problems of [software] process change are often complicated by the fact that no one is responsible to make it happen. If [software] process improvement isn´t anybody’s job, it is not surprising that it doesn’t get done! If it is important enough to do, however, someone must be assigned the responsibility and given the necessary resources. Until this is done, [software] process development will remain a nice thing to do someday, but never today.

La razón por la que la palabra software está entre corchetes es porque si sacamos esa palabra el comentario sigue teniendo sentido.

La cita me hizo pensar en dos cosas que veo muy a menudo en organizaciones, áreas y hasta equipos de trabajo:

A pesar de tener claro que los procesos deben ser trabajados o mejorados, se toma la cómoda posición de que en realidad los procesos son un problema de todos y por ende debería haber un abordaje conjunto del problema, sin un responsable claro. El resultado es que nadie lo tiene como prioridad, cumpliéndose lo que la cita dice.
Tal vez debido a que es difícil cuantificar su impacto en el “bottom-line”, se tiende a dar poco reconocimiento al trabajo en procesos. A partir de este escaso glamour, pocos están interesados en tomar el desafío y menor todavía es el apoyo de las demás personas al proyecto, cuando alguien lo hace.

Una lástima que sea así, a pesar de lo intangible, pequeñas mejoras de procesos pueden redundar en importantes mejoras en costos, time-to-market y hasta en el nivel de estrés de las organizaciones.

Seguimos pensando..

Usando bien nuestro tiempo

2011-09-10T12:26:00.001-03:00

¿Que pasaría si alguien viene y pone en duda la forma en que invierten su tiempo?

Imagínense que lo hace alguien relevante para nosotros (por ejemplo un jefe o un empleador), que lo hace correctamente y que lo hace con motivos totalmente constructivos.

¿Es razonable enojarse u ofenderse?

En mi opinión no. En todo caso es una pregunta valida sobre la que se puede reflexionar para luego responder. Si respondemos bien, convenceremos a la persona de que lo estamos haciendo bien y si no, tal vez el ejercicio nos aporte pistas de por qué está ocurriendo.

Pero ¿cómo se responde?

La respuesta tendrá que ser en términos de nuestras prioridades y el tiempo que dedicamos a cada una de ellas. Usamos bien nuestro tiempo si le damos más espacio en nuestro calendario a las cosas que son más importantes para nosotros y menos a las otras.

Siguiendo con la idea, ¿cómo sabemos a que dedicamos el tiempo?

Algunas personas registran sistemáticamente a que dedican su tiempo. Este hábito no es sencillo de mantener a lo largo del tiempo pero resulta extremadamente útil a la hora de entender si estamos haciendo las cosas bien o no, rendir cuentas y estimar.

Peter Drucker en su libro El ejecutivo eficaz, que ya mencioné en el post La efectividad como competencia clave, sostiene que el activo más preciado de un ejecutivo es su tiempo y por consiguiente debe ser cuidadoso en su uso.

Un buen punto de partida para trabajar el uso del tiempo es el podcast de Manager Tools llamado The Basics of Calendar Management. Entre otras cosas explican como hacer un “Drucker Analysis”, es decir una evaluación rigurosa de cómo estamos usando nuestro tiempo. Lo interesante para mi de esta idea es que no necesariamente debemos registrar siempre nuestro tiempo. Podemos hacerlo durante un tiempo, sacar conclusiones y mejorar.

Para terminar les dejo una pregunta sin respuesta: ¿están usando bien su tiempo? Si están leyendo esto definitivamente sí …

Seguimos pensando..

Otra víctima de la impuntualidad y van...

2011-09-04T13:30:00.001-03:00

En las últimas semanas he sido víctima de la impuntualidad en repetidas ocasiones y en distintos ámbitos. Nada terrible, unos minutos aquí, media hora allá y hasta cuarenta minutos en alguna. Tampoco voy a pararme en el olimpo de los dioses de la puntualidad que nunca llegaron tarde a ningún lado. Si bien suelo ser puntual, a veces puede fallar.

Obviamente hay casos en que existe una razón que justifica perfectamente la demora pero en otros realmente no. Por ejemplo puede ser un caso aislado de alguien que accidentalmente se retrasó o puede ser un caso más de alguien que sistemáticamente llega tarde. Podría ponerme a analizar si llegar tarde está bien, mal, justificado o injustificado, pero la verdad es que quería reflexionar un poco en el otro lado:

¿Qué me pasa a mi cuando alguien con el que tenía una reunión se retrasa (o peor, no viene)?

Creo que pensar en el abanico de emociones por las que la víctima pasa (sí suena un poco teatral llamarla así, no?) no sólo le sirve a ella, sino también a la otra parte. En el caso de la primera, le permite manejar mejor la situación de modo de no afectar el resultado de la reunión por este mal comienzo y en el caso del "impuntual" puede servir para manejar con mayor empatía ese momento también.

Veamos..

La primera sensación es la duda. ¿Era a esta hora o no? ¿Era en este lugar o no? ¿Me confundí de día?
Luego de chequear y re-chequear que no hemos cometido un error, viene la segunda sensación, la ansiedad. ¿Por qué no viene? ¿Le habrá pasado algo? ¿Habrá cancelado y yo no me enteré? ¿Si no tenemos la reunión hoy cuando la haremos? ¿Cuál es el impacto de no tener la reunión?
La tercer sensación es la impaciencia. Pensamientos como "si no iba a venir me debería haber avisado" o "mi tiempo también es importante también" saltan a la mente. "Ya llevo media hora aquí (cuando en realidad pasaron 3 minutos)".

En este punto llegamos a una encrucijada de 3 caminos para nuestra reunión: cancelación por ausencia, llegada sin disculpa o llegada con disculpa. Sólo si la reunión transcurre por el tercero podemos evitar la cuarta sensación, el enojo.

Repasemos los tres caminos:

Si la persona no llega es obvio que no lograremos los resultados esperados para la reunión y que la presentación de algún tipo de explicación es mandatoria. El enojo se hace presente rápidamente pues no olvidemos que no es una cancelación "a tiempo" y la víctima ya tuvo un costo.
Si la persona llega y no se disculpa el enojo aparece también y, dependiendo de para qué era la reunión, se hace presente ya en el primer comentario por lo que los resultados esperados peligran[1].
Si la (o las) persona(s) llegan [2] y dan una explicación razonable y correctamente expresada, tal vez la situación se remonte y la reunión finalmente produzca el resultado esperado. Expresar correctamente la explicación tiene que ver con realmente sentir lo que se dice y no usar sólo una frase hecha para salir del paso. Este es el único camino que tal vez no termine en enojo.

En este punto es bueno decir que la víctima puede (o debe) manejar la situación con profesionalismo y lograr los resultados de la reunión aún estando enojada. Más allá de lo que el impuntual haga o deje de hacer, la buena noticia es que podemos lograr los resultados que esperamos de la reunión si logramos pasar a la quinta emoción, la tranquilidad [3].

Me intriga saber cómo manejan ustedes este tipo de situaciones y cuál es su sensación respecto al tema en sus ámbitos de trabajo.

Seguimos pensando..

[1] En mi opinión hay muy pocas situaciones en las que realmente se justifique llegar tarde y no decir nada al respecto. Sin embargo, y suponiendo que esto no fuera cierto, estoy casi seguro que esta estrategia no es recomendable cuando vamos a una entrevista laboral, visitamos a un potencial cliente por primera vez o atendemos a un proveedor importante por primera vez.

[2] Nadie dijo que estuviéramos solos esperando o que el "impuntual" fuera una sola persona.

[3] Los que no me conocen podrían sugerirme no abandonar nunca la tranquilidad ... pero bueno..

El mandato del CIO

2011-08-29T21:05:00.001-03:00

Me encontré días atrás con un estudio muy interesante realizado por IBM Institute Business Value sobre 3.000 directores de tecnologías de la información con el objetivo de entender su rol y caracterizarlos.

El estudio comenta que, luego de analizar las respuestas de los CIOS, pudo determinar 4 patrones “que identifican distintos enfoques al liderazgo de TI en base a las necesidades y objetivos concretos de una organización”. Esto son

Potenciar. Estas organizaciones ven las TI como un proveedor de servicios tecnológicos fundamentales. A sus CIOs se les pide que aprovechen las TI para hacer más eficientes las operaciones con el fin de obtener una mayor eficacia de la organización.
Expandir. Este mandato, bastante generalizado, incluye a las organizaciones que esperan que los CIOs gestionen un conjunto equilibrado de responsabilidades que van desde las fundamentales hasta las visionarias. Sus CIOs lideran las operaciones TI que ayudan a expandir las capacidades de la organización refinando los procesos de negocio y mejorando la colaboración a nivel de empresa.
Transformar. Las organizaciones con este mandato ven las TI principalmente como proveedores de soluciones sectoriales para cambiar el negocio. Estos CIOs tienen a su cargo ayudar a transformar la cadena de valor sectorial mejorando las relaciones con clientes, partners y clientes internos.
Explorar. Aquí, las organizaciones ven predominantemente las TI como un factor crítico de la visión de la empresa/organización. Este grupo de CIOs está invitado a ser pioneros o a radicalmente rediseñar productos, mercados y modelos de negocio.

Estos enfoques, además de permitir entender las distintas líneas de trabajo del rol del CIO, permiten relacionar la estrategia de la empresa y su relación con la estrategia de TI. De esta forma es posible distinguir mandatos bajados del CEO al CIO:

Otro punto interesante marcado por el estudio es la creciente alineación entre las prioridades del CEO y del CIO.

Seguimos pensando..

Una mirada más integradora del management

2011-08-25T08:00:00.000-03:00

El otro día leí un buen artículo de Ana Falbo en El Cronista llamado La gestión rompe con los cisnes blancos en el que se describen algunos cambios de paradigma dentro de lo que usualmente se denomina como “el mundo de management”.

En particular, hay dos que me parecieron interesantes.

De una visión económica a una visión integradora

El artículo plantea la existencia de un cambio desde una visión centrada en lo económico a otra más integral y relacionada con la ética y la responsabilidad social empresaria:

Estos cambios están transformando el management e impulsando a las empresas a pasar de una visión puramente económica a una visión integrada. “Más allá del beneficio para los accionistas, las empresas comienzan a tener responsabilidades con los empleados, el staff, los asesores, los clientes, los distribuidores, los proveedores y, además, con una serie de instituciones de investigación, organizaciones sin fines de lucro, organismos periodísticos y hasta funcionarios, comenta Armando Bertagnini, profesor y director Académico del Programa Gerencial de Negocios de la Universidad de San Andrés. Y agrega: “Esto significa un cambio importante porque ya no se trata de una visión microeconómica en donde importa la remuneración y la ganancia, sino que es una mirada integradora”.

Me gusta esta visión integradora pues me parece de más largo plazo en contraposición con la económica que tiende a ser de corto. En Argentina se ve mucho esta dicotomía donde los beneficios inmediatos triunfan por sobre políticas y/o decisiones que hoy traen más costos pero que en el largo plazo permitirán un crecimiento más sano y sustentable.

Las estrategias genéricas no son casilleros sino ingredientes para mi estrategia

El otro punto interesante, sobre el cual coincido desde hace tiempo, es el de que es un error encasillar el posicionamiento de nuestra empresa:

Las nuevas experiencias y el contexto actual también llevaron a las empresas a buscar otra forma de enfocar y definir sus estrategias. Según Bertagnini, el concepto de estrategia que se manejaba a nivel empresarial ya no es aplicable. “Michael Porter estableció que las compañías buscan posicionarse en base a costos (hacer más a menor costo) o diferenciación (hacer menos con más valor), pero el mundo cambia y ya no se trata de costos o diferenciación, sino de "costos y diferenciación", hacer más a menor costo y ofreciendo más valor, explica”.

Las estrategias genéricas hoy en día son una guía para entender en qué quiero hacer énfasis. Es un error pensar posiciones estáticas (aún tan solo por un año). El secreto es definir el mix de cada una de ellas que formará mi estrategia. Siendo prácticos, hay que verlas como porcentajes que además deberán revisarse muy periódicamente.

Seguimos pensando..

Una mirada audaz sobre las reuniones

2011-08-22T08:00:00.000-03:00

En estos días estuve leyendo el libro Read This Before Our Next Meeting de Al Pittampalli publicado por The Domino Project de Seth Godin en una modalidad muy original que ya describí aquí.

En él se postula una nueva clase de reuniones: the modern meetings. El autor dice:

Traditional meetings are treated as just another form of communication. Just another item to be included in the same category as e-mail, memos, and phone calls. That’s an error in judment.

Meetings are too expensive and disruptive to justify using them for the most common types of communication, like making announcements, clarifying issues, or even gathering intelligence.

Like war, meetings are a last resort.

The Modern Meeting is a special instrument, a sacred tool that exists for only one reason:to support decisions.

Si bien me parece interesante el concepto y también el protocolo a seguir que propone el autor, no estoy del todo de acuerdo con esta idea de que las reuniones solo deban ser usadas para soportar decisiones.

Las reuniones son caras y, mal usadas pueden ser un golpe mortal a la productividad de un equipo, de un área y/o de una organización. Sin embargo creo que bien usadas y moderadas pueden ser una herramienta muy eficaz en el trabajo. Por poner un ejemplo, el Kick-off de proyecto para un equipo de 5 o 6 personas resulta mucho más eficaz hacerlo mediante una reunión que hacer el anuncio individualmente o por medio de un correo.

Mi sensación es que la clave no está en pensar en términos de si o no. Hay que pensar en cuánto tiempo duran, cuántas es sano tener, quiénes deben asistir a cada una y qué hay que hacer antes, durante y después de cada una de ellas.

Seguimos pensando..

PD: El libro es cortito y vale la pena leerlo.

Volviendo a dar clases

2011-08-18T08:00:00.000-03:00

Hoy empiezo a dar clases nuevamente en mi facultad. Voy a estar dando durante todo este cuatrimestre una materia optativa llamada Gestión de Proyectos y Procesos de Software. Por lo que estuve viendo la cantidad de inscriptos es buena y eso me tiene muy contento. Vamos a ver cómo nos va.

Dejo el link al sitio de la materia que iré actualizando y mejorando de a poco.

Seguimos pensando..

Crossing the Chasm

2011-08-15T08:00:00.000-03:00

Heinz Weihrich, autor del libro Management, define gestionar como:

Hacer las cosas a través de otros

Empezamos a gestionar en el momento en el que ya no nos alcanza nuestro propio tiempo para hacer todas las tareas que nos encomiendan y debemos depender de otros para lograrlas.

Tomo prestado el título del excelente libro de Geoffrey Moore para explicar lo que creo sucede en ese momento: Hay un abismo y debemos cruzarlo.

Para algunos pocos este paso no es gran cosa, pero para otros representa un salto importante (un abismo) en la forma de trabajo y en el nivel de estrés. Y digo que debemos cruzarlo porque la situación de no hacerlo no es sostenible en el tiempo en un trabajo normal.

Como en estos días estuve conversando sobre el tema con algunos colegas y leyendo cosas relacionadas, me permito dar cuatro consejos:

No intentes cubrir con más tiempo la incapacidad de delegar a otros ciertas tareas. Todos en algún momento colapsamos siguiendo esa estrategia. Y cuando digo todos, lo digo por experiencia propia.
No intentes saltar el abismo de una sola vez. La sensación de falta de control sobre lo que sucede y de no estar haciendo nada puede ser complicada de manejar. La mejor estrategia es cruzar el abismo de a poco soltando primero aquellas actividades que más conocemos y que por consiguiente vamos a poder controlar/monitorear desde lejos más fácilmente.
No intentes cruzar sin preparación. Hay muy poca gente que lo logra sin entrenamiento. Pedir ayuda para cruzar no es malo, al contrario. Hay gente que ya cruzó y sabe por donde pisar. Hay libros y técnicas para hacerlo. Todo eso suma.
No “quemes las naves”. Deja siempre mecanismos o formas de volver hacia atrás por dos razones: (1) A veces las cosas salen mal y es necesario (2) un buen manager/gestor tiene que poder hacer la mayor parte del trabajo de sus subordinados.

Seguimos pensando..

Interrupciones

2011-08-13T22:50:00.001-03:00

Del libro “La quinta Disciplina” de Peter Senge:

En uno de nuestros recientes programas sobre Liderazgo y Dominio, hablé con una ejecutiva nacida y criada en la India, quien ha trabajado en firmas americanas y japonesas. Comentaba que, en una firma japonesa, nadie interrumpe a una persona que está sentada en silencio. Se da por sentado que esa persona está pensando. Por otra parte, cuando la persona está en pie y en movimiento, los colegas se sienten en libertad de interrumpir.

Y añadió: “Es curioso, pero en las firmas americanas ocurre exactamente lo contrario. En los Estados Unidos, entendemos que una persona sentada en silencio no está haciendo nada importante”.

Seguimos pensando..

La regla de las 10.000 horas

2011-08-11T20:14:00.001-03:00

Una de las cosas más interesantes del libro Outliers: The Story of Success de Malcom Gladwell es la afirmación que hace sobre la cantidad de tiempo que una persona debe invertir para volverse realmente bueno en su profesión: 10.000 horas. Él la llamó, sorpresivamente debo decir, la regla de las 10.000 horas.

Haciendo algunas cuentas llego a que esto significa como mínimo 4,6 años de trabajo ininterrumpido en ese campo para dominarlo realmente. Básicamente, 10.000 dividido 8 horas nos da 1250 días, dividido 270 (la cantidad aproximada de días laborales en un año) nos da 4,62 años.

Alguna vez te pusiste a pensar ¿cuántas horas llevas invertidas en tu profesión? ¿Sabes realmente cuál es tu profesión? ¿Te parece que la regla se cumple?

Seguimos pensando..

PD: El libro vale la pena, léanlo!!

2 años

2011-08-08T09:22:00.001-03:00

Un año más de “seguir pensando”. Un año más para esta aventura de escribir sobre temas relacionados con la profesión (aunque a veces ya no tenga claro cuál es mi profesión).

Y como el año anterior uso este post simbólico para agradecer mucho a la gente que visita el blog, y un poquito más a los que lo “siguen” y un poquito más aún a los que comentan. El tiempo es algo muy valioso en estos días y que me dediquen algunos minutos por semana es un gran halago.

Seguimos pensando..

Breve nota en iProfesional

2011-08-03T16:07:00.001-03:00

Se publicó una breve nota titulada Cuáles son los principales desafíos de los Centros de Servicios Compartidos en www.iProfesional.com.

Seguimos pensando..

Escuelas de Pensamiento sobre Estrategia

2011-08-02T09:13:00.001-03:00

En una nota escrita por Booz & Co y publicada en la revista Gestión de Mayo – Junio 2011 titulada The right to win se mencionan cuatro cuadrantes de pensamiento estratégico que permiten clasificar a varios de los pensadores más importantes de los últimos 30 años.

El artículo es interesante por dos razones. El primero es que explica los motivos de surgimiento y los problemas de cada una de las escuelas. Segundo puntualiza algo que muchas compañías no entienden: definir e implementar una estrategia es un proceso continuo (una conversación organizacional) y no un ejercicio para hacer una vez al año.

Seguimos pensando..

Voy a implementar calidad en mi empresa

2011-07-30T12:34:00.001-03:00

El otro día me dijeron "voy a implementar calidad en mi empresa". “Bárbaro” dije yo y luego pregunté “pero qué significa eso para vos?”. “Certificar ISO 9001” me contestaron.

A partir de ese intercambio casual breve me quede pensando y concluí que sí, ciertamente ese es un enfoque posible. ISO 9001 permite organizar y estructurar toda una seria de iniciativas relacionadas con calidad y al final obtener un reconocimiento del logro visible desde el mercado. Igualmente, siguiendo esa línea de pensamiento se me ocurre preguntar con que alcance (algunos procesos o toda la empresa) y para qué (sólo para mejorar, para ganar nuevos mercados, por posicionamiento, para disminuir costos o un poco de todo).

Pero implementar calidad puede (o debería?) significar otras cosas también. En realidad a mi me gusta más pensar en gestionar la calidad. Y eso, según la trilogía de Juran significa: Planificar el nivel de calidad al que queremos llegar, controlar la calidad producida y mejorar la calidad.

Y agrego un término más: Gestionar la Calidad Ágilmente. Es decir, hacerlo jugando con objetivos más pequeños y prácticos, sin caer en proyectos faraónicos que logran resultados visibles a toda la organización luego de mucho tiempo. Ejemplos de este tipo de acciones pueden ser:

Implementar controles cruzados en los procesos de trabajo
Implementar un programa de mejora continua
Implementar un programa de métricas y un tablero de mandos
Definir planes anuales por área y seguirlos
Implementar un encuesta de satisfacción de clientes (o una de clima interno)
Etc.

Mejorar la calidad significa siempre producir un cambio cultural en la empresa y eso requiere lograr retroalimentación positiva rápida (quick-wins) en las personas. No es posible mejorar la calidad sin compromiso de todos. Es por eso que creo que una estrategia de trabajo más ágil con acciones concretas, cortas, realizadas por personas de todos los niveles y orientadas en una misma dirección más general resulta más eficaz.

Resumiendo, lo importante es definir que significa calidad a cada nivel (para la empresa como un todo, para cada área, para cada rol, para cada proceso de negocio, para nuestros clientes, para nuestros empleados) y luego trabajar en la implementación de manera planificada y sistemática pensando en que es más importante mantener el ritmo dando pequeños saltos que ir por todo de una vez.

Seguimos pensando..

Escribiendo procedimientos claros

2011-07-25T20:55:00.001-03:00

El otro día encontré en un libro de ejercicios para aprender inglés que se trataba el tópico de cómo escribir procedimientos claros [en inglés]. En particular hubo un ejercicio que me gustó pues pedía diferenciar los “dos” y los “don’ts” (lo que hay que hacer y lo que no hay que hacer) en esta lista que les transcribo a continuación:

Use long sentences
Prefer active verbs
Be direct – use imperatives
Use long words
Use abbreviations or acronyms
Be consistent with terminology
Remember the reader – do not assume they know certain information
Put steps in the right sequence
Use headings and split information into chunks
Use 1, 2, 3, and not one, two, three or first, second, third

Pensemos lo que opinamos de estas sugerencias en el contexto de escribir casos de prueba y/o incidentes de prueba claros y simples: ¿Cuales serían para ustedes sugerencias para respetar y cuales no?

Seguimos pensando..

Charla de Calidad de Software en Santa Cruz de la Sierra, Bolivia

2011-07-20T19:39:00.001-03:00

Siguiendo con mi movida agenda del segundo trimestre del año, la semana pasada estuve hablando sobre calidad de software en Santa Cruz de la Sierra, Bolivia. Saludos a los participantes y gracias por el interés demostrado.

Seguimos pensando..

PD: Aprovecho para agradecer al dios de las cenizas que me permitió ir y venir casi sin contratiempos.

El botón rojo del proyecto

2011-07-18T08:00:00.000-03:00

Este post fue escrito para el blog Mejores Proyectos. Imagen de Flickr por DumbleDad.

A lo largo de nuestra carrera profesional todos, tarde o temprano, formaremos parte de un proyecto que falla. En algunos casos será solo un pequeño sabor amargo al final del mismo, en otros será una sensación de derrota total. Pienso que es sólo cuestión de tiempo antes de que nos toque y estará en nosotros la forma en la que nos levantamos de esa caída y lo que logramos aprender de ella.

Dado que es inevitable que ocurra, la pregunta es entonces ¿qué hacemos para mitigar el impacto de una caída así?

Obviamente, la respuesta dependerá enormemente del contexto de cada proyecto pero hay algo que creo que es universal y que sirve para casi cualquier proyecto donde debamos participar: una vez visualizado el fracaso hay que cortar el proyecto lo antes posible. Hacer esto ahorrará costos tanto para nosotros como personas, para el equipo de trabajo y también para la organización.

A partir de esta idea es que creo que todo proyecto debe tener un botón rojo de cancelación de proyecto.

Y ¿qué es eso? Pues nada más ni nada menos que un procedimiento claro de cuando nosotros, como gerentes de proyectos, propondremos la cancelación. Obviamente que luego el comité de proyecto decidirá si acepta esta propuesta o no, pero es importante que nuestra posición sea clara.

Por experiencia además les digo que siempre es más difícil pensar en esto una vez que la crisis se ha desatado. Lo ideal es tratar de prever la mayor cantidad de situaciones antes, al momento de la planificación. Lo ideal es que el procedimiento tenga criterios claros al menos sobre 5 puntos:

Qué situaciones tendrán como consecuencia la cancelación (lo que dispara el procedimiento).
Quién podrá presionar el botón.
Cuándo podrá ser presionado.
Quiénes tomarán la decisión final.
Qué pasará luego de tomada la decisión.

Los que crean que la similitud de esta idea con Business Continuity Planning es pura casualidad, están equivocados. ;-)

Seguimos pensando..

Confusión de calidad

2011-07-15T08:00:00.000-03:00

Hace tiempo en esta ECI escuché decir que mucha gente confunde QA con testing. Coincido. Es común escuchar hablar a las personas de QA cuando en realidad están hablando de Testing de Software solamente (Quality Control). De hecho hay áreas llamadas “QA” que en realidad lo único que hacen es 0testing.

Pero la confusión no termina allí, enumero otras que también he visto que se repiten:

Testing con Testing Funcional
Testing Funcional con Testing Funcional Manual

En algunos casos es una forma simplificada de hablar. En otros, refleja una mirada estrecha de lo que en realidad podemos hacer para mejorar la calidad del software:

Testear manualmente y automáticamente la funcionalidad.
Testear aspectos no funcionales además de los funcionales.
Hacer otras actividades para controlar la calidad del producto además de testing. Por ejemplo revisiones por pares.
Trabajar sobre la calidad del proceso (QA) además de hacer control de producto.

Más allá de la variedad de actividades que hagamos para planificar, medir y mejorar la calidad, es importante tener claro “el todo”.

Seguimos pensando..

Un video para mostrar el costo de la calidad

2011-07-12T19:51:00.001-03:00

Un colega me pasó el link de este video acerca del costo de la calidad o, mejor dicho, de la no calidad.

Estos videos definitivamente nos sirven para seguir pensando.

La efectividad como competencia clave

2011-07-09T20:21:00.001-03:00

En el primer capítulo del excelente libro El ejecutivo eficaz, Peter Drucker habla de la necesidad de efectividad en los negocios y en los hombres de negocio. También dice que tanto el conocimiento como la creatividad son características encontrables en los trabajadores del conocimiento (él los llama “ejecutivos”), pero no así la efectividad:

"La inteligencia, la imaginación y el saber son esenciales, pero únicamente la efectividad los convierte en resultados."

Esta es una época totalmente dirigida por los resultados. Las buenas ideas no traducidas a resultados no sirven. La inteligencia sin resultados no sirve.

Aquellos que logren aprender cómo ser más efectivos tendrán un plus grande en la carrera por diferenciarse. Drucker dice en el libro que la efectividad puede aprenderse, yo digo que hay que pensar la efectividad como un hábito a cultivar.

Seguimos pensando..

Nota 1: El libro es una excelente fuente de tips para lograr esto último.

Nota 2: BJ Fogg, a quien escuché en el último HSM de Buenos Aires (aquí una reseña de Juan Carlos Lucas su charla), me dejó 3 pistas de cómo generar hábitos: (1) empezar muy pequeño (2) buscar un espacio de tiempo para hacerlo (3) entrenarse en el ciclo (automatizar).

Nota 3: Una referencia obligada a la hora de hablar sobre efectividad y hábitos productivos es David Allen.

Evento de Calidad de Software en Montevideo, Uruguay

2011-07-07T08:00:00.000-03:00

(y siguen los anuncios)

Ayer estuve hablando sobre estrategias de armado de áreas de control de calidad en áreas de sistemas en un evento organizado por Pragma en Montevideo, Uruguay.

Seguimos pensando..

Charla sobre Testing de Software en UADE

2011-07-06T09:11:00.001-03:00

El lunes pasado tuve la oportunidad de dar una charla sobre Control de Calidad en el posgrado de Tecnología de la Información de la UADE. Fue interesante compartir con los alumnos de allí mis impresiones sobre el nivel de madurez de las prácticas de testing en el mercado argentino.

Seguimos pensando..

Hay que aguantar al público..

2011-07-02T08:00:00.000-03:00

Cuando uno da una presentación en público debe estar dispuesto a soportar, como mínimo, al público. :-) Sí, un ítem más para la lista de cosas que parecen obvias pero que en realidad no lo son tanto.

No se puede pretender que toda la gente asista muda y extasiada a lo que uno dice. En cualquier presentación habrá gente que nos escuchará con interés y otra que no. Y lejos de preocuparnos por el primer grupo, debemos ser cautelosos con el segundo.

A continuación menciono 4 arquetipos sobre los que conviene estar prevenido:

El preguntón. Como su nombre lo indica esta persona se caracteriza por hacer preguntas fuera de tiempo (a veces sin sentido) durante gran parte de la presentación. El problema con él es que corta el ritmo y a veces exaspera tanto al auditorio como al presentador. Mi consejo aquí es marcar un límite a las preguntas ofreciendo un espacio al final de la charla para conversar.
El “figureti”. Esta persona también hace preguntas pero no con el objetivo de despejar sus dudas, sino para demostrar a la audiencia y al presentador que él sabe más y que sólo esta ahí porque alguien (o algo) lo ha obligado. El problema es similar a 1 con la diferencia de que puede ser más complicado poner un límite porque esta persona en realidad no está esperando una respuesta. Mi consejo aquí es “no engancharse” en una discusión, agradecer el comentario y avanzar. Eventualmente, hacer lo mismo que en 1.
El cansado. La persona en cuestión es fácil de reconocer ya que va deslizándose de la silla hacia abajo medio dormida a medida que la presentación avanza. La verdad es que más que un problema esta persona es un riesgo, porque detrás de cada cansado hay un potencial figureti o preguntón. Mi consejo, cambiar de tono durante la charla con la esperanza de que eso lo despierte.
El conversador. Este arquetipo se caracteriza por conversar con otro en voz más bien alta. Dependiendo del tamaño del lugar y de la cantidad de gente este arquetipo puede generar varios problemas: distraer al presentador, contagiar a otros o exasperar a los demás. Mi consejo es darle la palabra para que pueda hacer su aporte y luego seguir.

En definitiva, como dice Nancy Duarte en Slide Ology, hay que responder a las necesidades de la audiencia.

Seguimos pensando..

Primero pensar en la estrategia de pruebas, luego escribirla

2011-06-29T08:00:00.000-03:00

(Imagen de Flickr por jotacentrica)

Hace un tiempo atrás escribí este post sobre la importancia de pensar en la estrategia de pruebas en ciertos proyectos. Esta semana, gracias a Ariel, pude leer un post titulado Basics Revisited: Test Strategy que está muy alineado con lo que escribí en aquel momento y con lo que pienso sobre la problemática.

Si bien vale la pena leer el artículo, extraigo 6 lecciones importantes:

Pensar en la estrategia, no en el documento. No burocratizar el proceso.
Arrancar con diagramas y esquemas, no con el template de documento.
Procurar poner la estrategia en una página.
Pensar en para qué testeamos y qué testeamos.
Los stakeholders deben ser parte de las decisiones tomadas y deben conocer los riesgos que asumen.
Comunicar la estrategia antes para que los que quieran puedan opinar.
No enamorarse de la estrategia, cambiarla de acuerdo a la evolución del proyecto si es necesario.

Como siempre digo lo importante es vivir el proceso de armar la estrategia y no tanto el documento que queda al final.

Seguimos pensando..

No me gustan los árboles frondosos, cuando hablamos de tareas

2011-06-26T10:30:00.001-03:00

(Imagen de Flickr por chalo84)

Continuando con lo que hablaba en aquí sobre tareas, quiero hablar un poco sobre la estructura proyecto-tarea.

Como algunos de ustedes habrán notado, hay algunos programas para gestión de tareas que permiten organizarlas en forma de árbol. Esto es armar jerarquías sin un límite de niveles determinado del estilo:

Ítem 1
- Ítem 1.1
  - Ítem 1.1.1
  - Ítem 1.1.2
- Ítem 1.2

Esto, que a priori parece ser visto como una ventaja, a mi criterio puede ser una gran desventaja para los seguidores de GTD. Y lo digo principalmente porque va en contra del factor clave del método que es la simplicidad. Enuncio a continuación algunas de las complicaciones que este tipo de estructuras anidadas provocan en una lista de tareas:

El concepto de proyecto se hace más complejo. Dado que puedo anidar ítems en la jerarquía puedo tener sub-proyectos dentro de sub-proyectos dentro de proyectos. En este contexto, ¿qué significa terminar un sub-proyecto?
El concepto de tarea podría complicarse también. ¿Qué pasa si tengo una sub-tarea dentro de una tarea? ¿Es un proyecto en realidad o es solo una tarea compleja?
El concepto de próxima acción de un proyecto se hace difuso. El ítem 1.1.1 del ejemplo ¿es la próxima acción del ítem 1 y del ítem 1.1? ¿O sólo lo es de el ítem 1.1?
Nos queda la puerta abierta para hacer un abuso de la división en tareas. Es muy fácil caer en la tentación de tener 4 o 5 niveles de tareas que hacen inmanejable nuestra lista ya que terminamos perdiendo más tiempo en el armando de complejas estructuras de tareas en lugar de dedicarnos a lo primordial que es Getting Things Done.

En resumen, soy partidario de tener dos niveles únicamente en la lista de tareas. Es decir tener algo como lo que muestro a continuación:

Proyecto 1
- Tarea 1.1
- Tarea 1.2
Proyecto 2
- Tarea 2.1
- Tarea 2.2

De esta forma, mantenemos la lista simple, los conceptos de proyecto, tarea y próxima acción (rojo) bien claros y siempre sabemos para qué proyecto estamos trabajando cuando ejecutamos una tarea.

¿Ustedes qué prefieren? ¿Qué ventaja le ven a los "árboles frondosos"?

Seguimos pensando..

Ideas sobran, voluntad falta

2011-06-21T22:33:00.001-03:00

Hoy hablaba con un colega frustrado que me decía "estoy cansado de los cobardes" refiriéndose a esa gente que primero pide desafíos y luego, cuando se les dan, no los toma como propios y prefiere esconderse en excusas.

Mientras escuchaba recordé un ensayo de Seth Godin llamado The Will and the Way que se publicó en el libro Purple Cow. Extraigo el primer párrafo aquí:

"I don't think there's a shortage of remarkable ideas. I think your business has plenty of great opportunities to do great things. Nope, what's missing isn't the ideas. It's the will to execute them."

Godin habla de ideas, mi colega de responsabilidades y desafíos. Para mi están hablando de lo mismo. El saber popular ha registrado la misma enseñanza con otras dos frases muy conocidas: (1) del dicho al hecho, hay mucho trecho (2) es más fácil decir que hacer.

Muchas veces no se trata de talento o de creatividad, aunque tener estas cosas hace el camino mucho más fácil, sino de perseverancia, tozudez y voluntad.

Seguimos pensando..

Buscar el 10 al construir software tiene sus riesgos

2011-06-16T09:34:00.001-03:00

Yo sé que me voy a ganar algunos enemigos con este post pero ya llevo mucho tiempo con esta idea dándome vueltas en la cabeza y creo que ya es tiempo de que salga. Necesito escribiría o por lo menos empezar a enunciarla y escuchar opiniones por supuesto. :-)

En mi trabajo cotidiano es común encontrarme con excelentes desarrolladores, personas inteligentes, preparadas y experimentadas. Excelentes técnicos va. Pero que [muchas|algunas] veces caen en una pequeña confusión. Se enamoran de la programación en si misma perdiendo de vista el verdadero fin de la actividad que es crear software a un costo y en tiempos razonables que pueda usar el usuario.

No sostengo que buscar la excelencia sea algo malo, para nada. Está muy bien lograr un buen diseño, tener un buen modelo y trabajar con la mejor tecnología posible pero siempre teniendo en claro el contexto en el que nos movemos y las limitaciones que tiene cada proyecto. Veo muchas veces desarrolladores empecinados en construir el mejor software de la historia en lugar de construir un software suficientemente bueno respetando los costos y los tiempos que el proyecto impone.

Es justo decir también que a veces el usuario/cliente no colabora a la hora de mantener todo dentro de los parámetros fijados pero ese es otro problema en el que seguramente estaremos de acuerdo: ¿cómo hacer para que el usuario/cliente no conspire contra el logro de los resultados?

Ese otro problema no es objetivo de este post. Aquí quiero hablar de esa tentación de que tenemos tantas veces los técnicos de complicar la solución, de hacerla más sofisticada, de agregarle "firuletes" que luego no sólo no sumarán, sino que en realidad restarán.

Pongo un ejemplo personal. En un proyecto de construcción de un software tuve serias discusiones con el equipo técnico respecto de lo "genérico" que debía ser el modelo de datos. Mi posición era hacer un modelo simple, tal vez menos flexible pero más fácil de entender y seguramente más fácil de explotar desde los reportes. La posición del equipo técnico era la de hacer un modelo totalmente genérico que se adaptara a muchas otras situaciones además de la situación concreta sobre la cual debíamos trabajar. Fueron largas charlas para tratar de hacerles entender que luego tendríamos problemas para mantenerlo, que no tenía sentido hacer un software que sólo el 2% de la fuerza de desarrollo pudiera "tocar". Para hacer corta la historia les cuento que perdí la batalla y hoy ese software tiene los problemas que yo enuncie.

Mi lección aprendida es que, si bien ya estoy alejado del detalle técnico, tengo que hacerle un poco más de caso a mi olfato. :-S

El punto es que hay que encontrar un punto de equilibrio pues tampoco vale la situación inversa de no poder mantener el software por lo mal diseñado y programado que está. No sirve hacer un software "atado con alambre" porque tendremos problemas también. O como mínimo tendremos costo de "refactoring".

El equilibrio está en lograr una solución suficientemente solida como para seguir construyendo encima pero suficientemente sencilla como para poder mantenerla a un costo razonable.

¿Qué opinan? ¿Se han encontrado con este problema?

Seguimos pensando..

ECI 2011

2011-06-14T08:00:00.000-03:00

Como todos los años, entre el 25 y el 30 de julio, en la Facultad de Ciencias Exactas y Naturales de la Universidad de Buenos Aires, se realizará la edición 2011 de la Escuela de Ciencias Informáticas.

A continuación transcribo la comunicación recibida:

Los invitamos a colaborar en la difusión de la ECI 2011, que se realizará desde el 25 al 30 de julio y que en esta oportunidad cumple su 25º aniversario.
Nos gustaría que desde sus instituciones y/o empresas den a conocer la información de la ECI y recomienden a sus colegas que participen.
En el siguiente link pueden descargar las Gacetillas de Prensa, el Afiche y el Folleto (con cursos).

Aprovechamos para comentarles algunas novedades de esta 25º Edición:

Habrá 10 cursos con temáticas muy variadas: Robótica Móvil, Metabiología, Agromática, Seguridad con Haskell y Python, Análisis estático de aplicaciones .Net, Aprendizaje Automático, Programación con MPI, Modelado y simulación de sistemas físicos y dinámicas mundiales, Informática industrial y Optimización. http://www.dc.uba.ar/eci/cursos

Este año se ofrecerán actividades de divulgación científica, que incluirán charlas de investigadores del DC, exposición de posters de los doctorandos y conferencias sobre tecnología.

Invitamos a todos a seguir las novedades de la ECI en Facebook (www.facebook.com/ecidcuba) y en Twitter (@ecidcuba).

Desde ya les agradecemos por la colaboración con nuestra Escuela de
Ciencias Informáticas.

Desde ya que recomiendo a todos acercarse. El nivel de las charlas y cursos siempre es excelente.

Seguimos pensando..

Reuniones de una hora por decreto

2011-06-12T12:09:00.001-03:00

En el blog de Google se publicó este post donde se presentan algunos “features” nuevos en Google Apps y hubo uno en particular que me hizo pensar: the default meeting length.

¿Imagínense tener una regla para toda la organización que diga que ninguna reunión puede durar más de una hora? Y por que parar ahí, no? ¿Por qué no implementarla con clientes y proveedores también? ¿No ganaríamos mucho tiempo? ¿No ganaríamos en productividad?

A mi me encantaría … aunque a veces parece algo utópico.

¿Qué creen ustedes?

Seguimos pensando..

Confieso que yo también he caído en la trampa

2011-06-05T20:25:00.001-03:00

Apuesto a que si miran en su lista de tareas van a tener alguna tarea del estilo “preparar la gran presentación para el cliente X” o “planear viaje a YY”. Sí, estoy hablando de tareas que son muy difíciles de realizar o más bien imposibles. Cada vez que las vemos nos da pereza empezarlas y que además, una vez que lo hacemos, es casi imposible saber cuándo estarán terminadas.

Pero ¿cómo debe escribirse una tarea para que podamos decir que está bien formulada? Bueno, navegando por la web me encontré con un viejo post de Merlin Mann titulado Building a Smarter To-Do List en el que se describe exactamente eso.

Fiel a mi estilo recomiendo ir a la fuente y leer el post pero ya que estamos destaco algunas de las ideas más potentes.

La primera tiene que ver con lo que debemos pedirle a una tarea bien formulada.

The best and most useful to-dos share common qualities:

it's a physical action

it can be accomplished at a sitting

it supports valuable progress toward a recognized goal

it's something for which you are the most appropriate person for the job

La segunda es sobre la forma correcta de escribirla.

Framing your work in the physical world is easiest when you imagine what's being done, and the best trick here is to simply phrase your task in a form like: “verb the noun with the object.” That means instead of reminding yourself with the mystery meat of “Year-end report,” you'd more accurately first “Download Q3 spreadsheet from work server.” And, instead of “Get with Anil,” you'd probably want to “Email Anil on Monday to schedule monthly disco funk party.” Get specific in whittling the task down to one activity that you can accomplish completely at a sitting. “A sitting” will vary for you, but I try to never plan a task that would take more than ten minutes (your level of busy-ness might command even smaller-sized tasks).

En mi opinión la clave está en pensar lo suficiente en las tareas durante la “weekly review”, como para no tener que hacerlo al momento de ejecutarlas.

Seguimos pensando..

¿Área de testing o testers independientes?

2011-06-01T08:00:00.000-03:00

Me encuentro muchas veces ante la pregunta de si es mejor tener un área (o grupo) de testing independiente o tener gente que hace testing formando parte de los distintos equipos de desarrollo.

La idea detrás de la pregunta es que optando por alguna de las opciones (o estrategias) el problema de medir y controlar la calidad está resuelto. El razonamiento me parece equivocado y la razón es que ambas estrategias tienen fines diferentes.

El objetivo de un área independiente de testing dentro de un área de sistemas es controlar la calidad con la que liberan software los distintos equipos de desarrollo. Ellos están para medir el nivel de calidad a la salida del proceso de desarrollo. Tener un área permite lograr una visión independiente de la calidad, que no está sesgada por la agenda del equipo de desarrollo, optimizar costos, tener mayor especialización en el tema y hacer más foco en la calidad.

El objetivo de tener gente que hace testing formando parte de los equipos de desarrollo es tener dentro del equipo alguien especializado en la actividad de testing. En lugar de poner a un desarrollador a probar, ponemos a un tester que en teoría tiene una visión independiente, está mejor preparado y también más motivado para hacer la tarea. Ellos están para controlar la calidad durante el proceso de desarrollo.

Veo por supuesto puntos de intersección entre ambas estrategias pero creo que en realidad son complementarias y, aplicadas simultáneamente, se potencian.

Si tenemos gente dentro de los equipos especializada en testing, los desarrollos saldrán mejor de la fase de programación y entraran mejor a la fase de pruebas. Lográndose seguramente una menor cantidad de ciclos desarrollo-testing. Tener una fase de pruebas independientes nos permite medir todos los desarrollos con la misma vara y de esta forma entender los problemas de cada equipo más fácilmente.

Como cierre creo que la pregunta no es si una opción o la otra, sino más bien cómo ensamblar ambas estrategias de forma de no solaparse y por el contrario, multiplicarse.

Seguimos pensando..

Las perspectivas del testing de software

2011-05-29T10:27:00.001-03:00

En una charla del 2006 que encontré en su sitio vi el siguiente comentario de Cem Kaner:

There will probably always be bugs, so won’t there always be a need for skilled testers?

Bueno.. parece ser que, según el artículo IT’s invisible giant de la revista Test Magazine de Abril de 2011, hoy por hoy la afirmación es cierta.

El artículo es interesante porque en forma breve y concisa aporta algunos datos y tendencias relacionadas con el testing de software tanto desde el punto de vista del estado del arte como del negocio. Sería mucho mejor si citara las fuentes de todos los datos que da pero bueno.

El primer dato que me llamó la atención está relacionado con el nivel de inversión en testing.

The testing process is believed to consume between one third and one half of all software development budgets, so it is crucial that its efforts are a success. In an industry in which only 32 percent of projects are successful and half of all development efforts are wasted, there is little margin for error.

Si bien me parece un dato esperanzador, está lejos de lo que yo percibo en el mercado regional (américa del sur). Por estos pagos la inversión suele ser muchísimo menor. Estaría bueno tener la fuente de donde el autor saca esta información.

El segundo fue el del tamaño del mercado (también sin fuente). Un número realmente grande siendo que luego lo compara con el total del mercado de IT de China y son similares. Si el número es correcto constituye un objetivo interesante tanto para vendedores de software de pruebas como para prestadores de servicios tercerizados.

El tercero es el del lugar que ocupa el testing manual en las prioridades de las organizaciones.

However, in a survey conducted by Micro Focus, manual testing still ranked as a far higher priority among testers than automation, showing that there is still a long way to go before automation becomes the norm.

Coincido en la idea de que el testing automático irá ganando (debe ganar) protagonismo y también en que todavía el testing manual está al tope de las prioridades. En este rincón del mundo por lo menos, eso se ve bastante claro.

Para cerrar enumero otras 5 afirmaciones en las que coincidimos el artículo y yo:

El software será cada vez más complejo y por lo tanto sus pruebas.
El costo de la no calidad irá en aumento.
El software en la nube nos obligará a re-pensar la forma en que hacemos pruebas.
Las metodologías ágiles están obligando al tester profesional a reinventarse.
Las perspectivas de carrera para aquellos que decidan dedicarse a esta profesión son muy buenas.

Seguimos pensando..

Hablando sobre Kanban y Testing en el Tata Testing Day 2011

2011-05-26T17:06:00.001-03:00

Hoy estuve hablando sobre Kanban y Testing en el Tata Testing Day 2011 realizado en Montevideo Uruguay. Lindo compartir el rato con gente de testing allí, el auditorio preguntó mucho y estuvo bueno reencontrarme con alguna gente que no veía hace un tiempo.

La charla fue una versión 2 de la que di en la conferencia de Software Gurú.

Seguimos pensando..

Un romance que se extingue..

2011-05-23T08:00:00.000-03:00

Lo nuestro fue un amor a primera vista. Bueno, en realidad no. No está bien decir "lo nuestro", debería decir "lo mío". Lo mío fue un amor a primera vista, no correspondido (porque otros estaban y están en mi misma situación).

Me gustan los libros desde siempre (lo he dicho).

Me gusta leer y me gusta tenerlos.

Me resulta incómodo leer libros prestados porque si el libro me interesa lo suficiente como para darle parte de mi escaso tiempo de lectura que tengo, merece ser comprado.

El ritual de guardar el libro leído en la biblioteca y el hecho de tener una biblioteca también me gusta. A algunos les agarra con la música o con las películas, a mí con los libros.

Es por eso que ahora estoy en un dilema: llegamos a la era de los eBooks. Ahora podemos tener nuestra biblioteca "virtual" con todas las ventajas que eso tiene:

Podemos llevar todos los libros con nosotros a cualquier lado.
Los libros que sólo se venden "afuera" también pueden comprarse al instante.
El peso y el tamaño del libro ya no son un problema.
Y seguramente en un futuro cercano el precio será menor.

Pero la tecnología y la practicidad chocan contra mi romanticismo. Ya no tendré los libros en la biblioteca para mirar, subrayar [1] o mostrar. Desgraciadamente estamos ante otro caso en el que la comodidad le gana la pulseada al romanticismo y van ...

Seguimos pensando..

[1] Sí, yo subrayo los libros a veces, lo siento!

Senderos de carrera en testing de software

2011-05-20T08:00:00.000-03:00

El miércoles di una presentación sobre temas de testing de software en UADE y, entre otras cosas, hablé sobre senderos de carrera para la gente que trabaja en testing de software. Les dejo una de las transparencias para ver qué opinan:

Seguimos pensando..
Aclaración importante: más arriba no necesariamente significa mejor o más prestigioso!

¿Por qué la versión Kindle sale más barata que la versión física?

2011-05-17T08:00:00.000-03:00

Porque hay un mercado que lo paga me dirá algún economista. Pero hay costos que no tienen, como por ejemplo el de fabricar y distribuir el libro, diré yo. Pero hay alguien que lo paga [más caro], dirá el mismo (u otro) economista. Ergo, no hay razón para bajar el precio, no?

En fin.. Lo cierto es que, ahora que estoy pensando en comprarme un Kindle, me he vuelto más observador de los libros publicados en ese formato y sus precios.

A partir de esto puedo decir que los libros para Kindle están más caros. No puedo decir que hice un estudio de mercado o un muestreo estadísticamente representativo, pero todos los que revisé están más caros.

De ahí que me sorprendió gratamente el emprendimiento de Seth Godin llamado The Domino Project que intenta hacer un cambio en la forma de publicar libros. En particular es interesante lo que han hecho con el libro Do The Work de Steven Pressfield.

Si ustedes siguen el link del libro a Amazon verán que el costo del libro en formato Kindle es cero. Además, si miran atentamente la página van a encontrarse con la siguiente leyenda:

Want to read Do the Work for free? Thanks to a generous sponsorship by General Electric, the Kindle ebook edition of Do the Work is available for free through May 20, 2011. No Kindle? Download a free Kindle app for PC, Mac, iPhone, iPad, Blackberry, Windows Phone 7, or Android today.

La idea detrás de esto es que la gente lea el libro, lo recomiende y se venda en formato físico. Parece ser un modelo donde todos ganan: Amazon promociona su Kindle y obtiene “tráfico”, GE y el publicista obtienen publicidad y el autor obtiene $$$ por su obra.

Me gusta la idea de tener un modelo donde el autor recibe un rédito económico por su obra y a la vez el lector puede pagar un precio menor (o cero si está dispuesto a hacer el sacrificio de no tener el libro físico).

Para una discusión más profunda sobre el tema de propiedad intelectual recomiendo el post El caso Taringa: Cuando chocan los argumentos falaces de @amartino y Primero el Autor de @ajlopez (en ese orden).

Seguimos pensando..

¿De eso no se habla?

2011-05-14T08:00:00.000-03:00

De fútbol, religión o política no se habla dicen por ahí. Se supone que hacerlo puede llevarte a pasar un mal momento, generar una discusión "innecesaria" y hasta afectar una relación importante. Esto que es aplicable en la vida en general, lo es más en el ambiente laboral. Luego de haber "vivido" el clima interno de muchas empresas a lo largo de mis años de trabajo, mi sensación es que estos tres conceptos no tienen el mismo riesgo potencial y por consiguiente su tratamiento dentro del entorno laboral es muy diferente.

Siendo más concreto pienso que los entornos de trabajo actuales todavía son bastante torpes a la hora de "manejar" o "digerir" las diferencias de opinión y/o pensamiento en el plano político.

Las diferencias en cuanto a gustos futbolísticos suelen tener momentos de cruentas cargadas pero casi siempre terminan con buen humor. Estamos acostumbrados a conocer el cuadro de cada uno de nuestros compañeros de oficina, a bromear sobre las vicisitudes de los equipos contrarios y a0 resistir estoicamente los problemas del nuestro. Digamos que el riesgo potencial (de afectar relaciones laborales) es bajo.

La cuestión religiosa tiene la ventaja (o desventaja) de que la humanidad viene lidiando con esos temas de convivencia desde hace siglos. Por ejemplo, nadie oculta su religión o sus creencias y difícilmente nos encontremos con gente que nos descalifique cuando expresamos nuestras opiniones. Haciendo una evaluación del riesgo tradicional, el impacto aquí es altísimo pero la probabilidad de ocurrencia es baja.

En cambio cuando nos metemos en el plano político la cosa parece ser distinta (y más aún en esta época de Argentina). Difícilmente logremos mantener la discusión en el plano humorístico del fútbol y tampoco es posible llegar a ese nivel de aceptación (o resignación para algunos) que tienen las diferencias religiosas. En el plano político hay más virulencia y hay más enojo. Como consecuencia de esto en general somos más cautos al hablar o directamente no lo hacemos, procurando esquivar el potencial problema.

Si bien creo que pensar distinto en un plano de la vida no significa que no podamos pensar igual en otros (o acaso no han tenido que compartir cosas con un hincha de Boca?), me pregunto que será lo más atinado en el entorno laboral.

Seguimos pensando..

¿Quién debe hacer el diseño de los casos de prueba?

2011-05-11T08:00:00.000-03:00

He notado que de un tiempo a esta parte es cada vez más frecuente que los clientes que contratan servicios de testing de software decidan hacer ellos mismos el diseño de los casos de prueba para luego darle al proveedor solo la tarea de ejecutarlos. Esto es transforman el servicio de diseño y ejecución de pruebas a uno de ejecución solamente.

La pregunta que me hago es cuán buena es esta decisión. ¿Es conveniente para un cliente tomar la responsabilidad del diseño de las pruebas contratando solamente la mano de obra operativa necesaria para la ejecución?

Desde la perspectiva del cliente se escuchan dos argumentos a favor de esta estrategia:

Se conserva el control sobre el alcance pues se decide lo que se prueba y de lo que no. Si el conocimiento del negocio es complejo o el proveedor no tiene experiencia en el dominio, esta puede ser una forma más suave de ir generando conocimiento del lado del cliente.
Se fuerza a conservar el conocimiento del lado del cliente, ya que se ven obligados a tener que "entender" lo que hace la aplicación en cuestión.

Pero el enfoque tiene su contras también. El cliente que elige esto ..

Debe invertir (o gastar) en mantener la capacidad de definir bien esos casos puesto que una mala definición no sólo haría fracasar la prueba, sino que también haría perder el tiempo del proveedor.
No aprovecha la (deseable) experiencia del proveedor. Los buenos proveedores de este tipo de servicios podrán diferenciarse menos y tendrán menos margen para lograr eficiencias producto de esa experiencia.
Corre solo con el riesgo de decidir qué y cómo probar. El proveedor no tiene injerencia el alcance. Lo que es una ventaja, en las manos incorrectas puede ser un problema. El cliente debe preguntarse “¿realmente soy el único que puede diseñar esta prueba?

Por el otro lado, desde la perspectiva del proveedor ¿es mejor que el riesgo sea todo del cliente? En mi opinión no por dos motivos:

Por la pérdida de capacidad de diferenciación (que mencioné anteriormente). La tarea se vuelve tan operativa que cualquiera, en principio, podría hacerla. Se comoditiza el servicio y esto no es bueno para nadie.
Si los casos están mal definidos pueden tener problemas de eficacia y eficiencia en la ejecución. Excesivo trabajo de inducción, de preparación de datos o quejas por no haber prevenido errores (aún sabiendo todos que la responsabilidad era de otro).

En definitiva, la idea de tercerizar la ejecución de las pruebas parece ser una idea más “descansada” tanto para el cliente como para el proveedor pero en mi opinión termina siendo más problemática.

Seguimos pensando..

Sobre equilibrio vida-trabajo

2011-05-08T14:47:00.001-03:00

Qué complicado es hacer congeniar la vida familiar con las inquietudes intelectuales individuales. En la semana el trabajo, en el fin de semana la familia y demás intereses.

Cinco días para el trabajo y dos 2 días para "todo lo demás". 52 semanas trabajando y 2 de vacaciones. A priori no parece ser un buen balance, no?

La charla de Nigel Marsh me hizo pensar en este tema que obviamente no tiene una respuesta sencilla y mucho menos única. Es trabajo de cada uno buscar la propia y me quedo con dos ideas muy potentes de la charla:

Las pequeñas cosas importan.
La definición actual de éxito ("quien tiene más dinero al morir, gana") debe cambiarse.

Se las dejo, vale la pena invertir 10 minutos en ella.

Seguimos pensando..

10 maneras de renunciar mal a un trabajo

2011-05-01T08:00:00.000-03:00

No es que este mal renunciar a un trabajo ni mucho menos, pero la manera en que lo hacemos habla mucho sobre quienes somos como profesionales.

Hago aquí un top 10 de formas de renunciar que a mi criterio son poco felices:

Por SMS
Por chat
Por mail
Por teléfono
Un día antes de tu primer día
Un día después de tu primer día
Un día antes de tu último día
El día que volves de vacaciones
Sin avisar
A través de terceros (por ejemplo el cliente!)

Seguimos pensando..

Aclaración 1: Cualquier similitud con la realidad es pura coincidencia.

Aclaración 2: El objetivo de este post no es provocar una ola de arrepentimientos y/o pedidos de disculpas de ex-empleados a sus empleadores.

Artículo sobre Kanban en la revista InfoTesting

2011-04-28T08:00:00.000-03:00

En la revista www.InfoTesting.com de Abril 2011 salió publicada una nota escrita por Nora y por mí sobre el uso de Kanban en testing. Para los que quieran leerla pueden ir desde aquí.

Seguimos pensando..

Información Personal en la WEB: ¿oportunidad o amenaza?

2011-04-26T08:00:00.000-03:00

Me encuentro con un interesante informe publicado el 18 de febrero de 2011 por World Economic Forum sobre el futuro de la información personal en internet.

Resulta un poco escalofriante ver las proyecciones que hacen respecto de la cantidad de información personal que habrá disponible en la web para el 2020.

Por un lado no deja de resultar útil tener cada vez más información cargada «en la nube»: ahorra tiempo, permite darte a conocer y conocer nuevas personas, amplía las capacidades de acción en nuestro trabajo, achica distancia, etc.

Por otro, sin darnos cuenta vamos sumando pequeños pixels que, de a uno a la vez, van conformando una fotografía muy precisa acerca de nosotros.

El informe igualmente, como se comenta en Is Personal Data the Next Killer App for the Web?, se concentra en la oportunidad económica que esta fotografía representa.

Para mí, parándome del lado del individuo, la pregunta clave es:

¿Quién tiene acceso a esta foto y para qué?

Seguimos pensando..

A la hora de promocionarse, ¿todos dicen los mismo?

2011-04-24T11:33:00.000-03:00

En el post What’s Brewing with Beer Ads? se puntualiza el hecho de que la mayoría de las marcas de cerveza utilizan el mismo mensaje a la hora de promocionar cierta categoría de producto. En particular dice:

In a world of fierce originality and brand competition, it is a curious phenomenon that a whole category tends to follow the same basic advertising approach. Why? Is it the lack of a unique selling point/message?

Y luego pregunta:

And could this happen in other categories? For instance, could it be that all cellular companies will communicate the same message? Or should they make an effort to come up with a distinctive message?!

Pensando en esto creo que en 0aservicios de consultoría pasa algo similar. Cuando uno recorre el material comercial de cualquiera de las empresas de esta categoría (y aquí sumo también a empresas de desarrollo de software) se encuentra con mensajes muy similares que giran alrededor de 3 conceptos centrales:

Confianza
Especialización
Conocimiento del negocio

Me pregunto si estos conceptos son ya condiciones de mínima que cualquier empresa de la categoría deba garantizar y sobre los que hay que construir un discurso superador o si son todavía una meta a alcanzar.

Seguimos pensando..

Foto: Monasaurus

The Alpha Project Managers (colaboración en el blog Mejores Proyectos)

2011-04-22T11:56:00.000-03:00

Hace un par de días salió publicada una colaboración mía en el blog Mejores Proyectos. Agradezco a José Esterkin por la oportunidad de participar en su exitoso blog.

Seguimos pensando..

Si no usas una herramienta, estás en la edad de piedra

2011-04-19T09:53:00.001-03:00

En uno de mis primeros trabajos de testing de software usábamos un documento Word® para registrar los casos de prueba y un Excel® para registrar los incidentes.

Gracias a esto, los problemas que teníamos eran los que todos podemos imaginarnos: no teníamos trazabilidad entre casos, ejecuciones e incidentes, era difícil paralelizar las pruebas, al igual que juntar los incidentes de todos los testers, solo podíamos compartir el material con desarrollo una vez que habíamos terminado, etc.

En esa época, 15 años atrás, no era tan obvia la necesidad de tener una herramienta que gestionara toda esa operatoria. Ahora sí lo es.

No es posible instaurar un proceso de pruebas de software razonable si no contamos con una herramienta de registración y seguimiento de incidentes (errores). Y en realidad tampoco alcanza con registrar solo los incidentes, sino que también debemos registrar las ejecuciones realizadas, los casos de prueba definido y en qué proyectos (o pruebas).

A continuación doy una lista de 10 cosas que no podremos hacer si no tenemos una herramienta que apoye nuestro proceso de pruebas:

Compartir la información (los incidentes) en tiempo real con el equipo de desarrollo
Tener trazabilidad entre las pruebas y el desarrollo
Tener un estado de la prueba en tiempo real
Paralelizar tareas de testing y corrección durante las pruebas
Medir la productividad del equipo de pruebas
Medir la calidad del software en desarrollo
Reusar los casos de prueba y los incidentes en futuras pruebas
Tener información para planificar y estimar futuras pruebas
Tener definido el alcance de cada prueba
Determinar cuán efectiva es tu prueba

Aunque parezca mentira, todavía me encuentro con equipos que trabajan como hace 15 años atrás ;-)

Seguimos pensando ..

Las licitaciones y el CIO

2011-04-14T23:25:00.001-03:00

Las licitaciones son una herramienta fundamental a la hora de abastecerse de recursos para sus proyectos. Sin embargo no son la única opción.

Un buen CIO debe saber decidir qué servicios licitar y qué servicios contratar directamente. En algunos casos es conveniente recurrir a los proveedores estratégicos directamente, confiando en que nos ayudarán de la mejor manera posible.

Por el otro lado, el CIO debe ser un buen licitador. Una vez que decidió que un servicio será adjudicado por licitación, debe elaborar un pliego que le permita atraer a los mejores proveedores y asustar a los peores (como comenté en Teoría Económica y Outsourcing).

Seguimos pensando..

Lo siento Sr Smith, de acuerdo a nuestros registros usted está muerto

2011-04-09T21:09:00.001-03:00

Hace un par de días recibí un correo con la información de un vuelo que debo hacer la semana próxima. En él figuraba el código de reserva que debía usar para hacer el checkin on-line. Hoy, 72 horas antes, intenté hacer el checkin como otras tantas veces pero el sistema me dijo que no alegando que el susodicho código estaba mal. Luego de varios intentos, llamé al call center de la aerolínea para ver que había pasado y allí me enteré que estaba usando un código incorrecto. “¿Incorrecto?” dije yo “pero si ustedes me enviaron el código”.

La pregunta que me hacía luego es ¿cómo pudieron mandarme el código mal? ¿Alguien que se equivocó al tipear? ¿Había un error en alguno de los tantos sistemas por los que mi reserva pasó?

Un checkin que usualmente demora 10 minutos terminó llevándome 25 minutos. Imaginen que en una persona cualquiera esto produce irritación pero dada mi área de expertise (ingeniería de software, calidad, informática) la frustración es peor.

Las empresas pierden mucho tiempo y dinero por no prestarle atención a sus datos.

El título de este post está extraído de la página 3 del libro Data Quality for the information age de Thomas Redman. En ese primer capítulo el autor da 3 motivos por los que la calidad de los datos debería ser una preocupación para las empresas:

1. Poor data quality is pervasive. [..] Poor data quality is a plague to wich no industry is inmune - nor is goverment or academia.
2. Poor data quality is costly. It Lowers customer satisfaction, adds expense, and makes it more difficult to run a business and pursue tactical improvements such as data warehouses and re-engineering.
3. Data quality can be improved and the impacts noted above mitigated. Indeed, it seems that improved data quality can be a source of competitive advantage.

Ya no es suficiente probar nuestros sistemas pensando en las variaciones que el código puede producir. Ahora debemos probarlos según las variaciones que pueden producir sus datos también.

Sí, es cierto. Antes de que lo digan lo digo yo. Antes también debíamos probar nuestros sistemas pensando en los datos. Pero lo cierto es que ahora es mucho más necesario puesto que la probabilidad de mal comportamiento en el software debido a problemas en los datos de configuración o customización es mucho mayor.

Los sistemas de hoy en día cambian radicalmente su comportamiento según estos datos. Además utilizan información obtenida de bases de datos externas todo el tiempo. El paradigma de mis datos fueron generados por mi y yo soy el único que los toca ya no existe.

Debemos desempolvar los libros de “data quality” y las técnicas de “data testing”. Mi sensación es que si no, estaremos dejando pasar muchos problemas y entonces todos tendremos anécdotas divertidas como la del Sr. Smith.

Seguimos pensando..

Google y el testing

2011-04-03T11:50:00.000-03:00

Por referencia de un compañero de trabajo tomé contacto con una serie de posts que James Whittaker publicó en Google Testing Blog. La serie se titula How Google Tests Software y cuenta varios aspectos relacionados con la forma en que se organizan, los roles que ocupan y la filosofía/estrategia de pruebas que manejan.

A todos aquellos interesados en los temas de testing de software les recomiendo leer la serie y ver algunas de las charlas que el autor ha dado para GTac.

Resalto en este post dos ideas que a mi criterio son interesantes y con las que concuerdo.

La primera tiene que ver con la relación entre desarrollo y testing:

At Google, quality is not equal to test. Yes I am sure that is true elsewhere too. “Quality cannot be tested in” is so cliché it has to be true. From automobiles to software if it isn’t built right in the first place then it is never going to be right. Ask any car company that has ever had to do a mass recall how expensive it is to bolt on quality after-the-fact.

However, this is neither as simple nor as accurate as it sounds. While it is true that quality cannot be tested in, it is equally evident that without testing it is impossible to develop anything of quality. How does one decide if what you built is high quality without testing it?

The simple solution to this conundrum is to stop treating development and test as separate disciplines. Testing and development go hand in hand.

[...]

At Google this is exactly our goal: to merge development and testing so that you cannot do one without the other.

Me parece interesante porque coincide con algo que yo opino desde hace tiempo: Los testers no están para “controlar” a los desarrolladores. Si instauramos un área o un grupo de testing bajando esta línea a los miembros de ambos grupos (testers y desarrolladores) estamos bajando drásticamente la probabilidad de éxito de la iniciativa. Por si hiciera falta aclararlo, el grupo de testing está para ayudar a entregar productos de calidad en tiempo y forma.

La segunda idea interesante es la de que el testing automático no reemplaza al testing manual. Ambos son útiles y ambos son necesarios pero no intercambiables. Lo que sí hace el testing automático es liberar tiempo del equipo de testing para dedicarse a probar aquellas cosas que no pueden automatizarse a un costo razonable.

Having said that, it is important to note that Google performs a great deal of manual testing, both scripted and exploratory, but even this testing is done under the watchful eye of automation. Industry leading recording technology converts manual tests to automated tests to be re-executed build after build to ensure minimal regressions and to keep manual testers always focusing on new issues. We also automate the submission of bug reports and the routing of manual testing tasks. For example, if an automated test breaks, the system determines the last code change that is the most likely culprit, sends email to its authors and files a bug.

Dicho esto también creo que el contexto de Google no es del todo extrapolable a cualquier otro lugar donde se desarrolla software. El software de Google tiene una masividad tal que un error podría producirse millones de veces en simultáneo multiplicando el costo de corrección en forma exponencial. En entornos más acotados esto no ocurre y la necesidad de “automatizar todo lo automatizable” no es tan fuerte.

Seguimos pensando..

¿La revancha de la ingeniería de software?

2011-03-31T09:27:00.001-03:00

Quince años atrás, trabajar en temas de ingeniería de software (IS) en Argentina era una excentricidad. Poca gente lo hacía y poca gente sabía del tema. En lo personal tuve la suerte de dar con un grupo especializado que proponía enfocarse en estos temas tanto dentro de la academia como de la industria. Fueron años de aprendizaje y formación.

Luego el "momentum" de la IS se diluyo. Vinieron años de cuestionamiento a nivel mundial y de crisis a nivel local. Por un lado (a nivel mundial) se ponía en duda la utilidad de la IS como forma de desarrollar software a partir del aumento de la popularidad de metodologías más ágiles y varios fracasos bien documentados (como el del Ariane). Por el otro (a nivel local) la falta de presupuesto y proyectos, disminuyo el ámbito de aplicación para estos conceptos. Fueron años de letargo.

Hoy, y desde hace un tiempo, veo un renacer de la IS dentro de las empresas. Lo veo en la mayor demanda de servicios relacionados, en la dificultad creciente para conseguir personas calificadas que quieran trabajar en esta problemática y en asignaciones presupuestarias crecientes (parcialmente logradas por subsidios y ley de software).

Me gusta lo que veo. Si bien estoy seguro que la IS no tiene todas las respuestas al problema de desarrollar software de calidad (remember Non Silver Bullet), también creo que hay mucha tela para cortar por ese lado y que si seguimos trabajando, investigando y, por sobre todo, experimentando en esta línea de pensamiento lograremos hacerla avanzar.

Seguimos pensando..

Charla en SGV: ¿Cómo organizar un equipo de pruebas usando Kanban?

2011-03-29T19:15:00.001-03:00

El próximo 6 de abril estaré participando de la conferencia virtual de Software Gurú de la que hablé aquí. Será a las 16 hora de México (19 hora de Argentina). Paso aquí una breve descripción:

Kanban es una metodología ágil que permite visualizar el flujo de trabajo, dividir tareas y optimizar el tiempo dentro de la oficina. Originada en Toyota con el objetivo de mejorar el proceso de fabricación textil, en 2001 fue incluida dentro del Manifiesto Agile como una forma de organización del proceso de desarrollo de software.
A partir de su introducción en el mundo del software y, al igual que SCRUM, ha sido utilizada en diversas situaciones y proyectos de desarrollo.
En esta charla contaremos la experiencia de gestionar la demanda de una Fábrica de Pruebas (o Quality Assurance Factory) utilizando esta metodología ágil. Comentaremos, entre otras cosas, cuando resulta útil aplicarla, qué beneficios trae y algunas de las buenas prácticas, los tips y las lecciones aprendidas que hemos recolectado durante la implementación de estas ideas.

La charla es gratuita aunque requiere registración. Los espero!

Seguimos pensando..

La matemática de una presentación

2011-03-25T12:10:00.001-03:00

Algunas semanas atrás asistí a una presentación en la que al expositor se le acabó el tiempo mucho antes que los slides que quería pasar. Como consecuencia de eso tuvo que hacer el conocido sprint final para quedarse con la sensación de que cubrió todo el material.

Momento incómodo pensé yo desde mi lugar en la audiencia. Obviamente no es lo mismo que ocurra esto en una presentación para un grupo reducido, en un curso o siendo keynote speaker de una conferencia. Pero lo cierto es que no está bueno que pase y sinceramente muchas veces es algo que se puede evitar.

En mi caso, una de las primeras cosas que hago al comenzar a preparar una presentación es calcular la cantidad de slides que "debería" tener la presentación en función del tiempo que tengo disponible para hablar.

¿Cómo lo hago?

En primer lugar calculo el tiempo neto de presentación. Es decir, el tiempo en el que estaré hablando yo versus el tiempo que estarán haciéndome preguntas.

Y luego calculo la cantidad total de slides que tendría que tener para estar tranquilo con el material. En lo personal, calculo un slide cada 3 minutos.

Obviamente este ratio (slides x minuto) es totalmente personal y tiene que ver con múltiples factores como por ejemplo:

La forma de presentar y el ritmo de cada uno. Hay personas que necesitan más material que otras para hablar en público.
La audiencia. Los más técnicos podrían requerir más texto y sentirse incómodos con demasiadas imágenes o diagramas. Los menos técnicos podrían marearse con el detalle.
El tiempo de preparación y el conocimiento del material. Menos slides implica mayor entrenamiento/ensayo para dar la charla. Los slides muchas veces nos sirven como ayuda-memoria.

Tener este número presente también permite definir el espacio que cada tema tendrá dentro de la presentación de forma tal que el contenido no quede desbalanceado en cuanto a la profundidad.

El manejo del tiempo durante una presentación es esencial. Cuanto mejor planifiquemos la forma en que usaremos dicho tiempo, menos sufriremos.

Seguimos pensando..

Foto: stijnbokhove

Charlas sobre la Certificación ISTQB se ofrecen..

2011-03-23T11:42:00.001-03:00

Como comenté aquí soy miembro del HASTQB (Comité Hispanoamericano de Testing perteneciente al ISTQB) y dentro de mis responsabilidades como miembro está la de promover la certificación dentro de Argentina.

Es por eso que me gustaría invitar a aquellos interesados en recibir material, información o charlas referidas a este tema dentro de Argentina, que me contacten alguna de las múltiples vías existentes.

Seguimos pensando..

Los Intocables

2011-03-20T12:34:00.001-03:00

Luego de tenerlo en la pila de libros para leer un largo tiempo, en estas últimas vacaciones de verano logré leer La tierra es plana de Thomas Friedman. Una lectura muy recomendable para aquellos interesados en el fenómeno de las tercerizaciones.

Si bien encuentro varios conceptos que valdría la pena desarrollar del libro, quiero concentrarme en uno que encontré en el capítulo titulado Los Intocables:

En un mundo donde la tercerización es cada vez más fácil, las personas deberían tratar de convertirse en intocables. Es decir, personas cuyos puestos no se pueden subcontratar afuera.

El autor sostiene que hay cuatro categorías de trabajadores intocables:

Los especiales, gente con una habilidad especial. Por ejemplo un Messi o un Bill Gates. Ellos tienen cierto talento que los ubica en un escalón distinto a los demás. La empresa siempre preferirá tener a estos trabajadores dentro de ella y no subcontratados. La cotización de este tipo de trabajadores siempre es muy alta.
Los especializados, gente que cuenta con habilidades de alta demanda y de difícil intercambiabilidad[1] dentro de la empresa o el mercado. Todos aquellos trabajadores que no pueden ser especiales, buscan especializarse como manera de aumentar su empleabilidad.
Los anclados, gente que cubre un rol intransferible debido a que “se debe hacer en un lugar específico, a que está en contacto directo con el cliente/comprador/paciente”, etc.
Los verdaderamente adaptables, gente que constantemente está adquiriendo nuevas habilidades, conocimientos y pericia. Esta es gente funcional a las necesidades del negocio que puede agregar valor desde diversos puestos.

Si bien el enfoque del autor tiene que ver con los puestos de trabajo y la exposición a posibles tercerizaciones, me parece interesante usar esta clasificación a la hora de pensar el valor que uno aporta a su empresa y su empleabilidad en el mercado. Desde este punto de vista, ser intocable es mejor que no serlo y anclado es la peor opción dentro de los intocables.

¿Estás de acuerdo con las categorías? ¿Pensaste alguna vez en qué categoría estas? ¿Estás cómodo en ella? ¿Estas dispuesto a hacer los sacrificios que ella implica?

Seguimos pensando..

[1] El concepto de intercambiabilidad tiene que ver con aquello que puede ser tercerizado o no.

Lo que a veces pasa

2011-03-13T10:53:00.001-03:00

Estoy leyendo el libro Good To Great de Jim Collins por estos días y, si bien no lo he terminado, esta semana me encontré con tres párrafos que quiero compartir.

Few successful start-ups become great companies, in large part because they respond to growth and success in the wrong way. Entrepreneurial success is fueled by creativity, imagination, bold moves into uncharted waters, and visionary zeal. As a company grows and becomes more complex, it begins to trip over its own success-too many new people, too many new customers, too many new orders, too many new products. What was once great fun becomes an unwieldy ball of disorganized stuff. Lack of planning, lack of accounting, lack of systems, and lack of hiring constraints create friction. Problems surface-with customers, with cash flow, with schedules.

In response, someone (often a board member) says, "It's time to grow up. This place needs some professional management." The company begins to hire MBAs and seasoned executives from blue-chip companies. Processes, procedures, checklists, and all the rest begin to sprout up like weeds. What was once an egalitarian environment gets replaced with a hierarchy. Chains of command appear for the first time. Reporting relationships become clear, and an executive class with special perks begins to appear. "We" and "they" segmentations appear- just like in a real company.

The professional managers finally rein in the mess. They create order out of chaos, but they also kill the entrepreneurial spirit. Members of the founding team begin to grumble, "This isn't fun anymore. I used to be able to just get things done. Now I have to fill out these stupid forms and follow these stupid rules. Worst of all, I have to spend a horrendous amount of time in useless meetings." The creative magic begins to wane as some of the most innovative people leave, disgusted by the burgeoning bureaucracy and hierarchy. The exciting start-up transforms into just another company, with nothing special to recommend it. The cancer of mediocrity begins to grow in earnest.

Cualquier empresa (área o grupo humano) pierde cosas al crecer. Lo importante es ser consciente de esto y tratar de que lo esencial permanezca.

Seguimos pensando..

El efecto multiplicador de las personas

2011-03-08T19:22:00.000-03:00

Pensemos en dos números: R (de resultado) y M (de multiplicador). Primero asumamos que R es mayor a cero y luego pensemos en M. Si M es mayor que 1, al multiplicarlo por R, el resultado obtenido (digamos R') será mayor a R. En caso contrario, si M es menor que 1, R' será menor a R.

Ahora definamos el multiplicador Mp (léase el múltiplicador de la persona "p") para identificar la capacidad de una persona para contribuir, desde su trabajo, al resultado final que logrará un equipo.

A partir de lo dicho en el primer párrafo, podemos hacer algunas observaciones sobre Mp:

Las personas con Mp igual a 1, aportan lo justo al resultado sin empeorarlo ni mejorarlo. Tomemos este como el resultado base.
Las personas con Mp mayor a 1 lograrán un efecto "multiplicador" positivo sobre el resultado final pues lograrán un resultado mayor al que se lograría poniendo una persona de Mp = 1.
Las personas con Mp menor a 1 lograrán un efecto negativo sobre el resultado puesto que el resultado final será un poco peor al resultado base.
El caso Mp <= 0 no lo comento por razones obvias.

Y ¿por qué toda esta perorata pseudo matemática? Pues porque trabajamos en proyectos con personas y cada una de ellas tiene un efecto-multiplicador que consciente o inconscientemente aplica a los resultados del/su equipo. Es una noción subjetiva y arbitraria pero real.

¿No me creen que esto es así? Piensen en los niños y cómo juegan.

Todos en nuestra infancia hemos participado de juegos de equipo (como por ejemplo podría ser el fútbol en mi país) y para poder hacerlo, debíamos pasar por el tortuoso proceso de "armar los equipos". Más allá del método que cada uno utilizaba (en mi caso hacíamos "pan y queso"), al final del día siempre se trataba de dos personas eligiendo de alguna manera al resto de sus compañeros. Esta elección se hacía teniendo en cuenta "un no se qué" que a esa altura de nuestras vidas no podíamos precisar: el efecto-multiplicador de nuestros compañeros de juego.

La moraleja del post es tener siempre presente este efecto no sólo a la hora de elegir al equipo sino también cuando interactuamos con los demás compañeros de trabajo. Traten de tener siempre un efecto multiplicador mayor a 1 y busquen siempre gente que les proporcione lo mismo a ustedes.

Seguimos pensando..

Nota en Testing Experience

2011-03-04T12:02:00.002-03:00

Me acaban de confirmar que ya salió el número de marzo de la revista Testing Experience. Este número está dedicado el tema "testing en dominios" e incluye una nota que escribí con Damián Famiglietti y Leandro Caniglia sobre el testing de un producto en el mercado de Oil & Gas.

Para aquellos que trabajamos en esto desde hace tiempo y, en distintos dominios de negocio, resulta interesante ver cómo lo hacen en otros lugares.

Seguimos pensando..

3 razones por las que off-site puede ser mejor que off-shore

2011-02-28T08:00:00.000-03:00

Sin querer hacer de este post una defensa de los servicios off-site por sobre los servicios off-shore, sí quería marcar 3 razones que podrían pesar a la hora de tener que decidir cómo conformar equipos de trabajo geográficamente distribuidos (ETGD). Las tres están relacionadas con un factor clave de éxito en proyectos donde el factor humano es el predominante: la comunicación entre los miembros del equipo.

Razón número 1: La posibilidad de hacer reuniones presenciales

Por un lado sabemos que interactuar cara a cara es mejor que hacerlo telefónicamente, por chat o por correo electrónico. Hay múltiples razones y estudios que lo prueban. Por otro, existe una importante tendencia (que asumo inevitable en este post) hacia la formación de ETGD y a la tercerización, motivada principalmente en el ahorro de costos.

Ahora bien, una cosa es ahorrar costos descentralizando o tercerizando funciones y otra es negarnos la posibilidad de interactuar cara a cara.

En la mayoría de los proyectos con ETGD en los que me ha tocado trabajar, los resultados obtenidos cuando el equipo ha tenido contactos cara a cara, han sido superiores. A veces en forma sutil y/o intangible, pero superiores. Es por eso que, en la medida que podamos, siempre es mejor que el equipo tenga la posibilidad de verse las caras. Y si es posible, periódicamente puesto que de esta forma se ponen en funcionamiento esquemas que permiten prevenir problemas en lugar de ir corrigiéndolos a medida que aparecen.

Razón número 2: Hay mayor coincidencia del uso horario

La falta de comunicación es una de las principales causas de fracaso en proyectos con ETGD. A su vez, sabemos que una de las formas de mitigar este problema es justamente aumentarla.

Calidad no es igual a cantidad pero este es uno de esos casos donde entrenar sirve. No es lo mismo tener un problema y resolverlo en el acto llamando por teléfono para destrabarlo que tener que esperar hasta la mañana siguiente para hacerlo. Estos altos en el trabajo producen en el equipo tanto pérdidas de tiempo y energía como frustración.

En los servicios off-site, al estar en el mismo país [1], la comunicación aumenta pues hay mayor solapamiento horario (es decir mayor disponibilidad de las personas). Y el aumento de comunicación tiende a mejorar la situación y a mitigar el problema.

Razón número 3: Hay mayor coincidencia cultural

Por último, la coincidencia a nivel país aumenta el solapamiento cultural de las personas logrando nuevamente una mayor fluidez en el trabajo. Desde que todos hablen el mismo idioma hasta que todos trabajen bajo las mismas reglas (misma legislación, mismos horarios, mismos beneficios, mismo jefe, etc.), hay toda una serie de aspectos culturales a veces mínimos que facilitan el trabajo conjunto a pesar de no estar físicamente en el mismo lugar.

¿Qué les parece? ¿Están de acuerdo? ¿Encuentran otras razones por las que esta hipótesis podría ser cierta? ¿Por qué creen que en muchos casos las cosas ocurren distinto?

Seguimos pensando..

Imagen: www.gigaom.com

[1] Se considera que un servicio es off-site cuando se presta fuera de las oficinas del contratante pero dentro del país del mismo. Se considera que un servicio es off-shore cuando el servicio se presta fuera del país.

Charla en la conferencia virtual de Software Gurú

2011-02-26T08:00:00.000-03:00

He postulado una charla en la conferencia virtual de la revista Software Gurú llamada“¿Cómo organizar un equipo de pruebas usando Kanban?”. Para registrarse o conocer detalles pueden seguir este link.

La conferencia será el 6 de abril próximo. Si les interesa el tema regístrense, es gratuita.

Seguimos pensando..

Cliente malo, cliente bueno

2011-02-25T08:00:00.000-03:00

Uno de mis socios siempre dice que un proyecto es exitoso cuando el cliente para el que trabajamos contrata el siguiente.

Esto tiene que ver con que las empresas de consultoría exitosas saben que la fórmula para un negocio sustentable es construir relaciones de confianza en el largo plazo con sus clientes, y que dichas relaciones deben verificarse por medio de sucesivos proyectos conjuntos.

A partir de esta premisa y, en el proceso de adquirir nuevos clientes, es normal ser sometido como proveedor a ciertas pruebas de confianza. Por ejemplo tendremos que mostrar habilidad técnica para el tema en cuestión o vocación de negocios a la hora de fijar los precios de nuestros primeros servicios.

En respuesta a esta inversión del proveedor, el cliente lo recompensará con nuevos proyectos o menores exigencias en las siguientes contrataciones (por ejemplo no requiriendo procesos licitatorios para cada contratación).

Se trata, como en tantos otros órdenes de la vida, de generar una relación "win-win" entre ambos.

El problema es que algunas empresas (tanto proveedoras como clientes) confunden esto con la idea de que el proveedor debe hacer todos los sacrificios.

Si eres una empresa-proveedor y tienes el "sí fácil" (o el "no difícil") te aconsejo que revises periódicamente la relación que tienes con cada cliente. El objetivo es, por supuesto, diferenciar a los buenos clientes de los malos. Y puesto que tener esta capacidad puede ser de vida o muerte para ti, tiro algunas preguntas que podrían ayudar:

Los proyectos con este cliente, ¿son rentables? Es decir que con esos proyectos se ganó dinero.
¿Hay con este cliente continuidad de proyectos o contratos de largo aliento? Es decir que luego de un proyecto aparece otro relativamente cerca en el tiempo.
¿Somos, para este cliente en algún rubro, proveedores de confianza? Es decir que el cliente, para ese rubro, siempre nos llama primero a nosotros para cotizar.
Para algunos proyectos/contratos, ¿has logrado no pasar por toda su burocracia? Es decir que nos contratan en forma directa puesto que saben que estamos dando el mejor servicio posible al mejor precio posible, poniéndonos en la obligación de “hacer de entrada nuestro mejor esfuerzo”.
Cuando otro proveedor intenta "entrar", ¿recibes una oportunidad de igualar o mejorar la oferta? Es decir que, a igualdad de condiciones, el cliente nos prefiere.

Por otro lado, si eres empresa-cliente y crees en esta idea, también deberías recapacitar. Si bien es cierto que hay más de un proveedor para casi cualquier servicio que puedas necesitar, es igualmente cierto que los cambios de proveedores son costosos y que la fama de "mal cliente" también recorre el mercado haciendo que tu riesgo-cliente aumente.

Seguimos pensando..

El riesgo-cliente

2011-02-22T08:00:00.000-03:00

En los mercados de deuda entre países se maneja el concepto de riesgo-país o riesgo soberano. Dicha medida permite a los inversores fijar una tasa de interés particular para ese país, a la hora de prestarle su dinero.

La idea detrás de esto es que los países se van haciendo una cierta “fama” en el mundo, la cual repercute en el sobrecosto que pagarán sobre los prestamos que solicitan. Si el país hace las cosas mal, la tasa sube. Si hace las cosas bien, la tasa baja [1].

Mi hipótesis es que entre empresas ocurre algo similar a la hora de contratar servicios de consultoría: Cuando un cliente solicita una cotización por un servicio a un determinado proveedor, este último aplica una tasa de riesgo sobre la cotización del servicio en función de dos elementos clave:

El historial de relación entre ellos, que tiene que ver con los proyectos conjuntos rodados en el pasado. Si fueron grandes, rentables, exitosos, etc.
La fama del cliente en el mercado, que tiene que ver con la fama que el cliente a cosechado en relación a su manejo de proveedores.

Este proceso se da más o menos formalmente dependiendo del proveedor e inclusive, algunas veces, ni siquiera se da en forma consciente. Cuando el proveedor conoce al cliente de primera mano, el primer factor tiene más peso. Cuando no tienen historia en común, el segundo es el que domina.

Lo interesante del paralelo es que, al igual que con los países, esta dinámica es pública. Es decir que lo que pasa entre un determinado proveedor y un cliente tarde o temprano es conocido por los demás proveedores y demás clientes.

La moraleja tiene dos partes. La primera es para los que ocupan el rol de cliente y es que deben ser conscientes del impacto económico que tienen las malas prácticas de gestión de proveedores (con un proveedor en particular y con todos en general). La segunda es para los que ocupan el rol de proveedores y es que ellos tampoco están exentos de la fama que se fabrican.

Seguimos pensando..

[1] No voy a explicar aquí esta dinámica en detalle sino enunciar una hipótesis relacionada con la relación que hay entre proveedores y clientes en el negocio de la consultoría. Para una explicación más extensa sobre este tema pueden ir a este artículo y leer.

Foto: Fernando Stankuns

Para ganar mercados nuevos lo principal es animarse

2011-02-19T08:00:00.000-03:00

Hay mercados que intimidan. Estoy pensando en países-mercado y en industrias-mercado (dándole un sentido amplio a la palabra). Intimidan porque uno cree que no tiene nada “diferente” para ofrecer o que son muy grandes o que son muy exigentes o que tiene mucho para perder o todo al mismo tiempo.

Pero no hay que dejarse. Siempre podemos extrapolar experiencia de otros lugares o empezar "en pequeño" mitigando los riesgos. La cuestión principal para entrar es animarse. Luego, lo demás viene.

Dicho esto, también es cierto que hay que pensar en qué puedo darle yo a ese mercado. No se puede subestimar el problema y asumir que lo que funcionó en un lugar funcionará en otro o caer en un optimismo injustificado diciendo que "como me fue bien en XXX, seguro me va a ir bien acá".

Para cada mercado target elegido hay que hacer el ejercicio de desarrollar una estrategia tomando decisiones y luego salir al ruedo a testearla. El Times ha hecho esto con su estrategia de suscripciones de internet y aparentemente le ha salido bien.

Seguimos pensando..

Si no tengo errores en producción ¿Por qué habría de hacer testing?

2011-02-16T21:15:00.000-03:00

Siempre ha sido difícil vender la necesidad de hacer testing sistemáticamente, y sobre todo en ciertas latitudes del mundo. Pero resulta más complicado aún cuando, además, no hay errores en el ambiente de producción [1].

Parte de la explicación puede encontrarse en esa idea de que “no hay nada mejor para facilitar un cambio que una buena crisis”. En un contexto en el que se debe tomar la decisión inicial de introducir actividades de testing de software en un área de desarrollo o no, tener problemas en el ambiente productivo inclina la balanza hacia el sí.

Dado un proceso de desarrollo que produce software con bajo nivel de errores en producción – es decir que el usuario no tiene grandes quejas respecto a lo entregado – ¿por qué sería necesario encarecer los costos del proceso introduciendo nuevos controles?

A continuación ofrezco 3 argumentos:

El primer argumento es el de la disminución de riesgo potencial. El hecho de tener un proceso de desarrollo que no haya producido software defectuoso hasta el momento, no garantiza que esos resultados a futuro. En muchas situaciones la actividad de testing se concibe como un seguro que uno paga para “cubrirse” de posibles siniestros que pudieran ocurrir en el futuro.
El segundo argumento es el de entrenar al equipo y estar preparado para desafíos mayores. Tal vez el equipo de desarrollo funcione bien para cierto tipo de proyectos conocidos pero ¿qué pasa si los proyectos futuros tienen características nuevas? Otra vez: el éxito en los proyectos pasados no necesariamente es un buen estimador del nivel de éxito futuro. Tener incorporada la disciplina de controlar la calidad en proyectos conocidos permite encarar proyectos más complejos con mayor certidumbre, o dicho de otra forma, aprender a manejar en una autopista parece ser peor idea que hacerlo en una calle aislada. Practicamos en calles aisladas para luego ir a la autopista.
El tercer argumento es el del testing como observatorio metodológico. Tener un punto de control como el testing permite observar el proceso de desarrollo y, eventualmente, tomar decisiones o hacer cambios que lo potencien o mejoren. Inclusive que nos permitan ahorrar tiempo del personal suprimiendo acciones que no agregan valor o agregando otras que lo incrementen.

Seguimos pensando..

[1] El ambiente productivo (o de producción) es el ambiente donde se ejecuta el software y se contienen los datos reales de la organización. Las buenas prácticas de desarrollo de software indican que el ambiente productivo debe estar separado del ambiente de desarrollo de software y del de testeo.

Are you a time-stealer?

2011-02-11T08:00:00.000-03:00

Seguramente alguna vez llegaron al final del día laboral con esa sensación amarga de que no han logrado hacer todo lo que se habían propuesto. Bueno, a veces no es todo el día pero sí una mañana o una buena porción de tiempo. En situaciones como estas uno se pregunta ¿qué hizo con su tiempo?

Hoy leyendo este de Harvard Business Review me encontré con un concepto interesante que creo puede ayudar a luchar contra este problema cambiando un poco el eje de la cuestión. El concepto en cuestión es el de “time-stealers” (o robadores de tiempo). Según el artículo los time-stealers “can be in the form of demanding people, routine or unnecessary meetings or tasks, or even your own bad habits”.

Si bien todos los time-stealers mencionados son dignos de análisis, uno de ellos me hizo reflexionar: demanding people. ¿Quién no ha tenido un colega roba-tiempo? Es decir alguien que interrumpe constantemente para hacer preguntas off-topic.

Pensando en esto tal vez la pregunta correcta debería ser ¿quién se ha robado mi tiempo?

Mi reflexión sobre esto es que en nuestro mundo actual, de oficinas de puertas abiertas y grandes espacios con puestos de trabajo contiguos, tener reglas de etiqueta asociadas a la forma de interrumpir el trabajo de los demás es sumamente importante. Tal vez crucial para lograr la máxima productividad.

Obviamente definir y respetar estas reglas es un trabajo de todos pero creo que hay una pequeña tarea individual (en forma de pregunta) que todos debemos hacer antes de interrumpir a alguien: ¿estoy siendo un time-stealer?

Seguimos pensando..

2 enfoques complementarios a la hora de estimar testing

2011-02-08T08:00:00.000-03:00

Todavía recuerdo la primera vez que me encargaron hacer una estimación de esfuerzo. Se trataba de un testing funcional que debíamos hacer sobre un desarrollo de otro proveedor.

En retrospectiva fue divertido y desafiante pero en aquel entonces los primeros minutos de trabajo sobre la tarea fueron bastante tensos puesto que no tenía idea por donde empezar. Sin embargo, y luego de un rato de meditación sobre el asunto, la hoja en blanco se rompió y la cosa empezó a fluir [1].

La cantidad de métodos para estimar esfuerzo de testing funcional es inmensa. Particularmente a mi me gusta combinar siempre dos enfoques: top-down y bottom-up.

Llamo enfoque top-down a calcular el esfuerzo de testing a partir del esfuerzo total del proyecto o el esfuerzo estimado de desarrollo. La forma de implementarlo es hacer una cuenta del estilo "el testing debe ser el XX% del esfuerzo estimado para desarrollo". Dependiendo del contexto de proyecto y el software a testear, este XX puede ir desde el 20% hasta el 50%. Con este enfoque se tienen a minimizar los detalles de la prueba y a calcular esfuerzos que, en cierta forma, subestiman el trabajo.

En contraposición está el enfoque bottom-up, que consiste en estimar el esfuerzo sobre unidades funcionales del software más pequeñas. Para esto, es necesario hacer en forma combinada tres actividades: (1) Desgranar la funcionalidad en unidades mínimas (2) Estimar el esfuerzo individualmente para estas unidades (3) Calendarizar las pruebas individuales en el periodo de tiempo reservado para la prueba. Con este enfoque se tiende a exacerbar los detalles de la prueba produciéndose una sobreestimación del esfuerzo.

Estimar en base a ambos enfoques en simultáneo permite poner un poco de perspectiva sobre lo que uno realmente quiere invertir en la prueba. Así la tendencia natural a minimizar el problema del enfoque top-down se contrapone con la de maximizarlo del enfoque bottom-up.

Seguimos pensando..

[1] En aquella época no teníamos Google para tirar una consulta y ver cómo había resuelto el problema otra persona en este pequeño mundo que tenemos.

Patrones de servicio

2011-02-05T08:00:00.000-03:00

A lo largo de estos años trabajando en consultoría he llegado a la conclusión de que existen cierto patrones o templates de proyectos que tienden a repetirse a lo largo del tiempo y de los clientes.

Un ejemplo de esto es el de tipo “rescate de…”. Este patrón implica tomar una situación descontrolada en un cliente, entenderla, controlarla paulatinamente y luego enmarcarla en un proceso de trabajo predecible. El valor agregado en estos casos pasa principalmente por tener la capacidad de rescatar al cliente de su lío interno y no tanto por el tipo de actividad en juego en dicho lío. Si hablamos de un mantenimiento de software por ejemplo, el valor no está tanto en desarrollar software sino en manejar la situación de cómo es el proceso alrededor de dicha actividad.

El otro día leí aquí un párrafo que me recordó a esta idea que acabo de mencionar. Lo transcribo para clarificar:

Let’s take a closer look at the SIT methodology for new product development (NPD). At the heart of this methodology are 5 thinking tools, which are based on 5 templates of innovation. These templates are the outcome of a comprehensive analysis process of thousands of successful new products. These were collected and classified in an attempt to identify common patterns. Each such pattern depicts a certain type of transformation from the original version of a given product to the successful version of that product which was included in the analysis. And each such pattern was identified due to the fact that it was shared by several different successful products. The outcome of the analysis included 5 innovation patterns or templates, each occurring across a diverse range of successful products.

Los patrones de servicio resultan útiles porque facilitan el trabajo y achican los tiempos. Tener claro el patrón de servicio antes de darlo nos permite clarificar diferentes cosas con mayor rapidez y a menor costo:

Los roles necesarios en el equipo
El proceso de trabajo a seguir
Los entregables esperados por el cliente
Las características más salientes (por ejemplo: tiene ANS?)

Otros patrones de servicios que seguro les resultarán conocidos son “Relevamiento y Diagnóstico + Mejora” o “Servicio continuo de … (startup, estabilización, on going, cierre)”.

¿Qué otros patrones han detectado a lo largo de su experiencia laboral?

Seguimos pensando..

Más sobre el concepto de “la estrategia en una página”

2011-02-02T08:00:00.000-03:00

En la entrada anterior llamada 3 ejemplos de como presentar tu estrategia de negocio en una página mostré ejemplos de estrategias en una página. Aquí quiero contar el origen de la idea, que por supuesto no es mía.

Hace algo más de un año atrás encontré un post del blog Church of the Customer en el que mostraba un business plan de exactamente una página. Se trataba de un diagrama jerárquico que relacionaba objetivos, metas, estrategias y tácticas en forma de árbol. Por ese entonces andaba leyendo mucho sobre estrategia y me pareció una idea excelente.

Por un lado, si era capaz de lograr plasmar mi estrategia en una página, comunicarla iba a ser mucho más sencillo. Después de todo, ¿cuánto podía tardar en explicar una página a alguien? Y además, ¿no era que una imagen valía más que mil palabras?

Por la negativa, si NO era capaz de plasmar mi estrategia en una página, tenía un problema "estratégico".

A partir de eso tomé como regla que en cualquier análisis estratégico que hiciera iba a intentar llegar esa meta: la estrategia en una página.

Seguimos pensando..