Gestión de la dilatación del alcance y la sobrerregulación en proyectos de software

En el caso de los proyectos informáticos, las amenazas más frecuentes son el Scope Creep (procedente del propietario) y el Gold Plating (procedente del PM, el Scrum Master o los desarrolladores). Cambios incontrolados en el proyectoañadir nuevas funcionalidades o introducir cambios pertenecen sin duda a las amenazas que afectan tanto a la eficacia como a la velocidad de los proyectos. En el pasado tuvimos la oportunidad de cooperar con empresas de nueva creación y grandes corporaciones como Livenation / Ticketmaster, Stroer o Agora (el mayor grupo de medios de comunicación de Europa). Durante este tiempo, coordiné muchos proyectos de TI, especialmente los relacionados con desarrollo de software. Esta experiencia me permitió comprender que no importa si trabajas en una empresa pequeña o grande: si quieres tener éxito, debes ir un paso por delante de tu competencia.

Me gustaría compartir mis ideas sobre el desarrollo eficaz de proyectos de desarrollo de software. Como CCO en Codest, ejecutamos proyectos todos los días para empresas globales de todo el mundo. El enfoque adecuado de la gestión es la primera etapa clave que influye posteriormente en el éxito del proyecto. Distingo cuatro principios básicos, cuyo mantenimiento nos ha permitido desarrollar un modelo de gestión realmente eficaz. Gracias a ellos, evitamos problemas posteriores - incluidos los relacionados con la fluencia y la siembra de oro 'alcance. Aquí están:

1. Metodólogo. Independientemente de la envergadura del proyecto o de su nivel de avance, siempre aplicamos una metodología adecuada que nos permita gestionar el proyecto de forma coherente con el Ágil enfoque. En este caso, el metodólogo Scrum nos ayuda. Y gracias a ello, tenemos todas las etapas del proyecto bajo control. Cada miembro se centra en tareas estrictamente definidas. De este modo, evitamos distracciones innecesarias y mantenemos la máxima eficacia del trabajo.

2. MVP. Puede llamarse nuestro principio fundamental. Si quiere crear una aplicación, hágalo, pero en un rango muy básico. Ahorrará tiempo y evitará riesgos de agotamiento del presupuesto. La visión inicial de la producto suele verificarse y modificarse posteriormente. Con el tiempo, el cliente puede cambiar de opinión sobre las características necesarias de una aplicación, lo que, a su vez, genera costes innecesarios y alarga el trabajo.

El enfoque MVP funciona bastante bien. Creamos una aplicación que tiene, por ejemplo, 20% de todas las funcionalidades, pero ya es capaz de verificar su valor en el mercado. De este modo, el cliente recibe la opinión de los usuarios y sabe qué características debe tener su producto para ser eficaz. A continuación nos centramos en el desarrollo de estos elementos. Un gran reflejo de este proceso son los gráficos que se adjuntan a continuación:

3. Pruebas. Las pruebas de las funcionalidades individuales de la aplicación están directamente relacionadas con el MVP. Si resulta que algo no funciona como debería, es mejor rechazarlo y buscar una solución alternativa. En Codest, hemos conocido a clientes que, desde el principio, desde impusieron la forma final de una aplicación y estaban seguros de que esta es la única visión correcta. No quisiera extenderme sobre los efectos posteriores que tuvo este enfoque. Por eso considero necesario insistir una vez más en que la sencillez es la clave del éxito.

4. Desarrollo. La construcción de la aplicación debe comenzar con UX, Diseño, Backend y Frontend. En resumen, todo comienza con las tareas sencillas "imprescindibles" que conforman el producto MVP. Una vez alcanzada esta fase de desarrollo, puedes centrarte en el desarrollo de la funcionalidad denominada "nice to have".

Resumen

En mi opinión, estos son cuatro principios básicos estupendos para gestionar proyectos de desarrollo de software. Este enfoque reduce los riesgos de distracciones innecesarias, la prolongación de las horas de trabajo y la ineficacia de los costes.

Por último, permítanme darles un ejemplo más. Hace algún tiempo recibimos las especificaciones de un proyecto de un cliente. Inmediatamente nos unimos al equipo para evaluarlo. El cliente esperaba que creáramos el producto en doce meses. Según nuestro planteamiento, propusimos un enfoque MVP y un periodo de desarrollo de tres meses. Al final, conseguimos convencer al cliente. Al cabo de unos meses, quedaron impresionados con la solución. El cliente recibió su producto operativo en un plazo relativamente corto. En el caso de varias funcionalidades, decidieron cambiar el proyecto asumido desde el principio.

El modelo que he descrito en este artículo es nuestra forma de ejecutar con éxito proyectos de desarrollo de software. Créanme, esta solución no sólo mejora el trabajo y lo hace eficaz, sino que, como resultado, ayuda a evitar el alcance de la fluencia y el gold plating.