Jorge Paz's Blog

La influencia del líder en los clientes y el equipo

Si eres un líder de un equipo, ¿Tienes claro la influencia que tienes en las personas que interactúas? ¿Qué impacto tiene su estilo de liderazgo en la satisfacción y la lealtad de los clientes, en la confianza y el apoyo de la gerencia y en el rendimiento y la cohesión del equipo?

El líder es una pieza clave en cualquier organización, ya que es el responsable de establecer la visión, los objetivos y las estrategias del equipo. Además, asigna las tareas, supervisa el trabajo, resuelve conflictos, da feedback y reconocer los logros. Ante el cliente y la gerencia, es el representante del equipo, por lo que debe transmitir una imagen profesional, confiable y positiva. Pero no todos los líderes son iguales, ni todos los equipos necesitan el mismo tipo de liderazgo. Existen diferentes estilos de liderazgo, cada uno con sus ventajas e inconvenientes, que se adaptan mejor a diferentes situaciones, contextos y personalidades. Veamos algunos de ellos:

Liderazgo transformacional: El líder transformacional es aquel que inspira y moviliza al equipo hacia una visión compartida. Es el típico jefe que dice «vamos a cambiar el mundo». Este estilo puede ser efectivo en situaciones de crecimiento o innovación, cuando se necesita generar entusiasmo, confianza y lealtad, pero también puede generar expectativas irreales y una presión excesiva. Los clientes pueden percibir al líder transformacional como alguien carismático, visionario y apasionado, lo que puede aumentar su satisfacción y fidelidad. La gerencia puede valorar al líder transformacional por su capacidad de motivación e influencia, pero también puede cuestionar su realismo y consistencia.Liderazgo autoritario: El líder autoritario es aquel que impone su criterio sin consultar ni escuchar a los demás. Es el típico jefe que dice «aquí se hace lo que yo digo y punto». Este estilo de liderazgo puede ser efectivo en situaciones de crisis o emergencia, cuando se necesita tomar decisiones rápidas y claras. Sin embargo, puede generar desmotivación, frustración y resentimiento en el equipo, así como una baja calidad del trabajo y una alta rotación del personal. Los clientes pueden percibir al líder autoritario como alguien arrogante, inflexible y poco empático, lo que puede afectar negativamente a su satisfacción y fidelidad. La gerencia puede valorar al líder autoritario por su capacidad de control y disciplina, pero también puede cuestionar su creatividad e innovación.Liderazgo democrático: Es aquel que fomenta la participación y la colaboración de todos los miembros del equipo. Es el típico jefe que dice «¿qué opinan de este tema?». Este estilo puede ser efectivo en situaciones de cambio o incertidumbre, cuando se necesita generar ideas, consenso y compromiso. Sin embargo, puede generar lentitud, indecisión y confusión en el equipo, así como una falta de responsabilidad y dirección. Los clientes pueden percibir al líder democrático como alguien abierto, flexible y cercano, lo que puede favorecer su satisfacción y fidelidad. La gerencia puede valorar al líder democrático por su capacidad de comunicación e integración, pero también puede cuestionar su autoridad y liderazgo.

No hay un estilo de liderazgo que resuelve todo, dependerá del contexto de la situación. Lo importante es que el líder sea capaz de adaptarse a las necesidades y características del equipo, de los clientes y de la gerencia, así como a las circunstancias del momento. Un buen líder es aquel que sabe cuándo ser autoritario, cuándo ser democrático y cuándo ser transformacional (por ejemplo). Y, sobre todo, un buen líder es aquel que respeta, valora y potencia el talento de su equipo, que se preocupa por la satisfacción y la lealtad de sus clientes, y que se gana la confianza y el apoyo de su gerencia.

The post La influencia del líder en los clientes y el equipo first appeared on Jorge Paz.

Proyecto: ¿Qué necesitas para liderarlo?

¿Es suficiente tener el conocimiento para liderar un Proyecto y tener éxito? No es suficiente, sin embargo, hay personas que creen que es lo único que necesitan. Sigue leyendo para conocer algunas habilidades que se necesita para liderar un proyecto.

¿Un director de proyecto es simplemente un rol?

Es una idea que tienen muchos gerentes. Creen que basta con escoger alguna persona que ha tenido un buen desempeño en un área (efecto halo). No realizan un análisis si el aspirante cuenta con las habilidades necesarias para dirigir un proyecto.

¿Los conocimientos sobre proyectos es garantía de éxito?

Algunos creen que, por tomar un curso sobre proyectos, es suficiente. Sin embargo, por tener conocimientos de proyecto, no significa que aplicará esos conocimientos de la mejor manera. Conozco a directores de proyecto que no lo aplican al momento de dirigir un proyecto.

¿Es suficiente con tener actitud para dirigir un proyecto?

Es un atributo muy valioso, es una ventaja para alguien que dirigirá un proyecto. ¿Significa que un director con mala actitud este condenado al fracaso? No. Aunque, será más difícil obtener resultados en comparación con alguien que tenga una buena actitud. He trabajado con líderes con mala actitud, hacen que el trabajo de su equipo y de los interesados sea más difícil. Un director con actitud colaborativa, de resolver problemas, acepta y busca consejos, por ejemplo, tienen mayor probabilidad de éxito. Ahora bien, la actividad sola no puede resolver todos los problemas, se necesita apoyar de habilidades y conocimientos.

¿Qué habilidades son necesarias para dirigir un proyecto?

Las habilidades dependerán del contexto del proyecto, de acuerdo a ello, se podrá escoger a la persona adecuada para ello. Veamos algunas de ellas:

Comunicación

El director de proyecto dedica más del 80% de su tiempo a comunicar. En proyectos de Software, hay muchos directores que antes de obtener esta responsabilidad han sido programadores. Están acostumbrados a enfocarse en su trabajo y la comunicación no es una fortaleza para muchos de ellos. Esto puede ser un factor negativo si debe estar en varias reuniones con interesados. Necesita poder hablar en público, defender su punto de vista, saber escuchar, etc.

Relaciones personales

Necesita tener buenas relaciones con los interesados y con su equipo. Se puede conseguir mejores resultados cuando las personas se sienten valorados, incrementando la sinergia entre ellos.

Pensamiento crítico

Aunque el detalle del trabajo lo puede delegar, puede definir los objetivos, el alcance y los requisitos del proyecto. Además, debe identificar y resolver los problemas que puedan surgir durante su desarrollo.

Organizado

Planifica las actividades, las tareas, los plazos y los recursos del proyecto, así como para controlar su avance y cumplimiento. Esta habilidad es puesta a prueba cuando surgen los problemas. Al tratar de resolverlos, puede hacer a un lado la organización del equipo.

Liderazgo

El director es más que un administrador, es un líder. Debe poder influir en los interesados y al equipo para alcanzar el objetivo del proyecto. Esto hace que las personas lo sigan más allá de un horario de oficina.

Negociación

Siempre hay situaciones donde hay dos o más puntos de vista, esto puede detener un proyecto. Es necesario negociar para gestionar las expectativas y los intereses de los involucrados en el proyecto.

Resiliencia

Los problemas en un proyecto es parte del trabajo. Debe estar preparado para recibir impactos negativos en el proyecto y seguir adelante. Para las personas que empiezan a dirigir un proyecto y que este teniendo problemas, puede ser frustrante y puede impactar en el rendimiento del equipo del proyecto. Debe poder ayudar al equipo para sobreponerse de esta situación y seguir trabajando. Esto conlleva hacer cambios en el plan.

Adaptativo

Los cambios de rumbo de un proyecto son habituales, esto no es cómodo para muchos. Debe estar preparado para afrontar los cambios e imprevistos que puedan afectar al proyecto. Ajusta la planificación y las acciones según las nuevas circunstancias y oportunidades.

Autogestión

Los directores de proyecto son los responsables en alcanzar el objetivo del proyecto. Si bien puede tener jefes, está facultado para tomar decisiones (a menos que esté como coordinador o gestor). Decide qué, cómo y cuándo trabajará las actividades del proyecto y no esperar a que su jefe se haga cargo. Si están trabajando un proyecto con enfoque ágil, el equipo necesita ser auto gestionado y el director puede ayudarlos.

Colaborativo

Tiene la capacidad de trabajar de forma cooperativa con otras personas, compartiendo conocimientos, recursos y responsabilidades, y buscando el beneficio mutuo y el éxito del proyecto.

Creativo

