Impacto en el bienestar de la jornada laboral de cuatro días

¿Cuál es el impacto en el bienestar de la jornada laboral de cuatro días?

¿Cuál es el impacto en el bienestar de la jornada laboral de cuatro días?

En artículos anteriores

🔗 La consultora americana Gallup acaba de publicar este estudio sobre el impacto en el bienestar de la jornada laboral de cuatro días..   

🔗En artículos anteriores de novanotio ya hicimos una profunda reflexión sobre la mejor semana laboral para el ámbito de la tecnología.

 

La jornada mas adecuada es de treinta horas repartidas en cinco días, con dos o tres de ellos en teletrabajo.

A modo de resumen, aplicando dos de las leyes de la gestión de proyectos, "One project, one team, one site" y "Presión x Talento = Constante", llegamos a la conclusión de que la jornada mas adecuada sería un modelo híbrido de treinta horas repartidas en cinco días.

La jornada de cuatro días también parecía ofrecer varias ventajas.

Ambos esquemas deberían funcionar, pero en la práctica los experimentos fracasan al cabo de uno o dos años. ¿Por qué?

Posibles causas del fracaso de las jornadas reducidas

En nuestro artículo analizábamos también los posibles motivos de esos fracasos; dificultad para responder a una situación de crisis, retrasos en los proyectos (siempre los hay por la primera ley), limitaciones para hacer reuniones y coordinar equipos...

Gallup nos ofrece nuevas respuestas

El bienestar de los trabajadores depende sobre todo de la calidad del management.

Hoy Gallup nos ofrece una explicación basada en una macroencuesta a mas de 12.000 empleados en todo el mundo.

La productividad, el compromiso y el bienestar de los trabajadores dependen cobre todo de la calidad del management y, en menor medida, de la adopción del trabajo remoto o soluciones híbridas.

El impacto de la jornada laboral en la productividad, el compromiso y el bienestar de los consultores es limitado.

Ninguna sorpresa. Si habéis leído nuestro artículo sobre los parámetros a tener en cuenta antes de cambiar de empleo, ya sabéis que hasta el 70% de tu experiencia laboral (y también vital) dependen de tu jefe directo.

En resumen, para sentirnos mejor no necesitamos trabajar menos horas, ¡necesitamos mejores jefes!

 


El gran riesgo de la IA es que nos convenza de trabajar gratis para un unicornio

Trabajar gratis para un unicornio

Trabajar gratis para un unicornio

Hace ya un par de años llegó a mis manos un libro llamado 'Exponential Organizations'. En él se describen las características que poseen las organizaciones de crecimiento exponencial que llegan a estar valoradas en miles de millones de dólares.

El libro es muy interesante porque refleja la forma de pensar de la nueva élite empresarial tecnológica mundial. La Mentalidad.

Ya en primera lectura -he tenido que leerlo varias veces para asegurarme de que lo había entendido bien- me preocuparon los capítulos relacionados con las  relaciones laborales. Me parecieron peligrosos porque explicaban cómo conseguir que millones de personas estén dispuestas a trabajar gratis para un unicornio.

Y hay una gran diferencia entre automatizar procesos para mejorar la competitividad y el trabajo no remunerado.

El gran riesgo de la IA no son los empleos que puede destruir, es que sus algoritmos lleguen a convencernos de trabajar gratis para un unicornio.

En todos los países existen marcos normativos, que marcan unos límites en la negociación entre empresarios y trabajadores.

La Mentalidad son en realidad técnicas para escapar de estos marcos normativos, con el objetivo de alterar por completo un mercado, someterlo y capturar enormes cantidades de valor en el proceso. Sus seguidores lo llaman disrupción.

Veamos las técnicas que plantean en el libro.

Staff on demand

El primero capítulo controvertido de este libro es "Staff on Demand".

Explica que no es conveniente tener trabajadores en plantilla, ya que sus conocimientos quedan obsoletos "delante de tus ojos". Además las nuevas tecnologías permiten aprovisionarse de personal ajeno con un coste próximo a cero.

En nuestro sector tecnológico, este aprovisionamiento con coste próximo a cero viene de la mano de las plataformas de freelance tecnológicos de las que ya hablamos en nuestro anterior artículo.

En realidad, como hemos dicho, lo que se persigue es escapar de los marcos normativos y capturar las siguientes eficiencias:

Gestión y protección social

La principal eficiencia se consigue eliminando los costes de protección social, gestión y administración. El consultor es ahora responsable del pago de sus impuestos y costes de seguridad social. Nos mas gastos de gestoría, nóminas, despidos, permisos remunerados por paternidad, por enfermedad...

Staff on demand permite ahorrar esos costes de gestión y protección social y capturarlos para la plataforma.

Costes de formación

Mediante Staff On Demand, las empresas están trasladando los costes de formación a los consultores.

En el entorno tecnológico, cursos y certificaciones pueden ser muy costosos en tiempo y dinero. La formación, que ahora es responsabilidad del consultor, puede hacerse en paralelo con un proyecto, o entre un proyecto y el siguiente. Ambas opciones son malas, la primera por sobrecarga de esfuerzo y la segunda por incrementar los gastos en un periodo sin ingresos.

Es el segundo trasvase de valor de los profesionales a las plataformas.

Incremento de la jornada y disminución de tarifas

La tercera vía de ahorro, que todavía no ha llegado a nuestro mercado tecnológico, pero si aparece ya en otros sectores, es la mejora de la productividad mediante incrementos de jornada y reducción de salarios.

La forma más sencilla de conseguirlo sería trasladar a los consultores freelance el riesgo tecnológico de los proyectos. En teoría los desarrollos nunca terminan, siempre quedan errores por corregir y cambios que realizar. Como resultado, el 80% de los proyectos sufre severos retrasos. Si las plataformas consiguen traspasar ese riesgo tecnológico a los consultores, éstos se verán obligados a invertir muchas mas horas de las inicialmente planificadas.

El riesgo tecnológico de un proyecto llave en mano desarrollado con metodologías en cascada es de un 80%

Otra vía de reducción de salarios complementaria sería hacer participar a los consultores freelance en procesos de compras o RFPs, de forma similar a como las empresas hacen con sus proveedores. La competencia reduciría los ingresos de los consultores de forma notable.

Ambos mecanismos se puede reforzar si, en las plataformas de contratación, las empresas pueden valoran de una a cinco estrellas sus experiencias con esos colaboradores freelance. ¿Quién contrataría a un consultor con menos de cuatro estrellas?

