Desarrollo

¿Qué aplicar? ¿Cómo...? Planificar, diseñar,

desarrollar, implementar, dar

mantenimiento y que sea

funcional a través del tiempo.

Por: Byron Quisquinay

Dentro de las tareas que son propias de las áreas encargadas del

Mantenimiento, administración y desarrollo de Software, existe

una que resulta tenebrosa y es la de decidir qué estándares,

normas, reglas, estatutos o políticas de desarrollo aplicar; todo

ello con el único fin de garantizar “calidad” en el producto final.

Bien, al escribir el presente definir el problema parece suma-

mente sencillo. Pero cuando se vive la realidad que encierra el

reto de cumplir con los requisitos de una solicitud, es donde

empieza la dura agonía.

Y es que en el medio existe un sinfín de Buenas prácticas, nor-

mas, estándares, procedimientos, etc. Por ejemplo: ITIL, UML,

RUP, podría aplicarse ISO 9001:2000 (cláusula 7 en especifico) y

bueno muchas más.

¿Pero el empleo de cuál de ellas permitirá alcanzar la calidad

deseada del Software que producimos?

Me atrevo a decir que ninguna de ellas. Según me parece y dada

mi fascinación por las normas y estándares, además del tiempo

de vuelo que llevo en las áreas de Desarrollo de Software y de IT,

no son las normas, estándares, reglas, estatutos, políticas, res-

tricciones, o cualquier artilugio los que brinden calidad al pro-

ducto final.

No son las leyes, reglas o normas las que fomentan el respeto al

derecho ajeno. Por lo menos no cualquier ley, puesto que exis-

ten algunas que fomentan aquello que desean erradicar. ¿Basta

pues con un edicto (ley) para que deje de llover o que el árbol de

Olmo de Peras?

Bien, abordemos pues el tema con mayor detenimiento más que

con sarcasmo. Y es que los problemas vienen dados por una

sencilla razón: el equipo de trabajo no está convencido, no es

parte del reto y no cree o tiene certeza de los resultados de

aplicar tal o cual técnica. Y esto, cuando el equipo actual que se

desenvuelve en el área ha sido el que de forma continua a vivido

la transición o adoptó las reglas que rigen el proceso de Creación

de Software. ¿Qué otros elementos pueden estar involucrados

en la falta de éxito en alcanzar la calidad deseada en el Software

producido? Me parece que podríamos pues crear un listado de

factores, incluyendo el mencionado anteriormente, estos facto-

res serían:

Falta de empatía.

Falta de motivación.

Falta de capacitación.

La inexistencia de un plan que tenga como

objetivo el mantener vivo el compromiso de

la calidad en el producto a producir.

Es pues menester de aquellos en quienes reside la responsabili-

dad de definir las reglas del juego contar con la mayor cantidad

de variables que circundan este tema. Y según me parece, los

elementos que se deben de tener en consideración son:

Que exista un equipo y no un grupo de traba-

jo.

Que compartan los objetivos, la visión y la

misión del área y de la empresa o corpora-

ción.

Que sientan como propias, eficientes y fun-

cionales, las herramientas, reglas, estatus o

políticas internas para que no menoscaben el

ambiente laboral.

Que esas buenas prácticas, normas, sean

relativamente sencillas de aplicar o que los

instructivos o documentos que las referen-

cian, sean claros y concisos sobre la aplicación

de las mismas.

Que existan medios y recursos que permitan

el auto— aprendizaje de estos métodos,

normas o procedimientos

Bien, en realidad el tema está siendo abordado de la forma más

objetiva que se puede y la prueba de ello será que estos temas

son importantes puesto que:

Un equipo de trabajo aunará esfuerzos para

que el resultado sea un resultado general y

claro está, particular. El beneficio y la satis-

facción deberán ser globales e individuales.

Que compartan los objetivos, la visión y la

misión del área y de la empresa o corpora-

ción.

Que sientan como propias, eficientes y fun-

cionales, las herramientas, reglas, estatus o

políticas internas para que no menoscaben el

ambiente laboral.

Que esas buenas prácticas, normas, sean

relativamente sencillas de aplicar o que los

instructivos o documentos que las referen-

cian, sean claros y concisos sobre la aplicación

de las mismas.

Ahora bien, queda una duda en el ambiente que tratamos, pues:

¿Así de utópica es la solución? ¿Simplemente hacemos el paraíso

informático y eso basta? Quien administra una unidad de la

empresa, que desarrolla software, sabe perfectamente que la

administración del Recurso Humano, es uno de los temas más

difíciles.

¿Puede pues cambiarse la actitud y el comportamiento, así

como implantar el compromiso, la dedicación y la pro actividad

en las personas?

¿Esta el resto de la empresa dispuesto a aceptar el reto de

tener una unidad eficiente, sabiendo que esto tiene un costo

alto o mediano, dependiendo de que tan buenas sean las

estrategias emprendidas?

Y lo más complicado: ¿Cada integrante del área de Desarrollo

de Software, comprende, comparte y aplica las estrategias

