Embed Size (px)
Citation preview
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA DE PRODUÇÃO E
SISTEMAS
André Victor Cândido
PROPOSIÇÃO DE SISTEMÁTICA DE MELHORIAS DE
PROCESSOS COM BASE NO LEAN OFFICE E NO
GERENCIAMENTO ÁGIL DE PROJETOS: UMA PESQUISA-
AÇÃO EM UMA EMPRESA DE DESENVOLVIMENTO DE
SOFTWARE
Trabalho de Conclusão de Curso
apresentado ao Departamento de
Engenharia de Produção e Sistemas da
Universidade Federal de Santa
Catarina, como requisito parcial para
obtenção do título em Engenharia
Civil, habilitação Produção Civil.
Orientadora: Prof.ª Marina Bouzon
Florianópolis
2017
Ficha de identificação da obra elaborada pelo autor, através do Programa de Geração Automática da Biblioteca Universitária da UFSC.
Cândido, André Victor Proposição de sistemática de melhorias deprocessos com base no lean office e nogerenciamento ágil de projetos : uma pesquisa-açãoem uma empresa de desenvolvimento de software /André Victor Cândido ; orientadora, Prof.ª Marina Bouzon, 2017. 140 p.
Trabalho de Conclusão de Curso (graduação) -Universidade Federal de Santa Catarina, CentroTecnológico, Graduação em Engenharia Civil,Florianópolis, 2017.
Inclui referências.
1. Engenharia Civil. 2. Lean Office. 3.Gerenciamento Ágil de Processos. 4. Processo ágilenxuto. I. Bouzon, Prof.ª Marina . II. UniversidadeFederal de Santa Catarina. Graduação em EngenhariaCivil. III. Título.
Este trabalho é dedicado exclusivamente à
minha família, evidenciando meus pais
Marco e Andréia por todo apoio, carinho,
compreensão, motivação e confiança
depositados em mim. Dedico também a
minha orientadora Marina, meu supervisor
Alexandro, ao meu co-orientador Demis e
minha namorada Helen pelo grande auxílio
na realização deste trabalho.
RESUMO
Em busca de competitividade e flexibilidade, as empresas têm
necessitado tornar seus processos produtivos mais enxutos e ágeis. Neste
sentido, podem oferecer o valor esperado pelo cliente através de suas
atividades ao avaliarem constantemente seus processos internos, além de
rápida resposta às mudanças externas. O objetivo da presente pesquisa é
a proposição de uma sistemática de melhorias de processos em uma
empresa de desenvolvimento de softwares com base nos conceitos de
lean office e gerenciamento ágil de projetos, a fim de reduzir o tempo de
desenvolvimento e desperdícios em projetos de sistemas. A sistemática
consistiu na escolha do setor de maior relevância e maior inter-relação
com as demais áreas – o Setor de Qualidade de Softwares da organização
– como piloto na implementação das melhorias, com a proposição de
expandi-las posteriormente aos setores participantes do fluxo de
desenvolvimento do produto, visando melhorias nos processos da
empresa como um todo. As etapas da sistemática avaliaram os processos
internos, assim como o fluxo geral de desenvolvimento de sistemas;
foram mapeados os fluxos informacionais relacionados aos processos
internos da equipe e mapeado o fluxo de valor para o estado atual dos
processos. A seguir, foram feitos levantamento, classificação e
eliminação de todas as atividades não agregadoras de valor aos
processos internos da equipe, assim como a elaboração de um plano de
ações com base na mentalidade enxuta e no framework Scrum para
propor melhorias e a redução do tempo de desenvolvimento atual de
produtos. A sistemática apresentou como resultado um processo ágil-
enxuto para a Equipe de Qualidade, bem como fluxo de valor para o
estado futuro com redução significativa no tempo de desenvolvimento
dos processos da equipe. A sistemática foi validada com a empresa e
suas ações serão implementadas.
Palavras-chave: Lean Office. Gerenciamento Ágil de Processos.
Processo ágil-enxuto.
ABSTRACT
In search of competitiveness and flexibility, companies have been in
need of developing lean and agile processes each day. In that respect,
they can offer customers‟ expected value through their own activities by
constantly evaluating their internal processes, in addition to quick
responses to external changes. This work proposes a systematics for
process improvements in a software development company based on
lean office and agile process management concepts, with the aim of
reducing development cycle time, and process waste. The systematics
consisted of choosing the sector that reported the highest relevance and
highest interrelation with other areas – Software Quality Sector – as a
pilot in the improvements implementation, with the proposition of
posteriorly expanding them to other sectors who participate in the
products development flow, addressed at improvements in the company
as a whole. The steps contained in the systematics assessed internal
processes, as well as the general system development flow; information
flows relating to internal processes of the team were mapped. Next, a
collection, classification and elimination of all non-aggregated activities
of value to the team's internal processes was done, such as an action plan
based on lean mentality and the scrum framework to propose
improvements and reduction of products current development time. The
method resulted in lean agile processes in the Quality Team, and a
Future State Value Stream Map with meaningful reduction in products
development time. The systematics was validated along with the
company and actions are being implemented.
Keywords: Lean Office. Agile Process Management. Lean Processes.
LISTA DE FIGURAS
Figura 1 - Modelo Ecologia da Informação ........................................... 31
Figura 2 - Fluxo da Informação .............................................................. 32
Figura 3 - Visão Geral de Scrum ............................................................ 46
Figura 4 - Convergência entre os temas abordados ................................ 50
Figura 5 - Enquadramento Metodológico .............................................. 52
Figura 6 - Etapas da Pesquisa ................................................................. 55
Figura 7 - Ilustração da Sistemática ....................................................... 62
Figura 8 - Impedimentos e Desperdícios Prévios ................................... 66
Figura 9 - Organograma da Equipe ........................................................ 67
Figura 10 - Atividades da Equipe de Qualidade de Software ................. 69
Figura 11 - Fluxo "Porta-a-Porta" .......................................................... 73
Figura 12 - Inter-relação entre setores .................................................... 76
Figura 13 - Mapeamento do Fluxo de Valor - Estado Atual .................. 87
Figura 14 - Interface do Gitlab ............................................................. 102
Figura 15 - Mapeamento do Fluxo de Valor - Estado Futuro .............. 110
LISTA DE TABELAS
Tabela 1 - Taxa de Valor Agregado das Atividades ............................... 80
Tabela 2 - Lead time do Processo Inicial de Teste de Software ............. 83
Tabela 3 - Lead time do Processo de Validação de Correções ............... 84
Tabela 4 - Lead time do Processo de Auxílio à Elaboração de Materiais
(Apostila)................................................................................................ 85
Tabela 5 - Lead time do Processo de Auxílio à Elaboração de Materiais
(Manual) ................................................................................................. 86
Tabela 6 - Eliminação e Redução de Tempo das Atividades ................. 95
Tabela 7 - Lead time do Processo Inicial de Teste de Software com
Redução .................................................................................................. 97
Tabela 8 - Lead time do Processo de Validação de Correções com
Redução .................................................................................................. 98
Tabela 9 - Lead time do Processo de Auxílio à Elaboração de Materiais
(Manual de Usabilidade) com Redução ................................................. 99
Tabela 10 - Lead time do Processo de Auxílio à Elaboração de Materiais
(Apostila) com Redução ....................................................................... 100
LISTA DE QUADROS
Quadro 1 - Disposição Geral de Capítulos e Objetivos ......................... 24
Quadro 2 - Gestão da Informação .......................................................... 29
Quadro 3 - Lean Manufacturing x Lean Office ...................................... 36
Quadro 4 - Gerenciamento Tradicional x Gerenciamento Ágil ............. 43
Quadro 5 - Papeis do framework scrum ................................................. 46
Quadro 6 - Coleta de Dados ................................................................... 57
Quadro 7 - Etapas da Sistemática de Melhoria ...................................... 60
Quadro 8 - Relação dos desperdícios prévios com a literatura ............... 66
Quadro 9 - Levantamento e Classificação dos Desperdícios Encontrados
................................................................................................................ 89
Quadro 10 - Plano de Ações de Melhorias ........................................... 104
SUMÁRIO
1. INTRODUÇÃO ............................................................................... 21
1.1 CONTEXTUALIZAÇÃO E JUSTIFICATIVA ............................... 21
1.2 MOTIVAÇÃO ................................................................................. 22
1.3 OBJETIVOS .................................................................................... 23
1.3.1 Objetivo geral ............................................................................. 23
1.3.2 Objetivos específicos .................................................................. 23
1.4 DELIMITAÇÃO DO TRABALHO ................................................. 24
1.5 ESTRUTURA DO TRABALHO ..................................................... 24
2. FUNDAMENTAÇÃO TEÓRICA .................................................. 27
2.1 GESTÃO DA INFORMAÇÃO........................................................ 27
2.1.1 Fluxos Informacionais ................................................................ 28
2.1.2 Competências da Gestão da Informação .................................. 28
2.1.3 Modelos de Gestão da Informação ............................................ 30
2.2 LEAN OFFICE ................................................................................ 33
2.2.1 Competências do Lean Office .................................................... 33
2.2.2 Princípios do Lean Office ........................................................... 34
2.2.3 Lean Manufacturing x Lean Office .......................................... 35
2.2.4 Metodologia ................................................................................ 37
2.3 GERENCIAMENTO ÁGIL DE PROJETOS .................................. 40
2.3.1 Gerenciamento tradicional x Gerenciamento Ágil .................. 42
2.3.2 A ferramenta Scrum ................................................................... 43
2.3.3 Os atores do Scrum ..................................................................... 46
2.4 CONVERGÊNCIAS ENTRE AS ABORDAGENS DO LEAN OFFICE E DO GERENCIAMENTO ÁGIL DE PROJETOS ............... 48
3. MÉTODOS DA PESQUISA ........................................................... 51
3.1 ENQUADRAMENTO METODOLÓGICO .................................... 51
3.1.1 Enquadramento pelos objetivos ................................................ 53
3.1.2 Enquadramento pela abordagem .............................................. 53
3.1.3 Enquadramento pelos procedimentos ...................................... 53
3.2 PESQUISA-AÇÃO .......................................................................... 54
3.2.1 Estudo dos Fundamentos Teóricos ........................................... 55
3.2.2 Coleta de dados .......................................................................... 55
3.2.3 Análise de dados ......................................................................... 57
3.2.4 Proposição da Sistemática de Melhorias .................................. 57
3.2.5 Validação da Sistemática com a Empresa................................ 58
4. SISTEMÁTICA DE MELHORIAS ............................................... 59
4.1 OBJETIVOS DA SISTEMÁTICA DE MELHORIAS .................... 62
5. RESULTADOS ................................................................................ 63
5.1 A ORGANIZAÇÃO ........................................................................ 63
5.2 DESCRIÇÃO DO PROCESSO DE DESENVOLVIMENTO DE
SOFTWARES ......................................................................................... 63
5.3 OBJETO DE ESTUDO .................................................................... 64
5.3.1 Equipe de Qualidade de Software ............................................. 67
5.3.2 Atividades da Equipe de Qualidade de Software ..................... 67
5.4 DADOS ............................................................................................ 70
5.4.1 Considerações iniciais ................................................................ 70
5.4.2 Coleta dos Dados ........................................................................ 71
5.5 ESTADO ATUAL ........................................................................... 72
5.5.1 Mapeamento do Fluxo Geral de Desenvolvimento de Softwares
.............................................................................................................. 72
5.5.2 Processos da Equipe de Qualidade de Software....................... 73
5.5.3 Mapeamento do Fluxo de Informações dos processos da Equipe de Qualidade de Software ...................................................... 78
5.5.4 Atividades Agregadoras de Valor ............................................. 79
5.5.5 Taxa de Valor Agregado ............................................................ 80
5.5.6 Lead Time dos Processos da Equipe de Qualidade de Software
.............................................................................................................. 82
5.6 ESTADO FUTURO ......................................................................... 88
5.6.1 Identificação e Classificação dos Desperdícios ........................ 88
5.6.2 Restruturação da Equipe – Gerenciamento Ágil de Projetos 93
5.6.3 Eliminação das Atividades Não Agregadoras de Valor .......... 95
5.6.4 Tecnologia da Informação ....................................................... 100
5.6.5 Plano de Ações .......................................................................... 103
5.6.6 Mapeamento do Fluxo Geral de Desenvolvimento de Softwares
(Estado Futuro) ................................................................................. 108
5.6.7 Mapeamento dos Processos da Equipe (Estado Futuro) ....... 108
5.6.8 Mapeamento do Fluxo de Valor (Estado Futuro).................. 109
5.7 REPETIÇÃO DA SISTEMÁTICA – MELHORIA CONTÍNUA NA
ORGANIZAÇÃO COMO UM TODO ................................................ 111
5.8 AJUSTES NA SISTEMÁTICA ..................................................... 111
6. CONSIDERAÇÕES FINAIS........................................................ 113
REFERÊNCIAS ................................................................................ 117
APÊNDICE ........................................................................................ 123
APÊNDICE A - LEVANTAMENTO DE DADOS RELACIONADOS
ÀS ATIVIDADES DOS PROCESSOS DA EQUIPE ......................... 125
APÊNDICE B – MAPEAMENTO DO FLUXO GERAL DE
DESENVOLVIMENTO DE SISTEMA .............................................. 128
APÊNDICE C – MAPEAMENTO DO PROCESSO INICIAL DE
TESTES NOS SISTEMAS .................................................................. 129
APÊNDICE D – MAPEAMENTO DO PROCESSO DE VALIDAÇÃO
DE CORREÇÕES NOS SISTEMAS DESENVOLVIDOS ................. 130
APÊNDICE E – MAPEAMENTO DO PROCESSO DE AUXÍLIO À
ELABORAÇÃO DE MATERIAIS PARA O CLIENTE..................... 131
APÊNDICE F – INFORMAÇÕES DE ENTRADA E SAÍDA PARA OS
PROCESSOS DA EQUIPE DE QUALIDADE DE SOFTWARE ....... 132
APÊNDICE G – FLUXOS INFORMACIONAIS POR PROCESSO . 135
Processo Inicial de Testes nos Sistemas ........................................... 135
Processo de Validação de Correções nos Sistemas Desenvolvidos 136
Processo de Auxílio à Elaboração de Materiais para o Cliente ..... 137
APÊNDICE H – MAPEAMENTO DO FLUXO GERAL DE
DESENVOLVIMENTO DE SISTEMAS – ESTADO FUTURO ....... 139
APÊNDICE I – MAPEAMENTO DOS PROCESSOS DA EQUIPE DE
QUALIDADE DE SOFTWARE – ESTADO FUTURO ...................... 140
21
1. INTRODUÇÃO
Neste capítulo é apresentado de maneira introdutória o contexto,
objetivos e estrutura desta monografia de conclusão de curso.
1.1 CONTEXTUALIZAÇÃO E JUSTIFICATIVA
Constantemente, as empresas buscam maneiras de se
diferenciarem no mercado em que atuam visando a competitividade e entrega de valor aos seus clientes. Uma destas maneiras se baseia na
constante avaliação de seus processos internos ao eliminar os
desperdícios comumente encontrados em um ambiente organizacional,
deixando-os cada vez mais enxutos.
No presente trabalho será estudado um ambiente de
desenvolvimento de softwares de uma empresa de pequeno porte, cuja
problemática se dá na ausência de processos de trabalho bem definidos e
a baixa flexibilidade em sua produção. A partir disto, o objetivo será a
definição de processos internos enxutos e ágeis através da proposição de
uma sistemática de melhorias com base nos conceitos originados da
mentalidade enxuta e do gerenciamento ágil de projetos. Atualmente, os
princípios e filosofias de produção enxuta são aplicados principalmente
na manufatura, na busca da redução de custos, aumento da produtividade
e garantia de competitividade.
Porém, segundo Tapping e Shuker (2010), não é suficiente a
escolha de uma área específica para ser enxuta, o que muitas vezes
ocorre na manufatura, a qual negligencia a área administrativa. Seguindo
o raciocínio, ainda de acordo com Tapping e Shuker (2010), os
processos internos de uma organização são os responsáveis por sessenta
a oitenta por cento dos custos associados ao atendimento da demanda do
cliente e raramente se baseia nos princípios enxutos. Desta forma, o lean
office visa o aumento da taxa de valor agregado dos processos internos
das organizações, sendo uma metodologia voltada para a gestão de
processos informacionais, não ligados a materiais, mas sim a
informações (HERKOMMER; HERKOMMER, 2006).
Contudo, possuir seus processos internos de trabalho organizados
não garante a uma organização uma maior competitividade. É necessário, além disto, possuir a capacidade de se adaptar a um mercado
altamente dinâmico como o de hoje. Sendo assim, aumenta a
importância de a empresa ser eficaz no que diz respeito ao
gerenciamento ágil de seus projetos.
22
Frente ao contexto apresentado, o objetivo da pesquisa é a
verificação das possibilidades de melhorias no fluxo informacional e
processos internos de trabalho em uma empresa desenvolvedora de
software, propondo uma sistemática de melhorias sob o ponto de vista
do lean office e do gerenciamento ágil de projetos para a aplicação no
setor de Qualidade de Software da organização.
A área de pesquisa desse trabalho situa-se dentro da área das
Engenharias, mais especificamente na área de Engenharia
Organizacional. Segundo a ASSOCIAÇÃO BRASILEIRA DE
ENGENHARIA DE PRODUÇÃO (2008), nessa área encontram-se as
subáreas de conhecimento relacionadas à gestão das organizações,
englobando em seus tópicos o planejamento estratégico e operacional, as
estratégias de produção, a gestão empreendedora, gestão de projetos, a
avaliação de desempenho organizacional, os arranjos produtivos e os
sistemas de informação e sua gestão.
1.2 MOTIVAÇÃO
O tema relacionado a pesquisa surgiu a partir da atual necessidade
da organização em questão. Em um ambiente de desenvolvimento de
softwares, os requisitos estão sujeitos a frequentes mudanças durante o
ciclo de desenvolvimento do produto para atender às alterações
demandadas pelo cliente, tendo ainda como agravante a restrição de seus
recursos (CARVALHO; MELLO, 2012). Desta forma, uma empresa que
visa atender a alterações e novas demandas solicitadas pelos clientes
com rapidez e objetividade precisa possuir um processo de trabalho bem
definido, enxuto e ágil. Esta é a maior motivação da presente pesquisa,
uma vez que o ambiente em questão carece não somente da definição de
processos internos de trabalho, mas que estes apresentem as
características citadas.
Como dito anteriormente, a empresa estudada não conta com
processos internos de trabalho bem definidos e documentados para a
execução de suas atividades de desenvolvimento de softwares, além de
possuir deficiências no gerenciamento de projetos e fluxo informacional.
Como cada demanda de software a ser desenvolvida é considerada um
projeto e estes estão em crescente aumento, a organização apresenta a preocupação em definir seus processos visando a alta competitividade e
agilidade.
Tendo em vista que a melhoria global dos processos de uma
organização é gradativa, a estratégia adotada na presente pesquisa será a
aplicação do estudo no setor de maior relevância para a organização,
23
com maior inter-relação com as demais áreas. O setor de Qualidade de
Software, local onde será aplicada a sistemática de melhorias, é o
principal indicador dos problemas citados anteriormente, motivo este da
escolha da área de aplicação da pesquisa, uma vez que ao definir um
processo enxuto de trabalho para este setor com base nos princípios do
lean office e gerenciamento ágil de projetos, as demais áreas da
organização também serão atingidas e serão os próximos alvos da
aplicação da sistemática de melhorias. Diante dos problemas
encontrados e necessidades na organização em estudo, os conceitos de
mentalidade enxuta e gerenciamento ágil de projetos surgem como as
principais ferramentas na proposição de melhorias.
1.3 OBJETIVOS
Com o propósito de responder a problemática, serão apresentados
neste capítulo os objetivos a serem atingidos ao longo do trabalho.
1.3.1 Objetivo geral
Propor uma sistemática de melhoria de processos com base nos
conceitos de lean office e gerenciamento ágil de projetos em uma
organização de desenvolvimento de softwares.
1.3.2 Objetivos específicos
Buscar na literatura os principais conceitos e ferramentas
para reduzir os desperdícios em ambiente de escritório das
filosofias lean office e gerenciamento ágil de projetos,
utilizando a Gestão da Informação como suporte;
Identificar os pontos de convergência entre as filosofias
abordadas e adaptar as melhores práticas de cada uma para o
ambiente em estudo;
Propor uma sistemática de melhorias para o ambiente em
estudo para atingir o estado futuro desejado com base no
lean office e no Gerenciamento Ágil de Projetos;
Realizar uma iteração da sistemática de melhorias em um
setor da organização;
Validar e propor aos líderes da organização a melhoria
contínua na organização, visando novas iterações da
sistemática nos demais setores da empresa.
24
1.4 DELIMITAÇÃO DO TRABALHO
A fim de garantir o caráter científico da presente pesquisa, faz-se
relevante a citação de algumas delimitações relacionadas à metodologia
utilizada, assim como referenciais teóricos escolhidos.
Para a coleta de dados quantitativos para o presente trabalho,
foram utilizados os dados fornecidos pela empresa de acordo com a
disponibilidade destes. Quanto à confiabilidade dos dados, o presente
autor acredita na plenitude e sensatez da organização, ainda que exista a
alta preocupação com o sigilo de informações por parte da empresa.
Deve-se ressaltar ainda o não conhecimento, por parte do autor,
de outros trabalhos possuindo o mesmo método proposto na presente
pesquisa, a não ser a utilização dos temas escolhidos para outros fins,
sendo estes citados ao longo do trabalho.
1.5 ESTRUTURA DO TRABALHO
A presente pesquisa é disposta em 5 capítulos. O Quadro 1
apresenta cada um dos objetivos traçados e como cada capítulo atinge
esse objetivo.
Quadro 1 - Disposição Geral de Capítulos e Objetivos
Capítulo e Descrição Objetivo a ser atingido
Capítulo 1 – Introdução
Apresentar, de maneira introdutória,
o contexto, objetivos e estrutura dessa
monografia de conclusão de curso.
Capítulo 2 – Fundamentação
Teórica
Com base em pesquisas realizadas em
obras de diversos autores com
especialidade no assunto, este
capítulo apresenta as definições dos
principais conceitos abordados:
Gestão da Informação, Lean Office e
Gerenciamento Ágil de Projetos.
Objetivo 1
Buscar na literatura os principais
conceitos, filosofias e ferramentas
para reduzir os desperdícios em
ambiente de escritório das filosofias
lean office e gerenciamento ágil de
projetos, utilizando a Gestão da
Informação como suporte.
Objetivo 2
Identificar os pontos de
convergência entre as filosofias
abordadas e adaptar as melhores
práticas de cada uma para o
ambiente em estudo.
25
Capítulo 3 – Métodos de Pesquisa
Este capítulo descreve os métodos de
pesquisa científica adotados e as
etapas metodológicas utilizadas para
a obtenção dos dados necessários
para a realização do trabalho e suas
análises.
Capítulo 4 – Resultados
Apresentar a empresa analisada e o
setor escolhido para os estudos e
aplicação da sistemática de
melhorias, descrevendo
resumidamente a história da empresa,
as atividades desempenhadas pelo
setor escolhidos e processos
produtivos. Posteriormente, propor
uma sistemática com base nos
conceitos, filosofias e ferramentas do
Lean Office e Gerenciamento Ágil de
Projetos, usando como suporte a
Gestão de Informações, para melhoria
de processos do setor da empresa
escolhido para o estudo. Por fim,
propor novas iterações da sistemática
nos demais setores da organização.
Objetivo 3
Propor uma sistemática de
melhorias para o ambiente em
estudo para atingir o estado futuro
desejado com base no lean office e
no Gerenciamento Ágil de Projetos.
Objetivo 4
Realizar uma iteração da sistemática
de melhorias em um setor da
organização.
Objetivo 5
Validar e propor aos líderes da
organização a melhoria contínua na
organização, visando novas
iterações da sistemática nos demais
setores da empresa.
Capítulo 5 – Conclusão
Apresentar as conclusões e
considerações finais, revisando os
resultados obtidos ao longo de toda a
pesquisa. Por fim, expor as limitações
enfrentadas durante o trabalho, além
de sugestões para futuras pesquisas.
Fonte: Elaborado pelo autor.
5
26
27
2. FUNDAMENTAÇÃO TEÓRICA
Três principais elementos foram adotados como fundamentos para
este trabalho: Gestão da Informação, Lean Office e Gerenciamento Ágil
de Projetos.
O descritivo destes é apresentado nos subcapítulos que seguem.
2.1 GESTÃO DA INFORMAÇÃO
A Gestão da Informação consiste em adquirir informações
provindas de uma ou mais fontes, distribuir de maneira organizada
respeitando um fluxo lógico de atividades de um ambiente
organizacional e definir uma melhor alocação destas informações da
melhor forma possível para que estejam disponíveis no momento em que
forem requisitadas. Segundo Valentim (2008), a Gestão da Informação e
a Gestão do Conhecimento estão ativamente presentes em todas as
atividades desenvolvidas em um ambiente organizacional, servindo de
alicerces ao processo de tomada de decisões, planejamento, „fazer‟
organizacional e estratégias adotadas relacionadas a ações.
Valentim (2008) conceitua ainda gestão da informação como o
conjunto de atividades que têm como objetivo a obtenção de um
diagnóstico sobre as necessidades informacionais, mapeamento dos
fluxos de informação nos variados setores do ambiente organizacional
visando o apoio ao desenvolvimento das mais diversas atividades
cotidianas e processo decisório através da prospecção, coleta, filtro,
monitoramento e disseminação de informações provindas de diferentes
naturezas, contribuindo ainda na elaboração de serviços e sistemas
informacionais.
Araújo, Silva e Varvakis (2017) analisam o fluxo informacional
como um processo dinâmico de comunicação com o objetivo de que as
informações sejam transmitidas com um valor agregado de um agente
emissor a um ou vários agentes receptores, visando resposta para as
complexas necessidades informacionais e geração de conhecimento.
Conforme Choo (1998), a informação é um componente intrínseco de
todas as atividades realizadas por uma organização. O ambiente
organizacional que percebe o mais cedo possível o valor deste recurso e,
a partir de então, investe recursos para a organização e maior fluidez da
informação, certamente colherá muitos frutos no que diz respeito a
tomadas de decisão.
28
2.1.1 Fluxos Informacionais
De acordo com Tarapanoff (2001), é importante que se entenda
que a informação pode e deve ser gerida, sendo ainda o alicerce da
administração dos recursos de informação consistente da visão integrada
de todos os recursos que estão envolvidos no ciclo informativo,
incluindo a informação, recursos tecnológicos e humanos. A existência
destes fluxos informacionais é o resultado da relação entre dado,
informação, conhecimento e inteligência, sendo estes suportes ao
processo de tomada de decisão.
Os fluxos informacionais ocorrem de maneira natural pelos
setores e colaboradores que neles atuam através de atividades, tarefas e
processos decisórios. É necessário que a informação flua pelo ambiente
organizacional em que se encontra, impulsionando o desenvolvimento
de origem interna e até mesmo externa. A prioridade na administração
da informação, para muitas empresas, se difere da prioridade de
administração de seus recursos financeiros, humanos e materiais, o que
leva à dificuldade de realização da Gestão da Informação. A necessidade
de informação passa por todos os níveis hierárquicos - estratégico, tácito
e operacional - estando ligada diretamente ao saber e ao fazer de cada
um desses níveis. (CUNHA; PEREIRA; NEVES, 2015).
Quanto à categorização dos fluxos informacionais, as atividades
cotidianas desenvolvidas pelo ambiente organizacional tendem a se
repetir, sendo definidas por especificações claras e prévias, passíveis de
normalização. Estes fluxos de informação são de ordem estruturada, de
maneira formal. Geralmente, estas atividades circulam através das
diversas áreas da organização. Estes fluxos de informação estruturados
podem percorrer os setores da empresa de forma horizontal ou vertical,
variando com os níveis hierárquicos, sendo que cada um deles possui
demandas e necessidades específicas. Os fluxos informacionais servirão
de entrada para o desenvolvimento de atividades, além da efetividade e
ciência para tomadas de decisão. As atividades ditas não-estruturadas,
executadas de maneira informal, não são registradas e invisíveis aos
participantes do fluxo de atividades. Em geral, tais atividades são o
resultado de experiências e conhecimentos individuais de cada
colaborador (GREEF; FREITAS, 2012).
2.1.2 Competências da Gestão da Informação
É fundamental que o ambiente organizacional esteja bem
definido, sem que haja a possibilidade de redundâncias, inconsistências
ou informações incompletas, assim como barreiras, fluxo desorganizado,
29
informação sem qualidade e desordenada, o que aumenta os custos
operacionais e dificulta a comunicação entre os membros da organização
(GREEF; FREITAS, 2012).
Quadro 2 - Gestão da Informação
GESTÃO DA INFORMAÇÃO
Âmbito
Fluxos Formais
Objeto
Conhecimento explícito
Atividades ‘Base’
● Identificar necessidades e/ou demandas de informação;
● Mapear e reconhecer fluxos de informações formais;
● Desenvolver a cultura organizacional positiva em relação ao
compartilhamento e/ou socialização de informações;
● Proporcionar a comunicação informacional de forma eficiente, utilizando
tecnologias de informação e comunicação;
● Prospectar e monitorar informações;
● Coletar, selecionar e filtrar informações;
● Tratar, analisar, organizar, armazenar e agregar valor às informações
utilizando tecnologias de informação e comunicação;
● Desenvolver e implantar sistemas informacionais de diferentes naturezas,
visando o compartilhamento e o uso de informação;
● Elaborar sistemas e serviços informacionais;
● Elaborar e implantar normatizações visando à sistematização da informação
produzida interna e externamente;
● Retroalimentar o ciclo.
Fonte: VALENTIM (2008).
Ao realizar a Gestão da Informação, deve-se buscar a qualidade
informacional, não a quantidade. A maior importância da gerência dos
fluxos informacionais é o acesso às informações destinadas a atender as
necessidades internas e externas à organização, no tempo certo e com
custo coerente. Davenport (1998) aponta que o primeiro passo para se
inserir a Gestão da Informação em uma organização é a definição da
estratégia da empresa, passando pela escolha do sistema a ser criado,
qual mercado se pretende atingir e a que tipo de negócio deve-se
dedicar. O autor ainda apresenta as seguintes etapas para aplicação da
Gestão da Informação em um ambiente organizacional: determinação
30
das exigências informacionais, obtenção, distribuição e utilização da
informação.
Para a estruturação de programas ou modelos de Gestão da
Informação é necessário entender quais são as necessidades
informacionais dos usuários, assim como a forma como eles buscam e
utilizam esta informação. Logo, é de fundamental importância a
compreensão de como a informação é utilizada para o processo de
trabalho, visando competitividade e flexibilidade, além de um
gerenciamento eficiente. Para tal ação, identificar as necessidades de
informação deverá ser o primeiro passo. De acordo com Borges, Ferreira
e Silva (2002), o próprio indivíduo interessado deverá ter o
conhecimento sobre quais informações são úteis para ele em um dado
momento, sendo esta a informação necessária para a criação ou
determinação de um sistema ou processo. Para os autores, a informação
é a principal ferramenta de participação no processo de transferência de
conhecimento e, portanto, aprendizagem.
2.1.3 Modelos de Gestão da Informação
Dois modelos serão analisados no estudo da Gestão da
Informação em ambientes organizacionais: o modelo de Davenport
(1998) e o modelo de Choo (1998). Davenport (1998) propõe seu
modelo de Gestão da Informação referindo-se como Ecologia da
Informação, tratando a organização como um sistema ecológico, com
interdependências entre seus ambientes de trabalho e propondo uma
visão holística de pensamento. Estes sistemas foram chamados de
ambientes, e estes classificados em ambiente externo - o que abrange
todo o ambiente de negócios, ambiente organizacional - o espaço físico
que a organização necessita para a realização de suas tarefas, assim
como as tecnologias utilizadas, e o ambiente informacional, englobando
estratégia, cultura, política, arquitetura e processo. De acordo com a
Figura 1, o autor propõe um esquema que faz a menção de que o
ambiente informacional se insere nos outros dois ambientes citados,
mostrando ainda a interdependência entre os processos.
31
Figura 1 - Modelo Ecologia da Informação
Fonte: DAVENPORT (1998).
Davenport (1998) conceitua os seis itens atuantes no ambiente
informacional da seguinte maneira:
a) Estratégia da informação: Formulação de estratégias para
o uso da informação de forma relevante para a empresa;
b) Cultura e comportamento em relação à informação: Analisa o comportamento dos indivíduos envolvidos no que
diz respeito à informação no quesito valorização;
c) Política de informação: Poder da informação e como a
responsabilidade da direção no gerenciamento e uso;
d) Processos de gerenciamento da informação: Enfatização
igualitária entre aperfeiçoamento e mensurabilidade na
definição do gerenciamento da informação como processo;
e) Equipe especializada em informação: importância de se ter
uma equipe responsável pela informação no ambiente
organizacional, uma vez que as pessoas são os melhores
meios para identificação, filtro, categorização, integração e
interpretação da informação;
32
f) Arquitetura da informação: Mapa do ambiente
informacional no presente, sendo desta forma descrita, ou
ainda podendo ser determinista, ao oferecer um modelo do
ambiente em alguma época do futuro.
Choo (1998) modela a Gestão da Informação com base na
seguinte conceituação:
A Gestão da Informação é um conjunto de seis
processos distintos, mas inter-relacionados:
identificação de necessidades informacionais;
aquisição de informação; organização e
armazenamento da informação; desenvolvimento
de sistemas informacionais e serviços; distribuição
da informação e uso da informação. (CHOO,
1998, apud TARAPANOFF, 2001, p. 44).
O propósito deste conjunto de processos é a facilidade no acesso
das informações verdadeiramente relevantes ao negócio do ambiente
organizacional, evidenciando que o valor da informação é atribuído pelo
pessoal, sendo que, para ser de fato informação, precisa fazer sentido ao
receptor, ou seja, necessita de um significado. Segundo Choo (1998), o
valor da informação se dá na relação construída pelo usuário desta entre
a própria informação e a si próprio. O autor em seu modelo de Gestão da
Informação organiza sua ideia através de um ciclo informacional,
partindo sempre da identificação das necessidades de informação e, logo
após isto, realização da coleta de informações a fim de satisfazer tais
necessidades. O próximo passo é organizar essas informações e
armazená-las de modo a facilitar o uso no momento em que forem
necessárias e com a intenção de utilização para processos decisórios.
Figura 2 - Fluxo da Informação
Fonte: Adaptado de Choo (1998).
Além disto, o modelo evidencia a necessidade de reavaliação
constante das informações necessárias ao ambiente de negócios, uma vez
que podem variar conforme a insuficiência de conhecimento dos
indivíduos envolvidos para tomadas de decisão.
33
2.2 LEAN OFFICE
O lean manufacturing popularmente conhecido como Manufatura
Enxuta, é um modelo de negócios que objetiva produzir sistemas e
serviços com alta qualidade, visando a redução ou eliminação de
desperdícios e de atividades que não agregam valor ao resultado final ao
longo de todo o processo produtivo. A implementação desta filosofia é
de origem estratégica para a organização, a qual busca competitividade
no mercado em que atua (TICE et al., 2005). De acordo com Turati e
Musetti (2006), com os bons resultados desta filosofia em organizações
manufatureiras, surgem oportunidades de expansão deste conceito para
os diferentes setores existentes.
O lean office, escritório enxuto, é a adequação do lean
manufacturing para as funções administrativas buscando a eliminação do
desperdício e perdas na estruturação e administração de ambientes de
escritório. O objetivo do pensamento relacionado ao escritório enxuto é
a redução ou eliminação dos desperdícios ligados ao fluxo de
informações, já que apenas 1% das informações que são geradas
agregam de fato valor (HINES et al., 2000). São aplicados os princípios
da mentalidade enxuta ao gerenciamento de materiais, pessoas, mas,
principalmente, nos fluxos de informação, baseando-se em padrões
culturais, visuais, operacionais e gerenciais (LAGO; CARVALHO;
RIBEIRO; 2008).
2.2.1 Competências do Lean Office
A simplificação de processos, conhecimento e flexibilização dos
fluxos de informação, redução de tempo, prazo e atendimento ao cliente,
estocagem nula e eliminação de esperas são tarefas relacionadas ao lean
office, visando a aceleração da velocidade dos processos de acordo com
análise do fluxo de valor agregado às atividades desenvolvidas pelo
ambiente organizacional. Com o lean office procura-se ainda a
minimização de perdas internas e, por consequência, redução dos custos
internos, permitindo maior competitividade sem que haja perda na
qualidade. O fluxo de valor para a aplicação da filosofia abordada pelo
lean office consiste no fluxo de informações e no fluxo de conhecimento
(MCMANUS, 2003). A importância do estudo do mapa de fluxo de valor está em atingir o estado enxuto do processo produtivo,
identificando os fluxos informacionais dentro de um setor ou
organização como um todo.
34
As atividades processadas pelas pessoas em um escritório são
envolvidas por processos, manipulação de dados, informações e
ferramentas visuais compartilhadas pelos colaboradores da empresa. A
ideia do lean office é fazer com que esta comunicação seja contínua, ou
seja, ininterrupta, com um estoque zero, no caso sem informação parada.
Tais atividades giram em torno da captação, criação, seleção,
armazenamento, distribuição, uso e descarte de informação A
dificuldade de mapear estes fluxos de informação é evidente, uma vez
que se trata de um caráter intangível no dia-a-dia, porém não impede o
estudo de suas possíveis entradas, processamento e saídas
informacionais (GREEF; FREITAS; ROMANEL, 2012). Os autores
afirmam ainda que a forma ideal para alcançar isto é a aplicação de
conhecimentos de Gestão da Informação em todos os processos, desde a
geração de uma demanda informacional, passando pelas ações de coleta,
organização, análise, armazenamento, distribuição e por fim seu estoque
para um uso futuro ou geração de novos conhecimentos para o ambiente
de trabalho.
2.2.2 Princípios do Lean Office
Um ambiente de escritório permite relacionar os conceitos da
filosofia Lean ao fluxo informacional, assim como à criação de
conhecimento. Todavia, uma vez que as informações são de
característica intangível e exista uma dificuldade de como as
informações são utilizadas no meio administrativo, existe uma influência
destes problemas na implementação dos cinco princípios da mentalidade
enxuta trazidos pelo Lean (GREEF; FREITAS; ROMANEL, 2012).
a) Conceito de Valor para as atividades desempenhadas pelo
ambiente organizacional – muitas vezes difíceis de enxergar,
já que os objetivos variam constantemente;
b) Mapeamento do Fluxo de Valor, sendo este associado com
projetos de sistemas e serviços customizados;
c) Dependência do planejamento das interações entre pessoas e
recursos;
d) A demanda do escritório guia a produção puxada, porém
com difícil previsão;
e) Busca da perfeição, a qual permite repetição e
aprimoramento de tarefas e atividades sem a ocorrência de
erros, com aplicação em, no mínimo, um projeto.
35
Para Greef, Freitas e Romanel (2012), o Fluxo de Informação é o
principal veículo por meio do qual as ações descritas nos princípios da
mentalidade enxuta são realizadas, conferindo a importância de transitar
qualidade nos ambientes administrativos, sendo que estes necessitam
atribuir características da mentalidade enxuta para serem considerados
ambientes Lean Office. O primeiro reconhecimento da organização sobre a necessidade
de rever seus processos é a relação entre os recursos disponíveis para a
realização do trabalho e o trabalho propriamente dito. A contribuição da
mentalidade enxuta é o aumento da produtividade e, paralelamente, a
redução ao máximo da quantidade de erros cometidos, necessidades de
espaço, tempo de produção e custos adicionais. Na preparação do
pessoal para a aplicação desta nova filosofia, a utilização dos conceitos e
ferramentas para o mapeamento do fluxo de valor e comunicação dos
objetivos devem ser explicados, deixando claro para a equipe a mudança
relativa, a simplificação dos processos de atividades e a eliminação das
atividades não agregadoras de valor (LANDMANN et. al, 2009). Todos
estes propósitos aplicados fazem com que haja uma harmonia e
satisfação no trabalho com a informação, sendo que todo o ciclo
produtivo será minimizado assim como desperdícios. Os desperdícios
relacionados ao ambiente administrativo podem ser listados da seguinte
forma (LAGO; CARVALHO; RIBEIRO; 2008):
a) Objetivos departamentais não alinhados com a estratégia
global da empresa;
b) Deslocamentos dentro ou entre departamentos
desnecessários;
c) Transporte de informação em formato físico (folhas,
capas…);
d) Tempos de espera diversos, podendo estes estarem
relacionados a falta de assinatura, centralização de
informações, autorizações;
e) Retrabalho na produção de documentações;
f) Processamento de informações desnecessárias;
g) Layout inadequado.
2.2.3 Lean Manufacturing x Lean Office
São diversas as vantagens da utilização do conceito, aplicações e
ferramentas do Lean Office. De acordo com a derivação do lean
36
manufacturing, a produção tradicional, pode-se fazer uma adaptação das
vantagens da aplicação do Lean voltado à manufatura com as vantagens
de aplicação do Lean Office, conforme o Quadro 3 (GREEF; FREITAS;
ROMANEL; 2012, p. 171).
Quadro 3 - Lean Manufacturing x Lean Office
Produção Tradicional Lean Office
Simplificação do planejamento de
produção
Simplificação de processos
administrativos (desburocratização)
Maior precisão nas previsões dos
pedidos
Liberação de fluxos de informação
Redução do tempo de resposta a
alterações de engenharia
Redução do tempo de resposta a
alterações de documentações e
processos
Redução de estoques entre os
processos e de sistema final
Redução de estoques (informação
parada) entre os processos e a
documentação
Redução dos tempos de ciclo dos
processos de produção
Redução dos tempos de ciclo dos
processos comunicacionais
Capacidade de encontrar problemas
e resolver com antecedência
Capacidade de identificar problemas e
tratá-los quando ocorrem
Melhoria de qualidade dos sistemas
ou serviços
Melhoria de qualidade dos processos e
de recuperação da informação para
tomada de decisão
Fonte: Greef, Freitas, Romanel (2002).
A base estruturada para atender as propostas da Tabela 1 significa
gerenciar o trabalho para o cliente no menor tempo possível, com a
maior qualidade e com o menor desperdício de recursos, o que gera
competitividade, visto que o custo final do sistema diminui e, por
consequência, o preço de mercado (GREEF; FREITAS; ROMANEL;
2012).
Quanto a responsabilidade sobre os desperdícios que existem em
atividades realizadas em escritório, é papel do gerente se preocupar não
apenas com as atividades internas da empresa, contexto chamado de
back office, mas também com aquelas atividades que tem alto contato
37
com o cliente, as atividades front office. Os desperdícios a serem
minimizados de acordo com a filosofia do Lean Office no caso do back
office são aqueles que não são distinguíveis por parte dos clientes ou
usuários finais do sistema entregue, o que compromete o processo de
geração de valor. No contexto front office são notáveis pelo
comprometimento com a qualidade do valor. Dá-se, então, a devida
importância para o mapeamento dos fluxos de informação e de materiais
no escritório. Cabe à gerência minimizar perdas provindas de falhas,
priorizando a geração de processos com menor custo e crescente
qualidade, fazendo com que os principais objetivos de trabalho da
organização sejam definidos e as expectativas do cliente sejam
superadas (GREEF; FREITAS; ROMANEL; 2012). Para os autores, o
nível desta liderança não tem grande importância, mas sim sua
responsabilidade, o que faz a condução do trabalho realizado no
escritório uma estrutura com bom fundamento em planejamento e
aplicação de ferramentas e tarefas que fazem com que este ambiente seja
cada vez mais enxuto.
2.2.4 Metodologia
Ao incorporar a mentalidade enxuta em ambientes
administrativos, a organização não deve apenas pensar na eliminação
dos desperdícios existentes, mas também adotar atitudes e
comportamentos na cultura do ambiente. De acordo com Tapping e
Shuker (2010), uma organização para se tornar enxuta deve mudar sua
mentalidade, ou seja, sua cultura, além do aprendizado de observar os
desperdícios em todos os seus processos. Conforme Greef, Freitas e
Romanel (2012), são elementos culturais facilitadores da implementação
do lean office:
a) Comprometimento e contínua aprendizagem sobre os
processos internos, fluxos de informações e técnicas de
melhoria, todos voltados à filosofia lean;
b) Observar e identificar o fluxo do valor à medida que novas
atividades são realizadas, cumprindo imediatamente as
necessidades internas e/ou externas quando estas surgirem;
c) Sistematizar estados atuais e futuros dos fluxos de informação, materiais e volume de pessoas, visando
melhoria e aproximação entre atividades e demandas de
clientes;
d) Estabelecer métricas de trabalho;
38
e) Criação e implementação de planos de melhoria contínua em
todas as áreas da organização.
Os autores ainda indicam que para a aplicação das ferramentas e
filosofias do escritório enxuto é necessário traçar um plano diretor,
sendo este um projeto de estruturação da organização visando a nova
conceituação adotada. Este plano diretor traduz de maneira escrita e
oficial todas as ações que serão realizadas nas atividades e informações
do escritório que visa tornar-se lean. Os principais constituintes do
plano, segundo Greef, Freitas e Romanel (2012), são:
a) Identificar uma equipe organizadora e diretiva do plano;
b) Sistematização do projeto de trabalho;
c) Definição do projeto de implementação do Lean Office -
cronograma de atividades, diretrizes, prazos e papéis
envolvidos;
d) Levantar falhas, desperdícios, e problemas na execução das
atividades operacionais, no gerenciamento e também na
consolidação de processos para a entrega de valor aos
clientes - considerar nesta etapa os fluxos informacionais e
sua aderência à cadeia de valor;
e) Definição dos quatro padrões de estruturação do Lean Office
no escritório - vertentes cultural, visual, operacional e
gerencial;
f) Verificar se existe a necessidade de mudança de tecnologias
utilizadas para o trabalho - podendo ser hardware, software,
layout, maquinário;
g) Testar a implementação do lean em uma área ou processo
específico do escritório, como protótipo;
h) Verificar os resultados do teste e adequar plano original de
trabalho;
i) Aplicar nas demais áreas da organização.
Tapping e Shuker (2010) propõem ainda oito passos para o
ambiente organizacional alcançar a filosofia e os objetivos do lean office
(o escritório enxuto):
1) Comprometimento com a filosofia lean: o apoio da direção e
dos demais colaboradores deve apoiar todo o esforço
demandado para a mudança da cultura da organização para a
redução e eliminação do desperdício. Deve haver
estimulação ao trabalho em equipe assim como
39
comprometimento de todos na aplicação do lean office
(TAPPING; SHUKER, 2010).
2) Escolha do fluxo de valor: ao pensar em valor, deve-se
pensar por algo que está sendo criado e que possui valor a
uma clientela disposta a pagar por ele. Fluxo é a sequência
de atividades/tarefas necessárias para que o serviço
solicitado pelo cliente seja executado. Logo, este passo se
constitui na escolha do processo além do individual, mas do
antecessor e posterior. A importância do fluxo de valor deve
estar relacionado ao cliente final. O propósito, então, do lean
office é a melhoria do fluxo, fazendo com que o trabalho flua
com mais rapidez (TAPPING; SHUKER, 2010).
3) Aprendizado sobre o lean: o conceito trazido pelo lean office
assim como suas ferramentas deve ser explicado aos
funcionários da organização, podendo ser através de
motivação e estimulação a participação de cursos, ainda que
a melhor forma de aprendizado seja a prática. (TAPPING;
SHUKER, 2010).
4) Mapeamento do estado atual: representação visual através de
ícones ou símbolos dos fluxos de materiais e informações de
um específico fluxo de valor. A observação e o entendimento
do fluxo de valor é muito importante para um bom
mapeamento, sendo que o ponto de início é o ponto mais
próximo do cliente voltando por todo o fluxo de processos e
atividades iniciais de valor (TAPPING; SHUKER, 2010).
5) Identificação das medidas de desempenho lean: Para a
determinação de uma métrica lean que possua eficácia na
avaliação dos resultados do lean office, deve-se procurar a
que permita estratificação em componentes que abordem os
desperdícios identificados, com coleta de dados fácil, assim
como a compreensão (TAPPING; SHUKER, 2010).
6) Mapeamento do estado futuro: Deve-se analisar criticamente
o mapa de estado atual, com o objetivo de solucionar os
problemas encontrados. Além desta análise, é importante a
compreensão da demanda do cliente. Para que o estado
futuro seja atingido, todos os envolvidos devem colaborar
diariamente, com a visão de processo de evolução e tendo a
ciência de que o processo pode sobre variações futuramente
(TAPPING; SHUKER, 2010).
40
7) Criação dos planos Kaizen: Kaizen significa melhoria de um
fluxo de valor ou de um processo, com o objetivo de
aumentar o seu valor agregado, diminuindo os desperdícios
(MARCHWINSKI; SHOOK, 2003). Os processos vão sendo
alterados a medida que melhorias são feitas. O Planejamento
é fundamental para o reconhecimento dos esforços e metas
serem alcançadas. Para isto, torna-se necessário a divisão em
etapas e, esta sequência, servirá de auxílio na eficácia do
plano Kaizen (TAPPING; SHUKER, 2010).
8) Implementação dos planos Kaizen: São três os passos para a
implementação do Kaizen: preparação, implementação e
follow-up. As pessoas envolvidas precisam buscar formas de
melhoria contínua ao fluxo de valor para que haja
transformação da organização para uma cultura lean
(TAPPING; SHUKER, 2010).
O conceito de Lean Office é variável para cada tipo de escritório, já
que cada um possui um objetivo específico de agregação de valor às suas
atividades. A adaptação da filosofia lean ao escritório ocorre de acordo
com a aplicação, sendo responsabilidade de cada ambiente. Logo, cada
um deve se adequar e identificar sua forma específica de estruturação
lean, assim como o tipo de mudança cultural a adotar e também de
organização, envolvendo não somente os colaboradores internos, mas
também com a liberdade do envolvimento de interessados externamente
em suas atividades (GREEF; FREITAS; ROMANEL; 2012).
2.3 GERENCIAMENTO ÁGIL DE PROJETOS
Os projetos são empreendidos a fim de alcançar objetivos
voltados à estratégia de negócio da organização. Visando isto, os
ambientes organizacionais adotam processos e procedimentos formais de
gerenciamento (PMBOK, 2009). A ciência usa como definição de gestão
o processo de planejamento, controle, organização e liderança de um
projeto. Todavia, ao estudar o Gerenciamento Ágil, torna-se difícil
encontrar as diferenciações entre o gerenciamento tradicional e o
Gerenciamento Ágil. Contudo, o termo e o conceito surgem dos métodos
ágeis para o desenvolvimento de sistemas de informação e são comumente usados para projetos de sistemas voltados à tecnologia da
informação (STARE, 2014).
O Gerenciamento Ágil de projetos permite à organização um
processo de desenvolvimento flexível, aumentando a capacidade das
41
equipes envolvidas no projeto a reagirem a mudanças, tornando a
organização mais competitiva no mercado. A abordagem ágil assume
que os objetivos vão sofrer mudanças inevitáveis, porém alcançar valor
ao cliente é a consideração mais importante ao projeto (COLLINGS,
1996). Para Chin (2004), o Gerenciamento Ágil seria uma maneira de
agir baseada em princípios e técnicas em que essa atividade é conduzida
por equipes com a filosofia do auto-gerenciamento, utilizando formas de
gerenciamento simplificadas, ao qual melhor são adequadas em um
ambiente de incertezas e mudanças. Highsmith (2002) é um pouco mais
específico para definir Gerenciamento Ágil, conceituando como um
conjunto valores, práticas e princípios auxiliando a organização a
entregar sistemas ou serviços em um mercado dinâmico e desafiador.
Sendo assim, o Gerenciamento Ágil pode ser definido como o conjunto
de práticas, ações, técnicas e equipes autogeridas que possuem como
objetivo a redução de desperdícios, como tempo de planejamento e
iniciação de projeto, a fim de aproximar o cliente final do ambiente
interno da organização e satisfazê-lo, visando aumento em flexibilidade,
agilidade e, com isso, ser competitiva no mercado.
As organizações estão necessitando cada vez mais de agilidade no
desenvolvimento de seus projetos a fim de melhorar o processo de
entrega do sistema final ao cliente. Desta forma, com a adoção da
filosofia ágil no gerenciamento de projetos, as empresas visam o
aumento da capacidade de oferecer novos sistemas, flexibilidade, e
maior participação do cliente no ambiente interno das organizações
(OLIVEIRA; LIMA, 2011).
A cultura ágil passa pela definição de dois termos importantes:
agilidade e ambiente ágil. Agilidade pode ser definida como a habilidade
de criação e resposta a variações para se obter lucro em um ambiente de
negócios turbulento, buscando o equilíbrio entre estabilidade e
flexibilidade (HIGHSMITH, 2002). O autor propõe ainda o
gerenciamento ágil para projetos com alto grau de incertezas. Chin
(2004), indo ao encontro do que aborda Highsmith (2002), relaciona o
ambiente ágil à soma destas incertezas, podendo estas serem internas ou
externas. A importância de tais especialistas é evidenciada pelo autor, no
âmbito de equipe de projeto, indo também ao encontro do que aborda
Stare (2014) sobre a constante coordenação dos participantes da equipe
na implantação de metodologias ágeis.
A abordagem ágil se concentra na fase de execução de um
projeto. Além disto, a abordagem não altera todo o ciclo de projeto
(iniciação, planejamento, execução e fechamento), exceto que parte final
da iniciação e parte do planejamento são movidas para a etapa de
42
execução, fazendo com que o processo fique mais interativo, dinâmico e
ágil, eliminando desperdícios de tempo e, além disto, propondo que os
ciclos de desenvolvimento sejam mais curtos e participação ativa de
todos os envolvidos no projeto (STARE, 2014). O autor acrescenta ainda
que o gerenciamento ágil afeta principalmente a precisão do
planejamento, onde é criado um cronograma para todo o projeto já na
etapa de início.
2.3.1 Gerenciamento tradicional x Gerenciamento Ágil
A diferenciação existente entre o Gerenciamento Tradicional de
projetos e o Gerenciamento Ágil de projetos foi esclarecida por Stare
(2014), onde os requisitos para o projeto e soluções na forma tradicional
de gestão de projetos são bem definidas, ao qual grandes mudanças no
escopo não são esperadas. Existe ainda uma rotina de planejamento de
projetos, onde os mesmos são repetitivos e geralmente é utilizado um
modelo comprovado. Já na metodologia ágil para gerenciamento de
projetos, os requisitos e as soluções não são bem definidas - podendo ser
até parcialmente definidas, existe a possibilidade de recursos adicionais
que no momento atual a organização ainda não considerou ou que ainda
desconhece e pode sofrer uma gama ampla de modificações no escopo
do projeto - sendo estas mudanças, inclusive, esperadas pela equipe,
ocorrendo principalmente para projetos de desenvolvimento.
De acordo com Mundin et al. (2002), enquanto a metodologia
tradicional de gerenciamento de projetos se preocupa em redigir
documentação a respeito do projeto ou com o cumprimento rigoroso de
processos de atividades, a metodologia ágil está concentrada no
desenvolvimento em si e nas relações interpessoais. Logo, a proposta
será a definição de um processo para o projeto com o enfoque nos
participantes, ou seja, nas pessoas (SCHWABER; BEEDLE, 2002). O
Quadro 4 a seguir mostra o comparativo entre a abordagem ágil e a
abordagem tradicional de gerenciamento de projetos trazido por Chin
(2004).
43
Quadro 4 - Gerenciamento Tradicional x Gerenciamento Ágil
TÓPICOS Gerenciamento Tradicional Gerenciamento Ágil
Essência Orientado ao planejamento e
controle
Orientado à mudanças, com
foco na análise de valor e
de riscos
Natureza do
Projeto Em cascata Iterativa
Engajamento
do Cliente
Autorizativo, aprovando
especificações, planejamento e
produto
Colaborativo, com
envolvimento ativo em
todas as fases
Documentação Detalhada, com aprovações
formais Mínima necessária e útil
Vantagens Previsibilidade e controle mais
fáceis
Respostas rápidas às
mudanças demandadas
pelos clientes
Desvantagens
Custos elevados em
documentação e controle,
fortemente baseado nas
definições iniciais acordadas,
dificuldades de acomodar
mudanças
Maior dependência do time,
maior variação do produto
final, maiores riscos de
custos superiores ao
orçamento
Ideal para
Projetos cujos requerimentos
sejam pouco sujeitos a
mudanças (Ex. Construção de
fábrica)
Projetos de inovação, com
ambiente dinâmico ou mal
definido (Ex. Engenharia de
Software)
Fonte: Adaptado de Schwaber & Beedle, 2002.
2.3.2 A ferramenta Scrum
Existem diversas metodologias de desenvolvimento que são
classificadas como métodos ágeis de Gerenciamento de Projetos e,
dentre elas, a metodologia Scrum se destaca por ser um dos métodos
mais maduros, voltado ao gerenciamento de projetos ágeis. O Scrum é
uma estrutura para o desenvolvimento de sistemas, onde seus processos
e técnicas podem ser aplicados para projetos de caráter complexos
(STREULE et al, 2016). Para Bissi (2007) o Scrum se mostra como uma
metodologia extremamente flexível e ágil, que objetiva um processo de
desenvolvimento iterativo, podendo este ser aplicado em qualquer
sistema ou no gerenciamento de qualquer tipo de atividade, baseando-se
no desenvolvimento incremental com ciclos iterativos curtos. O Scrum
se evidencia por ser um processo de desenvolvimento de software
incremental em ambientes mais complexos, onde não há uma clareza
sobre os requisitos ou frequência de mudanças (SILVA; SOUZA;
44
CAMARGO, 2013). O Scrum está baseado em seis características
(SCHWABER, 1995):
a) Flexibilidade em relação aos prazos;
b) Flexibilidade em relação aos resultados;
c) Pequenas equipes;
d) Frequentes revisões do que é desenvolvido;
e) Colaboração entre os envolvidos;
f) Orientações a objetivos.
Esta metodologia foi criada na Easel Corporation, desenvolvida
posteriormente por outras duas empresas trabalhando em conjunto -
Advanced Development Methods e VMARK, tendo como objetivo um
processo conveniente para desenvolvimento e projetos
(SUTHERLAND, 2014). A metodologia é baseada em princípios como
equipes de pequeno porte, requisitos pouco estáveis e curtas iterações
para a promoção de uma visibilidade para o desenvolvimento.
A fundamentação do Scrum se dá na teoria de controle de
processo, e objetiva o aperfeiçoamento da previsibilidade e controle dos
riscos existentes em projetos. Como pilares para a sustentação da
metodologia Scrum estão transparência, adaptação e inspeção (SILVA;
SOUZA; CAMARGO, 2013). Silva, Souza e Camargo (2013)
esclarecem ainda que a garantia para que todos os processos possuam
clareza para ambas as partes do trabalho – organização e cliente – é a
transparência. A inspeção é realizada durante todo o projeto e objetiva a
detecção de qualquer variação e ajuste do processo. A adaptação é uma
necessidade provinda da inspeção, tendo como finalidade a adaptação do
processo para toda e qualquer variação detectada no pilar inspeção.
Existe uma complexidade bastante considerável nas atividades
relacionadas ao desenvolvimento de sistemas, evidenciando as empresas
de pequeno porte, já que dispõem de grandes limitações de recursos. De
acordo com Mundin et al. (2002), uma organização ao desenvolver um
sistema inter-relaciona praticamente todas as áreas atuantes, sendo
necessárias informações dos membros de cada área funcional, sendo
assim uma atividade multidisciplinar. A proposta da metodologia Scrum
é dividir o desenvolvimento dos sistemas em ciclos curtos, geralmente algumas semanas, e ao final de cada ciclo, o cliente (seja ele interno ou
externo) receba uma versão atual, agregando valor ao negócio (CRUZ,
2013).
São práticas gerenciais do Scrum:
a) Product Backlog;
45
b) Daily Scrum;
c) Sprint;
d) Sprint Planning Meeting;
e) Sprint Backlog;
f) Sprint Review Meeting.
O primeiro passo é o Product Backlog, sendo a coleta dos
requisitos de projeto (SCHWABER; BEEDLE, 2002). Através de
reunião com todos os envolvidos do projeto, além de investidores e até
mesmo parceiros, são apontadas todas as necessidades, regras de
negócio e requisitos técnicos que o sistema deverá apresentar, tudo em
formato de lista de atividades que serão desenvolvidas durante o projeto.
O Daily Scrum é uma rápida reunião diária com os membros da equipe
que servirá de definição das atividades que serão executadas e ter o
conhecimento do que foi executado de atividades do dia anterior.
Também chamada de Stand Up Meeting, visto que a intenção desse tipo
de reunião é a praticidade e o tempo reduzido, apenas para alinhamento
dos pontos em questão. Em geral, na reunião Daily Scrum as perguntas
„O que foi feito ontem?‟ „O que será feito hoje?‟ e „Há algum obstáculo
para a realização das suas atividades?‟ devem ser respondidas (RISING
& JANOFF, 2000). Na Sprint, principal prática do Scrum, serão
implementados os itens de trabalho que foram definidos no Product Backlog, podendo durar um tempo no intervalo de uma a quatro
semanas. O Sprint Planning Meeting é a reunião da equipe para o
planejamento de Sprint. O Sprint Backlog é chamado de subconjunto do
Product Backlog, uma vez que será a lista propriamente dita de
atividades que serão desenvolvidas do Sprint. Por fim, o Sprint Review
Meeting é uma reunião realizada após cada Sprint, na qual serão
discutidos os tópicos relacionados às dificuldades encontradas, lições
aprendidas, erros, acertos e observações.
De acordo com Mar & Schwaber (2001), a Figura 4 mostra uma
visão mais geral desta dinâmica do Scrum.
46
Figura 3 - Visão Geral de Scrum
Fonte: Mar & Schwaber (2001)
2.3.3 Os atores do Scrum
De acordo com Silva, Souza e Camargo (2013), a equipe do
Scrum tem sua composição por três partes, sendo elas o “Product
Owner”, proprietário do sistema, o qual será o membro representante do
cliente interno ou externo. Este definirá quais são os requisitos de
projeto, assim como sua priorização e grau de importância de cada um
deles. O “Scrum Master”, o papel assumido pelo gerente do projeto, o
qual deverá trabalhar para que o Scrum aconteça, removendo todo e
qualquer empecilho em prol da equipe. Outro ponto em questão de
responsabilidade do Scrum Master é a remoção dos obstáculos
apontados pelos membros da equipe no Daily Scrum. A “Equipe de
Desenvolvimento”, sendo esta composta por um grupo de pessoas
responsáveis pela análise, programação e testes do projeto. O Quadro 4
relaciona os componentes da equipe do Scrum e suas devidas
responsabilidades:
Quadro 5 - Papeis do framework scrum
Product Owner Scrum Master Equipe de
Desenvolvimento
Representante do
cliente
Auxílio aos membros da
equipe
Desenvolvimento do
sistema
Trabalha com a equipe Remove possíveis
obstáculos
Cada membro é
responsável por seu
trabalho
47
Prioriza os requisitos
do sistema
Exerce liderança aos
membros da equipe
Contribuem ao máximo
por cada sprint
Interface entre a
equipe e o negócio
Responsável pelo
gerenciamento de
processos
Varia de cinco à dez
pessoas na equipe
Define as
características do
sistema
Responsável pelas
reuniões diárias
Equipe auto-organizada e
multifuncional
Data e conteúdo no
lançamento
Responsável pelo
planejamento de Sprints
Responsável por fracassos
ou sucessos
Responsável pelo aval
final
Responsável pela
documentação requerida
Podem ser programadores,
testers, engenheiros, etc.
Aceitação ou rejeição
do resultado do
trabalho
Protege a equipe de
possíveis interferências
externas
Fonte: Adaptado de Silva, Souza e Camargo (2003).
Em uma lista de tarefas os requisitos de projeto são analisados, de
acordo com a prioridade de cada item, de forma que os itens de maior
importância ocupam o topo da lista, que deve ser continuamente
atualizada, conforme a priorização. O Scrum trabalha com
desenvolvimento incremental, dividindo os processos em interações
periódicas de trabalho para cada fase, chamadas de sprints. (SILVA;
SOUZA; CAMARGO, 2013). Segundos os autores, cada sprint possui
uma duração média de trinta dias, possuindo um objetivo bastante claro
e bem definido, com toda equipe possuindo conhecimento. Reuniões
diárias dentro de cada sprint são realizadas de modo a proporcionar ao
Scrum Master diariamente uma atualização do status do projeto, o que
auxilia na tomada de decisões.
Um projeto pode possuir mais de um sprint definido. Se for o
caso, cada sprint deve conter uma nova implementação do sistema.
Logo, cabe ao proprietário do projeto, ao final de cada sprint, decidir
sobre a implantação do sistema já desenvolvido ou adiar esta decisão no
final da próxima sprint. Ao final de cada sprint, o sistema deve estar
pronto, codificado e testado.
48
2.4 CONVERGÊNCIAS ENTRE AS ABORDAGENS DO LEAN
OFFICE E DO GERENCIAMENTO ÁGIL DE PROJETOS
O fluxo informacional está presente em todas as atividades de
uma organização (MOURA, 1995). Conforme posto anteriormente, a
informação é um dos principais insumos dos ambientes organizacionais,
sendo o meio de sincronização das mais diversas funções, processos e
setores de uma empresa.
Ainda na visão de Moura (1995), para que exista um processo de
trabalho bem definido e executado de maneira conforme, é necessário
um levantamento de todas as informações que serão necessárias para que
possa ser definido o fluxo informacional para a execução do processo.
Este estudo sobre as informações necessárias para a definição de
um fluxo informacional e a forma de alocação e disponibilização dessas
informações são de responsabilidade da Gestão da Informação e está
intimamente ligado aos estudos do Lean Office e do Gerenciamento
Ágil, uma vez que não há processo sem informação, não há
gerenciamento sem processo e, sem processo, não há como realizar
estudos voltados a desperdícios e sequenciamento de atividades para o
estudo de um possível fluxo de valor.
O Gerenciamento Ágil foi desenvolvido originalmente dentro das
indústrias de desenvolvimento de softwares, enquanto que a filosofia
lean dentro das indústrias de fabricação. Apesar das diferentes origens,
ambas filosofias visam a maximização do valor e minimização de
desperdícios nas atividades exercidas pela organização, gerenciamento
do tempo disponível para a execução das atividades relacionadas ao
processo produtivo, proposição de uma cultura de melhorias contínuas
ao processo, aumento de previsibilidade, motivação à proatividade de
adaptação a mudanças e alcance de resultados mensuráveis o mais cedo
e constante possíveis (ASEFESO, 2012).
Asefeso (2012) destaca ainda que apesar de muitos ambientes
organizacionais optarem por uma ou outra diante de suas atividades, a
melhor decisão é a combinação do melhor que as duas filosofias podem
oferecer. Enquanto que a contribuição da filosofia lean é no
gerenciamento de processos voltados ao valor que as pessoas podem
criar individualmente para o cliente, no Gerenciamento Ágil este valor é
criado através de um time auto-gerenciado e auto-organizado.
O foco do lean é no fluxo contínuo, o qual auxilia no
conhecimento das atividades mais importantes a serem feitas por cada
pessoa participante do processo, fornecendo assim técnicas para garantir
que o valor máximo seja alcançado a partir de recursos interdependentes,
49
porém separados. Na metodologia ágil, o foco é a criação de células de
trabalho flexíveis, uma vez que as equipes são auto-organizadas,
exigindo menos gastos em gerenciamento, menos transferências e
produzindo uma maior diversidade de sistemas finais.
Trabalhando em conjunto, as duas forças podem ser aplicadas no
gerenciamento de ambientes de trabalho que possui uma mistura
contínua de indivíduos e equipes auto-organizadas (ASEFESO, 2012).
Desta forma, uma organização “Ágil-lean” será capaz de deixar mais
operacional a execução e o aprimoramento de um processo na forma de
uma atividade de gerenciamento e realizar o aproveitamento das
individualizações para as tarefas ditas lineares.
Sendo assim, a organização pode unir a filosofia do estudo do
fluxo do valor agregado e a redução dos diversos tipos de desperdícios
decorrentes das atividades organizacionais sem a burocratização e a
morosidade causadas pela dependência informacional entre os
indivíduos, além do ganho em flexibilidade e proposição da cultura do
autogerenciamento, permitindo que a empresa seja enxuta, mas ao
mesmo tempo ágil, possuindo uma maior velocidade na execução de
seus processos, aumentando assim sua competitividade no mercado. A
Figura 4 ilustra as convergências entre os estudos.
50
Figura 4 - Convergência entre os temas abordados
Fonte: Elaborado pelo autor.
51
3. MÉTODOS DA PESQUISA
Neste capítulo será apresentado o enquadramento metodológico
da presente pesquisa, assim como o sequenciamento e descrição de cada
uma das etapas.
3.1 ENQUADRAMENTO METODOLÓGICO
De acordo com Tartuce (2006), a metodologia científica é o
estudo sistemático e lógico dos métodos utilizados na ciência, assim
como seus fundamentos, validação, e relação com as teorias científicas.
Para Cauchick Miguel et al. (2012), a evolução do estudo de
metodologia é de suma importância para a elevação do nível de um
trabalho apresentado, já que faz o delineamento da pesquisa e está
associado às técnicas de coleta e análise. A metodologia emprega e
aplica procedimentos buscando o conhecimento, a fim de demonstrar
validade e utilidade para a sociedade (FREITAS; PRODANOV, 2013).
Baseando-se nestes pressupostos, o presente trabalho se fundamenta
conforme o enquadramento metodológico apresentado na Figura 5.
52
Figura 5 - Enquadramento Metodológico
Fonte: Adaptado de Tartuce (2006).
53
3.1.1 Enquadramento pelos objetivos
A natureza dos objetivos, de acordo com os objetivos da
pesquisa, pode ser definida como descritiva, já que visa a análise e a
descrição de uma situação atual. O levantamento do estado de um
fenômeno tem como característica ser descritivo (MARCONI;
LAKATOS, 2003). Quanto à natureza, tem-se como classificação um
trabalho teórico e ilustrativa, uma vez que está focado em compreender
o estado do ambiente analisado relacionando-o à revisão bibliográfica.
A lógica da pesquisa é de caráter indutiva, já que as conclusões gerais
são obtidas em um cenário não tão esclarecido. O objetivo do estudo
indutivo é chegar a conclusões onde o conteúdo é muito mais amplo do
que o conteúdo das premissas nas quais se basearam (MARCONI;
LAKATOS, 2003).
3.1.2 Enquadramento pela abordagem
A abordagem da pesquisa foi, de maneira geral, qualitativa, com
algumas análises quantitativas para auxílio na tomada de decisões.
Segundo Cauchick Miguel et al. (2012), a preocupação da abordagem
qualitativa é a obtenção de informações sob a perspectiva dos indivíduos
- trabalhadores, diretores ou outros profissionais -, assim como a
interpretação do ambiente de trabalho em que a problemática ocorre.
Bryman (1989 apud CAUCHICK MIGUEL et al., 2012) evidencia a
escolha da análise qualitativa como forma de abordagem com sua
listagem das principais características da pesquisa qualitativa, sendo as
principais a ênfase na interpretação subjetiva dos indivíduos,
delineamento do contexto em que o ambiente estudado está inserido,
fontes múltiplas de evidências, análise da realidade do ambiente
organizacional e a proximidade com o fenômeno estudado.
3.1.3 Enquadramento pelos procedimentos
Como procedimento técnico para a realização do estudo o método
pesquisa-ação é o mais indicado, uma vez que, segundo Cauchick
Miguel et al. (2012), a base teórica e analítica dos assuntos estudados
está associada a uma ação ou proposição de resolução para uma problemática no qual os participantes que a representam e os
pesquisadores estão envolvidos em cooperação ou participação. O
próximo tópico adentra melhor nos procedimentos deste método.
54
3.2 PESQUISA-AÇÃO
Bryman (1989 apud CAUCHICK MIGUEL et al., 2012)
conceitua a pesquisa-ação como um tipo de pesquisa social concebida e
aplicada na qual o pesquisador e o „pesquisado‟ colaboram no
desenvolvimento de um diagnóstico e uma possível solução de uma
problemática. Sendo assim, a pesquisa-ação é um procedimento
reflexivo, sistemático, controlado e crítico, com finalidade de estudar
algum aspecto da realidade com o objetivo de ação prática no objeto de
estudo (BALDISSERA, 2001).
Segundo a autora, a pesquisa-ação utilizada como método de
conhecimento da realidade, possui como principal característica a
intervenção fundamentada em um embasamento teórico, servindo à ação
educativa e à conscientização dos envolvidos no processo de pesquisa.
A metodologia prega a simultaneidade entre o „conhecer‟ e o „agir‟. De
acordo com Lodi (2014), a pesquisa-ação tem a função de diagnosticar
uma situação, dar início a uma ação e realizar o acompanhamento desta,
desencadeando uma sequência de novas ações.
Conforme descrito, a pesquisa-ação deve iniciar-se com a fase
exploratória, com a coleta e análise de dados do objeto de estudo e
revisão da literatura do tema relacionado à pesquisa em paralelo.
Baldissera (2001) afirma que esta estratégia é importante, uma vez que a
realidade está em constante mudança. Esta fase exploratória visa
identificar as necessidades, características e situação do universo a ser
pesquisado (THIOLLENT, 2009).
Sendo assim, os procedimentos adotados pelo autor para o
desenvolvimento do presente trabalho foram a coleta de dados junto à
organização estudada, assim como a análise dos dados (Pesquisa de
Campo Preliminar), proposição de uma sistemática de ações visando a
cultura da mentalidade enxuta e ágil, de maneira contínua (Proposição
da Sistemática); validação da sistemática com os líderes e gestor geral
da empresa (Validação com a empresa); ajustes da sistemática;
apresentação e análise dos resultados (Contribuições para a literatura). A
Figura 6 ilustra as etapas de aplicação da pesquisa.
55
Figura 6 - Etapas da Pesquisa
Fonte: Elaborado pelo autor.
3.2.1 Estudo dos Fundamentos Teóricos
Para dar suporte à coleta e análise dos dados obtidos no objeto de
estudo, foi realizada uma revisão da literatura que se enquadra no tema
da presente pesquisa. De acordo com Moreira e Caleffe (2008), uma boa
revisão de literatura faz com que o pesquisador consiga contextualizar
seu problema de pesquisa em uma modelagem teórica mais ampla.
Sendo assim, esta etapa consiste na busca de um embasamento
teórico à pesquisa em questão, de forma a dar sustentação para análises
resultantes da pesquisa empírica.
3.2.2 Coleta de dados
Para a coleta dos dados, foram realizadas 4 (quatro) reuniões
durante 1 (um) mês de coleta, com duração aproximada de 1 (uma) hora
e meia por reunião. Líderes de cada equipe e ao menos dois
colaboradores de cada setor da empresa participaram das reuniões,
juntamente o presente autor, responsável por instruções referentes à
implementação de melhorias.
Cada setor (Análise, Desenvolvimento, Qualidade e Treinamento)
possui um líder responsável por gerir e minimizar impedimentos nas
tarefas relacionadas ao desenvolvimento do sistema. O líder da Equipe
de Análise de Sistemas possui 7 (sete) anos de experiência na área, com
56
4 (quatro) anos na atual empresa, tendo trabalhado em outras empresas
do mesmo ramo de concepção de softwares. Já o líder da Equipe de
Desenvolvimento conta com 9 (nove) anos de experiência na área, sendo
4 (quatro) na atual empresa e experiência trabalhando como
desenvolvedor e analista em outras organizações anteriormente. A
Equipe de Qualidade de Software não possui um líder direto, contando
apenas com a gerência do gestor geral. Neste caso, o supervisor
participou das reuniões com a responsabilidade de responder pela
equipe, juntamente com os outros colaboradores do setor. Este possui 5
(sete) anos de experiência na área, sendo 3 (três) anos na atual empresa.
Nestas reuniões informações sobre demandas, clientes,
desenvolvimento dos sistemas e o fluxo do produto pelos setores da
organização foram coletadas, além do conhecimento sobre as atividades
e, consequentemente, dos processos do objeto de estudo escolhido para
a aplicação da pesquisa. Com relação aos dados quantitativos coletados
para o suporte à análise do estado atual dos processos do setor
escolhido, foram utilizados os registros realizados pelo setor na atual
ferramenta de controle de atividades diárias, desenvolvida pelo próprio
setor.
Além disto, foram também realizadas reuniões de validação com
o gestor geral da organização, sendo de suma importância para a
compreensão das atividades que seriam priorizadas no estudo, uma vez
que a visão de valor da empresa de acordo com o cliente estava sendo
prejudicada por informações, atividades e processos que não agregam
valor, surgindo a necessidade de adequação à realidade, requisitos e
expectativas do cliente.
57
Quadro 6 - Coleta de Dados
COLETA DE DADOS
Reunião Data Dados Coletados Participantes
1 04/09/2017
Organograma da organização,
organograma da equipe de
qualidade, atividades
desempenhadas pela equipe de
qualidade.
Gestor geral e
supervisor da equipe de
qualidade.
2 11/09/2017
Fluxo geral de desenvolvimento
do produto, sequenciamento das
atividades, processos atuais da
organização. Dados quantitativos
(tempos de execução de
atividades).
Líderes das Equipes de
Análise,
Desenvolvimento,
Qualidade e
Treinamento.
3 18/09/2017
Atividades agregadoras de valor
para a organização e,
consequentemente, para a equipe
de qualidade.
Gestor geral e
supervisor da equipe de
qualidade.
4 25/09/2017
Desperdícios existentes na
equipe de qualidade e na
organização como um todo.
Gestor geral e
supervisor da equipe de
qualidade.
3.2.3 Análise de dados
Esta é a fase da pesquisa onde serão agrupados e organizados
todos os dados coletados na etapa anterior, fazendo a transformação
destes em informações importantes para o mapeamento do estado atual
do objeto de estudo escolhido. É nesta etapa que são identificadas as
atividades, as informações necessárias para as execuções e o respectivo
sequenciamento atual destas no presente ambiente de trabalho do setor
analisado.
3.2.4 Proposição da Sistemática de Melhorias
Através do estudo paralelo da literatura e da análise dos dados
quanto às atividades, informações e sequenciamentos no ambiente
pesquisado, pode ser proposta uma sistemática geral de melhorias de
processos e aplicada no setor escolhido da organização. Com a aplicação
das etapas desta sistemática, um estado futuro é proposto ao setor
estudado com a resolução ou minimização dos problemas, desperdícios
e falhas encontradas nos processos e no fluxo informacional.
58
3.2.5 Validação da Sistemática com a Empresa
Após a elaboração da sistemática através da revisão bibliográfica
e da pesquisa de campo na organização, torna-se necessária a validação
da sistemática elaborada com os líderes e gestor geral da empresa XY.
Para esta validação, foram realizadas reuniões para apresentação
e validação das etapas da sistemática para empresa, para a apresentação
das proposições de melhorias resultantes da aplicação da sistemática no
setor da empresa em estudo e da proposição de continuidade da
sistemática de melhorias nos demais setores da organização.
59
4. SISTEMÁTICA DE MELHORIAS
Com base nos estudos bibliográficos e na pesquisa preliminar
realizada em campo, a presente pesquisa tem como principal objetivo a
proposição de uma sistemática para melhorias de processos com base
nos conceitos e ferramentas da mentalidade enxuta aplicada a ambientes
organizacionais – o Lean Office – e do Gerenciamento Ágil de Projetos.
Esta abordagem “lean-ágil” usa ainda como suporte ao estudo a Gestão
da Informação, uma vez que para se implantar uma cultura enxuta e ágil
o fluxo informacional deve fluir continuamente, e o acesso às
informações relevantes ao atendimento das necessidades internas das
organizações deve ser simplificado e facilitado. O Quadro 6 caracteriza
as etapas da sistemática de melhorias proposta.
60
Quadro 7 - Etapas da Sistemática de Melhoria
PROPOSIÇÃO DA SISTEMÁTICA
No Etapa Descrição Ferramenta Autores
1
Realizar o
Mapeamento do
Fluxo Geral de
Produção da
organização estudada
Esta etapa é necessária para conhecer o atual processo produtivo da
empresa e identificar as relações de dependência entre os setores da
organização, afim de escolher o setor piloto para a primeira iteração
da sistemática, selecionado de maneira estratégia para a empresa.
Lean Office
(LAGO;
CARVALHO;
RIBEIRO; 2008).
2
Escolher um setor da
empresa como piloto
para 1 (uma) iteração
da sistemática de
melhorias
Após o mapeamento e análise dos setores participantes do fluxo
geral de produção, a sistemática propõe a escolha de um dos setores
para o estudo da aplicação. A escolha deste setor deve ser
estratégica para a empresa, uma vez que o próximo passo „pós-
sistemática‟ no setor é a aplicação da sistemática nos outros setores
da organização até atingir todos as áreas da empresa, buscando
assim a melhoria contínua na organização como um todo.
Lean Office
(LAGO;
CARVALHO;
RIBEIRO; 2008).
3
Realizar o
Mapeamento de
Processos do setor
escolhido
Nesta etapa são mapeados os processos produtivos no setor
escolhido, os quais resultam em produtos intermediários ou parciais
do produto principal produzido pela empresa. A ideia é melhorar a
produção destes produtos parcial de forma a atingir de maneira
indireta a melhoria na produção do produto principal.
Lean Office;
Bizagi Modeler
(LAGO;
CARVALHO;
RIBEIRO; 2008).
4
Realizar o
Mapeamento do
Fluxo de Informações
do setor escolhido
Para entender como as informações transitam entre os processos e
atividades pertencentes a estes, é necessário realizar um
mapeamento do fluxo informacional dos processos do setor
escolhido. Esta etapa evidencia ainda as informações originadas de
outros setores da organização necessárias para o setor em estudo.
Desta forma, a proposta aponta melhorias no fluxo informacional
não somente no setor em análise, como também às outras áreas da
empresa.
Lean Office (GREEF; FREITAS;
ROMANEL, 2012)
5 Realizar o
Mapeamento do
Com o resultado do mapeamento de processos e do fluxo
informacional do setor em análise, as atividades realizadas nos Lean Office
(GREEF; FREITAS;
ROMANEL, 2012)
61
Fluxo de Valor
(Estado Atual) dos
processos do objeto
de estudo escolhido
processos da área pesquisada devem ser estudadas e caracterizadas
em atividades que agregam e atividades que não agregam valor aos
produtos finais do setor. Desta forma, o Mapeamento do Fluxo de
Valor (MFV) pode ser desenhado e os tempos totais de conclusão
dos processos, os Lead Time, encontrados, assim como a Taxa de
Valor Agregado (TVA) de cada processo do setor.
6
Identificar
desperdícios, falhas e
retrabalhos no setor
escolhido
Além da eliminação ou minimização das atividades que não
agregam valor ao setor, desperdícios, falhas e retrabalhos devem ser
identificados e classificados, para que posteriormente possa se
propor a melhoria adequada com base na revisão de literatura.
Lean Office,
Gerenciamento
Ágil de
Projetos
(Scrum)
(GREEF; FREITAS;
ROMANEL, 2012);
(SCHWABER, 2002).
7
Propor melhorias nos
processos do setor
escolhido com base
no Lean Office e no
Gerenciamento Ágil
de Projetos
Com base na revisão bibliográfica, ou seja, nos estudos do Lean
Office e no Gerenciamento Ágil de Projetos, propor um plano de
ações para melhorias nos processos do setor escolhido para
aplicação da pesquisa, assim como na identificação de melhorias
nos demais setores da empresa.
Lean Office,
Gerenciamento
Ágil de
Projetos
(Scrum)
(GREEF; FREITAS;
ROMANEL, 2012);
(SCRUM) -
(SCHWABER, 2002).
8
Realizar o
Mapeamento do
Fluxo de Valor
(Estado Futuro)
Com o plano de ações de melhorias e as atividades não agregadoras
de valor eliminadas ou reduzidas, um novo MFV, agora visando um
estado futuro, pode ser mapeado, resultado em novos Lead Time e
TVA para o setor.
Lean Office (GREEF; FREITAS;
ROMANEL, 2012)
9
Repetir a sistemática
para os setores
seguintes, até
finalizar todas as
áreas da empresa
Após os resultados serem apresentados e validados pela empresa,
esta etapa propõe a continuidade dos estudos, ou seja, aplicando a
sistemática no setor estudado e aplicar também nos demais setores
da organização, visando a melhoria em todo fluxo de
desenvolvimento de produtos da empresa.
Lean Office,
Gerenciamento
Ágil de
Projetos
(Scrum)
(GREEF; FREITAS;
ROMANEL, 2012);
(SCHWABER, 2002).
Fonte: Elaborado pelo autor.
62
4.1 OBJETIVOS DA SISTEMÁTICA DE MELHORIAS
A sistemática propõe uma pesquisa preliminar em campo para
coletar dados que se converterão em informações necessárias para a
escolha do setor (alvo inicial). Nesta pesquisa de campo, reuniões com
os gestores da empresa são imprescindíveis, uma vez que estes
entendem o dia-a-dia da organização e possuem o conhecimento sobre
os pontos e setores que precisam ser estudados e compreendidos. As
etapas desta sistemática utilizam como objetivo a escolha de um destes
setores da empresa que possui significativa relevância para a
organização e maior inter-relação com as demais áreas da empresa. A
Figura 7 ilustra os objetivos da sistemática de melhorias de processos.
Figura 7 - Ilustração da Sistemática
Fonte: Elaborado pelo autor.
A estratégia da sistemática é aplicar as melhorias no setor
escolhido para que este possa evidenciar problemas não somente do
setor, mas também problemas associados aos demais setores da
empresa, os quais servirão de próximos alvos para seguintes iterações da
sistemática.
63
5. RESULTADOS
Neste tópico serão apresentados o objeto de estudo em questão, a
aplicabilidade da sistemática de melhorias e os resultados obtidos com a
proposição de aplicação.
5.1 A ORGANIZAÇÃO
A organização pesquisada, criada na década de 1990 por
iniciativa de seu fundador, é caracterizada por desenvolver atividades
voltadas ao desenvolvimento de softwares para a realização de estudos,
controle e projetos nas áreas de logística e transportes, atuando em
sistemas logísticos, macrologística, planejamento, organização,
operação de sistemas de transporte e avaliação de projetos.
A empresa conta com equipes de desenvolvimento, de qualidade,
de análise e de treinamento para o desenvolvimento de seus sistemas.
Por razões de confidencialidade das informações, a empresa será
chamada de „Empresa XY‟, sendo que todo e qualquer tipo de
caracterização da empresa será mantido no mais absoluto sigilo para
realização da pesquisa.
5.2 DESCRIÇÃO DO PROCESSO DE DESENVOLVIMENTO DE
SOFTWARES
Até a sua concepção final, os sistemas desenvolvidos passam
direta ou indiretamente por todos os setores da organização. O cliente,
dirigido como parceiro, reúne-se com o gestor da empresa e explica sua
atual necessidade e requisitos. Ao final desta reunião, um plano de
trabalho é esboçado para a execução do desenvolvimento do sistema
solicitado. O gestor elabora uma documentação oficial do plano de
trabalho, se reúne com o setor de análise de sistemas e repassa esse
plano de trabalho ao setor. O analista pensará em uma forma de atender
a necessidade do cliente através de funcionalidades do software.
Cada demanda de software realizada pelo cliente é considerada
um novo projeto de desenvolvimento, podendo a empresa XY possuir
mais de um projeto demandado por mais de um cliente, sendo
trabalhados simultaneamente, ou seja, mais de um sistema pode estar
sendo desenvolvido paralelamente. Desta forma, cada projeto terá um
produto final, sendo este um sistema desenvolvido.
No plano de trabalho encontram-se todas as especificações e
necessidades que o sistema deverá atender. O analista de sistemas, após
64
estudar o plano de trabalho, modela uma solução para a atual
necessidade e elabora um artefato de engenharia do sistema a ser
desenvolvido, contendo ilustrações do layout deste sistema e as
funcionalidades que o compõe. Estas funcionalidades atenderão às
necessidades do cliente. Após isto, a documentação é passada para o
setor de desenvolvimento de sistemas para a implementação das
funcionalidades conforme o artefato de engenharia do sistema.
As funcionalidades do sistema são desenvolvidas a fim de
satisfazer o que se encontra neste artefato e, consequentemente, no
plano de trabalho. Realizadas as implementações das funcionalidades, a
Equipe de Desenvolvimento fornece uma versão do sistema para a
Equipe de Qualidade de Software realizar suas atividades de teste. Após
os testes realizados, a Equipe de Qualidade registra os problemas e
sugestões de melhorias para que a Equipe de Desenvolvimento possa
implementar as devidas correções e assim disponibilizar uma nova
versão do sistema para a Equipe de Qualidade realizar a verificação das
correções e sugestões passadas e apontar novos situações, e procederá
desta forma até que uma versão estável do sistema possa estar
disponível para um primeiro contato do cliente.
A Equipe de Qualidade, à medida em que o sistema amadurece,
participa da elaboração dos materiais de uso do sistema para a entrega
final ao cliente junto com o software desenvolvido, sendo este material
composto pelo Manual de Usuário e a Apostila de Treinamento. A
Equipe de Treinamento realiza reuniões para viabilizar o contato final e
efetivo do cliente com o sistema desenvolvido, fornecendo toda e
qualquer explicação sobre as funcionalidades implementadas a partir de
casos de uso no dia-a-dia do solicitante.
5.3 OBJETO DE ESTUDO
O setor escolhido para a realização da presente pesquisa é a
Equipe de Qualidade de Software da Empresa XY, responsável pela
identificação de erros e proposições de melhorias aos sistemas
desenvolvidos. Optou-se pela Equipe de Qualidade de Software para a
aplicação dos conceitos estudados na atual pesquisa em virtude da
importância do setor para o atual fluxo de desenvolvimento dos sistemas da organização.
A Equipe de Qualidade de Software é responsável pela inspeção
constante do sistema, verificando a existência de erros e propondo
melhorias não somente ao sistema em si, como também ao processo
65
geral de desenvolvimento. A equipe é responsável ainda pela avaliação
constante dos sistemas quando aos requisitos exigidos pelos clientes.
Atualmente, o setor de qualidade de software apresenta
dificuldade na priorização de projetos e, por consequência, na
priorização de sistemas a serem testados em virtude do pouco
envolvimento do setor com as outras áreas de planejamento e
desenvolvimento. Desta forma, uma série de reuniões não planejadas,
assim como necessidade de solicitação de documentações sobre os
projetos e o tempo que necessita esperar por esta documentação são
considerados desperdícios não somente para a equipe, mas para a
organização.
Além desta situação, atividades não planejadas ou planejadas
para ocasiões diferentes sendo demandadas fora de prazos
informalmente definidos quebram o mínimo planejamento e o controle
de atividades da Equipe de Qualidade, resultando em atrasos na entrega
das versões dos sistemas testados e a falta de qualidade na execução das
atividades. Ou seja, todo o fluxo de desenvolvimento sofre as
consequências destas situações.
Ademais, com as atenções voltadas para a Equipe de Qualidade
de Software, existirá a possibilidade do levantamento de desperdícios,
falhas e problemas na execução das atividades operacionais, no
gerenciamento e consolidação de processos no fluxo de
desenvolvimento de sistemas. Uma vez que a Equipe de Qualidade está
envolvida com todos os setores participantes do fluxo geral de
desenvolvimento do produto, será possível usar o objeto de estudo como
indicador na investigação da origem das falhas em processos
encontradas pela própria Equipe de Qualidade realizando testes no
software e encontrando erros no sistema.
O relato de cada problema realizado pela Equipe de Qualidade
não identifica somente erros no sistema, mas também falhas nos
processos até a implementação da (s) funcionalidade (s) que
apresentaram os erros encontrados, ou seja, a qual ou quais
etapas/setores no desenvolvimento dos sistemas pertencem os erros
apontados pelo setor de qualidade. Desta forma, em reunião com o
gestor da empresa, foi explicado este ponto de vista analisado pelo autor
e o mesmo concordou com os estudos na área, repassando ainda
problemas prévios que havia confrontado a algum tempo.
Sendo assim, como primeira análise, a Figura 8 mostra
impedimentos e desperdícios previamente identificados mediante a
reuniões com a Equipe de Qualidade de Software.
66
Figura 8 - Impedimentos e Desperdícios Prévios
Fonte: Elaborado pelo autor.
De acordo com os princípios e desperdícios abordados no Lean Office, os eventos destacados em vermelho geram retrabalhos,
desperdícios e aumento no tempo de entrega dos sistemas produzidos
pela Equipe de Qualidade, os relatórios de testes e o material parcial de
uso dos sistemas. O Quadro 5 a seguir relaciona estas situações iniciais
encontradas nas atividades da Equipe de Qualidade de software aos
princípios e desperdícios abordados no Lean Office.
Quadro 8 - Relação dos desperdícios prévios com a literatura
Eventos encontrados na Equipe de
Qualidade
Desperdícios abordados no lean
office (LAGO; CARVALHO;
RIBEIRO; 2008)
Demandas de testes solicitadas fora do
prazo pré-estabelecido.
Aumento do lead time através de
atrasos dos prazos de entrega
Solicitação de documentações sobre os
sistemas a serem testados.
Aumento do lead time através de
atrasos dos prazos de entrega;
Tempos de espera diversos.
Reuniões não planejadas.
Processamento de informações
desnecessárias; Retrabalho na
produção.
Demandas de atividades não planejadas
para a equipe.
Aumento do lead time através de
atrasos dos prazos de entrega
Quebra no prazo de outras atividades
previamente planejadas.
Aumento do lead time através de
atrasos dos prazos de entrega
Equipe deveria estar dando enfoque em
testes exploratórios nos sistemas
desenvolvidos, servindo de clientes internos
à Empresa XY.
Objetivos departamentais não
alinhados com a estratégia global
da empresa.
Fonte: Elaborado pelo autor.
67
5.3.1 Equipe de Qualidade de Software
Atualmente, a Equipe de Qualidade de Software conta com quatro
colaboradores, sendo estes três testadores e um supervisor. O gestor do
sistema é o responsável pela liderança de toda a Equipe de
Desenvolvimento, Análise e por Qualidade. A Figura 9 mostra o
organograma da Equipe de Qualidade da organização em questão. Figura 9 - Organograma da Equipe
Fonte: Elaborado pelo autor.
5.3.2 Atividades da Equipe de Qualidade de Software
O propósito da Equipe de Qualidade de Software, como levantado
anteriormente, é efetuar uma série de inspeções e revisões com o
objetivo de assegurar a qualidade do uso dos sistemas desenvolvidos. As
atividades de teste desempenhadas atualmente pelo setor de qualidade
são:
a) Testes funcionais: É o teste realizado após o
desenvolvimento do sistema ou alteração solicitada. É
verificado se as funções estão cumprindo com todos os
critérios estabelecidos na etapa de planejamento do sistema.
São identificados possíveis ajustes e é oferecido um
feedback da forma de relatórios de testes para as equipes de
análise de sistema e de desenvolvimento;
b) Testes exploratórios: É o teste de harmonização das
funcionalidades do sistema desenvolvido, uma vez que
quando são implantadas correções em uma funcionalidade,
outras podem sofrer interferência. Neste teste ainda, com o
auxílio de um check list, o sistema é revisado como um todo.
Além destas atividades de teste, a Equipe de Qualidade de
Software realiza atividades de suporte, como elaboração de apostilas
Gestor das Equipes
Testador 1 Testador 2 Testador 3
Supervisor
68
para o treinamento dos clientes quanto a usabilidade dos sistemas
desenvolvidos e manuais dos softwares. Os „sistemas‟ dos processos
realizados pela Equipe da Qualidade de Software, ou seja, relatórios de
teste e materiais, interferem diretamente no sistema final e em seu fluxo
de desenvolvimento.
a) Elaboração de Manuais dos sistemas: Junto ao sistema,
deve ser entregue um manual do usuário que deverá conter
explicações de como funciona o sistema, objetivo de cada
funcionalidade, ilustrações e exemplos de utilização. A
Equipe da Qualidade auxilia na elaboração desse
documento.
b) Elaboração de Apostilas de Treinamento: Nas fases finais
da criação dos sistemas, para apresentação e entrega ao
cliente, deve ser preparado um treinamento pela Equipe de
Treinamento. Devido ao entendimento do sistema adquirido
durante o acompanhamento do processo de criação, a Equipe
da Qualidade é responsável por auxiliar na elaboração de
apostilas e no planejamento do treinamento.
A Figura 10 ilustra as atividades desenvolvidas pela Equipe de
Qualidade de Software. Conforme mencionado anteriormente, os
„produtos‟ dos processos realizados pela Equipe da Qualidade de
Software, ou seja, relatórios de teste e os materiais parcialmente
elaborados, interferem diretamente no fluxo de desenvolvimento e
entrega do sistema ao cliente.
69
Figura 10 - Atividades da Equipe de Qualidade de Software
Fonte: Elaborado pelo autor.
70
5.4 DADOS
Neste tópico serão abordadas as considerações prévias para a
coleta e análise dos dados disponíveis para a realização da pesquisa,
assim como a forma e as ferramentas utilizadas para a coleta.
5.4.1 Considerações iniciais
Antes do início da descrição desta fase da pesquisa, alguns pontos
devem ser esclarecidos quanto às decisões iniciais do presente trabalho.
Como aborda a literatura, o Mapeamento do Fluxo de Valor
(MFV) no estudo do lean office é uma adaptação do MFV provindo do
lean manufacturing. São utilizados os princípios e metodologias do
MFV, uma vez que se tem interesse na redução do Lead Time dos
processos da Equipe de Qualidade de Software a partir da identificação,
análise e eliminação de desperdícios voltados às atividades
organizacionais. Diante disto, a presente pesquisa seguiu as
recomendações da literatura relacionada ao MFV no estudo do Lean
Office de maneira adaptada à realidade da empresa.
Para o mapeamento dos processos da organização, a notação
utilizada foi a BPMN (Business Process Management Notation), uma
vez que se trata da notação mais moderna e amplamente mais aceita para
modelagem de processos (PAVANI JÚNIOR; SCUCUGLIA, 2011).
Como se trata de um ambiente de escritório, os dados disponíveis para o
estudo do lean office são referentes ao fluxo informacional, aos
processos de atividades da organização, sequenciamento das atividades
e tempos de ciclo para cada uma destas, o que difere um pouco da
abordagem do Lean voltado ao manufacturing.
Apesar destas dificuldades na adaptação do MFV abordado no
Lean Manufacturing ao MFV do Lean Office, a disponibilidade de
dados que se tem para a realização da presente pesquisa é justamente
relacionada aos principais pilares no estudo do lean voltado à ambientes
de escritório, uma vez que os princípios da mentalidade enxuta são
aplicados principalmente nos fluxos informacionais e processos de
atividades (LAGO; CARVALHO; RIBEIRO; 2008).
Desta forma, acredita-se que a utilização do BPMN como notação
para o mapeamento de processos e da necessidade de adaptação do
MFV abordado no Lean Manufacturing ao MFV do Lean Office para o
mapeamento dos estados atual e futuro do setor estudado não interferirá
nos conceitos e resultados esperados na busca da aplicação da
mentalidade enxuta e ágil no objeto de estudo.
71
5.4.2 Coleta dos Dados
Em geral, no estudo do lean manufacturing, para a coleta de
dados a equipe responsável pela análise e identificação de melhorias
percorre toda a planta do chão de fábrica, seguindo todos os passos do
fluxo produtivo no chamado “porta-a-porta”, iniciando pela expedição
final e em seguida nos processos anteriores (ROTHER; SHOOK, 2012).
A equipe descreve em folhas padrão cada situação envolvendo o sistema
estudado, cronometrando o tempo gasto em cada processo e medindo a
distância percorrida em cada etapa.
Concluída esta etapa, existe a divisão das atividades que agregam
valor, as que não agregam valor e as atividades que não agregam valor,
porém são necessárias para as atividades que agregam valor ao sistema
aconteçam, separando ainda os elementos do fluxo em processos,
inspeções, movimentações, estoques e esperas, de forma a facilitar a
identificação dos desperdícios e melhorias para o processo.
Para o presente trabalho, foram utilizados os mesmos
procedimentos, porém com as folhas padrão de maneira adaptada ao
Lean Office e as informações dispostas em tabelas. Para cada tarefa
dentro de cada processo da Equipe de Qualidade de Software existe uma
tabela contendo a descrição de suas atividades, o tempo de realização de
cada tarefa e a distinção entre as tarefas que agregam e não agregam
valor aos sistemas produzidos pela equipe. A grande diferença do chão
de fábrica está na intangibilidade, uma vez que o que está em contínuo
movimento entre as tarefas são informações. Logo, ao invés de seguir o
sistema de setor para setor, foi realizada uma verificação do andamento
do sistema desenvolvido no sistema de informação adotado pela
empresa XY a partir de registros. O Apêndice A mostra os dados
coletados relacionados aos processos da Equipe de Qualidade de
Software.
A partir destes dados coletados, juntamente com as descrições
detalhadas de cada fluxo durante as reuniões com os líderes e gestor da
empresa, foi possível fazer uma representação gráfica do fluxo geral do
processo produtivo assim como dos processos da Equipe de Qualidade
de Software. Desta forma, será possível fazer uma análise para a
identificação dos desperdícios, falhas e retrabalhos nas tarefas
desempenhadas, que será visto nos tópicos seguintes.
72
5.5 ESTADO ATUAL
A análise do estado atual reflete a atual situação do objeto de
estudo quanto a seus processos, seu fluxo informacional, seu fluxo de
materiais e recursos disponíveis (ROTHER; SHOOK, 2012). Ao adaptar
o estudo do mapeamento do estado atual originado do lean
manufacturing para o lean office, torna-se relevante somente o
mapeamento dos processos da organização e o mapeamento do fluxo
informacional, constituintes dos princípios da mentalidade enxuta
trazidos pelo lean office (GREEF; FREITAS; ROMANEL, 2012). Desta
maneira, são realizados os mapeamentos dos processos e fluxo
informacional da Equipe de Qualidade de Software, objeto de estudo do
presente trabalho.
5.5.1 Mapeamento do Fluxo Geral de Desenvolvimento de Softwares
O mapeamento do fluxo geral de desenvolvimento de sistemas foi
realizado com base nos dados coletados em reuniões conjuntas com o
gestor geral das equipes de desenvolvimento, análise e qualidade de
software, assim como com os líderes dos projetos e ao menos três
colaboradores de cada área distinta. O Apêndice B mostra o
Mapeamento do Fluxo Geral Detalhado do Sistema entre as áreas da
Empresa XY. A Figura 11 mostra o fluxo geral de desenvolvimento de
softwares „porta-a-porta‟.
73
Figura 11 - Fluxo "Porta-a-Porta"
Fonte: Elaborado pelo autor.
5.5.2 Processos da Equipe de Qualidade de Software
Para uma melhor compreensão e análise do sequenciamento e
relação das tarefas realizadas pela equipe, foram mapeados os processos
de atividades de acordo com seu estado atual, mostrado nos Apêndices
C, D e E. Como explicado no item 5.4.2, a notação utilizada para o
mapeamento do estado atual no fluxo de valor dos processos da equipe
será o BPMN, de forma a não perder os princípios do MFV e a notação
garantir uma ampla visão do fluxo, auxiliando da identificação dos
desperdícios e proposições de melhoria.
Oliveira (2011) conceitua processo como um conjunto de ações
ordenadas e integradas para um fim produtivo específico, onde ao final
serão gerados sistemas, serviços e/ou informações. No contexto das
competências pertencentes a Equipe de Qualidade de Software
74
apresentado anteriormente, foram mapeados os processos relacionados
às atividades desempenhadas pela equipe com o objetivo de analisar não
somente os seus processos de atividades, mas por consequência os
processos de atividades das outras áreas do fluxo de desenvolvimento
dos sistemas. Como citado anteriormente, para a elaboração do
mapeamento de processos, foi utilizada a Notação de Modelagem de
Processos de Negócio (BPMN – Business Process Management
Notation).
Através deste mapeamento, buscou-se conhecer todos os
processos envolvidos na realização das atividades da Equipe de
Qualidade, assim como as atividades que são executadas em cada
processo, os envolvidos nas dependências da área onde estas atividades
são desenvolvidas, a quem estas atividades estão relacionadas e como as
mesmas são realizadas. Segundo Hunt (1996), o mapeamento de
processos é uma ferramenta que realiza a identificação e análise de
processos permitindo a redução de falhas, sendo ainda uma excelente
ferramenta para entender a situação atual dos processos e identificar os
que necessitam melhoria ou mudança.
Como auxílio ao mapeamento de processos, foi utilizado o
software Bizagi Modeler por se tratar de uma ferramenta gratuita de
BPMN e que permite a criação de fluxogramas, mapas mentais e
diagramas em geral, possibilitando ao usuário a organização gráfica de
processos e as relações existentes em cada etapa. Com os processos na
notação BPMN, uma série de reuniões foram realizadas com a equipe
para o processo de validação dos mapeamentos, assim como para o
esboço inicial de cada processo. Nestas reuniões foram utilizadas
técnicas de interação dos membros do grupo para validações e
ampliações dos mapeamentos, como grupo focal. Esta etapa de esboço
inicial de processos e etapas de validação ocorreram em cinco reuniões
com a equipe, com uma duração média de uma hora e meia por reunião.
Sendo assim, foram mapeados os três processos de atividades da
Equipe da Qualidade de Software:
Processo Inicial de Testes nos Sistemas (1);
Processo de Validação de Correções nos Sistemas
Desenvolvidos (2);
Processo de Auxílio à Elaboração de Materiais para o
Cliente (3).
No Processo Inicial de Teste nos Sistemas, disponibilizado no
Apêndice C, a Equipe da Qualidade tem o primeiro contato com o
75
sistema desenvolvido pela Equipe de Desenvolvimento, onde deverá ser
realizada a análise das primeiras funcionalidades implantadas no sistema
de acordo com os critérios estabelecidos pelo cliente e layout geral.
Após a liberação da versão do sistema para testes, a equipe
solicita a documentação referente ao sistema a ser testado para a
compreensão de todas as funcionalidades nele existentes. A medida que
a equipe vai analisando o sistema, problemas, incompatibilidades e
proposições de melhorias são encontradas e reportadas para a Análise de
Sistemas. Este processo é composto por nove tarefas, um subprocesso e
três tarefas pertencentes ao subprocesso. O subprocesso é indicado pela
notação em formato de cruz na atividade do processo.
Tarefas:
Receber a versão do sistema para testes;
Solicitar a documentação relacionada ao sistema;
Analisar documentação;
Informar aos envolvidos do projeto o início dos testes;
Informar ao gestor da equipe sobre a distribuição de tarefas;
Realizar os testes;
Consultar o analista de sistema;
Registrar na ferramenta de cadastro;
Informar envolvidos do projeto o fim dos testes.
Subprocesso:
Preparar ambiente de testes.
Tarefas do Subprocesso:
Instalar versão do sistema nos computadores de teste;
Informar responsável pela versão do sistema e solicitar base
correta;
Criar um usuário de testes.
O Processo Inicial de Teste nos Sistemas mostra o mapeamento do fluxo do processo, identificando as tarefas, o subprocesso e as tarefas
do subprocesso descritas anteriormente. O subprocesso foi destacado em
seguida. O Processo de Validação de Correções nos Sistemas,
indicado pelo Apêndice D, ocorre quando a equipe de testes já teve
76
contato com o sistema desenvolvido em questão através da primeira
versão disponibilizada para testes.
A cada teste realizado, problemas e sugestões de melhoria são
encontrados na versão atual do sistema. Sendo assim, ao fim dos testes,
a Equipe de Qualidade informa os envolvidos do projeto sobre a
finalização dos testes e então o analista de sistemas faz análise do que
foi encontrado pela Equipe de Qualidade para que assim possa
selecionar o que será de fato corrigido, desenvolvido ou melhorado no
sistema. Feita esta triagem, o analista passa para o desenvolvedor o que
ele deve alterar no sistema e este realiza as implementações.
Após isto, o desenvolvedor lança uma nova versão do sistema
para a Equipe de Qualidade testar novamente o sistema, sendo que será
testado aquilo que foi implementado (correções, melhorias, ajustes) e
também testes exploratórios nas funcionalidades que podem ter sido
afetadas pelas modificações. Este processo é cíclico e começa a ocorrer
após o primeiro processo de teste ser executado e finalizado. Na Figura
12 abaixo segue a interação existente entre as equipes de Qualidade,
Análise e Desenvolvimento esquematizada.
Figura 12 - Inter-relação entre setores
Fonte: Elaborado pelo autor.
Geralmente variando de projeto para projeto, as funcionalidades
dos sistemas são desenvolvidas em etapas e assim vão sendo liberadas
77
para a Equipe da Qualidade realizar os testes. A forma de comunicação,
ou seja, a maneira que a equipe de testes relata os problemas e sugestões
de melhoria encontradas é por meio de relatórios de testes cadastrados
em uma ferramenta de gerenciamento de projetos. Com esta ferramenta,
é realizada a triagem dos problemas, ajustes e sugestões de melhorias
encontradas nos sistemas por versão pela Equipe de Qualidade até que
haja uma última versão com todas as funcionalidades implementadas e
funcionando de acordo com o esperado. Este processo é composto por
nove tarefas, sendo descritas a seguir.
Validar correções;
Solicitar documentação da (s) nova (s) funcionalidade (s);
Analisar documentação;
Informar aos envolvidos do projeto o início dos testes;
Informar ao gestor da equipe sobre a distribuição de tarefas;
Testar funcionalidade (s) nova (s) do sistema;
Consultar o analista do sistema;
Relatar na ferramenta de cadastro;
Informar aos envolvidos do projeto o fim os testes.
No Processo de Auxílio na Elaboração de Materiais para o
Cliente, indicado pelo Apêndice E, a Equipe da Qualidade participa
ativamente da elaboração de apostilas de treinamento das
funcionalidades dos sistemas para o cliente, assim como na elaboração
de manuais de usuário. O processo serve de auxílio para a Equipe de
Treinamento, sendo demandado pelo solicitante a medida em que as
funcionalidades dos sistemas vão sendo implantadas. A Equipe da
Qualidade realiza os testes nas funcionalidades, como descreve o
processo de Processo de Validação de Correções nos Sistemas
Desenvolvidos e, nos intervalos de testes nos sistemas, vai escrevendo o
material.
No caso da apostila de treinamento, a equipe elabora exercícios
com casos de uso do cliente, os quais seguirão para serem escritos na
apostila após a validação do solicitante da Equipe de Treinamento. Em
caso de manual de usuário, a Equipe de Testes, à medida que as
funcionalidades vão sendo implantadas, escreve um guia de como utilizar cada funcionalidade, apresentando interfaces e uso específico.
A equipe conta com o auxílio do analista de sistemas em caso de
dúvidas ou dificuldades relacionadas as funcionalidades. O
procedimento também funciona como um teste exploratório, uma vez
78
que em caso de uma funcionalidade não estar funcionando conforme o
esperado, na confecção de manuais e apostilas os problemas se
evidenciam. Foram mapeadas uma tarefa, um subprocesso e sete
subtarefas ao Processo de Auxílio à Elaboração de Materiais para o
Cliente. São os seguintes elementos:
Tarefa:
Analisar a demanda.
Subprocesso:
Elaboração do material.
Tarefas do Subprocesso:
Escrever manual com todas as funcionalidades do sistema;
Conversar com o solicitante e/ou analista de sistemas;
Informar ao solicitante o fim da escrita da apostila;
Elaborar os exercícios do treinamento para a apostila;
Validar com solicitante;
Escrever apostila de treinamento;
Informar solicitante o fim da escrita do manual.
5.5.3 Mapeamento do Fluxo de Informações dos processos da
Equipe de Qualidade de Software
Após o mapeamento dos processos da Equipe de Qualidade de
Software, foram levantadas todas as informações de entrada e saída para
cada atividade realizada pela equipe. As informações foram levantadas a
partir da realização de reuniões periódicas com a toda a Equipe de
Qualidade, foi possível fazer um levantamento das informações, origem,
local de disponibilização, entre outros dados.
Segundo Greef, Freitas e Romanel (2009), o levantamento em
conjunto ao ambiente de estudo é de suma importância, uma vez que a
participação das pessoas que atuam nos processos de informações é um
diferencial para a proposição e viabilização de soluções para problemas relacionados ao trabalho. Ainda segundo os autores, o mapeamento do
fluxo de informação possibilita a análise não somente dele próprio,
como também a identificação de problemas de desempenho ou falta de
qualidade. O resultado do levantamento de todas as informações de
79
entrada e saída para cada uma das atividades de cada processo da
Equipe de Qualidade de Software encontra-se no Apêndice F.
As informações de entrada e saída para cada atividade servirão
para o mapeamento do fluxo de informação para cada processo da
Equipe de Qualidade. Desta forma, desperdícios relacionados ao fluxo
informacional poderão ser identificados, classificados e tratados, assim
como a identificação da origem de cada um.
Primeiramente, cada processo é analisado de maneira individual,
sendo realizada a identificação e análise de cada informação necessária
para o andamento do processo. Feito isto, são mapeados os fluxos
informacionais relacionados a cada processo de atividades da Equipe de
Qualidade de Software. Com base nas informações levantadas no item
anterior, foram mapeados os fluxos informacionais de cada processo,
mostrados no Apêndice G.
5.5.4 Atividades Agregadoras de Valor
Ao realizar os mapeamentos dos processos e do fluxo
informacional de cada um dos processos da Equipe de Qualidade de
Software, para identificar o fluxo de valor entre as atividades da equipe
faz-se necessária a análise das atividades que agregam valor ao sistema
final de saída da equipe. São as atividades que têm valor ao cliente final,
ou seja, que o solicitante do sistema reconhece como válidas para o
processo produtivo, espera que as executem e que estaria disposto,
inclusive, a remunerar a empresa por estas atividades (ROTHER;
SHOOK, 2012).
A Equipe de Qualidade de Software possui atualmente dois
sistemas finais produzidos por seu setor: relatórios de testes nos
sistemas e materiais de uso dos softwares parcialmente elaborados.
Desta forma, esta etapa consiste em analisar as atividades mapeadas em
cada processo que resulta em cada sistema da Equipe de Qualidade de
Software e, juntamente com o gestor e supervisor da equipe através de
reuniões estratégicas, observar quais das atividades que estão sendo
realizadas agregam valor ao cliente final e, por consequência, eliminar
as atividades que não agregam valor.
Vale destacar que a análise está sendo realizada em uma equipe
específica que compõe fluxo geral do processo de desenvolvimento de
sistemas, na qual os dois sistemas resultantes dos processos da Equipe
de Qualidade de Software são considerados sistemas intermediários ao
sistema final da organização, os softwares desenvolvidos. Desta forma,
as atividades consideradas agregadoras de valor ao sistema principal da
80
Equipe de Qualidade de Software – os relatórios de testes – e as
atividades agregadoras de valor relacionadas ao outro sistema da equipe
– foram analisadas separadamente por processo, na adaptação em
tabelas das folhas padrão comumente utilizadas por equipes Kaizen na
análise de processos. Foram coletadas e analisadas informações sobre a
descrição das atividades, o valor agregado desta atividade para a
viabilização dos sistemas da equipe, as distâncias percorridas
(necessárias nas folhas padrão de análise, porém iguais a zero entre as
atividades de escritório) e os tempos de ciclo de cada atividade. Os
resultados são observados no Apêndice A.
5.5.5 Taxa de Valor Agregado
Com as informações sobre as atividades que agregam e as que
não agregam valor aos sistemas da Equipe de Qualidade de Software,
pode-se realizar um levantamento sobre a situação atual de agregação de
valor das atividades da equipe. Este levantamento é de suma
importância para as decisões que serão tomadas em sequência,
relacionadas à identificação de quais atividades deverão ser eliminadas
ou minimizadas ao máximo para que os processos possam fluir de
maneira enxuta.
Vale ressaltar que, em geral, as atividades de testes em produtos
na visão do lean não são atividades agregadoras de valor, uma vez que
teoricamente não modifica o produto, mas apontam erros. Porém, as
atividades do setor de Qualidade de Software fazem parte do “ciclo de
vida” do fluxo geral de desenvolvimento de sistemas
(SOMMERVILLE, 2003), sendo então, necessariamente, agregadoras
de valor ao produto final. A Tabela 1 mostra o resultado deste
levantamento.
Tabela 1 - Taxa de Valor Agregado das Atividades
SITUAÇÃO ATUAL DE AGREGAÇÃO DE VALOR DAS ATIVIDADES
DA EQUIPE DE QUALIDADE DE SOFTWARE
Atividades dos Processos VA
(horas)
Tempo Total
(horas)
Taxa de Valor
Agregado
Receber a versão do sistema para
testes 0 1,5 0,0%
Preparar ambiente de testes 0 0,5 0,0%
Solicitar documentação sobre o
sistema 0 16 0,0%
Analisar documentação 2 8 25,0%
Informar envolvidos do projeto o 0 0,033 0,0%
81
início dos testes
Informar gestor sobre a distribuição
das tarefas 0 0,333 0,0%
Realizar os testes 8 18 44,4%
Consultar analista de sistemas 1 8 12,5%
Registrar na ferramenta de cadastro 0,033 0,5 6,6%
Informar envolvidos do projeto o
fim dos testes 0 0,033 0,0%
Validar correções 2 12 16,7%
Solicitar documentação da (s) nova
(s) funcionalidade (s) 0 8 0,0%
Realizar testes exploratórios no
sistema 4 18 22,2%
Analisar a demanda 0 0,333 0,0%
Escrever manual com todas as
funcionalidades do sistema 1 18 16,7%
Conversar com solicitante e/ou
analista de sistemas 0 1 0,0%
Informar solicitante do fim da
escrita do manual 0 0,033 0,0%
Elaborar os exercícios do
treinamento para a apostila 1 18 0,0%
Validar com solicitante 0 1 0,0%
Escrever apostila de treinamento 1 18 0,0%
Informar solicitante do fim da
escrita da apostila 0 0,5 0,0%
Outras VA
(horas)
Tempo Total
(horas)
Taxa de Valor
Agregado (%)
Reuniões com solicitante do
material 0 8 0,0%
Reuniões em equipe 0 14 0,0%
Reuniões com analista de sistemas 0 15 0,0%
TOTAL 20,033 184,765 10,8%
Fonte: Elaborado pelo autor.
Os valores dos tempos de execução de cada atividade foram
coletados a partir da consulta do atual sistema de controle de tarefas
adotado pela equipe, através da consideração das médias dos tempos
gastos em cada atividade encontrados em 40 (quarenta) amostras coletadas aleatoriamente. Foram considerados os tempos gastos em um
período semanal, uma vez que as jornadas de trabalho da equipe são
controladas em horas semanais. Os tempos são fornecidos pelo sistema
82
em minutos, porém para a realização do estudo serão utilizados os
tempos em horas, com a devida conversão de unidades realizada.
A estimativa de quanto desse tempo gasto nas atividades gera
efetivamente o valor devido aos sistemas viabilizados pela equipe foram
realizados através do acompanhamento das atividades realizadas pela
Equipe de Qualidade de Software durante o período duas semanas. Para
isto, foram considerados o tempo total utilizado para a realização das
atividades subtraído deste o tempo gasto em tarefas e situações
imprevistas. Feito isto, foram encontradas taxas de valor agregado em
cada atividade, resultando em um total de 10,8% de valor agregado nas
atividades dos atuais processos da Equipe de Qualidade, como mostra a
Tabela 1.
5.5.6 Lead Time dos Processos da Equipe de Qualidade de Software
De acordo com Fernandes e Filho (2009), o Lead Time de um
processo é o tempo que faz a ligação entre a liberação de uma ordem de
serviço até o produto final pronto para uso. Este tempo é de suma
importância para a identificação do tempo desperdiçado com atividades
que não agregam valor aos produtos finais da Equipe de Qualidade de
Software.
Para encontrar os valores de Lead Time atuais dos processos da
Equipe de Qualidade de Software, foram somados os tempos de
execução de todas as atividades por processo. Tempos de esperas por
informações, documentações e situações semelhantes estão contidos aos
valores de tempo de execução por atividade, uma vez que a ferramenta
de controle utilizada pela equipe não faz distinção entre tempo de espera
e tempo específico de execução da atividade. A justificativa é que estes
tempos de espera são, na maioria das vezes, variáveis de acordo com o
projeto. Ainda assim, atividades como “Solicitar documentação sobre o
sistema” onde claramente o tempo de espera é o maior causador da
quantidade de horas do Lead Time, foram considerados os piores casos
de espera – por consequência o maior Lead Time – excluindo da análise
amostral as anomalias, os chamados outliers.
Nesta etapa da pesquisa, o foco é a identificação das atividades
geradoras de desperdícios de tempo e que não agregam valor aos
produtos resultantes dos processos da Equipe de Qualidade. Com a
dificuldade apresentada sobre a variação dos tempos de esperas, a
estratégia é a eliminação das atividades não agregadoras de valor e que
geram desperdícios de tempo para que, por consequência, sejam
eliminados os tempos de esperas desnecessários às atividades. A Tabela
83
2 mostra o resultado do Lead Time atual do Processo Inicial de Teste
de Software.
Tabela 2 - Lead time do Processo Inicial de Teste de Software
Processo Inicial de Teste de Software
Tarefa Tempo Total (horas)
Receber a versão do sistema para testes 1,5
Preparar ambiente de testes 0,5
Solicitar documentação sobre o sistema 16
Analisar documentação 8
Informar envolvidos do projeto o início dos testes 0,033
Informar gestor sobre a distribuição das tarefas 0,333
Realizar os testes 18
Consultar analista de sistemas 8
Registrar na ferramenta de cadastro 0,5
Reuniões em equipe 5
Reuniões com analista de sistemas 10
Informar envolvidos do projeto o fim dos testes 0,033
Lead time 67,899
Lead time (em horas) 68
Lead time (em dias de trabalho) 3,8
Lead time (em dias para os 3 testadores) 1,3
Fonte: Elaborado pelo autor.
Nota-se que a Equipe de Qualidade atualmente leva, em média,
aproximadamente 1 (um) dia e meio para concluir o processo inicial de
teste de software, considerando uma jornada de trabalho de seis horas
semanais para cada um dos três testadores. Vale ressaltar que a análise
está sendo feita com base no tempo necessário para iniciar e finalizar
um processo e divisão igualitária na distribuição de tarefas. O objetivo é
analisar o tempo necessário para executar um processo, identificando as
atividades que demandam tempo e podem ser eliminadas.
A solicitação da documentação sobre o sistema, ou seja, a
solicitação do plano de trabalho e/ou do artefato de engenharia do
sistema está levando, em média, 16 (dezesseis) horas desde a solicitação
até a efetiva disponibilização, o que acarreta em prejuízos de atraso nos
testes ou, caso sejam executados sem a documentação em mãos, perda de qualidade na realização dos testes.
Outro ponto importante a se destacar são os tempos gastos em
reuniões de alinhamento entre os membros da equipe e reuniões de
alinhamento com a análise de sistemas. Isto ocorre devido ao fato que a
Equipe de Qualidade de Software na maioria das vezes não dispõe da
84
documentação sobre o sistema ou sobre funcionalidades específicas,
sendo então necessárias reuniões com a análise para que sejam
explicadas estas situações. Como a equipe não consegue se planejar
quanto as demandas, a mesma necessita de reuniões emergenciais para
planejamentos paliativos. Estas atividades, como mostrado no item
anterior, não são atividades agregadoras de valor aos sistemas do setor,
surgindo a necessidade da eliminação ou minimização destas no
processo.
Para o Processo de Validação de Correções nos Sistemas
Desenvolvidos (2), a Tabela 3 mostra o resultado do Lead Time atual.
Tabela 3 - Lead time do Processo de Validação de Correções
Processo de Validação de Correções nos Sistemas Desenvolvidos (2)
Tarefa Tempo Total (horas)
Validar correções 12
Solicitar documentação da(s) nova(s) funcionalidade(s) 8
Realizar testes exploratórios nos sistemas 18
Analisar documentação 8
Informar envolvidos do projeto o início dos testes 0,033
Informar gestor sobre a distribuição das tarefas 0,333
Realizar os testes 18
Consultar analista de sistemas 8
Registrar na ferramenta de cadastro 0,5
Informar envolvidos do projeto o fim dos testes 0,033
Reuniões com analista de sistemas 5
Reuniões em equipe 5
Lead time 82,899
Lead time (em horas) 83
Lead time (em dias de trabalho) 4,6
Lead time (em dias para 3 testadores) 1,5
Fonte: Elaborado pelo autor.
A Equipe de Qualidade atualmente necessita, em média, de 1
(um) dia e meio para a validação de correções nos sistemas
desenvolvidos. Nota-se que novamente a equipe necessita de reuniões
de planejamento de forma paliativa relacionadas as demandas de teste e
reuniões com a análise de sistemas, desta vez para entender como as
correções foram efetuadas no sistema e caso tenham sido implementadas
funcionalidades novas ou alterações nas mesmas. Estas atividades
continuam não agregando valor aos relatórios de teste, uma vez que
além de tomarem muito tempo da equipe, não deveriam ser cruciais para
o andamento do processo.
85
Para o Processo de Auxílio à Elaboração de Materiais do
Cliente (3), dividiu-se em duas vertentes – quanto à produção da
apostila de treinamento e manual de usabilidade –, uma vez que a
equipe, apesar de realizar as duas tarefas, não desenvolve ambas
paralelamente. A Tabela 5 mostra o resultado do Lead Time atual da
apostila.
Tabela 4 - Lead time do Processo de Auxílio à Elaboração de Materiais
(Apostila)
Processo de Auxílio à Elaboração de Materiais - Apostila de
Treinamento
Tarefa Tempo Total (horas)
Analisar a demanda 0,333
Elaborar os exercícios do treinamento para a
apostila 18
Validar com solicitante 1
Escrever apostila de treinamento 18
Informar solicitante do fim da escrita da apostila 0,333
Reuniões com solicitante do material 8
Reuniões em equipe 4
Lead time 49,666
Lead time (em horas) 50
Lead time (em dias de trabalho) 2,8
Lead time (em dias para 3 testadores) 0,9
Fonte: Elaborado pelo autor.
A Equipe de Qualidade atualmente necessita de
aproximadamente 1 (um) dia para a elaboração parcial dos materiais
relacionados ao manual de usabilidade do sistema e metade de um dia
para a elaboração da apostila de treinamento do cliente quanto ao
sistema desenvolvido. Reuniões de planejamento entre os membros da
equipe neste processo continuam sendo necessárias, uma vez que as
demandas quanto à elaboração de materiais chegam sem aviso prévio ou
planejamento. Reuniões com o solicitante, ou seja, Equipe de
Treinamento, atualmente são necessárias para repassar as demandas da
Equipe de Qualidade. Nestas reuniões geralmente são definidas datas
aproximadas de entrega da elaboração parcial do material pela Equipe
de Qualidade, fazendo com que a equipe tenha que mudar todo o planejamento realizado nas reuniões em equipe. A Tabela 6 mostra os
resultados referente ao manual.
86
Tabela 5 - Lead time do Processo de Auxílio à Elaboração de Materiais
(Manual)
Processo de Auxílio à Elaboração de Materiais - Manual de Usabilidade
Tarefa Tempo Total
(horas)
Analisar a demanda 0,333
Escrever manual com todas as funcionalidades do
sistema 18
Conversar com solicitante e/ou analista de sistema 1
Informar solicitante do fim da escrita do manual 0,333
Reuniões com solicitante do material 8
Reuniões em equipe 4
Lead time 31,666
Lead time (em horas) 32
Lead time (em dias de trabalho) 1,8
Lead time (em dias para 3 testadores) 0,6
Fonte: Elaborado pelo autor.
Como as demandas de elaboração de materiais para a Equipe de
Qualidade dividem-se em apostilas ou manuais – dependendo da
periodicidade – será considerado o maior dos tempos finais entre os
processos de elaboração de apostilas de treinamento e manuais de
usabilidade para o Lead Time do processo de elaboração de materiais.
Neste caso, o Lead Time do Processo de Elaboração de Materiais para o
Cliente será de 0,9 dias.
Mapeamento do Fluxo de Valor (Estado Atual)
Com base nas informações e processos da Equipe de Qualidade
de Software mapeados, além de informações quanto ao Lead Time atual
destes processos, o resultado do Mapeamento do Fluxo de Valor para o
estado atual da equipe é mostrado através da Figura X.
Como os Lead Time foram divididos por processos realizados
pela Equipe de Qualidade em virtude da análise específica no setor, o
mapeamento do estado atual foi realizado também por processos,
acompanhando a agregação de valor atual de acordo com os sistemas da
equipe ao final de cada processo.
A estratégia para esta ação se dá pela utilização do setor como
piloto para aplicação da sistemática proposta, uma vez que reduzindo o
Lead Time da Equipe de Qualidade de Software, automaticamente se
reduz o Lead Time total do fluxo geral de desenvolvimento do sistema.
87
Figura 13 - Mapeamento do Fluxo de Valor - Estado Atual
Fonte: Elaborado pelo autor.
88
5.6 ESTADO FUTURO
Na busca pelo estado futuro almejado para os processos da
Equipe de Qualidade de Software, um plano de ações é fundamental
para implantar e posteriormente monitorar as melhorias propostas.
Primeiramente, foram identificados os desperdícios encontrados na
análise do estado atual da Equipe de Qualidade de Software e
adicionados aos desperdícios previamente discutidos com o gestor e
supervisor da equipe, listados de acordo com o Quadro 5, no item 5.3.1
do presente trabalho.
Após isto, os desperdícios foram classificados de acordo com
suas causas e foram propostas melhorias com base na fundamentação
teórica da presente pesquisa. Para esta proposição de melhorias, os
desperdícios foram analisados separadamente de acordo com a
classificação por tipo de problema, onde foi realizado um
enquadramento dos desperdícios encontrados nos fundamentos e
metodologias trazidas pelo Lean Office e Gerenciamento Ágil de
Projetos.
5.6.1 Identificação e Classificação dos Desperdícios
Para a identificação dos desperdícios, falhas, retrabalhos e
proposições de melhorias nos processos da equipe, a presente pesquisa
buscou não somente a análise dos processos da Equipe de Qualidade,
mas também do fluxo geral de desenvolvimento dos sistemas, em
virtude da identificação, através da Equipe de Qualidade de Software, de
desperdícios e falhas nas demais áreas da empresa, uma das motivações
do presente objeto de estudo.
Para isto, dados históricos cedidos pela organização através do
sistema de informação adotado foram analisados, assim como reuniões
com o supervisor e gestor da Equipe de Qualidade de Software foram
realizadas, sendo de grande valia para a fundamentação e validação da
análise. O resultado do levantamento dos desperdícios encontrados e
suas respectivas classificações está disposto no Quadro 8.
89
Quadro 9 - Levantamento e Classificação dos Desperdícios Encontrados
Levantamento e Classificação dos Desperdícios dos Processos da Equipe de Qualidade de Software
Desperdícios / Falhas /
Retrabalhos Descrição Consequências Causas
Enquadramento na
Fundamentação Teórica
Não há definições
concretas de prazos de
entrega dos produtos da
equipe
As demandas de testes são
solicitadas sem que haja um prazo
bem definido, o que acarreta em
uma série de problemas.
Falta de planejamento da
equipe para a realização dos
testes nos sistemas, além da
prejudicar a qualidade dos
testes executados.
Problemas no
gerenciamento
de projetos
Fundamentos e princípios do
Gerenciamento Ágil de
Projetos (SCRUM) -
Flexibilidade em relação aos
prazos (SCHWABER, 1995).
Equipe não tem acesso às
documentações
relacionadas ao sistema
A cada nova demanda de testes, a
equipe precisa solicitar
documentações relacionadas às
especificações das funcionalidades
implementadas nos sistemas,
informação que não é passada para
a equipe de maneira natural, como
esperado.
Qualidade da execução dos
testes é completamente
afetada, uma vez que a equipe
não possui o conhecimento das
funcionalidades e testes são
realizados de maneira não
conforme de acordo com o
cliente.
Problemas no
fluxo de
materiais
Fundamentos e princípios do
Lean Office - Falta de
documentações necessárias
(LAGO; CARVALHO;
RIBEIRO; 2008).
Excesso de reuniões não
planejadas
Reuniões extraordinárias e não
planejadas são rotineiras e
acontecem sem aviso prévio, uma
vez que as documentações
necessárias à Equipe de Qualidade
de Software sobre o sistema não
são repassadas, assim como
qualquer interação do cliente com
a empresa.
Atraso nas demandas de teste,
quebra do mínimo
planejamento realizado pela
equipe.
Problemas no
gerenciamento
de projetos
Fundamentos e princípios do
Gerenciamento Ágil de
Projetos (SCRUM) - Maior
controle no projeto
(SCHWABER, 1995).
90
Tarefas não planejadas
demandadas para a
equipe
A equipe de testes participa, como
anteriormente descrito, do
Processo de Auxílio à Elaboração
de Materiais para o Cliente.
Porém, a Equipe de Qualidade,
como descreve o processo (3)
acaba por realizar toda a
elaboração deste material,
consumindo muito tempo não
previsto, uma vez que não agrega
valor para a Equipe de Qualidade,
mas sim para a Equipe de
Treinamento.
Diminuição do tempo previsto
para as tarefas que agregam
valor às atividades da Equipe
de Qualidade, como o relatório
de testes.
Problemas no
gerenciamento
de projetos
Fundamentos e princípios do
Gerenciamento Ágil de
Projetos (SCRUM) - Maior
controle no projeto
(SCHWABER, 1995).
Atraso das atividades
demandadas para a
equipe
Como o processo de auxílio à
elaboração de materiais não segue
o previamente planejado, ou seja,
além desta demanda não possuir
um prazo definido, a equipe não
executa da forma proposta
(auxiliando, não executando-a por
completo), a tarefa consome mais
tempo do que o previsto para a
Equipe de Qualidade.
Atraso nas entregas dos
relatórios de teste, produto
este principal da Equipe de
Qualidade de Software.
Problemas no
gerenciamento
de projetos
Fundamentos e princípios do
Gerenciamento Ágil de
Projetos (SCRUM) - Maior
controle no projeto
(SCHWABER, 1995).
Necessidade de
informação sobre o início
e fim dos testes a cada
nova demanda
A Equipe de Qualidade precisa
informar, de maneira informal e
sem registro, o início e término de
suas atividades de teste.
Atraso na demanda de testes,
perda de informações, uma
vez que não há formalidade e
registro no aviso.
Problemas no
fluxo
informacional
Fundamentos e princípios do
Lean Office - Centralização de
informações (LAGO;
CARVALHO; RIBEIRO; 2008).
91
Supervisor com a tarefa
de distribuição de tarefas
Atualmente é de responsabilidade
do supervisor da Equipe de
Qualidade a distribuição de tarefas
para a equipe, assim como a
divisão entre os membros.
Originalmente, esta tarefa pertence
ao gestor da equipe.
As atividades desempenhadas
pelo supervisor são
prejudicadas, como a
preparação do ambiente de
testes da equipe (importante
para a realização dos testes
nos sistema pela equipe de
qualidade) entre outras
atividades.
Problemas no
gerenciamento
de projetos
Fundamentos e princípios do
Gerenciamento Ágil de
Projetos (SCRUM) - Melhora a
comunicação e distribuição de
tarefas (DANTAS, 2003).
Número excessivo de
versões dos sistemas
lançadas para teste
Atualmente, o desenvolvedor
implementa as funcionalidades e
correções no produto e lança
versões para teste sem que haja
um teste prévio ou uma atenção
especial no layout básico do
sistema.
Faz com que problemas
pequenos passem
despercebidos e versões com
erros prévios passados para a
Equipe de Qualidade. Isto gera
retrabalho, além do que o
lançamento de versões
demanda tempo, sendo
desnecessário se houvesse um
número menor de lançamento
de versões do sistema.
Problemas no
gerenciamento
de projetos
Fundamentos e princípios do
Gerenciamento Ágil de
Projetos (SCRUM) -
Frequentes revisões do que é
desenvolvido (SCHWABER,
1995).
Informações necessárias
para andamento das
atividades não
disponibilizadas para a
equipe
Informações necessárias para as
atividades relacionadas à equipe
de qualidade não são
compartilhadas, como interações
do cliente com a empresa,
mudanças no sistema, prazos de
entrega final acordadas com o
cliente, entre outras.
Qualidade da execução dos
testes é completamente
afetada, uma vez que a equipe
não possui o conhecimento de
situações importantes na visão
do cliente.
Problemas no
fluxo
informacional
Fundamentos e princípios do
Lean Office - Redução do
tempo de resposta a alterações
de documentos ou processos
(GREEF; FREITAS;
ROMANEL, 2012).
Carência de um
responsável para a
Atualmente, o supervisor executa
o papel mais próximo de gestor da
Sem planejamento eficaz para
a Equipe de Qualidade, perda
Problemas no
gerenciamento
Fundamentos e princípios do
Gerenciamento Ágil de
92
gerência das atividades
da equipe
Equipe de Qualidade de Software,
porém divide estas atribuições
com suas próprias atividades. O
gestor atual gere todas as áreas da
organização, como análise e
desenvolvimento, fazendo com
que seu tempo seja escasso e
priorizado para interações com o
cliente
de tempo passando todas as
informações para o gestor,
perda de qualidade nas
atividades executadas.
de projetos Projetos (SCRUM) - Maior
controle no projeto
(SCHWABER, 1995).
Não há devida interação
com demais setores,
especialmente análise e
desenvolvimento
Atualmente, a Equipe de
Qualidade não interage
diretamente com a análise e
desenvolvimento de maneira
correta, havendo interação
somente quando problemas ou
dúvidas ocorrem, assim como para
buscar informações.
Perda de qualidade na
execução dos testes do
sistema, uma vez que a equipe
não possui conhecimento das
especificações, alterações e
quaisquer interações do
cliente.
Problemas no
gerenciamento
de projetos
Fundamentos e princípios do
Gerenciamento Ágil de
Projetos (SCRUM) -
Colaboração entre os envolvidos
no projeto, objetivando um
processo de desenvolvimento
iterativo (BISSI, 2007).
Fonte: Elaborado pelo autor.
93
5.6.2 Restruturação da Equipe – Gerenciamento Ágil de Projetos
Analisando a Equipe de Qualidade de Software e os problemas
encontrados no setor, uma das razões para o número de desperdícios e
falhas encontrados é a falta de gerenciamento. A equipe conta com um
gestor geral e um supervisor, porém atualmente cabe a este gestor o
gerenciamento de todos os setores de desenvolvimento dos sistemas,
além da interação com os clientes externos.
Desta maneira, existe uma sobrecarga de atividades que não
permite ao gestor maior presença na Equipe de Qualidade de Software,
setor este responsável pela garantia de usabilidade e cumprimento de
requisitos dos sistemas desenvolvidos. O supervisor acaba realizando as
ações de gerenciamento da Equipe de Qualidade e repassando as
informações para o gestor, porém como é responsável por outras
atividades, o gerenciamento acaba sendo prejudicado, além das próprias
atividades desempenhadas, perdendo em qualidade.
Como uma organização típica de desenvolvimento de softwares,
a Empresa XY precisa desenvolver seus sistemas de maneira ágil,
flexível e com auto-organização (TAKEUCHI; NONAKA, 1986). Por
consequência, a Equipe de Qualidade de Software como a maior
indicadora de qualidade não somente dos sistemas desenvolvidos, mas
também dos processos realizados, também necessita incorporar estes
requisitos em seu ambiente de trabalho.
Além destes requisitos, a equipe precisa simplificar seus
processos e torná-los mais flexíveis, reduzindo o tempo de dedicação a
etapas de planejamento quando não se tem a clara noção de prazos e
resultado final, o que geralmente acontece em virtude das frequentes
alterações nos sistemas desenvolvidos por solicitações do cliente. Estes
requisitos se enquadram nos conceitos e filosofias abordados pelo
Gerenciamento Ágil de Projetos, uma vez que a metodologia tem como
características a flexibilidade e ao mesmo tempo simplicidade nos
processos de desenvolvimento de softwares (HIGHSMITH, 2002).
Desta forma, optou-se pela estruturação da Equipe de Qualidade
de Software de acordo com os conceitos e práticas do framework Scrum,
metodologia ágil para a gestão e planejamento de sistemas de software.
Esta escolha passa pela estratégia de incorporar os outros setores da
organização, uma vez que a Equipe de Qualidade de Software está
intimamente ligada com estas áreas e, desta forma, dar maior
abrangência a sistemática de melhorias até englobar toda a organização
e reduzir o Lead Time do fluxo geral do processo de desenvolvimento de
sistemas.
94
O Scrum prevê, inicialmente, definições de papeis e cerimônias a
serem realizadas pela equipe. Primeiramente, foram decididos os papeis
de Product Owner e Scrum Master, responsáveis pelo gerenciamento da
equipe visando os sistemas finais e facilitador na execução das
atividades, respectivamente. Após isto, foram definidas quais
cerimônias do Scrum serão realizadas, de acordo com a situação atual da
equipe. Desta forma, serão realizadas as cerimônias de Sprint Planning,
Daily Meeting e Sprint Review Meeting.
1. Sprint: Intervalo de tempo, acordado em duas semanas, em
que a Equipe de Qualidade de Software estará trabalhando
nas atividades das demandas trazidas pelo Product Owner;
2. Sprint Planning: Reunião onde serão planejadas as
atividades que serão realizadas pela Equipe de Qualidade de
Software de acordo com as informações e demandas trazidas
pelo Product Owner. Isto fará com que problemas atuais
como definições de prazos, falta de interações com as
demais áreas e atrasos nas execuções das tarefas por
demandas atravessadas sejam eliminadas ou reduzidas;
3. Daily Meeting: Reunião diária onde a equipe expõe o que
fez no dia anterior, o que vai fazer no presente dia,
dificuldades e/ou impedimentos que existiram e o repasse de
informações através do Product Owner para a equipe. Isto
auxiliará também nos atrasos de entrega de resultados, uma
vez que a equipe estará sempre informada sobre o que
acontece nos demais setores e resolvendo sempre aquilo que
está impedindo a continuidade das atividades;
4. Sprint Retrospective: Reunião para a identificação daquilo
que funcionou como o esperado, o que pode ser melhorado,
e quais ações serão tomadas para esta melhoria. Isto é
crucial para a proposição de melhoria contínua, indo ao
encontro do que é proposto no lean office.
5. Product Owner: Para a escolha deste papel, foi realizada
uma reunião com a equipe e todos os membros votaram
entre um dos colaboradores da empresa. Procedeu-se desta
forma para que o Product Owner fosse aproveitado como
um „ponto de apoio‟ do atual gestor, sendo que isto
facilitaria na gestão da Equipe de Qualidade de Software e
na execução das outras atividades do gestor. Desta forma, a
equipe optou pela escolha do colaborador mais presente no
95
dia-a-dia da equipe, com considerável hierarquia e
participante de todas as áreas da organização;
6. Scrum Master: Para este papel de acordo com as atribuições
que necessita e que o supervisor possui, a decisão sobre o
supervisor atual da equipe ser fazer o papel de Scrum Master
foi unânime. Desta forma, o mesmo poderá exercer suas
atividades e, literalmente, supervisionar e garantir que a
equipe cumpra com o planejado, eliminando impedimentos e
fazendo com que as cerimônias ocorram.
5.6.3 Eliminação das Atividades Não Agregadoras de Valor
Com a análise do estado atual dos processos da Equipe de
Qualidade de Software, as atividades realizadas pela equipe podem ser
separadas em atividades que agregam valor, atividades que não agregam
valor e atividades que não agregam valor ao cliente, porém são
necessárias para as atividades que agregam valor aconteçam, como
citado no item 5.6.1.
Desta forma, as atividades que não agregam valor devem ser
eliminadas, de maneira que o Lead Time de cada processo da equipe e,
consequentemente, do fluxo geral de desenvolvimento de sistemas seja
diminuído. Algumas atividades que não agregaram valor, mas que são
necessárias para que atividades que agregam valor aconteçam terão os
tempos diminuídos em virtude das melhorias obtidas. A Tabela 6 mostra
o resultado da seleção de atividades que serão eliminadas ou reduzidas
de acordo com o valor nos sistemas finais da equipe.
Tabela 6 - Eliminação e Redução de Tempo das Atividades
SITUAÇÃO ATUAL DE AGREGAÇÃO DE VALOR DAS ATIVIDADES DA
EQUIPE DE QUALIDADE DE SOFTWARE
Atividades dos Processos VA
(horas)
Tempo Total
(horas)
Taxa de Valor
Agregado
Receber a versão do sistema para
testes 0 1,5 0,0%
Preparar ambiente de testes 0 0,5 0,0%
Solicitar documentação sobre o
sistema 0 16 0,0%
Analisar documentação 2 8 25,0%
Informar envolvidos do projeto o
início dos testes 0 0,033 0,0%
Informar gestor sobre a distribuição
das tarefas 0 0,333 0,0%
Realizar os testes 8 18 44,4%
96
Consultar analista de sistemas 1 8 12,5%
Registrar na ferramenta de cadastro 0,033 0,5 6,6%
Informar envolvidos do projeto o
fim dos testes 0 0,033 0,0%
Validar correções 2 12 16,7%
Solicitar documentação da (s) nova
(s) funcionalidade (s) 0 8 0,0%
Realizar testes exploratórios no
sistema 4 18 22,2%
Analisar a demanda 0 0,333 0,0%
Escrever manual com todas as
funcionalidades do sistema 1 18 16,7%
Conversar com solicitante e/ou
analista de sistemas 0 1 0,0%
Informar solicitante do fim da
escrita do manual 0 0,033 0,0%
Elaborar os exercícios do
treinamento para a apostila 1 18 0,0%
Validar com solicitante 0 1 0,0%
Escrever apostila de treinamento 1 18 0,0%
Informar solicitante do fim da
escrita da apostila 0 0,5 0,0%
Outras VA
(horas)
Tempo Total
(horas)
Taxa de Valor
Agregado (%)
Reuniões com solicitante do material 0 8 0,0%
Reuniões em equipe 0 14 0,0%
Reuniões com analista de sistemas 0 15 0,0%
TOTAL 20,033 184,765 10,8%
Fonte: Elaborado pelo autor.
De acordo com a análise das atividades que não agregam valor
aos sistemas da Equipe de Qualidade de Software, do fluxo
informacional e a aplicação do Scrum no gerenciamento ágil da equipe,
as atividades destacadas em vermelho não fazem mais sentido e podem
ser eliminadas.
Com relação à atividade “Escrever apostila de Treinamento” e
“Escrever manual com todas as funcionalidades do sistema”, eram
necessárias informações sobre início e fim da escrita para o solicitante,
além de paradas para explicar ao solicitante sobre as funcionalidades e
repassar informações sobre a estabilidade do sistema. Com o Scrum, decidiu-se incorporar o solicitante em umas das reuniões diárias da
equipe para passar todas as informações necessárias ao solicitante,
reduzindo desperdícios de tempo com reuniões não planejadas.
96
97
Já as atividades destacadas em amarelo não podem ser excluídas
em virtude da necessidade das mesmas para que as atividades
agregadoras de valor aos sistemas da Equipe de Qualidade de Software
ocorram. Porém, com a adoção das melhorias, o tempo destas atividades
podem ser reduzidos. A redução dos tempos de ciclo das atividades é
estimada com relação aos tempos das cerimônias do Scrum, propostos
pela metodologia.
Com a eliminação das atividades destacadas em vermelho e a
redução do tempo das atividades destacadas em amarelo, o Processo
Inicial de Teste de Software apresenta os seguintes resultados:
Tabela 7 - Lead time do Processo Inicial de Teste de Software com Redução
Processo Inicial de Teste de Software (1)
Tarefa Tempo Total
Anterior
(horas)
Tempo Total
Posterior
(horas)
Receber a versão do sistema para
testes 1,5 1,5
Preparar ambiente de testes 0,5 0,5
Analisar documentação 8 8
Realizar os testes 18 18
Consultar analista de sistemas 0,5 0,5
Registrar na ferramenta de cadastro 8 0,5
Reuniões em equipe 5 1
Reuniões com analista de sistemas 10 0,5
Lead time 67,89 30,5
Lead time (em horas) 68 30,5
Lead time (em dias de trabalho) 3,8 1,7
Lead time (em dias para 3
testadores) 1,3 0,6
Fonte: Elaborado pelo autor.
O Lead Time do processo inicial de testes sofreu um decréscimo
significativo de 53,8% em relação ao Lead Time anterior, com as
atividades que não agregam valor na composição do fluxo. Além disso,
as atividades “Consultar analista de sistemas” e “Reuniões em equipe”
sofreram uma redução em seus tempos de ciclo, uma vez que com a
adoção do Scrum, as reuniões são planejadas, curtas, e melhor informativas, sem a necessidade de parar o tempo todo para decidir
como proceder diante de demandas “surpresas”, impedimentos, entre
outras situações.
Para o Processo de Validação de Correções nos Sistemas
Desenvolvidos os resultados são os seguintes:
98
Tabela 8 - Lead time do Processo de Validação de Correções com Redução
Processo Inicial de Teste de Software (1)
Tarefa Tempo Total
Anterior
(horas)
Tempo Total
Posterior
(horas)
Validar correções 12 12
Realizar testes exploratórios no sistema 18 18
Analisar documentação 8 8
Realizar os testes 18 18
Consultar analista de sistemas 8 0,5
Registrar na ferramenta de cadastro 0,5 0,5
Reuniões com analista de sistemas 5 0,5
Reuniões em equipe 5 1
Lead time 82,89 58,5
Lead time (em horas) 83 58,5
Lead time (em dias de trabalho) 4,6 3,25
Lead time (em dias para 3 testadores) 1,5 1,1
Fonte: Elaborado pelo autor.
O Lead Time do processo de validação de correções sofreu um
decréscimo de 26,6%. Considerando que esta é a atividade em que a
equipe passa a maior parte do tempo em virtude do número de versões
para validações ser superior ao número de projetos em desenvolvimento,
ou seja, ao número de softwares para se testar do início (Processo 1) o
resultado é bastante significativo. Novamente, esta redução foi possível
em virtude da adoção do framework Scrum e da mentalidade enxuta
aplicada ao processo, eliminando atividades que não agregam valor ao
sistema final da equipe.
Para o Processo de Auxílio à Elaboração do Manual de
Usabilidade do sistema, os resultados são os seguintes:
99
Tabela 9 - Lead time do Processo de Auxílio à Elaboração de Materiais (Manual
de Usabilidade) com Redução
Processo de Auxílio à Elaboração de Materiais - Manual de Usabilidade (3)
Tarefa
Tempo Total
Anterior
(horas)
Tempo Total
Posterior
(horas)
Analisar a demanda 0,333 0,333
Escrever manual com todas as
funcionalidades do sistema 18 18
Conversar com solicitante e/ou analista de
sistema 1 1
Reuniões com solicitante do material 8 0,25
Reuniões em equipe 4 0,5
Lead time 31,66 20,083
Lead time (em horas) 32 20
Lead time (em dias de trabalho) 1,8 1,1
Lead time (em dias para 3 testadores) 0,6 0,4
Fonte: Elaborado pelo autor.
O Lead Time do processo de elaboração do manual de usabilidade
do sistema sofreu um decréscimo de 33,3% em relação ao Lead Time
anterior. Como compete a equipe o auxílio na elaboração dos materiais,
o decréscimo é significativo, uma vez que com a eliminação das
atividades que não agregam valor e redução no tempo das que não
agregam, mas são necessárias, foi possível reduzir o Lead Time de um
processo que pouco agregava valor à equipe na forma que era realizado.
Desta maneira, a equipe consegue efetivamente realizar auxílio nos
materiais sem que prejudique o processo de produção dos relatórios de
teste, sistema principal dos processos da Equipe de Qualidade de
Software.
Para o Processo de Auxílio à Elaboração da Apostila de
Treinamento para o Cliente, os resultados são os seguintes:
100
Tabela 10 - Lead time do Processo de Auxílio à Elaboração de Materiais
(Apostila) com Redução
Processo de Auxílio à Elaboração de Materiais - Apostila de Treinamento
(3)
Tarefa Tempo Total
(horas)
Tempo Total
(horas)
Analisar a demanda 0,333 0,333
Elaborar os exercícios do treinamento para a
apostila 18 18
Validar com solicitante 1 1
Escrever apostila de treinamento 18 18
Reuniões com solicitante do material 8 0,25
Reuniões em equipe 4 0,5
Lead time 49,66 38,083
Lead time (em horas) 50 38
Lead time (em dias de trabalho) 2,8 2,1
Lead time (em dias para 3 testadores) 0,9 0,7
Fonte: Elaborado pelo autor.
O Lead Time do processo de auxílio à elaboração de apostilas de
treinamento para o cliente teve um decréscimo de 22,2% após a
eliminação de atividades não agregadoras de valor e estruturação da
equipe com o framework Scrum.
Como análise dos resultados relacionados à eliminação das
atividades não agregadoras de valor, pode-se concluir que com a
mentalidade enxuta a Equipe de Qualidade obteve um ganho de 1 (um)
dia e meio por jornada semanal.
Em reunião com gestor, supervisor (atual Scrum Master da
equipe) e o atual Product Owner, o ganho é significativo para a equipe,
uma vez que a organização sempre esperou usar os testadores da Equipe
de Qualidade como um cliente interno para a empresa, algo que não
vinha acontecendo em virtude dos desperdícios e consequente falta de
tempo. Além disso, a equipe poderá usar o tempo para capacitações de
seus membros e melhoria contínua de seus processos.
5.6.4 Tecnologia da Informação
A Equipe de Desenvolvimento e a Equipe de Análise da
organização utilizam o software GitLab como forma de interação entre
os setores da organização e para o desenvolvimento dos sistemas. O
GitLab é um software que permite o controle de versões dos sistemas
desenvolvidos. Com a ferramenta, a equipe de desenvolvimento
101
101
consegue armazenar o código em seus próprios servidores e a Equipe de
Análise consegue ter um status de como está a implementação das
funcionalidades no sistema.
Desta forma, foi proposta a utilização da ferramenta também pela
Equipe de Qualidade de Software como forma de interação com as
equipes, o que é essencial no desenvolvimento dos sistemas. Além de
proporcionar a comunicação informacional de forma eficiente utilizando
tecnologias eficazes, o que é uma premissa da Gestão da Informação
(VALENTIM, 2008) e, consequentemente, do Lean Office (GREEF;
FREITAS; ROMANEL 2012), aumenta a interação entre os três setores.
Sendo assim, primeiramente foi realizado um estudo sobre a
ferramenta para a verificação de como poderia ser útil na comunicação
entre os setores. No processo ágil de desenvolvimento de software
utilizado pelas equipes de análise e desenvolvimento, existe a prática de
expressar requisitos de softwares na forma de histórias de usuário. Essas
histórias, que são criadas pela equipe de análise, são a base das
informações para o desenvolvimento das funcionalidades, sendo estas
no formato de documentações chamadas de artefatos de engenharia de
sistemas.
Cada sistema desenvolvido é tratado como um projeto pela
organização, como mencionado durante o desenvolvimento do presente
trabalho. Na ferramenta, cada sistema em processo de desenvolvimento
é cadastrado como um projeto, sendo que a interação existente entre a
Equipe de Desenvolvimento e a Equipe de Análise é através destes
projetos no GitLab. A Figura 13 mostra a interface do software.
102
Figura 14 - Interface do Gitlab
Fonte: Elaborado pelo autor.
Desta maneira, foi cadastrado um projeto para a Equipe de
Qualidade chamado “Quality Assurance”. Este projeto servirá de
interação e comunicação entre a as três equipes (Qualidade,
Desenvolvimento e Análise), uma vez que a cada versão lançada para
testes, o projeto da Equipe de Qualidade será atualizado no software GitLab.
Como a Equipe de Qualidade possui um projeto criado dentro do
GitLab, poderá cadastrar os relatórios de teste diretamente nos projetos
de cada sistema, o que permite a atualização e análise imediata dos
problemas e sugestões de melhorias que vão sendo encontrados pela
equipe. Além disso, dúvidas e necessidades de informações sobre as
funcionalidades não compreendidas pelos testadores na documentação,
podem ser esclarecidas através de um espaço para comentários nos
cadastros de projetos.
A ferramenta possui ainda um conjunto de marcadores, chamados
de “Labels” para priorização de atividades e status das atividades. Sendo
assim, através desta ferramenta, o Product Owner poderá cadastrar as
demandas de atividades acordadas com a equipe na cerimônia Sprint Planning ou realizar a triagem e o repasse de demandas de teste e
elaboração de material dos outros setores da organização.
103
5.6.5 Plano de Ações
De acordo com a identificação e classificação dos desperdícios
encontrados nos processos da Equipe de Qualidade de Software com
base nos fundamentos e metodologia do Lean Office e do
Gerenciamento Ágil de Projetos, o Quadro 9 mostra o plano de ações
relacionadas a cada desperdício encontrado. As ações propostas no
plano de ações têm o objetivo de eliminar os desperdícios encontrados
durante a análise do mapeamento de processos, do fluxo de informações
e do mapeamento do fluxo geral de desenvolvimento de softwares.
Desta forma, o fluxo de informações entre os membros da Equipe
de Qualidade e da equipe com os outros setores da organização
apresentam melhoria, além da redução do Lead Time dos processos da
Equipe de Qualidade (consequentemente do fluxo geral de
desenvolvimento de softwares) e aumentando a taxa de agregação de
valor das atividades desempenhadas pela equipe.
A efetividade das propostas de estado futuro para o Fluxo Geral
de Desenvolvimento de Softwares e para os processos da Equipe de
Qualidade dependem da conclusão da implantação das ações propostas
no plano de ações.
104
Quadro 10 - Plano de Ações de Melhorias
Plano de Ações de Melhorias
No. Data
Inicial Problema Ação Responsável
Data
Prevista Status
1 29/10
Não há definições
concretas de
prazos de entrega
dos produtos da
equipe
Estruturar a Equipe de Qualidade de Software com base nos
fundamentos, conceitos e metodologias do Gerenciamento
Ágil de Projetos, utilizando o framework SCRUM. Desta
forma, chegará ao Product Owner ou o mesmo irá
providenciar as informações relacionadas aos prazos para a
entrega dos produtos da Equipe de Qualidade e repassar ao
Scrum Master
Product Owner,
autor 30/11
Solução
Proposta
2 29/10
Equipe não tem
acesso às
documentações
relacionadas ao
sistema
Além da estruturar a Equipe de Qualidade de Software com
base nos fundamentos, conceitos e metodologias do
framework SCRUM, no qual o Product Owner proverá
informações e documentação necessárias para o andamento
das atividades da equipe, serão idenficadas as atividades que
não agregam valor aos produtos finais dos processos da equipe
e estes serão eliminados ou reduzidos. Desta forma, atividades
de solicitação de documentações e/ou informações serão
descartadas.
Product Owner,
autor 30/11
Solução
Proposta
3 29/10 Excesso de
reuniões não
planejadas
Com a estruturação da Equipe de Qualidade de Software de
acordo com os princípios do SCRUM, os eventos que
caracterizam este framework como Sprint Planning, Reviews,
Daily Meeting, ocorreram continuamente. Desta forma, todas
as informações, dificuldades, impedimentos, entre outras
situações serão levantadas nestes eventos previamente
planejados, o que elimina desperdícios de tempo com reuniões
não planejadas, uma vez que não serão mais necessárias.
Product Owner,
Scrum Master e
membros
30/11 Solução
Proposta
105
4 29/10
Tarefas não
planejadas
demandadas para
a equipe
Todas as demandas, distribuições de tarefas, informações,
dificuldades, impedimentos, entre outras situações serão
levantadas nos eventos SCRUM previamente planejados, de
acordo com a estruturação da Equipe de Qualidade de
Software com os princípios do SCRUM. Logo, na etapa de
eliminação das atividades que não agregam valor com o lean
office, esta situação será descartada.
Product Owner,
Scrum Master 30/11
Solução
Proposta
5 29/10
Atraso das
atividades
demandadas para
a equipe
Com o descarte das atividades que não agregam valor aos
produtos da Equipe de Qualidade de Software e estruturação
da equipe de acordo com o framework SCRUM, as atividades
não serão demandadas sem um aviso prévio, uma vez que nas
cerimônias do SCRUM todas estas informações seriam
passadas pelo Product Owner.
Product Owner,
Scrum Master 30/11
Solução
Proposta
6 29/10
Necessidade de
informação sobre
o início e fim dos
testes a cada nova
demanda
A partir das filosofias e metodologias do escritório enxuto
(lean office), o fluxo de informações, com a eliminação de
atividades que não agregam valor e aplicação do SCRUM,
fluirá de maneira contínua. Além disso, como prevê o
conhecimento explícito da Gestão da Informação onde a
tecnologia utilizada deve ser revista e mudada, caso seja
necessário, visando o tratamento, análise, organização e
armazenamento das informações (VALENTIM, 2004), será
proposta comunicação e interação entre as áreas da empresa
através de uma nova tecnologia de informação.
Product Owner,
autor 30/11
Solução
Proposta
106
7 29/10
Supervisor com a
tarefa de
distribuição de
tarefas
Com a estruturação da Equipe de Qualidade de Software de
acordo com os princípios do SCRUM, a equipe terá um
Product Owner, responsável por tirar do supervisor atividades
de gerenciamento. Todavia, o conhecimento e contato diário
com os membros da equipe será aproveitado, sendo ele
nomeado Scrum Master da Equipe de Qualidade. Desta forma,
as atividades de supervisão e atividades de preparo de
ambientes de teste serão as atividades que ele executará, sendo
a distribuição de tarefas realizada na cerimônia do SCRUM
Sprint Planning.
Product Owner,
Scrum Master 30/11
Solução
Proposta
8 29/10
Número excessivo
de versões dos
sistemas lançadas
para teste
De acordo com metodologias propostas no Gerenciamento
Ágil de Projetos no desenvolvimento de softwares, a interação
entre desenvolvimento e qualidade deve ser continuamente
estimulada. Desta forma, testador e implementador devem
trabalhar mais em conjunto, o que não acontece atualmente.
As versões dos sistemas são lançadas para teste sem que
hajam testes básicos nas funcionalidades. Sendo assim,
quando chegam para teste os testadores acabam pegando
problemas em layout, travamentos, funcionalidades não
abrindo, algo que se tivesse sido testado de forma geral antes
da liberação da versão do sistema, pouparia todo o trabalho de
relatar os problemas encontrados, criar versões, aguardar nova
versão, aguardar novas correções, entre outros. São situação
que demandam muito tempo. Desta forma, será proposto que o
testador sente ao lado do desenvolvedor antes do mesmo
lançar a versão do sistema para realizar estes testes básicos.
Isso reduzirá o número de versões lançadas, economizando
tempo em relação as situações citadas anteriormente.
Product Owner,
Desenvolvimento
e Qualidade
30/11 Solução
Proposta
107
9 29/10
Informações
necessárias para
andamento das
atividades não
disponibilizadas
para a equipe
A partir das filosofias e metodologias do escritório enxuto
(lean office), o fluxo de informações, com a eliminação de
atividades que não agregam valor e aplicação do SCRUM,
fluirá de maneira contínua. Além disso, como prevê o
conhecimento explícito da Gestão da Informação onde a
tecnologia utilizada deve ser revista e mudada, caso seja
necessário, visando o tratamento, análise, organização e
armazenamento das informações (VALENTIM, 2004), será
proposta comunicação e interação entre as áreas da empresa
através de uma nova tecnologia de informação.
Product Owner,
autor 30/11
Solução
Proposta
10 29/10
Carência de um
responsável para
a gerência das
atividades da
equipe
Com a estruturação da Equipe de Qualidade de Software de
acordo com os princípios do SCRUM, a equipe terá um
Product Owner, responsável por servir de ponto de apoio ao
atual gestor. Este gestor poderá executar mais livremente
atividades de interação com o cliente e gerenciamento mais
superficial das áreas da organização. Desta a distribuição de
tarefas será realizada na cerimônia do SCRUM Sprint
Planning.
Product Owner 30/11 Solução
Proposta
11 29/10
Não há devida
interação com
demais setores,
especialmente
análise e
desenvolvimento
Com a estruturação da Equipe de Qualidade de Software de
acordo com os princípios do SCRUM, o Product Owner será a
ponte entre a equipe com os demais setores da organização,
sendo este responsável por reunir as áreas sempre que
necessário. Isto garantirá maior interação e dinamismo para a
empresa.
Product Owner 30/11 Solução
Proposta
Fonte: Elaborado pelo autor.
108
5.6.6 Mapeamento do Fluxo Geral de Desenvolvimento de Softwares
(Estado Futuro)
Com a implantação das ações propostas no plano de ações, um
novo mapeamento para o fluxo geral de desenvolvimento de Softwares
foi proposto, mostrado através do Apêndice H. A interação do cliente
com o sistema sendo desenvolvido tende a melhorar significativamente,
uma vez que o analista validará a modelagem de implementação dos
requisitos através de funcionalidades no sistema desenvolvido e através
de status sobre a implementação das funcionalidades pelo
desenvolvimento. Este é um problema notório na empresa.
Segundo o gestor, quando o sistema é apresentado ao final de
toda implementação, muitas correções são solicitadas por ele e as
informações eram constantemente alteradas entre os setores da
organização. Além disso, o mapeamento futuro resolveria o problema da
integração entre os setores de Análise, Desenvolvimento e Qualidade de
Software, já que os planos de trabalho e artefatos de engenharia seriam
disponibilizados no ato da chegada do projeto na organização e
concepção, respectivamente.
Esta disponibilização do plano de trabalho e do artefato de
engenharia fariam com que as Equipes de Qualidade e Desenvolvimento
interagissem mais entre si, uma vez que esta disponibilização reduziria o
tempo de compreensão das funcionalidades do sistema e reuniões
rotineiras com o analista de sistemas por parte da Equipe de Qualidade e
do que será implementado, por parte da Equipe de Desenvolvimento.
Além disso, as Equipes de Qualidade e de Desenvolvimento poderiam
interagir mais, uma vez que a Equipe de Qualidade poderá realizar testes
básicos nos sistemas antes do lançamento de versões. Isto se deve a
economias de tempo e possibilidade de planejamento que, atualmente, a
equipe não possui.
Por fim, a Equipe de Treinamento estaria mais integrada com a
Equipe de Qualidade de Sofware, e desta forma reuniões não planejadas
para explicação de funcionalidades do sistema, estabilidade e
compreensão do que deverá ser executado nas atividades de elaboração
de materiais serão eliminadas pelas cerimônias propostas pelo
framework Scrum, do gerenciamento ágil de projetos.
5.6.7 Mapeamento dos Processos da Equipe (Estado Futuro)
Com as atividades não agregadoras de valor eliminadas ou
reduzidas e a reestruturação da Equipe de Qualidade através do Scrum, é
proposta uma nova configuração para os processos da equipe, mostrada
109
no Apêndice I. A adoção das cerimônias e papeis do framework seriam
de grande auxílio para a Equipe de Qualidade de Software, uma vez que
as informações necessárias para o andamento das atividades estariam em
constante atualização para a equipe e este fluxo informacional estaria
contínuo e de simples acesso através do Product Owner.
Desta forma, a equipe conseguirá efetuar planejamento de suas
atividades, com periodicidade e metas a cumprir bem definidas por
prazos, uma vez que o Product Owner estará em constante contato com
os demais setores da empresa. Além do planejamento, a equipe poderá
se capacitar e estudar contínuas melhorias para seus processos de
trabalho, como por exemplo, segundo o supervisor, estudar sobre a
implantação de ferramentas para a automatização de testes. Com a
eliminação de atividades não agregadoras de valor, o processo ise
tornará mais enxuto e ágil – propostas das melhorias abordadas.
Além disto, com a constante atualização das interações da
empresa com o cliente, definições de prazos, acesso ao plano de trabalho
e artefatos de engenharia, a Equipe de Qualidade poderá ser aquilo que o
gestor sempre quis para a equipe – clientes internos da organização.
Desta forma, poderão propor melhorias mais contundentes e coesas,
agindo, pensando e utilizando o sistema como o cliente usará após a
entrega.
5.6.8 Mapeamento do Fluxo de Valor (Estado Futuro)
Para o Mapeamento do Fluxo de Valor para o estado futuro dos
processos da Equipe de Qualidade de Software, são considerados os
tempos de ciclos finais, com a implantação do plano de ações e
eliminação dos desperdícios de tempo causados por atividades que não
agregam valor, para encontrar o Lead Time final do setor de qualidade
da organização. Com o Lead Time final reduzido, o fluxo informacional
bem definido e os processos estruturados e enxutos, a Figura 15 mostra
o Mapeamento do Fluxo de Valor para o estado futuro da Equipe de
Qualidade de Software.
Este valor é de suma importância para a empresa, uma vez que
poderá ser usado como métrica para a continuidade da aplicação da
sistemática de melhorias, desta vez realizando iterações nas outras áreas
da empresa, até finalizar a organização como um todo. Vale lembrar que
diminuindo o Lead Time no setor de qualidade, consequentemente o
Lead Time geral do fluxo de desenvolvimento de softwares também
diminui.
110
Figura 15 - Mapeamento do Fluxo de Valor - Estado Futuro
Fonte: Elaborado pelo autor.
111
5.7 REPETIÇÃO DA SISTEMÁTICA – MELHORIA CONTÍNUA NA
ORGANIZAÇÃO COMO UM TODO
A redução do valor do Lead Time dos processos da Equipe de
Qualidade de Software é de suma importância e um grande indicativo
para a empresa, uma vez que poderá ser usada como modelo para a
continuidade do estudo de melhorias também nas demais áreas da
organização.
Desta forma, como o estudo no setor de qualidade apontou
problemas nos outros setores que influenciavam diretamente o trabalho
da equipe, outros desperdícios e atividades não agregadoras de valor
podem ser encontrados nas demais áreas da empresa.
Sendo assim, recomenda-se iterações da sistemática de melhorias
nos outros setores, até finalizar a organização como um todo. Vale
lembrar que diminuindo o Lead Time no setor de qualidade,
consequentemente o Lead Time geral do fluxo de desenvolvimento de
softwares também diminui. Porém, com novas iterações da sistemática
de melhorias nas demais áreas, espera-se uma redução ainda maior nos
desperdícios internos da empresa e, por consequência, diminuição do
Lead Time geral de desenvolvimento de sistemas, aumentando a
competitividade da empresa.
5.8 AJUSTES NA SISTEMÁTICA
Como mencionado anteriormente, a sistemática de melhorias foi
elaborada com base na revisão da literatura e na pesquisa de campo
preliminar realizada na organização em questão. Até chegar nas etapas
descritas no Capítulo 4, a sistemática de melhorias sofreu diversas
alterações não somente para melhor adaptação ao ambiente de
desenvolvimento de softwares, como também para a possibilidade de
aplicação em outras organizações produtivas.
Além disto, dificuldades como a cultura local, resistências à
grandes mudanças na forma de executar as atividades e capacitação
insuficiente do pessoal foram encontradas, o que gerou uma dificuldade
a mais na proposição da sistemática de melhorias. Em razão disto, após
a validação com o gestor geral da organização, ajustes nas etapas da
sistemática foram realizados de forma a se adaptar à realidade da
empresa. Sendo assim, todos os ajustes necessários estão inclusos na
sistemática apresentada no tópico 4.
112
113
6. CONSIDERAÇÕES FINAIS
A presente pesquisa foi concebida com o objetivo geral de propor
uma sistemática de melhorias de processos com base nos conceitos de
lean office e gerenciamento ágil de projetos a fim de reduzir o tempo de
desenvolvimento e retrabalhos de projetos em uma organização. O
objetivo foi atingido após a validação da sistemática proposta com a
empresa e, consequentemente, com a Equipe de Qualidade de Software.
Para atingir o objetivo traçado, foram buscados na literatura
conceitos, metodologias, filosofias e frameworks que auxiliassem na
fundamentação da sistemática de melhorias ao objeto de estudo. Com
base nas situações encontradas em campo, a literatura foi escolhida e
estudada a fim de estruturar uma metodologia capaz de resolver não
somente os problemas específicos do setor estudado, mas que fosse
aplicável a qualquer ambiente organizacional.
Durante a coleta de dados, a empresa se mostrou bastante
prestativa, apesar de cautelosa quanto à divulgação. Nas conversas com
o gestor da empresa foram evidenciados alguns dos principais
problemas com desperdícios, todos relacionados ao fluxo informacional
e ao gerenciamento de projetos da organização. A primeira etapa da
sistemática consistia em escolher um setor da empresa com maior
relevância e inter-relação com as demais áreas da organização. Desta
forma, para a realização da pesquisa, o Setor de Qualidade de Software
foi o escolhido como piloto.
Foram mapeados todos os processos da Equipe de Qualidade de
Software, assim como o fluxo informacional. Esta etapa evidenciou o
problema da organização com o fluxo informacional, levantado pelo
gestor da empresa. Os setores da Qualidade de Software, Análise e
Desenvolvimento não possuem interação entre si, ainda que, de acordo
com o fluxo geral de desenvolvimento dos produtos, as equipes sejam
totalmente dependentes. Além disto, apesar das ações intuitivas da
Equipe de Qualidade quanto às atividades, a mesma não possui um
processo de trabalho bem definido. Por consequência, as demandas de
atividades não são planejadas e informações sobre prazos raramente são
repassadas.
Desta forma, foram levantadas todas as atividades
desempenhadas que não agregam valor aos produtos finais dos
processos da equipe. Apesar das atividades relacionadas ao auxílio da
elaboração dos materiais para o cliente resultarem em baixas taxas de
valor agregado e não sofrer grande aumento após o mapeamento do
estado futuro, estas atividades de elaboração precisam continuar sendo
114
demandadas para a Equipe de Qualidade de Software, uma vez que a
Equipe de Treinamento não possui o conhecimento dos sistemas
desenvolvidos como a Equipe de Qualidade. Ainda assim, a autor
recomenda que estas atividades sejam reduzidas ainda mais, uma vez
que o valor gerado por estas atividades pertence aos processos da
Equipe de Treinamento.
Os resultados de Lead Time encontrados para cada processo da
Equipe de Qualidade de Software levam em consideração a execução
dos processos sem considerar os horários de cada testador. Uma
limitação existente na Equipe de Qualidade de Software e,
consequentemente na pesquisa, é que os testadores, por serem bolsistas,
possuem horários flexíveis e não contínuos, apesar de cumprirem 30
(trinta) horas semanais. Existe uma intercalação entre os horários dos
testadores. Isto dificulta na distribuição e execução de tarefas. Porém,
para o estudo realizado, foram considerados os tempos necessários para
que se inicie e se finalize um processo, considerando 6 (seis) horas
trabalhadas diárias. Ainda assim, o resultado é satisfatório e significante
para a empresa. Segundo o gestor, com a aplicação das melhorias a
equipe possuirá uma média de 1,5 (um dia e meio) dias por semana para
capacitações e planejamentos, mesmo com a adversidade dos horários
dos testadores.
Além disto, a equipe conseguirá planejar suas atividades de teste
com as informações chegando diariamente através das cerimônias de
Daily Meeting e as demandas chegarão com informações de prazo bem
definidos. Isto se deve à restruturação da Equipe de Qualidade com base
nos fundamentos e metodologias do gerenciamento ágil de projetos,
com o framework Scrum e da utilização da ferramenta de cadastros e
comunicação entre os setores. Com a estruturação de acordo com o
Scrum e as atividades não agregadoras de valor eliminadas, a equipe
definirá um processo de trabalho (Apêndice I) de maneira enxuta e ágil.
O Setor de Qualidade atualmente possui um sistema de controle
de tarefas manual, composto por um questionário onde os integrantes da
equipe respondem a perguntas como “O que você fez hoje?”, “Quanto
tempo levou para iniciar e concluir uma atividade?”. Isto fez com que a
pesquisa confiasse naquilo que o setor possuía de registro de tempo e
utilizou a amostra mais confiável deste cadastro. Com a adoção do
GitLab como ferramenta de comunicação e cadastro, esta forma de
registros se tornará ultrapassada, garantindo ganhos à equipe.
Outro ponto a se destacar é a atual cultura da empresa para
adquirir mudanças. Apesar dos principais líderes e gestor da
organização se mostrarem favoráveis a melhorias, os demais
115
colaboradores demonstraram um excesso de comodismo. Nas reuniões,
por exemplo, afirmações como “Sempre foi feito desta forma” e “Não
sei se vale a pena mexer nisto” eram recorrentes, ainda que os resultados
indiquem mudanças no processo de trabalho. Faz-se necessário a
mudança na cultura da empresa para que as melhorias propostas na
sistemática tragam os resultados esperados.
Por fim, recomenda-se, após a aplicação da sistemática e análise
dos resultados – confrontando com os resultados previstos pela
sistemática – que a empresa continue com a próxima etapa da
sistemática de melhorias e aplique nos demais setores da organização.
Segundo o supervisor da Equipe de Qualidade de Software, as melhorias
serão implementadas o mais rápido possível, de acordo com a data
estipulada no plano de ações, uma vez que o gestor da empresa validou
os resultados da sistemática. Além disto, recomenda-se ainda a
utilização de softwares como o ARENA ou o próprio BIZAGI
MODELER para simulações e análise de estado futuro mais precisos.
Espera-se que a presente pesquisa sirva de motivação para outros
estudos, sejam acadêmicos ou profissionais, com base na convergência
de metodologias. Para a continuidade do presente trabalho, recomenda-
se um estudo aprofundado à medida que a sistemática de melhorias vá
sendo implantada nos setores da empresa. A longo prazo, dados
quantitativos quanto às melhorias podem ser analisados, servindo de
parâmetros para mudanças visando à melhoria contínua. A presente
pesquisa alcançou seus objetivos até a validação da sistemática com a
empresa XY, porém seria interessante a continuação dos estudos com a
implantação e análise dos resultados.
116
117
REFERÊNCIAS
ARAÚJO, Wánderson Cássio; SILVA, Edna Lúcia; VARVAKIS,
Gregório. Fluxos de informação em projetos de inovação: estudo em
três organizações. Perspectivas em Ciência da Informação. v.22. n.1.
p.57-79. Jan./Mar. 2017.
ASEFESO, Ade. Lean Office: Key to Reducing Costs and Improving
Profitability. Swindon: AA Global Sourcing, 2012.
ASSOCIAÇÃO BRASILEIRA DE ENGENHARIA DE PRODUÇÃO.
Áreas e Sub-áreas de Engenharia de Produção. Disponível em:
https://www.abepro.org.br/interna.asp?p=399&m=424&ss=1&c=362.
Acesso em: 20 de setembro. 2017.
BALDISSERA, R. Estratégia, comunicação e Relações Públicas.
Anais do Congresso Brasileiro de Ciências da Comunicação, 24, 2001.
Campo Grande, MS.
BISSI, W. Scrum – Metodologia de Desenvolvimento Ágil.
http://revista.grupointegrado.br/revista/index.php/campodigital/article/vi
ew/312/146. Acesso em: 15 de março. 2017.
BORGES, Mônica Erichsen; FERREIRA, Marta Araújo; SILVA, Janete
Fernandes. Análise metodológica dos estudos de necessidades de
informações sobre setores industriais brasileiros: proposições. Ci.
Inf., Brasília, v. 31, n. 2, p. 129-141. Agosto, 2002.
BRYMAN, Alan. Research methods and organization studies.
London: Unwin Hyman, London, 1989.
CARVALHO, B.; MELLO, C. Aplicação do método ágil scrum no
desenvolvimento de produtos de software em uma pequena empresa
de base tecnológica. Gest. Prod., São Carlos, v. 19, n. 3, p. 557-573,
2012.
Chin, G. (2004). Agile project management: how to suceed in the
face of changing project requirements. New York: AMACOM.
CHOO, Chun Wei. Information management for the intelligent
organization: the art of scanning the environment. 2. ed. ASIS
Monograph Series, 1998.
COLLINS, James. C.; PORRAS, Jerry I. Building your company’s
vision. Boston: Harvard Business Review, 14p. 1996.
118
CRUZ, Breno Dantas. Um mapeamento sistemático de métricas para
metodologias ágeis Scrum, Kanban e XP. 2013. 80 f., il. Monografia
(Bacharelado em Engenharia de Software). Universidade de Brasília,
Brasília, 2013.
CUNHA, Izabella Bauer; PEREIRA, Frederico Cesar; NEVES, Jorge
Tadeu. Análise do fluxo informacional presente em uma empresa do segmento de serviços de valor agregado (SVA). Perspectivas em
Ciência da Informação. v.20. n.4. p.107-128. Out./Dez. 2015.
DAVENPORT, Thomas H. Ecologia da informação: porque só a
tecnologia não basta para o sucesso na era da informação. São
Paulo: Futura, 1998.
FREITAS, Ernani Cesar; PRODANOV, Cleber Cristiano. Metodologia
do Trabalho Científico: Métodos e Técnicas da Pesquisa e do
Trabalho Acadêmico. Universidade Feevale, Rio Grande do Sul, 2013.
GREEF, A. C.; FREITAS, M. C. D.; ROMANEL, F. B. Lean office:
operação, gerenciamento e tecnologias. São Paulo: Atlas, 2012.
HERKOMMER, J.; HERKOMMER, O. S. Lean office - System.
Zeitschrift fuer Wirtschaftlichen Fabrikbetrieb. v. 101, n. 6, p. 378-
381, 2006.
HIGHSMITH, J. A. Agile software development ecosystems. v. 13.
Addison-Wesley Professional, 2002.
HINES, P. et al. Value Stream management. Grã-Bretanha: Prentice
Hall, 2000.
HUNT, V. D. Process Mapping: How to Reengineer your Business
Process. John Wiley & Sons, New York, 1996.
LAGO, N.; CARVALHO, D.; RIBEIRO, L. M. M. Lean Office.
Revista Fundição. p.6-8. 1º e 2º tri. 2008.
LAKATOS, Eva Maria; MARCONI, Marina de Andrade.
Fundamentos de metodologia científica. 5. Ed. São Paulo: Atlas,
2003.
LANDMANN, R.; BITTENCOURT, E.; SCHWITZKY, M.;
WYREBSKI, J. Lean Office: aplicação da mentalidade enxuta em
processos administrativos de uma empresa do setor metal-mecânico.
In: ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO.
Salvador, 2009.
119
LODI, M.D.F. Uma reflexão sobre o uso da pesquisa-ação e a
hermenêutica à luz da teoria de prática. In: AdCont. V Congresso
Nacional de Administração e Ciências Contábeis. Rio de Janeiro. 2014.
MAR, K.; SCHWABER, K. Scrum With XP. Disponível em
http://www.informit.com/articles/article.aspx?p=26057. Acesso: 15 de
julho. 2017.
McMANUS, H. Product development value stream analysis and
mapping manual. Alpha Draft. Cambridge: Massachusetts Institute of
Technology, 2003.
CAUCHICK, M. P. A. Metodologia de pesquisa em engenharia de
produção e gestão de operações. 2. ed. Elsevier. Rio de Janeiro. 2012.
MOREIRA, Herivelto; CALEFFE, Luiz Gonzaga. Metodologia da
pesquisa para o professor pesquisador. 2.ed. Rio de Janeiro:
Lamparina, 2008.
MOURA, Luciano Raizer. Informação: a essência da qualidade.
Ciência da informação, Brasília, v. 25, n. 1, 1995.
MUNDIM, A. P. F.; ROZENFELD, H.; AMARAL, D.C.; SILVA, S.L.;
GUERRERO, V.; HORTA, L.C. Aplicando o cenário de
desenvolvimento de produtos em um caso prático de capacitação profissional. Gestão & Produção. v.9, n.1, p.1-16, abr. 2002.
OLIVEIRA, E. e LIMA, R. Estado da Arte Sobre o Uso do Scrum em
Ambientes de Desenvolvimento Distribuído de Software. Revista de
Sistemas e Computação, Salvador, v. 1, n. 2, p.106-119. 2011.
PAVANI JUNIOR, O.; SCUCUGLIA, R. Mapeamento e Gestão por
Processos – BPM: Gestão orientada à entrega por meio de objetos. São Paulo: M.Books, 2011.
PMBOK, GUIDE. Um Guia do Conhecimento em Gerenciamento de
Projetos. 4ª ed. Versão em Português. 2009.
ROTHER, M.; SHOOK, J. Aprendendo a Enxergar – Mapeando o
Fluxo de Valor para Agregar Valor e Eliminar Desperdício. Lean
Institute Brasil, v. 1, n. 4, 2012.
SCHWABER, K., BEEDLE M. Agile Software Development with
Scrum. Prentice Hall. 2002.
120
SCHWABER, Ken; SUTHERLAND, J. Guia do SCRUM. Trad. Heitor
Roriz Filho, Michel Goldenberg, Rafael Sabbagh. Disponível em:
http://www.scrum.org/scrumguides. Acesso: 12 de agosto. 2017.
SILVA Daisy Eliana; SOUZA Ingredy Thais; CAMARGO, Talita.
Metodologias ágeis para o desenvolvimento de software: aplicação e
o uso da metodologia scrum em contraste ao modelo tradicional de gerenciamento de projetos. v.2. n.1. Revista Computação Aplicada.
2013.
SOMMERVILLE, I. Engenharia de software. Addison Wesley. 2003.
STARE, A. Agile project management – a future approach to the
management of projects? Dynamic Relationships Management. v.
119, p. 295-304. 2014.
STREULE, Tomas; MISERINI, Nino; BARTLOMÉ, Olin; KLIPPEL,
Michael; GARCÍA DE SOTO, Borja. Implementation of Scrum in the
Construction Industry. Creative Construction Conference. Junho.
2016.
SUTHERLAND, J. Scrum: A revolutionary approach to building
teams, beating deadlines and boosting productivity. Random House
Business Books. Hardcover – Agosto. 2014.
TAKEUCHI, H. & NONAKA, I. The New New Product Development
Game. Harvard Business Review, 1986.
TAPPING, D.; SHUKER, T. Lean Office: Gerenciamento do fluxo de
valor para áreas administrativas - 8 passos para planejar, mapear e
sustentar melhorias Lean nas áreas administrativas. São Paulo:
Leopardo Ed., 2010.
TARAPANOFF, Kira. Referencial teórico: introdução. Inteligência
organizacional e competitiva. Brasília: Ed. da UnB, 2001. p. 33-49.
TARTUCE, T. J. A. Métodos de pesquisa. UNICE – Ensino Superior.
Fortaleza. 2006.
THIOLLENT, M. Metodologia da pesquisa-ação. São Paulo: Cortez.
2000.
TICE, J.; AHOUSE, L.; LARSON, T. Lean Production and EMS:
aligning environmental management with business priorities. Environmental Quality Management. vol. 5. 2005.
121
TURATI, R. C.; MUSETTI, M. A. Aplicação dos conceitos de Lean
Office no setor administrativo público. ENCONTRO NACIONAL
DE ENGENHARIA DE PRODUÇÃO. Fortaleza. 2006.
VALENTIM, Marta Lígia Pomim et al. Gestão da informação
utilizando o método infomapping. Perspectiva em Ciência da
Informação, Belo Horizonte, v. 13, n. 1, p. 184-198, Jan./abr. 2008.
122
123
APÊNDICE
124
125
APÊNDICE A - LEVANTAMENTO DE DADOS RELACIONADOS ÀS ATIVIDADES DOS PROCESSOS DA EQUIPE
Processo Inicial de Teste de Software (1)
Atividades do Processo
Receber a
versão do
produto para
testes
Preparar
ambiente de
testes
Solicitar
documentação
sobre o sistema
Analisar
documentação
Informar
envolvidos do
projeto o início
dos testes
Informar
gestor sobre a
distribuição
das tarefas
Realizar os testes
Consultar
analista de
sistema
Registrar na
ferramenta de
cadastro
Informar
envolvidos do
projeto o fim
dos testes
Descrição
do evento
A equipe de
qualidade recebe
a versão do
sistema, com
aviso via e-mail
sobre a
localização do
produto, pelo
desenvolvedor
do sistema.
O supervisor
realiza a
instalação do
sistema nos
computadores
de cada
colaborador
que realiza
testes.
A equipe solicita
a documentação
com as
especificações
das
funcionalidades
do sistema para a
realização dos
testes.
A equipe faz a
leitura da
documentação do
sistema para ter
conhecimento do
que trata o sistema,
funcionalidades
implementadas
para que os testes
possam ser
executados
conforme
requisitos do
cliente.
A equipe informa
o analista, o
desenvolvedor e
a quem mais
interessar sobre o
início dos testes
no sistema
através da
ferramenta de
comunicação
adotada pela
empresa XY.
O gestor da
equipe é
informado
sobre o início
dos testes pelo
supervisor,
informando
ainda todas as
atividades que
foram
demandadas
para a equipe e
devida
distribuição de
tarefas.
Os testadores
efetivamente
realizam os testes
no produto,
geralmente
utilizando uma
lista de checagem
ou casos de uso
relacionados as
funcionalidades
avaliando e
encontrando
problemas.
Caso o testador
não entenda uma
funcionalidade ou
queria conversar
pessoalmente
com o analista
sobre um teste ou
um resultado
específico, o
mesmo conversa
o analista.
Quando o
testador
encontra um
problema e/ou
sugestão de
melhoria no
produto, realiza
um cadastro na
ferramenta de
cadastro
adotada pela
empresa XY,
onde é gerado
um relatório de
testes no
sistema.
A equipe informa
o analista, o
desenvolvedor e
a quem mais
interessar sobre o
fim dos testes no
produto através
da ferramenta de
comunicação
adotada pela
empresa XY.
Valor
Agregado NAV NAV NAV VA NAV NAV VA VA VA NAV
Distância
percorrida
(m)
0 0 0 0 0 0 0 0 0 0
Tempo de
Ciclo
(T/C)
1,5 h 0,5 h 16 h 8 h 0,033 h 0,333 h 18 h 8 h 0,5 h 0,033 h
126
Processo de Validação de Correções nos Sistemas Desenvolvidos (2)
Atividades do Processo
Validar
correções
Solicitar
documentação
da(s) nova(s)
funcionalidade(s)
Analisar
documentação
Informar
envolvidos do
projeto o início
dos testes
Informar
gestor sobre a
distribuição
das tarefas
Testar nova(s)
funcionalidade(s)
no sistema
Consultar
analista de
sistemas
Registrar na
ferramenta
de cadastro
Informar
envolvidos do
projeto o fim
dos testes
Realizar testes
exploratórios no
sistema
Descrição
do evento
A equipe
verifica se os
apontamentos
de erros foram
implementados
no sistema.
A equipe solicita a
documentação com
as especificações
da(s)
funcionalidade(s)
nova(s) do sistema
para a realização
dos testes.
A equipe faz a
leitura da
documentação do
sistema para ter
conhecimento da(s)
nova(s)
funcionalidade(s)
implementadas
para que os testes
possam ser
executados
conforme
requisitos do
cliente.
A equipe
informa o
analista, o
desenvolvedor e
a quem mais
interessar sobre
o início dos
testes no
sistema através
da ferramenta
de comunicação
adotada pela
empresa XY.
O gestor da
equipe é
informado
sobre o início
dos testes pelo
supervisor,
informando
ainda todas as
atividades que
foram
demandadas
para a equipe
e devida
distribuição de
tarefas.
Os testadores
efetivamente
realizam os testes
na(s)
funcionalidade(s)
nova(s) no sistema,
geralmente
utilizando uma lista
de checagem ou
casos de uso
relacionados as
funcionalidades
avaliando e
encontrando
problemas.
Caso o testador
não entenda
uma
funcionalidade
ou queria
conversar
pessoalmente
com o analista
sobre um teste
ou um resultado
específico, o
mesmo conversa
o analista.
Quando o
testador
encontra um
problema e/ou
sugestão de
melhoria no
sistema,
realiza um
cadastro na
ferramenta de
cadastro
adotada pela
empresa XY,
onde é gerado
um relatório
de testes no
produto.
A equipe
informa o
analista, o
desenvolvedor e
a quem mais
interessar sobre
o fim dos testes
no sistema
através da
ferramenta de
comunicação
adotada pela
empresa XY.
Os testadores
realizam testes
exploratórios no
sistema visando
identificar se a
implementação
de
funcionalidades
novas não
interferiu nas
antigas ou na
usabilidade do
sistema e
proposições de
melhoria.
Valor
Agregado VA NAV VA NAV NAV VA VA VA NAV VA
Distância
percorrida
(m)
0 0 0 0 0 0 0 0 0 0
Tempo de
Ciclo
(T/C)
12 h 8 h 8 h 0,033 h 0,333 h 18 h 8 h 0,5 h 0,033 h 18 h
127
Processo de Auxílio na Elaboração de Materiais para o Cliente (3)
Atividades do Processo
Analisar a
demanda
Escrever manual com
todas as funcionalidades
do sistema
Conversar com
solicitante e/ou analista
de sistemas
Informar solicitante
do fim da escrita do
manual
Elaborar os exercícios do
treinamento para a
apostila
Validar com
solicitante
Escrever
apostila de
treinamento
Informar
solicitante do
fim da escrita da
apostila
Descrição
do evento
Nesta etapa a
equipe de
qualidade recebe a
demanda e avalia
se a escrita será de
manual de uso do
sistema ou da
apostila de
treinamento.
Com o auxílio da
documentação sobre a
funcionalidade cedida
pelo analista e pela
experiência dos testadores
sobre o sistema, a equipe
realiza a escrita do
manual de uso do sistema.
No momento da escrita
do manual de uso, a
equipe pode ter dúvidas
quanto ao nível de
especificação ou até
mesmo dúvidas sobre a
usabilidade. Sendo
assim, deve conversar
com o solicitante da
escrita ou analista de
sistemas.
A equipe informa o
solicitante da equipe de
treinamento o fim da
escrita do manual de
uso do sistema. Há
ainda a explicação da
escrita e da uso da
funcionalidade ao
solicitante.
Quando a demanda é a
elaboração da apostila de
treinamento do uso produto
ao cliente, a equipe elabora
exercícios, os casos de uso
para a apostila, onde
abrangem as
funcionalidades do sistema
que vão estar no
treinamento.
Os exercícios
serão mostrados
e explicados ao
solicitante que
fará a análise e
validará os
exercícios
elaborados.
Escrever apostila
de treinamento
com os exercícios
elaborados
anteriormente.
A equipe informa
o solicitante da
equipe de
treinamento o fim
da escrita do
apostila de
treinamento ao
cliente do
sistema.
Valor
Agregado NAV NAV NAV NAV NAV NAV NAV NAV
Distância
percorrida
(m)
0 0 0 0 0 0 0 0
Tempo de
Ciclo (T/C) 0,333 h 18 h 0,5 h 0,033 h 16 h 1 h 24 h 0,5 h
128
APÊNDICE B – MAPEAMENTO DO FLUXO GERAL DE DESENVOLVIMENTO DE SISTEMA
129
APÊNDICE C – MAPEAMENTO DO PROCESSO INICIAL DE TESTES NOS SISTEMAS
130
APÊNDICE D – MAPEAMENTO DO PROCESSO DE VALIDAÇÃO DE CORREÇÕES NOS SISTEMAS DESENVOLVIDOS
131
APÊNDICE E – MAPEAMENTO DO PROCESSO DE AUXÍLIO À ELABORAÇÃO DE MATERIAIS PARA O CLIENTE
132
APÊNDICE F – INFORMAÇÕES DE ENTRADA E SAÍDA PARA OS PROCESSOS DA EQUIPE DE QUALIDADE DE SOFTWARE
133
134
135
APÊNDICE G – FLUXOS INFORMACIONAIS POR PROCESSO
Processo Inicial de Testes nos Sistemas
136
Processo de Validação de Correções nos Sistemas Desenvolvidos
137
Processo de Auxílio à Elaboração de Materiais para o Cliente
138
139
APÊNDICE H – MAPEAMENTO DO FLUXO GERAL DE DESENVOLVIMENTO DE SISTEMAS – ESTADO FUTURO
140
APÊNDICE I – MAPEAMENTO DOS PROCESSOS DA EQUIPE DE QUALIDADE DE SOFTWARE – ESTADO FUTURO
