archivo

Archivo de la etiqueta: procedimientos

Si las normativas, procedimientos o procesos de desarrollo de software de tu organización no cambian o lo hacen en contadas ocasiones y en aspectos de poca trascendencia querrá decir, probablemente, que nos encontramos con alguna de las siguientes circunstancias:

1) Se ha descubierto un “martillo de oro” que permite que todos los desarrollos de la organización se realicen de la forma más efectiva posible independientemente de las características propias de cada proyecto.

2) No existe ningún tipo de intención y/o política de mejora continua y no por el hecho de que se haya encontrado esa llave que abre todas las puertas, sino porque se ha creado una cierta zona de seguridad sin analizar si realmente la misma aporta o no un valor a la altura de la inversión que hay que realizar en la misma tanto para su aseguramiento como para su aplicación (sobre todo).

Aunque pueda parecer sorprendente, cuando la normativa no cambia es porque hay un poco de ambas, por un lado se cree que se ha alcanzado una solución óptima para el contexto (es importante eso porque, muchas veces, cuando se analizan cambios, la defensa del inmovilismo se centrará en que las innovaciones no son válidas para el entorno de trabajo o la naturaleza de la organización) y por otro, el proceso está tan consolidado (que no es equivalente a obtener resultados) que apetece poco hacer cambios.

Ante estas circunstancias, podemos sospechar y lo más probable es que no nos equivoquemos es que unos procesos que no cambian se convierten con el paso del tiempo en obstáculos cada vez mayores porque los proyectos sí que viven en primera instancia la incertidumbre y los cambios de contextos y si se establecen límites artificiales, ajenos a esta realidad, se estará mermando la capacidad de las personas de poder hacer frente a ellos.

Nos podemos encontrar con que los procesos de desarrollo de software y la normativa asociada a los mismos dentro de la organización, acotan tanto nuestras posibilidades a la hora de tomar decisiones o buscar alternativas que condicionan sobre manera el devenir del proyecto y no precisamente en positivo, porque restan capacidad de poder adaptarse a las múltiples contingencias que se pueden producir en el proyecto e implican, en muchos casos, un sobrecoste por la realización de actividades o actuaciones que no aportan un valor real.

Esta forma de entender el desarrollo de software, desde mi punto de vista, considera que las personas son el problema y no son la solución, ya que tratan de reducir al máximo su capacidad de actuación.

Es entendible y razonable que la organización quiera hacer uniformes algunos aspectos relacionados con el desarrollo con el objeto de tener un cierto conocimiento y control de lo que se está haciendo pero es mucho más discutible que trate de encorsetar a los desarrolladores de tal manera que, aunque tengan cierto margen de actuación, el camino esté tan marcado que tengas pocas posibilidades para poder maniobrar, aunque la misma sea necesaria para mantener el rumbo del proyecto.

Cuando hablamos de normas de desarrollo, al final, los que quieren hacer las cosas bien, no querrán dejar de lado las directrices de la organización, ¿por qué? pues porque aunque lo importante sea el producto, no podemos olvidar nuestro contexto laboral. Ante estas circunstancias, cuando sea necesario hacer una interpretación más flexible de los procedimientos o que se aplique una excepción, lo mejor es buscar un diálogo razonado con quiénes gestionan y controlan esos procesos, es muy posible que se consiga encontrar una solución, tal vez no satisfactoria al 100% pero por lo menos mejor que la situación de partida.

Lo ideal es que ante estas circunstancias los gestores de procesos sean capaces de reaccionar y hacer cambios en las normativas que permitan que las mismas sean cada vez más adecuadas a lo que los proyectos y la organización necesita, de esta forma, además, en un futuro no será necesario malgastar energía en los mismos asuntos una y otra vez.

¿Y si no se encuentra solución? Los proyectos están llenos de resistencias, esta será una más, con mayor o menor impacto en el desarrollo. ¿Qué podría ser evitable?, ¿qué es un fastidio tener que asumir eso? Sí, pero eso afecta no solo a los procesos o normativas, ya que también tenemos que asumir muchas veces decisiones del área usuaria con las cuales no estamos en absoluto de acuerdo y que condicionan considerablemente el desarrollo de software.

Una de las causas de fracaso más común en la implantación, puesta en marcha y explotación de los sistemas de información es la falsa creencia que los sistemas de información están por encima o resuelven problemas de carácter organizativo.

Si hay problemas de organización, de consolidación o unificación de los procesos difícilmente las va a solucionar un sistema de información, en el mejor de los casos servirá de apoyo (o excusa), pero poco más.