Staff on demand permite saltarse limitaciones como salario mínimo o jornada laboral y capturar ese valor para la plataforma. Si quieres trabajar mañana, tienes que demostrarle al algoritmo cómo de productivo has sido hoy.

Adquisición y mantenimiento de los medios de producción

Hay un mecanismo para capturar un valor adicional que veremos en un párrafo posterior. ¿Para qué adquirir y gestionar los medios de producción si podemos trasladar estos costes a los propios consultores?

Community & Crowd

El siguiente y todavía más controvertido capítulo se titula  "Community & Crowd", algo así como comunidad y multitud.

Community

Este concepto va un paso mas allá en la extracción de valor saltándose el marco normativo. Defiende que, si consigues formar una comunidad de personas apasionadas alrededor de tu producto o servicio, ellos harán el trabajo de forma gratuita, solo por desarrollar su pasión o el reconocimiento de la comunidad.

Una frase explica cómo gestionar una comunidad. "En la cúspide de cada una de estas comunidades hay un dictador benevolente, porque a pesar de que no hay empleados, la gente tiene responsabilidades y se necesita llevar un control de su rendimiento". En resumen, están presentes todas las características de una relación laboral - planificación, responsabilidad, control- excepto el salario.

Un ejemplo de nuestro sector viene de la mano de las plataformas de software libre, donde miles de programadores invierten de forma altruista cientos de horas de su trabajo para beneficio de la comunidad... y en ocasiones de la propia plataforma. Programas tan populares como Linux, WordPress, Mozilla Thunderbird, GIMP o FreeCAD son ejemplos de estas comunidades Open Source.

Cuando la posibilidad de no monetizar tu esfuerzo es del 100% hablamos de certeza matemática.

Crowd

Con respecto a la multitud, el libro los define como grupos mucho mas grandes que las comunidades, pero con vínculos más débiles. En sus propias palabras: "La gestión de los seguidores se hace mediante atracción (pull based). Abres una idea, ofreces [] un premio que incentive... y dejas que la gente te encuentre"

La idea de atrapar a un gran número de profesionales mediante un premio es brillante y peligrosa, porque aparece un importante riesgo estadístico de no monetizar tu esfuerzo.

El ejemplo que da el libro es precisamente de nuestro sector. Explica que Netflix necesitaba un algoritmo de valoración de películas, y en lugar de desarrollarlo internamente, ofreció un premio de 1.000.000 $. Esto atrajo a 51.000 participantes que presentaron 44.014 prototipos. Uno de ellos ganó el premio. 44.013 organizaciones trabajaron sin remuneración durante varios años.

Eso es el riesgo estadístico, una probabilidad entre cuarenta mil de recibir ingresos por tu trabajo. Un riesgo del 99,999%.

El resultado, por supuesto, fue muy superior al que habría logrado su equipo interno de desarrollo, y es una de las bases del espectacular crecimiento de esta plataforma. ¿Quién capturó el valor del esfuerzo de esas miles de empresas?

Estos primeros ejemplos han dado lugar a un buen número de plataformas de crowdsourcing como IdeaConnection, Agorize, o, mi preferida, TopCoder (imprescindible seguir este link y revisar el contenido) donde las empresas pueden publicar sus desafíos para que la comunidad lo resuelva, pagando el premio "solo si el resultado es satisfactorio". En definitiva, sumar al riesgo tecnológico el riesgo estadístico.

Además, para estimular la competitividad, estas plataformas rankean de una a cinco estrellas a sus colaboradores, como anticipábamos en el párrafo de Staff On Demand.

Hay otro ejemplo que se está imponiendo en nuestro sector, la selección tecnológica mediante crowdsourcing. Cuando veinte empresas consultoras están buscando el mismo perfil para el mismo cliente, el riesgo estadístico es del 95%.

Leveraged Assets

Leveraged Assets significa no poseer los medios de trabajo.

Como comentamos en este otro artículo previo, en un entorno cambiante como el actual, tus activos rápidamente se transforman en pasivos.

¿Qué empresa no tiene oficinas vacías?¿Quién no tiene un coche sin etiqueta medioambiental azul?

Alquilar los medios de producción te permite escapar de esas trampas activo->pasivo, aunque hay métodos para extraer todavía mas valor.

Puedes trasladar los costes de adquisición y mantenimiento de los equipos de producción a los propios trabajadores. Los coches de Bla bla car, los inmuebles de Airbnb, algunas de las furgonetas de reparto de Amazon... El ahorro de no adquirir, alquilar o gestionar los medios de producción es enorme.

En nuestro mercado tecnológico estamos hablando de ordenadores, sistemas operativos, antivirus, software de propósito general, teléfonos móviles... Si multiplicáis este ahorro por los miles de consultores de una comunidad, podéis haceros una idea del valor capturado por las plataformas en el proceso.

Resumen

"Staff on demand", "Community & croud", "Leveraged assets", creemos que son en realidad formas de esquivar los marcos normativos vigentes y capturar enormes cantidades de valor para las plataformas. Y la creciente presión de los marcos normativos sobre las empresas (disminución de la jornada laboral, incremento de los costes de protección social) puede acelerar la adopción de estos modelos como fórmula defensiva.

Son además modelos de relación laboral que creemos elegir de forma voluntaria, pero tras los cuales hay un enorme esfuerzo de investigación en psicología, sociología e ingeniería. El gran riesgo de la IA es que sus algoritmos sean capaces de convencernos de trabajar gratis para un unicornio. ¿Por qué si no alguien asumiría riesgos del 90% o incluso del 100%?

En las sesiones de méntoring con nuestros consultores de novanotio, les explicamos estos riesgos y pero también las oportunidades que abren estas nuevas formas de relación laboral. El objetivo es que tengan una sólida base para tomar decisiones y esquivar posibles trampas profesionales. Pero ¿Quién sabe? Quizás algunos de ellos usen este conocimiento para crear sus propios unicornios. ¿Será un ex-novanotio el próximo Elon Musk?

Bibliografía

Hay algunos libros que me parecen fundamentales para entender la transformación que está sufriendo el mercado de RRHH tecnológico.

El primero es el que da origen a este artículo, 'Exponential Organizations', de Salim Ismail y otros autores.

Otro imprescindible es 'Persuasive Technology' de B.J.Fogg. Proporciona la base teórica para el desarrollo de esos algoritmos que consiguen convertirnos en auténticos adictos de las redes sociales.

Por último voy a mencionar 'La supervivencia de los mas ricos', de Douglas Rushkoff. En las antípodas políticas del libro de Ismail y el libro donde se utiliza por primera vez el termino 'La Mentalidad' para describir la forma de pensar de los milmillonarios tecnológicos.

 


