A menudo imparto formación sobre gestión de proyectos. Los perfiles que me encuentro en estos cursos son de lo más variado: programadores que quieren ampliar sus conocimientos, gestores de proyectos que llevan años gestionando proyectos pero que nunca han recibido formación sobre gestión de proyectos informáticos, analistas que pronto abordaran su primer proyecto como jefes de proyecto, gestores y comerciales que quieren entender lo que ocurre en los proyectos en los que participan.
Una cuestión que a menudo surge es ¿Debe ser el jefe de proyecto un gestor o un técnico? Es una pregunta que siempre se presta a la polémica, y si la traigo a este blog es precisamente por eso, porque quiero saber que opina la gente. Evidentemente si voy a pedir una opinión, antes voy a empezar dando la mía. Sin duda la respuesta correcta a esta pregunta debe abordar que aspecto de los dos debe dominar, pues todo jefe de proyecto debe aunar las dos facetas, ¿pero cual debe primar? .
Lo primero que quiero es comentar qué es lo que yo entiendo por jefe de proyecto. Esto es importante, porque bajo esta denominación podemos encontrar un montón perfiles diferentes. Para mí, el jefe de proyecto, es la persona encargada del día a día del proyecto, alguien completamente involucrado en el mismo, que se encarga de construir el entorno que permita al equipo de desarrollo trabajar de manera productiva y saludable y que es quien establece las pautas generales que guían el proceso de desarrollo.
Bueno y ahora viene cuando me mojo… YO prefiero un jefe de proyecto técnico. Es en mi opinión evidente que los proyectos necesitan de un líder técnico, que sea este el jefe de proyecto es para mi una situación optima. Los desarrolladores tendemos a valorar más las dotes técnicas que las relacionadas con la gestión y guiar un grupo humano es muchas veces una cuestión de respeto. Los desarrolladores tendemos a respetar a los líderes técnicos del proyecto y a ver como simples entes ‘políticos’ a los gestores. Es mucho más fácil que los desarrolladores nos valoren como jefes de proyecto si somos capaces de guiarles con garantías cuando tienen problemas técnicos.
Esto no quiere decir que no sean importantes los aspectos relacionados con la gestión, pero creo que la credibilidad que ganamos a ojos de los desarrolladores cuando somos buenos técnicos, nos facilita mucho las labores de gestión que muchas veces los desarrolladores comprenden menos. La idea subyacente es: el crédito que ganas por ser un buen técnico, lo puedes administrar para tomar decisiones de gestión, a menudo menos visibles y más difícilmente entendibles para los desarrolladores.
Otro problema con los jefes de proyecto no técnicos es su tendencia a tomar decisiones técnicas en el proyecto. No es fácil que alguien en un entorno técnico y siendo ‘el jefe’ asuma que no tienen el conocimiento necesario para tomar decisiones técnicas. Es lo que yo llama Antipatrón Jefe de Proyecto de Café Tecnológico, que toma sus decisiones en base a artículos técnicos, case studies y cafés tecnológicos y no en base a un profundo conocimiento de las tecnologías involucradas. Esta viñeta de Dilbert describe la situación a la perfección…
En mi opinión los jefes de proyecto no técnicos solo pueden triunfar si son capaces de identificar un buen líder técnico para el proyecto, dejar que todas las decisiones técnicas del proyecto las tome este, y centrarse en la labor de eliminar impedimentos, al estilo del ScrumMaster en Scrum. Eliminar impedimentos no es un trabajo menor, es algo de suma importancia. Ya lo dicen en Peopleware «el trabajo el jefe de proyecto no es hacer que la gente trabaje, sino construir el entorno que haga posible que la gente trabaje» y una manera excelente de hacer es eliminar los impedimentos y los problemas que el equipo de desarrollo encuentra, analizando su origen y asegurándose que se eliminan sus causas para evitar que se repitan.
No deja de ser sorpendente que según una encuesta de la Universidad de Carolina el 49% de los jefes de proyecto consultados admite que no tiene formación ni conocimientos técnicos. ¿Dejaríamos que alguien que no sabe nada de los aspectos técnicos dirijiese la construcción de un oleoducto, un coche, una batidora…?.
Seria sumamente interesante saber que relación hay entre motivación de los desarrolladores (principal factor de productividad en todo proyecto) y el tipo de jefe de proyecto.
¿Qué opinaís vosotros?
Pero aún, ¿Dejarimos que alguien que no sabe nada de los aspectos técnicos dirijiese nuestro transpante de hígado?.
Lo que está claro, que al final en todo proyecto es muy importante que haya una persona técnica, preparada, que sirva de guía a los demás miembros del equipo y que pueda tomar una serie de decisiones técnicas sobre por dónde debe de ir en el equipo; un lider, alguien a la que gente siga.
Esta persona creo que lo más conveniente es que sea el jefe de proyecto, salvo igual en proyectos grandes donde hay una labor muy alta de gestión y pueda ser muy útil que convivan los dos roles, el gestor y el técnico, pero cada uno es su «parcela».
Aún así, en mi opinión, todo persona con un puesto de responsabilidad en un proyecto, ya sea en la parcela de gestión, en la técnica o en ambas…debería haber pasado alguna vez por las «galeras» y saber lo que es desarrollar y cómo van tb las cosas por ese mundo… No sé si me estoy explicando, pero lo que quiero decir es que no veo que pueda haber gente que sea jefe de proyecto y no entienda nada de cómo se está haciendo y que simplemente sea un gestor, un gestor de algo que no entiende?? Espero haberme explicado..
Sobre la encuesta que comentas, tb tendría en cuenta que el término jefe de proyecto se aplica de muchas maneras y muchos no se ciñen a la definión que tu comentas, la de llevar el día a día del proyectos.
Otro tema es la cultura empresarial que veo. Los desarrolladores valoran mucho el tema técnica, más bien sólo valoran eso, pero en cambio desde otros esferas se valora el tema gestión, no dándole importancia al tema técnica, incluso considerándono poco importante ( Te podría contar alguna experiencia personal.. ). Al final volvemos a temas recurrentes, que es que hay que tiene que cambiar mucho de la cultura empresarial.
Y por último, tb tendría quiero mencionar que cualquier técnica no vale para jefe de proyecto. Un jefe de proyecto le veo que tiene que ser un buen técnico, pero un buen técnico no tiene por qué ser un buen jefe de proyecto.
Ibon.
MMmm pero un jefe de proyecto 100% técnico no creo que sea lo ideal. Porque, quien gestiona? el mismo, pero quizas no lo haga del todo bien.
Es cierto que es necesario un Lider Técnico, entonces creo que pueden convivir el Lider Técnico con el Gestor. El Gestor nunca tomaría decisiones técnicas y el Lider Técnico no debería estresarse con aspectos que estén más allá del proyecto.
Siempre voy a recordar una charla mía (Lider Técnico [LT]) con el jefe de proyecto (100% gestor [G])
LT: «.. y es por esto que aqui lleno un DataSet..»
G: «Noooo un DataSet noooo!!!»
LT: «Porque no? pero.. eh.. sabes que es un DataSet?»
G: «mmm algo.. a ver explicamelo porque lei por ahi que no era nada bueno..»
Resumen: prefiero un Jefe de Proyecto Técnico.
Bueno, un jefe de proyecto técnico es lo ideal…si el proyecto no es para una empresa puramente comercial, bancaria, etc. Quiero decir que en las empresas cuyo negocio no tiene nada que ver con la tecnología, los grandes proyectos tienen una componente política muy fuerte, y en este caso el negocio sólo va a confiar en uno de los suyos. Lo ideal es un buen Jefe Técnico con un buen gestor, que confie en el Jefe Técnico y le apoye ante la empresa, y viceversa, que el gestor se vea respaldado ante el equipo técnico. Parece difícil, pero ocurre muchas vece, cuando hay buena sintonía entre jefe Técnico y gestor. Cuando es así, todo va suave. Si no, el proyecto es un infierno
¡Que guay que saques aquí este temita que tú y yo hemos hablado por encima en alguna ocasión!.
Voy a recordar a un jefe que tuve (que no se si leerá este blog, pero le molaría por las cosas que se cuentan) y que no había estudiado una carrera de informática. Esta persona para mí, ha sido uno de los mejores jefes de proyecto que he visto y que he tenido, porque no siendo puramente informático, se ha inquietado siempre por los aspectos técnicos.
¿Que dos aspectos resumo de esta persona?. Su valor de gestión era incomiable, y a su lado aprendí muchísimo, pero luego, técnicamente era una persona buenísima e inquieta, siempre quería aprender… así que digamos que era gestor por el puesto que ocupaba pero muy técnico, de manera tal que los problemas que surgían en el proyecto, eran entendidos perfectamente y se solucionaban más rápidamente.
Sin embargo, estoy completamente de acuerdo con el comentario de Ibon, de hecho siempre lo digo yo también aunque de otra forma… un poco más soez, y es que como digo yo, para saber a que sabe o huele la mierda, primero hemos tenido que comérnosla o trabajar cerca de ella. Es un poco duro dicho así, pero es la forma de decir lo mismo que Ibon, es decir, que primero creo que se debe pasar por el esalafón más bajo (galeras) para ir poco a poco progresando, y de esa manera, el gestor (el que ha llegado ahí), ha pasado por la parte técnica, pero aún y así, creo que el gestor, además de ser técnico, debe reunir las cualidades suficientes de la inquietud por la parte técnica, porque la evolución de la parte técnica es constante, y esa evolución debe ser un compromiso del gestor/técnico, por lo que yo veo esta tercer pata en el comentario de Rodrigo, que es la inquietud por la tecnología. 🙂
Así que resumiendo lo dicho hasta ahora y lo que comento, yo veo que el gestor debe ser técnico, debe haber llegado ahí pasando por todos los eslafones posibles (desde las galeras), y debe tener pasión e inquietud por las tecnologías.
Creo sinceramente que un jefe de proyecto debiera ser ante todo tecnico, por que sabe que terreno pisa, y mas importante, sabe que terreno pisan sus desarrolladores.
Pero sobretodo, lo mas importante es la labor psicológica que debe realizar esa persona, es la parte posiblemente mas importante de todo el proyecto. Hacer un grupo de trabajo estable, un entorno no hostil, donde la gente sea colaborativa. El es la imagen de apoyo, la supuesta persona que sabe por donde debe salir cuando el proyecto esta trabado (aunque no este seguro de lo que dice, pero que de esa imagen de que si sabe lo que acaba de decir jeje)
A fin de cuentas, un jefe de proyecto debe ser compañero, gran repositorio de soluciones, el gestor de los tiempos de trabajo, y el psicologo tecnico del entorno de trabajo.
Un saludo. Carlos.
Creo que un jefe de proyecto como ya se ha comentado debe haberse formado en las galeras. Yo realmente no concibo un jefe de proyecto en tecnologías de la información que no tenga un perfil técnico. Es la mejor forma de conocer la problemática real de los desarrolladores.
Pero dicho ésto, comentar que un jefe de proyecto con sólo pérfil técnico no es suficiente. Como has mencionado Rodrigo, la verdadera labor del jefe de proyecto es: «el trabajo el jefe de proyecto no es hacer que la gente trabaje, sino construir el entorno que haga posible que la gente trabaje». Y para ello hacen falta algunas dotes de liderazgo para dirigir eficazmente al grupo. Y cuando «dirigir», no digo «mandar», sino tomar en algún momento las decisiones oportunas, y sobre todo saber hacer motivar en cada momento al grupo. Lo bueno es que con formación, una persona originalmente técnica puede llegar a aprender cuestiones puramente de gestión.
En resumen, me inclino hacia un jefe de proyecto eminentemente técnico, pero con formación en dotes de gestión de grupos.
Yo tras haber pasado por manos de varios de los dos estilos (técnicos y no técnicos) cláramente me decanto por un jefe técnico. Quizás con la frase que más estoy de acuerdo con Rodrigo es con que la motivación necesaria para la productividad del desarrollador debe ser producida gracias a un planteamiento tecnológico claro, y este tiene que ser desarrollado por el jefe de proyecto (o en su defecto, por el lider técnico). Lo que está claro es que el respeto que un desarrollador tiene hacia un gestor viene bastante relacionado con el nivel técnico del mismo, sin duda alguna, porque si no fuera así, ¿cual sería el referente del desarrollador?
Obviamente nadie pide un ‘jefe de látigo’, pero si no hay categorías y responsabilidades claras en el aspecto técnico, nunca podrá haberlas en la gestión, puesto que esta se convertiría en caótica, y cuando una nave es ingobernable, nunca llegará a buen puerto ;).
Empezaré por una obviedad: no hay reglas que valgan para todo. Es decir, las características de cada proyecto: tamaño, plazo, complejidad, ambiente político, multiculturalidad, etc. deben condicionar las características que deberá tener el jefe de proyecto a elegir. Obvio que en un proyecto de 2 meses y 3 programadores el jefe de proyecto tenga un alto conocimiento y experiencia técnica. ¿Y en un proyecto de 1 año, 20 programadores de 4 nacionalidades distintas y diversidad tecnológica? Un proyecto puede ser muchas cosas y por lo tanto puede requerir competencias y habilidades distintas. Lo importante es ser consciente de esto y hacer un buen «casting» de todo el equipo.
Yo creo que es condición necesaria, pero no suficiente el tener conocimientos técnicos (altos). Además debe de tener otra serie de características y conocimientos, que le permitar gestionar bien sus recursos. Comparto la opinión de Rodrigo.
Hace años estuve durante un tiempo de jefe de proyectos, en aquella época (bueno más bien antes de llegar a este cargo), estuve muy implicado en formarme en conocimientos de negocio, de gestion de proyectos, de recursos humanos, etc… con la intención hacer mi trabajo lo mejor posible. Y la verdad me sentía bastante cómodo, sobre todo porque cuando había ciertos problemas técnicos, me ponía con los programadores a resolverlos y ayudarles (y eso que realmente no me lo permitían), lo que hacía que mejorasen las relaciones y la unidad del equipo. Eran equipos pequeños, y mis conocimientos e implicación me ayudaron bastante, entre otras cosas, a evitar los tan poco deseados retrasos.
Ahora, a mi hay una frase que me han soltado alguna vez sobre este tema, gente con opinión contrara, y que siempre he intentado defender y argumentar: ¿ Necesita un arquitecto saber poner ladrillos para hacer bien su trabajo ?
Yo creo que es diferente el caso, cosa difícil de hacer ver a alguien que defiende la postura contraria.
Esta vez has dado en la diana con el asunto en cuestión.
En lo que es mi experiencia como desarrollador me he encontrado que
el motivo de que muchos proyectos fracasan es precisamente
lo que dices de que una persona no técnica acabe tomando decisiones técnicas.
Otra situación que me he encontrado es Jefes de Proyecto preguntándome cuestiones técnicas,
lo cual respondo encantado,
pero evidentemente supondría para mí una motivación mucho mayor
el estar a cargo de una persona de la que puedo aprender.
Una vez un directivo de una empresa me dijo: es mucho más fácil encontrar un perfil
analista-consultor-jefe (formación en económicas-empresariales-master) de proyecto que un
perfil de buen técnico (formación técnica).
En mi experiencia una de las principales funciones que hace un gestor de proyectos es planificar y estimar la duración del proyecto, con alguna desviación.
Sin embargo muchas veces se da menos importancia o simplemente se ignora un análisis de riesgos: que probabilidad hay
de que nuestras estimaciones fallen por completo y que hacer en este caso.
Para mi es obvio que cualquier pelele es capaz de hacer una estimación más o menos fiable de cuánto va a durar un
proyecto. No hace falta ser licenciado para eso. Sólo tener en cuenta ciertos criterios que la experiencia y
algún que otro master nos descubren.
Pero tener que evaluar riesgos es otra cosa muy distinta. Hay es donde o se tiene un perfil técnico, o estas andando por tierras movedizas.
Las personas, independientemente de la esfera en la que se encuentren, tienden a confiar más en aquello que conocen o con lo que se pueden comunicar sin problemas. Los desarrolladores confían más en la persona que tiene conocimientos afines a los suyos, y los altos directivos provenientes de carreras alejadas de los aspectos técnicos del proyectos tienden a confiar en el cumplimiento de los plazos e indicadores marcados en las planificaciones u objetivos comerciales o de mercado.
Si el foro en el que se tiene que defender, explicar o plantear un proyecto esta conformado por comerciales, marketinianos, financieros y demás personas alejadas en la mayoría de los casos de los aspectos técnicos, evidentemente se necesita una interfaz de comunicación «gestora», con indicadores y números que en la mayoría de las situaciones ofenden a los técnicos.
Si el foro es el de un conjunto de desarrolladores que deben de cumplir un plazo y que sienten que nadie les entiende o apoya, el perfil técnico es necesario ya que debe apoyar, dar soporte e incluso aportar soluciones a problemas que un técnico no solventa en un momento determinado (motivado por que lleva 10 horas seguidas trabajando, por ejemplo).
Lo que está claro para mí es que el jefe de proyecto (o los jefes de proyecto) deben ser aquellas personas que defiendan el proyecto en los distintos frentes de la mejor manera posible para que el proyecto cumpla su objetivo. Un proyecto puede ser un fracaso tanto si los desarrolladores no son liderados adecuadamente, como si el proyecto elaborado (por muy bueno que sea a nivel técnico) no transmite confianza y fiabilidad a quien sólo quiere escuchar que se ha conseguido el objetivo.
No podemos pedir a un técnico que entienda por qué sólo le miden por indicadores como puntos funcionales, plazos comerciales o incluso número de líneas de código, en lugar de por la calidad, estabilidad y fiabilidad del software que desarrolla. Tampoco podemos exigir a una persona con un perfil puramente gestor o político que entienda o decida sobre la arquitectura, técnicas, patrones y metodologías a utlizar en la parte técnica.
La jefatura de un proyecto debe estar formado por aquellas personas (o persona) que sepan defender el proyecto en todas las situaciones de riesgo para el mismo. Como siempre, en el equilibrio está la solución buena (recordando que lo perfecto es lo enemigo de lo bueno).
La cuestión es que si eres jefe de proyecto (como es mi caso) no de un proyecto sino de unos 12-15 proyectos llega un momento en que dejas de ser técnico, dejas de formarte en temas de programación y acabas siendo un gestor que sabía programar pero que se ha quedado obsoleto. Tu misión consiste en proporcionar a cada equipo de desarrollo todo lo que necesita y realizar una tarea de seguimiento del proyecto para dar la cara ante el cliente. Total que estas en medio, entre el cliente y el equipo de desarrollo y esto, en ocasiones te obliga a tragar carros y carretas (con unos y con otros) para que al final cada proyecto termine dignamente.
La cosa no es fácil y ser técnico y gestor a la vez es un sueño, a no ser que trabajes en una empresa balneario, con tiempo para estudiar y probar nuevas tecnologías.
Saludos
Miguel… yo creo que no se puede ser jefe de proyecto en más de dos proyectos. Un jefe de proyecto que gestiona 12-15 proyectos no hace sino molestar en todos. Por no decir que su tiempo se va en cambios de contexto y sin hacer una gestión efectiva de ninguno de ellos. La gestión activa de un proyecto es una tarea compleja y que consume mucho tiempo. No hay nadie que pueda gestionar correctamente más de 2-3 proyectos.
Cuando imparto formación sobre gestión de proyectos suelo preguntar a los asistentes cuantos proyectos
Lol Miguel, ole tus huevos, 15 proyectos, y que tal le va a tu empresa? 😛
Me conozco esa historia muy bien, estas en uno y otro y al final no estas en ninguno, y el trabajo realmente t lo hacen por debajo pero tu te llevas la medalla.
Estar en 15 proyectos no es ser un jefe de proyecto tecnico, ni un gestor, es ser un puto desastre para todo el mundo.
Cheers
Creo que es un exceso, aunque no sabemos la envergadura de los proyectos es un poco pasado de rosca.
Hacer bien el tabajo no es solamente dar el visto bueno
Bien. Para mi ha sido muy útil, tanto la introducción como las respuestas, ha quedado bastante claro que un jefe de proyectos debe ser un buen técnico. AHÍ VA MI PREGUNTA: He llevado varios proyectos (de poca monta)entendiendo bastante bien la parte técnica del proyecto, ahora voy a cambiar de empresa, y voy a llevar proyectos de mucha más envergadura, no domino la tecnología en absoluto (programan en .NET y SQL Server). Quiero ser un buen profesional, y creo que soy un buen líder, un buen jefe, que he pasado por las galeras (siendo autodidacta en una empresa que no es de infórmatica),un tio comprensivo… y mi más fuerte deseo es hacer un buen trabajo y ser un buen Jefe de Proyectos. ¿Qué debo hacer para conseguirlo? ¿Debo renunciar al trabajo por desconocer la tecnología utilizada? ¿Creeis que puedo conseguirlo?¿Creeis que puedo ganarme al equipo aunque no sea tan buen técnico como ellos?
Por favor, os estaré muy agradecido si me aconsejais para entrar en esa empresa y no ganar un sueldo por la cara a costa del esfuerzo de la gente que tiene que «picar código», no quiero ser una molestia al contrario deseo ayudar al 100% al equipo, no importa esfuerzos (evidentemente estudiaré todo lo que pueda la tecnología), pero como creeis que debo comportarme??
Gracias y un abrazo para todos.
Carlos…
Me voy a permitir darte un consejo sacado de Peopleware (http://geeks.ms/blogs/rcorral/archive/2006/10/02/He-le_ED00_do_3A00_-Peopleware-_3A00_-Productive-Projects-and-Teams_2C00_-2nd-Ed-de-Tom-Demarco-y-Timothy-Lister.aspx), libro que te recomiendo encarecidamente que leas: Recuerda que el cometido del jefe de proyecto no es hacer que los desarolladores trabajen sino construir el entorno en el que puedan trabajar.
Yo en tu lugar otro tema que yo no olvidaría es el formame en gestión de proyecto de software y en diferentes metodologías. Muchos gestores de proyectos se olvidan de que la gestión de proyectos es algo que se puede aprender, una disciplina en la que existen numerosísimas técnicas que a menudo gente que gestiona proyectos no conoce. Los profesionales informáticos que más reinventan la rueda son los jefes de proyecto: cada maestrillo tiene su librillo y esto es receta habitual de la no gestión.
Sobre lo de ser un lider técnico, que yo prefiera al jefe de proyecto técnico no quiere decir que no se pueda ser un gran jefe de proyectos sin conocer a fondo la tecnología empleada en el mismo. Hay otros caminos para lograr el respeto del equipo de desarrollo. Conocer a fondo una tecnología no significa ser técnico. Para mi un jefe de proyecto técnico no solo se desenvuelve en una tecnología determinada sino que es aquel que tiene la capacidad de escuchar las cuestiones técnicas planteadas por el equipo y ayudarle a encontrar la mejor solución.
Fijate que no digo que el jefe de proyecto sea quien de la solución sino quien guie al equipo y tire del hilo para dar con una solución satisfactoria.
He estado leyendo los comentarios y quiero dejar el mío.
En mi caso llevamos un proyecto de Outsourcing. Yo represento la parte técnica y mi compañero la parte de gestión, y creerme cuándo os digo que esta formula funciona.
Otro aspecto que es importante es el hecho de la dimensión del proyecto. Puede haber proyectos que requieran un gestor, otros un técnico y otros los dos. La mejor formula es T&G.
En mi opinión la cuestión (¿Debe ser el jefe técnico/no-técnico?) está mal planteada. Sobretodo, si detrás de los términos ‘técnico’ y ‘no-técnico’ leemos respectivamente ‘desarrollador/arquitecto’ y ‘gestor político/económico’ (esto se percibe leyendo los comentarios).
Creo que se puede plantear mejor el tema adquiriendo una visión a 360º de lo que es un proyecto (y desprendiendonos de nuestro «querido cachito»!). Tenemos muchas disciplinas involucradas en un proyecto: framework, lenguaje, BBDD (pura tecnología); user-experience, diseño, accesibilidad (parte más creativa); SEO; conocimiento del negocio del cliente, marketing; etc. Además el jefe debe tener habilidades «transversales»: liderazgo, capacidad de comunicación, metodología de gestión, etc.
Concluyo que es mejor que un jefe tenga conocimientos y capacidades «horizontales» (no «verticales», como por ejemplo un experto en .NET). Su back-ground debe permitirle entenderse y tomar decisiones con el equipo, el cliente y la dirección (cada uno experto en lo suyo). Si encima es un gran técnico, genial.
Un jefe no es mejor por ser técnico: quizás lo sea para su equipo, pero no de cara al cliente; quizás le vale para ciertos proyectos, pero no para todos. Un jéfe-técnico no es ni mejor ni peor que un jéfe-gestor. Lo importante es reunir lo necesario para interaccionar bien con todas las partes involucradas en el proyecto!
Es muy importante encontrar la diferencia entre el jefe de proyectos gestor y el jefe de proyectos tecnico especialmente cuando el tecnico ya ha tenido la experencia de ejecutar actividades en la practica y conoce los problemas y soluciones que se pueden implementar en la ejecucion de una actividad que se proyecto por alguien que tenia conocimeineto del tema.
atte, ing civil CRISTOBAL RICAURTE
He pasado de JP técnico de una tecnología conocida a coordinar y liderar proyectos de tecnologías no experimentadas o mí. Quiero decir que existe una pequeña linea entre que es mejor. Particularmente mi experiencia técnica me ha ayudado a comprender los problemas diarios de la gente, pero mi capacidad de gestión, coordinación, comunicación es la que me ha dado un valor añadido. Es muy común que técnicos muy buenos dan un paso natural a JP, creo que es un error muy común sin haber demostrado dotes y sin formación.
muy buenos comentarios, yo soy tecnico y deseo ser jefe de proyectos, me capasito en PMI para ser PMP, y despues cone l tiempo PgMP(Casi dios en proyectos), estoy liderando proyectos y mi conocimiento tecnico facilita el exito de estos, mi conosimiento de gestion por parte de PMI, facilita la gestion, sin embargo aun me queda mucho camino por recorrer y liderar proyectos de mas costo (Mayor a los 2 millones de dolares americanos), sigan acotando sus experiencia que es muy gratificante.
Yo creo que un buen Jefe de proyecto es:
1. Quien sabe satisfacer a su cliente, entregándole el producto que necesita.
2. A la vez que consigue la rentabilidad marcada por su Gerente o Director para ese proyecto.
3. Mientras que motiva y mantiene contento a su equipo de desarrollo.
Parece una perogrullada, pero es muy cierta.
P.D.: Si no hubiera un Jefe de Proyecto Tecnico en esta Web, no habria un Captcha en el formulario de registra comentarios. :p