Comunicación en equipo (importa más que sus herramientas)

Desde que trajeron a un par de contratistas, una pregunta que otros hacen es:

o¿Cómo es pasar de trabajar solo en proyectos a trabajar en proyectos con un equipo?

O, más simplemente, ¿cómo es tener contratistas? La respuesta corta es que me gusta porque ofrece algunas ventajas:

• tenemos que tener una fuerte división del trabajo,
• la empresa puede asumir más proyectos,
• podemos colaborar en cosas (que es algo que extraño de volar solo),
• y más.

Sin embargo, el otro lado de esto es que siento que tengo que aprender lo que es comenzar un negocio de nuevo.

Como empezar con una pizarra en blanco.

Esto, de ninguna manera, es algo malo. Es lo contrario. Pero cuando pasas de trabajar en proyectos por tu cuenta y desarrollar tu configuración, ocurre un período de ajuste.

Todavía estoy experimentando esto y trabajando a través de él. Requiere conversaciones con su equipo y un poco de introspección para determinar si lo que está haciendo sigue siendo adecuado para su forma de trabajar o si debe ajustarlo.

Comunicación del equipo

Obviamente, este tema en particular es amplio y yo, junto con muchos de ustedes, podría hablar sobre una variedad de cosas relacionadas con la gestión de un negocio.

Pero, por hoy, lo único de lo que quiero hablar es el papel que juega la comunicación del equipo, no las herramientas de desarrollo de software, en la entrega de soluciones a los demás.

Tus herramientas importan (pero no tanto)

Por ejemplo, he trabajado en un lugar donde te traen una máquina con un conjunto particular de herramientas y dicen "Esto es lo que usamos para construir nuestros proyectos".

Claro, requiere que lo aprendas, pero a una parte de mí le gustó esto, ya que elimina el dolor de cabeza que surge al descubrir qué usar. También me evitó tener que tomar esas decisiones por mi cuenta.

Por otro lado, también dificultaba la introducción de una nueva herramienta porque interrumpiría el flujo de trabajo de todo un departamento. Sin embargo, cuando eres un equipo pequeño, es un poco más fácil adaptarse.

Visual Studio Code se ha convertido en mi IDE favorito.

Primero, cuando trabajas para ti mismo, es probable que tengas tu favorito:

• VA
• sistema de control de fuente,
• construir herramientas,
• herramientas de despliegue,
• entorno de acogida,
• y así.

Sin embargo, cuando traes a otros a la mezcla, estás aportando exactamente las mismas cosas, excepto que es en sus términos. Ahora tiene la tarea de determinar si debe quedarse con lo que tiene, evaluar lo que tienen, hacer que adopten sus herramientas, adoptar sus herramientas, unir las dos o comenzar de nuevo.

Esta no es una manera trivial, especialmente cuando están trabajando juntos para resolver una solución para un cliente. Podría escribir mucho más sobre esto. Y no me malinterpreten: creo que es un tema que debe ser discutido y es algo que creo que es importante.

Pero hay algo que se encuentra por encima de todo esto que nunca debe subestimarse, y ese es el proceso de comunicación del equipo.

La comunicación importa (y más)

No estoy hablando de asegurarme de controlar el estado de ánimo de las personas todos los días (aunque eso es importante), y no estoy hablando de chatear por mensaje de texto o Slack o IRC solo porque sí, para que te sientas productivo.

La comunicación del equipo es más que Slack.

Estoy hablando de requisitos de comunicación completa.

Caso en cuestión: digamos que estoy hablando con un cliente, acepto un contrato y luego estoy listo para seguir adelante. Sé lo que quieren, los diseños existentes y cómo debería funcionar algo. Luego traigo a un compañero de equipo y digo "Oye, comencemos".

El problema aquí es claro, ¿verdad? No tiene idea de qué es lo que buscamos.

Y no importa cuánto describa los pasos en su herramienta de administración de proyectos o converse sobre cómo debería funcionar algo.

Además, puede tener la configuración de herramientas más elegante y eficiente posible, pero si su equipo no tiene claros los requisitos del proyecto, entonces nada de eso importa.

Cuando decida contratar a alguien para que lo ayude con los proyectos, y cuando decida comenzar a colaborar en la solución, posponga la discusión sobre las herramientas y los requisitos de la primera discusión.

Esto no puede ser subestimado.

Si conoce los requisitos y su compañero de equipo no, o si los requisitos no se comunican claramente por un motivo u otro, entonces no se entregará la solución adecuada. Y esto es obviamente costoso.

Además, si terminas pensando que tienes las mismas ideas en mente y terminas implementando algo completamente diferente, entonces tienes otro conjunto de problemas con los que lidiar.

En lo que a mi negocio se refiere, me preocupa principalmente desarrollar relaciones con las personas con las que trabajo, tanto en mi equipo como con quienes nos contratan.

Pero si las discusiones internas sobre las soluciones en las que estamos trabajando no están en la misma página, nada más importa: ni sus herramientas, ni lo que envía, ni qué tan rápido lo envía, y no si simplemente se hace.

Más por venir

Entonces, en una publicación futura, compartiré algunas ideas de experiencias personales hasta el momento, tanto errores como victorias, con la esperanza de que pueda evitar lo que sea que pueda enfrentar cuando opte por hacer crecer su equipo.

No me malinterpreten: es fantástico (y me encanta), pero requiere ajustes en niveles para los que no estaba completamente preparado.

Mientras tanto, si tiene cosas que aportar a esta publicación, no dude en hacerlo en los comentarios. Siempre estoy ansioso por escuchar cómo los autónomos y los que también trabajan por cuenta propia o que gestionan equipos manejan este tema en particular.