jueves, 6 de febrero de 2014

Productividad - Compartiendo experiencias

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!

Read More »

martes, 20 de agosto de 2013

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

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:
  1. Calidad: la máxima posible, intentando no afectar las fechas planificadas
  2. Fechas: lo más cercano a las planificadas, intentando no afectar los requisitos
  3. 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.


image
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, que 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.

Read More »

jueves, 27 de junio de 2013

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

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.

Read More »

viernes, 1 de febrero de 2013

Haz destacar tu oferta por encima de otras

Después de haber visto y hecho muchas ofertas de proyecto y algunas propuestas de producto, y aún así sorprenderme cada día por el comportamiento de los clientes (las personas siempre nos sorprenden), hay unas pautas que se repiten a la hora de que nuestra oferta se valore y/o se escoja por encima de otras.

Para quitarnos del medio el tema del presupuesto, que es recurrente, diré que si entre las ofertas presentadas hay una con un presupuesto considerablemente bajo, a decir más de un 30% menor que las demás, tiene una probabilidad MUY alta de ser escogida a pesar de que la oferta realizada carezca de suficiente nivel técnico o detalle de funcionalidades. Es así debido al desconocimiento técnico de muchos clientes y/o a su certeza de que conseguirán imponer que el producto final tenga TODAS las funcionalidades que han soñado. C’est la vie.

Si se ofrece un presupuesto muy bajo es por decisión corporativa y habrá que asumir las pérdidas que acarree el proyecto (ver “Tenemos que entrar en ese cliente como sea I y II”).

Apartándonos del tema monetario y pasando por alto el de los enchufes, voy directamente al comportamiento ya más impredecible de selección de la oferta y que es donde hay que comenzar a pelear; es en esta parte donde podemos sorprendernos con ofertas estilo “te ofrecemos todo lo que necesites en el tiempo que pides” o “te incorporamos nuestro framework super-especial que resolverá todas las ampliaciones futuras” y que aún así no sobreviven al proceso de selección.

Antes de comentar lo que he visto que sí influye, voy decir – IMHO – lo que NO va a influir en su decisión (o lo que menos influye):
  • Llenar las ofertas de palabrejos técnicos
  • Poner una lista interminable de funcionalidades cortadas y pegadas de su solicitud y – lo peor – explicar cada una de ellas como si fuésemos expertos en el negocio del cliente
  • Ofrecerles nuestro framework super-especial
  • Asegurarles que todo lo que nos piden lo vamos a hacer en el tiempo que nos piden – no se lo van a creer, este río lo han cruzado muchas veces
  • Decirles que utilizamos una metodología de desarrollo propia de la empresa que une lo mejor de “nombre de una metodología famosa” y lo mejor de nuestra experiencia, a la que se le ha llamado “frasecita guay”. Y lo peor, detallarle sólo cómo funciona la “metodología famosa”.
Si yo, como cliente, recibo una oferta así – de las que hay muchas – bueno, en fin… O no la escogería, o exigiría… mejor callo que los que ofertamos proyectos muchas veces somos los peores clientes.

Esto en realidad es la palabrería que nos saltamos cuando leemos las ofertas; es lo que hay en la mayoría de las ofertas; nosotros sabemos y el cliente sabe que estamos mintiendo como perracos y que lo que queremos es ese contrato.

Entonces, qué lo que le interesa a los clientes?


Read More »

martes, 10 de julio de 2012

El mundo es un pañuelo - Trends

Revisando Google Insights for Search se puede inferir un poco la tendencia de qué es lo que más le interesa a las personas en cuanto a compras, a noticias y a qué es lo que más buscan cuando se plantan delante de Google.

Me asombra que ya pocos escriben en la barra de direcciones la URL del sitio que buscan (a veces yo también lo hago). La gran mayoría de las personas escribe el nombre del sitio en Google confiando en que éste lo encuentre. Esto, para los hackers, es como poner un caramelo en un banco en un parque infantil y esperar a que algún niño lo coja.

Read More »

lunes, 9 de julio de 2012

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

- ... ¿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.



Read More »

viernes, 6 de julio de 2012

Empresa + Personas que aportan valor

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.



Read More »

martes, 23 de agosto de 2011

Convivencia laboral - Respetando el marco de trabajo

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?
Read More »

lunes, 22 de agosto de 2011

¿Te suena lo de "tenemos que entrar en este cliente como sea"? - PARTE 2


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.


Read More »

viernes, 19 de agosto de 2011

¿Te suena lo de "tenemos que entrar en este cliente como sea"? - PARTE 1

[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 el 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.

Read More »