Quanto vale um Software

Nos últimos anos, tenho trabalhado com um assunto desafiador: Fábrica de Software. 

E isso tem adquirido uma importância especial pra mim, até pelo fato de estarmos envolvidos com o tema sob diferentes dimensões.

Já fui desenvolvedor, já fui demandante dos serviços de fábrica, já cuidei dos contratos – sendo, portanto, intermediário entre a contratante e a contratada – e agora, pra completar o ciclo, estou do lado de lá, como fornecedor.

O tema, por si só, já é muito interessante. E percebê-lo sob diversas óticas torna tudo mais complicado – afinal, a ignorância é o segredo da felicidade – mas também muito mais gratificante.

Esses dias, conversando com duas colegas de trabalhado, fui consultado sobre o que, em princípio, parecia ser feijão-com-arroz pra mim, mas que percebi ser uma abordagem totalmente diferente: quanto vale um software. 

Minha preocupação sempre foi o preço justo de um sistema sob a ótica do custo, afinal o desafio era, até então, a prestação do serviço, visto que o seu produto – no caso, o aplicativo – era propriedade do contratante.  

Nesse contexto, podemos definir a métrica como a questão central. Quem é do meio sabe que apenas isso já é uma questão bastante complexa, envolvendo conceitos como SLoC (linhas de código), UCP (Casos de Uso), Pontos por Objeto,  APF (Pontos de Função) e outros. 

Para termos uma ideia de grandeza, há alguns anos (ou seriam décadas?) trabalhávamos no BB com uma ferramenta Case (Computer-Aided Software Engineering, ou Engenharia de Software apoiada por computador) da Texas Instruments. Reza a lenda que esse produto, chamado de IEF, tinha 20 mil pontos de função. Para efeito de comparação, o compilador VB e os populares Word, Excel e Project, todos produtos Microsoft, assim como o CICS, monitor de TP da IBM, têm entre 2 e 3 mil Pontos de Função de tamanho. 

Há alguns meses fiz uma palestra no IFPUG sobre as métricas contratuais adotadas nas Fábricas de Software do BB (basicamente APF e a nossa USTIBB) e, pela reação da plateia, percebi que estamos no caminho certo.

Até aqui, falamos basicamente de medir o produto. Para o adquirente, no entanto, há outras questões, podendo envolver inclusive métricas de processamento, como os MIPS (milhões de instruções por segundo) consumidos pela aplicação.

Bom, mas como falei, a questão aqui não é métrica. Ou não é só métrica.

Trata-se do valor de um software de prateleira, que vai muito além da questão do custo.

Para entendermos o problema – primeiro passo para chegarmos à solução – vamos trabalhar com um exemplo hipotético, de um aplicativo que custou R$ 100 mil para a softwarehouse em despesas de pessoal. Em tese, a aplicação poderia ser vendida por uns R$ 150 mil, propiciando uma margem bruta de 50% e uma margem líquida bem menor, se considerarmos outras despesas administrativas, de infraestrutura, impostos, taxa de risco, etc.

Mas vamos a algumas das diversas variáveis envolvidas.

A primeira (e principal): qual a percepção de valor que um potencial cliente enxerga no nosso produto? O que ele vai propiciar de retorno para o comprador? Ele se dispõe a pagar os R$ 150 mil? Meu produto é exclusivo ou há similares no mercado? Quanto custam? E se existir um Software Livre que atende os mesmos requisitos?

Mas tem muito mais: posso vender para apenas um cliente ou lucrar com várias cópias? Vou vender a licença? Ou o serviço (SaaS)? Haverá um contrato de manutenção? O treinamento está embutido no preço? Para quantos usuários?

Vamos adiante: o produto será customizado às necessidades do cliente? Qual o nível de integração envolvido? Requer a aquisição de outros produtos? Vai rodar na nuvem? O cliente tem um processo de diferimento definido? Isso torna o produto “mais barato” na prática. Qual o SLA do contrato?  

Bom, respostas pra tudo isso (se eu as tivesse) iria estender demais esse artigo. Além disso, no mundo real, envolvemos vários intervenientes, como a área técnica, o marketing e o jurídico, dentre outros.

Escrevo aqui mais como uma provocação para refletirmos sobre o tema. Afinal,  essa é uma preocupação que envolve desde gigantes da TI como uma IBM ou uma Oracle, até o estudante de ciência da computação que está desenvolvendo um site para a microempresa de um amigo.

Não fui eu!!

Recebi uma cobrança:

