¿Qué es un Gerente Técnico de Proyectos?

¿Qué es un Gerente Técnico de Proyectos (TPM)? La respuesta depende de a quién le pregunte, dice Andi Blackwell, un veterano consultor de TI y experto en operaciones comerciales. Como Director Principal de Gestión de Proyectos y Productos de Toptal, Blackwell encabeza el equipo responsable de vincular a los gerentes de proyectos altamente calificados en la red independiente de Toptal con organizaciones que buscan los mejores talentos para iniciativas específicas. En los últimos años, ha visto un aumento en la demanda de TPM.

“Definitivamente existe cierto debate en la industria de la tecnología sobre lo que realmente significa ese término”, dice Blackwell. “Hay muchas personas que se hacen llamar Technical Project Managers porque han trabajado muy de cerca con un equipo de ingeniería o han liderado un equipo técnico desde la perspectiva de la gestión de proyectos, pero eso no es lo que estamos buscando”.

La definición de Toptal es más específica. Todos los gerentes de proyecto en la red de Toptal son expertos en las habilidades tradicionales de gestión de proyectos, como la determinación del alcance, la elaboración de presupuestos y la gestión de cronogramas, así como en las prácticas ágiles de desarrollo de software relacionadas con la entrega iterativa y la mejora continua. Invariablemente, han trabajado en estrecha colaboración con los ingenieros y, si se les solicita, podrían entrenar y guiar a un equipo Scrum.

Sin embargo, para calificar como TPM, deben tener una capa adicional de experiencia más allá de la gestión de procesos ágiles y la colaboración con desarrolladores: deben haber sido desarrolladores ellos mismos.

Una combinación preciada

Las organizaciones grandes y pequeñas están cada vez más interesadas en esta combinación particular de habilidades. “La mayoría de las nuevas empresas no pueden contratar a una persona que solo puede hacer una cosa”, dice Blackwell, y las empresas más grandes quieren ver “desarrollador” o “arquitecto” en el perfil de un candidato si están contratando para un proyecto de ingeniería.

Incluso en los casos en los que un cliente no requiere específicamente un gerente de proyecto con experiencia técnica, tener marcada la casilla "desarrollador" es un punto de venta importante. ¿Alguien que pueda planificar y ejecutar un proyecto de software, implementar y optimizar procesos ágiles y codificar? Eso es una gran ayuda.

En realidad, sin embargo, no se espera que los TPM codifiquen, muchos no lo han hecho en años. ¿Por qué, entonces, la necesidad de experiencia en programación?

Los TPM son necesarios para tomar decisiones técnicas, dice Blackwell: "Si no tiene al menos una experiencia práctica relativamente reciente con una pila de tecnología moderna, SDK (kit de desarrollo de software), arquitectura o plataforma de automatización de pruebas, entonces usted ' potencialmente no va a tomar las decisiones correctas. No vas a tener credibilidad con el cliente porque no has usado esas cosas antes”.

Trabajar con equipos

Demostrar credibilidad a un posible cliente es un factor importante para asegurar compromisos, pero es solo el primer obstáculo. Una vez asignado a un proyecto, un TPM debe ganarse rápidamente la confianza y el respeto de un equipo técnico.

Michael Poythress comenzó a programar cuando era adolescente. A los 16, creó un sitio web comercial para un negocio de publicidad de bienes raíces que comenzó con su padre. Ha sido el CEO y fundador de múltiples startups desde entonces. En 2018, se unió a la red de Toptal como TPM y ahora trabaja en estrecha colaboración con los equipos de ingeniería. “Si no tuviera experiencia con la codificación, los programadores se darían cuenta”, dice. “No dispararían directamente conmigo. Pero si los desafío y les hablo como a un compañero, hay respeto y una buena relación”.

Y es la experiencia tecnológica lo que cuenta más que el título, dice Allen Takatsuka, TPM de Toptal con sede en Orange County, California: “Por lo que he visto, la 'T' en TPM realmente no tiene ningún peso para los ingenieros. Piensan que es solo otro gerente de proyecto que organizará sus reuniones y les pedirá que completen hojas de cálculo”.

Sin embargo, una vez que se establece un terreno común, “el sabor de la interacción es muy diferente. Es más una asociación con la ingeniería”, dice.

Takatsuka pasó décadas liderando equipos de ingeniería al principio de su vida profesional. Acredita esa experiencia por haber mejorado sus habilidades blandas. “Es una habilidad de empatía un poco diferente”, dice. “Tienes que demostrar que puedes hablar el idioma. Puede decir: 'Veo por qué tiene estos desafíos en función de las cosas técnicas que están sucediendo'".