Puede generar ideas originales, innovadoras y útiles para el proyecto, aplicando diferentes técnicas y fomentando la participación y la diversidad del equipo.

¿Hay una habilidad que sea imprescindible en la dirección de proyectos?     Creería que dependerá del contexto del proyecto. Por ejemplo, si se está realizando un proyecto que involucre a pocas personas, puede que las habilidades de comunicación no sean exigidas en comparación a un proyecto que impacte a muchos interesados.

Hay más habilidades que pueden influir en un proyecto, si deseas comentar alguna habilidad más, escríbelas en los comentarios.

 

Acerca del autor:

Jorge Paz es Coach, Consultor y autor de los libros «Creando valor con proyectos ágiles» y «Transforma la incertidumbre en oportunidades «. Con más de 10 años en la gestión de proyectos. Ha trabajado en proyectos en varios países de Latinoamérica apoyando a equipos de proyectos en alcanzar sus objetivos.

Imagen: Creador de imágenes de Bing

 

The post Proyecto: ¿Qué necesitas para liderarlo? first appeared on Jorge Paz.

Anatomía de impedimentos en Scrum

¿Qué pasa cuando un equipo de Scrum se enfrenta a un impedimento? Pues se crea un gran problema que se tiene que resolver en corto plazo. Si deseas saber cómo identificarlos, sigue leyendo.

¿Qué es un impedimento?

Los impedimentos son esos problemas que surgen en el desarrollo de un proyecto y que hacen que todo se retrase, se complique o fracasen, por ejemplo, que se caiga el servidor, que se pierda el código fuente o que el cliente cambie de opinión frecuentemente.

Para evitar que los impedimentos arruinen el sprint, el equipo de scrum debe identificarlos lo antes posible y buscar soluciones creativas y eficientes. El Scrum Master es el encargado de facilitar este proceso y de eliminar los obstáculos que se interpongan en el camino. Pero no es el único responsable: todos los miembros del equipo deben colaborar y comunicarse para superar los impedimentos y lograr el objetivo del sprint.

¿Son inevitables los impedimentos?

La respuesta simple es sí. ¿Porque? Scrum es utilizado para resolver problemas complejos y de alta incertidumbre, por lo que los impedimentos son parte de la complejidad y la incertidumbre. Los impedimentos son inevitables, pero no insuperables, además crean oportunidades para mejorar. Piensa que son parte del desafío de hacer scrum y pueden ser superados. Los impedimentos se pueden aprovechar para mejorar la autogestión del equipo, la creatividad, la inteligencia colectiva y la experiencia de cada uno de los profesionales que participan en el proceso.

Distintos tipos de impedimentos

Los impedimentos pueden ser internos o externos al equipo, pueden surgir en cualquier momento del sprint. Por eso, es importante identificarlos y comunicarlos lo antes posible, para que el equipo pueda actuar y resolverlos en corto plazo. Entre los impedimentos externos podemos mencionar cualquier situación que no se origina en el proyecto como terremoto, huracanes, pandemias, situaciones políticas o actividades que impactan al proyecto como falta de presupuesto, cambio en la gerencia, etc. Entre los impedimentos internos podemos mencionar:

No tener claro el objetivo del Sprint. El equipo se da cuenta que las actividades que están realizando, no están enfocadas a alcanzar el objetivo del Sprint, en consecuencia, el objetivo puede no alcanzarse y se necesite otro Sprint para intentar entregarlo.Falta de apoyo del Product Owner. El Product Owner se ausenta en el Sprint, los desarrolladores tienen dudas sobre los elementos que trabajan, causando atrasos en las entregas del Sprint.Situaciones técnicas. Los Sprints duran días, si es el primer Sprint y se espera que el incremento lo va a utilizar el usuario final, contar con el equipo listo, los ambientes y permisos son requeridos en corto plazo.Desempeño del equipo. Los desarrolladores pueden afrontar obstáculos como ser recién contratados, no tener experiencia en Scrum, no son especialistas en el área que están trabajando, etc.Falta de autogestión. Los desarrolladores están acostumbrados que alguien les asigne el trabajo y les diga que hacer, es el resultado de la falta de autogestión. Esto genera varios problemas en el rendimiento del equipo, esa persona que le dice que hacer a los desarrolladores forma a ser un cuello de botella.Exceso de reuniones. Los desarrolladores participan en reuniones para resolver dudas o aportar en temas que no tienen relación con el Sprint.Creación de informes para la gestión de proyecto. Aunque en el enfoque ágil se prefiere unl producto funcionando a una documentación extensiva, en algunas organizaciones, exigen todavía este tipo de documentación. El Scrum Master, el Product Owner u otro rol, se les asigna la responsabilidad de crear reportes de estado y esto les lleva a solicitar información puntual a los desarrolladores. Esto es en sí un obstáculo para alcanzar sus objetivos.Ausencia de despliegues continuos y pruebas automatizadas. Al durar poco tiempo los Sprints, por ejemplo 2 semanas, implicaría que el usuario recibiría al mes por lo menos 2 incrementos, esto hace necesario que incrementos sean entregados correctamente. Si los desarrolladores lo realizan de manera manual, la probabilidad de fallas de calidad por compilación se incrementa, esto se reduce con despliegues continuos y pruebas automatizadas.Bloqueo del flujo de trabajo para entregar el incremento. El flujo para trabajar un elemento del Sprint Backlog debe ser continuo, dejarlo a la mitad para trabajar otro no es la mejor práctica. El objetivo es disminuir el desperdicio de trabajo, si hay situaciones que impidan terminar el trabajo, el que notará el atraso y se quejará será el usuario.Elementos del Sprint Backlog sean ambiguos. Si los elementos a trabajar son ambiguos, puede hacer que los desarrollos puedan ampliarse, en consecuencia, los desarrolladores puedan perder el control de la entrega. Entre más detallado sea, habrá mayor control del desarrollo a realizar, además, puede originar en nuevos elementos para el Product Backlog.Cada desarrollador trabaja varios elementos a la vez. Trabajar varios temas a la vez no es la mejor estrategia, lo que hace es atrasar las entregas, puede que estén en varias cosas a la vez, pero no lo terminan.Resistencia al cambio por parte de los usuarios o del equipo. Aplicar Scrum no es fácil porque rompe paradigmas establecidos en las organizaciones, habrá resistencia al cambio, por ello, es necesario trabajar con las personas para que puedan aprovechar al máximo Scrum.

La lista puede seguir, a situaciones complejas e inciertas, aparecerán impedimentos que probablemente no nos habríamos imaginado. El Scrum Master debe ayudar al equipo a definir un plan para eliminar los impedimentos, y facilitar la comunicación con los interesados (personas que son afectados o que pueden afectar al proyecto) y otros equipos. El objetivo es que el equipo pueda trabajar de forma eficiente y alcanzar el objetivo del Sprint con calidad.

Acerca del autor:

Jorge Paz es Coach, Consultor y autor de los libros «Creando valor con proyectos ágiles» y «Transforma la incertidumbre en oportunidades «. Con más de 10 años en la gestión de proyectos. Ha trabajado en proyectos en varios países de Latinoamérica apoyando a equipos de proyectos en alcanzar sus objetivos.

Imagen: Creador de imágenes de Bing

 

 

The post Anatomía de impedimentos en Scrum first appeared on Jorge Paz.

8 Factores de éxito en un proyecto ágil

¿Te ha pasado que tienes problemas en obtener resultados en un proyecto ágil y no sabes porque sucede si estas siguiendo al pie de la letra lo que indica el marco de trabajo que estás utilizando? Si deseas saber algunas razones del porque fallan, sigue leyendo y lo sabrás.

Algunos creen que el utilizar un enfoque ágil es simplemente utilizarlo como una receta y esperar que dé resultados, he escuchado que es más simple que el enfoque tradicional como tener menor documentación, no hay jefes o no establecer una planificación desde el inicio el proyecto. Creen que estas características de por sí son las causas del fracaso de éste enfoque. Ojalá que así fuera de sencillo, tengo la duda si lo dicen como una manera de vender el enfoque ágil o sencillamente no saben el trabajo que implica, es más, requiere más esfuerzo y conocimiento este tipo de enfoque, ya te explicaré porqué.

Factores que debes tomar en cuenta

Todo proyecto es único debido al contexto de este. Sin embargo, algunos factores que se necesita contemplar al trabajar en este tipo de proyecto son:

