Os processos da minha equipe estão fora de controle?

Sou líder de equipe de desenvolvimento de software (recentemente assumi o controle de uma nova equipe) e, em última análise, sou responsável por manter alta produtividade, boa qualidade e prioridades organizadas.

Tenho 6 desenvolvedores seniores na minha equipe, mas as coisas parecem uma bagunça aqui. A situação é que eu tenho que lidar com solicitações do JIRA de cerca de 10 pontos de contato diferentes em nossa empresa, e todas elas representam diferentes unidades de negócios ou clientes.

O problema que tenho é que meu trabalho consiste principalmente em apagar incêndios o dia inteiro e garantir que os problemas de todos estejam sendo resolvidos. Infelizmente, a cultura em nossa empresa tem sido alta produtividade (lançamentos rápidos), mas baixa qualidade (bugs de produção), e nossos clientes não aceitarão um atraso repentino nos resultados.

Quais são algumas boas maneiras de lidar com isso? Tenho toneladas de teorias, mas estou procurando uma resposta de alguém que realmente tenha experiência de trabalho em uma situação como a minha.

Aqui está uma pequena lista de como as coisas funcionam:

• Cada desenvolvedor é responsável por um aplicativo e serviços específicos que interagem com ele;
• As liberações geralmente são testadas pelo cliente em um servidor de produção simulado e, em seguida, implantadas no servidor ativo;
• Cada aplicativo é usado por uma média de 50 a 80 pessoas, com 8 aplicativos no total.

obrigado

nossos clientes não aceitarão um atraso repentino nos resultados

Bem, então eles têm que aceitar a má qualidade que estão recebendo.

O que você precisa fazer para mudar isso é fazer com que seus clientes aceitem a realidade do desenvolvimento de software (ou qualquer outra produção!): Que coisas apressadas afetam a qualidade.

Crie uma grande lista das coisas que estão dando errado - das coisas que estão quebradas, dos momentos em que eles tiveram que reclamar. Explique a eles o motivo desses problemas e diga o que você gostaria de fazer para mudar isso. Explique a eles a porcentagem de tempo que sua equipe gasta suportando e corrigindo aplicativos ativos. Se você não estiver coletando os dados, agora é a hora de começar (e colete-os por um mês antes de apresentar as informações aos clientes).

Coloque as principais partes interessadas em uma sala e diga: "você quer que o X seja consertado ou que o Y seja entregue? Temos apenas tempo para um dos dois". Faça -os responsáveis pela definição das prioridades, e ser claro que você têm capacidade limitada. Se eles pedirem algo novo, pergunte a eles o que estão dispostos a sacrificar em seu roteiro atual para alcançá-lo.

Pergunte à sua equipe quanto tempo e recursos eles precisam para "consertar as coisas" (tanto em termos de correção de bugs básicos como em termos de correção de problemas maiores na qualidade / arquitetura do código / etc.). Inclua esses itens na lista de itens que suas partes interessadas devem priorizar.

A melhor coisa que já fiz no meu trabalho atual foi colocar as 8 principais partes interessadas em uma sala ao mesmo tempo e organizar uma pilha de 16 cartões de índice representando os novos recursos solicitados. Afastei-me da mesa e disse: "podemos entregar uma delas de cada vez. Em que ordem você as deseja?" Deixe que eles discutam um com o outro sobre a prioridade do negócio, em vez de você ficar preso no meio.

Pare, solte e role. Os incêndios precisam de combustível e, muitas vezes, vêm em forma de pânico. Separe um tempo para gerenciar a si mesmo e a equipe em ordem. Avalie seus desenvolvedores e veja se você tem algum que não seja qualificado o suficiente e / ou não trabalhe duro o suficiente para produzir os resultados desejados. Decida quem fica (e faça um esforço para mantê-los), quem precisa de um empurrãozinho, o resto tem que ir. Avalie o suporte e as ferramentas que seus programadores estão recebendo para garantir que eles possam fazer seu trabalho. Certifique-se de que são seguidos os testes, a revisão, o controle da fonte e a documentação do som. Boas pessoas com boas ferramentas precisam ser responsáveis ​​pelo bom trabalho.

É necessário que haja um sistema para saber o que sua equipe precisa fazer, atualmente está trabalhando e quando espera ser concluída. Muitas metodologias, teorias, software, quadros de apagamento a seco e notas adesivas, documentos e e-mail para fazer isso. Faça algo funcionar, fazendo com que todos cumpram. Se todo mundo tem alguma entrada no sistema, há mais incentivo para segui-lo.

