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

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

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

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

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

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

3 Metodologia. 3.1 Tipo de pesquisa

3 Metodologia. 3.1 Tipo de pesquisa 3 Metodologia Este estudo baseou-se em uma estratégia qualitativa de pesquisa, de caráter exploratório, por meio de uma pesquisa de campo. Neste capítulo, pretendemos demonstrar os procedimentos metodológicos

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

1. Introdução. Saiba mais

1. Introdução. Saiba mais 1. Introdução Gestão de Sistemas de Informação Aula 3 -Planejamento e desenvolvimento de sistemas de informação Prof: Cleber A. de Oliveira Para a adequada compreensão deste conteúdo, é preciso que estejam

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

9 RECURSOS HUMANOS 10 COMUNICAÇÕES

9 RECURSOS HUMANOS 10 COMUNICAÇÕES 10 COMUNICAÇÕES O gerenciamento das comunicações do projeto é a área de conhecimento que emprega os processos necessários para garantir a geração, coleta, distribuição, armazenamento, recuperação e destinação

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

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

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

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

Onde você vai encontrar as suas futuras iniciadas?????

Onde você vai encontrar as suas futuras iniciadas????? Há 16 anos quando entrou na MK, a consagrada Diretora Nacional, Gloria Mayfield, não sabia como chegar ao topo, hoje ela dá o seguinte conselho. As lições que eu aprendi na Mary Kay para me tornar uma

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

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

03 Passos para o Seu Dinheiro da Poupança

03 Passos para o Seu Dinheiro da Poupança 03 Passos para o Seu Dinheiro da Poupança Render 5 Vezes Mais por Leandro Sierra Índice Apresentação...03 Introdução... 04 Passo 1...05 Passo 2... 08 Educação Financeira para a Segurança do seu Investimento...

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

ESPECIFICAÇÃO DO ESCOPO DE SISTEMA DE SOFTWARE A PARTIR DA UTILIZAÇÃO DA ENGENHARIA DE REQUISITOS

ESPECIFICAÇÃO DO ESCOPO DE SISTEMA DE SOFTWARE A PARTIR DA UTILIZAÇÃO DA ENGENHARIA DE REQUISITOS ESPECIFICAÇÃO DO ESCOPO DE SISTEMA DE SOFTWARE A PARTIR DA UTILIZAÇÃO DA ENGENHARIA DE REQUISITOS Rosiane da Silva Biscaia Discente do curso Tecnologia em Análise e Desenvolvimento de Sistemas Faculdades

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

As cinco disciplinas

As cinco disciplinas As cinco disciplinas por Peter Senge HSM Management julho - agosto 1998 O especialista Peter Senge diz em entrevista exclusiva que os programas de aprendizado podem ser a única fonte sustentável de vantagem

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

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

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

:: 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

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

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

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

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

Escrito por. Guilherme guinor Cunha Ex-tenista profissional, campeão mundial de poker online FTOPS #35 e criador do método GuinorBets

Escrito por. Guilherme guinor Cunha Ex-tenista profissional, campeão mundial de poker online FTOPS #35 e criador do método GuinorBets s O 6 s o i cíp Prin Bá s o sic o d o ét M o D r o n s i t u e G B Escrito por Guilherme guinor Cunha Ex-tenista profissional, campeão mundial de poker online FTOPS #35 e criador do método Índice Quem

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

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

Prof. Raul Sidnei Wazlawick UFSC-CTC-INE. Fonte: Análise e Projeto de Sistemas de Informação Orientados a Objetos, 2ª Edição, Elsevier, 2010.

Prof. Raul Sidnei Wazlawick UFSC-CTC-INE. Fonte: Análise e Projeto de Sistemas de Informação Orientados a Objetos, 2ª Edição, Elsevier, 2010. Casos de Uso Expandidos Prof. Raul Sidnei Wazlawick UFSC-CTC-INE 2010 Fonte: Análise e Projeto de Sistemas de Informação Orientados a Objetos, 2ª Edição, Elsevier, 2010. Expansão dos Casos de Uso Corresponde

Leia mais

A FUNÇÃO CONTROLE. Orientação do controle

