Sistema de departamento de aplicaciones internas
Equipo que desarrolla herramientas y aplicaciones internas para la empresa, desde la solicitud del departamento hasta la adopción por los empleados y la medición del impacto.
El ciclo completo de construcción de la herramienta interna: solicitud, análisis, desarrollo, prueba y lanzamiento, y después adopción y medición de impacto real.
Sin tarjeta de crédito: tu proyecto queda listo con el sistema completo en un minuto
Así llegará el tablero del sistema: columnas de flujo de trabajo y tarjetas iniciales que muestran los primeros pasos
¿Cómo fluye el trabajo en este sistema?
Las necesidades de los departamentos llegan como tarjeta en «Solicitud», que explica el problema y no la solución prefabricada: qué proceso está atascado, quién lo sufre y cuánto tiempo cuesta. La tarjeta pasa a «Análisis», donde el analista se sienta con el departamento solicitante, entiende el proceso de verdad y escribe los requisitos y los criterios de aceptación en la tarjeta. Tras la aprobación pasa a «Desarrollo» y los desarrolladores trabajan en ella con entregas por fases; luego «Prueba», donde la prueban usuarios del propio departamento solicitante y sus observaciones se registran; después «Lanzamiento» cuando está lista para todos los empleados. El recorrido no termina en el lanzamiento: la tarjeta pasa a «Adopción» para seguir el uso de la herramienta por los empleados y formarlos en ella, y luego a «Medición» para documentar su impacto real en el proceso para el que se construyó.
El chat es para la coordinación diaria de los desarrolladores y las preguntas urgentes de requisitos con los departamentos solicitantes. El foro documenta las decisiones de ingeniería, los debates de los grandes requisitos y las retrospectivas posteriores al lanzamiento, para que las opciones de diseño y sus justificaciones sigan siendo comprensibles para quien se incorpore al equipo más tarde y no se repitan los mismos debates cada vez.
El director de aplicaciones recibe las solicitudes, ordena sus prioridades y aprueba su entrada en «Desarrollo»; el analista acompaña la tarjeta desde «Análisis» hasta la aceptación de «Prueba» con el departamento solicitante, y los desarrolladores ejecutan y tratan las observaciones. Los resultados de «Medición» vuelven al director de aplicaciones para que decida: desarrollar la herramienta con una segunda fase, mantenerla como está o retirarla oficialmente si no se usa.
¿Quién hace qué?
Los roles operativos de este sistema y la responsabilidad de cada uno en el trabajo diario: asígnalos a tu equipo tal cual o adáptalos a vuestra realidad.
Director de aplicaciones internas
Recibe las solicitudes de los departamentos y ordena sus prioridades; aprueba el paso de «Análisis» a «Desarrollo» y de «Prueba» a «Lanzamiento».
Analista de negocio
Analiza la necesidad del departamento solicitante y escribe los requisitos y los criterios de aceptación en la tarjeta; acompaña la prueba con los usuarios hasta su aceptación.
Desarrolladores
Construyen las aplicaciones en las tarjetas de «Desarrollo» y tratan las observaciones de «Prueba»; documentan las decisiones de ingeniería en el foro en el momento de tomarlas.
Coordinador de adopción y formación
Dirige la presentación de la herramienta a los empleados tras el lanzamiento y su formación en ella, y reúne los indicadores de uso en «Adopción» y «Medición».
¿Qué se prepara para ti desde el primer día?
Unidades del sistema
- Tareas — Un tablero kanban con columnas de flujo de trabajo y tarjetas de ejecución
- Chat — El canal rápido de coordinación diaria del equipo
- Foro — Debates documentados en secciones organizadas: decisiones y conocimiento que nunca se pierden
Secciones del foro (4)
- Decisiones de ingenieríaDocumentación de las opciones de arquitectura y de las herramientas adoptadas en la construcción de las aplicaciones internas y sus justificaciones: referencia para quien trabaje en el código más adelante.
- Requisitos y debates con los departamentosDiálogos en profundidad con los departamentos solicitantes sobre los grandes requisitos antes de convertirlos en análisis formal.
- Retrospectivas posteriores al lanzamientoQué funcionó y qué falló en cada lanzamiento: lecciones documentadas para los próximos proyectos.
- Ideas y mejorasPropuestas de nuevas herramientas internas o de mejoras sobre las existentes, del equipo y de las observaciones de los usuarios.
«Reglas de trabajo en este sistema» — Fijado en el foro
1) No hay desarrollo antes de un análisis aprobado: la tarjeta no entra en «Desarrollo» sin requisitos y criterios de aceptación escritos. 2) El solicitante del departamento participa en la prueba: no hay lanzamiento sin su aceptación. 3) Las decisiones de ingeniería se documentan en el foro en el momento de tomarlas, no después. 4) El lanzamiento no se considera completo hasta una fase de adopción y una medición de impacto documentadas. 5) La herramienta que no se usa se retira oficialmente con una decisión documentada, en lugar de dejarla languidecer.
Sistemas similares a este
¿Listo? Su primer proyecto está a dos minutos
Cree su espacio de trabajo gratis ahora e invite a su equipo antes de que termine el día.