Gestão 2.0 / Gestão, Software

Quem leu meu artigo de alguns dias atrás “Então você quer terceirizar um projeto? Quem é você?” pode imaginar que a culpa dos projetos terceirizados darem errado é somente de quem pede, do cliente. De jeito nenhum. Parte está lá sem dúvida, mas boa parte está fora, em quem atende, os terceiros, as “consultorias”.

Tudo começa quando você recebe uma Requisição de Proposta (RFP) e agora precisa entender o problema, rascunhar uma solução, descrevê-la numa proposta, precificar e enviar de volta ao requerente.

Se é ruim quando uma RFP vem apenas como “quero um site”, tanto pior é uma proposta que retorna com “eu faço sites, custará $X”. Do ponto de vista do departamento de compras, quando eles recebem uma proposta de volta obviamente concluem que quem está mandando a proposta está automaticamente afirmando que “sabe fazer”, e para ele basta observar quanto cada um vai cobrar. Basta que o responsável técnico avalie as propostas e se ele disser que todos atendem a solicitação, vence o menor preço.

Definição de Software

Parece simples, mas é bem mais complicado que isso. Começa partindo do princípio que quem vai avaliar as propostas entende o que está avaliando ou que pelo menos se importe com isso. Uma coisa é comprar material físico. Por exemplo, “quero comprar tijolo”. É bem mais simples e só isso é super claro, certo?

Errado, materiais físicos precisam (e podem) ser bem espeficados. Continuando meu artigo anterior, você não quer meramente qualquer tijolo. Você começa querendo “Bloco Cerâmico de Alvenaria”, por exemplo. Que segue as especificações NBR 7.171, NBR 6.461, NBR 8.947 e a Portaria Inmetro nº 152. Como você sabe que o fabricante segue tudo isso? Uma das formas é usando um terceiro com competência para realizar essa avaliação, como o InMetro.

Então, o problema é que em software não existem espeficicações como essas. E aí começa a procura pelo Santo Graal do mundo de software. E também uma grande confusão. Empresas de produção se certificam como PS 9000 ou QS 9000 no mundo automotivo, TL 9000 no mundo de telecom, ISO 13485:2003 no mundo médico e assim por diante.

Mas uma coisa é especificação técnica do produto manufaturado. Outra coisa é a auditagem e certificação dos processos de produção e controle de qualidade dos fabricantes. NBR 7.171 é uma especificação que define aspectos físicos do tijolo. ISO 9000 é a certificação que pode ser avaliada no processo de fabricação do tijolo na fábrica de tijolos. Existe ISO 9000 para empresas de software (aliás, ISO 9000 não é um único padrão mas uma família de padrões), é a ISO IEC 90003 2004. Mas ela não especifica o software em si, apenas os processos de produção desse software.

Todos sabem que não é “difícil” se certificar numa ISO numa empresa de software, ela é bem genérica. É trabalhoso, de fato, mas não é “difícil” no sentido que você não precisa ser cientista de foguetes. Outros tipos de certificação apareceram para tratar do assunto software, dois dos mais conhecidos são o CMMi, mundialmente, e o MPS.BR no Brasil. Novamente, nenhum deles tem nada a dizer sobre o conteúdo do software produzido, apenas do processo geral a que a empresa submete seus programadores.

Agora, o que eu sempre digo: software se chama “soft”-ware porque justamente não é “hard”-ward. Você tem condições de especificar muitas e importantes características de um hardware, como o tipo de material utilizado, as dimensões, volume, resistência, voltagem, corrente, capacitância, quantidade de transistores, etc. Elas efetivamente deixam pouca margem para diferenças entre dois hardwares. Claro que existem margens, é onde cada fabricante se diferencia, seja sendo mais eficiente do que está especificado ou com funcionalidades que não estão especificadas por um custo semelhante.

Experimente fazer o mesmo com software. Um tipo de produto final que não tem material físico, portanto não obedece leis da física, não tem dimensão, não tem volume, não tem peso, não tem nada que possa ser definido e comparado.

Você pode tentar definir aspectos da pré-produção, coisas como quantidade de linhas de código, quantidade de arquivos, quantidade de linhas por arquivo, quantidade de classes, diversas “quantidades” aleatórias e arbitrárias. E mesmo que tenha mil delas, se comparar dois softwares que obedecem esses parâmetros, terá a surpresa de encontrar dois produtos de comportamentos absolutamente diferentes e incomparáveis.

O produto final não são as linhas de código, ou os arquivos, esses são parte dos insumos. O software é o produto abstrato que fornece as funcionalidades que o cliente precisa. E esse produto é muito difícil de definir, exatamente porque um mesmo comportamento esperado pode ser produzido de infinitas combinações diferentes desses insumos.

