Gerente de software que faz os desenvolvedores fazerem o gerenciamento de projetos

Sou desenvolvedor de software e trabalha em uma empresa de sistemas embarcados. Temos um gerente de projeto, que cuida do cronograma geral do projeto (incluindo elétrica, qualidade, software e fabricação), portanto, o cronograma do software é muito breve.

Também temos um gerente de software, quem é meu chefe. Ele me faz escrever e manter a programação do software, projetar documentos (design de alto e baixo nível), SRS, gerenciamento de mudanças, planos e relatórios de verificação, gerenciamento de versões, revisões e, claro, o software.

Temos apenas um engenheiro de teste para toda a equipe de software (10 membros) e, a qualquer momento, há alguns projetos em andamento.

Estou gastando 80% do meu tempo produzindo esses documentos. Meu chefe tem experiência em processos e acredita que precisamos de uma documentação melhor para melhorar o software:

1. Ele considera o design primordial, a codificação é "apenas anotá-lo", não deve demorar muito e "todo o código deve ser escrito antes que o hardware esteja pronto".
2. Não entende a diferença entre um controle de versão central e distribuída, mesmo depois que dissemos a ele que era mais fácil colaborar com um modelo distribuído.
3. Não entende o código e quer entender cada bug e sua solução proposta.
4. Acredita que a verificação deve ser feita pelo desenvolvedor e a validação pelo Testador. Porém, nossa verificação só verifica se a implementação está correta (não escrevemos testes de unidade, isso nunca é considerado no cronograma) e a validação é um teste de caixa preta, portanto, os testes de unidades estão ausentes.

Estou realmente confuso.

1. Sou responsável por manter todos esses documentos? Isso me faz sentir como se estivesse fazendo o Gerenciamento de Projetos de Software, em essência. Estou bem com a documentação técnica, mas acredito que a programação / planejamento não deve ser feita pelo desenvolvedor.
2. Eu realmente não gosto de criar documentos, quero resolver problemas e escrever código. Na minha experiência, a criação de documentos de design ajuda apenas até certo ponto, nunca é a solução para códigos melhores ou mais rápidos.
3. Sinto que o chefe realmente não se importa em criar produtos melhores, mas apenas em ser um bom gerente aos olhos da gerência.

O que eu posso fazer? Durante todo o ano, eu fiz três meses de codificação real, o restante gasto apenas na criação de documentos e na espera de relatórios de erros dos clientes.

Você parece um engenheiro de software.

Um gerente de projeto está mais focado no status do projeto geral e na alocação de recursos de maneira eficaz para garantir que os marcos sejam alcançados e no tempo adequado. Eles também removem barreiras e ajudam os recursos do projeto a se concentrarem em suas funções específicas.

Escrever e manter a documentação técnica e de design é uma parte importante de ser um engenheiro de software e é apropriado para sua função. Muita coisa boa pode ser ruim (veja Análise Paraylsis ).

Ele considera o design primordial, a codificação é "apenas anotá-lo"

Se o gerente de projeto considera os documentos de design primordiais, espera que os documentos sejam entregues no processo. Não é um tempo perdido da sua parte se ele achar que são importantes o suficiente para alocar 80% do seu tempo.

não deve demorar muito e "todo o código deve ser escrito antes que o hardware esteja pronto".

Isso é uma ilusão e uma visão antiquada do estilo Waterfall de como o desenvolvimento de software funciona. Invariavelmente, nunca é tão limpo, não importa quanto design e preparação você dedique. No entanto, você deve ter especificações claras de hardware e ambientes de teste adequados e simulações simuladas de hardware para interagir com seu código, mas, novamente, o mundo real é confuso.

O gerenciamento de projetos é incrivelmente fácil em um mundo perfeito. O mundo não é perfeito, por mais que você deseje, tornando o gerenciamento de projetos real incrivelmente difícil. É por isso que eles recebem muito dinheiro.

(2) Não entende a diferença entre um controle de versão central e distribuída.

Por que ele deveria se importar? Como isso afeta os marcos? Não faz.

3) Não entende código e quer entender todos os erros e sua solução proposta

O objetivo dele é trabalhar com software e o seu também deve ser. Ele não precisa entender o código, mas precisa entender os problemas que estão impedindo o funcionamento do software. Uma vez que vocês dois estejam de olho nesse nível básico, seu objetivo mútuo o ajudará a trabalhar juntos de maneira mais eficaz.

(4) Considera que a verificação deve ser feita pelo desenvolvedor e a validação pelo testador.

O que há de errado com esse sentimento? Os testadores na função de garantia de qualidade devem se preocupar com a validação de recursos e requisitos. Os desenvolvedores devem fazer todos os esforços para verificar e testar seu trabalho antes que ele seja testado.

Eu realmente não gosto de criar documentos, quero resolver problemas e escrever código.

Se você prefere ser um programador simples, talvez deva conversar com seu chefe sobre isso e ver se há um papel melhor para você no projeto. Alguém precisa escrever e manter a documentação técnica, para que talvez um dos outros desenvolvedores possa ajudá-lo em algumas dessas tarefas, para que você não gaste 80% do seu tempo escrevendo documentação.

Na minha experiência, a criação de documentos de design ajuda apenas até certo ponto, nunca é a solução para códigos melhores ou mais rápidos.

