Este é um tema em que existe muita divergência e não existe uma maneira certa de se lidar. Trabalhar em grupo é essencial em qualquer tipo de projeto que se tenha de desenvolver em grupo ou projetos de desenvolvimento de software. Antes de mais, quero deixar claro que o que eu vou passar é um nincho do que é trabalho de grupo e são apenas experiências que eu passei. Muitas pessoas passaram por experiências diferentes em diferentes contextos. Podem ter passado por experiências diferentes das minhas, mas sinceramente o que eu passei levou a ter uma visão cautelosa com os trabalhos de grupo. Sei que muita gente não pensa assim, mas a realidade é que muitas pessoas têm comportamentos anti trabalho de grupo e que prejudica quem quer trabalhar ou levar um projeto até ao fim.
Um exemplo do que eu passei é de elementos de equipa que empurravam o trabalho com a barriga e depois chegava ao fim e estava soberbado de trabalho e depois tinha de fazer tudo e não tinha sequer tempo para outras coisas. Isso não é saudável. Conheço gente que faz tudo à pressa e eu não sou apologista disso porque existe outras coisas além desse projeto ou trabalho em específico.
Outra coisa que eu vejo muito é falta de planeamento do projeto em equipa e resistência à obtenção de novos conhecimentos e novas ideias. O que eu quero dizer com isso ?
No caso de desenvolvimento de software, em algumas empresas existe falta de planeamento do projeto ou seja design de software e arquitetura bem estruturada. Porque isso às vezes acontece ?
Tal como referi num post sobre as arquiteturas de software e em que abordei a Clean Architecture, existe por vezes a decisão entre MVC ou outra arquitetura. Por vezes é melhor MVC do que Clean Arch. Mas se houver um longo prazo de tempo, porque não optar por um design de software mais elaborado ?
Tal como referi num post sobre as arquiteturas de software e em que abordei a Clean Architecture, existe por vezes a decisão entre MVC ou outra arquitetura. Por vezes é melhor MVC do que Clean Arch. Mas se houver um longo prazo de tempo, porque não optar por um design de software mais elaborado ?
Quanto à dificuldade de aprender novos conhecimentos, refiro-me à situação de sismar com uma situação numa altura errada. Imaginemos, a nossa base de dados já está completamente modelada. Isto não tem haver com mudança de requisitos, mas sim com decisão de abordagem de equipa. Um domínio de negócio tem vários contextos e a forma como modelo o domínio pode não ser a mesma forma como outra pessoa modela o domínio. Para o mesmo domínio pode haver várias interpretações. No entanto, o domínio é algo que é muito difícil de mudar principalmente quando o projeto já está a meio. Isto significa que existe dúvidas relativamente ao domínio e que nem tudo foi esclarecido com os domain experts e foram seguidas premissas que são erradas segundo esses domain experts. Isto não é um bom design de software. Imaginemos uma cantina escolar.
Como é que uma refeição de uma cantina é definida ?
Pensemos um bocado no GIAE Online que havia nas escolas básicas antigamente. Vocês devem ter tido um cartão de estudante e tinham uma máquina tátil para tirar senhas. Quando vocês tiravam a senha tinham as senhas da semana e pagavam uma quantia por cada senha.
O que é uma refeição ? O que é uma senha ?
Uma refeição é algo que vai ser consumido numa dada altura. E o que essa refeição é ? Essa refeição é constituido por um prato("massa à bolonhesa, rojões à moda do Porto e etc") e cada prato tem um tipo de prato que pode ser: peixe, carne, dieta e vegetariano. E uma senha o que é ?
É uma reserva de uma refeição que foi paga e pertence a um utilizador(estudante, professor, funcionário, convidado).
Algumas pessoas neste caso interpretam a refeição como o prato de carne à bolonhesa. Mas será que isso faz sentido ? No senso comum, faz sentido, mas na lógica não faz. Vou explicar.
Imaginemos que no planeta Terra que o unico prato que existia era carne à bolonhesa. O prato é sempre o mesmo para todos os contextos. Uma refeição tem uma data e uma hora. Eu como às 12h do dia e às 20h da noite. Portanto, o prato mudou por ser a refeição ? Não. Isto em modelação de domínio e na base de dados as refeições podem ter o mesmo prato e o prato não muda por causa da refeição.
Discutir isto a meio de um projeto é uma prática totalmente errada... E aliás se o pensamento sobre o domínio de negócio for este, o pensamento do prato ter várias refeições é o mais indicado e não o pensamento do prato ser a refeição. Claro que isto vai depender do domínio, mas no caso das cantinas escolares normalmente seguem este tipo de raciocínio na implementação a menos que haja outras situações a nível de domínio.
Outra coisa é a falta de compromisso com a equipa. Detesto combinar uma hora e chegar a essa hora ou porque 'o piriquito morreu', ou 'porque espetei-me contra uma parede e fui para o hospital'. Se isso tivesse acontecido, a pessoa não avisaria antes ? E quando as pessoas dão ghost totalmente e eu à espera ?
Outra coisa é a falta de compromisso com a equipa. Detesto combinar uma hora e chegar a essa hora ou porque 'o piriquito morreu', ou 'porque espetei-me contra uma parede e fui para o hospital'. Se isso tivesse acontecido, a pessoa não avisaria antes ? E quando as pessoas dão ghost totalmente e eu à espera ?
Ui eu arrelio-me com isso.
Já vos apresentei algumas coisas que acontecem em trabalho em equipa inclusive desenvolvimento de software e agora como é que se lida com isso ?
Quanto a situação de empurrar as coisas pela barriga, temos que pensar o seguinte. Só faz falta quem está presente. E neste caso se só eu é que estou presente então a responsabilidade sobre o trabalho é minha e eu estou no controle.
Para a situação de empurrar as coisas pela barriga, um bom project plan também ajuda e definir um horário de trabalho é uma estratégia para lidar com a situação, agora é preciso que as pessoas cumpram o horário.
Quanto à situação de discutir sobre coisas que vão regredir o projeto, o planeamento é essencial mesmo que mudança de requisitos aconteça. E ás vezes não são os requisitos que mudam e sim a divergência de ideias. Se a ideia que falei da cantina foi a que o negócio englobava então, essa é a abordagem que deve se seguir porque o domínio é algo que é muito difícil de mudar.
Quanto à arquitetura é preciso ver o tempo que se tem.
E a falta de compromisso, é preciso assumir o compromisso. O que tem de ser tem muita força já dizia os Deolinda.
Em suma, trabalhar em equipa é algo que é muito complicado e que todos têm experiências negativas e todos têm experiências positivas. Mas ver a experiência de várias pessoas sobre este assunto, aprende-se sempre algo novo. Se eu perguntar a fulano sobre este assunto, ele vai ter opinião diferente. Se eu perguntar a fulana, ela vai ter opinião diferente. Mas uma coisa é muito importante, é definir o que é realmente importante num trabalho em equipa.