Soy un estudiante de posgrado de CS y estoy interesado en aplicar métodos de gestión de proyectos o ingeniería de software/sistemas a proyectos de investigación en mi universidad. Tengo experiencia en la aplicación del marco Scrum para equipos de desarrollo pequeños, pero no creo que dicho marco de gestión sea aplicable aquí. Usemos el Proyecto A como ejemplo.
Estas son algunas de las características del Proyecto A :
El Proyecto A todavía está en su infancia (¿fase de descubrimiento conceptual, quizás?). Al aplicar ingeniería de software/sistemas o métodos de gestión de proyectos a este proyecto, puedo imaginar vagamente la facilitación de:
Como mencioné anteriormente, no creo que Scrum sea del todo aplicable para administrar la solución técnica del Proyecto A. Mi experiencia en la implementación de soluciones técnicas implica compromisos de tiempo predecibles y consistentes, incluso si los equipos están distribuidos geográficamente o en varias zonas horarias. Sin embargo, no estoy familiarizado con la gestión de un proyecto en el que las personas pueden comenzar o dejar de trabajar de manera intermitente porque tienen otras prioridades en la organización (la organización es la universidad, en este caso).
¿Qué métodos de gestión de proyectos, ciclos de vida de desarrollo o ingeniería de software/sistemas podrían beneficiar al Proyecto A ?
El diccionario de Google arroja lo siguiente como la definición principal de un proyecto:
Una empresa individual o colaborativa cuidadosamente planificada y diseñada para lograr un objetivo particular.
La parte del "objetivo particular" es importante. Sin entregables claros que brinden valor a alguien (también conocido como partes interesadas), entonces es cuestionable si realmente puede llamar a algo un proyecto.
Las necesidades de la academia ciertamente diferirán de las de los proyectos del sector público o privado, pero incluso nuestros proyectos de investigación requieren una cierta cantidad de estructura para tener éxito.
Con base en algunos comentarios, se descubrió información adicional sobre el proyecto propuesto.
Los diversos departamentos y facultades de la universidad patrocinan el proyecto mediante la asignación de recursos, aunque un objetivo a largo plazo sería comercializar nuestros hallazgos/producto. Podría verme a mí y/o a un profesor administrando el proyecto en lo que respecta a facilitar la comunicación, organizar reuniones y coordinar esfuerzos. Me está costando mucho responder a su pregunta sobre las partes interesadas. Podría imaginar que los profesores y estudiantes que trabajan en el proyecto son todos interesados. La universidad en sí misma es solo una parte interesada indirectamente a través de cada departamento.
Ya sea que esté utilizando una metodología formal como PRINCE2 o una metodología liviana como Scrum, los proyectos siempre necesitan algún tipo de definición formal de proyecto para funcionar. En otras palabras, necesita algún tipo de estatuto del proyecto .
Con base en los comentarios citados, se puede inferir lo siguiente:
En otras palabras, es un proyecto en busca de un marco y un propósito, en lugar de un proceso formado en torno a un objetivo determinado. También faltan otras piezas, pero estas son las más importantes que deberían abordarse en algún tipo de estatuto formal.
Incluso una carta tiene un requisito previo: necesita partes interesadas que deseen entregar algo de valor. Si eso es Ph.D. los estudiantes que investigan para una disertación, un profesor titular que se prepara para un trabajo patrocinado por la escuela o un campus de ciencias aplicadas que proporciona trabajo de campo para sus estudiantes no importa. Lo que importa es que alguien, en algún lugar, debe estar conduciendo esto, o no es un proyecto.
En mi opinión, basándome únicamente en la información limitada provista, el objetivo del proyecto y sus partes interesadas clave deben ser algo evidentes como información para fletar este proyecto. Un Documento de Acta Constitutiva del Proyecto formal es el resultado de dicho proceso, pero si el proyecto en sí no tiene partes interesadas ni un objetivo en el proceso de constitución, parece poco probable que tenga éxito, independientemente del marco de gestión del proyecto que finalmente elija.
Habiendo dicho todo lo anterior, si puede abordar los problemas de formación de proyectos y seguimiento de dependencias necesarios para impulsar su proyecto, entonces aún necesita un marco que le brinde la capacidad de utilizar algún tipo de planificación de recursos de "mejor esfuerzo". .
Un sistema Kanban modificado puede ser una buena opción cuando los límites de trabajo en curso varíen ampliamente durante el proyecto en función de quién puede proporcionar compromisos de tiempo durante un período de tiempo determinado. Sin embargo, la verdadera clave para que esto sea un éxito sería asegurarse de que ningún elemento de trabajo exceda el tiempo mínimo disponible para cualquier participante del proyecto.
Si no puede descomponer las tareas a ese nivel y anticipa unidades de trabajo que variarán ampliamente en tamaño, entonces tendrá un problema de priorización donde el trabajo se extrae de la cola en función de dos factores: el trabajo actual en progreso límite basado en la capacidad de rendimiento actual y el tamaño de las historias de usuario que se pueden completar en un período de tiempo determinado.
Esto suele ser una mala idea, ya que no permite que la cola de trabajo se priorice correctamente. En lugar de sacar el trabajo de la parte superior de la pila en orden de dependencia o prioridad, es posible que deba permitir que las personas extraigan historias en función de criterios circunstanciales.
Sin embargo, si se utiliza correctamente, Kanban como marco parece una buena opción para proyectos en los que la mano de obra disponible variará ampliamente. Sin duda, puede hacer esto con cualquier metodología, pero Kanban proporciona límites de trabajo en curso y rendimiento promedio del sistema como herramientas simples que permiten estimaciones de entrega elásticas sin una replanificación pesada cada vez que cambian las restricciones de recursos.
Su millaje puede variar, pero al menos es un punto de partida. ¡Buena suerte con el proyecto!
Primero, felicidades por reconocer que scrum sería una clavija redonda en un agujero cuadrado en la estructura del proyecto que describe. Scrum requiere absolutamente compromisos de tiempo.
Podrías considerar Kanban. Solo he leído sobre él, pero parece ser un formato que admite una disponibilidad más flexible de recursos al tiempo que intenta restringir el desperdicio de esos recursos al mínimo absoluto. No tengo ninguna referencia que prefiera para esto, así que comience con Wikipedia .
Con respecto a las reuniones, bajo ninguna circunstancia iría a reuniones mensuales a menos que solo haya una persona trabajando en el proyecto durante un período de meses. La frecuencia quincenal debe ser un objetivo mínimo, especialmente en los casos en los que haya más personas jóvenes trabajando en el proyecto. Los miembros junior necesitan respuestas a sus preguntas, atención para mantenerlos motivados para cumplir y supervisión para evitar el enchapado en oro. Tal vez debería tener reuniones más frecuentes con aquellos que lo necesitan.
Como mínimo, necesita algún tipo de plan de proyecto que registre qué se entregará, cuándo y las dependencias entre estos componentes. Sin esto, va a ser realmente difícil comunicarse con los miembros de su equipo y mostrarles cuándo deben producir un artefacto que necesita otra persona. Esto también lo ayudará a comprender si el arreglo muy flexible de la disponibilidad de recursos puede incluso brindar lo que se requiere... "Joe solo está disponible a partir de febrero y está produciendo el documento del widget. Pero Jane necesita el documento del widget en enero... ."
Si está actuando como PM en esto, puede usar el plan como una herramienta de comunicación y también como una forma de alinear sus recursos con mucha anticipación... No espere hasta mediados de enero para verificar que Joe todavía está disponible. para producir el documento widget en febrero. Porque si no lo es, necesita tiempo para encontrar otro escritor de documentos de widgets.
Entonces, lo que estoy diciendo es cualquier enfoque que tome, comprenda las dependencias y planifique en torno a ellas.
Todd A. Jacobs
david kaczynski
Todd A. Jacobs