Vivimos en sociedades líquidas, donde el cambio acelerado transforma rápidamente activos en pasivos. ¿Cómo afecta esto al empleo tecnológico?

Empleos tecnológicos líquidos

Empleos tecnológicos líquidos

En nuestro artículo de marzo queremos hacer una reflexión sobre  las "sociedades líquidas" y su impacto en el empleo tecnológico.

Las sociedades líquidas

Las sociedades líquidas fueron definidas por el sociólogo Zygmun Bauman como aquellas que carecen de normas y estructuras sociales estables. En este contexto, los activos se transforman rápidamente en pasivos y esta situación afecta a activos tradicionales como los vehículos y las oficinas, pero también a los consultores y los empleos tecnológicos.

En el caso de los vehículos, el rápido avance tecnológico y la creciente regulación en torno a los motores de combustión hacen que la compra de un coche no tenga sentido a largo plazo, por lo que resulta más lógico optar por el renting.

De manera similar, en el caso de las oficinas, las empresas deben optar por el alquiler en lugar de la compra, ya que el rápido cambio tecnológico y la inestabilidad del mercado laboral dificultan prever las necesidades futuras de espacio.

Los empleos tecnológicos líquidos

Los consultores tecnológicos son el principal activo de muchas empresas tecnológicas. Sin embargo, el cambio acelerado puede igualmente convertir a este colectivo en un pasivo.

El desarrollo de nuevos productos tecnológicos puede convertir a grandes equipos multidisciplinares en un pasivo si el producto no consigue alcanzar las expectativas. De manera similar, cuando una empresa pierde una RFP para prestar servicios informáticos, algunos de los consultores pueden pasar al nuevo proveedor, mientras que el resto se convierte en un pasivo para su empresa.

Pero también los empleos tecnológicos pueden convertirse en una trampa laboral, si nuevas tecnologías se convierten en el nuevo estándar del mercado. Pensemos en los miles de consultores que todavía hacen el desarrollo evolutivo de sistemas mainframe y de escritorio, cuando la gran mayoría de las aplicaciones hoy en día se desarrollan para un navegador.

Hay que destacar igualmente la importancia de trabajar en varios proyectos y empresas para adquirir criterio sobre buenas y malas prácticas de gestión y liderazgo en ingeniería del software.

La aportación de las consultoras tecnológicas

En conclusión, vivimos en una sociedad líquida en la que los activos se transforman rápidamente en pasivos. Es importante que las empresas y los profesionales tecnológicos se adapten a este contexto y busquen una estrategia que les permita mantenerse competitivos en un mercado laboral en constante cambio.

En este entorno, puede ser importante la aportación de las consultoras tecnológicas, si dejan de ser meros 'proveedores de talento' y consiguen transformarse en 'agentes de desarrollo del talento'. Algo similar a los agentes de los deportistas de élite, que les acompañan en su carrera profesional y les aconsejan sobre su entrenamiento y el momento adecuado para enfrentarse a nuevos retos.


Jornada laboral para el sector tecnológico

¿Cuál es la jornada laboral más adecuada para el sector tecnológico?

¿Cuál es la jornada laboral más adecuada para el sector tecnológico?

El debate sobre la jornada laboral

La pandemia y la escasez de talento en el sector tecnológico han reavivado el debate sobre la jornada laboral y el teletrabajo.

Esta discusión corre paralela a los cambios que están experimentando las sociedades occidentales, con la progresiva desaparición de los empleos industriales.

Es una paradoja. Mientras en nuestro sector lo que faltan son profesionales y el problema es cómo retenerles, en todos los demás lo que escasea es el trabajo, así que el problema es cómo redistribuirlo. Distintos casos, ¿una única solución?

En este artículo vamos a analizar cual sería la jornada laboral más adecuada para el sector tecnológico, usando las mismas técnicas de gestión de proyectos que enseñamos a todos nuestros consultores.

Bienvenido a una sesión de formación de novanotio.

La jornada laboral y la segunda ley

La segunda ley de gestión de proyectos dice 'One Project, One Team, One Site'.

Esta ley pone de manifiesto la importancia de las relaciones personales en el mundo de la tecnología. Esto es especialmente cierto en el desarrollo de software, pero aplica por igual al resto de ámbitos de nuestro sector.

Para completar tu trabajo, necesitas la aportación de otros consultores que tienen una lista interminable de tareas pendientes. La mejor -la única- forma de que te atiendan rápido es que seáis buenos amigos. Y estos vínculos emocionales solo se forjan con el contacto directo y cotidiano.

En resumen, el trabajo presencial es muy importante.

La jornada laboral y la tercera ley

La tercera ley de gestión de proyectos dice Presión x Talento = Constante.

¿No os ha ocurrido que un problema que no podéis resolver en ocho horas, a la mañana siguiente lo resolvéis en cinco minutos?

Eso es talento.

Y Putnam, después de muchos años de investigación para el gobierno americano, llegó a la conclusión de que los proyectos sólo avanzan con esos 'Momentos de Talento'.

La tercera ley constata que cuantas más horas trabajes, más cansado vas a estar, menos momentos mágicos vas a tener y más despacio van a avanzar tus proyectos.

Desde este punto de vista, una jornada continua de cinco o seis horas al día sería la ideal.

La jornada laboral y el estado de flujo

En nuestro sector, el máximo rendimiento se consigue en estado de flujo, esa agradable sensación que experimentas cuando estás totalmente concentrado en tu trabajo y pierdes la noción del tiempo.

En las condiciones adecuadas puedes conseguir tres o cuatro horas diarias de concentración ¿Cómo podemos maximizar ese tiempo?

  • Necesitas silencio y un entorno sin distracciones, algo que se ha perdido con las praderas abiertas y los dispositivos móviles.
  • Además, si tienes que ir a la oficina, desperdicias la hora más productiva del día conmutando.
  • No tiene sentido madrugar, porque si estás cansado no te concentras (tercera ley).
  • Es imposible concentrarse después de comer, porque la sangre está en el estómago ayudando a la digestión y no en el cerebro.

Podemos sacar dos conclusiones: El teletrabajo es mejor que la jornada presencial, porque puedes levantarte más tarde, estás en un entorno más silencioso y, sobre todo, no tienes que ir y volver de la oficina. La jornada continua es mejor que la jornada partida.

La jornada óptima teórica para nuestro sector

Aplicando todo lo anterior, la jornada perfecta para el sector tecnológico sería una combinación de actividad presencial y teletrabajo, en una jornada continua de treinta horas.

