software pmp most management kpis indicators examples ejemplos common process-management kpi

process management - pmp - ¿Qué medidas usas para mejorar tus procesos?



project management indicators examples (9)

Esta pregunta originalmente preguntaba ''¿Qué KPI usas en una organización de desarrollo de software''? Desafortunadamente, parece que KPI es una palabra de cuatro letras, y la suposición inmediata es que los KPI siempre se usan mal (¿quizás sí?).

Por lo tanto, espero haber mejorado la pregunta para llegar a los objetivos subyacentes que originalmente pensé que los KPI eran útiles. Asumiendo que tiene algún proceso sobre cómo usted (o su organización) desarrolla software. En segundo lugar, suponga que usted (o su equipo) quiere mejorar en el desarrollo y el software de entrega. Finalmente, asuma que una de las formas de mejorar es refinando su proceso.

Teniendo en cuenta todo esto, ¿cómo sabe si los refinamientos de su proceso están teniendo un impacto positivo? Si se trata de KPI o [objetivos SMART] ( http://en.wikipedia.org/wiki/SMART_(project_management) , proporcione objetivos de KPI / SMART individuales o grupales que haya comprobado que sean efectivos. algún otro mecanismo, por favor explica qué es. Finalmente, supongo, si no crees que mejorar los procesos es algo útil, supongo que también puedes explicarlo.

Las áreas de mejora que creo que serían útiles son: calidad, puntualidad de las entregas, productividad, flexibilidad. Si hay otros aspectos de un individuo o equipo de desarrolladores, entonces sería interesante saberlo.

Notas aclaratorias:

La pregunta no es sobre cómo adaptar o cambiar mejor un proceso, o qué proceso de mejora de proceso es bueno (ya sea Kaizen, retrospectivas, etc.). Tampoco se trata de análisis de causa raíz u otros enfoques utilizados para determinar qué aspectos específicos de un proceso deberían mejorarse.

El uso de medidas para determinar si se ha logrado la mejora del proceso no debe confundirse con la mejora continua del proceso, como ocurre. (Eso es algo bueno, ¡pero de eso no se trata la pregunta!)

El proceso podría ser cualquier cosa; scrum, ágil, extrema, cascada, ad-hoc. Esta pregunta no es sobre qué proceso es mejor para ciertos tipos de desarrollo de software, sino cómo mejorar ese proceso a lo largo del tiempo.

Obviamente, la métrica específica dependerá del proceso involucrado y del problema percibido que intenta mejorarse. Esta pregunta simplemente está diseñada para obtener ejemplos de métricas utilizadas, que obviamente abarcarían una cantidad de procesos diferentes y áreas de mejora.

La métrica no necesita ser algo que se use todo el tiempo , por ejemplo, podría usarse solo mientras se prueba si funciona un cambio de proceso. (Por ejemplo, podría ser demasiado costoso, en tiempo o dinero, medir y rastrear en todo momento, por lo que solo puede rastrear el proceso).

Se toma como un hecho que si se implementa mal, el uso de métricas puede tener un efecto perjudicial a medida que los desarrolladores juegan con el sistema o de lo contrario. Se supone que la persona que implementa el cambio de proceso es consciente de este problema y ha tomado medidas efectivas para mitigarlo.

Todas las organizaciones de software son diferentes y cómo encajan en su empresa, por lo que se esperan diferentes cosas específicas dentro de la empresa, sin embargo, creo que la calidad del producto, la productividad, la flexibilidad y la puntualidad de los lanzamientos son aplicables a la mayoría si no a todas las organizaciones. (Con énfasis obviamente diferente dependiendo de la organización específica).

¡Esta pregunta no tiene nada que ver con las líneas de código fuente ! En particular, no estoy interesado en medir la productividad del programador, especialmente en términos de SLOC o n. ° de errores corregidos, o cualquier otra medida ingenua. Me interesa el nivel superior en que un equipo o un individuo mide su mejora. No estoy interesado en usar un solo KPI para medir el rendimiento de nadie. Estoy interesado en usar una gama de KPI para medir y mejorar los procesos de desarrollo de software de mi equipo.

Sé de historias de terror sobre KPI que se usan mal y son ineficaces (no es necesario buscar mucho para encontrarlas), pero no puedo creer que nadie intente mejorar continuamente sus procesos, por lo que debe haber algunos buenos ejemplos de KPI por ahí.

Sé todo sobre los inconvenientes de las métricas simplistas que se aplican a los programadores de software individuales. Realmente espero obtener ejemplos de KPI o estrategias alternativas que las personas consideren útiles, en lugar de todas las razones por las que no debería usar KPI.

Me interesan principalmente los procesos y el rendimiento relacionados con una organización de desarrollo dentro de una empresa más grande, en comparación con una empresa de desarrollo de software en general. Por ejemplo, una empresa de software debe asegurarse de que los productos tengan las características correctas para el mercado, pero generalmente esa es la función de la gestión del producto, en lugar de la ingeniería. Y sí, hay otra discusión completa sobre por qué y hasta qué punto los ingenieros deberían participar en la gestión de productos, pero eso es una discusión por separado.

Basar sus KPI en Costo, Calidad y Horario sería un buen comienzo. Considere cuáles son los atributos para cada uno de los que quiere medir.

Ser capaz de dividir cada una de estas medidas para mostrar el costo de los errores sería útil; muchos intentos de corregir errores tarde en el proyecto significan un costo / aplastamiento del programa. Ser capaz de determinar qué partes de la base de código tienen errores podría ayudar a seleccionar pruebas adicionales y reescribir el código posible: generalmente el 80% de los errores provienen del 20% del código. Saber dónde está eso permitirá que su equipo se enfoque mejor.

EDITAR : Mire medidas como Costo de calidad (CoQ) y Costo de calidad deficiente (CoPQ).

Las medidas como la productividad siempre son difíciles de cuantificar, por ejemplo, el uso de LOC / día lleva a un debate sobre qué es exactamente una línea de código. También puede conducir a un formato de código tonto para "aumentar" la productividad si los desarrolladores no entienden por qué estas cosas se están rastreando o perciben como mediciones personales. Incluso si LOC / día no se mide en el nivel de desarrollador, aún puede obtener rivalidad de equipo que lo lleve al mismo resultado.

EDITAR: Hay algunas buenas discusiones que se pueden encontrar en el sitio web Construx de Steve McConnell. [Sí, esa es la fama de Steve McConnell de Code Complete]

Con mucho, el mejor indicador individual es "funcionalidad comprobada entregada y aceptada". En el mundo ágil, generalmente medimos la "funcionalidad" en términos de "historias de usuarios", pero puede ser de cualquier forma conveniente siempre y cuando se mida la funcionalidad real entregada y probada, aceptable para el cliente.

Las otras medidas habituales, como SLOC, SLOC / hora del personal, etc., fallan debido a la Primera Ley de Administración de Charlie, que es:

Las personas entregarán lo que sean recompensados ​​para entregar.

Configure sus medidas como SLOC, y obtendrá un montón de SLOC. Use SLOC / hr, obtendrá muchos SLOC / ht. Ofréceles bonos por trabajar horas extras, obtendrás muchas horas extra.

Ah, y recuerda el correlato, también:

Lo que las personas están entregando es lo que creen que será gratificante ofrecer.

Si no obtiene lo que desea, pregunte por qué es gratificante hacer lo que se está haciendo.

El mejor uso para los indicadores clave de rendimiento es para conducir (o conducir , si lo prefiere). Para corregir el curso en tiempo real .

(Consulte los paneles de instrumentos son para conducir para obtener más información sobre este tema secundario. Advertencia: soy el autor del artículo de la crítica).

Entonces, la pregunta para usted es: ¿está tratando de evaluar el desempeño después del hecho , cuando ya es demasiado tarde para hacer algo al respecto , o está tratando de encontrar KPI que puedan ayudarlo a mantener el rumbo ?

Si lo hace, cualquier métrica que le interese a su organización (recuento de errores, desvío de la fecha de envío, líneas de código con comentarios, porcentajes de retorno de clientes, etc.) estará bien. Mida y buena suerte mejorando entre productos de envío y actualizaciones ;-)

