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

Las carreras profesionales en la tecnología

Las carreras profesionales en la tecnología

En esta serie de artículos vamos a analizar las posibles carreras profesionales en la tecnología.

El motivo para incluir este tema en nuestro mentoring Novanotio Certified es que buena parte de los consultores no tienen claro hacia dónde orientar su trayectoria. Quieren más responsabilidad y, por supuesto, quieren mas dinero. Pero no tienen claro a qué responsabilidad se refieren. Ni cuánto les va a costar ese dinero.

Cuando les preguntamos, la mayor parte responde que quieren llegar a ser ‘responsables de proyecto’ o ‘gurús tecnológicos’. Como veremos, hay varios tipos de ‘responsables de proyecto’. Y también algunos riesgos en la carrera de los ‘gurús tecnológicos’.

Las cuatro trayectorias profesionales

A modo de resumen, en nuestro sector hay cuatro posibles carreras profesionales; la carrera tecnológica pura, el liderazgo tecnológico, la gestión y las ventas.

La carrera tecnológica pura

Nunca te va a faltar trabajo.

Es la puerta de entrada. Todos empezamos programando, administrando sistemas o haciendo hacking ético.

Es también la trayectoria profesional más agradecida. Todos los años incrementas tus conocimientos y tu valor para el mercado. Cada vez eres capaz de asumir retos más complejos. Todas las semanas recibes docenas de ofertas laborales. Tengas la edad que tengas nunca te va a faltar trabajo. ¿No es  genial?

Lo realmente difícil de la carrera tecnológica es no salirse de ella. Frases como ‘Hazte cargo de estos becarios’ o ‘Acompáñame a visitar al cliente’ son resbaladizos toboganes por los que puede deslizarse tu trayectoria profesional.

Con perseverancia, pasarás de Becario a Consultor Junior, Consultor Senior y, finalmente, Especialista Tecnológico.

El liderazgo tecnológico

La carrera que se desvanece

El liderazgo tecnológico es una de las trayectorias preferidas por los jóvenes consultores. Diseñar los sistemas y ayudar a los equipos técnicos a construirlos.

Aquí se llega con poco de paciencia. Con la rotación de nuestro mercado, cuando llevas cuatro o cinco años desarrollando un módulo dentro de un sistema, eres quien mejor lo conoce. Cuando se incorporan los nuevos programadores, ¿quién mejor que tu para explicarles dónde está cada función dentro de dicho módulo? El rol de Analista-Programador es el punto de acceso al liderazgo tecnológico.

¿Pero qué ocurre en el siguiente paso? Cuando te conviertes en el Analista de todo el proyecto, conoces muy bien tu módulo y desconoces todos los demás. Ya no puedes ayudar al resto de analistas-programadores.

A partir de aquí, creces en el conocimiento funcional de los sistemas, pero desconoces los detalles de su implementación.  Jefes de Programa, CIOs, CISOs y CTOs son líderes técnicos que cada vez saben menos de tecnología.

Por eso el liderazgo tecnológico es una carrera que se desvanece. En el proceso de desarrollo Scrum, la responsabilidad del diseño es de los squads de desarrollo. En buena parte de las empresas, los CIOs, CISOs y CTOs no reportan al CEO sino al director de operaciones.

La gestión

A mayor responsabilidad, menor empleabilidad.

La carrera de gestión es la gran desconocida. En el imaginario colectivo, las funciones del Jefe de Proyecto se mezclan y confunden con las de los líderes técnicos. Buena parte de ellos creen que su responsabilidad incluye el diseño funcional y hasta la arquitectura del sistema. Error.

El Jefe de Proyecto es en realidad un firewall. Sus tres desconocidas funciones son:

  • Cobrar al cliente cuando todavía queda muuucho por hacer.
  • Proteger a los técnicos de la presión.
  • Motivar a los consultores y mediar en sus conflictos.

Ya lo se, casi puedo escuchar vuestras carcajadas según escribo estas palabras.

Como veis son necesarias habilidades de psicología y negociación. Vuestros preciosos conocimientos técnicos no os van a servir de ayuda. Las únicas matemáticas que vais a usar son los tantos por ciento.

Por encima del Jefe de Proyecto aparecen las figuras del Gerente y el Director de Operaciones, también conocido como COO. Más capacidad de negociación, más tantos por ciento y menos ofertas de trabajo. En el área de gestión, a mayor responsabilidad, menor empleabilidad.

