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

Factores del éxito en los proyectos informáticos

Factores del éxito en los proyectos informáticos

¿Cuáles son los principales factores que influyen en el éxito en los proyectos informáticos?

La metodología por si misma no basta para explicar el éxito o el fracaso de los mismos. Hemos participado en muchos proyectos exitosos que no seguían ninguna metodología formal. También en proyectos con fuertes retrasos y  sobrecostes gestionados con diferentes metodologías; CMMI, Waterfall, ITIL y también Scrum.

¿Cuáles son entonces los principales factores que influyen en el éxito de un proyecto informático?

Desde nuestra experiencia, y por orden de importancia:

  1. Experiencia previa en el proyecto. Los proyectos de mantenimiento evolutivo tienen una tasa de éxito muy superior, porque tanto el equipo de desarrollo como el de gestión conocen los requisitos funcionales.
  2. Tamaño del proyecto. Los proyectos pequeños son más exitosos porque pueden abordarse con un equipo reducido. Esto facilita la coordinación de los participantes y acelera la construcción de los requisitos funcionales.
  3. Liderazgo. Si el Jefe de Proyecto domina los fundamentos de la gestión de proyectos, no sólo mejora la productividad. Puede cambiar la precepción de éxito o fracaso del mismo.
  4. Metodología. Los proyectos gestionados con SCRUM tienden a ser más exitosos. Sobre todo porque SCRUM, como los buenos líderes, cambia la definición de éxito de un proyecto.

La experiencia previa y el tamaño del proyecto vienen impuestos por las circunstancias y no podemos gestionarlos.

Sin embargo, liderazgo y metodología son factores clave para el éxito de los proyectos informáticos que si están dentro de nuestra esfera de influencia. Por eso los estudiamos en nuestro méntoring Novanotio Certified.

Liderazgo

Los cuatro principios básicos de la gestión de proyectos informáticos se condensan en cuatro sencillas frases. Son todo lo que necesitas conocer para liderar equipos:

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

Estas 35 palabras son el credo de todo buen Jefe de Proyecto. En este artículo explicamos con más detalle su contenido y cómo utilizarlas.

Metodología

La metodología elegida para gestionar el proyecto también es importante.

Últimamente cobran especial relevancia las metodologías ágiles, con SCRUM a la cabeza. Hay cientos de libros y artículos sobre SCRUM que seguramente ya habrás leído. Solo añadiremos algunas reflexiones que consideramos importantes:

Las empresas cometen una y otra vez los mismos errores al implantar Scrum. Esta lectura de tres minutos evitará que caigas en las mismas trampas para novatos.

Es importante que conozcas los fundamentos de Scrum para implantarlo con éxito en tu organización. Si no entiendes estos fundamentos, vas a implantar Scrum como si fuera una religión. Y tus proyectos no mejorarán.

¡Mucha suerte en la gestión de tus proyectos!


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

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

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

Estas cuatro sencillas reglas son la base de la gestión de proyectos tecnológicos.

Son solo 35 palabras, pero necesitarás algunos años para dominarlas y aplicarlas correctamente. Si deseas convertirte en un buen Jefe de Proyecto, serán tu credo. Apréndetelas de memoria y practícalas cada día.

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

La primera ley es la responsable de que fracase el 80% de los grandes proyectos informáticos en todo el mundo. Esta cifra se mantiene estable desde los años 60 hasta hoy. Las nuevas herramientas de desarrollo y las diferentes metodologías no han conseguido mitigar este desastre.

Nos avisa de que el cliente no puede saber lo que quiere. Los sistemas informáticos son demasiado complejos. La especificación siempre estará incompleta. Por eso son inciertas.

Nos advierte de que no existe un lenguaje de alta precisión para comunicar las instrucciones técnicas. Los arquitectos disponen de los planos, un lenguaje de muy alta precisión. Los ingenieros informáticos sin embargo usamos el lenguaje natural, que es interpretable. Por eso son imprecisas.

Nos alerta de que un proyecto nunca termina. Siempre quedan errores que corregir y mejoras por implementar. ¿Alguna vez has puesto la última línea de código de un programa? Por eso son infinitos.

