Escolar Documentos
Profissional Documentos
Cultura Documentos
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.
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,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.
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.