7 cosas que he aprendido en 3 años como consultor de Thoughtworks
Por
Publicado: September 12, 2019
Mi nombre es Geison Goes. Tengo 35 años, soy una persona con tetraplejia y trabajo como Consultor/a Senior en Thoughtworks. Actualmente, me desempeño como líder técnico/a en un equipo que contribuye en la entrega de una de las plataformas de distribución de contenido en video y OTT más grandes de Brasil.
Después de haber trabajado como Ingeniero/a de Software durante 10 años, la experiencia de traducir mi experiencia técnica como consultor/a ha sido muy enriquecedora y me gustaría compartir mis aprendizajes clave contigo.
Como consultor/a, debes encontrar formas de comunicarte de manera comprensible para personas no técnicas. Tomarse el tiempo para buscar términos comerciales comunes y utilizar plantillas visuales, pizarras y metáforas puede ayudar a simplificar conceptos técnicos y sus implicaciones. Del mismo modo, alentar a tus compañeros/as técnicos/as a adoptar estos términos comerciales puede generar empatía dentro del grupo de clientes.
Imagina que eres/a el/a líder técnico/a de un equipo y necesitas decidir qué tecnologías se usarán para el proyecto. Incluso si estás familiarizado/a con una tecnología en particular, la mejor opción es trabajar con tecnologías con las que la mayoría de tu equipo se sienta cómodo/a. Es importante tener en cuenta que la entrega no es el único lugar donde puedes tener un impacto: desarrollar a otros/as y aumentar el rendimiento del equipo, y tal vez incluso tu cuenta, son todas áreas para generar una influencia positiva.
Como líder/a, tienes una posición única para fortalecer a tu equipo ayudando a cada individuo/a a rendir mejor. Habla con cada compañero/a de equipo para comprender su pasado, intereses y objetivos con el fin de ayudarles a alcanzar su potencial. Conecta a tus colegas con oportunidades de desarrollo. Esto implica permitir que los/as compañeros/as de equipo asuman riesgos para que puedan aprender y crecer, pero también contribuir al equipo. Fomenta el intercambio de conocimientos dentro del grupo y encuentra formas de facilitar la conexión.
El cliente está impresionado/a, pero pregunta sobre un plazo estimado para completar el proyecto. Estimas que tomará aproximadamente seis meses, lo que preocupa al cliente. A medida que aumenta la tensión, tu/a colega comienza a hacer preguntas:
Colega: Habrá usuarios/as para este sistema fuera de Brasil?
Cliente: No.
Colega: Entonces, si eliminamos la funcionalidad de ubicación del usuario para acelerar el tiempo de entrega, ¿sería mejor?
Cliente: Sí.
Colega: ¿Y puedes determinar el porcentaje de usuarios de iOS frente a Android en función de los perfiles de los/as clientes?
Cliente: Sí, alrededor del 70% usa Android.
Colega: Ok, ¿entonces tendría sentido hacer una entrega inicial más rápida solo para Android?
Cliente: Definitivamente.
Al desarrollar la aplicación solo para Android y eliminar la funcionalidad de ubicación del usuario, se redujo a la mitad el tiempo de entrega, lo que hizo feliz al cliente y sentó las bases para una asociación duradera.
¿Puedes ver lo importante que es hacer las preguntas correctas?
Por ejemplo, al solicitar retroalimentación, evita el ejemplo a continuación:
"¿Te gustó la presentación que hice?"
Intenta cambiarlo a:
"¿Cómo puedo hacer más efectiva la presentación que di ayer?"
¿Ves cómo en el segundo ejemplo quitamos el enfoque de la persona y lo dirigimos a la presentación?
Lo mismo se puede hacer al brindar retroalimentación, compara el ejemplo a continuación:
"Tienes poco o incluso ningún pensamiento estratégico."
¡Qué brusco! Pero si lo cambiamos a:
"Me resulta un poco difícil entender tu plan. ¿Podemos tomar un momento para que presente mi comprensión y asegurarme de que estemos alineados/as?"
¿No es mucho mejor? Al final, siempre debemos buscar mejorar sin dañar a los demás.
Por ejemplo, la "arquitectura evolutiva" es una técnica para diseñar la arquitectura de software con el principio de admitir cambios incrementales en diversas dimensiones. Esta técnica se explica mejor en el libro Building Evolutionary Architectures escrito por Neal Ford, Rebecca Parsons y Pat Kua.
Otras técnicas como "programación extrema," "implementación continua" y "entrega continua"—que se ocupan de las prácticas de desarrollo de software, empaquetado y distribución, respectivamente—también son esenciales para tener la infraestructura y los procesos necesarios para hacer posible el cambio.
"La ética en el trabajo es presentarse, llegar a tiempo, ser confiable, hacer lo que dices que vas a hacer, ser digno de confianza, dedicar un día laboral justo, respetar el trabajo, respetar al cliente, respetar a la organización, respetar a los/as colegas, no perder el tiempo, no dificultar el trabajo de los demás, no crear trabajo innecesario para los/as demás, no ser un/a obstáculo, no fingir trabajo. La ética del trabajo es ser una persona fundamentalmente buena en la que los/as demás puedan confiar y disfrutar del trabajo."
Ten cuidado cuando digas "Haz lo que digo, no lo que hago." No importa lo que digas, la gente recordará más cómo actuaste. Tener una sólida ética laboral significa trabajar de manera constante y asegurarse de que tus acciones reflejen tus palabras. Actuar incongruentemente destruye la confianza. Decir "no" o "ahora no" es mejor que prometer hacer algo y no cumplirlo.
Si siempre haces lo que prometes, realmente te preocupas por ayudar a las personas y vives tus enseñanzas, tendrás la confianza de la gente.
Si mis consejos fueron útiles para ti o si estás buscando obtener más información sobre lo que he compartido, estaré encantado de conectarme contigo. No dudes en ponerse en contacto conmigo a través de mi cuenta de LinkedIn.
Después de haber trabajado como Ingeniero/a de Software durante 10 años, la experiencia de traducir mi experiencia técnica como consultor/a ha sido muy enriquecedora y me gustaría compartir mis aprendizajes clave contigo.
1. Traducir términos técnicos al lenguaje de negocios
Para ser un/a consultor/a efectivo/a, es necesario construir relaciones sólidas con personas fuera del equipo de desarrollo que a menudo formarán parte del equipo del cliente. Estas personas pueden ser Gerentes de Producto o ejecutivos/as de Marketing o Ventas. Debido a la naturaleza de estos roles, es importante recordar que los términos que utilizas en desarrollo no siempre resonarán con una audiencia más orientada a los negocios.Como consultor/a, debes encontrar formas de comunicarte de manera comprensible para personas no técnicas. Tomarse el tiempo para buscar términos comerciales comunes y utilizar plantillas visuales, pizarras y metáforas puede ayudar a simplificar conceptos técnicos y sus implicaciones. Del mismo modo, alentar a tus compañeros/as técnicos/as a adoptar estos términos comerciales puede generar empatía dentro del grupo de clientes.
2. El grupo siempre será más importante que el individuo
"Si quieres ir rápido, ve solo/a. Si quieres llegar lejos, ve acompañado/a" - un proverbio africanoImagina que eres/a el/a líder técnico/a de un equipo y necesitas decidir qué tecnologías se usarán para el proyecto. Incluso si estás familiarizado/a con una tecnología en particular, la mejor opción es trabajar con tecnologías con las que la mayoría de tu equipo se sienta cómodo/a. Es importante tener en cuenta que la entrega no es el único lugar donde puedes tener un impacto: desarrollar a otros/as y aumentar el rendimiento del equipo, y tal vez incluso tu cuenta, son todas áreas para generar una influencia positiva.
Como líder/a, tienes una posición única para fortalecer a tu equipo ayudando a cada individuo/a a rendir mejor. Habla con cada compañero/a de equipo para comprender su pasado, intereses y objetivos con el fin de ayudarles a alcanzar su potencial. Conecta a tus colegas con oportunidades de desarrollo. Esto implica permitir que los/as compañeros/as de equipo asuman riesgos para que puedan aprender y crecer, pero también contribuir al equipo. Fomenta el intercambio de conocimientos dentro del grupo y encuentra formas de facilitar la conexión.
3. Hacer las preguntas correctas > tener siempre las respuestas
Imagina que en una reunión con el cliente, te piden desarrollar una aplicación móvil que calcule la cotización del dólar. Basándote en tu amplia experiencia en desarrollo móvil, ofreces una solución que servirá tanto para plataformas iOS como Android y aprovechará la ubicación del usuario para realizar la cotización correcta para su país específico.El cliente está impresionado/a, pero pregunta sobre un plazo estimado para completar el proyecto. Estimas que tomará aproximadamente seis meses, lo que preocupa al cliente. A medida que aumenta la tensión, tu/a colega comienza a hacer preguntas:
Colega: Habrá usuarios/as para este sistema fuera de Brasil?
Cliente: No.
Colega: Entonces, si eliminamos la funcionalidad de ubicación del usuario para acelerar el tiempo de entrega, ¿sería mejor?
Cliente: Sí.
Colega: ¿Y puedes determinar el porcentaje de usuarios de iOS frente a Android en función de los perfiles de los/as clientes?
Cliente: Sí, alrededor del 70% usa Android.
Colega: Ok, ¿entonces tendría sentido hacer una entrega inicial más rápida solo para Android?
Cliente: Definitivamente.
Al desarrollar la aplicación solo para Android y eliminar la funcionalidad de ubicación del usuario, se redujo a la mitad el tiempo de entrega, lo que hizo feliz al cliente y sentó las bases para una asociación duradera.
¿Puedes ver lo importante que es hacer las preguntas correctas?
4. La retroalimentación es importante pero no debe ser personal
Todos/as tenemos puntos ciegos: cosas que hacemos de manera ineficaz pero no podemos percibir a menos que alguien nos las señale. Por eso es tan importante la retroalimentación. Buscar, recibir y brindar retroalimentación son esenciales para el crecimiento profesional, pero debemos tener cuidado de no tomar la retroalimentación de manera personal.Por ejemplo, al solicitar retroalimentación, evita el ejemplo a continuación:
"¿Te gustó la presentación que hice?"
Intenta cambiarlo a:
"¿Cómo puedo hacer más efectiva la presentación que di ayer?"
¿Ves cómo en el segundo ejemplo quitamos el enfoque de la persona y lo dirigimos a la presentación?
Lo mismo se puede hacer al brindar retroalimentación, compara el ejemplo a continuación:
"Tienes poco o incluso ningún pensamiento estratégico."
¡Qué brusco! Pero si lo cambiamos a:
"Me resulta un poco difícil entender tu plan. ¿Podemos tomar un momento para que presente mi comprensión y asegurarme de que estemos alineados/as?"
¿No es mucho mejor? Al final, siempre debemos buscar mejorar sin dañar a los demás.
5. Responder al cambio es más importante que tener un plan
Dado que el cambio es inevitable en un proyecto de software, ya no es posible seguir un enfoque de gestión tradicional que se centre en el seguimiento del alcance, el tiempo y las limitaciones de costos. Un enfoque más adecuado podría ser aprovechar la gestión ágil, que se centra en recibir y asimilar los cambios de la mejor manera, conscientes de que efectivamente ocurrirán. Para desarrollar software de manera ágil, es importante adoptar un nuevo proceso que permita al equipo asimilar fácilmente los cambios.Por ejemplo, la "arquitectura evolutiva" es una técnica para diseñar la arquitectura de software con el principio de admitir cambios incrementales en diversas dimensiones. Esta técnica se explica mejor en el libro Building Evolutionary Architectures escrito por Neal Ford, Rebecca Parsons y Pat Kua.
Otras técnicas como "programación extrema," "implementación continua" y "entrega continua"—que se ocupan de las prácticas de desarrollo de software, empaquetado y distribución, respectivamente—también son esenciales para tener la infraestructura y los procesos necesarios para hacer posible el cambio.
6. Ser crítico/a sin criticar
Criticar el producto o servicio de un/a cliente es como ir a una cena y decirle al anfitrión que su comida tiene mal sabor. Esta analogía ilustra cómo debemos actuar como consultores/as. Debemos recordar que estamos en la "casa" de nuestro/a cliente y, por lo tanto, debemos respetar sus deseos, escuchar y comprender sus problemas y adaptar nuestras formas de resolver problemas para satisfacer sus necesidades. Siempre trabajamos en soluciones juntos/as.7. La ética laboral es esencial para construir la confianza
Jason Fried, uno de los autores del libro Rework, tiene una descripción concisa y clara de lo que significa tener una ética laboral profesional:"La ética en el trabajo es presentarse, llegar a tiempo, ser confiable, hacer lo que dices que vas a hacer, ser digno de confianza, dedicar un día laboral justo, respetar el trabajo, respetar al cliente, respetar a la organización, respetar a los/as colegas, no perder el tiempo, no dificultar el trabajo de los demás, no crear trabajo innecesario para los/as demás, no ser un/a obstáculo, no fingir trabajo. La ética del trabajo es ser una persona fundamentalmente buena en la que los/as demás puedan confiar y disfrutar del trabajo."
Ten cuidado cuando digas "Haz lo que digo, no lo que hago." No importa lo que digas, la gente recordará más cómo actuaste. Tener una sólida ética laboral significa trabajar de manera constante y asegurarse de que tus acciones reflejen tus palabras. Actuar incongruentemente destruye la confianza. Decir "no" o "ahora no" es mejor que prometer hacer algo y no cumplirlo.
Si siempre haces lo que prometes, realmente te preocupas por ayudar a las personas y vives tus enseñanzas, tendrás la confianza de la gente.
En conclusión
Es importante señalar que estas son cosas que aprendí en el contexto de una consultoría de software en Brasil, a través de la perspectiva de una persona con discapacidad y con mucha experiencia en el mercado.Si mis consejos fueron útiles para ti o si estás buscando obtener más información sobre lo que he compartido, estaré encantado de conectarme contigo. No dudes en ponerse en contacto conmigo a través de mi cuenta de LinkedIn.
Aviso legal: Las declaraciones y opiniones expresadas en este artículo son las del autor/a o autores y no reflejan necesariamente las posiciones de Thoughtworks.