¿Por qué SCRUM es más eficiente que las metodologías tradicionales Waterfall (II)?

¿Por qué SCRUM es más eficiente que las metodologías tradicionales Waterfall (II)?

En la primera parte de este artículo explicamos cómo algunas empresas tecnológicas implantan SCRUM sin conocer sus fundamentos. Adoptan los ritos de la metodología como el daily o los sprints pero no obtienen las mejoras de productividad prometidas.

En esta segunda parte vamos a explicar de dónde proceden los [celebrados | cacareados | esquivos] beneficios de SCRUM y cuál es el cambio de paradigma que proponen las metodologías ágiles.

SCRUM es una implementación de las Cuatro Leyes

Los beneficios de Scrum se derivan de que cumple las Cuatro Leyes Básicas de la gestión de proyectos tecnológicos. Por eso es más eficiente que las metodologías clásicas de desarrollo en cascada o Waterfall, que no cumplen ninguna de ellas.

Recuerda que hay otras implementaciones de las Cuatro Leyes como XP (extreme programming), que aportan mejoras de productividad similares.

El cambio de paradigma que propone Scrum es que proveedor y cliente asumen que lo construido es lo mejor que se puede hacer con el plazo y el presupuesto disponible.

SCRUM cumple la 1ª ley.

Las especificaciones son inciertas, imprecisas e infinitas.

La primera ley nos advierte tres cosas:

– Que el tiempo empleado en especificar es, en general, tiempo perdido

– Que la única interpretación válida de la especificación es la del cliente.

– Que no es posible finalizar los trabajos.

¿Como responde Scrum a estos tres desafíos?

– En Scrum el diseño es muy liviano; los principales requisitos se capturan en Epics y Features, cuya extensión es de un párrafo. Epics y Features se descomponen en Historias de Usuario cuya extensión es de una sola línea. El tiempo que se ahorra en la especificación se dedica a desarrollar código, sabiendo que tendremos que modificarlo cuando se lo presentemos al cliente.

– Se incorpora al squad un representante del cliente, el Product Owner, cuya misión es ayudar a los programadores a interpretar las historias de usuario.

– El cliente asume que no se concluirán los desarrollos, pero el Product Owner se asegura de que el software construido resuelva sus principales necesidades.

SCRUM cumple la 2ª ley.

One Project, One Team, One Site.

La segunda ley nos instruye sobre la importancia de construir vínculos emocionales y relaciones de confianza.

Y la mejor forma de construir vínculos y relaciones es mediante el contacto diario y la dedicación exclusiva.

¿Cómo construye Scrum vínculos y relaciones?

En Scrum los equipos de desarrollo están formados por entre cinco y nueve consultores, cuyos puestos de trabajo están próximos entre sí.

El grupo es autosuficiente para hacer sus tareas e incluye a programadores, testers y en caso necesario arquitectos de sistemas o administradores de BBDD.

El Product Owner es un miembro más del equipo, y está junto a ellos toda la jornada para ayudarles a interpretar las historias de usuario.

SCRUM cumple la 3ª ley.

Presión x Talento = Constante.

La tercera ley nos recuerda que la velocidad de avance de los desarrollos sólo depende del número de ideas que aporten los consultores del equipo, y no del número de integrantes ni del número de horas de su jornada.

Para que florezca el talento es necesario rebajar la presión. Se ha demostrado que un incremento de la jornada de trabajo produce un retraso de los desarrollos y, sin embargo, reducir la jornada a cinco horas diarias puede lograr incrementos de productividad del 30%.

¿Cómo elimina Scrum la presión?

En Scrum no es obligatorio completar todas las Historias planificadas para el sprint.

Aunque buena parte de los desarrollos se finalicen y superen los test, en muchas ocasiones al acabar el sprint habrá desarrollos a medias o que no superen las pruebas. Estos trabajos vuelven al team backlog y se abordarán (o no) en siguientes sprints.

SCRUM cumple 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 necesariamente se degrada.

Así que como cliente debes elegir entre

– Sacrificar el Alcance y entender que ciertas funcionalidades nunca se desarrollarán.

– Sacrificar el Plazo (y multiplicar el coste) y asumir que el sistema siempre estará en desarrollo.

– Sacrificar la Calidad, y aceptar que te entregarán un sistema apenas probado, con constantes errores en producción y difícil de operar.

En las metodologías tradicionales de desarrollo en cascada, se fijan por contrato Alcance, Plazo y Calidad. ¿El resultado? En el 80% de los proyectos se sacrifican las tres variables simultáneamente. ¿Es posible elegir peor metodología?

¿Qué se degrada al elegir SCRUM?

La metodología SCRUM procura que la única variable sacrificada sea el Alcance.

– El Plazo -y por tanto el presupuesto- se establece en el contrato. El Alcance se deja abierto.

– Para garantizar la Calidad, no se permite entregar desarrollos que no hayan superado sus correspondientes pruebas.

– Para maximizar el retorno de la inversión, el cliente desplaza un Product Owner a los squads para priorizar los desarrollos que aportan más valor a la empresa.

