Universidade Federal do Rio Grande do Sul (UFRGS) Aline Vieira Malanovicz; Ângela Freitag Brodbeck RESUMO

Tamanho: px
Começar a partir da página:

Download "Universidade Federal do Rio Grande do Sul (UFRGS) Aline Vieira Malanovicz; Ângela Freitag Brodbeck RESUMO"

Transcrição

1 ENTENDIMENTO COMPARTILHADO ENTRE USUÁRIOS E DESENVOLVEDORES SOBRE DEMANDAS DE SISTEMAS DE INFORMAÇÃO SEGUNDO O MODELO DE ORGANIZAÇÃO COMO PROCESSO DE WEICK: UM ESTUDO EMPÍRICO EM UMA EMPRESA DE SERVIÇOS Aline Vieira Malanovicz; Ângela Freitag Brodbeck Universidade Federal do Rio Grande do Sul (UFRGS) RESUMO Este trabalho objetiva investigar a contribuição do modelo de organização de Karl Weick como fundamentação teórica para o processo de entendimento compartilhado entre usuários e desenvolvedores sobre demandas de sistemas de informação. Considera-se o desenvolvimento de software como um serviço, e o modelo processual de Weick fundamenta o argumento de que o entendimento compartilhado das demandas resulta de um processo de organização entre os atores para a redução ou eliminação da ambiguidade das informações, de modo que a compreensão das demandas faça sentido para todos. Propõe-se aqui uma pesquisa exploratória, que busca compreender o processo segundo a percepção dos entrevistados. São realizadas Entrevistas Semiestruturadas com usuários e desenvolvedores de sistemas que atuam em uma empresa de serviços. Uma Análise de Conteúdo procura identificar indícios de elementos do modelo processual de Weick, na percepção dos atores sobre situações de sua prática profissional diária. Como resultado, percebe-se que o modelo processual de organização de Weick pode constituir uma lente teórica promissora para a compreensão deste processo quando tratado como um serviço. O modelo também parece contribuir para a Ciência de Serviços por ter potencial explicativo para outros serviços definidos com base na dualidade cliente-fornecedor. Como contribuição gerencial, espera-se que esta maneira de ver o processo proporcione uma compreensão mais ampla e mais aprofundada para os gerentes de projeto, desenvolvedores e usuários, que possa auxiliar no sentido de solucionar os frequentes problemas de entendimento que ocorrem na fase de levantamento e análise de requisitos de software.

2 Palavras-chave: desenvolvimento de sistemas como serviço; entendimento compartilhado entre usuários e desenvolvedores; modelo de organização de Karl Weick. INTRODUÇÃO A Ciência de Serviços é a disciplina que estuda sistematicamente serviços e sistemas de serviços, organizando o arcabouço científico para serviços e sistemas de serviços e possibilitando melhorias na eficiência e na qualidade de serviços fundamentadas em métodos acadêmicos e cientificamente testados e comprovados (PINHANEZ, 2009). Para o desenvolvimento e aplicação de pesquisas do campo de conhecimento da Ciência de Serviços, assim como para a maturidade da área como ciência propriamente dita, um tema de investigação que vem alcançando relevância refere-se aos desafios da adequada fundamentação teórica e conceitual dos trabalhos de pesquisa na área (KON, 2004). Em artigos científicos que abordam temas da área de Serviços, percebe-se a preponderância de abordagens comuns das Engenharias, na Administração e de outros campos científicos mais aplicados do que teóricos. O mesmo vale para a maioria dos livros-textos dedicados a esta área do conhecimento (BATESON; HOFFMAN, 2001; LOVELOCK, 2004; RANGEL, 2005; GIANESI; CORRÊA, 2008). Entretanto, também é possível perceber o potencial de contribuição de abordagens de outras áreas do conhecimento, como a Economia, a Sociologia, a Psicologia, a Comunicação, e outras investigações dos chamados Aspectos Humanos e Sociais (PINHANEZ, 2009). Considerar o desenvolvimento de software como um serviço prestado permite aos investigadores a fundamentação do tema utilizando conceitos próprios da Ciência de Serviços. Essencial para a compreensão do processo de desenvolvimento efetivamente como serviço é a noção da Dualidade Cliente-Fornecedor, que caracteriza as atividades de serviços (SAMPSON, 2000). Tal aspecto fica claramente exemplificado no processo de Levantamento e Análise de Requisitos de Software, que é a fase em que os desenvolvedores/analistas de sistemas procuram estabelecer um entendimento compartilhado sobre as necessidades dos usuários para um sistema (PRESSMAN, 2006). Entretanto, a prática profissional de gerentes e desenvolvedores aponta que são frequentes os problemas de compreensão das demandas. Da perspectiva gerencial, se destaca uma questão prática sobre como melhorar a eficiência do processo de entendimento compartilhado entre usuários e desenvolvedores, segundo o qual as necessidades dos usuários são adequadamente compreendidas (TAN, 1994) e então traduzidas para modelos de requisitos dos sistemas de informação. Mesmo após décadas de pesquisa 2

3 sobre melhoria do levantamento de requisitos (ACKOFF, 1967; GUINAN et al., 1998), uma comunicação pobre ou propensa a erros entre usuário e analista ainda é um dos principais problemas (BYRD et al., 1992; PORTELLA, 2009), e a questão permanece carente de uma fundamentação teórica que contribua para a compreensão da dinâmica do processo. Nesse sentido, para o conhecimento, delineamento e desenvolvimento da Ciência de Serviços, o aspecto da fundamentação teórica e das perspectivas metodológicas das pesquisas realizadas neste campo do conhecimento adquire relevância cada vez maior (KON, 2004). Na tentativa de ajudar a estabelecer uma consistente base teórica para trabalhos acadêmicos que tratem do desenvolvimento de sistemas considerado como serviço, o tema é aqui abordado em busca da compreensão da dinâmica do entendimento entre usuários e programadores, investigando um corpo teórico que se mostre uma alternativa útil para fundamentar a dinâmica do processo. Pelo fato de o conceito de sistema permear todo o processo de desenvolvimento de sistemas de informação, a Teoria Geral de Sistemas foi buscada como base explicativa inicial. A partir dela, teóricos de diversas áreas da ciência propuseram expansões. Um exemplo de modelo de relacionamentos intersubjetivos processuais sistêmicos de Psicologia e Teoria Organizacional é o modelo de Karl Weick, segundo o qual uma organização pode ser definida por seus processos de formação: os comportamentos interligados e relacionados que formam um sistema (1973, p.90). O modelo de Weick utiliza o arcabouço teórico da teoria de sistemas e enfatiza as relações subjetivas interpessoais, oferecendo aos pesquisadores e gestores uma alternativa processual para compreender aspectos não estáticos da dinâmica das organizações. Este trabalho tem como objetivo investigar a contribuição do modelo de organização de Karl Weick como fundamentação teórica para o processo de entendimento compartilhado entre usuários e desenvolvedores sobre as demandas dos sistemas de informação. Para tanto, são apresentados os conceitos referentes ao processo, e o referencial teórico que descreve o modelo de organização de Weick, e são esboçadas proposições que fundamentam a possível aplicação do modelo ao processo em questão. É então realizada uma pesquisa aplicada, com envolvimento dos atores e detalhamento do contexto em que estão inseridos, numa empresa de serviços que apresenta uma parceria entre a área de tecnologia e a de negócios. A técnica de entrevistas semiestruturadas é utilizada para identificar, na percepção dos entrevistados, como é o processo de entendimento das necessidades dos usuários e demandas dos sistemas por parte dos desenvolvedores. As questões procuram captar indícios de cada elemento do modelo de Weick, e uma análise de conteúdo das respostas verifica a possível aproximação da descrição empírica do processo às proposições teóricas derivadas do modelo. 3

4 1. DESENVOLVIMENTO DE SISTEMAS DE INFORMAÇÃO COMO SERVIÇO Nesta seção, é apresentada uma breve revisão da literatura sobre o tema Sistemas de Informação, sua abordagem como serviço, e os problemas do seu desenvolvimento, que exige o entendimento compartilhado entre usuários e desenvolvedores a respeito das demandas. Um resgate conceitual relembra que, para Fitzsimmons e Fitzsimmons (2005), serviços como o desenvolvimento de sistemas de informação definem-se como um processo. Consistem em uma experiência na qual o fator tempo é importante, e há o envolvimento do cliente/usuário no processo, na condição de coprodutor. Nesse processo, a comunicação contínua entre o usuário e o desenvolvedor é necessária para a retroalimentação a respeito do rumo do desenvolvimento de cada sistema em cada etapa de sua produção (LOVELOCK, 1995). Quanto ao processo de desenvolvimento de sistemas de informação, este é um método de trabalho estruturado em etapas que objetiva produzir sistemas para uma aplicação em geral (PRESSMAN, 2006; SOMMERVILLE, 2007), os quais podem contribuir para a solução de determinados problemas das empresas (LAUDON; LAUDON, 2007). E o levantamento de requisitos é a fase do desenvolvimento em que o analista de sistemas tenta entender as necessidades dos usuários e da organização para um sistema particular (PRESSMAN, 2006). A transformação desse conjunto de necessidades em um modelo conceitual é a especificação de cada requisito, ou seja, cada condição ou capacitação que um sistema ou componente de sistema precisa atender, ou ter, para satisfazer um contrato, um padrão, uma especificação, ou outro documento formalmente estabelecido (IEEE, 2000). O desenvolvimento bem-sucedido de sistemas de informação depende imensamente da interação entre usuários e desenvolvedores ou analistas de sistemas (GREEN, 1989; SCHEGLOFF, 1991; TAN, 1994; SOUZA, 2008). Mas ainda há muitos problemas associados à falta de entendimento entre usuários e analistas ou desenvolvedores (ACKOFF, 1967; SCOTT, 1988; PORTELLA, 2009). Essencial para o processo é a necessidade de criar um entendimento compartilhado entre usuários e desenvolvedores (FREEMAN, 2004). O entendimento compartilhado acontece quando as pessoas se comunicam sobre um tema e têm o mesmo entendimento desse tema (TAN, 1994). No que tange às pesquisas sobre o tema, Teichroew (1972) apresentou a chamada original para melhorar a comunicação entre usuário e desenvolvedor, e essa necessidade permaneceu forte na pesquisa em desenvolvimento de sistemas (BYRD et al., 1992; GUINAN et al., 1998; FREEMAN, 2004), especialmente visando à criação do entendimento compartilhado entre eles (TAN, 1994; BUTTERFIELD, 1998; MARAKAS; ELAM, 1998). 4

5 Trabalhos recentes também reiteram a importância da interação e do entendimento entre os atores (BERTAGNOLLI, 2004; CUNHA; SOUZA, 2006; SOUZA, 2008; SCHREIBER; PINHEIRO, 2009; TAVARES; THIRY-CHERQUES, 2009), tanto para reduzir riscos de problemas no processo (LEOPOLDINO, 2004; SANTOS, 2004; PENAFORTE; FRANCO, 2009), quanto para alcançar maior eficiência, correção e eficácia nos sistemas (BOOCH; RUMBAUGH; JACOBSON, 2005; DE SORDI; SPELTA, 2007; LANA; MORAES, 2009). Entretanto, o enfoque dessas pesquisas é predominantemente pragmático, sem buscar uma explicação ou compreensão teórica do processo de entendimento compartilhado entre os atores. 2. MODELO DE ORGANIZAÇÃO COMO PROCESSO SISTÊMICO DE WEICK Pelo fato de o conceito de sistema permear todo o processo de desenvolvimento de sistemas de informação, a Teoria Geral de Sistemas foi buscada como base explicativa inicial do processo. Segundo essa base teórica, um sistema se define como um complexo de elementos em uma interação de natureza ordenada (BERTALANFFY, 1975). A Teoria Geral dos Sistemas, elaborada por Bertalanffy ( ), é uma concepção científica que permite o estudo dos fenômenos que constituem sistemas. Bertalanffy estudou principalmente os sistemas abertos que estão em constante intercâmbio com o meio (TRIVIÑOS, 1995). O enfoque sistêmico parte da ideia de que existem numerosas relações no interior do objeto que se estuda, mas que este também está ligado ao meio externo. Os sistemas vivos e os sistemas sociais (indivíduos ou organizações) são sistemas abertos, ou seja, interagem com o ambiente onde estão inseridos, via importação (input) e exportação (output). Eminentemente adaptativos, devem, para sobreviver, reajustar-se constantemente às alterações do meio. Dessa forma, a interação gera ciclos de realimentações (feedback) que podem ser positivas ou negativas, criando assim um equilíbrio (BERTALANFFY, 1975). Aplicações da teoria de sistemas à teoria da informação e às teorias das organizações produziram a noção de que a informação pode ser usada como medida de organização de um sistema social. O modelo de Karl Weick utiliza o arcabouço teórico da teoria de sistemas e enfatiza as relações subjetivas interpessoais, oferecendo aos pesquisadores e gestores uma alternativa processual para compreender diferentes aspectos não estáticos da dinâmica das organizações. Weick afirma que uma organização pode ser definida por seus processos de formação: os comportamentos interligados e relacionados que formam um sistema (1973, p.90). O modelo suplanta as tradicionais propostas estruturalistas, que deixam de lado aspectos fundamentais dos complexos sistemas organizacionais, como interações dinâmicas que neles 5

