Descargo de responsabilidad: de ninguna manera se perjudicó a los desarrolladores en el proceso de investigación de este artículo.

Algunos días intentan sacarte cantidades ridículas de dinero. Otros días, son tus hermanos mayores y protectores que resuelven tus problemas desinteresadamente. Trátelos de manera justa e incluso podrían estar dispuestos a hacer un trabajo gratis para usted. Son una raza interesante y, para cualquier empresa de tecnología, son indispensables. Entonces, ¿cómo contratas y posteriormente trabajas con desarrolladores?

 

Mi propia incursión en el desarrollo

Originalmente aprendí fragmentos de desarrollo de software como un interés en la tecnología, pero también se transformó en un interés en las personas que participan en el desarrollo. Igual de bien, porque el tiempo que dediqué a aprender a codificar ha dado grandes frutos en mi capacidad para comunicarme entre el lado comercial y el lado técnico de la empresa. A CityFALCON, hemos tenido la suerte de tener un equipo de desarrolladores con los pies en la tierra que también estaban dispuestos a abrir la calle a la comunicación bidireccional, y mi capacidad inicial para iniciar una conversación con una idea clara de cómo piensan los desarrolladores probablemente contribuyó significativamente a esa apertura de comunicación.

 

Las demandas del desarrollador

Durante el proceso de contratación, los empresarios probarán por primera vez la especie. Para aquellos que nunca han trabajado en tecnología y no conocen la cultura del desarrollo de software, puede ser un poco sorprendente. Pero para aquellos que han leído este artículo, el impacto debería ser mitigado. Habrá alguna variación entre generaciones, pero probablemente no será tan pronunciada como la división generacional en algunas otras profesiones.

Condiciones comunes observadas a través de la experimentación repetida durante el proceso de contratación: Sin horas extras. No se trabaja en el lugar. Sin horario fijo. Sin plazos estrictos. Si paga alta. Sí, tiempo de vacaciones flexible. Sí, una selección de proyectos. Sí alta autonomía.

Estas son algunas demandas de muestra con las que podría encontrarse como agente de contratación. Sí, como agente de contratación, en la entrevista, es posible que se le pregunte si su empresa proporcionará estos beneficios. A veces, el requisito de no pagar horas extraordinarias puede ser un punto de fricción. Los mejores desarrolladores saben que pueden exigir esto, por lo que si tiene a alguien sentado frente a usted, exigiendo estas condiciones con mucha confianza, probablemente tenga un buen desarrollador a su alcance.

Esto puede ser un shock, ya que probablemente sea un poco diferente de las demandas de otros empleados, que generalmente piden salarios altos, tal vez unas vacaciones y beneficios adicionales, como membresías en gimnasios y café gratis. Por supuesto, a los desarrolladores probablemente también les gustarán esos beneficios, pero tienen sus razones para exigir lo que exigen.

Curiosamente, una vez que el espécimen se integra en el grupo, y especialmente en empresas con culturas muy unidas, se vuelven como una familia. Aquí es cuando muchas de esas demandas (temporalmente) desaparecen y el desarrollador se vuelve como el hermano mayor que lo ayuda sin importar el costo para ellos. Por supuesto, si presiona demasiado durante demasiado tiempo, simplemente se trasladarán a la siguiente (y posiblemente mejor) compañía.

 

Las motivaciones del desarrollador

Las demandas expresadas en la sección anterior se originan en las motivaciones particulares del desarrollador. Por supuesto, al igual que cualquier trabajador humano, aquí hacemos un punto para excluir a los trabajadores robot que tienden a no exigir nada en absoluto, excepto petróleo, electricidad y la actualización ocasional de software, el desarrollador quiere una vida agradable, aceptación social, trabajo interesante, y así.

Si bien muchas personas simplemente buscan dinero para comprar en la cultura del consumidor, los desarrolladores tienden a estar más interesados en el progreso y los logros intelectuales. Tiene sentido y se deriva naturalmente de su trabajo, ya que el campo elegido es un gran esfuerzo intensivo en conocimiento.

