Desenvolvedores que sabem dizer NÃO. Você é um deles?

Qualquer semelhança com o mundo real.. Não é mera concidência.

Marco (o gerente ansioso, na segunda-feira) – Eu preciso desta funcionalidade entregue até Sexta-Feira. É ordem do cliente!

Bernardo (o desenvolvedor) – Hmm. Marco, sei não. Esta funcionalidade lida com três itens regulatórios, uma nova aba com 30 campos e um relatório complexo. E eu ainda preciso testar tudo isso e cuidar da implantação no nosso ambiente de nuvem.

Marco (o gerente mais ansioso ainda) – Olha. Eu REALMENTE preciso desta funcionalidade realmente para Sexta-Feira. O prazo já está dado. Faça o que for necessário e não me venha com esta bobagem de precisar fazer testes e código limpo.

Bernardo (o desenvolvedor passivo, resmungando..) – Ok, chefe. Eu vou tentar!

Marco (aliviado) – Ótimo, então. Estou já no aguardo. 

….

Na sexta-feira…

Marco  – Bernardo, o código já está pronto? Cliente me ligou aqui já.

Bernardo – Ainda não, chefe. Mal consegui terminar o cadastro. E tenho apenas o protótipo do relatório. E o Cauã ainda está testando o cadastro.

Marco – P#@*$ Bernardo. Você não consegue cumprir prazos. Que m*#&$! O que vou dizer para o cliente?

Bernardo – Olha. Eu disse apenas que ia tentar. E não meu culpe por isso porque o requisito veio incompleto, o analista financeiro do cliente não tinha disponibilidade para tirar minhas dúvidas. Não é minha culpa!!!

E mais uma pequena tragédia da vida real da TI ocorre.

O que aconteceu aqui?

  • Se você é um desenvolvedor, você vai pensar que a culpa é do chefe malvado e opressor. E isso não é um problema do pobre desenvolvedor, que fez o seu melhor.
  • Se você é um gerente, você vai pensar que o problema é do desenvolvedor desmazelado e sem compromisso.

Mas vamos sair para a TI por um momento.

Você entra em um Uber e precisa cruzar o centro da sua cidade. Você precisa estar no seu compromisso em 10 minutos. Mas o motorista sabe que isso não é possível, pois isso leva 30 minutos no horário da tarde. E você como cliente pode protestar e dar um soco no capô do carro e dizer. P*##&#…. eu preciso estar lá em 10 minutos. E ainda assim qualquer motorista responsável irá dizer que isso não é aceitável. E tentar ir mais rápido não irá mudar a situação.


Do; or Do Not. There is no Try!

Diga Sim ou… Diga Não.

O que o desenvolvedor deveria ter feito?

  • Dizer sim, se ele possui uma experiência com este tipo de demanda e se sente bastante confortável com os prazos.
  • Ou dizer que ele não consegue entregar este escopo no prazo estabelecidor.

“Mas isso não é meu problema” …. pode pensar um desenvolvedor. “A culpa é do meu chefe”.

Sinto informar, mas é você que está sendo demandado. E então é sua obrigação ética dizer se a tarefa é viável ou não.

Se fazer de vítima (passivo) e depois ficar putinho na Sexta-feira (agressivo) é atitude imatura do esterótipo profissional passivo-agressivo. Isso demonstra, no mínimo, um quociente emocional ainda que precisa ser desenvolvido. Para não dizer um quarto palavrão no meu texto, que seria muito deselegante.

Entendi…  Então preciso apenas dizer Não!?

A resposta é… Não.

É fácil dizer Não e não fornecer opções. Qualquer criança de 6 anos faz isso. Mas enquanto profissional pleno você deve apresentar opções. E isso envolve negociações e encarar sem medo o conflito momentâneo com o seu chefe.

Bernardo (desenvolvedor responsável): Olha, Marco. Sexta-Feira não é aceitável. Eu preciso fazer a modelagem de dados, o protótipo de telas, a implementação do código. Preciso limpar dúvidas de regras de negócio com o cliente e isso vai demandar 4 horas apenas de reuniões. E preciso fazer os testes de unidade, refatorar o código, preparar a implantação na EC2 e coordenar os testes com o Cauã (Analista de testes) e com o time da infraestrutura.

