Questão:
Como posso convencer meu chefe de que o desenvolvimento de software precisa ser feito em equipe?
Mintri
2019-12-05 15:38:04 UTC
view on stackexchange narkive permalink

Sou desenvolvedor de software em uma empresa de 30 pessoas especializada em tecnologia financeira. Comecei a trabalhar aqui no início deste ano. Com o tempo, ouvi dizer que a empresa triplicou o número de funcionários nos últimos 3 anos. A organização de trabalho pode ser descrita como "mentalidade inicial", na melhor das hipóteses. Há muito gerenciamento de projetos de piso, de repente você começa a trabalhar na cozinha e assim por diante. Cada desenvolvedor faz o que precisa ser feito a seguir, independentemente de seus pontos fortes, pontos fracos ou experiência. Mas o mais estranho é que cada desenvolvedor trabalha sozinho em um projeto de desenvolvimento de software completo, complexo o suficiente, que nenhum outro desenvolvedor pode assumir em caso de doença. Além disso, um projeto só pode avançar se o desenvolvedor do projeto específico estiver disponível. Dependendo dos anos que o desenvolvedor trabalhou na empresa, pode acontecer que 4 projetos precisem desse recurso de desenvolvedor específico, se os clientes fizerem solicitações de mudança.

Aprendi gerenciamento ágil de projetos em uma grande empresa, e Eu amo isso. Aprendi muito sobre gerenciamento de projetos por conta própria e tive pouca experiência nisso, então na minha conversa de final de ano com meu chefe eu propus a ele, que acho que precisamos começar a trabalhar em equipes. Ele estava cético. Eu analisei os números na frente dele, porque trabalhar em equipe beneficia a empresa e contei as diferentes melhorias de habilidades soft, o trabalho em equipe no desenvolvimento de software coloca você no topo.

No final, ele recusou tudo com a expressão: isso tudo soa como colocar 2 homens no mesmo cargo, o que não é econômico e nossa pequena empresa não pode pagar por isso.

Fiquei tão perplexo ao ouvir a resposta de "2 homens no mesmo cargo" sobre a defesa do trabalho em equipe, que simplesmente silenciei.

Gosto de trabalhar aqui, mas odeio como trabalhamos, enquanto vejo como poderíamos ser muito melhores em tudo, se pudéssemos começar a organizar claramente a empresa e trabalhar juntos e não apenas trabalhar de alguma forma entre si.

Como posso convencer meu chefe de que o trabalho em equipe não é "2 homens no mesmo cargo"?

Qual é a sua capacidade no lugar da função?Você é um gerente ou um dos desenvolvedores trabalhando em um projeto solo?
"mentalidade de inicialização" é apenas uma nova palavra para não organização.Ter que defender o compartilhamento de conhecimento como você está longe de ser uma mentalidade de startup ...
@JayGould sou um dos desenvolvedores.
@LaurentS.eu simplesmente não consegui encontrar um texto melhor :)
@JoeStrazzere bem eh admite que meio que queremos ser ágeis, mas na verdade é apenas gerenciamento do caos.
Em vez de se concentrar em mudar o local de trabalho, concentre-se no que você pode aprender.Quando sentir que não está mais aprendendo ou que sua frustração é simplesmente insuportável, saia e encontre uma empresa mais estruturada.Problema resolvido.
Seis respostas:
520 says Reinstate Monica
2019-12-05 16:39:48 UTC
view on stackexchange narkive permalink

Aumente o fator de barramento

Uma pessoa trabalhando em um pedaço de software significa que apenas uma pessoa conhece o funcionamento interno desse pedaço de software. O que acontece se essa pessoa for atropelada por um ônibus? Sai da empresa? A demissão tem efeito imediato? Está doente? Não é possível contatá-lo durante uma crise?

A vida acontece, e os motivos pelos quais uma única pessoa não consegue mais trabalhar em projetos, seja temporária ou permanentemente, são abundantes e comuns. Ter pelo menos uma segunda pessoa nesse trabalho é uma boa apólice de seguro contra as eventualidades da vida moderna.

Veja o desenvolvimento do VKD3D, uma camada de compatibilidade DirectX12 para Vulkan. O fundador do projeto e um dos principais programadores, Józef Kucia, que tinha 30 anos na época, teve um acidente fatal enquanto explorava uma caverna de neve (Jaskinia Wielka Śnieżna) nas montanhas Tatra (Polônia) no início deste ano.

