Las empresas pueden ayudar a sus desarrolladores a maximizar su productividad de varias formas, desde cambiar el espacio de oficina hasta adquirir mejores herramientas y limpiar el código fuente. Pero, ¿qué decisiones tendrán el mayor impacto? Basándonos en la literatura sobre desarrollo de software y psicología industrial / organizacional, identificamos factores relacionados con la productividad y entrevistamos a 622 desarrolladores de tres empresas. Nos interesaron los factores mencionados y cómo las propias personas evalúan su propia productividad. Nuestros resultados sugieren que la autoestima está más influenciada por factores no técnicos: entusiasmo en el trabajo, el apoyo de sus compañeros para nuevas ideas y comentarios útiles sobre su productividad. En comparación con otros trabajadores del conocimiento,La evaluación de la productividad de los desarrolladores de software depende más de la variedad de tareas y de la capacidad de trabajar de forma remota.

1. Introducción

Es importante mejorar la productividad de los desarrolladores. Por definición, cuando completan sus tareas, pueden dedicar el tiempo libre a otras tareas útiles: introducir nuevas funciones y nuevos controles. Pero, ¿qué ayuda a los desarrolladores a ser más productivos?



Las empresas necesitan orientación práctica sobre qué factores manipular para maximizar la productividad. Por ejemplo, ¿un desarrollador debería dedicar tiempo a buscar mejores herramientas y enfoques, o debería desactivar las notificaciones durante el día? ¿Debería un líder invertir en refactorización para reducir la complejidad del código o dar a los desarrolladores más autonomía? ¿Deberían los jefes invertir en mejores herramientas de desarrollo o en una oficina más cómoda? En un mundo ideal, invertiríamos en varios factores para aumentar la productividad, pero el tiempo y el dinero son limitados, así que tenemos que elegir.



Este artículo trata sobre el estudio más amplio de pronóstico de productividad de desarrolladores de software hasta la fecha. Como se describe en la sección 3.1, la productividad se puede medir objetivamente (por ejemplo, en líneas de código por mes) o subjetivamente (según lo estimado por el propio desarrollador). Si bien ninguno de los enfoques es preferible, hemos tratado de cubrir el tema de manera amplia con un juicio subjetivo para responder a tres preguntas:

1. ¿Cuáles son los factores que mejor predicen la calificación de desempeño de un desarrollador?
2. ¿Cómo cambian estos factores de una empresa a otra?
3. ¿Qué predice la evaluación de un desarrollador de su productividad, en particular, en comparación con otros trabajadores del conocimiento?

Para responder a la primera pregunta, realizamos un estudio en una gran empresa de software.



Para responder a la segunda pregunta, que ayuda a comprender hasta qué punto se pueden generalizar los resultados obtenidos, realizamos un estudio en dos empresas de diferentes industrias.



Para responder a la tercera pregunta, que ayuda a comprender en qué se diferencian los desarrolladores de otros, realizamos un estudio entre representantes de otras profesiones y lo comparamos con los resultados obtenidos en el estudio de desarrolladores.



Nuestros resultados muestran que en las empresas que estudiamos, la autoestima por su productividad está fuertemente influenciada por el entusiasmo en el trabajo, el apoyo de los compañeros para nuevas ideas y la retroalimentación útil sobre su productividad. En comparación con otros trabajadores del conocimiento, la evaluación de los desarrolladores de software de su productividad depende más de la variedad de tareas y la capacidad de trabajar de forma remota. Las empresas pueden utilizar nuestros hallazgos para priorizar iniciativas relacionadas con la productividad (Sección 4.7).



La sección 2 describe las empresas que estudiamos. La sección 3 describe la metodología de investigación. La sección 4 describe y analiza los resultados obtenidos. La sección 5 describe otros trabajos sobre este tema.

2. Empresas investigadas

2.1. Google

Google tiene alrededor de 40 oficinas de desarrollo en todo el mundo, empleando a decenas de miles de desarrolladores. La empresa valora la colaboración estrecha dentro de los equipos, y las oficinas suelen ser de planta abierta para acercar a los miembros del equipo. La empresa es relativamente joven (fundada a finales de la década de 1990), su estructura organizativa es bastante plana y los desarrolladores tienen mucha autonomía. El proceso de promoción incluye la retroalimentación de los compañeros y los desarrolladores no necesitan pasar a puestos gerenciales para avanzar. Los desarrolladores planifican su tiempo ellos mismos, sus calendarios se muestran en la red corporativa. Google utiliza procesos de desarrollo ágiles (como Agile) que normalmente se aplican a todo el equipo.



Google valora la apertura. La mayoría de los desarrolladores trabajan en una base de código monolítica común y se les anima a realizar cambios en el código de los proyectos de otras personas. La empresa tiene una cultura sólida de pruebas y revisión de código: el código enviado al repositorio es revisado por otro desarrollador, generalmente mediante pruebas. La mayoría escribe código del lado del servidor que se publica con frecuencia y hace que sea relativamente fácil implementar correcciones. El conjunto de herramientas de desarrollo está en gran parte unificado (excluidos los editores) y construido internamente, incluidas las herramientas de análisis e integración continua, y la infraestructura para su lanzamiento.

2.2. TEJIDO

ABB tiene más de 100.000 empleados en todo el mundo. Como conglomerado de ingeniería, la empresa emplea una amplia variedad de profesiones. Hay alrededor de 4.000 desarrolladores de software comunes y más de 10.000 desarrolladores de aplicaciones que construyen sistemas industriales utilizando lenguajes visuales y textuales específicos de la industria. Para operar su gran infraestructura de TI, la empresa cuenta con una plantilla significativa de empleados cuyas responsabilidades incluyen la creación de scripts y la programación simplificada.



Aunque ABB se ha hecho cargo de varias empresas más pequeñas, tiene una organización central responsable de unificar los procesos de desarrollo de software. Entonces, a pesar de las diferencias entre departamentos, la mayoría de las herramientas y enfoques son consistentes. Lo mismo es cierto para la mayoría de las trayectorias profesionales: para los técnicos, desde los desarrolladores junior hasta los senior, y para los ejecutivos, desde el líder del grupo hasta el líder del departamento y la administración central.

2.3. Instrumentos Nacionales

National Instruments se fundó en la década de 1970. El desarrollo de software se concentra principalmente en cuatro centros internacionales de investigación y desarrollo. Los calendarios de los empleados son visibles para toda la empresa, cualquiera puede concertar una cita con cualquier otro empleado.



Las responsabilidades laborales facilitan los procesos de desarrollo. Los desarrolladores no pueden elegir un proyecto de forma independiente, pero pueden asumir tareas o funciones específicas. La mayoría trabaja con una base de código monolítica común, con sus diferentes partes lógicas que tienen propietarios específicos. El código ingresado debe ser aprobado por el "propietario". Es deseable que los líderes tecnológicos analicen el código. Esta política es opcional, pero muchos la siguen.



Los desarrolladores tienen mucha libertad en la elección de herramientas. No existen herramientas genéricas a menos que exista un beneficio inmediato. Por ejemplo, la elección del IDE depende en gran medida de la tarea. Hay varias herramientas de prueba y compilación personalizadas disponibles. Diferentes partes de la empresa han estandarizado diferentes sistemas para la gestión y el análisis del código fuente. Las actualizaciones de software generalmente se publican trimestralmente o anualmente, con la excepción de parches críticos raros.



Tabla 1. Perfiles de las tres empresas estudiadas:

3. Metodología

Nuestro objetivo: descubrir qué factores pueden predecir la productividad de los desarrolladores de software. Para ello, realizamos un estudio que contiene un conjunto de preguntas, un conjunto de factores de productividad y un conjunto de variables demográficas.

3.1 Evaluación de su productividad

Primero, describamos cómo mediremos la productividad. Ramírez y Nembhard han propuesto una clasificación de las técnicas de medición de la productividad descritas en la literatura, que incluyen análisis de puntos de función, autoevaluación, evaluación por pares, proporcionalidad de resultados y esfuerzos y uso profesional del tiempo [2]. Estas técnicas se pueden dividir en objetivas (por ejemplo, cuántas líneas de código se escriben por semana) y subjetivas (por ejemplo, autoevaluación o revisión por pares).