Obviamente, también exigen dinero porque necesitan vivir. Pero después de cierto punto, el dinero es menos importante que otros factores, como una cultura de trabajo y una gestión que los entienda.

Otras motivaciones incluyen:

Aprendizaje - Realmente no quieren ser las personas más inteligentes de la sala, porque entonces no podrían aprender ni mejorar. Honestamente hablando, la mayoría de los desarrolladores disfrutan de saber mucho sobre su área de especialización y lo harán alarde de ello cuando surja, pero también escucharán con atención cuando las personas con conocimientos en otras áreas hablen para poder aprender sobre esas áreas. Como una esponja cerebral que absorbe información para una conquista posterior.

Ser tomado en serio - si hacen una sugerencia, quieren que la dirección los tome en serio. Esta es una motivación básica de los empleados, pero por alguna razón, cuando los desarrolladores expresan sus sugerencias, muchos gerentes lo descartan como "solo una cosa técnica". No hay muchas cosas que hagan hervir la sangre de un desarrollador como una persona sin conocimientos técnicos que dice “es solo una cuestión de tecnología”. Sin sorpresa para nadie, la gran mayoría de las empresas funcionan con al menos algunos tecnología en estos días, en efecto, haciendo que cada negocio sea al menos algo "una cosa de tecnología"

Entendido - ellos también quieren ser entendidos. De manera similar a ser tomado en serio, este también es un deseo básico de los empleados. Y nuevamente, los desarrolladores tienden a ser menos entendidos que los equipos de cara al cliente o al socio. Este último trabaja con humanos e interacciones humanas todo el día, mientras que los desarrolladores trabajan con sistemas. A veces se necesita un poco de esfuerzo adicional para comprender a los desarrolladores sobre los roles centrados en el ser humano, pero vale la pena el esfuerzo.

 

Interactuar con las especies

Ahora que ha atrapado a un desarrollador (presumiblemente mediante la contratación y no mediante una trampa para osos), necesitará saber cómo manejar las interacciones. Obviamente, no te arrancarán la cara como un oso atrapado, pero varias malas interacciones y podrías ver sitios web más lentos y menor productividad. ¿Quién quiere trabajar en un lugar con una cultura opresiva?

 

Dar y recibir consejos

Un área en la que surgen muchos problemas es al dar y recibir consejos. Los empleados que no están en el lado tecnológico del negocio pueden creer que algo es perfectamente fácil de hacer, pero puede que no lo sea. Suelen dar consejos como "oh, haz X y funcionará". Claro, eso podría funcionar desde la perspectiva del usuario, pero hacer X rompe tres cosas en el backend y derriba un sistema integral que los usuarios no ven pero en el que confían por completo.

También está el problema de la condescendencia. Se podría decir "no debería ser tan difícil ..." Pero si el desarrollador dice que es difícil, probablemente sea difícil. La tecnología no es un dispositivo mágico y los desarrolladores no son magos. No pueden hacer que las cosas sucedan si no pueden hacer que las cosas sucedan, y usar un lenguaje como "no debería ser tan difícil" es una forma segura de causar obstáculos.

Por estas razones, los desarrolladores a menudo no siguen los consejos de nadie excepto de otros desarrolladores. En cierto modo, tiene sentido: las únicas personas que poseen un conocimiento profundo sobre los sistemas son otros desarrolladores. Los expertos dan consejos a otros expertos, precisamente porque ahí radica su experiencia. Los laicos generalmente no aportan mucho a la mesa. No querría que su plomero le dijera a su cirujano cardiotorácico cómo realizar una cirugía cardíaca, solo porque ambos funcionan con tuberías y válvulas, ¿verdad?

De manera similar, los desarrolladores pueden presionar por ciertas soluciones que no son operacionalmente o públicas relacionalmente factibles. ¿Tiene una solución para automatizar 75% de los trabajos pero solo alcanza la precisión de 81%? Bueno, podría ser una maravilla técnica, pero simplemente no funcionará desde una perspectiva comercial y de servicio al cliente. Por no hablar de la pesadilla de relaciones públicas de despedir a tres cuartas partes de la fuerza laboral. Para esta analogía, no querrá que su cirujano cardíaco repare su tubería reventada en una emergencia si nunca antes ha experimentado emergencias de presión de agua de 80 PSI.

 

