Situación General en el Desarrollo de Software

Síntesis

El objetivo del presente artículo es mostrar algunos conceptos que ejemplifican situaciones emergidas de los equipos de desarrollo de áreas de ingenieria de software de las organizaciones actuales que se encuentran en grados de inmadurez elevados y conforman un nivel caótico empresarial, graficando las cuatro horas que conceptualmente dan forma abstracta al desarrollo conceptual.
Introducción

Mucho se puede decir sobre esta temática hoy en día, las organizaciones discuten puntos importantes a cada hora sobre como seguir adelante, sobre ser más productivos, como minimizar el éxodo de recursos, y claro está surgen muchos interrogantes y teorías que pueden distorsionar la estrategia del área o incluso modificar la misma organizacional.

El desarrollo de software es una temática de interés crítico actualmente, todo gira sobre diversas metodologías, existen niveles de calidad y madurez que son certificados, pero las organizaciones tienen muchos quiebres, que verdaderamente se pueden mejorar paulatinamente, pero radicalmente importante es remarcar, no de la noche a la mañana.

Hay varios puntos de vista para analizar la situación, comenzaré definiendo un efecto que encontré en muchas organizaciones y charlas que fui desarrollando en el último tiempo.

Veremos algunas fases y como podemos afrontar los puntos explícitos de la organizaciones de hoy en día.

Nivel caótico Empresarial

Existen diversos puntos dentro de efecto anteriormente detallado y denominado “caótico empresarial”, no quiere decir que solo estos puntos detallados formen el famoso efecto empresarial pero si que estos seguramente desencadenan riegos difíciles de manejar en un área de ingeniería de software.

l Requerimientos no se pueden tener bajo control.

Como seguramente pasa por sus cabezas es algo normal encontrar quiebres sobre los requerimientos que se encuentran fuera de control, o como realizar un trazado correcto dentro del marco ingenieril del desarrollo de software. Todos pasamos por una de estas situaciones, el hecho de que sea emergente en un alto porcentaje de proyectos marca una tendencia y ese es el punto a tener en cuenta.

l Generalmente no se pueden controlar las versiones de un producto.

La gestión de requerimientos no es el único hecho que conforma el tan desagradable caos empresarial (hablando del software), las configuración de los paquetes alcanza problemas inmanejables también, versiones de ensamblados y otra vez como realizar un mapeo acorde dentro del proceso, se convierte en pesadilla para los integrantes del equipo y luego para la parte ejecutiva del área..

l En ocasiones la calidad es percibida como una burocracia innecesaria.

No siempre ocurre, pero si es grave llegar a este nivel, en líneas generales las organizaciones que toman este concepto en un 100% conforma un nivel extra de caos, pero el punto radica en que muchas veces se descuidan procesos vitales para un proceso o paquete por el simple hecho de que escapa a lo funcional, frases como “lo dejamos para una iteración posterior, donde lo manejaremos con un toque de calidad” es normal escuchar entre pasillos, esto como supondrán no ayuda en mucho a nuestro pseudoideal proceso ingenieril.

l Los procesos son una cosa personal

Muchas veces un concepto repetido lamentablemente, la famosa dependencia de la pericia de quien realiza el proceso, y en esto soy radical con mi exposición, una organización que madura no puede permitirse depender completamente de las prestaciones de sus recursos 100%, del nivel del mismo para todo, si, tiene que evolucionar en sus procesos, pero, si perder un recurso implica perder todo lo realizado….., imaginemos en donde nos encontramos.

l No se puede verificar ni validar el producto.

Esto de no poder validar o verificar un producto nos genera una incertidumbre extra, pensamos que tenemos un equipo trabajando para realizar pruebas, pero necesito concretamente la validación, el modelo del mismo y claro está, necesito saber como se encuentra eso con mi proceso, el de mi área, cuando tenga esta relaciones concretas bien estipuladas estaré en condiciones de verificar y validar el producto y claramente de ensamblarlo a mi proceso.

l Gerentes y personal viven bajo condiciones de stress y frustración permanente.

Todo este marco como puede que les haya pasado, genera mucho stress y claro en muchos casos frustración desmedida.


Luego del efecto planteado solamente por algunos de los puntos más importantes les voy a detallar las famosas horas que llegan y matizar a las organizaciones de desarrollo de software en donde el efecto caótico empieza a emerger.

Hora Artesanal

A esta fase le coloqué ese nombre ya que es normal encontrar este tipo de situaciones en las organizaciones actuales, puntualmente en áreas de ingeniería o desarrollo de software donde no existe un proceso bien estructurado.
Pero la pregunta que deben estar elaborando internamente es,
¿Cuales son los puntos que conformas esta fase?, veamos algunos…

l El software es virtualmente producto del arte más que de la Ingeniería.

Proporciona una visión fuera del proceso, fuera del modelo propiamente dicho de la ingenieria de software, sin artefactos o con escasa cantidad de ellos, ni siquiera los necesarios para lograr una traza entre los famosos requisitos y mi ensamblado o entregable.