No se prefiere ninguna técnica; ambas categorías tienen desventajas. Las medidas objetivas carecen de flexibilidad y alegría. Tomemos el número de líneas de código por semana. Un desarrollador productivo puede escribir una solución de una línea para un error difícil de encontrar. Y un desarrollador improductivo puede inflar fácilmente el número de líneas. Por otro lado, las mediciones subjetivas pueden ser inexactas debido a sesgos cognitivos. Tome las calificaciones de los pares: es posible que no les guste un desarrollador productivo y, por lo tanto, obtendrán calificaciones peores incluso si sus pares luchan por la objetividad.



Al igual que el equipo de investigadores dirigido por Meyer que analizó la productividad de los desarrolladores de software [3], utilizamos nuestras preguntas de investigación como una medida subjetiva de la productividad. Hay dos razones principales. Primero, como señalaron Ramírez y Nembhardt, la investigación es "una forma simple y popular de medir la productividad de [los trabajadores del conocimiento]". En segundo lugar, la investigación proporciona respuestas de desarrolladores en diferentes roles y también permite a los encuestados agregar información diferente a sus evaluaciones de desempeño.



Figura: 1. Metodología de la investigación:





Preguntamos a los encuestados cuánto están de acuerdo con la afirmación:

Regularmente logro una alta productividad.

Con él, queríamos medir la productividad de la manera más amplia posible. Primero formulamos ocho opciones para la pregunta y luego las redujimos a lo anterior hablando informalmente con cinco desarrolladores de Google sobre su interpretación de la frase (Figura 1, parte inferior izquierda). Agregamos las palabras "alto" y "regularmente" a la pregunta por tres razones. Primero, queríamos capturar un estado con el que las personas pudieran compararse. En segundo lugar, queríamos que este estado fuera alto para evitar los efectos de alcanzar el límite máximo en las respuestas de los encuestados. En tercer lugar, queríamos que los encuestados se centraran en dos medidas específicas de productividad: intensidad y frecuencia. En el futuro, los investigadores pueden aplicar medidas más detalladas dividiendo la intensidad y la frecuencia en dos temas separados.



Lo pusimos a prueba pidiéndole a tres ejecutivos de Google que lo enviaran a sus equipos preguntando: "¿Qué consideró al responder a una declaración de productividad?" Recibimos respuestas de 23 desarrolladores (Figura 1, centro inferior). La opción se consideró aceptable para nuestros propósitos porque las consideraciones de los encuestados coincidieron con nuestras expectativas con respecto al valor de la productividad. Estas consideraciones cubrieron problemas de flujo de trabajo, resultados del trabajo, estar en la zona o flujo, felicidad, metas logradas, eficiencia de programación, progreso y minimizar el esfuerzo desperdiciado. No analizamos estas respuestas en este artículo, pero el estudio incluyó cuatro medidas adicionales y refinadas de productividad tomadas de trabajos anteriores [2], [4], [5].



Elegimos dos medidas convenientes de productividad para agregar datos objetivos para contextualizar la autoestima, y ​​luego las correlacionamos entre sí en Google. La primera medida objetiva fue el número de líneas de código cambiadas por un desarrollador por semana, una medida de productividad popular pero difícil [6], [7]. La segunda medida fue la cantidad de cambios realizados por el desarrollador en la base de código principal de Google por unidad de tiempo. Es casi equivalente a la solicitud de extracción mensual utilizada por el equipo dirigido por Vasilescu [8]. Para evaluar nuestra productividad, utilizamos respuestas a una encuesta similar en Google (n = 3344 respuestas). No pudimos usar datos de nuestro estudio para este análisis porque las respuestas no contenían ID de participantes.mediante el cual se podrían comparar medidas objetivas de productividad. En ese estudio, se hizo una pregunta similar: "¿Con qué frecuencia siente que es muy productivo en el trabajo?" Los participantes podían responder "Rara vez o nunca", "A veces", "Aproximadamente la mitad del tiempo", "La mayor parte del tiempo" y "Siempre o casi siempre". Luego creamos una regresión lineal con el desempeño autoinformado como la variable dependiente ordinal (codificadas 1, 2, 3, 4 y 5, respectivamente). La regresión lineal asume la misma distancia entre las calificaciones de productividad. Dadas las palabras utilizadas en la pregunta, consideramos que esta suposición está justificada. Para la regresión logística ordenada, esta suposición no es necesaria. La aplicación de esta técnica aquí da resultados confiables: los mismos coeficientes son significativos en un lineal,y en un modelo ordenado.



Usamos medidas objetivas logarítmicas como variables independientes, porque ambas tienen un sesgo positivo. Para el control, tomamos el código de trabajo (por ejemplo, ingeniero de software, ingeniero de investigación, etc.) como una variable categórica, así como el rango (junior, medio, senior, etc.) como un número (por ejemplo, 3 para software ingeniero de nivel de entrada en Google). El código de trabajo fue estadísticamente significativo para dos roles de trabajador en cada modelo lineal. Había tres modelos en total: dos con una de las medidas objetivas y otro con ambas medidas objetivas.





Figura: 2: Modelos que predicen una evaluación subjetiva de la productividad basada en dos medidas objetivas. ns significa un factor estadísticamente insignificante con p> 0.05, ** significa p <0.01, *** significa p <0.001. En los Materiales complementarios se ofrece una descripción completa de los modelos.



Los resultados de la contextualización se muestran en la Fig. 2. Cada modelo demuestra un nivel estadísticamente significativo con una calificación negativa, que interpretamos como: los desarrolladores con calificaciones más altas tienden a calificarse a sí mismos como ligeramente menos productivos. Este es un fuerte argumento para el control de rango (sección 3.7.). Los dos primeros modelos demuestran una importante relación positiva entre las medidas objetivas y subjetivas de productividad. Es decir, cuantas más líneas de código se escriben o se realizan cambios, más productivo se considera un desarrollador. El modelo combinado resultante y las estimaciones de los dos primeros modelos sugieren que el número de cambios realizados es un indicador de productividad más importante que el número de líneas escritas. Pero tenga en cuenta que en todos los modelos el parámetro R ², que representa la proporción de varianza explicada, es bastante baja: menos del 3% para cada modelo.



En general, los resultados obtenidos indican que el número de líneas de código y los cambios realizados afectan la valoración de la productividad por parte de los desarrolladores, pero no de forma significativa.

3.2. Factores de productividad

Luego, durante el curso del estudio, preguntamos a los participantes sobre los factores que se consideran relacionados con la productividad en otros estudios. Hemos recopilado preguntas de cuatro fuentes (Figura 1, centro a la izquierda). Estas fuentes se toman porque, hasta donde sabemos, representan las descripciones más completas de los factores de productividad individuales en la investigación de programadores y otros trabajadores del conocimiento.



Primera fuenteEs una herramienta creada por un equipo liderado por Palvalin para revisar las medidas de productividad de los trabajadores del conocimiento [4]. La herramienta, llamada SmartWoW, ha sido utilizada por cuatro empresas y cubre aspectos del espacio de trabajo físico, virtual y social, las prácticas laborales personales y el bienestar en el trabajo. Hemos cambiado algunas de las preguntas para reflejar mejor la terminología actual de los desarrolladores y coincidir mejor con el inglés americano. Por ejemplo, SmartWoW pregunta:

A menudo teletrabajo para realizar tareas que requieren una concentración ininterrumpida.

Hemos parafraseado:

A menudo trabajo de forma remota para realizar tareas que requieren concentración ininterrumpida.

De SmartWoW, primero seleccionamos 38 preguntas para nuestro estudio.



