Bajo las antiguas metodologías, el conocer un lenguaje, o haber desarrollado alguna vez en tu vida, servía de herramienta para poder estimar junto al equipo, para que la planificación fuera certera (o al menos lo intentara ser), pero principalmente, para que no pudieran "engrupirte" fácilmente.
¿Pero qué pasa, cuando estás trabajando con un equipo nuevo, con un nuevo lenguaje o arquitectura que no dominas y debes liderar un proyecto?
Dos opciones:
- Cierras los ojos... y diriges el proyecto, sin la visión clara de las herramientas que tienes, para llegar al objetivo, o
- Te reinventas y vuelves a aprender.
Está claro que la segunda opción no es la más fácil. Pero cuando quieres aportar y realmente quieres entender las limitaciones o virtudes de un lenguaje/arquitectura, ¿no es mejor saber?
Cuando desarrollaba, me esforzaba por hacerlo bien. Tenía compañeros mucho más talentosos, pero siempre me empeciné en mejorar. Incluso recuerdo, las entretenidas competencias que haciamos con mi jefe (quien amaba y aún ama con toda su alma programar ) para ver quien lograba "botar" la aplicación del otro. Haciamos control de calidad cruzado y como ambos desarrollábamos, sabiamos qué exactamente un usuario común y silvestre no haría y aplícabamos lo que cualquier desarrollador motivado por la competencia haría: ocupábamos las combinaciones de teclas rebuscadas, condiciones de borde y cualquier artimaña que permitiese ganar.
Ahora que lidero proyectos, ¿por qué no iba a aplicar el mismo espíritu?
Una vez que comienzas a aprender, todo cambia. Entiendes los problemas a los que se enfrenta tu equipo, entiendes qué no es posible hacer; que es tanto o más poderoso que saber lo que si se puede hacer. Puedes aportar valor, no sólo realizando el trabajo de negociación con el cliente, que es parte de tu trabajo, sino que también aportas tu visión de los problemas y soluciones. Entiendes de qué se habla, frenas al cliente cuando se arranca con deseos no realizables. Haces mejor tu trabajo.
Tu compromiso e interés por aprender hará que mejores como profesional, no precisamente porque vayas a aportar con líneas de código, si no que con ello demuestras interés y respeto por el trabajo de tu equipo. Te hace parte. No que te vean, ni los hagas sentir como en las empresas convencionales, donde los jefe de proyecto están en un pedestal y los desarrolladores "bajo" ellos.
Lamentablemente aún en muchos lugares a los desarrolladores se les dice que para crecer profesionalmente, deben ser Jefes de proyecto. ¿Pero que pasa, si realmente aman desarrollar? Deberían poder optar a crecer en esa dirección y que se les valore por ello, no por intentar ser algo que no quieren. Pastelero a tus pasteles. Que tu talento y pasión guien tu camino profesional.
A mi me gusta liderar proyectos, armar equipos de trabajo, descubrir y orientar el talento de nuevos profesionales. No me interesa tener un cargo rimbombante. Y no es por falta de aspiración, es porque ésto es lo que me hace feliz.
Mi primer jefe, se ganó el respeto y admiración de su equipo, no porque hablara más alto ni por su cargo de "gerente de desarrollo", sino porque él, sabía. Entendía la implicancia de un desarrollo u otro, él era uno más del equipo. Con él podías hablar y él entendía de lo que hablabas.
Por ello, creo firmemente que un líder de proyectos, debe:
- Mostrar respeto por el trabajo de su equipo
- Aprender de sus errores
- Aprender con su equipo
- Conocer a los miembros de su equipo, interesarse realmente por ellos, preocuparse.
Pero también, ser firme cuando se requiera y un compañero cuando sea necesario.
Y sobre todo, debe estar dispuesto a ayudar a sacar adelante el proyecto, haciendo lo que se deba hacer.
Tengo la suerte de estar en un lugar donde hay excelentes desarrolladores, de los cuales puedo aprender día a día. Gente dispuesta a invertir su tiempo libre codificando, porque ama lo que hace. Y yo estoy allí, donde día a día, puedo aprender de y con ellos. Puedo ser mejor.