Es muy normal encontrarnos con este tipo de problemas en los sistemas de tramitación de expedientes en los que, por ejemplo, la tramitación de un determinado procedimiento se encuentra delegada en diferentes centros de trabajo, los cuales se encargan de trabajar con los expedientes relacionados con su zona.

Si el procedimiento de tramitación y documentación entre los diferentes centros no es uniforme y no existen unas normas claras y al detalle de que las tareas deben realizarse de una determinada manera, el problema llegará al sistema de información ya que cada cual querrá seguir trabajando como hasta ahora, algo que será incompatible con una aplicación que lo que pretende es homogeneizar procedimientos de trabajo.

Aquellos centros de trabajo que hayan intervenido más directamente en la definición del sistema o que la solución implementada se aproxime más a su forma de trabajar probablemente acogerán la aplicación de mayor agrado, mientras que en el resto el proceso de implantación será más costoso, en otros deficiente, cuando no inexistente.

Un factor de riesgo a analizar cuando se vaya a desarrollar un sistema de información es si el proceso o procesos que se van a informatizar están consolidados en la organización y se trabaja de homogénea (o si la solución a implementar se va a consolidar durante el proceso de desarrollo). Si no existe voluntad de hacerlo o se cree que existe esa homogeneización, pero la realidad es otra, lo mejor es no realizar la aplicación o tener en cuenta este aspecto en las especificaciones del sistema, ya que el mismo requerirá un importante grado de flexibilidad.

Hace más de año y medio que escribí un artículo dedicado a la Crisis del Software.

Desde entonces hasta ahora no cambia un ápice mi opinión sobre este asunto y me temo que si dentro de año y medio vuelvo a tratar el tema, la situación no cambiará. Para que todo esto cambie se requiere un cambio en la mentalidad tanto las organizaciones como en los que nos dedicamos a esto y no tengo muy claro que ni unos ni otros estén muy por la labor. Esta circunstancia provoca que los pasos que se dan sean tan pequeños que consigan dejar atrás la crisis del software.

Por regla general, el software que se entrega: incumple plazos, presupuestos y expectativas.

No toda la culpa es siempre del equipo de proyecto, también tiene mucha responsabilidad el área usuaria, pero tengo la convicción de que si el proceso de desarrollo de software se realizase siguiendo unos principios de ingeniería, con personal lo suficientemente formado y consciente de la importancia de hacer sus tareas de una determinada manera, se mejorarían indudablemente los resultados.

Lo anterior debe venir acompañado necesariamente por unos presupuestos y plazos acordes a la naturaleza del proyecto. Si no son realistas no se podrán conseguir milagros por muy buenas prácticas que se sigan y por muy bueno que sea el equipo de proyecto.

Con todo lo anterior podemos decir que una situación de partida a partir de la cual existe la posibilidad de que el proyecto salga bien, es la siguiente:

procedimientos + metodología + ingeniería + equipo de proyecto formado + usuarios con dedicación y responsabilidad en el proyecto + presupuesto adecuado + plazos asumibles.

Son muchas variables, ¿verdad? Pues habría decenas más. La idea es que cuentas más se cumplan, más posibilidades hay de que la situación de partida sea buena.

¿Por qué hablo de situación de partida y no del proyecto? Pues porque lo segundo se ve muy condicionado por lo primero. Sin una buena base el proyecto se tambalea.

En el desarrollo de software, nada asegura nada y por supuesto que una situación de partida adecuada no implica el éxito en el proceso de desarrollo de software, pero por lo menos ofrece un catálogo de oportunidades mucho mayor, lo suficiente para que el número de casos de éxito crezcan paulatinamente y para que esta forma de concebir el trabajo y los proyectos vaya calando y madurando y se produzca un efecto que realimente todo el proceso y vaya dejando atrás, esa lacra que nos acompaña desde que el desarrollo de software empezó a cobrar relevancia respecto a los sistemas físicos.

Los lectores habituales de mi blog conocéis de sobra mi opinión sobre la necesidad de implantar procedimientos de trabajo en los distintos ámbitos de la organización, con el objeto de dar un orden y sintonía a las tareas que se realizan en la misma.

Tal vez en entidades pequeñas, se puede prescindir de ellas o dejar solamente algunas básicas, pero cuando el número de trabajadores, departamentos y relaciones con terceros crece, la no existencia de procedimientos o si existen, su no cumplimiento, provocan una pérdida de control en la gestión, la imposibilidad de obtener un buen número de métricas para realizar un seguimiento, una reducción de la productividad, etc… que al final se traducen en menos ventas y/o menos beneficios en las mismas y más gasto.

