Arquitetura de Informação

18 mar, 2019

Clean Coder – #Parte2 – Como dizer não?

100 visualizações
Publicidade

O Portal iMasters está acompanhando o projeto do desenvolvedor Yan Magalhães, que se propôs a gravar vídeos sobre cada capítulo do livro Clean Coder, de Robert C Martin. Esta é uma das obras mais famosas e lidas sobre código e desenvolvimento em todo o mundo. Em recente sondagem do iMasters, vários desenvolvedores indicaram este livro como fundamental para qualquer profissional do setor, como você pode ler aqui.

Clean Coder

Yan Magalhães é um desenvolvedor que está lendo vários livros sobre sua profissão e tem produzido vídeos para o Youtube, com o objetivo de repercutir esses conteúdos. Sobre a série de gravações a respeito de Clean Coder, ele gentilmente aceitou o convite do iMasters e autorizou a transcrição do seus vídeos aqui no portal.

Na semana passada, você leu sobre a introdução e o capítulo 1 do Clean Coder. Hoje, você assiste ao segundo capítulo aqui e acompanha o conteúdo por escrito a seguir.

O Livro

Como dizer não? (capítulo 2)

Por Yan Magalhães.

“Na nossa área, se passa muito por esse tipo de situação. Às vezes, a gente é muito requisitado ou tem um prazo muito curto e acaba precisando dizer ‘não’ para algumas coisas. O autor do livro coloca algumas situações de como a gente não deve fazer isso ou de como a gente deve fazer isso.

Uma coisa que eu acho que precisa ficar muito clara, em qualquer atividade ou contexto é que é muito importante entender o porquê das coisas. Por que eu estou trabalhando neste tópico? Por que eu estou fazendo isso dessa forma? Quanto mais entendimento e informações você tem, mais você vai ver a relevância daquilo, o tamanho e o impacto que tem sobre seu produto e seu software. Baseado nisso, a gente consegue mensurar o tamanho das coisas e saber o tempo que você vai precisar para fazer aquele trabalho.

Evidentemente, estimativas na nossa área são um problema. Nunca são exatas. Mas, quanto mais prática, mais clareza a gente tem e as chances de acertar ficam muito maiores. O autor fala muito sobre isso. É muito comum, por diversos motivos (pressão de business, contexto de mercado, situação da empresa), a gente estar com um requisito que é muito grande na comparação com o prazo que se tem. Com isso, sofremos algum tipo de pressão, seja do gestor ou de algum outro líder, para que possamos entregar aquela demanda no prazo estipulado pelo cliente.”

“Diante da pressão sofrida, o profissional acaba falando ‘ok, vou tentar’. A gente tem que ter muito cuidado com isso”.
– Yan Magalhães, desenvolvedor.

“Diante da pressão sofrida, o profissional acaba falando ‘ok, vou tentar’. A gente tem que ter muito cuidado com isso, porque sabemos que existe o risco de não conseguir entregar aquela demanda. Então, isso pode aumentar a frustração, caso não se cumpra o prazo. Por vezes, será gerado um desgaste seu e do seu time, por precisar trabalhar muito mais para cumprir um requisito que, talvez, não seja possível atender naquele momento.

Então, será preciso saber lidar com este tipo de situação e saber conversar com seu gestor para achar um meio termo e descobrir o que será possível entregar naquele prazo e atingir a expectativa. Depois dessa primeira entrega, a gente pensa no restante. Esse cenário de grande demanda, é possível lidar muito bem quando se está trabalhando com metodologias ágeis, principalmente o Scrum. Com o Kanban eu tive experiências que não me deram tanta clareza. Com o Scraum, o escopo das tarefas é muito menor e você tem visão do tamanho total do escopo.

Com isso, é muito mais fácil de conseguir reagir ao tipo de situação de grande demanda, diferentemente de quando se está no modelo cascata, que é quando se tem um tamanho grande de coisas que precisam ser feitas e você começa a desenvolver o modelo. Vai desenvolvendo, desenvolvendo e quando percebe, não vê o final, assusta e tem a clareza que aquele requisito não vai caber no prazo.”

Trabalho em Equipe

“O autor fala também sobre trabalho em equipe. É muito importante, não só na nossa área, como na vida. A gente não alcança absolutamente nada sozinho. Em equipe, a gente consegue realizar muito mais coisas juntos e de uma forma muito melhor. Mas é preciso pensar na sua equipe. Tentar cumprir um prazo só para não dizer não, vai sobrecarregar a sua equipe.

A última parte do capítulo 2 é sobre qualidade, que diz respeito à qualidade da nossa entrega e do nosso código. Um exemplo é quando se está em uma situação em que o gestor da nossa equipe tenta negociar o prazo, para que a gente consiga entregar o trabalho em um prazo menor.

O gestor está no papel dele. Ele tem que tentar conseguir essa entrega no menor tempo possível. Mas em nenhum momento ele está pedindo para que você abra mão da qualidade da entrega. Ele não espera que a gente faça um código mal feito, não testado, difícil de manter e de evoluir. Então, essa negociação de prazo não inclui, em nenhum momento, negociar a qualidade do trabalho.

Não adianta nada aceitar um desafio de pegar uma feature muito grande e entregar em um curto espaço de tempo, se a gente for desenvolver da pior forma possível. Não vamos criar uma estrutura boa para conseguir trabalhar os próximos passos dela. Afinal, o software que a gente entrega hoje, é o que a gente vai manter amanhã.”


Para encontrar o Dev

Youtube – https://www.youtube.com/channel/UCTlKQLqY2-JbmMQd4Y7g4LQ

Twitter – https://twitter.com/yaanmagale

Github – https://github.com/yanmagale