Una segunda fuente es una revisión de Hernaus y Mikulić del impacto de las características del entorno de trabajo en la productividad de los trabajadores del conocimiento [9]. Su trabajo probado refleja estudios de productividad previos: un cuestionario de diseño del entorno de trabajo [10], un estudio de diagnóstico del entorno de trabajo [11], una evaluación de la colaboración en grupo [12] y una evaluación de la “naturaleza de las tareas” [13]. Hemos cambiado las preguntas para que sean breves y coherentes. Con el mismo propósito, tomamos preguntas directamente del trabajo [12], que está dedicado a grupos de trabajo con pocas consideraciones sobre la productividad personal.



Tercera fuente- una revisión estructurada de Wagner y Ruhe de los factores de productividad en el desarrollo de software [14]. A diferencia de otras fuentes, este trabajo no ha sido revisado a fondo por la comunidad científica y no contiene investigación empírica original. Pero a nuestro leal saber y entender, esta es la encuesta más completa sobre investigación de productividad de programación. Los factores formulados por Wagner y Rouet se dividen en factores técnicos y no cuantificables, y luego se destacan adicionalmente los factores de entorno, cultura corporativa, proyecto, entorno de producto y desarrollo, capacidades y experiencia.



La cuarta fuenteEs un estudio de desarrolladores de Microsoft dirigido por un equipo dirigido por Meyer. A partir de él, obtuvimos cinco razones principales para los días de trabajo productivos, incluido el establecimiento de objetivos, las reuniones de trabajo y el tiempo libre.



Agregamos también tres factores que, a nuestro juicio, no fueron debidamente tomados en cuenta en trabajos anteriores, pero que resultaron ser importantes en el contexto de Google. Una es la evaluación de la productividad de los trabajadores del conocimiento [16], un precursor inédito de SmartWoW. Lo adaptamos así:

La información que se me proporciona (informes de errores, secuencias de comandos de usuario, etc.) es precisa.

El segundo factor se toma del cuestionario de diseño del entorno de trabajo y se adapta de la siguiente manera:

Recibo comentarios útiles sobre la productividad de mi trabajo.

Y creamos un tercer factor que era importante en el entorno de ABB:

Necesito acceso directo a cierto hardware para probar mi software.

Primero, elegimos 127 factores. Para reducirlos a un número tal de preguntas que los encuestados puedan responder sin fatiga significativa [17], utilizamos los criterios que se muestran en el centro de la Fig. 1:

1. Duplicados eliminados. Por ejemplo, en SmartWoW [4] y el trabajo de Meyer con colegas [15], el establecimiento de metas se considera un factor importante en la productividad.
2. Factores similares combinados. Por ejemplo, Hernaus y Mikulich describen diferentes aspectos de la interacción entre grupos de trabajo que aumentan la productividad, pero los hemos reducido a un factor [9].
3. Se dio preferencia a factores de evidente utilidad. Por ejemplo, SmartWoW [4] tiene el siguiente factor:

Los empleados tienen la oportunidad de ver los calendarios de los demás.

En Google, esto es cierto en todas partes y es poco probable que cambie, por lo que el factor tiene poca utilidad.



Hemos aplicado estos criterios de forma conjunta e iterativa. Primero, se imprimió un cartel grande con todas las preguntas de los candidatos para su uso en el estudio. Luego colocamos un póster de Google junto a nuestra oficina. Luego, cada uno de nosotros analizó de forma independiente las preguntas en función de los criterios anteriores. El cartel estuvo colgado durante varias semanas, periódicamente complementamos y revisamos la lista nuevamente. Finalmente, se elaboró ​​una lista final de preguntas.



Nuestro estudio incluyó 48 factores en forma de declaraciones (Fig. 4, columna de la izquierda). Los encuestados indicaron su grado de acuerdo con estas afirmaciones en una escala de cinco puntos, desde “Totalmente en desacuerdo” hasta “Totalmente de acuerdo”. Los factores se pueden agrupar en bloques relacionados con la metodología, el enfoque, la experiencia, el trabajo, la oportunidad, las personas, el proyecto, el software y el contexto. También hicimos una pregunta abierta sobre los factores que los encuestados sintieron que podríamos haber pasado por alto. El cuestionario completo de nuestro estudio se proporciona en los Materiales complementarios.





Figura: 3: Pregunta de ejemplo de la investigación.

3.3. Demografía

Hicimos preguntas sobre varios factores demográficos, como se muestra en la Figura 1:

• Suelo.
• Posición.
• Rango.

Autores anteriores han sugerido que el género está asociado con factores de productividad de los desarrolladores de software, como el éxito de la depuración [18]. Por lo tanto, el estudio tenía una pregunta opcional sobre el género (masculino, femenino, me niego a responder, el mío). Los encuestados que no respondieron a la pregunta fueron asignados al grupo de "negarse a responder" (Google n = 26 [6%], ABB n = 4 [3%], National Instruments n = 5 [6%]). Tratamos estos datos como categóricos.



En cuanto al puesto, tomamos la antigüedad en Google del departamento de recursos humanos. Esto no fue posible con ABB y National Instruments, por lo que agregamos una pregunta opcional al estudio. En ABB, en ausencia de respuestas (n = 4 [3%]), llevamos 12 años de experiencia, este es el promedio de los datos recopilados. En National Instruments, llevamos 9 años por la misma razón (n = 1 [1%]). Puede hacerlo más difícil [19], por ejemplo, utilizando sustituciones para predecir los valores faltantes en función de los datos disponibles. Digamos que la información de rango que falta se puede completar con bastante precisión según la posición y el género. Sin embargo, sustituimos solo valores estadísticos promedio, dado que los factores demográficos no eran de importancia primordial para nosotros, solo eran información de acompañamiento para el control. Procesamos estos datos como números.



En términos de rango, en Google les pedimos a los participantes que indicaran su nivel como un número. Las respuestas faltantes (n = 26 [6%]) fueron el valor más común.



En ABB, los colaboradores podían indicar opcionalmente "desarrollador de software junior o senior", aunque muchos indicaron un título "diferente". Si la respuesta incluía las palabras:

• mayor
• líder
• gerente
• arquitecto
• investigador
• principal
• científico

luego remitimos esas respuestas a las "mayores". El resto se denominó "junior". Las respuestas faltantes (n = 4 [3%]) las atribuimos al significado más común: "mayor".



National Instruments tenía opciones:

• desafiador
• personal
• mayor
• arquitecto / ingeniero principal
• arquitecto / ingeniero jefe
• ingeniero de honor
• partícipe
• otro

El único "otro" resultó ser un pasante, a quien trasladamos a los "aspirantes". Las respuestas faltantes (n = 3 [4%]) las atribuimos al significado más común: "mayor".



Hemos codificado rangos en todas las empresas por números.

3.4. Comparación con no desarrolladores

A continuación, nos interesó qué nos permite predecir exactamente cómo los desarrolladores evalúan su productividad. Por ejemplo, asumimos que la productividad estaba influenciada por estar fuera del trabajo, pero eso podría decirse de cualquier trabajador del conocimiento. Por lo tanto, surge una pregunta natural: ¿afecta esto de alguna manera a la productividad del desarrollador de una manera especial?



Para responder a esta pregunta, elegimos profesiones comparables a las de los desarrolladores de software. Primero, intentamos seleccionar en función de las posiciones en Google. Aunque algunos puestos indicaron que eran trabajadores del conocimiento, el indicador más común y, en nuestra opinión, el indicador más confiable de un no desarrollador adecuado fue la presencia de la palabra "analista" en el puesto. Decidimos comparar a los analistas y desarrolladores de Google, en lugar de comparar a los analistas de Google con los desarrolladores de las tres empresas. Decidimos que esto nos permitiría controlar las características de la empresa (por ejemplo, si de repente los empleados de Google son estadísticamente más o menos sensibles a las interrupciones que los empleados de otras empresas).



Luego adaptamos nuestra investigación para analistas. Se eliminaron preguntas claramente relacionadas con el desarrollo de software, como "Mis requisitos de software cambian con frecuencia". Hemos rehecho otras preguntas específicamente para analistas. Por ejemplo, en lugar de "Uso las mejores herramientas y técnicas para desarrollar software", escribimos "Uso las mejores herramientas y enfoques para hacer mi trabajo".