¿Puedo usar las Cuatro Leyes sin necesidad de implementar metodologías ágiles?

Como hemos visto, las ventajas de Scrum se derivan de que cumple las Cuatro Leyes, y no del puntual cumplimiento de sus rituales. Por eso es frecuente que las organizaciones cometan errores en su implementación. Aquí aparece la figura del Scrum Master, que ayuda a realizar con éxito la transición.

También es posible el caso opuesto, puedes usar las Cuatro Leyes aplicando el sentido común, y mejorar los resultados sin necesidad de implementar una metodología de nombre exótico.

Recuerdo mis primeras experiencias de trabajo a comienzos de los años 90, antes de la fundación de novanotio, donde usábamos una metodología que cariñosamente llamábamos ASDM (A Salto De Mata).

Nunca invertimos mucho tiempo en especificar, los compañeros éramos uña y carne, teníamos una fantástica relación con el cliente y nunca nos pidieron trabajar un fin de semana. ASDM se podía resumir en la frase ‘Trata bien a tus consultores y estos harán un gran trabajo’.

Los proyectos funcionaron muy bien hasta que la organización apostó por metodologías formales como CMM, más preocupadas por la especificación que por las personas.

Emplea con sabiduría las Cuatro Leyes y cualquier metodología será la adecuada.


¿Por qué SCRUM es más eficiente que las metodologías tradicionales Waterfall (I)?

¿Por qué SCRUM es más eficiente que las  metodologías tradicionales Waterfall (I)?

SCRUM no es una religión. SCRUM es solo una forma de implementar las Cuatro Leyes Básicas de la gestión de proyectos. 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 seguramente no encontrarás la tierra prometida.

Si impones SCRUM a tu organización 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 oscuros de las cintas magnéticas, los profetas Brooks y DeMarco nos advirtieron que nos enfrentamos a problemas extremadamente complejos en los que podemos trabajar 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

El ritual SCRUM que nos inspiraron es como sigue:

La Sagrada Firma

El  Sumo Account Manager descubre una necesidad del cliente y junto con su acólito el Product Owner, preparan una oferta que tiene plazo y presupuesto definidos pero cuyo alcance queda indeterminado. Realizan 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 productos indeterminados. Es inútil explicarles que en los proyectos realizados según los heréticos ritos de Waterfall, aunque 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, 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 Manager 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 los escuadrones de desarrollo, con un 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 de una parte de la aplicación. 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 van a intentar implementar durante el Sprint, que durará entre tres y cuatro semanas. El Product Owner sabe qué historias de usuario son prioritarias. El squad conoce su velocidad de ejecución.

Cada mañana, antes de la salida del sol, el squad 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 finalizado y apto para entregar al cliente.

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 entrega al cliente y las Historias de Usuario que no se han completado se devuelven al team backlog.

El Sprint Retrospective

La ceremonia final es el Sprint Retrospective. Aquí Product Owner, programadores y testers reconocen sus faltas y hacen propósito de enmienda, con el fin de mejorar su capacidad y ser más productivos en los próximos sprints.

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 vistosos y diferentes de los que desconocemos su significado y son tentadores de imitar.

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

En el siguiente post de esta serie, explicaremos cómo usando las Cuatro Leyes Básicas de la gestión de proyectos, puedes conseguir la productividad de las metodologías ágiles sin necesidad de rituales.


Cómo orientar tu carrera profesional

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

Estás haciendo un gran trabajo, y como premio te han propuesto cambiar de rol. Quizás te han pedido que lideres a un grupo de consultores recién incorporados, o tal vez que acompañes al responsable de cuenta a una reunión de ventas.

Descubrirás que hay actividades que te son tan naturales cómo respirar y otras en las que, a pesar de tu esfuerzo, sólo recibes disgustos. ¿Cómo saber si la jugosa manzana está envenenada?

Para responder a esta pregunta vamos a utilizar 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 cinco 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 eres incapaz de buscar excusas para no completar una tarea, eres un auténtico ejecutor.
  • Fortalezas de pensamiento. ¿Qué es lo que mejor que podemos hacer en este momento? ¿Cuál es la mejor forma de hacerlo? Si no puedes dejar de estudiar o tienes una potente capacidad analítica eres todo un pensador.
  • Fortalezas de relación ¿Cómo construyo vínculos con los demás? Si ves rápidamente 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 que los demás trabajen para mi? Si siempre tienes en la boca la palabra adecuada o te encanta ganarte a la gente, considérate un influencer.

Tras miles de años en que las fortalezas más valoradas eran las de ejecución (agricultura, ganadería) a finales del siglo XX aparece el sector tecnológico, donde, por primera vez en la historia, se necesitan de forma masiva las fortalezas de pensamiento (programadores, analistas, técnicos de sistemas, hackers).

Aunque no todos los roles técnicos precisan de las mismas fortalezas. 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 determinantes, porque facilitan la construcción de las especificaciones y la coordinación de las tareas.

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