Dan Allen, un consultor de tecnología de Vienna, Virginia, describe la progresión de su carrera como "programador del tipo en el cubículo a líder técnico a arquitecto, director, VP, CTO, CIO". Desde que se unió a la red de Toptal como TPM en 2019, ha estado ocupado y ha trabajado en 14 interacciones con clientes.

“Raramente leo código. Casi nunca escribo código”, dice. “Pero ha habido situaciones en las que un desarrollador se atasca. Pueden guiarme a través de la arquitectura y puedo ver exactamente lo que están tratando de hacer y la lógica”.

Considera que la dinámica es útil no solo en casos extremos, sino de manera más amplia. “Tu equipo sabe que pueden acudir a ti y hablar, y realmente entiendes lo que dicen”, dice. “Puede ayudarlos a considerar todas las complejidades en caso de que se hayan perdido algo. Puede ser una caja de resonancia y proporcionar retroalimentación”.

El efecto multiplicador

Ese tipo de retroalimentación y conocimiento es importante para algo más que la construcción de relaciones. Los TPM ofrecen una propuesta de valor diferente a una organización. Sirven menos como conductos de información y más como fuentes de conocimiento. Sí, planifican, coordinan y comunican, pero también ayudan a los clientes y equipos a trabajar en decisiones tecnológicas complejas.

“Tienes la capacidad de ser técnicamente obstinado”, dice Takatsuka. “Y eso agrega valor a la organización porque ahora tienes más un efecto multiplicador, en lugar de solo organizar y colaborar”.

Takatsuka señala que los TPM tienen que pasar por menos obstáculos para resolver problemas. Especialmente en organizaciones más grandes, un programa no técnico o gerente de proyecto podría abordar un desafío técnico identificando a los actores y partes interesadas relevantes, ofreciendo contexto, agregando información y luego analizando los resultados para tomar una decisión. Los TPM pueden aportar su propio conocimiento.

“Puede abordar los riesgos de manera mucho más eficiente”, dice Oana Ciherean, TPM con sede en Tokio. “Y esos riesgos pueden provenir de muchos lugares. Pueden provenir de estimaciones incorrectas del equipo. Entonces puede decir: 'Está bien, estoy seguro de que este código no va a tardar una semana en escribirse' porque en realidad son dos días. Entonces puedes desbloquear personas. Porque te has dado cuenta de que están atascados y por eso les está tomando cinco días. Lo sabes porque has estado allí y tú mismo te has quedado atascado”.

Encontrar el equilibrio

Ciherean comenzó su carrera como desarrolladora, pero pronto pasó a la gestión de proyectos por el deseo de involucrarse en el panorama general. En esos roles, sin embargo, descubrió que extrañaba la codificación. Ella dice que la gestión técnica de proyectos ofrece lo mejor de ambos mundos: "Me permite ser realmente práctico en tecnología pero también de alto nivel para comprender el negocio y los clientes y lo que quieren en características".

Poythress también siente que ha encontrado su punto ideal. “Soy un traductor o un enlace entre los visionarios que tienen una idea y el talento técnico que sabe cómo construirla y hacerla realidad”, dice. “Hablo los dos idiomas con fluidez. Hablo 'persona normal' y hablo 'técnico-ese'”.

El mini CTO

Los TPM que trabajan para nuevas empresas y pequeñas empresas ocupan un lugar especialmente privilegiado en la intersección de los negocios y la tecnología. En estos compromisos, un TPM suele ser el primer empleado en incorporarse al comienzo de un proyecto. Luego, él o ella es responsable de evaluar la viabilidad del producto, definir el alcance técnico y los requisitos, y ayudar al cliente (a veces un solo fundador con una idea inicial) a seleccionar una pila tecnológica, evaluar a los proveedores para la prestación del servicio, implementar las mejores prácticas de DevOps, y armar el equipo correcto.

Takatsuka piensa en estos compromisos como roles de "mini CTO", en los que el TPM une los ámbitos comercial y técnico para hacer que las cosas despeguen. Algunos clientes no saben casi nada sobre el desarrollo de software, dice: “¿Cómo establezco una tienda? He leído sobre Agile. ¿Cómo puedo hacer eso?"

Poythress ve los dos roles como superpuestos, incluso indistinguibles entre sí en ciertos casos. “Hay mucha polinización cruzada”, dice. “Un CTO para una organización más pequeña podría pasar fácilmente a un rol de PM técnico superior en una organización más grande y sentirse como en casa”.

Habilitación de la agilidad

Si bien la mecánica de Agile está en la timonera de prácticamente cualquier gerente de proyecto con experiencia en desarrollo de software, alguien con aptitudes técnicas puede aportar una perspectiva más matizada a la gestión de procesos.

Ciherean encuentra que las metodologías ágiles nunca se implementan estrictamente en el libro; deben personalizarse, combinarse y adaptarse a las necesidades específicas de un equipo y proyecto.