Si es este último, elija la velocidad . Asumiendo que está usando un desarrollo basado en pruebas (TDD), por supuesto.

EDITAR: así que es el primero. Bueno, aquí está la razón por la que probablemente no tengas suerte:

Supongamos que usted decide que la "calidad" se cuantifica mejor midiendo la cantidad de errores reportados por los clientes como su KPI post-proceso. Supongamos que está usando TDD, y diga que su equipo entrega el Producto # 1 en 6 meses, y luego de 6 meses en el campo, encuentra que tiene 10 errores reportados por el cliente. Entonces, ¿qué vas a hacer exactamente para mejorar tu proceso? Prueba mas? ¿Pruebe específicamente para más cosas como las causas de los errores que se informaron? Me parece que ya estaría realizando pruebas, y cuando se descubren errores, ya sea por parte del cliente o no, agrega una prueba de regresión para el error específico y pruebas de unidades adicionales para asegurarse de que no haya más errores similares. En otras palabras, su respuesta de mejora posterior al proceso no será diferente a su respuesta de mejora en el proceso , por lo que este KPI realmente no es de gran ayuda para mejorar su proceso. El punto es que la forma en que mejora su proceso sigue siendo la misma, independientemente de si los errores se descubren 6 meses después del lanzamiento o dos días después de la codificación. Entonces, si bien esto podría ser un KPI brillante para colocar en el muro de un gerente o en un boletín informativo departamental, realmente no cambiará sus mecanismos de mejora del proceso. (¡Y tenga cuidado de no poner demasiada acción en este KPI porque puede verse influenciado salvajemente por factores que escapan a su control!). En resumen, saber la cantidad de errores no lo ayuda a mejorar .

