Termintreue

Ein Liefertermin ist für uns kein Wunsch — sondern eine Klausel, die nicht gebrochen werden darf

Wir lehnen die Unsicherheitskultur der Software-Branche ab.

Wenn der Liefertermin, den eine Agentur ihrem Kunden versprochen hat, ins Wanken gerät, ist das der härteste Schlag gegen den Ruf dieser Agentur. Die jahrhundertealte chronische Krankheit der Software-Branche — die 'chronischen Verzögerungen' — akzeptieren wir nicht; es ist der Name eines Krieges, in dem wir explizit eine Seite gewählt haben. Der Kalender, den wir Ihnen beim Start der Zusammenarbeit mit Partnerfy geben, ist keine 'geschätzte Vermutung'. Dahinter stehen mathematische Berechnungen, eine zeilenweise Risiko-Analyse (Buffer Time), ein zweistufiger Backup-Teamplan und eine klar in den Vertrag geschriebene Schadensersatzklausel. Keine Schätzung — eine Verpflichtung. Der Rest dieser Seite erklärt eins nach dem anderen, wie wir mit dieser Sicherheit sprechen können. Wenn Sie in der Vergangenheit die Enttäuschung eines gebrochenen Liefertermins erlebt haben — diese Enttäuschung werden Sie hier nicht wiedersehen.

‚Unsicherheit' ist ein Schweigen, das die Software-Branche akzeptiert hat

Denken Sie einen Moment darüber nach: Wie viele Leiter digitaler Agenturen mussten am Liefertag eines Software-Projekts den Satz „eigentlich verschieben wir uns um eine Woche, aber so etwas passiert eben" schlucken? Dieser Satz hat sich in der Branche so sehr normalisiert, dass die Kunden ihn selbst erwarten. Warten wurde zur Gewohnheit; die Gewohnheit wurde zur Kultur. Unser Arbeitsprinzip beginnt an dem Punkt, an dem wir diese Kultur ablehnen. Wenn ein Liefertermin auf dem Spiel steht, ist die einzige Lebenslinie, die wir halten, das „mathematisch validierte" Datum. Kein Datum wird ohne eine mathematische Berechnung gegeben; einmal gegeben, wird kein Datum ohne eine weitere Berechnung geändert. Die „Flexibilität" der Branche tritt vor unserer „Disziplin" zurück.
‚Unsicherheit' ist ein Schweigen, das die Software-Branche akzeptiert hat

Ein Liefertermin durchläuft drei Phasen

Ein erfundenes Datum zu geben ist eine Stunde Arbeit. Ein mathematisch validiertes Datum zu geben ist ein dreistufiger Engineering-Prozess.

1. Analyse & Buffer-Berechnung

Wir listen direkt zu Beginn die technischen Anforderungen, den Zustand des bestehenden Systems und die externen Abhängigkeiten (Drittanbieter-APIs, Store-Freigaben, Regulierung). Das Risiko jedes Punktes wird mit der Wahrscheinlichkeit multipliziert, dann wird ein Reserve-Aufschlag (Buffer Time) hinzugefügt. Welches Datum wir Ihnen auch geben — Sie können sich darauf verlassen, weil es nun 'mathematisch' ist.

2. Sprint-Management

Wir teilen das Projekt in zweiwöchige Sprints mit einem sichtbaren Ergebnis am Ende jedes Sprints. Erscheint eine Abweichung, schaltet sich das Kontroll-Tor nicht zu Beginn des nächsten Sprints ein — sondern noch im laufenden Sprint, am selben Tag. Frühe Erfassung rettet den Kalender.

3. Final-QA & Übergabe

Sobald der letzte Sprint endet, durchläuft der Code eine 100-Punkte-Qualitätsprüfung. Sobald die Fehlertoleranz auf null sinkt, wird das Projekt am zugesagten Tag und zur zugesagten Stunde ausgeliefert. Nicht um 23:59 — wir liefern zum Geschäftstagsbeginn.

Ein Datum zu geben ist zuallererst eine Mathematikaufgabe

