archivo

Archivo de la etiqueta: Gestión de proyecto

Siempre existe la posibilidad de que te toque la lotería (si la juegas) pero en el desarrollo de software lo mejor es no dejar cosas al azar.

Cuando de manera desestructurada “sueltas” a un conjunto de personas en un proyecto sin analizar si realmente tienen la capacidad para llevarlo a cabo, estás esperando prácticamente que el azar haga que las cosas vayan bien, para ello, sería necesario entre otras cosas que dicho grupo se autoorganizase de manera adecuada, fuera capaz de motivarse y ser más productivo y de tener la resistencia necesaria para hasta adquirir las habilidades requeridas (no solo técnicas) para sacar adelante el trabajo. Esa transformación es posible pero muy complicada.

Ese grupo, además, contará con muy poco apoyo de la organización, salvo que sus resultados sean lo suficientemente llamativos, ya que poco se puede esperar de quiénes han confiado de manera tan pobre en el proyecto y no le han dedicado lo que necesita.

En el caso de que ante tantos obstáculos se consiga el éxito hay algo de lo que no tendrá que preocuparse ese equipo y es el de levantarse temprano el día que repartan las medallas ya el día anterior los mismos que los pusieron en el disparadero se la habrán llevado todas.

Tener a tu equipo trabajando, recorriendo cientos de millas extras y pidiéndo esfuerzos cuando ya no quedan fuerzas, mientras no te involucras no es la mejor forma de que tu equipo crea en ti. Es más tu credibilidad se reducirá exponencialmente conforme tus actos se vayan alejando de tus palabras.

Que sí, que tu trabajo es uno y el de tu equipo puede ser otro. No se trata de roles, sino de implicación, de empatía y compromiso. Es cierto que esto requiere un esfuerzo extra para el gestor pero, ¿no es eso lo que pides en determinados momentos a tu equipo?.

Tu equipo no es una expendedora de servicios, son personas y tienen que sentirse arropadas. Si no lo están, solo quedará que entre ellos se autogestionen, algo que no es ni mucho menos malo, es más lo considero positivo, siempre y cuando tengan una visión que vaya más allá del día a día del proyecto, ya que pueden existir decisiones que requieran tener una visión de un mayor alcance y se les permita llevarlas a la práctica, algo que el gestor puede obstaculizar si lo interpreta como una intromisión en su trabajo en lugar de un apoyo.

Un equipo no se extralimita si existe un respeto entre los roles, existe un consenso entre los límites de cada parte y existe un diálogo fluido y confianza como para que todas las partes se escuchen entre sí.

La clave es que el gestor se sienta parte del equipo y el equipo lo sienta como parte integrante de él. Esto se gana, no se obtiene por tener unos simples galones.

Decía Lao-Tse que: “El sabio no enseña con palabras, sino con actos”.

He leído últimamente en Twitter con relativa frecuencia una cita que refleja en gran medida lo que es el desarrollo de software: “Hasta que el producto (o su versión correspondiente) no se pasa a producción no se sabe realmente cuál ha sido el esfuerzo y tiempo necesario”.

Una gran verdad. Los métodos de estimación son eso, métodos de estimación. Después, a lo largo del proceso de desarrollo pueden pasar muchas cosas (incertidumbre) que echen al traste todo lo estimado y sea necesario ir realizando reajustes a lo largo de todo el proyecto (bienvenidos sean esos ajustes porque lo que no tiene sentido es seguir engañándonos con estimaciones irreales).

En las metodologías ágiles, independientemente de que podamos establecer un objetivo final (en cuanto a la delimitación del alcance del producto y el tiempo y esfuerzo para llegar a eso), nos encontramos ante la misma situación, si bien, en este tipo de desarrollos al factor incertidumbre hay que sumarle el factor feedback del usuario que pueden obligar a hacer ajustes continuos en determinadas funcionalidades hasta que consigamos ponerla a la medida de las expectativas creadas en la misma (e igualmente, bienvenidos sean esos ajustes, ese feedback y esos cambios).

