Postagem em destaque

Procurando Profissional em Análise de Processos de Negócios, BPM, BPMS e Melhoria de Processos, para atuar na Região Metropolitana de Belo Horizonte?

Marco Gandra Brasileiro – Casado 41 anos - CNH B Nascido em Belo Horizonte e-mail gandraribeiro@gmail.com ...

Pesquisar neste blog

2 de jun de 2012

O drama da homologação

Por: Marcelo Arrevabeni 
Em: http://feedproxy.google.com/~r/imasters/~3/9iPf9OJTRu8/story01.htm


Hoje eu gostaria de falar das dificuldades da homologação de entregas de software. É, isso mesmo, você ouviu direito: HOMOLOGAÇÃO. “Uai, mas do que esse cara esta falando? Quem precisa de homologação quando se tem entregas constantes e refatoração??? Que cara antiquado…”.
A questão é, por mais inconveniente que seja falar isso, por mais que seja chato, nem todos os clientes aprovam/querem/curtem a ideia de entregas constantes de pequenos conjuntos de funcionalidades. Muito menos entregas que, isoladas de um todo, não representam (pelo menos aos olhos do cliente) valor para o negócio.
[Cena 1]
“Ding dong”, toca a campainha. O cliente abre a porta. Surge desenvolvedor com quatro rodas empilhadas e um notebook.
Desenvolvedor: - Caro cliente tenho uma entrega para você. As rodas do carro estão prontas.
Cliente: - Uai, mas o que eu vou fazer com quatro rodas, sem um carro para elas estarem? 
- Ahh, mas eu tenho este teste aqui – fala o desenvolvedor, mostrando o notebook – que mostra que as rodas funcionam perfeitamente. E caso algo não esteja funcionando posso ir fazendo correções até que elas estejam perfeitas!
- Amigo, eu quero um carro, não rodas e testes. Nem vou ficar testando até ficar perfeito. Sou um cara ocupado pacas, só volte aqui com esse carro completo…
O foco é entregar software, certo?
Certo, mas software que funcione. E o processo de refatorar até acertar, esperando chegar ao ponto certo, pode nem sempre ser o ideal.
Obviamente tudo depende do cenário em que você esta atuando.
Às vezes desenvolvemos aplicações voltadas para novas necessidades. Ou para nichos. Cheias de incertezas e de possibilidades, se baseiam em um feeling de que as pessoas precisam daquilo, só que ainda não sabem. 
Um microblog, uma rede social voltada para um publico especifico, um jogo para smartphone. De início acreditamos em algumas premissas, em algumas funcionalidades básicas, e a partir delas desenvolvemos e entregamos algo. Medimos os resultados, via reação e consumo do público-alvo (o cliente) e à medida que estas necessidades vão se esclarecendo, vamos refatorando o que existe, retirando o que se mostrou desnecessário, melhorando o que fez sucesso e entregando mais novidades.
Domínio emergindo, entrega constante, refatoração. Tudo como a teoria atualmente vigente prega. Esse é o lado sexy do desenvolvimento de software, que deu origem a produtos milionários como Facebook, Twitter, Instagram e muitos outros.
Porém muitas vezes construímos sistemas de informação para domínios complexos. Complexos (eu friso) e já estabelecidos. Com o objetivo de atender dezenas de tipos de cliente diferentes, esses domínios são erguidos sobre regras pré existentes, mas nem sempre claras, regidos por normas governamentais e internacionais. Sistemas que lidam com negócios, com a circulação de bens de consumo e que dão vida as corporações.
É nesse cenário que muitas vezes o “domínio emergindo, entrega constante, refatoração” não funciona tão bem. Porque?

Problema 01 – Nem sempre é possível isolar uma funcionalidade

Processos de negócio são formados por grandes blocos de ações, checagens e validações. Determinar onde as funcionalidade começam e terminam, onde fica cada coisa, qual é o significado de cada conceito é um trabalho árduo e que aos poucos vai dando forma a um domínio que mapeia e dá vida as necessidades do cliente. 
A questão é que muitas vezes ter uma pequena parte dessa necessidade já realizada não representa nada para o cliente. Precisaríamos de recortes maiores. Mas estes recortes maiores têm um custo muito mais alto para que sejam apresentados. 
Numa metáfora de construir um corpo humano, entregar uma válvula do coração não representaria um progresso real para o cliente. Porém, entregar um coração inteiro iria demandar um simulador de corpo humano complexo o suficiente para que fosse feita a validação real. E os custos deste simulador provavelmente seriam tão altos que inviabilizaria o projeto.

Problema 02 – O tempo do P.O. vale ouro

O papel de P.O. é uma criação da TI. Podemos falar para o cliente que irá nos guiar durante o processo de desenvolvimento “você será o product owner. Sua responsabiliade é nos guiar durante o processo de desenvolvimento indicando o que agrega mais valor ao projeto, aprovando as entregas e estando a nossa disposição full time”
Por mais que o cliente fale “Ok, ok”, ele tem outras atividades e responsabilidades, que tornam seu tempo muito muito precioso. Dessa forma nem sempre teremos a oportunidade de acertar por “tentativa e erro”, refatorando até chegar ao ponto ideal. Até porque várias entregas que não chegarem ao ponto (o famoso “é quase isso”) podem minar a credibilidade do projeto.

Problema 03 – Nem sempre é o P.O. que aprova as entregas

“Uai, mas não devia ser assim.”. Nem sempre :/ .Às vezes outros clientes têm que aprovar, afinal o P.O. representa os stakeholders que serão, em última instância, os usuários (diretos e indiretos) do sistema.
Solução? Como sempre, a velha história de que não existe bala de prata.
Se o negócio for complexo, o foco na sua organização e posterior formação de um domínio consistente ajuda muito. É muito mais fácil (e aceitável aos olhos do cliente) refatorar uma interface gráfica do que alterar todo um sistema de cálculo ou de validação. No final das contas é o domínio que dá a segurança para o usuário de que suas necessidades vão ser atendidas. 
Daí, gastar um tempo maior construindo o conhecimento (a famosa “análise”) do negócio, pode ajudar bastante. Conhecendo o negócio do cliente como um todo fica muito mais fácil determinar como efetuar recortes mais efetivos e com isso determinar pontos de entrega de pacotes maiores mas que facilitam a homologação com o usuário final. 
Desse modo o P.O. até poderia receber as entregas com mais constância, no final de cada sprint. Porém, os usuários finais/stakeholders as validariam a partir de “pacotes maiores”. Resumindo, o P.O. até olha as rodas, mas ele as testa com o usuário final quando existe uma carroceria e um eixo. Carroceria + eixo + rodas = volta de carro e com isso sensação real de progresso.
“Domínio emergindo, entrega constante, refatoração” é perfeito no mundo das intenções, mas nem sempre viável no mundo real. Se você conseguir estabelecer esta dinâmica, lindo, ótimo, maravilhoso. Mas se prepare para a frustração, porque nem sempre é isso que o cliente quer. E é ele que paga nossos salários.



Nenhum comentário:

Postar um comentário