CÓMO LAS GRANDES TECNOLÓGICAS DIRIGEN LOS PROYECTOS TECNOLÓGICOS Y LA CURIOSA AUSENCIA DE SCRUM

La gestión técnica de proyectos es el proceso de gestión de todos los proyectos informáticos y relacionados con la informática. Los gestores de proyectos técnicos son esenciales para dirigir un proyecto a través de su inicio, planificación, ejecución, seguimiento, control y finalización. La gestión técnica de proyectos implica la comunicación de las partes interesadas, tanto técnicas como no técnicas. Los gestores de proyectos han transformado la forma en que las empresas planifican y ejecutan los proyectos. Son innovadores, buenos comunicadores, facilitadores basados en datos y solucionadores de problemas que dirigen e inspiran a los demás.

Las grandes tecnológicas tienen enfoques diferentes de la gestión de proyectos tecnológicos que las demás empresas. Recogí datos investigando algunas conocidas empresas tecnológicas que cotizan en bolsa. He aquí cómo suelen hacer las cosas:

Empresa¿Tienen una metodología central?Metodología de gestión de proyectos que suele emplearse en la realización de proyectos de ingeniería.Líder de proyectos de ingeniería.
AmazonScrumPlanificar (6-paager) – Construir (iterar) – EnviarJefe Técnico
ManzanaScrumPlanificar – Construir (repetir) – EmbarcarJefe Técnico
DatadogLos miembros del equipo decidenPlan (RFC) – Construir – EmbarcarIngeniero técnico o jefe
FacebookLos miembros del equipo pueden elegirPlanificar – Construir (iterar) – EnviarIngeniero técnico o jefe
GoogleLos miembros del equipo decidenPlanificar (documento de diseño) – Construir – EmbarcarIngeniero técnico o jefe
NetflixLos miembros del equipo seleccionan una metodología adecuadaPlanificar – Construir (iterar) – EnviarIngeniero técnico o jefe
ShopifyLa metodología de gestión de proyectos suele utilizarse cuando se realizan proyectos de ingeniería.No, el equipo eligeIngeniero técnico o jefe

Éstas son algunas de las características que comparten los ingenieros de Big Tech en su forma de ejecutar los proyectos

  • Los ingenieros dirigen la mayoría de los proyectos: Tanto las empresas emergentes desarrolladas como las grandes tecnológicas suelen utilizar a sus ingenieros de todos los niveles para dirigir los proyectos de ingeniería. Como ingeniero, desarrollar las habilidades para llevar esto a cabo es esencial si quiere crecer en puestos directivos y de personal. Y como directivo, ayudar a la gente a desarrollar estas habilidades le ayudará a escalar como líder.
  • Los equipos tienen la voluntad de elegir la metodología de gestión del proyecto: Muchos equipos optan por un proceso de planificación tipo RFC, repiten en la construcción y envían todo en unas pocas semanas. Otros equipos utilizan métodos más parecidos al Kanban, trabajando en los elementos con mayor prioridad.
  • No existe un gestor de proyectos comprometido para los proyectos a nivel de equipo: La mayoría de las empresas cuentan con directores de programas técnicos (TPM) que se encargan de los grandes proyectos en los que participan varios equipos o que abarcan varias organizaciones. Estos gestores también dirigen programas de ingeniería que no se califican como productos. Cuando se trata de trabajar, eso no es un producto o una plataforma pero es esencial, como la migración de los centros de datos locales a un proveedor en la nube. Estas son las áreas en las que los TPM asumen la responsabilidad.

Esto es muy común para quienes trabajan en grandes empresas tecnológicas. Sin embargo, si se copiara el mismo enfoque en una empresa más tradicional, probablemente fracasaría. Esto se debe a que la estructura organizativa de las Big Tech afecta significativamente a la forma en que los equipos pueden desempeñar y ejecutar sus funciones.

