Hice una pregunta en líneas de código por hora y obtuve una nueva. Así que mi pregunta de seguimiento madura es la siguiente:
Si no son líneas de código, ¿cuál es una buena medida para medir (por hora / día / unidad de tiempo) la efectividad de los programadores remotos?
En 16 años nunca he encontrado una métrica viable del tipo que estás buscando.
Esencialmente, para ser útil, cualquier cosa debería ser medible, representativa e indecible (es decir, el sistema no puede ser jugado por desarrolladores inteligentes). Simplemente, hay demasiadas variables dentro del desarrollo de software para que pueda medirse como una pieza de esta manera.
Lo más cercano a usted es el progreso en comparación con las estimaciones, es decir, cuántas tareas están completando dentro de las estimaciones acordadas. El truco aquí es (a) obtener estimaciones buenas y justas y (b) comprender dónde se han superado las estimaciones por buenas razones por las cuales el desarrollador no puede / no debe ser culpado (eso es algo realmente más complejo de lo previsto). En última instancia, si presionas demasiado a los desarrolladores, es probable que encuentres estimaciones que aumenten gradualmente hasta un nivel en el que siempre se cumplan, no por el aumento de la productividad, sino por escalas de tiempo acolchadas.
Vaya al otro lado demasiado en términos de las estimaciones (reduciéndolas para crear presión para entregar) y cree plazos falsos que los estudios han demostrado que no aumentan la productividad y es probable que tengan un impacto en la moral del equipo (vea Peopleware para más información).
Pero esencialmente me pregunto si estás viendo un problema ligeramente falso. ¿Por qué los programadores remotos son diferentes a otros programadores cuando se trata de medir la productividad? ¿Cómo mide la productividad de los programadores no remotos?
Si se trata de no confiar en que trabajen de forma remota, eso es básicamente un problema de confianza más amplio. Si no confías en ellos para que trabajen desde casa, entonces debes establecer esa confianza, no dejar que trabajen desde casa o encontrar alguna forma de satisfacerte de que realmente están trabajando cuando se supone que deben estarlo.
Las métricas funcionan mejor en fábricas y los programadores no funcionan en una línea de ensamblaje.
Entiendo completamente el deseo de medir la productividad.
¿Pero usaría la misma métrica para un médico de familia y un cirujano cardíaco? ¿Qué tal si Miguel Ángel pinta la Capilla Sixtina y algún tipo en México que saca pinturas de terciopelo negro de Elvis?
Louis de Broglie escribió una tesis doctoral que fue tan breve que los examinadores la rechazarían, excepto que De Broglie era un aristócrata muy bien ubicado y necesitaban una buena excusa. Así que los examinadores lo enviaron a Einstein, quien no solo no lo rechazó, sino que lo remitió al comité del Nobel, y De Broglie recibió el Premio Nobel de Física cinco años después.
Las medidas numéricas funcionan mejor en el trabajo que es repetitivo, como fundir hierro o atornillar tornillos en las puertas de los autos. Pero si está repitiendo el código que se ha hecho anteriormente, no necesita un programador, solo necesita copiar y pegar. La programación es fundamentalmente una disciplina creativa, y la productividad depende completamente de lo que estás haciendo.
Algunos días, arranco 1000 líneas de código. Hoy, voy a corregir errores de geometría de coordenadas, y el código podría reducirse. Si tuviera que corregir un error en un controlador del kernel de Linux, podría dedicar todo el día a la depuración y no escribir una línea de código nuevo.
La medición de la productividad del programador es muy, muy, muy subjetiva .
Si desea saber si Joe es productivo, busque a Sally y Ralph, quiénes saben qué está haciendo Joe y tienen competencia en las mismas áreas, y pregúnteles.
El mejor sistema numérico que he visto en mi vida ha sido la planificación de puntos de póquer de Agile. Esa es solo una manera elegante de preguntarle a Joe, a Sally y a Ralph qué tan duro creen que será el próximo trabajo de Joe. Luego puede medir la productividad en puntos por semana para cada miembro del equipo. Pero incluso entonces, toma un tiempo calibrar las estimaciones de un equipo, y los números son confusos y fáciles de descartar.
Muchas personas quieren estimaciones de productividad para poder planificar su programación. Es algo así como la teoría de "enchúfelo a MS Project, observe el camino crítico y está la fecha de envío". Nunca, nunca he visto ese trabajo, hay demasiadas incógnitas. Si quieres eso, usa Waterfall, diseña todo por adelantado, no permitas ningún cambio y prepárate para decepcionarte de todos modos.
La única métrica que utilizo es la cantidad de software en funcionamiento que produce por una cantidad de dinero dada que he invertido
Independientemente de su horario, si trabaja de forma remota o no, la cantidad de pausas que toma, las metodologías que usa o la cantidad de horas de trabajo.
Por software de trabajo quiero decir:
Lista de funciones definidas por el usuario / cliente que cumple con el nivel de calidad requerido
Por cantidad de dinero :
Cuánto pagó el usuario / cliente por las funciones definidas + los costos de mantenimiento
Por lo tanto, tiene información directa sobre cómo se construye y la calidad del trabajo producido, pero no está vinculado a ninguna métrica de línea de código fuente.
Necesita un desarrollador o líder de equipo experimentado (que no esté asociado con esos programadores remotos) para estimar cuánto tiempo puede llevar una tarea, y la efectividad se mide comparando el tiempo requerido con las estimaciones. Para asegurarse de que las estimaciones sean buenas, puede seleccionar algunas tareas al azar y hacer que las ejecute un equipo interno que tenga bajo control.
Otra forma interesante de medir la productividad sería contar las pruebas automatizables revisadas por un gerente por día. El desarrollador obtiene:
El desarrollador y el administrador pueden mejorar conjuntamente el sistema de la siguiente manera:
El desarrollador no puede reproducir la métrica porque:
El administrador no puede jugar con la métrica porque:
El desarrollador no puede atornillar al administrador porque
El administrador no puede atornillar al desarrollador porque.
Otro gran beneficio para el administrador es que puede atraer a nuevos desarrolladores y saber que no podrán entregar el código que rompe el sistema en silencio (porque el conjunto de pruebas de regresión lo detecta).
La gran desventaja del gerente es que lo obliga a admitir que su sistema es más complejo de lo que parece en la descripción de 1 página de la característica. El otro inconveniente es que la transparencia de este método hará que sea difícil culpar a los desarrolladores por el fracaso empresarial.
Ciertamente, es posible diseñar todo tipo de métricas complejas para evaluar el desempeño, pero al final del día, una parte importante de su juicio tiene que depender de la subjetividad y los comentarios de las personas que están cerca del código base.
Por ejemplo, es bastante posible que algún equipo logre una pendiente que no se puede mantener internamente horrible a una velocidad muy rápida, y esto podría incluso cumplir con la fecha límite y las especificaciones requeridas. Pero, ¿la deuda técnica acumulada de ese tipo de estilo de trabajo es peor que si el equipo hubiera generado algo sólido y mantenible, pero no cumplió con el plazo de algunas semanas? Depende.
Si el propósito de la pregunta es resolver algún tipo de problema de productividad, diría que lo que realmente hace el gerente para facilitar el trabajo del equipo es tan o más importante que cualquier técnica de medición utilizada para evaluar el equipo . Es una calle de doble sentido. En otras palabras, estoy diciendo que las métricas están bien, pero si quiere más de un equipo, la pregunta final es si el gerente está haciendo todo lo posible para garantizar que el equipo pueda ser productivo.
Esto va más allá de escribir una especificación, encontrar un equipo, lanzar la especificación "sobre la pared" y hacer clic en un cronómetro.
Algunas ideas:
También es posible que desee realizar un seguimiento:
Mida de la misma manera que lo mide el cliente. En términos de código funcional, pero a menor escala.
Haga metas cortas, una o dos semanas, y vea si los programadores cumplen las metas, y hágalo de manera satisfactoria.
Yo sugeriría encarecidamente la revisión por pares de un código, ya que esto te permite capturar un código incorrecto por adelantado.
Cómo sobre la tasa de ventas del producto / servicio.
Algunas veces he escuchado que se llama comisión / porcentaje del bruto
La gente compra buenos productos, ¿no?
La empresa quiere vender el producto (o quizás el servicio, la misma diferencia para esto)
Así que si eso es lo que quieres, mídelo.
Un poco como decir que las personas que diseñan un auto que obtiene buenas críticas y amp; vende bien, realmente han hecho un buen trabajo.
Ahora adopte esta métrica y el equipo de programación querrá interactuar con el vendedor por dos razones.
Promsing underliverable
No vender productos a clientes de manera efectiva
Escribir código / Programar no es como poner un martillo en un clavo. Al igual que la "escritura" en general, no es algo que se pueda aplicar normalmente en las métricas, en mi opinión.
¿No podrías simplemente mirar sus registros o lo que han hecho a través de la revisión por pares, la revisión del código?
¿O sabe, si realmente producen código de trabajo y soluciones que solucionan problemas?
Utilice una metodología por la cual la documentación escrita se aleje con el código escrito. Comience la semana decidiendo qué debe hacerse, obtenga un acuerdo, luego espere hasta el final de la semana para ver si se ha hecho o no. Mantenga las tareas pequeñas y medibles como en cuántos días. No creo que deba medir el trabajo de los programadores por voz, pero el acuerdo sobre lo que se debe entregar y cuándo es una necesidad para el control.
La segunda parte de esta solución serían las revisiones de código de igual a igual, respaldadas por algún tipo de sistema de control de versiones que determina quién hizo qué y cuándo se puede rastrear. Si el consenso es que el código es bueno, entonces su ganador es, si es malo, entonces averigüe por qué y cómo podría mejorarse.
Los estudios de tiempo y movimiento son un no, por lo que a mí respecta, algunos códigos como Regexes o alguna lógica realmente difícil pueden tardar días en desarrollarse, pero solo pueden formar un par de líneas de código. La única medición verdadera son los entregables a tiempo, en un tiempo acordado.
Lea otras preguntas en las etiquetas project-management productivity metrics efficiency