
As empresas podem ajudar seus desenvolvedores a maximizar a produtividade de várias maneiras, desde alterar o espaço do escritório até adquirir ferramentas melhores e limpar o código-fonte. Mas quais decisões terão maior impacto? Com base na literatura sobre desenvolvimento de software e psicologia industrial / organizacional, identificamos fatores relacionados à produtividade e entrevistamos 622 desenvolvedores de três empresas. Estávamos interessados nos fatores mencionados e em como as próprias pessoas avaliam sua produtividade. Nossos resultados sugerem que a auto-estima é mais influenciada por fatores não técnicos: entusiasmo no trabalho, o apoio de seus colegas para novas ideias e feedback útil sobre sua produtividade. Em comparação com outros trabalhadores do conhecimento,A avaliação de produtividade dos desenvolvedores de software depende mais da variedade de tarefas e da capacidade de trabalhar remotamente.
1. Introdução
Melhorar a produtividade do desenvolvedor é importante. Por definição, quando concluem suas tarefas, eles podem gastar o tempo livre em outras tarefas úteis: introdução de novos recursos e novas verificações. Mas o que ajuda os desenvolvedores a serem mais produtivos?
As empresas precisam de orientação prática sobre quais fatores manipular para maximizar a produtividade. Por exemplo, um desenvolvedor deve gastar tempo procurando ferramentas e abordagens melhores ou deve desligar as notificações durante o dia? Um líder deve investir em refatoração para reduzir a complexidade do código ou dar aos desenvolvedores mais autonomia? Os chefes deveriam investir em melhores ferramentas de desenvolvimento ou em um escritório mais confortável? Em um mundo ideal, investiríamos em vários fatores para aumentar a produtividade, mas o tempo e o dinheiro são limitados, então temos que escolher.
Este artigo é sobre o estudo mais amplo da previsão de produtividade do desenvolvedor de software até o momento. Conforme descrito na seção 3.1, a produtividade pode ser medida objetivamente (por exemplo, em linhas de código por mês) ou subjetivamente (conforme estimado pelo desenvolvedor). Embora nenhuma das abordagens seja preferida, tentamos cobrir o tópico amplamente com um julgamento subjetivo para responder a três perguntas:
- Quais fatores são os melhores preditores de como um desenvolvedor avaliará sua produtividade?
- Como esses fatores mudam de empresa para empresa?
- O que prevê a avaliação de um desenvolvedor de sua produtividade, em particular, em comparação com outros trabalhadores do conhecimento?
Para responder à primeira pergunta, conduzimos um estudo em uma grande empresa de software.
Para responder à segunda questão, que ajuda a entender em que medida os resultados obtidos podem ser generalizados, realizamos um estudo em duas empresas de setores distintos.
Para responder à terceira questão, que ajuda a entender como os desenvolvedores se diferenciam dos demais, realizamos um estudo entre representantes de outras profissões e comparamos com os resultados obtidos no estudo dos desenvolvedores.
Nossos resultados mostram que, nas empresas que estudamos, a autoestima por sua produtividade é fortemente influenciada pelo entusiasmo no trabalho, pelo apoio dos colegas para novas ideias e por feedback útil sobre sua produtividade. Em comparação com outros profissionais do conhecimento, a avaliação dos desenvolvedores de software sobre sua produtividade depende mais da variedade de tarefas e da capacidade de trabalhar remotamente. As empresas podem usar nossas descobertas para priorizar iniciativas relacionadas à produtividade (Seção 4.7).
A seção 2 descreve as empresas que estudamos. A seção 3 descreve a metodologia de pesquisa. A seção 4 descreve e analisa os resultados obtidos. A seção 5 descreve outros trabalhos neste tópico.

2. Empresas pesquisadas
2.1. Google
O Google possui cerca de 40 escritórios de desenvolvimento em todo o mundo, empregando dezenas de milhares de desenvolvedores. A empresa valoriza a colaboração estreita dentro das equipes, e os escritórios geralmente têm um plano aberto para aproximar os membros da equipe. A empresa é relativamente jovem (fundada no final dos anos 1990), sua estrutura organizacional é bastante plana e os desenvolvedores têm muita autonomia. O processo de promoção inclui feedback de colegas, e os desenvolvedores não precisam fazer a transição para posições gerenciais para avançar. Os próprios desenvolvedores planejam seu tempo, seus calendários são exibidos na rede corporativa. O Google usa processos de desenvolvimento ágil (como Agile), geralmente aplicados a toda a equipe.
O Google valoriza a abertura. A maioria dos desenvolvedores trabalha em uma base de código monolítica comum, o que incentiva fazer alterações no código de projetos de outras pessoas. A empresa tem uma forte cultura de teste e revisão de código: o código enviado ao repositório é revisado por outro desenvolvedor, geralmente por meio de testes. A maioria escreve código do lado do servidor que é lançado com freqüência e torna relativamente fácil implementar correções. O kit de ferramentas de desenvolvimento é amplamente unificado (excluindo editores) e construído internamente, incluindo ferramentas de análise e integração contínua e a infraestrutura para lançamento.
2.2. ABB
A ABB tem mais de 100.000 funcionários em todo o mundo. Como um conglomerado de engenharia, a empresa emprega uma ampla variedade de profissões. Existem cerca de 4.000 desenvolvedores de software comuns e mais de 10.000 desenvolvedores de aplicativos que constroem sistemas industriais usando linguagens visuais e textuais específicas da indústria. Para operar sua grande infraestrutura de TI, a empresa mantém uma equipe significativa de funcionários, cujas responsabilidades incluem scripts e programação simplificada.
Embora a ABB tenha adquirido várias empresas menores, ela tem uma organização central responsável por unificar os processos de desenvolvimento de software. Portanto, apesar das diferenças entre os departamentos, a maioria das ferramentas e abordagens são consistentes. O mesmo é verdadeiro para a maioria dos planos de carreira: para técnicos, de desenvolvedor júnior a sênior, e para executivos, de líder de grupo a líder de departamento e gerenciamento central.
2.3. Instrumentos Nacionais
A National Instruments foi fundada na década de 1970. O desenvolvimento de software está concentrado principalmente em quatro centros internacionais de pesquisa e desenvolvimento. Os calendários dos funcionários são visíveis para toda a empresa, qualquer pessoa pode marcar um encontro com qualquer outro funcionário.
As responsabilidades do cargo facilitam os processos de desenvolvimento. Os desenvolvedores não podem escolher um projeto independentemente, mas podem assumir tarefas ou recursos específicos. A maioria trabalha com uma base de código monolítica comum, com suas diferentes partes lógicas tendo proprietários específicos. O código inserido deve ser aprovado pelo "proprietário". É desejável que o código seja analisado por líderes de tecnologia. Esta política é opcional, mas muitos a seguem.
Os desenvolvedores têm muita liberdade na escolha das ferramentas. Não existem ferramentas genéricas, a menos que haja um benefício imediato. Por exemplo, a escolha do IDE é altamente dependente da tarefa. Existem várias ferramentas personalizadas de construção e teste disponíveis. Diferentes partes da empresa padronizaram diferentes sistemas para gerenciamento e análise de código-fonte. As atualizações de software são normalmente lançadas trimestral ou anualmente, com exceção de patches críticos raros.
Tabela 1. Perfis das três empresas estudadas:
ABB | Instrumentos Nacionais | ||
O tamanho | Grande. | Grande. | Petite. |
Escritórios | Escritórios abertos. | Escritórios abertos e fechados. | Escritórios abertos. |
Ferramentas | Principalmente ferramentas de desenvolvimento unificadas. | Mesmas ferramentas. | Flexibilidade na escolha das ferramentas |
Tipo de desenvolvimento | Principalmente código do lado do servidor e móvel. | Uma combinação de desenvolvimento web, software embarcado e desktop. | Principalmente software integrado e de desktop. |
Repositório | Repositório monolítico. | Repositórios separados. | Repositório monolítico. |
Declive | Desenvolvimento de software. | Conglomerado de engenharia. | Desenvolvimento de softwares e equipamentos. |
3. Metodologia
Nosso objetivo: descobrir quais fatores podem prever a produtividade dos desenvolvedores de software. Para isso, conduzimos um estudo contendo um conjunto de questões, um conjunto de fatores de produtividade e um conjunto de variáveis demográficas.
3.1 Avaliando sua produtividade
Primeiro, vamos descrever como mediremos a produtividade. Ramírez e Nembhard propuseram uma classificação das técnicas de medição de desempenho descritas na literatura, incluindo análise de pontos de função, autoavaliação, avaliação por pares, proporcionalidade de resultados e esforços e uso profissional do tempo [2]. Essas técnicas podem ser divididas em objetivas (por exemplo, quantas linhas de código são escritas por semana) e subjetivas (por exemplo, autoavaliação ou revisão por pares).
Nenhuma das técnicas é preferida; ambas as categorias têm desvantagens. Medidas objetivas carecem de flexibilidade e diversão. Vamos pegar o número de linhas de código por semana. Um desenvolvedor produtivo pode escrever uma correção de uma linha para um bug difícil de encontrar. E um desenvolvedor improdutivo pode facilmente aumentar o número de linhas. Por outro lado, as medidas subjetivas podem ser imprecisas devido a vieses cognitivos. Considere as avaliações dos colegas: eles podem não gostar de um desenvolvedor produtivo e, portanto, suas avaliações serão piores, mesmo se os colegas buscarem objetividade.
Como a equipe de pesquisadores liderada por Meyer que analisou a produtividade dos desenvolvedores de software [3], usamos nossas questões de pesquisa como uma medida subjetiva de produtividade. Há duas razões principais. Em primeiro lugar, conforme observado por Ramirez e Nembhardt, a pesquisa é "uma maneira simples e popular de medir a produtividade [dos trabalhadores do conhecimento]". Em segundo lugar, a pesquisa fornece respostas de desenvolvedores em funções diferentes e também permite que os entrevistados adicionem informações diferentes às suas avaliações de desempenho.
Figura: 1. Metodologia de pesquisa:

Perguntamos aos entrevistados o quanto eles concordam com a afirmação:
Eu regularmente obtenho alta produtividade.
Com ele, queríamos medir a produtividade da forma mais ampla possível. Formulamos primeiro oito opções para a pergunta e, em seguida, reduzimos ao anterior, conversando informalmente com cinco desenvolvedores do Google sobre sua interpretação da frase (Figura 1, canto inferior esquerdo). Adicionamos as palavras “alto” e “regularmente” à pergunta por três motivos. Primeiro, queríamos capturar um estado com o qual as pessoas pudessem se comparar. Em segundo lugar, queríamos que esse estado fosse alto para evitar os efeitos de atingir o teto nas respostas dos entrevistados. Terceiro, queríamos que os entrevistados se concentrassem em duas medidas específicas de produtividade - intensidade e frequência. No futuro, os pesquisadores podem aplicar medidas mais detalhadas dividindo a intensidade e a frequência em duas questões distintas.
Colocamos isso à prova pedindo a três executivos do Google que enviassem a suas equipes: "O que você considerou ao responder a uma declaração de produtividade?" Recebemos respostas de 23 desenvolvedores (Figura 1, parte inferior central). A opção foi considerada aceitável para nossos propósitos porque as considerações dos entrevistados corresponderam às nossas expectativas em relação ao valor da produtividade. Essas considerações cobriam problemas de fluxo de trabalho, resultados do trabalho, estar dentro da zona ou fluxo, felicidade, objetivos alcançados, eficiência da programação, progresso e minimização do esforço desperdiçado. Não analisamos essas respostas neste artigo, mas o estudo incluiu quatro medidas adicionais e refinadas de produtividade tomadas em trabalhos anteriores [2], [4], [5].
Escolhemos duas medidas convenientes de produtividade para adicionar dados objetivos para contextualizar a auto-estima e, em seguida, correlacioná-los entre si no Google. A primeira medida objetiva era o número de linhas de código alteradas por um desenvolvedor por semana - uma medida popular, mas desafiadora de produtividade [6], [7]. A segunda medida foi o número de mudanças feitas pelo desenvolvedor na base de código principal do Google por unidade de tempo. É quase equivalente ao pull request mensal usado pela equipe liderada por Vasilescu [8]. Para avaliar nossa produtividade, usamos respostas a uma pesquisa semelhante no Google (n = 3344 respostas). Não pudemos usar os dados de nosso estudo para esta análise porque as respostas não continham IDs de participante.por meio do qual medidas objetivas de produtividade poderiam ser comparadas. Nesse estudo, foi feita uma pergunta semelhante: "Com que frequência você acha que é altamente produtivo no trabalho?" Os participantes podiam responder "Raramente ou nunca", "Às vezes", "Cerca de metade das vezes", "Na maioria das vezes" e "Sempre ou quase sempre". Em seguida, criamos uma regressão linear com desempenho autorrelatado como a variável dependente ordinal (codificada 1, 2, 3, 4 e 5, respectivamente). A regressão linear assume distância igual entre as classificações de produtividade. Dadas as palavras usadas na pergunta, consideramos essa suposição como justificada. Para regressão logística ordenada, esta suposição não é necessária. A aplicação desta técnica aqui dá resultados confiáveis: os mesmos coeficientes são significativos de forma linear,e em um modelo ordenado.
Usamos medidas logarítmicas objetivas como variáveis independentes, porque ambas apresentaram distorção positiva. Para controle, tomamos o código do trabalho (por exemplo, engenheiro de software, engenheiro de pesquisa, etc.) como uma variável categórica, bem como a classificação (júnior, médio, sênior, etc.) como um número (por exemplo, 3 para software engenheiro iniciante no Google). O código do trabalho foi estatisticamente significativo para duas funções de trabalho em cada modelo linear. Havia três modelos no total: dois com uma das medidas objetivas e um com as duas medidas objetivas.

Figura: 2: Modelos que prevêem estimativas subjetivas de desempenho com base em duas medidas objetivas. ns significa um fator estatisticamente insignificante com p> 0,05, ** significa p <0,01, *** significa p <0,001. Uma descrição completa dos modelos é fornecida nos Materiais Suplementares.
Os resultados da contextualização são mostrados na Fig. 2. Cada modelo demonstra um nível estatisticamente significativo com uma classificação negativa, que interpretamos como: desenvolvedores com classificações mais altas tendem a se classificar como um pouco menos produtivos. Este é um forte argumento para controle de classificação (seção 3.7.). Os dois primeiros modelos demonstram uma relação positiva importante entre medidas objetivas e subjetivas de produtividade. Ou seja, quanto mais linhas de código são escritas ou mudanças são feitas, mais produtivo o desenvolvedor se considera. O modelo combinado resultante e as estimativas para os dois primeiros modelos sugerem que o número de mudanças feitas é um indicador de produtividade mais importante do que o número de linhas escritas. Mas note que em todos os modelos o parâmetro R 2, representando a proporção da variância explicada, é bastante baixa - menos de 3% para cada modelo.
Em geral, os resultados obtidos indicam que o número de linhas de código e as alterações feitas afetam a avaliação dos desenvolvedores sobre sua produtividade, mas não de forma significativa.
3.2. Fatores de produtividade
Então, durante o curso do estudo, perguntamos aos participantes sobre os fatores que são considerados relacionados à produtividade em outros estudos. Coletamos perguntas de quatro fontes (Figura 1, meio esquerdo). Essas fontes são utilizadas porque, até onde sabemos, elas representam as visões gerais mais abrangentes dos fatores de produtividade individuais na pesquisa de programadores e outros trabalhadores do conhecimento.
Primeira fonteÉ uma ferramenta criada por uma equipe liderada por Palvalin para revisar as medidas de produtividade para trabalhadores do conhecimento [4]. A ferramenta, chamada SmartWoW, foi usada por quatro empresas e cobre aspectos de espaço de trabalho físico, virtual e social, práticas de trabalho pessoal e bem-estar no trabalho. Alteramos algumas das perguntas para refletir melhor a terminologia do desenvolvedor atual e corresponder melhor ao inglês americano. Por exemplo, SmartWoW pergunta:
Costumo teletrabalho para a realização de tarefas que exigem concentração ininterrupta.
Nós parafraseamos:
Costumo trabalhar remotamente para realizar tarefas que exigem concentração ininterrupta.
No SmartWoW, primeiro selecionamos 38 questões para nosso estudo.
Uma segunda fonte é uma revisão de Hernaus e Mikulić sobre o impacto das características do ambiente de trabalho na produtividade dos trabalhadores do conhecimento [9]. Seu trabalho comprovado reflete estudos de produtividade anteriores: um questionário de design do ambiente de trabalho [10], um estudo diagnóstico do ambiente de trabalho [11], uma avaliação da colaboração em grupo [12] uma avaliação da “natureza das tarefas” [13]. Mudamos as perguntas para serem curtas e consistentes. Para o mesmo propósito, tiramos questões diretamente do trabalho [12], que é dedicado a grupos de trabalho com poucas considerações sobre a produtividade pessoal.
Terceira fonte- uma revisão estruturada de Wagner e Ruhe dos fatores de produtividade no desenvolvimento de software [14]. Ao contrário de outras fontes, este trabalho não foi completamente revisado pela comunidade científica e não contém pesquisas empíricas originais. Mas, pelo que sabemos, esta é a pesquisa mais abrangente sobre pesquisa de produtividade em programação. Os fatores formulados por Wagner e Rouet são divididos em fatores técnicos e não quantificáveis e, em seguida, os fatores de meio ambiente, cultura corporativa, projeto, produto e ambiente de desenvolvimento, capacidades e experiência são adicionalmente destacados.
A quarta fonteÉ um estudo de desenvolvedor da Microsoft liderado por uma equipe liderada por Meyer. A partir dele, descobrimos cinco razões principais para dias de trabalho produtivos, incluindo definição de metas, reuniões de trabalho e intervalos do trabalho [15].
Acrescentamos ainda três fatores que, a nosso ver, não foram devidamente considerados em trabalhos anteriores, mas que se revelaram importantes no contexto do Google. Uma delas é a avaliação da produtividade dos trabalhadores do conhecimento [16], um precursor não publicado do SmartWoW. Nós adaptamos assim:
As informações fornecidas para mim (relatórios de bug, scripts de usuário, etc.) são precisas.
O segundo fator é retirado do questionário de design do ambiente de trabalho e adaptado da seguinte forma:
Recebo feedback útil sobre minha produtividade no trabalho.
E criamos um terceiro fator que era importante no ambiente da ABB:
Preciso de acesso direto a determinado hardware para testar meu software.
Primeiro, escolhemos 127 fatores. Para reduzi-los a um número de perguntas que os respondentes possam responder sem fadiga significativa [17], usamos os critérios descritos no centro da Fig. 1:
- Duplicatas removidas. Por exemplo, em SmartWoW [4] e Meyer et al. [15], o estabelecimento de metas é considerado um fator importante na produtividade.
- Fatores semelhantes combinados. Por exemplo, Hernaus e Mikulich descrevem diferentes aspectos da interação entre grupos de trabalho que aumentam a produtividade, mas nós os reduzimos a um fator [9].
- A preferência foi dada a fatores de óbvia utilidade. Por exemplo, SmartWoW [4] tem um fator:
Os funcionários têm a oportunidade de ver os calendários uns dos outros.
No Google, isso é verdade em todos os lugares e é improvável que mude, então o fator tem pouca utilidade.
Aplicamos esses critérios juntos e iterativamente. Primeiro, foi impresso um grande pôster com todas as perguntas do candidato a serem usadas no estudo. Em seguida, colocamos um pôster do Google ao lado de nosso escritório. Em seguida, cada um de nós analisou independentemente as questões com base nos critérios acima. O pôster ficou pendurado por várias semanas, periodicamente adicionamos e revisamos a lista novamente. Finalmente, uma lista final de perguntas foi elaborada.
Nosso estudo incluiu 48 fatores na forma de afirmações (Fig. 4, coluna da esquerda). Os respondentes indicaram seu grau de concordância com essas afirmações em uma escala de cinco pontos, de “Discordo totalmente” a “Concordo totalmente”. Os fatores podem ser agrupados em blocos relacionados à metodologia, foco, experiência, trabalho, oportunidade, pessoas, projeto, software e contexto. Também fizemos uma pergunta aberta sobre fatores que os entrevistados achavam que poderíamos ter esquecido. O questionário completo de nosso estudo é fornecido nos Materiais Suplementares.

