Noema

Fetichimos Visuais

Segue link para apresentação que realizei em 17/8/2007, no painel Second Life, durante o Seminário Fetichismos Visuais no Sesc São Paulo. Comentem!!

http://noema.typepad.com/SeminarioFetichismosVisuais.pdf

Sobre Peirce e as Metáforas

Saiu na última edição da Revista de Semiótica Aplicada da UNESP Araraquara,  Volume 4, Número 2 - Dez de 2006, artigo deste que vos escreve. O tema: o conceito de metáfora na obra C. S. Peirce.

Leiam aqui e comentem.

Revista "Sessões do Imaginário"

Saiu no último número dessa revista da PUC-RS (Julho de 2006) artigo no qual faço uma crítica do conceito de bios midiático do Muniz Sodré. Convido a ler.

Clique http://www.pucrs.br/famecos/pos/sessoes/s15/sessoes_abelreis.pdf.

Há um erro bizarro de tipografia na página 74, onde foram trocadas as letras gregas por caracteres aleatórios. Deve ter ocorrido na conversão do formato original do artigo (.doc) para o formato final da revista. Ficou chato, mas dá para tolerar.

Pirâmides, Sistemas e Gestão de Projetos

Artigo de Abel Reis publicado na Revista Business Standard, Julho de 2003.

Que diferença há entre erguer uma pirâmide no Egito Antigo e implementar um moderno e complexo sistema de informações? Inúmeras, mas duas chamam aqui nossa atenção: a construção de uma pirâmide tinha prazos elásticos – gerações – e recursos virtualmente infinitos – material e escravos, milhares de escravos. O desenvolvimento de sistemas de software de média/grande complexidade nos coloca o desafio de especificar, implementar e testar autênticas obras de Engenharia em prazos enxutos – poucos meses ou anos – e com recursos finitos – orçamentos, plataformas tecnológicas e equipes de projeto.

É provável que os egípcios usassem formas rudimentares de administração de suas grandes obras (faraônicas de fato), como de resto todas as grandes obras de Engenharia e Arquitetura ao longo da história da humanidade devem tê-lo feito. A Revolução Industrial contudo trouxe nova exigência: eficiência. A produção em larga escala guiada pela otimização de tempos, movimentos e custos. Assim, a partir do século XIX, com o advento dos conceitos de Administração Científica e a introdução de controles e previsibilidade nas organizações, inicia-se a formalização de práticas e ferramentas de administração de projetos. Contudo, são os programas militares e espaciais americanos iniciados nos anos 50, os grandes impulsionadores da disciplina de Gestão de Projetos. Mais recentemente, instituições como o PMI (Project Management Institute) (EUA) ou o IPMA (International Project Management Association) (Europa) vêm contribuindo para a consolidação teórica e a difusão de experiências e melhores práticas na área.

Em última instância, práticas bem-definidas e sistemáticas de gestão de projetos visam a garantir que objetivos claramente estabelecidos entre contratante e contratado sejam atingidos em prazos aceitáveis (para ambas as partes), com alocação ótima de recursos. Ou seja, tempo e dinheiro são recursos escassos e como tal devem ser administrados. Neste sentido, escopo, prazo, recursos, riscos e comunicação são fatores críticos cuja administração ao longo de um projeto, por práticas rigorosas e consistentes, permitem garantir o alcance de objetivos, minimizando riscos, e antecipando problemas. Vamos aqui nos deter em três desses fatores.

Escopo delimita as entregas (conjunto de funcionalidades de um sistema) que devem ser apresentadas ao final de um projeto para o cumprimento de seus objetivos. É o mais elementar de todos os fatores a serem gerenciados no projeto de sistemas. Contudo é o mais negligenciado. Isso decorre quase sempre da informalidade com a qual as referidas características são descritas. É como se alguém construísse uma casa sem suas especificações arquitetônicas (planta baixa, elétrica e hidráulica); ou seja, corre-se o sério risco, durante a obra, de descobrir que o banheiro principal ficou do lado de fora da casa. No projeto de sistemas a falta da especificação técnica para a delimitação e detalhamento de escopo leva invariavelmente a surpresas desagradáveis, para contratantes e contratados. Em última instância, escopo é uma ferramenta de comunicação na qual o contratador expressa necessidades, expectativas, regras inerentes ao domínio da aplicação (regras de negócio) e outros aspectos relevantes à compreensão, por parte do contratado, do que se espera da aplicação final. Ausência de escopo claramente definido resulta freqüentemente em clientes insatisfeitos e fornecedores irritados – quando não “quebrados”.

