¿Que es un desarrollador de mantenimiento?
En lo que refiere al ciclo de vida del desarrollo de software y desde la perspectiva del servicio, existen dos etapas muy distinguibles: el proyecto que da lugar al nacimiento de la aplicación y el mantenimiento de la misma.
En la primera etapa los requerimientos son difusos y se requiere un gran esfuerzo en lo relacionado al diseño de la arquitectura y la construcción de la base que soportará las actuales y futuras necesidades desde el punto de vista del usuario del servicio. En la segunda, los requerimientos son más específicos y el esfuerzo pasa por la programación de las nuevas funcionalidades.
Dada estas diferencias, cada etapa requiere capacidades particulares por parte de los desarrolladores (analistas, arquitectos, diseñadores y programadores) y es este el argumento por el cual divido a los desarrolladores en dos grandes grupos: Desarrolladores de proyectos y Desarrolladores de mantenimiento.
Un desarrollador de mantenimiento es aquel cuya experiencia se centra principalmente en añadir funcionalidades a un conjunto reducido de aplicaciones con un alto nivel de madurez y estabilidad.
Evidentemente estos desarrolladores son expertos en esta etapa pero generalmente carecen de ciertas características necesarias para llevar adelante con éxito el proyecto que dará lugar al nacimiento de una aplicación.
A continuación quiero compartir 10 observaciones que he realizado durante el desarrollo de varios proyectos en los cuales se utilizó desarrolladores de mantenimiento para la fase de construcción.
10 observaciones sobre los desarrolladores de mantenimiento
1. Innovación: Ante un nuevo proyecto, el desarrollador de mantenimiento buscará construirlo sobre lo que le es conocido y que considera estable. Esta actitud reduce significativamente la probabilidad de alcanzar la innovación.
2. Seguridad: Un desarrollador de mantenimiento presenta mucha inseguridad respecto a lo nuevo lo que generalmente lo lleva a tratar de controlar todos los factores desde el inicio demorando así el comienzo del proyecto.
3. Estabilidad: Acostumbra a trabajar sobre aplicaciones muy estables por lo que no sabe manejar las vicisitudes de una aplicación inmadura.
4. Estimación: No es un buen estimador del esfuerzo inicial de un proyecto ya que lo ha realizado muy pocas veces.
5. Restricciones: Tenderá a la calidad por sobre el alcance y el tiempo ya que buscará que la nueva aplicación este dotada de la misma madurez a la que esta acostumbrado.
6. Flexibilidad: Carece de flexibilidad en lo que refiere al procesamiento de requerimientos ya que esta acostumbrado a usuarios que manejan muy bien el mecanismo y el lenguaje para añadir nuevas funcionalidades a una aplicación existente pero una nueva aplicación puede definir nuevas reglas de comunicación ya que los usuarios y clientes aún no tienen claro que es lo que necesitan.
7. Presión: Una nueva funcionalidad generalmente no implica gran presión sobre el equipo de desarrollo ya que la solución de software ya cumple los requisitos fundamentales para la organización, sin embargo, un nuevo proyecto implica crear un servicio que aún no existe y la ansiedad de clientes y usuarios pueden generar un nivel de presión a la que los desarrolladores de mantenimiento no están acostumbrados.
8. Gestión: No estan familiarizados con el proceso de gestión de proyectos así como tampoco a la auto gestión en el contexto de un proyecto.
9. Riesgos: Carecen de la capacidad de reconocer y mitigar los riesgos asociados al proyecto.
10. Entregables: Por su forma de trabajo habitual ponen foco en el resultado final y no comprenden la importancia de entregables completos, correctos y a tiempo, muy necesarios para el éxito de un proyecto.
Es importante aclarar que estas observaciones parten de la comparación entre desarrolladores de mantenimiento y desarrolladores de proyectos y tan solo constituye una generalidad. En ningún caso deben ser utilizadas como único argumento para descartar la participación de un desarrollador de mantenimiento en un proyecto de construcción de software.
Sí es importante que los responsables del servicio o de la gestión del proyecto sepan reconocer desarrolladores de mantenimiento y conocer sus limitaciones para mitigar los riesgos asociados a su participación.
En lo que refiere al ciclo de vida del desarrollo de software y desde la perspectiva del servicio, existen dos etapas muy distinguibles: el proyecto que da lugar al nacimiento de la aplicación y el mantenimiento de la misma.
En la primera etapa los requerimientos son difusos y se requiere un gran esfuerzo en lo relacionado al diseño de la arquitectura y la construcción de la base que soportará las actuales y futuras necesidades desde el punto de vista del usuario del servicio. En la segunda, los requerimientos son más específicos y el esfuerzo pasa por la programación de las nuevas funcionalidades.
Dada estas diferencias, cada etapa requiere capacidades particulares por parte de los desarrolladores (analistas, arquitectos, diseñadores y programadores) y es este el argumento por el cual divido a los desarrolladores en dos grandes grupos: Desarrolladores de proyectos y Desarrolladores de mantenimiento.
Un desarrollador de mantenimiento es aquel cuya experiencia se centra principalmente en añadir funcionalidades a un conjunto reducido de aplicaciones con un alto nivel de madurez y estabilidad.
Evidentemente estos desarrolladores son expertos en esta etapa pero generalmente carecen de ciertas características necesarias para llevar adelante con éxito el proyecto que dará lugar al nacimiento de una aplicación.
A continuación quiero compartir 10 observaciones que he realizado durante el desarrollo de varios proyectos en los cuales se utilizó desarrolladores de mantenimiento para la fase de construcción.
10 observaciones sobre los desarrolladores de mantenimiento
1. Innovación: Ante un nuevo proyecto, el desarrollador de mantenimiento buscará construirlo sobre lo que le es conocido y que considera estable. Esta actitud reduce significativamente la probabilidad de alcanzar la innovación.
2. Seguridad: Un desarrollador de mantenimiento presenta mucha inseguridad respecto a lo nuevo lo que generalmente lo lleva a tratar de controlar todos los factores desde el inicio demorando así el comienzo del proyecto.
3. Estabilidad: Acostumbra a trabajar sobre aplicaciones muy estables por lo que no sabe manejar las vicisitudes de una aplicación inmadura.
4. Estimación: No es un buen estimador del esfuerzo inicial de un proyecto ya que lo ha realizado muy pocas veces.
5. Restricciones: Tenderá a la calidad por sobre el alcance y el tiempo ya que buscará que la nueva aplicación este dotada de la misma madurez a la que esta acostumbrado.
6. Flexibilidad: Carece de flexibilidad en lo que refiere al procesamiento de requerimientos ya que esta acostumbrado a usuarios que manejan muy bien el mecanismo y el lenguaje para añadir nuevas funcionalidades a una aplicación existente pero una nueva aplicación puede definir nuevas reglas de comunicación ya que los usuarios y clientes aún no tienen claro que es lo que necesitan.
7. Presión: Una nueva funcionalidad generalmente no implica gran presión sobre el equipo de desarrollo ya que la solución de software ya cumple los requisitos fundamentales para la organización, sin embargo, un nuevo proyecto implica crear un servicio que aún no existe y la ansiedad de clientes y usuarios pueden generar un nivel de presión a la que los desarrolladores de mantenimiento no están acostumbrados.
8. Gestión: No estan familiarizados con el proceso de gestión de proyectos así como tampoco a la auto gestión en el contexto de un proyecto.
9. Riesgos: Carecen de la capacidad de reconocer y mitigar los riesgos asociados al proyecto.
10. Entregables: Por su forma de trabajo habitual ponen foco en el resultado final y no comprenden la importancia de entregables completos, correctos y a tiempo, muy necesarios para el éxito de un proyecto.
Es importante aclarar que estas observaciones parten de la comparación entre desarrolladores de mantenimiento y desarrolladores de proyectos y tan solo constituye una generalidad. En ningún caso deben ser utilizadas como único argumento para descartar la participación de un desarrollador de mantenimiento en un proyecto de construcción de software.
Sí es importante que los responsables del servicio o de la gestión del proyecto sepan reconocer desarrolladores de mantenimiento y conocer sus limitaciones para mitigar los riesgos asociados a su participación.