Cosas a tener en cuenta al aplicar técnicas de gestión de calidad de proyectos de TI
Los desarrolladores de proyectos de TI generalmente creen que es difícil completar proyectos con alta calidad y a tiempo. No es que los gerentes de proyectos no quieran resultados de proyectos de alta calidad, solo quieren poder completarlos. a tiempo según la calidad. Lograr este proyecto una vez finalizado y por debajo o dentro del presupuesto. Si bien algunas técnicas de gestión de proyectos pueden efectivamente reducir los costos y el tiempo de desarrollo sin comprometer la calidad, es importante señalar que el uso excesivo de estas técnicas tiene el potencial de tener consecuencias desastrosas.
1. Time boxing
En la lista de eventos que destruyen la calidad de un proyecto, la aplicación del time boxing ocupa el primer lugar cuando le dices a alguien que se debe entregar una tarea. Antes de saber cuánto tiempo tiene para completar el trabajo, digo "entrega" en lugar de "completar", porque en casos extremos, esto a menudo significa que el código no es perfecto y es solo cuestión de tiempo completar el trabajo.
En la mayoría de los casos, el timeboxing es efectivo porque hace cuatro cosas:
1. Obliga a los desarrolladores a ser creativos y trabajar dentro de su presupuesto.
2. Elimina adornos innecesarios que a menudo se agregan al software, y estos adornos a menudo no aumentan el valor del software.
3. Evita que los desarrolladores realicen pruebas excesivas.
4. El propósito es simplemente obtener este producto. Se realizarán pruebas detalladas durante la etapa de evaluación de calidad (QA) completa. Se espera que se puedan encontrar problemas en el código durante esta etapa.
Cuando hay problemas desconocidos, o la tecnología no ha sido probada, o no existe una forma correcta de verificar los resultados, el timeboxing es inútil cuando el timebox es pequeño y no existe dentro del tiempo asignado. El enfoque también es ineficaz cuando es posible. En otras palabras, el timeboxing puede resolver bien algunos problemas, como comprender completamente, evaluar y ejecutar tareas cuidadosamente; sin embargo, también hay problemas que el método timeboxing no puede resolver bien, como la investigación y el desarrollo, la resolución de problemas, etc.
Si el timeboxing se utiliza correctamente, no debería resultar en pruebas de código incorrecto que pueden llevar a cientos de horas de diagnóstico y reelaboración. El timeboxing debe utilizarse de forma adecuada para garantizar el software de menor coste, más rápido y de mayor calidad.
2. Retraso
Todos deben tener un objetivo por el que esforzarse. Los hitos son un método respetado que se utiliza para inspirar a las personas a avanzar hacia el mismo objetivo. Esta motivación puede obtener resultados significativos. en un período de tiempo muy corto. Sin embargo, todos deben aceptar que no siempre se logran hitos y es necesario tomar nuevas decisiones.
Los gerentes de proyecto deben establecer objetivos hitos en el equipo para motivarlos a seguir adelante. Sin embargo, cuando la fecha establecida por el hito no es realista y los miembros del equipo cometen errores repetidos, entonces esto debe reevaluarse. Planeado. Si algunas circunstancias especiales hacen que esta fecha ya no sea importante, cuando llegue la fecha importante, todo el equipo tendrá pocos incentivos para alcanzar esta fecha importante. Cuando todo el equipo se pierde 10 fechas seguidas, ¿importa la fecha 11? Es como un niño llorando lobo.
Si no hay sanciones después de un cronograma establecido, entonces se debe aplicar o mover todo el cronograma cuando se incumpla este tiempo.
A la larga, crear un entorno constantemente estresante y confuso no crea un buen software. Los desarrolladores necesitan un entorno en el que puedan concentrarse en su trabajo. Las fechas de finalización del proyecto y la confusión sobre si las fechas de los hitos son reales a menudo llevan a los desarrolladores a omitir pasos críticos en el proceso de desarrollo o crear problemas difíciles de encontrar.
3. Ignorar dependencias
En el desarrollo de software, tenemos muchas técnicas para retrasar las dependencias. Podemos deshabilitar algunas funciones, mover la estructura básica de la conexión o evitar. Hay numerosos errores. Cuando se utilizan correctamente, todas estas técnicas pueden ayudar a avanzar en un proyecto. Sin embargo, cuando el factor de costo de estas técnicas no se tiene en cuenta en el plan general para completar el proyecto, quedan enterrados.
Muchas veces, organizar el orden del desarrollo de software en un proyecto es muy desafiante no es fácil de encontrar, por lo que es inevitable que muchos factores relevantes no estén ordenados en el plan. La programación para estas dependencias imprevistas puede volvernos locos, por lo que a menudo se utilizan métodos para suprimir las dependencias, pero si estas técnicas se utilizan en exceso, estos gastos a menudo pueden sumar una cantidad significativa del costo total del proyecto y no lo harán. ser descubierto hasta el final del proyecto.
Así que asegúrese de que lo que está haciendo ahora sea necesario para gestionar las dependencias, no agregue demasiados costos y sea una parte esencial del proyecto general de desarrollo de software. Cuando los gerentes de proyectos no logran equilibrar los costos con la conveniencia de reducir las dependencias, el código que ensamblan descuidadamente presentará problemas de calidad.
4. Haz como si no hubiera errores.
En la gestión de proyectos, el abandono no es una bendición. Además de una presión política imparable, es necesario educar al resto de la empresa sobre los riesgos del proyecto para poder completarlo con éxito. Casi todos los proyectos de desarrollo de software corren el riesgo de retrasarse, excederse del presupuesto o ambas cosas.
El problema es que cuando finalmente, en algún momento, estos riesgos se conviertan en realidad, causará pánico y todos estarán armando el resto del proyecto en un caos, y la calidad de todo el proceso se verá afectada. El proyecto se verá afectado.
Por supuesto, este problema no quedará completamente expuesto hasta que todo el proyecto esté retrasado. Sin embargo, la mayoría de los proyectos tienen una manera de dejar que ciertas partes del proyecto se retrasen un poco, y casi nunca se retrasan. retrasado. Todo proyecto corre el riesgo de apresurarse porque la dirección no está informada del verdadero estado del proyecto mucho después de que el proyecto haya quedado libre de cualquier problema.