Figura: 3: Exemplo de pergunta de pesquisa.
3.3. Demografia
Fizemos perguntas sobre vários fatores demográficos, conforme mostrado na Figura 1:
- Chão.
- Posição.
- Classificação.
Autores anteriores sugeriram que o gênero está relacionado aos fatores de produtividade dos desenvolvedores de software, como o sucesso da depuração [18]. Portanto, o estudo teve uma questão opcional sobre o gênero (masculino, feminino, recuso a responder, meu próprio). Os respondentes que não responderam à pergunta foram designados para o grupo “recusar responder” (Google n = 26 [6%], ABB n = 4 [3%], National Instruments n = 5 [6%]). Tratamos esses dados como categóricos.
Quanto ao cargo, tiramos a senioridade no Google do departamento de RH. Isso não foi possível com a ABB e a National Instruments, então adicionamos uma questão opcional ao estudo. Na ABB, na ausência de respostas (n = 4 [3%]), levamos 12 anos de experiência, essa é a média dos dados coletados. Na National Instruments, demoramos 9 anos pelo mesmo motivo (n = 1 [1%]). Você pode tornar isso mais difícil [19], por exemplo, usando substituições para prever valores ausentes com base nos dados disponíveis. Digamos que as informações de classificação ausentes possam ser preenchidas com bastante precisão com base na posição e no gênero. No entanto, substituímos simplesmente valores estatísticos médios, uma vez que os fatores demográficos não eram de importância primária para nós, eles eram apenas informações complementares para controle. Processamos esses dados como números.
Em termos de classificação, no Google pedimos aos participantes que indicassem seu nível como um número. As respostas ausentes (n = 26 [6%]) foram o valor mais comum.
Na ABB, os colaboradores podem opcionalmente indicar “desenvolvedor de software júnior ou sênior”, embora muitos tenham indicado um título “diferente”. Se a resposta incluiu as palavras:
- Mais velho
- conduzindo
- Gerente
- arquiteto
- investigador
- a Principal
- cientista
em seguida, encaminhamos essas respostas para as "seniores". Os demais foram chamados de "juniores". As respostas em falta (n = 4 [3%]) atribuímos ao significado mais comum - “idoso”.
A National Instruments tinha opções:
- desafiador
- funcionários
- Mais velho
- arquiteto / engenheiro principal
- arquiteto / engenheiro chefe
- engenheiro honrado
- participante
- de outros
O único “outro” acabou por ser um estagiário, que transferimos para os “candidatos”. As respostas ausentes (n = 3 [4%]) atribuímos ao significado mais comum - “sênior”.
Codificamos as classificações em todas as empresas por números.
3.4. Comparação com não desenvolvedores
Em seguida, estávamos interessados em saber o que exatamente nos permite prever como os desenvolvedores avaliam sua produtividade. Por exemplo, presumimos que a produtividade foi influenciada pela interrupção do trabalho, mas isso poderia ser dito para qualquer trabalhador do conhecimento. Portanto, surge uma questão natural: isso afeta de alguma forma a produtividade do desenvolvedor de uma maneira especial?
Para responder a essa pergunta, escolhemos profissões comparáveis a desenvolvedores de software. Primeiro, tentamos selecionar com base nas posições no Google. Embora alguns cargos indicassem que eles eram trabalhadores do conhecimento, o indicador mais comum e, em nossa opinião, o mais confiável de um não desenvolvedor adequado era a presença da palavra "analista" no cargo. Decidimos comparar analistas e desenvolvedores do Google, em vez de comparar os analistas do Google com desenvolvedores de todas as três empresas. Decidimos que isso nos permitiria controlar as características da empresa (por exemplo, se repentinamente os funcionários do Google forem estatisticamente mais ou menos sensíveis à interrupção do que os funcionários de outras empresas).
Em seguida, adaptamos nossa pesquisa para analistas. Perguntas removidas claramente relacionadas ao desenvolvimento de software, como "Meus requisitos de software mudam com frequência". Refizemos outras questões especificamente para analistas. Por exemplo, em vez de "Eu uso as melhores ferramentas e técnicas para desenvolver software", escrevemos "Eu uso as melhores ferramentas e abordagens para fazer meu trabalho".
As pontuações de produtividade foram medidas da mesma forma que os desenvolvedores. O mesmo vale para avaliar gênero, posição e classificação. Testamos a versão “analítica” do estudo em uma amostra conveniente de cinco analistas que disseram que o estudo era geralmente claro e fez alguns pequenos ajustes. Nós os aceitamos e conduzimos um estudo completo de não desenvolvedores.

3,5. Qestion de controle
Para excluir respostas que foram dadas de forma irrefletida, após cerca de 70% do início do estudo, inserimos uma questão de atenção [20]: "Responda," Discordo bastante. " Não levamos em consideração os formulários que não continham essa resposta a esta pergunta.
3,6. Compartilhamento de respostas
No Google, selecionamos 1.000 funcionários aleatórios em tempo integral de recursos humanos que estavam em funções de desenvolvimento de software. Recebemos deles 436 formulários preenchidos, ou seja, a taxa de resposta foi de 44%, o que é um indicador muito alto para pesquisas entre desenvolvedores [21]. Após a exclusão dos formulários com resposta errada à pergunta de segurança (n = 29 [7%]), restaram 407 respostas.
Para uma pesquisa com trabalhadores do conhecimento, selecionamos 200 funcionários aleatórios do Google em tempo integral com a palavra “analista” em seus cargos. Decidimos não pesquisar muitos analistas porque nosso alvo eram os desenvolvedores de software. 94 pessoas, 47%, responderam às nossas perguntas. Depois de excluir questionários com uma resposta errada à pergunta de segurança (n = 6 [6%]), 88 permaneceram.
Enviamos nossos questionários a aproximadamente 2.200 desenvolvedores de software selecionados aleatoriamente na ABB e recebemos 176 respostas. Isso é 8%, no limite inferior para tais estudos [21]. Depois de excluir os questionários errados (n = 39 [22%]), restaram 137.
Finalmente, enviamos os questionários a cerca de 350 desenvolvedores de software da National Instruments e recebemos 91 respostas (26%). Depois de deletar os questionários errados (n = 13 [14%]), 78 permaneceram.
3,7. Análise
Para cada fator em cada empresa, aplicamos modelos de regressão linear individuais, usando o fator como variável independente (por exemplo, “O prazo do meu projeto é apertado”) e a estimativa de nossa produtividade como variável dependente. Executamos modelos separados para cada empresa por uma questão de privacidade, de forma que os dados brutos de empresas diferentes não se misturassem. Para reduzir o efeito das variáveis colaterais, adicionamos variáveis demográficas existentes a cada modelo de regressão. Na interpretação dos resultados, nos concentramos em três aspectos da razão dos fatores de produtividade:
- Avaliação . Indica o grau de influência de cada fator, mantendo uma constante demográfica. Quanto maior o valor, maior o impacto.
- . . , .
- . p < 0,05. 48 , p -, [22].
Na interpretação dos resultados, focamos mais no grau de influência (estimativa) e menos na significância estatística, porque ele pode ser extraído de conjuntos de dados grandes o suficiente, mesmo se a significância prática for baixa. Como veremos a seguir, os resultados estatisticamente significativos foram encontrados com mais frequência no Google, com a maior taxa de resposta; menos ainda - em Instrumentos Nacionais, onde a taxa de resposta foi menor. Sentimos que essa diferença se devia em grande parte ao poder estatístico. Recomendamos que você tenha mais confiança nos resultados estatisticamente significativos.
Para fornecer contexto, também analisamos como os fatores demográficos se correlacionam com as classificações de desempenho. Para fazer isso, executamos uma regressão linear múltipla para cada empresa com variáveis demográficas como variáveis independentes e uma estimativa de nossa produtividade como variável dependente. Em seguida, analisamos o valor preditivo geral do modelo resultante, bem como o impacto de cada variável explicativa.
3,8. Sobre causalidade
A nossa metodologia permite-nos avaliar a relação entre os factores de produtividade e a avaliação da sua própria produtividade, embora na sua essência estejamos interessados no grau de influência de cada factor na variação da produtividade. Quão correto é acreditar que existe uma relação causal entre fatores e produtividade?
A correção depende principalmente da força da evidência de causalidade em trabalhos anteriores. E esse poder é diferente para diferentes fatores. Por exemplo, uma equipe liderada por Guzzo conduziu uma meta-análise de 26 artigos sobre avaliação e feedback, e os resultados fornecem evidências excelentes de que o feedback aumenta a produtividade no local de trabalho [23]. Porém, determinar a força da evidência para cada fator investigado requer muito trabalho, que foge ao escopo deste artigo.
Resumindo: embora nosso estudo não permita estabelecer uma relação causal, mas com base em trabalhos anteriores, podemos acreditar com segurança que esses fatores afetam a produtividade, mas interpretamos nossos resultados com alguma cautela.

4. Resultados
Para começar, descrevemos a relação entre todos os fatores de produtividade e a avaliação de sua produtividade ao controlar as características demográficas. Esses dados serão usados para responder a cada resposta da pesquisa, seguido por uma discussão dos resultados. Em seguida, discutiremos a relação entre as características demográficas e a medição de desempenho. Finalmente, vamos discutir as implicações e riscos.
4.1. Fatores de produtividade
Na fig. 4 mostra os resultados de nossa análise descrita na seção 3.7. A primeira coluna relaciona os fatores que foram propostos aos participantes na forma de afirmações; seguido pelos rótulos dos fatores (F1, F2, etc.) que atribuímos após a conclusão da análise A falta de dados significa que esses fatores são específicos para desenvolvedores e não foram sugeridos para analistas (por exemplo, F10).
Figura: 4: Relações entre 48 fatores e como desenvolvedores e analistas avaliam sua própria produtividade em três empresas:

