So arbeiten wir

Vier Phasen, klare Ergebnisse, nichts versteckt

Die Kurzfassung, wie ein Projekt mit TekPiq tatsächlich abläuft – geschrieben für Engineering-Verantwortliche, die genug Anbieterpräsentationen gesehen haben, um Substanz von Fassade zu unterscheiden.

Die TekPiq-Büroetage in Istočno Sarajevo mit Entwicklern bei der Arbeit an ihren Schreibtischen — Unsere Büroetage in Istočno Sarajevo – hier finden alle folgenden Phasen statt.

Das TekPiq-Team mit Laptops am Besprechungstisch, an der Wand ein gemeinsamer Bildschirm — Im Besprechungsraum.

1–3 Wochen

Discovery

Wir klopfen das Problem gründlich ab, bevor wir uns auf eine Lösung festlegen. Das Ergebnis ist ein Umsetzungsplan, mit dem Sie in die Beschaffung gehen können – kein Foliensatz.

Stakeholder-Interviews mit Produkt, Engineering und Betrieb
Review der bestehenden Systeme: Architektur, Datenflüsse, Schwachstellen, Einschränkungen
Nutzerforschung oder Validierung, wo die Ausgestaltung für Kunden noch unklar ist
Risikoregister, Annahmenprotokoll und ein priorisiertes Backlog
Umsetzungsplan mit Zeitplan, Teamzuschnitt und Budget

TekPiq-Entwickler in einer Architektur-Session am Whiteboard; einer von ihnen skizziert das Datenmodell — Am Whiteboard – Kundendetails unkenntlich gemacht.

2–6 Wochen (parallel zur frühen Umsetzung)

Design & Architektur

Design und Entwicklung arbeiten in einem Raum. UX, Datenmodell und Systemgrenzen entwickeln sich gemeinsam statt nacheinander.

UX von Low-Fi bis High-Fi; Entscheidungen als Bausteine des Designsystems festgehalten
Systemarchitektur-Diagramme (C4 oder ähnlich), gemeinsam mit Ihrem Team geprüft
API-Verträge, Datenschemata, Integrationsplan – festgelegt, bevor die Hauptentwicklung beginnt
Nicht-funktionale Anforderungen: Performance, SLAs, Observability, Sicherheit
Technischer Spike für jede unerprobte Komponente, bevor sie fest in die Roadmap aufgenommen wird

Hände auf einer mechanischen Tastatur vor einem Laptop und einem Monitor mit Code — Bildschirme unkenntlich gemacht – Kundencode bleibt vertraulich.

Sprints von 1–2 Wochen, Continuous Delivery

Build

Funktionierende Software in jedem Sprint. Sie sehen den Fortschritt in einer laufenden Umgebung, nicht auf Statusfolien.

Sprint-Planung mit Ihrem PM; verbindliches Backlog und Erfolgskriterien
Tägliche Stand-ups in Ihrem Slack oder Teams; schriftliche Zusammenfassungen nach dem Async-first-Prinzip für verteilte Teams
Code-Review bei jedem PR; automatisierte Test-Gates vor dem Merge
Demo + Retro am Sprint-Ende mit schriftlicher Zusammenfassung (für alle, die das Meeting auslassen)
Die Staging-Umgebung spiegelt die Produktion; Sie können alles durchklicken, sobald es gebaut ist

Zwei TekPiq-Kollegen beim Pair-Programming mit Laptops am Besprechungstisch — Pairing am Besprechungstisch.

1–3 Wochen

Launch & Übergabe

Eine Übergabe, die wirklich funktioniert: Ihr Team kann das Gebaute ab dem ersten Tag nach unserem Abschied selbst betreiben – oder wir bleiben per Retainer an Bord. Sie entscheiden.

Runbooks: Deployment, Rollback, Rufbereitschaft, häufige Störungen
Architekturdokumentation + Entscheidungsprotokoll, damit Ihr nächster Entwickler das Warum versteht, nicht nur das Was
Aufgezeichnete Wissenstransfer-Sessions für spätere Neuzugänge
Observability mit Baseline: Dashboards, Alerts, Error Budget
Optionaler Retainer nach dem Launch für Fixes, Erweiterungen oder Rufbereitschaft

Digitale Transformation

Transformationsmethodik in sieben Schritten

Bei größeren Transformationsprojekten – Modernisierung, KI-Einführung oder der komplette Neuaufbau eines Produkts – läuft der oben beschriebene Vier-Phasen-Rhythmus innerhalb dieses längeren Bogens. Die ersten drei Schritte dauern zusammen meist 8–12 Wochen und bringen etwas live in Produktion. Der Rest ist ein fester Betriebsrhythmus, kein Gantt-Diagramm.

Schritt 1

Bestandsaufnahme

Ist-Analyse von Systemen, Daten, Prozessen und den Menschen, die sie betreiben – einschließlich der Einschränkungen, die niemand gern aufschreibt.

Schritt 2

Strategieentwicklung

Zielarchitektur und ein Stufenplan, der an eine konkret benannte Geschäftskennzahl gekoppelt ist – nicht an ein vages „digital werden“.

Schritt 3

Design & Entwicklung

UX, Architektur und Entwicklung parallel – der erste produktionsreife Teil geht in Wochen live, nicht erst nach Freigabe der Präsentation.

Schritt 4

Implementierung

Schrittweiser Rollout per Strangler-Fig-Muster oder Feature Flags. Keine riskanten Hauruck-Umstellungen. Alte Oberflächen werden erst abgeschaltet, wenn sich der Ersatz bewährt hat.

Schritt 5

Schulung & Einführung

Akzeptanz wird gezielt hergestellt, nicht erhofft: Pilotgruppen, Onboarding direkt im Produkt und Schulungen, die gemeinsam mit dem Team entstehen, das mit dem Ergebnis leben muss.

Schritt 6

Monitoring & Feedback

Dashboards für Nutzung und Ergebnisse ab dem ersten Tag. Liegt die Nutzung im dritten Monat bei 20 %, ist das ein Fehler, den wir beheben – kein Problem der Anwender.

Schritt 7

Kontinuierliche Verbesserung

Vierteljährliche Überprüfung anhand der Geschäftskennzahl. Das System, das live geht, ist nicht das System, das ein Jahr später läuft – und das ist Absicht.

Alles zur Leistung Digitale Transformation

Arbeitsmodell

Kommunikation

Wir arbeiten in Ihren Tools – Slack/Teams für den Alltag, Jira/Linear/Notion für das Tracking, Git dort, wo es bei Ihnen liegt. Sie müssen nicht in unser Portal wechseln.

Transparenz

Ihr Team sieht dieselben Dashboards wie wir. Velocity, Burn-down und Testabdeckung sind live einsehbar, nicht als wöchentliche PDFs. Sprint-Reports fassen zusammen, woran tatsächlich gearbeitet wurde – nicht die Stimmung.

Starten Sie mit einem Erstgespräch

30 Minuten. Wir fragen nach dem Problem, den Rahmenbedingungen und danach, was „fertig“ für Sie bedeutet – und sagen Ihnen, in welcher Phase wir einsteigen würden und was es kostet, das herauszufinden.