Transcript
Page 1: 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

Page 2: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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

Page 3: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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.

Page 4: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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.

Page 5: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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.

Page 6: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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

Page 7: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

LISTA DE TABELAS

TABELA 1: Critérios observados ............................................................................................37

Page 8: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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

Page 9: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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,

Page 10: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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;

Page 11: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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

Page 12: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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.

Page 13: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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;

Page 14: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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.

Page 15: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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.

Page 16: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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

Page 17: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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)

Page 18: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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.

Page 19: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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.

Page 20: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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).

Page 21: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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.

Page 22: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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;

Page 23: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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

Page 24: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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.

Page 25: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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

Page 26: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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.

Page 27: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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.

Page 28: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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

Page 29: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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.

Page 30: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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).

Page 31: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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.

Page 32: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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,

Page 33: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO 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

Page 34: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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

Page 35: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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.

Page 36: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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.

Page 37: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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.

Page 38: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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

Page 39: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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

Page 40: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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

Page 41: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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.

Page 42: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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

Page 43: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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.

Page 44: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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.

Page 45: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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.

Page 46: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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

Page 47: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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.

Page 48: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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.

Page 49: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO DESENVOLVIMENTO DE SOFTWARE

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.

Page 50: DIVISÃO E ORGANIZAÇÃO DO TRABALHO NO 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.


Top Related