Programando com um grupo de pessoas que nunca conheci


50

Fui designado a um projeto de grupo da minha aula de ciências da computação em AP e sou obrigado a trabalhar com outras três pessoas. Eu nunca conversei com eles antes, não tenho idéia do nível de habilidade deles e tudo o que tenho é o endereço de e-mail deles. A tarefa, resumida, é a seguinte:

"Como equipe, você completará no mínimo três módulos para uma classe ..."

Vou tentar me tornar "capitão da equipe" porque nenhum deles tentou entrar em contato, mas estou curioso: como fazer isso? Enviei um e-mail para eles e perguntei se existem métodos de comunicação que eles preferem em vez de enviar um ao outro, mas assim que iniciarmos o projeto, terei que descobrir quem está fazendo o que.

O que devo fazer? Como "assumo o cargo" e lidero três pessoas que nunca conheci?

Aqui está um trecho da tarefa real:

Portanto, você precisará discutir as várias funções que cada membro da equipe assumirá neste projeto no início da semana. Você pode se comunicar via Pronto (ou Blackboard IM), e-mail, wiki, grupo do Google, blog ou qualquer outro método que achar melhor. Se um membro do grupo não participar do grupo até o final da semana, informe seu instrutor e ele fornecerá orientações adicionais.
...
Também no final de um projeto, haverá uma avaliação da equipe na qual você avaliará a contribuição de cada membro da equipe para a conclusão deste projeto, juntamente com uma nota sugerida.

Edit: Muitas pessoas sugeriram que eu os encontrasse em uma cafeteria, ou algo assim. O único problema é que todos nós estamos em estados diferentes. Também descobri que um deles não tem permissão para usar o Facebook / Skype / twitter, então tenho que recorrer a enviá-los por e-mail pelo yahoo messenger e e-mails.


10
Que tal "conversar com esse pessoal", "conhecê-lo", "ouvir o que eles querem desse projeto" e "pensar com a mente" em vez de perguntar ao SE sobre direções ... isso não pode lhe dar? Ninguém aqui os conhece. Quero dizer, se eles tivessem alguma disfunção comportamental e se estivessem em uma posição de poder, pedir orientações poderia fazer sentido ... mas esses são apenas homens como você. Você está em uma caixa de areia: é hora de descobrir as coisas.
ZJR

6
@zjr Quem queimou seu ganso? É claro que estou trabalhando com eles e tentando descobrir as coisas. Mas eu queria receber conselhos de pessoas que lidaram com essa tarefa antes, em vez de apenas fazer esse projeto às cegas. Também as pessoas mencionaram ótimas aplicações de gerenciamento de projetos e eu aprendi algumas coisas novas.
7772 Gabriel

2
@ZJR Não sei se esse é o objetivo de sua pergunta. Embora ele tenha dito que realmente não havia se comunicado com eles antes, sua pergunta era a respeito de se tratar de um projeto de programação e como ele deveria abordá-lo com a equipe com quem ele havia lidado.
Jarrod Nettles

Respostas:


90

O líder deste projeto será a pessoa que intensifica e assume o comando no início.

Isso se aplica à maioria das coisas na vida - não apenas ao desenvolvimento de software. Quando todo mundo está correndo como galinhas sem cabeça, a pessoa que pensa nas coisas avança e diz: " É isso que vamos fazer e é assim que vamos fazer ". geralmente é a pessoa considerada o líder para o restante do projeto. Lembre-se de que, ao fazer isso, você assume a responsabilidade pelo sucesso ou fracasso final do projeto.

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

  1. Use uma ferramenta de gerenciamento de projetos como o Trello e envie convites para todos e comece a atribuir partes do projeto às pessoas.
  2. Gere um banco de dados de bugs e comece a adicionar tarefas e bugs - novamente, apenas comece a atribuir.
  3. Configure um repositório de controle de versão e verifique um bom pedaço inicial de código no qual 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 avançar no desenvolvimento, mostrando-lhes como usar o sistema de controle de versão e o banco de dados de erros.
  5. Envie e-mails semanais detalhando o status do projeto e o andamento da semana anterior.

