Você está na página 1de 17

Um estudo empírico sobre a utilidade do Formal Rotinas

a transferência de conhecimentos e experiência


A maioria dos Framework de software de qualidade e melhoria de
processos
enfatizar escrita (ou seja formal) a documentação para transmitir
Recomenda práticas de trabalho. No entanto, existe considerável
cepticismo entre os desenvolvedores a aprender e respeitar
modelos de processos prescritos. Os últimos são muitas vezes vistos
como excessivamente Estruturado "ou implicitamente demais" controle
". Além disso, o que é conhecimento relevante tem sido muitas vezes
decidido por "outros" - muitas vezes o gerente de qualidade.
O estudo foi realizado no contexto de um estudo nacional software
Empírico sobre a utilidade de Rotinas Formal a transferência de
conhecimentos e experiência programa de processo de melhoria na
Noruega para as pequenas e médias empresas, empresas para avaliar a
atitude em relação ao conhecimento formalizado e fontes de
experiência. Os resultados mostram que os desenvolvedores estão
bastante céptico em usar rotinas de escrita, enquanto a qualidade e
a gerentes técnicos estão tomando esta para concedido. Esta é uma
combinação explosiva. A conclusão é que as rotinas formais devem ser
completadas por colaborativo, processos sociais para promover a
divulgação eficaz e aprendizagem organizacional. Tentar forçar um
(bem-intencionados) ·sistema de qualidade goela abaixo dos
desenvolvedores é fútil e
desmoralizante. As amplas implicações para a qualidade e ·trabalhos
de melhoramento são que temos de encontrar um equilíbrio entre a
"Disciplinada" ou "racional" e "criativa" caminho do programa de
melhoramento working. process na Noruega para as pequenas e médias
empresas, empresas para avaliar a atitude em relação ao conhecimento
formalizado e fontes de experiência. Os resultados mostram que os
desenvolvedores estão
bastante céptico em usar rotinas de escrita, enquanto a qualidade e
a gerentes técnicos estão tomando esta para concedido. Esta é uma
combinação explosiva.
Palavras-chave
Software de melhoria de processos, transferência de conhecimento,
conhecimento
gestão, rotinas formais, as atitudes do desenvolvedor.

1. INTRODUÇÃO
Para regulamentar e melhorar o trabalho no desenvolvimento de
software, muitas
organizações e projectos têm documentado o seu trabalho melhor
"
práticas ", como rotinas formais. Estes podem ser prescritos
processo
modelos, directrizes, regras, listas de verificação, etc.
Por outro lado, não podemos esperar que a adesão às rotinas formais
( "A conformidade do processo") a menos que as rotinas sejam
entendidas,
respeitado e demonstrou ser útil na prática diária. Podemos
mencionar dois extremos: jovens programadores são famosos por sua
improvisação e de desprezo pelas leis escritas e regulamentos (o
"Modo de trabalho criativo"). Por outro lado, temos os militares
sistema de comando onde as regras e comandos devem ser obedecidos
ao pé da letra (o "disciplina" modo de trabalho).
O estudo descrito foi realizado no contexto
de um norueguês software do programa de melhoria de processos, SpiQ,
envolvendo uma dezena de pequenas e médias empresas de software
intensivo. Muitos dos estas empresas têm instalado seus próprios
sistemas da qualidade e / ou bases de experiência, mas nem todos
estes foram totalmente explorados pelo desenvolvedores.
Assim, era natural para investigar como os diferentes grupos de
usuários, tais como desenvolvedores e gerentes, percebida como uma
rotina formal meio para expressar e divulgar o conhecimento e
experiência.
A estrutura do resto do documento é a seguinte: Secção 2 apresenta
uma síntese dos trabalhos relacionados. A Secção 3 explica as
questões e
hipóteses levantadas e o método de investigação para explorar estas.

A secção 4 apresenta os resultados, Secção 5 discute esses e


Secção 6 contém uma conclusão.
2. RELACIONADOS work1
Esta secção resume os trabalhos relacionados em um nível mais geral.
A discussão na secção 5 contém alguns mais específicos referências a
trabalhos relacionados.
A ênfase em rotinas formais reflecte uma suposição comum em
melhoria do processo de software (SPI) e garantia de qualidade (QA),

que "a qualidade de um produto de software é fortemente regulado


pelo
qualidade do processo utilizado para desenvolver e mantê-lo "[30],
p.8.
Isso geralmente significa que as práticas de trabalho em causa (os
processos) devem ser
sistematicamente documentados como rotinas formais, muitas vezes
como padrão
modelos de processo. Estas rotinas devem ser comunicadas à
desenvolvedores, personalizado e aprovado por eles e posteriormente
revisto
baseada na experiência e estratégias globais. Muitas empresas têm
estabelecido sofisticados sistemas de qualidade, a codificação de
tais rotinas.
Esse sistema de qualidade pode ser acoplado a uma experiência de
software
base (SEB), contendo tanto os dados experimentais e agregados
modelos (ou seja, "conhecimento") com base em tais dados.
1 SINTEF é a Fundação de Pesquisa Científica e Industrial
Pesquisa do Instituto Norueguês de Tecnologia. Com o advento da
Internet e das tecnologias da Web, muitas qualidade
sistemas e bases de experiência estão usando agora, como eletrônicos

mídia. Devemos, no entanto, ressaltar que as ferramentas


