Ein Briefing, das trägt

Warum das Briefing über das Angebot entscheidet

Ein Studio, das Ihr Projekt anbietet, schätzt Stunden. Wo Ihr Briefing klar ist, liegt die Schätzung nah. Wo es vage ist, muss das Studio raten, und jedes rät anders: Eines nimmt die einfachste Fassung an, um die Zahl niedrig zu halten, ein anderes die komplexeste, um sich abzusichern. Am Ende vergleichen Sie Vermutungen statt Preise.

Ein gutes Briefing beseitigt die Vermutungen. Es muss nicht lang sein und sollte nicht versuchen, die Software zu entwerfen. Es muss beschreiben, wer sie nutzen wird, was diese Menschen tun müssen, womit sie verbunden ist, welche Daten sie hält und unter welchen Rahmenbedingungen sie lebt. Diese Antworten entscheiden über die meisten Stunden und damit über den Großteil des Angebots.

Was ein gutes Briefing enthält

1. 01

   Das Problem, in einem Absatz

   Was heute schiefläuft, für wen, und was es Sie an Zeit, Fehlern oder verlorenem Geschäft kostet. Das lässt ein Studio eine einfachere Antwort vorschlagen, wenn es eine gibt.

2. 02

   Die Nutzer

   Jede Art von Person, die es nutzen wird: Kunden, Mitarbeitende, Führungskräfte, Administratoren, Partner. Für jede die drei bis fünf Dinge, die sie können muss.

3. 03

   Die Seiten

   Eine grobe Liste der Seiten oder Bildschirme. Sie muss nicht stimmen; sie muss existieren. Seiten sind die klarste Größeneinheit, die es gibt.

4. 04

   Die Anbindungen

   Jedes System, mit dem es sprechen muss: Buchhaltung, CRM, ERP, Zahlungsanbieter, E-Mail, Single Sign-on, die API eines Partners. Nennen Sie Produkt und Version, wenn Sie sie kennen.

5. 05

   Die Daten

   Was es speichert, ungefähr wie viel, ob etwas davon personenbezogen oder reguliert ist und ob bestehende Daten aus einem alten System übernommen werden müssen.

6. 06

   Die Plattformen

   Nur Web oder auch Apps für iOS und Android. Welche Browser und Geräte zählen. Ob es offline funktionieren muss.

7. 07

   Die Rahmenbedingungen

   Fristen, die echt sind (eine Startveranstaltung, ein Stichtag einer Vorschrift), und solche, die nur Wünsche sind. Anforderungen an das Hosting, etwa Daten in Kanada. Anforderungen an Barrierefreiheit und Sprachen.

8. 08

   Was schon existiert

   Designs, ein Markenleitfaden, ein altes System, ein Prototyp, Dokumentation. Jedes kann Arbeit sparen oder schaffen.

9. 09

   Nach dem Start

   Wer es betreibt, wer Nutzer unterstützt und ob Sie einen Supportplan wollen oder Ihr eigenes Team übernehmen soll.

10. 10

    Eine Budgetspanne

    Es fühlt sich wie ein Verhandlungsrisiko an, ist aber der schnellste Weg zu erfahren, ob Ihre Idee passt und was Sie kürzen sollten, wenn nicht. Ein gutes Studio sagt Ihnen, was darin realistisch ist.

Zählen Sie Seiten und Nutzer, nicht Funktionen

Funktionslisten sind die Stelle, an der Briefings schiefgehen. „Benutzerverwaltung“ kann eine Anmeldeseite heißen oder ein vollständiges System aus Rollen, Einladungen, Freigaben und Prüfprotokollen. Eine Liste von Nutzern und Seiten ist schwerer misszuverstehen, weil jede Seite gestaltet, gebaut und getestet werden muss und jeder Nutzertyp jeder Seite Berechtigungen hinzufügt.

Gut zwanzig Seiten und vier Nutzertypen, in fünf Minuten aufgeschrieben, sagen einem Studio mehr als drei Seiten Funktionsbeschreibungen. Wissen Sie nicht, ob etwas eine Seite oder zwei ist, sagen Sie das; das ist eine gute Frage für das erste Gespräch.

Nennen Sie jede Anbindung und jede Datenquelle

Anbindungen sind die Stelle, an der Schätzungen am häufigsten danebenliegen, weil das andere System außerhalb jeder Kontrolle liegt. Seine Dokumentation kann veraltet sein, seine Testumgebung kann fehlen, und seine Grenzen zeigen sich vielleicht erst im echten Einsatz. Ein Briefing, das jede Anbindung nennt, lässt ein Studio jede vor dem Angebot prüfen, statt sie im zweiten Monat zu entdecken.

• Nennen Sie das Produkt: „QuickBooks Online“ statt „unsere Buchhaltungssoftware“.
• Sagen Sie, in welche Richtung die Daten fließen: nur lesen, nur schreiben oder beides, und wie oft.
• Sagen Sie, ob Sie schon API-Zugang haben oder wer ihn gewähren müsste.
• Erwähnen Sie jede Datenmigration aus einem alten System, mit einer groben Zahl von Datensätzen und wie sauber sie Ihrer Meinung nach sind.

Nennen Sie die Rahmenbedingungen klar

Rahmenbedingungen verändern die Arbeit stärker als die meisten Funktionen, also schreiben Sie sie auf, selbst wenn sie selbstverständlich wirken.