A FUNÇÃO CONTROLE. Orientação do controle A FUNÇÃO CONTROLE O controle é a ultima função da administração a ser analisadas e diz respeito aos esforços exercidos para gerar e usar informações relativas a execução das atividades nas organizações

Leia mais

FERRAMENTA PARA GERAÇÃO DE IDÉIAS E SOLUÇÕES.

FERRAMENTA PARA GERAÇÃO DE IDÉIAS E SOLUÇÕES. Prof. Edson Costa Aildefonso FERRAMENTA PARA GERAÇÃO DE IDÉIAS E SOLUÇÕES. Qualquer um de nós que possua alguma experiência em trabalho de grupo sabe como é difícil desenvolver maneiras criativas para

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

Sessão de Perguntas e Respostas

Sessão de Perguntas e Respostas Bom dia Flávio, bom dia a todos. Minha pergunta na verdade é com relação à questão da PDD. Só para saber se eu entendi corretamente, você estava falando que a PDD relativa aos empréstimos pessoais representavam

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 ENGAJAR UM FUNCIONÁRIO NO PRIMEIRO DIA DE TRABALHO?

COMO ENGAJAR UM FUNCIONÁRIO NO PRIMEIRO DIA DE TRABALHO? COMO ENGAJAR UM FUNCIONÁRIO NO PRIMEIRO DIA DE TRABALHO? COMO ENGAJAR UM FUNCIONÁRIO NO PRIMEIRO DIA DE TRABALHO? Engajar funcionários é conseguir envolver as pessoas em um mesmo propósito que a empresa

Leia mais

Conceitos de Sistemas de Informação

Conceitos de Sistemas de Informação Conceitos de Sistemas de Informação Prof. Miguel Damasco AEDB 1 Objetivos da Unidade 1 Explicar por que o conhecimento dos sistemas de informação é importante para os profissionais das empresas e identificar

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

Transcrição da entrevista aos Stakeholders realizada no dia 16 de junho de 2014 no âmbito do Mestrado em Educação e Comunicação Multimédia.

Transcrição da entrevista aos Stakeholders realizada no dia 16 de junho de 2014 no âmbito do Mestrado em Educação e Comunicação Multimédia. Transcrição da entrevista aos Stakeholders realizada no dia 16 de junho de 2014 no âmbito do Mestrado em Educação e Comunicação Multimédia. Q1. Na sua opinião, quais são as principais motivações que podem

Leia mais

Estratégias em Tecnologia da Informação

Estratégias em Tecnologia da Informação Estratégias em Tecnologia da Informação Capítulo 6 Sistemas de Informações Estratégicas Sistemas integrados e sistemas legados Sistemas de Gerenciamento de Banco de Dados Material de apoio 2 Esclarecimentos

Leia mais

Padrões de Competências para o Cargo de Coordenador Pedagógico

Padrões de Competências para o Cargo de Coordenador Pedagógico Padrões de Competências para o Cargo de Coordenador Pedagógico O Coordenador Pedagógico é o profissional que, na Escola, possui o importante papel de desenvolver e articular ações pedagógicas que viabilizem

Leia mais

TECNOLOGIA E SISTEMAS DE INFORMAÇÃO UM ESTUDO DE CASO NA EMPRESA POSTO DOURADÃO LTDA RESUMO

TECNOLOGIA E SISTEMAS DE INFORMAÇÃO UM ESTUDO DE CASO NA EMPRESA POSTO DOURADÃO LTDA RESUMO TECNOLOGIA E SISTEMAS DE INFORMAÇÃO UM ESTUDO DE CASO NA EMPRESA POSTO DOURADÃO LTDA Hewerton Luis P. Santiago 1 Matheus Rabelo Costa 2 RESUMO Com o constante avanço tecnológico que vem ocorrendo nessa

Leia mais

Elaboração de Projetos

Elaboração de Projetos Elaboração de Projetos 2 1. ProjetoS Como se trabalha com projetos ALMEIDA, Maria Elizabeth. Como se trabalha com projetos. Revista TV Escola, [S.l.], n. 22, p. 35-38, 2001. Entrevista concedida a Cláudio

Leia mais

CULTURA OU FERRAMENTA: O DILEMA DA APROPRIAÇÃO QUE OS PROFESSORES FAZEM NO USO DA TECNOLOGIA