Marco (gerente ansioso): Testes de unidade. Refatoração. Isso é frescura de desenvolvedor Nutella! ha ha…  E ..hmmm… podemos envolver o Cauã apenas na Sexta-Feira e pular pode parte dos testes do relatório, não? E você pode fazer horas extras novamente! Tenho certeza que sua esposa irá entender a gravidade da situação

Bernardo (o desenvolvedor responsável):  Não fazer testes é gerar débito técnico. Você sabe, Marco, pela experiência do ano passado o que acontece quando envolvemos o time de testes apenas no final da demanda. E não criar a automação de testes de unidade vai gerar efeito muito ruim em médio prazo. E tudo isso vai afetar a imagem do produto e da nossa empresa.

Bernardo (o desenvolvedor responsável): E veja. Insistir em fazer horas extras em base continuada não irá melhorar a sirtuação. Você e eu sabemos que pessoas cansadas inserem mais defeitos no código. Já estou com 15 horas no banco de horas neste mês e não posso comprometer mais o tempo com meus filho e minha esposa.

Bernardo (o desenvolvedor responsável): Ao mesmo tempo … podemos buscar negociar com o cliente o escopo. Também fiz uma estimativa detalhada aqui com o João e a Marina e vi que podemos trabalhar primeiro na parte regulatória e negociar a nova aba com os dados adicionais que ele está pedindo. E podemos fazer uma consulta momentânea para exibir os dados centrais do relatório que ele está pedindo. E com isso podemos buscar negociar a outra aba do cadastro e o relatório para a próxima semana.

Marco (o gerente ainda ansioso): E então você me entrega isso na Sexta-Feira!

Bernardo: Sem problemas, chefe! 

O que aconteceu aqui?

O nosso desenvolvedor trouxe a realidade para a sala. Ele não removeu da sua lista as atividades essenciais, como testes de unidade ou refatoração. Ele sabe que isso seria irresponsável pois somente traria passivo técnico para ele e para o time. Ele fez um trabalho de estimativas com o time. E ele negociou o escopo e apresentou alternativas para a sua chefia.

Mas… eu tenho medinho de contestar com o meu chefe!!

Sim. Quanto tinha seis anos, eu também tinha medo de contestar meu pai. Mas quando você é adulto, você precisa ser responsável pelos seus atos.

E se você é um desenvolvedor responsável você precisa sim negociar e tomar atitudade responsáveis na hora de fornecer compromissos. Por experiência ao longo dos meus últimos 25 anos em TI, observo que a solução simples “Dizer sim” pode gerar um conforto momentâneo, mas o problema irá voltar. Muito pior e ainda sim teremos uma situação muito desagradável.

Negociar pode também ser desagradável. Você pode ter medo de ser repreendido. Você pode ter medo de ser despedido. Você pode ter medo do seu chefe ficar com raiva de você. Mas por experiência vejo que bons gerentes não despendem profissionais que contestem seus pedidos. Eles despedem profissionais que falham continuamente na entrega dos seus acordos.

E conheço vários bons gerentes que conheço esperam que os desenvolvedores saibam contestar. Eles passam a respeitar aqueles profissionais, muito mais que os passivos-agressivos que somente sabem resmungar e criticar o chefe na hora do almoço com seus coleguinhas de 6 anos de idade.

E saber contestar envolve:

  • Estudar com o profundidade o problema sendo dado;
  • Realizar diagnósticos precisos;
  • Apresentar alternativas;
  • Buscar soluções ganha ganha.

Mas… você não conhece o meu chefe! E aqui na minha empresa é diferente…

Talvez sim. E apesar disso você não irá cruzar o centro da capital do seu estado em 10 minutos no horário de rush. Não de carro. E dizer sim de forma ingênua não irá resolver o seu problema.

Ser transparente, que por acaso é um dos pilares dos métodos ágeis, é o caminho a ser seguido.

E onde aprendo a negociar com o meu gerente? No SEBRAE?

Para fazer negociações de desenvolvimento de software, não, infelizmente.

Recomendo duas leituras obrigatórias para o desenvolvimento emocional de todo bom desenvolvedor. O primeiro discute como a importância da atitude ética, técnicas de negóciação e como lidar com a natural pressão gerencial em toda empresa.

Já o livro abaixo é um dos cinco melhores que já tive a oportunidade de ler em minha vida e teve profunda influência no meu modo de pensar em TI. Ele irá lhe trazer uma visão sóciotécnica muita rica sobre o que é trabalhar em TI e 50 ferramentas para você usar no seu dia a dia de trabalho para bater as pressões de tempo que a realidade corporativa nos traz.