Incertidumbre del proyecto . Dependiendo el nivel de complejidad e incertidumbre del proyecto, se escogerá el enfoque más adecuado, si la complejidad y la incertidumbre es baja, se podría utilizar un enfoque tradicional para maximizar los recursos disponibles. Por el contrario, si no hay claridad a donde se quiere ir o la complejidad es muy alta y es necesario hacer cambios rápido, el enfoque ágil sería más apropiado para trabajarlo. Utilizar un enfoque para todo proyecto no importando su nivel de incertidumbre es un factor de fracaso porque no se aprovechará los recursos de la mejor manera. La práctica ágil involucra a todos los interesados . Algunos tienen la idea que solo los equipos deben ser ágiles y los demás siguen con sus prácticas habituales. Practicar la agilidad no es exclusivo de los equipos de proyecto, tiene que involucrar a la gerencia y demás interesados, este enfoque necesita de mayor interacción del equipo y los interesados. He visto como los usuarios al no tener claro este enfoque, esperan que su participación sea limitada y que desean un resultado al final del proyecto, es todo lo contario, por lo que se requiere que todos tengan claro cómo es el flujo de trabajo en este enfoque. Manejo del cambio . Utilizar un enfoque ágil requiere adaptarse a la situación que se encuentra, por lo que hace que los equipos tengan que adaptarse, muchas personas no quieren cambiar, desean hacer las cosas de la misma manera, este es un factor de hará la diferencia. He visto a equipos que sus miembros se han certificado el marco de trabajo que están utilizando, sin embargo, en el momento de una crisis, regresan a sus prácticas habituales porque creen que obtendrán resultados, sin embargo, ha causado desgaste en el equipo y pocos resultados. Es como si te dieran un auto, pero estás acostumbrado a manejar un bus escolar, por la costumbre no irás a alta velocidades y tengas que acostumbrarte la manera de manejarlo, llevará tiempo. Equipo adecuado a este tipo de enfoque . El que el enfoque ágil sea utilizado en proyectos con un alto nivel de incertidumbre, debe ser una llamada de atención para las personas que tienen la decisión de crear al equipo. Se requiere de personas con un conocimiento de negocio y técnico, sean multifuncional y autogestionados ¿por qué? Este enfoque requiere que se haga entregas parciales de semanas y no de meses o años, es necesario que el equipo se adapte a nuevas situaciones en cualquier momento y tome decisiones, esto es más difícil con personas recién contratadas o que no puedan autogestionarse, no obtendrán un resultado inmediato. Escucho a gerentes decir que se espera que el resultado de estos equipos sin experiencia o falte de autogestión darán resultados a mediano y largo plazo, a ello les digo, que su lógica es válida en un enfoque tradicional donde entregan valor en medio año o más, sin embargo, ¡es necesario dar resultados en semanas! Tener claro que significa no tener jefes . En Scrum (por ejemplo) no hay jerarquías, hay un Equipo Scrum conformado de Product Owner, Scrum Master y de desarrolladores, algunos se ponen felices por no tener jefes, sin embargo, no se dan cuenta que esto significa que todo el equipo es responsable del resultado y no un individuo en particular. Para algunos, no les gustará esta situación, en especial si les gusta sobresalir o no les gusta trabajar en equipo, pudiendo generar problemas de coordinación y búsqueda de alguien que les diga que hacer para disminuir su responsabilidad. Un equipo autogestionado mitiga esta situación, es por ello que las personas que conforman el equipo tengan características de negocio, técnica y autogestión.Mantener el flujo de trabajo
en movimiento. Al definir un flujo de trabajo, es esencial que no se detenga, por ejemplo, en Scrum, el flujo se divide en Sprint, el cual se define que dura un par de semanas, significa que el siguiente Sprint inicia cuando termina el primero y así sucesivamente. Si hay trabajo en el primer Sprint que no se terminó, se evalúa si se trabajará en un futuro, de esa manera los Sprints, siguen su flujo para entregar valor. Ahora bien, que pasa si esto no ocurre, por ejemplo, si el primer Sprint se extiende por diversas causas (problemas de infraestructura, mala calidad, etc.), esto puede generar que los demás Sprints se atrasen, hay equipos que, al evitar esta situación, los trabajan en paralelo, perdiendo el control de los entregables y complicando más la gestión de éstos.Comunicación
efectiva. Este tipo de proyectos donde se entrega valor de manera continua, requiere que los integrantes del equipo conozcan que hacen sus compañeros para tomar decisiones lo más pronto posible, obligando a que las reuniones sean eficientes para poder entregar a tiempo. No ayuda tener reuniones maratónicas para conocer el estado del proyecto o resolver un problema, es todo lo contrario, se vuelve un problema. Calidad . Se cree que al entregar en poco tiempo es sinónimo de mala calidad, sin embargo, para que esto no ocurra, es necesario mejorar algunas prácticas como el desarrollo, testing o refactorización. Esto mueve al equipo a mejorar los estándares de calidad, utilización de herramientas de automatización de código, mejoras en la inspección del producto, etc.

Hay más factores que influyen en el éxito de un proyecto, sin embargo, no hay una receta para ello por el simple hecho que este tipo de proyectos la incertidumbre es alta, por lo que siempre estará la situación de utilizar nuevas prácticas para resolver los impedimentos del proyecto.

 

Acerca del autor:

Jorge Paz es Coach, Consultor y autor de los libros «Creando valor con proyectos ágiles» y «Transforma la incertidumbre en oportunidades «. Con más de 10 años en la gestión de proyectos. Ha trabajado en proyectos en varios países de Latinoamérica apoyando a equipos de proyectos en alcanzar sus objetivos.

 

Imagen: Creador de imágenes de Bing

 

The post 8 Factores de éxito en un proyecto ágil first appeared on Jorge Paz.

¿ La multitarea funciona en los proyectos?

¿Es más productivo abordar varias tareas al mismo tiempo o enfocarse en uno hasta terminarlo? Son preguntas que muchos se hacen cuando están en proyectos porque no ven que terminan algo y ya están trabajando en otro tema. Si deseas saber cómo impacta la productividad la multitarea, sigue leyendo.

La multitarea se refiere a realizar varias actividades a la vez, es decir, toma la primera tarea, realiza ciertas actividades de ella (sin terminarla) y luego sigue con la siguiente tarea, esto da una sensación que están en todos los temas y puede dar tranquilidad a otras personas. Por ejemplo, contestar el teléfono, redactar un correo, atender a una persona o asistir a una reunión virtual, se puede creer que está en todo.

Un equipo que hace varios temas a la vez, pueden aumentar sus habilidades para adaptarse a situaciones imprevistas, los hace más creativos, la comunicación es alta para intercambiar opiniones, a priori, se desearía que todos los equipos fueran así. Incluso, en algunas organizaciones, asocian a las personas que están realizando varios temas a la vez como las más productivas y consideran imprescindible que un equipo tenga estas características. Puedes pensar que la duda está resuelta, los equipos que realizan multitarea son mejores, sin embargo…sigue leyendo, hay que ver la otra cara de la moneda.

Veamos un ejemplo de trabajar varias asignaciones a la vez, supongamos que tenemos 3, cada una de ellas tiene tareas, asumamos que hacen las tareas 11,21 y 31 al mismo tiempo, luego de terminarlas, se hacen las tareas 12,22 y 32, luego las tareas 12,23 y 33, por último, se hacen las tareas 1,4 ,2.4 y 3.4

En total les llevó 33 horas, es decir que los 3 temas terminaron (al mismo tiempo) en 4 días, ¿será que pudieron terminar antes utilizando otra manera de resolverlos? En algunas situaciones, el tema 1 puede que ya no sea de utilidad en el cuarto día, era necesario entregarlo como máximo en los 2 primeros días, ahora tocará realizar algún plan de acción para remediar esta situación.

Trabajar al mismo tiempo es un mito

Si bien se puede trabajar varios temas «al mismo tiempo», no es sinónimo que se entregue antes, lo más probable es que se tarde más, esto no puede ser lo mejor para algunos proyectos. Hay que preguntarse lo siguiente: ¿será que nuestro cerebro puede trabajar varios temas a la vez?

Según diversos estudios, el cerebro humano no está diseñado para procesar más de una información compleja al mismo tiempo, en el ejemplo anterior, contestar una llamada, escribir un correo o atender a una persona (que no traten un asunto crítico) no le lleve mucho esfuerzo por lo que lo podrá hacer sin problema.