- E aí, não vai mandar aquele texto que você prometeu? Estou só esperando pra poder publicar...

Resposta “na lata”:

- Ainda não fiz. E a culpa é sua!

Atônita, minha amiga, claro, não entendeu nada. Fiquei até com pena da cara de espanto dela...

Era uma brincadeira, lógico. E era sobre isso que eu pretendia escrever. A nossa tendência de “terceirizar” os problemas, de sempre culpar o outro por nossas deficiências. Às vezes de forma consciente, às vezes não.

Quando é de propósito, não há muito o que comentar. Mas o pior é que, na maioria das vezes, realmente acreditamos na desculpa. E é isso que nos impede de evoluir.

Infelizmente, no mundo atual, esse tipo de comportamento é cada vez mais frequente. E decorre da nossa incapacidade de nos observar de forma isenta. Isso ocorre no plano individual e no coletivo.

Há algum tempo, um colega de trabalho falou um coisa aparentemente boba, mas que representa bem o que estou querendo falar. Ele disse:

- Engraçado, quando eu trabalhava na minha equipe anterior, nós achávamos que todos os nossos problemas eram causados por este setor. Agora que vim pra cá, parece que o problema estava era lá...

Outro caso, também emblemático: eu acabara de assumir uma equipe e um funcionário, que eu não conhecia, me chamou pra conversar:

- Sérgio, eu sei que eu não tenho rendido o suficiente, mas preciso dizer que estou passando por umas dificuldades. Eu me separei e meus problemas pessoais estão interferindo no meu trabalho. Mas vou tentar mudar.

Aquela franqueza, claro, me sensibilizou. E passei a ser mais compreensivo com o dito cujo.

Passado algum tempo, a situação parecia não mudar. Conversando reservadamente sobre o fato com alguém que conhecia o funcionário há mais tempo, ele me falou:

- Sérgio, sabe há quanto tempo o fulano se divorciou? Quase oito anos...

Essa historinha nos remete a mais algumas reflexões. A primeira é que algumas pessoas realmente têm dificuldade para superar perdas, e aquilo as acompanha o resto da vida; a segunda (que de certa forma está relacionada à primeira) é que o ser humano adora uma “muleta”, algo em que se escorar para não mudar seu comportamento.

Bom, essa é a vida. Reconhecer nossas deficiências é o primeiro (e o mais difícil) passo para evoluirmos. Querer mudar, o segundo. O resto é mais fácil.

Pra fechar: Minha amiga não tinha nada a ver com meu atraso. A culpa era exclusivamente minha...

O Pedreiro, o Muro e as Métricas

Esses dias fui convidado para fazer uma palestra na Conferência de Métricas de Software do BFPUG, o “braço” brasileiro do IFPUG (Internacional Function Point Users Group). O evento ocorrerá em novembro, e pela primeira vez em Brasília.

Não sou especialista no assunto. Mas, enfim, vamos lá. Pensando em como estruturar a apresentação, lembrei-me de uma interessante analogia de um colega do BB, já aposentado, que considero emblemática para o desafio que temos na gestão de fábricas de software.

É bem simples, e mais ou menos assim:

Um sujeito contratou um pedreiro para construir o muro da casa dele. O preço era R$ 1 mil. 

Terminado o serviço, seu José apresentou a conta:

- Dotô, são dois mil e quinhentos...

- Como assim? Combinamos mil, e você não fez nada mais do que eu lhe pedi...

- Fiz sim. Primeiramente, o senhor pediu pra construir o muro ali. Eu construí. Depois, o senhor se arrependeu e disse que era pra fazer mais adiante. Então! Mil pra fazer o primeiro muro, quinhentos pra derrubar e mais mil pra construir de novo... Dois e quinhentos!!

Não é difícil transportarmos o exemplo para o nosso mundo de TI. O refazimento de uma solução antes mesmo do final de sua construção não é tão raro assim (embora devamos nos esforçar para evitar isso. Um bom planejamento ajuda bastante...).

Obviamente, na maioria dos casos o problema está na instabilidade dos requisitos. Mas o fato é que, com frequência, há retrabalho. E se formos tirar “um retrato” do serviço de forma estática, veremos que ele não representará o real esforço do trabalho. Consequentemente, medidas de produtividade e de remuneração serão impactadas, e há uma tendência de imputar à métrica adotada a culpa de eventuais distorções.

Ora, seja em que métrica for (pontos de função, linhas de código, pontos por caso de uso, pontos por objeto, etc, etc, etc) qualquer verificação estática apontará divergências.

