Tentarei ilustrar a situação com uma breve história.

.:.

Era uma vez uma empresa de médio para grande porte repleta de sistemas. Como é tradicional, a parte “feijão com arroz” do negócio (processos de apoio – financeiro, contábil, RH…) foi informatizada com um pacote ERP; A parte “filé com fritas” (processos primários – vendas, atendimento…) é um combinado de módulos desenvolvidos internamente com algumas soluções de terceiros. Antenada por necessidade, a empresa em questão, que chamaremos de ACME, já usa mas pouco abusa de conceitos modernos como SOA, BPM e BI.

Assim como acontece em praticamente todas as organizações ao redor do globo, a “Arquitetura Corporativa” da ACME assemelha-se ao retrato do inferno devidamente registrado por uma câmera de 12 megapixels. Consequência natural de anos e anos de projetos “para ontem”, adoção de caixinhas mágicas, fornecedores famintos e voluntariosos e algumas pitadas de modismos. A receita pode variar um pouquinho de empresa para empresa, mas o prato parece ser sempre o mesmo. E é indigesto.

A demanda por manutenção (80%) e novas aplicações (20%) é sempre maior que a capacidade instalada. Fornecedores devidamente homologados adoram essa parte. Afinal, “fábricas de software” (sic) foram inventadas para isso mesmo, certo?

Software é um elemento vital para a ACME. Aliás, deve ser para 80% das empresas. Mas ele ainda não é visto como ativo, como conhecimento. Software é contabilizado como despesa. E é tratado como tal: um mal necessário. Então a ACME brinca de fazer de conta que mantém o cérebro e terceiriza membros, mais precisamente os braços. Traduzindo: uma equipe interna definiria o que precisa ser feito; o “como” e respectiva construção seriam executados por “parceiros”. (Há palavra mais maldita que essa em nosso mundo?)

Acontece que o cérebro é pequeno e fica cada vez menor. Para cada neurônio disponível para “coletar requisitos” (sic), existem dezenas ou centenas de usuários putos da vida, atrasados, indecisos e com hora marcada no psicólogo. Quando muito, uma reunião(zinha) de 1 hora é tudo o que o neurônio tem para entender o que o usuário quer. Desse entendimento nasce um briefing. E dele extrai-se um “cheiro” que, como num passe de mágica, vira compromisso de prazo e custo. Tudo acontece tão rápido que o neurônio nem tem tempo de suspirar.

Com um olho na fila de usuários que aguardam sua vez de choramingar requisitos, o neurônio repassa para o parceiro selecionado por um critério qualquer aquele conjunto de parágrafos desconexos apresentados anteriormente como briefing. Sim, a escassez de neurônios é tamanha que cabe ao parceiro “fechar o escopo” (sic). Com um pouco de insistência e um tanto de sorte o parceiro consegue um ou dois encontros com usuários para desenvolver “casos de uso”. O papo é menos belicoso que aquele entre usuários e neurônios porque o parceiro é “de fora”. Mas, talvez para mitigar riscos de rusgas, o parceiro sempre manda um analista diferente. O rodízio deve seguir a lógica do namoro de jogador de futebol. Mas os usuários já se cansaram de dizer que “eu já expliquei isso antes…”

Tão logo o parceiro se manifeste satisfeito com as informações coletadas (implicitamente ele tá de saco cheio daquelas idas e vindas), tem início um hiato de duração indeterminada (apesar do cronograma assinado).

É marcado para um belo dia (e precisa ser belo mesmo – porque, se ameaçar chover, o parceiro nem tira o carro da garagem) a apresentação do projeto. Dependendo da cara (e do bolso) do sponsor, o evento tem lá suas regalias. Na maior parte das vezes, é só um encontro do parceiro com alguns usuários e um cafezinho. O neurônio autor do briefing é convidado a participar. Claro, se ele ainda estiver na folha de pagamentos da ACME.

O encontro é tenso. Já começa nervoso. E os usuários não colaboram com o clima: “Nossa, atrasou tanto desta vez, né?”