Quando a circunstância é boa, devemos desfrutá-la; quando não é favorável devemos transformá-la e quando não pode ser transformada, devemos transformar a nós mesmos, Victor Frankl

 

CERTICS – A Nova Certificação de Software Brasileira

Todos que desenvolvem ou mantém software conhecem (em algum nível) os modelos de maturidade do CMMI e MPS-BR. Didaticamente, podemos dizer que estes modelos avaliam a maturidade de uma organização no desenvolvimento de software (CMMI-DEV ou MPS-BR Desenvolvimento), gestão de dados (DMM), gestão de serviços (CMMI-SVC ou MPS-SV) ou mesmo a gestão de aquisição de software (CMMI-ACQ ou MPS-Aquisição). Os modelos de maturidade não devem ser confundidos com processos de software, i.e., eles apenas definem que objetivos uma organização deve atingir. O processo pelo qual uma organização atinge um objetivo (o como) não é relevante para estes modelos de maturidade.

Naturalmente, toda organização requer processos para desenvolver software ou fabricar produtos de software e diversos normativos de indústria apresentam melhores práticas para orientar a construção de processos de software. Um destes normativos é a ISO 15504, também chamada de SPICE. A partir dos princípios do SPICE, o Ministério da Ciência, Tecnologia e Inovação criou esta nova certificação, chamada de CERTICS. Em termos técnicos, o CERTICS tem por objetivo padronizar o processo de fabricação e evolução de produtos de software de empresas que desenvolvam software.

A CERTICS não deve ser confundida com um mero processo de desenvolvimento de software como por exemplo o RUP. Ela é muito abrangente e cobre todo o processo de fabricação de um produto, que é muito mais amplo que “fazer um software”. Exemplos de aspectos incluidos na CERTICS incluem ações de monitoramento de mercado ou mesmo ações de monitoramento de necessidades dos clientes.

Mais uma certificação? Para quê?

A CERTICS tem um objetivo nobre, que é fornecer vantagens para produtos de software desenvolvidos no Brasil. Se a sua empresa desenvolvedor produtos e for certificada CERTICS, ela terá benefícios diversos em licitações do governo Brasileiro.

“Dentre os benefícios de uma certificação de credibilidade que comprove desenvolvimento e inovação tecnológica em território nacional destaca-se a preferência do software certificado em licitações. Além disso, o certificado é também uma forma de comunicar ao mercado, de forma legítima, a existência de práticas e competências tecnológicas relacionadas ao software.”, Modelo de Referência do CERTICS.

Faço Produtos há 1450 anos? Preciso mesmo desta certificação?

Não. Você não precisa, mas pode ganhar muito com ela.

Observo da minha experiência de consultoria em empresas de produtos que aspectos primários que deveriam ser endereçados por estas empresas são completamente ignorados. No CERTICS, é esperado que toda empresa fabricante de produtos atenda aos 16 resultados esperados indicados na figura abaixo.

Resultados Esperados no CERTICS

A CERTICS ainda está em seu estágio embrionário e deve evoluir bastante com as críticas da comunidade de software. De toda forma, considero a iniciativa interessante. Se a sua empresa faz software, mantenha um olho nela. No mínimo, ela irá indicar pontos de atenção e preocupações que o seu produto de software deve atender.

Para quem tiver maior curiosidade sobre este novo modelo, recomendo os seguintes sítios.

– FAQ – http://www.certics.cti.gov.br/perguntas-frequentes.html

– Modelo de Referência – http://www.certics.cti.gov.br/downloads/ModeloCERTICS_Detalhado.pdf

– ISO 15504 – Definições básicas.

Os Sete Pecados Capitais do Desenvolvimento de Software

O quadro o Jardim das Delícias Terrenos é um dos mais impactantes quadros a avisar aos transgressores da fé católica o destino deles ao final de uma vida impura. Obra-prima de quase 2 metros de altura e largura, o quadro retrata o inferno dos luxuriosos, gulosos, avarentos, invejosos, preguiçosos, iracundos e vaidosos.

O Jardim das Delícias Terrenas
Obra prima de Hieronymus Bosch, pintor holandês contemporâneo de Leonardo da Vinci

 