Sin embargo, si la mayoría de tus fortalezas 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 sobre todo de relación, busca trabajos donde tengas que estar en contacto con el cliente.  Y si a las fortalezas de relación se suman las de influencia, tu sitio está en el departamento 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!

Para liderar equipos siempre son interesantes las fortalezas de influencia. Cuantas más aparezcan en tu test de Gallup, más cómodo te sentirás con cada ascenso. Descubrirás que buena parte de los directores son perfiles de pensamiento que solo saben decir lo que piensan.

Si la mayoría de tus fortalezas son de influencia, acabarás en la alta dirección. Algunos te llamarán trepa pisacuellos y aunque quizás no eres el mejor técnico, siempre sabes lo que tienes que decir y esas habilidades te llevarán a poner una C en tu cabecera de Linkedin.

Cuando tu trabajo está alineado 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 desgaste personal.

¿Quieres saber que actividades son mas adecuadas para ti? Envíanos el resultado de tu test de fortalezas y te explicaremos cómo acertar al cambiar de rol.


La tragedia del analista programador

El rol de Analista/Programador es la primera promoción dentro de la carrera tecnológica, y es una trampa que debes conocer.

Con un poco de paciencia, en dos o tres años serás el programador más veterano dentro de un grupo de cinco o seis consultores, lo que te convierte de facto en su Líder Técnico. Aquí aparece el primer dilema de los profesionales del mundo IT.

¿Dedico mi tiempo a realizar mi [importante] trabajo técnico o a formar a los recién incorporados?

Existen tres soluciones posibles:

1. Dedicas la mayor parte de tu tiempo a realizar tu [crítico] trabajo técnico y sólo ratos sueltos a dar soporte a los nuevos. Éstos aprenden lentamente ya que no puedes encargarles tareas complejas. Es el caso más habitual, representado en la gráfica por la línea roja. Conseguirás una alta rotación entre los recién llegados y mucha presión para que el equipo mejore sus resultados.

2. Haces tu [complejo] trabajo técnico y además dedicas mucho tiempo a formar a los nuevos. El volumen de horas necesario para realizar ambas tareas te llevará a presentar la baja voluntaria o la baja por depresión.

3. Dedicas la mayor parte de tu tiempo a formar a los nuevos consultores hasta que son capaces de trabajar con autonomía. Es el caso menos habitual, representado en la gráfica por la línea verde. El equipo tendrá resultados pobres durante los primeros meses pero a largo plazo construirás un Equipo de Alto Rendimiento. Si consigues soportar la presión, claro.

La gráfica presenta los resultados obtenidos por un equipo siguiendo las diferentes estrategias.

Como puedes ver, las tres estrategias ofrecen resultados que están por debajo de las expectativas del cliente, lo que se traduce en presión; retrasos, lista de tareas pendientes que tiende a infinito y tensas reuniones con el cliente.

En siguientes post estudiaremos estrategias que consiguen resultados que superan las expectativas del cliente. Y también veremos los nuevos problemas que eso genera.


Los tres errores más comunes al implantar Scrum

¿Cuales son los principales errores que se cometen al implantar Scrum?

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

Y tiene sentido, ¿por qué hacer el mismo trabajo en bloques de tres semanas iba a mejorar la productividad? Scrum es mucho mas que hacer sprints o un tablero lleno de post-it. Vamos a repasar los errores más comunes que se cometen en estas primeras experiencias.

1. No subir los desarrollos a producción después de cada sprint.

Quizás el error más recurrente y también el más importante. Asume que tu cliente no sabe 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. En la metodología tradicional se muestran los resultados al final del proyecto y se comienzan las modificaciones cuando ya no queda presupuesto.

Además, como la inversión económica de un sprint es pequeña y tu cliente utiliza las nuevas funcionalidades antes, su retorno de inversión -ROI- es mucho más rápido, música celestial para cualquier CFO.

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 clásico. Si te has equivocado en la estimación y no es viable finalizar los trabajos, ¿cuales son las posibles opciones?

a) Puedes pedir al equipo que haga un sobreesfuerzo y trabaje más horas.

b) Puedes rebajar la calidad y entregar algo que parece que funciona, pero sin hacer pruebas de regresión.

c)  Puedes rebajar el alcance y hacer menos funciones.

Debido a la inercia cultural, la mayor parte de los proyectos comienzan por la opción a) y terminan por b). Sin embargo Scrum establece que la respuesta correcta es la c).

Una parte de los incrementos de productividad en Scrum proceden de eliminar la presión de trabajo de los consultores. Otra parte se consigue con menos incidencias en producción.

3. No tener un Product Owner integrado en el equipo.

El Product Owner es una figura clave en Scrum y al él se debe también una parte del incremento de productividad.

Los programadores trabajan sin una especificación detallada, así que constantemente tendrán dudas sobre la funcionalidad a desarrollar. Es imprescindible que alguien familiarizado con el negocio esté con ellos durante todo el proceso de desarrollo.