Las ventas

Aquí

En una empresa, no pasa nada hasta que alguien vende algo. La función de ventas es el motor de la empresa.

En este área son fundamentales las habilidades de comunicación y de influencia. Tu trabajo se resume en mirar a tu cliente a los ojos, señalar la línea de puntos y decir ‘aquí’. Si estampa su firma, te has ganado tu comisión y toda la empresa se pone en marcha.

Pero antes de esa firma sobre la línea de puntos tienes que superar dos obstáculos.

  • Debes convencerle de que tu organización sabe más que la suya y podéis ayudarles. Te ayudará haber pasado unos años en el área técnica.
  • Tendrás que mejorar los precios de la competencia. ¿Cómo pueden ir siempre por debajo de costes?

Llegará un momento en que, para conseguir tu comisión, aceptarás plazos imposibles y presupuestos ridículos. No vas a tener muchos amigos en el resto de la organización.

Sobre Preventas, Business Analyst y Account Managers aparece el Director de Desarrollo de Negocio o CBDO. Su misión es consolidar los mercados ya conquistados y descubrir nuevos nichos de oportunidad. Todo un reto en un mercado en permanente revolución tecnológica.

¿Qué carrera es mejor para mi?

Ahora ya conoces las carreras profesionales en la tecnología. ¿Cómo decidir cual es la más adecuada?

Cualquier programador usaría la estrategia de prueba y error. Prueba una de las áreas y, si no te gusta, vuelve a la programación.

No es tan sencillo. La responsabilidad es como un fuerte licor que crea dependencia. Una vez que los has probado no es fácil dejarlo por muy amargo que esté. Conozco pocos casos en que, tras una fallida experiencia como Jefe de Proyecto, alguien haya tenido la humildad de dar un paso atrás.

En este artículo explicamos cómo descubrir qué carrera puede ser la mejor para ti, usando el test de fortalezas de Gallup. Quizás deberías leerlo antes de deslizarte por alguno de los toboganes.


Los postit, quizás la herramienta más conocida de Scrum

Scrum

Scrum

Scrum y los principios básicos de la gestión de proyectos

Hay miles de libros y artículos sobre Scrum. Es imposible que una entrada de novanotio se sitúe en las primeras páginas de los buscadores. Entonces, ¿por qué molestarse en escribir otro artículo sobre metodologías ágiles? Y ya puestos, ¿por qué incluir Scrum dentro de Novanotio Certified cuando hay academias que imparten ya esta formación?

Desde luego no para describir la metodología o explicar sus ventajas.  Eso puedes encontrarlo aquí, aquí, aquí o aquí

Nuestra intención es reforzar vuestros conocimientos sobre los principios básicos de la gestión de proyectos.

Si entiendes los principios básicos, puedes adoptar con éxito Scrum o cualquier otra metodología.

A lo largo de nuestra historia hemos participado en proyectos bien gestionados que no seguían ninguna metodología formal.

También hemos participado en proyectos pobremente gestionados que cumplían al pie de la letra diferentes metodologías; CMMI, Waterfall, ITIL y sí, Scrum.

Estaba claro que la metodología por si misma no explicaba el éxito o el fracaso de la gestión del proyecto.

Tampoco explicaba por qué, con buena gestión o sin ella, la mayor parte de los proyectos sufrían retrasos y fuertes sobrecostes.

Son más importantes los fundamentos que las metodologías. Cuando conoces los problemas intrínsecos del desarrollo de software y dominas los principios básicos de la gestión de proyectos, puedes adoptar cualquier metodología. O no utilizar ninguna.

Las Cuatro Leyes

Las Cuatro Leyes condensan en cuatro sencillas frases buena parte de los conocimientos que necesitas para gestionar proyectos. Cómo enfocar la toma de requisitos, cómo organizar los equipos, cómo liderar a los consultores y cómo gestionar a los clientes. Todo en 35 palabras:

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

Las Cuatro Leyes son una forma sencilla de enseñar los principios básicos de la gestión de proyectos. Nos gusta comenzar las visitas de seguimiento repasando estas 35 palabras, así las recordarás durante toda tu carrera profesional.

Nuestros artículos sobre Scrum

