10 observaciones sobre los desarrolladores de mantenimiento

¿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.

Nosotros creamos el servicio y el cliente lo bautiza

Quienes nos desarrollamos en actividades muy relacionadas a la tecnología solemos utilizar una terminología que nace de la pluma de autores referentes en nuestra área de conocimiento pero que lamentablemente es totalmente desconocida y hasta incomprensible para el resto del mundo.

Tal vez se deba a que el contenido detrás de los términos en nuestra área solo nos interesa a nosotros y por eso no se expande como sí lo hacen términos relacionados a otras áreas de conocimiento como las Ciencias Sociales o las Artes y Humanidades.

A decir verdad no he dedicado demasiado tiempo al análisis causal de esta situación ya que a muy temprana edad comprendí que la mejor forma de comunicarme con una persona es hablar su mismo idioma y eso incluye la terminología.

El motivo que me lleva a escribir este post es que algunas semanas atrás conocí a un profesional de la tecnología intentando “vender” su producto con un discurso tan cargado de terminología y jerga tecnológica que convirtió un sencillo mensaje en un complejo puzzle que los clientes no estaban dispuestos a armar.

El producto es bueno, el profesional parece ser una persona muy responsable y de confiar pero lamentablemente el cliente no va a comprar su producto. Mi diagnóstico: No supo comunicarse en el lenguaje del cliente.

Esta visión no solo se aplica a la venta de un producto o servicio a un cliente ajeno a nuestra organización sino que también a la venta de nuestro propio trabajo cuando debemos responder ante nuestros “superiores” - que en mi parecer no son más que clientes que nos pagan para obtener un determinado valor - o cuando debemos explicar cualquier situación a un cliente interno de nuestra organización.

Evitemos la terminología específica de nuestra área de conocimiento cuando tratemos de comunicarnos con personas ajenas a ella y sobre todo, leamos contenidos orientados a otras áreas, esto nos ayudará a ampliar nuestro vocabulario más allá del que manejamos en nuestro contexto diario.  

El emprendedorismo en la generación Y : Derrotistas y ambiciosos.

Para quién no me conozca, soy un gran observador del comportamiento laboral de la generación Y y en esta oportunidad quiero resumir el resultado de varios meses de observación sobre un aspecto de la relación entre esta generación y el emprendedorismo.

El hecho que me motivó escribir este post es la reciente asignación del título “The person of the Year” que otorgó la revista Times a Mark Zuckerberg, responsable de la creación de Facebook y quien, con apenas 26 años, cuenta con una fortuna que supera los 6.900 millones de dolares.

Mark, al igual que otros jóvenes que han forjado su fortuna a partir de una idea innovadora se han convertido en los iconos que representan el éxito empresarial para toda una generación (y tal vez más).

Cuando comencé a consultar a diferentes perfiles de miembros de la generación Y sobre el éxito de Facebook (y otras empresas exitosas basadas en una idea “simple”) podía distinguir tres claras actitudes que pueden ser representadas con las siguientes frases:

1. “Para lograr algo así es necesario vivir en Estados Unidos”

2. “Era estudiante de Harvard, evidentemente el dinero no fue problema para llevar acabo el emprendimiento”

3. “Hay que dedicarse completamente al proyecto durante años para lograr algo así”

La gran mayoría de los consultados dicen no haber podido crear algo como Facebook y de hecho solo algunos mencionaron la dificultad técnica o conocimientos necesarios, el resto adjudica esta imposibilidad a agentes que no pueden modificar fácilmente como el lugar de residencia, el capital económico o el tiempo, generando así, una actitud derrotista: “No participo en el juego porque tengo la certeza que voy a perder.”

Por otro lado, una vez que ahondé en la temática, la totalidad de los consultados dijeron tener la esperanza de que una idea llegue a sus puertas y con ella poder convertirse en millonarios. Incluso muchos de ellos mencionaron estar en su permanente búsqueda.

Concluyo que las afirmaciones derrotistas provienen de una sensación de fracaso y el consecuente proceso mental que lleva a los seres humanos a justificarlo.

La combinación de una actitud derrotista, gran ambición y un permanente proceso de auto justificación ante la falta de éxito podría ser el medio adecuado para el desarrollo de un virus que convertirá a gran parte de la generación Y en adultos frustrados.

La cura es sencilla:

Todos quienes tengan por misión o vocación, la formación de los miembros de ésta generación y de las siguientes, deben prepararlos para el fracaso, esto es, educarlos sobre la importancia del proceso a nivel cognitivo y emocional por el que debe ingresar el análisis del fracaso y debe emerger un conjunto de nuevas herramientas que les permitirán evitar los próximos.

No hablo de otra cosa que del proceso que denominamos “adquirir experiencia” pero lo que propongo es enseñarles a generar experiencia de forma eficiente tal y como les hemos enseñado a adquirir conocimiento.