En teoría, la jornada continua de 30 horas es preferible sobre la jornada de cuatro días semanales. Si solo puedes concentrarte unas tres horas al día, con la jornada de cuatro días pierdes el 20% de tu tiempo productivo.

Ambos esquemas de jornada reducida (jornada continua y jornada de cuatro días) te ofrecen más tiempo para descansar. Los días de trabajo presencial favorecen la coordinación y la formación de vínculos emocionales. El teletrabajo te aporta días de mayor concentración.

Olvídate del café. Las nuevas herramientas de mejora de la productividad individual son el descanso, la risa, el silencio, la meditación y los deportes de riesgo.

Los problemas de la jornada continua de 30 horas

Hemos visto que la jornada que mejor se adapta a nuestro sector es la jornada continua de 30 horas con teletrabajo parcial. Varias empresas han intentado adoptar este esquema, pero los intentos han fracasado. Paradigma Digital lo intentó en 2016 pero tuvo que volver a la jornada normal en 2018. ¿A qué se debe esto?

En todos los casos, la adopción de la jornada continua mejoró la productividad individual y la satisfacción de los trabajadores. ¿Qué fue entonces lo que empujó a las empresas a dar marcha atrás? ¿Por qué esa mejora de la productividad individual no se tradujo en una mejora de la competitividad empresarial?

Varios factores pueden explicarlo:

Gestión de los esfuerzos puntuales.

Con una jornada reducida, ¿Qué sentido tiene hacer sobreesfuerzos? ¿No estamos montando todo este esquema para tener mas tiempo libre?

Ante una crisis puntual, es sencillo prolongar la jornada tradicional hasta las 50 o 60 horas semanales. Pero en la jornada continua, la comida marca una frontera muy clara entre trabajo y descanso.

Uno de los requisitos para el éxito de cualquier jornada reducida es que los clientes no sufran impacto en la calidad del servicio. Es inadmisible que no se puedan atender crisis por las tardes porque no queda nadie trabajando.

Esto puede explicar el éxito relativo de los esquemas de cuatro días frente a los de jornada reducida. Igualmente se reducen las horas semanales, pero es más sencillo gestionar incidencias y crisis. Solo tienes que pedir a la mitad del equipo que trabaje de lunes a jueves, y a la otra mitad que lo haga de martes a viernes.

Capacidad del equipo de management

La principal función de la dirección y los mandos intermedios es el control y seguimiento de los procesos mediante interminables reuniones. Si la plantilla no está operativa, no se pueden reunir con nadie.

Este es uno de los problemas que las empresas reportan de forma recurrente. Con la jornada continua de 30 horas, los gestores pierden buena parte de su capacidad de dirección. La lista de problemas pendientes crece hasta hacerse ingobernable.

Aquí también funciona mejor la jornada de cuatro días. Los gestores siempre tienen al menos a una parte de la plantilla disponible para reuniones.

Apoyo tecnológico a compañeros y otros equipos

Este punto es parecido al anterior, pero aplicado a los expertos tecnológicos.

Como hemos visto, una hora de la persona que mejor conoce el problema puede ahorrar semanas de esfuerzo a todo un equipo. Aquí es donde hay que buscar los incrementos de productividad. Si solo haces tu labor técnica sin relacionarte con nadie, puede que seas muy productivo individualmente, pero la empresa pierde competitividad.

Las horas de baja productividad son la ocasión perfecta para ayudar a los compañeros, formar a los recién incorporados o aportar tu conocimiento en otra de esas aburridas reuniones con jefes de proyecto.

Resumen

El trabajo técnico tiene muchas facetas:

  • Tu trabajo técnico.
  • Atención a crisis e incidencias puntuales.
  • Apoyo a los compañeros.
  • Creación y clarificación de la especificación.
  • Desarrollo de vínculos emocionales.
  • Apoyo a la dirección.
  • ...

El desafío es encontrar un esquema que permita desarrollar todas ellas disminuyendo la carga de horas semanales.

En teoría debería funcionar la jornada continua de 30 horas, combinando teletrabajo y actividad presencial. En la práctica se están consiguiendo mejores resultados con la jornada de 4 días.

¿Acabaremos teniendo fines de semana de tres días?


Como destruir equipos de trabajo

10 formas de destruir un equipo de trabajo

10 formas de destruir un equipo de trabajo

En este artículo vamos a explicar cómo el comportamiento del Jefe de Proyecto puede destruir un equipo de trabajo.

Y la mala noticia es que todos empezamos siendo Jefes de Proyecto mediocres. Llegar a ser un buen líder requiere muchos años de práctica, y dominar unos conocimientos que no nos enseñan en las facultades de ingeniería.

Estos son los diez errores que vas a cometer con más frecuencia la primera vez que consigas una promoción:

1. Enfadarte y gritar.

Es la forma más rápida de destruir la motivación de un equipo. Educa tu amígdala, el autocontrol es fundamental para el liderazgo.

2. Feedback negativo

Si la anterior es la más rápida, ésta es la más frecuente. Dar feedback a tus consultores sólo cuando algo sale mal destruirá su confianza y su motivación. El feedback positivo es LA HERRAMIENTA de los líderes.

3. Presión

Un sobreesfuerzo prolongado destruye la motivación y dispara la rotación. ¿Cuando tu cliente te exija resultados inmediatos, qué otra cosa puedes hacer?

4. Productos de baja calidad

Los consultores quieren sentirse orgullosos de su trabajo. ‘Hay que entregar lo que sea’ no estimula el compromiso.

5. Consultores que trabajan para dos proyectos

La tentación es grande. En su proyecto no tiene mucha carga de trabajo, podría ayudar también en otro que va retrasado…

Tarde o temprano tendrá tareas urgentes en ambos, y tendrá que desatender uno de ellos.

6. Consultores que están separados físicamente

¿Qué puedes hacer?, la mitad del equipo que te han asignado está en otra ciudad…

Para que se formen vínculos emocionales son necesarias las interacciones personales. Si no hay contacto frecuente no se desarrollan las relaciones de confianza. Y el proyecto se retrasará.

7. Más consultores

¡Estamos creciendo! ¡Necesito más consultores!

Las nuevas incorporaciones pueden destruir tu equipo. Si no alcanzan el ritmo de los demás, o están quemados por su experiencia pasada en la empresa, establecerán el nuevo estándar de rendimiento.

8. Falta de confianza en tu equipo

Hay muchas formas de demostrar falta de confianza:

  • Ocultar información al equipo. Es absurdo, tarde o temprano se van a enterar y perderás tu credibilidad como líder.
  • Micromanagement, revisar minuciosamente todo su trabajo o imponerles cómo hacer cada tarea.
  • Supervisión visual. Controlar qué hacen en cada momento.