Los puntajes de productividad se midieron de la misma manera que los desarrolladores. Lo mismo ocurre con la evaluación de género, posición y rango. Probamos la versión "analítica" del estudio en una muestra conveniente de cinco analistas que dijeron que el estudio fue en general claro e hizo algunos ajustes menores. Los aceptamos y realizamos un estudio completo de no desarrolladores.

3.5. qestion de control

Con el fin de excluir las respuestas que se dieron sin pensar, después de aproximadamente el 70% del comienzo del estudio, insertamos una pregunta de atención [20]: "Responda esto," más bien no estoy de acuerdo ". No tomamos en cuenta los formularios que no contenían tal respuesta a esta pregunta.

3.6. Proporción de respuestas

En Google, seleccionamos 1,000 empleados aleatorios a tiempo completo de recursos humanos que estaban en funciones de desarrollo de software. Recibimos 436 formularios completados de ellos, es decir, la tasa de respuesta fue del 44%, lo que es un indicador muy alto para la investigación entre los desarrolladores [21]. Después de eliminar los formularios con la respuesta incorrecta a la pregunta de seguridad (n = 29 [7%]), quedaron 407 respuestas.



Para una encuesta de trabajadores del conocimiento, seleccionamos 200 empleados aleatorios de Google a tiempo completo con la palabra "analista" en sus cargos. Decidimos no investigar a demasiados analistas porque nuestro objetivo eran los desarrolladores de software. 94 personas, 47%, respondieron nuestras preguntas. Después de eliminar los cuestionarios con una respuesta errónea a la pregunta de seguridad (n = 6 [6%]), quedaron 88.



Enviamos nuestros cuestionarios a aproximadamente 2.200 desarrolladores de software seleccionados al azar en ABB y recibimos 176 respuestas. Este es el 8%, en el límite inferior para tales estudios [21]. Después de eliminar los cuestionarios incorrectos (n = 39 [22%]), quedaron 137.



Finalmente, enviamos los cuestionarios a unos 350 desarrolladores de software en National Instruments y recibimos 91 respuestas (26%). Después de eliminar los cuestionarios incorrectos (n = 13 [14%]), quedaron 78.

3.7. Análisis

Para cada factor de cada empresa, aplicamos modelos de regresión lineal individuales, utilizando el factor como variable independiente (por ejemplo, "El cronograma de mi proyecto es ajustado") y la estimación de nuestra productividad como variable dependiente. Ejecutamos modelos separados para cada empresa por motivos de privacidad, de modo que los datos sin procesar de diferentes empresas no se mezclen. Para mitigar el efecto de las variables colaterales, agregamos variables demográficas existentes a cada modelo de regresión. Al interpretar los resultados, nos centramos en tres aspectos de la relación de factores de productividad:

• Evaluación . Indica el grado de influencia de cada factor manteniendo una constante demográfica. Cuanto mayor sea el valor, mayor será el impacto.
• . . , .
• . p < 0,05. 48 , p -, [22].

Al interpretar los resultados, nos centramos más en el grado de influencia (evaluación) y menos en la significación estadística, porque se puede extraer de conjuntos de datos suficientemente grandes, incluso si la significación práctica es baja. Como veremos a continuación, los resultados estadísticamente significativos se encontraron con mayor frecuencia en Google, con la tasa de respuesta más alta; y menos aún, en National Instruments, donde la tasa de respuesta fue menor. Sentimos que esta diferencia se debió en gran parte al poder estadístico. Le instamos a tener más confianza en los resultados estadísticamente significativos.



Para proporcionar contexto, también analizamos cómo los factores demográficos se correlacionan con las calificaciones de desempeño. Para ello, realizamos una regresión lineal múltiple para cada empresa con variables demográficas como variables independientes y una estimación de nuestra productividad como variable dependiente. Luego analizamos el valor predictivo general del modelo resultante, así como el impacto de cada variable explicativa.

3.8. Sobre la causalidad

Nuestra metodología nos permite evaluar la relación entre los factores de productividad y la valoración de la propia productividad, aunque en esencia nos interesa cuál es el grado de influencia de cada factor en el cambio de productividad. ¿Qué tan correcto es creer que existe una relación causal entre factores y productividad?



La exactitud depende principalmente de la solidez de la evidencia de causalidad en trabajos anteriores. Y este poder es diferente por diferentes factores. Por ejemplo, un equipo dirigido por Guzzo realizó un metanálisis de 26 artículos sobre evaluación y retroalimentación, y los resultados proporcionan una excelente evidencia de que la retroalimentación aumenta la productividad en el lugar de trabajo [23]. Sin embargo, determinar la solidez de la evidencia para cada factor investigado requiere mucho trabajo, que está más allá del alcance de este artículo.



En resumen: aunque nuestro estudio no permite establecer una relación causal, pero basándonos en trabajos previos, podemos creer con seguridad que estos factores afectan la productividad, pero interpretar nuestros resultados con cierta cautela.

4. Resultados

Para empezar, describimos la relación entre todos los factores de productividad y la evaluación de su productividad al controlar las características demográficas. Estos datos se utilizarán para responder a cada respuesta de la encuesta, seguida de una discusión de los resultados. Luego discutiremos la relación entre las características demográficas y la medición del desempeño. Finalmente, analicemos las implicaciones y los riesgos.

4.1. Factores de productividad

En la Fig. 4 muestra los resultados de nuestro análisis descritos en la sección 3.7. La primera columna enumera los factores que se propusieron a los participantes en forma de declaraciones; seguido de las etiquetas de los factores (F1, F2, etc.) que asignamos después de que se completó el análisis. La falta de datos significa que estos factores son específicos de los desarrolladores y no se sugirieron a los analistas (por ejemplo, F10).



Figura: 4: Relaciones entre 48 factores y cómo los desarrolladores y analistas evalúan su propia productividad en tres empresas:

Las siguientes tres columnas son datos de tres empresas, así como datos de analistas de Google. Cada una de estas columnas se divide en dos subcolumnas. Estimación de



subcolumna(puntuación) contiene coeficientes de regresión que cuantifican la fuerza de la asociación de un factor con una estimación de su productividad. Cuanto mayor sea el número, más fuerte será la asociación. Por ejemplo, en la primera columna de Google, la estimación es 0,414. En este caso, esto significa que por cada punto de creciente concordancia con el enunciado sobre entusiasmo en el trabajo (F1), el modelo predice un aumento en la calificación de productividad del encuestado en 0.414 puntos con control de variables demográficas. Las calificaciones pueden ser negativas. Por ejemplo, en las tres empresas, cuanto más rotación de personal en el equipo (F48), menor es la valoración de su productividad. Junto a cada puntaje hay un indicador que refleja claramente el puntaje.



Tenga en cuenta que los puntajes no significan calificaciones más altas de factores, sino una correlación más alta entre el factor y la calificación de su productividad. Por ejemplo, National Instruments (F1) obtiene un mayor entusiasmo que otras empresas. Esto no significa que los desarrolladores estén más entusiasmados: en esta empresa, él es un factor más fuerte para predecir la evaluación de su productividad. No proporcionamos las calificaciones en sí, porque esto está prohibido según los términos de cooperación. Sin un contexto completo, las calificaciones pueden malinterpretarse. Por ejemplo, si informamos que los desarrolladores de una empresa están menos entusiasmados con su trabajo que los desarrolladores de otra empresa, es posible que tenga la impresión de que es mejor no trabajar en esa otra empresa.



En segundo lugar subcolumna de error(error) contiene los errores estándar del modelo para cada factor. Cuanto menor sea el valor, mejor. Intuitivamente, los valores más bajos parecen indicar que cuando los factores cambian, el modelo predice su desempeño de manera más confiable. Los valores de error generales son bastante estables de un factor a otro, especialmente en Google con una gran cantidad de encuestados.



