Programando com um grupo de pessoas que eu nunca conheci

O líder deste projeto será a pessoa que se posiciona e assume o controle no começo.

Isso se aplica à maioria das coisas da vida - não apenas ao desenvolvimento de software. Quando todo mundo está correndo como galinhas sem cabeça, a pessoa que pensa sobre as coisas dá um passo à frente e diz: " Isso é o que vamos fazer e como faremos isso " Geralmente, a pessoa é considerada a líder pelo resto do projeto. Tenha em mente que, ao fazer isso, você está assumindo a responsabilidade pelo sucesso ou fracasso final do projeto.

Você quer liderar este projeto? Veja algumas coisas que você pode começar a fazer imediatamente para causar um grande impacto.

1. Use uma ferramenta de gerenciamento de projetos como Trello e envie convites para todos e comece a atribuir partes do projeto a pessoas .
2. Gere um banco de dados de bugs e comece a adicionar tarefas e bugs - novamente, comece a atribuir.
3. Configure um repositório de controle de versão e verifique em um bom bloco inicial de código que todos possam trabalhar. Recuse-se a lidar com qualquer outra forma de controle de código.
4. Ofereça-se para ajudar as pessoas a começar o desenvolvimento, mostrando-lhes como usar o sistema de controle de versão e o banco de dados de bugs.
5. Envie e-mails semanais detalhando o status do projeto e o progresso da semana anterior.

Nenhum desses passos é particularmente difícil ou demorado, mas eles serão enormes poupadores de tempo no futuro. Além disso, fará com que sua equipe converse entre si e os acostume a ver você no comando.

A resposta de Jarrod Nettles praticamente resume muito o que eu sugeriria, então vou contar um pouco do que funcionou em minhas experiências recentes em uma situação semelhante.

Eu sugeriria encontrar alguma maneira de falar com eles vocalmente, em vez de por e-mail. Se você não estiver na mesma área, coloque todos no Skype. Se você estiver na área, encontre-os em um café ou algo assim. Falar pessoalmente nas reuniões iniciais levará você a tomar decisões e realizar o trabalho de vez em quando; Os tópicos de e-mail permitem que aqueles que são tímidos ou que não estão em seu computador possam segurar o processo - todos nós sabemos como os alunos preguiçosos podem ser!

Quando se trata de falar sobre o projeto, eu sugiro passar pelo que você acredita que o projeto envolve. Eu acho que é importante você deixar claro que esta é a sua compreensão, e não um caso de você dizer exatamente o que fazer. Todos devem ser capazes de lançar seus pensamentos e idéias no ringue, se tiverem algum, e você deve sair dessa reunião inicial com uma compreensão decente suficiente do que você, como grupo, acha que o projeto envolve.

Em reuniões (regulares) futuras, você pode começar a examinar diferentes partes do projeto em mais detalhes; veja o que precisa ser feito exatamente, que recursos e quanto tempo será necessário e quem pode fazer o quê. Divida a peça ainda mais, se necessário. Talvez tente definir alguns prazos curtos?

Do any of you have experience with working with a group of people you've never met online, and you don't get to meet them in person but must complete a project together?

Acrescente sub-orçamentos, prazos de pagamento ridículos e venda no rio pelo marketing, e isso parece mais ou menos 65% dos projetos de desenvolvimento de software no mundo real.

Provavelmente, você seria mais bem atendido fazendo com que as pessoas se oferecessem como voluntárias para as peças que elas estariam interessadas em fazer, em vez de assumir o controle unilateralmente e atribuir tarefas. Eles provavelmente estão todos sentados lá pensando em como eles devem tomar conta. Ou como eles podem conseguir algum pobre coitado que se importe demais em fazer todo o trabalho em grupo para que eles possam montar seu grau.

A primeira coisa a fazer em casos como este é estabelecer um rastreador de problemas e aprender como usá-lo .

Para uma introdução mais fundamental sobre como lidar com o desenvolvimento, como você descreve, minha referência favorita vai para o artigo de Martin Fowler Usando um processo de software ágil com o Desenvolvimento Offshore . Este artigo descreve os conceitos básicos e avançados da configuração da comunicação da equipe distribuída:

Use Continuous Integration to Avoid Integration Headaches
Have Each Site Send Ambassadors to the Other Sites
Use Contact Visits to build trust
Don't Underestimate the Culture Change
Use wikis to contain common information
Use Test Scripts to Help Understand the Requirements
Use Regular Builds to Get Feedback on Functionality
Use Regular Short Status Meetings
Use Short Iterations
Use an Iteration Planning Meeting that's Tailored for Remote Sites
When Moving a Code Base, Bug Fixing Makes a Good Start
Separate teams by functionality not activity
Expect to need more documents.
Get multiple communication modes working early

Para o seu projeto, você com certeza não conseguirá seguir todas as dicas e truques mencionados (por exemplo, provavelmente não haverá embaixadores nem visitas de contato para você :), mas vale a pena estudar de qualquer maneira.

• Para muitas equipes tendo tudo de acima seria um exagero, com certeza. Ainda assim, acho muito útil ter uma lista de verificação abrangente assim que mesmo itens ignorados são verificados e têm motivos claramente documentados para a rejeição - apenas para garantir que nada de importante foi perdido.

Você não nos contou quanto tempo você tem para isso, ou o idioma em que você está trabalhando (eu diria que uma única aula é muito pequena, mas talvez no seu idioma seja muito mais).

Primeiro, tenha um produto em funcionamento a qualquer custo.

Se o projeto durar duas semanas ou menos, suponha que você será o único a fazer qualquer coisa e fique muito feliz com qualquer ajuda que receber. Tente agendar as coisas para todos, mas certifique-se de que, se ninguém fizer nada, você ainda terá um produto em funcionamento. Mesmo que alguém faça alguma coisa, não confie em continuar: esteja preparado para qualquer um desistir a qualquer momento.

Se você tiver mais de uma semana, considere programar um dia da semana em que o produto deve ser marcado como um marco e cumpri-lo o máximo possível. Certifique-se de ter algo que você pode chutar e verificar as deficiências de: se o pior acontecer, isso será o que você entregar. Cada um que você criar, você verá o quanto você pode melhorar as coisas, o que o motivará a ir em. Não planeje muito para a frente: claro, você precisa ter uma ideia do resultado final, mas mantenha seus planos mais específicos a curto prazo.

Observe que esses dois se sobrepõem um pouco: isso é intencional, já que duas semanas são, na minha opinião, um pouco de cinza quando é difícil fazer duas iterações, mas trabalhar em uma iteração é arriscado.

Estou assumindo o pior caso, onde você estará trabalhando com pessoas muito novas na programação. Meu conselho geral seria:

• Mantenha uma lista de recursos que você deseja implementar em breve e quem trabalhará neles. Jarrod sugeriu Trello, e eu apoio inteiramente isso: se seus colegas de equipe não são muito experientes, ajudará muito. Você poderia tentar manter os bugs lá também.
• Em uma equipe de quatro pessoas, você precisa do controle de versão. Isso pode deixar os outros mais relutantes em contribuir se não souberem como trabalhar, mas vale a pena.
• Quaisquer dependências externas podem afugentar novatos. Se você escrever testes de unidade, diga às pessoas que elas não devem se preocupar em quebrá-las. Diga às pessoas que elas não devem se preocupar em quebrar a construção, especialmente no começo. É muito mais difícil corrigir pessoas que não cometem código do que aquelas que cometem código de bugs.
• Verifique se as coisas sugeridas aqui se aplicam a você. "Integração contínua" é um termo sofisticado - para um programa pequeno, isso pode significar "este programa é executado e todos os recursos podem ser usados". Você ainda tem sites? A divisão em equipes ajuda você?
• YAGNI, cem vezes. Se você realmente precisa, escreva as coisas antecipadamente para os recursos que você mesmo estará fazendo. Faça funcionar, depois refatorie, ou você não vai conseguir fazer isso funcionar.
• Refatorar. Quando estiver funcionando, gaste algum tempo para consertá-lo. Não se esqueça de que seus colegas de equipe também terão que ler seu código: um dia gasto na correção de peças feias e a substituição de soluções simples por outras de melhor desempenho não é um dia perdido.
• Fique de olho em todas as partes. Percorrer changelogs e, ocasionalmente, ler o código de outras pessoas ajuda a garantir que tudo esteja de acordo com os padrões de qualidade que você deve aplicar e garante que não será tão difícil mergulhar se a pessoa desistir.
• Não hesite em trabalhar na coisa mais importante, ao contrário da sua coisa designada. Se alguém está atrasado, faça uma anotação por escrito disso em algum lugar e faça você mesmo. Pergunte primeiro, mas vá em frente se eles não responderem, ou se você perguntar uma ou duas vezes e depois sentir que eles ainda não o farão.
• Concentre-se em fazer algo de que tenha orgulho. Mesmo se desviar da atribuição. Mesmo se você tiver que cortar grandes recursos em favor de tornar o que você tem mais suave. Cada iteração pensa "Estou orgulhoso disso?", E na próxima iteração, tente consertar essas coisas.