Concluímos, então, que o problema está no processo, não na métrica.

Dentre as muitas variáveis que podem ser utilizadas para se determinar a métrica ideal para desenvolvimento de software, considero o nível de granularidade do serviço de TI a ser medido uma das principais. Uma medição por Pontos por Objeto seria muito mais eficaz que a APF para medir serviços mais “granulares”, como a construção de um componente ou a modelagem de uma tabela.

Já para medir um documento de alto nível, no qual não conseguimos discernir num primeiro momento quais os objetos necessários para implementar a demanda, o ponto de função será mais útil.    

Pra fechar, seguem três questões de concurso relacionadas ao assunto. Uma delas, aliás, é bem polêmica. Quem se habilita?

CESGRANRIO - 2007 - EPE - Analista de Gestão Corporativa Júnior

Parte superior do formulário

A análise por pontos de função utiliza diversas características para estimar o tamanho de um software. Das características abaixo, indique a que NÃO afeta a contagem nesse tipo de métrica.

a)  Desempenho

b) Necessidade de backup

c) Necessidade de testes

d) Necessidade de comunicação de dados

e) Número de entradas do usuário 

FJG - RIO - 2011 - TCM-RJ

Na Análise de Pontos de Função, o fator de ajuste é o resultado da avaliação de 14 características gerais do sistema e é utilizado para determinar o tamanho final do software. Com efeito, os pontos de função obtidos da contagem das funções de dados e transacionais são conhecidos como “pontos brutos não ajustados”. O fator de ajuste promoverá uma variação nos pontos brutos num percentual, para cima ou para baixo, gerando os chamados “pontos de função ajustados”, que representam o tamanho final do software. Esse percentual é de até:

a) 5%

b) 10%

c) 20%

d) 35%

e) 50%

FGV - 2008 - Senado Federal - Analista de Sistemas

Parte superior do formulário

Considere as assertivas sobre a técnica de pontos de função para a estimativa de custo de desenvolvimento de um software:

I. A medida de pontos de função é independente da linguagem de implementação do software.

II. Os pontos de função são mais apropriados para medir os sistemas de processamento de dados dominados por operações de entrada e saída.

III. Existem grandes variações na contagem de pontos de função, dependendo do julgamento de quem fez a estimativa.

As assertivas corretas são:

a)  Somente II e III

b)  Somente I e III

c)  Somente I e II

d)  Todas estão corretas

e)  Somente I

Desenvolvimento de Software: Diferir ou Deferir?

Assim como dilatar/delatar, flagrância/fragrância, diferimento e deferimento tratam-se de palavras parônimas, com grafias parecidas mas significados bem distintos.

Na agência de um Banco, o gerente faz o deferimento de uma operação. No mundo de TI, também fazemos deferimentos no nosso dia-a-dia, mas vamos falar de outro assunto importantíssimo: o diferimento.

Nesse contexto, vamos abordar o diferimento de custos de software, um tema crítico, tanto pelos valores envolvidos como pelo reflexo direto no resultado das empresas.

O assunto não é trivial: temos alguns normativos legais sobre o tema, como a Lei 11.638/2007 e a MP 449/08. Esta última, inclusive, extinguiu o lançamento em contas de Ativo Diferido, mas permaneceu com o de Ativos Intangíveis, no qual se enquadram as soluções de TI.

O diferimento de custos de software existe pelo pressuposto de que, ao desenvolvermos um sistema, estamos investindo em algo que trará resultados para a organização em exercícios sociais futuros. Isso permite o artifício legal de “empurrar” a despesa para mais adiante, contabilizando o custo presente em uma conta de ativo da empresa e revertendo esse lançamento (amortização) em módicas prestações, ao longo dos exercícios seguintes.

Há algumas regras para se definir o que é e o que não é diferível no desenvolvimento de software, em dois níveis.

No primeiro, avalia-se a natureza da demanda. O esforço na evolução do sistema, como a inclusão/alteração de novas regras de negócio, é diferível; uma manutenção corretiva ou a extração de informações para órgãos de auditoria, não.

Além disso, devem ser avaliadas as atividades na implementação dessa demanda. Ex: o levantamento de requisitos e a codificação são diferíveis, o esforço de gestão do projeto, não.

Portanto, apenas a combinação desses dois níveis possibilitam a precisão dos valores a serem diferidos.