Además el Product Owner es el guardián del funcional, quizás no sabe programar pero entiende el valor añadido que aporta cada función al negocio. Si es capaz de priorizar dentro del sprint aquellos desarrollos que aportan más valor, conseguirá un retorno de inversión más rápido en cada iteración.

Si el Product Owner no está integrado en el equipo, los programadores serán más lentos, las modificaciones a lo ya desarrollado serán más frecuentes y el valor para el negocio de cada sprint será menor.

Aunque estos sean los tres errores más habituales e importantes, hay otros muchos que se pueden cometer al comenzar a implantar Scrum. Sin ánimo de ser exhaustivos:

- Hacer una especificación pesada. En Scrum se pasa de una idea de alto nivel a la especificación de detalle que hacen los programadores. ¿Para que emplear meses en una especificación de bajo nivel si damos por sentado que el cliente no sabe lo que quiere?

- Solicitar que el cliente valide la especificación. Aunque firme la especificación, sigue sin ser lo que necesita, y lo sabe. Tu equipo puede estar varias semanas de brazos cruzados antes de que el cliente de su consentimiento. ¿No es mejor emplearlas en presentarle una parte del desarrollo?

- Mantener las jeraquías dentro de los equipos. Ni el Jefe de Proyecto se transforma en Product Owner ni el Líder Técnico en Scrum Master. De hecho la figura de Líder Técnico desaparece; todos los programadores colaboran desde un plano de igualdad y ninguno puede imponer su criterio a los demás. El Jefe de Proyecto también se difumina; ya no es necesario negociar alcance y plazo de cada desarrollo, el control económico es mucho más sencillo y las funciones de motivación pasan al Scrum Master.

- No automatizar las pruebas a la vez que se hacen los desarrollos. Esto impedirá hacer pruebas de regresión y los sprints tendrán paulatinamente menos calidad, o menos funcionalidad. Si no automatizas las pruebas, ¿cómo piensas hacer DevOps?

- Tener a los equipos separados geográficamente. Recuerda que los equipos están creando la especificación mientras hacen el desarrollo. Si están separados ¿cómo van a transmitirse este conocimiento?

- No hacer retrospective. Celebrar los éxitos del sprint y analizar los puntos de mejora aporta cohesión y les permite crecer como equipo. Si no hay estos espacios para la reflexión, ¿cómo van a mejorar en la aplicación de la metodología?


Las carreras profesionales dentro del mundo de la tecnología se netrelazan entre si y son transversales unas a otras

Las cuatro carreras profesionales en la tecnología

Las cuatro carreras profesionales en el mundo de la tecnología

Analizamos en este [extenso] post las cuatro posibles carreras profesionales dentro del ámbito de la tecnología:

Las ventas (lo que decimos al cliente que haremos)

La gestión pura (lo que haremos en realidad).

El liderazgo tecnológico (cómo lo vamos a hacer)

La tecnología pura (ya lo hago yo).

Las recorreremos en orden inverso al expuesto. Veamos que aspecto tienen las escaleras del éxito de un programador y qué puedes esperar de cada peldaño. Recuerda la regla de oro, a mayor responsabilidad, menor empleabilidad.

La carrera tecnológica pura

Becario.

Eres la pesadilla del departamento, no solo no sabes hacer nada sino que retrasas a todo el mundo con tus preguntas. Hasta las tareas mas simples requieren en tu caso horas de explicación y seguimiento. Lo normal es que rompas más cosas de las que arreglas. Para colmo de males, es posible que tu salario supere al de algún senior.

Si eres bueno en las relaciones sociales al menos no te retirarán el saludo. Si además eres rápido aprendiendo en tres o cuatro meses te convertirás en…

Consultor Junior.

Aquí empieza la diversión, disfrútala porque no dura mucho. Cada día mejoras y eres capaz de completar tareas más complejas. Comienzas a entender el funcional y la arquitectura de la aplicación. Tus horas son productivas y cada día te vas a casa con la sensación del deber cumplido. Te llueven las ofertas, si te quedas es porque tu salario es adecuado, te caen bien los compañeros y el Jefe de Proyecto no es un cretino.

¿Puedes creerlo? En tan solo dos o tres años ya eres

Consultor Senior.

Diversión a lo grande, haces cosas increíbles y todavía te queda un mundo por aprender. Confían en ti para los fragmentos más complejos del proyecto, recibes docenas de ofertas cada día y tu salario no para de crecer. Final de la fiesta.

Un día aparecen tres becarios y te dicen ‘hazte cargo de ellos’. ¿Que vas a responder?

Para seguir creciendo en la carrera tecnológica debes decir NO; no quiero becarios, no quiero responsabilidad, no quiero más peldaños. Con tiempo y firmeza te conviertes en

 Especialista Tecnológico.

Un auténticos gurú, cada línea de tu código es una sentencia de muerte para un problema. Si el dinero no está en el top-ten de tus preocupaciones, puedes vivir una vida estimulante y sentirte útil mas allá los treinta.

Pero ten cuidado. A pesar de que eres el recurso más productivo de la empresa, tus mayores solo ven tu coste. Un día aparecerá un becario a tu lado para aprender esas cositas que tu sabes hacer.

