archivo

Archivos diarios: octubre 5, 2011

Las buenas ideas solo tienen valor si se materializan, si nunca se intentan llevar a cabo o si su implementación no es buena no pasarán de ser solamente buenas ideas.

Y lo que tienen las ideas es que no solo nosotros somos capaces de tenerlas, sino que probablemente tarde o temprano se le ocurrirá a otro que si la materializa antes que tú y de manera efectiva se terminará llevando el gato al agua o por lo menos partirá con suficiente ventaja como para que alcanzarlo requiera mucho esfuerzo.

En el desarrollo de software, la orientación al producto, sobre todo con la proliferación de empresas con vocación artesanal, es una posibilidad de conseguir ingresos que no se debe despreciar, ya sea por la venta de productos tal cual o por la adaptación del mismo a soluciones concretas para un cliente, es más, en circunstancias económicas como las actuales, muchos clientes solo podrán permitirse presupuestariamente este tipo de soluciones frente a otras basadas en soluciones completas a medida.

Con la competencia que existe, con el talento que hay, las buenas ideas pueden marcar la diferencia, suponen un punto de partida, por lo que la creatividad, el conocimiento del mercado y de las tendencias es importante, pero solo son trozos de pensamiento si después no pasan adecuadamente de lo intangible a lo concreto.

He insistido en diferentes artículos que gran parte de la suerte del proyecto se juega antes de que comience. Una mala negociación, una mala venta condiciona todo lo demás (pudiéndose partir de una situación de Death March Project) y solo produciéndose determinadas circunstancias ideales: un equipo de proyecto motivado y de calidad y un cliente y unos usuarios que facilitan las tareas, pueden paliar las pérdidas del proyecto, tangibles (en dinero), como intangibles (de pérdida de imagen con el cliente ante un proyecto de ejecución deficiente).

Sin embargo, la venta inicial del producto es solo una de las variables que condicionan el posterior desarrollo del proyecto, la elección de una mala metodología ya sea por parte del proveedor o impuesta por el cliente puede hacer estragos en el trabajo realizado, en el coste y en los resultados.

Lo mismo si no se delimita de manera adecuada el alcance (ya sea antes de la venta o antes incluso de empezar a recoger requisitos).

Y después toca el análisis. Si la metodología condiciona un desarrollo en cascada la realización de un análisis excelente es esencial, si bien, todo se puede ir al traste en el momento en que cambia algunas de las variables del proyecto (interlocutores, procesos, etc…) y es que los modelos predictivos tienen ese problema.

Si la metodología es ágil o al menos iterativa incremental (como RUP), las tareas de análisis también son de gran importancia, aunque desarrollos iterativos y evolutivos dan un mayor margen para la corrección de deficiencias en la captura e interpretación de los requisitos y en el modelado de la solución.

Por tanto, independientemente de que en función de la metodología aplicada la realización de un buen análisis tenga una mayor importancia, en todas condiciona el resto del proyecto y muchísimo.

Un mal análisis, si se detecta en etapas tardías (en muchos casos, cuando el producto ha llegado a producción), provocará un más que probable fracaso de la puesta en marcha del sistema y un más que probable esfuerzo económico importante para resolver esta circunstancia, mediante mantenimientos correctivos y evolutivos, que podrían ser incluso no asumibles si la deuda técnica del desarrollo es elevada.

Pero es que un mal diseño también tiene consecuencias y muy importantes en el resultado final del software.

Por eso destaco siempre que, además de contar con buenos programadores, disponer de buenos analistas funcionales y orgánicos permite que el trabajo de los que codifican brille más y sobre todo, sea útil.

De ahí la importancia de realizar testing desde el principio, fundamento este que dió lugar, por ejemplo a las metodologías de testing en V o en W.

En resumen, aunque muchos piensen que el partido se juega en la construcción del software, si no se han realizado de manera adecuada las etapas anteriores, el partido se habrá perdido antes de que el árbitro de el pitido inicial.