Por que ainda precisamos falar sobre diversidade nos ambientes de TI?

Por que?

Quem atua no mercado formal de trabalho hoje lida com as constantes mudanças comuns à cultura da inclusão. Em escritórios nos deparamos com pessoas de diferentes gerações, anseios e responsabilidades.

As pluralidades da sociedade: gênero, etnia, condições físicas e de vida, já estão refletidas no mundo corporativo. Nos ambientes de TI as equipes multidisciplinares são utilizadas como base para a aplicação de metodologias de trabalho capazes de garantir entregas “rápidas”. Isso, por formar times heterogêneos, contendo um pouco de cada especialidade necessária ao antedimento de produtos específicos, restringindo com isto os seus focos de atuação e por consequência ganhando em produtividade.

A esses times  deu-se a responsabilidade de decidir estratégias às soluções: o que fariam e em quanto tempo; com qual o grau de prioridade; e, com quais custos e ferramentas. Eles ganharam a capacidade de discutir ideias. Mas como ser eficaz se só ouço a minha parte da  clientela, a minha “face da moeda”, quando o mundo a quem atendo me apresenta múltiplas?


Por que uma figura “diferente” em meu time ainda me incomoda tanto?

Pela falta de representatividade. E o que isto significa? Que embora eu tenha contato com pessoas “diferentes” de mim em meu meio de convivência ou ambiente trabalho eu não as tenho como modelo, eu ainda não as enxergo como um exemplo a ser seguido ou muitas vezes não valorizo o seu discurso:

  • Apenas 2% dos funcionários das maiores empresas brasileiras são pessoas com deficiência (o mínimo exigido pela lei);
  • As mulheres representam 58,9% dos estagiários e apenas 13,6% das vagas executivas;
  • As mulheres recebem 70% da massa salarial obtida pelos homens;
  • Não existe um executivo de origem indígena nas empresas estudadas;
  • 94,2% dos cargos executivos pertencem a brancos, enquanto apenas 4,7% dos negros ocupam cargos nesse nível. Superatualizado

E por isso é tão importante incluir, para que pela noção de representatividade, cada pedacinho da sociedade se sinta motivada a colaborar com novas ideias. Soluções essas que poderão ser usadas por todos.


É lacração? É vitimismo? É mimimi?

Continuar lendo

A importância do CheckList

Um checklist é uma lista de itens genéricos os quais podem conter dois estados: feito ou não feito. Esses itens podem estar relacionados à execução de algumas atividades(trabalho, estudo, academia, etc.) ou estar relacionados aos aspectos de um projeto ou de um elemento dele (inspeção de obras de construção civil, inpeção sanitária, etc.). Um checklist possui aplicação genérica, mas seus itens devem ser de domínio específico para que a lista faça sentido.

Nas atividades envolvidas no processo de desenvolvimento de software, os checklists servem de guia na construção de alguma tarefa ou podem servir de guia na revisão de uma tarefa ou artefato. Para a atividade de revisão de projeto arquitetural, por exemplo, um checklist pode conter itens com os temas de: corretude, coesão entre componentes, reuso, manutenção, entre outros. Já para a atividade de codificação, eles devem apresentar itens com os temas correspondentes à: cobertura de funcionalidade, análise ciclomática, presença de bugs e warnings, aspectos de refatoração, etc.

Quando aplicado sobre a atividade de teste de sistemas, um checklist pode estar integrado no processo de verificação(revisão de produtos de trabalho – casos de uso, projeto de sistemas, glossários, etc.) e validação(execução dos testes de pré-homologação, execução dos testes de aceitação, entre outros). Se relacionado com a atividade de pré-homologação, ele deve conter itens relacionados às várias visões de análise a ser consideradas no teste. Exemplos de análise interna são: observar corretude do código-fonte e testes unitários, validar estrutura das tabelas e consistência dos dados mantidos na base de dados. Exemplos de análise externa são: verificar layout da aplicação, corretude dos fluxos de operação do sistema.

Esses são alguns passos para escrever um checklist:

  1. Escolher um domínio de aplicação (ex.: testes de software);
  2. Traçar os aspectos de análise/confecção importantes (ex.: executar testes funcionais sobre o projeto X.);
  3. Definir seções para o checklist, ou seja, os blocos de interesse pelos quais ele será dividido (ex.: usabilidade, acessibilidade, desempenho, etc.);
  4. Escrever os itens/perguntas relacionados(as) às seções (ex.: usabilidade – os botões de submissão de formulários estão em evidência? A tecla <enter> possui efeito de submissão de formulário?)

No momento da execução dos checklist, todos os itens devem ser avaliados para que o resultado seja considerado satisfatório ou não. Por esse aspecto, ele constitui também um artefato de validação de qualidade ou acertividade. O checklist é uma ferramenta simples, porém poderosa, se aplicada de forma eficaz sobre um domínio ou tema de interesse.

Fica a dica! 😉