(Aquí hay otro peligro, uno que se encuentra no solo en los negocios sino también en el ejército, y esa es la ilusión de que el análisis post-mortem reveló información valiosa, por lo que las lecciones aprendidas post-mortem se aplican vigorosamente al próximo proyecto, que probablemente no es lo mismo que el último proyecto . Esto se conoce como "pelear la última guerra").

Supongamos que la cantidad de devoluciones / reembolsos de los clientes es su KPI de elección para la "calidad": si este número es 5, ¿qué le dice esto? Las razones específicas por las cuales los clientes solicitaron un reembolso pueden ser una indicación de problemas de calidad ("demasiado lento", "no interactúa con el sistema XYZ", etc.), pero la mera cantidad de dichos incidentes no le dice nada. Una variación con respecto a un porcentaje de rendimiento esperado podría indicarle si la calidad está mejorando, pero nuevamente el número no lo ayuda a mejorar . Necesitas más información de la que te puede dar el número.

Entonces, para "la puntualidad de los lanzamientos", ¿qué medida sería apropiada? ¿Número de días de deslizamiento de fecha de envío? Desborde porcentual basado en estimaciones originales? No importa , porque una vez más los números no te ayudan a mejorar .

Si puede medir la "productividad" después de que el producto está listo, probablemente pueda medirlo mientras se desarrolla el producto (por ejemplo, velocidad), la diferencia es que la productividad menor a la esperada durante el desarrollo puede mejorarse inmediatamente, mientras que un número total de productividad medido una vez que se completa el desarrollo, es demasiado burdo, demasiado promediado, para ser de alguna utilidad. Uno solo podía adivinar por qué fue más bajo de lo esperado 6 meses después ...

No tengo idea de cómo se podría medir la "flexibilidad", suena como jerga de marketing ;-)

Espero no haber golpeado este clavo demasiado fuerte o demasiado lejos, pero no creo que haya algo útil que pueda medir después de los hechos que no pueda medir mientras está en progreso . Y hay muchas mediciones después de los hechos que son inútiles sin conocer las causas.

Ningún proceso te ayudará a mejorar lo que haces, salvo que realmente juntes a todos y averigües qué funciona y qué no funciona. Para el equipo que actualmente dirijo, lo hacemos a través de una serie de Retrospectivas (de las cuales recomiendo encarecidamente este libro ). En general, los equipos saben qué partes quieren mejorar; el truco está en darles el poder para medir y mejorar esas cosas.