POR QUÉ LAS GRANDES EMPRESAS TECNOLÓGICAS NO UTILIZAN SCRUM

  • Scrum no es ágil: Scrum se asoció tan fuertemente con los proyectos ágiles al principio que la comunidad no logró verlos como algo separado. El enfoque científico de Scrum y su promoción entusiasta indujeron a muchos a una falsa sensación de seguridad. El énfasis de Scrum en la gestión empírica es lógicamente sólido. Cuando las circunstancias y las prioridades cambian rápidamente, la planificación y la ejecución convencionales fracasan, por lo que hay que observar y adaptarse continuamente.
  • Esto es precisamente lo que consiguen los enfoques ágiles de desarrollo de software, aunque llegaron a prácticas similares desde una perspectiva diferente.
  • Hubris y entusiasmo: Muchos esperaban que Scrum fuera una «envoltura» alrededor de cualquier tipo de método de desarrollo de nuevos productos, lo cual era bienintencionado pero ignoraba un fallo lógico fatal: si se envuelve un proceso no ágil, el conjunto deja de ser ágil. Esta arrogancia hace que tantos proyectos Scrum siembren las semillas de su fracaso. El defecto fatal de Scrum es que se ve a sí mismo como algo vacío; no tiene opinión sobre cómo «debería» desarrollarse el software. Es como si la asociación de Scrum con Agile se considerara circunstancial y no intrínseca. Agile se describe por principios y valores, no por ceremonias y procesos. Agile se rige por un manifiesto, no por un manual de procesos. Se trata de dos cosas muy diferentes, pero aún hoy mucha gente sigue confundida por la confusión.
  • Scrum conduce a menudo a la expansión del alcance, debido a la falta de una fecha final definida.
  • Las posibilidades de fracaso del proyecto son altas si los individuos no están muy comprometidos o no cooperan
  • Adoptar el marco Scrum en equipos grandes es un reto
  • El marco sólo puede tener éxito con miembros del equipo experimentados
  • Las reuniones diarias a veces frustran a los miembros del equipo
  • Si algún miembro del equipo renuncia durante la ejecución de un proyecto, puede tener un gran impacto negativo en el mismo.
  • La calidad es difícil de implantar sin que los miembros del equipo pasen por un exigente proceso de pruebas

CÓMO INFLUYEN LAS ESTRUCTURAS ORGANIZATIVAS DE LAS GRANDES TECNOLÓGICAS EN LOS PROYECTOS

Para que entienda cómo gestionan los proyectos las grandes tecnológicas, demos un paso atrás y analicemos el entorno en el que operan la mayoría de estas empresas:

Autonomía para los ingenieros de software. De los desarrolladores de las empresas establecidas se espera que cumplan las tareas que se les asignan. En cuanto a las empresas de nueva creación, se espera que resuelvan los problemas a los que se enfrenta la empresa en ese momento. Se trata de una diferencia considerable que, a su vez, repercute en las operaciones cotidianas de cualquier ingeniero.

Solucionadores de problemas, no recursos sin sentido. Un ingeniero motivado que resuelve problemas con rapidez tiene más impacto que un trabajador industrial que sólo realiza las tareas que le han encomendado. Para las empresas con una configuración de trabajador industrial, este método no favorece los enfoques de gestión de proyectos más pesados que dejan menos margen para la interpretación a propósito.

Exposición al negocio y a las métricas empresariales. Los ingenieros deben interactuar con el resto de la industria y crear relaciones con el personal que no es ingeniero. Por otro lado, las empresas tradicionales suelen dificultar la interacción de los desarrolladores con el resto de la empresa.

Comunicaciones de ingeniero a ingeniero a través de la comunicación triangular. Lo que suele ocurrir en las empresas tradicionales es que promueven una comunicación jerárquica que ralentiza el flujo de información y da lugar a decisiones más lentas que provocan un retraso en el lanzamiento de los productos.

Crear una experiencia menos decepcionante para los desarrolladores. Las empresas que centran su atención en que los ingenieros puedan resolver los problemas lo antes posible crean varios equipos de plataforma, lo que reduce la rotación de la experiencia de los desarrolladores.

Una mayor remuneración se justifica por un mayor apalancamiento. Las empresas que apalancan a los ingenieros no tendrán problemas para pagar cerca de la cima del mercado o por encima de ella.

El calibre del talento contratado. Estas empresas contratan a personas muy competentes y muy motivadas, gracias a la combinación de todo lo anterior. Disponen de una gran reserva entre la que elegir, ya que son conocidas por sus generosos paquetes retributivos y sus importantes oportunidades de crecimiento profesional.

¿Qué es Scrum?

Scrum es una metodología de desarrollo ágil utilizada para desarrollar software basado en procesos repetitivos e incrementales. Scrum es fácilmente adaptable, flexible, rápido y un marco ágil práctico que ayuda a los equipos a trabajar juntos. Anima a los miembros del equipo a aprender a través de las experiencias, a autoorganizarse mientras resuelven un problema y a reflexionar sobre sus victorias y derrotas para garantizar una mejora continua. Está diseñado para aportar valor al cliente durante todo el desarrollo de un proyecto.