tecnológicas
remédios são apenas um meio para atingir uma meta. Em toda a
qualidade e
trabalhos de melhoramento, o critério de sucesso final está
satisfeito
clientes no espírito da Total Quality Management (TQM) [15]
ou ISO-9001 [28].
Algumas definições: No contexto deste estudo, definimos
formalização de regras escritas, procedimentos e instruções.
O conhecimento explícito é o conhecimento formalizado, por exemplo,
como processo
modelos ou orientações. O conhecimento tácito é a capacidade
operacional
que os praticantes possuem, incluindo o julgamento prático
capacidades (intuição, por exemplo) [27]. O conhecimento tácito não
pode sempre ser explicitado. Aprender é duradoura modificação no
comportamento, com base na experiência e compreensão, e exige tanto
formais formação e intercâmbio de informações informal. Muitas
teorias de aprendizagem existem, por exemplo, ver [5] [35]. Para
transferência de experiências, uma modelo útil é desenvolvido por
Nonaka e Takeuchi [27]: Exteriorização Internalização Combinação
Para Figura 1. Um modelo de conversão do conhecimento entre tácito e

conhecimento explícito [27].


Figura 1 expressa que os médicos primeiro internalizar novos
conhecimento (ou seja, a aprendizagem individual). O novo
conhecimento são então socializados para os processos de trabalho
revisto e alterado o comportamento
(aprendizagem em grupo). Os novos processos de trabalho e as mudou
comportamento são, então, observada e captada, ou seja
exteriorizada. Estes novos conhecimentos são então combinadas para
aperfeiçoar e alargar o actual
conhecimento (aprendizagem organizacional). Esse processo continua
em novos ciclos etc
Para permitir que a aprendizagem é a questão crucial, tanto a nível
individual, grupo e, em nível organizacional. A última significa a
criação e manter uma organização de aprendizagem que melhora
constantemente os seus
trabalho, deixando os funcionários de partilhar experiências com os
outros.
Em torno das bases experiência subjacente, que pode ser especial
(sub-) as organizações a gerência e divulgar os armazenados
experiência e conhecimento, como exemplificado pela experiência de
Fábrica [7]. Eles também referem-se à série de oficinas de
aprendizagem Organizações de software [4] [9].
Outros campos que introduziu o termo organizacional ou corporativa
memória para caracterizar activos estratégicos de uma organização,
embora não só do ponto de vista da aprendizagem [1].
A comunidade de engenharia de conhecimento também trabalhou em
bases de experiência, muitas vezes com ênfase no conhecimento
efectivo
representações, a dedução etc. Técnicas, e para uma ampla gama de
aplicações. O ramo da Case-Based Reasoning [3] surgiu a partir deste
trabalho, permitindo a reutilização do semelhante, do passado
informação ( "casos") para melhor dominar novas situações. Nós
também mencionar o ramo da mineração de dados [20].
Antropólogos e psicólogos têm estudado como
organizações "aprender", e como os seus empregados fazem uso de
fontes de informação em seu trabalho diário. Muito esforço de I & D
sido gasto na "externalização''fluxo, procurando válido
experiência que pode ser analisado, generalizada, sintetizada,
embalados e divulgados sob a forma de modelos melhorados ou
conceitos. Por exemplo, para fazer, calibrar e melhorar uma
modelo de estimativa baseada no desempenho do software anterior
projectos. O conhecimento explícito pode, contudo, ser mal
interpretada devido à falta de contexto e nuances, por exemplo, como
entender a contexto do pós-mortem? No entanto, a parte mais difícil
é a "interiorização''fluxo. Isto é, como
fazer um impacto na prática actual, mesmo se actualizado
conhecimento pode ser convincente disponíveis? Ver, por exemplo, a
etnografia estudo sobre o uso de sistemas de qualidade em [40].
Inibidores típicos são "Não inventado aqui'', desconfiança (" sido
queimado antes''), a falta de tempo extra / recursos (e não "Getting
Started"), ou simples falta de vontade tentar algo novo ou diferente
(como aderir ao formal procedimentos em um sistema de qualidade). Um
estudo de manutenção técnica para copiadoras indicou que esses
peritos foram mais prováveis para pedir aos seus colegas de
conselho, ao invés de olhar para ele ou até mesmo para seguir o
"livro" [10]. Na verdade, quantas vezes os cientistas não têm
computador perguntado sobre seus companheiros de escritório
comandos no Word ou Windows NT, em vez de directamente consultar
documentação relevante - apesar de uma "consulta" para a
Este último pode ser difícil de formular.
Além disso, a existência de manuais de qualidade de software, quer
em papel em classificadores de espessura (por vezes, 1-2 m nas
prateleiras) ou na web documentos de uma intranet, não é garantia
para a sua utilização. Na verdade, desde manuais podem ditar as
pessoas sobre como realizar seu trabalho, serviços tradicionais de
qualidade nas organizações de software estão não olhado com grande
estima pelos desenvolvedores. Por exemplo, Existem mais de 250
padrões de software proposto [32], muitos dos recomendando-lhes
"padrão" modelos de processo, mas como muitos dos estes estão em uso
prático?
Assim, se quisermos ter sucesso com as rotinas formal e explícito
conhecimento em um sistema de qualidade ou uma SEB para atingir a
aprendizagem, que
não deve levar o chapéu QA tradicional "de controle. Isso não
significa que todo o conhecimento formal, sob a forma de livros,
relatórios, etc
(como neste artigo) tem que ser descartado. A lição é que apenas
formal
rotinas devem ser formuladas e introduzidas com a devida
participação das pessoas envolvidas, a fim de ter o
efeito pretendido em prática.
Por último, muitas das ideias e técnicas de melhoria da qualidade
(TQM e similares) vêm de fabricação, com bastante estável
produtos, processos e organizações. Tecnologia da informação, em
Por outro lado, é caracterizada pela inovação de produtos rápido,
não processo gradual de refinamento [33]. Um "ano de TI" é como um
cão " anos (7 anos) em outras disciplinas, e time-to-market parece
sagrado (ou seja, pressão calendário). A força de muitos softwares
PME (Pequenas e Médias Empresas) reside na sua própria capacidade de
virar-se rápido e reconversão das tecnologias da próxima semana
radicalmente em novos produtos e serviços. Barrett [6], foi
utilizado a improvisação prazo, uma metáfora do jazz, para
caracterizar performers que executam actividades em desenvolvimento,
enquanto empregam um grande

base de competência. Com referência ao nosso desenvolvimento de


software
contexto, é preciso cuidado adoptar um conjunto de qualidade e
melhoria
tecnologias que podem funcionar em um ambiente muito dinâmico -
assim
Como gerir a mudança constante [17]? Desde SPI assume que
há "algo" estável que pode ser "melhorado", temos de escolher
nosso foco de aprendizagem em conformidade. Por exemplo, o norueguês

Computer Society (www.dnd.no) está oferecendo um curso de


"Caos e da teoria da complexidade", como uma alternativa de gestão
altamente
evolução dos projectos.
No entanto, é justo dizer que, especialmente TQM está ciente da
dimensões cultural e social do trabalho de qualidade. TQM tem uma
forte
ênfase na criação de uma organização que aprende, e com todas
empregados participar e envolver-se em fim de satisfazer
seus clientes.
Então, como podem as organizações melhor software de sistematizar,
organizar e
explorar a experiência anterior, a fim de melhorar o seu trabalho?
3. CONTEXTO, perguntas e
MÉTODO
3.1 O Projeto SpiQ
O projeto SpiQ [12] foi executado por três anos, em 1997-99, após
uma
meia-pré-estudo no ano de 1996. SpiQ representa SPI para melhor
Qualidade. O projeto, que foi financiado em parte pela investigação
Conselho da Noruega, envolveu três instituições de pesquisa e 12 de
TI
empresas, sobretudo as PME. Mais de 20 projectos-piloto foram SPI
executar nessas empresas. Um projecto de acompanhamento é chamado de
lucro
Agora, realizado em 2000-2002.
O principal resultado do projecto SpiQ era um método pragmático
manual [16], com os seguintes componentes:
� Uma abordagem, a dupla top-down/bottom-up, usando TQM [15] e
Melhoria da QualidadeIdéias Paradigm [7].
� Um processo adaptado para ESSI-type [19] Melhoria de Processos
Experimentos (EIP).
� O Goal-Question-Metric (GQM) método [8], por exemplo, GQM
sessões de feedback.
� O conceito de Fábrica de Experiência [7], para aperfeiçoar e
difundir
experiências do projecto.
� Uma abordagem incremental, com base em pesquisa acção [22].
� Reported estudos empíricos de cinco "SpiQ" as empresas.
Trabalho típicos nos 12 empresas SpiQ incluídos projectos-piloto
para testar uma tecnologia certa melhoria, como a inspecção novela
técnicas, desenvolvimento incremental, ou a utilização de medição e
experiência bases de software.
Para obter mais resultados de estudos comparativos de sucesso no SPI

SpiQ empresas e em vários outros EIP escandinavos, todos os


enfatizando os factores culturais e organizacionais ver, por exemplo
[13], [14], [18], e [37].

3.2 Como o estudo foi realizado Organização geral: O presente estudo


foi realizado entre NTNU / SINTEF e cinco empresas participantes do
SpiQ projecto. A colecta de dados foi realizada por dois estudantes
em NTNU o último ano de seu mestrado estudo, como parte de um "pré-
tese" do projecto [11]. Os dois estudantes foram aconselhados pelos
dois autores do presente papel, sendo o primeiro o seu professor e
também pesquisador SpiQ, sendo este último um pesquisador e
doutorado estudantes inscritos para o SpiQ projecto.
Preparação: Em primeiro lugar, o aluno ler e aprender sobre o
projecto e da literatura pertinente. Então, nós tentamos uma
formulação inicial de algumas questões importantes sob a forma de
questões de investigação, e discutidos estes. Ao mesmo tempo,
entramos em contacto com potenciais empresas e verificada a sua
vontade de participar e sua disponibilidade. Em seguida, um guia de
entrevista mais detalhada (ver 3.3) foi ·concebido, no diálogo entre
os alunos e seus assessores. O empresas tinham sido informados sobre
as perguntas, e quando e como as entrevistas estavam indo para ser
executado.
Questões de pesquisa - questões importantes a tratar são:
Q1: Qual é o conhecimento das rotinas que estão sendo utilizados?
Q2: Como são essas rotinas estão sendo usados?
Q3: Como são actualizadas?
Q4: Como eles são eficazes como meio de transferência de
conhecimento e experiência?
E, além disso, existem diferenças importantes entre
desenvolvedores e gerentes, e quanto a cooperação está envolvida
na elaboração e actualização das rotinas?
Temas: Inicialmente, tentamos ter uma dezena de empresas envolvidas,

mas o prazo de disponibilidade dos alunos (três meses em


Primavera de 1999) permitiu apenas cinco empresas. Uma delas foi em
Trondheim, o resto em Oslo. Três das empresas foram ISO -
9001. Duas das empresas foram IT / empresas de telecomunicações,
o resto eram casas de software. Uma amostra de conveniência (ou
seja,
voluntários disponíveis) de 23 pessoas foram entrevistadas com base
em sua experiência com a SPI, dos quais 13 promotores e 10
gestores. O último grupo inclui um gerente de qualidade e um
gerente de software (por exemplo, divisão ou gerente de projecto) de
cada uma das cinco empresas.
Colecta de dados: Depois de terminar o guia de entrevista, esta foi
enviada por e-mail para os inquiridos. Poucos dias depois, os dois
alunos visitaram as empresas, e passou um dia inteiro em cada
empresa. Em cada lugar que passei até uma hora com cada entrevistado
em entrevistas semi-estruturadas. Em cada entrevista, as quatro
perguntas foram tratados uma após a outra. Um dos alunos foi pedir
às perguntas, e ambos os alunos fizeram registos de notas
(entrevista) durante a entrevista. O outro estudante serviu como um
escriba, e escreveu um resumo estruturado, imediatamente após a
entrevista. O primeiro aluno, em seguida, verificado este contra as
suas próprias notas.
Análise dos dados: A classificação e consequente análise dos dados
foram feitas pelos dois alunos, em cooperação com os autores, e
relatados no pré dos alunos tese de diploma.

3.3 O Guia de Entrevista


Como mencionado, que formulou quatro questões principais da
pesquisa,
com um total de 14 sub pergunta:

Q1. Conhecimento das rotinas.


1,1 Descrever os (possíveis) nas rotinas de conteúdo a ser utilizado
para
desenvolvimento de software.
1.2 Como foram essas rotinas introduziu na empresa?
1,3 Qual foi o objectivo destas rotinas?
1.4 O que é que você impressão pessoal das rotinas?

Q2. Utilização de rotinas.


2,1 Status que faz uma rotina entre os desenvolvedores tem dado?
2,2 Até que ponto são as rotinas de fato sendo usados?
2,3 Quem são os mais activos e usuários passivo?
2,4 Qual é a disponibilidade das rotinas?
2.5 Como é o acompanhamento e controle do uso feito?
Q3. Actualização das rotinas.
3,1 Que procedimentos são utilizados para actualizar a rotina?
3.2 Quem participa das actividades de actualização?
Q4. Rotinas como um meio para a transferência de conhecimentos e
experiência.
4,1 Você escrito em rotinas como um meio eficiente para
transferência de conhecimentos e experiência?
4,2 Que alternativas para rotinas escritas que você acha que são
úteis ou em uso na empresa?
4,3 Que entraves contra a transferência de experiências que você
acha
são mais importantes?
O roteiro de entrevista continha conselhos sobre como lidar com
questões estruturadas, geralmente com três categorias de resposta,
como
"Sim, talvez não" ou "pouco alguns, muito". Nós permitimos mais
comentários não estruturados em forma de prosa respostas para
solicitar
mais directa as opiniões e comentários.
4. RESULTADOS
Nesta secção, apresentamos os resultados de nosso estudo sobre a
·utilidade das rotinas formais como um meio de transferência de
conhecimento e experiência. O foco está na participação e potencial
diferenças de opinião entre os desenvolvedores e gerentes
respeito da utilidade das rotinas.
4.1 Conhecimentos das rotinas, todos os entrevistados tinham um bom
conhecimento das rotinas que
estavam no lugar em suas respectivas empresas. Na verdade, dois
terços dos
dos entrevistados mostraram um bom conhecimento sobre o conteúdo das
rotinas. A Tabela 1 ilustra isso, e mostra os quão bem os
desenvolvedores e os gerentes eram capazes de descrever o conteúdo
específico das rotinas em sua companhia.
No entanto, quando ele veio para o conhecimento sobre como as
rotinas foram introduzidos, 50% dos desenvolvedores não sabia de
nada sobre este processo. Por outro lado, apenas um gerente não
sabia sobre o processo de introdução. Tudo em tudo, descobriu-se que

cerca de 30% dos desenvolvedores e 70% dos gerentes havia


participou activamente da introdução de rotinas (Tabela 2). Além
disso, parecia ser um entendimento comum sobre o objectivo de ter
rotinas formais. A maioria dos entrevistados disse que tais rotinas
foram úteis no que diz respeito à garantia de qualidade.
Outros entrevistados disseram que iriam permitir uma forma mais
unificada de trabalho. No entanto, eles enfatizaram que:
" As rotinas não deve ser formal, mas muito úteis e
necessário ".
Inquiridos nos três ISO-9001 empresas certificadas alegou
que as suas rotinas foram em primeiro lugar, criado para "obter o
certificado na parede ", e que a qualidade de seu software
processos ganharam pouco ou nada a partir da certificação ISO.
Um dos entrevistados expressaram sua opinião sobre esse facto
através da
seguinte exemplo:
"Você pode ser certificada ISO para produzir lifebelts em concreto,
contanto que você colocar exatamente a mesma quantidade de concreto
em cada
salva-vidas. "
Embora alguns dos entrevistados eram críticos para as rotinas,
afirmando que:
"10% das rotinas são úteis, enquanto os restantes 90% é
absurdo "
A maioria dos entrevistados, no entanto, teve uma boa impressão da
rotinas, tipicamente afirmando que:
"As rotinas são um pré-requisito para a colaboração interna."
"As rotinas são uma reafirmação e de grande ajuda."

4.2 Utilização de Rotinas


Os desenvolvedores de software e gerentes concordaram com o grau em
que
as rotinas foram utilizadas. Em geral, eles responderam que cerca de
50%
das rotinas estavam em uso, e que os mais experientes
desenvolvedores utilizadas as rotinas, em menor medida do que a mais

desenvolvedores inexperientes fazer. Além disso, era um comum


acordo que:
"Não há nenhum ponto em ter rotinas que não são considerados
útil ".
No entanto, o status da rotina entre os desenvolvedores de software
foi altamente divergentes, como visto as seguintes declarações:

"As rotinas são geralmente boas e úteis, mas alguns


desenvolvedores estão frustrados quanto à sua utilização ".
"O sistema é burocrático - que era melhor antes, quando nós
tinham mais liberdade para decidir o que é melhor para nós mesmos
deve ser
feito ".
"As rotinas são fáceis de usar."
"As rotinas são desinteressantes e reuniões de revisão são
chato. "
4,3 Actualização de Rotinas
Nenhuma das empresas que tiveram as revisões programadas, como parte
do processo de actualização das suas rotinas. A maioria das
respostas a esta questão eram muito vagas. Alguns respondentes
explicaram que tais revisões foram informalmente acionado, enquanto
outros inquiridos não
Não sei como a propor e implementar mudanças para registro
rotinas.
No entanto, os inquiridos de todas as empresas, tanto os gestores
e desenvolvedores de software, disse que todos os funcionários em
suas
respectivas empresas pudessem participar nas actividades de revisão,
caso
eles queriam.
4,4 Rotinas como um meio para a transferência deConhecimento e
experiência ·As respostas a esta questão variaram muito, e altamente
indicado
atitudes diferentes sobre a eficácia das rotinas formais
para transferência de conhecimentos e experiência. Particularmente,
pareceu -
ser uma clara diferença de apreciação entre os desenvolvedores de
software
e gestores. Embora sete dos dez administradores considerados escrita

rotinas como um meio eficiente para a transferência de conhecimento,


nenhum dos
os desenvolvedores fizeram! Além disso, metade dos colaboradores
considerados
tais rotinas de ser ineficiente para a transferência de
conhecimentos, enquanto apenas um dos gestores de partilha da mesma
Opinião.
Normalmente, os gestores afirmaram que as rotinas escritas foram
importantes como meios para substituir o conhecimento das pessoas
que haviam deixado a companhia. Os desenvolvedores de software, por
outro lado, não fizeram tal ligação clara entre a experiência, a
transferência de conhecimentos e rotinas formais. Um desenvolvedor
de software, disse que o diferente grupo dentro da empresa, nunca li
uns dos outros relatórios, enquanto outro desenvolvedor afirmou que
levaria muito tempo para aprender sobre a experiência dos outros
grupos. Vários dos desenvolvedores explicou seu ponto de vista,
afirmando que a documentação não foi suficientemente boa, era
difícil de encontrar, chata utilização e que leva muito tempo.
Quando perguntado sobre alternativas úteis às rotinas escritas, o
inquiridos responderam que considerar algum tipo de
"A experiência de base" ou "newsgroups", como a melhor classificação

alternativas. Outros alto-espesso alternativas eram "socialização",


"Os grupos de discussão", "relatórios de experiência", as reuniões
do grupo ",
e "A formação em serviço". A Tabela 3 mostra estas alternativas em
ordem de classificação (1 é melhor) para desenvolvedores de software
e gerentes
respectivamente.
Pedimos também que os inquiridos sobre o que eles consideravam como
a mais importantes barreiras contra a transmissão de conhecimentos e

experiência. Quase todos eles disseram que essa transferência, acima


de tudo, era uma questão pessoal, dependendo dos desejos individuais
para ensinar suas lições aprendidas aos outros. Além disso, a
disposição de partes depende do tempo disponível, personalidade,
auto-interesse e cultura da empresa.
Tabela 3. Mídia alternativa para a transferência de conhecimento.
Rank
Média Developers Direcção
Base Experience / newsgroups 1 1
Socialização 2 3
Os grupos de discussão 3 2
Relatórios Experiência 4 3
On-the-job-training 5 6
Trabalhar com ext. Consultores de 6 --
Reuniões do Grupo 7 5
Como mostra a Tabela 4, sete (seis desenvolvedores e um gerente) do
Dos 23 entrevistados responderam a um definitivo "Não" à pergunta
sobre a eficiência das rotinas de escrita como um meio para
transferência de conhecimentos e experiências. Da mesma forma, sete
respondentes (gestores apenas) uma resposta igualmente clara: "Sim"
para
a mesma pergunta. Os últimos nove responderam em algum lugar
no meio, e disse que em alguns casos, poderia ser escrito rotinas
eficazes, enquanto em outras situações, eles preferem ser uma
barreira.
Tabela 4. Você considera rotinas escritas como um eficienteDevido ao
tamanho da amostra relativamente pequena neste estudo, e os baixos
freqüência esperada em várias das células na tabela 4,
comparadas as avaliações dos entrevistados das rotinas e seus
função de trabalho por meio do teste exato de Fisher. Com este
teste,
a probabilidade exata (ou nível de significância), que o resultado
obtido
é puramente um produto do acaso é calculada [23]. A estatística de
teste
de 13,02 foi altamente significativa (p = 0,002, bicaudal). Assim,
rejeitou a hipótese de independência e concluiu que não
é uma diferença na distribuição da avaliação da utilidade
de rotinas formal como um meio eficiente para a transferência de
conhecimentos e experiências entre desenvolvedores de software e
gestores.
Uma vez que os desenvolvedores de software tinha sido envolvido no
processo deestabelece as rotinas para uma extensão muito menor do
que o
gestores, nós comparamos a avaliação do entrevistado do
rotinas com o nível de envolvimento com o teste exato de Fisher
(Tabela 5). A estatística de teste de 14,71 foi altamente
significativa
(p <0,0005, bicaudal). Assim, concluímos que há uma
diferença na avaliação da utilidade de rotinas formais
como um meio eficiente para a transferência de conhecimentos e
experiências
no que diz respeito ao grau de envolvimento com a introdução
processo.
Tabela 5. Grau de envolvimento vs avaliação formal rotinas como um
meio eficiente para a transferência de conhecimentos e experiência.
Grau de participação
Meio eficiente? Baixa Alta Sim - 7Ambos 5 4
N º 7
5. DISCUSSÃO
Nesta secção, vamos restringir a discussão para possíveis
explicações
por que nenhum dos desenvolvedores de software em nosso estudo
considerar rotinas formais como um meio eficiente para a
transferência de conhecimentos e experiência. A razão para isso é
que nós consideramos formalização e participação como questões
importantes para a relevância de grande parte da SPI o trabalho
feito hoje pelos dois pesquisadores e profissionais.
Os inquiridos no estudo foram os engenheiros de software e
gestores com uma formação em engenharia. Além disso, o software
e gerentes de qualidade, com um fundo de engenharia escreveram mais
das rotinas. Assim, as rotinas foram em grande parte, escritas por
engenheiros - para engenheiros. Ainda assim, havia uma muito
significativa diferença de atitudes em relação à utilidade das
rotinas para transferência de conhecimentos e experiências entre
software engenheiros e gestores.
Como visto do nosso ponto de vista, há três razões principais para a
diversidade observada em relação à avaliação da eficiência
de rotinas. Um deles é o conflito potencial entre os profissionais
culturas de desenvolvedores de software e gerentes. A segunda razão
tem a ver com o grau de participação no desenvolvimento do
desenvolvedor e introduzindo as rotinas. A terceira explicação tem a
ver com os pontos de trabalho e de aprendizagem e, portanto, a
capacidade de escrita rotinas em geral, a transferência de
conhecimentos e da experiência humana.
Estas razões são discutidas em 5,1-5,3 abaixo.
5,1 Ocupacional Cultura
Houve um acordo geral entre todos os entrevistados que a
intenção de introduzir rotinas formais foi o de contribuir para uma
processo eficiente de desenvolvimento de software de qualidade. Em
outras palavras, a intenção por trás das rotinas formais foi o de
fornecer métodos e técnicas apropriadas e padronizar o trabalho
processos necessários para resolver os problemas na mão.
As diferenças que observamos em atitude para a eficiência das
Rotinas formais entre os desenvolvedores de software e gerentes tem
estreitam semelhança com a falta de alinhamento entre os executivos,

engenheiros e operadores descritos por Schein [34]. Ele explicou


estas diferenças a partir de uma perspectiva cultural, que define a
cultura como "Um conjunto de básicos pressupostos tácitos sobre como
o mundo é e deve de ser, que compartilham um grupo de pessoas e que
determina o seu percepções, pensamentos, sentimentos e, até certo
ponto, a sua evidente comportamento "(ibid., p. 11). Schein alegou
que os grandes profissionais comunidades realmente não entende os
outros, e que este leva a falhas na aprendizagem organizacional.
Segundo Schein, a cultura da engenharia e da cultura executivo tem
um comum preferência a ver as pessoas como recursos impessoal que
geram problemas do que soluções. Além disso, a necessidade de
engenheiros fazer "real engenharia" irá conduzi-los em direcção à
simplicidade erotinizadas soluções que muitas vezes ignoram as
realidades sociais do local de trabalho, ver o trabalho de Kunda
[24] e Thomas [38].
Neste contexto, podemos compreender mais facilmente a preferência de
rotinas formais dentro da comunidade como SPI adoptados pelos
gestores de qualidade ou de membros de Software Grupos de engenharia
de processo (SEPGs). Da mesma forma, os gestores bastante ênfase nas
regras, procedimentos e instruções que em diálogo, discussão e
participação dos trabalhadores.
Além disso, o desenvolvimento de software é radicalmente diferente
da fabricação. O primeiro não é um processo mecânico com
forte modelos causais, onde só precisamos estabelecer o "direito"
rotinas formais. Em vez disso, os desenvolvedores de software vista
desenvolvimento em grande parte como uma actividade intelectual e
social.
Portanto, não podemos aplicar um modelo racionalista linear para
engenharia de software. Devemos admitir que a realidade para a
maioria organizações de software é uma organização não
determinística, multi-direccional fluxo que envolve Isso não
significa que devemos descartar a disciplina e formalização
completamente. O que é necessário, é equilibrar as "impar
Casal "de disciplina e criatividade no desenvolvimento de software
[21].
Este equilíbrio pode ser desafiador, pois perder de vista criativo,
design natureza intensa de trabalho de software leva à rigidez
sufocante, enquanto perder de vista a necessidade de disciplina leva
ao caos.
Isso nos leva à segunda razão possível para a divergência
atitudes entre o promotor e os gerentes, o de empregado
participação em torno de rotinas formais a constante negociação e
renegociação entre e entre os grupos sociais, formação do software
[17].

5,2 Participação
A participação dos trabalhadores, e a forma como as pessoas são
tratadas, foi assinalada como um factor crucial na gestão
organizacional e desenvolvimento desde os estudos na famosa
produtividade Fábrica Western Electric's Hawthorne na década de
1920. Os resultados destes estudos começaram uma revolução no
pensamento de gestão, mostrando que mesmo os trabalhos de rotina
podem ser melhorados se os trabalhadores estão tratados com
respeito.
Curiosamente o nosso estudo mostra, que não só os gestores
participam significativamente mais durante a introdução de rotinas,
mas também durante o desenvolvimento real das rotinas. Contudo,
ninguém é mais perito na realidade de uma empresa de software
negócio do que os próprios programadores. Eles não são
apenas especialistas sobre como fazer o trabalho - são também os
especialistas em como melhorá-lo. Assim, os desenvolvedores estão um
software fonte mais importante organização de produtividade e os
lucros --
o "capital humano" de exibição. Por isso, é importante envolver
todos os as pessoas que participam de um problema ou sua solução, e
tem decisões tomadas por estes. A este respeito, todas as empresas
violado um dos aspectos mais importantes do empregado
envolvimento no seu próprio ambiente de trabalho. Eles podem até
ter "violado" a legislação ambiental norueguês trabalho!
--------------------------------------------------------------------
--------------------------------------------------------------------
Formalização é uma característica central do 39 [de Weber]
burocrático tipo ideal. Visto à luz dos nossos resultados, não é
surpreendente que a investigação sobre formalização apresenta
frequentemente em conflito empírica achados em relação à sua
eficiência. Adler e Borys [2] explicou esta divergência, dizendo que
as pesquisas anteriores se concentraram em diferentes graus de
formalização, e pagou insuficiente atenção aos diferentes tipos de
formalização. Eles enfatizam uma permitindo que tipo de
formalização, onde os procedimentos de prestação de memória
organizacional como um recurso para capturar lições aprendidas ou
melhores práticas. O oposto é o tipo de coerção de formalização,
onde os procedimentos são apresentados sem uma fundamentação
motivadora e portanto, tendem a ser desobedecido, resultando em um
processo não conformes.
Os resultados relativos à avaliação dos colaboradores das rotinas
assemelham ao tipo coercitivo de formalização. Os ·desenvolvedores
não estão claramente contra as rotinas formais. Na verdade, eles
tem pontos de vista expressos em favor de tais rotinas,
especialmente aqueles que experiência do projecto capturado antes.
Ao contrário do actual rotinas, que julgaram coercitiva, eles
queriam rotinas do permitindo que tipo de formalização. Assim, a
melhor classificação alternativas para as rotinas formais era uma
espécie de "base" experiência ou "newsgroups".

5,3 Trabalho e de aprendizagem outro aspecto de nossos resultados é


que apoiam Brown e Duguid [10] perspectiva sobre a aprendizagem em
trabalho. Isto é, nós devemos enfatizar o informal, em oposição à
aprendizagem formal. Os mesmos autores referem a estes modos de
aprendizagem, respectivamente, como Práticas "não canónico" e
"canónico". Eles sugeriram que formação e os processos de
socialização são susceptíveis de ser ineficaz se canónica baseada na
prática, em vez do mais realista não canonical prática:
"As pessoas são normalmente vistos como realizar seus trabalhos
de acordo com a descrição formal de trabalho, apesar do fato de que
diariamente as evidências apontam para o contrário. Eles são
mantidos responsável perante o mapa, e não às condições da estrada.
" (Ibid., p. 42)
Assim, as rotinas formais só são insuficientes, e poderia muito bem
exigir mais habilidades de improvisação entre os desenvolvedores.
Esta é por causa da rigidez das rotinas, e o fato de que eles fazem
não reflectir a experiência real [17]. Apesar de muitas rotinas são
prescritiva e simples, eles ainda são difíceis de mudar, e eles
não pode ajudar em todas as situações complexas da prática real de
que são abstractas.
Não é de surpreender, portanto, que a "socialização" e "discussão
Grupos "estão entre as alternativas mais bem posicionado para as
formais rotinas. Esta é também, de acordo com Brown e Duguid's
constatação de que "contar histórias" é de extrema importância para
o tratamento com as complexidades da prática do dia-a-dia. Além
disso, esses autores em destaque contar histórias como um meio de
diagnóstico problemas comuns e como repositórios de sabedoria
acumulada. Este é semelhante à 40 [Zuboff] ênfase em contar
histórias para lidar com "Inteligentes" de máquinas, bem como a
utilização Greenwood e Levin [22] de narrativas na pesquisa acção.
Assim, ao contrário da rigidez das rotinas formais, as histórias e
as actividades sociais tácitos são vistos como mais flexíveis,
adaptáveis e relevantes pelos desenvolvedores de software em nosso
estudo.
Além disso, nossos resultados suportam a afirmação de que a
significativa aprendizagem não deve ser dissociada do seu contexto
específico - Socalled aprendizagem situada. Portanto, as rotinas, as
generalizações ou outros meios que contexto de formam devem ser
examinadas com cautela. Na verdade, parece que a aprendizagem pode
ser considerada um produto de uma comunidade de aprendizagem
organizacional, em vez de o indivíduo nele. Assim, as lições
aprendidas não podem ser facilmente transferidos de um
estabelecimento para outro, consulte Lave e Wenger [25].

5,4 Implicações
Embora o estudo é limitado, a discussão acima sugere diversas
implicações. Primeiro, os estudos sobre os efeitos da formalização,
se eles estão permitindo ou coercitiva, deve incidir sobre os
características das rotinas de reais, bem como a sua implementação.
Além disso, devemos prestar atenção ao processo de concepção das
·características e os objectivos que regem este processo.
Em segundo lugar, devemos reconhecer e enfrentar as implicações
profundamente enraizadas e pressupostos tácitos dos diferentes
culturas profissionais. E, além disso, aprender a estabelecer
melhor diálogos interculturais, a fim de permitir organizacional
aprendizagem e SPI.
Em terceiro lugar, uma importante implicação prática é que os
gestores devem reconhecer as necessidades de equilibrar a disciplina
e criatividade, em Para completar as rotinas formais com a
colaboração, social processo. Apenas por uma apreciação profunda e
honesta do presente, pode gerentes esperam divulgação eficaz dos
conhecimentos e experiência dentro de sua organização.
Com base nas conclusões deste estudo, concluímos que ambos
gerentes e desenvolvedores de software devem manter um diálogo
aberto diálogo a respeito da utilidade de rotinas formais. Esse
diálogo será aberto o caminho para a base empírica de aprendizagem e
SPI, e, portanto, alcançar as recompensas de um tipo de habilitação
da formalização.

5,5 Limitações e recomendações para


Pesquisa Futura
Este estudo centrou-se na utilidade de rotinas formais de
transferência conhecimento e experiência. Embora possa fornecer
valiosas insights para a introdução de rotinas formais no software
indústria, nosso estudo não é sem limitações. Primeiro, a amostra
pequena e a ausência de aleatoriedade na escolha dos entrevistados
pode ser uma ameaça para a validade externa. Em geral, a maioria
trabalho em SPI sofre de não participação do representante, uma vez
que empresas que, voluntariamente, participar em melhoria
sistemática actividades deve ser assumido como sendo melhor do que a
média.
Em segundo lugar, uma grande ameaça à validade interna é que não
temos avaliou a fiabilidade de nossas medidas. Variáveis tais como
grau de envolvimento e de eficiência das rotinas são medidos em
escala ordinal subjectiva. Uma questão importante para futuros
estudos é portanto, para assegurar a fiabilidade e a validade de
todas as medidas utilizadas, veja [18]. Podemos também perguntar se
os entrevistados eram sinceros em suas respostas. Por exemplo, eles
podem ter percebido que estava "procurando problemas ", e assim"
dar-nos o que queríamos "- ou seja, exagerando possíveis problemas.
No entanto, as suas respostas às quatro principais suas perguntas e
comentários adicionados qualitativa mostram uma consistente
Imagem de cepticismo e à falta de participação relativa formal
rotinas. Decidimos, portanto, em geral, acreditam que as suas
respostas.
Apesar das limitações mencionadas e da falta de controlos cruzados,
nós sinto que este estudo faz uma contribuição importante para a
compreensão das rotinas formais e seu papel na organização
aprendizagem e SPI.
Estudos futuros devem analisar as características de habilitação das
formais rotinas com muito mais detalhe. Os recursos poderiam ser
refinado e operacionalizado e utilizado para corte transversal e
longitudinal estudos de um número muito maior de empresas. Além
disso, tais estudos devem incluir uma abordagem múltipla, requerido
para cobrir todas as principais culturas profissionais. Eles devem
também realizar complementar, os estudos etnográficos sobre como os
desenvolvedores realmente trabalho e como seus trabalhos se
relacionam com as rotinas formais - ver [31] sobre
Estudos de observação de desenvolvedores da ATT.

6. CONCLUSÃO
Os resultados da pesquisa relatada neste artigo mostram que o
software desenvolvedores não percebe rotinas formal por si só como
um eficiente forma de transferir conhecimento e experiência. Além
disso, o estudo confirma nossas suspeitas sobre as grandes
diferenças na percepção de o utilitário de rotinas formais de
transferência de experiências e conhecimento. Ou seja, os
desenvolvedores estão cépticos a adoptar rotinas formais encontrados
nos sistemas tradicionais de qualidade. Eles também querem que
tais rotinas sejam introduzidos e actualizados de uma forma mais
cooperativa.
Estes resultados não são revolucionárias, e em consonância com
muitas outras investigações sobre temas semelhantes [2], [24], [34].
Veja também Parnas e artigo de Clements [29] sobre a forma de uma
falsa concepção racional processo. Assim, apesar de uma pequena
amostra, pensamos que os resultados são representante de uma classe
de grandes empresas de software.
A solução parece estar a criar um trabalho mais aberto e cooperante
atmosfera, com forte participação do colaborador no projecto e
promoção de sistemas de qualidade no futuro. Os desenvolvedores
também parecem abrir para começar a explorar os novos meios
electrónicos como meio de colaboração e articulação com as
tecnologias mais recentes SEB - ver também nossos estudos anteriores
[13] sobre este assunto. No entanto, o maior e mais difícil trabalho
permanece não técnico, isto é, para construir uma aprendizagem
organização.
Por último, não fomos capazes de formular hipóteses precisas sobre
as nossas quatros questões com antecedência, de modo que o estudo
tem um carácter de uma preliminar investigação. Estudos posteriores
podem ser realizados com maior precisão hipóteses e em uma amostra
maior.

Você também pode gostar