Los líderes técnicos

Pero si tomas a tu cargo a esos becarios te conviertes en

Analista/Programador.

Lo primero que tendrás que decidir es si haces tu trabajo, esos fragmentos de código complejos, o les ayudas a hacer el suyo, esas tareas rutinarias que tu harías en diez minutos y a ellos les llevará toda la semana. No te sorprendas si encima alguno de ellos gana más que tú.

En un mercado donde la permanencia media en una empresa es de dos años, si tienes paciencia acabarás siendo el

 Líder Técnico

de un proyecto. Como Líder Técnico eres culpable de todo lo que sale mal y se te retribuye en consecuencia. Cada retraso en las entregas, cada error en producción, cada funcionalidad que rechaza el cliente,  son tu responsabilidad. No es de extrañar que esta figura se esté difuminando y haya desaparecido por completo en la metodología Scrum.

El último peldaño dentro del liderazgo técnico recibe diferentes nombres; CIO para el responsable último de los equipos de desarrollo y pruebas, CTO para los de integración y operación y CISO para los de ciberseguridad. Parecen puestos hechos para ingenieros pero en realidad son posiciones para serpientes (la C es de cobra).

CIO [Career Is Over]

Es una figura fundamental en empresas no tecnológicas. Su responsabilidad es conocer la operación de la organización y desarrollar sistemas que apoyen a los procesos de negocio.

En teoría es responsable de la transformación digital pero seamos sinceros. La transformación digital consiste en que dos chavales de California reciben varios millones de dólares para [reventar | reinventar] todo un sector económico con una app. Hay miles de libros sobre este tema, mi recomendación es ‘Exponential Organizations

Su carrera termina cuando los departamentos de ventas y operaciones culpan a los sistemas del bajo rendimiento de la empresa.

CTO [Career Terminated OnSystemDown]

Es una pieza clave de las empresas tecnológicas. Se encarga de determinar los productos, arquitecturas y nubes que se van a utilizar en los desarrollos, la integración y el despliegue.

Como constantemente aparecen nuevos productos su labor tiene algo de brujería; probarlos todos y acertar con aquellos que se convertirán en un estándar.

En las empresas no tecnológicas el CTO se encarga de la implantación y soporte de los sistemas que ha desarrollado el CIO. Cómo están mal desarrollados, poco probados y pésimamente documentados, su vida puede ser un infierno. Si queréis haceros una idea leed la novela ‘El proyecto Phoenix‘.

CISO [Career Is Suddenly Over]

Se encarga de las tareas relacionadas con la ciberseguridad. No es la figura romántica que analiza  tramas TCP/IP para descubrir ataques de una potencia extranjera. La ciberseguridad tiene mucho que ver con el cumplimiento de aburridas normativas, la preparación de pesados informes de evidencias y el despliegue de herramientas que dan millones de falsos positivos.

Tu carrera profesional termina de manera fulminante cuando un ataque de Ramsonware bloquea las operaciones de tu empresa.

La carrera de ventas

Hay una leyenda urbana que dice que los mejores ingenieros vienen sin interfaz de comunicaciones voz. Hacemos cientos de entrevistas al año y algo hay de cierto. Si tienes un discurso fácil y eres capaz de recordar nombres y caras, seguramente acabarás en el área comercial. Siéntete orgulloso, en una empresa no pasa nada hasta que alguien vende algo.

Hay dos formas de llegar a las ventas. La primera es aterrizar como

Becario de preventa.

Aquí, más que tecnología necesitas entender cuál es el problema del cliente y pensar en cómo solucionarlo con las herramientas de la casa. Es un puesto muy divertido en el que vas a preparar muchos pilotos y pruebas de concepto. Recuerda que con el 20% del esfuerzo consigues el 80% del resultado, así que vas a construir sistemas casi de verdad con relativamente poco esfuerzo.

La segunda forma de llegar al área de ventas técnicas es desde la posición de Analista/Programador. Un día te dicen ‘acompáñame a visitar al cliente’ y ya no hay marcha atrás.

Business Analyst

Es uno de los puestos más divertidos de nuestro ámbito. Si has resuelto problemas similares durante tu etapa de programador, entiendes mejor que nadie qué es lo que el cliente necesita, y puedes hacer un diseño de alto nivel para que el equipo técnico lo construya.

Si además te han promocionado internamente, sabes de qué son capaces tus compañeros. Si vienes de fuera no tienes ni idea, y acabarás vendiendo soluciones que tu organización no es capaz de construir.

Key Account Manager,

Si permaneces en la organización de ventas el tiempo suficiente, olvidarás todo lo que sabes de tecnología y te dedicarás a recorrer pasillos y tomar cafés buscando oportunidades de negocio. Tu única labor es construir confianza con los clientes para que firmen los contratos sin leer la letra pequeña.

La parte negativa de este puesto es que los objetivos crecen todos los años. Es cuestión de tiempo que no llegues y entonces prometas cualquier plazo y tires los precios para conseguir contratos. Ya se las apañarán los ingenieros, lo primero es tu bonus.

