PMI Madrid Spain

Artículos

Un citizen-developer es un usuario sin formación en programación, que crea software de negocio para otros usuarios, mediante plataformas de desarrollo Low Code (LCDP) o plataformas de desarrollo No Code (NCDP) supervisadas por el departamento de informática de la organización.

Todas las organizaciones, grandes o pequeñas, consolidadas o de reciente creación, necesitan cada vez más software para llevar a cabo sus procesos internos y externos, con clientes, proveedores, empleados, etc. Los departamentos de informática necesitan cada vez más programadores, en nómina o subcontratados, pero cada vez hay mayor escasez de programadores disponibles.

Afortunadamente, cada vez hay más plataformas en la nube que permiten crear código sin programar. Programar aplicaciones web o aplicaciones móviles de buena calidad ya es posible simplemente reusando componentes que ocultan la complejidad técnica y que permiten centrarse en el valor para el negocio.

Por ejemplo, cualquier persona sin formación técnica puede programar una encuesta con SurveyMonkey o Google Forms, una campaña de marketing por correo electrónico con Mailchimp, un informe visual con PowerBI, un portal o un blog con WordPress, etc. A continuación se enumeran otras plataformas No-Code muy populares:

  • Zapier, para conectar aplicaciones.
  • Shopify, para programar tiendas online.
  • AppSheet, adquirida por Google en enero de 2020.
  • Webflow, para programar páginas web.
  • Airtable, para programar bases de datos.
  • Glide, para programar aplicaciones móviles (no se instalan desde Google Play o App Store, son enlaces a aplicaciones web con apariencia móvil, también denominadas PWA).

En este vídeo puede verse cómo desarrollar fácilmente una aplicación móvil con Glide.

En la economía de proyectos, las personas tienen los conocimientos y habilidades necesarios para transformar las ideas en realidad, y las organizaciones entregan valor a los interesados mediante la conclusión exitosa de proyectos, entrega de productos, y alineamiento con los flujos de valor.

En este contexto, PMI está impulsando decididamente la figura del citizen-developer, inicialmente a través de un curso de fundamentos y la publicación de un libro. Propone un marco metodológico basado en roles, técnicas, modelo de madurez, etc., para que las empresas puedan beneficiarse del citizen development evitando problemas tan preocupantes como el Shadow IT.

En este vídeo puede verse la presentación de la iniciativa por parte de PMI.

Según una predicción de Gartner, en 2024, más del 65% de las aplicaciones de negocio serán desarrolladas con plataformas LCNC. Esto implica que la mayoría de los proyectos software tendrán en sus equipos algún citizen-developer. En estos proyectos, el project manager debe facilitar que el equipo colabore efectivamente con el personal de soporte del departamento de informática y también con los interesados de las áreas de negocio.

Es importante entender bien que citizen-development no significa que los proyectos software trabajen al margen del departamento de informática, sino más bien todo lo contrario: los equipos de proyecto usan las herramientas LCNC proporcionadas por informática, que siempre supervisa que se cumplen los requisitos no funcionales. El departamento de informática pasa de “trabajar para el negocio” a “trabajar con el negocio”.

Los proyectos software de la economía de proyectos usan modelos de ciclo de vida hiperágiles: construyen ágilmente prototipos y MVPs para entregar valor a los usuarios de negocio tan pronto como sea posible, bajo la supervisión técnica del departamento de informática.

En este vídeo puede verse un ejemplo de herramienta de prototipado rápido.

Cuando la economía de proyectos deba emplear ciudadanos programadores, nosotros los project managers debemos asegurar que todos los participantes colaboren para entregar valor al negocio. La gestión de requisitos eficaz siempre ha sido el mayor reto de los proyectos software. Como decía Tom DeMarco en su libro Peopleware:

“En los proyectos de software, es más importante la sociología que la tecnología”.

  JoseBarato

Por Jose Barato, PMP, PMI-ACP, vocal de PMI-Madrid

 

I was talking recently about someone in my professional life who I am really proud of.  Besides the fact that she is a friend and her success is great news, her success is even more special because I think I played a partial role in it.

As a leader or manager, this feels great.  As a friend, it feels great.  As a human being who loves to help others along the way, it feels great.

Is there someone in your life who you can say the same thing about?

When we study leadership, we focus on the people we lead. But so often, that focus goes to the successful completion of the work or projects or strategies that we are working on.  But what about the individuals themselves and their successes.  Great leaders take pride in their people – not just the current state but the future state as well.  Where they end up.  Where they go next.  The awards, recognition and promotions that came along the way

As a leader or manager, take pride in developing talent.  Be proud of them as they walk out the door to something bigger and better.  You can replace them – get over it.  Hopefully, if you did a great job in training, coaching and mentoring, they will recognize the role you played.  But if not – so what.  You can still be proud of your results.

I am a serial entrepreneur and a dreamer.  I come up with new ideas all the time, which comes with good news and bad news.  

The good news is that some of these ideas, well under 50% admittedly, are good ones: ideas that could serve my community well, or employ many people or even, shockingly, be profitable. 

