Personalmente, diría que la mayor dificultad de trabajar con desarrolladores de software es encontrar un lenguaje común. Trabajo en una empresa de desarrollo de software (Neoteric) donde soy especialista en marketing.
Cuando vine a trabajar por primera vez en este mundo extraño, estaba muerta de miedo. O debería haberlo estado, porque en ese momento no estaba realmente consciente de lo que debía esperar. Me golpeó unos días después. No estaba muy seguro de por qué me contrataron y cómo debería hablar con el mundo exterior sin saber nada sobre el mundo dentro de la empresa.
La mayor dificultad para mí fue comprender a estas personas extrañas: saber de qué están hablando, aprender su jerga, familiarizarse con el código de cultura “tecnológica”. ¡Y ni siquiera estaba trabajando con ellos directamente! Quiero decir, no era ni gerente de proyecto, ni diseñador ni dueño de producto. Hice mi trabajo, ellos hicieron su trabajo y vivíamos en una simbiosis perfecta.
- ¿Estás haciendo programación de pares en tu trabajo?
- ¿Por qué algunas empresas que desarrollan software no valoran a los científicos teóricos?
- ¿Puedo conseguir un trabajo en Google para un puesto de desarrollador de software con experiencia en electrónica?
- ¿Debo aceptar un puesto de probador de desarrollador de software con Audible en Cambridge MA?
- Cómo convertirse en un desarrollador de software con el que a todos les gusta hacerse amigos
Sin embargo, durante los últimos 2 años tuve la oportunidad de observarlos, ver cómo funcionan, qué les gusta y qué no les gusta. Y creo que las mayores dificultades de trabajar con desarrolladores de software provienen de la falta de comprensión mutua . ¡Lo que se aplica tanto a los no desarrolladores que no entienden a los desarrolladores como a los desarrolladores que no entienden a los no desarrolladores!
Las personas no técnicas a menudo tienen problemas para comprender a los desarrolladores. No solo su trabajo en sí mismo (código y todas esas cosas técnicas), sino también la forma en que trabajan: su motivación, sus excentricidades y rarezas.
Hay algunas cosas que a la mayoría de los desarrolladores simplemente no les gusta. No les gusta ser interrumpidos (es algo sobre el “flujo” mágico), no entender cosas (como cuando se les dice que hagan algo sin que se les diga por qué hay que hacerlo), o trabajar en tareas aburridas y repetibles. (Más cosas con más explicaciones: ¿Qué odian los programadores?)
Por eso es importante tener a alguien que pertenezca a estos dos mundos alternativos . Como un buen gerente de proyecto que entiende las necesidades del negocio pero que también tiene suficiente experiencia técnica para llevarse bien con los desarrolladores.
Recientemente escribí un artículo con 10 cosas para evitar al trabajar con desarrolladores – basándome en mi respuesta anterior de Quora a lo que odian los programadores. ¡Mira esto!
Por último, pero no menos importante, aquí hay algunas pautas básicas para ayudarlo a encontrar un hilo de entendimiento con los programadores:
1. Nunca interrumpas
Mientras no haya fuego en el edificio, no haya llamadas telefónicas del hospital o de la policía, puede esperar. Cuando hablas y el desarrollador no responde pero sus dedos están constantemente escribiendo algo en el teclado, probablemente esté teniendo una conexión con alguna dimensión diferente. Respetarlo
2. No seas demasiado mandón
Mientras el proyecto se apegue al plan y su equipo no desperdicie su presupuesto, no tiene nada de qué preocuparse. Si los desarrolladores quieren gastar su dinero trabajando en algún problema relacionado con su proyecto, todo está bien. Y todavía está bien cuando al día siguiente llegan a la oficina al mediodía. (A menos que tengan alguna reunión programada, entonces no está bien en absoluto).
3. Da una razón
Cuando les pidas que hagan algo (o que no hagan algo), diles por qué es importante para ti. Recuerde que está tratando con el grupo con una gran necesidad de entender el mundo. Por cierto, ya se demostró que razonar sus solicitudes puede mejorar significativamente sus posibilidades de cumplirlas. El experimento realizado en 1977 por Ellen Langer (Experimento de atención plena de Xerox) demostró que mientras la solicitud sea pequeña, dar una razón para una solicitud, incluso la más absurda, es una estrategia mucho más efectiva que no dar ninguna razón. ¡Lo peor para recordar!
4. No seas ignorante
Vea lo que significa el ‘programador’ y en qué se diferencia del soporte técnico o del administrador, haga una hoja de trucos de las tecnologías y aprenda la diferencia entre un lenguaje y un marco. Eso debería funcionar desde el principio.
Y si realmente no puede evitar hacer nada de lo anterior, al menos muestre su simpatía .