Quando dizer não?

Sem dúvidas dizer não em um ambiente corporativo por vezes é extremamente complicado e por muitas vezes desencorajado em algumas organizações.

Quais as implicações de dizer SIM, quando deveria ter dito NÃO?

Quando você diz SIM, você está assumindo a responsabilidade de algo que você sabe que não poderá cumprir.

Vamos ao exemplo:

Você é desenvolvedor e precisa realizar uma entrega de alguns requisitos em 10 dias, seu gerente pede mais 1 requisito que irá levar 1 dia para desenvolve-lo, e enfatiza que esse requisito e os demais precisam ser entregues no prazo inicial. Diante da situação você apenas diz: Ok, vou ver o que consigo fazer.

Ok, vou ver o que consigo fazer: Isto na cabeça do gerente é um SIM.

Você assumiu um requisito a mais no projeto, não teve mais tempo, e vai precisar trabalhar depois do expediente para poder atender esse novo requisito.

Na próxima ocasião que seu gerente precisar de novos requisitos, ele não irá se importar já que você entregou no prazo, e isso vira uma bola de neve.

O que devemos fazer, ao dizer NÃO?

O melhor caminho é sempre o dialogo, se o cliente precisa de um requisito e o prazo não irá aumentar, negocie a retirada de requisitos que não foram iniciados, se não pode ser retirado requisitos, negocie funcionalidades dos requisitos,  a retirada de alguma funcionalidade pode ajudar a cumprir o prazo sem afetar as expectativas do clientes.

Eles são profissionais

No prefacio do livro O Codificador Limpo de Uncle Bob, Matthew Heusser conta  uma história vivenciada por ele quando fazia parte de uma equipe de desenvolvimento que para entregar um produto, trabalhou exaustivamente para poder cumprir um prazo, e que para lançar o produto precisava que 4 arquivos fossem revisados pelo jurídico da empresa, porém eles foram censurados ao indicar que o jurídico trabalhasse no final de semana, pois eles eram profissionais .

Profissionais da tecnologia da informação por vezes somos tratados como o menino da TI, quebra galho, um faz tudo dentro das empresas.

Enquanto você profissional, que “perde” horas estudando para se manter atualizado, que faz cursos e certificações, não começar a se tratar como Profissional, seu gerente, a empresa que você trabalha e seu cliente, também não vão te tratar como tal.

Não cause danos ao código

A primeira coisa que vem a cabeça, quando pensamos em não causar danos ao código, é que precisamos testa-lo, e para isto é necessário uma mudança de pensamento e da forma como escrevemos nossos códigos.

Durante muito tempo pensamos que escrever testes, eram uma perda de tempo, e que entre entregar um item sem teste e no prazo valia mais, que atrasar um pouco a entrega com os testes escritos da maneira correta, pois nada adianta ter testes, que não nada testam e que só fazem volume no projeto.

Escrever testes demandam um tempo, que as vezes pensamos não ter, porém, quando terminamos de escrever aquela feature, o que fazemos? Abrimos a aplicação e vamos testar o processo de forma manual,e se encontramos algum bug? Voltamos para o código e corrigimos, para então repetir todo o processo, até que não seja encontrado mais bugs.
Não seria mais fácil, escrever os testes, e roda-los automaticamente ao invés de fazer todo o processo manual?

Em alguns casos nosso código é tão complexo que é difícil escrever testes para ele, isto é um sinal que devemos repensar aquela feature,  talvez ela esteja com muita responsabilidade.

Um exemplo do título deste artigo:

Desenvolvemos uma feature e não criamos os devidos testes, depois de está funcionando perfeitamente no cliente, precisamos fazer um alteração, quando essa alteração é publicada, em um cenário que já funcionava apresenta um bug. Se tivéssemos criados os testes, esse bug jamais teria ido para o ambiente de produção do cliente.

 “Se você for um cliente de um restaurante, você pediria para o cozinheiro não lavar a mão e as verduras para lhe entregar o prato mais rápido? E se você fosse o cozinheiro, você aceitaria este pedido?” Mendes, Marco

Essa frase foi publicada pelo professor de pós graduação Marcos Mendes em seu Facebook, ele finaliza dizendo: Hora dos cozinheiros… da TI… aprenderem que lavar as mãos não é negociável e faz parte da ética profissional dos seus trabalhos.

A reflexão que fica é: Você comeria a comida feita com a mão suja do cozinheiro?

Como ser um profissional de desenvolvimento de software?

Para responder esta pergunta, iniciei a leitura do excelente livro:  O Codificador Limpo, do Uncle Bob, também conhecido como Robert Martin.

Pretendo criar uma série de artigos baseados neste livro, colocando alguns pontos que considero importantes nesta busca de ser um profissional.

A primeira coisa que temos que responder é: Você realmente quer ser um profissional?

 “Com grandes poderes vêm grandes responsabilidades.”

O verdadeiro profissional tem honra e orgulho, e principalmente, responsabilidade pelo que faz, então você não pode ter honra e orgulho de algo que não é responsável.

Uncle Bob, usa o seguinte exemplo no livro:

Se você permitisse que um defeito passasse por um módulo e custasse à sua empresa R$ 10.000,00, o que você faria?

– O não profissional daria de ombros , diria que “essas coisas acontecem” e começaria a escrever o módulo seguinte.
– O profissional faria um cheque de R$ 10.000,00 para a empresa!

Mudança de pensamento

Precisamos tratar a empresa, nosso cliente e os produtos que desenvolvemos, como se fossem nossos.

O que temos hoje no mercado em grande maioria são pessoas:

  • Que não se importam com a qualidade do que é entregue;
  • Não realizam testes;
  • Não procuram entender o produto, o negocio e a necessidade do cliente.

Hoje temos poucos profissionais no mercado, daquele que realmente faria um cheque para a empresa.