6 se estabelecem, e dimensões mutáveis, dinâmicas, ambíguas, ou inexatas (DAFT e WEICK, 2005). Weick concebe a dinâmica das organizações com base em características processuais, o que parece ser adequado para o estudo do desenvolvimento de sistemas de informação. Para Weick (1973), o processo de obtenção de coerência entre os membros caracteriza o ato de organizar e permite aos atores de uma organização fazer interpretações como sistema. O processo de formação da organização consiste na solução da ambiguidade num ambiente criado através de comportamentos interligados e incluídos em processos condicionalmente relacionados. [...] A formação da organização procura processar a informação e reduzir a ambiguidade de informações recebidas (WEICK,1973, p.91). Esses ciclos de comportamentos interligados são os elementos básicos dos processos que constituem qualquer organização, como é mostrado na Figura 1 e definido na Figura 2. Esses ciclos são formados por comportamentos repetitivos, recíprocos e contingentes, que se desenvolvem e são mantidos entre dois ou mais atores. [...] Supõe-se que a redução da ambiguidade seja uma atividade coletiva que conecta diferentes comportamentos (WEICK, 1973, p.91). Figura 1 O modelo de formação da organização (Fonte: WEICK, 1973, p.93) Elementos Indícios para uma Definição do Conceito de cada Elemento Referência Mudança Mudança que provoca ambiguidade na informação de fora do sistema, (Weick, 1973, ecológica (...) que é repentina, inesperada, inédita, e é recebida e enfrentada. p.79;95) Registro da Ambiguidade Processo de Criação Regras de reunião Processo de Seleção Escolha de ciclos Processo de Retenção Afastamento de ambiguidade Um item de informação contém várias possibilidades/suposições. É mais ou menos ambíguo, e sujeito a diferentes interpretações. [...] é registrada por aumento ou redução nas regras que são ativadas É a reflexão que escolhe e define mais precisamente certas partes da experiência passada [...] e gera a informação a que o sistema se adapta, e assim afasta uma pequena parte de ambiguidade. Regras de reunião são procedimentos ou guias usadas a fim de processar dados para uma interpretação coletiva, [...] meios pelos quais o grau de ambiguidade é registrado em qualquer processo O processo de seleção, via critérios estabelecidos pela experiência, separa a diversidade da informação ambígua, admite as partes que satisfazem os critérios e assim ordena a informação ambígua. Descoberta e a realização de um ou vários comportamentos recíprocos [...] Uma pessoa realiza uma ação, aceita ou modificada por outra pessoa, após o que, a primeira responde ao que a segunda fez. Processo de armazenamento [...] conserva rigidamente as variações escolhidas [...] integra itens novos com itens já registrados e, via reorganização, afasta ambiguidade criada por contradições. As várias possibilidades/suposições de um item de informação sujeito a várias interpretações são reduzidas e as propriedades duvidosas da mensagem ficam mais unívocas. [...] É uma atividade coletiva. Figura 2 Conceitos dos elementos do modelo de organização de Karl Weick (Weick, 1973, p.29;87) (Weick, 1973, p.69;92) (Weick, 1973, p.91;72) (Weick, 1973, p.92) (Weick, 1973, p.45;74) (Weick, 1973, 55;59;92) (Weick, 1973, p.29;91) 6

7 Para reduzir a ambiguidade, é preciso (WEICK, 1973, p.91): que a ambiguidade seja antes registrada e depois afastada. [...] As regras usadas para compor o processo de criação-seleção-retenção registram a ambiguidade; e os ciclos do processo de criação-seleção-retenção aplicados à informação recebida afastam a ambiguidade. [...] Esses ciclos comportamentais interligados se incluem em processos inter-relacionados que constituem um sistema. Ao propor seu modelo de organização, Weick explica que (WEICK, 1973, p.95): As ações estão associadas à criação, e as escolhas estão associadas à seleção; ambas estão nos ciclos escolhidos, que são formados por comportamentos interestruturados. Na criação, os ciclos adequados para esse processo referem-se a fazer, agir e realizar. A seleção refere-se a escolhas das ações anteriores que devem ser repetidas, reconhecidas e consideradas como experiência benéfica. Weick também define como é (criado) o ambiente de informação (WEICK, 1973, p.91): O ambiente de informação em que os processos de organização atuam é criado com base em interpretações retrospectivas de ações já feitas pelos atores de organizações. Eles separam partes de um contínuo de experiência em experiências discretas, o que produz a matéria-prima da formação da organização, e gera excesso de ambiguidade. [...] Cada ciclo comportamental interligado tem potencial para afastar certa ambiguidade, mas só quando vários ciclos diferentes são aplicados à informação que um grau suficiente de certeza é conseguido para que seja possível ação não ambígua. As relações entre os processos (ilustradas como setas na Figura 1), representam como os processos são determinados pelo estado das informações recebidas (WEICK, 1973, p.92). Quando se obtém informação a respeito da maneira de usar (enviar de volta ou enviar adiante) o conteúdo conservado, pode-se especificar a natureza das relações causais do envio da retenção para criação (WEICK, 1973, p.95). A complexa variação da ambiguidade na informação que constitui o ambiente é assim descrita: O grau de ambiguidade no ponto de partida da seta determina o grau de ambiguidade como informação ao processo, no ponto de chegada da seta. [...] De modo geral, tais relações são ligações causais diretas. Isso significa que [...] quando há muita ambiguidade, haverá menos regras para composição do processo; quando existe pouca ambiguidade, aumenta o número de regras; e as regras determinam o número de ciclos comportamentais de criação-seleção-retenção interligados que serão reunidos para o afastamento efetivo de ambigüidade quanto menos ciclos de criação-seleção-retenção, mais ciclos escolhidos (WEICK, 1973, p.94). Por exemplo (ver Figura 1): quanto mais mudanças ecológicas, mais ambiguidade (relação direta +/+, / ); quanto mais ambiguidade, menos regras de reunião (relação inversa +/, /+). Essas relações existentes entre os processos são os controles do sistema: um circuito que contém um número ímpar de sinais negativos corrige quaisquer desvios que possam surgir, mantendo-se em equilíbrio. Mas em um circuito que contém um número par de sinais negativos, seus desvios serão ampliados sem correção, tendendo à falta de equilíbrio (WEICK, 1973, p.82). 3. MODELO TEÓRICO E CONCEITUAL PRELIMINAR PARA A PESQUISA Uma contribuição preliminar deste trabalho é esta elaboração de enunciados para aplicação do modelo teórico sistêmico e processual de Weick como lente teórica explicativa do processo de entendimento compartilhado entre usuários e desenvolvedores sobre as necessidades e 7

8 demandas de desenvolvimento. Essa aplicação está resumida na Figura 3, que apresenta uma lista de proposições teóricas que fundamentam a pesquisa empírica realizada neste trabalho. Elementos Proposições para identificação empírica de indícios dos elementos do modelo Mudança Proposição 1: Uma nova necessidade de desenvolvimento de sistemas configura uma ecológica Mudança ecológica na organização de usuários e desenvolvedores. Registro da Proposição 2: A percepção de que a informação recebida e transmitida aos desenvolvedores Ambiguidade pode ter mais de um modo de entendimento configura o registro da ambiguidade. Processo de Proposição 3: Cada usuário e cada desenvolvedor cria o seu entendimento (interpretação, Criação sentido) da demanda para um sistema de informação. Regras de Proposição 4: Desenvolvedores e usuários usam procedimentos para estabelecer um reunião entendimento ou interpretação coletiva das informações trocadas (regras de reunião). Processo de Proposição 5: Cada desenvolvedor seleciona os modos possíveis de entendimento da Seleção informação segundo critérios da sua experiência individual e da experiência do usuário. Escolha de Proposição 6: Os desenvolvedores interagem com os usuários (escolha de ciclos), fazendo ciclos reconsultas necessárias para afastar ambiguidade da informação. Processo de Proposição 7: Cada usuário e cada desenvolvedor registra (processo de retenção) o seu Retenção entendimento da informação, mentalmente e em documentos ou artefatos. Proposição 8: O processo coletivo e interativo de reconsultas dos desenvolvedores aos Afastamento de usuários configura novo ciclo de criação-seleção-retenção, promove compartilhamento ambiguidade de sentidos, e reduz mais a ambiguidade da informação do que se não há reconsultas. Figura 3 Proposições para identificação empírica de indícios dos elementos do modelo Pode-se perceber que cada proposição refere-se a um elemento do modelo, e o enunciado da proposição está descrito de modo que o elemento possa ser identificado na prática, em relatos da fase de Análise de Requisitos, ao tentar-se estabelecer um entendimento compartilhado entre usuários e desenvolvedores sobre as necessidades de desenvolvimento. Entende-se que, para investigar a efetiva contribuição do modelo de Weick como conjunto teórico explicativo do processo, é imperativo unir à elaboração das proposições a realização de uma pesquisa aplicada, com o envolvimento dos atores e o detalhamento do contexto em que estão inseridos. MÉTODO A pesquisa realizada tem caráter exploratório e natureza qualitativa, para o entendimento de situações que necessitam de uma análise tanto descritiva quanto interpretativa (GIL, 2007). Este trabalho é a parte inicial de uma pesquisa mais aprofundada sobre o tema, e o cenário de estudo é uma empresa do ramo de serviços financeiros, peculiar por ter uma parceria entre desenvolvedores e usuários de sistemas (MORENO JR.; FERREIRA; CAVAZOTTE, 2009). 8

9 Elementos Questões para Entrevistas Mudança ecológica 1. Você poderia descrever uma situação comum em que surge uma nova demanda? Registro da Ambiguidade 2. Como você percebe quando uma necessidade ou demanda não ficou clara? Processo de Criação 3. Você elabora possíveis interpretações/cenários da demanda para si próprio? Regras de reunião 4. Como você organiza informações para resolver dúvidas com o desenvolvedor? Processo de Seleção 5. Quais são alguns critérios que definiram o entendimento de uma demanda? Escolha de ciclos 6. Em que situação se retoma a interação com o desenvolvedor para esclarecer a demanda? Processo de Retenção 7. Você registra o modo como o entendimento da demanda ficou estabelecido? Redução de ambiguidade 8. A interação usuário/desenvolvedor esclarece melhor o entendimento da demanda? Figura 4 Roteiro para entrevistas semi-estruturadas A coleta de dados incluiu entrevistas individuais com todos os usuários demandantes de desenvolvimento ou alteração de sistemas de uma área da empresa de serviços. As entrevistas semiestruturadas foram orientadas pelo roteiro apresentado na Figura 4, que inclui questões específicas para cada elemento do modelo. As entrevistas foram realizadas em outubro/2010, no horário e local de trabalho dos entrevistados. Com duração média de 30 minutos, incluindo a explicação dos objetivos da pesquisa (BAUER; GASKELL, 2002), foram gravadas, com autorização, transcritas e reenviadas a eles para confirmação das falas e revisão de linguagem. Caracterização dos Entrevistados A empresa do ramo de serviços financeiros (banco) em que atuam os entrevistados conta com 550 funcionários, e se estrutura em cinco superintendências, incluindo uma financeira. Esta é composta de departamentos contábil, financeiro, e de controle financeiro, o qual cadastra e acompanha a evolução das operações de financiamento contratadas conforme parâmetros de cálculo definidos pelo Banco Central do Brasil e processados por um sistema de informações. É a única área da empresa que apresenta uma parceria entre usuários e desenvolvedores de sistemas, com uma equipe de analistas de sistemas, subordinada ao departamento de tecnologia, mas dedicada ao desenvolvimento e manutenção exclusivos do sistema financeiro do banco, a qual realiza suas atividades na mesma sala da área financeira, ou seja, fisicamente junto à área de negócio. Id Sexo Equipe Tempo de empresa Id Sexo Equipe Tempo de atuação em desenvolvimento Tempo de empresa U1 F Cadastramento 29 anos D1 M Sis.Controles 15 anos 31 anos U2 M Controle Ativa 8 anos D2 F Sis.Financeiro 8 anos 5 anos U3 F Controle Passiva 3 anos D3 F Sis.Fórmulas 6 anos 3 anos U4 M Liberações 4 anos D4 M Sis.Fórmulas 8 anos 8 anos U5 F Cadastramento 27 anos D5 F Sis.Cadastros 24 anos 24 anos U6 F Gestão 6 anos D6 M Sis.Cadastros 31 anos 9 anos U7 M Gestão 34 anos D7 M Sis.Financeiro 35 anos 28 anos U8 M Financeiro 7 anos Figura 5 Perfil dos entrevistados, usuários e desenvolvedores que atuam na área financeira da empresa 9

10 Os quinze entrevistados (sete mulheres e oito homens), tanto usuários como desenvolvedores, trabalham na empresa há 15 anos em média (entre 3 e 34 anos), e os desenvolvedores atuam em desenvolvimento há 18 anos em média (entre 8 e 35 anos). Uma peculiaridade da empresa é o fato de ter passado dezoito anos sem realizar concurso nem contratar novos funcionários, por isso há hoje dois grupos distintos de funcionários em relação ao tempo de serviço na instituição: o dos novos e o dos antigos, como se observa no Tempo de empresa dos entrevistados na Figura 5: há um grupo com mais de vinte anos de empresa, e outro grupo com menos de dez anos de empresa. Tanto os usuários como os desenvolvedores atuam em diferentes equipes, ou subsetores desta empresa de serviços. ANÁLISE E DISCUSSÃO DOS RESULTADOS Para a análise dos dados, foram realizadas sequencialmente as três etapas básicas da Análise de Conteúdo, conforme orientação de Bardin (2004): a pré-análise, que é a organização do material; a descrição analítica, que é o estudo aprofundado e orientado, em princípio, pelas hipóteses e referenciais teóricos; e, a interpretação inferencial, onde a reflexão e a intuição alcançam maior intensidade, embasados nos materiais empíricos, estabelecendo relações. Uma classificação das falas das respostas das questões em conformidade com o elemento correspondente permitiu aproximar trechos que esclarecem e exemplificam um conceito, mas foram citadas como resposta à questão de outro. Foram categorizadas ideias coincidentes conforme os elementos do modelo, e foi elaborado um esquema de interpretação de acordo com seus conceitos. As entrevistas foram iniciadas com uma questão introdutória (BAUER; GASKELL, 2002) referente à Relação geral entre usuários e desenvolvedores. Quase todos os entrevistados abordaram de modo claro sua relação com o usuário e comentaram as vantagens da experiência de usuários e desenvolvedores no negócio e na tecnologia em uso. Também foram mencionadas vantagens da proximidade entre usuários e desenvolvedores, e da facilidade para reconsultas decorrente da parceria estabelecida nesta empresa de serviços foco do estudo, em que os desenvolvedores atuam na área de negócio junto com os usuários. Outra questão introdutória tratou do Processo em geral de entendimento entre usuários e desenvolvedores. As respostas de usuários e desenvolvedores configuraram narrativas da dinâmica do cotidiano, que parecem refletir a descrição do processo de organização de Weick (1973) aplicado à explicação da organização entre usuários e desenvolvedores no processo de entendimento entre eles sobre as necessidades, demandas e requisitos de sistemas. 10

