O processo de Significação Durante o Design do Sistema

Os problemas detectados durante a aplicação das técnicas de design participativo PHE (Participatory Heuristic Evaluation) e Conferência Semiótica foram classificados em dois grupos: (1) orientado a produto que enfoca o artefato de software e (2) orientado

a processo que enfoca o processo humano para o qual o artefato computacional pretende

dar suporte (Floyd, 1987; Mahemoff e Johnston, 1998; Müller e outros, 1995,1998). Embora não seja objetivo desta tese comparar a Conferência Semiótica e o PHE, nós podemos dizer que as duas técnicas têm naturezas diferentes e uma complementa a outra no SPaM. Enquanto o PHE tem seu foco na interface do usuário (contribuindo mais para a segunda fase do SPaM) e indicando principalmente problemas orientados a produto, a Conferência Semiótica é mais orientada a processo, apontando problemas e oportunidades para o aprimoramento no ambiente de trabalho da organização através do design e uso do sistema.

Em uma análise sobre o design do sistema Pokayoke, identificamos que a Conferência Semiótica (considerando todas as modificações propostas para os modelos ou protótipos durante todo o tempo do design) indicou um total de 39 problemas não redundantes. Dezenove problemas tiveram o foco principal no produto, problemas que foram descobertos enquanto os participantes discutiram soluções alternativas nas telas dos protótipos para refletir alterações nos diagramas de ontologia e normas associadas a eles. Por outro lado 20 problemas tiveram como foco principal a visão de processo; estes problemas foram descobertos, principalmente, durante discussões sobre o contexto organizacional e a sua relação com o sistema computacional.

Algumas atividades de avaliação são necessárias para engajar o grupo em um processo de significação sobre os elementos que envolvem o design do sistema com o objetivo de “informar” o design da interface. Desta maneira analisamos os problemas e identificamos um grupo especial de problemas orientados a processo que estavam fortemente relacionados ao processo de significação.

A principal característica destes problemas é que eles viabilizam a aprendizagem mútua, visto que eles resultam em possibilidades de aprimoramento no contexto organizacional, identificadas pelos trabalhadores durante o design do sistema, ou são

resultados da falta de compreensão das práticas de trabalho pelos designers do sistema (design aprendendo sobre o contexto). No primeiro caso os problemas identificados resultaram em modificações no sistema ou no contexto organizacional. Estas modificações são propostas pelos usuários com o objetivo de revisar ou criar novas práticas de trabalho. Esta é a parte do processo de significação pelo qual os usuários aprendem sobre as possibilidades trazidas pela tecnologia, através da avaliação de modelos e protótipos. O segundo caso, no qual os conceitos da prática de trabalho são mal compreendidos pelos designers, também é parte do processo de significação em que os designers aprendem sobre o contexto de trabalho.

Para ilustrar este processo nós apresentamos os problemas identificados durante o design do sistema Pokayoke que resultaram em discussões mais profundas sobre o contexto organizacional futuro e o design do sistema:

• “Quem pode emitir um cinco passos?” Somente os trabalhadores do departamento de qualidade até então podiam emitir um novo problema segundo o procedimento de “Cinco Passos”. Após discussões, designers e o pessoal do departamento de qualidade chegaram ao consenso de que todos os departamentos deveriam emitir seus próprios “Cinco Passos”. Também foi discutida a estratégia adotada para disseminar a cultura da resolução sistemática de problemas utilizando o procedimento de “Cinco Passos”;

• “O formulário de avaliação não é sempre preenchido” (o formulário de avaliação apresenta detalhes do problema no momento em que ele ocorre). Os designers tinham entendido que os formulários de avaliação eram sempre preenchidos, mas em algumas situações específicas eles não eram preenchidos pelos trabalhadores. Uma discussão a respeito do contexto organizacional clarificou os designers a respeito deste problema;

• “Os diagramas de Ishikawa, cinco porquês e as ferramentas de Brainstorming

são utilizadas somente durante alguns passos específicos”. Nos modelos e