Sí, ciertamente todavía necesitas a alguien que busque un nivel Macro. Si nos fijamos en una organización como Toyota, tienen un Ingeniero Jefe que abarca esa línea entre el negocio y la producción (para una buena explicación, vea la publicación del blog de Scott Bellware). En nuestra organización tenemos a alguien similar: mi jefe fue uno de los desarrolladores iniciales de nuestro producto hace casi 20 años, y se mantiene muy activo en el lado de la tecnología, pero también está muy involucrado en el lado del cliente. Mi trabajo también es mirar a los equipos como un todo para sugerir mejoras.

Para medir, primero nos aseguramos de que las mejoras que buscamos sean cosas que nuestros equipos realmente puedan cambiar, y luego utilizamos algo similar a los objetivos de SMART para que cualquier mejora sea medible. Tenemos un Muro grande y visible en el que publicamos las notas de la retrospectiva. Esto también ocurre donde también tenemos nuestros stand-ups diarios, por lo que nos enfoca en lo que está sucediendo.

Para aumentar las estadísticas de nuestras reuniones ejecutivas, nos enfocamos en la entrega del código, no en las líneas de código entregadas. Intenté patear al equipo para que no midiera en unidades nebulosas, lo que significa que no informamos que trabajamos x cantidad de horas, o días, o lo que sea. Lo que sí ven es un gráfico de tendencias de cómo estamos entregando nuestras características y cómo estamos mejorando. También incluiremos datos interesantes cuando el equipo sienta que quieren compartirlo.

La mejor parte de todo esto es que podemos probar cosas durante un mes y luego reevaluarlas solo 4 semanas después. Esto crea una barrera de entrada mucho más baja para probar cosas nuevas, ya que el equipo sabe que si los está afectando, lo cancelaremos de inmediato, o reevaluaremos y encontraremos mejores formas en la próxima retrospectiva.

Lo malo es que no es exactamente lo que estás buscando. No hay una métrica o conjunto de métricas que sigamos continuamente. Observamos las tendencias en todo momento y medimos las que creemos que son interesantes, pero solo por un momento, y solo cuando el equipo se dispone a lograr un objetivo específico gracias a ellas. Pero en general, estoy bastante satisfecho con la forma en que funciona, y he visto una mejora notable en la participación de los equipos en la mejora del proceso. No somos del todo Kaizen , pero estamos mejorando cada día.

Cuando escucho el Indicador clave de rendimiento me preocupa un poco, porque generalmente lo próximo que se hace es vincular el rendimiento a la recompensa y luego puedes despegarte rápidamente. Siempre me acuerdo de la empresa de software que optó por un sistema de recompensas para solucionar errores: los evaluadores serían recompensados ​​por encontrar errores y los desarrolladores serían recompensados ​​por corregir errores. El desarrollo se detuvo cuando se formó un mercado negro instantáneo alrededor de la inserción, detección y corrección de errores.

Sus KPI organizativos deben centrarse en el cliente. Dependiendo del tipo de producto de software que está haciendo, puede medirlo de las siguientes maneras:

  • Ventas: ¿su producto cumple los requisitos del cliente? Es posible que pueda medir esto en términos de proporción de presentaciones de software a ventas o visitas a la página de compra de su sitio web a compras reales
  • Calidad: ¿Es comprensible y confiable su software? ¿Cuántas llamadas de soporte por cliente recibe por día? ¿Las preguntas sobre cómo hacer algo o errores?
  • Satisfacción del cliente: ¿Qué tan satisfechos están sus clientes con su producto? Encuestar a sus clientes y averiguar qué podría estar haciendo para aumentar su satisfacción y luego encuestarlos nuevamente más tarde para averiguar si ha mejorado. (No moleste a sus clientes haciendo muchas preguntas o haciéndolo con demasiada frecuencia)

Sí, parece que estos indicadores no tienen nada que ver con las métricas del software de nivel básico, como los errores encontrados y las líneas de código producidas. Sin embargo, el problema con los errores encontrados es que debes clasificar la gravedad de los errores, y la refactorización a menudo reducirá tus líneas de código. La puntualidad solo importa si cumple con las expectativas de entrega oportuna de sus clientes.

Concéntrese en los objetivos comerciales. Si tiene clientes que compran su software, no necesitan mucho soporte para usarlo y están contentos, entonces su organización de software tiene éxito. No hay medida de los errores detectados, los resbalones del cronograma o cualquier otra cosa importará si no tiene esas tres cosas en su lugar.

