Como arquiteto de software, devo focar tanto na análise dos logs e na correção de bugs de outros?

Desde a minha graduação (final de 2005), eu trabalhava na mesma empresa que um engenheiro de software c ++. Há um ano, fui promovido como arquiteto de software, mas me envolvi cada vez mais na qualificação e correção de bugs, suporte de nível 2.

50% do meu tempo gasto no Notepad ++ analisando os logs do software e tentando descobrir o que deu errado. 30% corrigindo bugs de outros e o restante (se houver) revisando o código espaguete dos desenvolvedores.

Comecei a odiar este produto e a pensar em uma estratégia de saída desta empresa.

O que você acha que eu posso fazer nessa situação? você outro arquiteto de software ainda corrige bugs no código?

A maioria das pessoas geralmente concorda que um arquiteto de software deve estar envolvido principalmente em design de alto nível, estabelecendo padrões, escolhendo ferramentas ou estruturas, avaliando produtos, implementando protótipos e Prova de Conceitos e treinando e desenvolvendo mentores

A realidade, porém, é que o título geralmente pode ser uma nomeação política para um desenvolvedor, um título especial dado para liderar desenvolvedores de projetos ou até algo tão simples quanto uma solução alternativa em gerenciamento de RH para contratar um desenvolvedor tão necessário com um salário ou taxa que O gerenciamento de RH ou superior seria inaceitável para o título Desenvolvedor de software ou Engenheiro de software.

Em outras palavras, os títulos são praticamente sem sentido.

O artigo da Wikipedia define arquiteto de software como:

um programador de computador que faz escolhas de alto nível de design e determina padrões técnicos , incluindo padrões, ferramentas ou plataformas de codificação de software ...

Dado acima, suas estimativas "50% do meu tempo gasto ... analisando os logs do software ... 30% corrigindo os erros de outras pessoas" colocam você muito longe do que normalmente se espera que o arquiteto de software faça.

• Eu diria que acima faz o título que eles deram sobre 50+30=80%falso.

Observe que, por si só, atividades como a análise de logs ou a correção de erros de outras pessoas podem legitimamente ocupar parte do tempo do arquiteto - desde que atendam ao objetivo principal dessa função - ou seja, fazer escolhas de alto nível do projeto e estabelecer padrões técnicos. Na verdade, esse é o caso de qualquer tipo de atividades de desenvolvimento / manutenção / teste de software.

Por exemplo, se a análise de logs o levasse a entender como tornar mais fácil - melhorando os padrões de design, ferramentas ou codificação - isso seria um esforço perfeitamente justificável para um arquiteto. Da mesma forma, pode ser completamente aceitável para o arquiteto sujar as mãos, corrigindo erros específicos - desde que isso resulte em melhorias específicas no projeto / processo, resultando em menor taxa de erros etc.

_{Em uma nota um pouco mais positiva, sua pergunta demonstra pelo menos uma habilidade que é bastante importante para o arquiteto: capacidade de classificar diferentes atividades do tipo e acompanhar os esforços gastos nelas. Considere adicionar à sua "caixa de ferramentas" habilidades complementares para resumir suas observações e estimativas e comunicá-las claramente, especialmente na etapa de gerenciamento. :)}

Como arquiteto de software, devo focar tanto na análise dos logs e na correção de bugs de outros?

Suposto? sim e não. Você está encarregado da totalidade da qualidade do produto e do caminho da evolução - faça com que funcione amanhã, mas também no próximo ano.
Isso significa dar uma mãozinha para resolver problemas difíceis? Absolutamente - pelo menos eu faço. Você não pode fazer o produto funcionar amanhã se seus clientes o deixarem.
Isso significa que você deve dedicar todo o seu tempo a isso? Absolutamente não. Você é responsável pela TOTALIDADE da qualidade e evolução. Dedicar muito tempo à busca de problemas é contraproducente.

Você deveria ser proativo:

1. Inicie planos de educação para que outras pessoas (dev / support) possam levantar a carga. "ensine um homem a pescar" e todo esse jazz.
2. Invente maneiras e desenvolva ferramentas para oferecer suporte a análises de defeitos mais rápidas e fáceis e isolamento de causa raiz. Se você acha isso chato, outros desenvolvedores, possivelmente menos talentosos ou experientes, acham isso não apenas chato, mas também difícil e talvez até assustador. Ajude-os a superar isso com a tecnologia.
3. Inicie um esforço para aumentar a qualidade do produto - simplifique, modularize, crie estruturas de teste - dê o exemplo, não choramingando e ameaçando sair.
4. Certifique-se de que os desenvolvedores saibam o que você está fazendo - mas também de seus gerentes. Um papel de arquiteto é muito mais sobre relações com outras pessoas do que sobre codificação e análise. Por mais que você odeie isso, a política é fundamental aqui. Garantir que seus colegas vejam suas realizações facilita mais tarde convencê-las de que você está certo. Se você ainda não estiver lá, apoie suas reivindicações por pesquisa e POCs.
5. Se tudo mais falhar, e somente depois de gastar tempo para tentar melhorar as coisas, converse com seu gerente. Diga que suas habilidades são mais usadas nas fases de planejamento e design e veja o que pode ser feito para mudar a situação atual. Seu produto pode estar em uma pitada e a resposta do seu gerente pode ser "precisamos de você para isso aqui e agora". Eu insistiria em um plano de longo prazo - como vamos mudar a situação atual.

Eu vejo o papel de um arquiteto um privilégio. Você consegue influenciar o produto de uma maneira que muitas outras pessoas não podem - o único teoricamente mais influente do que você é o gerente de P&D de produto (e, possivelmente, o marketing) -, mas ele é o caminho para o gerenciamento ocupado.

O papel de um arquiteto de software tradicionalmente não os corrige bugs. Os arquitetos de software ajudam a corrigir os problemas de design do software; se, por erro, você quer dizer a maneira principal como o software foi projetado, se presta a mais fragilidade ou dificuldade em expandir / manter, o trabalho da SA é propor ou redesenhar aspectos do software para resolver esse problema.

Dado o que você disse:

50% do meu tempo gasto no Notepad ++ analisando os logs do software e tentando descobrir o que deu errado. 30% corrigindo bugs de outros e o restante (se houver) revisando o código espaguete dos desenvolvedores.

Esse não é o papel de uma verdadeira SA e, em vez disso, é mais do que gostaria que nossos programadores de desenvolvedor 1 e 2 desenvolvessem com um desenvolvedor sênior. Digo isso em particular porque acho que realmente ajuda os novos desenvolvedores de nossa empresa a entrar no produto e no código trabalhando nesse nível em questões de qualidade do código. Você é um novo SA na sua empresa e eles o fazem fazer esse trabalho para entrar no sistema? Se sim, talvez esteja tudo bem por um curto período de tempo. Se esse é o seu trabalho diário e existe há mais de um ano, é bem provável que esteja na hora de procurar outro papel.

Entendo sua frustração, mas entendo que, se você escreveu o código ou foi o último a tocá-lo, o tempo é curto e eles podem chegar até você, muitos gerentes vão procurá-lo para corrigi-lo, independentemente do seu título.

Descobrindo que você ainda tem amigos no grupo de desenvolvimento que está em crise, ajudará. O problema é quando eles, e mais importante, a gerência deles se acostuma a você ajudar, eles continuam voltando. Como se diz: "nenhuma boa ação fica impune". Se eles podem contar com você para resolver os problemas, independentemente do seu título, você é apenas mais um desenvolvedor e alguém que eles podem usar.

É um problema difícil de resolver, mas meu conselho é:

1. Peça o número de cobrança do projeto neste momento que não é arquiteto de software. Acho que os gerentes de projeto não estão tão ansiosos para pedir seu tempo, se tiverem que prestar contas por isso.

2. Converse com seu gerente sobre quanto tempo está sendo perdido e com quais grupos ou projetos. Seu gerente pode pedir para não ajudá-los e manter o foco em seus projetos. Nesse caso, o outro grupo vem e pede ajuda, diga a eles que seu chefe também não disse.

3. Organize seu trabalho, mantendo suas prioridades claras e não seja tão sensível a projetos externos de arquitetura.

4. Aja como um arquiteto, faça com que seus colegas o vejam como arquiteto, não como o mesmo desenvolvedor que você tem sido todos esses anos. Você quebrou os outros com o hábito de tratá-lo apenas como desenvolvedor.

Boa sorte.

Não, você está aqui para gerenciar o cenário geral.

Você tem um problema de gerenciamento: corrigir bugs e melhorar a qualidade do código é o trabalho dos desenvolvedores; como arquiteto, você deve emitir diretrizes e arquitetura real (UML ou qualquer outra coisa que flutue no seu barco) e, em seguida, revisar regularmente o código para garantir que essas diretrizes sejam seguidas corretamente. .

No entanto, você pode implementar e corrigir erros na arquitetura principal.

Exemplo: você trabalharia no PRISM, MEF etc. em um projeto WPF / C #, mas não trabalharia no XAML para exibir a tela de abertura.

Você trabalharia no design do banco de dados, mas não gravaria procedimentos armazenados para operações CRUD.

etc.