Cuando intentamos hacer multitarea, lo que hacemos en realidad es cambiar rápidamente nuestra atención de una tarea(compleja) a otra, lo que genera estrés, fatiga mental y pérdida de concentración. Hacer varias cosas a la vez, tiene el efecto que nos distraemos rápidamente, puede pasar que las personas que dirigen un proyecto, tengan problemas en enfocarse en un solo tema, por lo que ven normal asignar al equipo varios temas sin pensar en el impacto que tendrán en ellos.

¿Qué efectos tiene el trabajar varios temas a la vez?

En mi experiencia, he notado que la multitarea si bien es atractiva para las personas que gestionan el proyecto porque quieren que se trabaje todo lo que piden, puede ocurrir varias situaciones en especial si la duración de éste es de meses o años:

Pierden el objetivo a largo plazo, al hacer varios temas, puede ser un signo de improvisación, si bien es cierto que en hay situaciones que se salen de control, una cosa es que haya picos de trabajo a que todo el tiempo estén improvisando, esto es un síntoma de falta de planificación (no importa que enfoque de desarrollo estén trabajando).El equipo se agota, al inicio pueden trabajar fuera de horario (ver punto anterior), sin embargo, con el paso del tiempo, las personas se cansan e incluso, pueden llegar a enfermarse (presión alta, estrés, etc.).El rendimiento disminuye, pueden iniciar con la mejor actitud y utilizar sus habilidades para trabajar varios temas a la vez. Imagina si es la primera vez que diriges un proyecto, quieres dar una buena impresión trabajando fuera de horario. Pero la realidad es otra, al incrementar las tareas a trabajar al mismo tiempo, estas habilidades ya no son utilizadas de la mejor manera, ya no lo ven como una fortaleza sino como la causante de su bajo rendimiento.El equipo comienza a distraerse en actividades que no agregan valor, las reuniones es un ejemplo, son llamados a una reunión para que estén enterados de algún tema que estén involucrados, cuando se dan cuenta, la mayor parte del tiempo están atendiendo reuniones y su rendimiento disminuye.Se atrasan en sus compromisos, puede que no se den cuenta que una causa sea que no están enfocados en terminar un tema, por lo que ya se vuelve habitual el que estén siendo reactivos en resolver problemas.La calidad disminuye, al hacer varios temas al mismo tiempo, muchos de estos tienen fechas a corto plazo, por lo que, para llegar a cumplirlas, lo común (no quiere decir que sea correcto) es sacrificar la calidad de su trabajo, la transparencia en el equipo disminuye, creen que más adelante podrán corregirlo, el resultado es que el beneficiario del proyecto se da cuenta y exige correcciones.Todos estos temas, se vuelven cíclicos, el equipo no sabe cuándo acabará.¿La monotarea es la solución?

Por el contrario, la monotarea consiste en enfocarse en una sola actividad a la vez, dedicando toda la atención y los recursos a ella hasta completarla. Veamos el ejemplo anterior, hay 3 tareas, al terminarlas secuencialmente, se pueden utilizarse en menos tiempo:

Si bien no da la impresión que están trabajando los 3 temas al mismo tiempo, si se verá los resultados a corto plazo en cada uno de ellos. Es como en un restaurante de comida rápida, si hay 8 órdenes y sólo una persona despacha, normalmente se trabaja una orden a la vez, las demás esperan su turno, imagina que hacen lo contrario(multitarea), que hicieran todo al mismo tiempo, ponen las 8 bandejas, colocan primero las papas de cada orden, luego la hamburguesa u otro producto y por último la bebida (gaseosa, café, té, etc.), algunas ordenes pueden que sean simples, tardaran en entregarse y el cliente estaría insatisfecho.

La monotarea tiene varios beneficios:

Da más oportunidad de terminar las tareas antes porque no hay distractores, es decir, la gente se enfoca en una actividad a la vez.Las actividades de calidad pueden realizarse según se ha planificado, se puede mejorar el tiempo de solución.Hay más control de entregar las tareas a tiempo, el estrés y la ansiedad disminuyen.

Entonces, ¿significa que la solución a nuestros problemas? No es así de literal, las ventajas descritas de la multitarea no necesariamente son las fortalezas en la monotarea, dependiendo del contexto de la situación, se requiere que el equipo pueda adaptarse rápidamente a los cambios, haya creatividad o colaboración, y la monotarea puede dar la impresión de no avanzar como se desea.

Entonces, ¿qué es mejor para los equipos, trabajar varios temas a la vez o uno a la vez? La respuesta dependerá de varios factores como:

La naturaleza de la tarea, si requieren mucha concentración, nivel de incertidumbre, complejidad de la tarea, dependencia de otros equipos o tareas, etc.La capacidad de las personas de trabajar como equipo, puede ser que el equipo está recién formado y no se conocen entre ellos, son multifuncionales, se autogestionan, etc.Enfoque de desarrollo que se utilice en los proyectos, por ejemplo, predictivo, ágil, iterativo, etc.

Por lo tanto, lo ideal es que cada equipo encuentre su propio equilibrio entre la monotarea y la multitarea, adaptándose a las características de cada tarea. Algunos temas que te pueden ayudar a equilibrar entre los dos son:

Identifica que personas que hacen una solicitud, no es lo mismo atender una solicitud del gerente general y atender al mismo tiempo una solicitud de alguien que no tiene un alto cargo, el manejo de los interesados es importante.Administrar con eficacia las actividades, identifica que tareas son prioridades o urgentes, en el libro forjando nuestro destino, menciono varias técnicas de cómo gestionarlo.Manejar la incertidumbre como equipo, hay que adaptarse a los cambios, saber cómo manejar la ansiedad ante nuevas circunstancias para luego priorizarlos, hace que se tenga mayor claridad que trabajos hay que hacer primero.Al tener ordenado las tareas a realizar, puedes identificar que tareas son de baja complejidad (no significa que sean de poca urgencia o no sean importantes), el siguiente paso será evaluar si es factible hacerlos al mismo tiempo. Las que sean de alta complejidad, se podría hacer una a la vez.Planifica que trabajos se harán en el día, disminuir la participación de reuniones que no agreguen valor.Si estás desarrollando un producto, identifica el flujo de trabajo de las tareas, es decir, definir cuando inicia y cuando finaliza, al no definirlo, puede hacer que el equipo termine las tareas sin terminar el flujo, haciendo que el equipo tenga que regresar a finalizar las tareas que habían indicado como terminado, generando retrabajo.Trabajar en la mejora continua, determinar que se puede mejorar para hacer ajustes en las actividades diarias, también se puede detectar buenas prácticas para seguir aplicándolas

Siguiendo estos consejos podrás aprovechar mejor tu tiempo y mejorar tu rendimiento. Recuerda: menos, es más.

Acerca del autor:

Jorge Paz es Coach, Consultor y autor de los libros «Creando valor con proyectos ágiles» y «Transforma la incertidumbre en oportunidades «. Con más de 10 años en la gestión de proyectos. Ha trabajado en proyectos en varios países de Latinoamérica apoyando a equipos de proyectos en alcanzar sus objetivos.

The post ¿ La multitarea funciona en los proyectos? first appeared on Jorge Paz.

¿Mejora la productividad la multitarea en los equipos de proyecto?

¿Es más productivo abordar varias tareas al mismo tiempo o enfocarse en uno hasta terminarlo? Son preguntas que muchos se hacen cuando están en proyectos porque no ven que terminan algo y ya están trabajando en otro tema. Si deseas saber cómo impacta la productividad la multitarea, sigue leyendo.

La multitarea se refiere a realizar varias actividades a la vez, es decir, toma la primera tarea, realiza ciertas actividades de ella (sin terminarla) y luego sigue con la siguiente tarea, esto da una sensación que están en todos los temas y puede dar tranquilidad a otras personas. Por ejemplo, contestar el teléfono, redactar un correo, atender a una persona o asistir a una reunión virtual, se puede creer que está en todo. Un equipo que hace varios temas a la vez, pueden aumentar sus habilidades para adaptarse a situaciones imprevistas, los hace más creativos, la comunicación es alta para intercambiar opiniones, a priori, se desearía que todos los equipos fueran así, incluso, en algunas organizaciones, asocian a las personas que están realizando varios temas a la vez como las más productivas y consideran imprescindible que un equipo tenga estas características. Puedes pensar que la duda está resuelta, los equipos que realizan multitarea son mejores, sin embargo…sigue leyendo, hay que ver la otra cara de la moneda. Veamos un ejemplo de trabajar varias asignaciones a la vez, supongamos que tenemos 3, cada una de ellas tiene tareas, asumamos que hacen las tareas 11,21 y 31 al mismo tiempo, luego de terminarlas, se hacen las tareas 12,22 y 32, luego las tareas 12,23 y 33, por último, se hacen las tareas 1,4 ,2.4 y 3.4

