Estoy de acuerdo con aquellos comentarios que dicen que las métricas deberían de estar para ver lo no evidente; que ha mejorado y qué se puede mejorar. También están para justificar recursos que se necesitan o si hay procesos que se pueden mejorar.

Algunos ejemplos de métricas del siglo XXI:
http://www.ericsson.com/hr/etk/dogadjanja/mipro_2008/1220.pdf
- ¿Se entregaron los deliverables a tiempo? Ajustarse a los plazos establecidos…
- ¿Cuántas funcionalidades o requisitos se implementaron con éxito? Sirve también para medir la satisfacción de los clientes…
- ¿Por encima o por debajo del coste estimado? ¿Cuanto? Coste puede ser dinero, tiempo, recursos…
- Bugs reportados por el usuario (se deberían de haber cazado en QA). / Bugs encontrados en QA (¿cómo de cuidadoso es el programador?)
- Coste por bug encontrado. ¿Cuanto tiempo lleva solucionar bugs? No solo para el programador, sino también para QA. (horas/persona).
- etc…

De todos modos, como en todo, siempre hay varios puntos de vista. Aquí hay un artículo casi calcado al de Iván:
http://www.builderau.com.au/strategy/businessmanagement/soa/Are-key-performance-indicators-a-true-measure-/0,339028271,339282324,00.htm

Por último, algunos artículos de investigación al respecto en Español:
http://www.aemes.org/rpm/contenidos/articulos.php

Saludos

Ala que peseis un buen dia.

Perfecto. Si haces eso en tu trabajo conseguiras que todo el mundo lo de todo. Y si combinas eso con buenos salarios conseguirás que nadie se quiera marchar nunca de la empresa.

Lo que no acabo de ver es que las medidas que se vayan tomando en un proyecto puedan servir para otro proyecto futuro.

Me parece que generalmente las empresas de software lo mismo hacen un programa de gestión para un vídeoclub que para una farmacia.

Y los programas, aunque conceptualmente son lo mismo, en realidad no se parecen en absoluto.

Creo que lo que complica la medición no es que existan distintos tipos de programador, que también, sino que los problemas a resolver son distintos.

No veo cómo las métricas de un programa para una farmacia pueden valer para un vídeoclub, y viceversa.

Por mi experiencia, entiendo que las métricas que tomé mientras desarrollaba el programa para la farmacia, me servirán en tanto mi siguiente desarrollo sea para otra farmacia que funcione más o menos igual.

Usando un símil, no sé si un arquitecto que haya diseñado un polideportivo pueda predecir con poco margen cuánto le costará diseñar un edificio de apartamentos. Y digo diseñar, que no construir.
De hecho, no creo que pueda predecir cuanto tardará en diseñar el siguiente polideportivo, a menos que sea bastante parecido.
Y fijaos que la gran diferencia entre lo diseñado por un arquitecto y por un diseñador de software (o arquitecto, si lo preferís) es que lo que diseña el arquitecto de edificios, será prácticamente lo que finalmente se construirá. De hecho, en muchas ocasiones, el arquitecto podrá hasta realizar pruebas de su producto antes de construirlo.

No sé, no he tenido ocasión de preguntárselo a un arquitecto. Pero en la fase de diseño, no hay métrica que valga.
El arquitecto no sabe de antemano cómo será el edificio antes de tener entre sus manos los planos.
Con diseño en mano, la historia es otra.
Sabremos con bastante exactitud cuánto costará levantar una pared. Y sabremos cuántas paredes va haber que levantar.

Y creo que con el software pasa lo mismo. Lo complicado del software es diseñarlo.
Y lo malo del software es que no siempre sabemos de antemano lo que hay que construir. Muchas veces no lo sabe ni el cliente.
Lo malo, o lo bueno del software, es que cuesta prácticamente lo mismo diseñarlo que construirlo. Por eso, no solemos diseñarlo con todo el detalle que lo haría un arquitecto.
Lo malo del software es que no podemos probarlo antes de codificarlo.

Yo creo que las aplicaciones habría que codificarlas dos veces. Una vez para desglosar todas las características que va a tener. Y otra para aplicar unas buenas prácticas. Os aseguro que la segunda vez sabríamos con bastante exactitud cuánto vamos a tardar. Y podremos mejorar la productividad. Y la calidad.

Y la calidad? qué es la calidad? entiendo que la calidad es la medida de los requisitos satisfechos.

En cuántos proyectos habéis trabajado en los que los requisitos estaban completamente descritos? Los requisitos funcionales, los de seguridad, los de rendimiento, los de interfaz, complejidad, mantenibilidad, etc.

Cuando el arquitecto firma un proyecto, el cliente obtiene un contrato en el que se detalla casi de todo. Y allí donde tenga cabida la interpretación habrá una normativa legal que aplicar.

Y otro tema importante: El arquitecto tiene responsabilidad legal sobre el producto que va a construir. Si no se ajusta a los requisitos, si el edificio no se ajusta a la normativa legal, a la memoria de calidades, etc., tiene que responder por ello.
Eso es algo que no he oído que haya pasado en la historia de la informática. Ni tan siquiera cuando han habido accidentes causados por fallos que hayan derivado en pérdidas humanas.

Creo que la mejora en las métricas y en el aumento de la productividad vendrán determinadas por lo que progresemos en estandarizar, desarrollar metodologías, en crear componentes reutilizables, etc.

De hecho, creo que es algo que deberíamos aprender de las otras ingenierías. Creo que su éxito se basa en que rara vez se construye algo de cero. La mayoría de las veces, el trabajo de un ingeniero se trata de combinar adecuadamente elementos ya desarrollados.

(No lo sé con seguridad. ¿qué grado de fiabilidad hay las estimaciones de proyectos de IT? Un proyecto de IT consiste en combinar eficazmente componentes ya desarrollados)

Respecto al tema de la gestión de recursos, y a la manera en la que se distinguen a los programadores buenos de los malos, por mi corta experiencia en la gestión de equipos, diré que las personas que funcionan mejor en un proyecto no son las que más saben, ni las que tienen más experiencia. Para mí, las personas determinantes en un proyecto son las que se implican más, las más motivadas, las que tienen una gran conciencia de equipo y programan sabiendo que el producto es el resultado del trabajo de todos, y no de uno solo, por muy bueno que sea. Yo creo que todos tienen mucho que aportar. El que tiene más experiencia, el que tiene mucha capacidad de análisis, el creativo, cada uno puede encontrar su espacio.
Por supuesto hace falta gente preparada, con conocimientos, experiencia y cierta aptitud. Pero para mí, lo determinante es que la gente esté a gusto, y sienta que su trabajo merece la pena.

Me parece que los proyectos que carezcan de personas que motivadas, tiene todas las papeletas de fracasar.

Creo que este aspecto de la profesión es igual para todos los trabajos en los que se dependa de la gente.

Y un buen manager, uno del siglo XXI, debe saber gestionar estos recursos, y aportar motivación. Dar su espacio a cada uno, y hacer que se sienta valorado, para que pueda aportar lo mejor de sí mismo. Me parece que da igual las carencias que pueda tener una persona suficientemente motivada. Seguro que se esforzará por corregirlas.