La importancia del costo en la construcción de software

Sin duda uno de los conceptos fundamentales en las decisiones de negocio es el costo del servicio que estamos dispuestos a adquirir. El costo de los servicios que contratamos esta dictado por conceptos de oferta y demanda. A mayor cantidad de profesionales que prestan un servicio existe un menor costo para poder actuar de forma competitiva junto a una cantidad mayor de beneficios obtenidos al seleccionar una oferta.

Cuando nos adentramos en el mundo de la tecnología y especialmente en la construcción de software podremos observar principios y conceptos que actúan de forma distinta y si desconocemos de ellos pueden afectarnos de gran forma. Una mayor oferta o un menor costo hasta cierto límite puede indicar que nuestras expectativas no serán cumplidas aunque así sea en apariencia por lo que debemos seleccionar nuestros servicios de manera muy minuciosa e inteligente especialmente en los siguientes aspectos:

Alcance del servicio

Todo proyecto emprendido implica un esfuerzo de programación para llevar a cabo la construcción del software. Al desconocer la forma en que se construye el software es muy fácil pensar que llevando a cabo dicha tarea bajo las indicaciones de lo que esperamos es suficiente para obtener un buen resultado por lo que pagamos, sin embargo es la idea mas alejada de la realidad.

El esfuerzo real de programación o escritura de código fuente representa un promedio del 10% al 20% del esfuerzo total emprendido bajo una metodología correcta por lo que es fácil asumir que en el futuro nos enfrentaremos a dificultades costosas que vendrán como consecuencia de ese 80% de esfuerzo que no se realizó para la elaboración del producto. Mientras el costo del software baja de forma alarmante se reduce la capacidad para ofrecer el 100% de las fases de elaboración de software por lo que el modelo es insostenible.

Experiencia profesional y experiencia en negocios

Cada día contamos con más profesionales dispuestos a emprender proyectos de desarrollo de software. Una de las métricas básicas que utilizamos para medir el tiempo de desarrollo es precisamente la familiaridad del profesional con la herramienta de desarrollo, metodología aplicada y conocimiento del giro de negocio hacia el que va dirigido el software. A mayor desconocimiento de la herramienta de desarrollo, mayor será el tiempo en el que su esfuerzo sea productivo y mayor será el tiempo en el que los integrantes del equipo podrán organizarse para un trabajo en conjunto. Cabe destacar que el número de lenguajes de programación, IDEs (Integrated Development Environment), tecnología a utilizar e interacción entre las partes del software es extremadamente grande por lo que cualquier profesional sólido en su área está sujeto a la misma métrica de desconocimiento.

Todo profesional debe conocer el área para la cual construye software. Sería imposible solicitar una herramienta para control de trabajo en campo sin saber como se trabaja en campo. El resultado siempre será usuarios insatisfechos y pérdida de tiempo puesto que la herramienta abandona su concepto y se vuelve un obstáculo más que los usuarios deben saltar.

La experiencia del profesional en su área, años de trabajo y número de implementaciones corporativas en diferentes giros de negocio, dedicación personal a la interacción social para la satisfacción completa de los usuarios del producto final y la expectativa de ir un paso adelante y dar siempre un esfuerzo extra son directamente proporcionales al costo que estamos dispuestos a asumir por el producto que deseamos.

Experiencia en el análisis de riesgos y escalamiento de aplicaciones

Todo profesional ha pasado por problemas en su carrera y todo profesional ha sabido afrontarlas de alguna manera. A mayor número de escenarios con dificultades mayor será la capacidad para prever complicaciones y resolverlas exitosamente evitando costos. El software representa una base fundamental en las operaciones de las empresas. El cese de operaciones de software se traduce a pérdidas y diferentes niveles de insatisfacción. Podría observar usuarios molestos por una falla o clientes estratégicos que dejan de ser fieles a su negocio y van con la competencia. En extremo se puede llegar a afrontar demandas millonarias dependiendo del tipo de falla y las consecuencias para el cliente final, violaciones a derecho de autor en software no auditado o fallas en la seguridad del producto.

Durante la construcción del software siempre debe haber un análisis de su capacidad para interactuar con diferentes interfaces, cantidades de usuario y uso de recursos. ¿Que pasa cuando el software dejar de atender a decenas de usuarios y atiende a cientos, miles, millones? ¿Tendrá el software la capacidad de manejar sus recursos de forma efectiva? ¿Tendrá un rendimiento excelente, aceptable o reprobable?

No podemos exigir a un profesional en sus inicios que tenga la visión necesaria para prever todo tipo de escenario que solamente la experiencia amplía. Sin duda algunas fallas que son invisibles sin un análisis exhaustivo y el escalamiento a futuro requerirán una segunda inversión para ser satisfactorias. Debemos tener presente que reescribir software y corregir fallas sobre todo en código fuente desconocido siempre presentará un costo y tiempo mayor para ser implementado.

Metodología completa de desarrollo

Todo tipo de proceso en la construcción de software tiene un objetivo y toda metodología busca siempre reunir esos objetivos para un producto final satisfactorio en el menor tiempo posible y de fácil adopción para usuarios y flujos de negocio que la empresa ya tenga en funcionamiento.

Sabiendo ya que el modelo a un costo extremadamente bajo es insostenible podemos asumir con mucha seguridad que la metodología se utiliza de forma incompleta o incluso está ausente. Al carecer de metodología y procesos inevitablemente introducimos a mayor escala el factor del error humano sin importar la experiencia y la solidez de los profesionales involucrados. No se podría exigir un análisis correcto y esto impediría crear casos de uso para el aseguramiento de calidad del software (QA).

La referencia más apropiada para indicar el fin de la implementación de un producto de software es la satisfacción de los casos de uso. No podríamos decir con certeza si el software está 100% finalizado cuando no se sabe que puntos se van a satisfacer con la funcionalidad desarrollada. Sin entrar a detalles sobre soporte, mantenimiento correctivo o ampliación de funcionalidad hemos de concluir que el impacto del costo es vital para la obtención del producto de software deseado.

Cuando estamos informados sabemos tomar decisiones inteligentes. ¿Vale la pena arriesgar la implementación de los procesos diarios de su empresa?

--Texto adaptado como un deseo de dar a conocer un fragmento de nuestra forma de trabajo. Erick J. / IT Express