En esta serie de artículos vamos a analizar desde diferentes ángulos las similitudes entre Scrum y los principios básicos de gestión. Qué relación existe entre las Cuatro Leyes, los cuatro apartados del Manifiesto Ágil, los doce principios de Scrum y el proceso de desarrollo Scrum.

Espero de corazón que os ayuden a comprender los enormes desafíos a los que nos enfrentamos en la construcción y soporte de sistemas informáticos.

Con el tiempo añadiremos nuevas entradas, no olvides visitarnos de vez en cuando.

El proceso de desarrollo Scrum es eficiente porque cumple las Cuatro Leyes de gestión de proyectos informáticos.

Si no entiendes los fundamentos de Scrum, vas a implantar la metodología como si fuera una religión. Y tus proyectos no mejorarán.

Las empresas cometen una y otra vez los mismos errores al implantar Scrum.


Cumplimos veinticinco años

Cumplimos 25 años

El 8 de noviembre de 2020 cumplimos 25 años

¡Guau, un cuarto de siglo! Eso es el doble de la vida media de las empresas en España, que es de entre 8 y 12 años.

Si además tenéis en cuenta que la fundamos tres estudiantes recién salidos de la universidad, sin contactos, experiencia o capital, podéis considerar el caso novanotio como un pequeño milagro.

Lo hicimos porque no sabíamos que era imposible

¿Cómo hemos llegado hasta aquí?

Sin contactos, sin experiencia, sin capital, sin conocimientos sobre ventas, marketing o gestión de organizaciones.

No teníamos buenas cartas y sin embargo aquí estamos. ¿Cuáles han sido los pilares de nuestro éxito? Creemos que nuestros clientes, nuestra cultura y nuestra gestión financiera.

Nuestros clientes

Solo podemos dar las gracias a nuestros clientes por confiar en nosotros durante todos estos años.

Nuestro crecimiento depende de que hagan una gran gestión, y en estos veinticinco años hemos visto a varios de ellos transformarse en grandes multinacionales. Nos sentimos realmente afortunados de poder aportar nuestro granito de arena.

Gracias.

Nuestra cultura

Nuestra cultura se resume con la frase: ‘Trata bien a tus empleados y estos harán un gran trabajo’.

Mientras otras empresas han apostado por el control y los bonus por objetivos, nosotros tomamos el camino de la formación y la confianza.

¿Habéis hecho alguna entrevista con un recruiter que tiene que incorporar obligatoriamente a 10 consultores todos los meses? ¿Habéis notado la presión?

Es solo un pequeño ejemplo, pero nuestros recruiters en vez de presión reciben formación. Formación en las tecnologías en las que se especializan. Formación sobre gestión de proyectos. Formación sobre creatividad y liderazgo. Las salidas profesionales de un recruiter de novanotio van desde la programación hasta los puestos de Key Account Manager.

¿Habéis hecho una entrevista con un recruiter de novanotio? ¿Habéis notado la diferencia?

La gestión financiera

Con respecto a la gestión financiera, nuestra política ha sido capitalizar los beneficios para conseguir una excelente posición financiera.

Es una apuesta arriesgada porque podemos perder los frutos de muchos años de esfuerzo. Pero cuando las cosas se ponen realmente feas, como en la gran crisis del 2009, no hay mejor flotador que un balance sólido.

Y un poquito de suerte

La suerte influye en el devenir de las compañías.

Y en nuestro caso, el hecho de que tanto nuestros clientes como todo el sector tecnológico hayan crecido, aunque con altibajos, también nos ha ayudado.

Justo es por tanto reconocer la  contribución de la Diosa Fortuna a nuestra causa.

¿Cómo ha sido nuestra historia?

Durante estos veinticinco años no todo ha sido crecimiento y felicidad.

Y francamente no se qué es más difícil de gestionar, si las durísimas épocas de crisis cuando te cancelan los servicios, o las épocas de fuerte crecimiento donde no encuentras consultores para tus proyectos.

Acompañadnos en este viaje por nuestra pequeña intrahistoria.

1.995 – 2.000. La etapa de crecimiento exponencial

Aunque entonces no se estudiaba este concepto en las escuelas de negocio, novanotio creció de manera exponencial durante sus primeros cinco años de vida. Cada año doblábamos nuestra facturación.

Aun así éramos insignificantes para el mercado. Cuando partes de cero, aunque crezcas de forma exponencial, durante muchos años eres invisible.