Pero es que incluso a nivel de sprint, por muy cerrado que tengamos la carga de trabajo máxima (velocity) e incluso por mucha experiencia que tengamos a la hora de estimar y la estrategia de estimación sea adecuada (por ejemplo Planning Poker), también podemos equivocarnos. Lo importante en este caso es determinar la causa de la desviación para realizar, si proceden, las mejoras correctoras necesarias.

Otro artículo relacionado: “Desarrollo de software. Metodologías ágiles. Replanificar la fecha de entrega o cumplir con la misma“.

Uno de los grandes problemas del desarrollo de software en la Administración Pública lo tiene la utilización generalizada del ciclo de vida clásico o en cascada, no hago referencia directa a MÉTRICA v.3 ya que la misma no deja de ser un ordenación particular de dicho ciclo de vida que además es lo suficientemente abierta como para que una inmensa mayoría de los proyectos desarrollados en cascada sean compatibles con la misma.

¿Por qué es un problema? Porque está más que demostrado que el ciclo de vida en cascada no da buenos resultados. Y no es algo que yo haya leído, sino que lo he sufrido y estoy sufriendo en los proyectos que gestiono. Desarrollar en cascada es un error, yo le he estado cometiendo durante años y me ha servido para darme cuenta que la solución pasa por la aplicación de otras metodologías.

Sin embargo la Administración Pública apostó por MÉTRICA, como metodología oficial para el desarrollo de sistemas de información y las razones son varias:

– El ciclo de vida en cascada era (y lo sigue siendo) la metodología más utilizada y más implantada, en proyectos dentro y fuera de la Administración Pública.

– La Ley de Contratos, tiene una finalidad fundamental que no es otra que la de fiscalizar la actuación de la Administración y propiciar la concurrencia con igualdad de oportunidades de los licitadores a los concursos que se convoquen. Sin embargo tiene como inconveniente de que se trata de un procedimiento administrativo que lleva meses, desde que se elaboran los pliegos hasta que se realiza la adjudicación y posteriormente se formaliza (firma) el contrato.

¿Cuál es el inconveniente? Pues que en muchos casos se valora el sistema de información a desarrollar sin conocer en detalle los requisitos funcionales y los casos de uso o dicho de otra forma, sin conocer en profundidad qué es lo que quiere el área usuaria del proceso o procesos que se van a informatizar.

Para solucionar esto habría que realizar un preanálisis del proyecto, para conocer el alcance global que se persigue y entrar en un cierto grado de detalle a nivel de requisitos e interacción del sistema con los diferentes actores (usuarios y otros sistemas). A partir de ahí sí que es posible realizar una valoración más acorde con la realidad y tomar la decisión sobre qué metodología es más adecuada para realizar el proyecto, teniendo en cuenta las características de los usuarios y la divisibilidad del mismo en bloques funcionales que faciliten los desarrollos de manera iterativa e incremental.

Esto querría decir que el preanálisis habría que desarrollarlo con recursos internos o bien contratarlo, siendo la segunda opción la más común debido a que, por regla general, los Departamentos de Informática de la Administración Pública no están dimensionados acorde a las responsabilidades y funciones que tienen que acometer.

Si se contrata ese trabajo quiere decir que el desarrollo del sistema de información se tendría que contratar en otro procedimiento, por lo que como mínimo habría que esperar cuatro o cinco meses para poder empezar (cuando no un año o más, ya que dependerá del momento del año en el que se ha terminado el trabajo, la disponibilidad presupuestaria, etc…). Todos sabemos cómo son los usuarios y en un plazo de seis meses a un año donde ayer dije una cosa, hoy diré otra y salvo que esa dinámica adaptativa se haya tenido en cuenta en el presupuesto, el mismo partirá con un déficit que empezará a poner dificultades desde el principio.