Un asterisco (*) indica que este factor fue estadísticamente significativo en el modelo. Por ejemplo, el entusiasmo por el trabajo (F1) es estadísticamente significativo en las tres empresas, mientras que la preparación para las reuniones (F17) es significativo solo en Google.



La siguiente columna contiene la puntuación media ( μ ) de las tres empresas con la desviación estándar entre paréntesis ( σ). El primer indicador muestra claramente el valor de la puntuación media, el segundo indicador, el valor de la desviación estándar. Por ejemplo, la puntuación media de entusiasmo en el trabajo (F1) fue de 0,43 y la desviación estándar fue de 0,051. La tabla está ordenada por calificación promedio.



La última columna contiene las diferencias entre las calificaciones de los analistas y los desarrolladores de software en Google. Los valores positivos significan calificaciones más altas de los desarrolladores, los negativos significan calificaciones más altas de los analistas. Por ejemplo, en términos de entusiasmo (F1), los analistas tienen calificaciones ligeramente más bajas que los desarrolladores.

4.2. ¿Qué factores predicen mejor cómo los desarrolladores evaluarán su productividad?

Los factores predictivos más fuertes son las declaraciones con el puntaje promedio absoluto más alto. Los factores predictivos más débiles son aquellos con la puntuación promedio absoluta más baja. En otras palabras, los factores en la parte superior de la tabla en la Fig. 4 son los mejores predictores. Para comprender qué factor proporciona la mayor confianza en el resultado, hemos destacado los resultados que son estadísticamente significativos para las tres empresas:

• Entusiasmo por el trabajo (F1)
• Apoyo de pares para nuevas ideas (F2)
• Comentarios útiles sobre el desempeño laboral (F11)

Discusión . Tenga en cuenta que los primeros 10 factores de productividad no son técnicos. Esto es sorprendente dado que, en nuestra estimación, la mayor parte de la investigación de los desarrolladores de software se centra en aspectos técnicos. Por tanto, una reorientación activa hacia el factor humano puede conducir a un aumento significativo de la influencia de los investigadores en la industria. Por ejemplo, las respuestas a las siguientes preguntas pueden ser particularmente fructíferas:

• ¿Qué entusiasma a los desarrolladores de software con su trabajo? ¿Qué explica la diferencia de entusiasmo? ¿Qué intervenciones pueden aumentar el entusiasmo? Este artículo puede complementar la investigación sobre la felicidad [24] y la motivación [25].
• ? , ? ?
• , ? ? ?

Otra característica importante es la clasificación de factores de la línea de investigación COCOMO II. Estos factores, obtenidos en el curso de estudios empíricos de proyectos de software de la industria y verificados mediante análisis numérico de 83 proyectos [26], fueron originalmente formulados para estimar el costo del desarrollo de software. Por ejemplo, los factores de productividad de COCOMO II incluyen la volatilidad de la plataforma base y la complejidad del producto. Es curioso que los factores COCOMO II tomados en cuenta en nuestro estudio (F5, F10, F14, F16, F24, F26, F28, F32, F33, F34, F36, F38, F39, F43, F44, F46, F47, F48) recibieron menores valores. Se puede suponer que permiten predecir peor la productividad. La mitad superior de los factores predictivos (F1 - F24) incluyó solo 5 de COCOMO II, y la mitad inferior, 14 factores. Podemos ofrecer dos interpretaciones diferentes. Primero:COCOMO II carece de varios factores de productividad importantes, y las iteraciones futuras de COCOMO II pueden ser más predictivas si se introducen en la empresa más de los factores que investigamos, como el apoyo a los enfoques de autonomía de trabajo. Otra interpretación: COCOMO II está adaptado para la tarea actual - fijar la productividad a nivel de proyecto [6], [27], [28], [29], [30], [31] - pero menos adecuado para fijar la productividad a nivel de desarrollador individual. Esta interpretación enfatiza la importancia y novedad de nuestros resultados.COCOMO II está adaptado para la tarea actual - fijar la productividad a nivel de proyecto [6], [27], [28], [29], [30], [31] - pero menos adecuado para fijar la productividad a nivel de desarrollador individual. Esta interpretación enfatiza la importancia y novedad de nuestros resultados.COCOMO II está adaptado para la tarea actual - fijar la productividad a nivel de proyecto [6], [27], [28], [29], [30], [31] - pero menos adecuado para fijar la productividad a nivel de desarrollador individual. Esta interpretación enfatiza la importancia y novedad de nuestros resultados.



Además, todos los factores de COCOMO II fueron factores predictivos de productividad relativamente bajos y estadísticamente insignificantes en las tres empresas. Por ejemplo:

• Mi software necesita mucha potencia de procesamiento (F39).
• Mi software necesita un gran almacén de datos (F43).
• Mi plataforma de software (por ejemplo, entorno de desarrollo, pila de software o hardware) está cambiando rápidamente (F46).

Una explicación: en los 20 años transcurridos desde la creación y prueba de COCOMO II, las plataformas se han vuelto menos diversas en términos de productividad. Es probable que los sistemas operativos estandarizados ahora protejan a los desarrolladores de pérdidas de productividad debido a cambios de hardware (por ejemplo, Android en desarrollo móvil). Asimismo, las plataformas en la nube pueden proteger a los desarrolladores de las pérdidas de productividad debido al escalado de procesos y las necesidades de almacenamiento. Sin mencionar que los marcos modernos y las plataformas en la nube son fáciles de usar. Además, la diferencia de productividad al procesar grandes y pequeñas cantidades de datos puede haber desaparecido desde la creación de COCOMO II.

4.3. ¿En qué se diferencian estos factores de una empresa a otra?

Para responder a esta pregunta, puede observar la desviación estándar en las estimaciones de las tres empresas. Estos son los tres factores con la menor variabilidad, es decir, con los valores más estables entre empresas:

1. Usar el teletrabajo para enfocarse (F40).
2. Comentarios útiles sobre el desempeño laboral (F4).
3. Apoyo de pares para nuevas ideas (F2).

Creemos que la estabilidad de estos factores los convierte en buenos candidatos para la generalización. Es probable que otras empresas obtengan resultados similares para estos factores.



Y aquí están los tres factores con la mayor variabilidad, es decir, con la mayor distribución de valores entre empresas:

1. Utilizando las mejores herramientas y enfoques (F15).
2. Reutilización de código (F25).
3. Precisión de la información entrante (F6).

Discusión . Los tres factores menos variables (F40, F4 y F2) tienen una característica común: no se relacionan con la tecnología, sino con la sociedad y el medio ambiente. Quizás esto sugiera que dondequiera que trabajen los desarrolladores, se ven igualmente afectados por el trabajo remoto, la retroalimentación y el apoyo de pares para nuevas ideas. Cambiar estos tres factores puede resultar el mayor impacto.



¿Por qué los factores F15, F25 y F6 son tan diferentes en diferentes empresas? Para cada uno de ellos, tenemos una posible explicación basada en lo que sabemos sobre estas empresas.



El uso de las mejores herramientas y enfoques (F15) está más fuertemente asociado con la puntuación de desempeño de Google, pero no significativamente asociado con National Instruments. Posible explicación: la base de código de Google es mucho más grande. Por lo tanto, el uso de mejores herramientas y enfoques para navegar y comprender la base de código más grande de manera eficiente tiene un impacto significativo en la productividad. Y en National Instruments, la productividad depende menos de la herramienta porque el código base es más pequeño y claro.



La reutilización de código (F25) está fuertemente relacionada con la puntuación de rendimiento de Google, pero no significativamente en ABB. Posible explicación: Google facilita la reutilización del código. El código base es monolítico, y todos los desarrolladores pueden examinar prácticamente todas las líneas de código de la empresa, por lo que la reutilización no requiere mucho esfuerzo. Y ABB tiene muchos repositorios a los que acceder. Y en esta empresa, las ganancias de productividad (a través de la reutilización) pueden compensarse con pérdidas de productividad (al encontrar y recuperar el código correcto).