Si su proyecto de software es como la mayoría, será tarde, superará el presupuesto, se enviará con menos características de las anticipadas y tendrá errores. No te rindas sobre estas cosas, lidia con ellas y sigue adelante. Sí, necesita bases de datos de errores, control de fuente, pruebas y una forma de medir la velocidad del proyecto, pero al final si no cumple con los resultados del negocio no puede tener éxito, independientemente de qué tan pulido y brillante sea su código y cómo algunos errores que tiene.

Actualiza para intentar abordar la pregunta revisada

Los KPI que desee utilizar son difíciles cuando se entrega un producto intangible que también suele ser un objetivo en movimiento. ¿Sus KPI utilizados este año en un sistema de contabilidad tienen el mismo significado el próximo año cuando está implementando un sistema de administración de documentos?

Tomemos como ejemplo una profesión donde los KPI se utilizan ampliamente: abogados. Los abogados que miden usan KPI como: horas promedio facturadas por día; horas facturadas por mes; edad del libro mayor de deudores; edad promedio de trabajo no facturado; porcentaje de tarifas facturadas canceladas; y así. Aquí debe observar una tendencia: todos estos KPI se relacionan con la disposición (o no) de los clientes a pagar por los servicios prestados. Este es el árbitro final del éxito y es por eso que sugerí (arriba) algunas formas en que podría usar este tipo de medición como KPI para su negocio de software.

Cuando intenta llegar a tener KPI que no se relacionan con la disposición de su cliente a pagar por el valor que está brindando, entonces nos enfrentamos a problemas con lo que estamos midiendo, cómo lo está midiendo y qué diferencias hay en la medida o lo que se está midiendo este año en comparación con el año pasado.

Los "dólares pagados por los clientes" tienen un valor fijo año tras año: las métricas arbitrarias como "errores en el software", "la puntualidad de la publicación" y "flexibilidad" no tienen un valor fijo y un aumento en el KPI puede no tener un impacto directo relación con el valor subyacente que se pretende medir con el KPI, como "más errores significa una calidad inferior".

Por ejemplo, después del desastre de Columbia , recuerdo que el equipo de investigación presentó varios cientos de recomendaciones y elementos para ser investigados. ¿Estos "insectos" recién descubiertos significaron que el transbordador espacial de repente tenía mucha menos calidad? De hecho, después de la investigación, el transbordador espacial tuvo más calidad. Por lo tanto, un KPI en torno a los errores puede ser fácilmente distorsionado por una extensa sesión de QA y más errores reportados pueden significar que su software tiene mayor calidad.

La productividad en términos de puntualidad de las entregas se distorsiona fácilmente por factores comerciales, como que un cliente le arroje dinero para que haga algo de desarrollo personalizado para ellos. Su calendario de lanzamientos se perderá pero su negocio mejorará.

En cuanto a la flexibilidad, no puedo arriesgarme a adivinar cómo medirías algo tan intangible.

Acerca de la única medida que puedo pensar que tiene valor para este lado de la billetera del cliente es la velocidad del proyecto : ¿cuánto estimamos que haríamos la última iteración / ciclo / lanzamiento y cuánto realmente logramos? Luego, conecte esta cifra con el tiempo disponible para la próxima iteración / ciclo / lanzamiento para estimar cuánto probablemente podrá hacer esta vez. Puede visualizar el tiempo restante en un gráfico de reducción o similar durante la iteración.

El resto se reduce a procesar, lo cual no creo que pueda definir a KPI. Todo lo que puedes hacer es asegurarte de que tus desarrolladores saben lo que hacen todos (reuniones diarias de desarrolladores), tu equipo ampliado recibe comentarios (reuniones de equipo semanales o quincenales), entiendes qué funcionó la última vez y qué no (retrospectivas) y, sobre todo, tienes una comunicación transparente y efectiva.

Lamentablemente, no creo que haya KPI mágicos como lo que usted busca (pero no pase por alto la importancia de obtener dinero de los clientes como un KPI).

