Software Da Silva

Friday, 18. November 2011

Um software com que tive contato graças ao projeto que comentei foi o Da Silva. Ele auxilia na validação de páginas HTML que serão utilizadas por leitores de tela de deficientes visuais, entre outras coisas.

Pelo que vi, ele não funciona muito bem com sistemas 64 bits(se usa Windows 7, provavelmente pode esquecer de rodar). Mas se você usa o bom e velho Windows XP, conseguirá executar facilmente esse aplicativo, que por sinal é gratuito.

Na última versão disponível no site http://www.dasilva.org.br o download feito traz como versão um executável que aparentemente não é atualizado desde 2007.

O maior problema que tive foi o fato de que as páginas não estão abertas a público, e por isso para que eu consiga avaliá-las, eu precisei salvar as .HTML geradas e só depois rodar o programa na pasta para testar todas ou rodar em arquivo por arquivo(testando apenas os .HTML).

Os passos para avaliar com o Da Silva uma HTML que já está no seu computador são:

1) Menu “Avaliadores”
2) Opção “Avaliador de Acessibilidade”
3) Trocar o combo “Nível” de “página” para “arquivo”
4) Selecionar o arquivo “.html” desejado.

Obs.: Existem algumas limitações nessa versão, como por exemplo, se você usar uma “página.html” que seja muito grande, então o “Da Silva” exibe a mensagem: “o arquivo é muito grande para ser avaliado” e exibe a tela em branco.

Após o Da Silva avaliar o sistema, ele retornará uma lista com os arquivos avaliados e os erros e avisos encontrados.

Tela exibida após selecionar o arquivo - 01

 

Ao clicar na linha que deseja ver mais detalhes, uma tela com os erros detalhados aparecerão.

Nessa tela(Listagem dos erros – 02) existirá uma tabela com as seguintes informações:

  1. P.V (Ponto de Verificação): Ponto de referência que deveria usado para encontrar maiores detalhes sobre o erro ou aviso no site. Porém não encontrei um detalhamento de cada tipo de erro através do site oficial.
  2. Casos Gerais: Breve descrição do problema.
  3. Ocorrências: Quantidade de vezes em que o problema acontece.
  4. Linhas: Linhas onde o problema acontece.

Ao se clicar na linha de erro, o sistema aparentemente iria mostrar na janela “Saiba Mais”

Listagem dos erros - 02

Mas infelizmente isso não acontece. Procurei também no próprio site do Da Silva e não encontrei uma descrição mais detalhada sobre os erros que o software encontra. Apesar de fraca, a descrição informada auxilia a encontrar o possível erro.

Existem 3 tipos de erros, que segundo o site oficial são classificados como:

Prioridade 1

Pontos que os criadores de conteúdo Web devem satisfazer inteiramente. Se não o fizerem, um ou mais grupos de usuários ficarão impossibilitados de acessar as informações contidas no documento. A satisfação desse tipo de pontos é um requisito básico para que determinados grupos possam acessar documentos disponíveis na Web.

Prioridade 2

Pontos que os criadores de conteúdos na Web deveriam satisfazer. Se não o fizerem, um ou mais grupos de usuários terão dificuldades em acessar as informações contidas no documento. A satisfação desse tipo de pontos promoverá a remoção de barreiras significativas ao acesso a documentos disponíveis na Web.

Prioridade 3

Pontos que os criadores de conteúdos na Web podem satisfazer. Se não o fizerem, um ou mais grupos poderão se deparar com algumas dificuldades em acessar informações contidas nos documentos. A satisfação deste tipo de pontos irá melhorar o acesso a documentos armazenados na Web.

 

Quanto aos avisos, não encontrei informações sobre eles no site oficial.

Minha dica é:

Fique atento aos erros informados pelo software, pois coisas como campos com value=”" o software aponta como um possível erro, com a informação de que leitores de tela ou browsers podem não dar suporte para value vazio, algo que torna-se essencial em diversos aplicativos.