The bad news is that sometimes (OK… often) my ideas don’t stand up well to the Strategy Stress Test (SST).  In fact, last year, I was cut-off from any new ideas unless it was given the OK by my coach and by my wife/business partner.  From that day on, I had to include these two individuals in my own SST.

We all need an SST – organizationally, professionally and personally.  We need a test that will put our strategic plans through the scrutiny that will ideally help avoid disasters or disappointment in the future.  

I would love to be able to present a perfect SST that will fit all organizations and all individuals, but I cannot. Every strategic plan is unique and thus every SST is unique.

ABSTRACT

 El análisis de riesgos en los proyectos, dentro de la globalidad existente, es una herramienta necesaria y fundamental ante el actual mercado competitivo. Sin duda, esta clase de sucesos siempre ha existido y de una manera u otra se han tenido que afrontar.

Dada la complejidad de los proyectos, se ha de realizar una adecuada gestión que garantice un uso eficiente de los recursos. No solo es necesario plasmar una planificación estratégica de los portafolios o programas de las compañías, además se debe analizar cada proyecto de manera específica con independencia de su tipología y singularidad para desarrollar la identificación de los sucesos.

Implantar de manera defectuosa la gestión de riesgos, o no hacerla con las herramientas adecuadas, es una de las principales causas de fracaso de los proyectos.

Por todo esto, hay que llevar adelante una planificación estratégica de la organización como un conjunto de buenas intenciones; además, se deben desarrollar mecanismos que los plasmen en la práctica.

De estas necesidades se estableció una serie de metodologías, normas, buenas prácticas o estándares y sistemas de gestión de riesgos: PMI®, IPMA®, COSO®, ISO®, etc.

dsdm

 

En un proyecto ágil se fija el tiempo que dispone la organización para conseguir los objetivos. No se calcula plazo estimando el tamaño de los requisitos, el trabajo que supondrían y lo que tardarían los recursos disponibles. No puede hacerse así porque no se conocen los requisitos en detalle suficiente. En lugar de calcular un plazo del proyecto, se toma este plazo como una restricción del negocio. Se hace una planificación inicial en la que se acaban sabiendo los requisitos de alto nivel, el plan de entregas, las restricciones de plazo, etc. Así planificamos inicialmente el cronograma y también el coste, pues un equipo continuo durante un plazo concreto tendrá un coste determinado.

Un proyecto de 12-24 meses, por ejemplo, suele dividirse en 4-6 fases de 3-4 meses cada una. Cada una de estas fases puede gestionar a su vez como un proyecto o fase, teniendo en cuenta los 49 procesos del PMBOK, si es preciso. En proyectos software, estas fases suelen denominarse "releases" porque tienen el objetivo de entregar a los usuarios finales una funcionalidad terminada. Al proceso de planificar una release se le denomina "release planning" y consiste en determinar en equipo las historias más importantes de la release y asegurarse de que se pueden entregar. Teniendo en cuenta la velocidad del equipo, que suele medirse en historias por iteración, puede calcularse el número de iteraciones, que deben tener una duración fija durante toda la release (concepto de time-box: las iteraciones ágiles siempre terminan en fecha, normalmente duran entre 1-4 semanas, pero si se decide 2 semanas, por ejemplo, esto no se debe cambiar hasta la siguiente release).

El alcance se va planificando en detalle a medida que la release avanza. El resultado del "release planning" suele denomiarse "release backlog", que es propiamente un subconjunto del "product backlog". Al principio de la release, en el release backlog tenemos historias muy grandes (deberían denominarse épicas, mejor que historias) y deben irse descomponiendo y refinando gradualmente. El Product Owner es el encargado de mantener refinada la planificación de las historias del release backlog, especialmente aquellas planificadas para la siguiente iteración. Las historias pueden cambiarse, los cambios son bienvenidos porque ocurren en el product backlog. No debe cambiarse, sin embargo, el trabajo que ha entrado en la iteración, en el que ya está trabajando el equipo de desarrollo.

En la ceremonia llamada iteration planning, el equipo de desarrollo planifica la iteración descomponiendo las historias en tareas que deben ir procesando para ser completadas antes de que finalice la iteración. Típicamente se usan tableros kanban con columnas to-do, doing, done, para visualizar cómo va el trabajo del equipo durante la iteración.

Cada día, en el daily standup, los miembros del equipo informan unos a otros de lo que han hecho desde el último daily, lo que se proponen hacer durante el día, y los impedimentos que les dificultan trabajar al ritmo que esperaban.

Es decir, en un proyecto agile, si se ejecuta siguiendo el marco Scrum, se planifica el día, la iteración (2 semanas), la release (3-4 meses), el proyecto (12-24 meses)...

La planificación suele quedar como reflejo fiel a los trabajos ejecutados, no hay scope creep, no hay padding, etc.

¿Podríamos decir que en un proyecto ágil, si se gestiona bien, se dedica más esfuerzo a planificar que en un proyecto predictivo?

  JoseBarato

Por Jose Barato, PMP, PMI-ACP, vocal de PMI-Madrid