En total les llevó 33 horas, es decir que los 3 temas terminaron (al mismo tiempo) en 4 días, ¿será que pudieron terminar antes utilizando otra manera de resolverlos? En algunas situaciones, el tema 1 puede que ya no sea de utilidad en el cuarto día, era necesario entregarlo como máximo en los 2 primeros días, ahora tocará realizar algún plan de acción para remediar esta situación. Si bien se puede trabajar varios temas «al mismo tiempo», no es sinónimo que se entregue antes, lo más probable es que se tarde más, esto no puede ser lo mejor para algunos proyectos. Hay que preguntarse lo siguiente: ¿será que nuestro cerebro puede trabajar varios temas a la vez? Según diversos estudios, el cerebro humano no está diseñado para procesar más de una información compleja al mismo tiempo, en el ejemplo anterior, contestar una llamada, escribir un correo o atender a una persona (que no traten un asunto crítico) no le lleve mucho esfuerzo por lo que lo podrá hacer sin problema. Cuando intentamos hacer multitarea, lo que hacemos en realidad es cambiar rápidamente nuestra atención de una tarea(compleja) a otra, lo que genera estrés, fatiga mental y pérdida de concentración. El hacer varias cosas a la vez, tiene el efecto que nos distraemos rápidamente, puede pasar que las personas que dirigen un proyecto, tengan problemas en enfocarse en un solo tema, por lo que ven normal asignar al equipo varios temas sin pensar en el impacto que tendrán en ellos. En mi experiencia, he notado que la multitarea si bien es atractiva para las personas que gestionan el proyecto porque quieren que se trabaje todo lo que piden, puede ocurrir varias situaciones en especial si la duración de éste es de meses o años:

Pierden el objetivo a largo plazo, al hacer varios temas, puede ser un signo de improvisación, si bien es cierto que en hay situaciones que se salen de control, una cosa es que haya picos de trabajo a que todo el tiempo estén improvisando, esto es un síntoma de falta de planificación (no importa que enfoque de desarrollo estén trabajando).El equipo se agota, al inicio pueden trabajar fuera de horario (ver punto anterior), sin embargo, con el paso del tiempo, las personas se cansan e incluso, pueden llegar a enfermarse (presión alta, estrés, etc.).El rendimiento disminuye, pueden iniciar con la mejor actitud y utilizar sus habilidades para trabajar varios temas a la vez. Imagina si es la primera vez que diriges un proyecto, quieres dar una buena impresión trabajando fuera de horario. Pero la realidad es otra, al incrementar las tareas a trabajar al mismo tiempo, estas habilidades ya no son utilizadas de la mejor manera, ya no lo ven como una fortaleza sino como la causante de su bajo rendimiento.El equipo comienza a distraerse en actividades que no agregan valor, las reuniones es un ejemplo, son llamados a una reunión para que estén enterados de algún tema que estén involucrados, cuando se dan cuenta, la mayor parte del tiempo están atendiendo reuniones y su rendimiento disminuye.Se atrasan en sus compromisos, puede que no se den cuenta que una causa sea que no están enfocados en terminar un tema, por lo que ya se vuelve habitual el que estén siendo reactivos en resolver problemas.La calidad disminuye, al hacer varios temas al mismo tiempo, muchos de estos tienen fechas a corto plazo, por lo que, para llegar a cumplirlas, lo común (no quiere decir que sea correcto) es sacrificar la calidad de su trabajo, la transparencia en el equipo disminuye, creen que más adelante podrán corregirlo, el resultado es que el beneficiario del proyecto se da cuenta y exige correcciones.Todos estos temas, se vuelven cíclicos, el equipo no sabe cuándo acabará.¿La monotarea es la solución?

Por el contrario, la monotarea consiste en enfocarse en una sola actividad a la vez, dedicando toda la atención y los recursos a ella hasta completarla. Veamos el ejemplo anterior, hay 3 tareas, al terminarlas secuencialmente, se pueden utilizarse en menos tiempo:

Si bien no da la impresión que están trabajando los 3 temas al mismo tiempo, si se verá los resultados a corto plazo en cada uno de ellos. Es como en un restaurante de comida rápida, si hay 8 órdenes y sólo una persona despacha, normalmente se trabaja una orden a la vez, las demás esperan su turno, imagina que hacen lo contrario(multitarea), que hicieran todo al mismo tiempo, ponen las 8 bandejas, colocan primero las papas de cada orden, luego la hamburguesa u otro producto y por último la bebida (gaseosa, café, té, etc.), algunas ordenes pueden que sean simples, tardaran en entregarse y el cliente estaría insatisfecho.

La monotarea tiene varios beneficios:

Da más oportunidad de terminar las tareas antes porque no hay distractores, es decir, la gente se enfoca en una actividad a la vez.Las actividades de calidad pueden realizarse según se ha planificado, se puede mejorar el tiempo de solución.Hay más control de entregar las tareas a tiempo, el estrés y la ansiedad disminuyen.

Entonces, ¿significa que la solución a nuestros problemas? No es así de literal, las ventajas descritas de la multitarea no necesariamente son las fortalezas en la monotarea, dependiendo del contexto de la situación, se requiere que el equipo pueda adaptarse rápidamente a los cambios, haya creatividad o colaboración, y la monotarea puede dar la impresión de no avanzar como se desea.

Entonces, ¿qué es mejor para los equipos, trabajar varios temas a la vez o uno a la vez? La respuesta dependerá de varios factores como:

La naturaleza de la tarea, si requieren mucha concentración, nivel de incertidumbre, complejidad de la tarea, dependencia de otros equipos o tareas, etc.La capacidad de las personas de trabajar como equipo, puede ser que el equipo está recién formado y no se conocen entre ellos, son multifuncionales, se autogestionan, etc.Enfoque de desarrollo que se utilice en los proyectos, por ejemplo, predictivo, ágil, iterativo, etc.

Por lo tanto, lo ideal es que cada equipo encuentre su propio equilibrio entre la monotarea y la multitarea, adaptándose a las características de cada tarea. Algunos temas que te pueden ayudar a equilibrar entre los dos son:

Identifica que personas que hacen una solicitud, no es lo mismo atender una solicitud del gerente general y atender al mismo tiempo una solicitud de alguien que no tiene un alto cargo, el manejo de los interesados es importante.Administrar con eficacia las actividades, identifica que tareas son prioridades o urgentes, en el libro forjando nuestro destino, menciono varias técnicas de cómo gestionarlo.Manejar la incertidumbre como equipo, hay que adaptarse a los cambios, saber cómo manejar la ansiedad ante nuevas circunstancias para luego priorizarlos, hace que se tenga mayor claridad que trabajos hay que hacer primero.Al tener ordenado las tareas a realizar, puedes identificar que tareas son de baja complejidad (no significa que sean de poca urgencia o no sean importantes), el siguiente paso será evaluar si es factible hacerlos al mismo tiempo. Las que sean de alta complejidad, se podría hacer una a la vez.Planifica que trabajos se harán en el día, disminuir la participación de reuniones que no agreguen valor.Si estás desarrollando un producto, identifica el flujo de trabajo de las tareas, es decir, definir cuando inicia y cuando finaliza, al no definirlo, puede hacer que el equipo termine las tareas sin terminar el flujo, haciendo que el equipo tenga que regresar a finalizar las tareas que habían indicado como terminado, generando retrabajo.Trabajar en la mejora continua, determinar que se puede mejorar para hacer ajustes en las actividades diarias, también se puede detectar buenas prácticas para seguir aplicándolas

 

Siguiendo estos consejos podrás aprovechar mejor tu tiempo y mejorar tu rendimiento. Recuerda: menos, es más.

Acerca del autor:

 

Jorge Paz es Coach, Consultor y autor de los libros «Creando valor con proyectos ágiles» y «Transforma la incertidumbre en oportunidades «. Con más de 10 años en la gestión de proyectos. Ha trabajado en proyectos en varios países de Latinoamérica apoyando a equipos de proyectos en alcanzar sus objetivos.

 

The post ¿Mejora la productividad la multitarea en los equipos de proyecto? first appeared on Jorge Paz.