9. Reuniones de ego

Son ceremonias en las que, uno a uno, los técnicos te rinden cuentas en presencia de todos los demás. Es una pérdida de tiempo que demuestra tu nerviosismo.

10. Burocracia

¡Hay que seguir los procedimientos! Y un procedimiento significa:

  • Una vez pasó algo y no queremos que se repita.
  • Los que sabemos ya hemos pensado en esto.
  • Esta es la mejor forma de hacer las cosas
  • Te pagamos para que trabajes, no para que pienses.
  • No confiamos en tu criterio.

Es mejor utilizar las buenas prácticas, formas de hacer el trabajo que han demostrado su validez, pero que eres libre de adaptar a tu estilo

Conclusión

Cuando te promocionen a Jefe de Proyecto harás varias cosas de esta lista. Es normal, forma parte del proceso de aprendizaje y esperamos que poco a poco mejores como líder.

Para acelerar el proceso, a todos nuestros consultores les damos nuestro curso ‘Novanotio Certified, para que esa transición de jefe mediocre a líder sea lo más rápida e indolora posible. Esto que has leído es una de las sesiones de nuestro curso. Y una de las más divertidas, porque todos han sufrido en primera persona alguno de estos comportamientos.

Si en el futuro deseas liderar un equipo, puede ser una buena idea vivir una experiencia novanotio, ser parte de nuestra plantilla y formarte con uno de nuestros coordinadores. Aquí te dejo el enlace a nuestras ofertas,  espero que encuentres alguna perfecta para ti.


Las cuatro leyes de la gestión de proyectos tecnológicos

Las cuatro leyes de la gestión de proyectos tecnológicos

Las cuatro leyes de la gestión de proyectos tecnológicos.

Estas cuatro sencillas reglas son la base de la gestión de proyectos tecnológicos.

Son solo 35 palabras, pero necesitarás algunos años para dominarlas y aplicarlas correctamente. Si deseas convertirte en un buen Jefe de Proyecto, serán tu credo. Apréndetelas de memoria y practícalas cada día.

1ª ley. Las especificaciones son inciertas, imprecisas e infinitas.

La primera ley es la responsable de que fracase el 80% de los grandes proyectos informáticos en todo el mundo. Esta cifra se mantiene estable desde los años 60 hasta hoy. Las nuevas herramientas de desarrollo y las diferentes metodologías no han conseguido mitigar este desastre.

Nos avisa de que el cliente no puede saber lo que quiere. Los sistemas informáticos son demasiado complejos. La especificación siempre estará incompleta. Por eso son inciertas.

Nos advierte de que no existe un lenguaje de alta precisión para comunicar las instrucciones técnicas. Los arquitectos disponen de los planos, un lenguaje de muy alta precisión. Los ingenieros informáticos sin embargo usamos el lenguaje natural, que es interpretable. Por eso son imprecisas.

Nos alerta de que un proyecto nunca termina. Siempre quedan errores que corregir y mejoras por implementar. ¿Alguna vez has puesto la última línea de código de un programa? Por eso son infinitos.

Cómo usar la primera ley:

  1. Especifica menos y haz más prototipos.
  2. Relaciónate más con tu cliente.
  3. No discutas el significado de un párrafo.
  4. ¡Haz que abone las facturas cuando todavía queda mucho por hacer!

2ª ley. One project, one team, one site.

Como el cliente no puede saber lo que quiere, y no disponemos de un lenguaje de alta precisión, las relaciones personales cobran especial relevancia.

La especificación se construye según avanzan los desarrollos, y los vínculos emocionales son la clave para distribuir ese conocimiento.

La segunda ley nos indica cómo construir esos vínculos. Los analistas funcionales, programadores, testers e incluso el cliente deben estar en la misma sala. Y mucho mejor si cada consultor trabaja en exclusiva para el proyecto.

Las software labs, las organizaciones matriciales y los equipos distribuidos son ineficientes.

Un apunte de Franz Hassmann, CTO de BBVA Next. Mejor si los equipos son pequeños, de entre 5 y 9 componentes.

3ª ley. Presión x Talento = Constante.

Durante miles de años hemos dirigido organizaciones gestionando la presión. Con el nacimiento de la informática necesitamos, por primera vez en la historia, gestionar el talento.

La tercera ley anticipa que si incrementas la presión de trabajo, disminuye el talento y los desarrollos se retrasan.

Así que olvídate de los bonus por objetivos y de exigir horas extras. Esas son herramientas de gestión de la presión.

Debes gestionar el talento. Ofréceles retos. Usa el feedback positivo. Bloquea la presión del cliente y deja que el equipo encuentre su ritmo de trabajo.

4ª ley. Alcance, Plazo y Calidad. Si fijas dos de ellas, la tercera se degrada porque es la variable de ajuste.

Recuerda, las especificaciones son infinitas.

Así que algo tienes que sacrificar. Puede elegir entre el alcance (entregar menos producto), el plazo (retrasar las entregas) o la calidad (entregar algo sin apenas pruebas).

La cuarta ley nos propone que alcance, plazo y calidad están interrelacionados. Si fijas dos de ellos, el tercero se degrada.

Nunca, nunca, nunca sacrifiques la calidad. Nunca fijes alcanzo y plazo.

SCRUM por ejemplo fija plazo y calidad, el alcance queda indeterminado. Se factura por cada sprint.

TIME & MATERIAL, los servicios profesionales de toda la vida, fijan alcance y calidad, y es el plazo el que queda indeterminado. Se factura mensualmente por el esfuerzo dedicado.

Si haces PROYECTOS CERRADOS, perderás dinero en el 80% de los contratos.

Enlaces de interés

Son solo cuatro reglas sencillas de aprender. Sin embargo, muchas organizaciones todavía preparan extensos documentos funcionales, deslocalizan parte de los equipos y trasladan la presión del cliente a sus desarrolladores.

Os dejo los enlaces a las fuentes de las cuatro leyes. Si comprendéis los fundamentos de cada una de ellas, os será más sencillo  adaptarlas a vuestra organización.

La primera ley tiene su origen en ‘The mythical man-month’ de Brooks. Quizás el primer libro sobre ingeniería del software. Escrito a finales de los sesenta y una referencia obligada a día de hoy. Se complementa con Introducción a la PNL’ de Seymour, un libro sobre psicología del lenguaje.

La segunda ley procede del fantástico libro ‘Peopleware’ de DeMarco. Posiblemente el primer ensayo sobre programación y productividad. Muy entretenido.

