No es la primera vez que me ocurre. Un post de otro inspira uno mío.
Tras leer http://blog.ivangadea.com/2009/02/27/management-del-siglo-xx/ , copio el comentario que me inspiró.
—————————————————————————————————————————————————————–
Comprendo muy bien la necesidad de medir para mejorar la productividad. Me parece muy lógico que se pretenda medir para poder predecir resultados futuros.
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ñe el arquitecto de edificios, será prácticamente lo que finalmente se construya. 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.
Crossposted from crisfervil.com
