10 errores del joven PO (conclusión)

Y ahora 3 errores principales. Si se hacen una y otra vez, me temo que desde una OP joven puede asumir el papel de una OP anterior. Comience aquí y aquí .


8. No puedes despedir a nadie del equipo de desarrollo
De lo contrario, todo el equipo quedará desmotivado.

Sí, en los clásicos del género, el equipo scrum está autoorganizado, y te sientas en el "trono" y priorizas el trabajo atrasado. No importa como)

En realidad, un equipo autoorganizado no tiene miedo de discutir problemas, sinceramente le dice a otro miembro del equipo que "de hecho, no vamos a chatear aquí". Por ejemplo, si una persona apareció en el equipo, un dilatador, discutieron todo esto en retro, se dieron cuenta de que "esto no funcionará" y con las palabras " Esto es Esparta " ... se despidieron de él. (Ni siquiera sé cómo seguir trabajando en un equipo así :)

RO: él es el gerente, el propietario del presupuesto y, en consecuencia, si no se sumerge en los asuntos del equipo "autoorganizado" y no controla su "salud", es poco probable que esa historia termine bien. ¿Tú y el equipo intentaron cosas diferentes, pero no ayuda? Luego, el despido, la advertencia y todas esas cosas son su área de responsabilidad. Aunque las mejores prácticas sugieren que tales decisiones deben ser tomadas por el equipo, muy pocas de ellas alcanzan un nivel psicológico de interacción.

Quiero hablar sobre dos casos de mi práctica. Nuestro equipo tiene 2 ejemplos geniales.

• El primer ejemplo. Forzado el desarrollador participó en la planificación, discutió las características, apoyó, acumuló y luego pudo decir: "Chicos, tengo 2 meses de capacitación". Regresó, todo en un círculo otra vez. Pero el equipo en sí no pudo decirle nada, no quiso hacerlo y guardó silencio, y parte del trabajo se detuvo, todo el equipo se aferró a estas tareas planificadas y, por supuesto, no tuvo mucho tiempo. Vi esto durante mucho tiempo, hablé con el desarrollador, como resultado, nos despedimos de él. Y nada le sucedió a la salud del equipo, todos dijeron: "Sí, la decisión correcta, pero en general sería bueno tomar esas decisiones como un equipo completo" (madurado :)).
• Un ejemplo de lo segundo . Positivo El desarrollador sufrió de dilación, no está completamente claro lo que estaba haciendo. Pero en el retro, el equipo dijo que no era bueno, describieron los pros y los contras de la persona de su propio equipo. ¿Y sabes que? Nos dimos cuenta de que simplemente no nos entendíamos. El desarrollador comenzó a trabajar de una manera diferente, maneja mucho, escribe mejor. Eso es lo suficientemente retro. Entonces, a veces, la iluminación del equipo también se produce si hay un buen scrum master que ayudará a comenzar a hablar.

9. Cualquier negocio debe ser completado.

No, ninguno. En general, una cosa extremadamente rara debe completarse en el desarrollo de productos. Por supuesto, si ese final está definido correctamente :)

Por ejemplo, se te ocurrió una característica, mentiste al respecto, vive en la imaginación, el prototipo es hermoso y también tiene ese botón azul con un borde blanco. Afortunadamente, hay un mvp que salva vidas que no te permitirá hacer nada superfluo. El cliente recibirá en primer lugar lo más necesario, y solo después de eso: algo necesario, luego adicional y solo en algún momento algo para el alma.

Muchos principiantes de PO se preocupan de no haber hecho ninguna de sus ideas (épica), este sentimiento les hace tomar tareas que traerán poco valor pero gastarán muchos recursos, mientras que el cliente sufrirá un problema que usted podría rápidamente y solo decide.

Apaga al perfeccionista y ten una gran sensación por un tiempo. Llegará un momento en que el cliente estará bastante satisfecho y será posible realizar todas las tareas al final del trabajo atrasado (aunque yo mismo todavía no he estado en esta etapa del desarrollo del producto, pero entender esto ayuda a tomar decisiones fácilmente).

De esta manera funcionará por sí solo si las tareas tienen una historia de usuario descrita con precisión, dibujaré cómo se ve:



10. Trabaja y teme perder tu trabajo

Vienes a una nueva empresa / comienzas una startup, pero al mismo tiempo trabajas y tomas decisiones basadas en la experiencia pasada. En las nuevas realidades, ciertamente habrá personas / reglas / opiniones que le dirán que aquí "es imposible ", pero " no se acepta ", y " no pronuncie esta palabra en absoluto. Esto se convierte en una restricción artificial de un producto; a menudo se basa solo en conjeturas, opiniones subjetivas y el miedo a los demás. Pero no lo sabe, y construya muros de concreto alrededor de su producto, que no le permiten desarrollar.

Un ejemplo Nuestro equipo pasó seis meses sin servidores para el producto, porque "tales reglas: todos aquí esperan un servidor durante 6 meses", cuestan como Ferrari F60 America, y el alojamiento en la nube está prohibido. Ok, espera: el servidor debajo de la mesa no es tan malo.

Arriésgate, pruébalo. ¿No funcionó? Inténtalo de nuevo! O resulta que no tienes que construir un muro de hormigón o puedes romperlo, o lo peor que puede pasar es que descubras que es realmente imposible demolerlo. Pero en el camino descubrirá el contexto del problema tanto como sea posible, encontrará más opciones para las soluciones. Sí, lo más probable es que enojes a alguien con tus intentos de romper algo que no se puede romper. Nadie lo castigará por tratar de hacer todo lo posible por el producto y la compañía, y aún más para que no lo despidan :) las primeras tres veces, seguro. En el cuarto, es posible, pero hiciste todo lo que pudiste.

Por cierto, ahora estamos alojados en la nube e implementamos máquinas virtuales en 1 minuto en la cantidad que consideremos necesaria. Y todavía estoy trabajando aquí :)