¿Cuál debería ser el título de este puesto de PM?

• Gerente de Proyectos TI
• Gerente de proyectos ágiles
• Gerente de Proyectos de Software
• Gerente de entrega de software
• Gerente de programa de TI (si todos los proyectos están alineados con la misma visión)

El título del trabajo es en gran parte semántico. Los impulsores clave para el solicitante serán las responsabilidades, los indicadores clave de desempeño y el paquete de compensación.

Siempre puede realizar una prueba A/B de los títulos de trabajo y ver qué CV provienen de diferentes reclutadores.

Proporcione a la empresa de contratación A la descripción del trabajo bajo el encabezado Gerente de proyectos de TI y a la empresa de reclutamiento B la descripción del trabajo bajo el encabezado Gerente de entrega ágil. Luego compare y contraste las tasas de devolución y la calidad de los CV.

Esta es una buena pregunta que apunta a algo que puede dificultar que los equipos tengan éxito. Creo que la razón por la que el título de este puesto no está claro es porque la lista de Requisitos es una mezcla de responsabilidades y calificaciones que contiene menos detalles de los necesarios para definir completamente el rol. El resultado es que el empleado potencial, el reclutador e incluso los futuros miembros del equipo no comprenderán completamente cómo esta persona se integra al equipo.

Mi experiencia es que los equipos funcionan mejor cuando los roles están claramente definidos y la descripción del trabajo debe decir lo que esta persona debe hacer realmente para que los proyectos de desarrollo de software tengan éxito.

A continuación se identifica si cada Requisito de la lista parece ser una responsabilidad o una calificación, junto con algunas notas adicionales sobre lo que podría ayudar a aclarar la posición:

Responsabilidad: Administrar Proyectos Web, Base de Datos y Nube de varios Sistemas Empresariales

• ¿Gestionarlos cómo? ¿Administrar el cronograma, los recursos y el presupuesto que se inclina más hacia ser un Gerente de Proyecto o la operación diaria de los desarrolladores que se inclina más hacia ser un Líder Técnico? Sugiero enumerar las responsabilidades específicas abarcadas por el término "administrar".

Calificación: experiencia previa en software o PM basado en la web

• Este es el requisito más claro si buscas a alguien que aplique las mismas habilidades con la misma responsabilidad que tenía en este puesto anterior. Si esto es cierto, entonces creo que está buscando un Gerente de Proyecto.

Calificación: Experiencia previa en desarrollo ágil

• ¿Es esta experiencia como desarrollador, PM o alguna otra función? ¿Importa? Si no importa entonces la calificación es importante pero no nos dice cómo definir el nuevo rol.

Calificación: Experiencia previa en SDLC

• Como arriba con Agile Development Experience.

Responsabilidad: comunicación interfuncional (equipos técnicos/de desarrollo y operaciones)

• Este es un aspecto importante del rol, pero podría aplicarse a un BA, líder técnico, gerente de proyecto, etc. ¿Cuál es el alcance de la interacción de esta persona? ¿Transmitir requisitos, proporcionar informes de estado, características de negociación incluidas en una versión en particular? La respuesta a estas preguntas define el rol y el título apropiado para el puesto.

Calificación: Experiencia con Software Técnico

• Es posible que desee ser más específico acerca de lo que quiere decir con software técnico. Si es importante para usted que la experiencia sea en "los roles anteriores", entonces también podría decir eso.

Esto siempre es complicado, ya que se superpone nerviosamente en:

• Líder del equipo técnico (de desarrollo)
• Gerente de proyecto
• Gerente de Desarrollo de Software

Como tal, es probable que lo vea enumerado de todas las formas posibles en el mercado (siempre me molesta cuando veo las responsabilidades del líder del equipo técnico marcadas como un rol de PM).

Si no hubiera un componente de gestión de proyectos múltiples, diría que se alinea con el rol de Gerente de Desarrollo. Sin embargo, tan pronto como se involucra la gestión de proyectos real, y especialmente porque no hay responsabilidades de corte de código, es un rol de gestión de proyectos puro. Sin embargo, esperaría cierta gestión matricial con los equipos técnicos que tengan acceso y probablemente responsabilidades de gestión de línea cubiertas por un Gerente de desarrollo de software real, ya que serán los expertos en el dominio de la tecnología, no el PM.

Pero para la especificación de trabajo anterior, tiendo a inclinarme hacia el 'Gerente técnico de proyectos' para diferenciarme de un PM que maneja cambios comerciales y/o de procesos, ya que el PM de proyectos que contienen desarrollo y entrega de software significativo conlleva varios requisitos clave de habilidades y conocimientos. .

