PREGUNTAS FRECUENTES (SERVICIOS DE SOFTWARE A LA MEDIDA)
 
 
 

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.

 
 

Construir software es una actividad inherentemente costosa, puesto que requiere el concurso de personales profesionales altamente capacitados y altamente entrenados (los cuales devengan, por ley de mercado, salarios altos). Adicionalmente, los proyectos de software representan una de las más complejas tareas de la ingeniería humana, requiriendo importantes cantidades de tiempo para su concreción. Las plataformas preprogramadas -todas aquellas que van desde Word o Excel hasta un ERP de clase empresarial- han costado millones de dólares para desarrollar. Sin embargo, estas son más económicas porque son vendidas a cientos de miles -y a veces- millones de clientes, por lo cual su costo total es sufragado por una base amplia de compradores. En el caso del desarrollo de un proyecto de software por encargo (o el desarrollo a la medida), el costo total del proyecto es sufragado por uno o por pocos clientes, haciendo que el costo “unitario” del desarrollo sea igual al costo total del proyecto.

 
 

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.

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.

Desafortunadamente, muchos proveedores no son serios con sus estimados, y están dispuestos a adelantar un costo de un proyecto de desarrollo a la medida con una información de altísimo nivel que los está obligando a “adivinar”. De la misma manera que un ingeniero civil requiere de un estudio de suelos, planos detallados, planos eléctricos, detalle de acabados, ingeniería estructural, etc. para costear una obra civil, un ingeniero de software requiere de cientos de datos para poder hacer un estimado veraz.

Cuídese de quienes “cotizan” sus servicios por ganarse el cliente, pues están jugando con ellos y con usted a la “ruleta rusa”.

 
 

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.

Intentar desarrollar software sin seguir una metodología 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.

Como su nombre lo indica, las 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”.

Por tal motivo, los proyectos que se estimaron por adelantado normalmente sufren cambios del 30 al 40% en los requerimientos, luego de que éstos ya se encontraban terminados. Todos estos cambios generan procesos de re-estimación que consumen mucho tiempo y recursos, pero que no generan una sola nueva línea de código. Es así como académicos y practicantes de la ingeniería moderna concluyen que, en el agregado, las metodologías predictivas pueden costar entre un 30 a un 40% más que las metodologías ágiles, de las cuales hablaremos en nuestra próxima pregunta.

 
 

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.

Las metodologías ágiles, por el contrario, buscan 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.

A primera vista, esto parece un gran sacrificio: ¿cómo sabe un cliente, entonces, cuál será el tamaño y costo de su iniciativa? Las metodologías ágiles enfrentan este reto de dos formas. En una aproximación, el equipo da un estimado de alto nivel, de mejor esfuerzo, con información de alto nivel que toma a la máxima varias semanas en construirse. Este estimado no va a ser exacto, pero es muy rápido generarlo y por ende es poco costoso. Con este estimado en mano, el cliente logra aprobar un presupuesto y el equipo comienza a trabajar.

¿Pero si no hay un costo fijo, cómo sabe el cliente que el proveedor está trabajando de manera responsable? En las metodologías ágiles, el cliente recibe software operativo cada 2 a 4 semanas. Por tal motivo, el cliente puede rápidamente experimentar, de primera mano, si el software que se está construyendo cumple o no sus expectativas.

Igualmente, el cliente puede explorar si el avance del proyecto es satisfactorio, lo cual disminuye el riesgo versus metodologías “waterfall” donde sólo al final de muchos meses se sabe si el proyecto fue exitoso o no. ¿Esto como sucede? Cada Sprint (o iteración) el equipo revisa su estimado de tiempo y esfuerzo para el proyecto, el cual se va haciendo cada vez más exacto, puesto que el equipo aprende a conocer la complejidad específica de la iniciativa. En cada revisión de alcance y avance con el cliente (o sea, mínimo cada 2 a 4 semanas) se explora si el presupuesto restante es o no suficiente para cumplir con la funcionalidad “meta” que tenía el proyecto.

Es importante anotar que como ágil es adaptativo, permite que la funcionalidad original vaya cambiando según el aprendizaje o las nuevas ideas que le surjan al grupo. Por tal motivo, es muy posible que la funcionalidad que se consideró originalmente pierda prioridad, para ser reemplazada por nuevas demandas del mercado o nuevas ideas que surjan al grupo de desarrollo o los usuarios finales, a medida que interactúen con el software. Debido a que ágil nunca pretendió establecer un proceso de precio fijo, estos cambios no tiene que ser sometidos a costosos controles y reestimaciones formales -simplemente son incorporados al “backlog funcional” del proyecto, a veces desplazando funcionalidad anterior, a veces sumando a la ya existente. Por supuesto, el equipo da su opinión de experto sobre que tanto incrementa el esfuerzo estimado debido a una nueva funcionalidad agregada, para que el cliente decida si la incorpora o no a la iniciativa.

Bajo otra modalidad, el cliente puede optar por desplegar un proyecto ágil bajo una metodología de precio fijo y alcance variable. En este escenario, el cliente da como fijo el estimado inicial -de mejor esfuerzo- que le propuse el proveedor. Por otro lado, se elabora un backlog del alcance funcional que tendrá la aplicación. A medida que se suceden los Sprints del proyecto, el equipo evalúa que tan efectivo ha sido el equipo en desarrollar la funcionalidad esperada. El proyecto efectivamente culmina cuando el presupuesto se agota. En este momento, el equipo revisa si la funcionalidad mínima esperada se cumplió, se excedió o si el equipo se quedó corto. Cualquiera sea el escenario, lo que ocurra no será una sorpresa para el equipo, puesto que el cliente recibió, al final de cada Sprint (2 a 4 semanas) piezas de código operativas que demostraban si el proyecto iba por buen camino, como también daban luces al equipo del cliente para saber si lo que se pidió inicialmente -una vez probado en la pantalla- si era lo que se necesitaba.

Tiene otra pregunta sobre desarrollo de software u otro servicio de outsourcing de tecnologías de la información? Por favor, contáctenos, y háganoslo saber!