– Otro aspecto es la propia dinámica de funcionamiento de la Administración. Lo que hoy puede ser prioritario mañana puede dejar de serlo, lo que implica que recursos inicialmente previstos para el proyecto desde el área usuaria, pueden desaparecer o ver mermada su participación. A lo anterior hay que sumarle el alto índice de rotación de persona que existe. Esta casuística es un arma de doble filo, ya que por un lado aconseja cerrar unos requisitos para intentar “blindar” un alcance de los trabajos y poder desarrollar el proyecto y por otro ese blindaje finalmente no sirve de nada porque si hay aspectos funcionales que no han sido bien recogidos o bien cambian con el nuevo personal que se asigne al proyecto se requerirán cambios en los requisitos ya definidos, los cuales se producirán incluso en etapas tardías del desarrollo.

El camino para desarrollar proyectos con una mayor probabilidad de éxito pasa por un desarrollo iterativo e incremental, plásmándose este en la metodología que se considere mas adecuada a las circunstancias del proyecto. Es necesario hacer ese análisis ya que existen ciertas metodologías ágiles que por el alto grado de participación del usuario que requieren no son realistas de aplicar en muchos casos, por la dinámica de funcionamiento de al Administración que expliqué antes (lo cual no quiere decir que haya situaciones concretas donde sean posibles).

Es totalmente posible desarrollar este tipo de proyectos, pero es fundamental para ello cambiar la forma de enfocarlos, es necesario conocer qué se quiere obtener, pero plantearlo como una carrera por etapas. Si un ciclista trata de hacer todo el recorrido del Tour de Francia del tirón no podrá, si lo hace por etapas le costará trabajo llegar hasta el final pero por lo menos tendrá una oportunidad de conseguirlo. Y esto es válido tanto si se contrata todo el desarrollo de una vez como si se contrata primero el análisis o preanálisis y después a construcción (teniendo en cuenta que al coste calculado hay que añadirle un porcentaje por el proceso adaptativo del sistema de información a las necesidade del usuario en cada iteración).

Nos centramos mucho en los requisitos funcionales y en cierto modo es lógico que así sea, ya que si una aplicación no cumple el propósito y expectativas que se tiene sobre la misma de nada vale que la calidad del producto y del desarrollo sea impecable.

Parto de la base de que no es nada fácil conseguir lo que el usuario o el cliente busca, entre otras cosas porque es complicado que ambos tengan del todo claro lo que quieren (sí lo pueden tener en la cabeza, pero una aplicación son muchos detalles y es difícil que tengan en cuenta todos) y también que los analistas entiendan e interpreten a la perfección lo que les están contando.

Precisamente porque el desarrollo de un producto tiene asociado inherentemente tareas de mantenimiento correctivo y evolutivo es necesario ir más allá de que el producto funcione, entendiendo que el diseño y codificación realizados deben hacerse pensando en que habrá que modificar la aplicación, para ello desde un primer momento hay que pensar también en la calidad de la aplicación desde el punto de vista de la arquitectura, diseño y construcción.

No tener en cuenta estos detalles provocarán en el sistema desarrollado una deuda técnica que se arrastrará en los mantenimientos y tenderá a empeorar salvo que se decida atajar, ya que el software tiende a deteriorarse con los mantenimientos, siendo este deterioro muy sensible en aquellos casos donde el producto no ha tenido una ejecución buena desde el punto de vista de la calidad del código.

Sonar permite ver de manera muy sencillo lo que esconden las aplicaciones debajo de la alfombra a través de las diferentes métricas que permite obtener. Es cierto que solo son un conjunto de métricas y que hay que saber interpretarlas de manera individual, colectiva y en el contexto de cada aplicación, pero permiten dar una visión objetiva y externa tanto a clientes como a proveedores, ya que no hay trampa ni cartón si ambas partes conocen el juego de métricas y reglas que se le van a pasar al código.

Desde mi punto de vista Sonar es una herramienta de implantación obligatoria en los departamentos de desarrollo y/o de calidad del software, ya que además de permitir detectar aspectos del desarrollo que generan deuda técnica, permiten determinar la complejidad (y por tanto tiempo y esfuerzo) de los mantenimientos y puede ser utilizada para establecer determinados acuerdos de niveles de servicio en cuanto al software que se entrega.