Infelizmente o site encontra-se aparentemente abandonado e com poucas informações relevantes. Por hora o que tenho pra falar sobre o Da Silva é isso. Caso queiram, usem os comentários pra dúvidas, críticas ou sugestões.

Acessibilidade

Friday, 18. November 2011

Já faz algum tempo que estou tendo que lidar com alguns casos de uso que devem ser desenvolvidos de forma que deficientes visuais possam interagir com o sistema.

O cenário que tenho é o seguinte:

Temos um software WEB desenvolvido usando JSF, de uma grande Universidade, e ela precisa que alguns de seus casos de uso estejam acessíveis para alunos com deficiência visual.

Infelizmente o conteúdo que encontro na web que trata desse assunto é vago e fraco, principalmente se tratando da língua portuguesa.

Pretendo passar um pouco do que vivi(e ainda vivo) nesse projeto, e outras coisas que venho descobrindo a medida que vou aprofundando no assunto.

Recomendo também a leitura completa do artigo http://internativa.com.br/artigo_acessibilidade_06.html antes de se desenvolver ou prototipar qualquer tela acessível, para saber se nosso objetivo é passar no teste de acessibilidade ou realmente tornar nossas páginas acessíveis.

Essa página será fixa, pois pretendo ir atualizando os links e afins que eu for encontrando.

 

Da Silva(link para um artigo que eu fiz sobre o software Da Silva:

Site: www.dasilva.org.br – O site está parado desde 2007, e contém pouca informação/documentação sobre o sistema que eles desenvolveram.

 

Isso vai dar merda capitão

Wednesday, 9. November 2011

Depois de muito conversar com vários amigos e pessoas da área, ví que praticamente todos já passaram ou passam pelos mesmos problemas. Seja na empresa X ou Y, uma hora você vai passar por isso em sua carreira.

Antes de julgar o texto note que ele foi construído com base em experiências próprias e de diversos amigos e colegas da área de Tecnologia da Informação, não sendo direcionado a empresa K ou L, nem ao gerente Z ou W.

1) Foco da equipe

(sempre que alguém fala Foco da equipe, Foco no trabalho ou Foco nos “bugs xyz”, me vem na cabeça a imagem de uma FOCA graças a um meme ai)

No projeto em que você trabalha, qual é o foco que seu gerente passa? Em geral existem dois:

  1. Atender o que está em contrato
  2. Atender ao que o cliente quer E satisfazer ao contrato

Se o foco da equipe em que você trabalha tem como objetivo apenas atender ao que está no contrato, saibam que a empresa de vocês pode até receber no final do contrato, mas certamente vai ficar com o nome ruim na praça e se o cliente tiver a opção de não trabalhar mais com vocês, então isso vai acontecer.

O primeiro método é sempre o mais desmotivador, pois ele corta a possibilidade de se entregar aquilo na qualidade em que se pretende. O importante é atingir o contrato, e gerar conhecimento ou fazer da melhor forma só vai acontecer se o gerente não souber que existe outra forma de se fazer mais rápido.

Agora se o seu objetivo é o segundo item, existe alguma chance de se receber no final E manter o cliente satisfeito, com um possível novo contrato, significando mais rendimentos para a empresa que você trabalha, garantindo empregabilidade e condições de melhores salários(não que isso vá realmente acontecer, mas isso é outra história).

 2) Cronogramas

A única coisa realmente certa nesse tópico é que:

Cronograma não entrega projeto.

Além disso, temos outros pontos a observar, como:

Como seus cronogramas são montados? Pra isso existem diversas formas de se fazer, cada uma aplicável a um tipo de equipe e/ou projeto. Vou citar apenas 3.

  1. Baseia-se única e exclusivamente no PF (ponto de função)
  2. Um arquiteto ou desenvolvedor sênior avalia todos os CSUs
  3. Cada desenvolvedor avalia o próprio CSU

