Am laufenden System statt an Folien

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 ihr kommt — deshalb der nächste Abschnitt.

Was ihr mitbringen solltet

Eine Demo wird in dem Moment brauchbar, in dem sie an eurem 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 ihr wirklich habt

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.

Euer Arbeitsort

Plant und reviewt ihr in Tickets, in Pull-Requests oder in beidem? Davon hängt ab, an welcher Stelle sich das System in euren Prozess einfügt, statt einen neuen zu verlangen.

Die Frage, die euch 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 ihr aus einem anderen Anlass schreibt — dieKontaktseite fasst sie in einem Absatz zusammen.

Auch der Weg zu einem bezahlten Tarif

Wer nur ausprobieren will, braucht dieses Gespräch nicht: der freie Tarif steht ohne Umweg offen, und der Knopf „Kostenlos starten" auf den übrigen Seiten führt genau dorthin.

Für einen bezahlten Tarif ist es anders. Die Preisseite sagt es selbst: die Modell-Stufe setzt der Inhaber einer Organisation zwar in den Einstellungen selbst, eine Kasse zur Selbstbedienung gibt es im Cockpit aber noch nicht. Der Weg dorthin ist deshalb heute derselbe wie der zu einer Demo — eine E-Mail, ein Gespräch, danach die Einrichtung. Wir schreiben das hin, statt es hinter einem Knopf zu verstecken, der nichts auslöst.

So meldet ihr euch

Schreibt an hello@halvic.ch. Eine Zeile zu dem, was ihr baut, und eine zu dem, was ihr wissen wollt, 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 führt kein JavaScript aus und lädt nichts von fremden Servern nach; ein eingebetteter Terminkalender wäre beides auf einmal. Was ihr uns schreibt, schreibt ihr aus eurem 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.