Preguntas Frecuentes (FAQ)

Si su necesidad de software es común, explore primero si existe una plataforma en el mercado que le pueda servir, puesto que desarrollar software por encargo es costoso y toma tiempo. Elija el desarrollo de software cuando:

• No exista un producto en el mercado que pueda solucionar su problema;
• Usted considere que su necesidad de software cubre una ventaja competitiva estratégica, que lo diferenciará de sus competidores. En el primer caso, usted no tiene alternativa: como no existe una solución de software, usted debe desarrollar un software a la medida

En el segundo caso, su empresa está eligiendo adentrarse en un proyecto de desarrollo porque quiere establecer una ventaja competitiva que soporte un proceso de negocio core –en otras palabras, usted está invirtiendo para ser mejor que su competencia.

La respuesta es: depende. ¿Cuánto cuesta una casa? ¿Cuánto cuesta un carro? Todo depende del tipo de casa, del tipo de carro. Pero vamos más allá: en las primeras conversaciones, la mayoría de nuestros clientes creen tener una idea clara del tipo de software que desean. Sin embargo, la mayoría de las veces esto no es suficiente para estimar el costo de un software.

Supongamos que usted requiere un software especial de facturación para su empresa. Usted está claro que el software debe facturar. Tal vez tenga un formato en papel (o en Excel) que ha venido usando para facturar, y ahora quiere desplegar un proyecto de desarrollo de software por encargo para operar su facturación sobre una plataforma más masiva y robusta.

Cuál puede ser el problema?

El problema yace en que es muy probable que usted todavía no posea suficiente detalle para que un proveedor serio le entregue un estimado del costo del proyecto. Los estimados técnicos se fundamentan en una descripción muy específica de cada pantalla que va a tener el software, de cada campo, de cada menú, botón o consulta. Igualmente, éstos requieren de diseños de la arquitectura (o andamiaje tecnológico) que soportará la aplicación (lo que va desde temas técnicos, hasta otros de sentido común como por ejemplo, el tipo de tecnología en la que se desplegará la aplicación, el número de usuarios, las exigencias de desempeño que presenta el software, etc.).

Un proveedor de servicios de desarrollo responsable es quien le cuestiona el grado de información que usted tiene, y lo guía bien sea para que usted lleve la información a un mayor grado de detalle antes de ofrecer un estimado, o alternativamente despliega servicios para acompañarlo a generar la información adicional necesaria.

Para enfrentar un desarrollo de software a la medida se debe desplegar un proceso de ingeniería. Por ser complejo y requerir el concurso de múltiples recursos, profesionales, y usuarios, este proceso debe seguir unos pasos, debe ser constantemente coordinado, monitoreado, medido, ajustado y controlado. A través de los años, el mundo académico y empírico ha desplegado diferentes conjuntos de “mejores prácticas” con las cuales controlar este proceso, las cuales se denominan, como conjunto, “metodologías”. 

Algunas de las más conocidas en el entorno Latinoamericano son la metodología RUP (Rational Unified Process) y –recientemente- las metodologías denominadas ágiles, como lo es SCRUM.

Es riesgoso intentar desarrollar software sin seguir una metodología?

Si, es altamente riesgoso. De hecho, el Standish Group, consultora estadounidense dedicada a explorar el éxito o fracaso de los proyectos de ingeniería de software a nivel mundial, recalca como tan solo un 38% de los proyectos de software emprendidos en el mundo moderno se consideran exitosos. Así pues, un proyecto afrontado sin metodología corre un alto riesgo de ser entregado a destiempo, por fuera de presupuesto y con una funcionalidad diferente a la esperada.

No lo son. Cada una tiene un enfoque diferente y una manera de aproximarse al objetivo común de construir un software específico. A grandes rasgos, existen dos tipos de “escuelas” en el frente de las metodologías de desarrollo: las metodologías predictivas y las metodologías adaptativas.

• Metodologías “predictivas” 

Buscan predecir, por adelantado (o sea, antes de comenzar el proyecto) el esfuerzo y costo que tendrá un determinado proyecto de desarrollo. Por otro lado, las

• Metodologías “adaptativas”

Buscan incorporar nuevos aprendizajes y conocimientos al proyecto de desarrollo a medida que este se va desplegando. Las metodologías predictivas, entonces, tienden a ser más inflexibles. Las adaptativas mucho más flexibles.

A primera vista, las metodologías de desarrollo de software predictivas tienden a ser más naturales a los entes decisorios de una empresa, puesto que buscan “ponerle un precio” a un proyecto –dicho de otra manera, buscan comprar un proyecto de software como se compra un computador o un celular, en un trueque de un monto definido por un resultado con un alcance y costo completamente definido.  

Por este motivo, para muchos resulta irónico enterarse que este tipo de metodologías han sido prácticamente descartadas por los países más sofisticados en ingeniería de software. En EEUU, por ejemplo, Stanford, MIT y Carnegie Mellon –las tres universidades más prestigiosas del mundo en la materia- ya no las enseñan.

Las metodologías predictivas buscan definir por adelantado todos los aspectos relevantes a un proyecto de software. Pero el software no es fácil de definir o de imaginar, mucho menos para un usuario de negocio que conoce su proceso pero no es experto en la materia (o sea, no es experto en hacer el salto conceptual de plasmar un proceso de negocio en un conjunto de “pantallas” de software). 

Por tal motivo, la consultora Standish Group estima que el 45% de las funcionalidades que los usuarios piden en proyectos tradicionales de Grandes Requerimientos por Adelantado (GRPA) nunca se utilizan… esto es el equivalente de desperdiciar el 45% de su dinero!Igualmente, las metodologías de desarrollo de software predictivas de GRPA no pueden obviar un componente básico de la naturaleza humana: las ideas se le ocurren a las personas de manera espontánea, en cualquier momento, más no necesariamente en el momento “adecuado”.

Las metodologías de desarrollo de software denominadas ágiles buscan dedicar la mayor cantidad de tiempo y esfuerzo de un proyecto a construir funcionalidad (lo que en software equivale a construir código), en vez de dedicar un gran porcentaje del esfuerzo de un proyecto a construir documentación técnica o a generar estimaciones formales de esfuerzo. Las metodologías tradicionales, al requerir del proveedor estimar el esfuerzo de construcción de un proyecto por adelantado, fuerzan al proveedor a generar toda la documentación detallada del mismo, por escrito, desde el comienzo. En proyectos de alguna envergadura, esto puede tardar meses, donde la sola construcción de la documentación y su estimación puede constituir un 30 o 40% del esfuerzo total de un proyecto.

¿Que buscan las metodologías ágiles?

Disminuir al mínimo la documentación escrita, reemplazándola por conversaciones en tiempo real sobre la funcionalidad que debe tener el aplicativo. Como resultado de este cambio conceptual, los proyectos ágiles tienden a ser entre un 35 y un 40% más eficientes que los proyectos tradicionales (visto de otra manera, con el mismo presupuesto se logra construir un 35 a un 45% más de funcionalidad, o se logra construir la misma funcionalidad con un 35 a 40% menos de dinero invertido). 

Ahora bien, a cambio de una eficiencia significativamente mayor, el equipo de trabajo “sacrifica” predictibilidad; o sea, entrega la posibilidad de saber con mayor exactitud el costo y esfuerzo que tardará realizar un proyecto, puesto que este esfuerzo sólo puede ser calculado si se tienen por adelantado al menos un 80% de los requerimientos detallados, por escrito.