¿Producto y proyectos son incompatibles?

Hace unas semanas encontré un artículo en la que comparaba la gestión de productos y la gestión de proyectos (mencionan a Scrum contra predictivo), esto me pareció curioso, sin embargo, al leer el artículo, «casualmente» el navegador me comenzó a mostrar más artículos del tema y al parecer, varias personas creen que son dos enfoques diferentes para crear un producto. Si deseas saber si son incompatibles o no, te invito a seguir leyendo.

En estos artículos y en algunos videos, indican que la gestión de proyectos es una forma de crear un producto a través del enfoque predictivo, de por sí, se ha etiquetado que un proyecto es sinónimo de enfoque en predictivo (o cascada) y los productos pueden hacerse a través de otro enfoque como el ágil con el marco de trabajo Scrum. Algunos argumentan que cómo Scrum tiene un rol de Product Owner y está orientado a crear valor al usuario por medio de un producto que funciona en cada iteración, es otra manera de entregar un producto y no se necesita de un proyecto. Veamos algunos conceptos de varios términos que hemos utilizado hasta ahora.

Producto

La séptima edición del PMBOK del PMI (última edición al momento de escribir este artículo) dice que el producto es: «…un artefacto que es producido, es cuantificable y puede ser un elemento terminado en sí mismo o un componente de un elemento.» El producto puede ser uno o varios elementos que buscan valor al usuario final y que forman parte de una estrategia de una empresa a lo largo del tiempo. Hay productos que duran días porque al salir al mercado, ya está obsoleto (se dieron cuenta que la competencia tiene un producto con mejor tecnología) o productos que llevan más de 100 años en el mercado y son muy populares. En algunas empresas, tienen equipos enfocados a crear nuevos productos o mantener los existentes, con el fin de incrementar el valor al cliente y mejorar el retorno de inversión para la empresa, a esto se le puede llamar una gestión del producto.

Ciclo de vida del producto

Los productos tienen varias etapas a través del tiempo, estas son: introducción, crecimiento, madurez y declive.

La introducción tiene que ver con la creación del producto, concepción de marca, como se va a distribuir, establecer el precio, etc.La etapa de crecimiento se realiza actividades de mantenimiento de calidad, precios, mejoras en los canales de distribución, ampliación en la promoción del producto, etc.En la etapa de madurez, se realizan varias actividades de acuerdo al producto, se puede agregar otras características, mejoras en la producción del producto, mejoras o cambios de distribución del producto, etc.La etapa del declive puede ser por varios factores como ser un producto obsoleto en comparación a otros productos, el cliente ya no está interesado en adquirirlo, por lo que comienzan a tomar decisiones para reemplazarlo, buscarle otros usos o disminuir la producción paulatinamente.

En cada una de estas etapas, se realiza actividades que pueden ser temporales como la introducción y el declive que se tienen un objetivo a un plazo específico. Una vez el producto está en el mercado, surgen actividades que son operativas, es decir que no son temporales, como el servicio al cliente, mantenimiento del producto, incrementar las ventas, etc.

Enfoque ágil, Scrum y el producto

El enfoque ágil es una series de valores y principios que se enfocan en crear un producto en base a la adaptación del entorno, interacción con el cliente y entregar un producto que funciona a corto plazo. Hay varios marcos de trabajo que están alineados a estos valores y principios, uno de ellos es Scrum, que tiene artefactos, eventos y un equipo Scrum (conformado por desarrolladores, dueño de producto y Scrum Master) los cuales tienen como fin crear valor al usuario final a través de Sprints. Utiliza una lista llamada Product Backlog que es una lista ordenada de necesidades que tiene como fin, alcanzar el objetivo del producto por lo que las actividades en Scrum orbitan alrededor de éste, puede ser que, por ello, muchas personas creen que trabajar en un producto es sinónimo de Scrum y que al tener Scrum, no necesitan hacer más, sin embargo, no es así. En la guía Scrum 2020 dice lo siguiente: «Scrum es un marco de trabajo liviano que ayuda a las personas, equipos y organizaciones a generar valor a través de soluciones adaptativas para problemas complejos«, con problemas complejos se puede decir que hay una alta incertidumbre y complejidad a lo que queremos dar solución, si lo asociamos a un producto, se podría decir, por ejemplo que es un producto que no tiene claridad en el alcance ya sea porque el mercado es muy dinámico o el usuario no tiene claro que necesita, obligando a trabajar en conocer nuevas prácticas(reemplazando a otras) u optimizando las que ya se manejan, si el alcance del producto está bien definido y no hay mayor complejidad en crearla, puede que sea mejor utilizar otro enfoque para optimizar el tiempo y recursos. Scrum es un marco de trabajo muy popular en los últimos años por su simplicidad, sin embargo, el aplicarlo no es tan sencillo, porque no es una metodología.

Ambigüedad de Scrum

Recuerdo haber visto un video hace años sobre una capacitación de Scrum, el expositor preguntó a la audiencia qué es lo que más le llamaba la atención o que les gustaba de Scrum, un joven se levantó y dijo que estaba emocionado porque en el equipo Scrum no había jerarquías, todos podían opinar, el resto de la audiencia lo aclamaron. Lo que no dijeron en esa capacitación es que la responsabilidad de crear valor recae al equipo y no al individuo, ya no hay jefe a quien culpar, sino que la responsabilidad recae a todos, esto significa que tienen que trabajar en la auto gestión como equipo y no como individuos, pudiendo llevar una complejidad para realizarlo porque hay una dependencia de cada miembro del equipo. Sobre este tema, la guía dice lo siguiente: «El marco de trabajo Scrum es incompleto de manera intencional, solo define las partes necesarias para implementar la teoría de Scrum. Scrum se basa en la inteligencia colectiva de las personas que lo utilizan. En lugar de proporcionar a las personas instrucciones detalladas, las reglas de Scrum guían sus relaciones e interacciones«. Esta explicación tiene sentido, si vamos a trabajar en situaciones complejas, significa que no tenemos certeza de varios temas como el alcance, procesos, técnicas o prácticas, por ejemplo:

Crear un producto con tecnología que no existe hoy en día.Mejora en la calidad de un producto, significa que hay que replantearse si lo que estamos haciendo hoy en día es lo mejor.El cliente no sabe lo que necesita por lo que es necesario aprender nuevas técnicas para obtener el alcance o para interactuar con el cliente.

Los motivos para crear un producto pueden ser varias (oportunidad, necesidad, etc.) y también es importante conocer de dónde se origina la iniciativa, por ejemplo, puede ser una decisión corporativa (implementar un producto en varios países), de la gerencia, del departamento del producto o de otro departamento como el informático (IT), en ocasiones simplemente con solicitar a este departamento (IT) una necesidad (de menor tamaño), se dedican a trabajarlo y aplican Scrum sin mucho trámite (he participado en este tipo de desarrollos). Sin embargo, cuando se necesita un sistema de mayor tamaño que involucre varios departamentos, puede que se necesite hacer un análisis de la viabilidad de la creación del producto como el Retorno de Inversión(ROI), contratación de personal, compra de equipo, manejo del presupuesto, del riesgo, etc. Esto son actividades que, si bien no los va a utilizar el usuario final, son necesarios para crear el producto, es aquí donde comenzamos a hablar del proyecto.

Que es el proyecto

La séptima edición del PMBOK define al proyecto como: «Esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único. La naturaleza temporal de los proyectos indica un principio y un final para el trabajo del proyecto o una fase del trabajo del proyecto«. Con temporal, quiere decir que es un esfuerzo que tiene un final (puede ser de años), por ejemplo, al momento de crear un producto (etapa de introducción), ese producto que va al cliente tiene un objetivo, para ello necesita un presupuesto y una fecha límite, este es un tema de confusión de muchas personas, creen que no tener un alcance definido del producto, significa que no hay fin porque no se sabe cuándo van a terminar, pero no es así de literal, por ejemplo, si contrato a una persona a construir mi casa, esa construcción debe terminar en algún momento, porque quiero utilizar la casa, tengo una fecha límite para trasladarme a esa casa o porque tengo un presupuesto limitado. En una empresa pasa lo mismo, aunque no tenga claro el alcance del producto, se tiene una fecha límite y un presupuesto, esto define el producto que pueda tener al llegar la fecha límite o se haya agotado el presupuesto. El proyecto tiene un alcance, que incluye al producto en sí y todas las actividades que se necesitan para finaliza este producto, ahora bien, si se contrata a una empresa para que se encargue del proyecto o parte de ella, también hay que gestionarlo, esto es parte del alcance del proyecto y no del producto.

