En una startup que aconsejo, las tareas archivadas por PMs para que los ingenieros implementen tenían una prioridad baja / media / alta.
Dado que se trata de una etapa inicial, siempre hay más trabajo por hacer que tiempo o personas, por lo que los ingenieros nunca se pusieron a hacer tareas bajas o medianas.
Así que PMs dejó de presentar tareas de prioridad baja y media.
Ahora todas las tareas son de alta prioridad. Por lo tanto, las prioridades se comunican informalmente: «Sí, ambas son de alta prioridad, pero X viene antes que Y». Lo que naturalmente conduce a desacuerdos: «¿Por qué no terminaste A?»Porque estaba trabajando en B. «» Pero A es una prioridad más alta.»No, tienen la misma prioridad de alta.»
Lo interesante es que esto no sucedió porque un lado subvirtió el sistema. Al contrario, ambas partes estaban haciendo lo que se suponía que debían hacer bajo el sistema. Los ingenieros que abandonaban las tareas bajas y medias tenían sentido porque el objetivo de priorizar es decir qué se puede dejar de lado cuando no se pueden hacer todas. La decisión del PMs de archivar solo tareas de alta prioridad volvió a tener sentido porque ¿para qué archivar tareas que no se harán, de todos modos? Hacerlo solo es una pérdida de tiempo para todos los involucrados. Archivarlo como alto o no.
Por lo que el sistema se descompuso.
¿Cuáles son algunas alternativas?
Un método de priorización que funciona es tener prioridades definidas objetivamente. En Google, por ejemplo, P0 significaba una emergencia de producción: detenga lo que está haciendo y trabaje en esto. No es irrazonable que se llame a la gente para que arregle un P0, que se despierte en medio de la noche. P1 significaba una tarea de prioridad inusualmente alta: no es necesario detener lo que está haciendo para trabajar en el P1 (no es un P0), pero cuando haya terminado con lo que está haciendo, debe trabajar en el P1. P2 se utilizó para la mayoría de las tareas. Y P3 y P4 no se harían, nunca.
Este sistema funcionó porque las prioridades se definieron objetivamente y se entendieron ampliamente, para que la gente pudiera retroceder y establecer la prioridad correcta: «No, eso no es un P0 — no es una emergencia de producción» o «No, eso no es un P1 — sí, es importante, pero no tiene prioridad sobre todo el trabajo que tenemos.»Mientras que con bajo / medio / alto, ¿es una tarea en particular un medio o un alto? Es cuestión de opinión. Puede significar cualquier cosa, causando que el sistema se descomponga.
Un segundo método de priorización que funciona es que el PM defina un ciclo o un sprint que consiste en una lista definida de tareas que deben realizarse en un período de tiempo acordado. Si una tarea está incluida en el ciclo actual, eso significa que debe realizarse este ciclo, por lo que la prioridad es menos relevante .
Un tercer método de priorización que funciona es que el PM defina una lista de tareas priorizadas. Una lista numerada donde el primero es más importante que el segundo, que es más importante que el tercero, y así sucesivamente. Esto de nuevo tiene sentido. En última instancia, lo que importa es si un ingeniero debe hacer la tarea X o Y, cuando no hay tiempo para hacer ambas cosas. No si X es medio en un sentido absoluto, lo cual no tiene sentido de todos modos.
En cualquier caso, no utilice una prioridad baja / media / alta. Usa algo como Trello, donde arrastras tareas hacia arriba o hacia abajo para establecer una prioridad implícita .
Esto funciona especialmente bien si la lista incluye un objetivo de alto nivel, como la función de lanzamiento X. Eso les da a las personas la propiedad y las motiva.
Por supuesto, todo esto supone que tiene un PMs competente y bien intencionado. He trabajado con algunos SPm de segunda categoría que tratan de meter tantas tareas como sea posible en un ciclo, y luego se enojan cuando las cosas duran más de lo esperado. No pueden priorizar. Lo quieren todo. O no entienden el compromiso fundamental en la gestión de proyectos, es decir, el compromiso entre tiempo, alcance y calidad.
O entienden todo lo anterior, pero usan esto para manipular a los ingenieros para obtener más trabajo de ellos. Esto no funciona por mucho tiempo, dejé de darle información relevante al primer ministro, porque generalmente abusaba de eso como una oportunidad para criticarme. Descartaría todo lo que dice. Cuando tenía un desacuerdo con alguien más en el equipo, empezaba asumiendo que la otra persona tenía razón.
Si tiene un PMs de segunda o mal intencionado, ningún método de priorización funcionará bien.
Es interesante que las herramientas de seguimiento de errores diseñadas para ingenieros no funcionen tan bien como las herramientas de seguimiento de tareas diseñadas para cualquier tipo de tarea. Esto se debe probablemente al sesgo de los ingenieros de poner una interfaz de usuario encima de una base de datos. Pero los humanos no piensan como una base de datos. Una metáfora del mundo real como un montón de tarjetas dispuestas y ordenadas en un escritorio puede ser un mejor modelo.