Meu gerente recentemente me promoveu como "designer de software". Não sei que esse título existe. Tanto quanto sei, os SAs criam design de código de alto nível e fazem diagramas.

Eu tenho dificuldade em entender o design de código de alto nível que devo fazer. De acordo com meu gerente, eu deveria projetar todas as classes e todos os métodos dentro dessas classes. Ou seja, eu projetaria toda a estrutura de código e deixaria minha equipe implementar a funcionalidade de cada função ou classe. Por exemplo, em um sistema CRUD, devo ser capaz de planejar qual função deve ser usada ou quais classes devem ser criadas.

Dada minha experiência em design de software, achei extremamente impossível fazer isso. Como desenvolvedor, sempre crio minhas próprias classes, defino e implemento minhas próprias funções. Eu nunca experimentei projetar funções para outras pessoas.

Minhas perguntas são:

• Isso é comum? Para um sistema muito grande, a base de código não muda o tempo todo?
• Isso pode ser feito?

Sei que posso estar fazendo uma pergunta óbvia e estúpida aqui, mas sempre fui um desenvolvedor regular até agora e, portanto, não tenho experiência em projetar sistemas inteiros.

Notas preliminares sobre títulos:

• Às vezes, o que você realmente faz não corresponde ao seu título oficial. Como exemplo, anos atrás, fui contratado como "analista-programador no departamento de P&D"; no entanto, ninguém contratado fez análise, nem programação, nem pesquisa, nem desenvolvimento. O que eu (e outros) realmente fizemos foi codificar. Um macaco podia fazer metade das coisas que eu fazia. Qualquer estagiário de graduação poderia fazer a outra metade.

• Muitas vezes, o título não importa. Em algumas empresas, você pode acabar executando muitas tarefas diferentes e diversas, e simplesmente não existe um título que descreva tudo isso. Em uma empresa, eu fiz as tarefas de um arquiteto, um líder de equipe, um gerente, um funcionário de UX, um codificador e um especialista em produtividade, e eu estava garantindo que duas equipes estivessem se comunicando corretamente umas com as outras. Não existe um título único para isso.

• Finalmente, os títulos podem ter significados diferentes em empresas diferentes, ou as pessoas que atribuem títulos em primeiro lugar não têm a menor idéia do real significado do título, se houver. Em alguns casos, existem apenas títulos e chavões da moda. Você não precisa de um administrador de sistema - isso é antiquado. Você precisa de um especialista em DevOps. Você não fala sobre inteligência de negócios ou mineração de dados quando tenta contratar alguém: fala sobre Big Data!

Portanto, esqueça os títulos e concentre-se no que exatamente você foi convidado a fazer. Felizmente, sua pergunta faz exatamente isso.

Isso é comum? Para um sistema muito grande, a base de código não muda o tempo todo?

Não o vi e não acredito que possa ser sustentável.

Isso pode ser feito?

Sim, mas a um custo de pessoas normais deixarem a equipe.

O que seu gerente pode ter em mente é que você faz o design e o apresenta em uma forma de diagramas UML. É antiquado, mas quem se importa? A prática era bastante popular em algumas empresas e ainda funciona decentemente em outras. Pode ser uma abordagem adequada, se você for muito habilidoso, mas todos os outros membros da sua equipe são programadores iniciantes: eles simplesmente não têm experiência suficiente para fazer o design apropriado e estão em uma posição muito boa para ajudar eles.

Se eu fosse você, começaria conversando com seu gerente, a fim de determinar se é realmente isso que ele tem em mente. Se sim, jogue o jogo e tente essa abordagem por uma semana ou duas . O que poderia acontecer?

Você descobrirá que a abordagem funciona bem para sua equipe e, nesse caso, agradeça ao gerente por sua compreensão, ou a abordagem não funcionará.

Nesse caso, converse com sua equipe primeiro, para identificar todos juntos por que não funcionou e o que deve ser feito para melhorar o processo (em outras palavras, faça uma retrospectiva). Em seguida, implemente as alterações no processo, se você estiver em condições de fazê-lo, ou visite seu gerente e discuta-o com ele.

Então repita. A cada duas semanas (ou o que parece apropriado no seu contexto).

Idealmente, arquiteto de software é outro termo para engenheiro de software sênior , talvez com algumas responsabilidades adicionais, ou como uma maneira de fornecer algum reconhecimento geral a essa pessoa de que eles são o ponto de contato oficial em questões técnicas com os sistemas com os quais trabalham, ou que membros menos familiares da equipe de desenvolvimento possam confiar neles quando não souberem por que parte do sistema foi projetada de uma maneira específica. ou estão enfrentando problemas quando não conseguem encontrar uma solução boa / aceitável para um problema.

