Por qué los nombres internos importan
Un proyecto sin nombre interno es proyecto que el equipo no recuerda. 'La iniciativa de migración del backend de pagos a microservicios' es descripción técnica, no nombre. Tu equipo lo dirá tres veces y luego dirá 'el proyecto ese'. Proyecto Atlas se mencionará en cien reuniones sin esfuerzo.
Los nombres internos cumplen tres funciones: identidad (el equipo se reconoce trabajando en algo con nombre propio), confidencialidad (los proyectos en development pueden mencionarse sin revelar funcionalidad antes del lanzamiento) y memorabilidad (en post-mortems, retros y aprendizajes futuros, recordás nombres mejor que descripciones).
Apple usa nombres de pingüinos para sistemas operativos en desarrollo (Cheetah, Tiger, Snow Leopard, Big Sur). Google usa postres en Android (KitKat, Oreo, Pie). Microsoft usa nombres de ciudades en Windows. Estas convenciones internas crean cultura y ayudan a documentar décadas de proyectos sin colisión de nombres.
Convenciones que funcionan en empresas de software
La convención temática es la más adoptada: tu organización elige una familia (animales, ciudades, estrellas, mitología, comida) y bautiza cada proyecto con miembro distinto. Ventajas: un nuevo proyecto siempre tiene candidatos disponibles, los nombres comparten estética, y un newcomer entiende rápido el patrón.
La convención versionada agrega prefijo o sufijo de versión: Atlas v1, Atlas v2. Funciona si tu organización tiene proyectos que evolucionan en grandes saltos. Pero confunde si Atlas v1 y Atlas v2 son productos completamente distintos: mejor cambiá el nombre raíz cuando cambia la naturaleza.
La convención fonética usa nombres que codifican identidad de equipo. Si el equipo se llama 'Pampa' y todos sus proyectos llevan nombres de pájaros argentinos (Hornero, Cardinal, Cóndor), construye identidad de squad sin ser obvia desde afuera. Esto refuerza pertenencia.
Evitá la convención que codifica info sensible: Project NPS-50 revela que estás detrás de mejorar NPS hasta 50. Project Andromeda no dice nada al espía industrial casual. La opacidad del nombre interno es feature, no bug.
Errores comunes al nombrar proyectos
Nombres que ya son productos comerciales: Project Slack, Project Notion, Project Stripe. Aunque sea uso interno, generás confusión en docs, JIRA y conversaciones cross-team. Búsquedas de Google también se contaminan.
Nombres con significado político o cultural problemático: revisá tu propuesta antes de adoptarla. Operation Spartan está bien, Operation Crusade tiene carga histórica problemática. Project Neptune está bien, Project Cortez evoca colonialismo en LATAM. Tu nombre interno será mencionado en presentaciones, emails y eventualmente leaks: cuidá las connotaciones.
Nombres que requieren explicación pública si filtran: si tu proyecto se llama Operación Caja Negra y un periodista lo descubre, el nombre solo es titular. Project Atlas es opaco y aburrido para narrativas externas. Cuando elijas, imaginá tu nombre filtrado en TechCrunch: ¿genera escándalo o solo curiosidad?
Sobreabundancia de proyectos llamados Phoenix: probablemente sea el nombre de proyecto más usado del mundo del software. Si querés diferenciación, evitá los lugares comunes (Phoenix, Apollo, Atlas, Olympus). Optá por mitologías menos saqueadas: nórdica, eslava, africana, japonesa.
De nombre interno a marca pública
A veces el nombre interno se convierte en marca pública. Esto pasa cuando el proyecto interno funciona tan bien que se vuelve producto. Apollo de Spotify, Manhattan del Proyecto Manhattan, Olympus de Tesla son ejemplos. Si planteás esa posibilidad desde el inicio, evitá nombres demasiado específicos al equipo o cargados de jerga interna.
Antes de promocionar un nombre interno a público, hacé due diligence completo: trademark check, búsqueda de dominio, redes sociales, conflictos con productos similares. Lo que era opaco para uso interno puede colisionar feo en mercado abierto. Project Cortana internamente está bien; lanzar Cortana al mundo requiere que ya tengas la marca registrada.
Para proyectos que sabés desde el inicio que serán productos, usá dos nombres: uno interno (operación) y uno para producto. Esta separación permite seguir trabajando en Operación Atlas mientras desarrollás la marca pública en paralelo. Atlas puede tomarse mientras estás en development; Operación Atlas sigue siendo tuya internamente.
Documentá tu sistema de naming en una página de wiki interna. Después de 50 proyectos, va a haber colisiones, dudas y olvidos. Una página simple con 'Convenciones de naming · Lista de nombres usados · Familias temáticas disponibles' ahorra reuniones futuras y mantiene coherencia organizacional.