¿Cuánto se tarda en hacer un web part de SharePoint?
Última actualización:
Escribir el código son días. El proyecto son 6-12 semanas. Esa diferencia no es colchón ni ineficiencia: es todo lo que ocurre alrededor del código, y entenderlo es lo que te permite acortar un plazo en vez de solo quejarte de él.
Un desarrollador de SPFx competente construye un componente que lee una lista, la filtra y la pinta bien en tres a cinco días. Las semanas restantes se van en la especificación, el montaje de entornos, la revisión de seguridad del cliente, el despliegue en el catálogo de aplicaciones, la validación de usuario y las dos rondas de cambios que llegan tras el primer contacto con usuarios reales.
La consecuencia práctica: si quieres un plazo más corto, programar es lo que no hay que optimizar. Ya es la parte más pequeña.
Dónde se va el calendario
| Paso | Duración típica | En una vía no-code |
|---|---|---|
| Especificación y validación | 1–2 semanas | Igual, o menos porque enseñas en vez de describir |
| Montaje de entornos y proyecto | 2–4 días | Desaparece |
| Construir el componente | 3–5 días | Minutos |
| Pruebas internas | 2–4 días | Minutos: lo ves con datos de ejemplo antes de publicar |
| Revisión de seguridad del cliente | 1–4 semanas | Una vez por tenant, no por componente |
| Despliegue en el catálogo | 1 día–2 semanas | Una vez por tenant, no por componente |
| Validación de usuario y cambios | 1–3 semanas | El mismo trabajo, pero los cambios son minutos y no una entrega |
Dominan dos filas, y ninguna es desarrollo: la revisión de seguridad y el despliegue. En un proyecto a medida se repiten con cada componente, porque cada componente es código nuevo que hay que revisar y desplegar. Esa es la diferencia estructural, no la velocidad tecleando.
El paso que nadie planifica
La revisión de seguridad es el cuello de botella, y casi siempre falta en el plan. Es donde una estimación de cuatro semanas se convierte en una realidad de cuatro meses, y el motivo es organizativo y no técnico: quien quiere la herramienta no es quien puede aprobarla, y quien aprueba no tiene fecha límite.
Lo que sí la acorta:
- Empezarla el primer día, en paralelo a la construcción. La mayoría la empieza cuando el componente está terminado, y así serializa dos cosas que podían haberse solapado.
- Mandar el manifiesto de permisos antes de la reunión. Las revisiones se atascan por falta de información mucho más a menudo que por objeciones reales.
- Poner nombre al que aprueba. «TI» no es una persona y no te puede dar una fecha.
- Preguntar qué se ha aprobado antes. Si ya pasó un paquete de terceros, estás siguiendo un camino en vez de abrirlo.
Hay además un arreglo estructural: un paquete que se aprueba una vez por tenant y luego renderiza cualquier número de componentes convierte esto de un coste por proyecto en algo puntual. Ese es el modelo detrás del dossier de seguridad de Sharelio, que existe justo para que este paso pueda ocurrir sin reunión.
Plazos realistas
| Escenario | Plazo realista de principio a fin |
|---|---|
| Componente sencillo, tenant con catálogo y una aprobación previa | 2–3 semanas |
| Componente sencillo, primer paquete personalizado del tenant | 6–10 semanas |
| Componente con integración externa | 8–16 semanas |
| Lo mismo, en una organización regulada | 3–6 meses |
| Componente no-code, con el paquete ya instalado | Esa misma tarde |
La segunda fila es la que sorprende, y merece decirse claro: el primer componente personalizado de un tenant cuesta muchísimo más calendario que el segundo, porque paga el catálogo de aplicaciones, la revisión de seguridad y la conversación de gobierno. Presupuesta eso una vez y reutilízalo.
Preguntas frecuentes
¿Por qué una consultora presupuesta 6-12 semanas para cinco días de trabajo?
Porque está presupuestando el proyecto y no la programación, y ya ha aprendido lo que pasa de verdad. La estimación incluye la especificación, los ciclos de revisión, vuestro proceso de seguridad, el despliegue y los cambios que siempre llegan tras la primera demo, más el hecho de que su desarrollador no trabaja solo para vosotros. Un presupuesto de una semana para un web part a medida es una señal de alarma, no un chollo.
¿Podemos acelerar saltándonos la revisión de seguridad?
Se puede comprimir, no saltar, y se comprime preparándola, no metiendo prisa. Manda el paquete, el manifiesto de permisos y la respuesta sobre el flujo de datos antes de la primera reunión. Las revisiones son lentas sobre todo porque la información llega a trozos a lo largo de semanas.
¿Una plataforma no-code elimina la revisión de seguridad?
No, y cualquier proveedor que diga lo contrario está describiendo otro producto. Lo que cambia es cuándo ocurre: una vez, sobre un paquete, antes del primer componente, en vez de cada vez que alguien quiere algo nuevo. La revisión en sí es el mismo trabajo, hecho una sola vez.
¿Cuál es la vía honesta más rápida para tener algo la semana que viene?
Una lista de SharePoint con una vista formateada. Es gratis, no necesita despliegue ni aprobación, y cubre una parte real de los requisitos. Úsala para averiguar exactamente qué no puedes hacer: así elegirás una vía de pago contra una limitación conocida y no contra una suposición.