As três colunas a seguir mostram dados de três empresas, bem como dados de analistas do Google. Cada uma dessas colunas é dividida em duas subcolunas. Estimativa de
sub-coluna(pontuação) contém coeficientes de regressão que quantificam a força da associação de um fator com uma estimativa de sua produtividade. Quanto maior o número, mais forte é a associação. Por exemplo, na primeira coluna do Google, a estimativa é de 0,414. Nesse caso, isso significa que para cada ponto de concordância crescente com a afirmação sobre entusiasmo no trabalho (F1), o modelo prevê um aumento na produtividade do respondente em 0,414 pontos com controle das variáveis demográficas. As avaliações podem ser negativas. Por exemplo, nas três empresas, quanto mais rotatividade de pessoal na equipe (F48), menor é a estimativa de sua produtividade. Ao lado de cada pontuação há um indicador que reflete claramente a pontuação.
Observe que as pontuações não significam classificações mais altas de fatores, mas uma correlação mais alta entre o fator e a classificação de sua produtividade. Por exemplo, a National Instruments (F1) obtém mais entusiasmo do que outras empresas. Isso não significa que os desenvolvedores lá estejam mais entusiasmados: nesta empresa, ele é um fator mais forte na previsão da avaliação de sua produtividade. Não fornecemos as classificações, porque isso é proibido nos termos de cooperação. Sem contexto completo, as classificações podem ser mal interpretadas. Por exemplo, se informarmos que os desenvolvedores de uma empresa estão menos entusiasmados com seu trabalho do que os desenvolvedores de outra empresa, você pode ficar com a impressão de que é melhor não trabalhar nessa outra empresa. Erro da
segunda subcoluna(erro) contém os erros padrão do modelo para cada fator. Quanto menor o valor, melhor. Intuitivamente, valores mais baixos parecem indicar que, quando os fatores mudam, o modelo prevê seu desempenho de forma mais confiável. Os valores gerais de erro são razoavelmente estáveis de fator a fator, especialmente no Google com um grande número de entrevistados.
Um asterisco (*) indica que esse fator foi estatisticamente significativo no modelo. Por exemplo, o entusiasmo pelo trabalho (F1) é estatisticamente significativo nas três empresas, enquanto a preparação para reuniões (F17) é significativa apenas no Google.
A próxima coluna contém a pontuação média ( μ ) para todas as três empresas com desvio padrão entre parênteses ( σ) O primeiro indicador mostra claramente o valor da pontuação média, o segundo indicador - o valor do desvio padrão. Por exemplo, a pontuação média para entusiasmo no trabalho (F1) foi de 0,43 e o desvio padrão foi de 0,051. A tabela é classificada pela classificação média.
A última coluna contém as diferenças entre as avaliações do desenvolvedor de software e do analista no Google. Valores positivos significam classificações mais altas do desenvolvedor, e negativos significam classificações mais altas do analista. Por exemplo, em termos de entusiasmo (F1), as pontuações dos analistas são ligeiramente mais baixas do que as dos desenvolvedores.
4.2. Quais fatores são os melhores preditores de como os desenvolvedores avaliam sua produtividade?
Os fatores preditivos mais fortes são as declarações com a pontuação média absoluta mais alta. Os fatores preditivos mais fracos são aqueles com a pontuação média absoluta mais baixa. Em outras palavras, os fatores no topo da tabela da Fig. 4 são os melhores preditores. Para entender qual fator oferece mais confiança no resultado, destacamos os resultados que são estatisticamente significativos para todas as três empresas:
- Entusiasmo pelo trabalho (F1)
- Apoio de pares para novas ideias (F2)
- Feedback útil sobre o desempenho no trabalho (F11)
Discussão . Observe que os primeiros 10 fatores de produtividade não são técnicos. Isso é surpreendente, visto que, em nossa estimativa, a maior parte das pesquisas dos desenvolvedores de software está focada em aspectos técnicos. Portanto, uma reorientação ativa para o fator humano pode levar a um aumento significativo da influência dos pesquisadores na indústria. Por exemplo, as respostas às seguintes perguntas podem ser particularmente proveitosas:
- O que deixa os desenvolvedores de software entusiasmados com seu trabalho? O que explica a diferença de entusiasmo? Que intervenções podem aumentar o entusiasmo? Este artigo pode complementar a pesquisa sobre felicidade [24] e motivação [25].
- ? , ? ?
- , ? ? ?
Outra característica importante é a classificação dos fatores da linha de pesquisa COCOMO II. Esses fatores, obtidos no decorrer de estudos empíricos de projetos de software da indústria e verificados por análise numérica de 83 projetos [26], foram originalmente formulados para estimar o custo de desenvolvimento de software. Por exemplo, os fatores de produtividade do COCOMO II incluem a volatilidade da plataforma básica e a complexidade do produto. É curioso que os fatores COCOMO II levados em consideração em nosso estudo (F5, F10, F14, F16, F24, F26, F28, F32, F33, F34, F36, F38, F39, F43, F44, F46, F47, F48) receberam menor valores. Pode-se supor que eles tornam possível prever a piora da produtividade. A metade superior dos fatores preditivos (F1 - F24) incluiu apenas 5 de COCOMO II, e a metade inferior - 14 fatores. Podemos oferecer duas interpretações diferentes. Primeiro:O COCOMO II carece de vários fatores de produtividade importantes, e iterações futuras do COCOMO II podem ser mais preditivas se mais dos fatores que investigamos, como suporte para abordagens de autonomia de trabalho, forem introduzidos na empresa. Outra interpretação: COCOMO II é adaptado para a tarefa atual - fixando a produtividade no nível do projeto [6], [27], [28], [29], [30], [31] - mas menos adequado para fixar a produtividade no nível do desenvolvedor individual. Essa interpretação enfatiza a importância e a novidade de nossos resultados.COCOMO II é adaptado para a tarefa atual - produtividade de fixação no nível do projeto [6], [27], [28], [29], [30], [31] - mas menos adequado para a fixação da produtividade no nível do desenvolvedor individual. Essa interpretação enfatiza a importância e a novidade de nossos resultados.O COCOMO II é adaptado para a tarefa atual - produtividade de fixação no nível do projeto [6], [27], [28], [29], [30], [31] - mas menos adequado para a fixação da produtividade no nível do desenvolvedor individual. Essa interpretação enfatiza a importância e a novidade de nossos resultados.
Além disso, todos os fatores do COCOMO II foram fatores preditivos de produtividade relativamente baixos e estatisticamente insignificantes para as três empresas. Por exemplo:
- Meu software precisa de muito poder de processamento (F39).
- Meu software precisa de um grande armazenamento de dados (F43).
- Minha plataforma de software (por exemplo, ambiente de desenvolvimento, software ou pilha de hardware) está mudando rapidamente (F46).
Uma explicação: nos 20 anos desde a criação e teste do COCOMO II, as plataformas tornaram-se menos diversificadas em termos de produtividade. É provável que os sistemas operacionais padronizados agora estejam protegendo os desenvolvedores de perdas de produtividade devido a mudanças de hardware (como o Android no desenvolvimento móvel). Da mesma forma, as plataformas em nuvem podem proteger os desenvolvedores de perdas de produtividade devido ao dimensionamento do processo e às necessidades de armazenamento. Sem mencionar que os frameworks modernos e as plataformas em nuvem são fáceis de usar. Além disso, a diferença de produtividade no processamento de grandes e pequenas quantidades de dados pode ter desaparecido desde a criação do COCOMO II.
4.3. Como esses fatores diferem de empresa para empresa?
Para responder a essa pergunta, você pode examinar o desvio padrão nas estimativas das três empresas. Aqui estão os três fatores com a menor variabilidade, ou seja, com os valores mais estáveis entre as empresas:
- Usando teletrabalho para foco (F40).
- Feedback útil sobre o desempenho no trabalho (F4).
- Apoio dos pares para novas ideias (F2).
Acreditamos que a estabilidade desses fatores os torna bons candidatos para generalização. Outras empresas provavelmente verão resultados semelhantes nesses fatores.
E aqui estão os três fatores com maior variabilidade, ou seja, com a maior dispersão de valores entre as empresas:
- Usando as melhores ferramentas e abordagens (F15).
- Reutilização de código (F25).
- Precisão das informações de entrada (F6).
Discussão . Os três fatores menos variáveis (F40, F4 e F2) têm uma característica comum - não se relacionam com a tecnologia, mas com a sociedade e o meio ambiente. Talvez isso sugira que, onde quer que os desenvolvedores trabalhem, eles são igualmente afetados por trabalho remoto, feedback e suporte de colegas para novas ideias. Alterar esses três fatores pode ser o maior impacto.
Por que os fatores F15, F25 e F6 são tão diferentes em empresas diferentes? Para cada uma delas, temos uma explicação possível com base no que sabemos sobre essas empresas.
Usar as melhores ferramentas e abordagens (F15) está mais fortemente associado à pontuação de desempenho do Google, mas não significativamente associado à National Instruments. Explicação possível: a base de código do Google é muito maior. Portanto, o uso de ferramentas e abordagens melhores para navegar e compreender a base de código maior de forma eficiente tem um impacto significativo na produtividade. E na National Instruments, a produtividade depende menos da ferramenta porque a base de código é menor e mais clara.
A reutilização de código (F25) está fortemente relacionada à pontuação de desempenho do Google, mas não significativamente relacionada à ABB. Explicação possível: o Google facilita a reutilização de código. A base de código é monolítica, com todos os desenvolvedores capazes de examinar virtualmente todas as linhas de código da empresa, portanto, a reutilização não exige muito esforço. E a ABB tem muitos repositórios que você precisa acessar. E, nessa empresa, os ganhos de produtividade (por meio da reutilização) podem ser compensados por perdas de produtividade (por encontrar e recuperar o código certo).
A Precisão da Informação (F6) está fortemente relacionada às pontuações de desempenho da National Instruments, mas não significativamente relacionada à ABB. Explicação possível: os desenvolvedores da ABB estão mais bem isolados da influência de informações imprecisas. Em particular, na ABB, vários níveis da equipe de suporte são dedicados a obter as informações corretas sobre bugs dos clientes. Se o desenvolvedor receber informações imprecisas, sua produtividade pode cair, porque ele tem que delegar a tarefa de refinar os dados de volta para a equipe de suporte.
4,4. O que torna possível prever a avaliação de um desenvolvedor sobre sua produtividade, em particular, em comparação com outros trabalhadores do conhecimento?
Para responder a essa pergunta, vá para a última coluna da Fig. 4. Se olharmos para várias relações entre classificações máximas, veremos que a avaliação dos analistas sobre sua produtividade está mais fortemente associada a:
- Percepção positiva dos companheiros (F7).
- Autonomia na organização do tempo de trabalho (F4).
Por outro lado, a avaliação dos desenvolvedores sobre sua produtividade está mais fortemente relacionada a:
- Desempenhando várias tarefas dentro da obra (F13).
- Trabalhar efetivamente fora de seus locais de trabalho (F30).
Discussão . No geral, os resultados sugerem que os desenvolvedores são um pouco semelhantes a outros profissionais do conhecimento e um pouco diferentes. Por exemplo, a produtividade do desenvolvedor é mais bem prevista pelo entusiasmo no trabalho, e os analistas têm quase o mesmo. Acreditamos que as empresas podem usar nossas descobertas para selecionar iniciativas de produtividade específicas do desenvolvedor ou iniciativas mais amplas.
O Unified Development Toolkit do Google pode explicar por que o aumento da diversidade de tarefas está associado a classificações de produtividade mais altas entre desenvolvedores, não analistas. A diversidade de tarefas pode reduzir o tédio e aumentar a produtividade para ambos os grupos, mas as ferramentas de desenvolvimento unificadas do Google podem significar que os desenvolvedores podem usar as mesmas ferramentas para tarefas diferentes. E os analistas podem precisar usar ferramentas diferentes para tarefas diferentes, o que aumenta o esforço cognitivo na troca de contexto.
O trabalho fora do escritório pode explicar por que melhorar a eficiência do trabalho fora do local de trabalho está mais fortemente associado a ganhos de produtividade para desenvolvedores do que para analistas. Acreditamos que fazer uma pausa no trabalho é mais prejudicial durante a programação do que durante o trabalho analítico.
Parnin e Rugaber descobriram que retornar ao trabalho após a interrupção é um problema frequente e persistente para desenvolvedores [32], levando à necessidade de melhores ferramentas para ajudá-los a voltar a trabalhar em um problema [33].