Da mesma forma como num trabalho criativo como arte (novamente, não gosto também da palavra “arte” comparada a “software”, mas os efeitos são similares para os dois). Dois quadros que tem o mesmo “resultado” podem ser pintados com quantidade muito diferentes de materiais e tudo mais. Seria total idiotice – e acho que todos concordam – tentar “especificar” o que é um “processo de pintura de quadro padrão” dizendo que ela deve ser feita usando um cavalete de campanha metálica, uma palheta com 8 cores de tinta óleo, um godê de 300ml, um diluente específico de óleo de linhaça, uma espátula de ponta arredondada, 8 tubos de tinta óleo de 60ml, e o desenho não pode ter mais do que 100 traços e consumir mais do que os 8 tubos de tinta, e assim por diante. Pode especificar a pré-produção quanto quiser, mas um artista com um guardanapo e um lápis vai bater sua “arte especificada”.

Mas é exatamente essa a burrice que todos cometem: quem compra, quem venda e quem descreve esse mercado. Todos estão especificando a pré-produção, avaliando os processos de produção e ninguém está efetivamente avaliando o produto final, abstrato. E da mesma forma como para avaliar arte você precisa apreciar arte, para avaliar software você precisa apreciar software. Cada software é único, por mais que seu comportamento final seja similar ou igual.

O que quer dizer uma empresa certificada em CMMi nível 5? Quer dizer que a empresa conseguiu fazer o avaliador acreditar que ela segue os processos mínimos requeridos para o nível 5 – não necessariamente que ela tem de fato, inclusive, apenas que o avaliador acreditou. E isso não quer dizer absolutamente nada sobre o software produzido no final.

Os Terceiros

Depois dessa longa introdução sobre software, vamos retornar ao problema imediato: você é o terceiro que tem que atender o cliente. Vamos ver como você reage a uma requisição de proposta:

Você é do primeiro tipo se basicamente procura o template de documento mais próximo que tem, usa o recurso de substituir do Word para mudar o nome do cliente (acreditem, há quem esquece disso!), chuta um preço qualquer e envia de volta. O resto do projeto e tudo mais será tão aleatório quanto essa proposta enviada. Você é o cara que responde, “sim, faço seu site, custa R$X”. Você depende única e exclusivamente de vendedores bem relacionados ou outros tipos de relacionamentos que nada tem a ver com a entrega técnica. O dono da empresa é amigo da escola. O cara que aprova no departamento de compras tem o rabo preso com você ou coisas do tipo.

Você é do segundo tipo se tem um “processo” onde diversas áreas utilizando diversas metodologias (um COCOMO) e repositórios de históricos (como a partir de CMMi nível 3) para formatar uma proposta (pseudo)-cientificamente preparada. Você provavelmente tem alguma relação com o primeiro tipo, deu sorte, cresceu e agora vende baseado na sua marca “famosa” e ilusão de que é competente.

Você é do terceiro tipo se, dentro das limitações arbitrárias exigidas pelo cliente, consegue retirar o máximo de informações possível tanto do que está no documento de requisição como diretamente com os stakeholders (os que tem interesse no produto final) e, baseado em muita experiência e boas práticas, consegue descrever por escrito o que ele quer (o escopo), como ela será produzida (a solução técnica), o que é necessário acontecer para que isso seja feito (as premissas), quais os riscos inicialmente identificados e como mitigá-los, uma estimativa – que sempre, independente de como for feito, será um chute honesto -, e dará o preço desse chute. A partir daí gerenciará o projeto para que caiba dentro do que colocou na proposta.

Sobre os Elementos da Proposta

Agora falando sério sobre trabalho, não estou sendo sarcástico. Vamos ver a definição de estimativa: é o cálculo aproximado de um resultado que é usável mesmo que os dados iniciais sejam incompletos ou incertos. Mas o problema é que na área de gerenciamento de projetos é que uma “boa” estimativa (que não vai dizer 115.5 graus Celsius, mas vai dizer “razoavelmente quente” em vez de “gelado”) é a base de um plano de projetos decente. Todo o resto vai derivar dos parâmetros: objetivos, escopo, premissas, riscos, prazo. Daí podemos derivar: custos, cronograma, recursos humanos, tarefas, entregáveis, etc.

Aliás, comece do começo: o projeto não é o escopo. O projeto sempre deveria ser o Objetivo. Ou seja, independente do que será produzido, mesmo seguindo ipsis literis o que diz o escopo, o projeto deveria ser considerado um fracasso se seu objetivo não foi cumprido. E isso vale para o cliente requerente e para o terceiro que vai atendê-lo: se seu objetivo não for claro, direto e mensurável, seu projeto já começou fracassado. Resumindo e repetindo: o objetivo do projeto não é ter “um” software ao final. O objetivo é ter “algo” (um software) que ter uma determinada missão depois de pronto e um resultado que ele deve atingir.

