El equipo de desarrollo: ¿solo desarrolladores o un equipo real?

El equipo de desarrollo de software son en su mayoría chicos, son felices de trabajar solos por la noche en cuartos oscuros.

Y convierten el café, la cola y la pizza en código.

Mi experiencia hasta ahora

Para ser sincero, cuanto más tiempo he trabajado en el desarrollo de software, más me siento mal este estereotipo.

Es cierto que cuando aprendí a codificar, disfruté de esos momentos solitarios de descifrar una solución a un problema complicado.

No conté las horas y orgullosamente les conté a mis colegas y amigos sobre las noches que trabajé lejos.

Los primeros años de mi carrera como desarrollador de software trabajé en un pequeño equipo de tres personas donde todos tenían su experiencia específica.

Fui responsable de la aplicación del cliente que desarrollamos para una aplicación interna con el equipo de desarrollo propio.

Era el único que trabajaba con las tecnologías y bibliotecas específicas que usaba para crear las interfaces de usuario, así que básicamente era yo y una mezcla de documentos de Google y API (fue mucho antes de que naciera stackoverflow.com).

A veces pedía ayuda a mis colegas, pero la mayoría de las veces intentaban resolver sus propios problemas y no me eran de mucha ayuda.

Después de tres años, dejé esa empresa para comenzar un trabajo como consultor de TI.

Durante los siguientes seis años trabajé en muchos equipos diferentes, junto con mis colegas en nuestra propia oficina, como un equipo pequeño en la oficina de nuestro cliente o solo dentro del equipo de un cliente.

Algunos de esos equipos eran personas que trabajaban en el mismo problema, algunos eran equipos “reales”.

Entonces, ¿cuándo es un grupo en realidad un equipo?

Para mí, un equipo real no es solo personas que trabajan en el mismo problema, sino personas que tienen un objetivo común y colaboran estrechamente.

El objetivo común es el problema general que estamos tratando de resolver.

No desarrollamos software para satisfacer nuestro deseo de material tecnológico brillante, bueno, no solo, al menos. Intentamos facilitar la vida de nuestros clientes y usuarios.

Colaborar estrechamente significa trabajar con otros, no solo cerca de otros.

Con el tiempo he identificado varias características que considero necesarias para grandes equipos.

Autónomo

Los mejores equipos en los que he trabajado fueron autónomos hasta cierto punto.

Claro, algunos equipos tienen límites muy amplios y pueden elegir muchas cosas de los idiomas, las bibliotecas y las herramientas que usan para los problemas en los que quieren trabajar.

Otros tienen más restricciones.

Mientras trabajaba como parte de un equipo, una cosa importante para mí siempre fue tener límites claros que conozco y entiendo.

Entonces quería ser libre para decidir dentro de esos límites.

De esta forma pude sentir mucha autonomía incluso en entornos muy regulados.

Creo que los desarrolladores de software necesitan autonomía como condición previa para ser creativos en la búsqueda de soluciones, lo que nos lleva a …

Creativo

“Siempre lo hemos hecho así”.

Esta es una de las oraciones que más temo. Me despoja de toda la creatividad que tengo.

Aunque es posible que siempre hayamos hecho cosas así, esto no significa que no podamos mejorar al intentar algo diferente.

Por lo tanto, creo que la creatividad, el impulso intrínseco para encontrar nuevas (y mejores) soluciones a los problemas existentes, es clave para el desarrollo de software.

La tecnología y las necesidades de los usuarios cambian tan rápido que las soluciones de ayer a menudo no son aptas para los desafíos de hoy.

La creatividad es un rasgo individual que puede irradiarse y estimular a un equipo.

En mi experiencia, los equipos creativos también son …

Curioso

Soy una persona muy curiosa y no puedo contar los proyectos paralelos que comencé porque estaba interesado en aprender algo nuevo: una nueva tecnología, un nuevo dominio de problemas, una nueva forma de pensar.

Al igual que la creatividad, la curiosidad es un rasgo individual. La gente curiosa hace muchas preguntas.

Esas preguntas ayudan a descubrir la causa raíz de un problema. También nos permiten crear más información sobre un contexto específico en el que nuestra solución podría aplicarse.

Esto ayuda a prevenir soluciones que son torpes en el mejor de los casos y que no son aptas para el problema en el peor.

Ahora que hemos hablado sobre los rasgos individuales que ayudan a un Equipo de Desarrollo a ser lo mejor posible, hay algunas características del equipo. Los grandes equipos son grandes equipos de desarrollo.

Diverso