Como además no había financiación externa, teníamos importantes tensiones de tesorería. Pero éramos jóvenes y el dinero no nos importaba, así que renunciamos a nuestro salario para poder pagar las nóminas a fin de mes.

2.000 – 2.002 La crisis de las punto com

La burbuja de las empresas de internet fue la primera de las crisis que tuvimos que afrontar. ‘B2C significa Back To Consultory’ era el chascarrillo del momento.

Algunos de nuestros competidores desaparecieron al reducirse la actividad y agotarse el crédito. Otros vendieron o se fusionaron entre si.

Nosotros también recibimos buenas ofertas para vender la empresa, pero decidimos seguir nuestro camino porque nos gustaba la cultura que estábamos construyendo.

Además, tuvimos suerte porque nuestros clientes apenas sufrieron el impacto de esta crisis. Y fueron ellos los que nos ayudaron a superarla. De nuevo gracias.

2.003 – 2.008. La fase de crecimiento sostenido

Posiblemente la más divertida de todas. Estábamos en el sitio correcto en el momento oportuno, y la marea nos arrastró hasta llegar a ser casi 200 consultores.

Pero nos obsesionamos con el crecimiento y cometimos el primero de nuestros grandes errores. Renunciamos a nuestros márgenes para ganar volumen. Mas facturación, pero sin beneficios y de nuevo con tensiones de tesorería.

Necesitábamos más espacio, así que cometimos el segundo de nuestros grandes errores, comprar unas flamantes nuevas oficinas que no llegamos a estrenar.

2.009 – 2.014. La gran crisis

La gran crisis nos cogió por sorpresa en febrero de 2.009, sin márgenes para negociar con nuestros clientes y con la hipoteca de una oficina que ya no necesitábamos.

Entonces cometimos el tercero de nuestros grandes errores. Como teníamos consultores desocupados, intentamos comercializar nuevos servicios que nunca habíamos realizado antes.

Iniciar una nueva actividad en un entorno de crisis, cuando no tienes reconocimiento del mercado ni Account Managers bien formados es difícil. Así que la facturación de las nuevas unidades fue cero. Cero lapicero.

¿Os acordáis de lo del balance equilibrado y la capitalización de beneficios? Aquí es donde entra en juego el flotador financiero. Lo normal hubiera sido desaparecer o vender, como hicieron varios de nuestros competidores. Nuestra posición financiera nos dio la oportunidad de seguir adelante.

Fueron los momentos más duros de nuestra historia y desde aquí enviamos un fuerte abrazo a los consultores que estuvieron con nosotros en ese periodo tan complicado.

2.015 – 2.019. La segunda fase de crecimiento sostenido

Los años desde 2015 han sido parecidos a aquellos previos a la gran crisis del 2009.

Solo que en lugar de obsesionarnos con el crecimiento de la empresa, esta vez nos obsesionamos con el crecimiento de nuestros consultores.

Después de veinte años de actividad, habíamos visto los mismos errores repetidos una y otra vez. Sabíamos las causas y conocíamos los remedios. Y pensamos que era mejor explicaros las cosas antes de que sucedieran. De esa forma, cuando llegaban los problemas, disponíais de herramientas para enfrentaros a ellos.

Todo ese conocimiento ha cristalizado en novanotio certified, el programa de mentoring que los coordinadores hacemos con nuestros consultores, y que nos está proporcionando mayores satisfacciones que cualquier cuenta de resultados.

2020. La pandemia

Marzo de 2020 nos volvió a sobresaltar a todos con un confinamiento inimaginable para las sociedades occidentales.

Al comienzo del post he hablado de la cultura y es el momento de volver a ella.

La cultura de una empresa se define como ‘la forma de trabajar cuando el jefe no está’. Así que con el teletrabajo, todas las empresas hemos tenido que confiar en la cultura que habíamos construido. Los jefes ya no pueden supervisar y controlar cada detalle de la actividad.

En esta crisis, es nuestra cultura la que ha acudido a rescatarnos. Todos sabíamos como hacer nuestro trabajo sin necesidad de supervisión, así que apenas hemos notado la transición al trabajo remoto.

La crisis de la Covid acaba de comenzar y nadie sabe cuándo o cómo terminará. Nuestros clientes, nuestra estrategia financiera y nuestra cultura han demostrado ser notables herramientas de supervivencia. Esperamos superar este desafío igual que hemos superado los anteriores.

A por otros 25