Entenda melhor o que os clientes esperam. Isso pode não fazer parte do seu trabalho. Pode haver outras pessoas que fingem que seus cabelos estão pegando fogo, seus clientes estão infelizes e o céu está caindo. É o que eles fazem e alguns são realmente bons nisso. Se tudo é uma emergência, nada é uma emergência, porque nem tudo será feito. Ofereça-se para participar ocasionalmente de discussões com os clientes. Você verá que muitos 'legais de se ter' se transformam em 'quebradores de acordos' quando chegam à equipe de desenvolvimento. Seja o contato técnico ou alguma outra desculpa para ajudar. Fazer promessas que você não pode cumprir é pior do que dizer a eles o que eles não querem ouvir em primeiro lugar. Queremos fazer um bom trabalho, por isso precisamos de 8 semanas e não de 5. Eles serão mais felizes a longo prazo.

Por fim, você precisa educar seus clientes sobre o desenvolvimento de software e envolvê-los no processo, tanto quanto possível. O que eles estão vendo agora é a rápida entrega de novos recursos, mas também erros no software. Embora sejam felizes com o primeiro, não serão (ou não deveriam) ser felizes com o último.

Você precisa explicar a eles que, com processos melhores, enquanto a entrega de um novo software atrasar um pouco, haverá menos bugs (nunca haverá zero). Se você conseguir concordar que esse é o caminho a seguir, poderá começar a introduzir os processos necessários para recuperar o controle sobre seu desenvolvimento.

O uso do processo Agile pode ajudar aqui, pois sugerem (e em algum mandato de implementação) que o cliente seja incluído como parte da equipe. Se você envolver os clientes de perto, eles verão o que está funcionando e o que você pode produzir em primeira mão.

Minha opinião (com experiência limitada): acho que há dois problemas a serem resolvidos. Primeiro, o processo de qualidade. Você usa scrum / waterfall / algo no meio? No scrum, você pode adicionar tarefas adicionais para cada história: 1 para criar um script / plano de teste, outro para executá-lo, outro para uma revisão de código etc. Na cascata, você pode simplesmente adicionar essas etapas?

O outro problema é o enorme problema principal que existe em todo lugar no software. Gerenciando expectativas. Ou seja, aumentando o tempo de alguém gritando que precisa de um botão para executar o X e entregá-lo.

Se você pode adicionar etapas extras ao processo e fazer um grande anúncio sobre isso [agora estamos implementando esse processo de qualidade: o que significa menos tempo para corrigir bugs! e melhores resultados de qualidade! grandes e-mails / reuniões etc. para que eles saibam] e, regularmente, produzam resultados (ala scrum), a idéia é para quem você está entregando aprenderá e verá o valor nas etapas extras do processo, e eles irão comprá-lo. Menos tempo corrigindo bugs = mais tempo implementando e testando recursos.

Os clientes não aceitam um atraso repentino nos resultados? Eles praticamente precisam. É claro que não pode continuar como está. Talvez você possa adicionar as etapas extras de controle de qualidade e, se necessário, adicionar mais membros da equipe? Mas as etapas de qualidade são absolutamente necessárias.

Novamente, se você usar o scrum ou algo semelhante, poderá tentar um sprint de uma semana para que haja entregas regulares de resultados. Isso apaziguará as pessoas tanto quanto uma rápida reviravolta.

Espero que ajude até certo ponto .. espero que eu não tenha entendido o ponto.

O que você descreveu parece muito normal e nem um pouco alarmante.

• Os clientes geralmente têm uma mentalidade diferente sobre o que é importante que os engenheiros. Gostamos das coisas certas, mas os clientes se deparam com uma realidade que recompensa a pontualidade sobre a pureza. Eles precisam ter seus problemas resolvidos rapidamente para serem competitivos, e é exatamente por isso que estão pagando.
• A definição de prioridades é muito grande e complicada para uma pessoa gerenciar sozinha, tendo uma lista de pendências de questões importantes (então você está usando o JIRA), com os tenentes gerenciando cada área de interesse, é a melhor opção que temos para manter o trabalho impotente à frente o horário.

Não há nada com que se preocupar. Dito isso, você pode economizar muita dor transferindo o máximo possível de tarefas de gerenciamento para o cliente pagador, envolvendo-as no processo de desenvolvimento de definição de prioridades e tecnologia, automatizando a rotina tanto quanto possível. possível.