Los enfoques en los proyectos

Los proyectos utilizan diferentes tipos de enfoques para trabajar un producto, el que ha sido popular por muchos años ha sido el predictivo (o cascada), el cual, de manera errónea se cree que un proyecto solo tiene esta forma de trabajar, es por ello que varios de estos artículos asumen que trabajar en un proyecto significa que solo en este enfoque se puede utilizar. El mundo actual sufre cambios constantes, en la tecnología, el mercado, la política, etc. Esto hace que surjan nuevas formas de construir un producto, servicio o resultado, algunos de estos enfoques son el predictivo, el incremental, el iterativo o el ágil. Se utiliza el enfoque más adecuado para crear valor en los proyectos, dependerá del contexto del proyecto. Esto significa que se puede utilizar un enfoque ágil para crear un producto, implica que se utilizará un marco de trabajo que esté alineado a este enfoque como Scrum, SAFE, XP, Crystal, etc. Esto quiere decir que los proyectos y productos son compatibles, recordemos, el alcance del proyecto incluye el alcance del producto y el alcance de las actividades que ayudan a alcanzar ese objetivo (equipo, contratación de personal, riesgo, etc.), ahora bien, al utilizar Scrum para crear el producto, ¿las actividades que me ayudan a alcanzar el objetivo del producto, son las mismas que utilizaría en el enfoque predictivo? La respuesta seria que sufren cambios algunas de ellas, ¿porque? Esto es porque en Scrum (por ejemplo) hay varias entregas a lo largo del proyecto, por lo que los presupuestos deben reflejar esta situación, los riesgos se evidencian para un Sprint y pueden no existir para el siguiente, la resistencia al cambio se evidencia en cada entrega, esto hace que estas actividades se manejen de diferente forma. Si deseas saber más sobre los proyectos ágiles, te invito a leer el libro Creando valor con proyectos ágiles.

En conclusión, los productos y los proyectos no son incompatibles, es todo lo contario, el producto tiene varias fases a través del tiempo (introducción, crecimiento, maduración y declive) , esto requiere actividades temporales para alcanzar ciertos objetivos, como la creación del producto. Estas actividades temporales se manejan a través de proyectos que pueden utilizar varios enfoques para crearlos, entre ellos el enfoque ágil que tiene asociado varios marcos de trabajo como Scrum para desarrollarlo.

 

Referencia:

PMBOK Guide | Project Management Institute (pmi.org)

Guia Scrum 2020

Creando valor con proyectos ágiles: Cambia de la rigidez a la agilidad

 

Acerca del autor:

Jorge Paz es Coach, Consultor y autor de los libros «Creando valor con proyectos ágiles» y «Transforma la incertidumbre en oportunidades «. Con más de 10 años en la gestión de proyectos. Ha trabajado en proyectos en varios países de Latinoamérica apoyando a equipos de proyectos en alcanzar sus objetivos.

Los efectos de no contar con un Scrum Master en un equipo Scrum

¿Qué pasaría si te dijera que en algunos equipos que están iniciando Scrum creen que pueden hacerlo sin un Scrum Master? ¿Qué crees que pasaría? ¿Te ha pasado? Si de cajón piensas que la probabilidad de éxito disminuye considerablemente, estás en lo correcto, sin embargo, ¿qué pasa si experimentas esta situación? ¿sabes qué hacer? si quieres saber más, sigue leyendo.

¿Por qué ocurre eso?

La respuesta que se nos viene en mente es porque el equipo no conoce la guía Scrum, el cual se resuelve con que el equipo lo lea y mejor si se certifica. Esta puede ser una respuesta obvia, sin embargo, hay algunos factores que intervienen en la causa de este dilema, por ejemplo, que pasa si los equipos tienen experiencia en proyectos tradicionales, ¿será suficiente ponerlos a leer la guía y que la apliquen? Puede que la solución no sea tan sencilla, dependerá de la resistencia al cambio de estas personas para adoptar Scrum, algunos no tendrán problemas en adoptarlo, mientras que otros si se resistirán y querrán aplicar prácticas tradicionales en un proyecto Scrum. Otra razón pueda ser que se asuma que el rol de un Scrum Master es equivalente a la de un gerente de proyecto, esto hace que autocráticamente (decisión de la gerencia) se asigne al gerente de proyecto con ese rol, pero en la práctica no lo ejerce, es decir, no ayuda al equipo a adoptar Scrum ni los ayuda a resolver impedimentos, puede que se ocupe en hacer lo que sabe, impactando negativamente en el desempeño del equipo. Otra razón es que el equipo no pudo encontrar a un Scrum Master y sus actividades la delegan en el Product Owner, por lo que el rendimiento de éste disminuye. En ocasiones, los proyectos arrancan sin un Scrum Master y no es una opción esperar a tenerlo.

¿Cuál son las consecuencias de no tener un Scrum Master?

Si el equipo está recién formado y no tiene experiencia en Scrum puede ocurrir varias situaciones, por ejemplo:

No tengan claro para que funciona la Daily, la Retrospectiva y la Review. En algunos casos, no sabrán como dirigirla, harán reuniones adicionales debido que no han podido cumplir los objetivos de estos eventos ni cumplir con las cajas de tiempo.La Sprint Planning se extiende más de la cuenta, no utilizan prácticas como Planning póker porque no la entienden y prefieren utilizar prácticas de enfoque tradicional.Tienen problemas en ordenar y refinar el Product Backlog para el Sprint actual, impactando en el desempeño de los desarrolladores.Los usuarios finales o algún interesado(gerencia) pueden estar incomodos con no tener un alcance definido y soliciten un compromiso por parte del equipo para los siguientes Sprints, haciendo que el equipo realice actividades (predictivas) adicionales y generan atraso en los Sprints. No hay un Scrum Master que ayude a los interesados a clarificar los conceptos de Scrum.Los Sprints no terminan, el equipo cree que si se comprometió a entregar 20 historias (por ejemplo), debe entregarlo si o si, esto puede hacer que los Sprints no terminen, y probablemente arranquen con el siguiente Sprint para no seguir atrasándose, ocasionando muchos problemas al equipo.Problemas de autogestión en el equipo, hace que se improvise en la gestión, como colocar a un jefe para organizarlos, si tienen suerte, este jefe será un líder y los ayudará a mejorar en tomar decisiones y como equipo, hacerse responsable del trabajo que hacen.El equipo no tiene claro el objetivo del Sprint, no sabe a dónde va, solo algunos tienen una idea, pero no la comunican al resto del equipo.El compromiso para terminar a tiempo puede no existir, no hay alguien que les ayude a tomar consciencia de acabar el trabajo.No utilizar las herramientas apropiadas como Burndown, flujo acumulado o tablero Kanban.

La lista puede seguir, cada proyecto es único, ya sea por el contexto del proyecto, la cultura de la organización, los interesados o los miembros del equipo que conforman el equipo Scrum.

¿Qué hacer?

La respuesta simple seria ¡colocar a un Scrum Master! pero ¿cómo hacerlo? en especial si el equipo está ocupado en resolver problemas con las herramientas que tiene o lo que sabe hacer mejor. Algunas sugerencias son:

Hablar con la persona que toma las decisiones gerenciales, puede ser el patrocinador, esto tiene que venir desde arriba, aunque es importante que el equipo sea consciente en la necesidad de un Scrum Master, puede llevar tiempo hacerles consciencia de ello y luego tendrán que ir a hablarlo con la gerencia, esto puede llevar mucho tiempo que no se tiene.Evidenciar el rendimiento del equipo o el tiempo que ocupa algún miembro del equipo Scrum (Product Owner o desarrolladores) en realizar las actividades del Scrum Master.Reforzar la necesidad de los roles del equipo Scrum, si se tomó la decisión que un Gerente de Proyecto es el equivalente a un Scrum Master, se puede demostrar con hechos (punto anterior) que esta estrategia está teniendo inconvenientes.Al contar con un Scrum Master, tendrá que trabajar en varios aspectos según sea la prioridad para ese equipo, por ejemplo:Asegurarse que el equipo aplique los eventos y artefactos de Scrum correctamente.Apoyar al equipo a tener claro el objetivo del Sprint.Apoyar al Product Owner para que el Product Backlog esté refinado lo necesario para que se pueda utilizar en el Sprint actual.Apoyar en la autogestión del equipo, esto puede llevar un tiempo.Ayudar al equipo a resolver impedimentos.Puede ser el mediador entre el Product Owner y los desarrolladores.

