¿El software de gestión de proyectos debe estar compuesto por las tecnologías que usan los desarrolladores?

Como propietario y director de proyecto de una tienda de Rails mediana (~20 desarrolladores), me encuentro examinando constantemente una docena de pestañas tratando de medir el estado actual de cualquier proyecto. Mi equipo adopta la integración continua y las pruebas unitarias rigurosas; usamos GitHub, Trello, FogBugz y Slack para el control de versiones, el seguimiento de funciones/problemas y la comunicación, respectivamente. Tengo curiosidad por conocer el flujo de trabajo diario de otros PM, especialmente antes de informar a los clientes.

Internamente, estamos contemplando agregar mensajes de compromiso, sprites de Kanban, mensajes recientes de Slack, problemas abiertos, etc. y algunas métricas básicas en un solo tablero para simplificar este enigma de "docenas de pestañas". El objetivo del proyecto interno es disuadir la replicación que observamos al usar Asana. Las tareas se asignarían a través de Asana e inmediatamente se encontrarían en un tablero de Trello.

¿Existe algún valor de asignación de intercambios textuales, por ejemplo, la asignación y finalización de una función en Trello, a la base del código, por ejemplo, un mensaje de confirmación y un hash de git?

¿Se pregunta si a algún otro PM le resultaría útil este panel? ¿Deberíamos abrirlo al público?

Su título y pregunta no coinciden. Hay soluciones de software comercial y el trabajo de PM todavía existe. Nadie le dará una retroalimentación adecuada sobre una pieza de software que es tan vaga como "tablero". que es lo que quieres saber? ¿Su software tiene características únicas? Si es así, ¿Que son?
Si bien esta no es una solicitud de recomendación de software, creo que tiene suficientes atributos (efímera, relacionada con la opinión, sensible a los requisitos) como para cerrarla por los mismos motivos.
Visualice Baremetrics para Trello, GitHub + Issues, Slack. Más que Asana o JIRA, queremos una agregación de datos en tiempo real de las tecnologías que nuestros desarrolladores eligieron usar.
¿Te refieres a tiempo real como en "tiempo real"? ¿Te gusta actualizar constantemente sin la necesidad de presionar recargar en una página? Eso parece un poco demasiado.

Respuestas (2)

Creo que, idealmente, podría utilizar un subconjunto de funcionalidades de sus sistemas de desarrollo como su(s) herramienta(s) de gestión de proyectos. Sin embargo, parece que tienes muchos sistemas en la mezcla. El problema es que cuando agrega las salidas de estos sistemas en un sistema completamente nuevo, acaba de crear aún más partes móviles para administrar. Puede funcionar y ayudar por un tiempo, pero eventualmente cambiará una de las partes de su sistema. ¿Eso explotará todo tu sistema? ¿Por qué usa todos estos sistemas separados ahora en lugar de encontrar uno que haga (casi) todo para reducir la cantidad de partes móviles?

Para mí, esto haría que fuera más difícil generar valor y claridad para mis clientes y mi equipo, por lo que consideraría la consolidación. Puede significar que las herramientas son más caras, pero al final, si tiene menos piezas móviles, estará mejor. No siga la ruta de las 16 herramientas con conexiones automatizadas entre ellas. El tiempo dedicado a esto podría haberse dedicado a obtener licencias para una mejor configuración.

Buena suerte.

Me dijeron que los Project Managers serán reemplazados por software automatizado. En cierto modo, eso es cierto.

Pero, ¿qué era (y sigue siendo) la gestión de proyectos, entonces? Se trata en parte de establecer procesos para adoptar el cambio, comunicar con prontitud, evaluar y gestionar riesgos, facilitar el trabajo en equipo, medir la calidad y el progreso, etc.

La conclusión es (a menos que usted sea un mero coordinador de proyecto - aquí se usa la definición y aceptación de PMP): usted está ahí para ayudar a los profesionales a hacer su trabajo, reducir el estrés y el hipo, y mantener todo en ritmo (metáfora musical intencionada - jazz ¡jugadores, por favor, tengan la intención fuera de ritmo!). El software que usa su equipo es, en parte, su elección. Por lo tanto, mientras se mantenga actualizado sobre las herramientas y los procesos, su trabajo como gerente de proyecto nunca morirá.

En el futuro, los gerentes de proyecto pueden ser menos en número, pero mucho más capacitados... o serán más numerosos, menos capacitados y menos remunerados. ¿Quién sabe?

Piensa en la revolución industrial y la previsión de que ya nadie trabaje en las fábricas...

Entonces piensa en la era de la información, su revolución y la previsión de que nadie trabaje porque todo lo relacionado con la gestión de la información estará automatizado. Piense en cuántos desarrolladores se necesitarán en los próximos 20 años para satisfacer las necesidades de las industrias de la información.

Luego piense en la tercera revolución industrial, donde los robots reemplazarán toda la contribución humana en la cadena de construcción, pero aún así... parece que los humanos son necesarios de alguna manera.