definidas?

Esto nos lleva pues a una pregunta más global en sí del proble-

ma: ¿La solución es definida de una forma unilateral, bilateral

o multilateral? Para mí, la solución, la estrategia, es definida

unilateralmente por quien dirige y en quien recae esa tarea

dentro de la organización, y esto alineado a las políticas de la

empresa y con vistas a los objetivos de las mismas; más sin

embargo, son propuestas que deben ser consensuadas defini-

tivamente a aquellos que impactan directamente, pero así

mismo, deben ser consensuadas a quienes impactan indirecta-

mente.

Con lo anterior me refiero a que el establecimiento de instruc-

ciones de trabajo, políticas de administración y desarrollo de

software, flujos de actividades que permiten el realizar las

actividades que se ejecutan para la puesta final en Producción

de la solución. Afectan no solo al Recurso Humano de Desa-

rrollo de Software, también afectan al usuario que tendrá que

acatar las directrices que deriven de estas definiciones y así

pues a las otras áreas que coadyuvan a la tarea de IT en total.

Cabe pues ahora preguntar de qué se trata el presente artícu-

lo, puesto que dentro del título se describe: ¿Cómo...? Planifi-

car, diseñar, desarrollar, implementar, dar mantenimiento y

que sea funcional a través del tiempo.

Entonces, en lo personal, la solución tiene estos componentes

que hay que crear, fomentar y mantener:

Infraestructura (mobiliario y equipo).

Clima laboral.

Plan de compensación y sanción.

Definiciones de Visión y Misión del área y

sus dependencias.

Instrucciones de trabajo o manual de

(según) puestos.

Mapa de Flujos según sea la actividad em-

prendida por el área de IT.

¿Qué se gana con esto? Pues el definir ¿Qué hacer, con

qué recursos y porqué (recompensa o sanción)?

Ahora, se tiene que tener en mente que dependiendo del

plan estratégico que se aplique se podrá:

Fomentar el ambiente y las actuaciones de los inte-

grantes que sean parte de la maquinaria que provea

un producto o servicio de calidad.

O bien, podrán ser las causantes del detrimento y la

ausencia de calidad en el producto o servicio final

entregado por el área. <Falta de compromiso y res-

ponsabilidad, etc.>

Entonces:

¿Cómo planifico, diseño, desarrollo, implemento y le doy

mantenimiento al software que entrego a la empresa?

Teniendo los elementos que fomenten un ambiente propi-

cio para dicho fin, se deberá tener una definición, clara y

concisa de las tareas de las áreas (o procesos) encargadas

(os) de realizar el: Desarrollo y Mantenimiento (o explota-

ción) de los Sistemas de la empresa.

¿Si pero aún no se responde qué utilizar? Bien, se debe

de contar con:

Una fuente constante y actualizable de dichas definicio-

nes, para que puedan ser consultadas y/o actualizadas,

en su defecto, eliminadas.

¿Qué definiciones? Las de cómo y en qué medio y forma se

dejarán plasmados los: Planes, diseños, pruebas y comunica-

dos que permitieron el desarrollo e implementación de la

solución. Y esto pues es la prueba tácita del cumplimiento de la

definición del proceso que permite la creación del Software.

¿Y esa definición de qué, cómo, quién, cuando, etc. Empleando

qué técnica, buena práctica o norma? Pues si la empresa, corpo-

ración o estructura organizacional a la que se pertenece no tiene

definida una como estrategia del negocio y por ende el área de IT

debe de alinearse a ella, por ejemplo ISO 9001:xxxx, se deberá

optar por la qué más se adapte a las características que rigen el

área de Desarrollo y para ello habrá que sopesar:

¿Con qué recursos se cuentan?

¿Qué método de estilo de programación se emplea más?

¿Estructurada y Modular? ¿Orientada a objetos?

¿Cuál de esas técnicas, mejores prácticas, estándares, normas,

etc. Pueden ser cumplidas, definidas o articuladas de una

forma más natural o por medio del uso del sentido común?

¿Puede hacerse una mezcla de las que más se adapten según

los estilos me más rijan el desarrollo que se emplea en IT?

¿Bien, entonces al final se contestó la pregunta? Si, primero se

deberá tener el ambiente propicio y luego se definirán las técnicas

más aptas para la actividad de la Construcción y Mantenimiento

de Software.

¿Eso no es una respuesta o sí? En realidad sí, puesto que no hay

dos unidades, departamentos, sección o cualquier artilugio para

Desarrollo de Software que sean idénticos y que cuenten con

tecnologías y estilos iguales, por lo que no creo que se pueda

definir una receta igual para cada ámbito.

Hay unas preguntas que yo dejaría además de las que iniciaron el

presente artículo: ¿Si es usted el administrador o si es usted la

parte operativa del área, está dispuesto a entregar calidad en lo

que hace diariamente, fomenta usted el trabajo en equipo y está

dispuesto a dejar una honda huella en su empresa, departamento,

compañeros y en este medio, como un estratega, como un em-

pleado de excelencia?