Ein Datum zu geben ist zuallererst eine Mathematikaufgabe

Ein Liefertermin mathematisch zu berechnen bedeutet, drei Dinge nebeneinander zu legen: (1) den Projektumfang, in eine konkrete Zahl umgewandelt — Story Points oder Function Points; (2) die historische Performance des Teams (Velocity), datenbasiert gemessen, wie viel Arbeit pro Sprint im Durchschnitt abgeschlossen wird; (3) die Buffer Time, die den Unsicherheitsbereichen zugewiesen wird — meist zwischen 15% und 25% des Gesamtkalenders — wird obendrauf gerechnet. Wenn diese drei Zahlen aufeinandertreffen, ist das Datum, das wir in der Hand halten, kein „wir könnten" mehr — es ist ein „mathematisch — wir werden". Wenn zwei separate Senior-Ingenieure auf dasselbe Projekt schauen, geben sie dasselbe Datum — oder ein sehr nahes — weil die Berechnung offen und identisch ist.

Zahlen sind die lakonische Zusammenfassung von Verpflichtungen. Die aus vergangenen Projekten gesammelten Metriken sind die im Feld bewiesene Form unserer Kalender-Disziplin.

%97
Pünktliche Lieferung
Letzte 24 Monate
0
Anzahl der Entschuldigungen
Schadensersatz immer gezahlt
8 Yıl
Dieselbe Disziplin
Nie geändert

In unserer Welt ist „hat nicht geklappt" keine Antwort — sondern ein Geständnis

Die Schadensersatzklausel im Vertrag: keine Abschreckung, sondern eine automatische Regel.

Der Moment, in dem ein Vertrag unterzeichnet wird, ist nicht nur der Moment der Absicht — es ist auch der Moment, in dem der Preis, falls diese Absicht nicht eintritt, niedergeschrieben wird. In einem Partnerfy-Vertrag ist die „Verzugsschadens"-Klausel für uns keine Abschreckung, sondern eine wirtschaftliche Regel, die automatisch greift, wenn wir den Kalender verfehlen. „Hat nicht geklappt", „haben wir übersehen", „ein unerwartetes Problem kam auf", „die Drittanbieter-API hat nie geantwortet", „ein Teammitglied wurde krank" — keines davon wird in unserer Welt als Entschuldigung akzeptiert. Denn jedes davon ist eine Risikoposition, die bereits mathematisch in den Kalender eingerechnet sein sollte. Dass das Risiko eintritt, ist keine Überraschung; dass das Risiko nicht antizipiert wurde, ist vertraglich ein Fehler auf unserer Seite. Falls eine Verzögerung doch eintritt, würden wir lieber selbst die Kosten tragen, als Ihre Agentur vor ihrem Kunden ihr Gesicht verlieren zu lassen. Diese Präferenz ist keine Vertragsklausel; sie ist für uns ein nicht verhandelbares Prinzip.

Drei Sicherungen, die Risiken davon abhalten, Überraschungen zu werden

Wenn ein Risiko nicht mathematisch eingerechnet ist, wird es zur Überraschung, wenn es eintritt. Die folgenden drei Sicherungen verhindern, dass wir ein Risiko aus der Berechnung herauslassen.

Buffer Time

Jeder Kalender wird mit einer Reserve für die unsicheren Zonen jenseits des Umfangs berechnet. In einem typischen Projekt gehen 15-25% des Gesamtkalenders in den Buffer. Diese Reserve verwandelt das „Unerwartete" in das „mathematisch Erwartete".

Backup-Team-Plan

Hinter jeder kritischen Rolle steht ein Backup-Spezialist. Wenn ein Backend-Engineer krank wird, ist das kein Grund, dass der Kalender wackelt — sondern der Auslöser dafür, dass am selben Tag ein anderer Name einspringt. Ein Projekt, das von einer einzigen Person abhängt, ist für uns nicht fail-safe.

Risikoliste & Wahrscheinlichkeits-Multiplikator