Se a engenharia de software tivesse um inferno, poderíamos nos arriscar, como Dante Aligheri, a descrever os sete pecados capitais do desenvolvimento de software que os porquinhos de software cometem em base diária. Mary Poppendieck, uma das autoras doLean Software Development, descreva 7 formas de desperdício no desenvolvimento de software. Apresento e contextualizo estes pecados capitais abaixo no dia a dia do trabalho de software.

1. Funcionalidades extras. Pesquisas de institutos como o Standish Group (XP Conference, 2002) mostram que metade das funcionalidades de um software são raramente ou nunca usadas. Ainda assim, é muito comum que desenvolvedores “criativos” introduzam funcionalidades não desejadas em seus software que não trazem valor agregado algum para os seus clientes. A redução do desperdício tem forte relação com escrever menos linhas de código.

2. Transferência de responsabilidades, conhecimentos, ações e feedbacks. O uso de papéis muito especializados é um sintoma deste problema. “Arquitetos” e “projetistas” que não sabem codificar, “desenvolvedores” que não sabem testar ou implantar software e “gerentes de projeto” que se orgulham de não entrar em temas técnicos são exemplos de handovers (repassese fontes comuns de desperdício.

3. Defeitos. Se orgulhar de ter um time de testes que encontra muitos defeitos é no mínimo contra-produtivo. Devemos nos lembrar que defeitos são desperdícios, ou dinheiro jogado fora. As ações de projetos devem impedir que defeitos sejam introduzidos em primeiro lugar, e não focar em pegar defeitos ao final.  Um exemplo simples é no ciclo tradicional de especificação, codificação e testes. Ao invés, o teste deve validar e corrigir a especificação antes que a primeira linha de código seja escrita, visto que a maior parte dos defeitos nasce ainda na especificação do software. Da mesma forma, é papel do desenvolvedor usar técnicas diversas (refatoração, teste de unidade e integração contínua) para reduzir a quantidade de defeitos introduzidas no software.

4. Débito Técnico. Fazer código de má qualidade tende a gerar débito técnico no código, módulo e arquitetura de um produto. O débito técnico gera um efeito muito ruim a médio e longo prazo e gera efeitos colaterais no produto em pontos não imaginados. Livros como “Clean Code”, do Robert Martin, exploraram a criação de código de qualidade

5. Trabalho em progresso. Manter uma longa lista de tarefas com o status em  ”execução” esconde problemas e eventualmente gera desperdício. Cada pessoa de um time deve manter o mínimo número de tarefas abertas. Cada tarefa aberta deve ser rapidamente terminada para reduzir o seu tempo de ciclo, evitar retrabalhos e trabalho multitarefa. Um exemplo vem da metodologia japonesa chamada Kanban, que introduz o conceito chamado (WIP). O WIP (Work In Progress) tem um valor limite pequeno (tipicamente 3) e impede que uma pessoa tenha mais de 3 tarefas em execução. Um outro exemplo de combate a este desperdício é a prática de entregar software com frequência para os usuários chave, que limita o tamanho do backlog de tarefas em aberto para todo o time de desenvolvimento.

6. Trabalho multitarefa. Há algum tempo este mito assola os times de software, atolados no trabalho de novas demandas e na resolução de defeitos e adaptações de diversos softwares em paralelo. Estudos diversos mostram que o fator multitarefa reduz a produtividade, gera desmotivação e trabalho de pior qualidade, o que introduz mais defeitos e gera mais trabalho em progresso.

7. Esperas e atrasos. Provocar esperas e atrasos gera um efeito nocivo na produtividade do time e é também uma forma de desperdício. Por exemplo, enviar um email para uma equipe de desenvolvimento validar um documento de casos de uso gera espera, atraso e descontinuidade do trabalho. Apresentar este documento ao vivo melhora o entendimento para todos e também reduz ciclo de validação do documento gerado. Allistar Cockburn descreve a prática chamada de “Radiadores de Informação” em seu método ágil chamado Crystal Clear, que consiste em manter pessoas próximas e privilegiar a comunicação ao vivo com o uso de quadros brancos. Outros métodos ágeis como o Scrum ou o XP também advogam práticas similares.

Eliminar desperdícios é chave para gera software mais eficaz e em menos tempo para clientes. Um bom livro sobre este tema é o livro: Implementing Lean Software Development: From Concept to Cash, de Mary e Tom Poppendieck.

Lean Software Development