ISBSGCreo firmemente que lo están y, a menudo, me sorprende y desilusiona que más organizaciones no implementen medidas de tamaño funcional..

La productividad es un concepto que se discute ampliamente desde los gobiernos a nivel nacional hasta las empresas individuales., en todas las industrias que producen bienes o prestan servicios. A los efectos de esta discusión, tomo productividad para significar la cantidad de recursos consumidos para producir una unidad de producto. La clave aquí es que hay un resultado que se puede identificar y contar para compararlo con el recurso utilizado..

Los ejecutivos corporativos y los jefes de departamentos gubernamentales exigen regularmente que sus organizaciones mejoren la productividad cada año, ya sea, Por ejemplo, producir más producción con el mismo nivel de recursos o la misma producción con menos recursos. También están interesados ​​en el desempeño de su organización en comparación con otras empresas similares con las que compiten..

La industria de TI no es diferente. Los ejemplos incluyen proveedores de servicios que necesitan demostrar competitividad para ganar negocios, Departamentos de TI internos que necesitan demostrar que están entregando más al negocio con los presupuestos que se les asignan y directores financieros que necesitan asegurarse de que los acuerdos de subcontratación brinden beneficios reales al negocio., no solo una tarifa de mano de obra más barata.

En el campo del desarrollo de software, Las líneas de código se han utilizado como una medida de la salida producida, pero con la llegada de técnicas y herramientas de desarrollo modernas, ya no es una medida útil en la mayoría de los entornos modernos..

Una técnica más útil es medir el resultado de un proyecto de desarrollo de software en términos de la cantidad de funcionalidad que ofrece al cliente., independientemente de la tecnología/plataforma/metodología de desarrollo utilizada. Para hacer esto se necesita un estandarizado, forma repetible de identificar y evaluar las funciones comerciales entregadas y, por lo tanto, derivar un valor numérico para el tamaño del software entregado.

Algunas de las lecciones clave aprendidas en la implementación del dimensionamiento funcional son:

Mide lo que haces y luego mejora

  • A menos que tenga una línea de base del desempeño actual, no será posible administrar un programa de mejora. Varias veces escuché a los gerentes decir: "Queremos aumentar la productividad 10% por año” pero no sabían cuál era el rendimiento actual. también, necesita saber si el rendimiento actual es bueno, promedio o malo. Dependiendo de donde estés parado, puedes entender si necesitas mejorar, y de ser así, cuanto seria realista. Los datos de ISBSG pueden ayudarlo con esto.

Comprender sus datos y tomar medidas.

  • La medición es de poco valor a menos que se use para indicar acciones que se pueden tomar para mejorar. Por lo tanto, se requiere un proceso de "Análisis Causal" para comprender los atributos/factores/eventos que resultaron en el desempeño de cada proyecto individual..
  • Tenga cuidado con el "taburete de tres patas" del costo, calidad y horario. Todos son interdependientes y no deben gestionarse de forma aislada..

Cuidado con el mal uso de los datos

  • una vez escuché 2 Altos ejecutivos que se jactan del rendimiento de sus departamentos de TI utilizando Horas/Punto de función. Eran de empresas en diferentes sectores industriales con negocios sustancialmente diferentes, por lo que tal comparación casi no tiene sentido.
  • Existe el peligro de una simplificación excesiva. porque los proyectos, incluso en dominios similares, producirá resultados variables, se requerirá un análisis estadístico básico más allá de los promedios para comprender correctamente los resultados.

Correlación con el esfuerzo

  • El uso del tamaño funcional para medir la productividad o para estimar presupone que existe suficiente correlación entre el tamaño y el esfuerzo. No todas las tareas requieren que sea directamente proporcional al tamaño funcional, por lo que es posible que deba eliminarse del cálculo de productividad y manejarse por separado

Horas/FP o $/FP

Algunos definen productividad Esfuerzo/Unidad de producción mientras que otros prefieren Costo / Unidad de salida. Cada métrica tiene valor, ya que a menudo existe una relación entre la tasa de trabajo y la cantidad de horas necesarias para completar una tarea.. Recomiendo usar ambos.

me interesaria saber sus experiencias (bueno y malo) y especialmente las razones por las que no ha implementado el dimensionamiento funcional. Por favor contácteme en john.ogilvie@isbsg.org si estás interesado.

 

Sobre el Autor

John Ogilvie es director ejecutivo de la Grupo Internacional de Estándares de Benchmarking de Software.

 

Una publicación de blog representa la opinión personal del autor.
y puede no coincidir necesariamente con las políticas oficiales de Nesma.
Comparte este artículo en:

1 Comentarios

Deja un comentario
  1. Lo que describes como el “taburete de tres patas” de costo, la calidad y el cronograma son, en mi experiencia, la razón por la cual muchos programas de medición fallan. No logran relacionar los tres y manejarlos – o incluso peor – solo cuesta en espléndido aislamiento. Cuando se enfoca solo en el costo, puede terminar con un desarrollo de software muy eficiente que no produce lo que una organización necesita de su cartera de TI.. Cualquier programa de medición debe centrarse en “haciendo las cosas correctas” primero, antes de mirar “haciendo bien las cosas”. Esto significa calidad primero, luego programar y luego costo. Me he encontrado con muchas empresas que lo hacen al revés y luego fallan..

Deja una respuesta