¿Qué estructura de reunión de proyecto debe elegir un desarrollador único?

Soy un desarrollador en solitario que trabaja en un proyecto decentemente pequeño con otras 3 personas (no desarrolladores). Estas otras personas están involucradas en el proyecto en formas que no son de desarrollo y una también es mi gerente. Todos están bastante abiertos a discusiones ad hoc, también.

Mi gerente me dio lo que parece un sueño hecho realidad: me encargaron determinar qué estructura de reunión funcionaría mejor para el proyecto. Esto parece una forma maravillosa de lidiar con la sobrecarga de reuniones y / o reuniones sin sentido .

Con un gran poder viene una gran responsabilidad, como ahora, si sugiero algo que finalmente resulta en mucho tiempo perdido, es mi culpa.

Nunca he tenido una pizarra tan en blanco para pensar cómo estructuraría las reuniones. Mis pensamientos son:

Reunión diaria de "actualización de estado / base táctil" durante 15 minutos o menos (similar a las reuniones de pie) para comunicar los objetivos diarios y revisar el día anterior. O parece que podría obtener una pizarra y ponerla en mi escritorio para comunicar esta información.
Según sea necesario, reuniones para tomar decisiones específicas o abordar preguntas que el equipo tenga

... No veo la necesidad de una reunión semanal del proyecto de "estado". Tampoco estoy seguro de que la segunda viñeta requiera muchas reuniones programadas formalmente.

Mi preocupación es que estos "centrados en el desarrollador" (es decir, yo) pueden causar alienación con otros o hacer que mi gerente sienta una pérdida de control sobre el proyecto, ya que esta estructura sería considerablemente diferente de la mayoría de los proyectos que se ejecutan.

¿Qué estructura de reunión de proyecto debe elegir un desarrollador único?

Comentarios de direccionamiento:

¿Qué están contribuyendo las otras personas? ¿Son los usuarios previstos de este proyecto? ¿Está trabajando en aspectos no relacionados con el desarrollo (como temas e imágenes del sitio web o un DBA o pruebas de control de calidad)? Otros niveles de gestión / administración?

Son algunos de los usuarios finales y están interesados en el flujo de trabajo general. También están contribuyendo a varias áreas de formularios / documentos (cuyo formato no afectará ningún trabajo de desarrollo).

¿Puede recibir comentarios de los otros dos miembros? Algunos gerentes necesitan tener una reunión programada regularmente o nunca podrán incluirla en su agenda.

Obtener tiempo no parece ser un problema en el futuro.

— Enderland
fuente

¿Qué están contribuyendo las otras personas? ¿Son los usuarios previstos de este proyecto? ¿Está trabajando en aspectos no relacionados con el desarrollo (como temas e imágenes del sitio web o un DBA o pruebas de control de calidad)? Otros niveles de gestión / administración?

— Bobson

¿Puede recibir comentarios de los otros dos miembros? Algunos gerentes necesitan tener una reunión programada regularmente o nunca podrán incluirla en su agenda.

— JeffO

Respuestas:

Como desarrollador exclusivo, su mayor problema es la visibilidad. Mi recomendación es hacer ciclos completos de sprint, como en un proyecto Agile. Cada dos semanas, demuestre un poco más de funcionalidad (esto podría ser en una reunión de media hora a una hora de duración. Todos los días tenga un standup explicando lo que hizo ayer, lo que hará hoy y cualquier obstáculo que tenga.

Al hacer esto, se comunicará con los demás exactamente dónde se encuentra el producto en cualquier momento. Se sentirán involucrados, todos sabrán exactamente dónde está el progreso de la construcción del producto y se pueden tomar decisiones para desechar / introducir características según sea necesario.

Y un standup de 10 minutos diariamente solo "desperdicia" una hora a la semana. Tener una demostración de una hora una vez cada quince días limita la exposición de su reunión a un promedio de 1.5h por semana, lo cual no es mucho.

— Stephen
fuente

... and decisions can be made to scrap/introduce features as necessary.<--- Esto. Dado que va a programar estas reuniones con los usuarios, poder mostrar una maqueta e inmediatamente recibir comentarios sobre si satisfará sus necesidades o necesitará revisiones ahorrará tiempo a todos.

— Bobson

Un standup de 10 minutos diariamente "desperdicia" una hora a la semana para cuatro personas ; Esto no es insignificante. Si está entregando en iteraciones, no desea reconsiderar las características elegidas cada @ # $% día, de esa manera yace la locura;)

— Steven A. Lowe

La pausa de 10 minutos tiene dos propósitos: aumentar la visibilidad y permitir que el gerente del proyecto esté lo más informado posible sobre el tiempo. Si espera hasta la reunión quincenal para informarles que tiene una semana de retraso porque tenía este error realmente molesto que tardó una semana en encontrar y solucionar, bueno, eso es realmente malo para todos los demás en el equipo y debilita su confio en ti. El standup diario gestiona el lado humano del desarrollo de software, que es algo que algunos desarrolladores pueden pasar por alto.

— Stephen

@Stephen: si hipotéticamente espera 2 semanas antes de informar a su gerente / equipo acerca de los problemas del proyecto, hay problemas más importantes que las agendas de reuniones. Hay una cosa maravillosa llamada "teléfonos" y "correo electrónico" ...: D ... espera, ¿los desarrolladores son humanos?

— Steven A. Lowe

Ninguna

A menos que tenga algo que requiera una discusión grupal altamente interactiva ( como demostrar una iteración ), o simplemente necesite que lo vean trabajando, atar a 4 personas en una reunión, incluso durante 15 minutos, será un desperdicio.

Las reuniones en persona son la forma de comunicación de mayor ancho de banda disponible; También son la forma más costosa de comunicación. Úselos sabiamente, y solo cuando sea necesario.

— Steven A. Lowe
fuente

Estoy en desacuerdo; Si un proyecto es lo suficientemente importante como para ser lanzado, es lo suficientemente importante como para tener un standup diario. Estas cosas casi nunca duran más de 5 minutos; especialmente si solo hay un desarrollador y un PO. Si se abstiene de cualquier actualización, será mordido en el culo por todas las conversaciones de "espera, eso no es lo que tenía en mente", que suceden demasiado tarde en el proceso, lo que resulta en cambios costosos y largos. Está acortando el ciclo de retroalimentación que debe buscar, no alargándolo.

— Stefan Billiet

@StefanBilliet: si desea acortar el ciclo de retroalimentación, entregue un software que funcione y descuelgue el teléfono. A menudo. No soy fanático de las standups diarias, especialmente para un equipo de uno; la sobrecarga es demasiado alta (tiempo de reunión + tiempo de preparación + tiempo de viaje + tiempo de cambio de contexto + costo de oportunidad) x 4 personas x 5 días / semana = $$$!

— Steven A. Lowe

Creo que estamos hablando de cosas diferentes aquí. Mis / nuestras standups consisten en que me levanto, saludando al PO y caminando hacia nuestro scrumboard, todas las mañanas, a la misma hora. El tiempo de viaje promedio es de aproximadamente 2 segundos, el tiempo de preparación es ninguno, el tiempo de cambio de contexto es ninguno (hágalo antes de comenzar a trabajar) y en cuanto al costo de oportunidad: me ha perdido. Levantar un teléfono puede funcionar, pero sigue siendo menos eficiente que un breve momento cara a cara.

— Stefan Billiet

@StefanBilliet: sí, estamos hablando de cosas diferentes aquí. Estás hablando de los esfuerzos necesarios para que asistir a una de pie, y lo que implica que no hay nadie más involucrado (o que no perder el tiempo prestando atención a ellos si existen);) El PO dice que hay otras 3 personas en el equipo, y sugiere una reunión diaria de 15 minutos sin un propósito obvio.

— Steven A. Lowe

Como dije, si todas las personas involucradas piensan que un enfrentamiento no vale nada, entonces eso significa que las personas que firmaron el proyecto no se preocupan por su progreso. Demuestra que no les importa si todos o no todavía están en camino y si hay problemas o malentendidos (que siempre los hay). Si a esas personas no les importa, entonces ese proyecto debería cancelarse, porque significa que no saben cómo ofrecer un valor significativo y duradero. Y sé que mencionarás levantar el teléfono, pero un standup diario es mucho más propicio para argumentos significativos que una llamada telefónica.

— Stefan Billiet