Prazo é o mais mensurável e sensível dos fatores de projeto. Mensurável por razões evidentes pois trata-se de uma medida do tempo materializada num cronograma; e sensível porque qualquer estimativa errada de projeto (ex.: recursos) o atinge diretamente. Gerenciamento de prazo é uma atividade que envolve monitorar e avaliar os demais fatores de forma a garantir que o progresso físico do projeto (quanto das funcionalidades previstas no escopo foi implementado) está em linha com seu progresso no tempo. Quase sempre há diferenças para pior (“falta tempo no fim do projeto”). Muitos desentendimentos entre contratados e contratantes no projeto de sistemas decorrem de uma visão errada de que prazo é um alvo fixo. Infelizmente não é.  E por que não é? Porque no projeto de sistemas de média/alta complexidade há diversas fontes de interferência que afetam o prazo, entre eles: (a) a dinâmica das organizações e dos mercados (novos requerimentos); (b) o amadurecimento interno dos contratantes, que revêem definições e necessidades (revisão de requerimentos); e (c) a eventual falta de maturidade das plataformas tecnológicas envolvidas no projeto. Todos os pontos citados podem afetar o prazo e talvez nenhum deles possa ser previsto e controlado de forma efetiva no início do projeto. Portanto, prazo é um alvo móvel, e o que podemos assegurar é a probabilidade de atingi-lo dados os recursos disponíveis e os eventuais riscos envolvidos. Chegamos, assim, ao nosso terceiro fator crítico na gestão de projetos: riscos.

Riscos são eventos que não queremos que ocorram, mas que podem ocorrer. Portanto devemos monitorá-los. Mesmo assim, de forma geral e, no projeto de sistemas em particular, a mentalidade de avaliação estruturada de riscos é pouco difundida (pelo menos no Brasil). No âmbito da gestão de um projeto, riscos afetam (eventualmente de forma irreversível) a viabilidade de prazo ou recursos tais como estipulados originalmente. A identificação, análise, qualificação, ponderação e mitigação (execução de ações de contorno) devem ser realizadas recorrentemente de modo a perseguir as metas vigentes, ou ainda antecipar o seu descumprimento de forma a permitir que alternativas sejam consideradas a tempo.

O tema aqui em questão é amplo e haveria muito outros pontos a considerar. Mas vale por fim lembrar que a aplicação de técnicas de gestão de projetos no desenvolvimento de sistemas deve caber a contratados, mas também a contratantes. Em particular, escopo, prazo e riscos são fatores a serem geridos de forma aberta e compartilhada pelos envolvidos (cliente e fornecedor). No Brasil hoje é possível identificar um movimento ainda que tímido nesta direção, por exemplo através da criação de PMO’s (Project Management Office, instância de auditoria e suporte teórico e prático aos projetos), junto às áreas de sistemas de grandes empresas. Desta forma, ganha-se enorme eficácia e reduzem-se os riscos de chegar a “pirâmides inacabadas”.

O que rádios-relógios e web sites têm em comum?

Artigo de Abel Reis publicado na Revista Business Standard - Maio/2002. Rodou bastante pela web.

Toda vez que você programa o seu rádio-relógio, usa o equipamento de áudio, o MS Word ou a Amazon.com você está exposto ao que chamamos de interface de usuário. A facilidade ou dificuldade que temos para usar e comandar essas diferentes interfaces é o que define sua usabilidade. Quanto mais simples e intuitivo for o uso de uma interface, maior a usabilidade. O termo tornou-se um aspecto fundamental no projeto (design) de produtos para o mercado de consumo em massa.

Há 30 anos era incomum que produtos de consumo (eletroeletrônicos em particular) fossem projetados levando em conta aspectos como contexto de uso e características cognitivas (como as pessoas pensam e atuam) de seus usuários. Contudo, a competição globalizada obrigou as empresas a diferenciar seus produtos, via de regra, tornando-os mais complexos, com cada vez mais recursos (como enfatizaria qualquer bom vendedor).

Este último fenômeno obriga-nos a considerar o design de um produto não apenas pela ótica de sua engenharia, mas também pela da usabilidade. Como oferecer vários e sofisticados recursos sem dificultar dramaticamente o uso de um produto e sem obrigar seus usuários a ter o manual de operação sempre à mão? Como oferecer uma experiência de uso agradável e diferenciada sem tirar o usuário de seu objetivo principal, seja este imprimir um documento ou comprar um livro? Enfim, como esconder a complexidade numa interface de usuário agradável, ágil e de simples assimilação?

