Deinen Anwendungsfall am System durchgehen

Was wir zeigen

Der Nutzen einer Demo entscheidet sich daran, ob am Ende jemand einordnen kann, was das System tut und was es nicht tut. Vier Dinge gehören dafür auf den Tisch.

Ein Auftrag von vorn bis hinten

Aus einem Anforderungstext wird ein Graph aus atomaren Arbeitsschritten, aus den Arbeitsschritten werden Commits, am Ende steht ein Repository. Das ist der Teil, den man einmal gesehen haben muss, um alles andere einzuordnen.

Wo ein Mensch eingreift

Welche Stelle auf jemanden wartet und welche durchläuft, lässt sich je Projekt einstellen. Ohne gesetzte Stufe läuft der Auftrag durch — das ist die Voreinstellung, und sie gehört in eine Demo, weil sie oft anders erwartet wird.

Was ein Lauf kostet

Wo die Kosten eines Laufs sichtbar werden und welche Deckel sich setzen lassen. Ohne gesetzten Betrag greift keiner — die Voreinstellung ist unbegrenzt, und genau darüber lohnt das Gespräch.

Gemietet oder selbst betrieben

Der Unterschied entscheidet, wem Betrieb und Daten gehören und wer die Schalter in der Hand hat. Vieles, was im betriebenen Dienst eingeschaltet ist, ist im Auslieferungszustand aus; welche Merkmale das sind, gehen wir durch.

Es gibt dafür kein Drehbuch. Was gezeigt wird, richtet sich danach, womit du kommst — deshalb der nächste Abschnitt.

Was du mitbringen solltest

Eine Demo wird in dem Moment brauchbar, in dem sie an deinem Fall hängt und nicht an unserem. Nichts davon ist Voraussetzung; alles davon macht das Gespräch kürzer und die Antworten konkreter.

Eine Anforderung, die du wirklich hast

Ein Ticket, ein Absatz aus einem Konzept, ein Stück Backlog. An einem echten Text zeigt sich, was die Zerlegung leistet und wo sie nachfragt — an einem erfundenen zeigt sich nur, dass er erfunden war.

Dein Arbeitsort

Planst und reviewst du in Tickets, in Pull-Requests oder in beidem? Davon hängt ab, an welcher Stelle sich das System in deinen Prozess einfügt, statt einen neuen zu verlangen.

Die Frage, die dich blockiert

Eine Sicherheitsprüfung, eine Betriebsanforderung, eine Frage zur Datenhoheit. Wenn sie vorher auf dem Tisch liegt, können wir die Antwort mit der Stelle zeigen, an der sie hängt — oder sagen, dass wir sie nicht haben.

Wer mitliest

Ob jemand aus Betrieb oder Sicherheit dabei ist, ändert, worüber wir sprechen. Beides ist recht; es hilft nur, es vorher zu wissen.

Dieselben Angaben helfen auch, wenn du aus einem anderen Anlass schreibst — dieKontaktseite fasst sie in einem Absatz zusammen.

Zugang und Tarifwahl

Für Zugang trägst du dich auf der Warteliste ein. Kläre vor der ersten Aufgabe die Kosten für Abo, Plattformverbrauch und externe Modellanbieter.

Auch ein bezahlter Tarif braucht dieses Gespräch nicht mehr: Abo und Guthaben bucht der Inhaber einer Organisation im Cockpit selbst, bezahlt wird über einen Zahlungsanbieter — diePreisseite beschreibt den Stand. Das Gespräch bleibt für das, was eine Kasse nicht beantwortet: Sicherheitsfragen, Betriebsart, Enterprise.

So meldest du dich

Schreib an hello@halvic.ch. Eine Zeile zu dem, was du baust, und eine zu dem, was du wissen willst, reichen als Anfang — der Rest ergibt sich aus dem, was oben steht.

Es gibt hier bewusst kein Buchungswerkzeug und keinen Kalender eines Fremdanbieters. Diese Website lädt nichts von fremden Servern nach und führt ausser der eigenen Navigation kein Skript aus; ein eingebetteter Terminkalender eines Fremdanbieters wäre beides auf einmal. Was du uns schreibst, schreibst du aus deinem eigenen Postfach an eine Adresse, die imImpressum steht.

Was auf dieser Seite bewusst fehlt, ist eine Zusage darüber, wie schnell wir antworten oder wie lange ein Termin dauert. Solche Sätze sind schnell geschrieben und binden ein Haus, nicht ein System: es gibt hier keinen Bereitschaftsdienst und keine zugesagte Erreichbarkeit, also steht auch keine Zahl da. Wir halten es lieber wie auf dem Rest dieses Auftritts — was nicht gedeckt ist, wird nicht behauptet.