CULTURA OU FERRAMENTA: O DILEMA DA APROPRIAÇÃO QUE OS PROFESSORES FAZEM NO USO DA TECNOLOGIA CULTURA OU FERRAMENTA: O DILEMA DA APROPRIAÇÃO QUE OS PROFESSORES FAZEM NO USO DA TECNOLOGIA Aluna: Tatiana de Alemar Rios Orientador: Magda Pischetola Introdução A partir do estudo realizado pelo Grupo

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

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

Por Carol Alvarenga, em 17 de junho de 2014, 15h Esquemaria.com.br

Por Carol Alvarenga, em 17 de junho de 2014, 15h Esquemaria.com.br Esquemaria.com.br / Dicas de estudos / 4 mitos sobre estudos: saiba mais como evitar estes erros Talvez você conheça estes mitos sobre estudos, mas você sabe a verdade por trás deles? Hoje eu trago um

Leia mais

A APLICAÇÃO FOI DRASTICAMENTE REDUZIDA

A APLICAÇÃO FOI DRASTICAMENTE REDUZIDA Bernardo Leite AVALIAÇÃO DE DESEMPENHO HÁ TEMPOS... Objetivos principais: Aumento de salário Demissão CONCLUSÃO: A APLICAÇÃO FOI DRASTICAMENTE REDUZIDA A AVALIAÇÃO DE DESEMPENHO É um processo natural e

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

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

4 A resenha de filme na visão dos usuários do gênero

4 A resenha de filme na visão dos usuários do gênero 4 A resenha de filme na visão dos usuários do gênero Neste capítulo, apresentamos a análise dos dados oriundos do contato estabelecido com leitores, editores e críticos, a fim de conhecermos sua visão

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

CENTRO DE MEMÓRIA DO ESPORTE ESCOLA DE EDUCAÇÃO FÍSICA UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL PROJETO GARIMPANDO MEMÓRIAS

CENTRO DE MEMÓRIA DO ESPORTE ESCOLA DE EDUCAÇÃO FÍSICA UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL PROJETO GARIMPANDO MEMÓRIAS CENTRO DE MEMÓRIA DO ESPORTE ESCOLA DE EDUCAÇÃO FÍSICA UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL PROJETO GARIMPANDO MEMÓRIAS JOÃO DANILO BATISTA DE OLIVEIRA E CARLOS ALEXANDRE ANDRADE DOS SANTOS (depoimento)

Leia mais

Consórcio. Imobiliário. na prática. Por que o consórcio é muito mais interessante do que o financiamento? Livre-se dos Juros!

Consórcio. Imobiliário. na prática. Por que o consórcio é muito mais interessante do que o financiamento? Livre-se dos Juros! Consórcio Imobiliário na prática Por que o consórcio é muito mais interessante do que o financiamento? Livre-se dos Juros! 1 Sobre a empresa A A+ Consórcios iniciou suas atividades com o objetivo de gerir

Leia mais

Realizado a partir do Roteiro para grupo focal com monitores - Pesquisa UCA/BA [Escola CETEP/Feira de Santana] 1

Realizado a partir do Roteiro para grupo focal com monitores - Pesquisa UCA/BA [Escola CETEP/Feira de Santana] 1 Realizado a partir do Roteiro para grupo focal com monitores - Pesquisa UCA/BA [Escola CETEP/Feira de Santana] Categorias Apresentação do instrumento [-] Mobilidade/ portabilidade [,] 0 0 Transcrição Alguns

Leia mais

Vamos poupar dinheiro!

Vamos poupar dinheiro! Módulo 2 Unidade 8 Vamos poupar dinheiro! Para início de conversa... Observe a história em quadrinho abaixo: Matemática e suas Tecnologias Matemática 33 Todos nós sabemos que é muito bom guardar um dinheirinho

Leia mais

CALL com Mercado Projeto Integração das Clearings Processo de Certificação 07/06/2013

CALL com Mercado Projeto Integração das Clearings Processo de Certificação 07/06/2013 CALL com Mercado Projeto Integração das Clearings Processo de Certificação 07/06/2013 A implantação da integração das clearings da BM&FBOVESPA e do novo sistema de risco CORE (Closeout Risk Evaluation)

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

