Como miembro de un equipo o como programador, ¿aceptarías un jefe así? Si quiere aprender y le interesa programar y que hace un programador? ¿Puede alguien sin experiencia en programación entender rápidamente cómo funciona un entorno de TI?
Una cosa necesita ser aclarada aquí; el rol del PM NO es desarrollar ningún código . Un rol es el de programador, desarrollador, etc... así que contrataría a personas con las habilidades técnicas requeridas para hacer ese rol, y otro rol diferente es el de Gerente de Proyecto. Para este rol, contrataría a la persona con las capacidades más sólidas para liderar el proyecto (si él o ella tiene habilidades técnicas además de la experiencia en gestión de proyectos, entonces está bien, pero no es la competencia central en la que me concentraría)
El Gerente de Proyecto es la persona responsable de capturar los requisitos de los clientes, estimar, planificar y comunicar a los Miembros del Equipo, Partes Interesadas, etc.
Los buenos PM pueden manejar proyectos multidisciplinarios independientemente del campo/industria.
La clave para garantizar que tanto el PM como el equipo puedan trabajar juntos con éxito y entregar los resultados acordados es la COMUNICACIÓN.. Si usted, como programador, se encuentra con ciertos problemas con las infraestructuras, las pruebas o cualquier cosa relacionada con su área de especialización, necesita contar con el apoyo de respaldo de su PM. Él / ella necesita comprender su problema, estimar el impacto (con su ayuda, por supuesto) en el producto / resultado y comunicar retrasos o requisitos adicionales a las partes interesadas. Realmente no creo que necesite una persona que conozca diferentes lenguajes de programación para entender que por X razón no puede entregar y, por lo tanto, el proyecto puede retrasarse. Por otro lado, un gerente que entiende que tiene problemas y lo apoya al comunicarse de manera clara y efectiva con los clientes/patrocinadores y le brinda recursos/tiempo/fondos adicionales, creo que es más eficiente.
Mi recomendación es mantener la mente abierta y apoyar a su gerente. Una relación de trabajo sólida será más beneficiosa para usted durante el ciclo de vida del proyecto.
Soy un gerente de proyecto nuevo, que creció de desarrollador. Me di cuenta en mi empresa, que el conocimiento de los problemas técnicos realmente me ayuda a gestionar proyectos técnicos complejos. Me permite comprender mejor a los desarrolladores y, cuando trato con un cliente, puedo comprender mucho más los problemas técnicos y comerciales.
Noté que los PM en mi empresa, que no tienen ni siquiera un conocimiento técnico básico, tienen una situación más difícil con muchos problemas, porque simplemente no los entienden.
Si contrata o no a alguien que no tenga conocimientos técnicos depende de las características específicas del proyecto y de la competencia de esa persona en su empresa. Si él/ella no tendría que tomar decisiones que requieran tal conocimiento, o tendrá, por ejemplo, el gerente de producción, que podrá brindarle dicha información, entonces está bien. Pero personalmente creo que es mejor que la persona tenga al menos un conocimiento básico de la tecnología con la que tendrá que trabajar.
Contrataría a la persona que es inteligente y puede demostrar que puede hacer las cosas. Si tiene experiencia en TI, maravilloso.
Los PM no necesitan estar muy familiarizados con el entorno de TI para tener éxito. Ayuda pero no es crítico ya que la mayor parte del trabajo que hará no será de naturaleza técnica de todos modos.
En mi humilde opinión, tienes más problemas con los despistados que CREEN que lo saben.
La clave para tratar con PM no técnicos es tener un líder de equipo técnico sólido que actúe como puente entre el equipo y la gerencia. Si también te falta un buen líder de equipo, entonces las cosas pueden complicarse.
Preferiría un gerente de personas fuerte a un líder de programación brillante como mi jefe.
Alguien que lo tome a la ligera por el equipo, comprenda y resuelva los problemas de las personas.
En lo que respecta a los antecedentes de TI, en mi experiencia he visto a líderes/gerentes de proyectos no "técnicos" (que tienen las habilidades para entrevistar y obtener información de personas de tecnología y que crearon una cultura de confianza y valentía en el equipo) les va mucho mejor que los que tienen antecedentes "técnicos" de núcleo duro (que conducen puramente desde un aspecto técnico).
La clave es (como mencioné anteriormente) es la capacidad de "comprender" el lenguaje tecnológico y los egos de las personas tecnológicas, asegúrese de que no haya impedimentos en su camino :)
Para responder a la pregunta del titular: Absolutamente. Si la persona tiene las habilidades adecuadas, la aceptaría independientemente de su experiencia en programación o no.
Usted implica que un entorno de TI es igual a un entorno de programación. Ese es un tema secundario interesante: trabajo en un entorno de TI y siempre lo he hecho. En mi función actual, trabajo junto con una docena de PM de infraestructura y medio ambiente, y la mayoría de nosotros nunca hemos escrito código como programadores profesionales, y tampoco administramos programadores. Entregamos infraestructura, administramos pruebas y coordinamos implementaciones. Otros PM administran a los programadores.
También pregunta si un programador aceptaría a un no programador como jefe. Bueno, habiendo sido un no programador que manejó programadores en el pasado, debo decir que esto puede funcionar, pero ambos grupos deben aceptar que los conjuntos de habilidades y las bases de conocimiento son bastante diferentes, y tienen que superar lo inevitable. retos Esto puede traer beneficios para ambos: el PM a menudo puede ver soluciones no técnicas a un problema, mientras que el programador puede ofrecer mejores formas de lograr un resultado final que las que había propuesto el PM.
Su pregunta final también es interesante: si un PM sin experiencia en programación puede entender cómo funcionan los entornos de TI. Creo que la respuesta es sí, aunque puede llevar un poco de tiempo ponerse al día. No se debe requerir un conocimiento profundo y detallado, aunque una comprensión general es útil. Como PM que se ha movido de un negocio a otro y de un entorno técnico a otro varias veces, encuentro que la honestidad acerca de lo que sé o no sé es la mejor manera de progresar. Una de las preguntas más poderosas es "¿Puede explicar eso en un lenguaje fácil y sencillo?", lo que obliga a la persona técnica a pensar realmente en su respuesta y puede descubrir una gran cantidad de suposiciones o identificar cosas que se hacen "porque siempre hemos hecho de esa manera".
Tenga en cuenta que la gestión de proyectos no es una gestión funcional. El Project Manager debe conocer y estar familiarizado con los -tipos- de problemas y cuestiones que pueden surgir en un proyecto, pero no se espera que los resuelva. Más típicamente, el Gerente de Proyecto se beneficiará de más habilidades de "papeleo" y "interpersonales" que cualquier cosa relacionada con TI.
Como miembro del equipo en este entorno, si el PM está dispuesto a aprender, entonces podría ser una mejor situación, ya que el PM puede abordar las situaciones con una mente abierta y ser receptivo a los buenos comentarios del equipo, en lugar de tratar de usar su experiencia. y experiencia para "conducir" al equipo a un curso de acción.
Bueno, yo soy desarrollador y no aceptaría un jefe de proyecto que no fuera desarrollador al menos por un corto tiempo. Alguien sin esta experiencia no sabe cuáles son los problemas típicos de un desarrollador. No quiero que resuelva los problemas técnicos, pero creo que debería ser capaz de ver desde la perspectiva de sus desarrolladores para saber cuándo es necesario interferir y cuándo no.
Si su empresa tiene un estilo de gestión similar al tipo que recomienda Joel Spolsky , donde las decisiones técnicas las toman los técnicos de primera línea, entonces una persona que no sea de TI y que tenga buenas habilidades interpersonales debería funcionar bien.
Si su empresa tiene un estilo de gestión de comando y control o un lugar donde las decisiones técnicas se escalan "en la cadena", las posibilidades de que un gerente de proyecto no técnico sea aceptado por el equipo del proyecto y sea un líder efectivo es bastante baja.
Como gerente no técnico en una oficina llena de desarrolladores, puedo relacionarme con este tema por experiencia. Estoy de acuerdo en que: "La clave para tratar con PM no técnicos es tener un líder de equipo técnico fuerte que actúe como un puente entre el equipo y la gerencia. Si también falta un buen líder de equipo, entonces las cosas pueden complicarse". Sin embargo , mi trabajo requiere que investigue la industria misma en busca de tendencias y eventos actuales, mientras que esto a veces es "noticia" para los programadores que tienen un método preferido de codificación. Tienden a ser felices dentro de esos parámetros. No, no todos... pero siempre me sorprende cuántos no se molestan en mirar fuera de su rincón.
Cuando lo hacen, siempre es un placer porque ambos aprendemos algo.
No creo que haya una regla general porque hay PM buenos y malos, independientemente de la experiencia del desarrollador/TI.
He tenido excelentes PM que no han sido muy expertos en tecnología, pero sabían cómo escuchar y comunicarse. Un PM no es necesariamente alguien con quien te sientas y discutes problemas técnicos, sino que su función principal es actuar como administrador.
También he tenido PM mediocres que obviamente no pueden dejar atrás su pasado de desarrollador y ven una necesidad absoluta de microgestionar a los desarrolladores.
Así que no, no creo que sea necesario con experiencia en TI/desarrollador, pero es una ventaja si el PM es bueno.
En el PMBOK, en ninguna parte se menciona que un gerente de proyecto de un campo diferente no pueda administrar un proyecto en otro. Primero, debemos comprender los deberes de un gerente de proyecto y también debemos aprender a diferenciar entre el rol de un gerente funcional, un desarrollador y el gerente de proyecto. De lo contrario, no podemos obtener una solución adecuada de este debate. Una persona dijo que un gerente de proyecto de TI necesita ver el panorama general y eso es correcto. Pero nuevamente, creo que ese tipo solo está hablando de 1 estilo de gestión particular de los 5 estilos de gestión disponibles. El tipo estaba hablando de un estilo de gestión visionario, mientras que también tenemos disponibles estilos de gestión transformadores, democráticos, de tutoría y de Laissez-faire. En el estilo transformacional, el gerente empuja tanto al equipo como a sí mismo a salir de su zona de confort, lo que significa que hay una buena posibilidad de que el gerente de proyecto pueda obtener la experiencia técnica en paralelo a su trabajo, eso no es gran cosa si una persona es dedicada. Mi amigo también mencionó otros gerentes de proyectos con experiencia no técnica en su empresa que enfrentan problemas, pero mi pregunta es si se esfuerzan por desarrollar su experiencia técnica. También si hablamos de estilos de gestión democráticos y de Laissez-faire hablan más de empoderamiento del equipo para la toma de decisiones y la planificación. Entonces, en ese tipo de estilos, el equipo decidirá qué hacer y cómo hacerlo. Las funciones principales de un director de proyecto son la comunicación, la gestión de equipos, la gestión de conflictos, la gestión de recursos, la gestión de riesgos, la gestión de calidad, la planificación de proyectos, integración, elaboración de presupuestos, gestión del tiempo, gestión de horarios, gestión de costes. Debe tener buenas habilidades interpersonales, habilidades de comunicación, habilidades de negociación, habilidades para resolver problemas, adaptabilidad, habilidades de pensamiento crítico. De hecho, se menciona en la parte de scrum que la mejor práctica es que el maestro de scrum no codificará nada durante un scrum, solo actuará como un líder de servicio. PMP es un tipo de certificación que te enseña cómo hacer que un proyecto sea exitoso aplicando las mejores prácticas. En PMP nunca limitan tus habilidades de gestión de proyectos en ciertas habilidades técnicas. PMP te enseña cómo administrar cualquier tipo de proyecto con éxito y, al final del día, eso es importante. habilidad para resolver problemas, adaptabilidad, habilidades de pensamiento crítico. De hecho, se menciona en la parte de scrum que la mejor práctica es que el maestro de scrum no codificará nada durante un scrum, solo actuará como un líder de servicio. PMP es un tipo de certificación que te enseña cómo hacer que un proyecto sea exitoso aplicando las mejores prácticas. En PMP nunca limitan tus habilidades de gestión de proyectos en ciertas habilidades técnicas. PMP te enseña cómo administrar cualquier tipo de proyecto con éxito y, al final del día, eso es importante. habilidad para resolver problemas, adaptabilidad, habilidades de pensamiento crítico. De hecho, se menciona en la parte de scrum que la mejor práctica es que el maestro de scrum no codificará nada durante un scrum, solo actuará como un líder de servicio. PMP es un tipo de certificación que te enseña cómo hacer que un proyecto sea exitoso aplicando las mejores prácticas. En PMP nunca limitan tus habilidades de gestión de proyectos en ciertas habilidades técnicas. PMP te enseña cómo administrar cualquier tipo de proyecto con éxito y, al final del día, eso es importante. En PMP nunca limitan tus habilidades de gestión de proyectos en ciertas habilidades técnicas. PMP te enseña cómo administrar cualquier tipo de proyecto con éxito y, al final del día, eso es importante. En PMP nunca limitan tus habilidades de gestión de proyectos en ciertas habilidades técnicas. PMP te enseña cómo administrar cualquier tipo de proyecto con éxito y, al final del día, eso es importante.
También soy un profesional certificado PMP de PMI, EE. UU. Espero que no limitemos el alcance de un gerente de proyecto solo con límites técnicos, lo cual no es una buena práctica. Veamos la perspectiva más amplia, de lo contrario siempre hay posibilidad de microgestión.
andersk