Num caso específico a apresentação começou por uma parte bem complicada do projeto: uma tela de cadastro de clientes. O usuário do departamento de marketing mal esperou a tela acabar de ser “renderizada” (sic) e já reclamou: “Nossa logomarca sofreu pequenas alterações há 6 meses. Adequação para a nova realidade Web 2.0 e patati patatá…”. Foi interrompido. O parceiro falou que ninguém avisou. “Mas é uma pequena alteração besta…”, disse, tentando encerrar o assunto. Afinal, o importante era o conteúdo! O cara do marketing não concordou, mas silenciou.

Para testar o conceito de usabilidade o parceiro pediu que um outro usuário, sem nenhum treinamento, fizesse o cadastro de um cliente. Claro, ele escolheu a menininha mais bonitinha que estava na sala. E quase pegou em sua mão para guiar o mouse na direção do botão “Incluir”. “Por que esse botão tem a cor diferente dos outros?”, questionou a bela. Não mereceu resposta, mas seguiu em sua nobre tarefa.

Até que, após digitar nome, CPF e logradouro do namorado (para infelicidade do parceiro), se deparou com uma combo box onde ela deveria selecionar a Unidade da Federação. Clicou na setinha e viu uma lista mais ou menos assim: SP, BA, MG, RJ, DF, RS, SC, AC, RR, PA, MS, AM…

Não se sabe quem disparou primeiro, se o neurônio, a bela ou o cara de marketing. Talvez tenha sido um coro: “Caramba, por que a lista não está ordenada?”

O parceiro engoliu seco e sacou da mochila importada um calhamaço manchado e cheio de dobras que apresentava na capa a logomarca da ACME (desatualizada) e o nome do projeto. Passou pelas (33) páginas do caso de uso em questão – de trás para frente e de frente para trás – e cravou: “Não tá escrito aqui que a lista deveria ser ordenada. Isso é mudança de escopo!”

.:.

A história acima é uma ficção baseada em fatos reais. Só as trechos mais exagerados são verdadeiros.

A foto utilizada, “Lift Shaft Within the Old Town Hall Tower”, foi devidamente surrupiada de lostajy. Ela foi liberada com licença Creative Commons.

Quais são os pontos de vista relevantes? Depende do projeto. Trata-se de um empreendimento que exige interfaces complexas com usuários? A equipe deveria contar com um especialista em usabilidade. O projeto requer um sofisticado desenho de bases de dados? A presença de um especialista em bases transacionais, analíticas e em gerenciamento de conteúdo não estruturado é recomendada. O projeto requer um preciso dimensionamento de servidores e da rede? Convoque o especialista em infraestrutura. Claro, o AN é presença obrigatória. É sua responsabilidade *ensinar* o problema para a equipe e auxiliar no desenho da solução. Essa reunião de especialistas é o que chamo de “Parlamento“.

Parlamento, s.m. (do inglês parliament)
assembléia ou câmara legislativa;
ato de falar.

Cabe aqui um lembrete: tomando o RUP ou o OpenUP como referência, ainda nos encontramos na fase conhecida como Incepção. Não iniciamos ainda a etapa de elaboração que, segundo aquelas propostas, resulta no “Lifecycle Architecture Milestone” (veja figura abaixo ). O parlamento foi convocado para desenhar uma ou mais soluções para o problema colocado, e apoiar o AN na elaboração de uma proposta (ou documento de visão, ou project charter, ou…).

Ao aprender e debater cada caso de uso, começando sempre por aqueles mais críticos para o negócio, os participantes do parlamento “rabiscam” as primeiras idéias de solução. São essas idéias que, em determinado momento, são agrupadas. Como vimos no artigo anterior, podemos ter até três alternativas de solução – três agrupamentos de idéias.

Cada idéia deve ser avaliada por todos os participantes. Antes dos chutes (ou estimativas), espera-se uma classificação bem simples: a implementação daquela idéia é Simples, de Média Complexidade ou Complexa? Ainda estamos preocupados em descobrir qual é a melhor solução para aquele problema. Lembrando: “melhor” não significa a mais sofisticada ou a mais econômica. A melhor solução será aquela que estiver mais alinhada com os objetivos e restrições do negócio.

Neste momento eu gosto muito de utilizar uma ferramenta que, aparentemente, é meio bobinha. Estou falando da Matriz SMBP (confesso, acabo de inventar um nome para o brinquedinho). Veja o rabisco abaixo:

