¿Por qué el desarrollo de software falla y cómo evitarlo?

Los proyectos de desarrollo de software tienen siempre riesgo de que no resulten como se esperaba.

De acuerdo a estudios realizados, 25 por ciento de los proyectos de desarrollo de software fallan y del 20 al 25 no tienen un retorno de la inversión.

Lo peor aún es que un 50 por ciento o más incurren en retrabajo después de que concluyeron.

Sin embargo la pregunta es ¿por qué tantos proyectos fallan?.

Para una situación de tal dimensión te sugerimos ahondar al respecto y revises el contenido en nuestro Curso de gestión de proyectos en TICS. El capacitarte en gestión de proyectos te servirá después para comenzar la preparación para la Certificación PMP del PMI, que es la certificación en gestión de proyectos más valiosa a nivel internacional.

Si sospechas que tu sistema de software puede estar en riesgo por una mala calidad. Te invitamos a que bajes el siguiente test de evaluación.

Aunque muchos podríamos pensar que la respuesta se encuentra en aspectos técnicos, la realidad es otra.

En realidad más del 54 por ciento fallan debido a aspectos relacionados con su gestión y formas de trabajo en el equipo e involucrados.

Mientras que un bajo porcentaje es debido a problemas técnicos.

A continuación te diremos, cuáles son las razones principales por la que los proyectos fallan y lo que se puede hacer en cada una para prevenirlo.

1. Inadecuada gestión del proyecto de desarrollo de software

El no tener definidos y controlados elementos cruciales del proyecto como: requerimientos, planes, seguimiento, control de cambios, control de calidad, recursos requeridos, entre otros.

Esto dará como resultado una mala gestión de nuestro proyecto de desarrollo.

Derivado de esto veremos cuestiones como no lograr las fechas compromiso, tener un continuo cambio de alcance del proyecto, retrabajo y numerosos errores en las liberaciones que realicemos.

Para evitar esto es recomendable adoptar una metodología o modelo para nuestro proceso.

Existen diversas en el mercado de ellas podemos destacar las siguientes.

Scrum

Es un proceso para trabajar en equipo y aplicar las mejores prácticas dentro del marco de desarrollos ágiles.

En Scrum se realizan entregas parciales y totales del producto final, con la prioridad de lo que aporta más beneficio al cliente o quien recibe el proyecto.

El proceso consiste en ejecutar bloques cortos y fijos a los que se denominan iteraciones o sprints, normalmente son de hasta 2 semanas aunque pueden durar más.

Se dice que cada sprint debe proveer un resultado completo, es decir una parte del producto final que sea susceptible de entrega.

El product backlog será la lista completa de los objetivos que deberán estar priorizados para completar el producto.

Las actividades principales que se realizan en scrum son:

Planear la iteración
Ejecutar la iteración
Inspeccionar y ajustar

Por otro lado scrum identifica a roles principales dentro del proceso, en ellos tenemos a:

Product owner o dueño del producto
Scrummaster o facilitador
Equipo de scrum

CMMI

El Capability Maturity Model Integration o CMMI, es un modelo de madurez de capacidades para la mejora y evaluación de proceso de desarrollo, mantenimiento y operación de sistemas de software.

Este modelo se diseñó para que se use como base de las iniciativas a mejorar los procesos.

Para desarrollo se utiliza el CMMI-Dev o CMMI for Development, que es un modelo que contiene 22 áreas de proceso a los cuales se les asigna a un nivel de madurez organizativa.

Tiene dos representaciones el primero es por etapas y se representan de la siguiente forma:

Y la otra representación se de le denomina contínua.

Las 22 áreas de proceso que tiene el modelo CMMI son las siguientes:

Acrónimo	Área de procesos
CAR	Análisis y resolución causal
CM	Administración de configuración
DAR	Análisis y resolución de decisiones
IPM	Administración integrada de proyectos
MA	Medida y análisis
OID	Innovación e implementación organizativas
OPD	Definición de procesos organizativos
OPF	Enfoque de los procesos organizativos
OPP	Rendimiento de los procesos organizativos
OT	Aprendizaje organizativo
PI	Integración de productos
PMC	Control y supervisión de proyectos
PP	Planeación de proyectos
PPQA	Control de calidad de procesos y productos
QPM	Administración cuantitativa de proyectos
RD	Definición de requisitos
REQM	Administración de requisitos
RSKM	Administración de riesgos
SAM	Administración de acuerdos con proveedores
TS	Solución técnica
VER	Comprobación
VAL	Validación