Qualidade de software

Qualidade de software Faculdade de Ciências Sociais e Aplicadas de Petrolina - FACAPE Curso: Ciência da Computação Disciplina:Projeto de Sistemas Qualidade de software cynaracarvalho@yahoo.com.br Qualidade de software Qualidade

Leia mais

MUDANÇA CULTURAL NAS ORGANIZAÇÕES

MUDANÇA CULTURAL NAS ORGANIZAÇÕES 1 MUDANÇA CULTURAL NAS ORGANIZAÇÕES Wainy Indaiá Exaltação Jesuíno 1 Marco Antônio 2 Resumo O objetivo deste trabalho é demonstrar a importância da análise do clima organizacional para mudança da cultura

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

Engenharia de Software III

Engenharia de Software III Engenharia de Software III Casos de uso http://dl.dropbox.com/u/3025380/es3/aula6.pdf (flavio.ceci@unisul.br) 09/09/2010 O que são casos de uso? Um caso de uso procura documentar as ações necessárias,

Leia mais

1 Introdu ç ão. 1.1. A questão de pesquisa

1 Introdu ç ão. 1.1. A questão de pesquisa 1 Introdu ç ão 1.1. A questão de pesquisa A temática estratégia é muito debatida no meio acadêmico e também possui destacado espaço nas discussões no meio empresarial. Organizações buscam continuamente

Leia mais

1. IDENTIFICAÇÃO DO CURSO

1. IDENTIFICAÇÃO DO CURSO 1. IDENTIFICAÇÃO DO CURSO O Curso de Secretariado Executivo das Faculdades Integradas de Ciências Exatas Administrativas e Sociais da UPIS, reconhecido pelo MEC desde 1993, pela Portaria 905, de 24.06,1993,

Leia mais

Orientações para a elaboração dos projetos de pesquisa (Iniciação científica)

Orientações para a elaboração dos projetos de pesquisa (Iniciação científica) GRUPO PAIDÉIA FE/UNICAMP Linha: Episteduc Coordenador: Prof. Dr. Silvio Sánchez Gamboa Orientações para a elaboração dos projetos de pesquisa (Iniciação científica) Os projetos de pesquisa se caracterizam

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

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

de sistemas para recuperação de informação em interfaces de bibliotecas online.

de sistemas para recuperação de informação em interfaces de bibliotecas online. 1 Introdução Na época atual, as certezas definitivas já deram sinais de cansaço e à medida que avança a tecnologia, a sociedade se reformula. O conhecimento estabelecido durante séculos antes confinados

Leia mais

ROTEIRO PARA OFICINA DE ANALISE DO DESEMPENHO ESCOLAR E ELABORAÇÃO DO PLANO DE ENSINO

ROTEIRO PARA OFICINA DE ANALISE DO DESEMPENHO ESCOLAR E ELABORAÇÃO DO PLANO DE ENSINO ROTEIRO PARA OFICINA DE ANALISE DO DESEMPENHO ESCOLAR E ELABORAÇÃO DO PLANO DE ENSINO DOCUMENTOS BÁSICOS: - Cadernos Paebes; - Ata de resultados finais da Escola em 2010; - Guia de Intervenção Pedagógica;

Leia mais

Projetos na área de TI. Prof. Hélio Engholm Jr

Projetos na área de TI. Prof. Hélio Engholm Jr Projetos na área de TI Prof. Hélio Engholm Jr Projetos de Software Ciclo de Vida do Projeto Concepção Iniciação Encerramento Planejamento Execução e Controle Revisão Ciclo de Vida do Produto Processos

Leia mais

Presidência da República Casa Civil Secretaria de Administração Diretoria de Gestão de Pessoas Coordenação Geral de Documentação e Informação

Presidência da República Casa Civil Secretaria de Administração Diretoria de Gestão de Pessoas Coordenação Geral de Documentação e Informação Presidência da República Casa Civil Secretaria de Administração Diretoria de Gestão de Pessoas Coordenação Geral de Documentação e Informação Coordenação de Biblioteca 50 Discurso na cerimónia de lançamento