4.5. Outros fatores de produtividade
Ao final do questionário, os respondentes podem indicar fatores adicionais que, em sua opinião, afetam a produtividade. Na maior parte, essas adições foram as mesmas ou descrições mais refinadas de nossos 48 fatores. Descartamos tais acréscimos, mas, se necessário, criamos novos fatores. Os Materiais Suplementares contêm descrições de novos fatores, bem como descrições atualizadas daqueles que propusemos originalmente. Pesquisadores em potencial podem ter uma nova pergunta de equipe mista para trabalhar em um projeto, ou refinar ou sugerir quebras de perguntas mais específicas para os fatores F15, F16 e F19.
4,6. Demografia
No Google e na National Instruments, nenhum dos modelos demográficos gerais, mas as variáveis associadas individuais foram preditores estatisticamente significativos de suas pontuações de desempenho.
Para ABB, o modelo demográfico revelou-se significativo ( F = 3 , 406 , df = (5 , 131) , p <0,007). O gênero também se mostrou um fator estatisticamente significativo ( p = 0,007), as mulheres estimam sua produtividade 0,83 pontos a mais que os homens. Participantes de outros gêneros (“outro”) apresentaram avaliação 1,6 pontos maior do que os homens ( p = 0,03). A posição ( p= 0,04), a cada ano adicional a empresa aumentou sua estimativa de desempenho em 0,02 pontos. Pelo que sabemos, as diferenças entre a ABB e as outras duas empresas não explicam por que esses fatores demográficos foram considerados significativos apenas na ABB e em nenhum outro lugar.
4.7. Aplicação na prática e na pesquisa
Como usar nossos resultados na prática? Fornecemos uma lista classificada dos fatores mais importantes na previsão da produtividade que pode ser usada para priorizar iniciativas. Exemplos de iniciativas podem ser encontrados em trabalhos de pesquisa anteriores.
Por exemplo, para aumentar o entusiasmo no trabalho, Markos e Sridevi sugeriram ajudar os trabalhadores a crescer profissionalmente [34] por meio de workshops sobre tecnologia e comunicação interpessoal. Além disso, os pesquisadores sugeriram introduzir a prática da apreciação por um bom trabalho. Por exemplo, a ABB está experimentando a apreciação do público para desenvolvedores que implementaram ferramentas e técnicas para navegar em código estruturado [35].
Para aumentar o apoio a novas ideias, Brown e Duguid propuseram formas formais e informais de compartilhar as melhores práticas [36]. No Google, a disseminação unilateral de conhecimento é por meio da iniciativa de Teste de Toalete: os desenvolvedores escrevem pequenas histórias sobre o teste ou outra área e, em seguida, essas notas são postadas em banheiros de toda a empresa.
Para melhorar a qualidade do feedback sobre a produtividade do trabalho, London e Smither sugerem focar no feedback que não julga, seja baseado em comportamento, seja interpretável e orientado para resultados [37]. No Google, esse feedback pode ser obtido por meio de autópsias inócuas: após eventos negativos importantes, como uma queda nos serviços, os engenheiros redigem em conjunto um relatório sobre as ações que influenciaram a causa raiz do problema, sem culpar funcionários específicos.
Vemos várias direções para pesquisas futuras com base em nosso trabalho.
Em primeiro lugar, uma revisão sistemática de artigos que caracterizam o impacto e o contexto das evidências para cada fator de produtividade discutido aqui melhorará a usabilidade de nosso trabalho, criando relações causais. Onde eles são fracos, a aplicabilidade pode ser melhorada conduzindo uma série de experimentos para estabelecer a causa.
Em segundo lugar, conforme mencionado nas Seções 4.5 e 4.6, os pesquisadores em potencial podem usar fatores adicionais sugeridos por nossos entrevistados e examinar a influência do gênero e outros fatores demográficos na produtividade do desenvolvedor.
Terceiro, o impacto da pesquisa de produtividade no desenvolvimento de software pode ser melhorado com um conjunto multidimensional de métricas e ferramentas que foram validadas por meio de pesquisa empírica e triangulação.
Quarto, se os pesquisadores puderem calcular o custo dos fatores de mudança que afetam a produtividade, as empresas podem tomar decisões de investimento mais inteligentes.
4,8. Riscos
Ao interpretar os resultados deste estudo, vários riscos para sua validade devem ser considerados.
4.8.1. Riscos para a precisão dos dados
Em primeiro lugar, falamos sobre apenas uma medição - a avaliação da sua produtividade. Existem outras dimensões, incluindo medidas objetivas, como o número de linhas de código escritas por dia, abordagem utilizada pelo Facebook [38]. Como apontamos na Seção 3.1, todas as métricas de produtividade têm falhas, incluindo a medição de sua própria produtividade. Por exemplo, os desenvolvedores podem ser muito frívolos na avaliação de sua produtividade, ou artificialmente superestimar sua avaliação devido ao viés da sociedade [39]. Apesar dessas deficiências, a equipe liderada por Zelenski baseia-se no trabalho anterior para argumentar a validade da avaliação de desempenho [40], que também é usada neste artigo.
Em segundo lugar, medimos nossa produtividade com uma única pergunta que dificilmente cobre todo o espectro de produtividade do desenvolvedor. Por exemplo, a questão se concentra na frequência e intensidade, mas não considera a qualidade. Também não pedimos aos entrevistados que limitassem suas respostas a um período de tempo específico, portanto, alguns participantes podem responder com base em suas experiências na semana anterior, enquanto outros avaliaram suas experiências no ano anterior. Em retrospecto, o estudo deve operar com um intervalo de tempo fixo.
Em terceiro lugar, devido ao número limitado de perguntas, baseamo-nos apenas naqueles fatores que foram investigados em trabalhos anteriores. As 48 perguntas que selecionamos podem não cobrir todos os aspectos dos comportamentos relacionados à produtividade. Ou os fatores que escolhemos podem ser muito gerais em certos casos. Por exemplo, em retrospecto, o fator relacionado às melhores “ferramentas e abordagens” (F14) pode ser mais poderoso se separarmos ferramentas de métodos.
4.8.2. Riscos internos para confiabilidade
Quarto, como mencionamos na seção 3.8, recorremos a trabalhos anteriores para estabelecer relações causais entre fatores e produtividade, mas a força das evidências para as relações pode variar. Pode acontecer que alguns fatores afetem a avaliação de sua produtividade apenas indiretamente, por meio de outros fatores, ou sua conexão geralmente tem o sentido oposto. Por exemplo, é provável que um fator importante na produtividade, o aumento do entusiasmo pelo trabalho (F1), possa realmente ser devido ao aumento da produtividade.
4.8.3. Riscos externos à confiabilidade
Quinto, embora tenhamos examinado três empresas razoavelmente diferentes, a generalização com outros tipos de empresas, com outras organizações e outros tipos de trabalhadores do conhecimento é limitada. Neste artigo, selecionamos analistas como representantes de não desenvolvedores, mas esta categoria inclui vários tipos de trabalhadores do conhecimento - médicos, arquitetos e advogados. Outro risco para a confiabilidade é o viés devido à falta de respostas: as pessoas que responderam aos questionários foram auto-selecionadas.
Em sexto lugar, analisamos cada fator de produtividade separadamente, mas muitos fatores podem acompanhar uns aos outros. Este não é um problema de análise, mas sim de aplicabilidade dos resultados. Se os fatores forem co-dependentes, mudar um pode afetar adversamente o outro.
4.8.4. Riscos para a
credibilidade construtiva Sétimo, ao criar este estudo, nos preocupamos com a possibilidade de os respondentes reconhecerem nossa metodologia de análise e não responderem com veracidade. Tentamos reduzir essa probabilidade separando a questão da produtividade de seus fatores, mas os respondentes podem ter conseguido tirar conclusões sobre nossa metodologia de análise.
Finalmente, reformulamos algumas das questões para adequar o estudo aos analistas, o que poderia alterar de forma indesejável o significado das questões. Consequentemente, as diferenças entre desenvolvedores e analistas podem ter surgido de diferenças nas questões, e não na profissão.
5. Trabalho relacionado
Muitos pesquisadores estudaram fatores de produtividade individuais para desenvolvedores de software. Por exemplo, Moser e Nierstrasz analisaram 36 projetos de desenvolvimento de software e investigaram o impacto potencial das tecnologias orientadas a objetos na melhoria da produtividade do desenvolvedor [41].
Outro exemplo é o estudo de DeMarco e Lister com 166 programadores de 35 organizações fazendo um exercício de programação de um dia. Os autores descobriram que o local de trabalho e a organização estão associados à produtividade [42].
Um terceiro exemplo é um experimento de laboratório de Kersten e Murphy com 16 desenvolvedores. Descobriu-se que aqueles que usaram a ferramenta para se concentrar na tarefa eram muito mais produtivos do que outros [43].
Além disso, a análise sistemática de Wagner e Rouet dá uma boa idéia da relação entre fatores individuais e produtividade [14]. A equipe liderada por Mayer ofereceu uma análise ainda mais recente da visão geral dos fatores de produtividade [3]. Em geral, nosso trabalho é baseado nesses estudos de fatores individuais com um estudo mais amplo de sua diversidade.
A revisão sistemática de Petersen afirma que sete artigos quantificam fatores que predizem a produtividade do desenvolvedor de software [44]. Em cada trabalho, métodos numéricos são usados para previsão, geralmente é a regressão, que também usamos em nossas pesquisas. Os fatores mais comuns estão relacionados ao tamanho do projeto, e 6 dos 7 fatores são explicitamente formulados com base nos drivers de produtividade do COCOMO II ([6], [27], [28], [29], [30], [31]). O modelo de previsão mais complexo do estudo de Petersen usa 16 fatores [6].
Nosso trabalho tem duas diferenças principais. Em primeiro lugar, em comparação com trabalhos anteriores, estimamos mais fatores (48), e sua variedade é maior. Selecionamos fatores com base na psicologia industrial e organizacional. Em segundo lugar, tínhamos um assunto diferente para análise: pesquisadores anteriores estudaram o que poderia prever a produtividade no âmbito do projeto e estávamos interessados na produtividade pessoal das pessoas.
Além do desenvolvimento de software, estudos anteriores compararam fatores que predizem a produtividade em outras profissões, em particular, no campo da psicologia industrial e organizacional. Embora tais estudos tenham se concentrado na produtividade no nível da empresa [45] e no trabalho físico, como a manufatura [46], a área mais intimamente relacionada é a produtividade dos trabalhadores do conhecimento. Ou seja, pessoas que usam ativamente conhecimento e informação em seu trabalho, geralmente usando um computador [47]. Uma comparação de fatores para tais profissões é apresentada em dois trabalhos principais. O primeiro é um estudo de equipe liderado por Palwalin, explorando 38 fatores que estudos anteriores compararam com a produtividade. Esses fatores abrangem o espaço de trabalho físico, virtual e social,abordagens pessoais de trabalho e bem-estar no trabalho [4]. O segundo é um estudo de Hernaus e Mikulich com 512 trabalhadores do conhecimento. Os autores estudaram 14 fatores, divididos em três categorias [9]. Contamos com esses dois trabalhos para preparar nosso estudo (Seção 3.2).
No entanto, estudos comparando fatores de produtividade para trabalhadores do conhecimento não prestaram atenção aos desenvolvedores de software. Existem duas razões principais para isso. Primeiro, não está claro até que ponto os resultados gerais obtidos são projetados para os desenvolvedores. Em segundo lugar, tais estudos são geralmente abstraídos de fatores específicos do desenvolvedor, como reutilização de software e complexidade da base de código [48]. Portanto, existe uma lacuna na literatura no entendimento dos fatores que permitem prever a produtividade do desenvolvedor. Preencher essa lacuna é prático. Criamos três equipes de pesquisa em três empresas para melhorar a produtividade. Preencher essa lacuna de conhecimento ajuda nossas equipes a pesquisar e as empresas a investirem na produtividade do desenvolvedor.
6. Conclusão
Existem muitos fatores que afetam a produtividade do desenvolvedor, mas as organizações têm recursos limitados para se concentrar em melhorar a produtividade. Criamos e conduzimos um estudo em três empresas para classificar e comparar diferentes fatores. Desenvolvedores e líderes podem usar nossas descobertas para priorizar seus esforços. Para simplificar, artigos anteriores sugeriram muitas maneiras de melhorar a produtividade dos desenvolvedores de software e sugerimos como você pode priorizar essas maneiras.

