Processes In Information Technology

Negative point of view

Existen personas que creen que los procesos ъnicamente significan una carga adicional de trabajo innecesaria e ineficiente. Creen que la mejor forma de manejar un proyecto es contratar a la mejor gente, darle los recursos que pidan y dejar que trabajen a su manera. Creen que los procesos no son necesarios ni que se requiera prestar atenciуn a la manera como se esta llevando el proyecto. Esto se puede representar mediante la siguiente grafica:

Sin embargo, esto es incorrecto ya que los procesos si se llevan a cabo correctamente, solo llegan a formar parte de la etapa inicial, no de todo el proyecto. Ademбs, los proyectos que no establecen procesos al inicio, donde el costo es mнnimo, de cualquier forma terminan estableciйndolos en etapas intermedias o finales, donde el costo es mucho mayor y a veces hasta se pierde todo el proyecto.

Algunos escenarios muestran porque es mejor llevar a cabo los procesos desde un principio:

Control de cambios: Un ejemplo es cuando informalmente se accede a realizar cambios en etapas intermedias del proyecto, sin embargo, no se controlan esos cambios sino hasta el final que es cuando tanto el alcance del proyecto como el presupuesto para el mismo se han expandido.

Aseguramiento de calidad: Los proyectos que no llevan a cabo procesos para eliminar defectos en las etapas iniciales, caen en ciclos de pruebas interminables, donde constantemente se reÑŠnen los miembros del proyecto para tratar de corregir los defectos que no se detectaron a tiempo. Por consiguiente, muchas veces se saca al mercado software defectuoso y en el peor de los casos ni siquiera alcanza un nivel de calidad con el que se pueda sacar al mercado.

Revisiones no controladas: Los defectos que no se detectan a tiempo pueden ocasionar que el software sea rediseсado y reescrito durante la etapa de pruebas. Como esto no es algo planeado, el proyecto se ejecuta sin ningъn plan o control.

Seguimiento de defectos: Existen casos donde no se corrigen defectos debido a que estos son olvidados, por lo que el software se libera aun cuando estos defectos hubieran sido fбciles de corregir.

Integraciуn de sistemas: Los componentes desarrollados por separado no se integran sino hasta el final del proyecto. Sin embargo, al momento de integrarlos, las interfaces entre los componentes no corresponden y se tiene que hacer trabajo adicional.

Control de cуdigo fuente automatizado: Se establece el control del cуdigo fuente hasta el final, por lo que se sobrescribe cуdigo.

Calendarizacion: Cuando los proyectos se atrasan, los desarrolladores deben hacer una reestimaciуn del trabajo, por lo que se pierde tiempo.

Entre menos se tomen en cuenta los procesos en un proyecto, se pierde mucho mas tiempo corrigiendo errores en vez de dedicarlo a liberar el software. Cuando los desarrolladores se dan cuenta que no estбn cumpliendo con las fechas lнmite, se enfocan ъnicamente a sus asuntos y se mantienen alejados de administradores, clientes, testers, tйcnicos, asн como del resto de su equipo, y se pierde mбs la coordinaciуn.

Esto difiere de la visiуn que tienen los que creen innecesaria la implementaciуn de procesos, y lo que sucede en realidad se muestra en la siguiente grafica

Bajo este patrуn, a mitad del proyecto, el equipo se da cuenta que incrementa el nivel de trashing, lo que significa investigar informaciуn que ha sido abandonada o eliminada, y que implementar ciertos procesos podrнa ser beneficioso. Sin embargo, a esas alturas del proyecto ya es demasiado tarde y lo ъnico que consiguen es mantener el nivel de trashing igual o hasta se produce mбs.

Los proyectos que corren con suerte logran lanzar el software al implementar algo de procesos, pero hay otros que no completan el software debido a que todo el tiempo lo tienen que dedicar a implementar procesos y al trashing y al final terminan cancelando el proyecto y el resultado es mucho peor que haber implementado procesos desde el principio.

Process to the rescue

Sin embargo, con esto no se esta refiriendo a implementar procesos rнgidos e ineficientes (R. I. P), sino aplicarlos de manera que incrementen la eficiencia.

Cuando este tipo de procesos se lleva a cabo, el proyecto toma la siguiente forma:

En la grafica se puede ver que durante las primeras semanas los equipos que utilizan procesos pueden parecer menos productivos debido a que el trashing es el mismo para ambos, mientras que se estarнa dedicando gran parte del tiempo a los procesos.

A mediados del proyecto, el equipo que utilizo procesos ha reducido el trashing que presentaba y mantiene un orden en la ejecuciуn de las etapas del proyecto. En este punto es cuando el equipo que no lo hizo se da cuenta que en su caso este empieza a representar un problema mas serio y apenas comienza a buscar implementar procesos por su cuenta.

Al finalizar el proyecto, el equipo orientado a procesos va a estar funcionando de manera mбs eficiente, y aunque tolera un poco de trashing al final debido al trabajo adicional que representarнa eliminarlo.

Process vs Creativity and Morale

Uno de los problemas para la implementaciуn de procesos es que los programadores creen que esto va a limitar su creatividad. Surgen diferentes necesidades ya que los programadores quieren que se les deje ser creativos, mientras que los administradores del proyecto buscan que se pueda visualizar el progreso del proyecto, asн como cumplir con un calendario y adherirse al presupuesto.

Esto se debe a que