Apesar de muitos estudiosos insistirem que esse método funciona por se tratar da média, ainda não vi o sucesso acontecendo, ou talvez seja apenas uma desculpa geral a velha frase: “o projeto não está dando lucro”. Talvez se essa frase fosse modificada para: “o projeto não está dando o lucro esperado“, então estaríamos bem.

Para que esse primeiro método funcione, o gestor deve ter um conhecimento profundo sobre a produtividade dos membros da equipe, o comercial deve saber exatamente como VENDER esses pontos de função para não ter gente fazendo hora extra(banco de horas, em geral).

O segundo e terceiro método conseguem te dar um prazo mais próximo da realidade, se isso vai tornar seu projeto rentável ou não, isso é outra história.

Para que um arquiteto consiga avaliar o CSU para outras pessoas, ele deve conhecer muito bem do problema(CSU) em questão e do desenvolvedor, pois ele pode subestimar o problema e causar dores de cabeça para o desenvolvedor conseguir atingir o prazo definido.

Para o terceiro método a realidade se torna mais possível, porém sempre existe o fator humano em questão. Em equipes desmotivadas e desestimuladas isso pode ser um tiro no pé para prazos longos. Mas se a equipe em que você trabalha está empenhada e todos estão motivados, essa é uma forma de estimular a participação e mostrar que o membro da equipe tem poder de fala.

Não entrei em detalhes sobre quando se trabalha com homens/hora, pois nos casos em que isso é usado para terceirizar mão de obra o tempo é o que menos importa para a empresa que “aluga” o funcionário, e a perspectiva do cliente não é o meu foco nesse texto, apesar de ser de extrema importância e citada diversas vezes.

Uma forma interessante para o terceiro método é usar a Metodologia de Estimativas PERT, onde se faz um calculo simples com a estimativa pessimista, mais provável e otimista. Já trabalhei usando-as e foi interessante ver que elas se aproximam da realidade.

3) Motivação

De onde vem a motivação? De dentro do próprio funcionário, mas é claro que existem outros fatores que colaboram para que ela se fortaleça ou desapareça.

Pessoas que se dizem desmotivadas por causa do salário devem procurar outro emprego. Afinal, vagas existem.Todo mundo quer ganhar mais, em todas as áreas. Então isso nunca pode ser o fator decisivo pra você estar ou não motivado.

O que motiva uma pessoa pode não motivar outras.

Estar atualizado e trabalhando com tecnologias de ponta na área de TI é vontade de praticamente todo mundo com quem converso. Mas muitos projetos já existem e o custo/risco de se migrar é alto ao ponto de cortar essa possibilidade. E para isso existem alternativas de manter sua equipe atualizada mesmo quando não se pode “mexer” nos projetos.

Atenção as idéias de sua equipe, quando você apenas escuta e depois ignora a sugestão, você pode estar cortando futuras sugestões, pois as pessoas se cansam.

Flexibilidade de horários já é um ponto forte na política de muitas empresas, mas será que isso realmente acontece? Se está na política da empresa, o gerente pode até querer que isso não aconteça em determinados dias, mas o ideal é que a política da empresa é que seja seguida. Muita gente se vê atraída por esse benefício que o RH vende para o possível novo funcionário e quando ele entra, descobre que ela existe mas ninguém nunca viu, estilo cabeça de bacalhau.

Feedback é algo que pode motivar um funcionário a melhorar ou a continuar fazendo bem o que ele já faz. Mas saber como dar esse feedback é algo que muitos gestores não tem habilidade. Você pode até achar que está falando pra ajudar, mas se não souber como dizer, você pode estar prejudicando. Entre as principais funções de um gestor está o fato de saber lidar com pessoas, quando isso não acontece, pode esperar que cedo ou tarde pessoas desmotivadas vão se tornar um prejuízo ou um desgaste para a empresa.