Importancia de la metodología Scrum

  • La metodología Scrum es sencilla y eficaz. Es algo diferente de una colección esencial de componentes conectados. La Metodología Scrum suele entenderse erróneamente como una filosofía. Actualiza el método lógico de experimentación. La Metodología Scrum también puede utilizarse en lugar de un enfoque algorítmico a medida. Las personas tienden a pensar en la Metodología Scrum y ágil como algo similar porque la Metodología Scrum se basa en la mejora constante, que es una directriz central de la metodología ágil scrum.
  • La Metodología Scrum es un marco para realizar el trabajo, mientras que ágil es una actitud. El marco de la Metodología Scrum es experiencial; se ayuda del aprendizaje continuo y cambia siguiendo componentes fluctuantes. Identifica que los individuos no lo saben todo al principio de un proyecto y que se desarrollarán gradualmente.
  • La metodología Scrum ayuda a las organizaciones a adaptarse con poca frecuencia a los entornos fluctuantes y a las necesidades de los clientes. La principal prioridad del marco Scrum es mejorar los ciclos de entrega cortos y ayudar a las organizaciones a aprender mientras trabajan. Aunque la Metodología Scrum es organizada, no es muy inflexible. Su ejecución puede adaptarse a las necesidades de cualquier asociación. Existen numerosas hipótesis sobre cómo deben funcionar exactamente los grupos de la Metodología Scrum para ser eficaces. No obstante, tras más de un tiempo ayudando a los grupos ágiles a completar el trabajo en Atlassian, hemos descubierto que la buena correspondencia, la franqueza y el compromiso con la mejora continua deben permanecer siempre en el punto central de cualquier Scrum y marco ágil que elija.

Diferentes roles en Scrum

Los tres roles de Scrum describen las responsabilidades clave de quienes forman parte del equipo Scrum. No son títulos de trabajo, lo que significa que cualquier título puede desempeñar uno de los roles, incluido el suyo. En Scrum, el equipo suele centrarse en la autoorganización, la mejora continua y la creación de software de calidad. El propietario de un proyecto Scrum presta atención a la definición de las características que debe tener el producto (qué construir, qué no y en qué orden) y a la superación de los retos que puedan interferir con el equipo de desarrollo.

El equipo Scrum incorpora los siguientes roles:

Scrum master: es la persona que está detrás del equipo y que marca el camino y les guía para que actúen de acuerdo con las reglas y procesos de la metodología. El scrum master también controla la reducción de los impedimentos del proyecto y colabora con el propietario del producto para mejorar el rendimiento de la inversión. El scrum master también ayuda al propietario del producto a definir el valor, el equipo de desarrollo crea el valor y el equipo scrum lo mejora. El scrum master no sólo describe un tipo de liderazgo de apoyo, sino también las operaciones diarias del equipo.

Propietario del producto: es el representante de las partes interesadas y de los clientes que utilizan el software. Centran su atención en la parte empresarial y son responsables del rendimiento de la inversión del proyecto. El propietario del producto no sólo comprende las necesidades de los clientes, sino que también visualiza el valor que el equipo scrum aportará a los clientes. También se asegura de que exista un equilibrio entre las necesidades de las partes interesadas. Así pues, el propietario del producto debe encargarse de estas aportaciones y hacer del trabajo la prioridad número uno. Se trata de una responsabilidad esencial porque las prioridades contradictorias minimizan la eficacia del equipo y también rompen la confianza entre el equipo de desarrollo y la empresa.

El equipo: suele tratarse de un grupo de expertos con los conocimientos técnicos necesarios para desarrollar el proyecto, que realizan en colaboración las tareas que dan comienzo a cada sprint. La mayoría de la gente piensa que el equipo de desarrollo debe estar formado únicamente por ingenieros, pero no es así. El equipo de desarrollo puede contar con todo tipo de personas, incluidos diseñadores, programadores o redactores. Este equipo debe estar autoorganizado para poder tomar decisiones que permitan realizar el trabajo. El equipo de desarrollo, al igual que el equipo de apoyo a la producción, puede aplicar decisiones que solucionen los problemas que se presenten y también aportar valor. Este equipo también garantiza la transparencia durante el standup diario. El scrum standup diario ofrece transparencia al trabajo y proporciona una plataforma a través de la cual los miembros del equipo pueden buscar ayuda.

Conclusión

Ya hemos hablado de cómo las empresas de distintas etapas llevan a cabo sus proyectos con diferentes metodologías y de cómo las grandes tecnológicas no suelen instrumentar un enfoque único. No obstante, las grandes empresas cuentan con mucho apoyo organizativo para que este proceso funcione.

En general, la forma de dirigir equipos debería depender de su contexto. Los factores relevantes incluyen su estructura organizativa, las personas con las que trabaja, la autonomía y las habilidades de esas personas, su competencia y si está operando en «tiempos de guerra» o en «tiempos de paz». La lista continúa.

DevologyX OÜ
Harju maakond, Tallinn, Lasnamäe
linnaosa,
Vaike-Paala tn 1, 11415

+372 6359999
[email protected]
DevologyX Limited
Nakawa Business Park
Kampala
Uganda

+256206300922
[email protected]

DevologyX Pty Ltd
Tijger Park 3
Willie van Schoor Drive
Bellville
Cape Town
7530

[email protected]

DevologyX OÜ
Harju maakond, Tallin, Lasnamäe
linnaosa,
Vaike-Paala tn 1, 11415

+372 6359999
[email protected]
DevologyX Limited
Nakawa Business Park
Kampala
Uganda

+256206300922
[email protected]

DevologyX Pty Ltd
Tijger Park 3
Willie van Schoor Drive
Bellville
Ciudad del Cabo
7530

[email protected]