l Cada artista crea su propio proceso personal, el cual es parte de su sello personal.

Este particularmente es quien le da nombre a la fase, otra vez haciendo un llamado directo a la pericia interior, se deja jugar al recurso y este logra lo personal propio, sin mirar reglas o procesos, pero esto no quiere decir que no lo siga o que es un rebelde sin causa sino que posiblemente el proceso se inexistente, inconsistente o vagamente evolucionado.

l La gerencia ocupa una parte significativa de su tiempo en paliar problemas y enfrentar clientes insatisfechos.

Me pareció interesante cerrar la fase con una consecuencia que se encuentra periódicamente y tiene que ver con que la gerencia no para de enfrentar clientes y nuevamente emergen las características personales y las buenas características de cada gerente para encubrir el problema, mostrar una óptica que coteje a la partes y poder salir adelante de la mejor manera, muchas veces se pierde más tiempo en intentar cubrir estos problemas que en dar una solución radical al desfasaje planteado.


Hora Heroica

Muchas veces la organización o el área de ingenieria optan por fomentar este concepto heroico que en ocasiones de forma equilibrada puede significar una inyección de optimismo pero generalmente genera inconsistencia marcadas en el proceso de desarrollo.
Veamos algunos puntos que detallan que quiero graficar con el concepto planteado.


l El proyecto termina, la inversión hecha en desarrollar el proceso es raramente reutilizada en nuevos proyectos.

Ocasionalmente no se detecta en los primeros proyectos pero es la naturaleza del rehúso la que al evolucionar en nuestras tareas tiene un nivel de importancia superior que se vuelve radicalmente importante para la gerencia general.
Si nuestro proceso permite reutilizar modelos, que posteriormente podemos evolucionar o jerarquizar estamos hablando de poder escalar dentro del mismo y surgen conceptos de extensibilidad también, pero el interrogante es saber si realmente mi proceso permite esta característica, los número no indican esta tendencia.

l Los desarrolladores trabajen largas horas para paliar problemas cotidianos, lo cual disminuye su creatividad y productividad neta.

Es una realidad exigir el prolongado desempeño de los desarrolladores que al no tener formas de trazar muchos de los requerimientos o por problemas estructurales diversos dentro del proceso pasan muchas más horas que las que realmente requiere la problemática esto verdaderamente atenta con la creatividad y vuelve a poner como eje la pericia del recurso, algo que debemos considerar como crítico dentro del análisis por modelos.

l El éxito descansa en los hombros de estos héroes, tal como una película de acción americana.

Claramente no hay nada que exprese de forma más concreta el punto que esa frase, el punto es no llegar a ver la famosa “Vamos, pongo toda mi confianza en vos, sos el mejor, se que mañana va a estar terminado” y al día siguiente encontramos al desarrollador entrar triunfal (en el mejor de los casos y el final es feliz) o acribillado a tiros por el enemigo (el final alternativo del dvd) ustedes deciden cual es el normal o el alternativo

l Eleva la frustración y como cualquiera puede que decida explorar caminos en otras empresas con menor nivel de stress.

Todo el efecto o situación vivida genera frustración o dependiendo de cómo se va desarrollando el efecto eleva los niveles de stress, determinando éxodo de recursos, quizás excelentes recursos, esto hace perder valor a la organización y mayor es la pérdida como la evaluaremos en la última de las fases si el proceso es deficiente.

Hora Pérdida

Finalmente llegamos a la fase culminante del efecto y como el punto del mismo no era muy alentador menos serán las conclusiones.

l El proceso, que no está documentado ni ha sido compartido se va con los desarrolladores, dentro de sus cerebros.

Es crítico pensar en este punto, pero inevitable en muchas casos que el personal decida tomar otros caminos, el punto es estar preparados para esta contingencia, esta es la problemática a resolver, ya que no existe para un procesos el que el recursos se lleven en su cerebro lo realizado, pero lamentablemente es común encontrar estos problemas en los equipos y áreas actuales.

l Los que reemplazan heredan problemas y dificultades, raramente son capaces de recuperar los procesos de desarrollo.

Sin duda quienes llegan se van a encontrar en una crisis total a raíz de no tener absoluto control del dominio y de sufrir continuas presiones para las diversas partes organizacionales.

l Se obliga a reinventar la rueda, a un alto costo y generalmente retrasando los proyectos.

Sin duda el desencadenante es económico como siempre se sufre provocando pérdida notorias en el área e incluso en la organización.

Estos puntos expuestos solo son algunos de los que podemos analizar, pero forman parte de la columna vertebral de análisis de la situación actual en las organizaciones de software.

Solo resta mostrar algunas soluciones que ayudan a organizar el proceso de ingenieria de software para aplicar conceptos de calidad y prolijidad desechando el famoso efecto caótico y aportando valor agregado y trazado a las actividades del proceso.

En las próximas publicaciones voy a detallar algunas soluciones analizadas que marcan tendencias de solución, más allá de adherirse a normas de calidad o estándares, veremos como estructurar el ambiente del proceso de ingeniería del software.