Métricas: son como rotuladores, cada uno a su gusto. Sin métricas, la existencia de un negocio rentable como tal es imposible, nos rodean constantemente, esto es desagradable, pero un axioma. Para algunos, la métrica es el plan de ventas para el mes, para otros es la finalización del pedido antes de la fecha límite acordada, y para otros la cantidad de horas trabajadas.
No hay "Imágenes de atracción" adecuadas sobre este tema, así que tenga un gatoPor alguna razón, la palabra "métrica" en la esfera de TI está estrechamente asociada con tan "excelente" en sus prácticas de estupidez, como contar líneas de código escritas o tareas cerradas. Podemos decir con confianza que estas son las "herramientas de gestión" de control más inútiles y sin dientes. De hecho, las métricas adecuadas son, de manera bastante condicional, pero aún así, de dos tipos: métricas para el proyecto y / o trabajo, cuyo resultado y tiempo de ejecución son claros y predecibles en el tiempo, y viceversa, métricas para el proyecto y / o trabajo, el resultado y el tiempo de ejecución del cual es físicamente imposible de predecir. Para el primer tipo, se establecen métricas del resultado, y para el segundo, la distancia, en otras palabras, el tiempo trabajado.
El primer tipo de métricas "por resultado"
No existe una receta universal para establecer métricas para ningún empleado; esto siempre es un fenómeno situacional. La métrica del empleado siempre se forma a partir de una respuesta simple a la siguiente pregunta: ¿podemos predecir claramente el resultado final y, como resultado, el tiempo de trabajo a distancias cortas o medias?
Veamos la situación del trabajo independiente. Muy a menudo, los clientes establecen relaciones con los artistas intérpretes o ejecutantes sobre la base del pago por la cantidad de trabajo realizado. Es decir, hay un presupuesto para el proyecto, y la línea roja y la fecha límite para su entrega se acuerdan durante este presupuesto de negociación. Así es como trabajan los diseñadores, los diseñadores de diseño y varios desarrolladores. Muy a menudo, el presupuesto no se mueve, es decir, el "tiempo de ejecución" es la parte móvil.
Pero siempre es predecible más / menos, es decir, el cliente comprende claramente cuánto tiempo "aproximadamente" se dedicará a la ejecución de su orden. En base a esta cifra, se asigna un presupuesto, después del cual se busca un actor adecuado.
En general, el principio "no nos importa cuánto tiempo dedique a completar un pedido, solo hágalo bien y en el tiempo que sea aceptable para nosotros" se predica claramente en el entorno independiente. Esto elimina muchas preguntas sobre el monitoreo del trabajo de un profesional independiente contratado o empleado temporal, elimina la necesidad de pagarle tres, cuatro, diez veces el "salario" y así sucesivamente. Hay un tramo de prepago, hay un cierre de la cuenta final, previamente acordada.
Un enfoque similar se ha filtrado tanto a las pequeñas y medianas empresas, donde las personas parecen trabajar, como a tiempo completo, pero la compañía vive en un estado de competencia feroz y distancias cortas cuando se necesita el resultado en una fecha específica. Con “esfuerzos locos”, puede dibujar un diagrama de bloques tan áspero que lo guíe a la hora de decidir:
¿Qué pasa con las tarifas por hora de UpWork y otros modelos de tiempo independiente?
Quizás esta pregunta nació de usted, el lector, al comienzo del artículo, pero llegamos a la respuesta solo ahora. Más precisamente, a las respuestas, porque hay varias de ellas.
Primero: la compañía contratante está acostumbrada a controlar, porque la tarifa por hora en el 50% de los casos involucra un rastreador, y en el 100% - informes periódicos con una auditoría del trabajo realizado. Es decir, el cliente transfiere parte de las funciones gerenciales al contratista mismo, quien informa por sí mismo.
Segundo: la compañía necesita control sobre el proceso de desarrollo, porque solo tiene un intento. Si el proyecto se extiende por más de unas pocas semanas, el cliente debe comprender "bajo qué luz" es el trabajo. Muy a menudo, el presupuesto se asigna solo una vez para pedidos tan masivos y solo hay un intento. De hecho, una vez hubo compañías en el mercado que no requerían informes periódicos y a veces difíciles de parte de los ejecutores sobre grandes proyectos, pero les sucedió lo mismo que a los elefantes con orejas pequeñas: se extinguieron (los elefantes se sobrecalentaron, pero empresas, debido a plazos).
El segundo tipo de métricas es "a tiempo"
Pero todo se vuelve mucho, mucho más complicado si comenzamos a hablar de un proyecto grande, los plazos para los cuales van desde "de uno a tres años" y "este es un desarrollo eterno". En el caso del "desarrollo eterno", es casi imposible predecir el tiempo para obtener el resultado final siguientes razones:
- no solo una persona está trabajando en el proyecto, sino incluso varios equipos;
- cada equipo "en las direcciones" tiene de dos a tres a varias docenas de empleados;
- cuando termina el trabajo en el proyecto nadie lo sabe.
En tales condiciones, es fácil perderse y esparcir peras conocidas con un objeto conocido. Pero dado que el negocio no está involucrado en obras de caridad, es necesario pasar de las métricas "por resultados" a una categoría más compleja de métricas "por tiempo".
El ejemplo más simple y lógico de trabajar "a tiempo" es la oficina habitual a tiempo completo en empresas de 30 a 50 personas en el departamento de desarrollo. En estas condiciones, el negocio "en la costa" está de acuerdo con un empleado potencial, es decir, en la etapa de la entrevista, no sobre el momento de la finalización del proyecto, sino sobre el costo de una hora de trabajo basada en una semana laboral de 40 horas de acuerdo con el Código Laboral. Para nosotros, solo parece un salario.
Al mismo tiempo, uno debe entender claramente que los negocios no son tontos. El tamaño de la solicitud de propuesta (más precisamente, su reducción) incluye crisis de personalidad, tambaleándose por la oficina, pausas para fumar, 20-30 minutos adicionales para el almuerzo (es decir, una hora y media, en lugar de una hora) y solo la dilación en YouTube. Algunas compañías pueden pagar estos costos, debido a que el negocio actualmente es rentable y él puede permitirse una versión "ligera" de control simplemente configurando tareas a corto plazo con plazos borrosos en los que la gerencia junior y media están involucrados.
Pero si el negocio es de bajo margen o existe en un entorno Legacy competitivo, entonces todo empeora. Y aquí comienza el infierno uniforme, por lo que a los desarrolladores no les gusta tanto la palabra "métrica".
Una verdadera referencia estricta al tiempo trabajado no es una medida independiente de eficiencia, aquí se necesitan muletas.
Si a una persona se le paga no por el resultado, sino por la cantidad de tiempo trabajado, ¿cómo evaluar su efectividad? Esta pregunta la hacen constantemente las empresas. Hay varias variables aquí:
- Vinculación del rendimiento del equipo con la métrica del "resultado" en una distancia corta.
- El uso de métricas más pequeñas a nivel de tareas y sprints.
- Construyendo una estructura clara de responsabilidad, términos y prioridades, llámelo como quiera, por ejemplo, "política de desarrollo".
De hecho, el negocio se enfrenta a una situación en la que parece haber cambiado a un mecanismo más que comprensible de "tiempo de compra", pero aún es necesario controlar si se recibió algo por pagar por este tiempo en forma de resultados laborales. Es decir, nuestro concepto de "comprar un resultado" se convierte en una variable incrustada en el concepto de "tiempo de compra".
En la mayoría de los casos, sucede que la administración no puede rastrear claramente las necesidades de las empresas y los empleados al mismo tiempo, es decir, construir un sistema y una política de aplicación de métricas en las que ambas partes estén contentas con lo que está sucediendo. Lo que se quiere decir: las métricas deben cumplir simultáneamente con los intereses del negocio y ser comprensibles y factibles para los empleados.
Aquí nos enfrentamos a otro problema: si al trabajar "en orden" a distancias cortas, la tarea es a menudo clara y comprensible para todas las partes, entonces, cuando se desarrolla un producto grande, toda la estructura está en constante movimiento. Trite: los competidores lanzaron un nuevo producto o apareció un nuevo kit de herramientas, y todos los planes creados con amor por la administración se desperdiciaron.
En este punto, mucho depende de la gestión. Aquí puede describir simplemente los enfoques inadecuados y adecuados para establecer métricas.
Métricas inadecuadas:- número de líneas de código y confirmaciones;
- número de tareas cerradas sin tener en cuenta la complejidad;
- privar al desarrollador del derecho de voto;
- ignorar la dinámica y las necesidades de desarrollo en el período del informe (métricas que exceden el sentido común);
- largo proceso de revisión de métricas; falta de flexibilidad; ignorar las opiniones de desarrollo.
Aquí describí una típica "galera" cuando un desarrollador se convierte de una persona en una "máquina de escribir códigos" y no le importa cómo hace frente a las tareas / métricas a corto plazo que le llegan desde arriba. En este caso, el desarrollador pierde cualquier oportunidad de influir en el desarrollo, incluso si ve el "interior" del problema. Al mismo tiempo, la complejidad de las tareas no se tiene en cuenta y todo se reduce al trabajo de mono.
Métricas adecuadas:- Contabilización de la complejidad de la tarea;
- La capacidad de revisar las métricas después del hecho cuando surgen problemas;
- Capacidad para comentar sobre la tarea;
- Falta de vinculación estrecha con los indicadores cuantitativos de líneas de código / número de tareas;
- Ignorando el incumplimiento parcial de las métricas, si es necesario.
Las métricas adecuadas son aquellas métricas que no están clavadas al piso y que se pueden mover. Si una empresa busca la máxima eficiencia, entonces esta eficiencia debe ser a todos los niveles. Durante mucho tiempo ha quedado claro que la cantidad de tareas o líneas de código, de hecho, no significa mucho, ya que algunas tareas pueden tener un efecto decisivo en el producto y cientos de otras cuestan.
Además, la estrecha vinculación al cumplimiento de las métricas es contraproducente: si el desarrollador sabe que tendrá "problemas" debido al hecho de que cerró 19 tareas en una semana en lugar de 20, entonces la calidad de la tarea pasa a un segundo plano. Y el último mínimo, 20 tareas, se colocará en el "basurero", con muletas y bicicletas en lugar de verdaderamente y de una vez por todas para resolver la tarea.
La retroalimentación como parte integral del modelo de "compra de tiempo"
De hecho, un modelo de desarrollo bien construido, vinculado al tiempo de trabajo, es mucho más complicado de lo que parece a primera vista. Para trabajar eficazmente en este modelo, se deben organizar comentarios de alta calidad entre los artistas y los líderes, que deben ajustar constantemente la "política de partido" en todos los niveles. Después de todo, una tarea planteada inadecuadamente, es decir, una métrica formulada, está lejos de ser un problema para los desarrolladores, aunque es habitual llevar este problema a los artistas intérpretes o ejecutantes. Una métrica inadecuadamente formulada es un problema, solo de la administración que ha establecido esta tarea para los contratistas, siempre que el trabajo de ambas partes sea transparente.
Es la administración la que debe organizar el trabajo para que el tiempo de trabajo se gaste de manera eficiente, es decir, los presupuestos no se "quemen", pero al mismo tiempo, los desarrolladores podrían hacer frente a sus tareas sin agotamiento total en unas pocas semanas. Porque el recurso humano, aunque vasta, pero no infinito, especialmente cuando se trata de personal calificado.
Es la presencia de comentarios y la responsabilidad de las decisiones tomadas por la gerencia lo que difiere de una compañía que mantiene un registro detallado de las horas trabajadas, de una "galería" explícita donde los desarrolladores caen en una picadora de carne sin sentido.
Es la retroalimentación la que le permite a la empresa encontrar cuellos de botella en el desarrollo. ¿Con qué frecuencia se encontró con una situación en la que los empleados de un departamento se asfixiaban, trabajaban por el uso y el desgaste, pero no recibieron "refuerzos" en forma de un par de nuevos especialistas que reemplazarían un hombro y tomarían parte de la carga? Tales situaciones surgen todo el tiempo precisamente debido a la falta de comentarios de alta calidad entre el desarrollo y la gestión. En lugar de rastrear claramente la efectividad del equipo y su carga, el gerente se mete el dedo en la nariz y cuando alguien "se rompe", incapaz de soportar ese ritmo, todo empuja a los desarrolladores restantes. No hagas eso.
En lugar de salida
Lo peor que puede suceder en el proceso de organización de un proceso de trabajo es "distorsionar" los mecanismos inherentes en un modelo a otro. Por ejemplo, cuando se establecen plazos estrictos para proyectos a largo plazo sin una evaluación sólida de la complejidad y las capacidades del equipo. O cuando se trata de proyectos y tareas autosuficientes a corto plazo, tales formas de control se incorporan para que puedan encajar en el campo de la ciencia de cohetes, y estamos hablando solo de una orden de trabajo independiente.
Una comprensión clara de la idoneidad de ciertos métodos de trabajo en empresas de diversas estructuras y tamaños ayudará a preservar una gran parte de la salud y el sistema nervioso al buscar trabajo. Y mientras más desarrolladores, gerentes y dueños de negocios entiendan estos mecanismos, mejor será para todos los participantes en el segmento de TI.