terça-feira, 22 de setembro de 2015

Escravos da Estética





Bem fez Platão, que dissociava o belo do físico. Já no conceito aristotélico, a beleza estava associada à simetria, proporção e perfeição das formas. 

Vivemos uma ditadura da estética. Todos admiramos o belo, mas raramente paramos para refletir acerca de alguns dos seus aspectos não tão nobres.


O preconceito estereotipado a gays, negros, deficientes e diversas outras minorias já virou arroz de festa. E o preconceito ao feio? Normalmente passa despercebido. É comum ouvirmos um comentário despretensioso quando nos deparamos com uma criança loira, bonitinha, passando necessidade.


- Tão linda e nas ruas, pedindo esmola!
 

Como se a miséria fosse uma prerrogativa do feio...
 

Todos buscam o belo; em si próprio e também no outro. O homem fica com a mulher bonita e tola, em detrimento de outra bem mais interessante, porém com menos atributos físicos.
 

Não é de se espantar que assim seja. Voltando à filosofia, Immanuel Kant associava a beleza à sensação de prazer proporcionada pelo objeto observado.
 

Nas relações humanas, a beleza chega a ser negativa, no sentido em que frequentemente orientamos nossas escolhas a aspectos superficiais.
 

Mas há outras abordagens, relativas ao próprio detentor da beleza. O exemplo, obviamente, recai sobre a mulher, que, sem maturidade para lidar com a própria beleza e com o assédio natural dela decorrente, acaba “estragada” pelo excesso de paparicação, pelo amplo leque de possibilidades, pela não-necessidade de conquistar o outro.
 

É aí que a estética constitui-se, de certa forma, um desserviço a quem a possui.
 

Frequentemente, o belo é um ser autocentrado, incapaz de abstrair e enxergar as coisas por uma ótica que não seja a sua – ok, isso ocorre com a maioria das pessoas – e, consequentemente, torna-se alguém extremamente desinteressante.
 

O que se vê hoje é um culto exacerbado ao corpo, à beleza física. Nas academias, o objetivo é corpo bombado e modelado, e não a saúde.
 

A mídia, a TV e o cinema parecem vender cada vez mais a ideia de que o padrão de felicidade passa incondicionalmente pelo culto à estética. E não é bem assim.
 

Ou não deveria ser.

Devemos encontrar mecanismos para nos defender de nós próprios, para que a nossa natureza não acabe conosco, tal qual a parábola do sapo e do escorpião.
 

Uma das ferramentas mais interessantes para o conhecimento das relações interpessoais é a Janela de Johari. Os quadrantes do “eu desconhecido” e, mais ainda, do “eu cego”, são fundamentais para o entendimento do porquê de nossos comportamentos.
 

De qualquer forma, devemos ponderar o quanto estamos dispostos a mergulhar nos nossos “eus”. Afinal, a afirmação mais verdadeira que existe é a de que a ignorância é o segredo da felicidade; o conhecimento, da dor. 

Mas uma dor necessária.

Estética (do grego αισθητική ou aisthésis: percepção, sensação, sensibilidade) é um ramo da filosofia que tem por objetivo o estudo da natureza da beleza e dos fundamentos da arte. Ela estuda o julgamento e a percepção do que é considerado beleza, a produção das emoções pelos fenômenos estéticos, bem como: as diferentes formas de arte e da técnica artística; a ideia de obra de arte e de criação; a relação entre matérias e formas nas artes. Por outro lado, a estética também pode ocupar-se do sublime, ou da privação da beleza, ou seja, o que pode ser considerado feio, ou até mesmo ridículo.
Fonte: Wikipedia

domingo, 12 de julho de 2015

Bits, Bytes e Padrões



Resultado de imagem para bits e bytes que mundo é esseJá falei outras vezes sobre padrões e processos. É um assunto até meio cansativo, mas esses dias tive uma conversa na nossa Fábrica de Software que representa bem a importância do tema no mundo de TI.  Acho até que num curso sobre melhores práticas que ministrei há algum tempo tratamos desse assunto específico.