Cómo usar la primera ley:

  1. Especifica menos y haz más prototipos.
  2. Relaciónate más con tu cliente.
  3. No discutas el significado de un párrafo.
  4. ¡Haz que abone las facturas cuando todavía queda mucho por hacer!

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

Como el cliente no puede saber lo que quiere, y no disponemos de un lenguaje de alta precisión, las relaciones personales cobran especial relevancia.

La especificación se construye según avanzan los desarrollos, y los vínculos emocionales son la clave para distribuir ese conocimiento.

La segunda ley nos indica cómo construir esos vínculos. Los analistas funcionales, programadores, testers e incluso el cliente deben estar en la misma sala. Y mucho mejor si cada consultor trabaja en exclusiva para el proyecto.

Las software labs, las organizaciones matriciales y los equipos distribuidos son ineficientes.

Un apunte de Franz Hassmann, CTO de BBVA Next. Mejor si los equipos son pequeños, de entre 5 y 9 componentes.

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

Durante miles de años hemos dirigido organizaciones gestionando la presión. Con el nacimiento de la informática necesitamos, por primera vez en la historia, gestionar el talento.

La tercera ley anticipa que si incrementas la presión de trabajo, disminuye el talento y los desarrollos se retrasan.

Así que olvídate de los bonus por objetivos y de exigir horas extras. Esas son herramientas de gestión de la presión.

Debes gestionar el talento. Ofréceles retos. Usa el feedback positivo. Bloquea la presión del cliente y deja que el equipo encuentre su ritmo de trabajo.

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

Recuerda, las especificaciones son infinitas.

Así que algo tienes que sacrificar. Puede elegir entre el alcance (entregar menos producto), el plazo (retrasar las entregas) o la calidad (entregar algo sin apenas pruebas).

La cuarta ley nos propone que alcance, plazo y calidad están interrelacionados. Si fijas dos de ellos, el tercero se degrada.

Nunca, nunca, nunca sacrifiques la calidad. Nunca fijes alcanzo y plazo.

SCRUM por ejemplo fija plazo y calidad, el alcance queda indeterminado. Se factura por cada sprint.

TIME & MATERIAL, los servicios profesionales de toda la vida, fijan alcance y calidad, y es el plazo el que queda indeterminado. Se factura mensualmente por el esfuerzo dedicado.

Si haces PROYECTOS CERRADOS, perderás dinero en el 80% de los contratos.

Enlaces de interés

Son solo cuatro reglas sencillas de aprender. Sin embargo, muchas organizaciones todavía preparan extensos documentos funcionales, deslocalizan parte de los equipos y trasladan la presión del cliente a sus desarrolladores.

Os dejo los enlaces a las fuentes de las cuatro leyes. Si comprendéis los fundamentos de cada una de ellas, os será más sencillo  adaptarlas a vuestra organización.

La primera ley tiene su origen en ‘The mythical man-month’ de Brooks. Quizás el primer libro sobre ingeniería del software. Escrito a finales de los sesenta y una referencia obligada a día de hoy. Se complementa con ‘Introducción a la PNL’ de Seymour, un libro sobre psicología del lenguaje.

La segunda ley procede del fantástico libro ‘Peopleware’ de DeMarco. Posiblemente el primer ensayo sobre programación y productividad. Muy entretenido.

La tercera ley procede de un clásico sobre la motivación. ‘Drive’ de Daniel H. Pink. Igualmente divertido y ágil.

La cuarta ley procede tanto del libro de Brooks como de ‘Agile Software Requirements’ de Dean Leffingwell. No son fáciles ninguno de los dos, pero merece la pena el esfuerzo.

Te animo a compartir con todo nuestro sector tus experiencias en los proyectos en los que has participado. ¿Se han cumplido las cuatro leyes? ¿Añadirías alguna más?

¡Suerte en tu carrera de gestión de proyectos tecnológicos!


Domina los fundamentos de Scrum y multiplica tu valor en el mercado

Fundamentos de SCRUM

Fundamentos de SCRUM

Es importante que domines los fundamentos de SCRUM si quieres implementar con éxito esta metodología.

Seguramente ya has leído libros y blogs que explican los diferentes procesos de SCRUM. El desarrollo en sucesivas iteraciones o sprints, el daily, el Sprint Planning, la retrospective, etc.