Bloco de perguntas
O que torna um desenvolvedor produtivo?
Esta pesquisa anônima de uma página levará 15 minutos e nos ajudará a entender melhor o que afeta a produtividade do desenvolvedor. Por favor, responda aberta e honestamente.
A pesquisa fará perguntas sobre você, seu projeto e seu software. Lembre-se:
Meu software se refere ao software principal que você desenvolve na ABB, incluindo produtos e infraestrutura. Se você estiver trabalhando em programas diferentes, responda apenas no principal.
Meu projeto pertence à equipe com a qual você cria software. Responda a todas as perguntas relacionadas sobre outros desenvolvedores de software na ABB.
Algumas questões tocam em tópicos potencialmente delicados. Preencha as respostas para que ninguém possa espiar por cima do seu ombro e limpe o histórico e os cookies do seu navegador após preencher o questionário.
Avalie o seu acordo com as seguintes afirmações.
Lista de questões de pesquisa





Essas perguntas foram elaboradas para fornecer uma avaliação abrangente dos fatores que podem afetar a produtividade. Estamos perdendo alguma coisa?
Sexo (opcional)
Qual é o seu cargo? (opcional)
Em que ano você ingressou na ABB?
Materiais adicionais
Fatores de produtividade observados pelos entrevistados
Nesta seção, listamos os fatores que os entrevistados descreveram em suas respostas à pergunta aberta. Primeiro, descreveremos vários fatores novos e, em seguida, daremos descrições de fatores relacionados àqueles já no estudo. Complementamos os comentários dos entrevistados com códigos usando nossos fatores. Aqui não discutimos ou avaliamos as respostas das pessoas, não suplementamos as descrições existentes de nossos fatores.
Novos fatores
Nos comentários, foram levantados 4 tópicos que não se refletiram em nosso estudo. Seis respostas levantaram tópicos da equipe de projeto mista, em particular a proporção de gerentes para desenvolvedores; a presença de um número suficiente de funcionários no projeto; e se a administração é capaz de manter forte propriedade do produto. Um entrevistado observou o impacto na produtividade do tipo de software (servidor, cliente, móvel, etc.). Outro observou a influência de fatores fisiológicos como o número de horas de sono. Outro mencionou as oportunidades de crescimento pessoal.
Fatores disponíveis
F1. Cinco entrevistados mencionaram fatores relacionados ao entusiasmo no trabalho: dois mencionaram motivação e reconhecimento no trabalho, um - moralidade e um - um prédio comercial deprimente.
F3. Quatro dos entrevistados notaram fatores relacionados à autonomia na escolha dos métodos de trabalho. Um mencionou a autonomia ao nível da equipa, outro sobre a política que impede a utilização de um bom sistema open source, o terceiro sobre as prioridades adoptadas na empresa que limitam a utilização de determinadas técnicas em equipa.
F4. Um entrevistado observou autonomia no agendamento do horário de trabalho, que se limita às prioridades ditadas pela necessidade de promoção.
F5. Três entrevistados notaram competência de liderança. Um mencionou liderança com uma estratégia coerente, o segundo - prioridades conflitantes transmitidas pela gerência e o terceiro - gerenciar a produtividade dos funcionários.
F6. Oito entrevistados disseram ter fornecido informações precisas. Três mencionaram a comunicação entre as equipes por meio de documentação (e outros canais), e dois mencionaram a clareza das metas e planos da equipe.
F7. Dois entrevistados notaram sentimentos positivos em relação aos colegas à luz da equipe e da coesão da equipe.
F8. Um entrevistado observou autonomia para fazer o trabalho: a política da empresa dita quais recursos podem ser usados.
F9. Um entrevistado observou a resolução de conflitos, indicando que os hábitos pessoais dos colegas de equipe eram contrários às normas sociais.
F10. Quatro entrevistados observaram a competência dos desenvolvedores. Um mencionou as dificuldades de compreensão do código, o outro - o conhecimento da área temática, o terceiro - a seriedade da atitude em relação aos testes.
F11. Um entrevistado observou feedback sobre a produtividade do trabalho: obtenção de reconhecimento de colegas e da gerência, promoção.
F12. Um entrevistado observou a complexidade da implementação do software “do meu cérebro até o produto enviado”.
F13. Dois entrevistados notaram a variedade de tarefas, em particular, interceptar tarefas em nome de sua equipe e mudança de contexto.
F14 Quatro entrevistados classificaram o pessoal de requisitos e arquitetura como competentes. Um mencionou atenção insuficiente aos problemas, outro - a legibilidade dos documentos arquitetônicos, o terceiro - a qualidade dos planos do projeto, o quarto - a disponibilidade de "suporte adequado no desenvolvimento de requisitos".
F15. Trinta e dois entrevistados relataram usar as melhores ferramentas e abordagens. Doze mencionou o desempenho das ferramentas, especialmente os problemas de velocidade e latência na construção e teste. Cinco pessoas mencionaram os recursos disponíveis, três mencionaram problemas de compatibilidade e migração, duas mencionaram que mesmo a melhor ferramenta disponível pode não atender às necessidades. Outros comentários sobre ferramentas e abordagem mencionaram o nível de automação oferecido pelas ferramentas; depuradores e simuladores especializados; Abordagens ágeis; testes instáveis e ferramentas relacionadas; ferramentas que funcionam bem remotamente; escolha de linguagens de programação; ferramentas desatualizadas; separação das preferências pessoais nas ferramentas das adotadas na empresa.
F16. Dezenove entrevistados notaram uma transferência adequada de conhecimento entre as pessoas. Nove pessoas mencionaram as dificuldades de comunicação com outras equipes: três - acordo de metas entre equipes, uma - acordo de metas dentro de uma grande equipe, outra - chegar a um acordo entre equipes. Dois notaram a dificuldade de coordenar o trabalho em uma equipe internacional ou de fuso horário. Outros dois mencionaram a necessidade de contar com a documentação de outras equipes. Dois comentaram sobre a duração da revisão do código. Dois outros mencionaram a conscientização sobre as instalações de trabalho dos companheiros. Um mencionou a busca pela pessoa certa, outro - demora na interação, o terceiro - comunicação entre engenheiros e especialistas da área. Por fim, mencionou-se a importância de deixar claroquais canais de comunicação são melhores para usar em determinadas situações.
F18. Dois entrevistados observaram abordagens para a realização de reuniões, um mencionou que a eficácia das reuniões depende da disponibilidade de salas de reunião.
F19. Vinte e quatro entrevistados notaram interrupções e distrações do trabalho. Dez mencionaram ambientes ruidosos e sete indicaram que escritórios abertos reduzem a produtividade. Quatro mencionaram dificuldades com multitarefa e troca de contexto. Outros quatro relataram a necessidade de focar no trabalho principal ou em tarefas “opcionais” como entrevistas. Dois mencionaram dificuldade de concentração no trajeto de ida e volta para o trabalho.
F25. Um entrevistado observou a reutilização de código, apontando que as APIs de 2 a 3 linhas aumentam a complexidade com contribuição mínima para reduzir a duplicação.
F26. Um entrevistado comentou sobre a experiência com uma plataforma de software, indicando que os problemas se agravam quando um desenvolvedor alterna entre projetos.
F27. Três entrevistados observaram arquitetura de software e redução de risco. Um apontou "quão conhecida é a arquitetura do produto, quão interconectada ela é e como ela apóia as pessoas que conhecem suas funções e são capazes de se concentrar, que conhecem suas responsabilidades e limitações e o que elas possuem". Outro observou que a arquitetura, por meio da modularidade, pode facilitar a troca entre componentes de software. O terceiro sugeriu que a arquitetura deve ser consistente com a estrutura da organização.
F32. Quatro entrevistados mencionaram a necessidade de mudança de contexto. Dois mencionaram que a troca é necessária ao se mover entre projetos. Um explicou que a necessidade de troca de contexto é diferente do prazer de trocar. Outro mencionou que “projetos de produtividade” por si só podem reduzir a produtividade.
F34. Cinco entrevistados observaram prazos apertados. Um apontou que isso contribui para o crescimento do endividamento técnico, o outro - que tais prazos podem levar ao desperdício de recursos.
F42. Três entrevistados notaram limitações de software. Dois apontaram para restrições de privacidade e um para restrições de segurança críticas.
F44. Onze entrevistados notaram a complexidade do software. Dois mencionaram a complexidade particular do código legado, dois se referiram a dívidas técnicas e cada um observou o controle de versão, manutenção de software e
compreensão do código.
Coefficients:
Estimate Std. Error t value Pr(>|t|)
(Intercept) 2.786969 0.111805 24.927 < 0.0000000000000002 ***
log(lines_changed + 1) 0.045189 0.009296 4.861 0.00000122 ***
level -0.050649 0.015833 -3.199 0.00139 **
job_codeENG_TYPE2 0.194108 0.172096 1.128 0.25944
job_codeENG_TYPE3 0.034189 0.076718 0.446 0.65589
job_codeENG_TYPE4 -0.185930 0.084484 -2.201 0.02782 *
job_codeENG_TYPE5 -0.375294 0.085896 -4.369 0.00001285 ***
---
Signif. codes: 0 `***` 0.001 `**` 0.01 `*` 0.05 `.` 0.1 ` ` 1
Residual standard error: 0.8882 on 3388 degrees of freedom
Multiple R-squared: 0.01874, Adjusted R-squared: 0.017
F-statistic: 10.78 on 6 and 3388 DF, p-value: 0.000000000006508
Figura: 5: Modelo 1: Resultados da Regressão Linear Completa
Coefficients:
Estimate Std. Error t value Pr(>|t|)
(Intercept) 2.74335 0.09706 28.265 < 0.0000000000000002
log(changelists_created + 1) 0.11220 0.01608 6.977 0.00000000000362
level -0.04999 0.01574 -3.176 0.00151
job_codeENG_TYPE2 0.27044 0.17209 1.571 0.11616
job_codeENG_TYPE3 0.02451 0.07644 0.321 0.74847
job_codeENG_TYPE4 -0.21640 0.08411 -2.573 0.01013
job_codeENG_TYPE5 -0.40194 0.08559 -4.696 0.00000275538534
(Intercept) ***
log(changelists_created + 1) ***
level **
job_codeENG_TYPE2
job_codeENG_TYPE3
job_codeENG_TYPE4 *
job_codeENG_TYPE5 ***
---
Signif. codes: 0 `***` 0.001 `**` 0.01 `*` 0.05 `.` 0.1 ` ` 1
Residual standard error: 0.885 on 3388 degrees of freedom
Multiple R-squared: 0.02589, Adjusted R-squared: 0.02416
F-statistic: 15.01 on 6 and 3388 DF, p-value: < 0.00000000000000022
Figura: 6: Modelo 2: Resultados da Regressão Linear Completa
Coefficients:
Estimate Std. Error t value Pr(>|t|)
(Intercept) 2.79676 0.11141 25.102 < 0.0000000000000002
log(lines_changed + 1) -0.01462 0.01498 -0.976 0.32897
log(changelists_created + 1) 0.13215 0.02600 5.082 0.000000394
level -0.05099 0.01578 -3.233 0.00124
job_codeENG_TYPE2 0.27767 0.17226 1.612 0.10706
job_codeENG_TYPE3 0.02226 0.07647 0.291 0.77102
job_codeENG_TYPE4 -0.22446 0.08452 -2.656 0.00795
job_codeENG_TYPE5 -0.40819 0.08583 -4.756 0.000002057
(Intercept) ***
log(lines_changed + 1)
log(changelists_created + 1) ***
level **
job_codeENG_TYPE2
job_codeENG_TYPE3
job_codeENG_TYPE4 **
job_codeENG_TYPE5 ***
---
Signif. codes: 0 `***` 0.001 `**` 0.01 `*` 0.05 `.` 0.1 ` ` 1
Residual standard error: 0.885 on 3387 degrees of freedom
Multiple R-squared: 0.02616, Adjusted R-squared: 0.02415
F-statistic: 13 on 7 and 3387 DF, p-value: < 0.00000000000000022
Figura: 7: Modelo 3: Resultados da regressão linear completa.
Bibliografia
[1] R. S. Nickerson, “Confirmation bias: A ubiquitous phenomenon in many guises.” Review of general psychology, vol. 2, no. 2, p. 175, 1998.
[2] Y. W. Ramírez and D. A. Nembhard, “Measuring knowledge worker productivity: A taxonomy,” Journal of Intellectual Capital, vol. 5, no. 4, pp. 602–628, 2004.
[3] A. N. Meyer, L. E. Barton, G. C. Murphy, T. Zimmermann, and T. Fritz, “The work life of developers: Activities, switches and perceived productivity,” IEEE Transactions on Software Engineering, 2017.
[4] M. Palvalin, M. Vuolle, A. Jääskeläinen, H. Laihonen, and A. Lönnqvist, “Smartwow–constructing a tool for knowledge work performance analysis,” International Journal of Productivity and Performance Management, vol. 64, no. 4, pp. 479–498, 2015.
[5] C. H. C. Duarte, “Productivity paradoxes revisited,” Empirical Software Engineering, pp. 1–30, 2016.
[6] K. D. Maxwell, L. VanWassenhove, and S. Dutta, “Software development productivity of european space, military, and industrial applications,” IEEE Transactions on Software Engineering, vol. 22, no. 10, pp. 706–718, 1996.
[7] J. D. Blackburn, G. D. Scudder, and L. N. Van Wassenhove, “Improving speed and productivity of software development: a global survey of software developers,” IEEE transactions on software engineering, vol. 22, no. 12, pp. 875–885, 1996.
[8] B. Vasilescu, Y. Yu, H.Wang, P. Devanbu, and V. Filkov, “Quality and productivity outcomes relating to continuous integration in github,” in Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering. ACM, 2015, pp. 805–816.
[9] T. Hernaus and J. Mikulic, “Work characteristics and work performance of knowledge workers,” EuroMed Journal of Business, vol. 9, no. 3, pp. 268–292, 2014.
[10] F. P. Morgeson and S. E. Humphrey, “The work design questionnaire (wdq): developing and validating a comprehensive measure for assessing job design and the nature of work.” Journal of applied psychology, vol. 91, no. 6, p. 1321, 2006.
[11] J. R. Idaszak and F. Drasgow, “A revision of the job diagnostic survey: Elimination of a measurement artifact.” Journal of Applied Psychology, vol. 72, no. 1, p. 69, 1987.
[12] M. A. Campion, G. J. Medsker, and A. C. Higgs, “Relations between work group characteristics and effectiveness: Implications for designing effective work groups,” Personnel psychology, vol. 46, no. 4, pp. 823–847, 1993.
[13] T. Hernaus, “Integrating macro-and micro-organizational variables through multilevel approach,” Unpublished doctoral thesis). Zagreb: University of Zagreb, 2010.
[14] S. Wagner and M. Ruhe, “A systematic review of productivity factors in software development,” in Proceedings of 2nd International Workshop on Software Productivity Analysis and Cost Estimation, 2008.
[15] A. N. Meyer, T. Fritz, G. C. Murphy, and T. Zimmermann, “Software developers’ perceptions of productivity,” in Proceedings of the International Symposium on Foundations of Software Engineering. ACM, 2014, pp. 19–29.
[16] R. Antikainen and A. Lönnqvist, “Knowledge work productivity assessment,” Tampere University of Technology, Tech. Rep., 2006.
[17] M. Galesic and M. Bosnjak, “Effects of questionnaire length on participation and indicators of response quality in a web survey,” Public opinion quarterly, vol. 73, no. 2, pp. 349–360, 2009.
[18] L. Beckwith, C. Kissinger, M. Burnett, S. Wiedenbeck, J. Lawrance, A. Blackwell, and C. Cook, “Tinkering and gender in end-user programmers’ debugging,” in Proceedings of the SIGCHI conference on Human Factors in computing systems. ACM, 2006, pp. 231–240.
[19] D. B. Rubin, Multiple imputation for nonresponse in surveys. John Wiley & Sons, 2004, vol. 81.
[20] A. W. Meade and S. B. Craig, “Identifying careless responses in survey data.” Psychological methods, vol. 17, no. 3, p. 437, 2012.
[21] E. Smith, R. Loftin, E. Murphy-Hill, C. Bird, and T. Zimmermann, “Improving developer participation rates in surveys,” in Proceedings of Cooperative and Human Aspects on Software Engineering, 2013.
[22] Y. Benjamini and Y. Hochberg, “Controlling the false discovery rate: a practical and powerful approach to multiple testing,” Journal of the royal statistical society. Series B (Methodological),
pp. 289–300, 1995.
[23] R. A. Guzzo, R. D. Jette, and R. A. Katzell, “The effects of psychologically based intervention programs on worker productivity: A meta-analysis,” Personnel psychology, vol. 38, no. 2, pp.
275–291, 1985.
[24] D. Graziotin, X. Wang, and P. Abrahamsson, “Happy software developers solve problems better: psychological measurements in empirical software engineering,” PeerJ, vol. 2, p. e289, 2014.
[25] J. Noll, M. A. Razzak, and S. Beecham, “Motivation and autonomy in global software development: an empirical study,” in Proceedings of the 21st International Conference on Evaluation
and Assessment in Software Engineering. ACM, 2017, pp. 394–399.
[26] B. Clark, S. Devnani-Chulani, and B. Boehm, “Calibrating the cocomo ii post-architecture model,” in Proceedings of the International Conference on Software Engineering. IEEE, 1998, pp. 477–480.
[27] B. Kitchenham and E. Mendes, “Software productivity measurement using multiple size measures,” IEEE Transactions on Software Engineering, vol. 30, no. 12, pp. 1023–1035, 2004.
[28] S. L. Pfleeger, “Model of software effort and productivity,” Information and Software Technology, vol. 33, no. 3, pp. 224–231, 1991.
[29] G. Finnie and G. Wittig, “Effect of system and team size on 4gl software development productivity,” South African Computer Journal, pp. 18–18, 1994.
[30] D. R. Jeffery, “A software development productivity model for mis environments,” Journal of Systems and Software, vol. 7, no. 2, pp. 115–125, 1987.
[31] L. R. Foulds, M. Quaddus, and M. West, “Structural equation modelling of large-scale information system application development productivity: the hong kong experience,” in Computer and Information Science, 2007. ICIS 2007. 6th IEEE/ACIS International Conference on. IEEE, 2007, pp. 724–731.
[32] C. Parnin and S. Rugaber, “Resumption strategies for interrupted programming tasks,” Software Quality Journal, vol. 19, no. 1, pp. 5–34, 2011.
[33] C. Parnin and R. DeLine, “Evaluating cues for resuming interrupted programming tasks,” in Proceedings of the SIGCHI conference on human factors in computing systems. ACM, 2010, pp. 93–102.
[34] S. Markos and M. S. Sridevi, “Employee engagement: The key to improving performance,” International Journal of Business and Management, vol. 5, no. 12, pp. 89–96, 2010.
[35] W. Snipes, A. R. Nair, and E. Murphy-Hill, “Experiences gamifying developer adoption of practices and tools,” in Companion Proceedings of the 36th International Conference on Software Engineering. ACM, 2014, pp. 105–114.
[36] J. S. Brown and P. Duguid, “Balancing act: How to capture knowledge without killing it.” Harvard business review, vol. 78, no. 3, pp. 73–80, 1999.
[37] M. London and J. W. Smither, “Feedback orientation, feedback culture, and the longitudinal performance management process,” Human Resource Management Review, vol. 12, no. 1,
pp. 81–100, 2002.
[38] T. Savor, M. Douglas, M. Gentili, L. Williams, K. Beck, and M. Stumm, “Continuous deployment at facebook and oanda,” in Proceedings of the 38th International Conference on Software Engineering Companion. ACM, 2016, pp. 21–30.
[39] R. J. Fisher, “Social desirability bias and the validity of indirect questioning,” Journal of consumer research, vol. 20, no. 2, pp. 303–315, 1993.
[40] J. M. Zelenski, S. A. Murphy, and D. A. Jenkins, “The happyproductive worker thesis revisited,” Journal of Happiness Studies, vol. 9, no. 4, pp. 521–537, 2008.
[41] S. Moser and O. Nierstrasz, “The effect of object-oriented frameworks on developer productivity,” Computer, vol. 29, no. 9, pp. 45–51, 1996.
[42] T. DeMarco and T. Lister, “Programmer performance and the effects of the workplace,” in Proceedings of the International Conference on Software Engineering. IEEE Computer Society
Press, 1985, pp. 268–272.
[43] M. Kersten and G. C. Murphy, “Using task context to improve programmer productivity,” in Proceedings of the 14th ACM SIGSOFT international symposium on Foundations of software engineering. ACM, 2006, pp. 1–11.
[44] K. Petersen, “Measuring and predicting software productivity: A systematic map and review,” Information and Software Technology, vol. 53, no. 4, pp. 317–343, 2011.
[45] M. J. Melitz, “The impact of trade on intra-industry reallocations and aggregate industry productivity,” Econometrica, vol. 71, no. 6, pp. 1695–1725, 2003.
[46] M. N. Baily, C. Hulten, D. Campbell, T. Bresnahan, and R. E. Caves, “Productivity dynamics in manufacturing plants,” Brookings papers on economic activity. Microeconomics, vol. 1992, pp. 187–267, 1992.
[47] A. Kidd, “The marks are on the knowledge worker,” in Proceedings of the SIGCHI conference on Human factors in computing systems. ACM, 1994, pp. 186–191.
[48] G. K. Gill and C. F. Kemerer, “Cyclomatic complexity density and software maintenance productivity,” IEEE transactions on software engineering, vol. 17, no. 12, pp. 1284–1288, 1991.
[2] Y. W. Ramírez and D. A. Nembhard, “Measuring knowledge worker productivity: A taxonomy,” Journal of Intellectual Capital, vol. 5, no. 4, pp. 602–628, 2004.
[3] A. N. Meyer, L. E. Barton, G. C. Murphy, T. Zimmermann, and T. Fritz, “The work life of developers: Activities, switches and perceived productivity,” IEEE Transactions on Software Engineering, 2017.
[4] M. Palvalin, M. Vuolle, A. Jääskeläinen, H. Laihonen, and A. Lönnqvist, “Smartwow–constructing a tool for knowledge work performance analysis,” International Journal of Productivity and Performance Management, vol. 64, no. 4, pp. 479–498, 2015.
[5] C. H. C. Duarte, “Productivity paradoxes revisited,” Empirical Software Engineering, pp. 1–30, 2016.
[6] K. D. Maxwell, L. VanWassenhove, and S. Dutta, “Software development productivity of european space, military, and industrial applications,” IEEE Transactions on Software Engineering, vol. 22, no. 10, pp. 706–718, 1996.
[7] J. D. Blackburn, G. D. Scudder, and L. N. Van Wassenhove, “Improving speed and productivity of software development: a global survey of software developers,” IEEE transactions on software engineering, vol. 22, no. 12, pp. 875–885, 1996.
[8] B. Vasilescu, Y. Yu, H.Wang, P. Devanbu, and V. Filkov, “Quality and productivity outcomes relating to continuous integration in github,” in Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering. ACM, 2015, pp. 805–816.
[9] T. Hernaus and J. Mikulic, “Work characteristics and work performance of knowledge workers,” EuroMed Journal of Business, vol. 9, no. 3, pp. 268–292, 2014.
[10] F. P. Morgeson and S. E. Humphrey, “The work design questionnaire (wdq): developing and validating a comprehensive measure for assessing job design and the nature of work.” Journal of applied psychology, vol. 91, no. 6, p. 1321, 2006.
[11] J. R. Idaszak and F. Drasgow, “A revision of the job diagnostic survey: Elimination of a measurement artifact.” Journal of Applied Psychology, vol. 72, no. 1, p. 69, 1987.
[12] M. A. Campion, G. J. Medsker, and A. C. Higgs, “Relations between work group characteristics and effectiveness: Implications for designing effective work groups,” Personnel psychology, vol. 46, no. 4, pp. 823–847, 1993.
[13] T. Hernaus, “Integrating macro-and micro-organizational variables through multilevel approach,” Unpublished doctoral thesis). Zagreb: University of Zagreb, 2010.
[14] S. Wagner and M. Ruhe, “A systematic review of productivity factors in software development,” in Proceedings of 2nd International Workshop on Software Productivity Analysis and Cost Estimation, 2008.
[15] A. N. Meyer, T. Fritz, G. C. Murphy, and T. Zimmermann, “Software developers’ perceptions of productivity,” in Proceedings of the International Symposium on Foundations of Software Engineering. ACM, 2014, pp. 19–29.
[16] R. Antikainen and A. Lönnqvist, “Knowledge work productivity assessment,” Tampere University of Technology, Tech. Rep., 2006.
[17] M. Galesic and M. Bosnjak, “Effects of questionnaire length on participation and indicators of response quality in a web survey,” Public opinion quarterly, vol. 73, no. 2, pp. 349–360, 2009.
[18] L. Beckwith, C. Kissinger, M. Burnett, S. Wiedenbeck, J. Lawrance, A. Blackwell, and C. Cook, “Tinkering and gender in end-user programmers’ debugging,” in Proceedings of the SIGCHI conference on Human Factors in computing systems. ACM, 2006, pp. 231–240.
[19] D. B. Rubin, Multiple imputation for nonresponse in surveys. John Wiley & Sons, 2004, vol. 81.
[20] A. W. Meade and S. B. Craig, “Identifying careless responses in survey data.” Psychological methods, vol. 17, no. 3, p. 437, 2012.
[21] E. Smith, R. Loftin, E. Murphy-Hill, C. Bird, and T. Zimmermann, “Improving developer participation rates in surveys,” in Proceedings of Cooperative and Human Aspects on Software Engineering, 2013.
[22] Y. Benjamini and Y. Hochberg, “Controlling the false discovery rate: a practical and powerful approach to multiple testing,” Journal of the royal statistical society. Series B (Methodological),
pp. 289–300, 1995.
[23] R. A. Guzzo, R. D. Jette, and R. A. Katzell, “The effects of psychologically based intervention programs on worker productivity: A meta-analysis,” Personnel psychology, vol. 38, no. 2, pp.
275–291, 1985.
[24] D. Graziotin, X. Wang, and P. Abrahamsson, “Happy software developers solve problems better: psychological measurements in empirical software engineering,” PeerJ, vol. 2, p. e289, 2014.
[25] J. Noll, M. A. Razzak, and S. Beecham, “Motivation and autonomy in global software development: an empirical study,” in Proceedings of the 21st International Conference on Evaluation
and Assessment in Software Engineering. ACM, 2017, pp. 394–399.
[26] B. Clark, S. Devnani-Chulani, and B. Boehm, “Calibrating the cocomo ii post-architecture model,” in Proceedings of the International Conference on Software Engineering. IEEE, 1998, pp. 477–480.
[27] B. Kitchenham and E. Mendes, “Software productivity measurement using multiple size measures,” IEEE Transactions on Software Engineering, vol. 30, no. 12, pp. 1023–1035, 2004.
[28] S. L. Pfleeger, “Model of software effort and productivity,” Information and Software Technology, vol. 33, no. 3, pp. 224–231, 1991.
[29] G. Finnie and G. Wittig, “Effect of system and team size on 4gl software development productivity,” South African Computer Journal, pp. 18–18, 1994.
[30] D. R. Jeffery, “A software development productivity model for mis environments,” Journal of Systems and Software, vol. 7, no. 2, pp. 115–125, 1987.
[31] L. R. Foulds, M. Quaddus, and M. West, “Structural equation modelling of large-scale information system application development productivity: the hong kong experience,” in Computer and Information Science, 2007. ICIS 2007. 6th IEEE/ACIS International Conference on. IEEE, 2007, pp. 724–731.
[32] C. Parnin and S. Rugaber, “Resumption strategies for interrupted programming tasks,” Software Quality Journal, vol. 19, no. 1, pp. 5–34, 2011.
[33] C. Parnin and R. DeLine, “Evaluating cues for resuming interrupted programming tasks,” in Proceedings of the SIGCHI conference on human factors in computing systems. ACM, 2010, pp. 93–102.
[34] S. Markos and M. S. Sridevi, “Employee engagement: The key to improving performance,” International Journal of Business and Management, vol. 5, no. 12, pp. 89–96, 2010.
[35] W. Snipes, A. R. Nair, and E. Murphy-Hill, “Experiences gamifying developer adoption of practices and tools,” in Companion Proceedings of the 36th International Conference on Software Engineering. ACM, 2014, pp. 105–114.
[36] J. S. Brown and P. Duguid, “Balancing act: How to capture knowledge without killing it.” Harvard business review, vol. 78, no. 3, pp. 73–80, 1999.
[37] M. London and J. W. Smither, “Feedback orientation, feedback culture, and the longitudinal performance management process,” Human Resource Management Review, vol. 12, no. 1,
pp. 81–100, 2002.
[38] T. Savor, M. Douglas, M. Gentili, L. Williams, K. Beck, and M. Stumm, “Continuous deployment at facebook and oanda,” in Proceedings of the 38th International Conference on Software Engineering Companion. ACM, 2016, pp. 21–30.
[39] R. J. Fisher, “Social desirability bias and the validity of indirect questioning,” Journal of consumer research, vol. 20, no. 2, pp. 303–315, 1993.
[40] J. M. Zelenski, S. A. Murphy, and D. A. Jenkins, “The happyproductive worker thesis revisited,” Journal of Happiness Studies, vol. 9, no. 4, pp. 521–537, 2008.
[41] S. Moser and O. Nierstrasz, “The effect of object-oriented frameworks on developer productivity,” Computer, vol. 29, no. 9, pp. 45–51, 1996.
[42] T. DeMarco and T. Lister, “Programmer performance and the effects of the workplace,” in Proceedings of the International Conference on Software Engineering. IEEE Computer Society
Press, 1985, pp. 268–272.
[43] M. Kersten and G. C. Murphy, “Using task context to improve programmer productivity,” in Proceedings of the 14th ACM SIGSOFT international symposium on Foundations of software engineering. ACM, 2006, pp. 1–11.
[44] K. Petersen, “Measuring and predicting software productivity: A systematic map and review,” Information and Software Technology, vol. 53, no. 4, pp. 317–343, 2011.
[45] M. J. Melitz, “The impact of trade on intra-industry reallocations and aggregate industry productivity,” Econometrica, vol. 71, no. 6, pp. 1695–1725, 2003.
[46] M. N. Baily, C. Hulten, D. Campbell, T. Bresnahan, and R. E. Caves, “Productivity dynamics in manufacturing plants,” Brookings papers on economic activity. Microeconomics, vol. 1992, pp. 187–267, 1992.
[47] A. Kidd, “The marks are on the knowledge worker,” in Proceedings of the SIGCHI conference on Human factors in computing systems. ACM, 1994, pp. 186–191.
[48] G. K. Gill and C. F. Kemerer, “Cyclomatic complexity density and software maintenance productivity,” IEEE transactions on software engineering, vol. 17, no. 12, pp. 1284–1288, 1991.