Procesé la mejora profesionalmente durante 14 años. Aquí está mi consejo, deja de intentar cuantificar y comienza a hablar con la gente. La medición funciona bien para un problema específico (una vez que conoce el problema, tiene una mejor idea de qué medir) y para procesos repetibles como la fabricación. Su gente sabe exactamente dónde están las áreas problemáticas, también lo hacen sus clientes y usuarios (desde una perspectiva muy diferente). Diagrama de flujo (use símbolos de ingeniería industrial, no símbolos de programación de computadoras), descubra el proceso real para las áreas donde hay inquietudes (no es lo que pretendemos que sea el proceso, deberá observar y formular preguntas). Una vez que vea todo el flujo del proceso, busque retrasos, áreas donde el trabajo está duplicado, áreas donde hay un proceso innecesario (generalmente debido a agregar más pasos al proceso para dar cuenta del error humano, creando así muchas más áreas potenciales para humanos error). Cuestiona la necesidad de cada paso y si hay una mejor manera de hacer cada paso. Pruebe los cambios potenciales y vea si de hecho son una impronta (demasiadas veces empeoran la situación, no la mejoran). Bajo ninguna circunstancia, solo hable con los gerentes cuando tenga una idea de los problemas o cuando esté haciendo un diagrama de flujo. No obtendrá una imagen real y, por lo tanto, resolverá el problema equivocado.

Benno, estoy respondiendo tu comentario pero no tenía suficientes personajes para la respuesta.

Esto depende del problema que estás resolviendo. Supongamos, por ejemplo, que el tiempo desde que el desarrollador comprueba el código hasta que se coloca en producción parece demasiado largo. Luego obtendrías una medición de referencia de cuánto tiempo está tomando. entonces pondrías tu cambio y luego medirías por un período de tiempo para ver si ahora toma menos tiempo. También puede verificar algo así como la cantidad de veces que se determinó que la solución no funcionaba y se volvió a enviar para volver a trabajar antes y después también para asegurarse de que la solución no sea más rápida sino de menor calidad.

Ahora el problema en TI con estas mediciones es que puede llevar bastante tiempo acumular datos suficientes ya que algunos problemas no vuelven a ocurrir con frecuencia. En este caso, puede que tenga que comenzar confiando en datos subjetivos hasta que pueda acumular datos suficientes para saber si el cambio fue bueno o no. Pero no pregunte si algo es una mejora hasta que los usuarios se hayan acostumbrado. La primera o las dos semanas de un nuevo proceso, encontrará resistencia al cambio y obtendrá malos resultados subjetivos si lo solicita demasiado pronto.

Otra cosa de qué preocuparse es que si las personas saben que están midiendo algo, temerán que se mida su rendimiento personal y, por lo tanto, jugarán con el sistema para obtener buenos resultados. A menudo es mejor si puede tomar medidas basadas en algún sistema ya existente (tenemos un sistema que maneja las solicitudes de cambios de software, podríamos consultar la base de datos para averiguar históricamente cuántas solicitudes se saltaron la fecha límite, cuántas volvimos a abrir después de cerrado o relacionado con solicitudes pasadas, etc., cuál es la diferencia de tiempo entre el acabado del desarrollador y el código que se mueve a producción, etc.). También es posible que deba considerar la eliminación de valores atípicos severos, especialmente si el tiempo abarca el período de tiempo tanto del sistema antiguo como del nuevo. Por ejemplo, tenemos una solicitud que ha estado en Qa durante más de 100 días, no porque sea mala, sino porque QA tiene un problema de disponibilidad y esta es la prioridad más baja, por lo que sigue siendo golpeado por un trabajo de mayor prioridad. Esta vez no sería útil para medir la mejora del tiempo, ya que el factor que hace que el tiempo sea tan largo no es el proceso que está tratando de corregir. Si grafica los datos, verá fácilmente los valores atípicos que podrían necesitar excluirse.

Comprender el mapeo de residuos y el flujo de valor le mostrará dónde necesita hacer mejoras y, a partir de ese conocimiento, aprenderá lo que necesita medir. Los principios de Lean y Kanban se aplican aquí. Comprender el desperdicio y sus efectos en la producción de software lo llevará por el camino específico para mejorar que es inevitablemente específico para su organización. No puedes tomar un enfoque de corte de cookie. Lea (o escuche) "The Goal" y "Lean Thinking" para obtener más información sobre esta perspectiva realmente asombrosa y reveladora de lo que está mal y cómo solucionarlo.