Nenhuma dessas etapas é particularmente difícil ou demorada, mas economizarão muito tempo no caminho. Além disso, ele fará com que sua equipe converse e acostume-se a vê-lo no comando.


17
Se dois membros da equipe tentarem essa abordagem, tenha cuidado. Uma luta para controlar e liderar pode ser um desastre - muito pior do que um bando de colegas de trabalho que não fazem nada.
Corbin março

3
@CorbinMarch Concordado. Isso só funciona se houver uma clara falta de liderança na equipe - todo mundo esperando por alguém para fazer as coisas acontecerem. Se já houver outra pessoa emergindo como líder, a melhor coisa que você pode fazer pelo seu projeto é apoiá-la e apoiá-la.
Jarrod Nettles

4
Depois de ler isso, verifiquei o Trello e fui instantaneamente seduzido por sua simplicidade. +1 para o link. Se há uma maneira de instalar essa coisa localmente, seria a coisa mais perfeita ...
Radu Murzea

2
The leader of this project will be the person who steps up and takes charge at the beginning.Todos saúdam o Overlord do Blog :)
yannis

5
Que tal apenas encontrá-los em uma cafeteria? Como você atribuirá tarefas a eles, se você não tem idéia de quais habilidades eles têm? Pessoalmente, eu não gosto de receber e-mails "Aqui está o Trello, aqui está um rastreador de erros e aqui estão as suas tarefas" sem conhecer ninguém antes.
7772 Simon

24

A resposta de Jarrod Nettles resume bastante o que eu sugeriria, portanto, mostrarei um pouco do que funcionou em minhas experiências recentes em uma situação semelhante.

Eu sugeriria encontrar uma maneira de conversar com eles vocalmente, e não por e-mail. Se você não estiver na mesma área, obtenha todos no Skype. Se você estiver na área, encontre-os em uma cafeteria ou algo assim. Falar pessoalmente nas reuniões iniciais levará você a tomar decisões e realizar o trabalho naquele momento; os encadeamentos de e-mail permitem que aqueles que são tímidos ou que não estão no computador continuem o processo - todos sabemos como os alunos podem ser preguiçosos!

Na sua primeira reunião, eu tentaria conhecer seu grupo tentando continuar com o projeto - mas não o ignore! 10 ou 20 minutos gastos na quebra de gelo provavelmente são suficientes entre 4 pessoas.

Quando se trata de falar sobre o projeto, sugiro analisar o que você acha que o projeto envolve. Acho importante que você esclareça que esse é o seu entendimento, e não o caso de você dizer exatamente a eles o que fazer. Todos devem poder colocar seus pensamentos e idéias no ringue, se houver, e você deve sair dessa reunião inicial com uma compreensão suficientemente decente do que você, como grupo, sente que o projeto implica.

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


4
+1 por mencionar o contato de voz. Pessoalmente, é o melhor, videochat é o melhor, a chamada em conferência ainda melhor do que apenas o correio.
Barend

@andybursh Infelizmente, um aluno não pode usar nem o facebook. Portanto, o Skype está fora de questão ... espero que possamos descobrir as coisas através de texto.
7772 Gabriel

10

Algum de vocês tem experiência em trabalhar com um grupo de pessoas que nunca conheceu on-line e não os conhece pessoalmente, mas deve concluir um projeto juntos?

Acrescente sub-orçamentos, prazos ridículos e seja vendido no rio pelo marketing e isso soa como aproximadamente 65% dos projetos de desenvolvimento de software no mundo real.

Você provavelmente seria melhor servido por pessoas voluntárias para as partes que eles estariam interessados ​​em fazer, em vez de assumir o comando unilateralmente e atribuir tarefas. Provavelmente, todos estão sentados, pensando em como devem assumir o comando. Ou como eles conseguem um pobre coitado que se preocupa demais em fazer todo o trabalho em grupo para que ele possa andar na nota dele.