Leia mais

O que é e como encontrar uma oportunidade?

O que é e como encontrar uma oportunidade? CRIAÇÃO DE NOVOS NEGÓCIOS Danillo Tourinho Sancho da Silva, MSc O que é e como encontrar uma oportunidade? CRIAÇÃO DE NOVOS NEGÓCIOS É mais fácil perceber uma carência ou uma necessidade do que uma oportunidade.

Leia mais

MANUAL DE PROCEDIMENTOS MPR/SIA-015-R00

MANUAL DE PROCEDIMENTOS MPR/SIA-015-R00 MANUAL DE PROCEDIMENTOS MPR/SIA-015-R00 PLANEJAMENTO E ACOMPANHAMENTO DO ORÇAMENTO DA SIA 07/2013 PÁGINA INTENCIONALMENTE EM BRANCO 2 Brasília, 29 de julho de 2013. Aprovado, Fabio Faizi Rahnemay Rabbani

Leia mais

10 segredos para falar inglês

10 segredos para falar inglês 10 segredos para falar inglês ÍNDICE PREFÁCIO 1. APENAS COMECE 2. ESQUEÇA O TEMPO 3. UM POUCO TODO DIA 4. NÃO PRECISA AMAR 5. NÃO EXISTE MÁGICA 6. TODO MUNDO COMEÇA DO ZERO 7. VIVA A LÍNGUA 8. NÃO TRADUZA

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

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

Introdução à Matemática Financeira. Valor do dinheiro no tempo. Moeda. Gastar X investir

Introdução à Matemática Financeira. Valor do dinheiro no tempo. Moeda. Gastar X investir Introdução à Matemática Financeira Valor do dinheiro no tempo Moeda Antes de detalharmos a Matemática Financeira, vejamos algumas definições sobre o que são moeda e capital. Moeda é o meio que facilita

Leia mais

1ª PERGUNTA: Na sua opinião, como deve ser a formação do trabalhador para o atual mercado de trabalho?

1ª PERGUNTA: Na sua opinião, como deve ser a formação do trabalhador para o atual mercado de trabalho? ANÁLISE DE CONTEÚDO ALUNOS 681 1ª PERGUNTA: Na sua opinião, como deve ser a formação do trabalhador para o atual mercado de trabalho? ANEXO 4 - ANÁLISE DE CONTEÚDO ALUNOS SUJEITO UNIDADE DE CONTEXTO UNIDADE

Leia mais

3 c m FACULDADE DE COLIDER-FACIDER ( NOME) 3 cm (TÍTULO DO PROJETO)