Beim Projektstart listen wir jedes bekannte Risiko (API-Freigaben von Dritten, Store-Ablehnungen, regulatorische Änderungen, Team-Müdigkeit) und versehen jedes mit einem Wahrscheinlichkeits- und Auswirkungs-Multiplikator. Die Risikoliste ist nicht statisch; sie wird am Ende jedes Sprint-Retrospektivs neu vermessen. Eintretendes Risiko ist keine Überraschung — sondern Routine.

Die „Verzugsschadens"-Klausel in unserem Vertrag: Eine Regel, die automatisch greift

Wenn wir das versprochene Datum verfehlen — trotz Buffer Time, trotz Backup-Team, trotz Sprint-Kontroll-Toren — greift die Schadensersatzklausel im Vertrag automatisch. Die Klausel ist numerisch, nach einer vordefinierten Formel berechnet, und wächst mit den Tagen multiplikativ. Die Klausel funktioniert so: Eine Verzögerung in der ersten Woche entspricht 10% des Vertragswertes. Zweite Woche 20%. Dritte Woche 35%. Wenn die Verzögerung über die vierte Woche hinaus anhält, wird der gesamte Vertragswert zurückerstattet — plus der Teil des Schadens, den Ihre Agentur ihrem Kunden gegenüber erlitten hat und der auf uns fällt. Diese Klausel ist keine Einschüchterung; sie ist der externe Beweis unserer Kalender-Disziplin. Ein Technologie-Unternehmen, das eine so harte Klausel unterschreiben kann, ist gezwungen, mathematisch zu sein, wenn es ein Datum berechnet. Also liegt die Härte auf uns; die Bequemlichkeit auf Ihnen.
Die „Verzugsschadens"-Klausel in unserem Vertrag: Eine Regel, die automatisch greift

Ein Liefertermin ist kein Wort aus dem Herzen — sondern eine unterschriebene Zahl

Eine Verpflichtung, die durch Berechnung gebunden ist, nicht durch Glauben.

Was wir über die Jahre gesehen haben: In der Software fehlt es nicht an guten Absichten — sondern an Disziplin. Wenn ein Entwickler sagt „ich beende dieses Projekt in sechs Wochen", glaubt er das oft tatsächlich. Aber ein Datum ist nicht durch Glauben gebunden — sondern durch Berechnung. Deshalb entsteht bei Partnerfy ein Kalender zu Projektbeginn nicht aus der Absicht eines Senior-Engineers, sondern aus der Ausgabe einer Formel. Diese Formel führt die vergangene Velocity des Teams, die konkrete Zahl des Umfangs, die offenen Risiken und den Buffer zusammen. Die herauskommende Zahl schreiben wir in den Vertrag. Was sich für Sie ändert, ist eines: Der Satz „ich hoffe, es klappt" wird nicht mehr gehört — weder von uns noch von Ihnen zu Ihrem Kunden. Denn „klappt es?" ist keine Frage der Hoffnung mehr; es ist eine Frage der Mathematik. Und die haben wir bereits gelöst.

Kontaktieren Sie uns für einen mathematischen Kalender

Füllen Sie das Formular unten aus; wir führen ein kurzes Intake durch, um Umfang und Risiken Ihres Projekts zu verstehen. Am Ende dieses Intake haben Sie ein mathematisch berechnetes Lieferdatum in der Hand. Sie erreichen uns auch direkt unter 0850 259 30 04.

Bei Fragen können Sie uns jederzeit erreichen: [email protected]

Ihre Bewerbung ist eingegangen!

Wir prüfen Ihre Partnerschaftsbewerbung und melden uns unter so schnell wie möglich.

Welcher Firmentyp sind Sie?

Wobei benötigen Sie Unterstützung?

500
1 1.000

Geschätzter monatlicher Kundenzielwert (1 – 1.000)

Bölüm Tipi Seç

Eklemek istediğiniz bölüm tipini seçin

Eklendikten sonra Filament admin'den içeriği düzenleyebilirsiniz.

Treffer