Los procedimientos marcan un camino a seguir y si no entra a relucir la piel, nos convertiremos en un componente más de una cadena de montaje, que recibe tareas, las ejecuta y produce un resultado. Las relaciones humanas son esenciales en cualquier organización y la calidad del capital humano, así como la forma de gestionarlo es (o debería serlo) el principal activo de la organización.

La comunicación por tanto es necesaria, hacia arriba, hacia abajo y en horizontal, trascendiendo incluso los departamentos. Si a esto le acompaña un entorno de trabajo que fomente la empatía entre los empleados y se establecen unas políticas laborales que favorezcan el compromiso en los componentes de la organización, le habremos puesto a los procedimientos dos elementos de los que carece: corazón y sangre.

Si en una organización o en un departamento no hay una planificación y una relación de objetivos que cumplir, se fomentará que dentro de ella cada responsable de llevar a cabo un determinado tipo de trabajo ejecute su propia agenda de trabajo (en el caso de que la tenga) o bien lleve su día a día como buenamente entienda.

Esto implica que cada cual hace la guerra por su cuenta. De vez en cuando habrá órdenes de arriba que harán que determinados trabajos o tareas se realicen de una determinada manera, pero el resultado final será una descoordinación que resultará negativa a medio y largo plazo, ya que cuando se quiera hacer encajar las piezas será muy costoso completar el puzzle (si es que el rumbo de la organización permite que todavía lo haya).

No es malo que cada cual tenga su propios objetivos dentro de su trabajo en la organización, pero estos deben estar basados en unas directrices generales de funcionamiento y en unos objetivos globales encajados dentro de los procedimientos y procesos ya definidos (si ya puede resultar negativo el hecho de que no exista una agenda de trabajo, nos podemos imaginar qué resultados se pueden obtener si además no existen o no se cumplen los procedimientos que organizan y dan una visión uniforme al trabajo del día a día).

La implantación de procedimientos dentro de un departamento de desarrollo de software produce beneficios y por tanto un retorno de la inversión.

El principal inconveniente que encuentra es la reticencia del personal a cumplirlos ya que en su mayoría piensan que toda esa burocracia es una pérdida de tiempo.

El primer error es pensar que se trata de burocracia o por lo menos en el sentido negativo en el que se suele entender ese término, obligarte a seguir una serie de pasos para realizar determinadas acciones no es burocracia, son procedimientos. Esto no quita que el diseño de los procedimientos deba ir acorde con las posibilidades que tiene el departamento, si se va más allá de lo que se puede abarcar, estamos ante una situación contraproducente (no se terminarán por seguir los procedimientos y además se producirá una reducción de la eficiencia).

No es necesario empezar a procedimentarlo todo de la noche a la mañana. Lo mejor es ir poco a poco, que el personal se vaya acostumbrando a esta otra forma de trabajar, más ordenada, que permite, por todos, una mayor control de las acciones que se realizan.

Los procedimientos irán acompañados de herramientas (o por lo menos es aconsejable). En mi organización los procedimientos internos del departamento de desarrollo y nuestra interacción con el resto de departamentos del área TIC se realizan básicamente con 5 herramientas:

– Un Service Desk como componente que integra todo el conjunto de incidencias y peticiones en producción.
– Redmine como sistema de gestión de proyectos: planificación de tareas e interfaz con el repositorio documental (en nuestro caso Alfresco, aunque perfectamente se podría haber utilizado la propia herramienta como gestor documental).
– Alfresco, como repositorio documental.
– Mantis para el reporte de incidencias en la fase de pruebas de la aplicación.
– Una software de agenda compartida, para la gestión de nuestras citas y reuniones.

Como comenté antes, no se trató de implantar un conjunto de procedimientos de la noche a la mañana, sino que se hizo paulatinamente, asimismo no todas las herramientas se implantaron a la vez, ni el grado de uso de las mismas fue intenso desde el primer momento. Ha sido el tiempo y también determinadas decisiones de los responsables de informática los que han consolidado los procedimientos y las herramientas.

No son las únicas herramientas que utilizamos en el departamento de desarrollo ya que la realización de determinados procesos, requieren de otras herramientas complementarias que nos aportan, además una serie de ventajas:

