¿Es más difícil pasar de la ingeniería de software a la gestión de productos o al revés? Cazar Trabajos es un oficio

Asumiendo que no tienes experiencia profesional en la disciplina opuesta, pasar de PM a Dev es más difícil. La razón principal es que ser un PM a tiempo completo no brinda muchas oportunidades para aprender cómo ser un desarrollador de software profesional exitoso, incluso si tiene capacitación académica como ingeniero de software.

Sin embargo, ser un desarrollador de software, especialmente un desarrollador senior o principal, les brinda a los desarrolladores muchas oportunidades para aprender y practicar las habilidades que necesitarán como PM. Ejemplos:

Tendrá que escribir especificaciones u otros artefactos escritos que otros seguirán. Incluso si se trata de especificaciones técnicas, deberá comunicarse con claridad, organizar sus pensamientos de forma lógica, etc.
Los desarrolladores principales deben aprender cómo administrar los horarios, identificar bloqueadores y cuellos de botella, mantener a sus equipos en movimiento a toda velocidad, etc. La mayor parte de este trabajo se transfiere exactamente a la parte de gestión de proyectos del trabajo de MP, excepto que tendrá diferentes recursos y dependencias (marketing, socios, etc.) además de solo desarrolladores.
Obviamente, necesitará aprender a trabajar con desarrolladores, ganar (¡y perder!) Argumentos con colegas con inclinaciones técnicas, y aprenderá a lograr que un equipo llegue a un consenso sobre un curso de acción técnico. Como PM, tendrás que hacer eso para, aunque se requiere más humildad porque te has mudado al Lado Oscuro. 😉
Deberá sopesar las compensaciones (p. Ej., Recursos vs. tiempo vs. calidad vs.…) y tomar decisiones difíciles sobre qué arreglar y cuándo. Lo mismo que un PM, excepto que en lugar de compensaciones entre algoritmos, estará gestionando compensaciones entre características, entre oportunidades de mercado, etc.
Como desarrollador senior en la mayoría de las empresas, tendrá oportunidades para interactuar con los clientes y aprender a utilizar esas interacciones de manera efectiva para tomar mejores decisiones. Tendrás práctica para traducir las cosas incrementales, a menudo contradictorias, que los usuarios piden en una dirección clara para tu equipo. Aprenderá a diferenciar entre necesidades y deseos, y comenzará a aprender cómo decepcionar gentilmente a los clientes, que no tienen idea de cómo se construye el software, sin ofenderlos.
Puede obtener experiencia presentando o hablando a audiencias grandes y pequeñas. Estas pueden ser presentaciones técnicas, pero las habilidades de presentación son muy similares en todos los temas.
Aprenderá a usar herramientas de seguimiento de problemas (por ejemplo, JIRA) que son tan importantes para los PM como los desarrolladores.

Otra forma de decir esto es que si quieres ser un PM y actualmente eres un desarrollador, puedes comenzar a hacer más y más cosas similares a PM hasta que seas esencialmente un PM sin el título del trabajo. Muchas compañías de software van un paso más allá: no hay personas cuyo título de trabajo sea “Gerente de producto”, pero si observan lo que hacen algunos “desarrolladores” todos los días, en otras compañías se les llamaría PM.

Es cierto que hay algunas cosas de PM que la mayoría de los desarrolladores nunca hacen, como escribir comunicados de prensa o ejecutar programas formales de comentarios de los clientes, como grupos focales o encuestas. Y no podrá construir powerpoints como un profesional o un regalo para audiencias no técnicas hasta que lo haga mucho. Pero esas son habilidades fáciles de aprender para las personas que tienen el interés y un temperamento similar al PM.

Pero hay una lista mucho más larga y crítica de cosas que los desarrolladores de software profesionales hacen que los PM nunca hacen. Y estas son cosas que rara vez se enseñan en los programas universitarios de CS, por lo que generalmente tiene que aprender en el trabajo. Aquí hay algunos ejemplos:

Aprender la diferencia entre la codificación que hiciste en la escuela (pequeñas tareas para resolver problemas claramente definidos) y la codificación que hacen los desarrolladores de software profesionales, que en su mayoría es un nuevo código en una base de código complicada y adoquinada a lo largo de los años. Analogía: el código que escribiste en la escuela es como construir una casa modelo a escala. La codificación que haces en el trabajo es como remodelar un baño con unos pocos destornilladores y un martillo roto.
Dominio de la memoria muscular con editores de código, depuradores y otras herramientas. ¡Tus habilidades de atajo de teclado de powerpoint no se transfieren!
Los procesos interpersonales que ayudan a los equipos a escribir código excelente, incluidas las revisiones de código, los estándares de codificación, etc. Los PM generalmente funcionan de manera más independiente: ¡no hay otro PM que te diga que tus puntos son incorrectos! 😉
Partes enteras del proceso de desarrollo de software apenas se mencionan en la escuela. Tendrá que aprenderlos, por ejemplo, sistemas de construcción a gran escala, automatización de pruebas, sistemas de control de fuente, creación de perfiles para detectar problemas de rendimiento, herramientas de generación de carga, etc. Como PM, puede tener dos o tres herramientas principales, por ejemplo, Photoshop, PowerPoint y JIRA. Como desarrollador, puede tener 10, y todos son más difíciles de aprender que Photoshop y cada 2–3 años son reemplazados por una nueva generación.
Aprender la atención fanática a los detalles que se requieren para construir un software sólido. El trabajo de PM es, en general, más indulgente. Como desarrollador, si rompes la compilación demasiadas veces, ¡estás despedido!

Entonces … si lo que realmente está preguntando es “No estoy seguro de si debería ser un PM o un desarrollador … qué sucede si tomo la decisión equivocada”, entonces recomendaría comenzar como desarrollador. Tener experiencia de desarrollador definitivamente te hará un mejor PM. Lo contrario no es necesariamente cierto.