Dirijo un equipo de desarrollo de 8. Tenemos algunos PM aquí y, a menudo, preguntan acerca de cómo obtener una buena vista de los recursos gratuitos para desarrolladores que tenemos.
Otras partes del negocio tienen un calendario de perspectivas compartido, pero para los desarrolladores creo que esto se reduce a la microgestión. Siempre hay trabajo que hacer, pero es una cuestión de prioridades. No quiero que los PM cuestionen el hecho de que alguien está refactorizando la compilación o realizando una revisión del código; sugiriendo que este trabajo debería ser reemplazado por algún proyecto de trabajo.
Usamos Trello para asignar personas a tickets de soporte, etc., pero esto no da una idea de qué tan bien podemos financiar proyectos de varias semanas/meses.
Alguien sabe de algo que funcione bien?
Parece que intenta resolver el problema equivocado al tratarlo como un problema de disponibilidad individual. Lo más probable es que esto se deba a que tiene una organización extrañamente matricial que no se basa en equipos de proyectos o en la planificación de la capacidad del equipo , sino que aparentemente se basa en el notoriamente fallido "¿Joe está ocupado en este momento?" metodología.
Su equipo de ocho debe tener una capacidad variable pero generalmente predecible. En Scrum, este es su rango de velocidad durante algún período histórico posterior. Ya sea que siga Scrum o no, este tipo de estimación histórica de la capacidad futura suele ser su guía más precisa para determinar si un equipo puede tener capacidad para trabajo adicional.
Además, no se debe esperar que cada equipo de proyecto cambie de contexto sin una penalización visible y costosa para la productividad. Claramente, a su organización le falta un propietario del producto para cada proyecto y un marco escalable que pueda priorizar el trabajo en múltiples proyectos. Como resultado, todos tratan sus prioridades personales como las prioridades, y cuando todo es una "prioridad máxima", entonces no se hace nada.
Su proceso organizativo claramente necesita trabajo. Considere Scrum, Kanban y los marcos escalables disponibles como SAFe o Scrum-of-Scrums. No existe una panacea, pero casi cualquier marco formal será mejor que lo que la organización está haciendo ahora.
Estuve en una situación similar antes de que hiciéramos Scrum completo con una planificación real con los equipos y los propietarios de productos para definir la acumulación de sprint. Lo que estábamos haciendo para mitigar el flujo constante de solicitudes al equipo de desarrollo (20 desarrolladores, 7 QA) fue lo siguiente:
Esta es una forma muy tosca (y un poco lenta) de nuevo, sin incluir las negociaciones de los desarrolladores con los PM para reducir las características cuando sea posible, y todas esas cosas hermosas de Scrum, pero podría ayudar en el medio. Todo lo que intentamos hacer de antemano solo con los PM y los líderes del equipo.
Si es posible, realmente recomendaría usar Scrum completo, si tiene un buen candidato de PO y simplemente comenzar desde cero. Se necesita un tiempo para obtener la mano de los eventos Scrum y la planificación adecuada, pero realmente vale la pena.
Roland Tiefenbrunner