Director Comercial o CBDO – la C también es de cobra-

El jefe de los KAM se llama CBDO [Chief Business Development Officer]. Su labor principal es encontrar nuevos clientes y nuevos servicios que ofrecerles. Es decir, orientar el desarrollo de la organización hacia nuevos nichos de negocio.

Su segunda labor principal es quejarse de que el área técnica es lenta y cara, y de que los sistemas no dan soporte al negocio, por lo que la competencia se lleva los contratos una y otra vez.

La carrera de gestión

A la carrera de gestión se llega también por accidente. Eres Analista/Programador y un día te piden que negocies plazos y precios con el cliente. De la noche a la mañana te conviertes en…

Jefe de Proyecto.

Tu principal y desconocida tarea es decir NO a los clientes; no lo haremos en este plazo, no lo haremos por este dinero, no desarrollaremos esta funcionalidad. Si no sabes decir no, toda la presión caerá sobre tu equipo y te convertirás en un cretino

Eres responsable del resultado económico de los proyectos y te retribuirán como si tirases cada línea de código. Tienes suerte. Si tu salario fuera proporcional a los resultados, la mayor parte de las veces tendrías que poner dinero de tu bolsillo.

Las tareas de un proyecto son infinitas, así que, para obtener rentabilidad, necesitas que el cliente abone todas las facturas cuando sólo le has entregado la mitad del proyecto. O bueno, pedir a tu equipo que trabaje doce horas al día, lo del cretino del párrafo anterior.

Si no has quemado muchos clientes, y no has reventado demasiados equipos, es posible que llegues a ser el jefe de los Jefes de Proyecto.

Gerente

Tu misión ahora es imputar los costes de los proyectos deficitarios a los proyectos que sí tienen presupuesto, que son los que aún no han comenzado. También presionas a los Jefes de Proyecto para que entreguen de una vez todo lo que queda pendiente. Por último, identificas a los consultores más caros y buscas becarios que puedan hacer su trabajo por una fracción del coste.

Siempre estás en la cuerda floja y hace años que no recibes ofertas de trabajo, así que desarrollas el talento STC; pase lo que pase, Salvar Tu Culo.

Si eres realmente hábil en STC, puede que llegues a director de operaciones.

COO

Para los no iniciados, el área de operaciones son los que hacen de verdad el trabajo de la empresa. El resto son áreas de apoyo; RRHH y administración, conocidos como back-office, y marketing y ventas, conocidos como desarrollo de negocio.

Tu trabajo consiste en averiguar por qué todos los proyectos van retrasados y en promocionar a Gerentes y Jefes de Proyecto a aquellos programadores que destacan en STC.

Tu enemigo es el departamento de desarrollo de negocio, esos cretinos que firman proyectos a precios ridículos con plazos imposibles. Por su culpa, los equipos de ingeniería tendrán que trabajar doce horas al día.  Si todo sale mal, siempre se puede echar la culpa al CIO o al CTO.

Eres el responsable del margen bruto de la empresa y te van a pagar como si escribieras cada función en Java, configurases cada firewall y desplegaras cada Kubernetes.

Si tienes contactos, es posible que llegues a

CEO, Presidente Ejecutivo o Consejero Delegado. 

Si como COO eres responsable del margen bruto, como CEO eres responsable del resultado neto de la organización, y te retribuyen como si hicieras toooodo el trabajo.

No solo tu salario es el más alto, en los últimos tiempos se ha disparado frente al salario medio de la plantilla.

En teoría tu responsabilidad es establecer la visión y misión de la organización; qué hacemos, cómo lo hacemos, por qué lo hacemos, en que somos diferentes.

La realidad es que intentas que el margen bruto del área de operaciones, cubra los gastos de las áreas de apoyo y deje un beneficio adecuado.

Si el EBITDA no es suficiente, ¿vas a despedir a los vendedores? ¿Despedir a los que pagan las nóminas y gestionan las facturas? Parece que tu única alternativa es hablar con el COO para que reduzca el coste de los consultores.

A mayor responsabilidad, menor empleabilidad.


El especialista tecnológico y el techo de cristal

Una posible carrera profesional 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.

 

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 ofertas semanales y en las recesiones quizás una docena al año. Pero nunca te van a faltar esas llamadas que te aportan algo fundamental: La tranquilidad de saber que siempre tendrás trabajo.

 

Según cumplas años ‘manchándote las manos’, se incrementará la presión para que saltes al mundo de la gestión. Considérate un electrón dentro de un potente campo electromagnético. Alguien debe guiar a los ingenieros más jóvenes, y los líderes técnicos y jefes de proyecto renuncian de forma regular. Continuamente aparecen huecos dentro de tu organización. Necesitarás una férrea voluntad para no escuchar los cantos de sirena que hablan de salarios, despachos, coches de empresa y pomposos títulos en trozos de cartón.

 

Si eres fiel a ti mismo y decides seguir el camino del conocimiento puro, 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 que es, posiblemente, el consultor más rentable de la organización? La explicación está en el modelo de servicios.

 