11 Seria possível supor, conforme o modelo de Weick (1973), que o processo ocorre do seguinte modo: os usuários percebem uma demanda ou necessidade de desenvolvimento de sistemas (Mudança ecológica); caso essa necessidade não seja clara ou inequívoca, a percepção desse fato é chamada de Registro da Ambiguidade. Assim, cada usuário ou desenvolvedor formula (Processo de Criação) seu entendimento individual sobre a definição dos requisitos; avalia (Processo de Seleção) opções de especificação conforme critérios, regras e valores próprios; e verbaliza, escreve, ou implementa (Processo de Retenção) conforme esse entendimento. Com isso, usuários e desenvolvedores utilizam Regras de reunião para organizar as informações para essa seleção, e fazem uma Escolha de ciclos de reconsulta usuário/desenvolvedor para esclarecimento das demandas. E assim o processo como um todo promove o Afastamento da Ambiguidade da informação. O referencial teórico de Weick orienta a descrição analítica dos dados coletados, apresentada a seguir. Procura-se apresentar cada elemento do modelo, seguido da proposição teórica elaborada, complementada pelos indícios empíricos identificados nas falas dos entrevistados. Elemento 1: Mudança Ecológica Suponha-se uma mudança ou tendência de mudança, não muito bem definida, na configuração do ambiente organizacional, gerada por reguladores, fornecedores, concorrentes, clientes; esta seria uma situação de Mudança ecológica (WEICK, 1973, p.94). A adaptação desse pressuposto do modelo de Weick ao processo de estabelecimento de um entendimento compartilhado entre usuários e desenvolvedores sobre as demandas de sistemas gerou a seguinte proposição para o reconhecimento da Mudança ecológica nesse processo: Proposição 1: Uma nova necessidade de desenvolvimento de sistemas configura uma Mudança ecológica na organização de usuários e desenvolvedores. A Figura 6 mostra alguns indícios empíricos de Mudança ecológica coletados nas entrevistas, que evidenciam, no ambiente, mudanças que representam novas necessidades para sistemas. Sempre que tem um acordo pra ser cadastrado, e que não há previsão para aquele tipo de combinação [de parâmetros de cálculo] então são n casos diferentes que os analistas acham que o mutuário pode pagar deste jeito, ou daquele outro e vão desenvolvendo, dentro daquele contrato, umas coisas ( ) Por exemplo, eu pedi um procedimento de cálculo vincendo em que as parcelas pré-estabelecidas com vencimentos fixos deveriam partir de uma data no passado. Então esse foi um pedido não-usual ( ) Teve um caso ( ) Teve um que era meio-sac de seis em seis meses, meio-sac. Então, não tinha como tem uma fórmula pra SAC a empresa pagaria meio-sac. E então ( ) isso é uma situação nova. Não tem uma previsão dos procedimentos cadastrados na casa que tenham uma previsão de meio-sac. Então isso é uma situação nova que surge, uma necessidade nova. (U1) Tudo é baseado nas resoluções do BNDES ou do BACEN. (...) Também aconteceu comigo que eu tive que implantar uma nova unidade monetária, que o banco não utilizava, o INPC pro-rata. Tinha só o INPC cheio. (...) O que que se pediu ao desenvolvedor? Que criasse um programa para automatizar a atualização dessas cotações. (...) Bastou conversar, apresentar uma planilha em Excel. O pessoal entendeu rapidamente ali, e deu uma verificada na parte do cálculo matemático, e não houve problema. (...) Uma questão mais difícil [foi] uma repactuação de uma série de operações que contam com uma Equalização do Tesouro Nacional. (U2) Eu acho que a gente pode falar daquele negócio de se usar TJLP+1% ou SELIC para atualização dos valores, que foi uma coisa complicada, né? (...) Veio aquela carta do BNDES. (...) Foi uma situação que surgiu uma nova necessidade. (U3) 11

12 Era mais uma coisa que a gente identificava, ou eu mesmo identificava, e aí a gente arrumava. Alguns layouts de relatórios tavam eles vinham de um jeito, aí ficou excessivo de informações, muita informação. Aí no uso, a gente pode fazer diferente. E aí eu levava de volta. Ah, vamos fazer diferente isso aqui. (U4) Um caso que eu percebo assim, que foi pra melhorar o processo Por exemplo, a gente pegava o arquivo do BNDES, o [Sis.Controle] comparava com o nosso (o arquivo de cadastramento). Daí a gente via os erros, né?, e arrumava. E até foi uma ideia da [Usuária 6], de botar aquilo ali dentro no mesmo momento que a gente cadastra, que a gente confere os contratos do banco. ( ) Hoje nós olhamos o cadastro, temos que olhar o contrato, e já olhamos o BNDES. A coisa parece simples, mas facilitou muito a nossa vida, né? ( ) Mas é uma baita ferramenta tu poder comparar. É muito bom! (U5) Isso aconteceu também quando a gente alterou a taxa de juros, quando veio aquela resolução do BNDES, por exemplo que Ah, precisa alterar a taxa de juros. (U6) Um caso específico que não é mais atual, mas que ocorreu Quando foi implantado [pelo governo] o CPMF. (U7) Um caso que eu to fazendo agora: o recálculo da passiva do PRONAF. Então a chefia pediu e disse: Nós precisamos recalcular o PRONAF. (?) E aí? E aí eu tenho que correr atrás, porque isso não foi suficiente pra mim. (D1) Quando tem, por exemplo, determinações do Banco Central Quando vem Precisamos calcular o Bônus PGPAF Primeiro: Que diabos é o Bônus PGPAF? (D2) Uma forma que surgiu uma nova necessidade, que ocorre bastante, é com relação à interpretação de uma legislação Ocorreu aí, um tempo atrás, a questão do IOF (Imposto sobre Operações Financeiras). (D4) As demandas de desenvolvimento, elas chegam através da chefia, que recebeu alguma norma do Banco Central... Recentemente, a nossa chefia fez uma solicitação pra alguns financiamentos, o governo concedeu um benefício : poderiam pagar até uma data fixa após o vencimento, e não seria cobrada inadimplência. (D3) Às vezes, vem uma norma do BNDES, ou do Banco Central, principalmente nos financiamentos agrícolas, que têm a safra, a cada ano... Eles estão sempre modificando e incluindo um monte de coisa... Por exemplo, agora, eu to fazendo... um Relatório, para o BNDES, de Fiscalização da Conclusão do Projeto para o qual foi concedido um financiamento. (D5) Geralmente é por força de legislação ou de normas do Banco Central ou do BNDES. Quando o BNDES muda, a cada início de safra, mudam regras, né? Se criam mais linhas de crédito, algumas mudam suas características, tipo limites, percentuais sobre o empréstimo, essas coisas. (D6) Figura 6 Alguns indícios empíricos de Mudança ecológica Percebe-se que a maioria das Mudanças ecológicas citadas no caso foi referente à legislação ou a normas emitidas pelo Banco Central do Brasil, determinando novas condições de concessão e cálculo para os produtos da empresa, os financiamentos de médio e longo prazo. E outros casos surgem da percepção de oportunidades de melhorias no processo de trabalho. Elemento 2: Registro da Ambiguidade Pode-se supor que um ou mais usuários (ou instância reguladora, no caso) percebem ou criam uma demanda ou necessidade de desenvolvimento de sistemas, e comunicam-na aos desenvolvedores. Se esse enunciado sobre a demanda não é formal e inequívoco o suficiente para não permitir dúvidas para os receptores da mensagem (desenvolvedores), pode-se dizer que existe Ambiguidade. A proposição a seguir representa o modo como o Registro da Ambiguidade poderia ocorrer no processo de entendimento entre usuários e desenvolvedores. Proposição 2: A percepção de que a informação recebida pelos desenvolvedores pode ter mais de um modo de entendimento configura o Registro da Ambiguidade. A informação nova que vem do ambiente, em geral, não pode ser considerada inequívoca (WEICK, 1973), pois é capaz de gerar mais de um modo de compreender essas mudanças e suas consequências. Assim, pode-se dizer que essa informação apresenta algum grau de Ambiguidade, pois permite várias interpretações. A Figura 7 apresenta alguns trechos dos dados coletados nas entrevistas que podem exemplificar o Registro da Ambiguidade. 12

13 É comum os Contratos terem cláusulas meio ambíguas. ( ) Eu leio várias e várias vezes. (...) Na transcrição para o contrato final, que é o documento que vale para o público externo, aí a redação é um pouco precária (vamos dizer assim). (U1) Acho que seria importante destacar que é muito complicado, primeiro, entender a demanda! Eu faria essa observação. Tu pegas uma resolução do BNDES, uma resolução do BACEN ( ) Dificilmente vem, assim, uma fórmula É bem complicado. ( ) Tu começas a trabalhar procurando uma solução para aquilo, para como é que tu vais implementar aquilo, aí que tu descobres uma série de variáveis ali que às vezes não estão bem esclarecidas. (U2) Naquele caso, surgiu aquela carta do BNDES com termos difíceis. (...) À primeira vista, não tava muito clara. (...) Essa aí com certeza não ficou clara, né? (U3) Às vezes, sim, isso acontece. Acontece bastante até. (risos) ( ) Até hoje mesmo eu tava falando Não é falta de entendimento, é que às vezes a gente não consegue explicar direito (U4) Sim, normalmente, [o desenvolvedor] faz outras perguntas, e tu nota que ele tá confuso. ( ) Ou não ficou claro, ele não perguntou, e aí depois não fez o que a gente pediu. (risos) (U5) Às vezes, quando a gente faz uma reunião e conversa bastante sobre o assunto, a gente percebe na hora que ele não tá entendendo. ( ) Às vezes na conversa a gente já percebe que o negócio não tá ficando claro. Às vezes na reunião já dá pra perceber que não tá ficando claro. Isso já aconteceu de, conversando ou com vocês, ou com o [Desenvolvedor 7] e com a [Desenvolvedora 2], eu já percebi que Ah, não, não, não é isso., até a gente se acertar. (U6) É, como usuário, às vezes a gente nota que, pelo tipo de pergunta que o desenvolvedor faz, às vezes você conclui que ele não entendeu (...) Normalmente, a gente pode notar pelos questionamentos que ele faz. (U7) Ou quando vem o produto e não dá o resultado que a gente tá esperando. Porque a gente sempre faz o teste, né? Tipo: se não fecha um somatório, é um exemplo. (U8) O caso do PRONAF até que é o problema foi fácil recalcular o PRONAF Mas Como recalcular o PRONAF? tem muitas variáveis ali Pode ser de vários jeitos (D1) Quando vem uma definição como Precisamos calcular o Bônus PGPAF, primeiro: Que diabos é o Bônus PGPAF? Sempre fica com dúvida. Num primeiro momento, vai sempre ficar com dúvida (D2) Também essas demandas chegam através da chefia, que recebeu alguma norma do BACEN, que está obscura também. Não tá esclarecendo todas as possibilidades... Quando a gente vai colocar a mão na massa, começam a surgir dúvidas. (D3) Às vezes uma palavra pode não estar dando o significado completo do que a pessoa quer. Então ela fala uma coisa, e os outros entendem outra, e a pessoa acha que explicou bem, e às vezes não foi suficiente Até porque a Lei, a Norma, às vezes, ela não é tão específica assim, né? (D4) E acontece às vezes do usuário, ele não diz bem o que ele precisa... Às vezes, eles passam a impressão de que não sabem o que querem... Tem um exemplo daquele arquivo de informações para uma empresa parceira do Banco Ele tem uma definição, a definição não tava clara. (D6) Tem usuários que entendem e sabem o que que querem rapidinho, e tem outros que não sabem, não fazem nem ideia do que tão pedindo. (D5) Por exemplo, aqui já aconteceu de eu receber uma definição que diz assim: a taxa de juros deve ser cinco. Sim, mas Que taxa de juros que tá se referindo? Vale pra todas as linhas de crédito? Para alguma específica? Isso é taxa de juro de financiamento, ou é uma taxa de juro de alguma outra coisa? (D7) Figura 7 Alguns indícios empíricos de Registro da Ambiguidade Foram citados alguns exemplos de casos em que os entrevistados perceberam que uma demanda não ficou esclarecida, e em outros casos, foram esboçadas explicações para isso, tais como a indecisão do usuário, ou o não entendimento de expressões ditas, ou a obscuridade da norma, que concorrem para o não-esclarecimento e a imprecisão das demandas em geral. Percebe-se que o Registro da Ambiguidade ocorre com frequência, sendo citado por todos os entrevistados. Alguns citam inclusive exemplos de situações explícitas de Ambiguidade, em que uma demanda que lhes foi comunicada poderia ser interpretada de diversas maneiras. Vale registrar que indícios dos elementos Mudança ecológica e Registro da Ambiguidade foram citados nas mesmas falas pela maioria dos entrevistados, o que pode indicar sua relação. Elemento 3: Processo de Criação Supõe-se, assim, que a informação transmitida pelos usuários chega aos desenvolvedores de forma genérica demais para o seu entendimento, com tanta Ambiguidade (até mesmo por razões de desconhecimento de detalhes técnicos por parte dos usuários, o que é relatado como comum), que não permite aos desenvolvedores tomarem decisões bem fundamentadas para as ações. 13

14 Proposição 3: Cada usuário/desenvolvedor realiza o Processo de Criação quando representa o seu entendimento, interpretação, sentido, da demanda para um sistema de informação. No caso, se não há preocupação com a clareza da descrição para esclarecimento de demandas e efetiva compreensão dos desenvolvedores, há pouca redução de ambiguidade. O receptor da mensagem (desenvolvedor) dispõe apenas da informação ambígua, sem saber exatamente como implementar a demanda, porque parece haver mais de uma forma possível. Isso exige que os desenvolvedores disparem seu Processo de Criação para identificar as possibilidades de interpretação que lhes permitem adaptar-se ao novo ambiente de informação (Figura 8). Nesse processo de descobrir o que é a demanda, tentar entender, formar esse entendimento, ( ) a partir da conversa, leitura da regra, a busca e definição de critérios e variáveis envolvidas, e aí se partir para um modelo inicial, (...) E é a partir desse momento em que eu parto para essa elaboração, que eu percebo as dificuldades. (U2) Porque cada um pensa no seu ponto de vista, no seu setor, seu departamento, no que vai influenciar, né?, eu acho. (...) esse tipo de coisa de compreensão, porque é bem o tipo de coisa de cada um compreender, de interpretar. (U3) Sim, mais de uma solução. Várias soluções! ( ) Às vezes a gente pensa numa solução que não é tão fácil. ( ) Em geral eu chego com Ah, eu precisava da coisa assim. Aí a [Desenvolvedora 5], ela mesma sugere, vai se atualizando Ah, vou fazer assim. Aí no outro dia ela vem e: Ah, não ficou bom, vou fazer de outro jeito melhor. (U4) A gente pediu uma coisa pro [Desenvolvedor 1], ( ) que é gerar a consulta se já teve liberação, pra aparecer em algum lugar se já teve Liberação ou não. Porque às vezes a data de início de carência, no BNDES tá uma, e no nosso tá outra. Mas as duas estão certas, porque a Liberação saiu em determinado momento, e igual ela não vai calcular. ( ) Daí outra opção Poderia ser um botão. Pra nós daria na mesma. ( ) Aí [o desenvolvedor]: Mas não pode ser assim?, Pode. (U5) Sim, como usuário, o usuário tenta tenta!... apresentar todas as possibilidades que podem acontecer né? Ah, tudo que tem que ser feito em relação àquilo. ( ) Mas, muitas vezes, tem coisas que a gente não consegue prever, e o desenvolvedor acaba perguntando depois, né? Porque na hora que ele vai desenvolver é que ele vai perceber que ( ) Ah, não tinha pensado nisso Mas eu tento sempre pensar em todas as possibilidades. (U6) Eu acho que é importante também frisar qual é o produto que a gente espera. Qual é o resultado final que se deseja. (U7) Teve um trabalho que a gente pediu, pediu uma fórmula, analisou. Algumas coisas vieram fora da solicitação. E algumas, depois da análise, a gente também viu que devia ter solicitado de forma diferente. ( ) Mas a gente já tá preparado, né? Porque, como a gente trabalha o dia inteiro com a tarefa, já tá preparado para o que [o desenvolvedor] vai perguntar (U8) Eu consigo visualizar uma imagem A gente realmente visualiza (D1) Em geral, fica bem no ar, fica uma interrogação!... Eu fico pensando em que parte do sistema aquilo se encaixa (D2) Existe sempre mais de uma forma de se fazer as coisas... A gente imagina os casos, mas só na hora mesmo. (D3) Digamos, a nossa mente funciona por cenários, nós fazemos imagens Se tu tem, digamos, 45 cenários de situações com relação a um determinado cálculo, tu sempre vai tentar encaixar naquilo ali. (D4) Eu tento entender o que que tão pedindo... e depois eu vou encaixando naquilo que já existe... É a gente tenta montar ideias... Normalmente, a ideia que a gente cria, ou faz o esboço, normalmente fecha. (D5) São efetuadas interpretações/cenários da demanda... e se tenta sugerir possíveis soluções, se tiver. (D6) A gente sempre tem uma interpretação, forma uma ideia Eu faço as minhas interpretações, baseado no conhecimento que eu tenho da empresa, ou do sistema (D7) Figura 8 Alguns indícios empíricos de Processo de Criação Alguns indícios de Processo de Criação foram percebidos na forma dos termos: Elaboração, Ponto de vista, Soluções, Opção, Possibilidades, Imagem, Casos, Ideias, Cenários, Possíveis soluções, Interpretações, além da ideia de tentar encaixar a demanda a algo já elaborado e conhecido. Elemento 4: Regras de Reunião Exemplos de Regras de Reunião seriam procedimentos de tratamento da informação que permitem ao detentor da informação ambígua (o usuário ou o desenvolvedor) fazer escolhas e definições (WEICK, 1973). Por exemplo, critérios que regem com quem serão debatidos os aspectos de esclarecimento das demandas; quais critérios serão usados, e como os objetivos serão transmitidos ou informados para os demais atores envolvidos no processo. 14