La tercera ley procede de un clásico sobre la motivación. ‘Drive’ de Daniel H. Pink. Igualmente divertido y ágil.

La cuarta ley procede tanto del libro de Brooks como de ‘Agile Software Requirements’ de Dean Leffingwell. No son fáciles ninguno de los dos, pero merece la pena el esfuerzo.

Te animo a compartir con todo nuestro sector tus experiencias en los proyectos en los que has participado. ¿Se han cumplido las cuatro leyes? ¿Añadirías alguna más?

¡Suerte en tu carrera de gestión de proyectos tecnológicos!


Domina los fundamentos de Scrum y multiplica tu valor en el mercado

Fundamentos de SCRUM

Fundamentos de SCRUM

Es importante que domines los fundamentos de SCRUM si quieres implementar con éxito esta metodología.

Seguramente ya has leído libros y blogs que explican los diferentes procesos de SCRUM. El desarrollo en sucesivas iteraciones o sprints, el daily, el Sprint Planning, la retrospective, etc.

Si no conoces los fundamentos de SCRUM, lo mas probable es que cometas los mismos errores que la mayor parte de las organizaciones. Acabarás por implementar SCRUM como si fuera una religión y apenas conseguirás mejorar la productividad.

En novanotio defendemos que hay cuatro sencillas reglas que ayudan a gestionar con éxito los proyectos tecnológicos. Es una buena idea que revises nuestro artículo sobre las cuatro leyes antes de continuar con esta lectura.

En esta entrada vamos a analizar las relaciones entre las cuatro reglas básicas y los procesos de la metodología. Una vez que comprendas los fundamentos de SCRUM, estarás mejor preparado para implementarla en tu organización.

Relación entre SCRUM y la 1ª ley.

Las especificaciones son inciertas, imprecisas e infinitas.

La primera ley nos advierte tres cosas:

– Que el cliente no puede saber lo que quiere. El tiempo invertido en especificar suele ser tiempo perdido.

– Que una especificación redactada en lenguaje natural (castellano, inglés, alemán, etc.) es interpretable.

– Que no es posible finalizar los trabajos. Siempre queda algo por hacer.

¿Cómo responde Scrum a estos tres desafíos?

– El diseño es muy liviano; los requisitos se capturan en Epics, Features e Historias de Usuario, cuya extensión es de un párrafo.

– Para interpretar la especificación, se incorpora al squad un representante del cliente, el Product Owner,

– El Product Owner prioriza los trabajos para que el Retorno de Inversión sea el mayor posible, dentro del presupuesto.

Relación entre SCRUM y la 2ª ley.

One Project, One Team, One Site.

La segunda ley dice que para mejorar la productividad, todo el equipo de trabajo, incluido el cliente, debe estar en una única oficina y dedicarse en exclusiva al proyecto. La convivencia construye vínculos emocionales y relaciones de confianza que son imprescindibles.

¿Cómo construye Scrum los equipos?

En Scrum, los squads de desarrollo están formados por entre cinco y nueve consultores, cuyos puestos de trabajo están próximos entre sí. El Product Owner, que es el representante del cliente, es un miembro más del equipo.

Relación entre SCRUM y la 3ª ley.

Presión x Talento = Constante.

Talento y presión son antagónicos. Cuando uno crece, el otro disminuye.

La tercera ley nos recuerda que en el desarrollo de software debemos priorizar el talento sobre la presión. La velocidad de desarrollo depende del número de buenas ideas, no del número de horas de la jornada.

¿Cómo fomenta Scrum el talento?

Para eliminar la presión, en Scrum no es obligatorio completar todas las Historias planificadas para el sprint. Algunos desarrollos no superan los test y vuelven al backlog.

Relación entre SCRUM y la 4º ley.

El triángulo de Acero.

La cuarta ley nos enseña que Alcance, Plazo y Calidad están relacionados de tal forma que, si fijas dos de ellos, el tercero se degrada.

Tradicionalmente un contrato fija el alcance y el plazo. ¿El resultado? El 80% de los grandes proyectos son un fiasco.

Así que, como cliente, debes elegir entre:

– Sacrificar el Alcance. Ciertas funcionalidades no se construirán.

– Sacrificar el Plazo (y multiplicar el coste). El sistema se entregará muuucho mas tarde de lo planificado.

– Sacrificar la Calidad. El sistema tendrá errores en producción y será complejo de operar.

¿Qué variable sacrificamos en SCRUM?

La metodología SCRUM determina que la variable sacrificada es el Alcance.

La gran aportación de SCRUM es modificar la definición de éxito de un proyecto. Ya no tenemos que cumplir un alcance dentro de un plazo y con una buena calidad. Cosa que, por cierto, es imposible.

Éxito es conseguir el mayor retorno de inversión posible, dentro del presupuesto y en un plazo acotado.

¿Puedo mejorar la eficiencia sin usar Scrum?

Si conoces los fundamentos de Scrum, puedes utilizar los principios básicos de gestión de proyectos y mejorar el rendimiento de tus proyectos sin necesidad de implementar la metodología.

Pero SCRUM es la palabra de moda. ¡Aprende a implementar esta metodología y tu valor para el mercado se multiplicará!


Es hora de cambiar de puesto. Te ayudamos a descubrir que roles se te dan mejor usando el test de fortalezas de Gallup

Cómo orientar tu carrera profesional usando el test de Gallup

Cómo orientar tu carrera profesional usando el test de Gallup

En el entorno tecnológico es fácil tener una primera promoción

Estás haciendo un gran trabajo como programador, y como premio te han propuesto cambiar de actividad. Quizás te han pedido que lideres a un grupo de consultores. O tal vez que asistas a una reunión de ventas.

En el entorno tecnológico es fácil tener una primera promoción. Descubrirás que hay roles que te son tan naturales cómo respirar y otros en los que, a pesar de tu esfuerzo, sólo recibes disgustos. ¿Cómo saber si la jugosa manzana que te ofrecen está envenenada?

El test de fortalezas de Gallup

Vamos a estudiar cómo orientar tu carrera profesional usando el test de fortalezas de Gallup. Si todavía no lo has hecho tienes el enlace aquí. Considera estos veinte dólares como una de las mejores inversiones de tu vida.

