Cuando estamos trabajando en un proyecto durante bastante tiempo, vemos como este va sufriendo cambios, modificaciones, va evolucionando o incluso involuciona, es ley de vida y tenemos que ser lo más ágiles y rápidos posibles para tratar de adelantarnos al cambio y tener planes alternativos para que los procesos de desarrollo y calidad no se queden estancado ni obsoletos.
Lo más normal, es que al principio se haga una primera aproximación del proceso y con el tiempo se vaya mejorando poco a poco y adaptando a la manera de trabajar del equipo o de los diferentes equipos. Esto funciona durante un tiempo, ya que existe una época en el que el proyecto mantiene la misma exigencia, la misma manera de trabajar y cuenta con las mismas posibilidades, es una época de novedades, de desarrollo, de puesta en producción y habitualmente muy exigente. Es una fase en la que hay que mantenerse en alerta y que debería de ser lo más ágil posible, siempre teniendo pausas para asegurar la calidad de los desarrollos y que no se nos vaya de las manos más adelante.
Tras ese periodo de más stress, empieza una época en la que el proceso metodológico debería de adaptarse a la puesta en producción del desarrollo en el que estemos trabajando, con un cambio de mentalidad, dando más importancia, si cabe, a la parte de calidad y priorizando eso ante el resto. Esto debe de ser así porque los clientes ya están trabajando con la aplicación en cuestión y por lo tanto un solo desliz o problema en producción es un punto en contra hacía la reputación de todo el equipo de trabajo.
En esta época de cambios, la base central del proceso debería de estar más enfocada en que las nuevas funcionalidades que aporten valor a los clientes, los nuevos evolutivos, estén totalmente estables, que aporten y no resten a los clientes con un mal funcionamiento. Tenemos que ser totalmente conscientes de que lo que suma al proyecto y a los clientes es un buen funcionamiento para que crezca la satisfacción y el crecimiento boca a boca. Las nuevas funcionalidades tienen que pivotar entre desarrollo y calidad, pasando por un equipo de producto o proyectos y entre todos, cerrar todos los flecos para que no se nos escape nada de cara a su subida a producción. Todo tiene que estar cerrado y no subir por subir, ya que de esta manera tenemos el peligro de desestabilizar la plataforma y estropear todo el camino que hemos andado hasta la fecha.
Una vez que la plataforma entra en un tiempo de estabilización, de mantenibilidad o de poca evolución, el proceso tiene que ser mucho más sencillo, tienen que rebajarse estados, tienen que ser fusionadas diferentes fases y hay que intentar tratar que los profesionales que hay en el proyecto no caigan en la monotonía, proponiéndoles fases acotadas de refactorización, procesos de mejora, ampliación de las funcionalidades pendientes o incluso una formación en diferentes tecnologías para poder abrir puntos nuevos o movilizaciones.
Lo que implica una época de estabilización y mantenibilidad en un proyecto es que se tenderá a que la gente se quede un tanto parada, que se repita el trabajo más habitualmente de lo que se quiere y que entremos en barrena en una movilización de personal a otros proyectos de la competencia, por lo tanto, tenemos que ser conscientes de que debemos de retener el conocimiento y el talento en nuestras filas y motivarles de alguna manera, incluido el poder tener a varios meses vista lo que se va a realizar y lo que vamos a acometer en un futuro cercano. Hay veces, que esto no es posible y el proyecto quedará finalizado y concluido, por lo tanto, no se pueden realizar más acciones.
Lo más importante, al final, son las personas, es su conocimiento y es su valor tanto aportado como que aportará y si no se cuida eso, poco podemos hacer dentro de un proyecto o desarrollo tecnológico.
0 Comentarios