Todo caso de uso e requisito aprendido e desenvolvido pelo AN mereceu uma classificação simples: Fundamental, Importante ou Opcional. Vamos assumir que esta classificação equivale a 3, 2 e 1 ponto, respectivamente. Somamos a pontuação de todos os requisitos registrados em um caso de uso e dividimos pelo número de requisitos. Ou seja, calculamos a pontuação média de cada caso de uso.

Todas as idéias de solução propostas pelo parlamento também foram classificadas, como Simples, de Média Complexidade e Complexas. Assumiremos aqui os valores 1, 2 e 3 pontos, respectivamente. Como a complexidade foi avaliada por vários especialistas, também calculamos a pontuação média. Pronto, agora temos as coordenadas que permitirão o posicionamento de cada idéia na matriz SMBP.

Todas as idéias que aparecerem no quadrante de “Sonho” devem ser consideradas. Todas são de fácil implementação e satisfazem requisitos que foram considerados fundamentais para o negócio. Podemos dizer que um projeto que só tem itens neste quadrante também é um projeto “dos Sonhos”. Pena que eles são raros. Existem também aquelas idéias cuja implementação é mais difícil. Como elas também representam alto valor para o negócio, as chamamos de “Mal Necessário”. Muito necessárias. Não podemos ignorá-las.

Já os dois quadrantes da parte inferior da matriz representam itens que devem ser muito questionados. As “bobeirinhas” um pouco menos, já que sua implementação é relativamente simples. Mas das idéias “Pesadelo” devemos fugir. Além de representar pouco ou nenhum valor para o negócio, são todas de implementação difícil. Como justificá-las?

Como eu disse, a ferramenta parece uma besteirinha. Mas é muito útil na tomada rápida de decisões. Permite que toda a equipe se concentre em itens que realmente fazem a diferença em um projeto. Didática, a própria matriz pode ser utilizada para justificar o escopo do projeto para um cliente. Permite também que se decida a meta de cada iteração ou o escopo de versões posteriores do produto em questão.

O parlamento, uma reunião que deve durar algo entre 1 e 4 horas, fornece bases para que o AN desenvolva a melhor proposta ou estudo possível. Respeita as inevitáveis restrições de custos e tempo – “é pra ontem!” – ao mesmo tempo em que elimina riscos e armadilhas. Não todos, é claro, mas é óbvio que a proposta ou estudo gerado é mais forte, melhor fundamentado.

É cara? Se comparada às propostas “bumba-meu-boi” e “balança-mágica” que algumas empresas elaboram, sim. Mas é um custo facilmente recuperado em um projeto que já começa em trilhos certos, sem desvios ou surpresas. E, claro, se estivermos falando de propostas comerciais, o método aqui sugerido aumenta consideravelmente as chances de vitória.

.:.

Notas:

1. Sim, *Especialistas*. Não coringas-especialistas-generalistas que chutam com as duas. Isso não tem nada a ver com Taylor e afins. O papo é cansativo, mas insistirei: é papo de Drucker, que diz que “conhecimento, por definição, é especializado“. Todo trabalhador do conhecimento (knowledge worker) busca (ou deveria buscar) a especialização. Como sou especialista em chatice, explorarei mais o tema em futuros artigos. A citação de Drucker eu tirei de “O Advento da Nova Organização”, artigo publicado na Harvard Business Review em 1988 (edição jan-fev).
2. Figura (indevidamente?) surrupiada do OpenUP (que não deveria ter Copyright).
3. Adoro nossa criatividade quando o assunto é a geração de propostas. O método “bumba-meu-boi” parece ser o default: um cara de vendas (ou pré-vendas) vai lá no cliente, se esforça para entender suas “dores”, volta correndo pra casa e se desdobra para traduzir aquilo tudo em cifras. Sim, porque a primeira coisa que seu chefe quer saber é o valor do projeto. “Bumba meu boi bumbá – é melhor alocar e cobrar por mês!!”, hehe.
   A “balança mágica”, como o nome confessa, é bem mais sofisticada. Ouvi dizer que uma grande empresa a utiliza. Na verdade, uma versão adaptada d’uma balança que um dia foi usada para pesar outro tipo de coisa ilícita. É de altíssima precisão. Joga lá a RFP e vê quanto deu: 127,34 gramas? Então o preço é R$ 400k, arredondado, e o projeto demorará 6 meses!! hehehe… Imprime até etiquetinha!