15 Proposição 4: Desenvolvedores e usuários usam procedimentos para estabelecer um entendimento ou interpretação coletiva das informações trocadas (regras de reunião). A Figura 9 apresenta alguns indícios empíricos de Regras de reunião coletados nas entrevistas. É que ali, basicamente, o que eu faço segue um determinado padrão, né? de atualização monetária, juros, se são exponenciais ou não são, se são 365 por 365, ou se o ano é comercial. Então tudo isso já tá escrito ali no contrato, né? Então a gente faz um resumo e vai pro desenvolvedor: Olha, nós precisamos assim, assim, assim. (U1) Houve uma confluência. Houve uma reunião das ideias, para se definirem critérios. (...) Fazer com que esse modelo seja aceito. Isso é o mais importante. (...) Com todas as pessoas que estavam envolvidas com isso na época, isso foi muito debatido, e se chegou a essa conclusão. (...) Eu vou precisar de critério: qual é a data final, de que forma que a gente vai chegar àquele ponto (...) As memórias disponíveis, os campos, o formato, qual vai ser a resposta que tem que ser dada De onde é que virão as informações (U2) É muito fácil pra nós, porque nós estamos todos meio juntos, né? Mas poderia ter um jeito mais profissional (vamos dizer assim) de fazer isso pra uma solicitação pro [setor de informática], por exemplo, né? Tipo fazer um protocolo de demanda... tipo todos os setores envolvidos, todas as implicações... sei lá. (U3) Em geral é bem assim: eu chego com uma demanda e, ou o desenvolvedor implementa e depois sugere uma outra coisa, ou eu mesmo sugiro. No geral, tem sido assim. ( ) A gente precisava disso aqui. aí isso aqui dá pra fazer? dá. ( ) É, em geral assim, tudo dá pra fazer, tudo o que foi solicitado dava pra fazer. ( ) Na verdade, dá pra fazer, só que vai levar tempo. Então tá. Ela já identifica dá pra fazer assim, ou dá pra fazer assado (U4) Eu uso geralmente um exemplo. ( ) Eu acho que é a melhor coisa o exemplo. (U5) Ou quando a gente vai modificar um [Cálculo de Pagamentos/Recebimentos], por exemplo, daí aqueles testes: Ah, se pagar a menor, vai funcionar? O que tem que fazer?, Se pagar a maior, que que tem que fazer? Concede bônus ou não concede bônus?, Se pagar antecipado, o que que tem que fazer?, Se pagar antes do dia? Se pagar depois do dia? Tudo isso a gente tenta prever. (U6) (...) o desenvolvedor deve saber: Bem, para chegar naquele produto final, naquele relatório, naquele resultado, eu tenho que ter variáveis, às vezes até com cálculos, interferência de busca de arquivos em outros sistemas e coisa que o valha. (...) e pra ver Ó, eu vou pegar os dados daqui e daqui, vou fazer tal e tal coisa, e vou chegar lá., E isso fica mais claro também para o usuário. De onde estão sendo buscados os dados, o que vai acontecer, e que dados ele vai ter. (U7) Nesse trabalho aí, [o desenvolvedor] tava com várias dúvidas. E ele perguntava e a gente respondia. De vez em quando, a nossa resposta não era em consenso. Até a gente demorava um pouquinho pra chegar a Ah, não, melhor mandar pra tal pessoa., Ah, é tal pessoa que vai receber? (U8) Muitas vezes, eu consigo pegar um geral da ideia, mas falta mais Então daí eu volto: vem cá, é isto?, e vou montando um quebra-cabeça À medida que eles vão pedindo, eu vou fazendo e já vou mostrando Pergunto já com o cenário Acho que até dá trabalho a mais. Mas isso é até por falta do entendimento. (D1) Eu tento reunir a documentação que já existe sobre o assunto, alguma coisa parecida... A gente sempre tenta resolver as confusões se organizar pra esclarecer. Acho que estar próximo dos usuários facilita muito. (D2) Existe a volta de maneira bem informal mesmo, que a gente simplesmente chega ali na sala [da chefia] e diz Ah, eu pensei isto. Pode ser isto? Pode ser aquilo?... a gente coleta alguma informação... pra dar algum respaldo àquela dúvida. (D3) Por exemplo, se o usuário chega e diz que tem que fazer um cálculo de juros pra um período lá da carência, e ele só me diz isso. Aí, quando eu vou falar com ele, eu digo Olha, eu posso usar o cálculo com base em 360 dias, em 365 dias Se for um, vai dar este resultado, se for o outro, vai dar este resultado. (D4) Eu, normalmente, eu faço eu faço um esboço... do que já tem no Sistema, do que tem que ser alterado, ou que tem que ser criado... O que eu não sei, eu dou a ideia e coloco interrogações pra falar com quem sabe... (D5) As informações são organizadas... e retornadas para os usuários em forma de uma definição inicial da tarefa (minuta). Os pontos que não estão claros deverão ser ressaltados Quando uma necessidade não ficou clara... teria que relacionar os pontos, relacionar a dúvida, e fazer uma consulta (D6) Quando eu percebo que algo está duvidoso, eu anoto isso e esclareço. Uma vez esclarecido, aquele confirmando Conforme conversamos, ficou assim? E eu respondo perguntando: O que que tu quis dizer com tal frase?... Baseado em quê? Por quê? Nesta frase aqui, eu não entendi o que tu quis dizer.(d7) Figura 9 Indícios empíricos de Regras de reunião Percebe-se que, entre as Regras de reunião utilizadas e mencionadas pelos entrevistados, figuram práticas como apresentar uma ou mais possibilidades de entendimento, para o usuário determinar a correta e o desenvolvedor dizer se é possível, e indicar o que não está claro. Elemento 5: Processo de Seleção Pode-se supor que, quando os desenvolvedores procuram traduzir as demandas em protótipos ou especificações técnicas, produzem o sentido de sua tradução de maneira não consciente, selecionando aspectos conforme o seu próprio entendimento e a sua experiência. Nessa fase 15

16 da tradução, há um sério risco de uma transmissão com perda (ou alteração) de informação. O entendimento mútuo ficaria prejudicado se a ambiguidade da informação fosse resolvida por uma escolha de suposições que definem o sentido das diretrizes originais apenas para o desenvolvedor, pois partiriam da experiência e da compreensão da demanda somente dele. Proposição 5: Cada desenvolvedor seleciona os modos possíveis de entendimento da informação segundo critérios da sua experiência individual e da experiência do usuário. A Figura 10 apresenta alguns indícios empíricos de Processo de Seleção. E aí começaram os entendimentos com o Tesouro Nacional, porque não adiantava o banco desenvolver uma fórmula, achando que o seu critério era o correto, se o Tesouro dissesse outra coisa. (...) A partir daí, então, aquilo que eu te falei, questão do entendimento, primeiro entender o que é a demanda, a partir do momento em que se definiram os critérios Bom, é isto aqui que tem que ser feito. OK Conseguimos ter um convencimento dentro da casa, conseguimos ter um convencimento no Tesouro Nacional. (...) Depois de definidos os critérios, o Tesouro até colocou de uma forma bastante clara. (...) Então eles determinaram a maneira como aquilo devia ser calculado. (U2) Cada um vai pensar: um vai pensar quanto dinheiro tem envolvido, outro vai pensar quantas operações tem envolvidas, outro vai pensar quantas horas leva pra fazer isso, essas coisas... cada um vai pensar numa coisa diferente, eu acho. (...) É um entendimento de conjuntura, assim, do banco, de política, de, sei lá, porque a gente já sabe como é que o BNDES é, né? Mas o desenvolvedor não vai saber esse tipo de coisa. (...) Se ele é contador, ele vai interpretar conforme as coisas que vão implicar lá na contabilidade. (...) O analista de sistemas, ele tá pensando, a primeira coisa é criar, deixar registrado. O gestor já tá pensando na articulação, assim: isso vai impactar lá na contabilidade. (...) Eu acho que é bem assim: o setor que ele tá, o usuário, sei lá, o conhecimento técnico que ele tem, é o que vai influenciar o jeito como a pessoa vai interpretar. (U3) Um critério seria no retorno, na pergunta, quando ainda assim sobra alguma dúvida, a gente ou tenta discutir na hora, ou buscar a norma que vai dizer, né?, Alguma norma escrita, ou algum caso semelhante Ah, como é que a gente fazia naquele caso? Ah, então vamos fazer igual. Quando ainda resta confusão. (U6) Exatamente. Para ver se ficou claro, se é aquilo que o usuário quer, se é o que o desenvolvedor entendeu (...) para chegar mais próximo do que é a expectativa do usuário. (U7) Os usuários, as chefias, as chefias das áreas, no caso da financeira e da área de informática, participaram, a área de desenvolvimento, o desenvolvedor, e tal. ( ) A gente tá ciente do que a gente quer fazer. E a gente também justifica, economicamente, porque é que a gente tá fazendo isso aí. Que é importante mostrar quanto custa pro nosso bolso fazer desta forma, em horas trabalhadas, ( ) essas coisas. (U8) A gente toma por base aquilo que a gente já sabe Se eles vêm pedir pra gente, é porque ah, ele sabe da coisa e vai saber resolver, eles sabem do conhecimento que a gente já tem sobre aquele assunto. (D1) Em geral, são os usuários do próprio departamento, né? Quando é assim, geralmente tem uma boa definição. Os critérios, as regras, são ditos por alguém que entenda do negócio. Os critérios são registrados em s. (D2) No meu caso, eu tomo por base a experiência dos outros... As pessoas são o grande depositário de informações... O trabalho todo fica alicerçado no entendimento e no conhecimento informal que eles têm... A coisa fica num vai e volta até que alguém determina como vai ser... É o que parece mais coerente, né? (D3) O critério que define o entendimento e fica registrado é o da Instrução Normativa, da legislação, e o contrato Normalmente, quando tu tem uma situação nova, tu vai fazer uma associação com as coisas que tu já conhece Então, em cima da experiência que a pessoa já tem de casos positivos, ela consegue enxergar. (D4) Pra mim, no caso, eu acho até que é mais fácil porque eu conheço o sistema desde o início... Eu já sei as pessoas que podem ser consultadas... Se tem alguém que já tá acostumado, ele vai ler, vai entender e vai passar isso pra gente... A gente vai atrás de quem poderia auxiliar e dar mais um esclarecimento. (D5) Os critérios são definidos pelo usuário responsável. Na verdade, não é uma pessoa, são uma, duas, três, quatro, mais... Podem ser definidos de várias maneiras... E de modo geral, os critérios ficam registrados. (D6) Recebeu qualquer coisa de qualquer pessoa, leu, interpretou, entendeu, anota da forma como entendeu, anota as dúvidas, divide o problema e esclarece por partes (D7) Figura 10 Alguns indícios empíricos de Processo de Seleção Alguns dos entrevistados mencionam critérios para o Processo de Seleção baseados na sua experiência, no seu conhecimento, nas normas, nos custos, e na expectativa do usuário. Podese supor que, quando não há uma reconsulta ao usuário (ou novo Ciclo coletivo para o Processo de Seleção), pode ocorrer um processo não consciente de geração de ambiguidade (WEICK, 1973), entre o usuário e o desenvolvedor do sistema de informação. Essa perda de informação 16