2
Você esqueceu o fato de que muitos de nós temos que trabalhar com equipes offshore que nunca conhecemos antes.
Maple_shaft

7

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

Para uma introdução mais fundamental sobre como lidar com o desenvolvimento como você descreve, minha referência favorita é para o artigo de Martin Fowler, Usando um processo de software ágil com desenvolvimento offshore . Este artigo descreve os conceitos básicos e avançados da configuração da comunicação de 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 será capaz de seguir todas as dicas e truques mencionados lá (por exemplo, provavelmente não haverá embaixadores nem visitas de contato para você :), mas vale a pena estudar de qualquer maneira.

  • Para muitas equipes, todas as opções acima seriam um exagero, com certeza. Ainda assim, acho realmente útil ter uma lista de verificação abrangente como essa - para que até os itens ignorados sejam verificados e tenham razões claramente documentadas para a rejeição - apenas para garantir que nada importante seja perdido.

6
Eu concordo com esses pontos, mas sua equipe está se unindo apenas por um tempo muito curto, e a maioria dessas sugestões seria um exagero para o que ele precisa. Muito aplicável, porém, para avançar mais as equipes permanentes.
Jarrod Nettles

@JarrodNettles que é um bom ponto graças - Eu atualizei a resposta
mosquito

3
... sim, vamos levá-los ao inferno da burocracia, em vez de deixá-los produzir qualquer código real. por favor.
21412 ZJR

11
@ZJR Como eu disse, a lista dele é pouco extensa para esse tipo de projeto, mas a organização adequada da equipe e do código permitirá que eles produzam código de trabalho em vez de apenas o código em suas telas.
Jarrod Nettles

@ZJR bem para as coisas listadas por Fowler Prefiro seguir padrões "burocráticos". Ideia de inventar minhas próprias formas criativas para rastrear bugs, integrar as alterações de código e conhecimento da equipe share de alguma forma simplesmente não ilumine meu fogo
mosquito

5

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

Primeiro de tudo, tenha um produto funcional a qualquer custo.

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

Se você tiver mais de uma semana, considere agendar 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 em que possa chutar e verificar as deficiências: se o pior acontecer, será isso que você entregará. Cada um que você criar, verá o quanto você poderia melhorar as coisas, o que o motivará a seguir em frente. em. Não planeje muito adiante: claro, você precisa ter uma idéia do que vai acabar, mas mantenha seus planos mais específicos a curto prazo.

Observe que essas duas se sobrepõem um pouco: isso é intencional, pois duas semanas é, na minha opinião, um pouco de uma área cinzenta onde é difícil realizar duas iterações, mas apenas trabalhar em uma iteração é arriscado.

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

  • Mantenha uma lista dos recursos que deseja implementar em breve e quem trabalhará neles. Jarrod sugeriu o Trello, e eu apoio inteiramente isso: se seus colegas de equipe não forem muito experientes, isso ajudará muito. Você pode tentar manter os bugs lá também.
  • Em uma equipe de quatro, você precisa de controle de versão. Pode deixar outras pessoas mais relutantes em contribuir se não souberem como trabalhar, mas vale a pena.
  • Quaisquer dependências externas podem assustar iniciantes. 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 interromper a construção, principalmente no início. É muito mais difícil corrigir pessoas que não confirmam nenhum código do que aquelas que cometem código de buggy.
  • Verifique se as coisas sugeridas aqui realmente 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ê tem sites? A divisão em equipes ajuda você?
  • YAGNI, cem vezes. Se você realmente precisar, escreva as coisas com antecedência para os recursos que você estará criando. Faça com que funcione, depois refatore, ou você não conseguirá fazê-lo funcionar.
  • Refatorar. Quando estiver funcionando, dedique algum tempo a corrigi-lo. Não esqueça que seus colegas de equipe também terão que ler seu código: um dia gasto consertando peças feias e substituindo soluções simples por soluções com melhor desempenho não é desperdiçado.
  • Fique de olho em todas as partes. Observar os 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 seja tão difícil entrar em detalhes se a pessoa desistir.
  • Não hesite em trabalhar na coisa mais importante, em oposição à sua coisa designada. Se alguém estiver atrasado, anote isso em algum lugar e faça você mesmo. Pergunte a eles 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 se orgulha. Mesmo que se desvie da atribuição. Mesmo se você precisar cortar grandes recursos para tornar o que você tem mais suave. Toda iteração pensa "Tenho orgulho 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 porquê de ter falhado, se quiser, mas isso resume como eu faria algo assim se tivesse outra chance.