Agradezco comentarios.

¿Reingeniería o mejora continua?

Semanas atrás llega a mis oídos que un consultor senior en procesos argumenta que no es necesario analizar y mucho menos realizar un flujograma para realizar recomendaciones de mejora sobre un proceso.

En una primera instancia decidí otorgarle el beneficio de la duda y averigüé si esta persona trabaja en un sector que domina o ejerce la consultoría en cualquier sector.

Lamentablemente se trata del segundo caso y digo lamentablemente porque su metodología de trabajo perjudicará a muchas empresas.

El punto es, existen dos grandes escuelas (entre otras) en lo que tiene que ver con la mejora de procesos: La Reingeniería y la mejora continua.

La primera implica considerar que el proceso es inadecuado y que la mejor estrategia es diseñarlo desde cero. La segunda en cambio propone un análisis del proceso y establecer planes de mejora.

Ambas líneas metodológicas tienen sus pros y contras y como herramientas que son, deben ser aplicadas si el contexto es el adecuado.

Es tan ridículo matar un mosquito con un lanzallamas como podar un árbol con una navaja.

La Reingeniería es una herramienta que solo puede ser utilizada por profesionales con mucha experiencia y conocimientos en el sector en el cual compite la empresa ya que esta metodología exige un basto conocimiento del negocio, de las reglas del mercado y de la idiosincrasia del sector.

Es verdad que personas con una gran capacidad analítica y con gran velocidad de aprendizaje de las reglas del negocio pueden, en pocos meses, adquirir TODO el conocimiento necesario para diseñar un proceso óptimo, pero seamos realistas, éstas personas son un bien muy escaso, el resto debe contar con dicho conocimiento antes de emprender la tarea.

En contraposición, las metodologías basadas en la mejora continua como Kaizen y Six Sigma proponen que el profesional realice una análisis del proceso (y del problema si se conoce a priori) de modo que le sea posible comprender la razón de su existencia, sus particularidad y las realidades que lo hacen ser como es.

Luego, el profesional aplicará una metodología concreta para establecer un plan de mejoras.

La mejora continua parte de la hipótesis que el proceso requiere ser mejorado pero que no es un desastre total como lo plantea la Reingeniería.

Los profesionales que aplican metodologías de mejora continua no requieren grandes cantidades de conocimientos y experiencia en el sector (aunque es deseable) sino que deben ser mayormente personas muy analíticas, críticas y sobre todo, orientadas al negocio.

Si usted se dedica a la consultoría de procesos o lo hará en el futuro, tenga en cuenta que modificar procesos implica riesgos, algunos de los cuales no se presentan a simple vista. Si realmente conoce todos los riesgos posibles podrá pensar en aplicar Reingeniería, de otra forma las consecuencias pueden ser muy graves y en muchos casos irreversibles.

Reclutamiento 2.0 vs Captación 2.0: Captar talento en Linkedin

Les dejo aquí el link al artículo que he publicado en suite101.net en el día de ayer.

En ésta ocasión he decidido poner foco en la captación de talento a través de las redes profesionales (captación 2.0) como técnica complementaria al reclutamiento 2.0 del cual he publicado otros artículos en suite101.net

Leer más en Suite101: Reclutamiento 2.0 vs Captación 2.0: Captar talento en Linkedin http://www.suite101.net/content/reclutamiento-20-vs-captacion-20-captar-talento-en-linkedin-a26903#ixzz11R45qcWt

Talento en redes sociales: Participación en grupos de Linkedin

Les dejo mi nuevo artículo en Suite101 :

Talento en redes sociales: Participación en grupos de Linkedin

Leer más en Suite101: Talento en redes sociales: Participación en grupos de Linkedin http://www.suite101.net/content/talento-en-redes-sociales-participacion-en-grupos-de-linkedin-a25807?sms_ss=linkedin#ixzz10D6ynnCW

Los errores del Reclutamiento 2.0

El reclutamiento de personal en redes sociales como Linkedin o XING presenta nuevos desafíos para los reclutadores. Las principales claves o tips.

Mucho se habla de los beneficios del Reclutamiento 2.0 pero poco sobre las metodologías y cuan eficaces son. ¿Cuenta su empresa con la preparación para realizar esta actividad?

Errores típicos que cometen los reclutadores 2.0

El principal error que cometen las empresas a la hora de buscar talento en las redes sociales es asignar la tarea a un reclutador tradicional sin previa preparación. Es decir, sin la formación adecuada, un reclutador tradicional aplicará las mismas estrategias a las que esta acostumbrado pero esta vez, en las redes sociales...

Leer más en Suite101: Los errores del Reclutamiento 2.0 http://www.suite101.net/content/reclutamiento-20--contamos-con-la-formacion-adecuada-a25366#ixzz0zRxrS64a