As empresas, por acaso, precisariam de um consultor da área da administração?
Neste post - que promete ser gigante -, vou falar um pouco sobre a história do desenvolvimento de software, alguns dos problemas atuais encontrados na nossa área e uma pequena sugestão de evolução das metodologias de desenvolvimento de software adotando um novo papel: o do consultor da área da administração.
A maior parte das empresas têm problemas para saber exatamente o que o cliente quer. Será que não seria então mais interessante para as empresas ter um serviço de consultoria para isso? Ter alguém da área de administração para fazer o MAPEAMENTO DE PROCESSOS do cliente?
Antigamente - nem tão antigamente assim - se usava o modelo cascata. Dúzias de analistas de sistemas - que não eram da área da administração mas sim da área da informática ou engenharia - se reuniam com quilos de papéis para tentar descobrir o que os clientes queriam (a famosa etapa de análise / levantamento / elicitação de requisitos) para só depois começar a implementar um sistema.
Como todos nós sabemos - ou deveríamos saber - isso não funciona. Não funciona porque o cliente pede algo e quando o sistema é entregue ele percebe que deveria ter pedido mais X, mais Y e que aquele Z que ele pediu, ele pediu errado, que ele deveria ter pedido W, na verdade.
Daí veio a famosa frase que diz que o cliente não sabe o que quer e que ele só vai saber quando o sistema for entregue. E mesmo depois que o sistema foi entregue talvez ele ainda não saiba o que quer.
Então todo mundo começou a falar: no início do projeto a incerteza é muito alta exatamente porque o cliente não sabe o que quer. Então vamos reduzir a incerteza divindindo todo o processo em ciclos pequenos e iterativos para entregar pedaços de software mais cedo.
Quanto mais cedo o cliente ver o sistema (mesmo que seja uma parte dele) mais ele vai saber o que quer e mais cedo ele vai informando o que deve mudar para a equipe.
E é muito mais fácil (e barato) alterar um sistema no início do projeto do que no final dele. Surgiu então o processo iterativo e incremental.
Com o processo iterativo e incremental - principalmente os processos iterativo e incremental utilizado pelas famosas metodologias ágeis (XP, Scrum, etc.) - você e/ou a equipe faz o levantamento geral e abrangente de tudo o que deve ser feito no programa falando diretamente com o cliente.
Depois que esse levantamento inicial e geral é feito, o cliente prioriza as tarefas levantadas dizendo quais são as mais importantes.
Então é criado um pequeno ciclo de desenvolvimento de 1 ou 2 semanas. Nestas 1 ou 2 semanas a equipe conversa com o cliente para fazer um levantamento mais detalhado destas tarefas (mesmo que de maneira meio informal) e desenvolve as tarefas que o cliente disse que são as mais importantes e que mais geram valor de negócio para o cliente.
Em cada um desses ciclos, a equipe entrega uma ou mais funcionalidades já 100%. Dessa forma, o cliente tem software rodando bem mais cedo. E se o software for entregue mais cedo, a incerteza do cliente diminui.
A cada pedaço de software entregue, mais o cliente vai descobrindo melhor o que ele quer e com isso, as chances do sistema terminar com sucesso é muito maior.
Resumindo, com o processo iterativo e incremental as chance de se entregar o que o cliente realmente quer é muito maior.
Mas e se a empresa de software deseja mais do que apenas entregar o que o cliente quer?
Mas entregar o que o cliente quer é o sonho de toda a empresa de software, certo? Certo. Mas conseguir mais do que isso é o que faz uma empresa se destacar muito mais do que as outras.
E se, ao invés de entregar o que o cliente quer, a empresa AJUDE O CLIENTE a DESCOBRIR o que ele REALMENTE PRECISA?
Isso seria possível se a empresa - além de trabalhar como uma desenvolvedora de software - também trabalhasse como uma consultoria administrativa.
Neste caso, a empresa de software disponibilizaria um profissional da área da administração para fazer todo o LEVANTAMENTO DE PROCESSOS da empresa do cliente.
Este profissional iria até a empresa do cliente, falaria com ele e iria analisar a empresa do cliente.
Analisar a empresa do cliente significa:
1 - acompanhar o dia-a-dia da empresa do cliente, para entender o que a empresa do cliente realmente faz;
2 - depois que o consultor entendeu de verdade o que a empresa faz, ele deve olhar o dia-a-dia de cada uma das pessoas que estão envolvidas no negócio do cliente.
Desde o presidente da empresa, passando pelos diretores, gerentes, técnicos, digitadores, os funcionários que controlam linhas de produção, os que atendem os usuários, etc. até o trabalho dos porteiros, office-boys, encarregados da manutenção, faxina, etc.
O seja, todos os funcionários que estão diretamente ou indiretamente ligados a empresa;
3 - fazer o mesmo, mas para todos os terceirizados e fornecedores da empresa. Como que é o relacionamento da empresa com seus fornecedores e com as empresas terceirizadas que prestam serviços pra empresa.
Acompanhar o dia-a-dia de como os funcionários da empresa se relacionam com estes terceiros;
4 - fazer o mesmo, mas agora com os clientes da empresa. Ver como que a empresa se relaciona com seus clientes. Qual é a visão que os cliente têm da empresa. Como que é a comunicação da empressa com os clientes. Quais papéis, formulários, requisições o cliente precisa preencher, etc. Quais as principais críticas e elogios que os clientes têm para com a empresa, etc.
Após analisar todos estes passos, o consultor então começa a desenhar o diagrama de processos da empresa, como se faz nas cadeiras de administração mesmo.
Tudo isso serve para poder identificar o processo que a empresa atualmente utiliza.
A maior parte das empresas pequenas ou médias não sabe atualmente como que é, 100% no papel, o processo de sua própria empresa. E este desconhecimento do seu próprio processo pode se dar pelos seguintes fatores:
1 - falta de conhecimento da área administrativa da empresa. São várias as empresas que são administradas não por pessoas da administração, mas sim por técnicos que por serem muito bons, por ter um bom relacionamento dentro da empresa e por conhecer a empresa há anos, acabam sendo elencados a uma posição administrativa, de coordenação.
Estas pessoas, mesmo sem ter uma formação administrativa, conseguem fazer a empresa funcionar muito bem e corretamente. Porém, a parte mais teórica da administração - como o mapeamento de processos - elas acabam não fazendo;
2 - Outro fator pode ser o famoso "nunca fizemos isso e até agora isso não nos fez falta. Se algum dia a gente sentir necessidade de fazer isso, a gente faz". Esse fator todo mundo conhece muito bem ;) ;
3 - Outro fator é que a empresa pode achar melhor contratar uma consultoria para fazer isso. E o preço cobrado por essa consultoria pode ser bem alto, o que faria isso não entrar para a lista de prioridades da empresa devido a uma relação custo/benefício.
Geralmente as empresas só resolvem fazer um mapeamento de processos quando a empresa resolve tirar uma certificação ISO. Para se tirar uma certificação ISO, um dos passos necessários é fazer o mapeamento do processo da empresa - claro que não é só isso que é necessário. É necessário mais várias coisas como padronizar a forma de trabalhar das pessoas, etc.
Ok, fizemos o mapeamento dos processos da empresa. Agora podemos começar a desenvolver software, certo?
Hum... eu teria um pouco mais de calma.
Isto porque nós fizemos o mapeamento dos processos da empresa, certo? Ou seja, descobrimos "de cabo a rabo" como que a empresa funciona. Legal.
Geralmente, quando se faz o levantamento de requisitos ou quando se faz as conversas com o cliente tanto no modelo cascata quanto nos modelos iterativo / incremental e modelos ágeis, nós conversamos com o cliente exatamente para descobrir como que a empresa funciona. Mais ou menos como que é o mapeamento de processos da empresa.
Se toda esta conversa com o cliente for muito bem feita, você vai chegar bem perto do mapeamento de processos que eu citei aqui até agora.
Só que é aí que mora mais um dos problemas do desenvolvimento de software: chegamos o mais perto possível do mapeamento de processos perfeito da empresa, ou seja, descobrimos como a empresa trabalha. Mas e quem diz que a empresa trabalha bem? Quem diz que os processos da empresa são bons?
Se você fizer um sistema para uma empresa cujos processos são ruins, o seu software será ruim para a empresa. Isto porque o seu software será um reflexo dos processos da empresa. Um software nada mais é do que o processo de uma empresa em um formato computacional automatizado. Nada mais.
Então aí vem mais uma vantagem de se fazer o levantamento dos processos de uma empresa por alguém da área da administração: além de levantar os processos de uma empresa, sugerir mudanças para melhorar o processo da empresa.
É como se você fosse fazer um software para uma empresa que trabalha com linha de produção. Digamos que esta empresa fabrica 1000 itens por dia. Você descobre algumas falhas no processo da empresa e propõe melhorias no processo que fará a empresa produzir 1500 itens por dia ao invés dos atuais 1000.
Seria bem melhor para o seu cliente, certo? E se seria melhor para o seu cliente, seria melhor para você também.
Este é o ponto que eu queria chegar. Não basta fazer o levantamento dos processos da empresa e desenvolver um software a partir dele. De certa forma isto é o que todo mundo faz (ou tenta fazer).
Para você se diferenciar, para se destacar, para fazer mais do que os outros, você precisa fazer o levantamento dos processos da empresa, melhorar estes processos e, então sim, desenvolver um software a partir dele. Daí com certeza, sua empresa seria uma empresa diferenciada. A qualidade do seu produto seria muito melhor.
Em equipes de desenvolvimento mais tradicionais, nós temos o Analista de Requisitos ou o Analista de Negócios. A minha sugestão seria a de que, nestes casos, o Analista de Requisitos ou o Analista de Negócios não fosse alguém da área da informática, mas sim alguém da área da administração, que ele fosse o consultor da área da administração.
Ou isso, ou que os Analistas de Requisitos e/ou de Negócios fizessem uma pós-graduação em Administração para que eles mesmo possam fazer um levantamento de processos corretamente.
Em equipes ágeis, nós temos algumas figuras no desenvolvimento de software. Temos a equipe, o líder da equipe e temos o Product Owner (PO).
O PO é a pessoa que representa o cliente, a pessoa que vai dizer para a equipe o que o cliente espera do software, o que a equipe deve fazer, quais tarefas deve fazer e que também prioriza as tarefas. Este PO geralmente é o próprio cliente. Alguém que trabalhe na empresa do cliente.
A minha sugestão para equipes ágeis é que além de ter o PO como parte da equipe, também deveríamos ter o consultor da área da administração como parte da equipe. Desta forma o PO mais este consultor deveriam guiar a equipe de desenvolvimento sobre o que deve ser feito.
Mas o importante é que o consultor - nestes casos de equipes ágeis - se reúna antes com o PO para mostrar o resultado do levantamento de processos e faça as sugestões de melhorias no processo. Tudo isso antes de envolver a equipe de desenvolvimento.
Depois que tudo foi acordado e que o consultor mostrou todos os processos para o PO, daí sim deve-se dar início ao desenvolvimento com a equipe todos juntos.
Já nesta segunda etapa junto com a equipe, o consultor deve deixar o PO conduzir todo o processo e apenas deve se manifestar caso o PO tenha esquecido de mencionar alguma coisa ou se o PO falar algo que contrarie o que havia sido acordado antes entre os dois.
Afinal, se o PO fala algo que contrarie o novo processo proposto, pode ser que o PO não tenha entendido corretamente o novo processo, então o consultor deve entrar em cena para debater o assunto junto com o PO e a equipe apenas para "afinar" o desenvolvimento.
Desta forma, teríamos o desenvolvimento em equipes ágeis bem parecido com o que se faz hoje em dia, apenas adicionaríamos esta figura do consultor para ajudar.
É importante lembrar e frisar que o consultor deve deixar o PO conduzir o desenvolvimento. O PO é o dono do produto, não o consultor. O consultor é apenas uma ajuda, um reforço. O maestro deve continuar sendo o PO.
Desta forma, acho que podemos melhorar um pouco ainda mais o desenvolvimento de software para que cada vez mais projetos alcancem o sucesso com uma ótima qualidade.
Principalmente porque a quantidade de projetos que não dão certo, que não atendem às expectativas dos clientes ou que não apresentam uma boa qualidade, é muito grande. Isso sem falar dos projetos que terminam com atraso.
Tanto que na área de software, os clientes já aprenderam a se contentar com pouco, exatamente porque são poucas as empresas que conseguem fazer este pouco.
A maior parte das empresas não consegue fazer um sistema que espelhe 100% os processos atuais da empresa, quem dirá propor melhorias no processo. De fato, isto seria um "mundinho ideal". Seria muito bom fazer isso, mas é muito difícil.
Continuando no "mundinho ideal", outra coisa que é preciso prestar atenção é que mesmo sugerindo melhorias no processo da empresa, os processos têm uma característica marcante: a mutabilidade.
Ou seja, um processo não dura pra sempre estático. Os processos mudam, evoluem com o tempo. E o que acontece - pra tristeza das empresas em geral e pra alegria das empresas que desenvolvem software :) - é que sempre que processos mudam, os softwares relacionados a estes processos precisam mudar também.
Então, para completar o "mundinho perfeito", o ideal seria fazer um software que se adaptasse às mudanças nos processos sem a necessidade de precisar reescrever ou alterar o código fonte do software.
Mas para chegar neste patamar creio que ainda é preciso alguns muitos anos a mais na questão do amadurecimento da indústria de software.
Isto tudo porque a área de desenvolvimento de software é uma criança ainda, se você analisar bem. Se comparar com qualquer outra área - administração, a maior parte das engenharias, psicologia, medicina, etc. - veremos que a àrea de desenvolvimento de software ainda é muito nova e muito recente.
Na nossa área não existe ainda uma regra de como desenvolver software. Regra do tipo "faça isso, isso e aquilo e você conseguirá construir um software bom e de qualidade". Todas as outras áreas já têm isso, só nós é que ainda não temos.
Na engenharia civil, existem regras que devem ser seguidas para se construir um prédio. Estas regras até podem mudar para que sejam construídos novos prédios diferentes, com novos materiais, etc., mas se você seguir as regras normais, você conseguirá construir um prédio bom, corretamente e de qualidade. Ou seja, existem as regras básicas. E as regras básicas são boas.
Já no desenvolvimento de software nós também temos as nossas regras básicas segundo o modelo cascata (o modelo de software mais tradicional que existe). Só que daí vemos estudos que dizem que uns 70% dos projetos falham.
70% é muito. Já imaginaram se 70% dos prédios caíssem?!
Na psicologia existem várias escolas. Freudiana, Junguiana, Lacaniana. São teorias sobre a psiquê humana já consolidadas. Hoje em dia, se você encontra uma teoria psicológica nova, ela já tem uns 20 anos! Ou seja, existem as regras básicas. E as regras básicas são boas.
Tendo isto em vista, vemos como o desenvolvimento de software é uma coisa nova. De certa forma, somos todos pioneiros tentando descobrir, inventar as regras que serão as regras básicas no desenvolvimento de software daqui a 40, 50 anos.
Já tivemos a programação estruturada. Agora temos a orientada a objetos. Já tivemos o modelo cascata. Agora estão aparecendo as metodologias ágeis. E assim vai.
Do ponto de vista romântico isto é algo bom pois somos pioneiros, descobridores, desbravadores.
Já do ponto de vista do dia-a-dia, em que precisamos desenvolver software pra ganhar dinheiro, isto já não é algo tão bom assim.
Afinal quanto mais fácil, rápido e com uma qualidade mínima aceitável desenvolvermos sistemas, mais dinheiro ganharemos. Por este ponto de vista seria muito bom já tivéssemos as nossas regras básicas estabelecidas.
Mas é isso aí pessoal. "A luta continua, companheiro" :)
