Fundamentos de SCRUM
Fundamentos de SCRUM
Es importante que domines los fundamentos de SCRUM si quieres implementar con éxito esta metodología.
Seguramente ya has leído libros y blogs que explican los diferentes procesos de SCRUM. El desarrollo en sucesivas iteraciones o sprints, el daily, el Sprint Planning, la retrospective, etc.
Si no conoces los fundamentos de SCRUM, lo mas probable es que cometas los mismos errores que la mayor parte de las organizaciones. Acabarás por implementar SCRUM como si fuera una religión y apenas conseguirás mejorar la productividad.
En novanotio defendemos que hay cuatro sencillas reglas que ayudan a gestionar con éxito los proyectos tecnológicos. Es una buena idea que revises nuestro artículo sobre las cuatro leyes antes de continuar con esta lectura.
En esta entrada vamos a analizar las relaciones entre las cuatro reglas básicas y los procesos de la metodología. Una vez que comprendas los fundamentos de SCRUM, estarás mejor preparado para implementarla en tu organización.
Relación entre SCRUM y la 1ª ley.
Las especificaciones son inciertas, imprecisas e infinitas.
La primera ley nos advierte tres cosas:
– Que el cliente no puede saber lo que quiere. El tiempo invertido en especificar suele ser tiempo perdido.
– Que una especificación redactada en lenguaje natural (castellano, inglés, alemán, etc.) es interpretable.
– Que no es posible finalizar los trabajos. Siempre queda algo por hacer.
¿Cómo responde Scrum a estos tres desafíos?
– El diseño es muy liviano; los requisitos se capturan en Epics, Features e Historias de Usuario, cuya extensión es de un párrafo.
– Para interpretar la especificación, se incorpora al squad un representante del cliente, el Product Owner,
– El Product Owner prioriza los trabajos para que el Retorno de Inversión sea el mayor posible, dentro del presupuesto.
Relación entre SCRUM y la 2ª ley.
One Project, One Team, One Site.
La segunda ley dice que para mejorar la productividad, todo el equipo de trabajo, incluido el cliente, debe estar en una única oficina y dedicarse en exclusiva al proyecto. La convivencia construye vínculos emocionales y relaciones de confianza que son imprescindibles.
¿Cómo construye Scrum los equipos?
En Scrum, los squads de desarrollo están formados por entre cinco y nueve consultores, cuyos puestos de trabajo están próximos entre sí. El Product Owner, que es el representante del cliente, es un miembro más del equipo.
Relación entre SCRUM y la 3ª ley.
Presión x Talento = Constante.
Talento y presión son antagónicos. Cuando uno crece, el otro disminuye.
La tercera ley nos recuerda que en el desarrollo de software debemos priorizar el talento sobre la presión. La velocidad de desarrollo depende del número de buenas ideas, no del número de horas de la jornada.
¿Cómo fomenta Scrum el talento?
Para eliminar la presión, en Scrum no es obligatorio completar todas las Historias planificadas para el sprint. Algunos desarrollos no superan los test y vuelven al backlog.
Relación entre SCRUM y la 4º ley.
El triángulo de Acero.
La cuarta ley nos enseña que Alcance, Plazo y Calidad están relacionados de tal forma que, si fijas dos de ellos, el tercero se degrada.
Tradicionalmente un contrato fija el alcance y el plazo. ¿El resultado? El 80% de los grandes proyectos son un fiasco.
Así que, como cliente, debes elegir entre:
– Sacrificar el Alcance. Ciertas funcionalidades no se construirán.
– Sacrificar el Plazo (y multiplicar el coste). El sistema se entregará muuucho mas tarde de lo planificado.
– Sacrificar la Calidad. El sistema tendrá errores en producción y será complejo de operar.
¿Qué variable sacrificamos en SCRUM?
La metodología SCRUM determina que la variable sacrificada es el Alcance.
La gran aportación de SCRUM es modificar la definición de éxito de un proyecto. Ya no tenemos que cumplir un alcance dentro de un plazo y con una buena calidad. Cosa que, por cierto, es imposible.
Éxito es conseguir el mayor retorno de inversión posible, dentro del presupuesto y en un plazo acotado.
¿Puedo mejorar la eficiencia sin usar Scrum?
Si conoces los fundamentos de Scrum, puedes utilizar los principios básicos de gestión de proyectos y mejorar el rendimiento de tus proyectos sin necesidad de implementar la metodología.
Pero SCRUM es la palabra de moda. ¡Aprende a implementar esta metodología y tu valor para el mercado se multiplicará!
Cómo orientar tu carrera profesional usando el test de Gallup
Cómo orientar tu carrera profesional usando el test de Gallup
En el entorno tecnológico es fácil tener una primera promoción
Estás haciendo un gran trabajo como programador, y como premio te han propuesto cambiar de actividad. Quizás te han pedido que lideres a un grupo de consultores. O tal vez que asistas a una reunión de ventas.
En el entorno tecnológico es fácil tener una primera promoción. Descubrirás que hay roles que te son tan naturales cómo respirar y otros en los que, a pesar de tu esfuerzo, sólo recibes disgustos. ¿Cómo saber si la jugosa manzana que te ofrecen está envenenada?
El test de fortalezas de Gallup
Vamos a estudiar cómo orientar tu carrera profesional usando el test de fortalezas de Gallup. Si todavía no lo has hecho tienes el enlace aquí. Considera estos veinte dólares como una de las mejores inversiones de tu vida.
Este test te descubre tus principales fortalezas, es decir, los tipos de talento que has desarrollado de forma natural. Gallup distingue entre treinta y cuatro fortalezas que se agrupan en cuatro ámbitos:
- Fortalezas de ejecución. ¿Qué es lo siguiente que tengo que hacer? Si tu única recompensa es un trabajo bien hecho o no puedes dejar una tarea a medias, eres un auténtico ejecutor.
- Fortalezas de pensamiento. ¿Cuál es la mejor forma de hacer las cosas? Si no puedes dejar de estudiar o tienes una potente capacidad analítica eres todo un pensador.
- Fortalezas de relación ¿Cómo construyo relaciones? Si rápidamente sabes cómo son las personas, o para ti lo más importante es el ambiente de trabajo, tienes este tipo de fortalezas.
- Fortalezas de influencia. ¿Cómo consigo convencer a los demás? Si siempre tienes en la boca la palabra adecuada considérate un influencer.
¿Qué fortalezas ayudan a desempeñar los distintos roles tecnológicos?
No todos los roles tecnológicos precisan de las mismas fortalezas. Según el resultado de tu test de Gallup, te sentirás más cómodo en unos u otros puestos.
Si tus fortalezas son de pensamiento y relación
En los primeros test de Gallup que realizamos, descubrimos que los mejores programadores combinaban fortalezas de pensamiento y relación.
Pronto nos dimos cuenta que, para programar, los vínculos emocionales son muy importantes, porque facilitan la construcción de las especificaciones y la coordinación de las tareas.
En resumen, si tus principales fortalezas son de relación y pensamiento, la programación se te dará bien de forma natural.
Si tus fortalezas son de pensamiento
Sin embargo, si la mayoría son de pensamiento, estarás más cómodo en roles con más complejidad y menos relación, como la administración de sistemas o la ciberseguridad.
Si tus fortalezas son de relación
Si tus fortalezas son sobre todo de relación, busca trabajos donde tengas que estar en contacto con el cliente. Los roles de soporte combinan una parte de conocimiento técnico y mucha relación con los usuarios de las aplicaciones y sistemas.
Si tus fortalezas son de relación e influencia
Si a las fortalezas de relación se suman las de influencia, tu sitio está en el área de ventas. Aquí tu misión es crear un vínculo con el cliente y convencerle de que ponga una firma. ¡Como pueden pagar esas comisiones por un trabajo tan sencillo!
Si combinas fortalezas de pensamiento e influencia
La combinación de pensamiento e influencia es interesante para liderar equipos. Te sentirás cómodo en las posiciones de Líder Técnico, Jefe de Proyecto o Gerente.
Si tus fortalezas son sobre todo de influencia
Cuantas más fortalezas de influencia aparezcan en tu test de Gallup, más cómodo te sentirás con cada ascenso. Director de Operaciones, CIO, CTO… El cielo es el límite.
Si la mayoría de tus fortalezas son de influencia, tu sitio está en la alta dirección. Algunos te llamarán trepa o pisacuellos. Bueno, quizás no has sido el mejor técnico, pero siempre sabes lo que tienes que decir. Y esas fortalezas te empujarán a los roles que empiezan por C.
¿En qué organizaciones encajarás mejor?
Si tus fortalezas son sobre todo de pensamiento, estarás más cómodo en organizaciones con cultura Growth Mindset.
Por el contrario, si son de ejecución o influencia, busca empresas de tipo Fixed Mindset.
En este artículo de nuestro blog analizamos las diferencias entre ambos tipos de liderazgo.
Alinea tu trayectoria con tus fortalezas
Cuando tu trayectoria profesional está alineada con tus fortalezas, te pagan por hacer lo que se te da bien de forma natural. En el caso contrario también puedes hacer un trabajo brillante, aunque a costa de un mayor esfuerzo y desgaste personal.
¿Quieres saber que actividades son mas adecuadas para ti? Envíame el resultado de tu test de fortalezas y te daré algunas ideas para orientar tu carrera.
Scrum no es una religión
Scrum no es una religión
SCRUM no es una religión. SCRUM es una forma de aplicar las Cuatro Leyes Básicas de la gestión de proyectos. El proceso de desarrollo Scrum es eficiente porque cumple estas cuatro reglas.
Si entiendes los fundamentos de la gestión de proyectos informáticos, puedes adaptar SCRUM, o cualquier otra metodología, a tu empresa.
Pero si no conoces estos fundamentos, corres el riesgo de implantar SCRUM en tu organización como si fuera una poderosa religión.
Y no encontrarás la tierra prometida.
Si adoptas SCRUM como si fuera una religión…
SCRUM es la religión de los elegidos
Scrum es todopoderoso porque es la religión de los elegidos. Si quieres llegar a la tierra prometida de la tecnología, ese lugar idílico donde todos los proyectos finalizan en plazo, debes seguir puntualmente cada uno de sus ritos.
Ya en los tiempos olvidados de las tarjetas perforadas, los profetas Brooks y DeMarco nos advirtieron que los proyectos son tan complejos que podemos trabajar en ellos por los siglos de los siglos. Imbuidos por el espíritu, propusieron abordar la solución en sucesivas iteraciones, meditando junto al cliente tras cada una de ellas qué se ha conseguido y qué se debe hacer a continuación.
El ritual SCRUM que inspiraron es como sigue:
La Sagrada Firma
El Sumo Account Manager descubre una necesidad del cliente y prepara una oferta que tiene plazo y presupuesto definidos pero cuyo alcance queda indeterminado. Realiza sacrificios a Poseidón y ofrendas a Baco para que el cliente realice la Sagrada Firma.
La Sagrada Firma es el ritual más complejo y al que menos atención se presta en los Textos Sagrados. Los clientes no iniciados se resisten a comprometer presupuestos determinados a cambio de servicios indeterminados. No intentes explicarles que en los proyectos realizados según los heréticos ritos de Waterfall, donde el alcance si estaba definido, en media sólo se entregaba el 50% de lo especificado.
El Product Backlog y el Team Backlog
Tras la Sagrada Firma, el cliente unge a uno de sus acólitos con la pesada responsabilidad del éxito de la empresa. A partir de ahora todos le conocerán como el venerable Product Owner.
En un concilio entre cliente, Account Manager y Product Owner, describen el sistema en una docena de tarjetas sagradas de una extensión de algunos párrafos llamadas Epics y Features. Las sagradas tarjetas se exponen a los acólitos en un altar de corcho llamado Product Backlog para que sean para ellos fuente de inspiración.
En sucesivos aquelarres, el Product Owner y los programadores, descomponen Epics y Features en nuevas tarjetas llamadas Historias de Usuario, que tienen la forma ‘Como usuario <perfil de usuario> soy capaz de hacer <tarea> y así consigo <valor para el negocio> ’. Exponen su trabajo en un nuevo altar de corcho, el Team Backlog.
La implementación
Es el momento de comenzar los ritos de implementación.
El primero es formar la escuadra de desarrollo, con el Product Owner, un Scrum Master y entre cinco y siete consultores. Sus puestos de trabajo deben estar próximos entre sí y se encargarán de implementar de extremo a extremo las Historias de Usuario. Su sagrado apostolado incluye definir la arquitectura, hacer el diseño, codificar, probar, integrar y documentar.
Cada iteración comienzan con la ceremonia del Sprint Planning. El squad se reúne para decidir qué Historias de Usuario intentarán implementar durante el Sprint, que durará entre tres y cuatro semanas. El Product Owner sabe qué historias de usuario son prioritarias. La escuadra intuye su velocidad de ejecución.
Cada mañana, antes de la salida del sol, la escuadra se reúne para maitines, rito también conocido como daily. Durante el resto del día, diseñan las Historias de Usuario, las codifican, desarrollan las pruebas unitarias y prueban el software construido. Sólo si el código supera las pruebas se considera apto para depositar a los pies del cliente e implorar su aceptación.
El Product Owner ayuda a los programadores a interpretar las sagradas Historias de Usuario. El Scrum Master vela por la pureza de los rituales.
El Sprint Review
Finalizado el Sprint, el squad celebra el Sprint Review, ceremonia en la que el código desarrollado se ofrece al cliente y las Historias de Usuario que no se han completado se devuelven al team backlog.
El Sprint Retrospective
El acto final es el Sprint Retrospective. Aquí Product Owner, programadores y testers reconocen sus faltas y hacen propósito de enmienda, con el fin de ser más productivos en próximas iteraciones.
Que los Dioses te sean propicios
Sigue religiosamente este ritual y alcanzarás la tierra prometida con la bendición de los Dioses.
Los peligros de imponer SCRUM a tu organización como si fuera una religión
Los ritos de SCRUM son folclore, comportamientos llamativos que emplean otras organizaciones. Desconocemos su significado, pero hay cientos de artículos describiendo su éxito y son tentadores de imitar.
Un ejemplo de imitación del folclore. Una organización que compró una mesa de billar, pero despidió a un consultor por ir al médico. ¿Veis a lo que me refiero? Si te despiden porque estás enfermo y vas al centro de salud, ¿cuál será el castigo si estás sano y dejas de trabajar para hacer carambolas?
Si no conoces las reglas básicas de la gestión de proyectos, corres el riesgo de implantar SCRUM como si fuera una religión, y cometer los mismos errores que buena parte de las organizaciones.
Y entonces no llegarás a la tierra prometida.
Carreras profesionales. El analista programador
Carreras profesionales. El Analista Programador.
El Analista Programador es la primera promoción dentro de las carreras profesionales tecnológicas. Y esconde una trampa que debes conocer.
Con un poco de paciencia, en tres o cuatro años serás el programador más veterano de un pequeño grupo de consultores, lo que te convierte de facto en su líder técnico, el Analista Programador.
Aquí te vas a enfrentar a tu primer problema de liderazgo. ¿Dedico mi precioso tiempo a realizar mi trabajo técnico, o a formar a los consultores recién incorporados?
Existen tres posibles estrategias:
Estrategia 1. Priorizas la formación de los nuevos consultores
Tu primer intento será priorizar la formación de los nuevos consultores, para que puedan trabajar con autonomía.
Hemos representado en la gráfica el resultado de esta estrategia con una línea verde. ¿Te das cuenta de que a corto plazo es la solución menos eficiente? Esto significa dos cosas. Que tu lista de tareas pendientes amenaza con llegar al infinito. Y que tu cliente y tu Jefe de Proyecto están muuuy nerviosos.
Si consigues soportar la presión, a medio plazo construirás un Equipo de Alto Rendimiento.
Pero lo normal es que resbales a la estrategia número dos.
Estrategia 2. Priorizas tu trabajo técnico
Cedes a la insoportable presión del cliente y dedicas la mayor parte de tu tiempo a esa lista de tareas críticas pendientes.
Estás tan concentrado que hasta te molesta que te consulten dudas. Los jóvenes consultores se aburren y se frustran porque aprenden muy despacio. Hasta es posible que alguno de ellos se vaya. ¡Justo ahora que empezaba a tener algunos conocimientos!
Hemos representado en rojo los resultados. A corto plazo superas a la estrategia uno, pero sigues muy lejos de las expectativas del servicio. Ya sabes, tensas reuniones con el cliente y con tu Jefe de Proyecto.
Así que, agotado, caes a la estrategia número tres.
Estrategia 3. Haces tu trabajo técnico y además formas a los nuevos consultores.
Esta estrategia supone un enorme desgaste por el volumen de horas necesario. Es una muestra de compromiso hacia tu empresa y tu cliente. ¡Estás sacrificando tu vida personal y familiar! Lo menos que esperas es que alguien te de las gracias.
Y si te fijas en la línea amarilla, tus resultados superan a las estrategias uno y dos. Pero lamentablemente sigues por debajo de las expectativas. ¿Sabes lo que eso significa? Si. En lugar de agradecimientos, mas tensas reuniones con el cliente y con tu Jefe de Proyecto.
¿Ves como se desploma la línea amarilla? Ese es el punto en que presentas la baja voluntaria o la baja por depresión.
A corto plazo, ninguna de las estrategias alcanza las expectativas
Como puedes ver, a corto plazo ninguna estrategia ofrece resultados acordes con las expectativas, lo que se traduce en presión. Retrasos, tareas pendientes y discusiones.
Entonces ¿Cuál de ellas elegir?
Pues, teniendo en cuenta que las estrategias dos y tres nunca alcanzan la productividad deseada, la decisión no es difícil.
Nuestro consejo es apostar por las personas y elegir la primera de las opciones. Aprenderás a gestionar la presión y aprenderás a crear equipos de alto rendimiento. Y si la presión te supera, es un buen momento para dar un paso atrás y retomar el camino del Especialista Tecnológico.
En próximos artículos veremos cómo la estrategia número uno consigue a largo plazo superar las expectativas del cliente. Y veremos también los nuevos desafíos que eso genera.
No olvides volver de vez en cuando y revisar las nuevas entradas.
Errores más frecuentes al implantar Scrum
Errores más frecuente al implantar Scrum
Vamos a repasar en este artículo los errores más frecuentes al implantar Scrum y sus consecuencias.
Muchos de los proyectos en los que participamos han comenzado su transición a las metodologías ágiles. El resultado más visible es que hacen ‘sprints‘ de tres o cuatro semanas, pero los incrementos de productividad siguen siendo una promesa. Los proyectos continúan con sus dinámicas previas.
Y tiene sentido. ¿Por qué hacer el mismo trabajo en bloques de tres semanas va a mejorar la productividad? Scrum es mucho mas que sprints o tableros con post-it.
Estos son los errores más habituales al implantar Scrum:
1. No subir los desarrollos a producción después de cada sprint.
Quizás el error más frecuente y también el más importante. Asume que tu cliente no puede saber lo que quiere y que tendrás que modificar el trabajo realizado. Cuanto antes descubras lo que en realidad necesita, más productivo será el proyecto.
Además, como la inversión económica de un sprint es pequeña y tu cliente utiliza las nuevas funcionalidades en tres semanas, su retorno de inversión -ROI- es mucho más rápido. Música celestial para cualquier CFO.
En las metodologías tradicionales los desarrollos se entregan al final del proyecto. Esto no solo retrasa el ROI. Comienzas las modificaciones cuando ya no queda presupuesto.
La única forma de comprobar que has acertado es poner el software en manos de sus usuarios finales.
2. Obligar a que se finalicen todos los trabajos planificados para el sprint.
El segundo error clásico. Si te has equivocado en el sprint planning y no es viable finalizar los trabajos, ¿cuáles son las posibles opciones?
a) Puedes pedir al equipo que haga un sobreesfuerzo y trabaje más horas.
b) Puedes rebajar la calidad y no hacer las pruebas de regresión.
c) Puedes rebajar el alcance y entregar menos desarrollos.
Por inercia cultural, la mayor parte de los proyectos comienzan por la opción a) y terminan por añadir la opción b). Scrum establece que la respuesta mas apropiada es la c).
Buena parte de los incrementos de productividad asociados a Scrum proceden de eliminar la presión de trabajo de los consultores.
3. No tener un Product Owner integrado en el equipo.
El Product Owner es una figura esencial en Scrum, y es otra de las vías del incremento de productividad.
Los programadores trabajan sin una especificación detallada, así que constantemente tienen dudas sobre la funcionalidad a desarrollar. Es necesario que alguien procedente del cliente les explique las Historias de Usuario.
El Product Owner es también el guardián del ROI. No sabe programar, pero entiende el valor que aporta cada Historia al negocio. Si prioriza adecuadamente los desarrollos, conseguirá un mayor retorno de inversión en cada iteración.
Si el Product Owner no está con su squad, los programadores no interpretan bien las Historias, las modificaciones son más frecuentes y el valor para el negocio de cada sprint es menor.
¿Hay más errores típicos?
Aunque estos sean los tres errores más frecuentes al implantar Scrum, hay otros muchos que puedes cometer. Sin ánimo de ser exhaustivos:
Hacer una especificación pesada.
En Scrum se pasa de una idea de alto nivel al desarrollo que hacen los programadores. ¿Para que emplear meses en una especificación detallada si damos por sentado que el cliente no puede saber lo que quiere?
Solicitar que el cliente valide la especificación.
Aunque el cliente firme la especificación, sigue sin ser lo que necesita. Y lo sabe. Tu equipo puede estar valiosas semanas esperando a que el cliente dé su consentimiento. ¿No es mejor emplearlas en desarrollar un prototipo?
Mantener las jerarquías dentro de los equipos.
Ni el Jefe de Proyecto se transforma en Product Owner ni el Líder Técnico en Scrum Master. La figura del Líder Técnico desaparece. Los programadores colaboran desde un plano de igualdad y ninguno impone su criterio a los demás.
El Jefe de Proyecto también se difumina porque ya no es necesario negociar alcance y plazo de cada desarrollo.
No automatizar las pruebas a la vez que se hacen los desarrollos.
Si no automatizas las pruebas, ¿cómo piensas hacer DevOps? No podrás hacer pruebas de regresión y con cada sprint tus desarrollos tendrán menor calidad.
Tener a los equipos separados geográficamente.
No es solo que no puedan hacer el daily. Recuerda que los equipos están creando la especificación a la vez que hacen el desarrollo. Si están separados ¿cómo van a construir ese conocimiento?
No hacer retrospective.
Celebrar los éxitos del sprint y analizar los puntos de mejora aporta cohesión y les permite crecer como equipo. Potencia estos momentos de reflexión para que crezcan en la aplicación de la metodología.
Algunas reflexiones finales
Si has llegado hasta aquí, es porque te interesa la ingeniería del software. Te dejo algunas reflexiones y enlaces para que prosigas tu crecimiento.
Lo primero que debes entender es que el software es diferente al resto de disciplinas de la ingeniería por muchos motivos. Quizás los dos más importantes son:
- Es mucho más complejo describir el comportamiento de un sistema software que de cualquier otro sistema ideado por ingenieros, ya sea un vehículo eléctrico, un puente, un edificio o un compuesto químico. Por eso decimos que el cliente no puede saber lo que quiere.
- No tenemos un lenguaje de alta precisión para describir el software. Por contra, el resto de ramas de la ingeniería disponen de los planos, las matemáticas y la física. Por eso decimos que el cliente no puede decirnos lo que quiere.
No es de extrañar que la tasa de fracaso de los grandes proyectos de software sea del 80%. Esta cifra se mantiene estable desde los años 70. Y es el motivo de la aparición de Scrum.
Así que olvídate de gestionar los desarrollos informáticos como si fueras un ingeniero. Quema tu apuntes de ITIL. Necesitas un enfoque que incluya la psicología. Tu punto de partida es Peopleware, de Tom de Marco. Puedes acceder a su ficha en la wikipedia haciendo click sobre estas palabras verdes.
En novanotio explicamos a nuestros consultores estos conceptos que necesitarán a lo largo de su carrera profesional. Si la gestión de proyectos o el liderazgo de equipos despiertan tu curiosidad, quizás quieras descubrir nuestro proceso de mentoring Novanotio Certified.
Tal vez sea un buen momento para incorporarte a uno de nuestros proyectos y establecer los cimientos de tu carrera con nuestro proceso de mentoring. Este enlace te lleva a algunas de nuestras ofertas de trabajo, espero que encuentres una perfecta para ti.
Carreras profesionales. El Especialista Tecnológico
Carreras profesionales. El Especialista Tecnológico.
Una de las posibles carreras profesionales dentro de la informática es convertirse en un gurú de la tecnología. Seguir vinculado a la consola y el Eclipse pasando por las sucesivas etapas de Becario, Consultor Junior, Consultor Senior y, finalmente, Especialista Tecnológico.
Nunca te va a faltar trabajo
Lo más agradecido de este recorrido es que no te van a faltar oportunidades laborales, sino mas bien al contrario.
En la parte expansiva del ciclo económico recibirás una docena de propuestas semanales. En las recesiones dos o tres al mes. Pero nunca te van a faltar esas ofertas que te aportan algo fundamental, la tranquilidad de saber que siempre tendrás trabajo.
Según cumplas años ‘manchándote las manos’, aumentará la presión para que saltes a la gestión. Como un electrón en un campo electromagnético. Alguien debe liderar a los ingenieros más jóvenes y tu tienes los conocimientos precisos. Necesitarás una férrea voluntad para no sucumbir a los cantos de sirena que susurran magníficos salarios, amplios despachos, potentes coches de empresa y títulos que comienzan por C en las tarjetas.
El techo de cristal
Si tu intención es firme y decides recorrer el camino del conocimiento, más temprano que tarde vas a tropezar con el techo de cristal. Tu salario se estancará y tu empleabilidad disminuirá. ¿Por qué puede ocurrirle esto al consultor más rentable de la organización? La explicación la encontramos en la metodología Scrum y en el modelo de servicios.
¿Recuerdas la primera ley? ¿Las especificaciones son inciertas, imprecisas y, sobre todo, infinitas? Cuando cliente y proveedor firman un proyecto ‘llave en mano’, se condenan a negociar sine die el significado de cada funcionalidad y el coste de cada modificación. Es un esfuerzo agotador para ambas partes, que, como en un matrimonio disfuncional, se sienten rehenes la una de la otra.
Las alternativas son la metodología Scrum y el Modelo de Servicios. En ambos casos, se contrata un grupo de N consultores a cambio de E euros mensuales. Y en ambos modelos el alcance queda indeterminado. Así desaparece buena parte de ese esfuerzo de negociación.
Para el cliente el coste es conocido y constante. E euros mensuales. Para el proveedor los ingresos son constantes, E/N euros mensuales por consultor.
Debido a su simplicidad, ambos enfoques se utilizan de forma intensiva en todo el mundo. Pero fíjate que en los dos casos, la rentabilidad de cada consultor disminuye cuanto mayor sea su salario. Una vez que el servicio está en marcha, la tentación de sustituir Especialistas Tecnológicos por Becarios es muy poderosa.
Cómo evitar el techo de cristal
Si entre todas las carreras profesionales has decidido convertirte en Especialista Tecnológico, existen algunas alternativas para esquivar el techo de cristal.
La primera es orientarse a tecnologías hype, con alta especialización y fuerte crecimiento. Como no hay Becarios para hacer el trabajo, la demanda transforma el techo de cristal en un techo elástico. Ciberseguridad, integración continua, microservicios o inteligencia artificial son buenos ejemplos.
Otra posible solución es buscar empresas que desarrollan productos, porque aquí los ingenieros con mayor productividad si que son los más rentables.
Por último está la posibilidad, cada vez más compleja, de buscar oportunidades en países con economías mas potentes.
Con ayuda de Glassdoor puedes comprobar que, en España, la banda salarial para los Consultores Senior está en 40-45 K . Solo en empresas de producto, como Amazon, Ericson, Amadeus o Microsoft, encontramos ofertas en el rango de 55-70 K. Sin embargo en EEUU los salarios para los Especialistas Tecnológicos llegan hasta los 220 K.
Construir equipos de alto rendimiento usando el test de Gallup
Construir equipos de alto rendimiento usando el test de Gallup.
El test de fortalezas de Gallup puede ayudarte a construir equipos de alto rendimiento.
Un equipo de alto rendimiento tan solo es un grupo de consultores que trabajan con confianza. Personas normales que consiguen resultados extraordinarios. En este post descubriremos cómo usar el resultado del test de fortalezas de Gallup para diseñar los equipos. No siempre el mejor programador se transformará en un buen Jefe de Proyecto.
Tipos de consultores
El test de fortalezas de Gallup distingue entre 34 tipos de talento, que se agrupan en cuatro ámbitos; pensamiento, relación, ejecución e influencia. Hay por tanto cuatro tipos básicos de consultores tecnológicos, y como en Hogwarts, mejor si los combinas en un determinado orden y proporción.
Los consultores con fortalezas de pensamiento son los más abundantes en tecnología. Antes se les llamaba soñadores, ahora se les llama gurús. Sienten curiosidad y ganas de aprender, pero les cuesta madrugar, solo son productivos cuatro horas al día y les aburren las tareas repetitivas.
Los consultores con fortalezas de ejecución son igualmente frecuentes. Antes se les llamaba diligentes, ahora se les llama machacas. Les gusta madrugar, son incansables, ejecutan con precisión tareas repetitivas y les encantan los procedimientos.
Los consultores con fortalezas de relación son algo menos frecuentes en nuestro entorno tecnológico. Antes se les llamaba dicharacheros, ahora se les llama soporte de nivel uno y dos. Se les reconoce porque siempre tienen un tema del que hablar, generalmente relacionado con personas. No sienten la curiosidad de los pensadores ni son incansables como los ejecutores, pero aportan cohesión al equipo.
Por último los consultores de influencia son los menos comunes. Antes se les llamaba trepas, ahora se les llama trepas. No son brillantes como los pensadores ni eficientes como los ejecutores, pero escuchándoles se diría que hacen el trabajo de todos ellos. Tienen montones de conocidos y la palabra adecuada siempre en la boca.
¿A quien elegir como Jefe de Proyecto?
El Jefe de Proyecto es un perfil de gestión, sus funciones son atender al cliente y motivar a su equipo. ¿Quiénes son los mejores candidatos?
La decisión más habitual es promocionar a los consultores de pensamiento. Por su curiosidad y su facilidad para adquirir nuevos conocimientos harán un buen trabajo en cualquier rol. Aunque cuidado, les cuesta tomar decisiones. La parálisis por análisis es su talón de Aquiles.
Los consultores de ejecución también son una buena opción. Son incansables, soportan el estrés y las jornadas interminables. ¿Su punto débil? Creen que todos deben ser incansables como él. ¿Os acordáis de la tercera ley? ¿Presión x Talento = Constante? Ellos son La Presión, y pueden destruir el talento del equipo.
Los consultores de relación son la elección menos habitual. No son brillantes como los de pensamiento ni incansables como los de ejecución. Si los promocionas a Jefe de Proyecto, gestionarán sobre todo el ambiente de trabajo.
Pero la decisión más sabia es elegir a los consultores de influencia, porque saben lo que conviene decir en cada situación. Vale, no son los mejores técnicos. Pero el Jefe de Proyecto no es un rol técnico. En el mundo empresarial, tener razón es irrelevante. Lo importante es que te den la razón.
Combinaciones potencialmente inestables:
Hay combinaciones potencialmente inestables que debes evitar a toda costa.
La más habitual es Jefe de Proyecto de pensamiento y consultor de influencia. Uno tiene los conocimientos para liderar, el otro ha nacido para liderar. Uno tiene razón, al otro le dan la razón. Cuando haces esta combinación, se desata una guerra que siempre gana el consultor de influencia.
Sin embargo, la combinación Jefe de Proyecto de influencia y consultor de pensamiento es invencible.
Otra combinación explosiva es Jefe de Proyecto de ejecución y consultor de pensamiento. El primero se queja de la falta de compromiso, el segundo de que van en la dirección equivocada. Prepárate para escuchar quejas sin fin.
La combinación de consultores de pensamiento y ejecución funciona muy bien cuando el primero de ellos es el Líder Técnico.
La burocracia destruye los equipos de alto rendimiento
La burocracia destruye los equipos de alto rendimiento.
Construir Vs destruir
La burocracia destruye los equipos de alto rendimiento.
Construir equipos de alto rendimiento (EAR) es una tarea compleja. Existen varias aproximaciones para que personas con diferentes intereses trabajen con confianza y consigan resultados sobresalientes. Pero ninguno de estos métodos garantiza el éxito.
Sin embargo, destruir equipos de alto rendimiento es una tarea sencilla que las empresas suelen dominar. Existen al menos diez efectivos EARicidas. Y la burocracia es uno de los más poderosos.
Desde la primera edición de Peopleware, en el año 1.987, sabemos cómo la burocracia afecta a los grupos de desarrollo. Os recomendamos leer el capítulo Teamicide, que describe los efectos de dedicar tu tiempo a empujar papeles.
Un procedimiento tiene cinco significados
Con cada procedimiento la empresa nos transmite cinco mensajes:
- Una vez pasó algo, que tuvo un impacto negativo en la empresa, y no queremos que se repita.
- Los más listos de la empresa, es decir, la dirección, hemos ideado este procedimiento. Es definitivamente la mejor forma de hacer las cosas.
- No te pagamos para pensar, te pagamos para que trabajes. Sigue el procedimiento.
- No confiamos en ti.
- Porque no tienes talento.
Algunos ejemplos de Burocracia en acción
Estos son algunos casos que he conocido de primera mano.
Hace unos años, un consultor se quedó con el equipo informático cuando cambió de trabajo. Ahora todos los consultores deben firmar un recibí cada vez que les entregamos material. Una vez pasó algo y no queremos que se repita.
Antonio necesitaba pagar con tarjeta de crédito un servicio web de 50 € al año. Su empresa le explicó el procedimiento. Debía tramitar un pedido a través de la plataforma de compras, pedir tres ofertas y los pagos se hacen a noventa días mediante transferencia. Ya hemos pensado la mejor forma de hacer esto. (Por supuesto lo pagamos nosotros y resolvimos el problema en diez minutos).
Carlos necesitaba una mochila para transportar su ordenador portátil. La bandolera que le había proporcionado su empresa le hacía daño en la espalda. Prepararon un procedimiento ad-hoc para su caso, debía aportar un justificante médico. No confiamos en ti.
Pablo necesitaba urgentemente un entorno de pruebas, pero había un procedimiento: Debía solicitar a la central de Alemania una máquina virtual con una configuración estándar. No podía instalar nuevo software ni hacer pruebas para optimizar el rendimiento. No te pagamos para que pienses.
Jorge tenía problemas para avanzar con el desarrollo. Las especificaciones eran imprecisas y algunas sentencias SQL no tenían sentido. Solo necesitaba hablar unos minutos con el cliente, pero había un procedimiento: El Solutions Architect trasladaba la consulta al Account Manager, y el Business Analyst se reunía con el cliente. Tu no tienes talento.
La burocracia incumple la tercera ley
Hemos hablado en varias ocasiones de las cuatro leyes, esas 35 palabras que guardan casi todo lo que debes saber para gestionar proyectos informáticos.
La tercera ley dice Presión x Talento = Constante. Es decir, debes elegir entre maximizar la presión o maximizar el talento.
Mientras en buena parte de las actividades empresariales es conveniente gestionar la presión, en el ámbito de la tecnología necesitas maximizar el talento.
Y la burocracia, ¿mejora la presión o mejora el talento? Si has leído con atención hasta aquí, la respuesta es sencilla. La burocracia genera una carga de trabajo innecesaria (presión) porque asume que no tienes talento. La burocracia es por tanto similar a los bonus por objetivos o a los incrementos de jornada laboral. Formas de presión que destruyen el talento.
Las Buenas Prácticas
Sin embargo, no es económicamente viable reinventar la rueda cada vez que realizamos una actividad. Es necesario un mecanismo que busque la eficiencia pero que se apoye en el talento de los profesionales. Y la respuesta son las Buenas Prácticas.
Las Buenas Prácticas tienen el siguiente enunciado: ‘Ésta forma de hacer las cosas se ha demostrado que funciona y recomendamos su uso. Eres libre de buscar formas más eficientes de hacer el trabajo porque no eres tonto y confiamos en tu talento. Junto con nuestra confianza te damos el derecho a equivocarte de vez en cuando y la obligación de trasladar tu conocimiento al resto de la organización‘.
Este enfoque persigue el mismo objetivo que los procedimientos, realizar el trabajo de forma homogénea y eficiente. Sin embargo refuerza la tercera ley porque se apoya en el Talento de los consultores.
Las fuentes
Si te interesa el tema, te aconsejo acudir a las fuentes. Además del mencionado Peopleware, te recomendamos ‘El japonés que estrelló un tren para ganar tiempo’ de Gabriel Ginebra y ‘Rework’ de Jason Fried.
Si quieres ayudar a la comunidad IT, puedes comentar algunos de los procedimientos de tu empresa y cómo te afectan en tu trabajo.