← Volver a todos los proyectos

Proyecto para cliente

KSUP: sistema corporativo interno de gestión de proyectos

KSUP: sistema corporativo interno de gestión de proyectos

Tecnologías

ReactSharePointReduxStrategyProjectFrontendBackend

Servicios

  • Búsqueda unificada entre entidades con sistema de filtros adaptativo configurado por JSON
  • Módulo de planificación financiera para el rol de director financiero (React + C# + jQuery DataTables)
  • Sistema de permisos de visibilidad de campos con PeoplePicker y resolución de pertenencia a grupos
  • Actualización interactiva de planes operativos con abstracción C# VirtualSpListItem
  • TimerJob de integración de pagos AX con sincronización incremental/completa y registro de auditoría
  • Estándares de arquitectura frontend/backend introducidos de forma incremental en todos los módulos

Entregables

  • Búsqueda en la base de conocimiento entre todas las entidades — reconfigurable sin redespliegue
  • Generación automatizada de planes financieros a partir de ventas, contratos y planes operativos
  • Sistema de visibilidad de campos basado en roles, configurable por administradores sin cambios de código
  • Modal interactivo de actualización de PO — los usuarios revisan y eligen candidatos antes de confirmar
  • TimerJob de sincronización AX con modos completo/incremental, validación y registro de auditoría
  • ~30% de reducción en el tiempo de entrega de funciones gracias a la arquitectura compartida Redux/saga

Desafío

KSUP es una plataforma interna de gestión de proyectos construida sobre SharePoint para un gran cliente gubernamental. Cuando el equipo se incorporó, el sistema había crecido considerablemente sin estándares de ingeniería consistentes: código de frontend/backend fuertemente acoplado, ausencia de patrones de componentes reutilizables y un ciclo de compilación y despliegue lento. Las nuevas funciones eran costosas de lanzar y aún más costosas de mantener.

La solicitud era amplia: entregar varios módulos nuevos importantes — búsqueda, planificación financiera, permisos dinámicos de campos, actualizaciones de planes operativos y sincronización de datos externos — mientras se mejoraba a la vez el estado de la base de código que ralentizaba a todo el mundo.

Descubrimiento

Cada módulo reveló una clase distinta de problema:

  • Los usuarios alternaban entre cinco listas separadas para encontrar entidades — no existía una búsqueda entre entidades.
  • Los directores financieros tenían que compilar manualmente los planes financieros a partir de planes operativos, presales, contratos y ventas — todo en listas separadas.
  • Los campos de los formularios eran visibles para todos, sin importar el rol — no existía un sistema de permisos a nivel de campo.
  • Las actualizaciones de planes operativos se ejecutaban de forma totalmente automática, sin dar a los usuarios la oportunidad de revisar o seleccionar candidatos antes de confirmar los cambios.
  • Los datos de pagos del sistema externo AX debían reflejarse en ventas y contratos, pero no existía ningún mecanismo de sincronización.

Opciones consideradas

  1. Abordar cada módulo de forma aislada sin patrones compartidos — descartado. Repetiría los mismos problemas de acoplamiento y perdería la oportunidad de elevar toda la base de código.
  2. Refactorización completa antes de las nuevas funciones — descartado. Inviable dentro de los plazos de negocio; no entregaría nada durante meses.
  3. Mejora incremental — introducir estándares módulo por módulo — elegido. Cada módulo nuevo sigue una separación limpia de frontend/backend; el código existente se mejora de forma oportunista a medida que se toca.

Decisión

Se estandarizó en React/TypeScript/Redux con redux-saga para los efectos secundarios y reselect para el estado derivado. Cada módulo obtiene su propio slice de Redux, contratos de API tipados codiseñados con el desarrollador backend y cobertura de pruebas unitarias. La configuración compartida (por ejemplo, los esquemas de filtros) se almacena en bibliotecas de documentos de SharePoint para que el comportamiento pueda cambiarse sin una recompilación.

Implementación

Búsqueda unificada en la base de conocimiento

Se construyó una única página de búsqueda que cubre todas las entidades del sistema. La barra lateral de filtros adaptativa se reconstruye según el tipo de contenido seleccionado; cada tipo de filtro (lista, term store, campo enum, rango de fechas, rango numérico) se describe mediante una configuración JSON almacenada en SharePoint — reconfigurable sin un despliegue de código. La carga de opciones de filtro es perezosa y paginada mediante watchers de redux-saga. Se aportaron mejoras a la biblioteca de código abierto react-widgets — varios PR fueron fusionados en el repositorio oficial.

Módulo de planes financieros

Se introdujo un flujo de trabajo específico para el director financiero que genera automáticamente planes financieros anuales agregando datos de planes operativos, presales, contratos y ventas. Un plugin de jQuery personalizado (DataTables + Mustache) renderiza el campo de informe JSON como una tabla financiera interactiva directamente en la página del elemento de lista de SharePoint. El servicio backend en C# se encarga de la generación del plan, la validación a nivel de dirección y los receptores de eventos de SharePoint — cubierto por completo con pruebas de integración NUnit.

Visibilidad de campos por permisos

Se desarrolló un UserControl con un PeoplePicker que permite a los administradores asignar reglas de visibilidad de campos a usuarios individuales o grupos de seguridad — sin necesidad de cambiar el código. La configuración JSON se guarda a través de un servicio WCF; la capa en C# resuelve la pertenencia a grupos de forma recursiva en el momento del renderizado. El módulo se entrega con cobertura de pruebas completa.

Actualizaciones interactivas de planes operativos

El proceso existente de actualización del PO comparaba automáticamente las ventas/contratos antiguos y nuevos y confirmaba los cambios sin revisión del usuario. Se rediseñó para mostrar un modal con dos tablas de comparación — posiciones nuevas y posiciones modificadas — permitiendo a los usuarios elegir qué incluir. El principal desafío técnico: la lógica existente estaba fuertemente acoplada a SPListItem. En lugar de reescribirla, se introdujo un contenedor VirtualSpListItem en C# — API idéntica, pero opera exclusivamente en memoria sin crear elementos de lista de SharePoint, lo que permite seleccionar candidatos antes de confirmar cualquier dato.

Integración de datos de pago de AX

Se construyó un TimerJob de SharePoint que sincroniza los datos de pago del sistema financiero externo AX con las entidades de ventas y contratos. Admite modos de sincronización tanto completa como incremental. Cada ejecución valida los campos obligatorios, empareja entidades por código de proyecto y serializa los calendarios de pago en JSON para su almacenamiento. Un registro exhaustivo con puntos de control garantiza que cada sincronización pueda auditarse. Cubierto por pruebas de integración contra datos reales de AX.

Resultado

Cinco módulos en producción entregados en una plataforma donde antes cada función requería trabajo de integración a medida. Introducir una separación limpia de frontend/backend y patrones compartidos de Redux redujo el tiempo de lanzamiento de nuevas funciones en aproximadamente un 30%. El enfoque de configuración de filtros eliminó categorías enteras de despliegues — los product managers ahora pueden reconfigurar el comportamiento de búsqueda sin involucrar a ingeniería.

Disponible para colaboración por contrato

Estoy disponible para colaborar por contrato. Si tiene una idea de proyecto interesante, reserve una llamada por Calendly.

Agenda una llamada de 30 min