La precisión de la información (F6) está fuertemente relacionada con los puntajes de desempeño de National Instruments, pero no significativamente con ABB. Explicación posible: los desarrolladores de ABB están mejor protegidos de la influencia de información inexacta. En particular, en ABB, varios niveles del equipo de soporte están dedicados a obtener la información correcta sobre errores de los clientes. Si el desarrollador recibe información inexacta, entonces su productividad puede disminuir, porque tiene que delegar la tarea de refinar los datos en el equipo de soporte.

4.4. ¿Qué permite predecir la evaluación de un desarrollador de su productividad, en particular, en comparación con otros trabajadores del conocimiento?

Para responder a esta pregunta, pase a la última columna de la Fig. 4. Si observamos varias relaciones entre las calificaciones máximas, veremos que la evaluación de los analistas de su productividad está más fuertemente asociada con:

• Percepción positiva de sus compañeros (F7).
• Autonomía en la organización de la jornada laboral (F4).

Por otro lado, la evaluación de los desarrolladores de su productividad está más fuertemente relacionada con:

• Realización de diversas tareas dentro del trabajo (F13).
• Trabajar eficazmente fuera de sus lugares de trabajo (F30).

Discusión . En general, los resultados sugieren que los desarrolladores son algo similares a otros trabajadores del conocimiento y algo diferentes. Por ejemplo, la productividad de los desarrolladores se predice mejor por el entusiasmo en el trabajo, y los analistas tienen casi lo mismo. Creemos que las empresas pueden utilizar nuestros hallazgos para seleccionar iniciativas de productividad dirigidas a desarrolladores o elegir iniciativas más amplias.



El kit de herramientas de desarrollo unificado de Google puede explicar por qué el aumento de la diversidad de tareas se asocia con índices de productividad más altos entre los desarrolladores, no entre los analistas. La diversidad de tareas puede reducir el aburrimiento y aumentar la productividad para ambos grupos, pero las herramientas de desarrollo unificadas de Google pueden significar que los desarrolladores pueden usar las mismas herramientas para diferentes tareas. Y los analistas pueden necesitar usar diferentes herramientas para diferentes tareas, lo que aumenta el esfuerzo cognitivo en el cambio de contexto.



El trabajo fuera de la oficina puede explicar por qué la mejora de la eficiencia del trabajo fuera del lugar de trabajo está más fuertemente asociada con ganancias de productividad para los desarrolladores que para los analistas. Creemos que despegar del trabajo es más perjudicial durante la programación que durante el trabajo analítico.



Parnin y Rugaber descubrieron que regresar al trabajo después de una interrupción es un problema frecuente y persistente para los desarrolladores [32], lo que los lleva a necesitar mejores herramientas para ayudarlos a volver a trabajar en un problema [33].

4.5. Otros factores de productividad

Al final del cuestionario, los encuestados podrían indicar factores adicionales que, en su opinión, afectan la productividad. En su mayor parte, estas adiciones fueron descripciones iguales o más refinadas de nuestros 48 factores. Descartamos tales adiciones, pero, si fue necesario, creamos nuevos factores. Los Materiales Suplementarios contienen descripciones de nuevos factores, así como descripciones actualizadas de los que propusimos originalmente. Los investigadores potenciales pueden tener una nueva pregunta de equipo mixto para trabajar en un proyecto, o refinar o sugerir desgloses de preguntas más específicas para los factores F15, F16 y F19.

4.6. Demografía

En Google y National Instruments, ni los modelos demográficos generales ni las variables complementarias individuales fueron predictores estadísticamente significativos de sus puntajes de desempeño.



Para ABB, el modelo demográfico resultó ser significativo ( F = 3 , 406 , gl = (5 , 131) , p <0,007). El género también resultó ser un factor estadísticamente significativo ( p = 0,007); las mujeres estiman su productividad 0,83 puntos más que los hombres. Los participantes de otros géneros (“otros”) mostraron una puntuación 1,6 puntos superior a la de los hombres ( p = 0,03). La posición ( p= 0,04), cada año adicional la empresa elevaba su estimación de rendimiento en 0,02 puntos. Hasta donde sabemos, las diferencias entre ABB y las otras dos empresas no explican por qué estos factores demográficos solo se predijo que serían significativos en ABB y en ningún otro lugar.

4.7. Aplicación en la práctica y en la investigación

¿Cómo utilizar nuestros resultados en la práctica? Hemos proporcionado una lista clasificada de los factores más importantes para predecir la productividad que se pueden utilizar para priorizar iniciativas. Se pueden encontrar ejemplos de iniciativas en trabajos de investigación anteriores.



Por ejemplo, para aumentar el entusiasmo en el trabajo, Markos y Sridevi sugirieron ayudar a los trabajadores a crecer profesionalmente [34] mediante talleres sobre tecnología y comunicación interpersonal. Los investigadores también sugirieron introducir la práctica de reconocer el buen trabajo. Por ejemplo, ABB está experimentando con el reconocimiento público de los desarrolladores que han implementado herramientas y técnicas para navegar por el código estructurado [35].



Para aumentar el apoyo a nuevas ideas, Brown y Duguid han propuesto formas formales e informales para compartir las mejores prácticas [36]. En Google, la difusión unidireccional del conocimiento es a través de la iniciativa de prueba de inodoros: los desarrolladores escriben noticias breves sobre pruebas u otra área, y luego estas notas se publican en los baños de toda la empresa.



Para mejorar la calidad de la retroalimentación sobre la productividad laboral, London y Smither sugieren centrarse en la retroalimentación que no sea crítica, basada en el comportamiento, interpretable y orientada a los resultados [37]. En Google, dicha retroalimentación se puede obtener a través de autopsias inocuas: luego de eventos negativos importantes como una caída en los servicios, los ingenieros escriben conjuntamente un informe sobre las acciones que influyeron en la causa raíz del problema, sin culpar a empleados específicos.



Vemos varias direcciones para futuras investigaciones basadas en nuestro trabajo.



Primero, una revisión sistemática de artículos que caracterice el impacto y el contexto de la evidencia para cada factor de productividad discutido aquí mejorará la usabilidad de nuestro trabajo al crear relaciones causales. Cuando son débiles, la aplicabilidad se puede mejorar realizando una serie de experimentos para establecer la causalidad.



En segundo lugar, como se menciona en las Secciones 4.5 y 4.6, los posibles investigadores pueden utilizar factores adicionales sugeridos por nuestros encuestados y examinar la influencia del género y otros factores demográficos en la productividad de los desarrolladores.



En tercer lugar, el impacto de la investigación de la productividad en el desarrollo de software se puede mejorar con un conjunto multidimensional de métricas y herramientas que se han validado mediante investigación empírica y triangulación.



Cuarto, si los investigadores pueden calcular el costo de cambiar los factores que afectan la productividad, las empresas pueden tomar decisiones de inversión más inteligentes.

4.8. Riesgos

Al interpretar los resultados de este estudio, se deben considerar varios riesgos para su validez.



4.8.1. Riesgos para la confiabilidad de los datos



En primer lugar, hablamos de una sola medida: la evaluación de su productividad. Hay otras dimensiones, incluidas medidas objetivas, como el número de líneas de código escritas por día, un enfoque utilizado por Facebook [38]. Como señalamos en la Sección 3.1, todas las métricas de productividad tienen fallas, incluida la medición de su propia productividad. Por ejemplo, los desarrolladores pueden ser demasiado frívolos al evaluar su productividad o sobreestimar artificialmente su evaluación debido a sesgos en la sociedad [39]. A pesar de estas deficiencias, el equipo dirigido por Zelenski se basa en trabajos anteriores para argumentar la validez de la evaluación del desempeño [40], que también se utiliza en este artículo.



En segundo lugar, medimos nuestra productividad con una sola pregunta que apenas cubre todo el espectro de la productividad del desarrollador. Por ejemplo, la pregunta se centra en la frecuencia y la intensidad, pero no considera la calidad. Tampoco pedimos a los encuestados que limiten sus respuestas a un período de tiempo específico, por lo que algunos participantes pueden responder en función de sus experiencias durante la semana pasada, mientras que otros evaluaron sus experiencias durante el año pasado. En retrospectiva, el estudio debería operar con un intervalo de tiempo fijo.