Se ele fosse o único desenvolvedor, todo o projeto estaria ferrado; o projeto é muito complexo para alguém simplesmente pegá-lo sem qualquer tipo de documentação, o que, se você for a única pessoa trabalhando no trabalho, simplesmente não terá tempo para fazer.

Eu trouxe esse ponto.Mas meu chefe acredita em nossa experiência.Bem, eu mostrei que posso de alguma forma pegar um projeto de 10 anos com código legado horrível e quase 0 documentação.temos 2 seniores que estão na empresa há mais de 10 anos, no total a empresa tem 13 anos.E sem meu chefe ser arrogante, ele afirmou que, de alguma forma, sempre funciona de uma maneira ou de outra, e 13 anos de crescimento e sucesso não podem estar todos errados.
Nada disso vai importar em uma crise.Se você precisa de uma correção crítica e seu cliente precisa que isso seja feito * agora *, você não pode simplesmente designar pessoas para uma tarefa e esperar que elas o atualizem. Você pode ter sido capaz de, eventualmente, alcançar um projeto de 10 anos com um código ruim, mas poderia fazer isso em um cenário de emergência?O problema da sorte é que eventualmente acaba.Quando isso acontecer, você precisa de um plano B
Eu concordo completamente com você.Eu meio que vejo que as conquistas desta empresa vêm de 60-70 horas semanais de trabalho do meu chefe, uma mão cheia de desenvolvedores realmente locais e confiáveis e muita sorte, nada sério nunca apareceu.mas isso dificilmente pode ser chamado de sucesso por método.Eu meio que me sinto em uma situação em que tento contar a uma criança.para não tocar no fogo, porque está quente.Contanto que não haja nenhum acidente ao qual reagir.Ele parece ser o tipo de pessoa frio e analítico superdimensionado.E dizer aos clientes que um projeto precisa congelar algum tempo, por causa de um acidente fica mais barato do que 2 homens no mesmo posto de trabalho.
Bem, como a criança que quer tocar no fogo, ela só vai ter que aprender da maneira mais difícil.Ele aprenderá um dia que, na verdade, sua matemática de custo / retorno simplesmente não está somando;não apenas dois desenvolvedores podem cobrir muito mais terreno do que um, mas também significa que menos bugs entram em produção porque o testador não está fazendo seu próprio dever de casa e é muito mais provável que você tenha alguém capaz de responder em uma crise.Se uma grande vulnerabilidade de segurança for encontrada nos produtos, os clientes não aceitarão 'tempo de congelamento';eles vão parar de usá-lo e colocar a empresa na lista negra de contratos futuros.
@520saysReinstateMonica Embora eu concorde totalmente com sua resposta, deixe-me corrigir um ou dois detalhes sobre o fator de ônibus.
@iLuvLogix que correções você tem em mente?
veja minha edição ..;)
@iLuvLogix Ahh eu vejo isso.Sim, é uma boa adição!Fiz uma pequena edição para esclarecer que não estamos falando de duas pessoas na mesma equipe
@520saysReinstateMonica np, eu só queria corrigir o fato de que ele não foi morto - ele infelizmente morreu em conseqüência de um acidente e que tinha 30 anos ..
@iLuvLogix ~~ você pode estar confundindo-o com Jozef Kucias, que tinha 30 anos, mas morreu há um século.O desenvolvedor do VKD3D tinha 28 anos - Deixa pra lá.Codeweavers atualizou seu blog, mas os artigos de notícias não.
@520saysReinstateMonica Por favor, corrija-me se eu estiver errado, mas ele não morreu em [2019] (https://www.winehq.org/news/2019091101)?Se eu estiver errado, sinto muito, meu mal - mas ainda é um exemplo triste, mas verdadeiro a ser usado em relação ao fator de ônibus .. link para [codeweavers] (https://www.codeweavers.com/about/ blogs / jwhite / 2019/09/08 / a-tragic-loss)
@iLuvLogix você está correto, Józef Kucia morreu em 2019. É um exemplo muito triste.
Daniel
2019-12-05 19:38:44 UTC
view on stackexchange narkive permalink

Você não vai mudar a cultura da empresa da noite para o dia!

Vamos encarar:

  • você é 1 em 30 funcionários , a maioria deles provavelmente está acostumada ou até mesmo gostando da maneira como é feito agora
  • Você não está em uma posição de poder (gerente etc.)
  • Você foi contratado para fazer um trabalho diferente (Desenvolvimento)
  • Você é relativamente novo na empresa

Portanto, o peso da sua opinião é relativamente pequeno. Pergunte a si mesmo: Se eu não consegui mudar esta parte, quero continuar trabalhando aqui. Se não, comece a procurar outro emprego. Se você ainda gosta de manter o emprego, prepare-se para uma longa jornada.

Você pode influenciar a cultura da empresa com o tempo e aos poucos. Mas você não os mudará durante a noite e nunca obterá 100% do que você acha que deveria ser feito.

Eu sugiro que você dê pequenos passos para melhorar a colaboração. Converse com suas faculdades e veja o que estão pensando. Talvez você possa introduzir padrões de codificação? Standups semanais para pelo menos ter uma ideia do que os outros estão fazendo? Um wiki para problemas conhecidos ... etc. Coisas pequenas que não assustam seu chefe, mas melhoram um pouco o trabalho em equipe.

Além disso, se houver obstáculos e dificuldades que possam ser atribuídos a práticas de desenvolvimento ruins, você pode relatar eles. Porém, não jogue o jogo da culpa. Sempre fique neutro, objetivo e sugira melhorias acionáveis. Ninguém gosta de ouvir um profeta do Juízo Final divagar sobre como tudo está ruim.

Algum dia, algo realmente vai dar errado - especialmente se a empresa continuar crescendo assim. Se isso acontecer, espero que você tenha estabelecido uma visão de futuro e cheia de ideias para melhorias. Resista ao impulso de dizer eu-avisei! Ofereça sua ajuda!

Se você está preparado para colocar muito esforço extra e muita paciência com pouca expectativa de retorno, às vezes pode mover algo. Eu sugiro que você leia um pouco sobre o tópico: "conduzindo de baixo para cima"

nunca pensei em "liderar de baixo" definitivamente vou procurar, obrigado. Estou trabalhando há quase um ano nesta empresa.Não percebi tudo isso no início, pois havia muito o que fazer no primeiro dia, mas meu cérebro de desenvolvedor não consegue parar para tentar otimizar as coisas. Agora é meio que uma solução para mim somar outras coisas com as quais não estou muito feliz, mas como prefiro consertar as coisas do que recomprar, tentei o meu melhor para consertar a situação.Mas estava fadado ao fracasso, que isso introduziria minha despedida nesta empresa.Obrigado pela ótima resposta!
@Mintri Eu ouvi você, sobre o "bastante consertar as coisas", mas, infelizmente, mudar uma organização pode ser uma tarefa bastante difícil, mesmo quando bem-vinda pela administração.É por isso que existe todo um campo chamado "gerenciamento de mudanças".Espere muito trabalho e frustração e não muito obrigado por isso.No entanto, se você for bem-sucedido, também poderá ser muito recompensador e colocá-lo à frente em sua carreira.Eu te desejo sorte!
user180146
2019-12-05 15:52:03 UTC
view on stackexchange narkive permalink

Além disso, um projeto só pode avançar se o desenvolvedor do projeto específico estiver disponível. Dependendo dos anos que um desenvolvedor trabalhou na empresa, pode acontecer que 4 projetos precisem desse recurso de desenvolvedor específico, se os clientes fizerem solicitações de mudança.

Encontre exemplos em que isso deu errado e dê-os a ele. Também argumente que, se um desenvolvedor sair, todo o conhecimento desse projeto de software específico será deixado na configuração atual. Tudo isso custa dinheiro e talvez então ele verá as vantagens.

Editado após comentários:
Mas no final, se seu chefe vier com argumentos irracionais, você não poderá convencê-lo com argumentos racionais . Também pode ser que ele tenha bons motivos, mas não pode ou simplesmente não quer explicá-los. No final, é sua decisão. Portanto, esteja preparado se a resposta for não.

Pode haver argumentos racionais que o chefe não expressou ou que o OP não citou.Existem razões válidas para se opor ao Agile e razões pelas quais é geralmente mais eficaz ter pessoas trabalhando em projetos únicos.É claro que há desvantagens conforme mencionado, mas também há desvantagens em qualquer uma das sugestões do OP.É uma escolha de qualquer maneira, e cabe ao chefe - o que aparentemente ele já fez há muito tempo.
@Battle Concordo que existem prós e contras no Agile.Eu não queria sugerir que recusar o Agile fosse irracional em si mesmo.mas dizer: "2 homens na mesma posição de trabalho" soa como uma razão irracional (ou falácia, inglês não é meu idioma principal) para mim.
Bem, matematicamente você pode ver desta forma: 1 pessoa trabalhando em um projeto, 100% de eficiência.2 pessoas trabalhando em um projeto: cada uma com 80% de eficiência.3 pessoas - 65%, etc. Ele pode diminuir por ter que se adaptar um ao outro, comunicação, problemas relacionados ao trabalho de código, etc. Um desafio geralmente é minimizar essa perda por vários meios, como revisão de código no caso de muitos desenvolvedores,ou apenas ter uma estrutura de código / projeto adequada.Tudo isso ainda tem um custo de uma forma ou de outra.Além disso, que tal uma das duas pessoas não ser capaz de trabalhar em sua área de especialização?
Eu trouxe esse ponto.Mas meu chefe acredita em nossa experiência.Bem, eu mostrei que posso de alguma forma alcançar um projeto de 10 anos com código legado horrível e quase 0 documentação.temos 2 seniores que estão na empresa há mais de 10 anos, no total a empresa tem 13 anos.Eu vejo de onde vem sua posição.E sem que meu chefe fosse arrogante, ele afirmou que, de alguma forma, sempre funciona de um ou de outro jeito, e 13 anos de crescimento e sucesso não podem estar errados. Mas só porque não houve nenhum acidente grave ainda.
Eu não vejo esse crescimento selvagem funcionar, também porque vamos mudar nosso campo de operação de serviço orientado para desenvolvimento de produto de software, mas talvez eu apenas esteja vendo as coisas muito sombrias.
@Battle Seguindo sua lógica: Se um deles estivesse doente, por exemplo: a eficiência diminuiria de 100 para 0% (ninguém para assumir) enquanto em uma equipe cairia na pior das hipóteses para uma pessoa ainda em 80%."2 homens no mesmo cargo" é uma simplificação extrema do trabalho em equipe.
Corrigir.Essa é a compensação.Mas geralmente a maioria das pessoas não fica doente mais de 5% do tempo em que trabalham, e nem todas as tarefas ou projetos são cruciais para o tempo.Sair, entretanto, deixará uma grande marca, e esse é o verdadeiro risco e compensação.Lembre-se também, em uma equipe nem sempre é o caso de todos conhecerem todas as partes do código - então, se for necessário trabalhar nessas partes, o aspecto "equipe" não ajudará muito, embora ainda estejamos falando de> 0% de eficiência.
@user180146 eu concordo com você, que é uma simplificação extrema do trabalho em equipe, então eu tento encontrar, uma maneira de deixá-lo ver, que trabalho em equipe> trabalho solo em todos os aspectos, imo.um argumento meu era: equipe de 3 homens trabalhando em 2 projetos.portanto, há 120 horas de trabalho -20 para gerenciamento de equipe e sincronização e outras coisas.portanto, são 50 horas de trabalho realizadas em todos os projetos em uma semana, com recursos transferíveis.Caso adoeça, a equipe ainda tem 66 horas de trabalho e os dois projetos ficam com 33 horas de trabalho nesta semana.depois disso, ele perguntou por que eu sou um desenvolvedor e não um gerente de projeto e veio com dois homens no mesmo cargo
Goose
2019-12-05 19:34:13 UTC
view on stackexchange narkive permalink

“... 2 homens no mesmo cargo ...”

Parece que um (ou os dois) estão assumindo que “Agile é igual a Programação em pares”. Você precisa esclarecer isso em sua próxima conversa sobre o assunto.

A principal coisa que precisa ser considerada é o ajuste do modelo operacional da sua empresa e a implementação Agile que você está pensando (XP, Scrum, etc). Por exemplo, se o seu modelo de negócio envolve licitar X horas / dólares do projeto para ganhar um projeto do cliente, então é melhor ficar longe da programação em pares porque esse aumento na qualidade do software e compartilhamento / resiliência de conhecimento fará com que você licite mais do que seus concorrentes não estão fazendo isso. Isso deixará sua empresa em uma posição econômica desagradável.

Se o seu grupo, no entanto, está trabalhando em um produto - algo que você vende repetidamente -, vi muitos produtos de sucesso desenvolvidos usando Técnicas de Scrum.

Para resumir, para defender o trabalho em equipe, você precisaria defender uma abordagem (por exemplo, XP, Scrum) que se adequasse ao seu modelo de negócios / viabilidade econômica. Você terá dificuldade em apresentar uma abordagem que ignore o ambiente em que vai operar.

dwizum
2019-12-05 23:01:27 UTC
view on stackexchange narkive permalink

Qualquer pergunta que comece com,

Como posso convencer a pessoa X de ...

é difícil para responder, porque nenhum de nós sabe realmente o que motiva seu chefe. Portanto, embora possamos fornecer ideias para argumentos específicos que você pode apresentar, não podemos realmente entender se esses argumentos realmente ajudarão ou não. Como você observou, alguns chefes rejeitarão o que parece ser um argumento sensato para você.

A boa notícia é que você pode seguir um processo para responder a essa pergunta sozinho. A chave para convencer alguém de algo é entender sua perspectiva. O erro que a maioria das pessoas comete é tentar defender a mudança com base em sua própria perspectiva. Embora possa ser importante fazer uma mudança que o ajudará pessoalmente, você será muito mais eficaz se puder enquadrá-la do ponto de vista da outra pessoa.

Se quiser ter a melhor chance de convencer seu chefe para fazer uma mudança, dê um passo atrás de seus argumentos atuais e faça o seguinte:

  • Certifique-se de entender a cultura de sua empresa. Se houver alguma estratégia, missão ou outra estrutura geral (oficial ou não oficial), certifique-se de entendê-la.
  • Observe seu chefe e reflita sobre o que o motiva. Eles estão alinhados aos objetivos da empresa? Eles têm algum motivador pessoal? Coisas nas quais eles estão interessados ​​ou com medo?
  • Deixe seus próprios argumentos e motivações de lado.
  • Certifique-se de que consegue articular claramente o problema em questão e a mudança que você quer fazer, de uma forma que faça sentido do ponto de vista de seu chefe. Seja capaz de expor o problema de uma forma que faça sentido para eles e vincule sua solução aos motivadores deles.

Se seu chefe fica feliz em ignorar o "fator ônibus", então você provavelmente não vai ganhar argumentando pela mudança por causa de pontos únicos de falha. No entanto, talvez seu chefe esteja motivado por reduzir tíquetes de bug, ou tempo de resposta de reuniões, ou rendimento de tarefas, ou algum outro fator. Talvez haja até uma métrica mensurável com a qual eles se importem! Ou, pelo menos, um fator flexível ao qual você pode vincular sua mudança.

Ao tornar a relação entre sua mudança e seus objetivos o mais clara possível, você terá mais chances de conseguir o que deseja.

Manuel Rodriguez
2019-12-05 18:52:47 UTC
view on stackexchange narkive permalink

O trabalho em equipa normalmente não é desejado pela própria empresa mas é solicitado do exterior, nomeadamente do cliente que compra os produtos. A interface com o mundo externo geralmente está localizada no departamento de marketing. Se o objetivo é introduzir o trabalho em equipe para o desenvolvimento de software, isso equivale a permitir que o departamento de marketing controle as decisões tecnológicas.

Um bom ponto de partida é uma solicitação do cliente que só pode ser atendida se diferentes departamentos combinarem suas forças. Se um desenvolvedor não estiver motivado para trabalhar em equipe, ele pode se reportar diretamente ao cliente e explicar a ele por que a tarefa pode ser resolvida muito melhor por uma única pessoa.

Para apresentar o trabalho em equipe para um projeto de desenvolvimento de software é importante saber que não os engenheiros de longo prazo têm que decidir que tipo de software é necessário, mas o cliente. Falar com o cliente, perguntar sobre suas necessidades e comunicá-lo de volta para a empresa é uma obrigação da gestão e resultará em uma atmosfera colaborativa.



ⓘ
Estas perguntas e respostas foram traduzidas automaticamente do idioma inglês.O conteúdo original está disponível em stackexchange, que agradecemos pela licença cc by-sa 4.0 sob a qual é distribuído.
Loading...