Manejo de expectativas

Aquellos en la primera línea del negocio tendrán visiones, pero con demasiada frecuencia creen que los desarrolladores son magos. Ellos no están. Pueden ser inteligentes, pueden hacer algunos trucos de magia, pero todo se basa en la física y la informática. Eso significa que no hay hechicería y no todas las visiones comerciales pueden implementarse de manera factible. O tal vez es posible, pero al departamento de TI solo se le asigna un cierto presupuesto, y la visión sería demasiado costosa en recursos computacionales.

La peor forma de gestionar las expectativas es involucrar a los desarrolladores en la conversación en las últimas etapas del desarrollo. No hagas esto. Si desea que se desarrolle algo, debe traer al desarrollador temprano. Eso asegurará que sea técnicamente factible.

Los desarrolladores tampoco son autómatas descerebrados. Son interactivos, siempre y cuando les hable, y ellos (normalmente) responden. Te dirán qué es posible e incluso trabajarán para encontrar soluciones si creen que existen. Probablemente también ayudarán a guiar el proceso de desarrollo desde un punto de vista técnico. No desea que todo su proyecto se base en una única suposición para descubrir, después de 3 meses de planificación, que su suposición no es posible en función de los recursos informáticos de la empresa.

 

Promoción y responsabilidades

Los desarrolladores quieren codificar y diseñar sistemas. Esa es la razón por la que se metieron en esta línea de trabajo en primer lugar. Muchos tampoco quieren seguir el camino tradicional de progresión profesional. Los desarrolladores (y muchos otros trabajadores técnicos) a menudo se convierten en gerentes, pero muchos de ellos realmente no quieren las responsabilidades adicionales ni el aspecto de gestión humana. Los seres humanos son complejos y a menudo ilógicos, a diferencia de los sistemas informáticos. Eso puede resultar extremadamente frustrante para las personas acostumbradas a trabajar con sistemas lógicos. Tampoco se puede descartar por completo a un humano y reconstruirlo en un entorno virtual, por lo que también existe eso.

Por otro lado, a algunos desarrolladores les gustaría ser administradores. O están lo suficientemente abiertos a nuevas ideas como para al menos intentarlo. Si no les gusta, asegúrese de tener una forma de hacer la transición de nuevo a roles menos gerenciales después de un tiempo. Si no lo hace, podrían abandonar el barco. Los trabajos de desarrollo solo para tecnología son abundantes y están muy bien remunerados.

 

Tiempo a solas y sociabilidad

Existe un estereotipo de desarrolladores como habitantes de la sala de servidores, sentados en el frío y en la oscuridad, sin hablar con nadie excepto a través de programas de chat, sin salir de la sala excepto para ir a casa, y cualquier interrupción es totalmente inoportuna. Esto sólo es parcialmente cierto.

Los desarrolladores, al igual que cualquier otra persona, realmente quieren un tiempo ininterrumpido para trabajar en sus proyectos. Con frecuencia, los desarrolladores deben hacer malabarismos con varias partes de un sistema en sus cabezas e intentar integrar nuevas ideas en ellas sin romper ninguna de las otras partes. La memoria humana no es tan confiable como la memoria de la computadora, y las interrupciones pueden hacer que ese acto colapse rápidamente. Se necesita mucha energía para que los malabares comiencen de nuevo, y esa es la razón por la que a los desarrolladores no les gusta que los interrumpan.

Sin embargo, son tan sociales como cualquier otra persona del grupo. Trate de incluirlos en sus salidas o en sus payasadas en la oficina (aunque puede omitir la política de la oficina). Solo asegúrate de no hacerlo bien antes de un gran lanzamiento. En su lugar, hágalo inmediatamente después y felicítelo por su trabajo. Ellos lo apreciarán, usted se congraciará con ellos e incluso puede aprender un par de cosas sobre sus sistemas tecnológicos en el camino.

 

La cuestión de los plazos

