Qual a importancia da arquitetura de software (e outros processos além do "codar") para vocês?
Um dos principais diferenciais da minha empresa (Piggly Lab) que me fez e faz conquistar dezenas de projetos de sofware sob demanda é respeitar os processos que vão além de abrir o VSCode e começar a programar. Tem muita coisa por trás. Desde a arquitetura, modelagem, testabilidade e afins.
Claro que acredito que tem solução para todo mundo no mercado. Profissionais e empresas com propostas mais aceleradas que irão pular todos os processos possíveis (testes unitários, testes de integração, UX/UI, QA, arquitetura, etc) desde que o "software funcione". Assim como também existe profissionais e empresas mais cuidadosas com o processo. Mas em geral, vejo constantemente devs desvalorizando partes do processo - como comentário pessoal tem gente ainda que mete VARCHAR e INT em todas as tabelas de um banco relacional, não sabe quando usar outros tipos e se quer se importa com questões de DBA.
Dentre todas essas coisas, uma das que mais vejo a galera abrir mão é a arquitetura. A quantidade de sofware que foi feito por freelas que eu pego sem uma linha de documentação, sem um conjunto claro de operações definidas, é impressionante... O dev simplesmente já parte para o git iniciar o código-fonte, monta as SQL ou coleções esperadas exatamente igual aos modelos de dados e classes (mal dos ORM) e vai entregando requisitos (isso quando não atrasa). Não sei se é impressão minha, mas nesses 15 anos que trabalho com isso, vejo muita gente simplesmente negligenciando processos além de "programar" em si.
Uma das primeiras coisas que eu faço para qualquer projeto que chega por aqui, por exemplo, é produzir a arquitetura (todos os diagramas, modelagem, definições, etc). Utilizo principalmente a metodologia Domain-Driven Design e foco totalmente no valor da entrega do software acima da aceleração do desenvolvimento. O resultado é produtivo, tenho uma resposta positiva acima de 95% de acerto, menos de 5% de bugs e uma fidelização alta.
O resultado é claro, um software entregue na data esperada e na qualidade ideal para que os usuários sintam a fluídez dos processos. Observo até pelos meus contratantes que geralmente estão (ou estavam) trabalhando com outros devs e empresas e dispensarem todos para trazer todas as demandas para minha empresa. Pelo menos na minha visão, os processos além de codar elevam a qualidade de entrega, facilitam o processo de desenvolvimento e tornam o projeto mais dinâmico e alinhado com as expectativas das entregas.
Tenho visto muito naquela rede (X) os devs listando profissões que qualificam como desnecessárias (DBA, UX/UI, Gerente, Arquiteto, QA, PM e PO, Scrum Master, etc) sendo que nem conseguem entregar essas competências e mal conseguem cumprir prazos. Por que alguns devs se incomodam tanto com essas especialidades? Na opinião de vocês, não faz mais sentido planejar e arquitetar antes de executar (deixando para quem tem competência ou conquistando essa competência)?