Debido a las peculiaridades de la informática, cuando un cliente contrata un desarrollo ‘llave en mano’, se condena a discutir con el proveedor durante meses sin fin el significado de cada requisito 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.

 

La alternativa es contratar un servicio. Un grupo de N consultores a cambio de E euros mensuales. Así desaparece buena parte de la complejidad; periódicamente se definen qué trabajos se van a abordar, siendo el coste conocido y constante de 12 x E euros anuales. Debido a su simplicidad frente a los esquemas de desarrollo en cascada ‘llave en mano’, el modelo de servicios se utiliza de forma masiva en todo el mundo.

 

 

Nótese que en el modelo de servicios la rentabilidad de cada consultor es E/(N x Salario), es decir, menor cuanto mayores sean los ingresos del consultor. Una vez que el servicio está en marcha, la tentación de sustituir a los especialistas por consultores junior o incluso becarios es muy poderosa.

 

Para evitar el techo de cristal hay algunas alternativas. La primera es orientarse a tecnologías con alta especialización y alta demanda. Como un becario no es capaz de hacer el trabajo, la necesidad de profesionales 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 donde el ingeniero más valioso sea también el más rentable, como las que desarrollan productos. En este caso, además de tu conocimiento técnico, tu organización premiará tu creciente conocimiento funcional. Analizando nuestro sector con ayuda de Glassdoor encontramos que la banda salarial es consistente entre los 20-25 K para los ingenieros junior hasta los 40-45 K para los senior. Solo en empresas de producto como Amazon, Ericson, Amadeus o Microsoft encontramos expertos tecnológicos en el rango de 55-70 K. La sorpresa la encontramos en Job & Talent, donde hemos visto los salarios más altos de la industria. Ten cuidado, la diferencia de potencial intentará arrastrarte hacia posiciones de Product Owner.

 

Por último está la posibilidad, cada vez más compleja, de emigrar a países mas potentes. Con ayuda de glassdoor hemos analizado el mercado americano y los salarios para los desarrolladores se encuentran en la banda de 40 – 220 K$


¿Con quien trabajas mejor?

Hay 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 trabajar ocho 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. No les cuesta madrugar, les encanta cumplir su horario, ejecutan con precisión tareas repetitivas y les encantan los procedimientos.

Los consultores con fortalezas de relación son menos frecuentes, su sitio natural son las ventas no IT. Siempre tienen un tema del que hablar, generalmente conocidos suyos o famosos. No tienen la curiosidad de los pensadores ni ejecutan como los ejecutores, pero son como los neutrones que aportan cohesión -y masa- al átomo.

Por último los consultores de influencia son los menos abundantes porque son las fortalezas menos comunes. Antes se les llamaba trepas, ahora se les llama víboras. No son brillantes como los pensadores ni eficientes como los ejecutores, pero escuchándoles se diría que hacen el trabajo de ambos. No tienen buenos amigos como los de relación, pero tienen montones de conocidos.

Hay dos combinaciones potencialmente inestables:

Pensamiento e influencia son como el lobo y el lobo. Uno tiene los conocimientos para liderar, el otro sabe que ha nacido para liderar, cuando los combinas en un equipo estalla una guerra que siempre gana la influencia. La combinación influencia-pensamiento funciona cuando el primero de ellos es Jefe de Proyecto.

Pensamiento y ejecución son como la cigarra y la hormiga. Uno es capaz de afrontar nuevos retos, el otro hace la mayor parte del trabajo, si los combinas en un equipo prepárate para escuchar quejas sin fin. La combinación pensamiento-ejecución funciona cuando el primero de ellos es el Líder Técnico.


Cinco formas en que la burocracia destruye Equipos de Alto Rendimiento

Desde la primera edición de Peopleware, en el año 1.987, sabemos que la burocracia es una de las causas de destrucción de Equipos de Alto Rendimiento. Es de obligada lectura el capítulo Teamicide, que describe los efectos de dedicar una parte de tu tiempo a empujar papeles. En este post vamos a ir un paso más allá y vamos a analizar las causas de este fenómeno.

Nuestro argumento es que, si solo existen cuatro leyes para la gestión de proyectos IT, los procedimientos empresariales tienen que entrar en conflicto con alguna de ellas. Voy a apoyarme para el estudio en cinco casos representativos que he vivido en primera persona como coordinador de Novanotio.

Caso 1. Carlos solicitó una mochila para su ordenador portátil porque la bandolera que le había proporcionado su empresa le hacía daño en la espalda, entonces le explicaron el procedimiento: Debía aportar un justificante médico de su problema de espalda a la dirección de RRHH. En resumen, no confiamos en ti.

Caso 2. Nico necesitaba crear un entorno de pruebas y nuestro cliente le explicó el procedimiento: Debía solicitar una máquina virtual a la central de Alemania, que se encargaba de su conectividad, configuración y mantenimiento. No podía desplegar el entorno según las necesidades del nuevo proyecto ni hacer pruebas para optimizar el rendimiento, debía usar la configuración estándar. En resumen, no te pagamos para que pienses.