17 na comunicação pode provocar uma discordância entre a demanda solicitada pelo usuário e a programação efetivamente implementada pelo desenvolvedor (O popular telefone-sem-fio ). Os entrevistados parecem considerar esse fato: entre os critérios que utilizam para ordenar a informação ambígua, destacam os benefícios da experiência, do conhecimento e do entendimento do negócio (tanto do desenvolvedor como do usuário). Para eles, tais fatores facilitam o entendimento das demandas e determinam a seleção da interpretação correta. Elemento 6: Escolha de Ciclos Pode-se supor que, num novo Ciclo realizado coletivamente entre os atores (WEICK, 1973), os usuários e os desenvolvedores avaliam conjuntamente (em um processo coletivo) as opções de interpretação elaboradas (Criação) e fazem coletivamente a Seleção das opções válidas. Proposição 6: Os desenvolvedores interagem com os usuários (escolha de ciclos), fazendo as reconsultas necessárias para afastar ambiguidade da informação. Um Ciclo de processo poderia ser exemplificado por uma reunião entre os usuários e os desenvolvedores. Os critérios de seleção são assim expostos pelos usuários, e a seleção de ações a tomar e objetivos a buscar é realizada em conjunto, em Ciclos de debate. É feita a exposição da ambiguidade identificada na informação do ambiente, e a apresentação do modo como cada um produziu o sentido dessa informação. Também é feito coletivamente o registro dos motivos, regras e critérios que levaram à seleção das opções de entendimento válidas. Em outras palavras, em vez de ativar regras de tratamento da informação (e já sair fazendo escolhas e definições), o desenvolvedor pode escolher realizar um novo Ciclo de tratamento da informação, voltando ao processo de Criação-Seleção-Retenção junto dos usuários. Assim, afasta ambiguidade suficiente para compreender melhor a demanda (WEICK, 1973). Assim, a Escolha de ciclos (Figura 11) é dada pela organização dos desenvolvedores em ações recíprocas de reconsulta aos usuários para seleção do correto entendimento da demanda. Quando tem o retorno, é que nós todos ficamos curiosos, pra ver se é tão complicado, que Bah, mas será que deu certo? Então é só isso, a gente volta a conversar, né? (...), daí a gente vai ver como é que ficou. ( ) Sempre, no dia seguinte, eu faço a revisão, pra ver se aquilo que o [Contrato] queria é o que tá refletido ali no [Sistema], ou na cobrança das parcelas se o cronograma tá correto. Isso aí a gente sempre faz. ( ) (U1) A gente faz e refaz, faz e refaz, até conseguir resolver tudo. (...) [Naquele caso], houve uma confluência, houve uma reunião das ideias, para se definirem critérios. (...) Com todas as pessoas que estavam envolvidas com isso na época, isso foi muito debatido, e se chegou a essa conclusão. (...) É assim que as coisas vão acontecendo. (...) Então isso aí é constante. Essa troca é constante. Nunca é um processo fechado. (U2) Então eu acho que essa interação, assim, durante, deve ser importante, principalmente se for um sistema mesmo... (...) Essa é uma coisa bem importante (...) que também depende do desenvolvedor. (...) Tipo: de ele não fazer tudo que pediram, né? De ele ir lá, fazer uma etapa, mostrar. Tá ficando bom? É isso que tu quer?, É.. (...) Eu to pensando, assim, numa coisa que tenha que mudar... Poxa, mas tu me disse que tu queria isto, sabe? Ah, pois é... faltou. (U3) A gente tá sempre trocando informação, né? Tá funcionando? Tá OK? e eu digo: Ah, tá. ou Ah, não tá. Sempre vou levando, tem coisa que pode melhorar ( ) E eu levo pra [Desenvolvedora 5]: Isto tá ruim. Ou Isto tá bom. (U4) [Naquele caso,] eu expliquei pra ele e, no começo, ele fez ( ) E aí deu uma confusão. Ele entendeu tudo bem ao contrário. mas depois ele ajeitou. Depois, nós conversamos pessoalmente. ( ) Quando ele veio aqui, daí a gente conversou ( ) Daí eu peguei um exemplo, mostrei. Fica mais fácil de entender. ( ) Daí depois disso, melhorou. (U5) A gente faz uma reunião e conversa bastante sobre o assunto ( ) A gente discute o que vai ser feito em si, e dali sai pra fazer. ( ) A gente conversou assim: Ah, vamos fazer isso, aquilo., Tá?, Tá. ( ) Isso já aconteceu de, 17

18 conversando ou com vocês ([Desenvolvedor 4], [Desenvolvedora 3], [a própria pesquisadora]), ou com o [Desenvolvedor 7] e com a [Desenvolvedora 2], eu já percebi que Dá pra fazer?, Ah, não, não, não é isso., até a gente se acertar. ( ) Muitas vezes, tem coisas que a gente não consegue prever, e o desenvolvedor acaba perguntando depois, né? Porque na hora que ele vai desenvolver é que ele vai perceber ( ) Porque o desenvolvedor, na hora que ele for realmente fazer, ele vai ter dúvida. E aí ele vai entrar em contato. (U6) Uma coisa que acontece, que a gente vê pela experiência de anos, que, às vezes, o próprio usuário não sabe bem o que quer. Então ele pede uma coisa, e depois que tem o resultado daquilo, ele diz Ah, mas podia ser diferente. (...) É Eu acho que uma boa prática, seria o seguinte: fazer uma primeira abordagem, uma primeira entrevista, e depois de algum tempo, (...) E discutir novamente, em outra oportunidade, com o usuário, pra ver: Ó, eu vou pegar os dados daqui e daqui, vou fazer tal e tal coisa, e vou chegar lá., E isso fica mais claro também para o usuário. (...) E para o desenvolvedor seria uma oportunidade de esclarecer alguma coisa que não ficou muito clara e tal e aí partir para a execução. (U7) Olha, normalmente quando o usuário ( ) gera críticas, algumas realmente tem que se refazer determinados parâmetros. ( ) Tá correto, mas não ficou E na hora da produtividade do usuário, da interação do usuário com o sistema, ele vai ver: Não, mas se este campo ficasse em primeiro lugar, já ia ficar mais fácil. Eu vou ver, fica muito mais produtivo. Então vale a pena chegar e devolver o produto pra um ajuste fino, né? (U8) A gente começa a montar e apresentar, e aí ele vai dizendo se tá certo ou não, se tá bom ou não À medida que eles vão pedindo, eu vou fazendo, e já vou mostrando Mesmo o usuário que apresenta já tudo pronto, às vezes no meio do caminho a gente pode dar uma ajustada, fazer algum ajuste que ele acha que é melhor. (D1) Quando fica ambíguo assim, a gente vai atrás pra saber: tem certeza que é isso mesmo que tu quer? Mas normalmente são feitas várias reuniões, definições A gente reconsulta o usuário, sempre Sempre tenta se organizar para esclarecer. Acho que estando próximo dos usuários, facilita muito. (D2) De maneira informal, sempre reconsultamos para checar se a solução está de acordo com o que se espera...temos que ficar sempre em contato com quem solicitou... A reconsulta é necessária! Já faz parte do processo. Várias reconsultas! (D3) O fato de a gente ter proximidade com eles nos facilita um monte a entender qual é a demanda, qual é o motivo, ou qual é o critério, porque eles estão no nosso lado Se o cliente, o usuário, pede uma coisa As pessoas acham que entenderam tudo E é implementado dum jeito E se, quando ele vai ver o resultado Ah, mas não era isso que eu queria! Então vai vir uma nova necessidade Aí tem que pegar e refazer (D4) Tem que ser assim: se faltou alguma coisa, se não tá claro aquilo ali que eu escrevi, ou se o que eu criar não atende, a gente sempre vai aceitar a sugestão de quem tá usando e reelaborar... Eu reescrevo a definição, ou complemento a sugestão. (D5) À medida que o desenvolvimento vai andando, as partes vão ficando prontas, deve-se chamar o usuário e mostrar: É isto mesmo? Eu entendi isto? Tá escrito isto. Foi o que eu entendi. Vamos mostrar o produto. Pelo menos as partes dele Essa é a grande vantagem dos que trabalham aqui, na área que atendem. (D7) Figura 11 Alguns indícios empíricos de Escolha de ciclos Percebe-se que os desenvolvedores elaboram a definição ou protótipo ( as partes vão ficando prontas ) do jeito que entenderam ( foi o que eu entendi ), e optam por checar se a solução está de acordo com o que se espera. Frente à Escolha de Ciclos de reconsulta ao usuário, se o que eu criar não atende, então a reação do desenvolvedor inclui dar uma ajustada, pegar e refazer. Vale ressaltar a menção da proximidade entre usuários e desenvolvedores (no caso em estudo) como grande vantagem, facilita muito, facilita um monte a entender qual é a demanda. Elemento 7: Processo de Retenção Pode-se supor que a maior parte da ambiguidade da informação foi afastada na fase do Processo de Seleção. Essa informação conserva apenas pequena quantidade de ambiguidade quando chega ao Processo de Retenção. Então, há ativação de várias regras e seleção de poucos ciclos (WEICK, 1973, p.94). Isso gera o afastamento de pouca ambiguidade, quase apenas registrando os critérios adotados e o modo como a demanda ficou entendida. Conserva-se, então, a maior parte daquela pequena quantidade de ambiguidade que o item já tinha originalmente quando atingiu o Processo de Retenção (WEICK, 1973, p.94). Proposição 7: Cada usuário e cada desenvolvedor registra (processo de retenção) o seu entendimento da informação, mentalmente e em documentos ou artefatos. 18

19 Um Processo de Retenção da informação na organização pode ser exemplificado pelo registro das decisões dos usuários e dos desenvolvedores em documentos de projeto, ou em protótipos iniciais, para fins de entendimento das demandas e especificação do sistema. Neste processo de registro, o afastamento da ambiguidade depende da clareza na descrição das decisões. O registro dos modos como o entendimento da demanda ficou estabelecido, referente ao Processo de Retenção (mostrados na Figura 12), e a identificação de critérios, referente ao Processo de Seleção, também aparecem nas mesmas respostas na maioria das entrevistas (quando fica bem compreendida a questão proposta sobre o Processo de Seleção). Tudo já tá escrito ali no contrato, né? Então a gente faz um resumo e vai pro desenvolvedor. (U1) Com certeza. Isso aí a gente fez. Houve algumas alterações, mas como a, digamos assim, a fórmula que veio, a determinação veio de uma forma bastante clara (...) Então, a partir do momento em que o Tesouro colocou um comunicado ( ) Tem registro sim. Houve bastante trabalho na época. ( ) Foi o [Desenvolvedor 4] que trabalhou muito nisso, então com certeza ele tem muita documentação. (...) Com certeza tem. (U2) A [Desenvolvedora 5] se preocupa muito em escrever as coisas no , né?, pra deixar registrado. Eu acho legal, sabe? (...) A gente deveria ter, assim, um padrão. A gente tem muita coisa informal, assim. (...) Deveria ter uma coisa assim, mais formalizada, eu acho. (...) Mas esse negócio do entendimento, (...) eu não tenho absoluta certeza se ele entendeu bem o que eu queria, né? Mesmo registrado, talvez eu já não tenha, né?, porque sempre é uma coisa muito de entendimento, né? É complicado. Mas eu acho que o nosso é bem informal. (U3) Sim, a [Desenvolvedora 5] tem uma listinha de tudo. Tanto que ela vai e cavouca: Ó, tá aqui, ó! (risos) ( ) Mas até, muitas vezes, quando o usuário recorre ao desenvolvedor, ele tá com a corda no pescoço, né? ( ) Tem épocas do mês que não dá pra parar. (U4) O registro final eu acho que até acontece mais do que o registro da decisão, né? porque eu acho até que [os desenvolvedores] registram mais o que modificam no sistema, daí fica registrado. ( ) É mas não tanto da decisão (...) do como fazer, quem estava presente, quem decidiu, isso a gente não tem muito registrado. (...) Deveria. A gente tá tentando. Um dia a gente chega lá! Mas na correria do fazer (...) Ah, decide, conversa, tá, então vamos fazer! e sai fazendo, né? Mas deveria ter sempre essa etapa prévia de registrar. (U6) Esse registro é mais de memória. Mas eu acho que seria importante. Talvez naquela segunda reunião escrever, ter a concordância dos dois lados, para que fique claro. Foi isso que foi tratado, e isso que foi pedido, e era a proposta. (U7) A maioria das definições e tal, elas ficam nos s. Geralmente é no , mas memorando a gente não usa Eu recebi um do desenvolvedor do produto. Vou marcar uma reunião com o colega amanhã, para a gente afinar melhor o produto. Mas por . Tá registrado ali que a gente tá marcando. (U8) Aí a gente começa a montar e apresentar, e aí ele vai dizendo se tá certo ou se não tá, se tá bom ou não. (D1) A gente registra normalmente num documento, uma versão inicial do projeto (a gente chama de projeto ). E vai fazendo várias versões (001, 002, 003, ), até chegar numa versão final E o que fica pra ser definido fica em vermelho, com uns pontos de interrogação. E a gente vai sempre fazendo as alterações. (D2) Eu crio blogs para registrar cada coisa que eu faço, para poder retomar o desenvolvimento no outro dia. (D3) Eu acho que às vezes a gente faz uma Ata das coisas E eu acho que muitas dessas mudanças de entendimento, às vezes também não ficam registrados Só que seria bom fazer Quanto mais registro, melhor, né? (D4) Eu anoto, coloco assim: a data,..., às vezes, quem solicitou, o documento normativo, a pessoa, e também quem definiu e quem solicitou... E esclareço, e aí eu vou pra definição de novo, vou de novo pra essa definição pra onde tem os pontos de interrogação... A primeira versão, depois mais uma, e mais uma. (D5) É efetuado o registro em forma de uma definição da tarefa (ou projeto). As informações são retornadas para os usuários em forma de uma minuta, ou esboço do projeto. A gente deixa na versão tal Se tem coisas a definir Ela vai ter coisas a definir, geralmente em uma outra cor e tal para que quem olhe saiba (D6) Conversa-se, anota-se, conversa-se, esclarecem-se todas as dúvidas, se reescreve tudo num documento, se manda para todas as partes envolvidas, confirmando se é exatamente isso ou não... É muito comum, a [colega] me perguntar: Por que que foi feito isso? Aí eu vou lá nos meus s e pesquiso: Ó: tá aqui. Isso foi feito em tal data, por tal motivo, por solicitação deste ou daquele, de alguém. Então tem onde pesquisar o passado. Eu sou muito fã de documentação. (D7) Figura 12 Alguns indícios empíricos de Processo de Retenção Os entrevistados percebem a informalidade dos registros de algumas decisões, mas é habitual a definição de requisitos, com alto grau de detalhe, elaborada pelos desenvolvedores a partir do entendimento das demandas. É com base nela que são desenvolvidos os sistemas. Com isso, pode-se entender que tanto as decisões, como as definições, como o próprio sistema ou protótipo desenvolvido configuram o registro das opções de entendimento escolhidas. E as 19

