Olá, Mentes Tech!
Se você disser sim, para qualquer das perguntas abaixo, este texto é para você.
Tenho retrabalho ?
A minha entrega não cumpre com o esperado pelo cliente ?
Não consigo entender o que o meu cliente quer ?
Na carreira de um Engenheiro de Software, isto é mais comum do que parece.
E pode acontecer quando o cliente está indeciso, quando não há clareza dos objetivos, quando não está relacionado a alguma métrica ou algum número que você gostaria que aumentasse ou diminuísse, uma ui que não está amigável.
Note que as situações o problema não está na sua implementação, mas na forma como você entendeu o desafio. concorda que aqui temos uma possibilidade do ponto de falha ser o planejamento, em vários níveis ?
Mas o meu foco é no desenvolvimento de software, imagine que você possui uma especificação do que o cliente quer.
Alinhe expectativas, faça protótipos, mapeie os pontos de solução em alto nível, um ponto de solução pode ser granular e pode chegar a nível de registradores, dependendo da entrega.
Antes de colocar a mão na massa.
Após alguns anos fazendo o planejamento antes da implementação, ir para IDE é somente para digitar, pois a solução já está validada planejada e vai fazer exatamente o que foi proposta para fazer no planejamento, note que todo esforço está concentrado no planejamento e não na execução.
Codificar virou apenas uma tarefa de digitação, ou delegar para o Copilot.
Como você planeja suas entregas ?
Top comments (2)
Muito Legal o conteúdo.
Eu atuo em fabrica de software e infelizmente raramente para não dizer nunca esse cenário se aplica como dev sou o ultimo na hierarquia, então muitas vezes o que eles querem saber se da pra fazer e quanto tempo leva.
Geralmente os protótipo são print de coisas rabiscada no paint, estou uns 7 anos nessa vida ja trabalhei em grandes corporações e startups no inicio de vida e no fim do dia o que conta e a entrega e quanto mais rápido melhor, dito isso não estou reclamando faz parte do jogo e a gente joga os 90min. rsrs
Parabéns pelo conteúdo!
@andersonpull
Aproveitando para falar sobre o processo de desenvolvimento, tenho o hábito de utilizar os dados fornecidos pelo protótipo do Paint por exemplo, para criar um teste (TDD), visando atender uma expectativa delineada no protótipo.
Isso me permite validar e corrigir erros precocemente.
Dessa forma, é possível ajustar o rumo ainda na fase de planejamento, evitando investimento excessivo no código.
Quando surgem obstáculos durante o desenvolvimento, retorno às etapas anteriores. Muitas vezes, uma falha em alguma fase do planejamento pode ser identificada e corrigida.