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.