20 versões de documentos e protótipos representam o Processo de Retenção, que integra itens novos a itens já registrados e reorganiza possíveis contradições (WEICK, 1973, p.92). Elemento 8: Afastamento de Ambiguidade Proposição 8: O processo coletivo e interativo de reconsultas dos desenvolvedores aos usuários configura novo ciclo de criação-seleção-retenção, promove compartilhamento de sentidos, e reduz mais a ambiguidade da informação do que se não há reconsultas. A Figura 13 apresenta os indícios empíricos de Afastamento da Ambiguidade identificados nas falas dos entrevistados. Com certeza. Com certeza. (...) Eu acho que a proximidade ajuda. Ajuda muito! Muito, muito! ( ) Pras nossas necessidades, a proximidade física ajuda muito e agiliza. (U1) Com certeza. Até este aspecto que a gente tem aqui no banco, de estarmos próximos, isso é básico! A gente consegue Há uma troca quase imediata: a partir do momento em que o desenvolvedor diz assim: Tá disponível!, eu vou lá e experimento e não funciona, ou se dá um resultado que eu não consigo entender, é muito fácil, muito rápido trocar impressões e realmente reduzir essas ambiguidades. Com certeza, esta nossa formatação aqui, eu acho que é muito boa, é bem interessante, é um caminho para solução. (U2) Total! Total! A gente falou aqui, né? Só o fato de estar perto já esclarece. O cara pode estar ali programando no sistema, e daqui a pouco ele ouve uma conversa... (...) É porque já tem uma questão de proximidade mesmo. (...) E tem uma coisa assim, ó, que dizem... Ah, o analista de sistemas, ele não é muito aberto ao relacionamento. A gente tem vantagem aqui. Os nossos todos são bem legais. Mas então isso funciona. (U3) Sim, sempre. ( ) o feedback assim a gente tá sempre conversando ali, entre a [Desenvolvedora 5], até com [a própria pesquisadora] ali, tu vai ali na [equipe Controle Passiva] ver o que tá precisando. Isso é sempre importante. E com certeza esclarece e ajuda a identificar alguma coisa que pode melhorar. Isso é constante. (U4) É essencial, eu acho! Qualquer probleminha, tu já vai ali conversar e já termina. (...) [Naquele caso,] eu expliquei pra ele ( ) Ele entendeu tudo bem ao contrário, mas depois (...) nós conversamos pessoalmente. ( ) Fica mais fácil de entender. ( ) Daí depois disso, melhorou. (U5) Com certeza. O fato de ter os usuários e os desenvolvedores aqui próximos, né? faz muita diferença. Porque um , eu já vi que não funciona tão bem quanto uma conversa. Porque é ali que surge a dúvida, né? (...) Por telefone também não funciona tão bem. (...) Mas para o entendimento, não tem igual como conversar. (...) As pessoas falando talvez se expressassem melhor. Eu acho que essa interação tem que ser presencial. Faz muita diferença. (U6) Eu tenho certeza que não dá pra fazer o desenvolvimento de um produto, de uma demanda de um usuário, sem ter entendido ela perfeitamente, porque, se não entendeu Se entendeu bem, pode ser que não saia a contento do usuário, imagina se não entendeu bem?! Então não deve continuar se tem dúvida. Se houver dúvida, é melhor perder um tempo e voltar ao assunto, voltar a conversar com o usuário, do que continuar desenvolvendo, e depois resultar um produto que não satisfaz. Aí tem que começar tudo de novo. Aí a perda de tempo é maior. (U7) Eu acho que sim. Nesse trabalho aqui, (...) o desenvolvedor, olhando o trabalho do usuário, ele pode chegar a uma otimização do modelo, verificar o sistema, se está adequado ou se não está adequado e tal. Mas a interação, eu acho que não tem como conversar. Não tem esse negócio de Não, o usuário não vai ver, só vai ver a versão final. Acho que não vai trazer benefício nenhum. É conversar, é a pessoa vai discutir com, vai dizer o que que acontece Aí a gente vai tentar. Se isso acontecer, a gente vai poder falar. Eu acho que é isso. (U8) A gente retoma bastante o contato com o usuário. E se reajusta tudo. Eu acho que a reconsulta é necessária sim A gente entende melhor as demandas. Geralmente esclarece. Porque, se não esclarece, não vai adiante o projeto, daí ele para Sempre tem que ter uma volta Sempre acaba esclarecendo, clareando (D1) A interação com o usuário esclarece melhor o entendimento da demanda, certamente!... A interpretação de cada um é diferente, então a que vale é sempre a do usuário. Se ele não responder às dúvidas, quem vai responder? (D2) Os pontos dúbios ficam esclarecidos... Resolvem-se as dúvidas... Você entende melhor as demandas... Senão, a gente não conseguiria fazer nada... Para nós o entendimento da demanda em sua totalidade é fundamental para que possamos desenvolver os cálculos corretamente. (D3) Tem muitos casos que a gente vai ter que voltar, vai ter que testar, vai ter que ver Às vezes achou que era uma coisa, depois viu que não era bem aquilo É importante, em muitos casos, retomar essa interação. (D4) Com certeza, as coisas ficam mais bem definidas, porque se tem o aval do usuário... Com certeza. Porque a gente tenta ir na pessoa que usa, que vai usar. É no dia-a-dia que fica melhor para ter o entendimento, porque alguma coisa de repente fica entendida nos detalhes... É, eu acho que as coisas ficam mais bem definidas. (D5) A interação usuário-desenvolvedor esclarece, é claro, os pontos dúbios dentro do âmbito dos dois. É que o próprio usuário pode ter uma dúvida... uma Instrução, um Normativo, uma coisa assim... Mas esclarece melhor... A interação ajuda a esclarecer as interpretações possíveis. As demandas são melhores entendidas. As coisas ficam melhores definidas. (D6) 20

Rodrigo Rennó Questões CESPE para o MPU 06

Rodrigo Rennó Questões CESPE para o MPU 06 Rodrigo Rennó Questões CESPE para o MPU 06 Questões sobre o tópico Avaliação de Desempenho: objetivos, métodos, vantagens e desvantagens. Olá Pessoal, Espero que estejam gostando dos artigos. Hoje veremos

Leia mais

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE Curso Técnico em Informática ENGENHARIA DE SOFTWARE Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Clayton Maciel Costa

Leia mais

Ajuda ao SciEn-Produção 1. 1. O Artigo Científico da Pesquisa Experimental

Ajuda ao SciEn-Produção 1. 1. O Artigo Científico da Pesquisa Experimental Ajuda ao SciEn-Produção 1 Este texto de ajuda contém três partes: a parte 1 indica em linhas gerais o que deve ser esclarecido em cada uma das seções da estrutura de um artigo cientifico relatando uma

Leia mais

Você já teve a experiência de enviar um email e, em pouco tempo, ver pedidos de orçamento e vendas sendo concretizadas?

Você já teve a experiência de enviar um email e, em pouco tempo, ver pedidos de orçamento e vendas sendo concretizadas? 2 Você já teve a experiência de enviar um email e, em pouco tempo, ver pedidos de orçamento e vendas sendo concretizadas? É SOBRE ISSO QUE VOU FALAR NESTE TEXTO. A maioria das empresas e profissionais

Leia mais

O que é ISO 9001:2000?

O que é ISO 9001:2000? O que é ISO 9001:2000? Um guia passo a passo para a ISO 9001:2000 SISTEMAS DE GESTÃO DA QUALIDADE Conteúdo * SISTEMAS DA QUALIDADE ISO 9001:2000 E PDCA... 1 * OITO PRINCÍPIOS DE GESTÃO DA QUALIDADE...

Leia mais

Manual de Aplicação do Jogo da Escolha. Um jogo terapêutico para jovens usuários de drogas

Manual de Aplicação do Jogo da Escolha. Um jogo terapêutico para jovens usuários de drogas Manual de Aplicação do Jogo da Escolha Um jogo terapêutico para jovens usuários de drogas 1 1. Como o jogo foi elaborado O Jogo da Escolha foi elaborado em 1999 pelo Centro de Pesquisa em Álcool e Drogas

Leia mais

3. Os erros têm sido cometidos exatamente onde há maior dificuldade...

3. Os erros têm sido cometidos exatamente onde há maior dificuldade... Entrevista com PEDRO MANDELLI Consultor na área de mudança organizacional, Pedro Mandelli é um dos maiores especialistas em desenho e condução de processos de mudança em organizações. É professor da Fundação

Leia mais

Ensino de Artes Visuais à Distância

Ensino de Artes Visuais à Distância 1 Ensino de Artes Visuais à Distância Bárbara Angelo Moura Vieira Resumo: Através de uma pesquisa, realizada em meio ao corpo docente da Escola de Belas Artes da Universidade Federal de Minas Gerais, as

Leia mais

As Etapas da Pesquisa D R. G U A N I S D E B A R R O S V I L E L A J U N I O R

As Etapas da Pesquisa D R. G U A N I S D E B A R R O S V I L E L A J U N I O R As Etapas da Pesquisa D R. G U A N I S D E B A R R O S V I L E L A J U N I O R INTRODUÇÃO A pesquisa é um procedimento reflexivo e crítico de busca de respostas para problemas ainda não solucionados. O

Leia mais

Quanto aos meios, trata-se de uma pesquisa bibliográfica, documental, telematizada e pesquisa de campo, conforme descrito abaixo:

Quanto aos meios, trata-se de uma pesquisa bibliográfica, documental, telematizada e pesquisa de campo, conforme descrito abaixo: 3 METODOLOGIA Apresenta-se a seguir a descrição da metodologia utilizada neste trabalho com o objetivo de expor os caminhos que foram percorridos não só no levantamento dos dados do estudo como também

Leia mais

3 METODOLOGIA DA PESQUISA

3 METODOLOGIA DA PESQUISA 3 METODOLOGIA DA PESQUISA O objetivo principal deste estudo, conforme mencionado anteriormente, é identificar, por meio da percepção de consultores, os fatores críticos de sucesso para a implementação

Leia mais

5 Considerações Finais

5 Considerações Finais 5 Considerações Finais Neste capítulo serão apresentadas as considerações finais do estudo. Quando necessário, serão feitas referências ao que já foi apresentado e discutido nos capítulos anteriores, dispondo,

Leia mais

> Folha Dirigida, 18/08/2011 Rio de Janeiro RJ Enem começa a mudar as escolas Thiago Lopes

> Folha Dirigida, 18/08/2011 Rio de Janeiro RJ Enem começa a mudar as escolas Thiago Lopes > Folha Dirigida, 18/08/2011 Rio de Janeiro RJ Enem começa a mudar as escolas Thiago Lopes Criado em 1998, o Exame Nacional do Ensino Médio (Enem), inicialmente, tinha como objetivo avaliar o desempenho

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Prof. José Honorato F.N. Prof. José Honorato F.N. honoratonunes@gmail.com Requisitos de Software Software é o conjunto dos programas e dos meios não materiais que possibilitam o

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO Santa Maria, 10 de Outubro de 2013. Revisão aula anterior Documento de Requisitos Estrutura Padrões Template Descoberta

Leia mais

ALINE VIEIRA MALANOVICZ malanovicz@gmail.com UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL - UFRGS

ALINE VIEIRA MALANOVICZ malanovicz@gmail.com UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL - UFRGS UMA PESQUISA DOCUMENTAL SOBRE O PROCESSO DE ENTENDIMENTO COMPARTILHADO ENTRE USUÁRIOS E DESENVOLVEDORES SOBRE DEMANDAS DE SISTEMAS DE INFORMAÇÃO ANALISADA COM BASE NO MODELO DE ORGANIZAÇÃO DE WEICK ALINE

Leia mais

PESQUISA QUALITATIVA

PESQUISA QUALITATIVA PESQUISA QUALITATIVA CONHECIMENTO É o processo pelo qual as pessoas intuem, apreendem e depois expressam. Qualquer ser humano que apreende o mundo (pensa) e exterioriza, produz conhecimento. PESQUISA É

Leia mais

Palavras-Chaves: engenharia de requisitos, modelagem, UML.

Palavras-Chaves: engenharia de requisitos, modelagem, UML. APLICAÇÃO DA ENGENHARIA DE REQUISITOS PARA COMPREENSÃO DE DOMÍNIO DO PROBLEMA PARA SISTEMA DE CONTROLE COMERCIAL LEONARDO DE PAULA SANCHES Discente da AEMS Faculdades Integradas de Três Lagoas RENAN HENRIQUE

Leia mais

8 Erros Que Podem Acabar Com Seu Negócio de Marketing Digital

8 Erros Que Podem Acabar Com Seu Negócio de Marketing Digital 8 Erros Que Podem Acabar Com Seu Negócio de Marketing Digital Empreender em negócios de marketing digital seguramente foi uma das melhores decisões que tomei em minha vida. Além de eu hoje poder ter minha

Leia mais

Transcriça o da Entrevista

Transcriça o da Entrevista Transcriça o da Entrevista Entrevistadora: Valéria de Assumpção Silva Entrevistada: Ex praticante Clarice Local: Núcleo de Arte Grécia Data: 08.10.2013 Horário: 14h Duração da entrevista: 1h COR PRETA

Leia mais

Um exemplo prático. Como exemplo, suponha que você é um recémcontratado

Um exemplo prático. Como exemplo, suponha que você é um recémcontratado pessoas do grupo. Não basta simplesmente analisar cada interpretação possível, é preciso analisar quais as conseqüências de nossas possíveis respostas, e é isso que proponho que façamos de forma racional.

Leia mais

remuneração para ADVOGADOS advocobrasil Uma forma mais simples e estruturada na hora de remunerar Advogados porque a mudança é essencial

remuneração para ADVOGADOS advocobrasil Uma forma mais simples e estruturada na hora de remunerar Advogados porque a mudança é essencial remuneração para ADVOGADOS Uma forma mais simples e estruturada na hora de remunerar Advogados advocobrasil Não ter uma política de remuneração é péssimo, ter uma "mais ou menos" é pior ainda. Uma das

Leia mais

Gerenciamento de Projetos

Gerenciamento de Projetos Gerenciamento de Projetos PMI, PMP e PMBOK PMI (Project Management Institute) Estabelecido em 1969 e sediado na Filadélfia, Pensilvânia EUA, o PMI é a principal associação mundial, sem fins lucrativos,

Leia mais

ERP. Enterprise Resource Planning. Planejamento de recursos empresariais

ERP. Enterprise Resource Planning. Planejamento de recursos empresariais ERP Enterprise Resource Planning Planejamento de recursos empresariais O que é ERP Os ERPs em termos gerais, são uma plataforma de software desenvolvida para integrar os diversos departamentos de uma empresa,

Leia mais

SISTEMAS DE GESTÃO DE ESTOQUES EX-PROJECT RESUMO INTRODUÇÃO

SISTEMAS DE GESTÃO DE ESTOQUES EX-PROJECT RESUMO INTRODUÇÃO SISTEMAS DE GESTÃO DE ESTOQUES EX-PROJECT Antonio Evangelino de Carvalho Soares Cintia Silvia Victor dos Santos Claudinei Candido Vieira Érica Natália Martins Silva Kátia Ribeiro dos Santos Marco Túlio

Leia mais

MATEMÁTICA E ENEM. Luiz Henrique Almeida de Souza do Nascimento UFMS luiz_g4@hotmail.com. Nathalia Teixeira Larrea UFMS nathalia_tl@hotmail.

MATEMÁTICA E ENEM. Luiz Henrique Almeida de Souza do Nascimento UFMS luiz_g4@hotmail.com. Nathalia Teixeira Larrea UFMS nathalia_tl@hotmail. MATEMÁTICA E ENEM Luiz Henrique Almeida de Souza do Nascimento UFMS luiz_g4@hotmail.com Nathalia Teixeira Larrea UFMS nathalia_tl@hotmail.com Luzia Aparecida de Souza UFMS luzia.souza@ufms.br Resumo Este

