fcnatra

Se rompió el vaso

2026-04-30T19:01:00.006+02:00

Puedo afirmar casi con absoluta certeza que alguna vez has dicho “se rompió el vaso”. Este pequeño detalle lingüístico, común en español y en japonés, refleja cómo es tu realidad y cambiarlo puede cambiar hasta cómo vives tu vida.

Esta forma de hablar es un constructo verbal que influye en cómo se recuerda la acción, minimizando la responsabilidad de la misma porque no se indica quién la hizo. En inglés, sin embargo, están acostumbrados a asociar una persona a las acciones, de modo que dirían “John broke the glass”, en vez de “The glass broke (itself)”, que haría parecer a la persona evasiva y falta de responsabilidad.

Por eso se dice que cada lenguaje es un reflejo de una cultura, y que cuando aprendemos uno nuevo, también aprendemos una forma diferente de ver la realidad.

Hace un par de años me sorprendió cómo mi mente hizo clic cuando Jorge Salinas nos contó en su máster la importancia de tomar el control de nuestras palabras: El vaso no se rompió, he roto el vaso sin querer.

Como explica Lera Boroditsky en su artículo para Scientific American "How Language Shapes Thought", el lenguaje moldea el pensamiento, y el pensamiento nos prepara para tener éxito (o no) en cada escenario de la vida. Forzarnos a usar un lenguaje alineado con la realidad que nos gustaría vivir nos va a acercar más a vivirla.

Cambiar las quejas por un plan y una acción ya tiene efecto inmediato, no sólo en cómo imaginamos el futuro sino también en cómo nos sentimos en el presente y en cómo nos relacionamos con los demás.

Reconstruir el lenguaje enfocado en el problema por un lenguaje enfocado en soluciones requiere práctica, pero ya sabemos que el cerebro es un músculo y también hay que entrenarlo.

“Esto no funciona”
👉 “Vamos a probar otra cosa”

“Se están quejando”
👉 “¿Puedo aprovechar esa la información?”

“No me dan oportunidades”
👉 “¿Qué habilidades necesito para tener más oportunidades”

Cada vez que construimos una narrativa que nos ayude a salir del problema, estamos creando oportunidades y nos estamos convirtiendo en personas más resolubles, optimistas, amables y felices.

Pensar “No me suben el salario” es una situación cotidiana, pero pensar sólo así es como decir “se rompió el vaso”. Descargamos la responsabilidad sólo en los demás. Si reconstruimos el lenguaje y decimos “¿Qué necesito hacer para ganar más el año que viene?” ya estamos planeando, nos frotamos las manos, nos preparamos para la acción – hacer una mejora, aprender una habilidad nueva, cambiar de empresa, montar una – y tenemos un objetivo claro, una presa.

Es habitual que el lenguaje verbal de una persona sea coherente con su comportamiento. Personas con un lenguaje amable suelen ser más amables en todas las facetas de su vida: el trabajo, en casa y conduciendo un coche. Personas con un lenguaje más duro, o -para reconocernos mejor- menos amable, serán más agresivas en esos mismos escenarios. Un escenario fácil de identificar es cuando conducimos un coche y nos quejamos por cómo conduce el resto, pero es raro encontrar a alguien que se plantee salir de ese escenario. Nos gusta conducir, pero ¿nos gusta conducir protestando y a disgusto?

Si queremos reducir el conflicto en nuestras vidas y encontrar más cooperación y, por ende, satisfacer antes nuestras necesidades, ayuda mucho practicar un lenguaje verbal más amable. Esto hará más amable nuestro comportamiento en el trabajo, en nuestra familia y sí, también al volante y ojo: la amabilidad en sí no es el objetivo final, sino un medio para mejorar la estabilidad y la felicidad en todos los ámbitos de nuestra vida.

Y si queremos aumentar las posibilidades de éxito en cualquier situación que se nos presente, es primordial tener un lenguaje que no se centre en el problema, en la queja y en los culpables sino que visualice las posibilidades de éxito.

Prueba este ejercicio: Identifica una frase que uses a menudo y que te limite y reconstrúyela por una en la que tomes el control.

El lenguaje es una herramienta. No lo uses sólo para describir la realidad, úsalo para crear una realidad mejor.

Piensas una cosa, haces otra - Disonancia cognitiva

2023-03-20T11:44:00.006+01:00

Leyendo artículos sobre comportamiento me topé -de nuevo- con el concepto de disonancia cognitiva. Cada vez que leo sobre ello me doy cuenta de que si no tenemos presente qué es y cómo se manifiesta, tendemos a comportarnos de ese modo, incoherente e incómodo.

Imagina que eres una persona muy preocupada por el medio ambiente, y siempre tratas de llevar un estilo de vida sostenible y respetuoso con la naturaleza. Sin embargo, un día recibes una oferta para trabajar en una empresa que produce y vende productos de plástico desechable en grandes cantidades. Sabes que el plástico es uno de los materiales más contaminantes y dañinos para el planeta, pero la oferta de trabajo es tentadora y te pagarían un salario muy atractivo.

La disonancia cognitiva es un fenómeno psicológico que ocurre cuando tenemos dos pensamientos, creencias o actitudes que son contradictorios o incompatibles entre sí. Es una teoría que propuso el psicólogo Leon Festinger en 1957 y que permite detectar cuándo "se dice una cosa, pero se piensa otra".

El conflicto que produce este comportamiento nos genera una sensación de malestar y puede afectar negativamente a nuestra salud mental, ya que puede provocarnos desde estrés hasta depresión. De ahí la importancia de estar alerta para detectarla y poder actuar a nuestro favor.

Hay algunos puntos que hacen saltar las alarmas, tanto si los vemos en otras personas como en nuestro propio comportamiento. Está claro que hay disonancia cognitiva cuando:

Minimizas la importancia del problema
Tratas de justificar tu decisión
Cuando te dan información nueva, la evitas o te bloqueas
Hablas de la perspectiva de los demás de forma imprecisa
Malinterpretas las opiniones o preguntas sobre el tema
Ajustas tus criterios para evaluar una misma situación que ocurre en dos momentos/lugares separados
Te enfadas o gritas
Atacas la personalidad de la otra persona, en vez de el problema sí, porque te quedas sin argumentos
Te alejas de las personas que hablen del conflicto

El uso de estas estrategias no será consciente en la mayoría de los casos. Son estrategias que usa nuestro cerebro para reducir el conflicto. Pero estas estrategias también las verás en personas que saben que no están diciendo la verdad, que saben que están dando información imprecisa o que saben que están ocultando información, y eso es porque hay disonancia entre lo que dicen y lo que saben (muy visto entre las personas de la política gubernamental).

Para evitar que exista la disonancia cognitiva, en cambio, se recomiendan las siguientes estrategias:

Cambiar una de las cosas que generan el conflicto y estar "en paz" con el cambio

Esto implica ajustar tus creencias y valores para que se adapten a tus acciones, o tratar de cambiar tus acciones para que se alineen mejor con tus creencias y valores.

Buscar información objetiva y contrastada sobre los temas que nos generan conflicto

Aprender más sobre lo que entra en conflicto puede ayudarnos a estar "en paz" con las acciones que hacemos y nos hace conscientes de qué pros y contras tiene cada parte. De esa forma podemos ser honestos con nosotros mismos y reconocer nuestras contradicciones e inconsistencias.

Además de estrategia, es muy saludable estar abiertos al cambio y al aprendizaje continuo, ser flexibles y tolerar que otras personas pueden tener otras opiniones y, por supuesto, buscar ayuda profesional si no podemos resolver el conflicto por nuestros medios.

Ser conscientes de nuestro comportamiento nos ayudará a estar más saludables, cultivar mejores relaciones y a ser más felices.

Para finalizar, adapto una historia sobre cómo sacar partido de la disonancia cognitiva (fuente Coursera, más abajo):

Un hombre muy bajito monta una tienda cerca de una escuela. Un grupo de niños que pasaba cada día frente a su tienda, camino a la escuela, le comenzó a llamar "¡Enano! ¡Enano!".

Un día el hombre les espera en la puerta de la tienda y les dice que a cada uno que le llame enano, le dará cinco céntimos, porque le gusta que le llamen enano.

Dos días seguidos pasaron gritando "¡Enano! ¡Enano!", y dos días seguidos el hombre bajito da cinco céntimos a cada niño. Pero al tercer día, el hombre les da dos céntimos a cada uno, bajo el pretexto de que no ha habido mucho negocio en la tienda. Y al cuarto día, cuando le gritaron "¡Enano! ¡Enano!", el hombre sólo les dió un céntimo a cada uno y nuevamente les dijo que no había mucho negocio. Al quinto día los niños no le gritaron, porque no iban a hacerlo sólo a cambio de un céntimo. Problema resuelto.

¿Por qué le acosaban gratis, pero no por un céntimo?

El cerebro tiende a reducir o evitar la inconsistencia psicológica, de modo que cuando el tendero dice que está contento con que le llamen "Enano" y cambia el juego de acoso a recompensa económica crea en los acosadores una inconsistencia y una disonancia en el acoso sin suficiente compensación económica. Muy parecido con el ejemplo del principio de este post.

¿Cambian nuestros principios si nos dan suficiente compensación económica? ¿Estamos en paz con ello?

Tú piensa.

Fuentes:

Wikipedia: https://en.wikipedia.org/wiki/Leon_Festinger

AIs: Bing's Sidney, OpenAI

Youtube: https://www.youtube.com/watch?v=EVF0ojfhSrE

Coursera: https://www.coursera.org/lecture/social-psychology/lecture-2-4-cognitive-dissonance-and-self-perception-iZcej

Managing workload

2017-12-17T14:54:00.000+01:00

Testing Python vs C# - Read CSV file

2017-12-05T08:53:00.005+01:00

Es inevitable que quiera hacer esto mientras aprendo un lenguaje.

No he aplicado nada de refactorización en Python, pero sí en C# para intentar ahorrar tiempo.
Seguro que habrá todavía margen de mejora en ambos lenguajes, pero ya había pasado el tiempo razonable dedicado a refactorizar.

Si tenéis sugerencias para reducir el tiempo de ejecución, genial, así aprendemos todos.

En la red podéis encontrar comparaciones más profundas de ambos lenguajes. Aquí dos de ellas:

https://www.slant.co/versus/110/115/~python_vs_c

http://onstartups.com/tabid/3339/bid/128/Python-vs-C-Business-and-Technology-Tradeoffs.aspx

Los resultados que obtuve son estos:

Read CSV file - 23865 rows, filter year 2015, sum values from one column

--- Excel
62683287355
62.683.287.355
62.683 million persons

--- Python
Rows after first filter: 274
Rows after second filter: 272

World population in 2015: 62683.287355 million persons
Read CSV file - 23865 rows, filter year 2015, sum values from one column
Execution time: 18.53711571297298ms

--- C#
Rows after first filter: 274
Rows after second filter: 272

World population in 2015: 62683,287355 million persons
Read CSV file - 23865 rows, filter year 2015, sum values from one column
Execution time: 24ms

PYTHON CODE

import pandas as pd
import timeit
import numbers

"""Read CSV file, filter year 2015, sum all results"""

def getDataFrameFromCsv(csvFileName):
   """Read CSV file"""
   worldPopulation = pd.read_csv(csvFileName, sep = ',')
   return worldPopulation

