¿Cuál es la mejor manera de rastrear la productividad de los desarrolladores y diseñadores web?

Lo que debe hacer es medir el rendimiento, que se realiza mejor utilizando la metodología de desarrollo de software Agile. Básicamente, significa que divide un proyecto en una gran cantidad de pequeñas tareas que podrían ser tan simples como “agregar botón en formulario1” o “escribir registro en la base de datos”. Para cada tarea, se debe hacer una estimación de cuánto tiempo debe tomar arreglarlo.

Cada dos semanas, el equipo debería poder realizar aproximadamente 56 horas por desarrollador de estas tareas (28 horas por semana) y el tiempo restante debe dedicarse a otras cosas como estudiar, investigar y lo que sea más. Este período de dos semanas se llama ‘Sprint’ y podría usar sprints más largos o más cortos, sin embargo, dos semanas es un buen promedio.

Si está subcontratando, ¡solo debe pagar esas 56 horas! No para otro momento que esos desarrolladores necesitarán.

También asegúrese de implementar pruebas unitarias y métodos de compilación automatizados adicionales. Lo necesitará para asegurarse de que la calidad del código sea alta. Todavía no se realiza ninguna tarea que falle la prueba de unidad relacionada.

Cada dos semanas, simplemente verifica si todas las tareas asignadas para este período han tenido éxito. ¡Si lo hicieron, su equipo está funcionando bastante bien! Si no, trate de encontrar la causa por la cual el equipo no cumple con estos plazos. ¿Las estimaciones fueron incorrectas? ¿Alguien se enfermó? ¿Qué pasó que causó la demora? Los retrasos no son tan malos si hay una buena explicación, pero si aún logran entregar la mayoría de las tareas a tiempo, siguen siendo un buen equipo.

Si las pruebas unitarias fallan a menudo, entonces hay algo mal con los desarrolladores. No están haciendo bien su trabajo si siguen fallando estas pruebas. Una prueba unitaria básicamente dice: “Estos datos entran y espero que salgan”. y no se conforman con eso. Esta no es una buena señal.

La prueba de la unidad debe ser parte de la compilación automatizada y esta compilación automática debe ejecutarse diariamente, si se han producido cambios en el código. (La compilación automatizada es más que simplemente compilar todo. ¡Tiene que configurar el entorno de prueba completo!) Durante el sprint, las pruebas unitarias pueden fallar ya que los desarrolladores aún pueden estar trabajando en eso. ¡Pero al final de cada sprint, todas las pruebas unitarias deben tener éxito para las cosas implementadas durante este período y para todas las cosas implementadas antes del sprint! Suele suceder que un cambio en el sprint actual romperá algo creado anteriormente, por lo que eso no debería suceder.

Si las pruebas unitarias fallan, el sprint falló técnicamente y hay que pensar en las consecuencias. Si se trata solo de un par de tareas, estas podrían pasar al siguiente sprint, pero esto significa que otras tareas también avanzarán, incluida la fecha límite de su proyecto. Si esto significa que su fecha límite final se retrasará por meses, ¡entonces su equipo se desempeña mal! Todavía no tiene que ser culpa suya, pero tendrá que encontrar una buena explicación para todo.

Además, una vez que el proyecto comience a tener alguna forma, necesitará algunos probadores para probar el proyecto manualmente. Esto significa que tendrán que configurar planes y escenarios de prueba y cada vez que finalice un sprint, deberán probar la última compilación para detectar cualquier error que puedan encontrar. Esto difiere de las pruebas unitarias porque las pruebas unitarias solo prueban pequeños fragmentos de código. Las pruebas manuales probarán todo, por lo tanto, todo combinado.

Estos resultados de la prueba también proporcionarán una indicación de la calidad de su equipo. Sus probadores sabrán qué tareas se han implementado y si encuentran errores, básicamente significa que algunas tareas aún fallan, por lo que deben rehacerse. Esto también causa retrasos en su fecha límite.

Para los desarrolladores de .NET, la mejor herramienta para esto sería Team Foundation Server, que le permite administrar proyectos completos, definir tareas y subtareas y medir el rendimiento mediante gráficos y otras herramientas. También proporciona un entorno para que los desarrolladores y otros miembros del equipo se comuniquen sobre tareas específicas.

Para otros entornos, los servicios en línea como Axosoft o YouTrack serían buenas opciones.

Básicamente, no está preguntando a los desarrolladores qué han hecho, sino que les proporciona un montón de tareas y le dirán cuáles están terminadas. Validas si las tareas están realmente terminadas y mides qué tan rápido están terminando las tareas, lo que comparas con qué tan rápido deben funcionar. Esto dice mucho sobre su calidad.

Olvídese de la idiotez desafortunadamente común de aplicar conceptos de productividad industrial fordistas (con el seguimiento y la medición del tiempo como la idiotez más grande de todos) al trabajo del conocimiento. Es una trampa de gestión que dañará su negocio al establecer incentivos perjudiciales, alienar a los mejores talentos, etc.

En cambio: establezca objetivos claros en términos de la contribución de valor que se debe proporcionar, enfóquese en los resultados, enfóquese en el ROI. Haga que las personas sean responsables no de aparecer, el tiempo dedicado, las líneas de código escritas, etc., sino en términos de qué valor ofrecen. Hacerlos responsables en términos de desarrollo (lo que les permite aumentar el valor que pueden contribuir). Haga que la gerencia sea responsable de proporcionar el liderazgo necesario que permita buenos resultados.

Y no intente resolver conjuntos de problemas de gestión conceptual con herramientas, simplemente mitigaría el problema. Sabrá qué medir una vez que tenga una idea clara y razonable de cómo se crea el valor dentro de su empresa / unidad / equipo.

La compañía con la que trabajo actualmente utiliza listas de tareas y tiene supervisores que verifican las tareas después de que un desarrollador las marca resueltas.

Mira algo como Asana o Basecamp.