Observaci贸n de la industria: evaluaci贸n del trabajo y el valor de un desarrollador

Es un a帽o nuevo y las empresas de todo el mundo est谩n dando a los desarrolladores objetivos de A帽o Nuevo y revisando sus esfuerzos durante el a帽o pasado.

Una pregunta que escucho mucho es: “驴C贸mo califica el trabajo de un desarrollador y su valor para la organizaci贸n?”

Algunas empresas a煤n se apegan a la m茅trica de l铆neas de c贸digo creadas por un desarrollador, lo que puede no ser una evaluaci贸n justa dada la responsabilidad adicional de realizar pruebas, garantizar la seguridad, cumplir con las pautas y regulaciones, y m谩s en el complejo mundo actual.

Este m茅todo est谩 anclado en el pasado, que las organizaciones de desarrollo modernas han evitado en gran medida para crear una cultura impecable.

Las empresas con visi贸n de futuro examinar谩n el papel del equipo de desarrollo en colaboraci贸n con ingenieros de software, evaluadores, expertos en seguridad y empleados de la empresa, y adoptar谩n una visi贸n hol铆stica del desempe帽o del equipo.

“El recuento de l铆neas es una m茅trica terrible, y creo que todos podemos estar de acuerdo”, dijo Chris Downard, vicepresidente de ingenier铆a de Gigsmart, un sitio web de contrataci贸n de conciertos. “Hay momentos … en los que podr铆a ser 煤til como un punto de datos adicional, pero no necesariamente como informaci贸n”.

Cuando se trata de personas, no es bueno reducir cada acci贸n a puntos de datos. Se necesita tiempo para construir el contexto, ya que los datos a menudo pueden tergiversar las cosas. En Gigsmart, Downard dijo que no usan sprints, usan algo llamado “enfoque continuo e ininterrumpido del combate”. Sin embargo, utilizan informes de sprint compuestos por m茅tricas que se recopilan cada dos semanas para comunicar lo que sucedi贸 durante ese per铆odo.

Se帽al贸 que sab铆a lo que estaba haciendo su equipo entre los informes de sprint: trabajaron duro, trabajaron juntos y vio que aumentaba el n煤mero de solicitudes de fusi贸n. “Pero uno de los indicadores normales de productividad es, cuando se alcanzan los puntos, vamos a mover las cosas a trav茅s de la l铆nea para entregarlos”, dijo, y ese n煤mero baj贸. Sin embargo, bas谩ndose en su conocimiento del equipo y el contexto de todo lo dem谩s, redujeron el n煤mero, sabiendo que la productividad del equipo era muy, muy alta. “Es simplemente la forma en que se sacudi贸 la emisi贸n de boletos y se cre贸 un punto de datos que no necesariamente indica qu茅 es exactamente”, anot贸.

Como jefe de la organizaci贸n, dijo Downard, es necesario pensar en las cosas que se supone que la organizaci贸n debe producir y luego pensar en las medidas que indican que est谩 teniendo 茅xito o tiene problemas. Los diferentes equipos obviamente tienen diferentes objetivos.

鈥淐uando lidera un equipo de DevOps, puede encontrar importante el tiempo de resoluci贸n. Si est谩 siguiendo la parte de desarrollo de un departamento de TI, puede ser el momento de ajustar los informes y los datos. Debe perseguir las cosas que son importantes para el 茅xito de su negocio. Por eso, hago un seguimiento del n煤mero de solicitudes de fusi贸n durante una semana. Y no necesariamente hacemos nada con estos datos. No es una cosa de zanahoria y palo. Solo me da informaci贸n adicional. Un poco como un m茅dico diagnosticar铆a a un paciente. “

Sin embargo, los puntos de datos a menudo no coinciden con la calificaci贸n de productividad del desarrollador porque la programaci贸n tiene en cuenta el lado del razonamiento l贸gico del cerebro, pero tambi茅n el lado creativo. Entonces, para Downard, los puntos de datos brutos son 鈥済eneralmente terribles. Pero lo que obtenemos son muchos indicadores blandos. Obtienes informaci贸n de las actualizaciones de personas que dicen c贸mo se sienten acerca de lo que est谩n haciendo. Obtiene puntos de datos duros en el sentido de que puede ver su actividad de confirmaci贸n, pero necesita mantener el contexto. 鈥淐omo l铆der, dijo, tienes que defender a los desarrolladores y traducir lo que encuentran en todas las dem谩s organizaciones relacionadas con el desarrollo.

Seg煤n Downard, Gigsmart usa Bushido, el C贸digo de Conducta Samurai, que define los valores de c贸mo usted y c贸mo debe comportarse como individuo, como su esp铆ritu organizacional. 鈥淛ason Waldrip, nuestro director de tecnolog铆a, y yo nos sentamos y creamos un conjunto de ideales para impulsar a la organizaci贸n hacia adelante, y lo utilizo como el n煤cleo de todo lo que hacemos. Entonces, cuando empiezo a perseguir algo, hay que asignarle un valor a partir de ah铆, porque si trato de perseguir cosas que no est谩n bien asignadas a esos valores, no puedo comprometerme con esos valores con el equipo. No se pegar谩, se volver谩 hueco. “

Los puntos de datos, dijo, no son m谩s que se帽ales para investigar algo y hacer preguntas. 鈥淵 siempre debe ser exploratorio, no acusatorio. Esto es importante para nosotros.