Análisis de viabilidad técnica

La viabilidad técnica de un proyecto no es la respuesta a “¿se puede hacer?”. Porque en el mundo del software moderno casi todo “se puede hacer” con suficiente tiempo, presupuesto e ingenieros. Esa no es la verdadera pregunta. La verdadera pregunta es: “¿Está alineado con su presupuesto, su calendario y los objetivos de su cliente?”. Nuestro análisis de viabilidad busca la respuesta a esa pregunta. Qué integración de terceros tiene un costo que supera su estimación de tráfico mensual; qué normativa limita su diseño de datos; qué funcionalidad no puede realizarse con la tecnología que utiliza; qué objetivo de rendimiento es matemáticamente imposible: todo eso lo enumeramos de antemano. Esa lista no existe para decirle “su proyecto no se hará”; todo lo contrario: existe para decirle “con estas pequeñas revisiones, su proyecto será posible y sostenible”. Convertir un sueño más en realidad pasa por un cuidadoso análisis de tres semanas al inicio.

Cuando sometemos un proyecto a un análisis de viabilidad, nuestro equipo busca respuestas por escrito a cinco preguntas independientes: (1) ¿De qué servicios de terceros dependerá y cuáles son sus límites y costos diarios o mensuales? (2) ¿Qué normativas afectan al diseño de datos y al período de conservación? (3) ¿Cómo evoluciona la curva de usuarios estimados y costo de servidores: primer mes, primer año, quinto año? (4) ¿Qué stack tecnológico se adapta a la arquitectura existente y sigue siendo sostenible? (5) ¿Cuántos especialistas en paralelo se necesitan para asegurar la fecha de entrega que espera el cliente? Cuando se reúnen las respuestas a esas cinco preguntas, surge el perfil real del proyecto: toda la distancia entre lo perfecto sobre el papel y lo probado sobre el terreno. Las páginas de respuestas se entregan como anexo a su contrato; si más adelante surge una discrepancia, leemos juntos en el mismo documento por qué algo es como es.

No todos los proyectos pueden realizarse exactamente en la forma en que llegan por primera vez. Pero todo proyecto tiene una versión realizable. Nuestro informe de viabilidad no se limita a decir “sí” o “no”: normalmente traza una hoja de ruta alternativa a la que podemos decir “sí, si se plantea de esta manera”. El enfoque MVP consiste en publicar primero la versión mínima que cubre la necesidad real del cliente y aporta un valor real al usuario. El resto de las funcionalidades se planifica sobre un mapa visible; además de la ventaja de velocidad, los comentarios de usuarios reales permiten volver a trazar el camino que sigue. En el enfoque por fases dividimos el proyecto en 3 o 4 etapas. Al final de cada fase, el cliente ve algo publicado, se cierra una parte del pago y el alcance de la fase siguiente se recalcula con los datos más recientes. El riesgo baja, la satisfacción del cliente sube y el equipo de ingeniería no se siente bajo presión. A veces, un cambio de tecnología es el único camino para evitar que el presupuesto del proyecto se duplique. Multiplataforma en lugar de móvil nativo; integración sobre un SaaS líder del mercado en lugar de un CRM a medida; sistemas más sencillos basados en reglas donde la IA o el aprendizaje automático no son necesarios. Calculamos la relación costo/valor de cada opción y se la presentamos: la decisión siempre es suya.

La “Hoja de ruta técnica” que recibe al final del proceso de viabilidad de tres semanas es lo que llamamos “la constitución del proyecto”. Este documento es el único punto de referencia al que volverán todos los equipos desde el inicio del proyecto hasta su entrega. El documento es conciso, pero exhaustivo: diagramas de arquitectura, esquemas de bases de datos, lista de integraciones de terceros, tabla de costos de servidores, análisis de cumplimiento legal, calendario de entrega con Buffer, registro de riesgos y alternativas. Todo en un solo PDF, en un lenguaje que pueden leer los abogados tanto de su agencia como de su cliente. Cuando más adelante surge una discrepancia (“¿esta funcionalidad estaba en el plan?”, “¿por qué este costo es así?”, “¿cómo se fijó este plazo?”), consultamos este documento. No es verbal, sino escrito; no es estimado, sino calculado; no es unilateral, sino firmado. Así es la constitución de un proyecto.