Parte da resposta seria encontrar um engenheiro disposto a assumir essa carga.

Obviamente, a razão pela qual isso é um problema é que você acha esse trabalho indesejável, o que não envia a mensagem de que é atraente para os outros engenheiros, portanto eles também não estão ansiosos para buscá-lo.

Eu vejo duas possibilidades.

1. Você recebeu a posição de arquiteto para poder trabalhar em itens de figuras maiores.
   Nesse caso, você deve mencionar à gerência que não pode trabalhar nesses itens mais amplos, porque ninguém assumiu a função de suporte de nível inferior. Esse é o problema deles a resolver.

2. O título é amplamente cerimonial - um osso jogado para você para mantê-lo por perto.

Nesse caso, o gerenciamento pode não estar muito interessado em facilitar sua carga de suporte.

-

Uma coisa que definitivamente não será útil para seu objetivo é adotar uma atitude de desprezo pelos outros desenvolvedores e engenheiros que vejo vazando na sua pergunta. Você quer que essas pessoas intensifiquem e lidem com esses problemas com confiança, para que você não precise (possivelmente cometer alguns erros ao longo do caminho). Se eles souberem que você só vai falar mal das soluções deles e corrigi-los depois, provavelmente eles nunca irão avançar.

50% do meu tempo gasto no Notepad ++ analisando os logs do software e tentando descobrir o que deu errado. 30% corrigindo bugs de outros e o restante (se houver) revisando o código espaguete dos desenvolvedores.

Definitivamente, esse é um tipo de trabalho que você NÃO deve realizar para esse papel. De acordo com minha experiência / observações, o arquiteto deve estar envolvido no design do aplicativo, melhorias, esclarecimentos de requisitos técnicos e possíveis problemas de desempenho (não verificando logs todos os dias, mas analisando principalmente problemas / erros graves) que precisam ser resolvidos ou evitados.

Em outras palavras, meu ponto 1 é: arquitetos são designers de alto nível e integradores de sistemas com experiência prática em como os trabalhos internos da tecnologia funcionam / se aplicam e precisam ser usados.

Se você tiver oportunidade de atribuir e gerenciar a qualidade do código, suas habilidades de gerenciamento de trabalho precisam ser aprimoradas. Portanto, o planejamento do trabalho deve ser sua prioridade na abordagem "como fazer o trabalho".

Ponto 2 : se você é um dos poucos desenvolvedores nessas aplicações - esse título é apenas mais um pouco de açúcar da gerência da empresa para mantê-lo na mesma função de "consertar" com um novo título sofisticado .

O papel de um arquiteto de software é muito mais do que o que você está fazendo em sua empresa atual. Ele é responsável por definir padrões de design de software, criar design de alto nível, padrões de codificação, etc. Mas, como você disse, você está trabalhando em um produto, ou seja, sendo um arquiteto de software, a expectativa de você quanto à confiabilidade do produto será bastante alta e, nesse caso, seu envolvimento nessas coisas não só ajude o produto, mas também a empresa, pois você é bastante experiente nisso. Mas você também deve receber alguma exposição ao desenvolvimento de novos recursos e a novas tarefas, que incutirão seu interesse em sua organização atual.

Como arquiteto de software, devo focar tanto na análise dos logs e na correção de bugs de outros?

Em questão de falar, 'Sim'.

Aqui está como eu qualificaria minha resposta:

1. Por padrão, você deve permitir que os desenvolvedores do software analisem os logs e corrijam os erros.
2. No entanto ... Você deve estar ciente dos defeitos que ocorreram na perda de dados, exigir uma reversão onerosa do banco de dados, levar muito tempo para os desenvolvedores resolverem ou solicitar desculpas ao cliente.
   1. Como regra, seus subordinados diretos devem informá-lo sobre esses defeitos.
   2. Você deve criar uma cultura na qual seus subordinados diretos se sintam habilitados a falar sobre esses defeitos, mas não sejam obrigados a falar sobre os triviais.

Mais sobre # 2:

1. Esses tipos de defeitos geralmente implicam uma falha na arquitetura. Quando o fazem, você deve entender a natureza precisa do defeito e arquitetar uma correção.
   1. Portanto, por extensão, você deve estar pronto, disposto e capaz de examinar os logs e corrigir os erros de outras pessoas (mesmo se você não confirmar diretamente o código no repositório de código-fonte).

A resposta provavelmente é não. Por que você está gastando tanto tempo depurando e suportando problemas? Alguém está atribuindo esse trabalho a você?

Parece que você precisa esclarecer o que deveria estar fazendo. Você pode precisar corrigir bugs; isso provavelmente não deve ser a maior parte do seu tempo.