Este test te descubre tus principales fortalezas, es decir, los tipos de talento que has desarrollado de forma natural. Gallup distingue entre treinta y cuatro fortalezas que se agrupan en cuatro ámbitos:

  • Fortalezas de ejecución. ¿Qué es lo siguiente que tengo que hacer? Si tu única recompensa es un trabajo bien hecho o no puedes dejar una tarea a medias, eres un auténtico ejecutor.
  • Fortalezas de pensamiento. ¿Cuál es la mejor forma de hacer las cosas? Si no puedes dejar de estudiar o tienes una potente capacidad analítica eres todo un pensador.
  • Fortalezas de relación ¿Cómo construyo relaciones? Si rápidamente sabes cómo son las personas, o para ti lo más importante es el ambiente de trabajo, tienes este tipo de fortalezas.
  • Fortalezas de influencia. ¿Cómo consigo convencer a los demás? Si siempre tienes en la boca la palabra adecuada considérate un influencer.

¿Qué fortalezas ayudan a desempeñar los distintos roles tecnológicos?

No todos los roles tecnológicos precisan de las mismas fortalezas. Según el resultado de tu test de Gallup, te sentirás más cómodo en unos u otros puestos.

Si tus fortalezas son de pensamiento y relación

En los primeros test de Gallup que realizamos, descubrimos que los mejores programadores combinaban fortalezas de pensamiento y relación.

Pronto nos dimos cuenta que, para programar, los vínculos emocionales son muy importantes, porque facilitan la construcción de las especificaciones y la coordinación de las tareas.

En resumen, si tus principales fortalezas son de relación y pensamiento, la programación se te dará bien de forma natural.

Si tus fortalezas son de pensamiento

Sin embargo, si la mayoría son de pensamiento, estarás más cómodo en roles con más complejidad y menos relación, como la administración de sistemas o la ciberseguridad.

Si tus fortalezas son de relación

Si tus fortalezas son sobre todo de relación, busca trabajos donde tengas que estar en contacto con el cliente. Los roles de soporte combinan una parte de conocimiento técnico y mucha relación con los usuarios de las aplicaciones y sistemas.

Si tus fortalezas son de relación e influencia

Si a las fortalezas de relación se suman las de influencia, tu sitio está en el área de ventas. Aquí tu misión es crear un vínculo con el cliente y convencerle de que ponga una firma. ¡Como pueden pagar esas comisiones por un trabajo tan sencillo!

Si combinas fortalezas de pensamiento e influencia

La combinación de pensamiento e influencia es interesante para liderar equipos. Te sentirás cómodo en las posiciones de Líder Técnico, Jefe de Proyecto o Gerente.

Si tus fortalezas son sobre todo de influencia

Cuantas más fortalezas de influencia aparezcan en tu test de Gallup, más cómodo te sentirás con cada ascenso. Director de Operaciones, CIO, CTO… El cielo es el límite.

Si la mayoría de tus fortalezas son de influencia, tu sitio está en la alta dirección. Algunos te llamarán trepa o pisacuellos. Bueno, quizás no has sido el mejor técnico, pero siempre sabes lo que tienes que decir. Y esas fortalezas te empujarán a los roles que empiezan por C.

¿En qué organizaciones encajarás mejor?

Si tus fortalezas son sobre todo de pensamiento, estarás más cómodo en organizaciones con cultura Growth Mindset.

Por el contrario, si son de ejecución o influencia, busca empresas de tipo Fixed Mindset.

En este artículo de nuestro blog analizamos las diferencias entre ambos tipos de liderazgo.

Alinea tu trayectoria con tus fortalezas

Cuando tu trayectoria profesional está alineada con tus fortalezas, te pagan por hacer lo que se te da bien de forma natural. En el caso contrario también puedes hacer un trabajo brillante, aunque a costa de un mayor esfuerzo y desgaste personal.

¿Quieres saber que actividades son mas adecuadas para ti? Envíame el resultado de tu test de fortalezas y te daré algunas ideas para orientar tu carrera.


Es fácil confundir Scrum con una religión. No cambies el triángulo de acero por el ojo sagrado.

Scrum no es una religión

Scrum no es una religión

SCRUM no es una religión. SCRUM es una forma de aplicar las Cuatro Leyes Básicas de la gestión de proyectos. El proceso de desarrollo Scrum es eficiente porque cumple estas cuatro reglas.

Si entiendes los fundamentos de la gestión de proyectos informáticos, puedes adaptar SCRUM, o cualquier otra metodología, a tu empresa.

Pero si no conoces estos fundamentos, corres el riesgo de implantar SCRUM en tu organización como si fuera una poderosa religión.

Y no encontrarás la tierra prometida.

Si adoptas SCRUM como si fuera una religión…

SCRUM es la religión de los elegidos

Scrum es todopoderoso porque es la religión de los elegidos. Si quieres llegar a la tierra prometida de la tecnología, ese lugar idílico donde todos los proyectos finalizan en plazo, debes seguir puntualmente cada uno de sus ritos.

Ya en los tiempos olvidados de las tarjetas perforadas, los profetas Brooks y DeMarco nos advirtieron que los proyectos son tan complejos que podemos trabajar en ellos por los siglos de los siglos. Imbuidos por el espíritu, propusieron abordar la solución en sucesivas iteraciones, meditando junto al cliente tras cada una de ellas qué se ha conseguido y qué se debe hacer a continuación.

El ritual SCRUM que inspiraron es como sigue:

La Sagrada Firma

El  Sumo Account Manager descubre una necesidad del cliente y prepara una oferta que tiene plazo y presupuesto definidos pero cuyo alcance queda indeterminado. Realiza sacrificios a Poseidón y ofrendas a Baco para que el cliente realice la Sagrada Firma.

La Sagrada Firma es el ritual más complejo y al que menos atención se presta en los Textos Sagrados. Los clientes no iniciados se resisten a comprometer presupuestos determinados a cambio de servicios indeterminados. No intentes explicarles que en los proyectos realizados según los heréticos ritos de Waterfall, donde el alcance si estaba definido, en media sólo se entregaba el 50% de lo especificado.

El Product Backlog y el Team Backlog

Tras la Sagrada Firma, el cliente unge a uno de sus acólitos con la pesada responsabilidad del éxito de la empresa. A partir de ahora todos le conocerán como el venerable Product Owner.

En un concilio entre cliente, Account Manager y Product Owner, describen el sistema en una docena de tarjetas sagradas de una extensión de algunos párrafos llamadas Epics y Features. Las sagradas tarjetas se exponen a los acólitos en un altar de corcho llamado Product Backlog para que sean para ellos fuente de inspiración.

En sucesivos aquelarres, el Product Owner y los programadores, descomponen Epics y Features en nuevas tarjetas llamadas Historias de Usuario, que tienen la forma ‘Como usuario <perfil de usuario> soy capaz de hacer <tarea> y así consigo <valor para el negocio> ’. Exponen su trabajo en un nuevo altar de corcho, el Team Backlog.

