Cómo trabajamos

Cuatro fases, entregables claros y nada oculto

La versión corta de cómo funciona de verdad un proyecto con TekPiq, escrita para responsables de ingeniería que han visto suficientes presentaciones de proveedores como para distinguir lo real del relleno.

La planta de la oficina de TekPiq en Istočno Sarajevo, con ingenieros trabajando en sus puestos — La planta de nuestra oficina en Istočno Sarajevo, donde tienen lugar todas las fases que verás a continuación.

El equipo de TekPiq alrededor de la mesa de la sala de reuniones, con portátiles y una pantalla compartida en la pared — En la sala de reuniones.

1–3 semanas

Discovery

Ponemos a prueba el problema antes de comprometernos con una solución. El resultado es un plan de entrega que puedes llevar a tu departamento de compras, no una presentación.

Entrevistas con stakeholders de producto, ingeniería y operaciones
Revisión del sistema actual: arquitectura, flujos de datos, puntos críticos y limitaciones
Investigación o validación con usuarios cuando no está clara la parte de cara al cliente
Registro de riesgos, registro de supuestos y un backlog priorizado
Plan de entrega con calendario, composición del equipo y presupuesto

Ingenieros de TekPiq en una sesión de arquitectura frente a la pizarra; uno de ellos dibuja el modelo de datos — En la pizarra, con los datos del cliente difuminados.

2–6 semanas (en paralelo con el inicio del desarrollo)

Diseño y arquitectura

Diseño e ingeniería trabajan en la misma sala. La UX, el modelo de datos y los límites del sistema evolucionan a la vez, no uno detrás de otro.

UX de baja a alta fidelidad (low-fi → high-fi); las decisiones se plasman como primitivas del sistema de diseño
Diagramas de arquitectura del sistema (C4 o similar), revisados con tu equipo
Contratos de API, esquemas de datos y plan de integración, cerrados antes del grueso del desarrollo
Requisitos no funcionales: rendimiento, SLA, observabilidad y seguridad
Spike técnico sobre cualquier componente no probado antes de incluirlo en el roadmap

Manos sobre un teclado mecánico frente a un portátil y un monitor con código — Pantallas difuminadas: el código del cliente sigue siendo privado.

Sprints de 1–2 semanas, entrega continua

Desarrollo

Entregamos software que funciona en cada sprint. Ves los avances en un entorno real, no en diapositivas de seguimiento.

Sprint planning con tu PM; backlog comprometido y criterios de éxito
Dailies en tu Slack o Teams; resúmenes por escrito, asíncronos por defecto, para equipos distribuidos
Revisión de código en cada PR; tests automatizados obligatorios antes del merge
Demo + retro al final de cada sprint, con un resumen por escrito (para quien se salte la reunión)
El entorno de staging replica producción; puedes probar cualquier cosa en cuanto está lista

Dos compañeros de TekPiq trabajando en pareja con sus portátiles en la mesa de reuniones — Trabajando en pareja en la mesa de reuniones.

1–3 semanas

Lanzamiento y traspaso

Un traspaso que funciona de verdad: tu equipo puede operar lo que hemos construido desde el primer día tras nuestra salida, o nos quedamos con un contrato de soporte. Tú decides.

Runbooks: despliegue, rollback, guardias e incidencias habituales
Documentación de arquitectura + registro de decisiones, para que tu próximo ingeniero entienda el porqué, no solo el qué
Sesiones de transferencia de conocimiento grabadas para futuras incorporaciones
Línea base de observabilidad: dashboards, alertas y error budget
Contrato de soporte opcional tras el lanzamiento para parches, mejoras o cobertura de guardias

Transformación digital

Metodología de transformación en siete pasos

En los proyectos de transformación más grandes (modernización, adopción de IA o reconstrucción completa de un producto), el ciclo de entrega en cuatro fases descrito arriba se desarrolla dentro de este arco más largo. Los tres primeros pasos suelen llevar 8–12 semanas en total y dejan algo funcionando en producción. El resto es cadencia operativa, no un diagrama de Gantt.

Paso 1

Diagnóstico

Auditoría del estado actual de sistemas, datos, procesos y de las personas que los gestionan, incluidas las limitaciones que nadie quiere poner por escrito.

Paso 2

Definición de la estrategia

Arquitectura objetivo y un plan de secuenciación ligado a una métrica de negocio concreta, no a «digitalizarse».

Paso 3

Diseño y desarrollo

UX, arquitectura e ingeniería en paralelo: el primer corte listo para producción sale en semanas, no cuando se aprueba la presentación.

Paso 4

Implantación

Despliegue incremental con el patrón strangler fig o con feature flags. Nada de migraciones heroicas de un día para otro. Lo antiguo solo se retira cuando el reemplazo ha demostrado que funciona.

Paso 5

Formación y adopción

La adopción se diseña, no se espera: grupos piloto, onboarding dentro del producto y formación creada junto al equipo que tendrá que convivir con el resultado.

Paso 6

Monitorización y feedback

Dashboards de adopción y resultados desde el primer día. Si al tercer mes el uso es del 20 %, es un bug que hay que corregir, no un problema de las personas.

Paso 7

Mejora continua

Revisión trimestral frente a la métrica de negocio. El sistema que se lanza no es el mismo que funciona un año después, y está pensado así.

Descubre todo el servicio de transformación digital

Modelo operativo

Comunicación

Trabajamos con tus herramientas: Slack/Teams para el día a día, Jira/Linear/Notion para el seguimiento y Git donde ya lo tengas. No te obligamos a entrar en nuestro portal.

Visibilidad

Tu equipo ve los mismos dashboards que nosotros. La velocidad, el burn-down y la cobertura de tests se ven en directo, no en PDF semanales. Los informes de sprint resumen cómo va el trabajo, no las sensaciones.

Empieza con una llamada para definir el alcance

30 minutos. Te preguntaremos por el problema, las limitaciones y qué significa para ti «terminado», y te diremos en qué fase empezaríamos y cuánto costaría averiguarlo.