El rol de un Scrum Master es muy importante para que los equipos puedan adaptarse a los cambios en los proyectos y puedan tomar decisiones lo más pronto posible a través del coaching. Tener un equipo Scrum completo (Scrum Master, Product Owner y desarrolladores) mejora el rendimiento del equipo, no tenerlos generará bastantes inconvenientes para alcanzar el objetivo del proyecto. Si deseas saber más sobre la gestión de proyectos, te invito a leer el libro: «Creando valor con proyectos ágiles».

Otros artículos:

La autogestión en los equipos

¿Cómo aplicar la mejora continua en equipos agiles?

La transparencia en los proyectos agiles

Creando valor en los proyectos

Acerca del autor:

Jorge Paz es Coach, Consultor y autor de los libros «Creando valor con proyectos ágiles» y «Transforma la incertidumbre en oportunidades «. Con más de 10 años en la gestión de proyectos. Ha trabajado en proyectos en varios países de Latinoamérica apoyando a equipos de proyectos en alcanzar sus objetivos.

 

 

Creando valor con proyectos ágiles

El enfoque ágil es utilizado cada vez más en los proyectos, sin embargo, hay muchas dudas que surgen al momento de utilizarlo, el libro “Creando valor con proyectos ágiles”, describe varios componentes que se deben tomar en cuenta para crear valor en ellos.

La autogestión en los equipos

Lo equipos que trabajan la autogestión tienen un rendimiento mayor en comparación a los equipos que necesitan de un jefe para hacer su trabajo, si esto es la clave para obtener mejores resultados en equipo, ¿porque no se promueve la autogestión? ¿Qué se debe hacer para promoverla?

¿Qué es la autogestión?

Se refiere a los equipos que deciden que trabajar, como hacerlo, cuando hacerlo y son responsables de sus actividades. Es un concepto que se aplica en los equipos ágiles porque requieren tomar decisiones en un ambiente con alto incertidumbre para resolver un problema en poco tiempo y es más efectivo que el equipo decida cómo hacerlo en comparación de un jefe. ¿Es decir que ya no necesitan jefe? En algunas organizaciones es más fácil trabajar sin jefes que en otras. Veamos qué pasa cuando hay un jefe (yo he sido uno a lo largo de mi vida profesional), si el jefe decide que va a hacer cada uno de los miembros del equipo, la velocidad para obtener resultados está limitado en la capacidad del jefe en asignar el trabajo, explicarlo y capacitar al equipo, si se encuentra ocupado, no asigna el trabajo y puede que algún miembro del equipo no sea productivo. Recuerdo hace años, me pidieron que apoyara a un equipo que estaba teniendo problemas, el jefe de este equipo tenía a su cargo más de 10 personas, al visitarlo, me sorprendí al ver a su equipo hacer una cola para entrar a su oficina, le pregunté a uno de ellos si estaban regalando algo para yo hacer la cola también, esta persona se sonrió y me dijo que algunos tenían problemas y necesitaba instrucciones para resolverlos o que su jefe les asignara el trabajo. Esto hacia que su equipo saliera de la oficina a altas horas de la noche e impactaba en su rendimiento. He apoyado a otros equipos con jefes que se administran mejor y obtienen resultados, sin embargo, es más evidente que el rendimiento depende del jefe cuando se ausenta, el rendimiento del equipo puede cambiar para mejor o peor. Si la justificación a ello es por un buen liderazgo del jefe, ¡¡Bingo!! ¡Hemos llegado a un punto importante! ¿Qué hace un líder? Influencia a los demás para alcanzar un objetivo en común, ahora bien, ¿qué pasaría si el equipo con un objetivo claro comienza a trabajar en alcanzarlo ese objetivo en común, con autonomía y se hace responsable? El rendimiento es mayor, ¿porque? Se debe a que una persona al conocer el objetivo, no esperan a que les digan que hacer, son creativos, toman decisiones, esto es autogestión.

¿Porque se dificulta trabajar la autogestión?

Hace unos días, estaba leyendo un artículo sobre el «Índice de distancia al poder o IDP», en el artículo, define que es «es una variable que determina cuánto se valora o se respeta a la autoridad o al poder», entre más alto es el valor en un país, las personas tienen un alto respeto a la autoridad, es un tema cultural. Al ver el listado de los países con su IDP, me llamó la atención que algunos países europeos e Israel, tienen un IDP bajo, mientras que los países latinoamericanos tienen un IDP medio a alto. Esto me hizo sentido porque trabajo con equipos de Latinoamérica y veo que los equipos están acostumbrados a trabajar con un jefe, se sienten incómodos tomar decisiones, desean limitar su responsabilidad, a ello, se debe agregar el clima organizacional, aunque haya una persona proactiva y que desee tomar decisiones, puede ser limitado por su jefe. Ayudar al equipo a ser autónomos y responsables no es suficiente decirles «tomen sus propias decisiones y sean responsables», es necesario trabajar en sus creencias, cambiar sus hábitos de trabajo y mejorar en sus habilidades. Esto no es seguir una receta, ya que no genera un resultado inmediato, sino que es un proceso que pueda llevar tiempo.

¿Cómo puedo trabajar la autogestión?

Cada equipo tiene sus particularidades, algunos de estos temas que describen a continuación ya lo están practicando. Una forma simple de ver la autogestión en los equipos es si tienen a un jefe, si no lo tienen, se espera que el equipo está tomando sus propias decisiones y tienen un nivel de autogestión, en caso de tener un jefe, seria de determinar el nivel de dependencia que puedan tener hacia esta persona. Algunos aspectos a tomar en cuenta son:

Disminuir la influencia del jefe en el equipo. Entre menos influya en las decisiones del equipo, estará incentivando para que puedan tomar sus propias decisiones y que sean responsables de sus acciones. El jefe en lugar de decirles que hacer, puede preguntarles cómo, quienes y cuando lo harán.Tener un objetivo claro. Si el objetivo no está claro, el equipo no puede alinearse para tomar una decisión, es probable que cada miembro tome decisiones de acuerdo a su perspectiva de lo que sería lo mejor. Al tener un objetivo, el equipo debe tomar decisiones para alcanzar en ese objetivo y en una fecha establecida (si existiera).Transparencia. Los miembros deben mantener una comunicación constante con el equipo respecto a lo que pasa en sus actividades, en especial si tiene atrasos o problemas que les impide cumplir con un objetivo.Administrar las prioridades. Deben administrar como manejan su tiempo para alcanzar sus actividades, es decir, que actividades pueden dejar a un lado para realizar otras.Adaptación. Los cambios son comunes, la clave es como se reacciona a ellos. Las personas tienden a resistirse a realizar nuevas actividades, esto hace que ante una adversidad, los equipos tengan problemas en ponerse de acuerdo en cómo solucionarlo, entre más trabajen en adaptarse a los cambios, será más sencillo resolverlos.Mejora continua. Los equipos evolucionan con el tiempo, es mejor si se controla esta evolución a través de una mejora continua, permite establecer detectar aspectos a mejorar y definir acciones para optimizar las actividades que realizan.Desarrollo profesional en todo momento. Si hay miembros que solo ellos pueden realizar una actividad, limitan el rendimiento del equipo a esa persona, es mejor incentivar la capacitación para tener el conocimiento necesario (no experta) para realizar cualquier actividad, de esta manera, se puede delegar el trabajo a cualquier miembro.Resiliencia. Afrontar la adversidad es parte del trabajo de un equipo que se autogestiona, al no tener un jefe directo, los problemas deben resolverlos en equipo, esto hace que algunos miembros se desmotiven ante esta situación. Tener una mentalidad resiliente, hace posible ver oportunidades en medio de la crisis.

La autogestión tiene varios beneficios como la disminución (o eliminación) de procesos administrativos, fomenta el empoderamiento y las organizaciones tendrán personas con más iniciativa y organización.

 

Referencia:

http://www.kaosklub.com/indice-de-distancia-al-poder-y-la-seguridad-aerea

Acerca del autor:

 

Jorge Paz es Coach, Consultor y autor de los libros «Forjando Nuestro Destino» y «Transforma la incertidumbre en oportunidades «. Con más de 10 años en la gestión de proyectos. Ha trabajado en proyectos en varios países de Latinoamérica apoyando a equipos de proyectos en alcanzar sus objetivos.