La implementación

Es el momento de comenzar los ritos de implementación.

El primero es formar la escuadra de desarrollo, con el Product Owner, un Scrum Master y entre cinco y siete consultores. Sus puestos de trabajo deben estar próximos entre sí y se encargarán de implementar de extremo a extremo las Historias de Usuario. Su sagrado apostolado incluye definir la arquitectura, hacer el diseño, codificar, probar, integrar y documentar.

Cada iteración comienzan con la ceremonia del Sprint Planning. El squad se reúne para decidir qué Historias de Usuario intentarán implementar durante el Sprint, que durará entre tres y cuatro semanas. El Product Owner sabe qué historias de usuario son prioritarias. La escuadra intuye su velocidad de ejecución.

Cada mañana, antes de la salida del sol, la escuadra se reúne para maitines, rito también conocido como daily. Durante el resto del día, diseñan las Historias de Usuario, las codifican, desarrollan las pruebas unitarias y prueban el software construido. Sólo si el código supera las pruebas se considera apto para depositar a los pies del cliente e implorar su aceptación.

El Product Owner ayuda a los programadores a interpretar las sagradas Historias de Usuario. El Scrum Master vela por la pureza de los rituales.

El Sprint Review

Finalizado el Sprint, el squad celebra el Sprint Review, ceremonia en la que el código desarrollado se ofrece al cliente y las Historias de Usuario que no se han completado se devuelven al team backlog.

El Sprint Retrospective

El acto final es el Sprint Retrospective. Aquí Product Owner, programadores y testers reconocen sus faltas y hacen propósito de enmienda, con el fin de ser más productivos en próximas iteraciones.

Que los Dioses te sean propicios

Sigue religiosamente este ritual y alcanzarás la tierra prometida con la bendición de los Dioses.

Los peligros de imponer SCRUM a tu organización como si fuera una religión

Los ritos de SCRUM son folclore, comportamientos llamativos que emplean otras organizaciones. Desconocemos su significado, pero hay cientos de artículos describiendo su éxito y son tentadores de imitar.

Un ejemplo de imitación del folclore. Una organización que compró una mesa de billar, pero despidió a un consultor por ir al médico. ¿Veis a lo que me refiero? Si te despiden porque estás enfermo y vas al centro de salud, ¿cuál será el castigo si estás sano y dejas de trabajar para hacer carambolas?

Si no conoces las reglas básicas de la gestión de proyectos, corres el riesgo de implantar SCRUM como si fuera una religión, y cometer los mismos errores que buena parte de las organizaciones.

Y entonces no llegarás a la tierra prometida.


Dentro de las carreras profesionales tecnológicas, Analista Programador es la primera promoción. Y esconde una trampa que debes conocer.

Carreras profesionales. El analista programador

Carreras profesionales. El Analista Programador.

El Analista Programador es la primera promoción dentro de las carreras profesionales tecnológicas. Y esconde una trampa que debes conocer.

Con un poco de paciencia, en tres o cuatro años serás el programador más veterano de un pequeño grupo de consultores, lo que te convierte de facto en su líder técnico, el Analista Programador.

Aquí te vas a enfrentar a tu primer problema de liderazgo. ¿Dedico mi precioso tiempo a realizar mi trabajo técnico, o a formar a los consultores recién incorporados?

Existen tres posibles estrategias:

Estrategia 1. Priorizas la formación de los nuevos consultores

Tu primer intento será priorizar la formación de los nuevos consultores, para que puedan trabajar con autonomía.

Hemos representado en la gráfica el resultado de esta estrategia con una línea verde. ¿Te das cuenta de que a corto plazo es la solución menos eficiente? Esto significa dos cosas. Que tu lista de tareas pendientes amenaza con llegar al infinito. Y que tu cliente y tu Jefe de Proyecto están muuuy nerviosos.

Si consigues soportar la presión, a medio plazo construirás un Equipo de Alto Rendimiento.

Pero lo normal es que resbales a la estrategia número dos.

Estrategia 2. Priorizas tu trabajo técnico

Cedes a la insoportable presión del cliente y dedicas la mayor parte de tu tiempo a esa lista de tareas críticas pendientes.

Estás tan concentrado que hasta te molesta que te consulten dudas. Los jóvenes consultores se aburren y se frustran porque aprenden muy despacio. Hasta es posible que alguno de ellos se vaya. ¡Justo ahora que empezaba a tener algunos conocimientos!

Hemos representado en rojo los resultados. A corto plazo superas a la estrategia uno, pero sigues muy lejos de las expectativas del servicio. Ya sabes, tensas reuniones con el cliente y con tu Jefe de Proyecto.

Así que, agotado, caes a la estrategia número tres.

Estrategia 3. Haces tu trabajo técnico y además formas a los nuevos consultores.

Esta estrategia supone un enorme desgaste por el volumen de horas necesario. Es una muestra de compromiso hacia tu empresa y tu cliente. ¡Estás sacrificando tu vida personal y familiar! Lo menos que esperas es que alguien te de las gracias.

Y si te fijas en la línea amarilla, tus resultados superan a las estrategias uno y dos. Pero lamentablemente sigues por debajo de las expectativas. ¿Sabes lo que eso significa? Si. En lugar de agradecimientos, mas tensas reuniones con el cliente y con tu Jefe de Proyecto.

¿Ves como se desploma la línea amarilla? Ese es el punto en que presentas la baja voluntaria o la baja por depresión.

 

Resultado de las posibles estrategias de trabajo de un Analista Programador
Resultado de las posibles estrategias de trabajo de un Analista Programador. ¿Es que no hay forma de cumplir las expectativas?

A corto plazo, ninguna de las estrategias alcanza las expectativas

Como puedes ver, a corto plazo ninguna estrategia ofrece resultados acordes con las expectativas, lo que se traduce en presión. Retrasos, tareas pendientes y discusiones.

Entonces ¿Cuál de ellas elegir?

Pues, teniendo en cuenta que las estrategias dos y tres nunca alcanzan la productividad deseada, la decisión no es difícil.

Nuestro consejo es apostar por las personas y elegir la primera de las opciones. Aprenderás a gestionar la presión y aprenderás a crear equipos de alto rendimiento. Y si la presión te supera, es un buen momento para dar un paso atrás y retomar el camino del Especialista Tecnológico.

En próximos artículos veremos cómo la estrategia número uno consigue a largo plazo superar las expectativas del cliente. Y veremos también los nuevos desafíos que eso genera.

No olvides volver de vez en cuando y revisar las nuevas entradas.