En tercer lugar, debido al número limitado de preguntas, nos basamos solo en aquellos factores que fueron investigados en trabajos anteriores. Es posible que las 48 preguntas que seleccionamos no cubran todos los aspectos de los comportamientos relacionados con la productividad. O los factores que elegimos pueden ser demasiado generales en ciertos casos. Por ejemplo, en retrospectiva, el factor relacionado con las mejores “herramientas y enfoques” (F14) podría ser más poderoso si separamos las herramientas de los métodos.



4.8.2. Riesgos internos para la confiabilidad



Cuarto, como mencionamos en la sección 3.8, nos hemos basado en trabajos anteriores para establecer relaciones causales entre factores y productividad, pero la fuerza de la evidencia de las relaciones puede variar. Puede resultar que algunos factores afecten la evaluación de su productividad solo indirectamente, a través de otros factores, o que su conexión generalmente tenga la dirección opuesta. Por ejemplo, es probable que un factor importante en la productividad, el mayor entusiasmo por el trabajo (F1), se deba en realidad a una mayor productividad.



4.8.3. Riesgos externos para la confiabilidad



En quinto lugar, aunque examinamos tres empresas bastante diferentes, la generalización con otros tipos de empresas, otras organizaciones y otros tipos de trabajadores del conocimiento es limitada. En este documento, hemos seleccionado analistas como representantes de no desarrolladores, pero esta categoría incluye varios tipos de trabajadores del conocimiento: médicos, arquitectos y abogados. Otro riesgo para la confiabilidad es el sesgo debido a la falta de respuestas: las personas que respondieron los cuestionarios fueron autoseleccionadas.



En sexto lugar, analizamos cada factor de productividad por separado, pero muchos factores pueden acompañarse entre sí. Este no es un problema de análisis, sino la aplicabilidad de los resultados. Si los factores son codependientes, cambiar uno puede afectar negativamente al otro.



4.8.4. Riesgos para la



credibilidad constructiva En séptimo lugar, al crear este estudio, nos preocupaba la posibilidad de que los encuestados reconocieran nuestra metodología de análisis y no respondieran con sinceridad. Intentamos reducir esta probabilidad separando el problema de la productividad de sus factores, pero es posible que los encuestados hayan podido sacar conclusiones sobre nuestra metodología de análisis.



Finalmente, hemos reformulado algunas de las preguntas para adaptar la investigación al analista, lo que podría alterar indeseablemente el significado de las preguntas. En consecuencia, las diferencias entre desarrolladores y analistas pueden haber surgido de diferencias en las preguntas, más que en la profesión.

5. Trabajo relacionado

Muchos investigadores han estudiado factores de productividad individuales para desarrolladores de software. Por ejemplo, Moser y Nierstrasz analizaron 36 proyectos de desarrollo de software e investigaron el impacto potencial de las tecnologías orientadas a objetos en la mejora de la productividad de los desarrolladores [41].



Otro ejemplo es el estudio de DeMarco y Lister de 166 programadores de 35 organizaciones que realizan un ejercicio de programación de un día. Los autores encontraron que el lugar de trabajo y la organización están asociados con la productividad [42].



Un tercer ejemplo es un experimento de laboratorio de Kersten y Murphy con 16 desarrolladores. Resultó que quienes usaban la herramienta para concentrarse en la tarea eran mucho más productivos que otros [43].



Además, el análisis sistemático de Wagner y Rouet da una buena idea de la relación entre los factores individuales y la productividad [14]. El equipo dirigido por Mayer ofreció un análisis aún más reciente de la descripción general de los factores de productividad [3]. En general, nuestro trabajo se basa en estos estudios de factores individuales con un estudio más amplio de su diversidad.



La revisión sistemática de Petersen afirma que siete artículos cuantifican los factores que predicen la productividad de los desarrolladores de software [44]. En cada trabajo, se utilizan métodos numéricos para la predicción, generalmente esta es la regresión, que también usamos en nuestra investigación. Los factores más comunes están relacionados con el tamaño del proyecto, y 6 de los 7 factores se formulan explícitamente en función de los impulsores de productividad de COCOMO II ([6], [27], [28], [29], [30], [31]). El modelo de pronóstico más complejo del estudio de Petersen utiliza 16 factores [6].



Nuestro trabajo tiene dos diferencias principales. Primero, en comparación con trabajos anteriores, estimamos más factores (48), y su variedad es más amplia. Seleccionamos factores basados ​​en la psicología industrial y organizacional. En segundo lugar, teníamos un tema diferente de análisis: investigadores anteriores estudiaron qué podía predecir la productividad en el marco del proyecto, y nos interesaba la productividad personal de las personas.



Además del desarrollo de software, estudios previos compararon factores que predicen la productividad en otras profesiones, en particular, en el campo de la psicología industrial y organizacional. Aunque dichos estudios se han centrado en la productividad a nivel de empresa [45] y el trabajo físico como la fabricación [46], el área más estrechamente relacionada es la productividad de los trabajadores del conocimiento. Es decir, personas que utilizan activamente el conocimiento y la información en su trabajo, normalmente utilizando una computadora [47]. La comparación de factores para tales profesiones se presenta en dos trabajos principales. El primero es un estudio en equipo dirigido por Palwalin sobre 38 factores que estudios anteriores han comparado con la productividad. Estos factores abarcan el espacio de trabajo físico, virtual y social,enfoques de trabajo personal y bienestar en el trabajo [4]. El segundo es un estudio de Hernaus y Mikulich de 512 trabajadores del conocimiento. Los autores estudiaron 14 factores, divididos en tres categorías [9]. Nos basamos en ambos trabajos para preparar nuestro estudio (Sección 3.2).



Sin embargo, los estudios que comparan los factores de productividad para los trabajadores del conocimiento no han prestado atención a los desarrolladores de software. Existen dos motivos principales para esto. En primer lugar, no está claro en qué medida los resultados generales obtenidos se proyectan a los desarrolladores. En segundo lugar, estos estudios suelen extraerse de factores específicos del desarrollador, como la reutilización del software y la complejidad de la base de código [48]. Por lo tanto, existe un vacío en la literatura para comprender los factores que permiten predecir la productividad del desarrollador. Llenar este vacío es práctico. Hemos creado tres equipos de investigación en tres empresas para mejorar la productividad. Cerrar esta brecha de conocimiento ayuda a nuestros equipos a investigar y a las empresas a invertir en la productividad de los desarrolladores.

6. Conclusión

Muchos factores afectan la productividad de los desarrolladores, pero las organizaciones tienen recursos limitados para enfocarse en mejorar la productividad. Creamos y realizamos un estudio en tres empresas para clasificar y comparar diferentes factores. Los desarrolladores y líderes pueden utilizar nuestros hallazgos para priorizar sus esfuerzos. En pocas palabras, los artículos anteriores han sugerido muchas formas de mejorar la productividad de los desarrolladores de software, y hemos sugerido cómo puede priorizar esas formas.

Bloque de preguntas

¿Qué hace que un desarrollador sea productivo?

Esta investigación anónima de una página le llevará 15 minutos y nos ayudará a comprender mejor qué afecta la productividad de los desarrolladores. Responda de forma abierta y honesta.



La investigación hará preguntas sobre usted, su proyecto y su software. Recuerde:



Mi software se refiere al software principal que desarrolla en ABB, incluidos los productos y la infraestructura. Si está trabajando en diferentes programas, responda solo en el principal.



Mi proyecto pertenece al equipo con el que creas el software. Responda cualquier pregunta relacionada con otros desarrolladores de software de ABB.



Algunas preguntas tocan temas potencialmente delicados. Complete las respuestas para que nadie pueda mirar por encima de su hombro y borre el historial de su navegador y las cookies después de completar el cuestionario.