Dice Nassim Taleb que la esperanza de vida de una empresa que lleva veinticinco años en el mercado es de al menos otros tantos.

Nada nos gustaría más que seguir ayudando a crecer a nuestros consultores y clientes durante otro cuarto de siglo.

Para hacerlo tendremos que superar nuevas crisis y desarrollar nuevas estrategias. Y tenemos las mejores herramientas para conseguirlo, el reconocimiento de nuestros clientes y el cariño de las personas que nos conocen. Gracias, gracias, gracias.

¡A por otros 25!

 

 

 


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.


El proceso de desarrollo SCRUM y las Cuatro Leyes

El proceso de desarrollo SCRUM y las Cuatro Leyes

¿Por qué el proceso de desarrollo SCRUM es más eficiente que las metodologías tradicionales Waterfall?

En este primer artículo de la serie que dedicamos a Scrum, vamos a explicaros la relación entre el proceso de desarrollo Scrum y los principios básicos de gestión de proyectos.

Nuestro objetivo es que entendáis por qué motivos Scrum es más eficiente que las metodologías tradicionales waterfall.

El proceso de desarrollo 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.

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, asumiendo 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 squads 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 incrementos de la jornada de trabajo producen retrasos en los desarrollos y, por el contrario, reducir la jornada a cinco horas diarias mejora la productividad un 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 pasan sus test, algunos pueden quedar a medias o no superar las pruebas. Estas Historias vuelven al team backlog y se abordan (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.

Como cliente debes elegir entre

– Sacrificar el Alcance y entender que ciertas funcionalidades no se construirán.

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

– Sacrificar la Calidad, y aceptar que obtendrás un sistema con errores en producción y complejo de operar.

Habitualmente en los contratos se fijan 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é variable se degrada en el proceso de desarrollo SCRUM?

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

– El Plazo, y por consiguiente el presupuesto, se establecen en el contrato. El Alcance se deja abierto.

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

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

¿Puedo mejorar la eficiencia sin usar Scrum?

Como hemos visto, las ventajas de Scrum se derivan de que cumple los principios básicos de la gestión de proyectos.

Es frecuente que las organizaciones se obsesionen con la puntual observancia de sus rituales, lo que les lleva a cometer una y otra vez los mismos errores en su implementación, sin encontrar las prometidas mejoras de productividad.

Pero también es posible el caso opuesto. Puedes utilizar los principios básicos de gestión de proyectos y mejorar el rendimiento de tus proyectos sin  implementar el proceso de desarrollo de Scrum.

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

La productividad fue excelente hasta que la organización apostó por CMMI, una metodología más preocupadas por la especificación que por las personas.

Emplea con sabiduría los principios de la gestión de proyectos y cualquier metodología será la adecuada.


Es hora de cambiar de puesto. Te ayudamos a descubrir que roles se te dan mejor usando el test de fortalezas de Gallup

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 recién incorporados, o tal vez que acompañes al responsable de cuenta a las reuniones 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 recompensa es un trabajo bien hecho o eres incapaz de 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 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 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

Para liderar equipos siempre es interesante la combinación de fortalezas de pensamiento e influencia. Busca las posiciones de Líder Técnico o Jefe de Proyecto.

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. Gerente, Director de Operaciones, CIO, CTO…

Si la mayoría de tus fortalezas son de influencia, tu sitio está en la alta dirección. Por el camino algunos te llamarán trepa o pisacuellos. Bueno, quizás nunca has sido el mejor técnico, pero siempre sabes lo que tienes que decir. Y esas habilidades te llevarán a poner una C en tu Linkedin.

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íanos el resultado de tu test de fortalezas y te explicaremos cómo acertar al cambiar de rol.


Es fácil confundir Scrum con una religión. No cambies el triángulo de acero por el ojo sagrado.

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.


Dentro de las carreras profesionales tecnológicas, Analista Programador es la primera promoción. Y esconde una trampa que debes conocer.

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.

 

Resultado de las posibles estrategias de trabajo de un Analista Programador
Resultado de las posibles estrategias de trabajo de un Analista Programador. ¿Es que no hay forma de cumplir las expectativas?

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.


¿Cuáles son los tres errores más frecuentes al implantar SCRUM?

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.

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.


Si dentro de las carreras profesionales eliges ser Especialista Tecnológico, tarde o temprano chocarás con el techo de cristal

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.