def filterColumn(dataFrame, columnName, columnValue):
   """Filter dataFrame by year columns"""
   dataFrameFilter = dataFrame[columnName] == columnValue
   filterResult = dataFrame[dataFrameFilter]
   print("Rows after first filter: " + str(len(filterResult)))
   return filterResult

def filterIntsInColumn(dataFrame, columnName):
   """Filter int values in column"""
   dataFrameFilter = dataFrame[columnName] >= 0
   filterResult = dataFrame[dataFrameFilter]
   print("Rows after second filter: " + str(len(filterResult)))
   return filterResult

def sumColumn(dataFrame, columnName):
   """Sum column"""
   result = sum(dataFrame[columnName])
   return result

def mainProgram():
   year = 2015
   yearColumnName = 'Year'
   populationColumnName = 'Medium Projection (UN Population Division (2015 revision)) (people)'
   fileName = 'world-population-1750-2015-and-un-projection-until-2100.csv'

   csvContent = getDataFrameFromCsv(fileName)
   contentFilteredByYear = filterColumn(csvContent, yearColumnName, year)
   contentFilteredByYear = filterIntsInColumn(contentFilteredByYear, populationColumnName)
   worldPopulation = sumColumn(contentFilteredByYear, populationColumnName)

   millionUnits = 10**6
   print("\nWorld population in " + str(year) + ": " + str(worldPopulation/millionUnits) + " million persons")

executionTimeInSecs = timeit.timeit(mainProgram, number=1)
print("Read CSV file - 23865 rows, filter year 2015, sum values from one column")
print("Execution time: " + str(executionTimeInSecs * 1000) + "ms")

C# CODE

using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;

namespace SumCsvColumn
{
    class Program
    {
        static void Main(string[] args)
        {
            long elapsedMs = MeasureMainProgram();
            PrintResults(elapsedMs);
        }

        private static long MeasureMainProgram()
        {
            var watch = System.Diagnostics.Stopwatch.StartNew();

            MainProgram();

            watch.Stop();
            var elapsedMs = watch.ElapsedMilliseconds;
            return elapsedMs;
        }

        private static void PrintResults(long elapsedMs)
        {
            Console.WriteLine("Read CSV file - 23865 rows, filter year 2015, sum values from one column");
            Console.WriteLine("Execution time: " + elapsedMs.ToString() + "ms");
            Console.ReadLine();
        }

        private static void MainProgram()
        {
            var year = 2015;
            string[] columnNames = null;

            var yearColumnName = "Year";
            var yearColumnIndex = 0;

            var populationColumnName = "Medium Projection (UN Population Division (2015 revision)) (people)";
            var populationColumnIndex = 0;

            long worldPopulation = 0;
            double millionUnits = Math.Pow(10, 6);

            string[] csvContent = LoadCsvFile();
            IEnumerable<string[]> rowsSplitted = SplitRowsIntoColumns(csvContent);

            columnNames = rowsSplitted.First();
            yearColumnIndex = Array.IndexOf(columnNames, yearColumnName);
            populationColumnIndex = Array.IndexOf(columnNames, populationColumnName);

            rowsSplitted = FilterColumn(rowsSplitted, yearColumnIndex, year);
            worldPopulation = SumColumn(rowsSplitted, populationColumnIndex);

            Console.WriteLine("\nWorld population in " + year.ToString() + ": " + (worldPopulation / millionUnits).ToString() + " million persons");
        }

        private static string[] LoadCsvFile()
        {
            string fileName = "world-population-1750-2015-and-un-projection-until-2100 - CS.csv";
            String[] csvContent = GetArrayFromCsv(fileName);
            return csvContent;
        }

        private static long SumColumn(IEnumerable<string[]> rows, int columnIndex)
        {
            long sumResult = 0;

            foreach (var row in rows)
                sumResult += GetNumberFromString(row[columnIndex]);

            return sumResult;
        }

        private static long GetNumberFromString(string value)
        {
            return long.TryParse(value, out long longResult) ? longResult : 0;
        }

        private static IEnumerable<string[]> FilterColumn(IEnumerable<string[]> rows, int columnIndex, int columnValue)
        {
            var columnValueToString = columnValue.ToString();

            var filteredResult = rows.Where(row => row[columnIndex] == columnValueToString).ToList();

            Console.WriteLine("Rows after first filter: " + filteredResult.Count().ToString());
            return filteredResult;
        }

        private static IEnumerable<string[]> SplitRowsIntoColumns(string[] csvContent)
        {
            return csvContent.Select(row => row.Split(',')).ToList();
        }

        private static String[] GetArrayFromCsv(string fileName)
        {
            String[] values = File.ReadAllText(fileName).Split('\r');

            return values;
        }
    }
}

Ishikawa

2017-12-02T08:46:00.001+01:00

"Es muy difícil saber qué sucederá dentro de un minuto.

Podemos crear todas las condiciones para que suceda lo que esperamos: mover una taza, dibujar una línea, abrir una ventana, pero no es posible saber con exactitud qué sucederá.

La causalidad encadena un acontecimiento tras otro hasta el efecto final. Ni siquiera los primeros principios - esos irrefutables - son primeros.

Pero sí debemos responsabilizarnos por nuestras acciones - nuestros primeros principios - los que nos han llevado hasta donde estamos. No hay que sufrir, no hay que resistirse a lo que es.

Hay que aceptar que estamos aquí por lo que hemos hecho, pero tenemos que saber qué hemos hecho para estar aquí. Así, más adelante sabremos a dónde nos llevarán esas mismas acciones.

Por desgracia, a las personas se nos olvida pronto todo lo que no nos impacta de un modo irreparable. Y aún de aquellas situaciones que nos han afectado mucho no sabemos encontrar la causa. Así vamos, ciegos paso tras paso, sin saber qué sucederá dentro de un minuto."

En ciclo de vida del software cobra cada vez más importancia analizar que medir. No quiere esto decir pensar dos veces y hacer una, sino que va más relacionado con la observación.

En esto nos pueden ayudar los diagramas causales, como parte de las retrospectivas y acciones de mejora. (Ver Ishikawa)

Coger un problema que puede repetirse.
Colgar de él una línea central.
Colgar los principales actores de esa línea central.
Colgar de los actores las principales acciones (causas) que pueden contribuir a el problema
Colgar de esas acciones otras acciones que han influido a que esa acción suceda.

De VARGUX - Trabajo propio, GFDL, Enlace

Si minimizamos las acciones que han contribuido a llegar a este problema, es posible no repetirlo y que nuestro próximo intento termine en un escenario positivo para nuestros equipos y nuestros clientes.

Ahí os lo dejo.

Autoridad y Liderazgo

2015-11-12T22:39:00.004+01:00

Back again sharing my thoughts!

La última reunión que tuvimos en Agile Norte de nuevo me ha dado energía para compartir lo que he escuchado, compartido y aprendido con los que asistimos a ella. El formato se hizo en forma de taller, guiado por Joserra Díaz, que siempre nos da cancha para discutir sobre nuestras experiencias y compararlas con las ideas que nos expone.

Taller de Liderazgo de Equipos Ágiles

Joserra nos preparó con un ejercicio de calentamiento tipo "follow the leader" del que terminamos discutiendo si nos sentíamos más cómodos siguiendo una mano o haciendo que la otra persona la siguiese y también del porqué habíamos accedido a hacer el ejercicio.

Algunos se sentían más cómodos siguiendo, otros haciendo que siguieran su mano, pero al final lo que quedó claro es que le habíamos dado "autoridad" a Joserra para que nos indicara qué ejercicio hacer. Autoridad formal, que no informal. Formal porque confiamos en que por su experiencia sabría lo que hacía y por qué. No la autoridad informal porque debía ganársela durante la charla. Es decir, era autoridad, no liderazgo.

Llevándolo al entorno ágil todos expusimos nuestra opinión sobre qué autoridad formal o informal tienen (o deben tener) a los roles básicos en un marco de trabajo Scrum y está claro que al discutirlo ninguno nos sentimos demasiado cómodos y menos aún al exponer las características que debía tener un "buen seguidor".

Quedó claro que un la elección de una líder raramente es formal, ya que cada persona puede cambiar de rol - de seguidor a líder o viceversa - dependiendo de la situación. Esta selección de la persona que creemos nos puede representar, ayudar o guiar en determinado momento a resolver un conflicto o salir de un problema es casi inconsciente. Para cada conflicto, reto o mejora una persona diferente puede erigirse como líder en una transición imperceptible. Yo me atrevería a decir que más que "puede", debería suceder así.

¿Un líder nace o se hace?

Es indudable que hay personas que nacen con habilidades de liderazgo y que al parecer son "buenos en todo", pero es común que con el tiempo salgan a la luz las fortalezas o carencias en determinadas situaciones. Normalmente estas personas son más identificadas con la autoridad.

Habilidades de comunicación y motivación ayudan mucho a identificar a una persona como líder, además de sus conocimientos sobre cómo hay que afrontar los problemas a los que hay que poner solución, pero es más su actitud ante los problemas lo que le erige como tal ante determinadas situaciones.

Principalmente son estas características las que dotan de liderazgo a una persona:

- Generar un proceso de movilización: Un líder no es líder si nadie le sigue. No es que necesite hacerse de seguidores (lo que es la autoridad, el "jefe" que todos conocemos) sino que las personas deben percibir que su trabajo tiene un objetivo que claramente mejorará la situación actual.

- Afrontar una "realidad incierta": Pisar terreno firme es sencillo. Un líder se arriesga. No es que no tenga cabeza, es que tiene claro que no hay cambio sin riesgo y no hay mejora sin cambio.

- Desarrollar en el entorno nuevas capacidades de adaptación: No todos los cambios propuestos llegan a buen puerto, pero en cada intento hay aprendizaje y con cada pequeño logro se mejora la capacidad de las personas que han participado en él y del entorno para adaptarse a nuevas situaciones.

- Tener como propósito el progreso y el bienestar del grupo que lidera: Aquí también hablamos sobre si un líder es en realidad un manipulador. Una cosa quedó clara: un líder sí manipula al entorno para conseguir su propósito (genera un proceso de movilización a través de acciones que hagan a las personas percibir un objetivo de mejora) pero también el propósito del líder es el progreso y el bienestar. Aunque se consiga generar un proceso de movilización, tarde o temprano se verá si el propósito es el adecuado o no.

Y por último comentamos un tema que fue el colofón del taller: si se tira mucho de la cuerda, ésta se rompe y el entorno ya no tomará en serio las propuestas, y si se afloja mucho la cuerda nadie escuchará las propuestas que se hacen o éstas caerán en saco roto. Lo ideal está en el medio, en no cejar, en forzar la máquina pero no demasiado. - Y Joserra nos lo dijo en unas palabras que calaron en todos: "El líder mantiene el desequilibrio y el conflicto, porque el conflicto genera adaptación y aprendizaje".

La zona de aprendizaje está justo en el medio, en no dar mucho la tabarra, pero no dejar de hacerlo, NUNCA.

No te rindas.

Hackeando Agile - De vuelta a los principios ágiles

2015-06-24T09:20:00.002+02:00

Acabo de llegar de la Agile Open Spain 2015 y, como siempre, me traigo ideas nuevas para trabajar.

