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


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.


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.