Alguns exemplos:
- a codificação em uma manutenção corretiva não é passível de diferimento;
- a codificação em uma manutenção evolutiva é passível de diferimento;
- a gestão de um projeto de saneamento (melhoria de performance) em um sistema não é passível de diferimento;
- a gestão de projeto em uma manutenção evolutiva não é passível de diferimento.

O diferimento dos custos de pessoal deve se dar mensalmente, pois deve guardar coerência com o dispêndio da folha de pagamento da empresa.

Já na terceirização, o assunto é um pouco mais complexo. Nos contratos bodyshop (baseados em horas, atualmente desaconselhados pelos órgãos legais) o processo é similar ao do desenvolvimento interno.

Nas fábricas de software, cujo modelo de negócios baseia-se na entrega, a provisão do que será pago e a métrica de cada contrato devem ser avaliadas. Na APF (Pontos de Função), por exemplo, a verificação se dá pelas fases/disciplinas da engenharia de software; na utilização de métricas proprietárias, cada tarefa definida no “cardápio de TI” deve ser avaliada.

Para soluções adquiridas, o lançamento do valor a ser diferido pode, dependendo do contrato, ocorrer de uma única vez. Já no caso dos softwares internos - tanto in-house como via outsourcing - o diferimento se dá num continuum, visto que praticamente todos os meses surgem novos valores a serem contabilizados como ativos e suas correspondentes amortizações, por conta desse dinamismo, variam a cada mês.

Bom, essa é apenas uma primeira abordagem. Futuramente voltaremos a falar sobre o tema. 

Tempo Valioso...

Tanto faz se é cereja ou jabuticaba; se já foi reproduzido mil vezes na rede; se o autor é Ricardo Gondim, Rubem Alves, Mário de Andrade ou – o que me parece mais provável – seu xará angolano, Mário Coelho Pinto de Andrade, poeta e escritor.

O fato é que o texto O Valioso Tempo dos Maduros me diz muito, e quanto mais cedo começarmos a “roer o caroço”, mais sorveremos da vida o essencial. No final desse post reproduzo uma das versões que circulam pela internet.

Dia desses, eu estava numa festa bem divertida. Aliás, surpreendentemente divertida.

Mas eis que o telefone tocou uma vez, tocou duas, três, e era sempre trabalho, abacaxis a descascar, o que, aliás, tem sido uma constante de uns tempos pra cá.

A barulheira me empurrou pra longe da diversão. Depois de dar os devidos encaminhamentos aos ananás (que dizem ser mais ácidos que os abacaxis), sentei numa sombra e ali permaneci sozinho por um bom tempo, exaurido, sem disposição para voltar à comemoração.

Acho que passou-se mais ou menos uma hora. Eu, sozinho, a divagar como a vida estava difícil, e como eu certamente contribuíra para isso, no mínimo pela minha baixa resiliência, por não transigir de alguns valores que considero inegociáveis ou, quem sabe, por incompetência mesmo.

Quando a festa caminhava para o fim e aquele monte de gente começava a dispersar, alguém chegou e sentou ao meu lado. Depois mais um, e outro, e mais outro. Não sei exatamente o que motivou aquele movimento: amizade, pena, curiosidade, o lugar agradável... O mais provável é que não tenha havido motivo nenhum. 

De repente, éramos uns oito ou dez, e aquela turma conseguiu levantar meu astral. Como o local precisava fechar, terminamos o dia num barzinho, tomei umas e outras e mais algumas - o que há muito não fazia - e voltei pra casa refletindo: num mundo onde sua história de vida não vale muita coisa, onde as pessoas relativizam conceitos básicos como respeito, ética, seriedade, bom senso e discernimento sobre o que é certo e o que é errado, aquele gesto gratuito e descompromissado de solidariedade representou muito pra mim. 

Aquele tempo “perdido” foi, pra mim, o tempo valioso citado no texto a seguir:

“Contei meus anos e descobri que terei menos tempo para viver daqui para a frente do que já vivi até agora.

Tenho muito mais passado do que futuro.

Sinto-me como aquele menino que recebeu uma bacia de jabuticabas.

As primeiras, ele chupou displicentemente, mas percebendo que faltam poucas, rói o caroço.

Já não tenho tempo para lidar com mediocridades.

Não quero estar em reuniões onde desfilam egos inflamados.

Inquieto-me com invejosos tentando destruir quem eles admiram, cobiçando seus lugares, talentos e sorte.

Já não tenho tempo para conversas intermináveis, para discutir assuntos inúteis sobre vidas alheias que nem fazem parte da minha.

Já não tenho tempo para administrar melindres de pessoas que, apesar da idade cronológica, são imaturas.

