Antes de começarmos: projetos não falham. Pessoas falham. Mas pessoas não gostam de assumir responsabilidade sobre seus erros, então é usual falar que “o projeto deu errado”, “o projeto falhou”.
Nos últimos quatro anos conheci uma figura que repetia semanalmente para os seus superiores: “o projeto é complexo demais, precisamos de mais tempo, mais dinheiro, o sistema é muito complicado”.
Isso durante quatro anos. O projeto ainda não acabou, está indo para o quinto ano. Agora ele fala que o problema é que o cliente foi omisso durante os quatro anos, e deixou o projeto solto. Esta figura não faz bem seu trabalho, mas não reconhece isso.
Quando eu trabalhava como desenvolvedor em Fábrica de Software, que tinha que virar noite, fazer mais hora extra que hora útil, sempre tinha um que falava: “que sistema filho d****”, ou “que projeto do infer** é esse” e coisas do tipo.
Não tínhamos humildade nem maturidade para reconhecer que tínhamos que parar de achar legal “ficar tomando café e fazendo gambiarra”.
Muitas vezes também ouvi algo do tipo “deste projeto eu não quero nem lembrar, nunca vi um projeto dar tanto problema”.
Geralmente essa crítica vinha dos analistas que ferravam o projeto (não necessariamente de propósito, muitos eram colocados para fazer coisas que ainda não tinham condições de fazer, ou então, estavam sob a pressão de gerentes puxa saco, ou gerentes que não eram puxa saco, que estavam apenas tentando defender seu emprego).
Também ouvia isso de gerentes que tinham autonomia para fazer as coisas certas, mas arrebentavam com tudo sempre que podiam. Eram destruidores.
Ainda conheço alguns assim. Tenho um amigo que costuma falar que um conhecido nosso (que não é um bom gerente) possui o “toque de mer*a”, uma alusão ao Toque de Midas. Tudo que ele “pega para gerenciar ” dá mer*a, dá errado.
Coitado dos projetos, sempre os culpados por serem uns fracassados.
Um detalhe: existem gerentes bons, progressistas, criadores. Mas nos tempos atuais (~ 2015), talvez seja uma minoria.
Mas quando algum projeto “dá certo”, sempre é “a equipe foda de fulano de tal“, ou “fulano de tal carregou o projeto nas costas“, ou “viu, minha empresa é diferente desse monte de lixo que tem por aí, aqui a gente sabe fazer software“, ou “só deu certo porque eu apareci para por ordem nessa zona” (essa última eu conheço um cara que já falou duas vezes). Impressionante.
Bom, alguns acreditam em milagres, outros em matemática.
Outros acreditam que Chuck Norris é uma verdade e está por aí destruindo sozinho milícias de cinco mil pessoas, outros preferem acreditar que ele é apenas um cara que faz roleta russa com o revolver totalmente carregado, e vence o jogo.
Projetos não são culpados pelos seus próprios fracassos. Projetos não são seres animados.
Pessoas sempre tem o mérito no sucesso, ou demérito no fracasso.
Talvez pareça óbvio aqui, mas tenho certeza que muitos profissionais/pessoas não percebem isso desta forma.
É comum não aceitarmos nossas falhas, e atribuímos nosso fracasso a outras pessoas ou coisas.
É uma questão moral, cultural também. Mas que não é legal.
Qual é a realidade dos projetos de software? De que “tamanho” de problema estamos falando?
Na nossa página do Facebook, semana passada, publicamos a imagem a seguir:
O gráfico acima esta no documento “Big Ban Boom”, do Standish Group, responsável pela produção do Chaos Report.
Apenas 6% dos projetos grandes são concluídos com sucesso. Abaixo a descrição sobre cada uma dos três rótulos, conforme contido no documento:
“Successful projects are on time, on budget, and have a satisfactory implementation. Challenged projects are over budget, late, and/or have an unsatisfactory implementation. Failed projects are projects that were either canceled prior to completion or not used after implementation.”
Basicamente, conforme o critério de classificação adotado, o projeto bem sucedido [6%] foi feito no tempo (prazo) e orçamentos planejados, e teve uma implementação satisfatória.
Projetos que falharam [42%] foram cancelados antes de acabar, terminaram sem produzir o software escopo do projeto, ou tiverem o software produzido, mas o software foi implantado em produção.
A última linha do trecho acima quer dizer: desperdício. Ou por mudança de estratégia, ou por outro motivo.
Mudança de estratégia não aborta nem 5% dos projetos aprovados em empresas com uma gestão madura.
A parcela restante é projeto “desafiador” [52%] (Challenged); projeto que ultrapassou o orçamento, atrasou no prazo, e/ou teve uma implementação não satisfatória…
… isso para mim é um projeto mal sucedido. Não tem “meio bem sucedido” ou “meio fracassado”, mas tudo bem, precisamos ter bom senso e procurar o meio termo em todas as coisas. Nem tudo é tão binário quando poderia ser.
Bom, mas o cenário é este.
Segundo o mesmo relatório citado, para projetos de portes menores, os números são horríveis, mas nem tanto. E assim devem ser mesmo, logo à frente explico como a quantidade de problemas é proporcional à complexidade de cada projeto.
/* quando alguém diz quem um projeto é “desafiador” é importante ficar claro que esta pessoa quer dizer que o projeto “já está condenado a fracassar, salvo se o Messias aparecer”. E o Messias vai ser escolhido, e uma hora será você. Obs.: por favor, não quero parecer rebelde, eu sei me virar bem e não costumo cair no discurso de raposas, mas já vi dezenas de vezes isso acontecer e pessoas mais simples e menos articuladas se prejudicarem seriamente (seriamente mesmo) por não conseguirem resolver “projetos desafiadores”. Sempre que ouvir “projeto desafiador” fique atento pois poderá ser o próximo Messias. E os Messias na nossa história geralmente acabam na cruz.*/
/* Podem sim existir projetos realmente desafiadores, onde o negócio (business, contexto de negócio do projeto) é mais complexo, o cliente é mais difícil, a tecnologia é mais recente, o orçamento é enxuto, os riscos envolvendo P&D são altos etc. Mas na prática este tipo de projeto tem outra classificação, não “desafiador”. Estes projetos costumam ser muito legais, mas não é a este tipo de projeto que os “gestores” referem-se quando falam de um “projeto desafiador”. */
Vamos equalizar alguns conceitos antes
Vamos alinhar alguns conceitos para analisarmos a problemática do fracasso em projetos de software. São conceitos que podem parecer filosóficos demais, mas que penso serem fundamentais para uma compreensão de verdade do problema.
Na realidade entendo estes problemas como axiomas, que se deixassem de existir, não haveria projeto de software mal sucedido.
Na área de software precisamos parar de achar que tudo é o que parece ser, precisamos pensar um pouco fora da caixa, sair da cultura na qual fomos doutrinados (mesmo que não tenhamos percebido que fomos) e entender os “porquês” do contexto no qual estamos inseridos.
As pessoas tendem a pensar apenas nelas próprias [AXIOMA 1]
As causas dos fracassos nos projetos são responsabilidades de pessoas. Uma pena é que na maioria das vezes os responsáveis não são aqueles que absorvem o ônus do fracasso nos projetos. Geralmente no fim o ônus ficam para os que menos tem culpa.
/* Não tenho a intenção de trazer aqui um “discurso libertador” sobre a realidade dos projetos de software, sobre a escravidão e tortura envolvidas em algumas realidades. Mas é necessário eu abordar, na introdução ao assunto, as dores envolvidas nisso tudo. É fundamental para despertar melhor a reflexão em cada um que está lendo este post. */
O homem tem por hábito não se colocar no lugar do outro. Não tenta desenvolver sua empatia. Se não possui empatia, terá muito dificuldade para exercer o altruísmo. Pela razão, na ausência de altruísmo, sobra então o egoísmo.
O homem tem uma tendência natural a ser egoísta. É natural, ainda somos muito “animais”, e animais são instintivos por uma questão de sobrevivência (leões altruístas seriam comidos pelos seus pares – mas analistas altruístas não serão devorados por seus pares, isso precisamos entender); egoísmo é instinto, altruísmo é razão.
E os profissionais de TI tendem a ser mais egoístas que a média (é uma opinião minha e de algumas pessoas que conheço, e é claro que existem exceções).
/* Aos leitores deste post, por favor não sintam-se ofendidos com minhas opiniões sobre “pessoas na TI”. São apenas minhas opiniões; não significa que sou melhor que o esteriótipo descrito aqui; não significa que eu não possua diversas das características aqui citadas. Não sou modelo moral para ninguém. Entendo que todos estamos neste mundo para aprender, progredir. Não quero ainda ser irônico com outras pessoas em algumas de minhas citações, mas às vezes é necessário pela proposta do texto. Não aprovo criticar pessoas, mas de maneira construtiva e anônima, criticar as ações destas pessoas que são prejudiciais a outras, para mim é válido. */
As virtudes ou os vícios – por uma série de questões que não vou detalhar aqui para não estender muito o texto – direciona as atitudes das pessoas.
Atitudes virtuosas geram resultados virtuosos, atitudes viciosas geram resultados viciosos. Se a maioria das pessoas possui em demasia o vício do egoísmo, então a maioria dos resultados serão egoísticos.
Projetos são feitos por times. Produzir software em empresas não é um “esporte de um homem só”.
Fez errado, vai dar errado. Fez certo, vai dar certo [AXIOMA 2]
Todo efeito tem causa. E um efeito sempre será da mesma natureza de sua causa. Não existe (ou não deveria existir) Lei de Murphy; trata-se apenas a lei de causa e efeito interpretada de outra forma. “Qualquer coisa que possa correr mal, ocorrerá mal, no pior momento possível”. Claro! Óbvio! Se houve uma causa de natureza “errada”, fatalmente haverá um efeito “errado”, e quanto ao ocorrer no “pior momento possível”, nunca há momento bom quando algo da errado, somos dramáticos por padrão e sempre acharemos que era o pior momento de algo ruim acontecer.
A filosofia nos ensina que tudo está em tudo. Não há nada, material ou imaterial, que não esteja conectado. A teoria do caos prova isso, mais claramente através do efeito borboleta.
Qualquer ação que um analista tomar no projeto gerará um efeito. E como citado, o efeito sempre será da mesma natureza que a causa. Se for uma ação errada, isso vai fatalmente gerar um problema. E sempre se faz muita coisa errada em projetos de software.
Quanto maior o projeto, maior sua complexidade [AXIOMA 3]
Nova York é mais complexa que Belo Horizonte. O oceano atlântico é mais complexo que o Rio das Velhas. Uma Ferrari é mais complexa que um Fusca.
Pensando no nível atômico das coisas, no “grande” há muito mais variáveis que no “pequeno”. Onde há mais variáveis, há mais complexidade. Onde há mais complexidade, há um maior potencial de ocorrerem problemas.
Software, por default, é algo bastante complexo.
/* Com todo respeito aos engenheiros e arquitetos da construção civil, sempre que estou em algum bate papo com um viés mais filosófico sobre Engenharia de Software, costumo dizer que um projeto de um software é muito mais complexo que um projeto de um prédio. E comparo uma coisa com a outra. Basicamente, software é algo dinâmico (muda toda hora: em tempo de projeto, de construção, de homologação, implantação e manutenção), e um prédio não. Prédios possuem muitas constantes, software muitas variáveis. */
Por isso, naturalmente que há uma tendência de ocorrerem mais problemas em potencial, em projetos desta natureza. E onde há essa tendência natural, a atenção com a administração dessa tendência é crucial.
Na maioria dos projetos de software, os riscos ficam apenas na declaração de escopo e nas apresentações power point do PMO.
Finalizando sobre os três Axiomas
/* Tudo começa e termina nas pessoas. Entender isso é fundamental. Ninguém muda ninguém e não é plausível se alterar toda uma cultura no curto prazo. Mas é imperativo começar a mudar o mindset, pensar menos em “coisas” e pensar mais em “pessoas”. Empresas nada mais são que agrupamentos lógicos de pessoas. Mas com um detalhe: orientação às virtudes, e guerra aos vícios. */
Os problemas mais comuns em projetos de software
Eu dividi os problemas em dois grupos: problemas relacionados a Cultura, Pessoas Educação e Moral e problemas relacionados a Técnica, Método e Processos.
Vamos começar pelo primeiro grupo, que é o mais difícil de resolver, e infelizmente o mais crítico.
Não há orientação a pessoas. Pessoas são consideradas “recursos”
Quem nunca foi um “recurso”? Quem nunca ouviu um gerente de projetos falar: “ô recurso, terminou a tela?”. O Microsoft Project tem um campo dos mais importantes no cronograma chamado “Resource (recurso)”, e nesta ferramenta sempre que um profissional é trabalhado no contexto do projeto, o termo “recurso” é utilizado (“uso do recurso”, “adicionar recurso”, “recursos corporativos” etc.).
Essa cultura de chamar o profissional de “recurso” entra na lista de fatores responsáveis pelos projetos não darem certo. Existe um conceito que é: todo ser humano quer se sentir parte de algo maior.
No contexto empresarial, isso refere-se ao profissional sentir-se parte da empresa, criar uma identidade, uma correspondência, uma intimidade, afinidade; acreditar, crer na relevância da empresa de tal forma que sua crença o faça vestir realmente a camisa, abraçar a causa dos acionistas, brigar para valer pela empresa.
Alguns podem dizer assim: “é só piadinha, tratar o cara como recurso não diminui ele não, afinal é recurso mesmo e tal…”. Em primeiro lugar, pessoas devem ser tratadas como pessoas, não como números. Em segundo lugar, o líder (ou pseudo-líder – 90% dos casos) que entende que não há problemas em chamar um profissional de “recurso” não entende nada de engajamento, de rapport, e isso já mostra que ele tem uma deficiência séria em termos de perfil (ou “soft-skill”, como diz o jargão atual) de liderança.
Com certeza é um chefe (pseudo-líder) mediano ou medíocre, e vai ter resultados medianos ou medíocres. Em terceiro lugar, este conceito deveria ser revisto desde já, e nas ferramentas como o Microsoft Project e guias como o PMBOK este conceito deveria ser abolido com urgência.
Pessoas merecem respeito, merecem ser mais que um número ou “resource ID”.
O profissional que se sente fora do time não joga pelo time. Se todo o time se sente fora do time, então esse time nunca será vencedor. Apenas ficará 90 minutos em campo para garantir o salário no fim do mês.
Gestores de equipes de software, mas que não sabem fazer software
Vamos considerar o mundo ideal, em termos de plano de carreira em empresas de software.
O profissional entra na empresa como Estagiário ou Trainee. Daí ha alguns bons anos, em função da Carreira em Y que a empresa oferece, o profissional poderá se tornar um Gerente ou um Especialista. Após passar alguns anos como Analista Sênior, o profissional opta por seguir o caminho da gestão, tornar-se um Gerente de Projetos, por exemplo.
Legal, começará uma transformação para este profissional.
Mas antes dele chegar na gerência ele foi: Estagiário, Trainee, Analista Júnior, Analista Pleno, Analista Sênior.
Suponhamos que este ciclo durou oito anos.
Em uma empresa medianamente séria, um profissional que segue este caminho sem ser demitido é um bom profissional. Então, o mais novo gerente de projetos ficou oito anos trabalhando duro, ficou fera em arquitetura, modelagem de dados, engenharia de requisitos, construção, implementação de testes. Por vários vezes vivenciou implantações complexas em produção, correções de bugs em produção, se relacionou com clientes difíceis, trabalhou em projetos condenados etc.
Este gerente tende a ser um bom gerente. Por uma simples questão: ele terá autoridade, em função de ter propriedade naquilo que vai gerenciar, propriedade adquirida com conhecimento de causa (horas de rodagem, de mão na massa).
Autoridade é diferente de autoritarismo. O líder não manda, ele solicita. E a quem é solicitado, quando há uma relação envolvendo autoridade superior de fato (não somente “de direito”), é sempre um prazer atender à solicitação, e atender bem.
Só para constar: mandar é uma estupidez. Inseguros mandam. Inseguros obedecem. Mas isso é uma questão mais complexa, fica esta frase apenas para registro.
O fato é que a maioria dos gerentes de projetos de software (não necessariamente gerentes de projeto [que muitas das vezes – principalmente em empresas com estrutura funcional – não tem autonomia nenhuma], em muitos casos diretores e gerentes de operação, seção etc.) não tem autoridade naquilo que gerenciam. Não possuem visão ampla sobre o que pode dar certo, o que pode dar errado, o melhor caminho, o pior caminho, os riscos realmente relevantes etc.
E em empresas que possuem cultura de promover gestores sem autoridade, raras serão as que possuem uma cultura horizontal (empresas horizontais também possuem gestores, mas em número muito menor).
Logo, não haverá o dialogo necessário entre capitão e marinheiros, em viagens onde o capitão não sabe remar, não sabe ler uma bussola, não sabe ler uma tábua de marés etc.
Não aprender com os erros dos projetos fracassados
Você já ouviu falar sobre Lições Aprendidas? ”
Já ouviu isso: “vamos fazer a reunião de encerramento (ou cancelamento) do projeto, onde serão apresentadas as lições aprendidas”.
E já ouviu alguém dizer: “está tudo dando errado, estão acontecendo as mesmas coisas que aconteceram no projeto abc.”.
Nós temos dificuldades em aprender com nossos próprios erros! Mas o pior é que este é, na prática, o único caminho o aprendizado que faz a diferença na vida.
Isso é muito sério. O ideal é não termos que errar para aprender. Tudo bem, é difícil para a maioria de nós. Então, precisamos errar para aprender com o erro. É, mas demora, aprender na primeira é difícil, geralmente aprende-se na segunda ou terceira.
Mas, e quando se erra de maneira contumaz, e mesmo assim não aprende? Isso é muito ruim, pois pode significar que não haverá perspectivas de aprender a fazer certo.
O ser humano é empírico por natureza. Em função disso, e por não possuir sua razão plena (ainda), fatalmente vai ter que errar para descobrir como fazer certo. Mas sem olhar para o erro, não se descobre como fazer certo.
E nas empresas, entre profissionais de gestão principalmente, assumir que errou “de verdade” é um problema, pois descobre o véu da vaidade, do ego, do autoritarismo.
Você consegue imaginar Hitler, Mussolini, Hugo Chávez, Nicolás Maduro ou Kim Jong Un reconhecendo “de verdade” seus próprios erros, e implementando ações concretas para não repeti-los?
Mas falta de oportunidade não é. Como erramos muito mais que acertamos, o acervo de resultados ruins para posterior análise é farto, muito farto. O que falta é reconhecer a incompetência e ter boa vontade para melhorar.
Tudo aquilo que sempre se faz da mesma maneira, sempre gerará o mesmo resultado. E o pior, com o tempo se ganha mais eficiência, e assim atinge-se o cúmulo da ineficiência: fazer as coisas erradas da melhor forma possível.
Foco no ganha-perde, nunca no ganha-ganha
Qualquer relação entre partes tem um objetivo. Naturalmente.
Mas nem sempre o objetivo é comum entre as partes envolvidas, nem sempre as partes querem a mesma coisa com o atingimento do objeto comum. Até aí é natural, pois pode-se trabalhar numa mesma coisa, e o principal resultado esperado de cada lado ser diferente. É uma questão de expectativas.
Por exemplo, numa relação comercial o objetivo é ter um imóvel reformado. Um lado pode esperar ganhar dinheiro com a prestação de serviços de reforma e pagar dívidas atrasadas dos sócios da empreiteira, e o outro lado espera poder abrir um comércio com a receita dos serviços de reforma executados.
Mas na relação comercial, é premissa ética que todas as partes ganhem. A isso se dá o nome de ganha-ganha. Significa que ninguém deve perder, ter prejuízo para o outro ter lucro. Mas, infelizmente, na prática não é bem assim.
São poucos os casos onde se trabalha com um objetivo comum, com as partes se ajudando de verdade, todos imbuídos de um sucesso coletivo.
E onde há desequilíbrio, não há como alguém ter controle pleno. Por mais que exista um ninja em administrar as partes interessadas, que seja um exímio político e mediador, não tem jeito. Vez ou outra, a corda arrebentará, e algum dos lados sairá no prejuízo.
E onde alguém perder, alguém ganha. Onde apenas um ganha, alguém perde. E em times, ou se ganha no conjunto, ou não se ganha. Porque será que Cristiano Ronaldo, Messi ou Neymar não conseguem êxito em suas seleções?
Forte orientação a venda, mesmo que seja venda de lote na lua
Eu sei, empresas que não vendem quebram. Sim, claro. Mas sei também, que empresas que vendem lote na lua, uma hora quebram também.
Na área de TI temos o problema da ausência do conselho regional (ou federal). Não há regulamentação, então vale tudo. No segmento de Engenharia Civil, se uma construtora conseguir vender o conceito de um prédio de massinha de modelar, com 55 andares e ejetável, essa construtora vai ter que entregar isso pronto. Se não conseguir vai se dar muito mal, vai quebrar, os donos terão que vender até os talheres de suas casas para pagar multas.
Em TI não.
Então é possível prometer tudo. E todo mundo sabe disso. E o cliente acredita que prédio de massinha de modelar, com 55 andares e ejetáveis são viáveis tecnicamente. Ou ao menos finge acreditar. Tem muito joguinho onde o fornecedor finge falar a verdade e o cliente finge acreditar.
E isso acontece em oito em cada dez vendas. Se perguntar o comercial porque ele faz isso, ele vai dizer: “tenho que bater minha meta, ou serei demitido”. Se perguntar o CEO se ele sabe que o comercial pensa assim, ele vai dizer: “eles estão dando o seu melhor, temos que apoiá-los” (no fundo muito CEO não liga para isso, quer bater meta de faturamento com seu comercial e o resto f*****. Depois se algo der errado é só demitir alguns “recursos” para ajustar o fluxo de caixa). Se perguntar ao Diretor de Projetos se ele sabe disso, ele vai dizer: “devemos entender, o comercial fica numa posição difícil mesmo, e agora as equipes vão ter que dar conta e se virar para entregar”.
E os “recursos” pagarão mais uma vez o pato.
Equipes se formam por afinidades, não por talentos ou meritocracia
Na corporação ideal, amizade deveria ser, talvez, o último critério para promoção de funcionários. Talvez, seria até um critério para não promoção, pois a visão de amizade que o homem atual possui, permite, por exemplo, relações corruptas em função dos “laços de amizade”.
/* Ainda confunde-se muito o funcionário fiel com o funcionário comparsa. */
Mas eu acho que esta corporação não existe. Vamos supor que eu esteja certo.
A amizade, em muitas empresas de software torna-se quase que o primeiro critério a ser analisado na hora da promoção. E se isso acontece, deixa para trás outros critérios mais importantes: mérito, talento, conhecimento técnico. Ou seja, o “amigão” pode ser um profissional sem méritos, sem talentos, fraco tecnicamente, mas será promovido.
Equipes em que isso acontece não se movem a não ser pelo salário no fim do mês. É assim acontece o parto de mais um futuro gestor autoritário, e de mais uma equipe que apenas reage.
Além de todo o efeito colateral que um gestor despreparado e “avalizado” pelo diretor pode gerar, uma equipe não funciona sabendo que seu “norteador” é incompetente e está no cargo apenas por “amizade” como manda chuva.
Programar em todas as linguagens é fácil, se comparado a alguém reformar-se moralmente
Concorda?
Agora vamos na parte menos difícil de atuar, mas muito crítica também para o fracasso dos projetos. Técnicas, métodos e processos.
O escopo do software é volátil. Fatalmente o será, mas poderá ser menos ou mais volátil
Em projeto de software temos duas visões sobre escopo: o escopo do projeto e o escopo do sistema. O segundo é parte do primeiro. Mas no escopo do projeto existem coisas “extra escopo do software”, tem coisas pertinentes a implantação, faturamento etc. O problema crítico em projetos de software refere-se ao escopo do sistema.
Projetos de software são projetos que utilizam refinamento contínuo. No início, os escopo é muito macro, e no decorrer do projeto, por razões diversas, o escopo vai se tornando muito detalhado, vai ficando mais claro. As fronteiras do escopo vão sofrendo alterações (geralmente se “expandindo”).
Para entender melhor isso, é fundamental entender o que é o Cone da Incerteza.
Gerenciar essa realidade é uma tarefa hercúlea. No início do projeto ninguém assume que isso acontecerá (e acontecerá sempre), pois o fornecedor não quer perder a venda, e o cliente não quer a chance de ter alguém para realizar o projeto de sua Estação Espacial Internacional no custo de um Albergue.
Não costuma constar em contrato de fabricação de software regras rígidas e bem detalhadas para gestão do escopo. E as empresas geralmente não possuem maturidade para gerenciar adequadamente o escopo, no nível de detalhe necessário. O escopo de um sistema é volátil por natureza, pela natureza deste tipo de projeto.
E a relação comercial por padrão começa torta. No começo as partes acham que que está tudo bem, mesmo sabendo que não ficará tudo bem mais à frente. É como um casamento onde os noivos escondem seus podres de adolescência e suas dívidas um do outro. Uma hora vai dar problema.
Não se tem maturidade para uma boa Engenharia de Requisitos
Quando falamos de escopo, no nível conceitual, estamos falando de requisitos (requisitos funcionais, regras de negócio e requisitos não-funcionais). Ou seja, escopo = requisitos (podemos assumir isso como quase verdade).
E requisitos mal especificados, mal pensados, mal administrados, acabam com os projetos, devastam os projetos. Quando não se tem maturidade na Engenharia dos Requisitos, não se tem controle sobre o escopo, e paga-se um preço alto por isso.
Vejamos a imagem a seguir.
Ela nos mostra o custo de um defeito (custo de correção do defeito) conforme cada fase de um projeto de software. Pela questão do refinamento contínuo, quanto mais cedo o defeito por detectado, mais barato (em termos de esforço e custo) será corrigi-lo, e menos efeito colateral o defeito gerará em outras funcionalidades do sistema.
Mas a maioria dos profissionais tomadores de decisão nas empresas que produzem software não enxergam isso. Muitos sofrem de Miopia do Marketing.
- Um ou mais requisitos funcionais gerarão uma funcionalidade (m1).
- Para construir uma funcionalidade se produz casos de uso ou estórias de usuário (m2).
- Casos de uso ou estórias de usuário gerarão classes de negócio, classes de dados, classes de apresentação etc., modelos de dados e tabelas físicas num banco de dados (m3).
- Casos de testes precisam de funcionalidades prontas para serem produzidos. (m4)
Cada “m” que coloquei é um “momento” no tempo do projeto, onde, o momento 4 acontece depois do momento 3, por exemplo.
No “momento 1” nada aconteceu ha não ser a produção de requisitos. Então, se o defeito por detectado neste momento, apenas os requisitos relacionados deverão ser corrigidos.
Já no “momento 2”, corrigir o defeito detectado demandará alterar os casos de uso ou estórias, e também os requisitos. Agora aplique este raciocínio ao “momento 4”.
Por isso que corrigir bug com um software em produção custa até 1000 x mais que corrigir um bug com o software na fase de engenharia de requisitos.
Projetos e Operações – juntos e misturados
Vamos pensar em Capitalismo e Comunismo. São modelos antagônicos. Agora imagine que num país Comunista o Ditador quer “rodar” o Capitalismo, mas com toda uma cultura, estrutura pública etc. moldada no Capitalismo.
Isso é o que algumas empresas insistem em fazer. Muitas empresas orientadas a operação tentam ter sucesso na execução de projetos, com a mesma cultura e estrutura que possuem orientadas a operação, rodando projetos com viés de operação.
Não conseguem fazer dar certo, e acham que o problema é outro (geralmente atribuem o fracasso aos “recursos” do projeto – que nestas empresas são divididos com outros vários projetos, e tarefas de operação). Estas empresas geralmente possuem uma estrutura organizacional chamada Funcional.
Projetos em estruturas funcionais são tão aderentes à realidade da empresa quanto políticas Capitalistas num estado Comunista.
Acreditar que linha de produção de software é possível
Não estou me referindo ao conceito de Fábrica de Software. Fábrica de Software é algo viável. Mas as pessoas associam fábrica a linha de produção, a produção em série.
Fábrica de Software é uma coisa, produzir software em série, através de linha de produção é outra. E que não funciona!
/* Fazer software não é fazer pastel. Quanto maior o capital intelectual necessário para a realização de uma uma atividade, mais complexa torna-se a automatização da execução desta atividade. Produzir pastel é uma atividade que demanda pouca produção intelectual, então é viável automatizar isso. Já produzir patentes demanda muita produção intelectual, não é possível fazer isso em linha de produção.*/
Produzir software é uma atividade artesanal, mas que pode ser planejada e controlada de maneira profissional. Pensar na produção de software de maneira industrial é um contrassenso.
Testar apenas no final
No mundo ideal, implementou -> testou, no ato! Na hora! E não passa pra frente no cronograma se o teste não passar (teste passar = funcionalidade sem defeito). Isso é aplicar testes unitários, usar TDD (não é em todo CRUD que se vai gastar dinheiro fazendo métodos de teste de alta cobertura, há um bom senso nos critérios adotados), trabalhar de olho na qualidade da entrega etc.
No mundo real, os testes ficam para o final. E aí a Lei de Murphy que citei anteriormente vai sim aplicar-se, o Cone da Incerteza também citado vai se confirmar, e a teoria do custo de correção do defeito, também citada, idem.
E quando os testes vão ser realizados, já se tem um passivo enorme de defeitos a serem corrigidos, e não tem mais latência para queimar no cronograma. Ou seja, acabou o tempo, acabou o dinheiro, acabou a paciência do patrocinador, mas aumentou o escopo do projeto, pois o passivo de defeitos precisa ser corrigido.
Procrastinar como modus operandi para geração de débito técnico
Eu conheci uma figura que sempre falava: “no final do projeto a gente arruma isso“. Falava também “isso não é prioridade agora“.
E toda a equipe técnica pensava o contrário: quando ele falava que não era prioridade a equipe achava que era. Quando falava que no final a gente arrumava, todo mundo achava necessário arrumar na hora.
Só que esta figura falava isso umas seis vezes por semana, num projeto que durou três anos. Essa figura era o Líder Técnico do projeto, e tinha autonomia total sobre o escopo que estava sendo produzido. O resultado deste projeto fica fácil de imaginar.
Semelhante à questão de “testar no final”, procrastinar resoluções técnicas é um péssimo negócio, pois acumula pendências para o fim do projeto que nem sempre são solucionáveis.
Às vezes quando se vai discutir uma pendência técnica no fim do projeto, percebe-se que é inviável resolvê-la neste momento, pois demandaria “desmanchar” aquilo que foi feito errado, corrigir todos os efeitos colaterais, e ainda fazer certo o que não foi feito no tempo adequado.
E o que se faz no fim: joga-se a sujeira para debaixo do tapete. Os gestores não assumem que enrolaram em situações como essa.
Conclusão
Não tem mágica. Não tem milagre. É matemática. Mas às vezes uma matemática mais complicada do que pode parecer, pois os projetos dão errado principalmente por problemas causados pelo produto mais perfeito que conhecemos: o ser humano.
/* Esta é a versão 1.0 deste post. Imagino que teremos alguns incrementos de versão em breve. Participem com críticas, comentários, nos ajudem a fazer a versão 2.0. Acreditamos que ele é muito relevante para todos que são da área de software! */
Se você gostou do conteúdo deste post, deixe seus comentários, para ajudar outras pessoas a encontrarem este material! 🙂
Obrigado, grande abraço!