O assunto era a chamada de sub-rotinas dentro de um programa Cobol. Hipoteticamente, temos um programa XXXP0001 que chama a sub-rotina XXXS999.

Quando chegava um programador novo, geralmente passava-se a seguinte orientação:
- Olha, para chamar o subprograma você deve codificar:
Na Working Storage:
XXXS9999 PIC X(8) VALUE “XXXS9999”.
E na Procedure Division:  
CALL XXXS9999 USING “Variáveis”.
- Uai (geralmente os programadores novos eram mineiros)! Disseram-me que era pra chamar direto, entre aspas (CALL ”XXXS9999” USING “Variáveis”)! E funcionou!
Ou ainda:
- Bah (alguns eram gaúchos)! Eu tenho que chamar vários programas! Porque preciso declarar a variável XXXS9999? É melhor criar uma variável genérica, tipo GDA- SUBROTINA! Funciona, fica mais claro e eu posso reusar a guarda!
Nesse caso, o código na Procedure Division ficaria assim:
MOVE “XXXS9999” TO GDA-SUBROTINA.
CALL GDA-SUBROTINA USING “Variáveis”.
MOVE “XXXS8888” TO GDA-SUBROTINA.
CALL GDA-SUBROTINA USING “Variáveis”.
A resposta, nos dois casos, geralmente dada por quem não tinha ido atrás dos porquês, era sempre a mesma:
- Olha, esse é o padrão do pessoal da Governança de TI. Esses caras de processo vivem inventando moda! É melhor fazer como eles querem e ficar quieto.
Assim, as coisas funcionavam, os caras da MDS (metodologia de desenvolvimento de sistemas) eram os chatos e a vida seguia.
Mas não era bem assim. O padrão estava certo. Aliás, perfeito. A única falha dos “chatos da MDS” era não ter comunicado adequadamente qual o motivo do bendito padrão.
Vamos tentar clarear um pouco:
No caso do mineirim, ao dar o CALL na sub-rotina entre aspas, estamos passando ao processo de compilação (na realidade, de linkedição) a informação de que a chamada é estática, e não dinâmica.
Portanto, o executável resultante do processo de compilação e linkedição do programa XXXP0001 teria incorporado também o XXXS999. Funciona? Sim, funciona, inclusive até mais rápido.
No entanto, no momento em que versionássemos a sub-rotina XXXS9999, apareceria um dos seguintes problemas:

  • Se a XXXS9999 tivesse instruções SQL, o programa XXXP0001 abendaria com o famoso SQLCODE -805 (acho que já falei sobre isso no post “Desmistificando o Bind”), no momento de acessar o banco de dados DB2, por divergência no timestamp do Cobol X999 com o do package de mesmo nome;

  • Se fosse uma sub-rotina em Cobol puro (sem SQL), o problema seria ainda maior. O P0001 continuaria rodando, mas chamando a versão anterior da S9999, embutida no seu executável.

Portanto, ao declarar a variável, o CALL passa a ser dinâmico, com o P0001 chamando a X9999 em tempo de execução, sempre em sua versão mais recente.
Bem, já o caso do gaúcho é um pouco mais sutil, e mesmo “programalistas” experientes não sabem bem o porquê do padrão ser o nome da variável com o mesmo da sub-rotina.
A palavra-chave aqui é rastreabilidade.  Existem ferramentas (na minha empresa temos o X-REF, dentre outras) que buscam a cadeia de chamadas dos módulos. Isso é bastante útil para sabermos qual o impacto de uma alteração em um programa chamado por vários outros.
Essas ferramentas são bem interessantes, mas algumas delas (na realidade quase todas) trabalham por varredura no código-fonte, e não seriam capazes de detectar que o programa P0001 chama o S9999 no “CALL GDA-SUBROTINA”, como ocorre no “CALL XXXS9999”. Na realidade, usamos de um artifício para “enganar” o X-REF, pois ele acha que estamos chamando diretamente o XXXS9999, quando estamos mesmo é chamando uma variável de mesmo nome. Como o seu conteúdo é exatamente o mesmo (ver o VALUE no início do texto), o resultado é a chamada rastreada corretamente.
Bom, o objetivo dessa sopa de bits e bytes era apenas reforçar a importância dos padrões e da comunicação no nosso trabalho.
Um abraço e até a próxima!