“Debe asegurarse de que lo que está diseñando como proceso no interfiere con el trabajo de los desarrolladores y, de hecho, lo hace más eficiente o productivo”, dice. “A veces, eso significa profundizar en el flujo de trabajo de GitHub, por ejemplo, para ver cómo hacen sus compromisos, ver cómo crean ramas para su código y ver si su proceso se ajusta a su flujo de trabajo. Y luego corrige su proceso o corrige su flujo de trabajo”.

La experiencia de un TPM también puede informar prácticas y artefactos ágiles específicos, como la acumulación de productos y las estimaciones de tamaño relativo.

“Si comprende la técnica, conoce la complejidad aproximada de las cosas en un trabajo pendiente”, dice Takatsuka. “De lo contrario, todo lo que tienes es esta lista y sería difícil para ti saber si el número uno es una camiseta talla grande en comparación con el número dos. Es posible que tengas la idea de que uno es más difícil, pero realmente no sabes qué hay detrás de escena. Un TPM "extremo", dice, "podría dimensionar las cosas por sí mismo, con la advertencia de que cuando el equipo suba a bordo, tendrán su propia velocidad".

Poythress usa su comprensión de la estimación del tamaño como un indicador para evaluar los líderes tecnológicos y los ingenieros que considera para un proyecto. Si espera que algo sea una tarea pequeña pero alguien más lo considera gigante, eso es una señal de alerta: “Los escucharé para ver si hay complejidades que no conozco, pero si eso no se sostiene, Estoy como, 'Está bien, bueno, eso no encaja bien'. Necesitamos a alguien que entienda esto muy bien y que no se sienta intimidado por lo que debería ser una característica simple”.

Los TPM también ayudan a educar a los clientes sobre los requisitos no funcionales. ¿Cómo lidias con la alta disponibilidad? ¿Cómo lidiar con la recuperación ante desastres? “Sin la comprensión técnica, no sé cómo tienes esa discusión”, dice Takatsuka. “Probablemente se detenga en el nivel de requisitos de Scrum y dé por terminado el día hasta que llegue el personal técnico. Bueno, entonces tienes este enorme abismo”.

Mantenerse actualizado

Aunque su tiempo en un teclado juega un papel fundamental en lo que hacen hoy, los TPM no pueden depender de la experiencia pasada para seguir siendo relevantes. Dada la velocidad a la que la tecnología cambia y se desarrolla, es fácil quedarse atrás.

Poythress aprendió esto de la manera más difícil, durante una ventana de cinco años antes de unirse a Toptal, cuando se centró exclusivamente en dirigir su propia empresa. “Definitivamente me estanqué”, dice. "Llegaron muchos idiomas diferentes y resolvieron problemas en ese período de tiempo de los que no sabía nada porque teníamos nuestra pila tecnológica y eso era todo lo que necesitábamos".

Hoy pasa hasta el 10 por ciento de su tiempo leyendo documentación, mirando YouTube y haciendo sandboxing “para aprender sobre las últimas y mejores cosas”.

“Casi siempre estoy incursionando en un nuevo idioma o tecnología, solo para mantenerme alerta”, dice. “Porque si no lo hago, la industria seguirá adelante. Me ha pasado eso antes. Y es mucho más difícil abarrotar que mantenerse al día”.

Takatsuka también es proactivo a la hora de llenar sus lagunas de conocimiento: “Google es excelente en estos días. YouTube es increíble. Tienes que hacer tu tarea. Pero ese trabajo se basa en sí mismo”.

También cuenta con una amplia red de colegas consultores para el apoyo y el intercambio de conocimientos. “He estado en situaciones en las que el cliente quiere usar Google, pero conozco mejor la plataforma de AWS”, dice. “Puedo llamar a mis amigos y decirles: 'Oye, vamos a usar Firebase. ¿Has tenido algún cliente que haga esto? ¿Qué pasa con la escalabilidad?'”

Incluso después de más de 30 años en el negocio y múltiples roles de nivel ejecutivo, Dan Allen no tiene miedo de ensuciarse las manos. En los últimos tres años, aprendió por sí mismo a implementar en Amazon y Google Cloud sin ayuda de nadie. “Lo hice para poder entenderlo y ayudar a un cliente de Toptal”, dice. “No tenían un equipo de tecnología. Todo lo que tenían era a mí. Así que fui a la Universidad de YouTube y lo logré”.

Mucho ha cambiado desde que Allen comenzó como desarrollador en 1985. Pero disfruta los desafíos que surgen con cada nueva oportunidad. “Eso es parte de lo que me encanta del trabajo”, dice. “Siempre hay algo que no has hecho, algo nuevo. Y siempre te vas con una pluma adicional en tu gorra que puedes aprovechar en el próximo compromiso”.