archivo

Archivos diarios: May 5, 2010

Hace tiempo os comenté que iba a probar el tema de los microcréditos a través de Kiva, ya que me parecía una forma interesante de poder ayudar a emprendedores de diferentes lugares del mundo que no tienen la posibilidad de obtener crédito de las fuentes financieras habituales.

Esto lo empecé hace unos meses con una modesta aportación económica y la verdad es que estoy bastante satisfecho, ya que la tasa de devolución de los créditos es superior a la que en principio podía imaginar y creo que el uso que se está haciendo del dinero, dado que va dirigido a emprendedores, permite no sólo conseguir una mejora individual y de su familia, sino que potencialmente también es posible conseguir una mejora de la comunidad en la que viven. Por estos motivos, la cantidad de dinero que me van reingresando mensualmente la vuelvo a utilizar para prestarla a otras personas.

Con Kiva.org, no se gana dinero, simplemente lo prestas y te lo devuelven, es decir, no cobras nada de intereses y te puedes arriesgar a que no te lo devuelvan. De todas formas quienes decidimos participar en este tipo de iniciativas no tenemos en mente obtener beneficios de ella y sabemos que corremos un riesgo (aunque dado lo modesta de mi aportación y la tasa de devolución que existe, el riesgo me parece nulo).

Os animo a participar, se puede prestar desde 25$ y puedes elegir a qué persona o grupo de personas irá dirigido el dinero que prestas y también podrás conocer para qué lo necesitas.

Si los proyectos no varían de proveedor de servicios de desarrollo de software o de responsable del proyecto, la importancia de las métricas y de la documentación pueden pasar a un segundo plano, ya que de una u otra forma el sistema de información seguirá adelante. Es cierto que las métricas y la documentación pueden resultar también de gran utilidad en estos casos, sobre todo si se quiere ver cómo evoluciona la calidad de la herramienta y las incidencias que están teniendo los usuarios en el uso cotidiano de la aplicación.

En cualquier caso el problema está en que generalmente nos solemos acordar de la documentación y de conocer métricas cuando las necesitamos y precisamente por eso, cuando tenemos que echar mano de ellas no las tenemos.

Como es lógico, esa no son las únicas circunstancias que aconsejan que se documenten los proyectos y se obtengan métricas, ya que por encima de eso está la persistencia del conocimiento de la aplicación lo que permite que la adaptación a cambios en la gestión y en los proveedores resulte menos traumática. También permitirá tener un punto de referencia para evaluar la evolución del producto en las nuevas condiciones de explotación o mantenimiento.

Por ejemplo, si se fueran a externalizar en bloque el mantenimiento de una serie de aplicaciones de una organización probablemente lo primero que querrían conocer los posibles proveedores de ese servicio sería información general de las aplicaciones: tecnologías, arquitecturas, fecha de puesta en producción, etc… y métricas: número de incidencias de relacionadas con correctivos, frecuencia de mantenimientos evolutivos, volumen, calidad y formato de la documentación, etc… Si eso se adobara con informes Sonar que indiquen la evolución del análisis estático de código de las mismas, les permitiría todavía más ser más precisos en la estimación del esfuerzo que se requeriría para realizar el servicio en función del número de aplicaciones a mantener, las características del servicio y del acuerdo de nivel de servicio. Además de todo lo anterior, les sería interesante conocer las reglas de desarrollo y de calidad del software de la organización, el ecosistema de desarrollo, las características del entorno de producción, preproducción y desarrollo: sistemas físicos, software de base y servidores de aplicaciones, la estructura organizativa del departamento de informática, el proceso de paso a producción, etc…