"Necesitamos software a medida" suena, para la mayoría de las pymes, a un proyecto de tres o cuatro meses. Reuniones de relevamiento, un documento de requerimientos, aprobaciones, un cronograma con hitos, y recién ahí, algún día, algo que se puede usar.
No tiene por qué ser así. La mayoría de los sistemas que resuelven un problema real de una pyme -no una plataforma de escala, un sistema puntual- se pueden construir y entregar en dos a seis semanas. La diferencia no es magia ni un equipo más grande. Es qué se corta.
Lo que hace largo un proyecto no es el código
Escribir la lógica de un sistema -el CRUD, las validaciones, la integración con un medio de pago, el panel de administración- rara vez toma meses. Lo que estira los proyectos es todo lo que rodea al código: semanas de relevamiento antes de escribir la primera línea, un documento de alcance que se revisa varias veces antes de aprobarse, capas de aprobación donde cada cambio pasa por dos o tres personas antes de tocar el proyecto.
Nada de eso construye el sistema. Solo lo demora. Y en una consultora con estructura, esas capas existen porque hay que coordinar a mucha gente. En un proyecto de una sola persona apoyada en IA, esas capas directamente no existen: no hay a quién coordinar.
Descubrimiento corto, no descubrimiento cero
Achicar el tiempo no significa saltear entender el problema. Significa no convertir esa etapa en un proyecto en sí misma. Una o dos conversaciones para entender qué se necesita de verdad -no lo que el cliente cree que necesita, sino el problema de fondo- alcanzan para arrancar. El resto del alcance se termina de definir mientras el sistema ya se está construyendo, no antes.
Eso invierte el orden habitual: en vez de documentar todo antes de construir nada, se construye una primera versión funcional rápido y se ajusta sobre eso. Es más fácil corregir algo que ya se puede ver y usar que corregir un documento.
Iteración semanal, no entrega única al final
Un proyecto de tres meses suele tener una sola entrega: al final. Hasta ese momento, el cliente no vio nada funcionando, solo maquetas o documentos. Si algo se entendió mal, se descubre tarde, cuando ya es caro corregirlo.
Un proyecto de dos a seis semanas funciona al revés: hay algo andando desde la primera semana, aunque sea una versión mínima. Cada avance se muestra apenas existe. Si algo no es lo que el cliente esperaba, se corrige en días, no en la revisión final de un proyecto de tres meses.
Lo que se corta y lo que no
Achicar los tiempos no es hacer las cosas más rápido y peor. Es sacar del medio lo que no agrega valor al resultado final:
- Documentación exhaustiva que nadie vuelve a leer una vez que el sistema funciona.
- Reuniones de seguimiento que existen para coordinar gente, no para avanzar el trabajo.
- Rondas de aprobación en cadena, donde cada instancia agrega días sin agregar decisión.
- Fases separadas de diseño, desarrollo y testing, en vez de hacerlo todo junto.
Lo que no se corta es el criterio: entender bien el problema antes de resolverlo, cuidar los casos donde el dinero o el stock están en juego, y probar que funciona antes de darlo por terminado.
Para qué proyectos no aplica esto
Esto funciona para sistemas puntuales: un catálogo, una gestión de turnos, un checkout, un panel de reportes. No aplica igual a una plataforma que va a escalar a miles de usuarios desde el día uno, o a un proyecto que necesita integrarse con varios sistemas legados a la vez. Ahí sí hace falta más tiempo de diseño previo, porque los errores de arquitectura son mucho más caros de corregir después.
La mayoría de las pymes, sin embargo, no están en ese caso. Necesitan resolver un problema concreto, no construir una plataforma. Y para eso, tres meses no son garantía de mejor resultado. Muchas veces son solo tiempo perdido en el medio.