Leia mais

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE RESUMO Fazer um bom levantamento e especificação de requisitos é algo primordial para quem trabalha com desenvolvimento de sistemas. Esse levantamento

Leia mais

APLICAÇÃO DA MODELAGEM UML NA FASE DE ANÁLISE DE UM PROJETO DE SOFTWARE PARA AGENDAMENTO DE USO DE VEÍCULOS INTERNOS DE UMA EMPRESA

APLICAÇÃO DA MODELAGEM UML NA FASE DE ANÁLISE DE UM PROJETO DE SOFTWARE PARA AGENDAMENTO DE USO DE VEÍCULOS INTERNOS DE UMA EMPRESA APLICAÇÃO DA MODELAGEM UML NA FASE DE ANÁLISE DE UM PROJETO DE SOFTWARE PARA AGENDAMENTO DE USO DE VEÍCULOS INTERNOS DE UMA EMPRESA ANDRE APARECIDO LEAL DE ALMEIDA Discente da AEMS Faculdades Integradas

Leia mais

Palavras-Chaves: Arquitetura, Modelagem Orientada a Objetos, UML.

Palavras-Chaves: Arquitetura, Modelagem Orientada a Objetos, UML. MODELAGEM ORIENTADA A OBJETOS APLICADA À ANÁLISE E AO PROJETO DE SISTEMA DE VENDAS ALTEMIR FERNANDES DE ARAÚJO Discente da AEMS Faculdades Integradas de Três Lagoas ANDRE LUIZ DA CUNHA DIAS Discente da

Leia mais

ERP. Planejamento de recursos empresariais

ERP. Planejamento de recursos empresariais ERP Enterprise Resource Planning Planejamento de recursos empresariais ERP Enterprise Resource Planning -Sistema de Gestão Empresarial -Surgimento por volta dos anos 90 -Existência de uma base de dados

Leia mais

NOKIA. Em destaque LEE FEINBERG

NOKIA. Em destaque LEE FEINBERG Em destaque NOKIA LEE FEINBERG A Nokia é líder mundial no fornecimento de telefones celulares, redes de telecomunicações e serviços relacionados para clientes. Como Gerente Sênior de Planejamento de Decisões

Leia mais

Discursivas do Cespe Tema específico: resposta fácil, organização complicada.

Discursivas do Cespe Tema específico: resposta fácil, organização complicada. Toque de Mestre 16 Discursivas do Cespe Tema específico: resposta fácil, organização complicada. Profa. Júnia Andrade Viana profajunia@gmail.com face: profajunia Autora do livro Redação para Concursos

Leia mais

Equações do primeiro grau

Equações do primeiro grau Módulo 1 Unidade 3 Equações do primeiro grau Para início de conversa... Você tem um telefone celular ou conhece alguém que tenha? Você sabia que o telefone celular é um dos meios de comunicação que mais

Leia mais

Rio de Janeiro, 5 de junho de 2008

Rio de Janeiro, 5 de junho de 2008 Rio de Janeiro, 5 de junho de 2008 IDENTIFICAÇÃO Meu nome é Alexandre da Silva França. Eu nasci em 17 do sete de 1958, no Rio de Janeiro. FORMAÇÃO Eu sou tecnólogo em processamento de dados. PRIMEIRO DIA

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às

Leia mais

Engenharia de Requisitos

Engenharia de Requisitos Engenharia de Requisitos Conteúdo Definição Questionamentos Típicos Visão Geral Ciclo de Vida dos Requisitos Síntese dos Objetivos Gerência de Mudança Identificação de Requisitos Classificação de Requisitos

Leia mais

com níveis ótimos de Brand Equity, os interesses organizacionais são compatíveis com as expectativas dos consumidores.

com níveis ótimos de Brand Equity, os interesses organizacionais são compatíveis com as expectativas dos consumidores. Brand Equity O conceito de Brand Equity surgiu na década de 1980. Este conceito contribuiu muito para o aumento da importância da marca na estratégia de marketing das empresas, embora devemos ressaltar

Leia mais

3 Metodologia 3.1. Design da pesquisa

3 Metodologia 3.1. Design da pesquisa 3 Metodologia 3.1. Design da pesquisa O objetivo do presente estudo é o de avaliar um processo de comunicação oficial na organização STAR, uma organização do segmento de educação, sem fins lucrativos,

Leia mais

UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas

UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas 4.1 Motivação Sistemas de Informação são usados em diversos níveis dentro de uma organização, apoiando a tomada de decisão; Precisam estar

Leia mais

IMPLANTAÇÃO E TREINAMENTO NO SISTEMA DE INFORMAÇÕES GERENCIAIS ESTUDO DE CASO

IMPLANTAÇÃO E TREINAMENTO NO SISTEMA DE INFORMAÇÕES GERENCIAIS ESTUDO DE CASO 503 IMPLANTAÇÃO E TREINAMENTO NO SISTEMA DE INFORMAÇÕES GERENCIAIS ESTUDO DE CASO Christina Garcia(1); Franciane Formighieri(2); Taciana Tonial(3) & Neimar Follmann(4)(1) Acadêmica do 4º Ano do Curso de

Leia mais

Preparação do Trabalho de Pesquisa

Preparação do Trabalho de Pesquisa Preparação do Trabalho de Pesquisa Ricardo de Almeida Falbo Metodologia de Pesquisa Departamento de Informática Universidade Federal do Espírito Santo Pesquisa Bibliográfica Etapas do Trabalho de Pesquisa

Leia mais

MACROPROCESSOS É um conjunto de processos que correspondem a uma função da organização.

MACROPROCESSOS É um conjunto de processos que correspondem a uma função da organização. GESTÃO POR PROCESSOS Prof. WAGNER RABELLO JR PROCESSO Conjunto de recursos e atividades interrelacionadas que transforma insumos (entradas) em serviços ou produtos (saídas); GESTÃO DE PROCESSO OU GESTÃO

Leia mais

Como Eu Começo meu A3?

Como Eu Começo meu A3? Como Eu Começo meu A3? David Verble O pensamento A3 é um pensamento lento. Você está tendo problemas para começar seu A3? Quando ministro treinamentos sobre o pensamento, criação e uso do A3, este assunto

Leia mais

fagury.com.br. PMBoK 2004

fagury.com.br. PMBoK 2004 Este material é distribuído por Thiago Fagury através de uma licença Creative Commons 2.5. É permitido o uso e atribuição para fim nãocomercial. É vedada a criação de obras derivadas sem comunicação prévia

Leia mais

Encontro Nacional Jovem de Futuro 2013: conexões e troca de experiências

Encontro Nacional Jovem de Futuro 2013: conexões e troca de experiências boletim Jovem de Futuro ed. 04-13 de dezembro de 2013 Encontro Nacional Jovem de Futuro 2013: conexões e troca de experiências O Encontro Nacional Jovem de Futuro 2013 aconteceu de 26 a 28 de novembro.

Leia mais

Modulo 4. Principais instrumentos de coleta de dados. Entrevista Questionário Formulário Observação Triangulação

Modulo 4. Principais instrumentos de coleta de dados. Entrevista Questionário Formulário Observação Triangulação Metodologia de Estudo e de Pesquisa em Administração Modulo 4 Principais instrumentos de coleta de dados. Entrevista Questionário Formulário Observação Triangulação UAB - UNEMAT Prof. Dr. Marcos Luís Procópio

Leia mais

Técnicas e Instrumentos Utilizados na Pesquisa Científica Cavalcanti

Técnicas e Instrumentos Utilizados na Pesquisa Científica Cavalcanti Técnicas e Instrumentos Utilizados na Pesquisa Científica Técnicas de Pesquisa Técnica: Conjunto de preceitos ou processos de que se serve uma ciência. Toda ciência utiliza inúmeras técnicas na obtenção

Leia mais

A grande farsa da evolução do processo de gestão empresarial

A grande farsa da evolução do processo de gestão empresarial A grande farsa da evolução do processo de gestão empresarial Começo minha reflexão de hoje pensando um pouco na história da Administração, nos princípios de gestão e formas como as empresas hoje são geridas.

Leia mais

Auditoria de Sistemas. UNIPAC Ipatinga Segurança e Auditoria de Sistemas Prof. Thiago Lopes Lima

Auditoria de Sistemas. UNIPAC Ipatinga Segurança e Auditoria de Sistemas Prof. Thiago Lopes Lima Auditoria de Sistemas UNIPAC Ipatinga Segurança e Auditoria de Sistemas Prof. Thiago Lopes Lima Auditoria É uma atividade que engloba o exame das operações, processos, sistemas e responsabilidades gerenciais

Leia mais

Desculpe, Sérgio, eu não sei se eu falei saúde, a minha pergunta é sobre automóveis.

Desculpe, Sérgio, eu não sei se eu falei saúde, a minha pergunta é sobre automóveis. Iago Whately, Banco Fator: Eu tenho duas perguntas. A primeira é a respeito da sinistralidade no seguro de saúde. A sinistralidade da SulAmérica no 1T ficou bem abaixo da média do mercado segurador. Eu

Leia mais

OS 4 PASSOS ALTA PERFORMANCE A PARTIR DE AGORA PARA VOCÊ COMEÇAR A VIVER EM HIGHSTAKESLIFESTYLE.

OS 4 PASSOS ALTA PERFORMANCE A PARTIR DE AGORA PARA VOCÊ COMEÇAR A VIVER EM HIGHSTAKESLIFESTYLE. OS 4 PASSOS PARA VOCÊ COMEÇAR A VIVER EM ALTA PERFORMANCE A PARTIR DE AGORA HIGHSTAKESLIFESTYLE. Hey :) Gabriel Goffi aqui. Criei esse PDF para você que assistiu e gostou do vídeo ter sempre por perto

Leia mais

GESTÃO DO CRÉDITO: AVALIAÇÃO DO RISCO, E ANÁLISE PARA TOMADA DE DECISÃO DE CRÉDITO

GESTÃO DO CRÉDITO: AVALIAÇÃO DO RISCO, E ANÁLISE PARA TOMADA DE DECISÃO DE CRÉDITO Encontro de Ensino, Pesquisa e Extensão, Presidente Prudente, 22 a 25 de outubro, 2012 109 GESTÃO DO CRÉDITO: AVALIAÇÃO DO RISCO, E ANÁLISE PARA TOMADA DE DECISÃO DE CRÉDITO Claudinei Higino da Silva,

Leia mais

Atividade - Sequência Conrado Adolpho

Atividade - Sequência Conrado Adolpho Atividade - Sequência Conrado Adolpho Agora, eu quero lhe apresentar os 6 e-mails do conrado adolpho para vender o 8ps. Quero que você leia está sequência com muita atenção e, depois, responda às provocações

Leia mais

:: Cuidados na Elaboração de uma Redação Científica

:: Cuidados na Elaboração de uma Redação Científica :: Cuidados na Elaboração de uma Redação Científica José Mauricio Santos Pinheiro em 21/04/2005 Os princípios indispensáveis à redação científica podem ser resumidos em quatro pontos fundamentais: clareza,

Leia mais

TOBY MENDEL (Consultor Internacional da Unesco): [pronunciamento em outro idioma] INTÉRPRETE: Deixa eu começar agradecendo para os apresentadores.

TOBY MENDEL (Consultor Internacional da Unesco): [pronunciamento em outro idioma] INTÉRPRETE: Deixa eu começar agradecendo para os apresentadores. TOBY MENDEL (Consultor Internacional da Unesco): [pronunciamento em outro idioma] INTÉRPRETE: Deixa eu começar agradecendo para os apresentadores. Aqui, a gente tem uma apresentação muito importante, e

Leia mais

Levantamento, Análise e Gestão Requisitos. Aula 06

Levantamento, Análise e Gestão Requisitos. Aula 06 Levantamento, Análise e Gestão Requisitos Aula 06 Agenda Técnicas de Levantamento de Requisitos: Entrevista Workshop, Brainstorming, Storyboarding e Roleplaying Prototipação JAD Joint Application Design

Leia mais

UNIVERSIDADE FEDERAL DO RIO GRANDE TECNOLOGIA EM ANALISE E DESENVOLVIMENTO DE SISTEMAS

UNIVERSIDADE FEDERAL DO RIO GRANDE TECNOLOGIA EM ANALISE E DESENVOLVIMENTO DE SISTEMAS UNIVERSIDADE FEDERAL DO RIO GRANDE TECNOLOGIA EM ANALISE E DESENVOLVIMENTO DE SISTEMAS Professor: Adriel Ziesemer Disciplina: Engenharia de Software TRABALHO ACADÊMICO Cristian Santos - nº 45671 Guilherme

Leia mais

FERRAMENTAS DE GESTÃO NOS EMPREENDIMENTOS DE ALIMENTAÇÃO

FERRAMENTAS DE GESTÃO NOS EMPREENDIMENTOS DE ALIMENTAÇÃO FERRAMENTAS DE GESTÃO NOS EMPREENDIMENTOS DE ALIMENTAÇÃO Dennis Pessoa da Silva 1 RESUMO Ferramentas administrativas são técnicas utilizadas na gestão de empresas para solucionar problemas. Elas controlam

Leia mais

Tecnologias da Informação e da Comunicação Aula 01

Tecnologias da Informação e da Comunicação Aula 01 Tecnologias da Informação e da Comunicação Aula 01 Douglas Farias Cordeiro Universidade Federal de Goiás 31 de julho de 2015 Mini-currículo Professor do curso Gestão da Informação Professor do curso ESAMI

Leia mais

A pesquisa de campo foi realizada com questões para os núcleos administrativo, pessoal e acadêmico e procura explorar duas situações distintas:

A pesquisa de campo foi realizada com questões para os núcleos administrativo, pessoal e acadêmico e procura explorar duas situações distintas: 4 Pesquisa de campo Neste capitulo será apresentado o resultado dos questionários da pesquisa de campo que serviu para o estudo de caso. A coleta de dados será dividida em: Núcleo administrativo Núcleo

Leia mais

O papel do CRM no sucesso comercial

O papel do CRM no sucesso comercial O papel do CRM no sucesso comercial Escrito por Gustavo Paulillo Você sabia que o relacionamento com clientes pode ajudar sua empresa a ter mais sucesso nas vendas? Ter uma equipe de vendas eficaz é o

Leia mais

Engenharia de Software Software Requirements

Engenharia de Software Software Requirements Requisitos Engenharia de Software Software Requirements SWEBOK, Capítulo 2 Primeira Classificação de Requisito 1. Requisito do usuário: declarações sobre as funções que o sistema deve oferecer 2. Requisito

Leia mais

II SEMINÁRIO SOBRE GESTÃO DE PESSOAS NO SETOR PÚBLICO DESAFIOS DO DESENVOLVIMENTO GERENCIAL. Palestrante: Luisa Rocha Cabral