No caso particular de projetos de software (considerando aqui Web sites como um tipo de software), ao longo das duas últimas décadas, consolidou-se uma área de conhecimento própria com base em teorias e métodos da Psicologia Cognitiva e da Engenharia de Software denominada User Interface Design, ou Projeto de Interface de Usuário (IU). Paralelamente, ocorreu a consolidação de mercado dos sistemas operacionais de interface gráfica (ex.: MS Windows), viabilizando a fixação de uma “cultura de uso” de aplicações baseadas em recursos gráficos (janelas, botões, ícones, etc.). Hoje ninguém duvida da importância de empregar conceitos e técnicas de IU para desenvolver sistemas de média-alta complexidade que sejam intensivos em interação com usuários finais.

O boom da internet acabou por transformar o projeto de IU num fator crítico de sucesso para Web sites, tanto do ponto de vista da usabilidade quanto da qualidade visual de apresentação. A internet coloca o desafio de oferecer, em tempo real, sistemas online para milhões de usuários distribuídos, com culturas, perfis e níveis de experiência diversificados. Ou seja, sem projeto de IU adequado, um Web site tem grande chance de dar errado.

Levando tudo isso em conta, é fácil entender porque usabilidade tornou-se uma palavra-chave na indústria de software. Agora cabe a pergunta: o que deve ser considerado no projeto de uma bem-sucedida interface de usuário, em particular, quando falamos de Web sites? Como tudo na vida, projeto de interfaces exige método. Vamos dividir da seguinte forma o processo de criação e desenvolvimento de IU na internet:

Entenda
Antes de mais nada é fundamental entender plenamente os objetivos do Web site, o perfil típico dos seus usuários – em particular, idade, instrução e experiência com sites similares – bem como o contexto de uso. Em última instância, você precisa saber para quem e como a interface será usada. Óbvio? Nem tanto. Exemplificando: é muito diferente o projeto de interface para um Web site que vende medicamentos de outro que comercializa roupas. A rigor, ambos vendem para, eventualmente, os mesmos públicos. Mas os contextos de uso (lugar, motivação, disponibilidade mental, urgência) são muito diferentes.

Desenhe e simule
Uma vez que estão identificados os objetivos, públicos e contexto de uso é chegada a hora de formular o escopo da interface. Ou seja, que serviços e conteúdos serão oferecidos aos usuários. Exemplo: ao apresentar uma peça de vestuário, apresentaremos também recomendações de outros itens?
Com o escopo pronto, o passo agora é desenhar todas as telas às quais os usuários estarão expostos. Cada uma delas corresponderá a um momento (estado) da interação do usuário com a interface do Web site. Exemplo: ao clicar num link de “busca avançada” da tela “home” de uma loja de departamentos virtual, via de regra, chega-se a uma tela específica de configuração dos parâmetros de busca.
Ao fechar uma seqüência lógica de telas, devemos simular sua utilização de forma exaustiva visando a identificar: ausência de telas, ausência de serviços e conteúdo previstos no escopo, oportunidades para simplificar ou melhorar processos, potenciais pontos de dificuldade de entendimento por parte dos usuários. Veja que este estágio não implica em desenvolvimento de software. Tudo pode ser feito no papel ou em telas estáticas no computador. Por vezes, neste estágio de simulação pode-se envolver grupos de usuários finais com o objetivo de validar conceitos e premissas.

Construa
De posse das telas desenhadas, é chegada a hora de implementar tecnicamente a interface. As boas práticas de desenvolvimento de software recomendam dividir um Web site em três camadas: apresentação, lógica de negócios e dados. Seguindo esta abordagem você codificará as telas em HTML ou mesmo ASP ou JSP, de forma a isolar os componentes da camada de apresentação dos componentes que implementam transações, acesso a bancos de dados, integração com sistemas legados.
Esta abordagem permite alocar equipes diferentes, em paralelo. Quanto mais complexo, dinâmico e transacional for um Web site, mais benefícios tira-se dessa abordagem. Outro ponto importante: não é preciso desenhar todas as telas para então começar sua programação. Pode-se dividir o processo em etapas e evoluir de forma incremental.