• Barrierefreiheit: Ist die Software öffentlich, sagen Sie, welche Stufe Sie brauchen. Die Barrierefreiheitsrichtlinien des W3C legen die Stufen A, AA und AAA fest ^[1], und eine davon zu nennen macht aus einem vagen Wunsch eine Anforderung, die sich anbieten und testen lässt.
• Datenschutz: Enthält sie personenbezogene Daten, sagen Sie es. Kanadas PIPEDA beruht auf Grundsätzen fairer Informationspraxis wie Einwilligung, Begrenzung der Erhebung, Schutzmaßnahmen und individuellem Zugang ^[2]. Ihre Berater können Ihnen sagen, was gilt; das Studio muss wissen, dass es gilt.
• Regulierte Daten: Gesundheits-, Finanz- oder Behördendaten haben eigene Regeln. Erwähnen Sie sie im ersten Gespräch, nicht nach dem Angebot.
• Hosting: ob Daten in Kanada bleiben müssen, ob Sie einen bevorzugten Cloud-Anbieter haben oder ob es auf Ihren eigenen Servern laufen muss.
• Sprachen: Englisch und Französisch ab dem ersten Tag ist ein anderes Projekt als Englisch jetzt und Französisch später.
• Fristen: welche Termine fest sind, und warum.

Was Sie weglassen sollten

Ein Briefing ist weder ein Design noch eine technische Spezifikation, und der Versuch, eines zu schreiben, geht meist nach hinten los.

• Lassen Sie die Technik weg, außer sie ist eine echte Rahmenbedingung (Ihr Team betreibt schon einen bestimmten Stack, oder eine Aufsicht verlangt ein bestimmtes Hosting). Lassen Sie das Studio vorschlagen und seine Wahl erklären.
• Lassen Sie detaillierte Seitenentwürfe weg, außer Sie haben sie schon. Eine Skizze einer wichtigen Seite hilft; ein pixelgenaues Mock-up jeder Seite legt Entscheidungen fest, bevor jemand sie getestet hat.
• Lassen Sie Funktionen weg, bei denen Sie unsicher sind, oder führen Sie sie getrennt als „später“ auf. Ein mit Vielleichts aufgeblähtes Angebot ist schwerer zu vergleichen.
• Lassen Sie vertrauliche Details weg, die Sie noch nicht teilen müssen. Ein Studio kann nach der Form des Problems anbieten; es braucht keine Kundennamen oder Finanzergebnisse.

Ein Briefing, zu einer Schätzung gemacht

Das Buchungsportal aus der Tabelle oben, mit einer Web-App, Apps für iOS und Android, Kartenzahlungen, einer Anbindung an das Buchhaltungssystem des Kunden, Englisch und Französisch und personenbezogenen Daten, sieht in unserem Rechner so aus. Das durchgerechnete Beispiel unten zeigt die Spanne nach unserer heutigen Preisliste, mit den Stunden je Rolle und dem Zahlungsplan.

Öffnen Sie es im Rechner und ändern Sie eine Antwort nach der anderen: die mobilen Apps streichen, Echtzeitaktualisierungen ergänzen, auf ein sauberes Standarddesign wechseln. Zuzusehen, wie sich die Spanne bewegt, ist der schnellste Weg zu sehen, welche Teile Ihres eigenen Briefings am meisten zählen.

Dasselbe Briefing an mehrere Studios schicken

Mehr als ein Angebot einzuholen ist vernünftig, und ein schriftliches Briefing macht sie vergleichbar. Schicken Sie jedem Studio dasselbe Dokument, beantworten Sie die Fragen jedes Studios schriftlich und teilen Sie jede Antwort mit allen. Sonst bekommt das Studio, das die beste Frage gestellt hat, das genaueste Bild, und sein Angebot sieht schlechter aus, weil es ehrlich ist.

• Bitten Sie jedes Studio, die Annahmen hinter seiner Zahl aufzulisten, und vergleichen Sie diese vor den Summen.
• Fragen Sie nach den Stunden je Rolle, damit Sie sehen, ob Tests, Design und Projektmanagement enthalten sind.
• Fragen Sie, was ausgeschlossen ist: Hosting, Support, Drittgebühren, Inhalte und Datenmigration.
• Seien Sie vorsichtig bei einem Angebot, das weit unter den anderen liegt. Meist wurde ein Teil des Briefings anders gelesen oder weggelassen.

Eine einseitige Vorlage

• Projektname und ein Satz dazu, was es ist.
• Das heutige Problem, in einem Absatz.
• Nutzer: jeder Typ, mit den drei bis fünf Dingen, die er tun muss.
• Seiten: eine grobe Liste, nach Nutzer gruppiert.
• Anbindungen: jedes System, die Richtung der Daten und ob Zugang besteht.
• Daten: was gespeichert wird, ob es personenbezogen oder reguliert ist, und jede Migration.
• Plattformen: Web, iOS, Android, offline.
• Rahmenbedingungen: Fristen, Hosting, Barrierefreiheit, Sprachen, Compliance.
• Was existiert: Designs, Marke, alte Systeme, Dokumente.
• Nach dem Start: wer es betreibt und wer unterstützt.
• Budgetspanne, und was am meisten zählt, wenn nachgegeben werden muss.

Was passiert, nachdem Sie es geschickt haben

1. 01

   Fragen

   Wir lesen das Briefing und melden uns mit den Fragen, die es aufwirft, meist zu Anbindungen, Daten und Nutzerrollen.

2. 02

   Eine Schätzung mit ihren Annahmen

   Sie erhalten eine Spanne, die Stunden je Rolle und die Liste der Annahmen, auf denen sie beruht, sodass Sie genau sehen, was berechnet wurde.

3. 03

   Analysephase

   Machen Sie weiter, bestätigt die erste Phase Seiten, Anbindungen und Daten im Detail, und die Spanne verengt sich zu einem Festpreis für die Entwicklung.

4. 04

   Änderungen, berechnet vor der Arbeit

   Alles, was sich danach ändert, wird als Änderungsauftrag aufgeschrieben und freigegeben, bevor die Arbeit daran beginnt.