En esta edición hemos discutido sobre relación con el cliente, equipos, eficiencia, hemos traído nuestros problemas y retos y los hemos presentado a los demás, pero también hemos hackeado Agile con el Dojo de #NoIfs y con las discusiones #NoProjects #NoEstimates #NoTeams #NoProductOwner.

De todas las AOS, en mi bolsa de ideas, siempre reservo la "caja del tesoro" para lo que más me ha llamado la atención. En esa caja me traje el año pasado el cómo aborda Diego Rojas el coaching, para mí el descubrimiento del año.

Este año han sido Joserra Díaz y Jorge Uriarte los que me han hecho pensar en qué estamos haciendo mal para que a tantas empresas les cueste tanto aplicar correctamente las prácticas ágiles.

Jorge nos lanzó la pregunta de en qué punto creemos que se encuentra la adopción de los marcos ágiles de trabajo - en nuestro entorno laboral -. Hubo diversas opiniones, desde quienes piensan que estamos al inicio de la curva de adopción hasta los que opinan que estamos en la cima.

Pero un punto nos quedó claro: muchas empresas lo intentan más de una vez y desisten del intento, otras implantan prácticas ágiles de modo incorrecto no consiguiendo el objetivo de la práctica en sí y son muy pocas las que consiguen tener un marco de trabajo ágil correcto, con lo que he aquí la pregunta: ¿Debemos aceptar el fracaso ágil?

Como juego para hackear Agile, este título no es más que un reto para que nos preguntemos qué está pasando.

Con las opiniones de unos y otros y las muy valiosas de Xavier Gost, que es un exponente claro de la base sólida Agile, fuimos desgranando los motivos de por qué estamos donde estamos...

Intentamos aplicar las prácticas de Agile olvidándonos de que esas prácticas se basan en los principios Agile

Y es cierto.

¿Cuántas veces escuchamos hablar sobre Scrum, Lean, Kanban, TDD, Clean Code, Inceptions, Motivation, GTD, Pomodoro, Retrospectives y muchas otras prácticas para mejorar en eficiencia, comunicación, desarrollo, entregas y cuántas otras veces escuchamos a alguien mencionar los doce principios que promueve el Manifiesto Ágil?

La verdad es que no necesitamos hacer TDD, necesitamos ser capaces de hacer desarrollos simples que funcionen, "maximizar la cantidad de trabajo NO hecho".

No necesitamos Scrum, necesitamos entregar frecuentemente software que funcione.

De hecho, no necesitamos entregar por entregar, sino entregar software que tenga valor para el cliente porque nuestra máxima prioridad es satisfacerle.

