Errores comunes en desarrollo software (II)

Expectativas irreales. Incapacidad para comprender el significado de la palabra “estimación”. Esta mala praxis puede presentarse de dos formas:  bien mediante estimaciones optimistas, bien mediante una selección para desarrollo de un conjunto de funcionalidades demasiado ambiciosas.

Falta de apoyo efectivo al proyecto. Aquí la principal responsable es la parte directiva: planificación, control de cambios, introducción de nuevas prácticas de desarrollo… Sin esto surgirán compromisos irreales o cambios que dañarán el desarrollo del proyecto.

Falta de implicación de los stakeholders (personas implicadas e interesadas en el desarrollo del producto: clientes y usuarios). Toda persona relacionada de algún modo con el proyecto debe implicarse. Cuando todas estas personas se coordinan es más probable lograr un desarrollo rápido y satisfactorio.

Falta de involucración por parte del usuario. Conduce a una mala interpretación de los requisitos.

Políticas por delante del objetivo. Anteponer políticas a resultados es fatal para un buen desarrollo. El objetivo siempre es lo primero, y todo lo que ayude a alcanzar ese objetivo se cuidará y se aprovechará al máximo; todo aquello que sea un factor negativo para la consecución del objetivo se descartará.

Pensamientos pretenciosos. Las suposiciones optimistas no tienen razón de ser, conducen a la desesperación y a la sensación de fracaso. Es cerrar los ojos y esperar que todo funcione bien, sin ninguna base lógica que lo apoye. Esto es especialmente peligroso en las primeras estimaciones del proyecto, que es donde más se presenta este error.

En cuanto al factor productivo:

Estimaciones excesivamente optimistas. Mala percepción del proyecto, minimización de tareas de análisis y diseño, daño al plan, excesiva presión en los desarrolladores… todo esto daña la productividad a largo plazo. Es uno de los condicionantes más frecuentes y más graves.

Gestión de riesgos insuficiente. Riesgo es un error no común. Basta con que ocurra un riesgo no previsto de antemano para ralentizar e incluso cancelar el proyecto. Más claro y más simple imposible.

Fallo de subcontratación. Si se utilizan COTS (Components Of The Shelf, utilidades desarrolladas por terceros) y el diálogo con este personal no es fluido, podemos encontrarnos con componentes de baja calidad o que no se ajustan a lo que pretendíamos. La paradoja surge cuando vemos que siendo el objetivo de subcontratar el acelerar, lo que hemos conseguido es ralentizar.

Planificación insuficiente. La planificación debe ser apropiada para un desarrollo rápido.

Abandono del plan en situaciones de presión. Los equipos hacen planes y de forma habitual los abandonan cuando empiezan a tener problemas de calendarización. Otro de los habituales. El raíz del problema aquí yo creo que está en la percepción de que el plan es algo estático, que se hace al principio de forma muy estudiada y que si luego no se cumple, surge la alarma y el caos.
El plan es siempre dinámico, y la mejor cualidad de un plan debe ser su capacidad de adaptación y flexibilidad a todo tipo de situaciones más o menos esperadas (una vez más, aquí tiene mucho que decir una buena gestión de riesgos).

Tiempo perdido en fases “ante-proyecto”. Es decir: tiempo durante el cual se estudia el presupuesto, la viabilidad… Muchos proyectos pierden aquí demasiado tiempo y luego vienen las prisas en etapas más críticas y que precisamente necesitan más cuidado en su desarrollo por su riesgo inherente (ej.: diseño).


Referencias:

Steve McConnell: Rapid Development, Taming Wild Schedules

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s