Eu tive um projeto que falhou horrivelmente recentemente; você pode ler meus pensamentos sobre o motivo da falha se quiser, mas isso resume como Eu faria algo assim se tivesse outra chance.

A resposta de Jarrod Nettles é boa. Eu adicionaria isso:

1. Espere que pelo menos uma das outras três pessoas seja completamente inútil.
2. Apenas aceite que você sentirá que está fazendo a maioria (ou todos) do trabalho, mas todos receberão o mesmo crédito. Qualquer tentativa de tentar tornar as coisas "justas" só irá causar conflitos desnecessários e atrasá-lo.
3. Mantenha contato com qualquer membro da equipe que seja bom. Essas pessoas são difíceis de encontrar e você vai querer trabalhar com elas novamente.

Eu tenho estado em uma posição similar algumas vezes, como tenho certeza de ter muitas pessoas. A principal coisa é fazer o melhor para manter todo o conteúdo contente e feliz, então eu acho que é bom que você queira assumir a tarefa de líder de equipe, mas como alguém mencionado acima - isso precisa ser abordado com cuidado como outra pessoa. pode sentir que deveria fazer o trabalho em vez disso.

Eu sei que você disse que ninguém se preocupou em contatar um ao outro, mas às vezes essas situações podem ser difíceis para as pessoas, como você disse que está trabalhando com pessoas que você nunca conheceu e pode ser difícil se comunicar etc.

Gostaria de começar com um e-mail abordando todos e deixando-os saber quem você é, como você acha que o projeto deve ser abordado e informar que você deseja liderar o projeto, definindo papéis, metas, prazos, tempo de comunicação , meetups (se desejado / desejado) e atualizações de projetos.

Embora você não possa influenciar completamente outras pessoas, você pode acompanhar quem está fazendo o quê e quem não está. Delegar tarefas permite que o trabalho seja dividido de maneira uniforme ou apropriada para pessoas com diferentes conjuntos de habilidades ou níveis.

Desta forma, se determinado trabalho não está sendo feito, você pode assumir a responsabilidade de dividir o trabalho entre as pessoas que estão realmente interessadas em trabalhar nele. Desta forma, você não vai acabar com um projeto com falha no final e você terá registros de tentar comunicar datas, horários e todas as informações relevantes que você pode mostrar no final, se as coisas derem errado. TODAS as coisas que mantêm você na direita, se algumas pessoas não puxarem o peso.

Em termos de dicas:

Pessoalmente, adoro um ambiente de trabalho colaborativo encontrado aqui: link

Isso permite que você compartilhe documentos do Word, planilhas, etc. É uma ótima maneira de trabalhar colaborativamente. Eu não posso enfatizar o quão útil isso é às vezes. Eu uso com algumas pessoas com quem trabalho e que não estão no país no momento.

Espero que isso ajude alguém, há tantos aspectos de liderar um projeto que poderíamos continuar para sempre, mas isso depende de muitas coisas. Pelo menos isso é um pouquinho para ajudar.