PMBOK

Se enfoca a la gestión de cualquier tipo de proyecto tomando en cuenta 9 áreas de conocimiento (Integración, Alcance, Tiempo, Costos, Calidad, Recursos, Comunicación, Riesgos, Adquisiciones).

Por otra parte contempla 5 grupos de procesos (Inicio, Planificación, Ejecución, Seguimiento y Control, Cierre).

Mientras que las metodologías ágiles y tradicionales se basan en la gestión de proyectos exclusivamente de desarrollo de software.

Es decir su principal enfoque está en el producto cada una con sus ventajas y desventajas.

ITIL

El Infraestructure Library o biblioteca de infraestructura de TI es un marco de referencia que describe un conjunto de mejores prácticas y recomendaciones.

Todo esto para la administración de los servicios de TI.

Desde que comenzó se puso a disposición pública un conjunto de nombre, de ello se deriva su nombre.

En total para su segunda versión consta de siete libros que son los siguientes:

Soporte al servicio
Entrega del servicio
Seguridad
Infraestructura ICT
Administración de las aplicaciones
La perspectiva del negocio
Planeación para implantar la administración de servicios

Para cualquiera de estas metodologías y modelos, hoy en día es posible encontrar decenas de libros de referencia para su mejor entendimiento e implementación.

Así también existen para cada una de ellas certificaciones en el mercado que se podrán conseguir para la empresa o individuo.

2. Resultados pobremente definidos o sin definir

Aunque esto parece increíble pero muchos de los proyectos, no tienen claramente sus resultados definidos.

Así como es preciso definir con total precisión los requerimientos técnicos, diseños, guías y manuales, es primero indispensable que resultados queremos conseguir.

Estos deben ser precisos y carecer de ambigüedad, dado que serán en realidad lo que dará guía y dirección a todo lo que se especifique en nuestro desarrollo de software.

Una de las mejores formas para documentar y dejar claro lo que queremos conseguir como resultados de negocio, es a través de un documento de visión.

Aquí IBM tiene una plantilla con una estructura clara y bien definida de lo que debe tener tener dicho documento.

3. Falta de compromiso del equipo de proyecto

En la mayoría de los casos ocurre porque se cree que el área de sistemas o de tecnología, o en su caso el equipo de desarrollo de software es la responsable total y completo del éxito o fracaso del proyecto.

Esto es un error, que cometen los niveles directivos o gerenciales al dejar toda la responsabilidad solamente a dicha área o conjunto de personas.

El equipo de proyecto debe estar conformado tanto por el personal que construirá el producto en cuestión.

Así como los representantes de usuarios y personas que darán visto bueno y validación al sistema.

Si los ejecutivos no están dando la línea y recursos para que todos se involucren, participen y asuman la responsabilidad que les corresponde, será muy fácil que no funcione como un equipo integrado que genere resultados.

Para resolverlo se requiere que antes del inicio del proyecto, se identifiquen quienes son los diferentes responsables.

Una forma de hacerlo es a través de definir una matriz de responsabilidades RACI por sus siglas en inglés de Responsible, Accountable, Consulted e Informed.

El PM Project-management.com tiene ejemplos de como implementar la matriz RACI, un tutorial y hasta un Webinar.

El resultado debe ser algo parecido a esto.

Una vez identificados los responsables se debe convocar a la reunión de kick-off o inicio de proyecto, ahí mostrar el alcance y como se ve involucrado cada responsable dentro del proyecto.

4. Falta de comunicación del equipo de desarrollo de software y los demás

El tener una pobre comunicación, así como carecen de los mecanismos para propiciarla dará como resultado huecos y omisiones en el proyecto.

En muchos de los casos esto dará consecuencia a falta de definiciones que comúnmente deberá hacer los involucrados no técnicos o usuarios de negocio al equipo de desarrollo de software.

Será por lo tanto vital incluir tanto del equipo técnico como no técnico a miembros con habilidades sólidas de comunicación.

Como buena práctica en la planeación del proyecto se sugiere hacer un plan exclusivamente para definir, cuáles serán los elementos válidos de comunicación para el proyecto.

De ellos se puede definir:

Correo electrónico
Software de mensajería como Skype o Slack
Reuniones de trabajo o seguimiento al proyecto
Conferencias remotas
Registros o bitácoras de actividades
Entre otras

Por otro lado para garantizar también que hubo un adecuado entendimiento la información comunicada, es recomendable que se conduzcan sesiones del entendimiento y validación de requerimientos que las áreas usuarias proveen.

