Qual a estrutura de reunião do projeto que um único desenvolvedor deve escolher?

Sou um desenvolvedor solo trabalhando em um projeto decentemente pequeno com cerca de 3 outras pessoas (não desenvolvedores). Essas outras pessoas estão envolvidas no projeto de maneiras que não são de desenvolvimento e uma delas também é minha gerente. Todo mundo também é bastante aberto a discussões ad hoc.

Meu gerente acabou de me dar o que parece um sonho tornado realidade - fui encarregado de determinar qual estrutura de reunião funcionaria melhor para o projeto. Parece uma maneira maravilhosa de lidar com a sobrecarga de reuniões e / ou reuniões sem sentido .

Com grande poder vem uma grande responsabilidade, como agora, se eu sugerir algo que, em última análise, resulta em muito tempo perdido, é minha culpa.

Nunca tive uma folha em branco para pensar em como estruturaria as reuniões. Meus pensamentos são:

Reunião diária "atualização da base de toque / status" por 15 minutos ou menos (semelhante às reuniões em pé) para comunicar objetivos diários e revisar o dia anterior. Ou, parece que eu poderia simplesmente pegar um quadro branco e colocá-lo na minha mesa para comunicar essas informações.
Conforme as reuniões necessárias para tomar decisões específicas ou resolver perguntas que qualquer equipe tenha

... Não vejo a necessidade de uma reunião semanal do projeto "status". Também não tenho certeza se o segundo item exigiria muitas reuniões agendadas formalmente.

Minha preocupação é que esses "focados no desenvolvedor" (ou seja, eu) possam causar alienação com outras pessoas ou fazer com que meu gerente sinta uma perda de controle no projeto, pois essa estrutura seria consideravelmente diferente da maioria dos projetos executados.

Qual a estrutura de reunião do projeto que um único desenvolvedor deve escolher?

Endereçando comentários:

O que as outras pessoas estão contribuindo? Eles são os usuários pretendidos deste projeto? Trabalhando em aspectos não relacionados ao desenvolvimento (como temas e imagens de sites ou um DBA ou teste de controle de qualidade)? Outros níveis de gerenciamento / administração?

Eles são alguns dos possíveis usuários e estão interessados no fluxo de trabalho geral. Eles também estão contribuindo para várias áreas de formulários / documentos (cujo formato não afetará nenhum trabalho de desenvolvimento).

Você é capaz de obter feedback dos outros dois membros? Alguns gerentes precisam ter uma reunião agendada regularmente ou nunca serão capazes de ajustá-la à sua agenda.

Conseguir tempo não parece ser um problema daqui para frente.

— enderland
fonte

O que as outras pessoas estão contribuindo? Eles são os usuários pretendidos deste projeto? Trabalhando em aspectos não relacionados ao desenvolvimento (como temas e imagens de sites ou um DBA ou teste de controle de qualidade)? Outros níveis de gerenciamento / administração?

— Bobson

Você é capaz de obter feedback dos outros dois membros? Alguns gerentes precisam ter uma reunião agendada regularmente ou nunca serão capazes de ajustá-la à sua agenda.

— JeffO

Respostas:

Como desenvolvedor exclusivo, seu maior problema é a visibilidade. Minha recomendação é fazer ciclos completos de sprint, como em um projeto Agile. A cada duas semanas, demonstre um pouco mais de funcionalidade (isso pode durar meia hora a uma reunião. Todos os dias, há um stand-up explicando o que você fez ontem, o que fará hoje e quaisquer obstáculos que tiver.

Ao fazer isso, você estará se comunicando com os outros exatamente onde o produto está a qualquer momento. Eles se sentirão envolvidos, todos saberão exatamente onde está o progresso da construção do produto e poderão ser tomadas decisões para descartar / introduzir recursos, conforme necessário.

E uma espera de 10 minutos diariamente apenas "desperdiça" uma hora por semana. Uma demonstração de uma hora a cada quinzena limita a exposição da sua reunião a uma média de 1,5h por semana, o que não é muito.

— Stephen
fonte

... and decisions can be made to scrap/introduce features as necessary.<--- Isso. Como você agendará essas reuniões com os usuários, a possibilidade de mostrar uma maquete e obter imediatamente um feedback sobre se elas atenderão às necessidades ou precisarão de revisões economizarão o tempo de todos.

— Bobson

Um stand-up de 10 minutos diariamente "desperdiça" uma hora por semana para quatro pessoas ; isso não é insignificante. Se você está entregando em iterações, você não querer reconsiderar as características escolhidas cada @ # $% dia, que a loucura maneira mentira;)

— Steven A. Lowe

O standup de 10 minutos tem dois propósitos - aumentar a visibilidade e permitir que o gerente de projeto seja o mais informado possível sobre o tempo. Se você esperar até a reunião quinzenal para que eles saibam que você está atrasado uma semana porque teve um bug realmente irritante que levou uma semana para encontrar e corrigir, isso é muito ruim para todos os outros membros da equipe e enfraquece a Confio em você. O stand-up diário gerencia o lado humano do desenvolvimento de software, algo que pode ser esquecido por alguns desenvolvedores.

— Stephen

@ Stephen: se você esperar duas semanas hipoteticamente antes de informar seu gerente / equipe sobre os problemas do projeto, há problemas maiores em jogo do que cumprir as agendas. Existe uma coisa maravilhosa chamada "telefone" e "email" ...: D ... espera, os desenvolvedores são humanos?

— Steven A. Lowe

Nenhum

A menos que você tenha algo que exija uma discussão em grupo altamente interativa ( como demonstrar uma iteração ) ou apenas precise ser visto trabalhando, amarrar 4 pessoas em uma reunião, mesmo por 15 minutos, será um desperdício.

As reuniões presenciais são a forma de comunicação com maior largura de banda disponível; eles também são a forma mais cara de comunicação. Use-os com sabedoria e somente quando necessário.

— Steven A. Lowe
fonte

Discordo; se um projeto é importante o suficiente para ser lançado, é importante o suficiente para se manter diariamente. Essas coisas quase nunca duram mais de 5 minutos; especialmente se houver apenas um desenvolvedor e um pedido. Se você se abster de qualquer atualização, você será mordido por todas as conversas "espere, não era isso que eu tinha em mente", acontecendo muito tarde no processo, resultando em mudanças caras e demoradas. É encurtar o ciclo de feedback que você deve buscar, não prolongá-lo.

— Stefan Billiet 4/13

@ StefanBilliet: se você quiser diminuir o ciclo de feedback, forneça o software em funcionamento e atenda o telefone. Frequentemente. Não é fã de standups diários, especialmente para um time; a sobrecarga é muito alta (tempo de reunião + tempo de preparação + tempo de viagem + tempo de alternância de contexto + custo de oportunidade) x 4 pessoas x 5 dias / semana = $$$!

— Steven A. Lowe

Acho que estamos falando de coisas diferentes aqui. Meus / nossos standups consistem em me levantar, acenar para o PO e caminhar até o nosso scrumboard, todas as manhãs, ao mesmo tempo. O tempo médio de viagem é de cerca de 2 segundos, o tempo de preparação é nenhum, o tempo de mudança de contexto é nenhum (faça isso antes de começar a trabalhar) e quanto ao custo de oportunidade: você me perdeu. Atender um telefone pode funcionar, mas ainda é menos eficiente do que um momento curto face a face.

— Stefan Billiet

@ StefanBilliet: sim, estamos falando de coisas diferentes aqui. Você está falando sobre o esforço necessário para você para participar de um standup, e implicando que não há mais ninguém envolvido (ou que você não perder tempo prestando atenção a eles, se houver);) O OP diz que há 3 outras pessoas na está sugerindo uma reunião diária de 15 minutos sem nenhum objetivo óbvio.

— Steven A. Lowe

Como eu disse, se todas as pessoas envolvidas pensam que um acordo não tem valor, isso significa que as pessoas que assinaram o projeto não se importam com o seu progresso. Isso mostra que eles não se importam se todo mundo ainda está no caminho certo e se há problemas ou mal-entendidos (que sempre existem). Se essas pessoas não se importam com isso, esse projeto deve ser cancelado, porque significa que elas não sabem como gerar um valor significativo e duradouro. E eu sei que você mencionará que atende o telefone, mas uma consulta diária é muito mais propícia a argumentos significativos do que uma chamada telefônica.

— Stefan Billiet