segunda-feira, 4 de maio de 2015

Todos do mesmo lado

Quando eu comecei a desenvolver software, lá pelos anos de ... Bem, deixa pra lá quando foi isso... (você percebe que está ficando velho quando algumas pessoas acham que você existe desde a criação do mundo, junto com o Sílvio Santos e o Sarney...)

Bem, voltando ao assunto, nessa época, eu via o pessoal que trabalhava com processos e normatização como burocratas, indivíduos sem nenhuma conexão com o mundo real, que se preocupavam apenas em aplicar seus conhecimentos acadêmicos.

Santa ignorância: Com o passar do tempo, ao aprender um pouquinho mais e enxergar a TI de uma forma um pouco mais holística, comecei a entender a importância das normas e dos padrões.

Gerir um parque de TI como o nosso não é uma tarefa fácil. Se, num determinado momento, a Ditec “fechasse pra balanço” e passasse um tempo sem atender nenhuma demanda da área de negócios (algo impensável no mundo real, obviamente), ainda assim seria necessário um razoável contingente de pessoas apenas para manter tudo funcionando, contingente esse muito maior se não tivéssemos uma governança estruturando e organizando a casa.

Imagine como seria nosso legado de mais de 1000 sistemas desenvolvidos conforme a criatividade de cada um. Um simples B37 (abend por falta de espaço, se não me engano) seria um grande desafio para o analista da madrugada resolver.

Assim é que alguns problemas são triviais simplesmente porque temos padrões de codificação, de compilação, de bibliotecas, de procedures, de documentação, de procedimentos, de nomenclaturas, etc.

Portanto, na minha simplória ignorância (o segredo da felicidade, como costumo afirmar...), eu queria era liberdade para construir os sistemas do jeito que bem entendesse.

No mundo tecnológico, existe uma certa dicotomia entre desenvolvedores e normatizadores. Uns acham que os outros definem coisas não aplicáveis ao mundo real; os outros acham que os “uns” são meio insubordinados, que não leem instruções e fazem as coisas erradas de forma proposital.

Os dois lados estão certos – e errados. Precisamos exercer um pouco mais uma certa palavrinha muito em voga ultimamente: empatia. Colocar-se na situação do outro e entender o porquê dele não fazer aquilo do jeito que queremos.

Embora tenhamos profissionais com características claramente de desenvolvedores ou de normatizadores, é bastante saudável que, periodicamente, as pessoas vivenciem o outro lado, e percebam que somente com retroalimentação de parte a parte as normas se tornam facilitadoras da execução, bem como contribuem para mitigar riscos.

Peter Drucker, austríaco naturalizado americano, considerado o guru da administração, já dizia a algumas décadas que 60% dos problemas organizacionais decorrem de problemas de comunicação.

Todo mundo sabe – mas às vezes esquece – que processos e padrões não são um fim em si mesmo. Cobit, Itil e PMBOK, pra ficar somente nesses três, são frameworks excelentes, mas declaram, salvo melhor juízo, cerca de 110 processos.

Implementações segregadas dessas boas práticas, sem levar em conta o contexto das organizações, certamente levam a redundâncias e overhead.

Já vi o PMBOK ser acusado - injustamente - de atrasar os projetos. Como um conjunto de boas práticas, seu objetivo é exatamente racionalizar sua gestão, mantendo-o sob controle do líder.

Gosto muito de uma frase que já ouvi mais de uma vez em eventos de TI: Framework – adote e adapte.

Padrões e normativos são diretrizes e nunca exaurem todas as possibilidades, notadamente num meio tão complexo como o nosso. 

Um abraço e até a próxima.

domingo, 22 de março de 2015

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 é 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.

quarta-feira, 10 de setembro de 2014

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...

terça-feira, 29 de julho de 2014

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 


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%

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