Errores clásicos en la gestión de desarrollo de software - La Oficina de Proyectos de Informática

miércoles, 17 de julio de 2013

Errores clásicos en la gestión de desarrollo de software

Imagen obtenida de: comerecommended.com
En 1996, Steve McConnel, un influyente consultor de la industria del desarrollo del software, público su obra “Desarrollo Rápido: Domesticando Cronogramas Salvajes de Software” (Rapid Development: Taming Wild Software Schedules).

Una de las secciones del libro, describen los errores clásico al tratar de acelerar (o hacer Fastrack) de los proyectos, prácticas de desarrollo de software que son seleccionadas con tanta frecuencia y con los mismos malos resultados predecibles, que merecen ser llamadas “clásicos”, y que siguen estando muy vigentes a pesar que la obra se público hace 17 años.

¿Algunas de estas prácticas erróneas le son familiares?, por ejemplo, ¿Qué hacemos si un proyecto está retrasado?, ¿incorporamos más gente?, ¿que hacemos si algún integrante está dañando la productividad del equipo?, ¿esperamos hasta el final del proyecto para despedirle?, o ¿que haría si le han asignado un proyecto agresivo en fecha?, ¿reclutar a todos desarrolladores disponibles (inclusive si son novatos) e iniciar lo antes posible sin planificación?.

A continuación dejamos la lista, si conoces algún error clásico que no esté incluido, te invitamos a dejar un comentario.

Los Desarrolladores, Gerentes y Clientes usualmente tienen buenas razones para tomar las decisiones que toman, pero estos errores clásicos se han cometido con tanta frecuencia que hoy en día sus consecuencias son fáciles de predecir, y la experiencia ha demostrado que lejos de mejorar la situación, tienden a agravarla.

A continuación los errores clásicos en proyectos de desarrollo de software de Steve McConnel

Gestión de Personal
Procesos
Producto
Tecnología
1.     No dar importancia a la motivación.
2.     Aceptar personal con debilidades.
3.     No controlar a empleados problemáticos.
4.     Privilegiar el “Heroismo” en lugar de el buen desempeño continuo.
5.     Incorporar personal a un proyecto retrasado.
6.     Permitir oficinas ruidosas, con muchas personas.
7.     Permitir la fricción entre desarrolladores y el cliente (los usuarios).
8.     Comprometer expectativas no realistas.
9.     Carecer de patrocinio efectivo.
10.  Carecer de apoyo de interesados (stakeholders).
11.  No involucrar a los usuarios finales.
12.  Privilegiar la politiquería sobre los resultados.
13.  Exceso de optimismo.
14.  Permitir cronogramas optimistas.
15.  No gestionar  los riesgos o gestionarlos de forma insuficiente.
16.  Usar contratitas y no gestionarlos.
17.  Planificar de forma insuficiente.
18.  Abandonar la planificación al estar bajo presión.
19.  No aprovechar el tiempo mientras el proyecto es aprobado.
20.  Ir directo a la programación sin hacer análisis y diseño.
21.  Diseñar de forma inadecuada.
22.  Omitir revisiones, inspecciones de código y pruebas, al estar bajo presión.
23.  Insuficiente control por parte de la Gerencia.
24.  Integración prematura o muy frecuente del producto.
25.  Omitir tareas esenciales en las estimaciones.
26.  Planificar para recuperar el retraso después.
27.  Programación alocada (Code Like Hell).

28.  Incluir al principio requerimientos no necesarios realmente (Gold Plating).
29.  Permitir constantes cambios en los requerimientos, sin aplicar controles.   (Feature Creep).
30.  Incluir requerimientos técnicos no necesarios (Developer Scrope Creep).
31.  Modificar el cronograma para corregirlo, pero luego agregar más esfuerzo y tareas.
32.  Desarrollo orientado a la investigación (Hacer investigación de Software en lugar de desarrollo de software).
33.  Síndrome de la bala de plata. (Asumir que la misma solución funciona para todo).
34.  Sobrestimar los ahorros que se pueden obtener al implementar nuevos métodos o herramientas.
35.  Cambiar herramientas en el medio del proyecto.
36.  Carecer de automatización de control de código fuente.

¿Y qué opinas tú? 