Algunos de los documentos que es recomendable realizar para evidenciar y obtener el visto bueno del entendimiento son:

Documento de visión del negocio
Historias de usuario y casos de uso
Prototipos
Documento de definición reglas de negocio
Modelo de procesos
Secuencias o actividades
Diagramas de contexto
Entre otros

5. No implementar pruebas o revisiones

El no planear y ejecutar pruebas consistentes de las funcionalidades desarrolladas en el producto de software en un gran problema.

Dado que los sistemas son diseñados para ejecutarse por personas y no por máquinas, el no validar su funcionamiento y entendimiento, dará posibilidad a que el software no se desarrolle como es requerido.

La gran mayoría de los programadores e ingenieros creen saber lo que el usuario quiere, pero esto puede diferir mucho de lo que en realidad son sus necesidades y problemas.

Por lo tanto es indispensable conducir en todo momento pruebas y verificaciones tanto al software, como a la especificación del mismo respectivamente.

Una vez que se empiezan a realizar pruebas se comienza a tener una retroalimentación por parte de los usuarios, por lo que dará pie a que se alinee con lo que está requiriendo.

De esta manera entre antes se empiece con las verificaciones y pruebas en el proyecto de desarrollo de software, se comenzarán a depurar y eliminar cualquier concepción errónea que se haya hecho.

Las pruebas no se deben detener nunca y es obligación del equipo de proyecto realizarlas en todo momento, así como asegurarse de tener el visto bueno del usuario.

Algunas de las plataformas más utilizadas y mejor probadas para desempeñar pruebas son las siguientes:

Zephyr

Es la número 1 en ventas con más de 11,000 clientes alrededor del mundo, en más de 100 países y con más de 20 millones de pruebas ejecutadas.

Zephyr ofrece diferentes aplicaciones y visibilidad en tiempo real para conocer el estatus de los proyectos de desarrollo de software.

Se integra con herramientas las herramientas que el equipo ya están usando como JIRA, Selenium, QTP / UFT, Bamboo, Jenkins, Confluence y mucho más a través de una bien documentadas API REST.

qTest

No es de extrañar por qué qTest es la herramienta de gestión preferida entre los equipos de pruebas y QA ágiles.

QTest ofrece equipos de pruebas y desarrollo de software con una gestión de pruebas fácil de aprender, fácil de usar, rápida y escalable que se integra perfectamente con JIRA, otros ALM y herramientas de automatización.

QTest ha demostrado que cada paso del proceso de control de calidad es más rápido, sencillo y eficiente como:

Administrar Requisitos, Repositorio de casos de prueba, Ejecución de pruebas, Seguimiento de defectos, Informes e Integraciones.

PractiTest

Un completo SaaS de extremo a extremo de control de calidad y ágil herramienta de gestión de prueba.

Utilizando sus filtros únicos y personalizables, puede organizar eficientemente sus necesidades, crear y ejecutar pruebas, rastrear errores y generar informes utilizando esta herramienta.

Se integra perfectamente con las principales herramientas de seguimiento de errores como JIRA, Pivotal tracker, Bugzilla y Redmine, así como diversas herramientas de automatización como Selenium, Jenkins, etc.

Sin embargo, su API puede garantizar una personalización adicional para las necesidades de su proceso.

Test Collab

Test Collab es una herramienta de gestión de pruebas moderna que ofrece una plataforma completa para las pruebas de su aplicación.

Ofrece una integración de última generación con todos los populares buscadores de errores y herramientas de automatización de pruebas.

Aparte de eso, ofrece seguimiento de tiempo, metodología ágil, gestión de requisitos, planes de prueba y programación.

QAComplete

QAComplete es una herramienta de gestión de pruebas potente y flexible.

Ayuda a los usuarios a gestionar fácilmente los requerimientos, las pruebas y los defectos en un solo lugar.

La herramienta es fácil de usar y proporciona un concentrador central para administrar e informar sobre todas sus pruebas: manual, Selenium, TestComplete, SoapUI y mucho más.

Conclusiones

Como podemos darnos los principales problemas que afectan a los proyectos de desarrollo en realidad no son técnicos.

Sin embargo, sí hay problema técnicos que pueden tomar tiempo en resolver para el equipo desarrollo.

A pesar de esto los problemas técnicos se pueden sobrepasar después de encontrar la solución.

Para todos los demás problemas relacionados con la gestión del proyecto y personas involucradas, es deber de los responsables de proyecto implementar las medidas recomendadas.