Detesto fazer acareação de desafetos que brigam pelo majestoso cargo de secretário-geral do coral.

As pessoas não debatem conteúdos, apenas rótulos.

Meu tempo tornou-se escasso para debater rótulos. Quero a essência. Minha alma tem pressa.

Sem muitas jabuticabas na bacia, quero viver ao lado de gente humana, muito humana; que sabe rir de seus tropeços, não se encanta com triunfos, não se considera eleita antes da hora, não foge de sua mortalidade; caminhar perto de coisas e pessoas de verdade.

O essencial faz a vida valer a pena.

E para mim, basta o essencial.”

Desafios da TI

Após a apresentação de uma softwarehouse, fui indagado sobre o que tinha achado do seu produto. Parecia muito bom (embora no Power Point tudo funcione, ainda mais se apresentado por um vendedor), mas refleti um pouco antes de responder. 

Minha conclusão foi: se eu fosse um bilionário russo daqueles que acordam e resolvem comprar um time de futebol e fundar um banco, o produto cairia como uma luva.

No entanto, para o ambiente tecnológico do meu Banco, pelo seu tamanho, complexidade, centenas de sistemas interligados, diversas plataformas, não seria um bom negócio. E ainda tem o processo. Ah, o processo...

Já falei sobre o assunto anteriormente, mas se vamos comprar um produto que implemente uma commodity, algo já maduro no mercado, precisamos ponderar se vamos incorporar também o processo, o que normalmente é uma boa idéia, mas nem sempre. Caso positivo, mesmo assim, sempre se faz necessário algum tipo de integração com o legado.

Mas se, por algum motivo - que muitas vezes está relacionado à cultura da organização ou a processos inter-relacionados - pretendermos manter do mesmo jeito o que já vínhamos fazendo, é possível que a solução requeira tantas customizações que acabe não valendo à pena sua aquisição.

Uma outra constatação: quanto mais maduro é o ambiente de TI de uma empresa – o que certamente é o caso dos grandes instituições financeiras do Brasil – mais complexa pode ser a integração. Afinal, bases corporativas, desacoplamento, não-redundância e outros conceitos tornam mais robusto e seguro o ambiente, mas por vezes podem ser um overhead no momento de conectá-lo a novas soluções.

Essa problemática faz com que o esforço de desenvolvimento “nativo” - pelo insourcing ou pelo outsourcing – das empresas seja sempre volumoso e pesado. Mas precisamos perseguir obstinadamente as melhores alternativas, que geralmente são também as mais simples, de forma a não tornar a TI algo inadministrável.

Hoje, a Tecnologia é reconhecida por todas as grandes corporações como apoiadora e mesmo alavancadora de soluções de negócio, mas a cada dia surgem novos desafios a serem superados.

A preocupação com eficiência operacional, com a priorização de demandas, com os processos (que não devem ser um fim em si mesmo, e sim viabilizadores das nossas entregas) e com a gestão do conhecimento, deve ser constante.

Acredito que teremos avançado mais um degrau de maturidade quando nossos produtos de TI tiverem um certo padrão, independente de sua origem, seja make by desenvolvimento interno, make by terceiros ou simplesmente buy. 

No Banco do Brasil, especificamente, o desenvolvimento interno, fundamentalmente, é o que nos fez chegar até aqui. A força e competência do nosso pessoal, o maior patrimônio da Ditec, foi e sempre será imprescindível. O outsourcing também é importante, no banco e em todas as demais organizações, essencialmente para que possamos gerir nossos vales e picos de demandas (quase sempre picos).

Costumo dizer que a maior qualidade do ser humano é a capacidade de reconhecer suas deficiências, pois somente a partir daí conseguimos atuar para superá-las.

Acredito que isso funcione também com as organizações, para conseguir superar seus imensos desafios.

Nau Sem Rumo

Há algum tempo estou para escrever sobre o momento delicado que o país atravessa, sacudido por manifestações populares, com uma lista quase interminável de reivindicações.

De tanto demorar, o assunto caducou, até porque já se falou demais sobre isso, sob todas as óticas possíveis.

Mas, esses dias, conversando com um grande amigo e sobrinho, acerca da questão dos médicos cubanos, o assunto me voltou à mente, sob algumas perspectivas diferentes.

A primeira é que percebi claramente que a minha procrastinação estava relacionada a uma questão física: sempre que eu pensava no tema, ele sugava todas as minhas energias, pois de forma meio subliminar – mas agora muito claramente – de alguma forma eu percebia estarmos diante de vários problemas praticamente sem solução.