Me clasifico como Gerente Técnico de Proyectos y regularmente rechazo oportunidades para contratos de Gestión de Proyectos (o no se consideran) que no están relacionados con el software. Otra especialización que veo regularmente es 'Gerente de Proyectos de Infraestructura' donde las entregas de hardware e infraestructura forman una parte importante del proyecto.

TL;RD

Si bien estoy tentado a cerrar esta pregunta como una encuesta de opinión, creo que se puede reconfigurar para enfocarse adecuadamente en las funciones y responsabilidades de un puesto de gestión de proyectos. Esto también lleva a una respuesta muy simple:

1. Los títulos son una herramienta de comunicación, pero tienen poco significado intrínseco.
2. Lo que está solicitando es un Gerente Técnico de Proyectos .

Los "requisitos" del rol no son responsabilidades

Su problema fundamental es que no ha podido identificar claramente el alcance del rol, las responsabilidades del rol y los resultados del rol. El título de un trabajo nunca debe centrarse en las calificaciones, debe ser una forma abreviada de describir lo que se supone que debe lograr el rol .

En su larga lista de requisitos, en realidad ha enumerado solo dos responsabilidades reales:

1. Administre varios proyectos web, de base de datos y en la nube de Business Systems
2. Comunicación interfuncional (equipos técnicos/de desarrollo y operaciones)

Le está encargando a esta persona la gestión de una serie de proyectos técnicos y haciéndola responsable de las comunicaciones entre equipos. Debido a que le gustaría que esta persona tuviera conocimientos técnicos además de desempeñar las responsabilidades enumeradas anteriormente, Gerente de proyecto técnico parecería ser una descripción abreviada razonable que comunicaría claramente el alcance del rol.

Consulte a su equipo directivo y a su departamento de recursos humanos

Repartir títulos en el vacío suele ser una mala idea. Si su empresa históricamente ha llamado al rol descrito anteriormente "El asistente junior impotente a cargo de actualizaciones sin sentido", entonces también debería llamarlo así. El título debe transmitir el alcance dentro de una forma centrada en la empresa, así que no se desvíe de la reserva cuando invente nuevos títulos.

En segundo lugar, parece que realmente está tratando de escribir una descripción del trabajo o un anuncio de búsqueda de ayuda, en lugar de simplemente identificar el título correcto para el trabajo. Si ese es el caso, debe involucrar a los profesionales apropiados en su organización para que lo ayuden a:

1. Escriba una descripción del trabajo más clara, con un mejor enfoque en las funciones y responsabilidades en lugar de las habilidades o el historial laboral.
2. Identifique la empresa adecuada tal como la utiliza su empresa internamente.
3. Identifique un título de trabajo apropiado que atraiga al tipo de candidato que necesita.

Si bien la redacción de descripciones de puestos, anuncios de búsqueda y el proceso de contratación en sí están fuera del alcance de los temas aceptables en PMSE, la comprensión de cómo involucrar a los recursos correctos de la empresa para iniciar o dotar de personal a un proyecto ciertamente está dentro de los límites. En mi experiencia, cuando te enfocas en las responsabilidades principales de un trabajo, el título del trabajo se escribe solo.

Algunas organizaciones usan "ágil" sin comprender los conceptos o prácticas. Si su organización ha adoptado ágil o scrum, indíquelo sin ambigüedades, preferiblemente en el título del trabajo. Si no, no use la palabra de moda con la esperanza de que la contratación de miembros ágiles del equipo convierta milagrosamente a su organización. Los administradores de proyectos ágiles y los maestros de scrum son muy cautelosos y se molestarán a menos que comunique de manera convincente el compromiso de cambio de su organización. Algunos aceptarán el desafío pero esperan ser compensados ​​por el dolor adicional; realizarán cambios transformadores en su cultura organizacional que van mucho más allá de la tienda de software. Si no es ágil/scrum, haga que gerentes ágiles/maestros de scrum experimentados realicen la selección de currículums y las entrevistas. Esté atento a los aspirantes que ven esto como una forma de convertirse en ágil/scrum.

El requisito de "Comunicación interfuncional (equipos técnicos/de desarrollo y operaciones)" podría implicar para algunos que puede estar buscando experiencia en "devops". Al igual que ágil y scrum, devops es una palabra de moda que debe usarse con cuidado en un reclutamiento. Devops también es un cambio transformador en su cultura organizacional que a menudo es el resultado lógico de una organización de desarrollo ágil exitosa. Esté preparado para poder responder preguntas sobre si este PM implementará soluciones devops.