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.
¿Cómo te irá en tu nuevo trabajo? (II)
¿Cómo te irá en tu nuevo trabajo?
En nuestro artículo de diciembre del 22, explicábamos que lo más importante de una oferta de trabajo es también lo más difícil de averiguar en una entrevista. La relación con tu nuevo jefe determinará el 70% de tu experiencia de empleado.
En el artículo de enero del 23, llegamos a la conclusión de que la mejor fuente de información sobre tu nuevo jefe son tus futuros compañeros, y explicamos qué preguntas hacerles. Lamentablemente no siempre vas a tener acceso a ellos.
En este artículo de febrero del 23, explicamos qué puedes preguntar durante una entrevista de trabajo a tu futuro responsable, para averiguar cómo será vuestra relación antes de estampar tu firma en el contrato.
¿Cuáles son las tres mejores preguntas que puedes hacer al líder del proyecto?
Vamos con las tres preguntas que, a nuestro entender, os aportarán mayor información, sin poner incómodo a vuestro futuro jefe.
1. ¿Qué funciones haces como líder del equipo?
Empezamos con una pregunta trampa, para dejarle que se luzca y que hable de si mismo.
Eres un profesional, solo quieres conocer el rol de tu nuevo jefe y la cultura de la organización.
Es el Product Owner
Si su respuesta es:
- Yo no soy un técnico, solo resuelvo las dudas funcionales de los consultores.
- Priorizo las actividades del sprint
Tu nuevo líder es un Product Owner. La empresa ha alcanzado un buen grado de madurez en metodologías ágiles y Scrum.
El cambio de trabajo es una apuesta segura.
Es el Jefe de Proyecto
Si responde algo así como:
- Me aseguro de que haya un buen ambiente de trabajo en el equipo.
- Negocio con el cliente para ajustar la carga de trabajo y que el equipo no se queme por exceso de horas extras.
Es un Jefe de Proyecto que tiene claras sus funciones.
Un buen comienzo de una nueva relación laboral.
Es el Líder Técnico
Si está orgulloso de decir:
- Explico a cada consultor qué es lo que tiene que hacer y cómo hacerlo.
- Superviso que están efectivamente haciendo aquello que les he pedido y les ayudo si están atascados.
Es un Líder Técnico. Su experiencia puede ayudarte a crecer profesionalmente, pero si nadie bloquea la presión del cliente, el proyecto tarde o temprano se transformará en un infierno.
Ten cuidado.
Es un Analista/Programador
Si tiene aspecto cansado y su respuesta es:
- Soy el consultor más veterano del grupo.
- Además de mi trabajo técnico, te ayudaré a irte poniendo en marcha.
Es un Analista/Programador. Esta figura es garantía de problemas.
Para empezar, tiene que elegir entre realizar su trabajo técnico y liderar al equipo. Haga lo que haga, el rendimiento general será bajo, así que la presión del cliente será elevada. Y no hay nadie para bloquearla.
Ten cuidado.
El rol del líder aporta mucha información sobre el grado de madurez de la organización.
2. ¿Qué KPIs utilizas para medir el desempeño?
Me encanta porque es una pregunta de aspecto inocente. Aparentemente quieres conocer los criterios que más valora porque quieres hacer un gran trabajo.
En realidad le estás preguntando por su cultura X (Fixed Mindset) vs Y (Growth Mindset).
Aquí no hay respuestas mejores o peores. Lo importante es conocerte a ti mismo, y que tu cultura sea compatible con la suya.
"No uso KPIs, intento motivar a mis consultores con formación y proyectos que son un desafío tecnológico"
Posiblemente estás hablando con un Líder Técnico con una cultura de tipo Y. En general todos los programadores también tienden a tener cultura Y.
Si tu también crees que al trabajador hay que motivarle todos los días mediante formación, desafíos tecnológicos, feedback positivo y un gran ambiente de trabajo, tu cultura es Y. Os llevaréis genial.
"Los KPIs que utilizo para medir el desempeño de los consultores son..." o "Los criterios para establecer nuestros bonus por objetivos son...".
Seguramente estás hablando con un Jefe de Proyecto de cultura X o Fixed Mindset.
Si tu también crees que los profesionales deben venir formados y motivados de casa, que el bonus por objetivos es la mejor forma de motivar a un consultor, y que al trabajo se viene a trabajar y no a tomar café, tu cultura también es X. Tendrás una buena relación profesional con él. A lo mejor hasta os hacéis amigos.
Recuerda, X no es mejor que Y. Lo importante es que tu cultura coincida con la del líder del proyecto.
3. ¿Cómo gestionáis los picos de trabajo?
Eres un profesional. Sabes que eventualmente habrá picos de trabajo por incidencias en planta o por deadlines. Forma parte de nuestra actividad y lo asumes. Solo quieres conocer cómo se gestionan esas situaciones.
Hay varias respuestas posibles, de nuevo de mejor a peor.
"Aquí no hay presión porque hacemos SCRUM. Las historias de usuario que no se completan durante el sprint, se devuelven al backlog"
Es posiblemente la mejor respuesta.
Tu nuevo jefe es un Product Owner. La organización tiene un elevado grado de madurez en la metodología Scrum y no comete los errores típicos de los principiantes.
Posiblemente te mostrará el tablero canvan con los epics e historias de usuario del backlog, y el progreso de las tareas en el sprint actual. Incluso es posible que te presente a tus futuros compañeros.
Un diez.
"Intento que no haya presión, pero de vez en cuando hay momentos de crisis. Entonces hablo con el equipo y ellos se organizan para solucionarlo".
Otra buena respuesta.
Estás ante un Jefe de Proyecto que entiende que su principal misión es bloquear la presión del cliente.
Pero eventualmente son necesarios esfuerzos puntuales. El hecho de que el equipo sea capaz de autogestionar estas situaciones indica que hay un buen ambiente de trabajo. Posiblemente se ha formado un equipo de alto rendimiento.
Un nueve alto.
"Hay bastante presión al final de cada sprint para acabar todas las historias de usuario planificadas"
La organización está haciendo la transición hacia metodologías ágiles.
Cometen los errores típicos del comienzo del proceso, pero eventualmente se convertirán en un buen sitio para trabajar.
Un seis.
"Cuando hay momentos de crisis, hablo con el equipo y les pido un sobreesfuerzo para lograr los objetivos".
Cuando exiges a todo un equipo un sobreesfuerzo, siempre hay alguien con hijos que no puede mantener el ritmo. El conflicto está servido. Adiós al ambiente de trabajo.
El liderazgo es débil y no consigue bloquear la presión del cliente. Es cuestión de tiempo que esos momentos de crisis se conviertan en el día a día.
Un cuatro y medio.
"Llevamos tres meses haciendo un sobreesfuerzo, por eso te contratamos"
Es sin duda la peor de las respuestas.
El proyecto acumula varios meses de retraso, el cliente está muy nervioso y el líder del proyecto no sabe como bloquear la presión. Posiblemente han entrado en una dinámica de lluvia ácida...
El líder del proyecto desconoce los conceptos básicos de gestión de proyectos tecnológicos:
- El 70% de los proyectos a nivel mundial multiplica por tres su plazo de ejecución o se cancela. El caos es el estado natural de los servicios tecnológicos.
- A más presión, menos talento. Incrementando la presión, el líder del proyecto está destruyendo el talento justo cuando más lo necesita.
Un dos.
En resumen
Un cambio de trabajo no debería ser un acto de fe, pero en demasiadas ocasiones damos este paso a ciegas.
Para cubrir ese vacío, arrancamos esta serie de artículos hace ya tres meses a partir de un #ThinkingBreakfast con el equipo de novanotio. Esperamos que estas reflexiones os sirvan de guía durante toda vuestra carrera profesional.
Nos vemos de nuevo en el artículo de marzo de 2023.
El peor escenario para un proyecto informático es la lluvia ácida
El peor escenario para un proyecto informático es la lluvia ácida
El peor escenario para un proyecto informático no es que vaya con mucho retraso. O que multiplique por tres el coste presupuestado. O que el cliente esté muy enfadado.
Eso ocurre en el 80% de los proyectos, tal como anticipa Pareto y nos confirma The Standish Group en sus informes 'Chaos Report'
El peor escenario para un proyecto informático es la lluvia ácida. Y el Jefe de Proyecto es el único responsable.
Bienvenido a una sesión de méntoring de novanotio.
La lluvia ácida
Pero, ¿Qué es la lluvia ácida? Es la situación en que la resolución de incidencias interrumpe continuamente los trabajos de desarrollo.
Por supuesto, siempre hay incidencias en los entornos de producción. Por eso hay equipos de operaciones encargados de monitorizar los procesos, levantar las aplicaciones o corregir entradas inconsistentes en las bases de datos.
Cuando el equipo de operaciones no es capaz de restablecer el servicio, se produce una incidencia crítica que el equipo de desarrollo debe atender de manera urgente.
De la atención de incidencias a la lluvia ácida
Todos los desarrolladores hemos tenido que atender incidencias de producción en algún momento.
El problema aparece cuando esas incidencias son tan frecuentes que fagocitan el tiempo del equipo de desarrollo. He visto grupos dedicar mas del 70% de su jornada a solucionar incidencias.
Cómo se origina la lluvia ácida
La lluvia ácida tiene la misma dinámica que la bola de nieve que rueda ladera abajo. Crece y crece hasta convertirse en un monstruo ingobernable.
Es sencillo entender el hilo de pensamientos del Jefe de Proyecto que desemboca en esta situación:
- Quiero que mi cliente esté satisfecho.
- Y necesito que el proyecto no se retrase todavía mas.
- Así que, tenemos que solucionar rápidamente esta incidencia de producción.
- Y, además, hay que cumplir la planificación que hemos acordado.
Es una línea argumental con la que todos estaríamos de acuerdo, salvo por dos importantes detalles:
- Hagas lo que hagas, el 80% de los proyectos multiplicarán por tres su plazo y su coste. Lo predice Pareto. Lo confirman año tras año las estadísticas de nuestro sector. No puedes escapar del principio de Pareto como no puedes escapar de la ley de la gravedad.
- La cuarta ley nos advierte que alcance, plazo y calidad están interrelacionados, de forma que si fijas dos de ellos el tercero se degrada. Si mantienes el plazo y amplías el alcance (todo lo planificado más la resolución de las incidencias), la calidad se degrada.
La lluvia ácida aparece cuando sacrificas la calidad
El origen de la lluvia ácida es un Jefe de Proyecto que, presionado por su cliente, sacrifica la calidad.
Ese código desarrollado a toda prisa y que se pone en producción sin apenas pruebas, va a generar nuevas incidencias en producción, que poco a poco, van a consumir el tiempo disponible para el desarrollo.
Por eso, introduciendo presión en el equipo de desarrollo, no aceleramos los trabajos, sino todo lo contrario.
Por no hablar del incremento de la rotación, que aparecerá como un nueva causa de retrasos del proyecto.
Cómo soluciona Scrum el problema de la lluvia ácida
Scrum soluciona el problema de la lluvia ácida mediante dos mecanismos.
- El primero consiste en planificar dentro de cada sprint un cierto tiempo para atender incidencias en producción.
- El segundo es obligar a que sólo se entreguen al cliente los desarrollos que superen las pruebas funcionales.
Scrum asume que hay que atender incidencias y que no se van a completar todos los trabajos planificados para el sprint. Pero se asegura que aquello que se entregue esté convenientemente probado.
Scrum evita la aparición de la lluvia ácida asegurando la calidad.
Y para asegurar la calidad sacrifica el alcance . Es decir, aplica la cuarta ley de gestión de proyectos informáticos.
Resumen
La posición de Jefe de Proyecto no es sencilla. Con independencia de tu experiencia o la de tus desarrolladores, el 80% de tus proyectos van a sufrir importantes retrasos y sobrecostes.
Si intentas acelerar los proyectos metiendo presión a tus equipos, vas a empeorar la situación.
No solo ralentizarás los desarrollos porque los programadores están cansados. Aparecerán efectos de segunda ronda como la lluvia ácida y la rotación, que dilatarán todavía más tu planificación.
Si has seguido las sesiones de méntoring de novanotio, ya sabes cómo evitar la aparición de la lluvia ácida:
- Garantiza la calidad, sacrifica el alcance (4ª ley de gestión de proyectos informáticos).
Y además:
- Quita presión a tus equipos de trabajo (3ª ley de gestión de proyectos informáticos).
- Prioriza los desarrollos que mas valor aportan (Principio de Pareto).
- Y gestiona las expectativas de tu cliente (1ª ley de gestión de proyectos informáticos).
La metodología Scrum puede ayudarte a conseguir todos estos objetivos.
Gracias por compartir el artículo si te ha parecido interesante y nos vemos en la próxima sesión de méntoring de novanotio.
Scrum y el principio de Pareto
Scrum y el principio de Pareto.
El principio de Pareto
El principio de Pareto, también conocido como la regla del 20 - 80, describe el fenómeno estadístico por el cual, el 20% de la población posee el 80% de las tierras de una región.
Esta regla fue enunciada en 1.896 por el matemático italiano Wilfredo Pareto. Desde entonces se ha aplicado a múltiples áreas de las ciencias, la economía y la organización empresarial.
- El 20% de tu ropa la usas el 80% de las veces.
- Con el 20% de tiempo de estudio, consigues el 80% de la calificación.
- El 20% de tus clientes aportan el 80% de tu facturación.
- El 20% de tus productos suponen el 80% de tus ventas.
En resumen, con el 20% del esfuerzo, consigues el 80% del rendimiento.
Este principio es, como veremos, muy importante para el desarrollo de sistemas informáticos. Aunque no lo encontrarás en el Manifiesto Agile, es uno de los pilares fundamentales de Scrum.
Bienvenido a una sesión de formación de novanotio.
Porcentaje de éxito en el desarrollo de sistemas informáticos
Ésta es la primera pregunta que hacemos a todos nuestros consultores en su primera sesión de méntoring. ¿Cuál es el porcentaje de éxito en el desarrollo de los sistemas informáticos?
La respuesta la obtenemos de los análisis que año tras año realiza The Standish Group en su informe 'Chaos Report'. Aproximadamente un 20%.
A pesar de todos los esfuerzos del sector para construir nuevas herramientas y desarrollar nuevas metodologías, el 80% de los proyectos tienen importantes problemas o se cancelan.
Es una aplicación más del principio de Pareto. El 20% de los proyectos aportan el 80% del valor. Organizaciones y estados han invertido miles de millones para escapar a esta regla sin conseguirlo.
No es posible tener éxito en los proyectos
La definición tradicional de éxito es: 'Completar el alcance que se ha acordado en la especificación, en el plazo establecido, con el coste presupuestado y con una buena calidad'
La cuarta ley de la gestión de proyectos informáticos nos avisa de que es imposible conseguir el éxito así definido. Alcance, plazo y calidad son tres parámetros que están interrelacionados, de forma que si fijas dos de ellos, el tercero se degrada.
No es posible alcanzar el éxito según la definición tradicional porque fija alcance, plazo y calidad. Obligatoriamente uno de esos parámetros debe degradarse.
El 80% de los proyectos quedan atrapados por la gravedad de la cuarta ley. Los pocos que consiguen el éxito suelen ser proyectos pequeños sin un alcance demasiado preciso.
Scrum no cambia el porcentaje de éxito, cambia la definición de éxito
Scrum no cambia el porcentaje de éxito de los proyectos. La cuarta ley no desaparece solo por dividir el desarrollo en sprints de cuatro semanas.
Scrum cambia la definición de éxito.
Y es que buena parte del software desarrollado nunca se utiliza. En concreto, aplicando la regla de Pareto, el 20% de la funcionalidad se utiliza el 80% de las veces.
Si conseguimos desarrollar ese 20% que más valor aporta, podemos construir casi todo el sistema con una fracción del esfuerzo.
Así que esta es la nueva definición de éxito que Scrum nos proporciona: 'Usar el presupuesto para construir la mayor cantidad posible de funcionalidad, empezando por aquella que se utiliza con más frecuencia y aporta más valor, con una buena calidad'
Ahora si es posible conseguir el éxito y escapar de la cuarta ley, porque en esta definición se fijan plazo y calidad, pero el alcance queda indeterminado.
Conclusión
El desarrollo de software seguirá siendo complejo a pesar de las nuevas herramientas y metodologías. Los proyectos seguirán retrasándose y fracasando, especialmente aquellos más grandes y complejos.
Afortunadamente Pareto nos indica el camino a seguir. ¡Busca junto con tu cliente ese 20% de la funcionalidad que aporta el 80% del valor!
13 técnicas para convertir tus programadores en un equipo de alto rendimiento
Cómo transformar un grupo de programadores en un equipo de alto rendimiento
En este artículo vamos a estudiar una de las funciones más importantes de un Jefe de Proyecto. Cómo transformar un grupo de jóvenes ingenieros informáticos en un equipo de alto rendimiento.
Ya os adelantamos que no es una tarea sencilla. Cuando incorporas un grupo de juniors, en pocas semanas tu oficina parece la taberna de Piratas del Caribe. Y eso lastra su productividad.
De Marco, en su ensayo de 1.987 ‘Peopleware’, avisa que existen multitud de formas de destruir equipos de alto rendimiento, pero ninguna técnica garantiza el éxito. Ni siquiera las que 13 os presentamos en esta entrada. No te desanimes si no tienes éxito en tus primeros intentos.
Qué son equipos de alto rendimiento
Antes de intentar construir un equipo de alto rendimiento, es importante saber qué son y por qué son más productivos.
Un equipo de alto rendimiento es un grupo de consultores que trabajan con confianza. Solo eso. No tienen que ser gurús de la programación ni excelentes arquitectos de sistemas. Simplemente tienen que confiar unos en otros.
Confianza y productividad
¿Por qué la confianza incrementa la productividad? Porque cuando hay confianza, puedes tomar riesgos y resolver los problemas de forma creativa. No es lo mismo buscar soluciones que buscar culpables, ¿verdad?
Cuando no existe confianza, nadie se atreve a tomar decisiones y los equipos se ‘esclerotizan’.
Putnam, en su clásico ‘Five Core Metrics’, determina que el ritmo de avance de un proyecto sólo depende del número de buenas ideas que tiene el equipo. El número de horas empleadas es importante para determinar el coste, pero irrelevante para acelerar los desarrollos.
Para incrementar la productividad, tienes que gestionar el talento de tu equipo. Debes conseguir que cada día tengan buenas ideas. Y para eso es necesaria esa confianza que vas a construir.
Cómo identificar equipos de alto rendimiento
Estos son algunos síntomas de que tu equipo comienza a fraguar:
- Están auto organizados. No hace falta que distribuyas las nuevas tareas, siempre hay alguien que las asume.
- No necesitan presión externa. Cada uno sabe cuándo debe hacer un sobreesfuerzo.
- Aparece la Presión Inter Pares (PIP). La exigencia la marcan los compañeros. Tu sólo apartas las trabas burocráticas para que ellos puedan avanzar más rápido.
- Sensación de SWAT. Sienten que son capaces de superar al resto del mercado en alguna faceta de su trabajo.
- La rotación es inferior a la del entorno y se produce fuera de periodos críticos.
- Es divertido ir a trabajar. Te sientes bien los domingos por la tarde.
13 técnicas para construir equipos de alto rendimiento
Vamos con las 13 técnicas que puedes emplear para transformar a tus consultores en un equipo de alto rendimiento. Recuerda, ninguna de ellas garantiza el éxito. Ten paciencia y descubre poco a poco cuáles se adaptan mejor a tu personalidad.
1. Explícales cuál es su misión
No hay nada más descorazonador que programar sin tener claro qué estás haciendo.
Así que dedica todo tu esfuerzo a que los programadores entiendan la especificación. Asegúrate de que tienen acceso a alguien que conoce el problema. Busca la complicidad y el apoyo del cliente o del business analyst. Si usas la metodología SCRUM, asegúrate de que el cliente aporte un Product Owner al squad.
Y avisa a tus programadores de que la especificación cambiará a lo largo del proyecto. Esto les afectará porque, con frecuencia, su esfuerzo de varias semanas terminará en el cubo de la basura.
Tienes que explicarles que esos constantes cambios de funcionalidad son la esencia misma del software. Si fuera posible hacer una especificación cerrada, el desarrollo se haría en Asia y los consultores europeos estarían en paro.
En la literatura sobre ingeniería del software, se insiste en que, con frecuencia, la especificación se construye en esas reuniones informales delante de la máquina del café. Una buena idea es fomentar estos ‘momentos de café’ y asegurarse de que participa todo el equipo.
2. Asegúrate de que disponen de los medios materiales adecuados
Comprueba que tus programadores disponen de los medios adecuados para hacer su trabajo. Es desesperante esperar quince minutos por una compilación. ‘Haz lo que puedas con lo que tienes’ no fomenta el compromiso.
Un chip de memoria cuesta menos de 100 € y obra milagros en la motivación de un consultor.
3. Comprueba que todos los días tienen ocasión de hacer las cosas que les gustan
Este es un problema endémico en nuestro sector.
En muchas ocasiones, los consultores no están haciendo aquello para lo que se los contrató, sino que están usando una tecnología obsoleta para resolver un problema urgente del cliente.
Otras veces tienen la sensación de que sus entornos se están quedando desfasados y hay tecnologías más punteras que deberían estar aprendiendo.
En ambos casos sienten que están ‘perdiendo su tiempo’ o ‘perdiendo oportunidades’. Empiezan a prestar atención a las ofertas de trabajo que reciben y de ahí a su renuncia solo hay unos días.
Tienes que saber si tus consultores están haciendo lo que les gusta, y una buena forma de averiguarlo es preguntarles. Reúnete con cada uno de ellos varias veces al año. Antes de que pidan la baja voluntaria, cambiales de proyecto o reserva una parte de su jornada para que experimenten con nuevas tecnologías.
4. Dales feedback positivo
El feedback positivo es LA HERRAMIENTA para mejorar la motivación. Y además es gratis. Solo tienes que decirles lo que han hecho bien, seguro que hacen cosas increíbles todos los días. Incluso puedes montar una pequeña celebración para dar más énfasis a algún logro del equipo.
Muchos jefes de proyecto pasan de puntillas por los éxitos y solo dan feedback cuando algo sale mal. Es un error de novato. El feedback negativo solo puedes usarlo con los equipos de pruebas de sistemas. ‘Este error se os ha escapado’ es todo el aliciente que necesitan para redoblar sus esfuerzos destructivos.
Las técnicas clásicas del palo y la zanahoria, como el bonus por objetivos, no funcionan en los entornos tecnológicos. Conseguirás que trabajen más horas, pero no que tengan mejores ideas.
5. Preocúpate por su situación personal
Recuerda que tus consultores, por encima de todo, son personas.
El trabajo no es solo una forma de obtener ingresos, cubre también muchas necesidades emocionales. En el ámbito laboral muchos encuentran su familia. sus amigos y su tribu.
Es importante que conozcas la situación de cada uno de ellos y les preguntes con frecuencia por sus parejas, sus hijos o sus seres queridos. Ofréceles consejo si la situación lo requiere, o consuelo si es lo único que puedes darles en ese momento.
6. Anímales a formarse
El ser humano es curioso por naturaleza y tus programadores lo son aún más.
Una buena forma de mejorar su motivación es mediante el aprendizaje. La formación les da seguridad e incrementa su creatividad.
Pídeles que realicen cursos o consigan certificaciones. O reserva una parte de su jornada para que prueben y experimenten con nuevos entornos y aplicaciones.
7. Ten en cuenta sus opiniones
Otra de nuestras necesidades emocionales es influir en las personas que nos rodean.
Así que puedes mejorar el compromiso y la creatividad de tu equipo escuchando sus sugerencias y probando algunas de ellas. O puedes darles un poco de tiempo libre para experimentar y crear prototipos, seguro que algunos se transformarán en valiosas herramientas.
SCRUM utiliza esta idea del empoderamiento y prescinde de los líderes técnicos. Las decisiones de diseño y construcción del sistema las toman los programadores del squad.
Ten cuidado con los procedimientos empresariales, son una forma de decirles ‘tu opinión no cuenta’. Una de tus principales misiones como Jefe de Proyecto es ayudar a tu equipo a superar las trabas burocráticas.
8. Explícales por qué su trabajo es importante para la sociedad
El ser humano es más feliz cuando tiene una misión que dé sentido a su existencia. Esforzarse sin tener un propósito en la vida es como programar sin tener clara la especificación funcional.
No corren buenos tiempos para encontrar una misión vital, toda vez que la religión y la ideología se tambalean en sus pedestales. No es de extrañar que ante este vacío, muchos confundan los fines con los medios y se lancen en busca de la riqueza o la fama.
Aprovecha a tu favor este vacío existencial para mejorar el compromiso de tus consultores. Explícales cómo los servicios de la empresa no son solo un proceso para generar beneficios sino que contribuyen a construir un mundo mejor.
Por usar un ejemplo sencillo, si no hubiera servicios de ciberseguridad, nuestra sociedad colapsaría en 24 horas. Pensad en el impacto para cientos de familias del ataque informático al SEPE. Multiplicadlo por varios millones.
9. Vigila los ‘garbanzos negros‘
El consultor con el rendimiento más bajo fija el estándar de excelencia de todos los demás.
Una de las labores más complejas de un líder es detectar a aquellos cuyo rendimiento es inferior al del resto. Y es difícil porque no existen métricas, cada desarrollo es único y diferente. Así que sólo puedes tener sospechas de que alguno de tus consultores ha bajado los brazos.
Reúnete periódicamente con cada uno de ellos, posiblemente no quieran criticar abiertamente a un compañero, pero leyendo entre líneas encontrarás la información que necesitas.
Uno de los momentos más peligrosos para un equipo de alto rendimiento es la incorporación de un nuevo miembro. ¿Estará a la altura de los demás? ¿Será capaz de construir buenas relaciones con el resto? Si la respuesta es no, tienes un grave problema.
El éxito es un potente catalizador. ¿Quién no quiere estar en un equipo que consigue cosas increíbles? Celebrar los éxitos es una buena forma de motivar a esos ingenieros que han llegado a tu equipo rebotados de otros grupos.
Si nada de lo anterior funciona, debes apartar a esos garbanzos negros del equipo.
10. Fomenta las relaciones de amistad
Como hemos visto en puntos anteriores, el trabajo cubre necesidades emocionales además de las económicas.
Se ha demostrado que la productividad de los programadores crece si en el equipo tienen un buen amigo. Así que fomenta las relaciones de amistad; busca ‘momentos de café’ dentro de la jornada laboral y asegúrate de que participe todo el equipo, invítales a comer a un sitio nuevo, incluso proponles actividades lúdicas como el pádel o el MTB.
O también puedes reservar un poco de su tiempo para que prueben nuevos entornos con algún compañero de su elección.
11. Haz reuniones individuales de seguimiento varias veces al año
Esta es una idea que ya ha aparecido en varios de los puntos anteriores. Con estas reuniones cubres buena parte de tus funciones como jefe de proyecto:
- 3. Puedes averiguar si están haciendo lo que les gusta.
- 5. Te interesas por su situación personal
- 6. Puedes animarles a formarse.
- 7. Es una forma de conocer y tener en cuenta sus opiniones
- 8. Puedes explicarles por qué su trabajo es importante para la sociedad.
- 9. Puedes descubrir si hay algún ‘garbanzo negro‘ en el equipo.
Pero además de todo eso, tus ingenieros necesitan saber cómo están creciendo.
Dales feedback sobre su crecimiento. Es una poderosa herramienta para construir su compromiso. Cuéntales qué cosas te gustan de su trabajo y explícales hacia donde esperas que avancen.
Las sesiones individuales de seguimiento no tienen coste y no tienen precio.
12. Celebra los éxitos
Otra idea que ha aparecido en varios de los puntos anteriores:
- 1. Estas reuniones informales ayudan a construir la especificación.
- 4. Son una forma de dar reconocimiento y feedback positivo.
- 8. Es un buen momento para recordarles por qué su trabajo es importante para la sociedad.
- 9. Es una forma de sacar de su apatía a los ‘garbanzos negros‘
- 10. Fomentas las relaciones de amistad
La parte más complicada de celebrar los éxitos es, precisamente, encontrar un éxito. Recuerda que el porcentaje de proyectos que está en una situación delicada es del 80%. Tendrás que decidir que algo de lo que se ha conseguido es extraordinario.
La ceremonia de celebración es muy sencilla, solo tienes que llevar a la oficina algo ‘especial’ como manolitos o palmeritas de Morata y compartirlo con todo tu equipo en algún momento de la jornada laboral. Una mínima inversión económica pero un gran trabajo de liderazgo.
13. Reserva parte de su tiempo para que hagan prototipos o prueben nuevas tecnologías
Otra idea muy interesante que salpica todo el texto. Google lo hace. Amazon lo hace. Los motivos están claros:
- 3. Te aseguras de que parte de su jornada la dediquen a las cosas que realmente les gustan.
- 6. Les animas a formarse y a incrementar sus conocimientos.
- 7. Tienes en cuenta sus opiniones.
- 10. Fomenta las relaciones de amistad.
- 1X. Algunas de esas pruebas de concepto acabarán siendo valiosas herramientas o nuevas fuentes de ingresos.
Puede que te preguntes: ‘si ya vamos fuera de plazo, ¿cómo emplear parte de la jornada en cosas ajenas al proyecto?’.
No te preocupes por el tiempo invertido en este aprendizaje. La mejora de la motivación, el compromiso y la productividad pagarán con creces estas horas de crecimiento personal.
¿Y el dinero?
El único Dios verdadero (Joaquín Sabina, ‘Como te digo una co, te digo la o’).
¿Qué papel juega el dinero en la motivación de los consultores y en la construcción de equipos de alto rendimiento?
El dinero es un problema complejo. Cubre necesidades básicas, pero también es una forma de rankear a los miembros de un equipo. Mas ganas, mas vales.
Con frecuencia los programadores más antiguos te pedirán aumentos de sueldo porque los junior a los que están formando ganan más que ellos. Es otro problema endémico de nuestro sector, sobre todo en épocas de fuerte crecimiento económico.
Pero las mas de las veces, cuando tus consultores te piden un incremento salarial, es porque hay problemas en otras facetas de su trabajo. Y el dinero no compensa hacer cosas que no te gustan, tener un portátil antiguo o que tus compañeros estén desmotivados.
Cuando el dinero no es el problema, el dinero no es la solución.
Bibliografía
Este artículo está basado en los estudios de Gallup recogidos en ’12, the elements of great managing’. Hemos adaptado las conclusiones al mundo de la programación y enriquecido el contenido con nuestra experiencia de 25 años en el sector.
También hemos incorporado algunas referencias de los estudios de Putnam y DeMarco con sus respectivos enlaces.
Es una buena idea leer todos estos libros si quieres crecer como Jefe de Proyecto.
Funciones del líder técnico en la era SCRUM
El líder técnico en la era SCRUM. Las funciones de un rol condenado a desaparecer
El rol de líder técnico es la carrera profesional más deseada por los jóvenes ingenieros informáticos. En este artículo vamos a estudiar su historia, sus vías de crecimiento profesional y cómo se transforman sus funciones con la llegada de SCRUM.
Un poco de historia
El líder técnico es el primer rol de liderazgo que surge en las empresas tecnológicas, junto con el de analista/programador. En los albores de la informática, era el responsable del diseño y la construcción de los sistemas.
Su misión original era extensa; entender las necesidades del cliente, hacer un primer diseño de alto nivel, preparar el diseño de bajo nivel, controlar los costes, determinar el alcance del sistema y, por supuesto, motivar y dirigir al equipo técnico.
Nuestro líder técnico terminó apoyándose en su ayudante, el gestor del proyecto. Un personaje gris al que delegó las aburridas tareas de control económico, interlocución con el cliente y motivación del equipo. Durante los años 80 del pasado siglo, el gestor del proyecto arrebató progresivamente el protagonismo y el reconocimiento al líder técnico y se transformó en el Jefe de Proyecto.
Funciones del líder técnico
El líder técnico mantiene dos de sus funciones originales, el diseño de bajo nivel y la supervisión del trabajo técnico.
El diseño de bajo nivel es su actividad preferida. Recibe del Business Analyst una especificación de alto nivel y la transforma en un conjunto de actividades más simples y detalladas que asigna a los diferentes equipos técnicos.
Brooks, en su clásico ‘The mythical man month’, nos advierte no existe un lenguaje de alta precisión para comunicar esas especificaciones de bajo nivel. Por eso es tan importante la segunda de sus funciones, el seguimiento de la actividad del equipo técnico. Sin esta supervisión, los analistas y programadores desarrollarían funciones diferentes a las especificadas.
El seguimiento del equipo técnico puede ocupar hasta el ochenta por ciento de su tiempo.
¿Cómo se llega a líder técnico?
Para ser un buen líder técnico necesitas un profundo conocimiento funcional del sistema y de su arquitectura, es decir, qué problema resuelve y cómo están construidos sus módulos. La única forma de adquirir estos conocimientos es participando en la construcción, por lo que el Líder Técnico suele ser uno de los programadores más veteranos.
A este rol se accede con paciencia. Como la permanencia media de un consultor en un proyecto es de 24 meses, en tres o cuatro años serás analista/programador y en otros tres o cuatro probablemente serás el líder técnico.
Crecimiento profesional del líder técnico
Ya eres líder técnico y tu equipo ha desarrollado con éxito varios proyectos. ¿Cuál es el siguiente paso de tu carrera profesional?
La evolución natural es hacia CIO/CTO, el responsable de los sistemas informáticos de la empresa, por tus conocimientos funcionales y tecnológicos.
Si has estado desarrollando un producto, lo mas probable es que acabes siendo el Product Manager. Tu misión será definir el roadmap de los futuros desarrollos.
Siempre puedes crecer hacia posiciones de Business Analyst, por tus conocimiento de las necesidades de los clientes.
Por último puedes crecer hacia Jefe de Proyecto, pero entonces toda tu experiencia anterior será inútil. Necesitarás desarrollar habilidades de motivación y negociación.
La desaparición del Líder Técnico en la era Scrum
La transición a las metodologías ágiles es un proceso complejo.
No basta con agrupar los equipos técnicos en squads y desarrollar en sprints de tres semanas. Es necesario que el cliente se involucre y participe de forma activa en el desarrollo, aportando un product owner al squad.
Y sobre todo es necesario que el cliente entienda que el alcance de los trabajos está abierto. La gran aportación de Scrum es cambiar la definición de éxito de un proyecto. ‘Desarrollar la mejor funcionalidad posible dentro de un plazo y con un presupuesto’.
Con la llegada de las metodologías ágiles, desaparece paulatinamente la figura del Líder Técnico.
No pueden ser el Product Owner, porque sólo el cliente conoce el retorno de inversión de cada desarrollo. Y los squads no necesitan un líder técnico, son los programadores los que deciden la arquitectura de sus módulos.
Con la llegada de SCRUM, el rol de líder técnico está llamado a desaparecer.
Factores del éxito en los proyectos informáticos
Factores del éxito en los proyectos informáticos
¿Cuáles son los principales factores que influyen en el éxito en los proyectos informáticos?
La metodología por si misma no basta para explicar el éxito o el fracaso de los mismos. Hemos participado en muchos proyectos exitosos que no seguían ninguna metodología formal. También en proyectos con fuertes retrasos y sobrecostes gestionados con diferentes metodologías; CMMI, Waterfall, ITIL y también Scrum.
¿Cuáles son entonces los principales factores que influyen en el éxito de un proyecto informático?
Desde nuestra experiencia, y por orden de importancia:
- Experiencia previa en el proyecto. Los proyectos de mantenimiento evolutivo tienen una tasa de éxito muy superior, porque tanto el equipo de desarrollo como el de gestión conocen los requisitos funcionales.
- Tamaño del proyecto. Los proyectos pequeños son más exitosos porque pueden abordarse con un equipo reducido. Esto facilita la coordinación de los participantes y acelera la construcción de los requisitos funcionales.
- Liderazgo. Si el Jefe de Proyecto domina los fundamentos de la gestión de proyectos, no sólo mejora la productividad. Puede cambiar la precepción de éxito o fracaso del mismo.
- Metodología. Los proyectos gestionados con SCRUM tienden a ser más exitosos. Sobre todo porque SCRUM, como los buenos líderes, cambia la definición de éxito de un proyecto.
La experiencia previa y el tamaño del proyecto vienen impuestos por las circunstancias y no podemos gestionarlos.
Sin embargo, liderazgo y metodología son factores clave para el éxito de los proyectos informáticos que si están dentro de nuestra esfera de influencia. Por eso los estudiamos en nuestro méntoring Novanotio Certified.
Liderazgo
Los cuatro principios básicos de la gestión de proyectos informáticos se condensan en cuatro sencillas frases. Son todo lo que necesitas conocer para liderar equipos:
1ª ley. Las especificaciones son inciertas, imprecisas e infinitas.
2ª ley. One project, one team, one site.
3ª ley. Presión x Talento = Constante.
4ª ley. Alcance, Plazo y Calidad. Si fijas dos de ellas, la tercera se degrada porque es la variable de ajuste
Estas 35 palabras son el credo de todo buen Jefe de Proyecto. En este artículo explicamos con más detalle su contenido y cómo utilizarlas.
Metodología
La metodología elegida para gestionar el proyecto también es importante.
Últimamente cobran especial relevancia las metodologías ágiles, con SCRUM a la cabeza. Hay cientos de libros y artículos sobre SCRUM que seguramente ya habrás leído. Solo añadiremos algunas reflexiones que consideramos importantes:
Las empresas cometen una y otra vez los mismos errores al implantar Scrum. Esta lectura de tres minutos evitará que caigas en las mismas trampas para novatos.
Es importante que conozcas los fundamentos de Scrum para implantarlo con éxito en tu organización. Si no entiendes estos fundamentos, vas a implantar Scrum como si fuera una religión. Y tus proyectos no mejorarán.
¡Mucha suerte en la gestión de tus proyectos!