 |
| Imagen obtenida de: comerecommended.com |
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.
¿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.
También puedes seguirnos vía Twitter, Facebook o Linkedin:
¿Interesado en libros sobre Gestión de Tecnología?
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.
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
>> Sección de Productos Amazon
Artículos relacionados
Reescribiendo el 8 como el 7:
ResponderEliminar7. Permitir la FICCION entre vendedores y el cliente (los usuarios).
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.
ResponderEliminarNormalmente 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!
Hola Daniel,
ResponderEliminarPermitir 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.
"24. Integración prematura o muy frecuente del producto." -> Estoy muy en desacuerdo con esto. De hecho es una gran virtud.
ResponderEliminar