Permitir que los PM califiquen/clasifiquen a los desarrolladores

Primero, cada tasación, sin importar quién la haga, es arbitraria hasta cierto punto. Si alguien no está de acuerdo con eso, debería encontrar un lugar donde no haya evaluaciones en absoluto.

En segundo lugar, para alguien que busca retroalimentación, más retroalimentación siempre debería ser mejor que menos retroalimentación. Quiero decir, incluso cuando no estoy completamente de acuerdo con la opinión de alguien, puede ser muy valioso porque muestra cómo otros ven mi trabajo y, posiblemente, lo que puedo hacer para cambiar sus puntos de vista.

Desde estas perspectivas, es bueno encontrar una manera de incorporar los comentarios de casi cualquier persona que esté relacionada de alguna manera con el trabajo de los desarrolladores para su evaluación. Y PM es definitivamente una persona cuyo trabajo está "de alguna manera conectado" con el desarrollo.

Hablando de eso, PM tiene una perspectiva bastante diferente de un proyecto, por lo que sus comentarios serán aún más valiosos. Si mantenemos los comentarios solo dentro de un grupo funcional, aquí: los desarrolladores y el administrador funcional de los desarrolladores obtenemos una vista bastante homogénea de un proyecto. Traer otro punto de vista, especialmente de alguien que trabaja más cerca de un cliente, definitivamente ayudaría a mejorarlo.

Nota: En mi respuesta, me estoy enfocando en la retroalimentación en general y no en una calificación, índice, calificación o como lo llames.

Esto se debe a que, en términos de evaluación de personas, cualquier sistema de calificación es complicado por defecto.

Mi consejo sería incorporar los comentarios entregados por los PM, pero evitar cualquier calificación directa de los desarrolladores. Si el gerente funcional no está completamente a la defensiva cuando se trata de su gente, debería poder brindar dicha retroalimentación a las personas de una manera valiosa. Sin embargo, tal enfoque requiere confianza entre casi todos los que están alrededor: PM, un gerente y un miembro del equipo. PM confía en que sus comentarios llegarán a un desarrollador. Un gerente confía en recibir comentarios honestos, directos y posiblemente basados ​​en hechos. Un desarrollador confía en que nadie intenta atropellarlo, etc.

Dependiendo de los estándares de su organización, puede ser una forma estándar de calificar a las personas en una escala y, si es así, no digo que deba evitarlo a toda costa. Recuerde que la retroalimentación de PM es solo una parte del juicio total sobre el trabajo de uno.

Si las personas (aquí: PM) nunca entregaron comentarios a otros miembros del equipo, el sistema de calificación puede ser una buena manera de estandarizar la forma en que construyen sus comentarios.

Por otro lado, evite cualquier medida automática, como una cantidad de errores, líneas de código, etc. No tiene nada que ver con la retroalimentación y solo hará subir o bajar los números medidos (según el objetivo) sin influencia directa en la calidad. , por ejemplo, si mide una cantidad de errores enviados , puede estar bastante seguro de que la gente dejará de enviar errores; no dice mucho sobre la calidad de un proyecto e incluso nubla más su visibilidad.

Insectos:

La programación generalmente implica tomar muchos conceptos vagos o abstractos y luego unirlos para construir algo grandioso. Juzgar a los desarrolladores en función de la cantidad de errores en el código quizás sea una de las peores formas en que una organización puede dispararse en el pie.

En un mundo donde todo es tan ágil, no hay un plan a seguir. No estamos construyendo casas, la forma más pura de modelo de cascada posible, donde sabemos que cada montante debe estar a 16 pulgadas de distancia porque así es como construimos las últimas 15 casas. Cada proyecto de software es fundamentalmente diferente de alguna manera significativa de otros proyectos de software.

Por lo tanto, los errores son solo un hecho de la vida. Todo el software tendrá errores, porque muchas veces los desarrolladores unen cosas que nunca antes se habían unido. No base el rendimiento en errores, a menos que su objetivo sea desmoralizar y derrotar a su equipo.

Velocidad de codificación:

Algunos desarrolladores pueden codificar muy rápidamente, pero luego de 6 a 12 meses; De repente, el progreso se detiene debido a todos los atajos y las malas decisiones tomadas en el código. Los programadores no son mecanógrafos. No mides el éxito por la rapidez con la que pueden arrojar código en su editor.

Otros desarrolladores son metódicos, pacientes y orientados a los detalles. Se toman el tiempo para pensar qué enfoque garantizará el éxito del producto. Sus decisiones aseguran que el producto aún pueda recibir soporte dentro de muchos años. Se aseguran de que cuando una parte del sistema cambie, no se cree un efecto dominó que repercuta en todo el código base, eliminando todo lo demás. Su código está bien comentado, es legible, está diseñado y es fácil de mantener.

Entiendo por qué nosotros, como gerentes de proyecto, queremos medir esto, pero debemos entender que este es un equilibrio muy delicado, posiblemente inconmensurable, e implica un buen juicio y toma de decisiones por parte de los técnicos del proyecto.

A los desarrolladores generalmente se les paga un salario porque sus trabajos implican la capacidad de tomar decisiones y juicios, no producir pequeños artilugios redondos en una línea de producción de salario mínimo.

Cumplimiento de los requisitos:

El desarrollo de software es un proceso creativo. También es un proceso de ingeniería. El proceso de ingeniería entra en juego cuando el desarrollador tiene que asegurarse de que entiende qué es lo que se debe construir. Usando lógica, buena documentación, a veces métodos formales y planificación, un desarrollador debe poder tener una idea clara de lo que debe construir.

