Interesante artículo extraído de aquí
El mundo de los administradores es muy diferente al de los desarrolladores de software y con frecuencia tienen problemas para comunicarse entre sí.
¿Por qué ocurre esto? Buena parte se debe a que el desarrollo de aplicaciones es una habilidad difícil de adquirir y dominar. A un desarrollador le preocupan más el aspecto técnico que el económico -negativo o positivo- de sus acciones. Su visión muchas veces es limitada y no tiene “sentido del impacto político que puede causar”, como argumentan algunos administradores de dependencias gubernamentales.
El autor del libro sobre programación The Ruby Way, Hal Fulton, con una amplia experiencia como desarrollador en la industria de cómputo, nos comparte sus consejos para motivar a los desarrolladores de código, comunicarse mejor con ellos, y entender a esas “extrañas personas” que diseñan las aplicaciones en que tanto confiamos.
1. Recuerde al desarrollador que “la excelencia técnica no es garantía de éxito”. Muchas veces estos conceptos ni siquiera están relacionados. La historia está llena de ejemplos en que productos superiores fracasaron por diversas razones y los desarrolladores lo entenderán si se les recuerda esto.
2. Señale el impacto económico siempre que pueda y sea lo más específico posible. Si un desarrollador quiere atrasar la agenda un mes para añadir una funcionalidad que él considera importante, introduzca el dinero en la ecuación. Háblele de la importancia de tener a tiempo el desarrollo y el impacto de retrasar un mes la entrega del sistema, ya sea en cuantificación monetaria -tal vez por recaudar menos o por gastar más en el desarrollo- e incluso el impacto político que puede tener. Pida al desarrollador que evalúe la situación a la luz de esos hechos.
3. Explore las razones que tiene el desarrollador para estar en desacuerdo, porque pueden ser válidas. No olvide que el otro lado puede tener la razón. Lo más importante es tener una buena comunicación entre las dos partes para mitigar el conflicto. Si un desarrollador está en contra de seguir un plan de acción, no deseche su opinión de inmediato; él es un profesional en su campo, tal como usted lo es en el suyo. No sea un dictador.
4. Explique al desarrollador las limitaciones y las suposiciones sobre las cuáles está usted trabajando, así como la razón de sus decisiones. Si debe ignorar la opinión de un desarrollador, ¡al menos tenga una justificación para ello! Ambas partes suelen ser razonables y todo es cuestión de una buena comunicación.
5. Para que la comunicación sea posible es necesario que ambas partes hablen el mismo lenguaje. Si la organización tiene programas de actualización, promueva que los desarrolladores estudien algo relacionado con administración. Si tiene suerte, eso les “abrirá los ojos”.
6. Tampoco hace daño que el administrador estudie algo en un nivel más técnico. No se trata de igualar el nivel experiencia de un programador, pero sí de entender mejor el aspecto técnico y estar actualizado en las tendencias y novedades. Nunca pretenda saber algo que no conoce. La ignorancia honesta siempre es mejor que el conocimiento supuesto.
7. No sujete demasiado a los desarrolladores a la burocracia que suele existir dentro de las organizaciones. Nada frustra más a un desarrollador que estar alejado del trabajo real para llenar formas o atender a aparentes reuniones sin sentido en las que no se logra nada. Seguir las reglas y procedimientos es necesario, pero no se convierta en un esclavo de ellas.
8. Aleje a sus desarrolladores de la burocracia tanto como pueda. Ellos lo apreciarán y lo respetarán más y serán más productivos.
9. Ayude a hacer más eficientes los procesos, e incluso reducirlos, si esto ayuda a la productividad. ¿Necesitan sus desarrolladores registrar lo que hacen cada15 minutos? ¿Requieren llenar un reporte de tres páginas cada semana? Si estas cosas contribuyen al resultado final, manténgalos; pero si no es así, mire a otro lado mientras esas prácticas inútiles se dejan de hacer.
10. Léa la tira cómica Dilbert. No le sorprenderá darse cuenta que gente con la que trabaja se parece mucho a Dilbert, el personaje de la tira estadounidense. Si usted mira más allá de la exageración del cómic, apreciará la realidad. ¿Quién dijo que aprender no puede ser divertido?
No hay comentarios.:
Publicar un comentario