II SEMINÁRIO SOBRE GESTÃO DE PESSOAS NO SETOR PÚBLICO DESAFIOS DO DESENVOLVIMENTO GERENCIAL. Palestrante: Luisa Rocha Cabral 1 II SEMINÁRIO SOBRE GESTÃO DE PESSOAS NO SETOR PÚBLICO DESAFIOS DO DESENVOLVIMENTO GERENCIAL Palestrante: Luisa Rocha Cabral Graduada em Administração Pública pela Escola de Governo Professor Paulo Neves

Leia mais

, como desenvolver o seu primeiro infoproduto

, como desenvolver o seu primeiro infoproduto Olá! Seja bem-vindo a essa série de três vídeos, onde eu quero mostrar exatamente como criar, como desenvolver e como fazer um marketing do seu próprio produto digital, criando um negócio altamente lucrativo

Leia mais

4 Metodologia. 4.1. Primeira parte

4 Metodologia. 4.1. Primeira parte 4 Metodologia [...] a metodologia inclui as concepções teóricas de abordagem, o conjunto de técnicas que possibilitam a apreensão da realidade e também o potencial criativo do pesquisador. (Minayo, 1993,

Leia mais

Indicadores de desempenho de processos de negócio

Indicadores de desempenho de processos de negócio Indicadores de desempenho de processos de negócio 14:30, a sala de reunião de uma empresa. De um lado da mesa estão o gerente de um produto, um usuário-chave representante do cliente, do outro se encontram

Leia mais

PLANEJAMENTO E ESTRATÉGIAS 1. O CENÁRIO DO SETOR AGROPECUÁRIO BRASILEIRO

PLANEJAMENTO E ESTRATÉGIAS 1. O CENÁRIO DO SETOR AGROPECUÁRIO BRASILEIRO PLANEJAMENTO E ESTRATÉGIAS 1. O CENÁRIO DO SETOR AGROPECUÁRIO BRASILEIRO A economia brasileira tem passado por rápidas transformações nos últimos anos. Neste contexto ganham espaço novas concepções, ações

Leia mais

Código de Ética. PARTE I Relação com o cliente de Consultoria

Código de Ética. PARTE I Relação com o cliente de Consultoria Código de Ética PARTE I Relação com o cliente de Consultoria 1. É essencial que o Consultor estabeleça de inicio com o cliente, de forma clara, os objetivos do trabalho previsto, dos meios a serem utilizados,

Leia mais

FORMAÇÃO DE PROFESSORES QUE ENSINAM MATEMÁTICA

FORMAÇÃO DE PROFESSORES QUE ENSINAM MATEMÁTICA FORMAÇÃO DE PROFESSORES QUE ENSINAM MATEMÁTICA Fabiana de Jesus Oliveira União de Ensino do Sudoeste do Paraná fabiana@unisep.edu.br Diversas são as pesquisas que têm mostrado que o ensino encontra-se

Leia mais

Grasiela - Bom à gente pode começar a nossa conversa, você contando para a gente como funciona o sistema de saúde na Inglaterra?

Grasiela - Bom à gente pode começar a nossa conversa, você contando para a gente como funciona o sistema de saúde na Inglaterra? Rádio Web Saúde dos estudantes de Saúde Coletiva da UnB em parceria com Rádio Web Saúde da UFRGS em entrevista com: Sarah Donetto pesquisadora Inglesa falando sobre o NHS - National Health Service, Sistema

Leia mais

Agilizando o processo de compras para aumentar a eficiência e comprar melhor

Agilizando o processo de compras para aumentar a eficiência e comprar melhor Agilizando o processo de compras para aumentar a eficiência e comprar melhor Toda empresa privada deseja gerar lucro e para que chegue com sucesso ao final do mês ela precisa vender, sejam seus serviços

Leia mais

Utilize o roteiro abaixo como mapa para elaboração do projeto. Organizado o conjunto, amplie as partes que requerem detalhamento.

Utilize o roteiro abaixo como mapa para elaboração do projeto. Organizado o conjunto, amplie as partes que requerem detalhamento. Utilize o roteiro abaixo como mapa para elaboração do projeto. Organizado o conjunto, amplie as partes que requerem detalhamento. ROTEIRO PARA ELABORAÇÃO DE PROJETO DE PESQUISA Título provisório (uma expressão

Leia mais

CONSULTOR CARLOS MARTINS AÇAO EM MARKETING

CONSULTOR CARLOS MARTINS AÇAO EM MARKETING CONSULTOR CARLOS MARTINS CRIA - AÇAO EM MARKETING SUA EMPRESA Copyright Consultor Carlos Martins - Todos os direitos reservados wwwcarlosmartinscombr - consultor@carlosmartinscombr Como conquistar Clientes

Leia mais

TESTE: RELACIONAMENTO INTERPESSOAL

TESTE: RELACIONAMENTO INTERPESSOAL TESTE: RELACIONAMENTO INTERPESSOAL (JANELA JOHARI) É constituído de 20 situações possíveis de ocorrer dentro de uma empresa, composto por duas afirmativas de resposta em cada. O usuário deve analisar qual

Leia mais

Observação dos programas de educação pelos pais, e pessoas designadas pelos mesmos, com o Propósito de Avaliação

Observação dos programas de educação pelos pais, e pessoas designadas pelos mesmos, com o Propósito de Avaliação Educação Especial Informe de Assistência Técnica SPED 2009-2: Observação dos programas de educação pelos pais, e pessoas designadas pelos mesmos, com o Propósito de Avaliação Para: Superintendentes, diretores,

Leia mais

Rubricas e guias de pontuação

Rubricas e guias de pontuação Avaliação de Projetos O ensino a partir de projetos exibe meios mais avançados de avaliação, nos quais os alunos podem ver a aprendizagem como um processo e usam estratégias de resolução de problemas para

Leia mais

PESQUISA QUANTITATIVA e QUALITATIVA

PESQUISA QUANTITATIVA e QUALITATIVA universidade de Santa Cruz do Sul Faculdade de Serviço Social Pesquisa em Serviço Social I I PESQUISA QUANTITATIVA e QUALITATIVA BIBLIOGRAFIA: MARCONI, Marina de Andrade; LAKATOS, Eva Maria. Técnicas de

Leia mais

Conhecendo um pouco de matrizes e determinantes

Conhecendo um pouco de matrizes e determinantes Módulo 3 Unidade 29 Conhecendo um pouco de matrizes e determinantes Para início de conversa... Frequentemente em jornais, revistas e também na Internet encontramos informações numéricas organizadas na

Leia mais

Apresentaremos um diagrama de um processo de Vendas Consultivas que quando bem utilizado pode proporcionar :

Apresentaremos um diagrama de um processo de Vendas Consultivas que quando bem utilizado pode proporcionar : Pesquisa do professor Walter Brum Monteiro. Para conhecer nossos clientes e realizar negócios mais consistentes e duradouros, precisamos passar mais tempo interagindo e aproveitar o máximo possível deste

Leia mais

5 Passos para vender mais com o Instagram

5 Passos para vender mais com o Instagram 5 Passos para vender mais com o Instagram Guia para iniciantes melhorarem suas estratégias ÍNDICE 1. Introdução 2. O Comportamento das pessoas na internet 3. Passo 1: Tenha um objetivo 4. Passo 2: Defina

Leia mais

Projeto de Sistemas I

Projeto de Sistemas I Instituto Federal de Educação, Ciência e Tecnologia de São Paulo Projeto de Sistemas I Professora: Kelly de Paula Cunha E-mail:kellypcsoares@ifsp.edu.br Requisitos: base para todo projeto, definindo o

Leia mais

CONTEÚDO PROGRAMÁTICO

CONTEÚDO PROGRAMÁTICO CONTEÚDO PROGRAMÁTICO Projeto de Sistemas Profa. Cynara Carvalho cynaracarvalho@yahoo.com.br http://cynaracarvalho.webnode.pt Ementa: Conceito de Sistemas; Partes ou módulos de um sistema; Visão Geral

Leia mais

A Computação e as Classificações da Ciência

A Computação e as Classificações da Ciência A Computação e as Classificações da Ciência Ricardo de Almeida Falbo Metodologia de Pesquisa Departamento de Informática Universidade Federal do Espírito Santo Agenda Classificações da Ciência A Computação

Leia mais

Como levantar o ciclo de serviço:

Como levantar o ciclo de serviço: CONSTRUÇÃO DE QUESTIONÁRIOS PARA MEDIÇÃO E MONITORAMENTO DA SATISFAÇÃO DE CLIENTES CICLO DE SERVIÇO : A base do questionário é um roteiro que contém os principais incidentes críticos do ciclo de serviço.

Leia mais

FORMAÇÃO CONTINUADA: MUDANÇAS NA PRÁTICA PEDAGÓGICA NA VIVÊNCIA DE UM PROGRAMA.

FORMAÇÃO CONTINUADA: MUDANÇAS NA PRÁTICA PEDAGÓGICA NA VIVÊNCIA DE UM PROGRAMA. FORMAÇÃO CONTINUADA: MUDANÇAS NA PRÁTICA PEDAGÓGICA NA VIVÊNCIA DE UM PROGRAMA. Rosângela de Fátima Cavalcante França* Universidade Federal de Mato Grosso do Sul RESUMO Este texto apresenta de forma resumida

Leia mais

ACENDA O OTIMISMO EM SUA VIDA. Quiz Descubra Se Você é uma Pessoa Otimista

ACENDA O OTIMISMO EM SUA VIDA. Quiz Descubra Se Você é uma Pessoa Otimista ACENDA O OTIMISMO EM SUA VIDA Quiz Descubra Se Você é uma Pessoa Otimista Uma longa viagem começa com um único passo. - Lao-Tsé Ser Otimista não é uma tarefa fácil hoje em dia, apesar de contarmos hoje

Leia mais

II Congresso Nacional de Formação de Professores XII Congresso Estadual Paulista sobre Formação de Educadores

II Congresso Nacional de Formação de Professores XII Congresso Estadual Paulista sobre Formação de Educadores II Congresso Nacional de Formação de Professores XII Congresso Estadual Paulista sobre Formação de Educadores A VISÃO DE ALGUMAS BOLSISTAS DO PIBID SOBRE SUA ATUAÇÃO EM CONTEXTOS EDUCACIONAIS INCLUSIVOS

Leia mais

Se observarmos nos diferentes livros. Planejamento de Testes a partir de Casos de Uso

Se observarmos nos diferentes livros. Planejamento de Testes a partir de Casos de Uso Planejamento de Testes a partir de Casos de Uso Arilo Cláudio Dias Neto ariloclaudio@gmail.com É Bacharel em Ciência da Computação formado na Universidade Federal do Amazonas, Mestre em Engenharia de Sistemas

Leia mais

Rodrigo Rennó Questões CESPE para o MPU 12

Rodrigo Rennó Questões CESPE para o MPU 12 Rodrigo Rennó Questões CESPE para o MPU 12 Questões sobre o tópico Desenvolvimento e treinamento de pessoal: levantamento de necessidades, programação, execução e avaliação. Olá Pessoal, hoje veremos outro

Leia mais

A PERCEPÇÃO DAS EMPRESAS SOBRE OS SERVIÇOS PRESTADOS PELOS PROFISSIONAIS DA AREA DE SISTEMA DE INFORMAÇÃO 1

A PERCEPÇÃO DAS EMPRESAS SOBRE OS SERVIÇOS PRESTADOS PELOS PROFISSIONAIS DA AREA DE SISTEMA DE INFORMAÇÃO 1 A PERCEPÇÃO DAS EMPRESAS SOBRE OS SERVIÇOS PRESTADOS PELOS PROFISSIONAIS DA AREA DE SISTEMA DE INFORMAÇÃO 1 Tatiana Pereira da Silveira 1 RESUMO O objetivo deste trabalho é apresentar os resultados da

Leia mais

Contabilidade Financeira e Orçamentária

Contabilidade Financeira e Orçamentária Contabilidade Financeira e Orçamentária Mercados Gestão de Riscos Planejamento Orçamentário Mercado Financeiro Mercado financeiro Em uma economia, de um lado existem os que possuem poupança financeira

Leia mais

Etapas para a elaboração de um Pré- Projeto de Pesquisa

Etapas para a elaboração de um Pré- Projeto de Pesquisa Etapas para a elaboração de um Pré- Projeto de Pesquisa Estrutura de um projeto de pesquisa: 1. TEMA E TÍTULO DO PROJETO 2. DELIMITAÇÃO DO PROBLEMA 3. INTRODUÇÃO 4. RELEVÂNCIA E JUSTIFICATIVA 5. OBJETIVOS

Leia mais

Como tirar proveito de um balanço na administração financeira...

Como tirar proveito de um balanço na administração financeira... Como tirar proveito de um balanço na administração financeira... José Alberto Bonassoli* Muitos contadores ficam frustrados quando entregam um balancete ou um balanço para administração. São poucos empresários

Leia mais

Código de Ética do IBCO

Código de Ética do IBCO Código de Ética do IBCO Qua, 14 de Novembro de 2007 21:00 O papel do consultor de organização, no desempenho de suas atividades, é o de assistir aos clientes na melhoria do seu desempenho, tanto nos aspectos

Leia mais

COVERSAS COLABORATIVAS ENTRE PROFESSORES DE INGLÊS: PRINCÍPIO PARA A DESNATURALIZAÇÃO DE CRENÇAS?

COVERSAS COLABORATIVAS ENTRE PROFESSORES DE INGLÊS: PRINCÍPIO PARA A DESNATURALIZAÇÃO DE CRENÇAS? COVERSAS COLABORATIVAS ENTRE PROFESSORES DE INGLÊS: PRINCÍPIO PARA A DESNATURALIZAÇÃO DE CRENÇAS? SILVA, Arivan Salustiano da Mestrando do Programa de Pós-Graduação em Estudos de Linguagem MeEL/UFMT arivanss@yahoo.com

Leia mais

1ª. Apostila de Filosofia O que é Filosofia? Para que a Filosofia? A atitude filosófica. Apresentação

1ª. Apostila de Filosofia O que é Filosofia? Para que a Filosofia? A atitude filosófica. Apresentação 1 1ª. Apostila de Filosofia O que é Filosofia? Para que a Filosofia? A atitude filosófica. Apresentação O objetivo principal de Introdução Filosofia é despertar no aluno a percepção que a análise, reflexão

Leia mais

DESENVOLVIMENTO DE PROJETOS Profa. Dra. Alessandra de Linhares Jacobsen (CAD/UFSC)

DESENVOLVIMENTO DE PROJETOS Profa. Dra. Alessandra de Linhares Jacobsen (CAD/UFSC) INPEAU/UFSC Instituto de Gestão Liderança Universitária, da Organização Universitária Interamericana, do Canadá. DESENVOLVIMENTO DE PROJETOS Profa. Dra. Alessandra de Linhares Jacobsen (CAD/UFSC) OBJETIVOS

Leia mais