Este siempre es delicado. Los plazos incumplidos son difíciles, pero ocurren con una frecuencia desconcertante en el desarrollo de software. Los desarrolladores quieren lanzar productos de primera categoría, pero hay muchos problemas que podrían surgir. Tampoco quieren ser responsables si todo falla, ni quieren arreglar cinco agujeros de seguridad en el servidor de producción si pueden solucionarlos antes de que se lance el producto.

Una fuente común de problemas inesperados es el código de terceros. Muchos sistemas se basan en códigos de terceros y, a veces, ese código no funciona bien con otros códigos de terceros. Es posible que ese conflicto no se descubra hasta tarde en un proyecto, y luego la fecha límite debe adelantarse un mes mientras se escribe el código propietario para adaptarse al problema o se encuentra e integra un nuevo código de terceros. Otra fuente común de sobrepaso de la fecha límite es un error importante en los cimientos del sistema que causa problemas para el nuevo código, lo que significa que más de un proyecto debe revisarse antes del lanzamiento.

Dado que los sistemas pueden volverse tan complejos rápidamente que ninguna persona sabe cómo funciona todo, a menudo se pasan por alto los plazos. Así es la vida del desarrollo de software. Puede establecer fechas límite, pero asegúrese de que su personal técnico sepa que un producto sólido es más importante que una fecha límite arbitraria. En realidad, si no conecta la fecha límite con un evento importante, los desarrolladores podrían simplemente ignorarlo por completo.

Por lo tanto, establezca fechas límite, pero anótelas en las consecuencias del mundo real, como que su competidor será el primero en comercializar y todo su negocio se hundirá. Eso ayudará al equipo de desarrollo a priorizar. Sea flexible, porque se incumplirán los plazos. Y asegúrese de gestionar sus expectativas; de lo contrario, sus plazos no estarán alineados con las capacidades de los desarrolladores y se perderán.

Finalmente, si un desarrollador dice que no publique el software, no lo publique. No hay nada peor para las relaciones con los clientes que una actualización de software que se rompe o crea un agujero de seguridad. Perder una fecha límite por unos días es infinitamente mejor que perder unos días de ingresos debido al código defectuoso y el impacto en la reputación que causará.

 

Observaciones finales

Como cualquier buen artículo (no) científico, queremos terminar con un breve resumen y una conclusión.

A lo largo del artículo, hablamos de los desarrolladores como una especie, casi ajena a los gestores de personas. Pero los desarrolladores también son humanos y deberían ser tratados como tales. Si tiene algo de tiempo, como emprendedor que busca un equipo de desarrollo, le sugiero que aprenda al menos un poco de codificación, cómo funcionan sus sistemas y qué está haciendo su equipo. Ayudará en gran medida a comunicarse sin problemas e incluso podría darle un par de hermanos mayores y protectores.

Conocer las limitaciones de sus sistemas y de su equipo garantizará que todos estén en la misma página y que no se produzcan explosiones o quemaduras. Impulsa al equipo hacia adelante como un equipo de remo bien orquestado en lugar de uno vacilante que hace que todos se sientan infelices. Y los desarrolladores tienen una demanda tan alta como siempre, por lo que presionar continuamente los botones equivocados hará que esta especie busque pastos más verdes. La lealtad a la empresa solo está muerta para las empresas desleales, así que no sea víctima de perder un gran desarrollador y potencialmente toda su infraestructura técnica.

 

Solo teníamos un alma valiente dispuesta a mostrar su rostro como una de las especies de actualidad, así que aquí está esa alma valiente (es nuestro DBA y el tipo de infraestructura):

Y como nadie más se ofreció como voluntario (los desarrolladores pueden ser un poco tímidos e introvertidos a veces), aquí hay una foto de parte de nuestro equipo. Para ser honesto, es difícil encontrarlos en un solo lugar a la vez; la cultura de trabajo remoto de los desarrolladores realmente infecta a toda una startup, incluso a aquellos que no son desarrolladores.

Y todos en la oficina, no solo los desarrolladores de software, parecen estar haciendo esto todo el tiempo (mirando las computadoras)