¿Te has encontrado con estas prácticas erróneas?, ¿Cuál fue el resultado?, ¿conoces otra práctica que te ha traído resultados desastrosos en tus proyectos de software?, te invitamos a dejar tus comentarios en la Web de La Oficina de Proyectos de Informática (pmoinformatica) (Si lo deseas, puedes firmar tu comentario con la dirección de tu web).

¿Buscas más información de metodologías ágiles?

¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y otros recursos de metodologías ágiles?, entonces presiona "suscríbete" a continuación.

Suscríbete a la lista de correo electrónico:


Vía FeedBurner, se abrirá una nueva ventana

También puedes seguirnos vía Twitter, Facebook o Linkedin:

  

¿Interesado en libros sobre Gestión de Tecnología?











Steve Jobs (en Castellano)
Autor: Walter Isaacson
>> España (amazon.es)
>> Latinoámerica (amazon.com)
>> Ver reseña
Claves del marketing digital
Autor: Silvina Moschini
>> España (amazon.es)
>> Latinoamérica (amazon.com)
Social Media: Métricas y Análisis
Autor: Media Active
>> España (amazon.es)
>> Latinoámerica (amazon.com)

Gestión de 
Servicios de TI
basado en ITIL V3
Autor:
Ruby Tjassing
>> España (amazon.es)
>> Latinoamérica (amazon.com)

Novedades Amazon

¿Interesado en otros productos Amazon sobre Gestión de Tecnología de Información y Proyectos?
>> Sección de Productos Amazon

Artículos relacionados


4 comentarios :

  1. Reescribiendo el 8 como el 7:

    7. Permitir la FICCION entre vendedores y el cliente (los usuarios).

    ResponderEliminar
  2. De acuerdo a nuestra experiencia, el error más grave que se comete en los proyectos es justamente en el principio de los mismos y tiene que ver con el establecimiento de la necesidad a cubrir.
    Normalmente el cliente viene y nos pide "un sistema para" y nos ponemos de inmediato a ver la mejor manera de hacerlo, cuando muchas veces no indagamos en el para qué, y mucho menos planteamos alternativas diferentes a hacer un sistema (eso iría en contra de nuestra función como informáticos ¿o no?)
    Por otro lado, el otro problema serio es elegir mal la metodología a utilizar. No existen las metodologías omnivalentes...
    Se plantea en el artículo el tema de los cambios en los requerimientos como si esto fuera un error a evitar, cuando en realidad es parte de la vida diaria. Cambia el entorno, cambia el negocio, cambia el mercado, cambias las personas, por lo cual, es imposible que un proyecto no cambie en sus necesidades (al menos esto es así en la mayoría de los proyectos de software), o que el cliente se vaya dando cuenta de otras necesidades o mejores formas de cubrirlas en el camino, a medida que se avanza en la profundización en el problema.
    Por eso las metodologías ágiles están teniendo una presencia mucho mayor en las empresas, porque resuelven muchos de los problemas planteados de manera más natural.
    Mi humilde opinión.
    Gracias por compartir!

    ResponderEliminar
  3. Hola Daniel,

    Permitir cambios en los requerimientos en principio no es un error a evitar (de hecho, en los nuevos enfoques de desarrollo ágil es bienvenido), lo que sí es un error es permitir cambios sin control, por ejemplo no tener un procedimiento de revisión de todos los interesados, escalamientos, aprobaciones, ect. En el artículo no lo habíamos escrito así, gracias por el comentario (hemos modificado ligeramente la redacción).

    Enfoques tradicionales (predictivos), trabajan estos cambios como factores externos a la ejecución (debe revisarse el cambio, estimarse y aprobarse). Por otro lado, los enfoques ágiles literalmente, "incorporar en cambio dentro de sus procedimientos".

    Un Saludo.

    ResponderEliminar
  4. "24. Integración prematura o muy frecuente del producto." -> Estoy muy en desacuerdo con esto. De hecho es una gran virtud.

    ResponderEliminar

Pmoinformatica.com," La Oficina de Proyectos de Informática ", es un participante en el Programa de Servicios de Amazon Associates LLC, un programa de publicidad de afiliación diseñado para proporcionar un medio para que sitios web puedan ganar honorarios por la publicidad y enlaces a amazon.com y amazon.es.