Avalie
O fato de você ter aprovado a interface em tempo de Desenho não significa que na prática tudo será como você espera. Ao implementar tecnicamente uma interface, muitas vezes percebe-se pontos de lentidão, redundâncias indesejáveis, gaps de informação que podem tornar incompreensível alguma tela, etc. Para minimizar tais problemas, o melhor é conduzir uma avaliação completa e minuciosa da interface sob a forma de grupos de usuários reais que testam o produto final antes de seu lançamento em larga escala. Naturalmente quanto mais cuidadosa for a fase de Desenho menos problemas serão detectados nesta última etapa.

Blogs Corporativos

Artigo de Abel Reis, publicado na Gazeta Mercantil na edição de 29 de setembro de 2005. Teve boa repercussão.

Empresas são redes sociais. Esse é o ponto zero. O resto vem depois. Marcas são signos na mente das pessoas, que resultam em muito da propagação de idéias, opiniões e desejos através de redes de pessoas. Se não, como explicar o famoso “efeito viral”? Produtos são objetos nas prateleiras de lojas e de casas, mas também são resultado de interações complexas entre redes de fornecedores. Se não, por que falaríamos de “cadeias de valor”?

Empresas sempre foram assim. Décadas atrás, essas redes eram bem rígidas, hierárquicas (VPs de diretores de gerentes de chefes de...). Hoje, as redes sociais nas empresas tendem a ser menos hierárquicas e mais distribuídas no espaço e no tempo (pense no email). Além disso, essas redes cruzam empresas criando redes de redes... E é por essas redes que trafegam as informações e o conhecimento que movem as empresas (para frente e às vezes para trás). Tudo isso trouxe novos desafios: segurança da informação, gestão de pessoas, gestão de conhecimento são alguns deles. Interessa-nos aqui o último desses pontos: a gestão de conhecimento.

Conhecimento é um ativo das empresas que deve estar a serviço da sua eficiência organizacional, da geração de valor para acionistas, e da qualidade final para clientes. Este assunto sempre pareceu “difícil”. Eis então que surgem os blogs. Sim, acredite, os blogs. Blogs são web sites relativamente padronizados cujo desenvolvimento não requer habilidades técnicas de programação de software. Blogs permitem que usuários leigos publiquem conteúdos diversificados (textos, fotos, áudios), e que outros usuários, visitantes do blog, agreguem comentários pessoais de forma rápida, simples e padronizada. Assim, todos se tornam, potencialmente, autores e publishers – basta um bom assunto na cabeça e um editor de blogs na mão.

Mas, o que gestão de conhecimento nas empresas tem a ver com blogs? Muito. Isto porque empresas vêm descobrindo que a simplicidade - tipo “ovo de colombo” - dos blogs, pode ser colocada a serviço da produção, captura, organização e disseminação de informações e conhecimentos. O ponto é oferecer nas redes internas (intranets) recursos de blog pelos quais cada funcionário, departamentos ou filiais tornam-se publishers. O blog corporativo é, particularmente, muito adequado para armazenar e difundir conteúdos poucos amenos ao tratamento formal por sistemas estruturados (é o caso dos textos). E, na prática, o formato pelo qual conhecimento e informação relevantes circulam nas redes sociais das empresas é frequentemente informal. Há aqui muitas aplicações: como ferramenta de RH, de relações com o mercado, de colaboração em projetos de grande porte, e por aí vai. Exemplo? A IBM que declara ter hoje mais de 3.600 blogs internos mantidos por seus colaboradores. Grandes marcas também descobriram que blogs podem ser muito úteis, graças à sua simplicidade e agilidade, na comunicação com seus consumidores e outros públicos externos à empresa. Não se trata aqui de fazer do blog um SAC. Blogs corporativos são nesse caso um meio natural e prático de influenciar clientes, mas também de ouvi-los, identificando preferências e expectativas. Exemplo? A Procter&Gamble que mantém o sparklebodyspray.com para interagir e influenciar consumidores adolescentes de uma marca de desodorantes.

Para encerrar, um alerta: blogs não são plataformas para desenvolver sistemas ou portais de internet ou portais corporativos. Não queira usá-los para formar complexos e robustos banco de dados ou repositórios indexados de documentos ou algo nessa linha. Para isso há outras ferramentas e tecnologias bem mais adequadas. Pense nos blogs como ferramentas simples, ágeis, rápidas de implantar, e que funcionam como catalisadores para a “química das redes sociais”, na sua vida ou na sua empresa.