3 c m FACULDADE DE COLIDER-FACIDER ( NOME) 3 cm (TÍTULO DO PROJETO) 3 c m FACULDADE DE COLIDER-FACIDER ( NOME) 3 cm (TÍTULO DO PROJETO) 2 cm (arial / times roman 12 ) TIRAR NUMERAÇÃO PARA IMPRESSAO CAPA CIDADE/ESTADO 2 c m ANO (NOME) TÍTULO DO PROJETO) (arial / times roman

Leia mais

Escrita Eficiente sem Plágio

Escrita Eficiente sem Plágio Escrita Eficiente sem Plágio Produza textos originais com qualidade e em tempo recorde Ana Lopes Revisão Rosana Rogeri Segunda Edição 2013 Direitos de cópia O conteúdo deste livro eletrônico tem direitos

Leia mais

Documentos: Implementação de melhores práticas de solução de problemas de TI

Documentos: Implementação de melhores práticas de solução de problemas de TI Documentos: Implementação de melhores práticas de solução de problemas de TI Você pode aguardar o número de bilhetes de defeitos e o tempo para encerrar o bilhete e declinar à medida que a tecnologia de

Leia mais

Combinando a norma ISO 10006 e o guia PMBOK para garantir sucesso em projetos

Combinando a norma ISO 10006 e o guia PMBOK para garantir sucesso em projetos Combinando a norma ISO 10006 e o guia PMBOK para garantir sucesso em projetos Combining the ISO 10006 and PMBOK to ensure successful projects 1 Por Michael Stanleigh Tradução e adaptação para fins didáticos

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

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

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

Sistemas de Informação Gerencial SUPPLY CHAIN MANAGEMENT

Sistemas de Informação Gerencial SUPPLY CHAIN MANAGEMENT CIÊNCIAS CONTÁBEIS e ADMINISTRAÇÃO Sistemas de Informação Gerencial SUPPLY CHAIN MANAGEMENT maio/2014 APRESENTAÇÃO Em um ambiente onde a mudança é a única certeza e o número de informações geradas é desmedido,

Leia mais

DISCIPLINAS TEORIA DAS ORGANIZAÇÕES:

DISCIPLINAS TEORIA DAS ORGANIZAÇÕES: DISCIPLINAS TEORIA DAS ORGANIZAÇÕES: A Teoria das Organizações em seu contexto histórico. Conceitos fundamentais. Abordagens contemporâneas da teoria e temas emergentes. Balanço crítico. Fornecer aos mestrandos

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

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

MPA 015 Fundamentos de Sistemas de Informação

MPA 015 Fundamentos de Sistemas de Informação MPA 015 Fundamentos de Sistemas de Informação UNIFEI Universidade Federal de Itajubá Mestrado Profissional em Administração Prof. Dr. Alexandre Ferreira de Pinho Prof. Dr. Fábio Favaretto 1 Informações

Leia mais

SISTEMATIZAÇÂO DOS TIPOS DE INFORMAÇÂO DO PLANEJAMENTO ESTRATÉGICO EMPRESARIAL E DE TECNOLOGIA DA INFORMAÇÂO E COMUNICAÇÂO

SISTEMATIZAÇÂO DOS TIPOS DE INFORMAÇÂO DO PLANEJAMENTO ESTRATÉGICO EMPRESARIAL E DE TECNOLOGIA DA INFORMAÇÂO E COMUNICAÇÂO SISTEMATIZAÇÂO DOS TIPOS DE INFORMAÇÂO DO PLANEJAMENTO ESTRATÉGICO EMPRESARIAL E DE TECNOLOGIA DA INFORMAÇÂO E COMUNICAÇÂO Danilo Freitas Silvas Sistemas de informação CEATEC danilofs.ti@gmail.com Resumo:

Leia mais

www.projetode redes.co m.br www.redesde com p uta dores. com. br

www.projetode redes.co m.br www.redesde com p uta dores. com. br Outras Apostilas em: www.projetode redes.co m.br www.redesde com p uta dores. com. br Centro Universitário Geraldo di Biase 1. Sistemas, Processos e Informações Ao observarmos o funcionamento de um setor

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 ALUNOS COM DEFICIÊNCIA NA ESCOLA REGULAR: UM ESTUDO SOBRE A VISAO DE PROFESSORES SOBRE A INCLUSÃO

Leia mais

A Paralisia Decisória.

A Paralisia Decisória. A Paralisia Decisória. Começo este artigo com uma abordagem um pouco irônica, vinda de uma amiga minha, que, inconformada como a humanidade vêm se portando perante a fé em algo superior, soltou a máxima

Leia mais

Como é ser aprovado no vestibular de uma Universidade Pública, em que sabemos da alta concorrência entre os candidatos que disputam uma vaga?

Como é ser aprovado no vestibular de uma Universidade Pública, em que sabemos da alta concorrência entre os candidatos que disputam uma vaga? Abdias Aires 2º Ano EM Arthur Marques 2º Ano EM Luiz Gabriel 3º Ano EM Como é ser aprovado no vestibular de uma Universidade Pública, em que sabemos da alta concorrência entre os candidatos que disputam

Leia mais

Antônio Carlos Ribeiro (antonilos@gmail.com) Unifal - Universidade Federal de Alfenas Deptº de Ciências Humanas e Letras Professor de Ciência

Antônio Carlos Ribeiro (antonilos@gmail.com) Unifal - Universidade Federal de Alfenas Deptº de Ciências Humanas e Letras Professor de Ciência Antônio Carlos Ribeiro (antonilos@gmail.com) Unifal - Universidade Federal de Alfenas Deptº de Ciências Humanas e Letras Professor de Ciência Política Estudo comparado: FOCCO/AL; FOCCO/PE; FOCCO/PB. Entrevistas

Leia mais