Todos odeiam estimativas, os programadores mais ainda, porque todos sabemos que “estimar” e “com precisão” não combinam na mesma frase, e sabemos que o tempo pode variar radicalmente do nada. Como eu disse antes, diferente do mundo físico onde tudo obedece as leis da física, não existe nada equivalente num mundo abstrato. Ela não tem leis. Lembre-se: as 3 leis da física de Newton, só valem para a física! Parem de tentar encontrar coisas como “ação e reação” em mundos abstratos!

Novamente, o objetivo não é “acertar” a estimativa, porque isso é impossível. A responsabilidade da consultoria é justamente gerenciar para que o projeto “caiba” no que foi estimado. Não é “adivinhar” o futuro, é “produzir” o futuro. Estimativas são afirmações de que uma determinada produção não pode continuar infinitamente e que existe a espectativa de ao final desse tempo termos software que cumpre os objetivos do projeto.

Mas então basta acertar “exatamente” o escopo. Novamente, algo quase impossível! Como disse antes, não existem maneiras de se ter especificações técnicas precisas sobre o software. E, não, dizer que ela segue os Design Patterns do Gang of Four ou DDD do Eric Evans ou qualquer nova “tendência” da moda atual, não quer dizer quase nada. Nenhuma delas garante que o software criado atinge os objetivos do projeto.

Qualquer coisa pode acontecer durante o tempo do projeto, muitas delas são conhecidas, por isso existem Premissas e Riscos. Quanto mais premissas o cliente atender, menor será o preço estimado inicial do projeto. Quanto mais riscos forem mitigados, menor serão os acréscimos ao preço final faturado ao cliente. Essas condições precisam estar descritas em palavras, no papel, e ambos os lados precisam concordar com elas. O famoso “depois não diga que não avisei”.

Não dá para prever tudo. Por isso experiência é importante. O programador mais genial, mas com pouca quilometragem, não saberá descrever premissas básicas. Aliás, bons programadores sempre tendem a ser otimistas. E não, não me importa se você usa pontos de função, pontos de casos de uso, COCOMO, COSYSMO, PRICE, SEER-SEM, SLIM ou qualquer acrônimo. Usar ou não usar não torna sua estimativa “mais próxima” ou “menos próxima” do que será futuramente gasto.

E esqueça sobre utilizar históricos de outros projetos, comparação de estimado x realizado. É como querer ganhar na loteria utilizando os resultados anteriores como parâmetro no chute. Tempo gasto em projetos de software são eventos estatisticamente independentes. De forma grosseira, se você lançar uma moeda e cair cara 3 vezes, não há nenhuma justificativa para dizer que sairá cara novamente. A probabilidade do evento continua sendo 50%, independente de quantas vezes você já jogou a moeda. A maioria das pessoas infelizmente costumam não entender esse problema e é onde você confunde correlação com causalidade.

Estimativas, dentre outras coisas, servem para limitar o esforço que será gasto no projeto. Uma mesma equipe de software que levou 8 meses para terminar um projeto, provavelmente consegue levar 6 meses. Eu particularmente costumo brincar dizendo que equipes de software obedecem o comportamento dos gases: todo gás vai ocupar todo o volume do recipiente onde é colocado. Só precisa ter certeza que o volume do recipiente pelo menos cabe todo o gás sem estourar! E novamente na analogia dos gases, num volume constante, quando mais aumentar a pressão, maior aumenta a temperatura!

Portanto, “estimativa” é o tempo “adequado” que inicialmente parece que “cabe” o desenvolvimento do software descrito no escopo que cumpre o objetivo do projeto. Novamente, determinar “adequado” e “cabe”, não depende de nenhuma equação, é unicamente dependente de experiência de quem está participando na descrição da proposta. E lembrando, que é o tempo que “cabe” segundo as premissas descritas na mesma proposta.

Dada a estimativa, dela deriva também o que será construído, quem vai construir – quais papéis – e durante quanto tempo corrido. Por exemplo, uma estimativa de 800 horas pode significar um projeto de 5 meses com uma pessoa ou um projeto de 3 meses para 2 pessoas sendo que uma delas só ficará por 2 meses. Ou ainda um projeto de um mês para 5 pessoas, lembrando que até certo ponto não adianta colocar 9 mulheres que a gravidez não vai demorar só 1 mês.

E com os papéis determinados, vem o custo do projeto, que engloba a taxa de compra do consultor acrescido do overhead da empresa multiplicado pela quantidade de pessoas e multiplicado pelo total de horas estimadas. Lembrando novamente que muita gente esquece que na hora de estimar não tem só codificação propriamente dita, tem reuniões, tem idas e voltas de aprovação, tem várias tarefas não-técnicas que normalmente não estão estimadas e por isso depois o projeto fracassa para a consultoria em termos de tempo. Quer ver um exemplo? Vamos pegar um bem simples:

• 1 programador: 320 horas (8 semanas)
• 1 designer: 80 horas (2 semanas)
• Total: 400 horas
• Tempo corrido de: 10 semanas (porque o design tem que estar pronto antes do desenvolvimento)

Comece agora a colocar uma reunião de 1 hora por semana, uma espera de 1 semana para para somente um round de aprovações (caso otimista), mais tempo de um gerente (sim, ele é necessário e precisa fazer o meio de campo entre os desenvolvedores e as expectativas do cliente). Fora o tempo pós-entrega que vai ter mudanças do cliente, sempre tem. Vamos rascunhar:

• 1 programador: 360 horas (9 semanas)
• 1 designer: 120 horas (3 semanas)
• 1 gerente: 60 horas (por todo o projeto)
• Total: 540 horas
• Tempo corrido: 12 semanas

35% não é pouca coisa! 140 horas a mais é quase o tempo de 1 novo programador por quase 1 mês. E esse tipo de coisa é esquecida ao se fazer estimativas e ninguém entende porque o tempo não deu.

Outra coisa, muitas vezes já vi coisas assim: “prometeram o projeto para 3 meses a um total de R$ 4 mil, não dava pra recusar”. Façamos uma básica conta de padeiro: 3 meses são aproximadamente 510 horas. 4 mil dividido por 510 é menos de R$ 8 por hora. Nem um trainee trabalha por meras R$ 8/hora! Se o projeto fosse durar mesmo 510 horas, e faça de conta que a taxa (de venda, não de compra!) média dos envolvidos fosse na época R$ 40/hora (obviamente é um valor-fantasia, dado que eu também trabalho numa consultoria), então esse projeto não poderia custar menos de R$ 20.4 mil! Uma enorme diferença! E pasmem: é o tipo de conta que poucos que recebem as propostas fazem! Escolha o mais barato e tenha certeza absoluta que esse projeto será uma enorme dor de cabeça.

Às vezes é estratégia da empresa terceirizada usar um preço muito abaixo do custo para tentar “ganhar” clientes. Isso é burrice! Repito: isso é burrice! Um cliente que aceita uma certa faixa de preços do fornecedor jamais vai aceitar que essa faixa dobre ou triplique no próximo projeto. Você estará assumindo prejuízos que certamente não pode aguentar lembrando que o pagamento do cliente vem sempre depois que você já teve que pagar seus consultores na taxa de compra cheia! Enfim, é o caminho mais rápido para falir.

Porém, para cada uma pequena consultoria que fale praticando essa “estratégia”, parece que surgem mais duas, e para o cliente às vezes é bom porque ele vai retirar tudo que puder antes dela falir, ou terá um mal projeto mas talvez nem se importe por causa dos motivos que já expliquei no artigo anterior. Socialmente falando, se um cliente diz “eu gosto de você”, não quer dizer que ele “goste” como você está pensando, porque ninguém completa a frase. Ele pode querer dizer: “eu gosto de você porque você é barato, vai falir, mas não está reclamando” ou “eu gosto de você porque seu projeto vai fracassar, eu vou ganhar créditos por mandar vocês embora, e ainda posso ganhar uma promoção em cima de vocês!”. Claro, a recíproca também é verdade. Ninguém é verdadeiramente transparente. Quando alguém diz “somos transparentes” eu só consigo enxergar um vidro fumê. Acha que é transparente? Coloque por escrito, em palavreado não-ambíguo, coloque publicamente e assine embaixo.

Enfim, são apenas alguns toques para entender os dois lados: quem terceiriza e quem é terceiro. Continuem acompanhando, ainda tenho muito mais a dizer sobre isso. Ah sim, e dica de ouro para quem avalia propostas: enviem os motivos de porque uma proposta foi recusada. Se existe tanto processo para dificultar tudo, não vejo porque justamente onde ela teria mais valor, o passo não existe. Quer garantir que quem está avaliando leva seu trabalho a sério? Então envie por escrito porque determinada proposta foi recusada, tanto internamente quanto para os fornecedores. Afinal, como o fornecedor saberá o que você quer, se nem mesmo você sabe? Qualquer coisa diferente disso significa que o critério é tão aleatório quanto jogar cara e coroa para escolher (o que seria até justo de dizer) ou alguém tem o rabo preso (e por isso não pode dizer).

Disclaimer: todas as opiniões deste artigo refletem apenas a visão pessoal do autor e não refletem a visão da Info, da empresa do autor ou qualquer outra entidade.