Comecemos pela questão da saúde. Esse meu querido sobrinho é um jovem médico, vibrante, engajado, extremamente esclarecido, que já sofreu na pele todo o contexto da penúria da saúde pública no Brasil.

Pedi sua opinião sobre a proposta do governo em relação aos médicos estrangeiros. Ele me contextualizou e, coerente como é, me passou alguns links com outras opiniões, tanto da sua área quanto de outros segmentos da sociedade.

Bem, sem me aprofundar na proposta em si, até porque já se falou disso além da conta, a questão é: digamos que o governo reformulasse sua pauta, exigindo dos médicos estrangeiros a validação de seus diplomas segundo o CFM (Conselho Federal de Medicina), definisse uma carreira para profissionais da área no setor público (por que um médico trabalha com contratos temporários e ou mesmo verbais com o prefeito? Um juiz ou um promotor faz o mesmo? Qual a diferença fundamental entre os dois?), destinasse mais verbas para a saúde, determinasse a construção de novos hospitais, compra de remédios, etc, etc, minha opinião é: NÃO FUNCIONARIA. TUDO CONTINUARIA NA MESMA, OU PIOR.

Apenas para jogar lenha na fogueira (O Ronaldo já misturou os assuntos e deu no que deu...), o problema dos estádios da copa, foi dinheiro de menos? Ou dinheiro demais?

Porque a questão fundamental é: não temos gestão, seriedade de propósitos, continuidade. Nossas instituições estão corrompidas de uma forma muito mais profunda do que imaginamos. E por mais que ocorram algumas boas iniciativas aqui e lá, estas geralmente ocorrem por espasmos.

Uma das piores atitudes do governo tão logo o povo foi às ruas exigir seus R$ 0,20 de volta, foi ir à TV e revogar incondicional e linearmente todos os aumentos de passagens, dando uma demonstração, ao mesmo tempo, de fraqueza, submissão, falta de planejamento e administração por espasmo.

O que poderia ter feito? Se houve alguma lógica na atribuição do aumento, um ou outro poderia ter sido revertido, outro revisto para R$ 0,10, sei lá, e outros mantidos, com as devidas justificativas. Mas não. Da forma que foi feito, a percepção é que ele realmente foi desnecessário. Será que algum dia a população aceitará pacificamente qualquer aumento no preço da gasolina?

Na década de 1980, bancário no interior de Pernambuco, percebi que a população da pequena cidade onde eu trabalhava aceitava sem questionamento os desmandos do grupo dominante. E, mais que isso, entendia como lícita a apropriação do FPM (Fundo de Participação dos Municípios) e do patrimônio público em geral por parte do prefeito. Quando a situação chega a esse nível, fica difícil mudar alguma coisa.

Não conheço tantos países assim, mas creio que a grande maioria tem sua parcela de políticos corruptos. No entanto, aceitar, como no Brasil, a perpetuação de figuras reconhecidamente inescrupulosas em cargos-chave dos poderes, notadamente no legislativo, é uma afronta à sociedade.

Além disso, uma grande, imensa parcela da população que marcha contra a corrupção, é contra apenas a corrupção alheia. Que o digam as suas atitudes do cotidiano.

Voltando à questão das manifestações: as atitudes coletivas são importantíssimas, fundamentais, aliás. Mas a postura individual e, mais que isso, a “ralação” do dia-a-dia é que pode resolver alguma coisa. Uma amiga, professora universitária, contou o seguinte diálogo que teve com o filho, de 23 anos:

- Mãe, tô indo pra manifestação na praça!

- A favor de que?

- Não sei bem, mas precisamos mudar o Brasil.

- Quer mudar o Brasil? Arranje um emprego, trabalhe duro, ajude quem precisa. Faça a sua parte. Se sobrar tempo, vá às manifestações, sabendo, pelo menos, do que se trata.

É por aí.

De qualquer forma, se nem no ponto de partida consegue-se alguma coerência, fica difícil imaginar algum avanço. Voltando à delicada questão da saúde:a comunidade médica não foi ouvida, o serviço obrigatório no SUS cheira a trabalho escravo, o estudante de medicina, já tão sobrecarregado, precisará de pelo menos uma década pra se preparar para o mercado. Nada contra, se outras categorias mais privilegiadas não tivessem que trabalhar tão pouco, como aquela leva que zarpa de Brasília às quintas-feiras.

O país assemelha-se a uma nau sem rumo, chegando a uma perigosa encruzilhada.