protótipos anteriores, estas ferramentas não foram associadas com passos específicos no processo de resolução de problemas. Os modelos e o sistema foram alterados para dar suporte a idéia de que estas ferramentas deveriam ser

utilizadas somente durante alguns passos específicos. Esta discussão corrigiu alguns aspectos mal interpretados pelos designers;

• “Nós temos que definir os papéis para a pessoa que abre e para a que

coordena o processo de resolução de problemas.” Durante a Conferência

Semiótica, os trabalhadores entenderam que eles não tinham regras bem definidas em relação às responsabilidades no procedimento de “Cinco Passos”. Eles enfatizaram a necessidade de defini-las o quanto antes. Todos os participantes discutiram as normas de responsabilidades durante alguns encontros. Eles estabeleceram nomes para cada papel desempenhado na resolução de problemas; alguém deveria ser o responsável por abrir o “Cinco Passos” (inclui-lo no sistema) e por conduzir o passo um e cinco, e outra pessoa deveria ser responsável pelas fases de correção (passos II, III, IV). Novas práticas foram adotadas na fábrica como um resultado desta discussão, mesmo antes que o sistema fosse utilizado em larga escala;

• “O responsável pelo passo não é o responsável pelas ações.” Novamente uma discussão a respeito da responsabilidade, porém agora com foco em quem deveria ser o responsável pelas ações. O conceito de “responsável pelas ações” foi clarificado. Novas práticas foram adotadas na fábrica como resultado desta discussão, mesmo antes que o sistema fosse utilizado em larga escala;

• “Nós temos diferentes versões de cinco passos para cada parte da fábrica.” A organização em que nós trabalhávamos possui três “plantas” divididas de acordo com a produção. Conforme mencionado anteriormente cada uma delas tinha um procedimento de “Cinco Passos” diferente; algumas diferenças apareceram durante a Conferência Semiótica. Um padrão comum foi definido para todas as “plantas”;

• “Após o diagrama de Ishikawa nós queremos fazer um cinco porquês.” O sistema até então não previa a ferramenta de “Cinco Porquês”. Isso resultou em modificações no modelo do sistema que foi resultado de uma discussão a respeito da necessidade da ferramenta conhecida como “cinco porquês”. Esta discussão resultou em uma melhor compreensão por parte dos designers do sistema, de como esta ferramenta é utilizada na prática;

• “O responsável (quem emitiu o passo) é quem escolhe os trabalhadores que

irão compor o time multifuncional.” Outra discussão sobre a responsabilidade

foi conduzida com o objetivo de estabelecer normas de responsabilidades e deveres para o “responsável” e o “responsável pelo cinco passos” durante o processo de resolução;

• “A definição do que deveria ser implementado para corrigir o problema

ocorre no quarto passo.” Outro aspecto sobre as práticas de trabalho que havia

sido mal compreendido pelos designers. Uma discussão a respeito do que deveria ser feito no terceiro e no quarto passos foi conduzida com o objetivo de clarificar as práticas de trabalho;

• “O gerente de qualidade deverá verificar todos os cinco passos” Os participantes entraram em uma discussão a respeito do papel do gerente da qualidade; após uma discussão foi detectado que ele deveria ser responsável por verificar todos os “Cinco Passos”;

• “Como fazer auditoria neste novo contexto.” Os trabalhadores perceberam que as regras para auditoria não existiam no modelo do sistema. Os trabalhadores discutiram como fazer esta tarefa utilizando o sistema e foram levantadas novas possibilidades para conduzir esta tarefa da maneira mais simples possível.

Conforme destacado, as discussões que surgiram durante a aplicação do SPaM, particularmente as que ocorreram durante a aplicação da Conferência Semiótica (que contribuiu com oito das doze situações exemplificadas acima), promoveu uma compreensão compartilhada dos signos presentes nas práticas de trabalho. Desta maneira, estas discussões contribuíram para a aprendizagem mútua durante o processo de design.