Isso é verdade principalmente ... mas apenas se todos os dez desenvolvedores estiverem gastando 80% do seu tempo escrevendo documentação técnica que ninguém nunca lerá. Esse é um enorme antipadrão de gerenciamento em que vivi antes. Se você acha que está fazendo a maior parte da documentação para a equipe, dificilmente parece justo que lhe seja negado o direito de executar mais trabalhos de codificação.

O fato é que a melhor documentação técnica é o próprio código.

Eu sinto que o chefe realmente não se importa em criar produtos melhores, mas apenas em ser um bom gerente aos olhos da gerência

Eu sinto que ele se importa porque o produto é sua ala e se os projetos e recursos não forem concluídos e os clientes não estiverem satisfeitos, a gerência superior não se importará muito com ele. O problema é que sua perspectiva sobre as melhorias necessárias na qualidade não corresponde à dele e à alta gerência, e a percepção dos clientes sobre o que eles sentem é importante.

Tente entender o que é realmente importante para o produto, porque, embora você possa aumentar a eficiência de um processo em três vezes, se você passar uma semana inteira fazendo isso, fica à custa de outro recurso importante que o cliente está exigindo.

Todos queremos ter uma boa aparência aos olhos de nosso superior. Não há nada de errado nisso, é da natureza humana ser auto-suficiente. Isso é um fato da vida.

Até certo ponto, concordo com o seu gerente de projeto. O desenvolvimento de software vai muito além dos recursos de codificação. :-)

Dada a sua situação, eu iria até ele e explicaria que os pedidos dele estão ocupando 80% do seu tempo, e busco entender por que é importante para ele passar esse tempo mantendo a documentação em vez de desenvolver (o que vai além da codificação).

A FYI, Atlassion , uma empresa de software, possui uma proporção de 13 desenvolvedores para uma pessoa de controle de qualidade e a maioria dos testes (planejamento e execução) é feita pelos desenvolvedores. Aprendi isso durante uma de suas apresentações no Agile 2012 e em nossas equipes que atualmente estou tentando imitar essa prática.

No entanto, eu também discutia com seu gerente de projeto se ele estaria aberto a experimentar o Scrum como uma metodologia para ajudar a levar toda a equipe adiante. Dada a sua descrição, acho que você não está usando o Scrum.

Como você, fiquei extremamente frustrado por manter planos que mudavam constantemente e uma abordagem leve do Scrum me ajudou a superar essa frustração.

As equipes com melhor desempenho em minha experiência foram aquelas que enfrentaram a menor quantidade de processo necessária para realizar seu trabalho. Em algum momento, um processo adicional começa a tirar a qualidade do produto. Se o controle de qualidade começar a perder bugs, porque eles estão mais preocupados com a burocracia, e o DEV não está codificando recursos ou corrigindo bugs porque eles estão escrevendo documentação, então você tem um problema. No entanto, descobrir se esse é realmente o caso da sua empresa é uma pergunta altamente localizada que apenas as pessoas da sua equipe podem responder (não a nós).

Há uma coisa sobre a qual seu chefe está muito errado, e esse é o fato de você ter tão pouco controle de qualidade e nenhum teste de unidade. Um bug criado pelo adeveloper é, por definição, uma supervisão da parte deles. Esperar que os desenvolvedores sempre testem seus próprios recursos e que tenham poucos testes além disso é um problema de processo. O controle de qualidade pode ser substituído por testes automatizados, dependendo do seu domínio, até certo ponto, mas se você não o tiver, provavelmente estará deixando os erros passarem (e isso geralmente acaba custando mais do que encontrá-los mais cedo).

Além disso, de uma perspectiva estrita dos negócios, contratar QA é mais barato do que contratar desenvolvedores. Você poderá cobrir mais terreno com o dinheiro gasto se as equipes tiverem uma boa relação QA / DEV.

As implementações do CMMI que eu já vi ou ouvi diretamente foram pesadas no processo e na documentação; seus chefes acreditam que a documentação deve ser detalhada o suficiente para tornar a implementação trivial implica fortemente que a expectativa dele é semelhante.

Se você estiver recebendo uma parcela desproporcional da documentação / manutenção da documentação, é razoável solicitar uma distribuição mais uniforme. Se os outros desenvolvedores tiverem documentação semelhante às taxas de codificação e você desejar gastar a maior parte do tempo escrevendo código; talvez seja hora de considerar encontrar um novo empregador.

Você está falando de sistemas médicos ... então a segurança é fundamental - e, portanto, a documentação (especificamente a rastreabilidade) é essencial.

Um testador parece um pouco leve, mas fora isso, sim - você é responsável por garantir que a documentação esteja no local.

Minha experiência no mundo da medicina é limitada, mas no mundo aeroespacial / de defesa, temos o Do-178B (agora C), que prescreve um modelo de ciclo de vida que especifica a documentação e o nível de testes necessários (dependendo da criticidade de segurança [mais especificamente, o nível de garantia de design] do software) e, no mundo automotivo, temos a ISO26262, que faz o mesmo.

Se a documentação não estiver no local, o produto não será certificado.

Mas o importante é trabalhar com a documentação necessária para melhorar seu produto ... não tente fazer engenharia reversa da documentação como uma reflexão tardia, pois ela não serve para nenhum propósito do mundo real.