Volvamos al estereotipo con el que comencé esta publicación. En primer lugar, creo (espero) que sea difícil encontrar un equipo de personas que encarne este cliché.

Al menos los equipos que me gusta recordar por la diversión y la eficacia que pudimos tener, eran diferentes.

Consistían en personas muy diferentes. Personas de diferente género, raza, creencias, edad, etc.

Esta diversidad permitió crear un contexto más amplio de experiencias y conocimientos. Nos criaron de manera diferente, vivimos de manera diferente y, sin embargo, pudimos trabajar en equipo. La diversidad induce tolerancia.

La diversidad como se describe aquí es un lado de la moneda. Los grandes equipos en los que he trabajado también fueron …

Multifuncional

La diversidad para mí describe quién es alguien. Cuando hablo de la funcionalidad cruzada, hablo de lo que alguien sabe y puede hacer: el tipo de experiencia que alguien tiene.

En el complejo entorno del desarrollo de software, existen muchos tipos especiales de conocimiento que necesitamos para resolver un problema. Desde el dominio comercial o problemático a través de diferentes partes de tecnología, sistemas y sus dependencias hasta ejecutar, monitorear y mantener la solución. Una persona no puede tener todo este conocimiento en la profundidad necesaria.

Por lo tanto, necesitamos individuos que sean expertos en uno o más de esos dominios y que sean …

Generoso

Compartir conocimiento y experiencia es clave para un equipo multifuncional. Ayuda a las personas a crecer y a todo el equipo a mejorar.

El desarrollo de software no es un juego de suma cero. Esto significa que el beneficio de una parte del sistema tiene que venir con una pérdida para otra parte.

Mientras más personas comparten, más mejoran los miembros del equipo y el equipo en general. Un colega que se beneficia de mi conocimiento y experiencia no me quita nada, por el contrario: al compartir y aprender unos de otros, todos nos beneficiamos.

¿Cómo llegar ahí?

Si bien esos rasgos son beneficiosos para el miembro individual del equipo, también están mejorando mucho el equipo en general y su rendimiento. En mi experiencia, el costo de tratar de mejorar continuamente un equipo en esos y otros aspectos es más que compensado por los beneficios a largo plazo que el equipo y la compañía obtienen.

La pregunta ahora es cómo puedes crear y hacer crecer un equipo con esas características. Para ser sincero, no lo sé. Ni siquiera creo que haya una sola receta para crear grandes equipos. Lo que he experimentado en el pasado es que puedo trabajar con mis compañeros y colegas, discutir dónde estamos en este momento (y celebrar nuestros éxitos hasta ahora) y qué podemos hacer para mejorar aún más.

Algunas cosas concretas que he visto trabajar en los equipos con los que trabajé fueron:

Intercambio de conocimientos dentro de los equipos: almuerzos de bolsa marrón, charlas tecnológicas, programación en pareja / mafia

Invite a la gerencia a definir explícitamente los límites que el equipo debe respetar en su autoorganización y a revisarlos periódicamente, p. como parte de una retrospectiva

Cuando se encuentra con un problema, hacer algo completamente diferente para obtener nuevas ideas e ideas nuevas y ejecutarlas con el equipo de desarrollo.

Intentar aprender más sobre los dominios de negocios, tal vez colaborar con un usuario de negocios de su sistema durante unas horas o días lo ayudará a comprender con qué realmente están luchando.

Invitar a otros equipos o colegas que no trabajan directamente con el sistema que creamos a las revisiones y solicitar sus comentarios; a veces solo explicar lo que hemos tratado de hacer a alguien no relacionado ayuda a crear una mejor imagen

Esta lista es, de lejos, no completa. Estos son solo algunos ejemplos de cosas que hice en el pasado con el equipo de desarrollo del que formaba parte.

Siempre disfruto conocer a otros desarrolladores de software, discutir el trabajo en equipo e intercambiar experiencias. Creo que la asesoría entre pares es una excelente manera de mejorar. No se trata de encontrar la mejor manera de trabajar en equipo. Para mí, se trata más de descubrir qué hacen los demás y cómo esto podría ser aplicable a mi propia situación.

¿Cuál es tu experiencia?

Entonces, ¿cuál es tu experiencia? ¿Qué características ves que forman grandes equipos? ¿Cómo puedes (auto-) mejorar en tus equipos? ¿Estás en desacuerdo? Tengo curiosidad por tus comentarios sobre el equipo de desarrollo.

Si eres un Scrum Master, ¿cómo puedes o podrías ayudar a tu equipo a mejorar en esos aspectos? ¿Ese es el equipo de desarrollo necesita mucho tu ayuda?