Na minha opinião, um arquiteto de software não deve ser alguém que trabalha em uma proverbial "torre de marfim" criando designs ou tomando decisões unilaterais para outros desenvolvedores; as decisões de design ainda devem ser conduzidas pelas pessoas que estão ativamente envolvidas na escrita e manutenção do código, e as equipes de desenvolvimento devem ter responsabilidade coletiva, com os desenvolvedores individuais sendo responsáveis ​​pela qualidade de seu próprio código, pela compreensão do design de um sistema e por não introduzir alterações que "quebrem" a arquitetura ou que introduzam níveis inaceitáveis ​​de dívida técnica.

Embora às vezes possa ser valioso capturar o design de alto nível de um sistema como um meio de ajudar uma equipe de software a comunicar idéias e compartilhar conhecimentos (particularmente para iniciantes e desenvolvedores inexperientes), a principal atividade do design é escrever o próprio código (incluindo testes automatizados); Faria sentido para um arquiteto de software assumir a "propriedade" da documentação do projeto, embora não seja a mesma coisa que dizer que eles são quem a escreveu; mais do que eles garantem que a equipe crie a documentação necessária e suficiente e esteja disponível para revisar a precisão.

Para todos os propósitos práticos, há pouco ou nenhum valor na tentativa de separar o papel do design de software do desenvolvimento, porque eles são essencialmente a mesma coisa - de fato, a realidade é geralmente bastante prejudicial porque tende a levar a uma mentalidade pela qual os desenvolvedores são tratados como "macacos de código" da linha de produção, proibidos de pensar por si mesmos.

Pela sua descrição, parece que seu gerente deseja que você assuma uma posição de liderança e não sabe como articular isso

Ele o promoveu e deseja que você projete o software e divida as tarefas. Sua confusão sobre como articular é natural. Ele está colocando você em uma posição de liderança que pode ser facilmente confundida com seu papel como gerente.

As equipes tradicionais de desenvolvimento têm um gerente único, que é dividido entre atividades externas (buscar financiamento, política, talentos na busca de cabeças, vender idéias e produtos e etc.) e atividades internas (coordenar o desenvolvimento). Mas essas atividades estão em conflito e requerem diferentes conjuntos de habilidades. Geralmente "o gerente" é bom nas atividades externas e ruim nas internas.

Essas funções podem ser separadas. Na verdade, é uma das principais características da metodologia Scrum. As equipes bem-sucedidas e produtivas que conheço separaram esses papéis. E a maioria nem sabe que está fazendo isso: um dos programadores começou a organizar a equipe e o gerente deixou.

Isso só funciona se houver um vínculo de confiança entre "o gerente" e o "desenvolvedor líder". Muitas equipes falham. À medida que um dos desenvolvedores assume a liderança, o gerente pode se sentir ameaçado ou com ciúmes. A equipe pode perder o respeito do gerente, porque ele ou ela está fora o tempo todo e eles não entendem a importância das atividades externas. É importante estar ciente disso e evitar esses problemas.

Como dividir as tarefas

Para dividir as tarefas, você não precisa seguir o exemplo dele.

É importante abusar da prova de conceitos, protótipos exploratórios funcionais para tornar o progresso da equipe mais visível para ele. O importante é que ele sinta que o desenvolvimento está progredindo.

Uma maneira de conseguir isso é criar um protótipo somente para sql. Crie tabelas, preencha com dados, crie casos de teste somente para sql que executam as consultas que as telas e rotinas principais executariam. Quando tiver certeza de que a simulação é boa, divida o trabalho entre seus desenvolvedores juniores para criar as telas e rotinas. Enquanto seus desenvolvedores juniores estão trabalhando, você cria os protótipos para o próximo ciclo de desenvolvimento.

Todo mundo está ocupado, a produtividade é alta, o gerente está feliz.

Experimente por alguns sprints, mas você irritará seriamente os desenvolvedores que está gerenciando e eles, por sua vez, gemerão com quem estiver ouvindo.

Eu diria que você está definindo as decisões gerais de arquitetura (push vs pull; padrões de mensagem; o serviço x deve ser DDD ou CRUD é bom) para a equipe; depois, use o processo de revisão de código e o emparelhamento para manter todos no caminho certo e ajudá-los se estiverem travando.

Realmente não precisa ser de cima para baixo, a morte pela UML. O que você procura são aulas no lugar errado; a lógica de negócios não está onde você esperaria e assim por diante.

Não seja muito duro com a equipe, se eles estão aprendendo alguma coisa conhecida, trabalhe primeiro em novos princípios e depois limpe as más práticas remanescentes.