Leitura interessante, eu estive em situações semelhantes e parece algumas das falhas são muito comuns
Joe Taylor

4

A resposta de Jarrod Nettles é boa. Eu acrescentaria 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 a totalidade) do trabalho, mas todos receberão o mesmo crédito. Qualquer tentativa de tentar tornar as coisas "justas" só causará conflitos desnecessários e atrasará você.
  3. Mantenha contato com todos os membros da equipe que sejam bons. Essas pessoas são difíceis de encontrar e você desejará trabalhar com elas novamente.

Eu discordo de seus dois primeiros pontos. Não espere o pior das pessoas ou é isso que você terá. Você criará ressentimento e poderá perder o apoio de membros úteis da equipe se sentirem seu desdém. Mentoring aquele garoto que não está familiarizado com o idioma pode ser uma ótima experiência e reduzir sua carga de trabalho. (Mas esteja atento às sanguessugas que se recusam a pensar.) Além disso, o projeto tem uma "avaliação de equipe" para que quem faz o trabalho possa obter crédito. (Ou quem fez todos se sentirem sujos não recebe nada.) Seja brutalmente honesto e não se preocupe com o fato de o cara que não fez nada falhar. É justo para sua equipe.
Idlii

3

Eu já estive em uma posição semelhante algumas vezes, pois tenho muitas pessoas. O principal é que você faça o possível para manter todos satisfeitos e felizes, então eu acho que é bom que você queira assumir a tarefa de líder de equipe, no entanto, como alguém mencionado acima - isso precisa ser abordado com cuidado como outra pessoa pode achar que eles deveriam fazer o trabalho.

Sei que você disse que ninguém se encarregou de entrar em contato, mas às vezes essas situações podem ser difíceis para as pessoas, como você disse que está trabalhando com pessoas que nunca conheceu e que pode ser difícil se comunicar etc.

Gostaria de começar com um e-mail apenas abordando todos e informando quem você é como você acha que o projeto deve ser abordado e informando que você deseja liderar o projeto, assumindo a responsabilidade de definir funções, meta, prazos, tempo de comunicação, encontros ( se desejado / desejado) e atualizações do projeto.

Embora você não possa influenciar completamente outras pessoas, você pode acompanhar quem está fazendo o que e quem não está. A delegação de trabalhos permite que o trabalho seja dividido de maneira uniforme ou adequada a pessoas com diferentes conjuntos de habilidades ou níveis.

Dessa forma, se determinado trabalho não estiver sendo realizado, você pode dividir o trabalho entre as pessoas que realmente desejam trabalhar nele. Dessa forma, você não terminará com um projeto com falha no final e terá registros de tentativas de comunicar datas, horários e todas as informações relevantes que você pode mostrar no final, se algo der errado. Todas as coisas que o mantêm certo se algumas pessoas não exercem seu peso.

Em termos de dicas:

Pessoalmente, adoro um ambiente de trabalho colaborativo encontrado aqui: https://docs.google.com/

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

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


Bem-vindo ao P.SE! +1 para o conselho aqui. Bom conselho.
Jarrod Nettles
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.