Es más, implantar estas técnicas "desde las trincheras" como hemos hecho muchas veces, nos lleva a esta situación en la que podemos practicar, pero no conseguir un paso constante, seguro e interiorizado de las prácticas ágiles, porque para que funcionen las personas de negocio y las de desarrollo deben trabajar juntos y a diario en los proyectos (o en un #NoProject ;)

Quizá nos convendría poner en un mapa estos doce principios y asociar cada técnica que empleamos al principio en el que se basa, para que no olvidemos el por qué queremos usar esa técnica... ese "SO THAT" en que hacemos tanto hincapié.

Eso me he traído esta vez en mi caja del tesoro. Ahora que la he abierto estoy venga a jugar con esas ideas.
Jmmm...

Productividad - Compartiendo experiencias

2014-02-06T17:29:00.004+01:00

El pasado 22 de enero de 2014 nos juntamos varias personas para compartir un poco nuestras experiencias - buenas o malas - sobre la productividad

Formamos un par de equipos que participaron en el juego de terminar un dibujo en tres pequeñas iteraciones, sin que el currela/dibujante/víctima supiera lo que se cocía a su alrededor… uno de los equipos tenía un ladrón del tiempo entre ellos, previamente pactado.

Aunque para algunos fue un poco pesado tener que esperar solos a que explicáramos el juego a los implicados - cosa que tendré que mejorar la próxima vez -, el resultado del juego nos dio pie para comenzar a discutir sobre la importancia de los agentes externos en la productividad y cómo no nos damos cuenta de todo aquello que nos roba tiempo y concentración de las tareas más importantes que tenemos que terminar.

Ya metidos en el ajo, todos aportamos nuestro granito de arena sobre cómo sacar más partido del tiempo y los recursos para obtener determinados resultados (más resultados o de mejor calidad, depende de cómo se mire), pero sobre todo, hablamos de cómo conseguir estar un poco más en paz con la avalancha de trabajo que se nos viene encima cada día.

Estos son algunos de los temas de los que hablamos:

Foco sobre la tarea que queremos abordar
Aprender a decir “NO”
Listas, Organizar, Priorizar
Técnica Pomodoro
Evitar distracciones
Gestionar interrupciones
Productividad a nivel de equipo
Gestión del correo electrónico
Técnica GTD (Getting Things Done)

De todo lo que hablamos dedicamos bastante tiempo a cómo conseguir dedicar períodos de tiempo en los que centrar la dedicación a una sola tarea y para ello, claro está, la técnica Pomodoro es ideal, así fue tema recurrente bastantes veces y al parecer, caló entre los asistentes.

- sketching de @iceoverflow

- comentario de @joruus

Sólo con haber conseguido que uno de los puntos cale hondo debemos sentirnos satisfechos con haber participado de este encuentro. Gracias a la colaboración de Consultec S.L. (@ConsultecSL) por facilitar el sitio donde juntarnos y a Agile Norte (@agileNorte) por promover este tipo de eventos.

La guía de la reunión la encontraréis en: http://bit.ly/fcnatraProductivityTips

Aprender es más fácil compartiendo experiencias. Gracias por venir!

Caso de Éxito: Scrum en un proyecto de 3 meses

2013-08-20T10:20:00.002+02:00

Me habían pedido muchas veces que publicara cómo hicimos para que este proyecto tuviera un principio y final felices y aquí va mi retrospectiva personal.

Proyecto: Proyecto de software para industria.

Cliente: Familiarizado con las tecnologías de software, había oído hablar de Scrum, pero nunca lo había usado como marco de trabajo.

Equipo: Tres personas. Dos de ellas habían trabajado con Scrum, otra no lo conocía. Las tres personas tenían una velocidad de trabajo diferente.

Mi empresa: Nos da la libertad de gestionar el proyecto siempre que se obtengan los resultados esperados, según mi opinión, en este orden:

Calidad: la máxima posible, intentando no afectar las fechas planificadas
Fechas: lo más cercano a las planificadas, intentando no afectar los requisitos
Requisitos: los acordados con el cliente al principio del proyecto o los que se acuerden a lo largo del proyecto

Inicio del proyecto

Los requisitos, las fechas y el presupuesto ya estaban pactados con el Cliente, pero como hago siempre, reviso de nuevo los requisitos y vuelvo a realizar una estimación predictiva con al menos uno de los miembros del equipo que va a formar el proyecto para hacerme una idea de la presión que vamos a tener. En este caso, preveía una desviación de aproximadamente un 20%.

Decidimos – el Equipo de Desarrollo – hablar con el Cliente para volver a analizar en profundidad todos los requisitos y de paso construir el Product Backlog. Para ello, sin usar términos de Scrum, le comentamos que queríamos reunirnos con ellos para analizar todos los requisitos.

Mi idea era realizar parte de una Inception, que me permitiera dejar claro a todos las partes del proyecto qué es lo que íbamos a hacer y cómo lo haríamos.

¿Por qué no toda la Inception? Pues porque era la primera vez que iba a jugar con esta técnica y porque se supone que ya estábamos consumiendo horas del proyecto en la que no se había presupuestado tiempo para esto. De modo que seleccioné aquellas preguntas que creí me permitirían acotar mejor el proyecto:

Definir el proyecto en una explicación corta y concisa
Definir qué NO es este proyecto
Comentar qué podría quitarnos el sueño durante el desarrollo de este proyecto
Conocer a los vecinos – esa lista de implicados, sean personas o no, a los que afectará el proyecto

De estos puntos lo que más nos ayudó, sin ninguna duda, fue definir “Qué podría quitarnos el sueño”. Fue lo que más nos ayudó con diferencia. Y en orden, saber “qué no es este proyecto”, luego alguna vez recurrimos a la definición del proyecto y por último, para las Historias de Usuario y definición de la seguridad, a la lista de vecinos. El haber hecho estas preguntas fue decisivo para que el proyecto llegara a buen puerto.

Luego, en un par de jornadas duras escribimos las Historias de Usuario del Product Backlog, de modo que el cliente quedó contento porque reflejaban de forma clara qué se quería hacer, para quién y por qué, aunque no estaba reflejado el cómo. Cada vez que escribíamos una, comentábamos brevemente, junto con el equipo, sobre la dificultad de la historia de usuario y le asociábamos un valor que representaba ese esfuerzo. Habiendo explicado muy rápido cómo definíamos ese valor, por qué usábamos puntos y no horas y por qué mientras más esfuerzo más separación había entre un valor de esfuerzo y el siguiente, no hubo problemas.

Cabe decir que para escribir las Historias de Usuario leímos más de una vez la oferta formal que se hizo para la contratación del proyecto, pero salieron muchas cosas que no estaban escritas en la oferta, de modo que la satisfacción estaba asegurada para todos. Así llegamos a completar la lista inicial del producto y nos hicimos una idea de cuánto esfuerzo nos llevaría desarrollar todo lo que se quería.

Una vez conocido el esfuerzo total (recalco: inicial) – hicimos un cálculo muy sencillo:

Explicamos al cliente que el equipo tenía una velocidad de trabajo de N puntos diarios y que esos puntos reflejaban:
- la cantidad de trabajo que el equipo era capaz de sacar adelante cada día, es decir, la capacidad diaria de trabajo
- que esa capacidad diaria (N puntos) es equiparable a los puntos de esfuerzo asignado a las tareas
Luego, teniendo la fecha límite para la entrega del producto, contamos los días laborables y determinamos la capacidad de trabajo total - aproximada- hasta la fecha de entrega y vimos que no coincidían, como casi nunca coincidirán. Para desarrollar todas las historias de usuario se necesitaba más esfuerzo que capacidad tenía el equipo.

Viendo esto, le explicamos que eso sucede en la gran mayoría de los proyectos y es por eso que se entregan fuera de plazos, con poca calidad y muchos errores, y que para evitar eso, lo que nos aseguraba la calidad era la priorización de tareas por períodos de tiempo de 15 a 20 días y la entrega, demostración e instalación del producto al final de cada período.

Es en este punto donde se produce un problema de negociación importante. Es en este punto clave donde hay que explicar bien, si no cabe todo, por qué no cabe y qué consecuencias traería intentar desarrollar todo con los mismos recursos en el mismo tiempo. Es en este punto – el más importante de la negociación del tan famoso triángulo de compensación – donde se va a definir qué se mueve de los pilares del proyecto: Coste/Recursos, Tiempo/Fechas o Alcance/Funcionalidades. Nosotros conseguimos explicarnos bien y he de reconocer que teníamos un cliente que comprendía las consecuencias de una decisión incorrecta – decidimos que variarían las funcionalidades a desarrollar y que las menos importantes, quedarían fuera del desarrollo, se realizarían en fases posteriores.

Cuando hay funcionalidades que se quedan fuera de alcance la mayoría de las veces se recomienda – en este orden:

[Alcance] Dejar fuera aquellas funcionalidades menos importantes del proyecto, para futuras fases, después de probar, entregar y facturar lo que se ha desarrollado – Esto es sencillo si se prioriza bien al principio de cada Sprint.
[Coste] Ampliar el equipo hasta donde lo permita el proyecto y abordar más funcionalidades. Esto requiere una ampliación del presupuesto y requiere que la empresa cuente con personas capaces de integrarse en el equipo existente. – Dos opciones difíciles de conseguir.
[Tiempo] Como opción última y menos recomendable, mover la fecha de entrega final. Esta opción también requiere variar el presupuesto, porque a más tiempo de desarrollo, más costes para el proyecto – y este es un punto de muy difícil negociación una vez firmada la oferta.

Hay que intentar por todos los medios no mover la fecha de entrega final, porque será el comienzo de una fecha de entrega cambiante que alargará indefinidamente el tiempo de desarrollo y los costes del proyecto.

Nosotros decidimos optar por la primera opción (dejar fuera aquellas funcionalidades menos importantes) ya que ampliar el presupuesto para ampliar el equipo no estaba en los planes. Casi siempre es la opción escogida.

Y dicho esto, ¡comenzamos con el primer Sprint!

Inicio de cada Sprint

Ya en las reuniones de inicio del proyecto le explicamos al cliente que para obtener el producto que él necesitaba, nosotros, el equipo, necesitaríamos compromiso por su parte y que era imprescindible que estuviera al principio y al final de cada Sprint para validar que el trabajo que íbamos a hacer era el que él necesitaba.

De modo que habiendo llegado a un acuerdo, antes de iniciar cada Sprint hacíamos, junto con el cliente, una selección de Historias de Usuario.

¿Cómo las seleccionábamos?

La primera vez fue un poco duro porque nuestro Product Backlog no estaba priorizado, de modo que comenzamos por priorizarlo todo. Nuestra técnica para priorizar fue la siguiente:

Decidimos priorizar asignando valores de 1 a 100.
Aquellas Historias de Usuario con una prioridad de más de 75 puntos quedarían fuera del alcance de nuestro desarrollo y podrían abordarse en fases posteriores. Es importante matizar esto para evitar la idea de que esas funcionalidades nunca se van a hacer.
Comenzamos por la primera Historia y le asignamos una prioridad.
Pasamos a la segunda Historia y le asignamos una prioridad respecto a la primera Historia priorizada con una pregunta muy sencilla – “¿esta Historia es más o menos importante que esta otra?” – y luego, sabiendo si era más o menos importante, teníamos un valor de referencia para priorizarla.
Pasamos a la tercera historia y la priorizamos respecto a las dos Historias ya priorizadas, usando la misma pregunta.
A partir de la cuarta Historia teníamos varias referencias para priorizar y era mucho más sencillo decidir cuándo se debía hacer esa Historia, si antes o después de otra.

Si no teníamos claro el orden en que debíamos poner dos Historias de Usuario podíamos darles la misma prioridad o cambiar algún valor de prioridad que habíamos dado anteriormente a otra Historia.
Al Product BackLog podían entrar nuevas Historias de Usuario en cualquier momento. Al inicio del siguiente Sprint les asignábamos un esfuerzo y las priorizábamos.

Al saber cuánta capacidad de desarrollo teníamos hasta la fecha de entrega y tener priorizadas –ordenadas- las Historias, sabíamos qué se quedaba fuera cada vez que entraba una nueva historia. Eso permitía al cliente ver, en todo momento, las consecuencias de los nuevos requisitos y priorizar mejor, porque la prioridad indicaba qué entraba y qué no entraba en cada versión del producto final.

Y una vez priorizadas, seleccionamos las Historias de Usuario del Sprint por comenzar. Para seleccionarlas, en vez de decidir primero los días que iba a tener el Sprint, seleccionábamos un grupo de ellas que ocuparan de 15 a 20 días de desarrollo – las más importantes. Los pasos que hacíamos eran:

Seleccionar las Historias más importantes, según su prioridad, de modo que la suma del esfuerzo ocupara de 15 a 20 días de desarrollo, atendiendo a la velocidad del equipo de desarrollo.
- Si ya el cliente había probado una versión anterior del producto:
  - Hablamos de los cambios que deseaba incluir o las incidencias que había encontrado.
  - Los cambios ya sabemos cómo los tratamos: incluimos y priorizamos antes de comenzar la selección.
  - Las incidencias son la mayoría de las veces responsabilidad nuestra y tenemos que resolverlas como primeras tareas del siguiente Sprint, suman tiempo al Sprint, tiempo que debe asumir el equipo y que no suele ser facturable.
- Si se habían incluido Historias de Usuario – cambios – durante el desarrollo del Sprint anterior, se priorizaban antes de comenzar la selección.
Definíamos en presencia del cliente las Tareas a realizar por cada Historia de Usuario y le asignábamos el tiempo de desarrollo a las tareas, esta vez en horas. Comprobábamos que la suma horas de las tareas se correspondía con el esfuerzo que habíamos asignado a la Historia de Usuario contra la Velocidad de trabajo. Si no se correspondía, modificábamos el esfuerzo de la Historia, para ser realistas.
- En cada tarea poníamos, junto con el cliente, lo mejor que sabíamos, los criterios de aceptación
- Dentro de las tareas de cada Historia, como costumbre personal, incluimos la de actualizar la Guía de Usuario y la Guía de Instalación, de modo que con cada entrega tuviésemos actualizada la documentación a entregar – por cada tarea. Esto me ha demostrado un ahorro de tiempo considerable.
Por último, definíamos los días que ocuparía el Sprint y la fecha de la próxima reunión, donde realizaríamos la demo y entregaríamos al cliente el desarrollo realizado para que lo instalase en los servidores, junto con la documentación que le permitiría instalar y trabajar con el producto.

Me gustaría recalcar dos puntos que considero muy importantes:

En el primer Sprint incluimos todas las tareas necesarias para montar la arquitectura inicial del proyecto. Esas tareas las incluimos delante del cliente, de modo que viera que “eso” también lleva tiempo. No hubo problemas con la asignación de tiempo para ello.
En el primer y segundo Sprints decidimos incluir todas aquellas funcionalidades relacionadas con “aquello que nos quita el sueño” y que hablamos en la Inception. Esta decisión nos quitó muchísimas preocupaciones de encima a lo largo del proyecto, ya que todos los problemas que podían surgir se solucionaron en la primera mitad del proyecto, consiguiendo el final feliz que todos queríamos.

Reuniones de planificación, seguimiento, entrega y todas (y sólo) las que sean necesarias

Respetar el tiempo de los demás es primordial para que las reuniones sean efectivas y no se vean como innecesarias o como un retraso en el trabajo.

Para ello, es muy importante al realizar una convocatoria poner bien claro de qué se va a hablar en la reunión y poner una duración realista para que todos sepan de antemano a qué se va y cuánto tiempo se va a estar.

Por lo demás, hay mucha documentación que ayuda a mantener reuniones efectivas. De modo que no comentaré este punto.

Durante todo el proyecto intentamos, por todos los medios, mantener las reuniones que recomienda Scrum y lo conseguimos. Nos reuníamos tanto de forma presencial como en remoto.

No sólo nos juntábamos en el momento de la reunión, sino que cuando hizo falta, hicimos pair-programming aunque tenemos que mejorar en las técnicas a emplear y cualquier otra vez que lo necesitábamos, nos juntábamos para comentar cómo abordar un determinado detalle del proyecto. – Nunca nos pareció que nos juntásemos más de la cuenta, la verdad, y cuando pensábamos que nos estábamos enrollando mucho cualquiera de nosotros lo decía y decidíamos lo que fuese – o seguir o cambiar o arrancar a desarrollar de nuevo.

Es responsabilidad de todo el equipo – incluyendo al cliente, claro está – el no malgastar el tiempo. De cualquier modo, cuando tenemos las tareas ahí, frente a la cara, esperando para ser desarrolladas y un tiempo con el que nos hemos comprometido, sabemos que hay que trabajar porque es nuestra palabra el entregar en tiempo y forma lo que hemos dicho.

Y no sé qué más contaros… ah sí, una cosa, en el último Sprint decidimos “probar” a no actualizar las guías de usuario y de instalación en cada tarea, sino actualizarlas al final, como última tarea, antes de la demo con el cliente. Resultado? – Esa vez no pudimos entregarlos porque nos concentramos en terminar otras cosas más importantes.

Post-Proyecto

Una vez entregado el último paquete del producto nos cogimos un par de semanas por nuestra cuenta para probar bien el producto e ir solucionando aquello que no funcionase bien. Esto nos lo pudimos permitir por la carga de trabajo de ese momento. Por lo general ese tiempo debe estar planificado dentro del proyecto, desde el inicio, y casi nunca se hace para abaratarlo. No debería haber problemas si se desarrolla bien, pero eso es casi una quimera.

El cliente no nos reportó prácticamente ninguna incidencia y las que encontramos por nuestra cuenta las resolvimos e hicimos una última entrega.

Ya que el cliente planeaba continuar ampliando por su cuenta el producto, pero quería realizarnos consultas o solicitarnos pequeños desarrollos se le propuso una bolsa de horas en las que nos pudiera solicitar cualquier desarrollo sobre el mismo u otro producto y las consultas que necesitase y fue aceptada.

El cliente nos envió un mensaje contándonos lo cómodo que estuvo durante el tiempo de desarrollo y su satisfacción con el producto final.

Nosotros aprendimos a valorar – yo una vez más – la comodidad del trabajo con Scrum.

Hay muchos más detalles sobre el trabajo de desarrollo día a día, pero cada uno de ellos merece ser explicado con calma.

Espero que esta historia os sirva para algo y si hacéis otras cosas que nos permitan mejorar el trabajo y sentirnos más cómodos al abordar un proyecto, estaré encantado de que me lo contéis.

Pon un hobby en tu vida, que te guste y que te ayude

2013-06-27T11:08:00.003+02:00

Sí, un hobby, no un hobbit.

Tenemos toda la libertad del mundo para escoger qué hacer con nuestro tiempo libre: ver la tele, ir al cine, ayudar a otros, leer un libro, practicar un deporte o un juego de mesa, o salir con nuestras amistades, pero ese hobby ¿lo hemos elegido nosotros o es él quien nos ha elegido? ¿Hemos probado otras opciones que podrían mejorar nuestra vida de forma significativa? A veces nos dejamos llevar y terminamos dedicando nuestro tiempo libre a algo que nos entretiene, pero que no nos aporta nada.

Elegir un hobby que nos permita llevar una vida personal y profesional mejor va a incidir en nuestra calidad de vida en... ¿cuánto?... mucho, sin duda. Eso sí, la elección no es tarea sencilla. Bueno, escoger sí, acertar con uno que además de ayudarnos, nos guste, quizá no tanto.

Uno bien seleccionado nos ayudará a afrontar mejor los problemas, porque mientras lo practicamos nuestro cerebro y nuestro cuerpo también practican y eso nos moverá a tener otros puntos de vista, mejor humor y más paciencia. He probado los efectos positivos de un buen hobby y los hecho mucho de menos cuando no lo practico.

El hecho de sentirnos cómodos con lo que hacemos en nuestro tiempo libre nos hace dudar ante la idea de cambiar la forma de aprovechar ese tiempo. Salirnos de nuestra “zona de confort” siempre nos da pereza y miedo, pero una vez que nos lanzamos se abre ante nosotros un mundo nuevo de experiencias. De hecho, no es imprescindible cambiar nuestros pasatiempos, sino que lo verdaderamente interesante es explorar más allá de lo que conocemos.

Por ejemplo, un deporte nos traerá consigo beneficios físicos y efectos mentales positivos. Al practicar ejercicio físico nuestro cuerpo genera endorfinas que nos producen bienestar, vitalidad y alegría y que tienen un efecto analgésico. He tirado de la wikipedia y de endorfina salté a opiáceos y de ahí a narcóticos... entonces paré... No en balde dicen muchos que ciertos deportes son como una droga... te enganchan.

Si el hobby que practicamos es de trabajo en equipo, mejorará tus habilidades de comunicación, te ayudará relacionarte y a sentir más empatía por quienes te rodean. Esto nos hará la vida más fácil en el mundo laboral.

Lo que sí es importante es que ese hobby no sea la misma tarea que realizas en el trabajo, porque eso no abre tu campo de mejora personal, no relaja tu mente, no te ayuda a cambiar el chip ni a resolver los problemas "retos ;)" que se presenten, porque sólo tienes una perspectiva para afrontarlos.

En mi opinión, el objetivo no debería ser encontrar el hobby ideal (que nos guste y nos ayude personal y profesionalmente) - aunque si lo encontramos, mejor -. Lo más importante de todo es, como en todas las facetas de la vida, explorar nuevos caminos. Es en esa búsqueda donde creceremos de verdad.

Caminante, no hay camino, se hace camino al andar

Y ya que os incito a tener un hobby os digo el mío, el que me gusta y me ayudó a crecer mucho, y que tengo un poco abandonado: es el Mugendo. Espero retomarlo pronto.

Auto-conversación (¿salario = valor que aportamos?)

2012-07-09T09:13:00.002+02:00

- ... ¿y si nuestro salario lo definiese el valor que fuésemos capaces de aportar? - una media del valor que aportamos, por ejemplo. Sería todo más justo, ¿no?

- Estaría bien, pero... ¿qué empresa puede decir con certeza que es capaz de "medir" el valor que aporta cada persona? ¿cómo se podría medir el valor que aporta un scrum master, un director de departamento o un comercial?, ¿ventas, reuniones? ¿cómo se mide la motivación que has creado, el conocimiento que has transmitido, la organización que has conseguido implantar? - ¿encuestas, velocidad de programación?

- Al final, el valor que se aporta no siempre va alineado con el valor que necesita la empresa que aportes, pero en ese caso, ya sabemos qué hay que hacer: poner a cada persona en el sitio en el que más valor aporte. La medición del valor aportado sacaría a la luz que no estamos dando lo que se necesita en el puesto en el que estamos. Quizá yo sea mejor programador que jefe de proyectos, o viceversa.

- Volvemos a una premisa fundamental: todo pasa por medir. Algunas empresas lo hacen mediante falsas evaluaciones del desempeño. Digo falsas porque no se basan en medidas claras, muchos de sus puntos se basan en opiniones y, lo más grave, en muchísimas empresas no hay suficiente confianza como para hacer evaluaciones de 360 grados.

- Según este curso de microeconomía, la empresa debe contratar "siempre y cuando el valor que genera el nuevo trabajador sea mayor que el salario que le tiene que pagar", pero ¿con qué herramientas cuenta la mayoría de las empresas para medir lo que está aportando una persona? - Muchas dirán el valor se mide en que termine su trabajo a tiempo lo cual es incorrecto, ya que si el trabajador no ha participado en la estimación de ese trabajo, la planificación es incorrecta y por ende, la medición posterior también.

- ¿Eres capaz de decir qué velocidad de programación tienes? ¿Qué herramientas usas para organizar y medir tu velocidad? ¿Somos capaces - personas o empresa - de decir en qué podemos aportar valor y promoner medios para medirlo? ¿Es capaz una empresa de realizar una medición real del valor que aportas?

- Creo que a nivel personal ya somos muchos los capaces de aproximarnos a las respuestas correctas a estas preguntas, incluso de proponer medios de medición, pero a nivel de dirección no hay interés por este tipo de medición - quizá por miedo a los resultados -. Sin duda, mientras no midamos estas cosas, seguiremos menospreciando a gente muy capaz y sobrevalorando a otras personas - y la empresa perdiendo terreno en el mercado, claro está.

- Y enlazo la pregunta del principio con esta afirmación que he hecho de que muchos somos capaces de aproximarnos a las respuestas que me he planteado: ¿nos arriesgaríamos a que nuestro salario - o la parte de él que está por encima del salario mínimo - esté directamente vinculada al valor que aportamos a la empresa?... y pienso en una mini-sonrisa en la comisura de vuestros labios.

Empresa + Personas que aportan valor

2012-07-06T10:01:00.002+02:00

Iba a responder a una entrada del blog de Consultec, pero viendo que la respuesta se alargaba, he decidido publicarla en mi blog - después de un rato largo de silencio -.

A propósito de la gestión de la edad en nuestras organizaciones, ¿no creéis que en estos tiempos de la tan nombrada crisis las empresas están buscando personas que aporten valor y experiencia en vez de personas a las que se les pague poco dinero y no aporten mucho? (ejemplo de comparación: ver este estudio).

Creo que no sólo se debe actualizar [constantemente] los conocimientos y habilidades de las personas que trabajan con nosotros, sino asegurarnos de estar rodeados de personas que aporten valor y que vean la empresa como suya. Es a esas personas en las que hay que enfocar la formación, de hecho, ellas mismas lo van a pedir. De acuerdo en que hay que formar a todos, pero el foco debe ser ese grupo de personas que empujan la empresa, porque ellas formarán al resto.

También creo que la promoción sólo debe usarse si en ese nuevo puesto la persona va a aportar más valor que en el que está. Hay personas muy buenas en un puesto de producción que a pesar de controlar su trabajo de forma excelente no serán buenas en un puesto que gestione esas tareas. Otras, en cambio, son mejores gestionando que produciendo, porque conocen más el negocio y son más eficientes organizando que produciendo.

Detectar en qué son buenas las personas - esa es la clave para formar y promocionar.

He visto personas de todas las edades, acabadas de salir de la universidad o con muchos años de experiencia en sus espaldas, que no sienten como suyo el trabajo que están haciendo, que sólo trabajan por el salario, que no aportan más de lo que se les pide - y muchas veces aportan menos que eso - y también he visto personas que aportan, proponen, empujan y motivan. Esas son las personas que necesitamos.

Muchas empresas se han dado cuenta de que formar y promocionar no aporta valor cuando la persona a la que va dirigido ese plan de crecimiento profesional no tiene interés en crecer; otras empresas siguen dedicando recursos a ello años y años, confiando en que esas personas aprovecharán lo que se les dedica, pero consiguen muy poco después de mucha inversión.

Una empresa está abocada al fracaso tanto en productividad como en la creación de nuevas líneas de negocio si no sabe detectar qué personas le aportan valor y quieren - y pueden - crecer, y cuáles son un lastre para ellas.

Vamos a poner esto en positivo: una empresa podrá crecer y crear nuevas líneas de negocio si sabe detectar qué personas quieren aportar valor y quieren crecer, porque el pilar principal de las empresas son las personas; la empresa ES las personas que la forman; el espíritu de la empresa ES el espíritu de sus personas.

¿Qué pasa con el resto de las personas? - esta es la parte más polémica y sobre la que siempre termino discutiendo: cada persona encontrará su hueco en el mercado laboral de acuerdo a sus capacidades. Una empresa no tiene por qué mantener a personas en un puesto en el que no aporten valor - ni por la antigüedad ni por enchufe - porque su producción no trae beneficios, sino pérdidas.

Nuestro trabajo - crear programas informáticos - tiene casi siempre un objetivo: reducir la cantidad de personas que una empresa necesita para realizar determinados procesos. ¿Qué pasa con las personas que ya no aportan valor en un proceso? ¿Debe la empresa seguir formándolas?

Ejemplo: una empresa tiene en alta estima a una persona que aporta mucho valor en su puesto de trabajo. La implantación de una solución de automatización consigue realizar el 75% del trabajo de esa persona y esa persona no quiere que le cambien sus tareas, y las nuevas tareas que se le asignan, después de muchas jornadas de formación, las hace con desgana y desmotivada. ¿Se le promociona porque conoce el negocio? ¿Se crea un puesto ex-profeso para ella? - CCC

Antes yo pensaba que no era justo que mucha gente perdiera el trabajo por la implantación de nuestras soluciones; ahora veo que es una oportunidad de crecer para la empresa y para las personas, siempre que ambas partes sepan aprovechar bien los recursos.

Otro ejemplo: una empresa tiene en alta estima a una persona que aporta mucho valor en su puesto de trabajo. La implantación de una solución de automatización consigue realizar el 75% del trabajo de esa persona, pero por su conocimiento del negocio y su motivación para realizar nuevas tareas se le propone que participe en la creación de una nueva línea de negocio. Esa persona aporta ideas, se le forma para el nuevo trabajo, se pone en marcha la nueva línea de negocio y al cabo de unos años se le promociona.

Son tiempos difíciles, pero creo que esta experiencia nos servirá para que las personas se encuentren, para que las personas encuentren en qué son buenas y se dediquen a ello, y para que las empresas aprovechen la formación y la promoción para sacar lo mejor de las personas y a la vez sepan cuidar a aquellas personas que den lo mejor de sí para la empresa.

¿Estáis de acuerdo?

Convivencia laboral - Respetando el marco de trabajo

2011-08-23T09:45:00.001+02:00

Todos nos hemos sentido incómodos alguna vez con alguien que ha interferido en nuestro trabajo, diciéndonos cómo tenemos que hacerlo. Quitando aquellas personas que no aceptan consejos y las técnicas que facilitan la comunicación, cuando nos sentimos así es porque han violado nuestro marco de trabajo o de responsabilidad.
Independientemente del lugar que una persona, digamos Stan, ocupe en un equipo de trabajo o el rol que tengamos dentro de la empresa, puede que sepa cómo otra, digamos Kenny, puede hacer mejor su trabajo.
Stan puede ocupar un puesto cualquiera en la estructura organizativa de la empresa, pero no debe decirle a Kenny que haga las cosas de esta o aquella manera, ni lanzar propuestas que estén en el marco de trabajo de Kenny sin contar con él, porque estará menospreciando su trabajo. Quizá hace 10 o 20 años esa era la forma de trabajar en muchas empresas, pero actualmente, con la colaboración como uno de los pilares fundamentales para el crecimiento de las empresas, esas actuaciones tienen muy poca cabida, y la misma aceptación que antes, es decir, ninguna.

En cambio es muy posible que Kenny aceptase mejor una orientación que una orden o una intromisión en su trabajo. Más que aceptar probablemente hasta lo agradezca.

Stan puede proponerle a Kenny probar a hacer las cosas de “esta” otra forma porque él ha visto que produce mejores resultados, puede proponerle probar juntos una nueva forma de hacer algo, puede enseñarle o demostrarle cosas que ya conoce y que son efectivas; todo esto a solas, en una reunión o en un correo electrónico.
Lo que no debe hacer Stan es, en cualquier entorno, decirle a Kenny que haga las cosas de “este” modo, u organizar tareas que son responsabilidad de Kenny.

La diferencia la marcará el cómo Stan plantee su opinión o idea. Cuidar la forma en que ayudamos a los demás o en que colaboramos en las tareas colectivas permite llevarlas a buen puerto y mantener a la vez una buena convivencia laboral, que redundará en una mejor colaboración en el resto de tareas de la empresa, focalización en las tareas y motivación.

Piensa en la última vez que te ocurrió esto y si eras Stan o eras Kenny y la relación laboral entre ambos. ¿En qué terminó todo?

¿Te suena lo de {tenemos que entrar en este cliente como sea} ? - Parte II

2011-08-22T08:53:00.002+02:00

[ver Parte 1]

En la primera parte de este post comentábamos los problemas que provoca llevar proyectos siguiendo dos directrices que tanto estamos acostumbrados a escuchar:

Vender el proyecto a cualquier precio
Terminar el proyecto a cualquier precio

...¿o deberíamos llamarles anti-directrices? También analizamos los beneficios de realizar un proyecto que no se vea condicionado por estos puntos.

En esta segunda parte daremos algunas pistas sobre cómo eliminar esta forma de pensar.

Cómo eliminar el problema de forma poco traumática

Teniendo en cuenta que esas dos son ideas del pasado, es claro que eliminar estos puntos pasa por formar a todas las personas que intervienen en un proyecto, desde la venta hasta el desarrollo.

La formación por sí sola no propiciará el cambio, pero el participar en un proyecto en el que la mejora en los resultados esté asociada con cambios en determinadas partes de la gestión hará que quienes participen en el proyecto difundan qué se ha hecho para mejorar, y querrán que el siguiente proyecto en el que participen se lleve de igual manera.

La mejora en los resultados no quiere decir que el proyecto tendrá mayores beneficios, sino que tendrá los beneficios acordados desde un inicio, positivos o negativos, las personas que participan en el proyecto y los interesados en él estarán más tranquilos durante la vida del proyecto y el producto final tendrá mejor calidad, traduciéndose en satisfacción del equipo de desarrollo y del cliente.

¿Que en qué hay que formarse? - En habilidades de comunicación, gestión del tiempo y motivación más que nada. También se puede estudiar sobre planificación de proyectos, pero el problema del que hablamos no es de planificación de proyectos, sino de habilidades.

No es recomendable intentar aplicarlo en todos los proyectos a la vez si al menos un integrante del equipo de cada proyecto no ha participado en algún proyecto en el que la comunicación sea fluida, no se oculte información relevante para la planificación del proyecto y no se integre al equipo de desarrollo en la toma de decisiones de planificación o de resolución de problemas. Lo ideal es comenzar con un proyecto y trasladar la experiencia al resto de proyectos.

Analizar los resultados al final de cada ciclo de desarrollo hará que el siguiente ciclo de desarrollo vaya mejor, ya que en caso de retrasos se podrán determinar las causas y cómo resolverlas. Las retrospectivas tienen una utilidad inmensa en la mejora continua.

Una última recomendación, muy importante, es que al firmar un proyecto sobre una planificación estimada, todas las partes tienen que tener muy claro que la planificación puede variar una vez que se realice un análisis en profundidad de cada parte del proyecto. Deberá quedar pactado desde un inicio como será negociada esa variación de la planificación, si sobre presupuesto o sobre funcionalidades.

Cuál es el siguiente paso

Estudiar y aplicar. No hay más.

¿Dudas que esto puede resolver el problema de “tenemos que terminarlo como sea”? Pruébalo y nos cuentas tu experiencia.

¿No quieres probarlo porque estás seguro/a de que no funcionará? Eso es porque conoces otra forma de resolver el problema. Cuéntanosla.

Tampoco esperes que todos los clientes sean tan receptivos como para aceptar que un retraso es por causas que van más allá de tu voluntad o que quien vende los proyectos acepte que se termine fuera del tiempo que él o ella vendieron, a pesar de haberles dado desde el principio una estimación más realista.

El arma más potente para todo esto es la información. Si desde el principio se comunica a las partes interesadas en la empresa sobre la estimación obtenida por de un análisis preliminar y no por un proceso de adivinación, al final del proyecto no se podrá decir que no lo había sido advertido, a pesar de lo que se le haya escrito al cliente en la oferta. Que no queden en el aire esas palabras que tanto has dicho “no lo terminamos en ese tiempo ni de coña”. Envíalas por correo electrónico, comunícalas, publícalas.

Conclusiones

Por más que se oculten los problemas siempre van a salir a relucir, si no el problema mismo, sus consecuencias: retrasos, errores, personas incómodas, prisas, pérdida de rendimiento y de confianza en la empresa.

Por más que se reduzcan las estimaciones en tiempo, el desarrollo tardará lo que tiene que tardar; si tarda mucho menos de lo estimado habrá que analizar las causas al igual que si tarda mucho más de lo estimado, así la siguiente vez se podrá realizar una estimación más acertada.

Comunicar a tiempo permite corregir a tiempo.

Post Data: Todavía me considero programador

Todavía me considero programador a pesar de no haber programado casi nada desde hace un tiempo – y no es un sentimiento que sólo tengo yo, sino que más de un gestor de proyectos me ha expresado lo mismo – porque a pesar de mi tarea ahora es gestionar los proyectos, estuve pegándome con el código durante más de diez años y pasé por todas las etapas de la vida de un programador.

Hoy entiendo que una parte muy importante de una empresa que se dedica a vender software son las personas que programan y que por muy bien (o muy mal) que se gestione un proyecto, sin esas personas no hay qué vender. Y otra parte también muy importante son los clientes, que contratan los proyectos, los usan y difunden lo bien o lo mal que funcionan. Cada día vuelvo a intentar poner en sintonía al equipo de desarrollo y al cliente e intento que manejen la misma información; esa acción es el lubricante para el engranaje de nuestra empresa. No queremos que se pare ¿no?, pues desecha los malos hábitos. Manos a la obra.

Material de lectura recomendado

Motivando a tu equipo, Retrospectivas, Contratos ágiles

¿Te suena lo de {tenemos que entrar en este cliente como sea} ? - Parte I

2011-08-19T01:34:00.003+02:00

[ver Parte 2]

No he ido danzando de empresa en empresa, pero mi colaboración con muchas empresas me ha permitido ver cómo funcionan generalmente las PYME que venden servicios relacionados con el software.

Si se reflexiona acerca de cómo se contrata y se gestiona un proyecto, hay que fijarse si hay dos “objetivos” presentes desde el momento de la contratación hasta el cierre:

Vender el proyecto a cualquier precio
Terminar el proyecto a cualquier precio

Si la empresa tiene estos “objetivos” entre los del proyecto no va por buen camino y su línea de desarrollo de software penderá de un hilo mientras no los destierre de la cabeza de quien vende y quien hace.

El problema

Vender a cualquier precio: En sí mismo no es malo si se asumen las consecuencias de la venta. Cuantas veces no habremos escuchado lo de “Tenemos que entrar en ese cliente a cualquier precio”, vender el proyecto a precio de coste, incluso recortar las horas estimadas de un proyecto y conseguir la venta, pero al comenzar la construcción del proyecto resulta que se presiona al equipo de desarrollo para obtener beneficios por encima de lo vendido, incluso de lo estimado.

Si los precios de venta acordados (PVP) bajan hasta el precio de coste estimado o menos, hay que asumir desde el principio que los beneficios a obtener serán los estimados en el momento de la venta.

No se debe recortar la estimación inicial de un proyecto a menos que se tengan bases bien fundadas. Cualquier recorte indiscriminado o forzado de tiempo o recursos lleva asociado una pérdida potencial de beneficios.

Terminar el proyecto a cualquier precio: El seguimiento correcto del proyecto determinará la variación de las entregas. Si el proyecto tiene entregas definidas desde un inicio, estas variaciones hacen más mella en el proyecto que en aquellos en los que se define la siguiente entrega después entregar la anterior. Forzar que las entregas coincidan con las fechas estimadas nunca repercute a favor del proyecto. Es por eso que son estimadas.

Las entregas forzadas siempre llevarán parches y bugs, por no contar con los errores que pueden acarrear consecuencias graves para el negocio del cliente.

Cada vez que se dice “tenemos --- como sea” se está incurriendo en el auto-engaño y se está forzando al equipo a entregar algo con lo que no se ha comprometido, por lo que puede que no se entregue en la fecha esperada a pesar de hacer horas extras y hay un riesgo muy alto de afectar la calidad del producto final.

Una vez instalado el producto todos los fallos generados podrán ser corregidos por el equipo de desarrollo, pero aun así el cliente sentirá que no se ha realizado un desarrollo serio, que le han tomado el pelo o que le han robado su dinero.

¿Qué ganas eliminando el problema?

Estas dos formas de pensar sobre un proyecto están tan arraigados en tantas Pymes que es fácil encontrar quien piense así en cualquiera de los roles de la empresa: desde la gerencia hasta quien programa.

Eliminar esta forma de trabajar del ciclo de vida de un proyecto trae mejoras para muchos procesos en toda la empresa:

Los proyectos comienzan con una idea clara de los beneficios que se van a obtener
El equipo se siente más comprometido con las entregas.
Todos conocen (cliente y proveedor) qué se va a entregar y en qué fechas.
Se entrega un producto con calidad.
El cliente está más satisfecho con el producto.

Cada uno de estos puntos tiene más ventajas asociadas que no he puesto para no aburrir, pero que hacen obvia la necesidad de llegar a esa forma de trabajo. Os aseguro que una vez experimentada no hay vuelta atrás.

En la siguiente parte del post comento algunas pistas para eliminar "el problema", porque seguro que tú has escuchado lo de "hay que terminarlo como sea"... esa gran metodología que deriva en las 3Cs.

[ver Parte 2]

He leído “Matemáticas de la creatividad”

2011-05-16T18:26:00.004+02:00

Brevemente puedo deciros que este libro-estudio, que recomiendo leer, nos demuestra lo importante que es no perder la ilusión por esas ideas que nos vienen a la cabeza y que pueden parecer absurdas, pero ya sabemos de dónde salen las mejores creaciones: de ideas locas.

Extraído del libro, unas líneas:

¿Cómo funciona la creatividad en el cerebro? ¿Cuál es la diferencia matemática entre las ideas que repercuten –o que se nos quedan- y aquellas que se desvanecen o que ni siquiera se notan desde un principio?

Varios estudios sugieren que recibimos miles de mensajes comerciales cada día. Otros sugieren que sólo una mínima fracción de esos mensajes se nos quedan. ¿Cuáles son éstas?

Lo primero que notamos es que las ideas mediocres se olvidan rápidamente. La típica persona promedio P, que se coloca en la marca del 50% tiene sólo el 25% de probabilidades de seguir entre las niñas de tus ojos el segundo día (0,5 x 0,5 = 0,25) un una entre 8 el tercer día. Una semana después de que P entrara a nuestras vidas sólo existe un 0,4% de que pensemos en ella, es un trágico uno entre 250.

Pero lo que es menos obvio inmediatamente es que esas ideas que inicialmente parecen altamente memorables también sufren degradaciones en el tiempo y son olvidadas. De modo que una idea fresca con un 90% de memorabilidad sigue teniendo relevancia un segundo día (81%) pero se convierte en aburrida al final de una semana (41%).

Pasado el tiempo suficiente, hasta las buenas ideas puede comenzar a desvanecerse en nuestra memoria. La persona P(90%) cae al 21% después de dos semanas, a un 10% después de tres y a un 4% al final del mes.

De modo que encontramos que muy pocas ideas son suficientemente robustas para mantenerse en nuestros cerebros poco cuidadosos e irregulares. Una idea de 99% se mantiene conectada durante un mes (74%), mientras que la idea “una entre mil”, que es la del 99,9% es la que incluso después de un mes sigue virtualmente inamovible en el 97%. Pero como dijo un economista, al cabo del tiempo todos estamos muertos. De modo que, usando este modelo matemático, todas las ideas que sean menores que el 100% caerán en la mediocridad con el tiempo suficiente.”

Ahora no os voy a contar cómo propone el autor mejorar nuestro ratio de creatividad, ni cómo fomentarlo en la empresa. Sí que os comentaré que me ha ayudado a no perder esa chispa de decir… “¿por qué no hacemos esto?” o “creo que esto sería genial” y después de reírnos un poco quedarte pensando en… “oye, quizá no es una mala idea”. --- Alguna ya las hemos puesto en marcha.

Aquí tenéis los tres primeros capítulos: http://patternrecognition.typepad.com/pattern_recognition_/2009/10/the-mathematics-of-creativity-the-book.html

Y aquí todo el libro: http://www.mtnmath.com/book/node19.html

Ya me contaréis.

Comunicación eficaz - Lo sencillo hecho difícil… o viceversa

2011-02-17T23:53:00.004+01:00

Yo iba en el tren y cerca de mí, una madre y una niña de 5 años conversan; no pude evitar oír cuando la niña (digamos Lucía) pregunta a su madre (digamos Mar) "¿Qué es espiritual?" y luego una pausa de silencio. Miré hacia ellas y vi a la madre con cara de “¡A ver cómo salgo de esta!”.

No es que Mar no supiera qué es espiritual, sino que no sabía cómo explicarlo con palabras sencillas, en un concepto simple que no implicara años de experiencia para entenderlo.

Y me quedé dándole vueltas, imaginando la cara de los clientes cuando les hablo de WCF, de Servicios Web o de SCRUM. En el mundo de la tecnología, donde todo se expresa con siglas, muchas veces hablamos con los demás sin pensar en que para comunicar no sólo hacer falta que haya otra persona escuchándonos, sino que también nos entienda.

A pesar de toda la experiencia que me falta para comunicar bien, sé que:

mientras crecemos ampliamos el lenguaje y, con ello, complicamos las explicaciones
muchas veces no logramos comunicar porque nos concentramos más en presumir del amplio vocabulario que tenemos sobre un tema que en hacernos entender
otras simplemente no logramos que nos entiendan porque ni nosotros mismos tenemos claro qué es lo que tenemos que explicar o qué significa algo y para explicarlo damos más vueltas que un tiovivo
y algunas otras porque ya tenemos tan arraigada una estructura de comunicación que más que facilitar, obstaculiza la transmisión de la idea

Pongo dos ejemplos que necesitan una explicación simple:

Un técnico explica a un cliente que va a utilizar WCF para transmitir la información entre las oficinas
Y el de antes: cómo le explica Mar a Lucía qué es “espiritual”

No hay más que escribir en un buscador las palabras “forma sencilla explicar” para ver cuántas personas están pidiendo auxilio… o dándolo.

Personas que trabajan conmigo me han dado algunos de estos consejos que os pongo debajo; otros los he leído en libros y o en blogs de comunicación. Si os sirven de ayuda, quizá puedan explicarle a Lucía y al cliente esas palabras raras que no consiguen entender.

Para transmitir eficazmente una idea puedes:

Apoyarse en imágenes o diagramas es muy útil, recuerda que una imagen vale más que mil palabras
Usar palabras sencillas o situaciones de la vida cotidiana que reflejen lo que se quiere expresar facilita la asociación de ideas
Si la explicación que has dado no es comprendida, no lo dejes así, busca una forma alternativa de explicarlo
Si hay alguien que lo sepa explicar mejor que tú, haz que lo explique por ti. Esto es especialmente útil cuando los interlocutores son de diferentes culturas, aunque hablen el mismo idioma
Si no estás seguro de que te han entendido y es imprescindible que lo hayan hecho, pide que te lo expliquen
Si la explicación es larga haz pequeñas pausas entre ideas para que tu interlocutor pueda digerir lo que le has dicho y sea capaz de asimilar el resto, cuidando que no sean aprovechadas para interrumpirte
- Por ejemplo: “¿Recuerdas el programa de TeleVisión que daban todas las noches después de las noticias hace unos 3 años? [pausa] Había un personaje que hacía poca gracia pero estaba en todas las escenas graciosas [pausa] ¡Eso es lo que estamos buscando!”

Ahora, ¿podríamos imaginarnos cómo explicar de forma sencilla en las dos situaciones que he comentado antes?

Decisiones Irracionales – así de predecibles somos

2011-01-04T16:21:00.004+01:00

Acabo de ver una charla de Dan Ariely sobre las decisiones irracionales que tomamos día a día.

Me ha asombrado lo predecibles que somos tomando decisiones y también saber que, en realidad, la gran mayoría de las veces no tenemos el control de lo que decidimos sino que tomamos las decisiones que otros quieren.

Si ya hemos tomado una decisión y nos presentan una opción que no hemos probado, la probamos antes de hacer lo que habíamos decidido, pero si nos presentan dos, ya no las probamos… creo que con algún cliente me ha pasado esto… ahora sé por qué escogió el diseño más feo.

Mira la charla: http://bit.ly/esBJCL

¿Que no te puede pasar? ¿Seguro?

Aquí tienes una demostración de que no elegimos entre las escaleras o las escaleras mecánicas porque estamos seguros de que es la decisión que queremos… http://bit.ly/g1yotf.

No sé si hay alguna forma de escapar de esta irracionalidad porque, incluso siendo conscientes de ella, es difícil tomar la decisión correcta cuando somos manipulados.

La regla de las 24 horas en la comunicación

2010-12-10T13:38:00.003+01:00

¿Cuántas veces nos ha pasado el no contenernos ante un comentario que nos ofende o simplemente con el que no estamos de acuerdo?

Lo peor de todo es que la mayoría de esas veces en que respondemos de forma impulsiva, erramos, metemos la pata hasta el fondo, porque no nos hemos dado el tiempo necesario para analizar lo que nos han dicho, cómo nos lo han dicho, si es cierto o no y, lo más importante, la forma en que vamos a responder.

Muchas de las veces nos dicen las cosas de forma constructiva, pero respondemos contraatacando y más tarde terminamos disculpándonos, después de haber hecho el daño, de haber herido, de haber dañado una relación de amistad, cuando no familiar.

Hay una regla que nos ayuda a evitar estas situaciones: la regla de las 24 horas. Esta regla nos recomienda esperar un margen de tiempo antes de responder a algo que no nos ha gustado o que nos ha ofendido. En estos tiempos en que la comunicación va por canales rápidos y que estamos acostumbrados a intercambiar rápidamente conversaciones orales o escritas, casi no analizamos lo que nos dicen y cómo respondemos. Así tendremos el margen que debe tener toda comunicación efectiva.

Esta regla de comunicación puede aplicarse en cualquier medio que nos permita comunicarnos con un margen para responder pasado un tiempo: conversación oral cara a cara, conversación telefónica con alguien a quien podemos llamar más tarde, escrita por correo electrónico, en un blog.

Aprovecharla nos hará mejorar nuestras relaciones profesionales y personales con los demás.

Aquí os dejo un ejemplo: http://bit.ly/eY9m3v

Cómo NO gestionar las críticas del cliente

2010-11-09T16:05:00.006+01:00

Un par de colegas suelen poner entre los comentarios de su blog común opiniones sobre los restaurantes a los que van, y aunque algunos se llevan los mejores trofeos, otros no tienen esa suerte.

Pues resulta que desde uno de los desafortunados restaurantes les han llamado por teléfono para que retiraran el comentario que han publicado hace unos meses sobre su restaurante, porque aparece entre los primeros resultados de los buscadores cuando se pone el nombre del restaurante.

Y ahí está el error: intentar esconder las críticas en vez de aprovecharlas para mejorar.

Qué se ha hecho BIEN:

- Controlar la información que hay en Internet sobre su negocio: Controlando el nivel de visibilidad del negocio en la red y el nivel de satisfacción, se pueden tomar decisiones en torno a ello: ponerse en contacto con los usuarios, pasar encuestas de satisfacción o aumentar la visibilidad de la marca.

- Contactar con los clientes a los que hemos dado servicio: Es correcto contactar con los clientes si durante el servicio prestado se le ha solicitado autorización para ello o si el cliente tiene publicada información de contacto. Los clientes de un servicio es el medio principal para conocer la calidad del mismo y los medios de mejorarlo.

Qué se ha hecho MAL:

- Contactar por teléfono sin autorización: Después de una exhaustiva búsqueda de cómo contactar con las personas que han puesto la crítica negativa sobre el servicio, el teléfono no es el mejor medio para realizar las primeras tomas de contacto. Los primeros contactos deberían realizarse por correo electrónico, para intentar invadir lo menos posible la privacidad de los clientes.

- Solicitar la eliminación de comentarios u opiniones: Esta acción cumple con las famosas 3C de la ley internacional de A.d.D.: CAGADA, CAGADA, CAGADA. Aprovechar la toma de contacto con el cliente para reprocharle la opinión que ha dado sobre el servicio que se la prestado no hará más que aumentar la opinión negativa sobre el negocio, y que se replique la negatividad entre los contactos del cliente, en cascada, en dos o tres niveles de los contactos. Por el contrario, habría que aprovechar una crítica tan detallada para mejorar exactamente en los puntos donde hemos fallado, detectar qué ha hecho que se produzcan los fallos y corregirlo, y ya de paso invitar al cliente a que regrese a nuestro negocio, ofreciéndole un descuento, para que compruebe la mejora del servicio. Eso:

lo fidelizaría
haría que se escribiera otra crítica, esta vez positiva, sobre el servicio

Pero el mal ya está hecho. Ahora costaría mucho más subsanarlo por la propagación de la noticia.

Espero que muchos de los que trabajamos con clientes aprendamos de ello para no caer en los mismos errores. Os deseo las menos 3Cs posibles.

Esta es la crítica a la que hago mención: http://bit.ly/dgiZFL

Un equipo motivado

2010-10-20T11:13:00.005+02:00

La motivación es todo un mundo.

Comencé a responder un post de Rodrigo Corral sobre motivación, pero la respuesta se convirtió en otro post…. así que decidí ponerla aquí.

El "no desmotivar", como propone Rodrigo, implica también tener un equipo (que no grupo) de personas con capacidad de auto-motivación, pero cuando hay que hacer tareas aburridas o que la gente no ve como un reto, el ser capaces de motivar a nuestro equipo juega un papel fundamental. No todas las personas tienen la capacidad de auto-motivarse, y no siempre conseguiremos “no desmotivar” si tenemos que responder por los intereses de nuestra empresa. Lo que sí podremos hacer es detectar aquello que desmotive y compensarlo con puntos que sí lo hagan.

Desde dar a conocer los objetivos globales, hasta dar incentivos sorpresa -no monetarios-, salir con el equipo, hacer deporte juntos, la palmada en el hombro, decir "buen trabajo", "eres un@ crack", tener una frase propia en el equipo, una comida o cena todos juntos -de ser posible pagada por la empresa-, un mini-reto paralelo a la tarea aburrida o alternar tareas aburridas con aquellas que aportan beneficios intelectuales, son técnicas que funcionan.

Hay que estar siempre alertas para detectar si durante un tiempo (1 mes, por ejemplo) no se presentan situaciones que motiven, que rompan el ritmo monótono de trabajo. En ese momento hay que plantearse pensar en algo que haga que el equipo despierte. A veces no pasa en todo el equipo, sino sólo con una persona. A no todos se nos motiva igual, y ahí entra en juego la pirámide de Maslow que muchas veces se olvida.

Experiencia corroborable por uno de los lectores de este blog: Tuve que asignarle impartir un día de formación y casi entra en estado de shock. "Que me voy de la empresa" me decía... y tuve que aplicar todas las técnicas conocidas de motivación para que impartiera la formación. Reforzar su auto-estima, decirle que confiaba en él plenamente para esa tarea... en fin... que dió la formación y ahora mismo es capaz de asumir muchos más retos que antes.

Otra experiencia: un responsable de proyecto (no diré de qué empresa, por supuesto) se quejaba de que los trabajos que entregaba a los clientes solían tener errores. Había decidido entonces revisar todo antes de entregar y si habían errores, corregirlos él mismo, porque si los mandaba de vuelta a corregir, le volvían a entregar el trabajo con errores. Le comenté que tenía que motivar a la gente para que cerrase mejor los proyectos y darles las herramientas que necesitaban para ello. Y su respuesta fue: "Si la gente no está motivada ¿qué quieres que le haga?". El trabajo de un responsable de personas es Motivar, Dar las herramientas, Resolver todos aquello que se interponga en el trabajo de las personas. El trabajo de un responsable de personas no es revisar y corregir los trabajos que entregan, sino asegurarse que tienen todo lo necesario para que lo entreguen bien y hacer que conozcan las metas a alcanzar. Si no eres capaz de hacerlo, estamos perdiendo dinero contigo.

Aunque creamos que motivamos bien a las personas, nunca está de más volver a leer un libro, posts interesantes como el de Rodrigo, o volver a recibir un curso en el nos enseñen prácticas para motivar.
Un equipo motivado contamina positivamente al resto de personas de la empresa. Aprovechémoslo.
Aquí, otro post con algunas pistas para motivar: http://bit.ly/aelaIP

Espero que os sirva.

¿Cuál es la frase que define a tu empresa?

2010-09-22T10:03:00.007+02:00

Meses después de leer un artículo en la Hardvard Business Review, me vino a la mente por otros motivos la misma pregunta: ¿cuál es la frase que define a tu empresa?

La frase de visión define el objetivo principal de una empresa, define por qué está creada y define el marco de trabajo de cualquier proyecto a emprender en la empresa.

Cuando una empresa emprende un proyecto debe tener claro si el proyecto ayuda a conseguir el objetivo principal de la empresa. Si lo hace, adelante con él. Si no, deséchalo, porque será un lastre para conseguir ese objetivo.

Es por ese motivo, el de evitar lastres, evitar distracciones, tener la certeza de que cada cosa que estamos haciendo es por EL OBJETIVO, es por eso que la frase debe ser tan corta que toda persona que trabaje en la empresa la memorice, debe estar tan visible que la encontremos rápidamente, y debe ser repetida una y otra vez para que nadie olvide la línea de trabajo.

Aquellas empresas que no tienen una frase contundente y clara, no tienen claro qué objetivo perseguir con cada proyecto. Están condenadas a quedarse en a mitad de camino entre el fracaso y el éxito. Y de la mitad al suelo es más fácil llegar que de la mitad al cielo.

Del artículo antes mencionado extraigo: la frase de ING-USA: “Orientamos a los estadounidenses para que vuelvan a ahorrar”, la de Google “Organizamos la información mundial y la hacemos accesible y útil a nivel universal”. Hasta los presidentes tienen frases que definen el objetivo que persiguen: “Preservar la unión de USA y liberar a los esclavos” (Lincoln). Cada una de estas empresas o personas tiene (o tenía) claro a dónde quería llegar y ponía todos sus recursos para alcanzarlo.

Ahora, pregúntate: ¿Sabes qué frase define a tu empresa?. Si no, corre y búscala, y si no tiene… corre y punto.

Ser pagado por lo que vales… (to get paid what you're worht…)

2010-09-16T10:46:00.002+02:00

Para ser pagado por lo que vales tienes que saber cuáles son tus conocimientos disruptivos: Averígualo aquí: http://bit.ly/cpnvGH

Este artículo de la Hardvard Business Review comenta que para optar por un puesto de trabajo no sólo es necesario dominar una metodología, modelo o técnica, sino tener habilidades relacionadas con el puesto que permitan obtener toda la información necesaria para poner en el modelo.

El ejemplo que pone el autor es: (...esa persona) conoce sus habilidades para conectar los puntos entre personas e ideas en aquellos casos en que otros no ven esa conexión, pero nunca había pensado que esa habilidad le permitiría optar por mejor salario o categoría profesional, sino que su conocimiento de modelos financieros le bastaba. Resulta que las habilidades son lo más importante y el conocimiento para ponerlas en el modelo es lo que va a permitir plasmarlas.

También comenta: mucha gente sobrevalora de sí misma lo que NO es, e infravalora aquello que SÍ es.

Ahí os lo dejo.

Pensamiento crítico en los líderes

2010-08-03T09:15:00.004+02:00

El pensamiento crítico siempre ha sido una característica bastante arraigada en aquellas personas que lideran personas, valga la redundancia, pero últimamente hemos visto cómo esa característica ha perdido fuerza al lado de “cantidad de trabajo que puede asumir”.

Por consecuencia, la calidad de los productos o procesos se ha visto mermada.

Para recuperar esa calidad, debemos acostumbrarnos a pensar críticamente. ¿Cómo?:

- Preguntar: Los pensadores críticos son inquisitivos ante cada proposición. Buscan el qué y el por qué. La crisis de estos últimos años ha hecho florecer un poco el pensamiento crítico, al tener la necesidad de obtener ganancias con presupuestos reducidos.

- Adoptar diferentes puntos de vista: La globalización permite aprovechar los puntos de vista de diferentes culturas. Así, por ejemplo, la idea de formación online para una persona de China varía a la idea que se tiene en el mundo occidental. Y la idea que se tiene en los países del norte de Europa varía (por políticas de gobierno) respecto a la que se tiene en los países del sur de Europa. Hoy día es más fácil conocer los puntos de vista de diferentes culturas, géneros y edades y ampliar el mercado de los productos, conocimientos o procesos.

- Ver el potencial: Quien piensa críticamente tiene la capacidad de ver oportunidades donde otros ven obstáculos. Por ejemplo, una persona del departamento de dirección puede ver una piedra en el camino donde un pensador avispado ve una oportunidad de mejorar el proceso de producción para sacar un nuevo producto.

- Gestionar la ambigüedad: En el mundo actual los cambios están a la orden del día. Un pensador crítico también debe ser capaz no sólo de gestionarlos, sino de preparar los procesos o productos para responder ante los cambios que puedan surgir.

Para cualquier negocio es crítico que se busque el pensamiento pensadores crítico al contratar personas, o se potencie este tipo de pensamiento entre quienes realizan labores de liderazgo, que secan capaces de medir correctamente cualquier situación, se den cuenta del potencial donde otros sólo ven problemas y que aprovechen las oportunidades al realizar la toma de decisiones.

18 Lecciones de Liderazgo

2010-07-05T14:39:00.002+02:00

… de Collin Powell

Ser responsable a veces significa fastidiar a la gente.
El día en que los soldados dejen de contarte sus problemas será el día en que hayas dejado de liderarlos. Han perdido la confianza en que puedes ayudarles o han llegado a la conclusión de que no te interesa. En ambos casos es fallo de liderazgo.
No te dejes cegar por expertos y los de la élite. Unos tienen más datos que juicio y los otros se vuelven tan endogámicos que cuando chocan con el mundo real se desmoronan.
No temas enfrentarte a los profesionales incluso en su propio terreno.
Nunca menosprecies los detalles. Cuando todo el mundo esté distraído o tenga la mente embotada, el líder debe estar el doble de vigilante.
No se sabe qué se puede sacar de algo hasta que no se intenta.
Mira más allá de las apariencias. No te amilanes sólo porque podría no gustarte lo que puedas encontrar.
La organización no acomete nada. Los planes tampoco acometen nada. Lo que hace que tenga o no éxito la empresa acometida son las personas involucradas en la empresa. Sólo atrayendo a los mejores se podrán realizar grandes hazañas.
No mucho de los gráficos y títulos que destacan por su elegancia.
Nunca dejes que tu ego se mezcle tanto con tu cargo que cuando el cargo desaparezca, el ego se vaya con él.
No te ciñas a los estereotipos. No persigas la última moda en la gestión. Es la situación la que dicta la mejor manera en que el equipo debe abordar la misión.
El optimismo perpetuo es un multiplicador de fuerza.
Las reglas de Powell para escoger personas: Mirar la inteligencia y el juicio y más que nada la capacidad de anticiparte, de ver detrás de las esquinas. También mirar lealtad, integridad, energía, ego balanceado y que intente terminar lo que ha empezado.
Los grandes líderes son grandes simplificadores y pueden acortar las discusiones, debates y dudas, ofreciendo una solución que todos puedan entender.
Parte I: "Usa la fórmula P= de 40 a 70 donde P es la probabilidad de suceso y los números el porcentaje de información adquirida.” Parte II: "Una vez que la información esté en el rango de 40 a 70, hazle caso a tu intuición”
En el campo, el comandante siempre tiene la razón, no así la retaguardia, a menos que se pruebe lo contrario.
Diviértete en tu misión. No corras todo el tiempo de forma vertiginosa. Descansa cuando te lo hayas ganado: pasa tiempo con tu familia. LQQD: rodéate de gente que se toma en serio su trabajo, pero no a sí mismos, aquellos que trabajan duro y juegan duro.
Mandar es una tarea solitaria.

Indudablemente, y a pesar de la opinión de cada uno sobre su carrera política, aquí vemos que los grandes líderes tienen siempre en mente grandes ideas acerca de cómo mantener unidas a las personas, cómo hacerles seguir a los líderes y cómo hacer equipos eficientes.

¿Qué puedo leer más allá de estas líneas?:

- No hay que tener miedo de hacer lo que hay que hacer, aunque haya que poner en tela de juicio lo que dicen los profesionales.
- Hay que preocuparse por mantener la confianza del equipo en el líder y en el propio equipo.
- Las decisiones no deben ser tomadas sólo basándose en datos o emociones, sino también con juicio. hay que fijarse bien en los detalles de toda la información que tenemos, aunque no parezcan relevantes. Hay que mirar más allá de lo que parecen las cosas.
- No hay que predecir los resultados de una tarea si no se conoce el camino para hacerla. Primero hay que probar el camino.
- La gente es la clave
- Cada situación requiere una solución específica. Los estereotipos y las modas casi nunca nos valen al 100%
- Líder motivado = Equipo motivado
- Los grandes líderes son grandes simplificadores
- Pásalo bien en tu trabajo y si comienzas algo, termínalo.
- Auto-motívate.