La parte creativa entra en juego con la resolución real de los problemas que finalmente surgirán durante el proceso de desarrollo. Esto también ocurre a veces en otros campos, como en la construcción. Tal vez haya alguna razón por la que los dos últimos montantes no puedan tener una separación de 16 pulgadas, por lo que se debe poner algo de creatividad para encontrar una solución segura y sostenible. Con el software, a veces los desarrolladores se topan con muros, y deben encontrar una manera de sortear ese muro tomando lo que saben sobre varios conceptos de programación diferentes y luego juntarlos para encontrar una gran solución.

Ahora, la parte de la creatividad del desarrollo de software no significa que el desarrollador deba construir lo que quiera construir; en cambio, el desarrollador aún debe cumplir con los requisitos. La parte creativa está en el enfoque para resolver el problema, no en el problema real en sí.

Dicho esto, a veces los ingenieros presentan ideas creativas que pueden mejorar el producto. Sin embargo, si esos elementos se implementan o no depende únicamente de a quién está destinado el producto. En una startup, es probable que el ingeniero tenga mucha libertad para innovar y crear algo que inculque pasión en las personas. Por otro lado, en una gran corporación que crea software personalizado para un cliente, el objetivo es entregar lo que el cliente desea, y eso puede dejar poco espacio en los requisitos para cambios no solicitados.

Resumen

En resumen, los dos primeros puntos son elementos que simplemente no tiene sentido medir. Los insectos son un hecho de la vida. Solo mírelos como características inacabadas o como parte del proceso de mejora. La velocidad de codificación puede no ser una función del éxito del proyecto porque la codificación es un proceso de ingeniería, no un proceso de fabricación. Finalmente, el cumplimiento de los requisitos puede cambiar de un proyecto a otro y puede no ser medible o importante en algunos proyectos.

En su lugar, concéntrese en evaluar a las personas. ¿Es fácil llevarse bien con él? ¿Ayuda a motivar a otros miembros del equipo? ¿Ayuda a colaborar con el equipo y genera ideas para resolver problemas? ¿Confía en que esta persona entregará lo que él o ella dice que entregará? Cuando se encuentran errores, ¿se responsabiliza y profundiza apasionadamente y corrige la función inconclusa (error)?

Por su propia naturaleza, el desarrollo de software es un proceso subjetivo y no puede utilizar criterios de evaluación objetivos para evaluar puestos como este sin perjudicarse a sí mismo, a su equipo ya su organización.

No creo que ser desarrollador sea relevante para responder a esta pregunta. Vivimos en un mundo donde somos medidos por nuestro desempeño, sin importar la actividad o el trabajo que estemos realizando. Ser medido y comparado con nuestros pares es consistente con establecer metas y lograrlas, una competencia sana y eliminar a los que no pertenecen. Cómo uno se siente al respecto es irrelevante.

La vara de medir que utilice debe ser una versión descompuesta de la vara utilizada para medir el desempeño de la organización.

Siempre habrá efectos secundarios no deseados en una métrica. En muchos casos, esos efectos secundarios no tienen consecuencias para la organización. En otros casos, la métrica que elija provocará un cambio de comportamiento que no deseaba. Entonces lo abordas inteligentemente. No mida algo simplemente para decir que está midiendo. Mídalo porque tiene un objetivo que debe cumplir y está atento a los comportamientos no deseados que también puede producir.

Los directores de proyecto deben centrarse en la gestión del tiempo y los recursos para cumplir con el plazo. Yo pensaría que no importa cuál sea la disciplina, un PM debería poder calificar cómo los miembros del equipo participan en el inicio del proyecto (participaron), qué tan bien planificaron (su falta de planificación o falta de habilidad en la planificación afectó negativamente el cronograma) ejecutan (¿coincidieron sus estimaciones con su producción real o tasa de quemado?) y qué tan bien monitorean y controlan (trabajo correcto dentro de su área de influencia) y cerraron el proyecto correctamente (comprometen lecciones aprendidas, presenten entregas contractuales finales, etc.).

Sin embargo, creo que la premisa y los detalles de su pregunta en el área de desarrollo de software (número de errores, etc.) son erróneos. Los PM deben centrarse en las áreas de disciplina que conocen. Si bien creo que, como equipo, podría haber métricas definidas que coincidan con las áreas de conocimiento de PM (por ejemplo, áreas de conocimiento clásicas de PMI asignadas a lo que el equipo de programación crea que es una métrica coincidente para esa área), evitaría influir y administrar a un programador o equipo de programación. a menos que formara parte del equipo y fuera afectado por la(s) medición(es).

Usted dice que está buscando "aplicar algún tipo de calificación" basada en:

1. número de errores
2. velocidad de código
3. adherencia a los requisitos

solo el último de ellos tiene algún tipo de parte subjetiva de la medición e incluso entonces, dependiendo del rigor y la granularidad del seguimiento de sus requisitos, eso puede estar sujeto a debate.

Así que mi pregunta es ¿por qué convertir esto en la tarifa del PM? ¿Por qué no simplemente hacerlo automatizado? busque la cantidad de errores, las métricas de rendimiento en las pruebas nocturnas, etc. para el código de cada desarrollador y mantenga un promedio móvil o algo así.

Por supuesto, si lo convierte en una métrica automatizada, corre el riesgo de que los desarrolladores jueguen con el sistema. Si lo convierte en una medida puramente subjetiva de las opiniones del gerente del proyecto sobre el código de los desarrolladores, entonces es una medida bastante inútil a menos que sus PM también sean desarrolladores.

Soy un desarrollador y no me agradaría que una persona no técnica calificara mi código en una escala arbitraria. Es difícil para mí ofrecer una mejor solución sin saber lo que está tratando de lograr o si hay un problema subyacente que está tratando de abordar.

Los gerentes de proyecto deben participar absolutamente en las revisiones de desempeño de las personas en sus equipos.