– Subversion: Como sistema de gestión de fuentes y sus versiones.
– Artifactory: Como repositorio de librerías dependientes.
– Hudson: Para la automatización del proceso de compilación, generación del desplegable e interacción con Sonar (tenemos previsto próximamente el uso de Hudson para realizar el despliegue completo de una aplicación).
Sonar: Para el análisis estático de código.
– Enterprise Architect: Diseño de modelos (requisitos, casos de uso, etc…) y de documentación a partir de los mismos.

Como he comentado antes, los procedimientos requieren herramientas y las herramientas procedimientos, los unos sin los otros no terminan por producir buenos resultados.

Los procedimientos deben estar por escrito y ser dados a conocer por quienes los tienen que cumplir y se debe hacer un seguimiento de su implantación, por lo menos hasta que se consiga que la organización asimile la nueva dinámica de funcionamiento.

¿Por dónde se empieza? Supongamos que ya tenemos definida una dinámica de trabajo en cuanto al propio proceso de codificación de software, si no es así, ese debe ser el inicio (es decir, habría que establecer un framework de desarrollo, la selección de un IDE, de un sistema de gestión de versiones, una herramienta de integración continua, etc…, unos entornos de preentrega, un sistema de atención interna de dudas, sugerencias, etc… en el proceso de desarrollo (así como la persistencia de aquellas que sean más interesantes, para permitir la consulta futura), etc…

A partir de ahí, el siguiente paso debe ser controlar hacia dónde se enfoca la dedicación de los empleados, lo que hace necesario la existencia de una herramienta de imputación horaria. Esta gestión de incurridos es fundamental si la función principal de tu organización es la prestación de servicios a terceros. En el caso de mi organización no tenemos ninguna herramienta de esas características porque somos principalmente clientes de los trabajos (lo que ha hecho que no sea algo prioritario).

A continuación se debe trabajar en la gestión de las entradas de incidencias y peticiones por parte de terceros, así como su planificación. De esta forma se consigue dar un orden al trabajo, saber qué esta haciendo cada cual en cada momento y poder planificar los recursos humanos en el tiempo, de manera que se reduzca el número de tiempos muertos y cada persona se utilice, en la medida que sea posible, en aquellos proyectos y actividades donde se pueda aprovechar de mejor manera su potencial.

Lo comentado en el párrafo anterior se puede hacer en paralelo, con la obligación de que cada reunión con un cliente tenga como resultado final un acta (siguiendo en la medida de lo posible un mismo formato y que se almacena de la misma forma para todos los proyectos), que además debe ser enviada a los mismos. Como podéis ver, estos procedimientos que no requieren gran esfuerzo implantarlos, producen beneficios innegables. Solo requiere pequeños cambios en algunas de las rutinas de los empleados (el desarrollo de software es mucho más que tener abierto Eclipse toda la jornada laboral).

Una vez llegado a este punto resulta recomendable integrar el sistema de imputación horaria con el sistema de planificación de proyectos para tener el tiempo real que se ha invertido en cada tarea.

Sabemos cuánto se ha presupuestado cada proyecto, cuánto se lleva invertido en cada uno y aproximadamente el grado de avance en los mismos. Con esas variables es posible conocer el estado de los costes de cada proyecto, algo fundamental para detectar desviaciones a tiempo y tomar medidas (de nada sirve detectar que hay problemas si no se toman decisiones al respecto).

¿Por dónde se sigue? A partir de aquí, entrarán en juego, las preferencias personales. En mi caso, yo potenciaría el establecimiento de una normativa documental en los desarrollos apoyada en una herramienta CASE. Los desarrolladores odian documentar, principalmente porque no se sabe documentar (duele, pero es la verdad) y porque no se tiene un procedimiento, técnica y mecánica para hacer que ese proceso “insufrible” sea menos doloroso, es decir, que haga que el proceso de documentación sea más eficiente y productivo. Si con documentación vas a tener problemas con el cliente de todas maneras, ya sabemos todos los problemas que se tiene cuando se carece de ella, donde al final el cliente meterá casi tantos goles por la escuadra como quiera, ya que él dispone de todas las cartas y tú de ninguna. Además, la documentación puede guiar el proceso de desarrollo, cuestión de acostumbrarse a trabajar con ella y además permite dar un acabado a los proyectos que puede dar lugar, en muchos casos, a marcar la diferencia entre un proveedor y otro.

¿No crees en los procedimientos? Prueba a implantar alguno, hazle un seguimiento y mide los resultados, lo mismo cambias de opinión.