Si no conoces los fundamentos de SCRUM, lo mas probable es que cometas los mismos errores que la mayor parte de las organizaciones. Acabarás por implementar SCRUM como si fuera una religión y apenas conseguirás mejorar la productividad.

En novanotio defendemos que hay cuatro sencillas reglas que ayudan a gestionar con éxito los proyectos tecnológicos. Es una buena idea que revises nuestro artículo sobre las cuatro leyes antes de continuar con esta lectura.

En esta entrada vamos a analizar las relaciones entre las cuatro reglas básicas y los procesos de la metodología. Una vez que comprendas los fundamentos de SCRUM, estarás mejor preparado para implementarla en tu organización.

Relación entre SCRUM y la 1ª ley.

Las especificaciones son inciertas, imprecisas e infinitas.

La primera ley nos advierte tres cosas:

– Que el cliente no puede saber lo que quiere. El tiempo invertido en especificar suele ser tiempo perdido.

– Que una especificación redactada en lenguaje natural (castellano, inglés, alemán, etc.) es interpretable.

– Que no es posible finalizar los trabajos. Siempre queda algo por hacer.

¿Cómo responde Scrum a estos tres desafíos?

– El diseño es muy liviano; los requisitos se capturan en Epics, Features e Historias de Usuario, cuya extensión es de un párrafo.

– Para interpretar la especificación, se incorpora al squad un representante del cliente, el Product Owner,

– El Product Owner prioriza los trabajos para que el Retorno de Inversión sea el mayor posible, dentro del presupuesto.

Relación entre SCRUM y la 2ª ley.

One Project, One Team, One Site.

La segunda ley dice que para mejorar la productividad, todo el equipo de trabajo, incluido el cliente, debe estar en una única oficina y dedicarse en exclusiva al proyecto. La convivencia construye vínculos emocionales y relaciones de confianza que son imprescindibles.

¿Cómo construye Scrum los equipos?

En Scrum, los squads de desarrollo están formados por entre cinco y nueve consultores, cuyos puestos de trabajo están próximos entre sí. El Product Owner, que es el representante del cliente, es un miembro más del equipo.

Relación entre SCRUM y la 3ª ley.

Presión x Talento = Constante.

Talento y presión son antagónicos. Cuando uno crece, el otro disminuye.

La tercera ley nos recuerda que en el desarrollo de software debemos priorizar el talento sobre la presión. La velocidad de desarrollo depende del número de buenas ideas, no del número de horas de la jornada.

¿Cómo fomenta Scrum el talento?

Para eliminar la presión, en Scrum no es obligatorio completar todas las Historias planificadas para el sprint. Algunos desarrollos no superan los test y vuelven al backlog.

Relación entre SCRUM y la 4º ley.

El triángulo de Acero.

La cuarta ley nos enseña que Alcance, Plazo y Calidad están relacionados de tal forma que, si fijas dos de ellos, el tercero se degrada.

Tradicionalmente un contrato fija el alcance y el plazo. ¿El resultado? El 80% de los grandes proyectos son un fiasco.

Así que, como cliente, debes elegir entre:

– Sacrificar el Alcance. Ciertas funcionalidades no se construirán.

– Sacrificar el Plazo (y multiplicar el coste). El sistema se entregará muuucho mas tarde de lo planificado.

– Sacrificar la Calidad. El sistema tendrá errores en producción y será complejo de operar.

¿Qué variable sacrificamos en SCRUM?

La metodología SCRUM determina que la variable sacrificada es el Alcance.

La gran aportación de SCRUM es modificar la definición de éxito de un proyecto. Ya no tenemos que cumplir un alcance dentro de un plazo y con una buena calidad. Cosa que, por cierto, es imposible.

Éxito es conseguir el mayor retorno de inversión posible, dentro del presupuesto y en un plazo acotado.

¿Puedo mejorar la eficiencia sin usar Scrum?

Si conoces los fundamentos de Scrum, puedes utilizar los principios básicos de gestión de proyectos y mejorar el rendimiento de tus proyectos sin necesidad de implementar la metodología.

Pero SCRUM es la palabra de moda. ¡Aprende a implementar esta metodología y tu valor para el mercado se multiplicará!


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.