Caso 3. Isaac necesitaba pagar mediante tarjeta de crédito un servicio web de 50 € al año y su empresa le indicó el procedimiento: Debía tramitar un pedido a través de la plataforma de compras y, por cierto, los pagos se hacían exclusivamente por transferencia. En resumen, la dirección ya ha pensado en cómo hacer esto.

Caso 4. Jorge tenía problemas para avanzar con el desarrollo. Las especificaciones eran imprecisas y algunas sentencias SQL no tenían sentido. Podía resolver sus dudas hablando unos minutos con el cliente, pero había un procedimiento: El Solutions Architect, que era quien conocía el sistema, pasaba la consulta al Account Manager, que era quien conocía al cliente, y organizaban una reunión junto con el Business Analyst, que era quien conocía el problema. En resumen, eres tonto.

Caso 5. Éste nos afecta en primera persona. Hace unos años, un consultor de Novanotio se llevó el equipo informático cuando cambió de trabajo, así que ahora nuestros consultores deben firmar un recibí cada vez que les entregamos material. En resumen, una vez pasó algo y no queremos que se repita.

En definitiva, un procedimiento significa cinco cosas: Para que no se repitan ciertos hechos (1), desde la dirección hemos creado un procedimiento que es la mejor forma de hacer las cosas (2). Ahora estamos tranquilos porque puedes hacer tu trabajo sin necesidad de pensar (3). No confiamos en ti (4) porque eres tonto (5).

Si recordamos las cuatro leyes:

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

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

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

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

Vemos que los procedimientos entran en conflicto con la tercera ley; no confiamos en ti porque no tienes Talento.

No es viable reinventar la rueda cada vez que realizamos una actividad, así que 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, y sin embargo refuerza la tercera ley, ya que se apoya en el Talento de los consultores.

Si te interesa el tema, te aconsejo acudir a las fuentes, en este caso ‘El japonés que estrelló el tren para ganar tiempo’ de Gabriel Ginebra, ‘Rework’ de Jason Fried y ‘Scaling lean & agile development’ de Craig Larman. También es interesante cualquier libro sobre el modelo Toyota.

Si quieres ayudar a la comunidad IT, comenta por favor algunos de los procedimientos de tu empresa y como te han afectado en tu trabajo.


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

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

Tan solo cuatro leyes gobiernan la gestión de los proyectos tecnológicos:

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.

La primera ley asume que no disponemos de una herramienta para transmitir las instrucciones técnicas. La comunicación se hace mediante sucesivas iteraciones soportadas en relaciones personales. Corolario: Especifica menos y relaciónate más.

La segunda ley nos indica cómo fomentar las relaciones personales; los equipos de diseño, desarrollo, pruebas, integración y delivery están en una única oficina y cada consultor trabaja para un único proyecto. Las software labs y las organizaciones matriciales son ineficientes.

La tercera ley anticipa que si incrementas la presión de trabajo, obtienes menos producto. El desarrollo tecnológico es más inspiración que transpiración. Deja que el equipo encuentre su ritmo y gestiona las expectativas del cliente.

La cuarta ley nos propone cómo gestionar las expectativas del cliente. Dado que las especificaciones son infinitas, uno de los tres parámetros debe degradarse y lo habitual es fijar Alcance y Plazo, degradando la Calidad. La propuesta de SCRUM es fijar Plazo y Calidad mientras el Alcance se determina con el cliente en sucesivas iteraciones. La propuesta de TIME & MATERIAL es fijar Alcance y Calidad, sin plazo cerrado y facturando por el tiempo dedicado.

Son pocas y son fáciles, y sin embargo buena parte de las organizaciones, como consecuencia de la herencia cultural de la ingeniería industrial, trabajan contra ellas preparando extensos documentos funcionales, deslocalizando parte de los equipos, trasladando la presión del cliente a los desarrolladores y fijando en los contratos alcance y plazo de entrega.

Quizás la magia no está en conocer las cuatro reglas, están ahí a disposición de cualquier gestor que quiera aplicarlas. Lo difícil es comprender la psicología que hay detrás de cada una de ellas, de forma que puedas adaptarlas a tu organización. Las referencias básicas son ‘Introducción a la PNL’ de Seymour,The mythical man-month’ de Brooks, ‘Peopleware’ de DeMarco y ‘Drive’ de Pink.

Por eso cuando hay retrasos en los proyectos, se forman silos dentro de las organizaciones o los resultados se evaporan sin razón aparente, algunas empresas contratan un análisis estratégico y otras invitan a su coordinador de Novanotio a tomar un café y le preguntan la forma más sencilla de aplicar las cuatro reglas a su caso particular.

Si quieres ayudar al desarrollo del sector, puedes compartir experiencias sobre proyectos en los que se trabajó a favor o en contra de las cuatro leyes. También puedes proponer nuevas leyes y abrir un debate sobre por qué son necesarias y por qué tienen un carácter universal.