Califique su acuerdo con las siguientes declaraciones.





Estas preguntas están diseñadas para proporcionar una evaluación integral de los factores que pueden afectar la productividad. ¿Nos estamos perdiendo algo?



Sexo (opcional)



¿Cuál es su título? (opcional)



¿En qué año se incorporó a ABB?

Materiales adicionales

Factores de productividad señalados por los encuestados

En esta sección, enumeramos los factores que los encuestados describieron en sus respuestas a la pregunta abierta. Primero, describiremos varios factores nuevos y luego proporcionaremos descripciones de factores relacionados con los que ya están disponibles en el estudio. Complementamos los comentarios de los encuestados con códigos utilizando nuestros factores. Aquí no discutimos ni evaluamos las respuestas de las personas, no complementamos las descripciones existentes de nuestros factores.

Nuevos factores

En los comentarios se plantearon 4 temas que no se reflejaron en nuestro estudio. Seis respuestas plantearon temas del equipo de proyecto mixto, en particular la proporción de gerentes a desarrolladores; la presencia de un número suficiente de empleados en el proyecto; y si la gerencia puede mantener una fuerte propiedad del producto. Un encuestado señaló el impacto en la productividad del tipo de software (servidor, cliente, móvil, etc.). Otro señaló la influencia de factores fisiológicos como la cantidad de horas de sueño. Otro mencionó las oportunidades de crecimiento personal.

Factores disponibles

F1. Cinco encuestados mencionaron factores relacionados con el entusiasmo en el trabajo: dos mencionaron la motivación y el reconocimiento en el trabajo, uno - moral, otro - un edificio de oficinas deprimente.



F3. Cuatro de los encuestados señalaron factores relacionados con la autonomía en la elección de métodos de trabajo. Uno mencionó la autonomía a nivel de equipo, otro sobre la política que impide el uso de un buen sistema de código abierto, el tercero sobre las prioridades adoptadas en la empresa que limitan el uso de determinadas técnicas en equipos.



F4. Un encuestado señaló la autonomía en la programación de las horas de trabajo, que se limita a las prioridades dictadas por la necesidad de promoción.



F5. Tres encuestados señalaron competencia de liderazgo. Uno mencionó el liderazgo con una estrategia coherente, el segundo, las prioridades en conflicto transmitidas por la gerencia, el tercero, la gestión de la productividad de los empleados.



F6. Ocho encuestados dijeron que proporcionaron información precisa. Tres mencionaron la comunicación entre equipos a través de documentación (y otros canales), y dos mencionaron la clara definición de los objetivos y planes del equipo.



F7. Dos encuestados notaron sentimientos positivos hacia los colegas a la luz de la cohesión del equipo y del equipo.



F8. Un encuestado señaló la autonomía para hacer el trabajo: la política de la empresa dicta los recursos que se pueden utilizar.



F9. Un encuestado señaló la resolución de conflictos, lo que indica que los hábitos personales de los compañeros de equipo eran contrarios a las normas sociales.



F10. Cuatro encuestados señalaron la competencia de los desarrolladores. Uno mencionó las dificultades para comprender el código, el otro - el conocimiento del área temática, el tercero - la seriedad de la actitud hacia las pruebas.



F11. Un encuestado señaló comentarios sobre la productividad laboral: obtener el reconocimiento de los colegas y la gerencia, promoción.



F12. Un encuestado señaló la complejidad de la implementación de software "desde mi cerebro hasta el producto enviado".



F13. Dos encuestados señalaron la variedad de tareas, en particular, las tareas de interceptación en nombre de su equipo y el cambio de contexto.



F14 Cuatro encuestados calificaron los requisitos y las personas de arquitectura como competentes. Uno mencionó la atención insuficiente a los problemas, otro - la legibilidad de los documentos arquitectónicos, el tercero - la calidad de los planes del proyecto, el cuarto - la disponibilidad de "apoyo adecuado en el desarrollo de requisitos".



F15. Treinta y dos encuestados informaron que utilizaban las mejores herramientas y enfoques. Doce mencionaron el rendimiento de las herramientas, especialmente los problemas de velocidad y latencia en la compilación y la prueba. Cinco personas mencionaron las características disponibles, tres mencionaron problemas de compatibilidad y migración, dos mencionaron que incluso la mejor herramienta disponible puede no satisfacer las necesidades. Otros comentarios sobre herramientas y enfoques han mencionado el nivel de automatización que ofrecen las herramientas; depuradores y simuladores especializados; Enfoques ágiles; pruebas inestables y herramientas relacionadas; herramientas que funcionan bien de forma remota; elección de lenguajes de programación; herramientas obsoletas; separación de las preferencias personales en herramientas de las adoptadas en la empresa.



F 16. Diecinueve encuestados señalaron una adecuada transferencia de conocimientos entre personas. Nueve personas mencionaron las dificultades de comunicarse con otros equipos: tres - acordar metas entre equipos, una - acordar metas dentro de un equipo grande, la otra - llegar a un acuerdo entre equipos. Dos señalaron la dificultad de coordinar el trabajo en un equipo internacional o de zona horaria. Otros dos mencionaron la necesidad de contar con la documentación de otros equipos. Dos comentaron sobre la duración de la revisión del código. Otros dos mencionaron el conocimiento de las instalaciones de trabajo de los compañeros de equipo. Uno mencionó la búsqueda de la persona adecuada, otro - retrasos en la interacción, el tercero - comunicación entre ingenieros y especialistas en el área temática. Finalmente, uno mencionó la importancia de dejar claroqué canales de comunicación es mejor utilizar en determinadas situaciones.



F18. Dos encuestados señalaron enfoques para la celebración de reuniones, uno mencionó que la eficacia de las reuniones depende de la disponibilidad de salas de reuniones.



F19. Veinticuatro encuestados informaron interrupciones y distracciones del trabajo. Diez mencionaron entornos ruidosos y siete indicaron que las oficinas abiertas reducen la productividad. Cuatro mencionaron dificultades con la multitarea y el cambio de contexto. Otros cuatro informaron de la necesidad de centrarse en su trabajo principal o en tareas "opcionales" como entrevistas. Dos mencionaron dificultad para concentrarse al ir y venir del trabajo.



F25. Un encuestado señaló la reutilización del código y señaló que las API de 2 a 3 líneas aumentan la complejidad con una contribución mínima para reducir la duplicación.



F26. Un encuestado comentó sobre la experiencia con la plataforma de software, indicando que los problemas empeoran cuando un desarrollador cambia de proyecto.



F27. Tres encuestados señalaron la arquitectura de software y la reducción de riesgos. Uno señaló "qué tan conocida es la arquitectura del producto, qué tan interconectada está y cómo apoya a las personas que conocen sus roles y son capaces de concentrarse, que conocen sus responsabilidades y limitaciones, y lo que poseen". Otro señaló que la arquitectura, a través de la modularidad, puede facilitar el intercambio entre componentes de software. El tercero sugirió que la arquitectura debería ser coherente con la estructura de la organización.



F32. Cuatro encuestados mencionaron la necesidad de cambiar de contexto. Dos mencionaron que el cambio es necesario cuando se cambia de proyecto. Uno explicó que la necesidad de cambiar de contexto es diferente del placer de cambiar. Otro mencionó que los “proyectos de productividad” en sí mismos pueden reducir la productividad.



F34. Cinco encuestados señalaron plazos ajustados. Uno señaló que esto contribuye al crecimiento de la deuda técnica, el otro, que tales plazos pueden conducir a una pérdida de recursos.



F42. Tres encuestados señalaron las limitaciones del software. Dos apuntaban a restricciones de privacidad y uno a restricciones de seguridad críticas.



F44. Once encuestados señalaron la complejidad del software. Dos mencionaron la complejidad particular del código heredado, dos se refirieron a la deuda técnica y cada uno señaló el control de versiones, el mantenimiento del software y la



comprensión del 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 completos de regresión lineal

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 completos de regresión lineal

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 completos de regresión lineal.