Políticas de premiações são um ponto interessante e pouco explorado, talvez pelo fato de que uma métrica eficiente para dizer quem se destacou ainda não seja fácil de se achar. E quando o fator humano entra para ajudar a escolher quem se destacou ou não, vários murmurinhos sobre o motivo pelo qual a pessoa se destacou podem surgir, então escolham consciente a(s) pessoa(s) que irá(ão) receber o “prêmio”.

4 ) O mito do técnico virar gerente

Não leve o título do tópico muito a sério. Existem os casos em que isso acontece e vai bem. Eu concordo que um gerente precisa conhecer do território que ele está pisando para poder facilitar os caminhos. Mas achar que seu melhor técnico vai ser o seu melhor gestor não é uma verdade.

As qualidades de um excelente gestor são diferentes das qualidades esperadas em um excelente técnico.

Um gestor que já foi técnico é importante para a equipe, para saber com o que está lidado e para não se mostrar despreparado diante do cliente. Mas quando esse gestor começa a dizer como as coisas devem ser implementadas começamos a correr um sério risco de falhar e a culpa ainda cair sobre o desenvolvedor que por estar conversando com um gestão não teve coragem de dizer que esse não era o melhor caminho.

Saber o lugar de cada um é importante para o bom andamento do projeto.

Existem metodologias e certificações que definem um padrão de como um gestor deve ser/agir, mas isso deve ser adaptado para a realidade da equipe/empresa/projeto, ou estará fadado ao fracasso.

5) Hora Extra/Banco de Horas

Não pretendo entrar no mérito do que é o certo perante a lei no que diz respeito ao que define uma hora extra ou ao que define o banco de horas.

Acontece muito de alguns membros(ou até mesmo toda a equipe) ter a disponibilidade para trabalhar quando se fala que suas horas serão pagas, e quando essas horas começam a se tornar banco de horas essa disponibilidade desaparece.

Isso é normal e deve ser compreendido. Ninguém quer trabalhar de graça, assim como ninguém quer ter que trabalhar para lotar o banco de horas e quando for para esvaziar o banco de horas, ter problemas.

O problema de tudo é o abuso. Em casos em que a hora extra é liberada, certos indivíduos chegam a ficar na empresa apenas para completar as “X” horas que precisa a mais para “Y” de dinheiro no fim do mês. E é isso que faz com que as coisas sejam cortadas. O abuso da liberdade que possui. (Fato muito parecido com a liberdade do acesso a internet, mas acho que seja assunto pra outro tópico)

Já vi gente reclamando de não conseguir usar o banco de horas quando bem quis. E isso deve ser aceito quando se tratar de uma fase de projeto delicada, como fase de entrega e afins. Mas é dever do gerente conseguir equilibrar as atividades de forma que em algum momento essas horas sejam usadas. Mas será que isso acontece?

 6) Informação Aberta

Isso é algo que pode incomodar muito uma equipe. Muitos desenvolvedores com quem conversei não sabem exatamente como está o projeto em que trabalha, para onde ele vai, nem de onde ele veio.

É interessante que quando possível a equipe seja informada de qual o feedback do cliente com relação que eles entregaram, além de também ser importante saber quais serão os próximos módulos que a equipe irá participar. Ví muito de você não saber o que vai ter de atividade quando acabar o que está fazendo, seja por não saber se virão novos módulos, ou até mesmo se você será remanejado. A falta de informação já fez gente procurar por novas oportunidades, então manter sua equipe bem informada pode ser algo que te traga um bom retorno.

 

Nada do que foi falado aqui é novidade, e muitos dos gerentes de hoje sabem e/ou já tiveram até as mesmas opiniões que vários funcionários tem, mas por algum motivo não aplicam isso na prática. E é a prática quem pode fazer a diferença para que tudo caminhe bem do início ao fim.

Seria gratificante que vocês participassem nos comentários, com seus pontos de vista, críticas ou seja lá o que for. E ainda se possível, compartilhem!