curso intensivo de la tarde

Tengo experiencia en ingeniería y acepté una oferta de una empresa de tecnología para la cual lideraré un nuevo proyecto web (combinación de PM + líder tecnológico). No hay ningún trabajo previo realizado excepto el concepto general del proyecto. Es decir, sin equipo, sin arreglo sobre qué tecnología usar, sin herramientas y metodología de gestión de proyectos. Tendré que manejar todo eso, incluida la selección de pilas, personas, herramientas de mantenimiento preventivo, etc. Además, lo importante es que esta empresa es un fabricante de hardware, no una empresa de software como todos mis empleadores anteriores, por lo que tampoco tienen herramientas y metodologías disponibles.

Por supuesto, tengo ideas basadas en mi experiencia previa y he estado del otro lado de PM por un tiempo, pero realmente agradecería consejos e ideas sobre dónde aprender más para mi nuevo trabajo. Busco específicamente consejos para herramientas de PM (por ejemplo, Jira), subcontratación, pruebas automatizadas, compilaciones automatizadas, implementaciones, administración de equipos y problemas comunes de PM.

¡Muchas gracias!

Hola mvbl, ¡bienvenido a PMSE! Siguiendo el enfoque de preguntas y respuestas para todos los sitios de SE, esperamos tener preguntas objetivas y enfocadas para ofrecer respuestas específicas, como puede ver en nuestras preguntas frecuentes y Cómo preguntar . Creo que su pregunta, tal como está ahora, es demasiado amplia, ya que está preguntando varias cosas a la vez. Idealmente, las preguntas deben presentar un problema específico al que se enfrenta (incluido lo que ya ha hecho y dónde se quedó atascado) para ofrecerle las mejores respuestas/consejos. ¡Salud!
Si está dispuesto a dedicar más tiempo, vale la pena leer Rapid Application Development de Steve McConnell

Respuestas (4)

Hay muchas facetas en su pregunta, pero el enfoque en este momento debe ser solo el tema general de cómo tiene éxito en esta primera tarea. Estoy de acuerdo con David en que el éxito es un mal maestro, pero el objetivo es aprender de pequeños incrementos de fracaso que no afectan el éxito general del proyecto.

Me gustaría agregar algunos detalles sobre los problemas comunes de PM que parecen muy relevantes para su situación actual.

  1. Alcance, expectativas o entregables mal definidos.

    Esto no solo se aplica al proyecto web, también se aplica a su trabajo. En términos de los próximos 90 días, ¿qué es más importante para su empleador? el lanzamiento del sitio web/aplicación o la creación de un marco para la web continua u otro desarrollo de software? Si la atención se centra en el lanzamiento, emitirá juicios y establecerá prioridades en función de eso. Como sugirieron las dos respuestas anteriores, manténgalo lo más simple posible si el lanzamiento es la prioridad.

    ¿Qué hay de los requisitos del proyecto en sí? Si todo lo que tienen es un concepto general, eso necesita un poco de trabajo antes de que pueda comenzar a pensar en muchas de las otras cosas sobre las que preguntó.

  2. Priorización y filtrado de tareas insuficientes

    Un problema común con PM es la presión de tener una cantidad inmanejable de cosas al mismo tiempo y parece que ya estás en medio de eso. Sugeriría comenzar con una lista de tareas de alto nivel y centrarse en determinar los elementos de la ruta crítica. Tome la tarea más importante y construya el siguiente nivel de la jerarquía para ella, también en orden de ruta crítica.

  3. Ajuste incorrecto de la infraestructura o la metodología

    Para tomar prestada una cita popular: "su metodología e infraestructura deben ser lo más simples posible pero no más simples". Realice una búsqueda de metodologías de gestión de proyectos ligeras o simples y herramientas SDLC y elija las que parezcan accesibles y realistas en este momento. Hay tiempo para actualizar y volverse más sofisticado más tarde.

gracias por la respuesta. Tiene razón, por lo que entiendo, el alcance en sí aún no se ha definido bien, aunque la idea general es bastante clara. Mira, todas mis preguntas vienen porque me siento cómodo con el lado tecnológico y de ingeniería de las cosas, pero no tanto con el manejo del proyecto como un todo. De todos modos, muchas gracias por los valiosos consejos.

Concéntrese en el "qué" y asegúrese de que el equipo se concentre en el "cómo" en la medida de lo posible. Su trabajo como PM será asegurarse de que todo lo que debe hacerse se haga. Así que planifica, planifica y vuelve a planificar. Y pregúntese qué puede salir mal y averigüe cómo tratarlo (gestión de riesgos). Aparte de eso, consígase un buen libro PM y/o un curso de capacitación, y no tenga miedo de pedir ayuda.

No me preocuparía demasiado por herramientas y metodologías específicas en este momento. Puede planificar en una pizarra o en una hoja grande de papel. Las herramientas pueden seguir.

Gran parte del entrenamiento de PM pone nombres, formalidad y rigor a lo que has estado haciendo desde los cuatro años. Ciertamente, hay cosas como EV o varios métodos o análisis de riesgo cuantitativo que no hizo cuando era niño, pero hay muchos proyectos exitosos realizados por organizaciones de PM razonablemente maduras que hacen estas cosas de manera deficiente e incorrecta. Confía en tus instintos. Cometerá muchos errores, pero el éxito es un mal maestro.

Me temo que mi respuesta tampoco responderá; usted pidió una recomendación de la lista de compras. Como muchos de los otros, voy a responder solo a los "problemas comunes".

El PM es responsable de cerrar el proyecto con éxito, pero no controla nada que contribuya directamente a cerrar el proyecto. El personal, las prioridades, etc. todo pertenece a otra persona. Lo único que controla es la información sobre el proyecto y el estado del proyecto. Cultiva y nutre esa información porque es tu herramienta principal.

Su trabajo es descubrir los riesgos/problemas que afectarán la probabilidad de que el proyecto se complete con éxito a tiempo/por debajo del presupuesto/alta calidad/relevante para la misión de la empresa. Analice esos riesgos y problemas y comunique el análisis a las partes interesadas que controlan los otros recursos. PERO asegúrese de que sus comunicaciones estén enfocadas con láser. Pregunte a cada parte interesada qué necesita saber para mantener su apoyo al proyecto y asegúrese de que cada parte interesada tenga acceso a esa información. El control de cambios es tu amigo.

Los proyectos enfocados en hardware tienen una tremenda ventaja; las métricas son generalmente mucho más fáciles: puede saber cuántos widgets ha producido, la calidad/cantidad/costo del widget, etc. El valor ganado es mucho más fácil de calcular.

La mejor de las suertes.