DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE
-
Upload
mario-ferreira -
Category
Software
-
view
169 -
download
1
description
Transcript of DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE
PONTIFÍCIA UNIVERSIDADE CATÓLICA DE MINAS GERAIS Pós-Graduação em Engenharia de Software
Mário Antônio de Almeida Ferreira
DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENT O DE SOFTWARE
Belo Horizonte 2012
Mário Antônio de Almeida Ferreira
DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENT O DE SOFTWARE
Monografia apresentada ao Curso de Pós-Graduação em Engenharia de Software da Pontifícia Universidade Católica de Minas Gerais, como requisito parcial para obtenção do título de Especialista em Engenharia de Software. Orientador: Carlos Alberto Marques Pietrobon
Belo Horizonte 2012
Mário Antônio de Almeida Ferreira
DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENT O DE
SOFTWARE
Monografia apresentada ao Curso de Pós-Graduação em Engenharia de Software da Pontifícia Universidade Católica de Minas Gerais, como requisito parcial para obtenção do título de Especialista em Engenharia de Software.
______________________________________________________
Carlos Alberto Marques Pietrobon (Orientador) – PUC Minas
______________________________________________________
Pasteur Ottoni de Miranda Júnior – PUC Minas
Belo Horizonte, 14 de dezembro de 2012.
RESUMO
Observa-se, atualmente, que as seções de desenvolvimento de sistemas das empresas têm
dado pouca importância a forma de estruturar o trabalho das pessoas. Normalmente, esse
processo é feito sem nenhum estudo científico e sem verificar como essa organização
escolhida poderia influenciar resultados como a produtividade e a satisfação do cliente final.
O objetivo desse trabalho é ajudar as empresas a encontrarem a melhor forma de estruturar e
dividir o trabalho de desenvolvimento de software. O estudo mostra como a produtividade
estaria relacionada a fatores como a especialização do trabalho, motivação e visão sistêmica; e
como esses fatores estariam relacionados com a forma de se organizar as pessoas no trabalho.
Mostra também como esses fatores estudados pelas teorias administrativas têm aparecido na
evolução dos conceitos da engenharia de software mostrando assim suas tendências para o
futuro. Consiste ainda como objeto de estudo verificar como um modelo de desenvolvimento
formado por desenvolvedores mais generalistas conseguiria obter grande parte desses
benefícios e resultar em um processo de trabalho mais eficaz e mais efetivo.
Palavras-chave: Engenharia de software. Generalista. Produtividade. Desenvolvimento de
sistemas. Especialização do trabalho. Motivação. Visão sistêmica.
ABSTRACT
We observe today that the systems development departments of companies have given little
thought to how to structure the work of the people. Typically, this process is done without any
scientific study and without checking how that could influence results as productivity and
customer satisfaction. The aim of this work is to help companies find the best way to structure
and divide the work of software development. The study shows how productivity is related to
factors such as work specialization, motivation and systemic view, and how these factors are
related to the way of organizing people at work. It also shows how these factors studied by
management theories have appeared in the evolution of the concepts of software engineering
thus showing trends for the future. It is still an object of study to see how a model of
development formed by more generalist developers could get most of these benefits and result
in a work process more effective and efficient.
Keywords: Software engineering. Generalist. Productivity. Systems development. Work
specialization. Motivation. Systemic view.
LISTA DE FIGURAS
Figura 1: Hierarquia das necessidades de Maslow...................................................................28 Figura 2: Três pilares para a Engenharia de Software..............................................................36 Figura 3: Estruturação da equipe. .............................................................................................39 Figura 4: Canais de Comunicação. ...........................................................................................43 Figura 5: Generalistas. Mesmos recursos nas atividades. ........................................................44 Figura 6: Iterativo. Ociosidade. ................................................................................................45 Figura 7: Adiantar nova iteração. Não “Time Box”.................................................................45 Figura 8: Vários projetos. Gerenciamento complexo...............................................................46
LISTA DE TABELAS
TABELA 1: Critérios observados ............................................................................................37
SUMÁRIO
1 INTRODUÇÃO..................................................................................................................9 1.1 Justificativa.................................................................................................................9 1.2 Problema.....................................................................................................................9 1.3 Objetivos...................................................................................................................10
1.3.1 Objetivo geral ...................................................................................................10 1.3.2 Objetivos específicos........................................................................................10
1.4 Metodologia..............................................................................................................11 1.5 Organização do trabalho...........................................................................................11
2 DIVISÃO E ESPECIALIZAÇÃO DO TRABALHO......................................................13
2.1 Especialização da tarefa............................................................................................13 2.2 Otimização do processo............................................................................................16 2.3 Estrutura organizacional ...........................................................................................19 2.4 Limites da especialização .........................................................................................20
3 VISÃO SISTÊMICA DO TRABALHO ..........................................................................22 4 FATOR HUMANO ..........................................................................................................25
4.1 Abordagem humanística ...........................................................................................25 4.2 Grupos e lideranças informais ..................................................................................26 4.3 Motivação .................................................................................................................27 4.4 Comprometimento....................................................................................................29
5 TEORIAS COMPLEMENTARES...................................................................................31 6 HISTÓRICO DA ENGENHARIA DE SOFTWARE......................................................32 7 ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE...37
7.1 Composição da equipe..............................................................................................38 7.2 Motivação e comprometimento ................................................................................40 7.3 Lideranças.................................................................................................................41 7.4 Visão sistêmica e benefícios para os clientes ...........................................................41 7.5 Comunicação ............................................................................................................42 7.6 Adequação a processos iterativos .............................................................................44 7.7 Padronização e melhoria contínua das atividades....................................................46
8 CONCLUSÃO..................................................................................................................49 REFERÊNCIAS BIBLIOGRÁFICAS .....................................................................................50
9
1 INTRODUÇÃO
1.1 Justificativa
Observa-se, atualmente, que as seções de desenvolvimento de sistemas das empresas
têm dado pouca importância a forma de estruturar o trabalho das pessoas. Normalmente, esse
processo é feito sem nenhum estudo científico e sem verificar como essa organização
escolhida poderia influenciar resultados como a produtividade e a satisfação do cliente final.
Muitas vezes, são investidos esforços na criação de processos de software e
certificações puramente para seguir práticas de mercado, sem, no entanto, ter objetivos claros
de como isso poderia realmente trazer maiores benefícios para seus clientes.
Sem uma visão holística dos benefícios gerados, as empresas podem acabar
organizando o trabalho sem nenhum critério científico de forma simplesmente a encontrar
uma maneira mais fácil de adequar o trabalho da equipe à implantação dos processos.
Acredita-se que uma investigação científica nessa área poderia encontrar formas
melhores ou pelo menos proporcionar uma base melhor de informações para poder ajudar as
pessoas a decidirem qual a melhor forma de dividir o trabalho de desenvolvimento de
software na suas empresas.
1.2 Problema
As seções de desenvolvimento de sistemas de algumas empresas precisam estruturar
sua área para desenvolver e manter os sistemas corporativos da empresa. Elas precisam saber
qual seria a melhor forma de estruturar o trabalho da equipe para conseguir os melhores
resultados possíveis. Elas precisam decidir se estruturam sua equipe com desenvolvedores
mais generalistas atuando em várias disciplinas ou se seria melhor formar equipes com
desenvolvedores mais especializados atuando em uma única disciplina do desenvolvimento de
software.
Elas precisam saber as vantagens e desvantagens de se utilizar cada abordagem,
identificando qual delas pode trazer maior produtividade e maiores benefícios para o cliente,
10
analisando-se itens como a melhoria do processo, motivação, comprometimento e visão
sistêmica.
1.3 Objetivos
1.3.1 Objetivo geral
O objetivo desse trabalho é ajudar as empresas a encontrarem a melhor forma de
estruturar e dividir o trabalho de desenvolvimento de software mostrando como esta
organização pode influenciar a produtividade e a satisfação do cliente final.
Um estudo científico mais apurado nesse assunto, através de experiências
principalmente da área de administração, poderia levar as áreas de desenvolvimento de
software a atingirem resultados melhores com maior satisfação da equipe e dos clientes.
1.3.2 Objetivos específicos
A partir da definição do objetivo geral do trabalho foi possível elaborar objetivos
específicos, que seguem abaixo:
a) mostrar como a produtividade estaria relacionada a fatores como a especialização
do trabalho, motivação e visão sistêmica; e como esses fatores estariam
relacionados com a forma de se organizar as pessoas no trabalho;
b) mostrar a importância da divisão e especialização do trabalho, bem como, os
cuidados que se deveria ter para que isso não trouxesse como conseqüência uma
especialização excessiva das pessoas;
c) mostrar como se poderia alcançar uma maior motivação e comprometimento das
pessoas e como esses fatores se relacionam com a especialização das pessoas na
execução da tarefa;
d) verificar como a visão sistêmica poderia tornar o trabalho mais assertivo e como as
equipes poderiam fazer para obter essa visão;
11
e) mostrar como esses fatores estudados pela administração têm aparecido na evolução
dos conceitos da engenharia de software verificando suas tendências para o futuro;
f) propor uma forma de dividir e organizar o trabalho de desenvolvimento de software
que consiga obter o máximo dos benefícios identificados pelos estudos realizados.
1.4 Metodologia
Para mostrar a relação da especialização do trabalho, da motivação e da visão
sistêmica com a produtividade das pessoas foi feita uma pesquisa bibliográfica, qualitativa,
através de conhecimentos disponibilizados principalmente pela área de administração onde se
pôde inferir que tal relação realmente existe.
Para mostrar a relação desses aspectos das teorias administrativas com a engenharia de
software foi feita também uma pesquisa bibliográfica sobre engenharia de software e utilizou-
se a técnica de comparação para identificar as similaridades existentes entre esses dois
universos.
Por último, utilizando o conhecimento adquirido nessas pesquisas e comparações, foi
possível propor uma forma de organização do trabalho e inferir como ela poderia atingir os
aspectos de produtividade analisados.
1.5 Organização do trabalho
No capítulo 2 foi apresentado como alguns autores das teorias científica e clássica da
administração acreditavam que a especialização das atividades e das tarefas poderia trazer um
aumento de produtividade na execução do trabalho.
No capítulo 3 foi visto como teorias baseadas na visão sistêmica são importantes para
eficácia do trabalho.
No capítulo 4 foram apresentados estudos de como os efeitos psicológicos e sociais
das pessoas poderiam afetar também a produtividade.
No capítulo 5 foi visto que em teorias administrativas ainda mais novas, como a teoria
da contingência, acredita-se ser possível que essas teorias científicas com ênfase colocada na
12
tarefa possam ser complementares às teorias humanísticas com ênfase nas pessoas e às teorias
sistêmicas com ênfase no sistema, e que, juntas elas possam produzir resultados ainda
melhores do que cada uma na sua visão individual.
No capítulo 6 foi feita uma descrição de como o trabalho no desenvolvimento de
software é realizado e dividido em disciplinas e atividades. Foi observado como aspectos das
teorias administrativas abordados nos capítulos anteriores aparecem e são tratados na
engenharia de software.
No capítulo 7, baseado nos resultados e conclusões das pesquisas realizadas, o
trabalho sugeriu e justificou uma forma de dividir e organizar o trabalho que atendesse ao
máximo possível os requisitos identificados para que se conseguissem melhores
produtividades e melhores benefícios para os usuários.
Por fim, no último capítulo é apresentada uma conclusão do trabalho.
13
2 DIVISÃO E ESPECIALIZAÇÃO DO TRABALHO
2.1 Especialização da tarefa
À medida que as sociedades foram se organizando, iniciou-se um processo de divisão
do trabalho por meio do qual as pessoas colocariam suas melhores habilidades a serviço da
sociedade, de forma que o produto de seu trabalho pudesse ser trocado com o produto do
trabalho de outras pessoas e juntos pudessem atender as necessidades individuais de cada um.
A divisão do trabalho faz parte da natureza. É observada, por exemplo, no reino animal, onde quanto mais perfeito é o ser, maior é a variedade de órgãos encarregados de funções diferentes; nota-se nas sociedades humanas, nas quais, quanto mais complexo é o corpo social, tanto maior e mais íntima é a relação entre a função e o órgão. À medida que a sociedade aumenta, aparecem novos órgãos destinados a substituir o órgão único, primitivamente encarregado de todas as funções (Fayol, 1989).
Ao final do século XVIII, Adam Smith (1976) começou a observar que a divisão e a
especialização das atividades poderiam tornar o trabalho das pessoas mais eficiente.
Observando uma manufatura pequena de fabricação de alfinetes, Smith notou que um
operário não treinado para essa atividade, empenhando o máximo de trabalho, dificilmente
poderia fabricar mais que vinte alfinetes por dia. Ele observou que apesar da fabricação de
alfinete já ser considerada uma atividade específica na sociedade, seu trabalho ainda poderia
ser dividido em diversas tarefas menores cada qual considerada como um ofício
especializado: desenrolar o arame, endireitar o arame, cortar, fazer as pontas, afiar as pontas
para a colocação da cabeça do alfinete, fazer a cabeça do alfinete, etc. Ao todo, seriam
aproximadamente 18 operações necessárias para a produção de um alfinete. Ele observou uma
manufatura com 10 empregados, com cada um executando no máximo 2 ou 3 dessas
operações e verificou que eles conseguiam juntos produzir cerca de 48 mil alfinetes por dia, o
que daria 4 800 alfinetes por dia por pessoa.
Adam Smith (1976) considera que essa enorme diferença de produtividade, em
conseqüência da divisão do trabalho, é devido a três circunstâncias distintas:
g) “maior destreza existente em cada trabalhador”, devido a repetição da tarefa;
14
h) “à poupança daquele tempo que, geralmente, seria costume perder ao passar de um
tipo de trabalho para outro”;
i) “à invenção de um grande número de máquinas que facilitam e abreviam o trabalho,
possibilitando a uma única pessoa fazer o trabalho que, de outra forma, teria que ser
feito por muitas”.
Dado esse estudo, propõe-se nesse trabalho analisar essas três justificativas dadas por
Smith para o aumento de produtividade sob três formas diferentes de utilização dos 10
empregados.
A primeira, tendo cada um dos 10 funcionários fazendo as operações necessárias para
fabricação de um alfinete seqüencialmente, ou seja, cada um fazendo um único alfinete de
cada vez.
A respeito da primeira justificativa, Adam Smith considera que quanto maior for a
repetição da mesma tarefa, maior é a habilidade adquirida para sua execução. Sob esse ponto
de vista, é lógico que quanto menos tarefas diferentes um empregado executar, maior será sua
destreza na execução delas. Considerando que os empregados nesse exemplo repetiriam as
mesmas 18 operações durante um grande período de tempo (meses, talvez anos),
possivelmente eles ganhariam maior destreza na execução delas. Não seria essa repetição
suficiente para que eles ganhassem a habilidade necessária em todas elas? No modelo
observado por Smith alguns chegam a executar até três tarefas. Será que a habilidade
adquirida em uma operação poderia ajudar em outra operação em se tratando de atividades no
mesmo ramo (fabricação de alfinetes)? Qual seria o nível ideal de especialização das pessoas?
Essas são dúvidas que as observações de Smith não são suficientes para responder.
Quanto à segunda justificativa, a alternância de tarefas, essa sim, parece ter um grande
efeito na diferença de produtividade encontrada por Smith. As atividades de preparação para
execução das tarefas como preparar os materiais, preparar as ferramentas e se posicionar para
a execução podem ser muito maior que a própria execução da tarefa. Pode-se tomar como
exemplo, a atividade de cortar o arame. Seria muito mais produtivo usar o mesmo tempo de
preparação de se cortar o arame para um único alfinete, para se cortar o arame para muitos
alfinetes com a mesma preparação. No caso do exemplo com cada empregado fazendo um
alfinete de cada vez, o tempo de alternância entre as tarefas influencia bastante na produção
total de alfinetes.
15
Quanto à terceira justificativa de Adam Smith, verifica-se que quanto mais tempo uma
pessoa se dedica a uma mesma tarefa, mais apta ela fica em achar pontos de melhoria no
processo e de identificar ferramentas e máquinas que possam lhe auxiliar na execução.
Novamente, para o exemplo dos 10 empregados fazendo todas as 18 operações, teríamos
teoricamente, por esse ponto de vista, uma queda na capacidade de identificação de melhorias
no processo. Entretanto, teríamos a possibilidade de identificar mais melhorias através de
idéias que possam surgir a partir de todos os dez empregados, ao invés de dependermos das
idéias de um único empregado. Além disso, ficaria mais fácil identificar melhorias na relação
de um processo com outro ou até mesmo na identificação de novas operações ou na
eliminação de alguma existente. Os empregados fazendo todas as atividades teriam uma visão
mais abrangente de todo o processo de fabricação de alfinete.
Percebe-se aqui o fato que talvez o mais importante seja enxergar as tarefas de forma
especializada e não necessariamente especializar as pessoas.
A segunda forma de dividir o trabalho sobre os dez empregados para análise das
justificativas dadas por Smith seria dividir as tarefas entre eles de forma que cada um fique
responsável por uma tarefa, ou no máximo por três tarefas, já que temos 18 operações a serem
divididas pelos 10 funcionários. Como esse é exatamente o caso observado por Smith, tem-se
a sua própria explicação para cada uma das justificativas apresentadas. Com uma maior
repetição da operação, o funcionário obtém maior destreza na execução da mesma. É possível
diminuir bastante a alternância das tarefas. E a especialização da tarefa pode fazer com que as
pessoas visualizem melhor o processo para que possam melhorá-lo ou buscar inovações ou
ferramentas na forma de executá-lo.
E por último, uma terceira forma de analisar as justificativas de Smith, seria fazer com
que todos executassem as 18 operações, mas não de forma seqüencial como foi visto no
primeiro exemplo. Para facilitar o entendimento, suponha-se que não haja limitação de
material e de ferramentas, de forma que todos os 10 empregados possam se empenhar na
execução da mesma operação por um tempo tal que elimine uma nova preparação para
execução da tarefa. Como exemplo, poderia ser utilizado um dia de trabalho para o tempo de
permanência numa mesma tarefa, já que teriam que interromper as atividades para irem para
suas casas e voltar à execução somente no dia seguinte. Nesse exemplo, os empregados
eliminariam o tempo gasto na alternância das atividades, que é a justificativa de Smith que
parece mais influenciar a produtividade. Quanto às demais justificativas de Smith, essa forma
de divisão do trabalho se comportaria como a que já foi discutida no primeiro exemplo.
16
Entretanto, existe uma grande diferença que pode ser ressaltada: os empregados teriam uma
visão muito maior da divisão do trabalho e da especialização das tarefas.
Dada a análise feita com esses exemplos, parece verificar-se que os principais fatores
que contribuíram para esse enorme aumento de produtividade foram basicamente a
capacidade de enxergar o trabalho nas suas operação mínimas e a minimização da alternância
entre as tarefas. Já o fato de especializar as pessoas nas atividades parece também ter certa
importância, mas não necessariamente essa especialização deve-se dar nas operações
mínimas. É preciso entender ainda qual seria o ponto ótimo de especialização das pessoas que
traria maiores benefícios para a produção.
2.2 Otimização do processo
Em 1911 foi publicado o livro Principles of scientific management (Princípios da
administração científica) de Frederick Winslow Taylor.
Taylor (1971) desejava substituir os métodos empíricos por métodos científicos.
Depois dos sucessos que vinham sendo obtidos com a divisão e especialização das tarefas e
consequentemente pela diminuição da alternância entre elas, Taylor achava que as tarefas
deveriam parar de ser feitas de forma empírica. Ele considerava possível achar
cientificamente as melhores formas de executá-las. Ele acreditava que um estudo científico
dos tempos e movimentos das tarefas, poderia mostrar a maneira mais produtiva de se
executar cada uma das operações mínimas identificadas na divisão e especialização do
trabalho.
Assim há diferentes maneiras em uso para fazer a mesma coisa, talvez quarenta, cinqüenta ou cem modos de realizar as tarefas em cada ofício e, por esta mesma razão, há grande variedade de instrumentos, usados em cada espécie de trabalho. Ora, entre os vários métodos e instrumentos utilizados em cada operação, há sempre método mais rápido e instrumento melhor que os demais. Estes métodos e instrumentos melhores podem ser encontrados, bem corno aperfeiçoados na análise científica de todos aqueles em uso, juntamente com acurado e minucioso estudo do tempo. Isto acarreta gradual substituição dos métodos empíricos pelos científicos, em todas as artes mecânicas. (Taylor, 1971).
Segundo Chiavenato (2003), para Taylor, o operário não tinha capacidade e nem
formação para analisar cientificamente seu trabalho e, por isso, não concordava que o
supervisor deixasse a critério do empregado a forma de execução da tarefa. Taylor achava que
deveria haver uma repartição da responsabilidade entre a gerência e o empregado. A gerência
17
(direção) ficaria com o planejamento (estudo e estabelecimento do método de trabalho) e o
empregado com a execução.
Segundo Taylor, essas novas atribuições da direção podem ser grupadas nos quatro
títulos abaixo:
a) “desenvolver para cada elemento do trabalho individual uma ciência que substitua
os métodos empíricos”;
b) “selecionar cientificamente, depois treinar, ensinar e aperfeiçoar o trabalhador”;
c) “cooperar cordialmente com os trabalhadores para articular todo o trabalho com os
princípios da ciência que foi desenvolvida”;
d) “manter divisão eqüitativa de trabalho e de responsabilidades entre a direção e o
operário”.
Para Taylor é essa combinação da iniciativa do trabalhador, com novos tipos de
atribuições conferidas à direção, que faz a administração mais eficiente do que os antigos
sistemas.
Chiavenato (2003) também comenta que embora Taylor preocupasse mais com a
filosofia, já que considerava que o objetivo principal da administração era assegurar o
máximo de prosperidade para o patrão e ao mesmo tempo o máximo de prosperidade ao
empregado, a tendência de seus seguidores foi uma preocupação maior com as técnicas do
que com a filosofia em si.
Taylor considerava que a prosperidade do empregado estava quase que totalmente
relacionada ao dinheiro. Que sua satisfação era conseqüência apenas do aumento dos seus
rendimentos. Taylor achava que a maior produtividade traria como conseqüências o aumento
do salário do empregado bem como a redução do preço do produto. Entretanto, seus
seguidores perceberam que, com a especialização da tarefa e o domínio de sua execução pela
direção (gerentes), poderiam especializar também os empregados de forma a reduzir a
execução a tarefas mínimas que poderiam ser facilmente compreendidas tornando os
empregados mais descartáveis e totalmente substituíveis, diminuindo o nível de habilidades
necessárias para a execução e conseqüentemente reduzindo os salários. Chiavenato (2003)
18
comenta que como a oferta de trabalhadores era abundante na época, a empresa nada devia a
eles, embora esperasse lealdade de sua parte.
Segundo Chiavenato (2003), uma decorrência do estudo de tempos e movimentos
acabou sendo a especialização do operário limitando-o a execução de uma única tarefa de
maneira contínua e repetitiva. Isso levou a criação das linhas de montagem onde o funcionário
perdeu toda sua liberdade e iniciativa e passou a ser confinado a execução automática e
repetitiva da tarefa durante toda sua jornada de trabalho.
Apesar de alguns exemplos de ações do próprio Taylor relatados no livro acabem
dando a impressão do confinamento à execução automática e repetitiva da tarefa sem maiores
esclarecimentos, pode-se ver que esse não era especificamente seu pensamento já que em sua
obra ele discute a cooperação dos trabalhadores no aperfeiçoamento dos métodos e das
ferramentas.
Pode parecer que, na administração científica, não há o mesmo incentivo que estimule o engenho do trabalhador a inventar métodos novos e melhores, bem como a aperfeiçoar as ferramentas, como nos antigos sistemas da administração. Verdade que na administração cientifica não é permitido ao operário usar qualquer instrumento e método que acredite ser o aconselhado na prática diária de seu trabalho. Todo o estímulo, contudo, deve ser dado a ele, para sugerir aperfeiçoamentos, quer em métodos, quer em ferramentas. E sempre que um operário propõe um melhoramento, a política dos administradores consistirá em fazer análise cuidadosa do novo método e, se necessário, empreender experiência para determinar o mérito da nova sugestão, relativamente ao antigo processo padronizado. E quando o melhoramento novo for achado sensivelmente superior ao velho, será adotado como modelo em todo o estabelecimento. Conferir-se-á honra ao trabalhador por sua idéia e ser-lhe-á pago prêmio como recompensa. Por este meio, a verdadeira iniciativa do operário é obtida de modo melhor sob a administração científica do que sob o antigo sistema individual. (Taylor, 1971).
Taylor ainda comenta em sua obra a importância do efeito que a idéia da tarefa exerce
sobre a eficiência do trabalhador. Inclusive, por isso, esse sistema vinha sendo conhecido pelo
nome de administração das tarefas. O simples fato de enxergar o trabalho em tarefas menores
que podem ser organizadas e melhoradas já tornava os funcionários mais produtivos.
Pode-se notar que a proposta científica de Taylor era de um sistema que permitisse a
gestão de conhecimento e a difusão das melhores práticas entre os operários. Ele queria
prover um modelo científico, que dada essa divisão do trabalho em tarefas mínimas, pudesse
melhorar continuamente a execução de cada uma delas. Daí a importância de se enxergar as
operações menores que compunham o trabalho.
19
Assim como muitos modelos criados recentemente para melhorar a capacidade e
maturidade da organização na execução dos processos, Taylor preconizava que os processos
deveriam ser gerenciados, definidos, medidos e estarem em constante otimização. É possível
identificar as seguintes atividades descritas na obra de Taylor: gerenciar e observar a
execução das tarefas; definir a melhor forma de executar, treinar os operários e repetir as boas
práticas; gerenciar quantitativamente os processos e descobrir melhorias que podem ser
adicionadas incentivando a participação dos funcionários para que o processo fique em
constante otimização. Não é difícil notar aqui uma clara semelhança com os níveis de
maturidade do modelo CMMI (2010) (Capability Maturity Model Integration) da SEI.
Inclusive, pode-se ressaltar até as semelhanças negativas que existem em algumas
implantações de seguidores que talvez não tenham se atentado para os valores corretos dos
dois modelos (Taylor e CMMI). Distorcendo a teoria fizeram com que o funcionário perdesse
toda sua liberdade e iniciativa, passando a ser confinado a execução automática e repetitiva da
tarefa se tornando descartável e facilmente substituível.
2.3 Estrutura organizacional
Segundo Chiavenato (2003), enquanto a teoria da Administração Científica era
desenvolvida nos Estados Unidos por Taylor e outros engenheiros, em 1916, surgia na França
a Teoria Clássica da Administração. Enquanto a primeira se caracterizava pela ênfase na
tarefa realizada pelo operário, a segunda dava ênfase na estrutura que a organização deveria
possuir para ser eficiente, mas ambas, de certa forma, tinham em comum a especialização do
trabalho.
Fayol (1989) salientava que toda empresa era dividida em seis funções: funções
técnicas, funções comerciais, funções financeiras, funções de segurança, funções contábeis e
funções administrativas.
Fayol (1989) também defendia alguns princípios, entre eles, a divisão do trabalho,
unidade de comando e centralização. Princípios que o levaram a sugerir uma estrutura
organizacional linear e hierárquica baseada nas funções essenciais e na autoridade única e
absoluta do superior sobre seus subordinados, típica de organizações militares.
20
Segundo Chiavenato (2003), atualmente, nem mais as funções são nomeadas e
divididas dessa forma, como também a forma de organizar e de compor a estrutura
organizacional tem mudado nas empresas.
Segundo ele, além da departamentalização funcional, que agrupa as atividades e
tarefas de acordo com as funções principais desenvolvidas pela empresa, algumas empresas
têm adotado outros tipos de departamentalização como forma de organizar a empresa para
melhor se adequar a seus objetivos. Portanto, além da funcional que é ainda a mais utilizada,
pode-se ter, também, uma departamentalização por produtos e serviços, localização
geográfica, clientes, fases do processo e por projetos. Algumas empresas também misturam
esses tipos para se chegar à forma ideal e que traga mais benefícios na execução dos seus
negócios.
Apesar de Fayol defender a estrutura linear e a unidade de comando, já é possível na
atualidade ver alguns casos questionando essa teoria e apresentando formas de trabalho com
mais de uma unidade de comando. O próprio PMI (Project Management Institute) considera a
estrutura matricial como uma das formas de se estruturar uma organização para projetos com
o comando dividido entre o gerente de projeto e o gerente funcional. À medida que as pessoas
se tornam mais auto-gerenciáveis, permite-se que os gerentes possam fazer cada vez mais
uma função de apoio, coach (técnico ou consultor), e menos da função de comando,
permitindo que as estruturas caminhem para modelos matriciais que possam dar mais
flexibilidade e agilidade para empresas desenvolverem e executarem seus negócios.
2.4 Limites da especialização
Através desse estudo elencou-se a relação da divisão e especialização do trabalho na
sociedade e nas empresas através das profissões, da estrutura dos departamentos das empresas
e das execuções das tarefas. Porém muitas críticas foram feitas a esse modelo devido ao fato
de não se saber ao certo até que ponto as pessoas também deveriam ser especializadas.
“Por mais que suas vantagens sejam universalmente reconhecidas e não se admita a
possibilidade de haver progresso sem o trabalho especializado dos sábios e dos artistas, a
divisão do trabalho tem suas limitações e a experiência e o senso da medida ensinam não
ultrapassar.” (Fayol, 1989).
21
Alem disso, verifica-se nas empresas atuais, uma busca por agilidade e
conseqüentemente a necessidade de agruparem as pessoas não apenas pelas funções técnicas
executadas, mas também por outros tipos de relações (projetos, clientes, produtos, etc) e, às
vezes, até mesmo por mais de uma forma ao mesmo tempo, forçando-as a flexibilizar a
unidade de comando rígida que existia e a amadurecer seus profissionais tornando-os mais
auto-gerenciáveis.
22
3 VISÃO SISTÊMICA DO TRABALHO
Segundo Senge (2010), as pessoas aprendem desde cedo, a desmembrar os problemas
e a fragmentar o mundo para tornar as tarefas e assuntos complexos mais administráveis. Mas
em troca, elas pagam um preço oculto e muito alto, que é perda da capacidade de perceber as
conseqüências de suas ações, perdendo a noção intrínseca de conexão com o todo.
A abordagem clássica havia sido influenciada por três princípios intelectuais
dominantes: o reducionismo, princípio que se baseia na crença que todas as coisas podem ser
decompostas e reduzidas em seus elementos fundamentais simples; o pensamento analítico,
em que a solução ou explicação do todo constitui a soma ou resultante das soluções ou
explicações das partes; e o mecanicismo, princípio que se baseia na relação simples de causa-
e-efeito entre dois fenômenos. (Chiavenato, 2003).
Com advento da teoria geral dos sistemas, a administração passou a ser também
influenciada por três novos princípios opostos ao da abordagem clássica que eram voltados
para especialização da tarefa. Esses novos princípios são: o expansionismo, princípio que
sustenta que todo fenômeno é parte de um fenômeno maior e a ênfase reside na focalização do
todo do qual aquele fenômeno faz parte; o pensamento sintético onde o fenômeno é visto
como parte de um sistema maior e é explicado em termos do papel que desempenha nesse
sistema maior; e a teleologia, princípio segunda a causa é condição necessária, mas nem
sempre suficiente para que surja o efeito. (Chiavenato, 2003).
Senge (2010) acredita que o mundo não é feito de forças separadas, sem relação entre
si, e quando as pessoas perceberem isso, será possível construir organizações que aprendam,
organizações nas quais as pessoas expandam continuamente sua capacidade de criar
resultados que realmente desejam, em que se estimulam padrões de pensamento novos e
abrangentes, onde a aspiração coletiva ganha liberdade e as pessoas aprendam continuamente
a aprender juntas.
Para Senge (2010) existem cinco disciplinas ou dimensões que convergem para inovar
as organizações que aprendem:
a) domínio pessoal: capacidade de esclarecer e aprofundar continuamente a própria
visão pessoal;
23
b) modelos mentais: generalizações ou mesmo imagens que influenciam nossa forma
de ver o mundo e de agir;
c) visão compartilhada: capacidade de ter uma imagem compartilhada do um futuro
que se busca criar em conjunto;
d) aprendizagem em equipe: capacidade de estender os limites existentes de que uma
única pessoa consegue aprender individualmente.
e) visão sistêmica: capacidade de ver as conexões e relações existentes entre objetos e
ações.
Segundo Senge (2010), o pensamento sistêmico é a disciplina que integra as outras,
fundindo-as em um corpo coerente de teoria e prática. Construir uma visão compartilhada
estimula o compromisso com o longo prazo. A teoria dos modelos mentais concentra-se na
abertura necessária para revelar as limitações em nossas formas atuais de ver o mundo. A
aprendizagem em equipe desenvolve a habilidade dos grupos de buscarem uma visão do
quadro como um todo, que está além das perspectivas individuais. E o domínio pessoal
estimula a motivação pessoal de aprender continuamente como nossas ações afetam o mundo
e a não ficar presos em nossos limitados modelos mentais.
Cada pessoa pensando de forma sistêmica é importante, mas como os sistemas podem
ser muito complexos, conter muitas variáveis e difíceis de serem observados, todas essas
disciplinas colaboram entre si para tornar maior a visão e o alcance de um grupo de pessoas,
algo que individualmente talvez fosse impossível de conseguir.
Sem a visão sistêmica, as organizações acabam perdendo muitos esforços em
atividades e ações que individualmente parecem ser importantes, mas que sistemicamente e
globalmente não contribuem ou contribuem negativamente para os resultados da empresa.
Pode-se, por exemplo, achar que está agindo para resolver um problema, quando na verdade
está aumentando o problema. Sem visualizar globalmente a situação, acaba-se por aumentar o
esforço na mesma ação e fazer com que o problema se torne cada vez maior em um ciclo sem
fim.
Assim como foi vista a importância de se enxergar as tarefas de forma dividida e
especializada para compreender o que está sendo feito, melhorar o processo e diminuir a
alternância entre as atividades, percebe-se aqui a importância que existe também na
24
perspectiva contrária de se enxergar as tarefas como parte de um sistema complexo e
dinâmico onde cada tarefa o influencia e é por ele influenciada. Essa nova perspectiva ajuda a
entender quais tarefas contribuem ou não para resultados positivos no sistema, fazendo com
que haja uma maior eficiência nas escolhas das ações e na alocação dos esforços.
25
4 FATOR HUMANO
4.1 Abordagem humanística
Como foi visto no estudo da especialização do trabalho, parece que por uma lógica
simples, quanto mais se especializa o trabalho das pessoas, mais hábeis elas ficam e
consequentemente mais produtivas.
Entretanto, quando se lida com pessoas, essa lógica simples não funciona. Vários
fatores psicológicos e sociais também podem influenciar na produtividade das pessoas que
trabalham nas organizações.
Segundo Chiavenato (2003), na década de 1930, devido à necessidade de humanizar e
democratizar a administração, teve início a Teoria das Relações Humanas na administração. A
abordagem humanística fez com que a preocupação com a máquina e o método de trabalho
cedesse prioridade para a preocupação com as pessoas e seus grupos sociais.
Ainda segundo Chiavenato (2003), Kurt Lewin em suas pesquisas sobre
comportamento social já se referia ao importante papel da motivação com a elaboração de
uma teoria de campo que se baseava em duas suposições fundamentais: que o comportamento
humano é derivado da totalidade de fatos coexistentes e que esses fatos têm caráter de um
campo dinâmico onde cada parte desse campo tem inter-relação com as demais outras partes.
Lewin propõe que o comportamento é função ou resultado da interação entre a pessoa
e o ambiente.
Segundo Chiavenato (2003), Elton Mayo conduziu uma pesquisa em uma indústria
têxtil com elevadíssima rotatividade de pessoal em torno de 250% ao ano e que havia tentado
inutilmente várias abordagens de incentivos salariais. Mayo introduziu intervalos de descanso,
delegou aos operários a decisão sobre os horários de produção e contratou uma enfermeira.
Em pouco tempo, emergiu um espírito de grupo, a produção aumentou e a rotatividade de
pessoal diminuiu.
Chiavenato (2003) descreve que em 1927, o Conselho Nacional de Pesquisas iniciou
uma série de experiências na fábrica de Hawthorne. Nessas experiências foi observada a
variação da produção em relação à modificação de diversos fatores nas condições de trabalho
26
como o sistema de pagamento por grupo, intervalo para descanso e quantidade de horas de
trabalho.
Segundo Chiavenato (2003), através dessas experiências foi possível chegar as
seguintes conclusões:
a) que o nível da produção é resultante da integração social do empregado e não
somente de sua capacidade física ou fisiológica;
b) que quanto maior a integração social no grupo, maior a disposição para produzir;
c) que os trabalhadores não agem ou reagem isoladamente como indivíduos, e sim,
como membros de um grupo;
d) que as recompensas e sanções sociais podem ter mais valor que as financeiras,
observado que alguns operários preferiam ganhar menos do que por em risco suas
relações amistosas com os colegas;
e) que cada pessoa possui uma personalidade própria e influi no comportamento e nas
atitudes das outras com que mantém contato e são, por outro lado, igualmente
influenciadas.
f) que as pessoas querem ser compreendidas, aceitas e participar, no intuito de atender
a seus interesses e aspirações pessoais;
g) que trabalhos simples e repetitivos tornam-se monótonos e maçantes afetando
negativamente a atitude do trabalhador e reduzindo a sua satisfação e eficiência, ou
seja, que a natureza do trabalho tem influência sobre a moral do trabalhador.
4.2 Grupos e lideranças informais
Uma das conclusões das experiências de Hawthome foi a identificação da existência
de grupos informais e de sua influência na produção. Esses grupos são, por sua vez,
influenciados por vários líderes informais. Um líder informal é qualquer pessoa no ambiente
de trabalho que exerça uma influência positiva ou negativa nas demais pessoas. A soma
dessas influências é que vão dar origem aos valores, à motivação e ao comprometimento do
grupo.
27
Maslow (2001) descreve em seu livro uma observação feita em uma tribo indígena
onde não existia uma hierarquia formal. Ele observou que a para cada função diferente, surgia
um líder diferente, baseado nas necessidades de cada função e na confiança das pessoas no
conhecimento e nas habilidades de cada líder.
Isso mostra o processo natural que existe no aparecimento de líderes informais durante
a realização de trabalhos em uma sociedade. Percebe-se também que qualquer pessoa no
ambiente de trabalho pode influenciar e ser influenciada, sendo que essa característica não é
exclusiva do líder formal (chefe ou gerente). Todas as pessoas são líderes em potencial e em
qualquer grupo que seja, haverá sempre pessoas influenciando e sendo influenciadas,
formando sua cultura, seus valores e suas crenças.
Por essas razões, é que se torna importante observar os grupos informais e fazer com
que as influências geradas pelas pessoas sejam as mais positivas possíveis, motivando-as a
agir de forma a se obter o máximo comprometimento com o grupo e com o trabalho realizado.
Para Chiavenato (2003), quando as tarefas são rotineiras e repetitivas, a liderança
formal é limitada e sujeita a controles pelos chefes. Nesses ambientes, as pessoas vêem as
lideranças informais como o único caminho para atender suas necessidades e são fortemente
por elas influenciadas, e na maioria das vezes, influenciadas negativamente, ou seja, contra os
interesses da organização.
4.3 Motivação
Os estudos sobre motivação tendem e descobrir e entender as razões para que uma
pessoa aja de certa maneira.
Segundo Chiavenato (2003), a motivação se refere ao comportamento que é causado
por uma necessidade dentro do indivíduo que o direciona aos objetivos que podem satisfazer
essas necessidades.
“O homem é considerado um animal dotado de necessidades que se alternam ou se
sucedem conjunta ou isoladamente. Satisfeita uma necessidade, surge outra em seu lugar e,
assim por diante, contínua e infinitamente” (Chiavenato, 2003).
Chiavenato (2003) fala de três níveis ou estágios de necessidades que devem ser
atendidas: as fisiológicas, as psicológicas e as de auto-realização.
28
Figura 1: Hierarquia das necessidades de Maslow.
Fonte: Maslow, 2001.
Um dos trabalhos mais conhecidos de Maslow (2001) é sua pirâmide de hierarquia das
necessidades. Maslow acreditava que todas as pessoas buscavam subir pelas camadas da
pirâmide em busca da auto-realização. À medida que um nível fosse satisfeito, a pessoa era
motivada a buscar o próximo nível. E ele acreditava que o papel das empresas seria o de
facilitar esse caminho até o topo da pirâmide. Em primeiro lugar deveriam ser satisfeitas as
necessidades fisiológicas como alimentação, sono, sexo, abrigo e atividade física. No segundo
nível aparecem as necessidades por segurança como proteção, autodefesa, estabilidade no
emprego. O próximo nível é a necessidade de socialização através da amizade, da família e
dos relacionamentos em geral. No quarto nível temos a necessidade de estima, de ser
respeitado e de ser reconhecido. E por último a auto-realização que é o impulso de realizar o
próprio potencial e de estar em contínuo autodesenvolvimento.
Para Maslow (2001), com as pessoas em processo de auto-realização, estes indivíduos
altamente evoluídos assimilariam o seu trabalho como identidade, fazendo com que o trabalho
se tornasse parte inerente da definição que eles fazem de si mesmo. Quando você pode dizer
“Nós fizemos isso” você participa da glória, do prazer e do orgulho de todos do grupo.
“As únicas pessoas felizes que conheço são aquelas que estão trabalhando direto em
algo que acham importante.” (Maslow, 2001).
Por fim, Maslow pensava que não era necessário descobrir algo para fazer as pessoas
criarem. Elas são naturalmente criativas. O que se precisa descobrir é o que está inibindo e
29
bloqueando estas pessoas tornando-as não criativas. Ou seja, é preciso descobrir o que as
empresas estão fazendo para bloquear as pessoas a subir na hierarquia das necessidades e
buscarem sua auto-realização.
4.4 Comprometimento
Segundo Chiavenato (2003), uma das formas que os líderes têm de transformar as
organizações e obter o comprometimento das pessoas é desenvolver a confiança nas pessoas.
Para ele, não se pode desenvolver a confiança sem tratar as pessoas com respeito e dignidade.
A confiança exige que os valores organizacionais adotados tenham forte significado para as
pessoas.
Além desse ambiente de confiança, Senge (2010) acredita que a visão sistêmica
contribui para que as pessoas se comprometam com o todo. Quando as pessoas enxergam
apenas um pedaço do trabalho, elas não conseguem se comprometer com o resultado final do
trabalho.
Segundo Maslow e Senge, uma visão mais ampla e compartilhada faz a pessoa se
sentir na busca de sua auto-realização fazendo com que seu trabalho passe a se confundir com
o seu próprio eu.
“Uma real realização significa, inevitavelmente, uma tarefa válida e virtuosa. Realizar
uma tarefa idiota muito bem certamente não é real realização.” (Maslow, 2001).
Herzberg, citado por Chiavenato (2003), propõe o enriquecimento das tarefas ou do
cargo como forma de proporcionar continuamente a motivação no trabalho. Consiste em
substituir tarefas mais simples por tarefas mais complexas ou por um número maior de
tarefas. Segundo ele, esse enriquecimento da tarefa, pode dar maior significado para o
trabalho, provocando efeitos desejáveis como o aumento da motivação, aumento da
produtividade, redução do absenteísmo e da rotatividade de pessoas.
Além disso, uma visão mais global e sistêmica permite que as pessoas tenham mais
capacidade de contribuírem nas tomadas de decisão, aumentando a contribuição de cada
pessoa e conseqüentemente sua motivação e comprometimento por se sentir mais responsável
pelo trabalho realizado.
30
“O comprometimento pessoal é uma emoção. Se essa é ignorada, não há
comprometimento pessoal e a tarefa passa a ser executada mecânica e automaticamente, sem
motivação.” (Chiavenato, 2003).
31
5 TEORIAS COMPLEMENTARES
Segundo Chiavenato (2003), em teorias recentes como a teoria da contingência, a
teoria das relações humanas vem sendo encarada mais como uma compensação ou
complemento do que como uma contradição com a administração científica.
Para Chiavenato, a teoria da contingência enfatiza que não há nada absoluto nas
organizações ou na teoria administrativa. Tudo é relativo e tudo depende. Sendo assim, não há
que falar que uma teoria é melhor ou pior que outra. Elas podem ter sucessos diferentes para
ambientes diferentes e podem ser complementares.
Segundo ainda Chiavenato (2003), Lawrence e Lorsch concluíram através de uma
pesquisa que todas as empresas possuem características de diferenciação e integração. A
diferenciação relaciona-se ao processo de especialização da tarefa, enquanto a integração
refere-se ao movimento oposto no sentido de obter a união e coordenação dos esforços.
Isso mostra a necessidade das empresas de conviver com as duas visões: especializada
e sistêmica.
32
6 HISTÓRICO DA ENGENHARIA DE SOFTWARE
É possível observar aspectos de algumas abordagens administrativas na engenharia de
software. Assim como na administração científica de Taylor, a tarefa de desenvolvimento de
software também foi dividida em atividades menores para que pudesse ser mais bem
compreendida e otimizada. A engenharia de software iniciou-se em um trabalho científico
para descobrir quais eram as etapas necessárias para a produção de um software, e para cada
uma dessas etapas, começou-se a catalogar quais seriam as melhores práticas, métodos,
técnicas e ferramentas para tornar o trabalho mais produtivo e para se produzir um software
de melhor qualidade.
Pressman (2011) fala a respeito de cinco atividades que podem ser consideradas para
qualquer processo genérico de software: comunicação (levantamento das necessidades),
planejamento, modelagem, construção, emprego.
Pode-se observar também em vários processos de software e livros de engenharia de
software um agrupamento das atividades por disciplinas.
O RUP (Rational Unified Process), processo unificado criado por Ivar Jacobson,
Grady Booch e James Rumbaugh define algumas disciplinas que são agrupamentos de
atividades que vão a um nível de detalhe um pouco maior do que as atividades genéricas
levantadas por Pressman. Ele acrescenta também algumas atividades de apoio que são
necessárias para o desenvolvimento do software. Ao todo, o RUP apresenta as seguintes
disciplinas: modelagem de negócio, requisitos, análise, projeto, implementação, testes,
implantação, gerência de configuração e mudanças, gerência de projeto e configuração do
ambiente (Kruchten, 2000).
Assim como aconteceu nos trabalhos de Taylor na teoria científica da administração,
onde se observou que alternância entre as tarefas trazia perdas de produtividade, os primeiros
processos de software também propunham fazer cada uma dessas atividades de forma
completa antes de passar para a seguinte. Além da perda pela alternância, verificou-se
também que se tinha condição de fazer muito melhor a tarefa seguinte se a tarefa anterior
tivesse sido feita completamente de forma a minimizar retrabalhos.
Desse conceito, surgiu o processo de software chamado de “modelo cascata” que
sugere uma abordagem seqüencial e sistemática para o desenvolvimento de software,
33
começando com o levantamento das necessidades com o cliente, avançando pelas atividades
de planejamento, modelagem, construção, entrega, até a continuidade do sistema. (Pressman,
2011).
Assim como na administração científica, a visão detalhada do trabalho permitiu a
engenharia de software seguir melhorando as atividades. Com isso a produção de software
obteve benefícios parecidos com os benefícios conseguidos pelos seguidores de Taylor: maior
produtividade, melhor assertividade na execução das tarefas e mais qualidade do produto
final. Além disso, como previu também Taylor, modelos de capacitação e maturidade, como o
CMMI (Capability Maturity Model Integration) e o MPS-BR (Melhoria de Processos do
Software Brasileiro), foram criados para melhorar e difundir as técnicas, os métodos e as boas
práticas de cada disciplina.
Entretanto, começou-se a perceber que em vários projetos, os produtos construídos
não atendiam as necessidades do usuário. Às vezes, eram construídos softwares de qualidade
que atendiam completamente os requisitos, mas esses requisitos não representavam bem as
necessidades do usuário ou o software não trazia benefício algum. Em outras situações, o
software não chegava nem a ficar pronto, porque somente no meio da implementação,
descobria-se que o modelo definido no projeto não era implementável.
Esses problemas geraram uma necessidade da engenharia de software evoluir também
em um outro sentido. Além de observar o trabalho de forma detalhada e melhorar cada
atividade, começou a haver a necessidade de observar os benefícios gerados pelo software
construído, bem como o relacionamento entre as atividades e suas conseqüência com os
benefícios gerados. Nesse momento alguns aspectos vistos na abordagem sistêmica da
administração começaram a ser percebidos.
Um pouco mais de atenção passou a ser dada aos aspectos globais do desenvolvimento
de software. As disciplinas e suas atividades passaram a ser vistas também de forma
relacionada. Através da visão sistêmica, identificou-se que no desenvolvimento de software
havia uma dependência mútua das disciplinas. Não eram somente as disciplinas seguintes que
dependiam das anteriores, mas o contrário também era verdadeiro. Descobriu-se que o
“feedback”, o retorno das disciplinas seguintes poderiam melhorar os resultados das
disciplinas anteriores.
Assim, verificou-se que em diversas situações, era preferível voltar várias vezes em
todas as disciplinas, em um processo cíclico e evolutivo, até que todo software ficasse
34
completo a fazer o trabalho completo de cada uma delas, ainda que perdesse algum dos
benefícios citados.
Desse conceito surgiram os processos “iterativos” com o trabalho passando por todas
as disciplinas e terminando na entrega de um executável. Com isso, o “feedback” obtido com
a entrega poderia alimentar a próxima iteração fazendo com que o software atendesse cada
vez mais as necessidades do usuário.
Craig Larman (2004) destaca em seu livro as principais motivações para se
desenvolver de forma iterativa. Entre elas estão: a antecipação da entrega de pedaços do
software trazendo confiança e satisfação para equipe e para o cliente; e a antecipação dos
riscos e mudanças nos requisitos para as fases iniciais do projeto tornando-os mais
controláveis e previsíveis.
Entretanto, faltava-se ainda resolver um problema gerado pela iteratividade: minimizar
o retrabalho e as dificuldades de integração dos pedaços de software. Verificou-se que esse
trabalho diminuiria se ele começasse com as partes de maior valor para o negócio e maior
dificuldade técnica. Isso faria com que o risco diminuísse consideravelmente e
consequentemente aumentasse as chances de sucesso do projeto. Esse conceito de priorização
de requisito ganhou tal importância que passou a ser um dos principais trabalhos dos
arquitetos de software, a identificação de requisitos arquiteturais que tem sido uma tarefa
essencial para vários processos iterativos. Alguns processos até possuem fases para verificar
se alguns pontos de risco foram superados. No RUP, onde essa priorização é feita, o final da
fase de concepção serve para indicar que o projeto é viável tecnicamente e vale a pena ser
construído no ponto de vista do negócio. Já o final da fase de elaboração indica que os
maiores riscos técnicos e de negócio foram superados e estabilizados permitindo um aumento
da produção na fase seguinte (Rational, 2001). No Scrum, o “Backlog” do produto é,
geralmente, ordenado por valor, risco, prioridade e necessidade. Quanto maior a ordem (topo
da lista) de um item, mais o item do “Backlog” do produto deve ser considerado, e mais
consenso existe em relação a ele e ao seu valor (Schwaber; Sutherland, 2011).
Esses são vários conceitos e técnicas vindos de uma visão mais sistêmica e não
somente da visão simples de cada disciplina e atividade.
Mais recentemente, um novo conceito global vem surgindo na engenharia de software,
a busca por agilidade. Não se pode mais seguir um processo de software fazendo-se todos os
modelos simplesmente pela padronização sem um motivo que realmente justifique cada
35
artefato produzido. Com isso, os processos precisaram ser mais flexíveis e permitirem certa
customização de um projeto para o outro para que somente o realmente necessário fosse feito.
O processo utilizado em um projeto poderia não ser o ideal para outro projeto, mas ainda
assim, seria importante que as melhores práticas, técnicas e ferramentas fossem
compartilhadas e utilizadas quando necessárias. Assim, uma ênfase maior passou a ser dada a
conceitos fundamentais como valores e princípios ao invés de enfatizar processos rígidos e
burocráticos.
“Se os homens são puros, as leis são desnecessárias; se os homens são corruptos, as
leis são inúteis". (Thomas Jefferson). Pode-se fazer uma analogia aos processos mostrando
que alguns não vão segui-los, ou porque não acreditam neles ou porque não concordam com
eles. Já aqueles que os seguem, talvez não precisassem deles. Bastava-se para esses, o
direcionamento dos princípios e valores para que com o bom senso utilizassem as boas
práticas disponíveis.
Tanto que esse conceito fez com que personagens importantes da engenharia de
software se juntassem e criassem o manifesto ágil.
Através deste trabalho, passamos a valorizar: Indivíduos e interação entre eles mais que processos e ferramentas; Software em funcionamento mais que documentação abrangente; Colaboração com o cliente mais que negociação de contratos; Responder a mudanças mais que seguir um plano. (BECK e outros, 2012)
Interessante observar também, que essa abordagem ágil está desenvolvendo também
aspectos de outra teoria administrativa: a teoria humanística. Esse desenvolvimento parece ser
fundamental para se permitir que se diminuam as regras e a rigidez nos processos e passe a se
trabalhar no nível mais fundamental de valores e princípios com o objetivo de aumentar a
liberdade e flexibilidade na execução das atividades sem reduzir a qualidade do produto final.
No primeiro item do manifesto já se fala da valorização do indivíduo e do relacionamento
entre eles. O terceiro item do manifesto mostra também a valorização da confiança do cliente,
mais que papéis e assinaturas.
Pode-se até dizer que existe mais valor em errar juntos do que em acertar sozinho,
tamanha importância que está sendo dada ao relacionamento e confiança entre as pessoas em
relação aos processos e às atividades. O grupo fica mais forte para superar e corrigir seus
próprios erros e caminhar de forma mais consistente para direção correta.
36
Além disso, observa-se também um incentivo a equipes auto-gerenciáveis que só pode
ser conseguido com o desenvolvimento e amadurecimento das pessoas propiciando a elas um
caminho para auto-realização. Um dos princípios do manifesto ágil é “Construir projetos ao
redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que
farão seu trabalho” (BECK e outros, 2012).
No guia do Scrum desenvolvido por Schwaber e Sutherland (2011), temos também:
“Times Scrum são auto-organizáveis e multifuncionais. Equipes auto-organizáveis escolhem
qual a melhor forma para completarem seu trabalho, em vez de serem dirigidos por outros de
fora da equipe”.
Até o PMI (Project Management Institute) já observou essa tendência do auto-
gerenciamento e criou certificações de gerenciamento de projeto para pessoas técnicas. Um
dos alvos dessa certificação CAPM® são os profissionais técnicos sem experiência em
gerenciar projetos, mas que trabalham em projetos e querem adquirir mais conhecimento de
gerenciamento de projeto.
Portanto, a engenharia de software parece, agora, ter tomado o caminho ideal,
juntando-se as abordagens científica, sistêmica e humanística da administração. Valorizando
tanto a especialização da atividade, a visão holística e sistêmica quanto também as pessoas. E
por esses caminhos ela deve seguir evoluindo seus métodos, técnicas, conceitos e ferramentas
para propiciar as melhores práticas de desenvolvimento de software.
Figura 2: Três pilares para a Engenharia de Software.
Fonte: Elaborada pelo autor.
37
7 ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTW ARE
Nesse tópico, pretende-se mostrar como poderia ser composta e estruturada a equipe
de desenvolvimento de forma a buscar o máximo possível dos fatores de produtividade
discutidos nos capítulos anteriores.
Será apresentada uma forma de organização baseada em desenvolvedores mais
generalistas sob uma gerência multidimensional em contraste a equipes com desenvolvedores
mais especializados com unidade de comando única e mais autoritária.
A seguir será visto que há fortes indicações que essa equipe formada por
desenvolvedores mais generalistas sob uma gerência multidimensional teria mais condições
de atingir os fatores de produtividade discutidos.
Serão analisados aspectos importantes para a eficiência e a eficácia no
desenvolvimento de sistemas como: motivação e comprometimento da equipe; liderança;
visão sistêmica e benefícios para os clientes; comunicação; padronização e melhoria contínua
das atividades. Para cada um desses aspectos, serão verificadas as facilidades e dificuldades
de atingi-los caso se tenha estruturado a equipe com desenvolvedores mais generalistas.
A tabela a seguir mostra os critérios que serão analisados para a equipe que está se
propondo de forma a se observar e inferir se ela se adéqua aos fatores identificados
anteriormente como provedores de maior produtividade.
TABELA 1: Critérios observados Aspecto Critérios observados Motivação Capacidade das pessoas atingirem os maiores níveis
na pirâmide de hierarquia de Maslow. Comprometimento Maior probabilidade das pessoas se comprometerem
e de se responsabilizarem pelo trabalho. Liderança Capacidade de trazer as influências das lideranças
informais para os interesses da organização. Visão sistêmica Capacidade da equipe de atingir uma visão mais
sistêmica, enxergar melhor as conseqüências de suas ações e propiciar maiores benefícios para os clientes.
Comunicação Utilização da comunicação de forma mais eficiente. Adequação a processos iterativos Facilidade de alocação dos recursos humanos. Padronização e processos de software
Gestão do conhecimento, reutilização de padrões e de boas práticas e melhoria do processo. Fonte: Elaborada pelo autor.
38
7.1 Composição da equipe
Visto a importância dessas três perspectivas para o desenvolvimento de qualquer
trabalho: a especialização da tarefa, a visão sistêmica e o desenvolvimento das pessoas. Essa
importância que existe tanto em enxergar com detalhe cada parte do trabalho bem como
enxergar sua conseqüência para o todo, sem deixar de lado as pessoas que o executam. Ou
seja, a importância das perspectivas do todo, da parte e do meio.
Pode-se tentar agora descobrir uma forma ideal de organizar e dividir o trabalho da
engenharia de software entre as pessoas de forma a viabilizar ao máximo o desenvolvimento
dessas três perspectivas dentro da organização.
Como foi analisado, as pessoas precisam ter certa especialização nas tarefas
executadas para ganhar experiência e habilidade, mas essa não pode ser excessiva de forma a
impedir a motivação e a visão sistêmica do grupo. Com relação à motivação, foi visto que a
pessoa precisa se sentir fazendo algo importante em busca se sua auto-realização. Já no
aspecto da visão sistêmica, é importante que as pessoas possam ver o máximo possível do
trabalho que está sendo realizado. Quando isso não for possível, que a soma das visões
individuais consigam atingir todo o sistema observado e que exista também um pouco de
sobreposição entre as competências para facilitar a comunicação das visões e juntas formarem
uma visão compartilhada do todo.
Para atender ao máximo esses requisitos, a equipe poderia ser composta por
desenvolvedores multidisciplinares e auto-gerenciáveis. O nível de especialização utilizado
para as pessoas poderia ser a especialização na área de desenvolvimento de sistemas da
engenharia de software. A princípio, esse nível de especialização já seria suficiente para
repetir várias vezes o trabalho e adquirir maior habilidade na execução. Pegando-se as
disciplinas do RUP como exemplo, esses desenvolvedores teriam que ter competência para
trabalhar no máximo de disciplinas possíveis, desde a modelagem de negócio até a
implantação passando também pelas disciplinas de apoio.
Caso a competência da pessoa não consiga atingir todas as disciplinas, a pessoa
deveria participar de projetos onde existam outras pessoas que possam suprir suas
deficiências, mas de forma que exista alguma sobreposição de disciplinas para facilitar a
comunicação e formar uma visão compartilhada do todo no grupo. Inclusive algumas pessoas
39
da equipe deveriam ir adquirindo competência no negócio do cliente para que essa
sobreposição e visão compartilhada cheguem até ele.
Observando-se as formas de departamentalização e as tendências às visões
multidimensionais da organização discutidas anteriormente, poderia haver quatro visões
gerenciais sustentando esses desenvolvedores de forma matricial: gerência de negócio,
gerência de projeto, gerência estratégica e gerência funcional. A gerência de negócio para
manter o trabalho de desenvolvimento direcionado a fornecer benefícios reais para o cliente
que está sendo atendido. A gerência de projeto para manter o trabalho direcionado para os
acordos realizados entre os interessados e manter a confiança entre eles. A gerência
estratégica para manter o grupo fiel aos valores, princípios e a visão de futuro compartilhada.
E a gerência funcional para fornecer as competências técnicas necessárias ao desenvolvimento
dos sistemas.
Figura 3: Estruturação da equipe.
Fonte: Elaborada pelo autor.
A figura 3 mostra exemplos da distribuição das habilidades e competências dos
desenvolvedores. Quanto mais disciplinas o desenvolvedor tiver conhecimento, melhor para
se construir uma visão sistêmica, o que torna importante que eles sejam treinados nas
competências que ainda não possuem. As sobreposições destacadas em laranja permitem que
se tenham múltiplos modelos mentais, facilitam a aprendizagem em equipe e ajudam a formar
a visão compartilhada. Alguns desenvolvedores e clientes deveriam possuir também
competências sobrepostas para que a visão conjunta abranja um escopo maior tornando mais
Negócio Modelagem de Negócios Requisitos Análise e Design Implementação Teste Implantação Gerência de Configuração Gerenciamento de Projeto Ambiente
D D D D D
Estratégia Negócio
Técnica Projeto
C C
40
próximos o desenvolvimento do software e o conhecimento do negócio. As elipses mostram
as visões gerenciais multidimensionais que direcionam os grupos para atingirem os resultados
e benefícios esperados pela organização.
Nas seções seguintes será discutido como essa forma de organização poderia atender
alguns aspectos existentes no desenvolvimento de sistemas como: motivação e
comprometimento da equipe; liderança; visão sistêmica e benefícios para os clientes;
comunicação; padronização e melhoria contínua das atividades.
7.2 Motivação e comprometimento
Como foi visto anteriormente, a organização deve facilitar o caminho para que as
pessoas consigam chegar ao topo da pirâmide de Maslow para ficarem em busca constante
das suas auto-realizações.
Se forem aplicados na equipe de desenvolvimento de sistemas os mesmos conceitos
vistos na época de Taylor em que algumas organizações especializavam as tarefas e as
pessoas com objetivo de tornar as tarefas mais independentes das pessoas, tornando-as
descartáveis, e consequentemente reduzindo seus salários, não se conseguiria atingir nem os
primeiros níveis da pirâmide de Maslow. Nesses primeiros níveis, as pessoas buscam
satisfazer suas necessidades fisiológicas e de segurança. Elas buscam ter um salário que
proporcione o atendimento dessas necessidades, além de buscarem estabilidade para ter
segurança que esse salário não seja algo temporário. Além disso, nesses modelos de trabalho,
grande parte da comunicação é feita através de documentos que transferem as especificações
de uma disciplina (um setor) para a disciplina seguinte deixando as pessoas mais isoladas e
sozinhas diante do computador e prejudicando o atendimento das necessidades de
socialização, amizade e afeto. Quanto às necessidades de estima, reconhecimento e respeito,
costumam-se ver atitudes de premiação que mais desmotivam os não premiados do que
motivam a própria pessoa premiada, que muitas vezes se sente afastada do grupo, e até
culpada por isso. Quanto à busca por auto-realização, foi visto pelos estudos de Maslow,
Senge e Chiavenato que seria quase impossível alguém se sentir realizado executando tarefas
em um escopo tão reduzido.
Já com a equipe formada por desenvolvedores mais generalistas e multidisciplinares
seria muito mais provável conseguir satisfazer essas necessidades das pessoas. Seus trabalhos
41
se tornariam mais nobres, elas realizariam coisas mais importantes, elas se tornariam mais
reconhecidas, seus salários seriam maiores, elas interagiriam mais com outras pessoas, elas
conseguiriam buscar a auto-realização. Com a visão sistêmica, elas passariam a fazer parte
não só mais de uma simples tarefa de um projeto. Elas passariam a fazer parte da realização
do produto e até mesmo dos seus benefícios gerados para os clientes dos seus usuários.
Como foi visto anteriormente, o comprometimento das pessoas é conseguido através
da confiança. Facilitar o caminho das pessoas a subirem na hierarquia da motivação e a
buscarem suas auto-realizações contribui muito para gerar essa confiança. Quando as pessoas
se sentem realizadas e importantes no que fazem recebendo reconhecimento e respeito, elas se
comprometem.
7.3 Lideranças
Foi visto a força que as lideranças informais exercem sobre a equipe, e que é
importante torná-la positiva para a organização.
Com a proposta de equipe de desenvolvedores mais generalistas, espera-se dar mais
força para essas lideranças informais. A gerência matricial (funcional, projetos, estratégia,
cliente) torna as lideranças formais mais fracas e por isso a necessidade de equipes auto-
gerenciáveis onde lideranças informais surgem e finalizam o tempo todo de acordo com o
assunto tratado ou a tarefa realizada. Essas gerências formais que poderiam ir se tornando
cada vez mais uma assessoria ou consultoria serviriam apenas para manter nas pessoas e nos
líderes informais as várias visões que são importantes para a organização. Manter o
desenvolvimento das técnicas funcionais, manter e reavaliar o planejamento, desenvolver os
valores e princípios e buscar sempre os maiores benefícios para o cliente.
7.4 Visão sistêmica e benefícios para os clientes
Como já foi visto, Peter Senge define as cinco disciplinas das empresas que aprendem:
domínio pessoal, modelos mentais, visão compartilhada, aprendizagem em equipe, visão
sistêmica.
42
Na forma de organização sugerida, as pessoas possuiriam competências em várias
disciplinas, inclusive também poderiam ter algum conhecimento do negócio do cliente. A
sobreposição de competências de várias pessoas em uma mesma disciplina faria com que se
tivessem vários modelos mentais para a mesma disciplina, ou seja, faria com que a equipe
tivesse capacidade de enxergar o trabalho sobre perspectivas diferentes. A sobreposição de
algumas competências ajudaria também a fazer a comunicação das partes não sobrepostas
possibilitando uma aprendizagem da equipe para buscar a visão do todo e facilitar a
construção de uma visão compartilhada de longo prazo.
Formando essa visão sistêmica, as decisões do negócio do cliente passariam a ser
compartilhadas com a equipe de desenvolvimento, somando-se a experiência e a capacidade
de enxergar o negócio de forma completa do cliente com a capacidade de abstrair e de
estruturar conceitos da equipe de desenvolvimento.
Portanto, essa formação também contribuiria para o desenvolvimento pessoal das
pessoas fazendo com se sentissem fazendo algo mais importante e buscando sua auto-
realização. A equipe poderia se sentir realmente participante do negócio da empresa ao invés
de se sentirem simplesmente como uma estrutura de apoio.
Assim, as demandas poderiam ser priorizadas de forma conjunta e seriam mais
assertivas evitando o desenvolvimento de produtos ou funcionalidades que seriam descartadas
por não trazer benefício algum para o negócio.
Essa eficácia de fazer a coisa certa seria um dos fatores que mais poderiam contribuir
para melhorar o desempenho da área de desenvolvimento de sistemas. Muitos esforços
poderiam ser evitados através da visão sistêmica e compartilhada. Idéias no negócio poderiam
surgir evitando que sistemas inteiros fossem construídos ou que fossem pelo menos
simplificados.
7.5 Comunicação
A maior parte do tempo do trabalho de um gerente de projeto é gasto com
comunicação. (PMI, 2008). Alguns estudiosos chegam a falar em 90% do tempo.
O gerente de projeto deve considerar o número de potenciais canais de comunicações
como um indicador de complexidade das comunicações do projeto. O número de potenciais
43
canais de comunicação é dados por n(n-1)/2 onde n representam número de “stakeholders”
(interessados no projeto). (PMI, 2008).
Figura 4: Canais de Comunicação.
Fonte: Elaborada pelo autor.
Com a proposta de uma equipe multidisciplinar, tende-se a ter equipes menores e mais
dedicadas em tempo integral ao projeto. Em modelos com desenvolvedores mais
especialistas, é mais provável que, para não ficarem ociosos, eles acabem trabalhando em
mais de um projeto. Sendo assim, a forma mais vertical de se trabalhar, com desenvolvedores
mais generalistas fazendo vários papéis, diminuiria os canais de comunicação e, portanto a
complexidade das comunicações do projeto. E se a complexidade diminuísse, o tempo
necessário de gerência de projeto também ficaria reduzido. Talvez esse seja um dos motivos
que possibilitem as equipes a serem mais auto-gerenciáveis, princípio das metodologias ágeis.
Além disso, um outro conceito das metodologias ágeis, o de se reduzir a
documentação ao que seja realmente necessário, também pode ser facilitado com esse tipo de
equipe. Não seria necessário documentar simplesmente para fazer a comunicação de uma
disciplina para outra, porque na outra disciplina iriam estar as mesmas pessoas. Assim a
documentação poderia ficar mais focada no entendimento do problema e na manutenção do
sistema. Em muitos processos “cascata” e com pessoas alocadas somente em uma das
disciplinas, tem-se notado que uma enorme parte da documentação tem esse objetivo e
mesmo assim o entendimento é falho como numa brincadeira de “telefone sem fio”. Para
tentar resolver esse problema, tem-se visto que cada vez mais esforços são investidos nessas
documentações para melhorar o entendimento tornando-as ainda cada vez maiores.
44
7.6 Adequação a processos iterativos
O desenvolvimento iterativo é uma abordagem para a construção de software, na qual
o ciclo de vida total do projeto é composto por várias iterações em seqüência. Cada iteração é
um mini-projeto auto-suficiente composto por atividades como análise de requisitos, design,
programação e teste. A meta para o final de uma iteração é um lançamento de uma versão
parcial, estável, testada e integrada do sistema completo. (Larman, 2004).
Pode-se dizer também, que esse processo é bem parecido com o ciclo PDCA, plan
(planejar), do (fazer), check (avaliar), act (atuar) idealizado por Shewhart e divulgado por
Deming. Ambos visam ter um “feedback”, uma avaliação, para poder atuar na próxima
iteração ou no próximo ciclo.
Com uma equipe de desenvolvedores que atuam em todas as disciplinas, poder-se-ia
alocar para todos eles atividades das diferentes disciplinas. Eles poderiam dividir e separar
algum tipo de trabalho, mas em raros momentos se teria alguém ocioso já que eles poderiam
colaborar com qualquer tipo de trabalho que precisasse ser feito (figura 5).
Figura 5: Generalistas. Mesmos recursos nas atividades.
Fonte: Elaborada pelo autor.
Já se a equipe fosse formada por desenvolvedores alocados exclusivamente para cada
disciplina, ter-se-ia uma dificuldade maior para não deixá-los ociosos, já que alguns trabalhos
de algumas disciplinas dependeriam dos trabalhos realizados em disciplinas anteriores (figura
6). Também, não se poderia adiantar um trabalho de uma iteração seguinte, porque a iteração
seguinte dependeria de um “feedback” (retorno) do produto que seria gerado na iteração atual.
45
Além disso, uma iteração possui a característica de ser “time box”, o que significa que são
caixas de tempo que não podem ser sobrepostas no tempo (figura 7). Outra solução seria a
alocação dessas pessoas em vários projetos, o que, provavelmente, faria com que eles
perdessem totalmente a percepção do todo e do significado de cada projeto, e ainda,
complicaria muito o gerenciamento dos recursos já que a atividade de um projeto poderia
atrasar causando impacto em outro projeto (figura 8).
Figura 6: Iterativo. Ociosidade.
Fonte: Elaborada pelo autor.
Figura 7: Adiantar nova iteração. Não “Time Box”
. Fonte: Elaborada pelo autor.
46
Figura 8: Vários projetos. Gerenciamento complexo.
Fonte: Elaborada pelo autor.
7.7 Padronização e melhoria contínua das atividades
Como já foi visto, através de Adam Smith e Taylor, a especialização da tarefa pode
trazer alguns benefícios para a execução do trabalho. O simples fato de enxergar as atividades
de forma dividida já propicia um aumento de produtividade através de mecanismos de
avaliação e de melhoria de cada atividade. Viu-se também que a engenharia de software tem
trabalhado nesse sentido para descobrir os melhores métodos, técnicas e ferramentas que
podem ser empregados em cada uma das atividades de acordo com a necessidade do software
que está sendo construído.
Foi visto também que a especialização das pessoas no trabalho aumenta sua habilidade
na execução da tarefa. Entretanto, excessos da especialização trazem alguns problemas sociais
e motivacionais, além da falta de visão sistêmica e da falta de visão das conseqüências da
realização das tarefas.
É possível observar algumas organizações especializando ao máximo as atividades das
pessoas com o objetivo de tornar as pessoas mais rápidas na execução da tarefa, e também, de
padronizar as tarefas para torná-las mais independente das pessoas.
Apesar do conceito “Fábrica de Software” ter sido criado mais como uma forma de
padronizar boas práticas de desenvolvimento e reutilizar componentes, algumas organizações
têm criado fábricas de softwares como forma de especializar o trabalho das pessoas e
seqüenciá-lo através de um conceito de linha de produção onde cada disciplina aparece como
um setor específico dessa linha de produção recebendo artefatos da disciplina anterior e
47
enviando artefatos resultantes para a disciplina seguinte. Assim como Taylor pregava,
normalmente as pessoas dessas fábricas são obrigadas a fazer as atividades da forma descrita
por seus gerentes. Entretanto, isso acaba sendo contraditório com outra proposta do próprio
Taylor, a de melhorar os processos continuamente através da melhor percepção que as
pessoas teriam de suas atividades. Na prática, a melhoria do processo acaba sendo feita
somente pela visão e medições feitas pelo gerente quase sem nenhuma participação das outras
pessoas, e com o tempo, o processo acaba se estagnando.
Através desse autoritarismo imposto pelos gerentes ou pelos donos dos processos,
consegue-se fazer a empresa chegar a uma boa padronização e consequentemente conseguir
certificar-se em alguns níveis do CMMI ou do MPS-BR. Ou seja, a empresa consegue fazer
software de forma padronizada. Entretanto, as certificações não necessariamente significam
que os softwares atendem as necessidades esperadas pelo cliente e se realmente o
desenvolvimento foi feito de forma produtiva. Poderia significar que até erros cometidos
estariam agora padronizados.
O autoritarismo e a especialização das pessoas parece realmente ser a forma mais
rápida de atingir essa padronização tanto desejada pelas empresas. Com isso a empresa
poderia chegar mais facilmente até a certificação do nível 3. Mas a partir do nível 4, a
participação das pessoas começaria a ser mais necessária, e se a empresa continuasse nesse
modelo, poderia até se certificar, mas talvez tendo um falso benefício. Há indicações que
tanto as medições quanto as melhorias contínuas do processo precisam da participação efetiva
das pessoas e da visão sistêmica para realmente direcionar os processos a trazer benefícios
reais. Para medir e melhorar os processos seria essencial uma maturidade maior das pessoas,
por isso esses dois conceitos aparecem nos últimos níveis dos modelos de maturidade.
Com a forma de organização sugerida de equipes multidisciplinares poderia-se
demorar mais a se chegar numa padronização e reutilização de técnicas e métodos, mas é
provável que se chegasse de forma mais consistente. Pelo que foi visto por Senge, a visão
sistêmica compartilhada pela equipe e inclusive a visão do próprio cliente fariam com que
apenas métodos e técnicas realmente necessários fossem utilizados e que benefícios para o
usuário fossem realmente alcançados. Já o compartilhamento de métodos, técnicas e
ferramentas poderiam ser conseguidos utilizando-se a estrutura de gerência funcional
compartilhada pelas equipes. Essa gerência de apoio poderia observar as práticas utilizadas
pelas equipes, bem como novas práticas do mercado e divulgá-las em todo o grupo fazendo a
gestão do conhecimento técnico.
48
Quanto à padronização, essa não seria atingida na sua plenitude porque seria
prejudicial. A padronização poderia levar as equipes a utilizarem práticas desnecessárias para
seus projetos. A padronização que deveria existir é a reutilização de soluções para o mesmo
problema até que uma forma melhor seja encontrada por alguma equipe, nos mesmos moldes
que os padrões de projeto (design patterns) padronizam soluções para problemas de projeto.
A padronização do processo deveria se dar apenas no nível de valores e princípios
como proposto pelas novas abordagens utilizadas pelos processos ágeis. Isso criaria uma
visão compartilhada entre os desenvolvedores e direcionaria suas decisões dentro dos
projetos.
Dessa forma poderia se ter uma verdadeira gestão do conhecimento, reutilização de
padrões e de boas práticas e uma constante melhoria das atividades gerando realmente
benefícios para a equipe e para o cliente. Independente da certificação que se tenha, esse
talvez fosse o verdadeiro nível 5 de maturidade do CMMI. Princípios e valores
institucionalizados; melhores práticas sendo seguidas e compartilhadas; e a melhoria contínua
do trabalho sendo realizada conseguida através da maturidade das pessoas.
49
8 CONCLUSÃO
Primeiramente, pode-se concluir que vale a pena um estudo científico mais profundo
para se entender melhor as conseqüências e influências da divisão do trabalho nos resultados
da organização.
Demonstrou-se que essa divisão pode influenciar bastante em fatores como
produtividade, satisfação e geração de benefícios para os clientes finais.
Verificou-se também como algumas teorias administrativas teriam sido aplicadas na
evolução da engenharia de software e que novas preocupações como a visão sistêmica e
relacionamento das pessoas ter-se-iam juntado aos interesses que já existiam com a melhoria
das atividades.
O estudo ainda propõe e justifica uma forma de estruturação que poderia ser utilizada
para atingir os aspectos identificados como importantes para os resultados da organização.
Por fim, espera-se que as empresas possam observar de forma mais holística e
sistêmica os aspectos identificados e analisados nesse estudo antes de decidirem a forma de
estruturação e organização do trabalho que irão adotar em seus setores de desenvolvimento de
software.
50
REFERÊNCIAS BIBLIOGRÁFICAS
BECK Kent et al. Manifesto Ágil em português. Disponível em: http://www.manifestoagil.com.br, Outubro/2012. CHIAVENATO, Idalberto. Introdução a teoria geral da administração. 7ª Ed. Rio de Janeiro: Elsevier, 2003. CMMI. Disponível em: http://www.sei.cmu.edu/cmmi/ , Outubro /2012. FAYOL, Henry. Administração industrial e geral. Tradução: Irene de Bojano e Mário de Souza. São Paulo: Atlas, 1989. KRUCHTEN, Philippe. The rational unified process: an introduction. Addison Wesley, 2000. LARMAN, Craig. Agile and iterative development: a manager's guide. Boston: Pearson Education, 2004. MASLOW, Abraham H.. Maslow no Gerenciamento. Tradução de Eliana Casquilho. Rio de Janeiro: Qualitymark, 2001 MPS-BR. Disponível em: http://www.softex.br/mpsbr/ , Outubro /2012. PRESSMAN, Roger S.. Engenharia de Software. Porto Alegre: AMGH, 2011. PMI, A guide to the Project Management Body of Knowledge: PMBOK . Pennsylvania, USA: 2008 RATIONAL Software Corporation. Rational Unified Process®. 2001. SCHWABER Ken; SUTHERLAND Jeff. Guia do Scrum. Tradução de Fábio Cruz. Disponível em http://www.scrum.org/ScrumGuide.aspx, Outubro, 2011. SENGE, Peter M.. A Quinta Disciplina. Tradução: Gabriel Zide Neto. Rio de Janeiro: BestSeller, 2010 SMITH, Adam. A riqueza das nações. Tradução: Luís João Baraúna. São Paulo: Círculo do Livro, 1996. SOMMERVILLE, Ian. Engenharia de Software. Tradução de Selma Shin Shimizu Meinnikoff e Reginaldo Arakaki. São Paulo: Pearson Addison-Wesley, 2007. TAYLOR, F. W.. Princípios de administração científica. Tradução: Arlindo Vieira Ramos. São Paulo: Atlas, 1971.