Die meisten Texte zu dieser Frage sind für Projektleiter geschrieben und hören bei ein paar vagen Warnzeichen wieder auf. Dieser hier ist für die Person geschrieben, die das Projekt bezahlt und selbst nicht programmiert: fünf Prüfungen, die Sie an einem einzigen Nachmittag durchführen können, die schlichte Rechnung hinter einer ehrlichen Terminprognose und die Bandbreiten, die wir in echten Projekten tatsächlich sehen, bis hin zu dem Punkt, an dem die richtige Antwort lautet, den Bau zu beenden.
Warum Ihnen niemand eine klare Antwort zum Fortschritt gibt
Sie kennen den Moment vermutlich schon: Seit drei Monaten steht in jedem Bericht dieselbe Zahl, „etwa achtzig Prozent“, die Rechnungen kommen weiterhin pünktlich, und Sie haben keine Möglichkeit zu prüfen, ob an dieser Zahl irgendetwas dran ist. Sie fragen nach, bekommen eine freundliche Antwort mit vielen Wörtern, und legen mit demselben ungewissen Gefühl wieder auf. Das liegt selten daran, dass jemand Sie anlügt, sondern daran, dass „achtzig Prozent“ überhaupt keine Messgröße ist, sondern eine Stimmung.
Dahinter steckt ein Unterschied, den man von außen nicht erkennt, nämlich der zwischen Betrieb und Fortschritt. Betrieb ist alles, was nach Arbeit aussieht: Termine, Abstimmungen, Entwürfe, Bildschirme, an denen gerade jemand sitzt. Fortschritt ist etwas anderes, nämlich ein Stück des Systems, das ein echter Kunde heute benutzen könnte. Von außen fühlt sich beides identisch an, beides erzeugt Rechnungen, und nur eines davon ist Ihr Geld wert.
Damit die Erwartung von Anfang an stimmt: Fast jedes Projekt gerät irgendwann aus dem Tritt, das ist normal und gut zu überstehen, und ordentliche Teams fangen es wieder ein. Teuer wird nicht das Abweichen selbst, sondern der Zeitpunkt, zu dem Sie davon erfahren. Ein Rückstand von sechs Wochen, den Sie im zweiten Monat bemerken, kostet Sie ein unangenehmes Gespräch und eine Umplanung. Derselbe Rückstand, den Sie eine Woche vor dem geplanten Start entdecken, kostet Sie den Start.
Deshalb geht es hier nicht um Methoden und nicht um Werkzeuge. Sie bekommen Fragen, die jedes ehrliche Team gern beantwortet, und Rechnungen, die Sie mit einem Blatt Papier nachvollziehen können, ohne je gewusst zu haben, was eine Datenbank ist.
Der einzige Beweis, der zählt, ist Software, die Sie selbst anklicken können
Fangen wir mit dem Begriff an, den Sie dafür brauchen: die Testumgebung, im Fachjargon meist „Staging“ genannt. Das ist eine private Kopie Ihres Systems, im Internet erreichbar, für Kunden aber unsichtbar, auf der jeder Zwischenstand angesehen und ausprobiert werden kann, bevor er jemals echte Nutzer erreicht. Wenn es eine solche Kopie in Ihrem Projekt nicht gibt, ist das bereits der erste Befund, denn ohne sie bleibt Ihnen nichts außer dem Wort des Teams.
Damit lässt sich jede Prozentzahl durch eine einzige Regel ersetzen: Was Sie nicht auf Ihrem eigenen Handy öffnen und benutzen können, ist nicht fertig, egal was im Bericht steht. Die Regel klingt hart, aber sie ist der einzige Maßstab, der sich nicht schönreden lässt, und gute Teams mögen sie, weil sie damit umgekehrt auch beweisen können, dass es gut läuft.
Bei Linkysoft gilt in individuellen Entwicklungen deshalb ein fester Takt: einmal pro Woche eine Vorführung von dreißig bis fünfundvierzig Minuten, in der der Kunde selbst die Maus führt. Keine Folien, kein kommentiertes Video, sondern Sie klicken. Der Unterschied ist messbar, denn Sechsmonatsprojekte ohne diesen wöchentlichen Klicktermin laufen typischerweise fünfundzwanzig bis vierzig Prozent über die Zeit, aus sechs Monaten werden also siebeneinhalb bis achteinhalb. Mit wöchentlicher Vorführung und einer schriftlichen Änderungsliste bleibt derselbe Verzug in unseren Projekten meist unter zehn bis fünfzehn Prozent.
Dazu gehört ein gemeinsames Verständnis des Wortes „fertig“, und zwar vier Haken statt einer Meinung: gebaut, getestet, von Ihnen angesehen und freigegeben, und auf der Testumgebung lauffähig. Solange einer dieser vier Haken fehlt, ist das Stück in Arbeit und nicht fertig. Wie viel in einer individuellen Webanwendung wirklich steckt, wird weiter unten noch wichtig, weil der größere Teil davon in keiner Vorführung sichtbar ist.
Was ein echter Statusbericht enthält, und was ein vager verbirgt
Ein brauchbares Update besteht aus drei Teilen, und es ist erstaunlich, wie selten alle drei zusammen vorkommen. Erstens: Was ist seit dem letzten Mal fertig geworden und lässt sich anklicken? Zweitens: Woran wird gerade gearbeitet, und zu welchem Datum ist es klickbar? Drittens: Was ist blockiert, und wie heißt die Person, bei der es gerade liegt? Wenn diese drei Punkte in fünf Zeilen stehen, brauchen Sie keine Statusrunde von einer Stunde.
Genauso lehrreich ist die Sprache, die an die Stelle dieser drei Punkte tritt, wenn es nicht rund läuft. Achten Sie auf „fast fertig“, „so gut wie durch“, „nur noch Feinschliff“, „wir warten noch auf ein paar Dinge“, „es gab Probleme bei der Anbindung“ und auf jeden Satz, in dem kein einziges konkretes Hauptwort vorkommt. Keine dieser Formulierungen ist eine Lüge, aber jede ist eine Einladung, genau eine Frage mehr zu stellen: Was genau, bis wann, und bei wem liegt es?
Blockaden sollten Sie dabei nicht erschrecken, ganz im Gegenteil. Ein Team, das seine Hindernisse beim Namen nennt, weiß, wo es steht, während ein Team, das angeblich nie welche hat, sie in aller Regel nur nicht erzählt. Ihre Aufgabe ist nicht, Hindernisse zu verhindern, sondern sie schnell aus dem Weg zu räumen, und dafür müssen Sie sie überhaupt erst sehen.
Damit Sie im Zweifel nicht nach Worten suchen müssen, hier drei Fragen zum Kopieren in eine E-Mail:
- Welche Punkte sind seit dem letzten Bericht fertig geworden, und unter welchem Link kann ich sie selbst ausprobieren?
- Wie viele Punkte stehen insgesamt noch offen, und wie viele davon sind in den letzten vier Wochen fertig geworden?
- Was ist gerade blockiert, wer muss es auflösen, und bis zu welchem Datum?
Ein Team, das darauf innerhalb eines Tages sachlich antwortet, arbeitet gut. Ein Team, das darauf mit einem Termin für ein längeres Gespräch reagiert, verschiebt die Antwort, und auch das ist eine Information.
Fünf Prüfungen, die Sie diese Woche selbst machen können
Zusammen kosten die folgenden fünf Prüfungen etwa eine Stunde, und für keine davon brauchen Sie technisches Wissen. Machen Sie sie am besten in dieser Reihenfolge, weil jede die nächste vorbereitet.
1. Der Klicktest, zehn Minuten
Öffnen Sie die Testumgebung auf Ihrem eigenen Handy, nicht auf dem Rechner eines Entwicklers, und erledigen Sie eine vollständige Aufgabe von Anfang bis Ende, genau so wie ein Kunde es täte: Konto anlegen, Termin buchen, Ware in den Warenkorb legen und bezahlen. Notieren Sie, an welcher Stelle Sie stecken bleiben. Wenn Sie keine einzige Aufgabe durchgängig erledigen können, ist das Projekt unabhängig von jeder Prozentangabe in einem früheren Stadium, als der Bericht behauptet.
2. Der Test der Änderungsliste, fünfzehn Minuten
Bitten Sie um die schriftliche Aufstellung aller Änderungswünsche seit Projektbeginn, jeweils mit den Tagen, die sie zusätzlich gekostet haben. Gibt es diese Liste nicht, kann der Terminplan gar nicht stimmen, denn die Zeit ist ja irgendwo hingegangen, und ohne die Liste weiß niemand mehr wohin. Diese eine Datei ist im Streitfall übrigens auch Ihr bester Schutz, weil sie zeigt, welcher Verzug aus Ihrem Haus kam und welcher nicht.
3. Der Test des Fehlerbuchs, zehn Minuten
Fragen Sie nach zwei Zahlen: Wie viele Fehler und offene Punkte sind heute offen, und wie viele waren es vor einem Monat? Die absolute Höhe sagt wenig, denn achtzig offene Punkte in einem großen System können völlig normal sein. Was zählt, ist die Richtung, und wenn niemand die Zahl von vor einem Monat nennen kann, wird nicht mitgeschrieben.
4. Der Test Umfang gegen Rechnung, zwanzig Minuten
Legen Sie die ursprüngliche Funktionsliste neben die Summe, die Sie bisher gezahlt haben, und zählen Sie ausschließlich die Funktionen, die Sie anklicken können. Alles, was „in Arbeit“ ist, zählt in dieser Rechnung als null, weil es das für Ihr Geschäft heute auch ist. Die beiden Prozentzahlen, die dabei herauskommen, sind der ehrlichste Projektbericht, den Sie bekommen werden.
5. Der Zwei Personen Test, fünf Minuten
Fragen Sie zwei verschiedene Mitglieder des Teams unabhängig voneinander, was in der nächsten Woche ansteht. Kommen zwei verschiedene Antworten zurück, existiert der Plan nur im Kopf einer einzigen Person, und Ihr Projekt hängt damit an deren Anwesenheit, Laune und Kalender. Das ist kein Vorwurf an das Team, sondern ein Risiko, das sich mit einer geteilten Aufgabenliste an einem Nachmittag beseitigen lässt.
Wenn Sie an dieser Stelle wissen möchten, wie viel Prüfaufwand in einem gesunden Projekt eigentlich normal ist, finden Sie in unserem Blog weitere Beiträge zum Thema Tests, die genau diese Frage in Zahlen beantworten.
Die Terminrechnung, die jeder selbst machen kann
Hören Sie auf, Prozente zu zählen, und fangen Sie an, Stücke zu zählen. Die Frage lautet: Wie viele Dinge sind in den letzten vier Wochen wirklich fertig geworden, also klickbar? Diese Zahl geteilt durch vier ist die tatsächliche Wochenleistung Ihres Teams, ganz gleich, was der Plan behauptet, und sie ist die einzige Geschwindigkeit, mit der Sie rechnen dürfen.
Rechnen wir ein Beispiel langsam durch. Angenommen, Ihr Projekt besteht aus sechzig Punkten auf der Funktionsliste, von denen fünfundzwanzig fertig und klickbar sind, und in den letzten vier Wochen sind zwölf Punkte dazugekommen, also drei pro Woche. Damit bleiben fünfunddreißig Punkte übrig, und fünfunddreißig geteilt durch drei ergibt rund zwölf Wochen, während im Plan noch sechs stehen. Niemand hat gelogen, aber der Plan beschreibt eine Geschwindigkeit, die dieses Team in diesem Projekt noch nie erreicht hat.
Diese Rechnung müssen Sie danach noch um die Kapazität korrigieren. Eine Person, die als „Vollzeit“ im Projekt geführt wird, liefert in einer Vierzigstundenwoche realistisch fünfundzwanzig bis dreißig nutzbare Stunden, sobald man Besprechungen, gegenseitige Durchsichten, Support für ältere Projekte und das ständige Umschalten zwischen Aufgaben abzieht. Ein Plan, der mit vierzig Stunden rechnet, ist damit schon vor dem ersten Problem im besten Fall um fünfundzwanzig und am anderen Ende dieser Spanne um fast vierzig Prozent zu optimistisch.
Und dann ist da noch die Neunzig Prozent Falle, die Sie am besten in Tagen betrachten. Eine Funktion, die mit neunzig Prozent gemeldet wird, braucht typischerweise noch einmal zwanzig bis vierzig Prozent ihrer ursprünglichen Schätzung, bis sie wirklich fertig ist. Bei einer Funktion, die auf zehn Tage geschätzt war, sind das zwei bis vier weitere Tage und nicht der halbe, den man bei neunzig Prozent erwartet. Der Grund ist banal: Was am Ende fehlt, ist nicht die Funktion selbst, sondern ihre Verbindung zu allem anderen, die Sonderfälle und das Testen, und genau dieser Rest ist der langsamste Teil der ganzen Arbeit.
Die Arbeit, die Sie nicht sehen, und warum die Bildschirme nur ein Drittel sind
Bei einer typischen individuellen Webanwendung machen die Bildschirme, die Sie anklicken können, etwa fünfunddreißig Prozent des Gesamtaufwands aus. Rund fünfundzwanzig Prozent stecken in Regeln, Berechtigungen und Anbindungen an andere Dienste, achtzehn Prozent in Testen und Beheben, zwölf Prozent im Übernehmen der alten Daten und zehn Prozent in Start, Absicherung und Übergabe. Diese Zahlen sind keine Ausrede, sondern eine Landkarte, damit Sie wissen, wo Ihr Geld hingeht.
Im Klartext heißt unsichtbare Arbeit: Wer darf was sehen und ändern, wie hängt das System an Zahlung, Versand oder Buchhaltung, wie kommen zwanzigtausend alte Kundendatensätze sauber in das neue System, was passiert bei einem Zahlungsabbruch mitten im Vorgang, wie wird getestet, wie wird abgesichert, wie werden Sicherungskopien angelegt und wie geht das Ganze schließlich live. Nichts davon lässt sich in einer Vorführung zeigen, und alles davon entscheidet, ob Sie am Ende ein System haben oder nur eine Sammlung schöner Seiten.
Für Sie folgt daraus eine ziemlich brauchbare Faustregel: Freigegebene Entwürfe bedeuten, dass ungefähr ein Drittel der Arbeit hinter Ihnen liegt. Ein Projekt, das zum Zeitpunkt der fertigen Bildschirme die Hälfte des Budgets verbraucht hat, ist völlig in Ordnung. Ein Projekt, das an derselben Stelle bei achtzig Prozent des Budgets steht, ist es nicht, weil der teuerste Teil dann noch komplett vor Ihnen liegt.
Besonders unsichtbar ist der Anteil für Absicherung und Sicherheit, der zusammen mit Start und Übergabe in jenen zehn Prozent steckt. Rechteprüfungen, verschlüsselte Verbindungen, sichere Passwortverfahren, Sperren gegen automatisierte Angriffe und geprüfte Sicherungskopien sieht man in einer Vorführung eben nicht, weil sie im Erfolgsfall genau nichts tun. Bezahlt werden sie trotzdem, und gestrichen werden sie in Projekten unter Druck oft als Erstes, was der teuerste Fehler von allen ist.
Wo Projekte ihre Wochen wirklich verlieren, und das ist selten der Code
Wenn ein Sechsmonatsprojekt etwa zwei Monate zu spät fertig wird, verteilen sich die zusätzlichen Wochen fast immer nach demselben Muster: rund zweieinhalb Wochen Warten auf Entscheidungen des Kunden, zwei Wochen für Umfang, der mitten im Bau dazukam, anderthalb Wochen für externe Dienste wie einen Zahlungsanbieter, eine Bank oder ein Behördenportal, anderthalb Wochen für unterschätztes Testen und eine Woche, weil eine Schlüsselperson nicht verfügbar war. Der eigentliche Bau der Software taucht in dieser Liste gar nicht auf.
Der größte Posten sitzt also auf Ihrem eigenen Schreibtisch, und das sagen wir ohne Vorwurf, sondern weil es die gute Nachricht ist. Ein normales Projekt braucht zwölf bis zwanzig Entscheidungen vom Auftraggeber, von der Rückgabefrist über die Rabattlogik bis zur Frage, wer eine Rechnung stornieren darf. Die meisten dieser Wartezeiten kosten nichts, weil das Team in der Zwischenzeit an etwas anderem arbeitet, und teuer werden nur die wenigen Entscheidungen, die den nächsten Arbeitsschritt anhalten: schon zwei oder drei davon, die jeweils eine Arbeitswoche liegen bleiben, ergeben die zweieinhalb Wochen aus der Aufstellung oben, während das Entwicklungsteam nicht das Geringste falsch macht. Dieser Teil gehört Ihnen vollständig, und deshalb können Sie ihn auch vollständig abstellen.
Der zweitgrößte Posten ist der Umfang, und auch hier ist die Nachricht milder, als Sie denken. Dass sich der Umfang über ein Viermonatsprojekt hinweg um fünfzehn bis dreißig Prozent verändert, ist normal und oft sogar gesund, weil Sie unterwegs schlauer werden als am Tag der Unterschrift. Ungesund ist nur, eine Änderung anzunehmen, ohne schriftlich festzuhalten, wie viele Tage sie kostet und um welches Datum sie den Start verschiebt. Wir sehen bei Linkysoft regelmäßig Projekte, in denen nicht der Umfang das Problem war, sondern die zwölf kleinen Zusagen, die nie jemand aufgeschrieben hat.
Die Gegenmaßnahme kostet nichts und dauert zehn Minuten pro Woche: eine schriftliche Entscheidungsliste, jede Zeile mit der offenen Frage, dem Namen der Person, die entscheidet, und dem Datum, bis zu dem entschieden sein muss. Diese Liste gehen Sie in derselben wöchentlichen Sitzung durch, in der auch die Vorführung stattfindet. Mehr Steuerung braucht ein Projekt dieser Größe nicht.
Signale, die etwas bedeuten, und Rauschen, das nichts bedeutet
Weil sich beides ähnlich anfühlt, hier zuerst das Rauschen, über das Auftraggeber unnötig in Panik geraten: ein verpasstes Datum bei einer einzelnen Funktion, ein hässlicher Zwischenstand auf einem Bildschirm, ein Entwickler, der eine Woche Urlaub nimmt, eine rohe Verwaltungsseite, die außerhalb Ihres Büros ohnehin niemand zu sehen bekommt. Nichts davon sagt etwas über den Zustand des Projekts aus, und wer daraus eine Krisensitzung macht, verbrennt genau die Zeit, die er gerade retten wollte.
Ernst nehmen sollten Sie dagegen die folgenden Punkte:
- Zwei Vorführungen hintereinander, in denen es nichts Neues zu klicken gibt.
- Die Zahl der offenen Fehler steigt drei Wochen in Folge.
- Der plötzliche Vorschlag, größere Teile noch einmal von vorn zu bauen.
- Die Bedeutung des Wortes „fertig“ verschiebt sich still und leise.
- Es wird ruhig, die Berichte kommen später, kürzer und unbestimmter.
Die Fehlerzahlen lassen sich dabei zu einer Regel verdichten, die Sie ohne jede Erklärung anwenden können. In den sechs Wochen vor dem Start schließt ein gesundes Projekt mehr Punkte, als neue dazukommen, und zwar drei Wochen hintereinander. Steigt die Liste der offenen Punkte stattdessen drei Wochen in Folge, hat sich der Starttermin bereits verschoben, ob das jemand ausgesprochen hat oder nicht. Diese eine Zahl ersetzt jede Diskussion über Gefühle.
Das gilt besonders für alles, was still gestrichen wird, wenn ein Projekt unter Druck gerät, und ganz oben auf dieser Streichliste stehen Tests und Absicherung. Wenn Sie sehen möchten, was dabei konkret auf dem Spiel steht, lohnt ein Blick in unsere Beiträge zum Thema Sicherheit, bevor jemand vorschlägt, diesen Teil „nach dem Start nachzuholen“.
Das Geld gegen die gelieferte Arbeit lesen
Die Budgetprüfung besteht aus einer einzigen Zeile: Vergleichen Sie den Anteil des ausgegebenen Geldes mit dem Anteil der Funktionen, die Sie anklicken können. Stehen siebzig Prozent Ausgaben gegen vierzig Prozent klickbare Funktionen, müssen die verbleibenden dreißig Prozent des Budgets noch sechzig Prozent der Arbeit tragen, und das werden sie nicht. Diese Rechnung dauert fünf Minuten und ist ehrlicher als jeder Statusbericht, weil beide Zahlen aus Quellen stammen, die niemand beschönigen kann.
Damit Sie in diese Lage gar nicht erst kommen, koppeln Sie Zahlungen an Ergebnisse statt an Kalendermonate. Ein Meilenstein, der „Ende März“ heißt, bezahlt vergangene Zeit. Ein Meilenstein, der „Kunden können sich registrieren, anmelden und ihre Bestellungen sehen, auf der Testumgebung“ heißt, bezahlt Fortschritt. Wie sich echte Projekte in solche zahlbaren, benutzbaren Stufen zerlegen lassen, sehen Sie an den Beispielen in unseren Fallstudien, in denen jede Stufe etwas enthält, das der Kunde selbst öffnen konnte.
Und rechnen Sie von Anfang an damit, dass ein Projekt mit dem Start nicht endet. Für Betrieb, Aktualisierungen, Sicherheitsaktualisierungen und kleine Änderungen sollten Sie jedes Jahr fünfzehn bis zwanzig Prozent der Baukosten einplanen. Wer diesen Posten vergisst, steht später ohne Budget für ein System da, das dann genau in dem Moment ins Rutschen kommt, in dem es endlich Geld verdient.
Sie liegen hinter dem Plan. Was jetzt?
Es gibt genau vier Hebel, und jede Lösung, die Ihnen jemand vorschlägt, ist eine Kombination daraus: Umfang kürzen, Termin verschieben, Geld nachlegen oder aufhören. Sobald Sie das einmal so nüchtern vor sich sehen, wird das Gespräch mit dem Team deutlich einfacher, weil es nicht mehr um Schuld geht, sondern um die Wahl zwischen vier Möglichkeiten.
Vom Nachlegen von Personen sollten Sie sich dabei am wenigsten versprechen, denn es ist der langsamste der vier Hebel. Ein neuer Mensch im Projekt bedeutet, dass diejenigen, die gerade bauen, zwei bis vier Wochen lang vor allem erklären, und erst danach liefert die neue Kraft überhaupt etwas zurück. Ein spätes Projekt wird durch zusätzliche Leute zuerst noch langsamer, und wenn nur noch sechs Wochen zu retten sind, kommt der Gewinn schlicht zu spät.
Die beste Antwort ist meistens eine andere, nämlich eine kleinere erste Fassung. Sechzig Prozent des Umfangs, dafür drei Monate früher live, bringt echte Kunden, echtes Feedback und echte Einnahmen, und diese Einnahmen bezahlen den Rest. Die Erfahrung dabei ist fast immer dieselbe: Einen Teil der gestrichenen vierzig Prozent will nach einigen Wochen echter Nutzung niemand mehr haben, dafür fällt Ihnen anderes ein, das auf keiner ursprünglichen Liste stand.
Was Sie in jedem Fall brauchen, ist eine saubere Neuplanung, und die passt auf eine Seite: neues Datum, neuer Umfang, was sich geändert hat, warum es sich geändert hat, und beide Seiten setzen ihre Unterschrift darunter. Eine Neuplanung, die nur mündlich stattfindet, ist keine Neuplanung, sondern die nächste stille Verschiebung, und die kostet Sie in drei Monaten dasselbe Gespräch noch einmal.
Bleibt der vierte Hebel, das Aufhören, und damit es sich nicht wie ein Scheitern anfühlt, hier die Zahlen dahinter. Ein stehen gebliebenes oder abgebrochenes Projekt später von einem anderen Team übernehmen zu lassen, kostet typischerweise vierzig bis siebzig Prozent eines Neubaus, und allein drei bis sechs Wochen davon gehen dafür drauf, überhaupt zu verstehen, was bereits existiert. Genau deshalb ist es fast immer günstiger, ein falsches Projekt früh zu beenden, als es bis zum Start durchzudrücken.
Wenn die kleinere und günstigere Lösung die ehrliche Antwort ist
Manchmal liegt das Problem nicht in der Steuerung, sondern in der Entscheidung, überhaupt zu bauen, und dann hilft eine Rechnung, die Sie laut aussprechen sollten. Ein fertiges Werkzeug aus dem Regal kostet dreißig bis achtzig Euro im Monat, also dreihundertsechzig bis neunhundertsechzig Euro im Jahr. Eine individuelle Entwicklung beginnt üblicherweise zwischen achttausend und fünfundzwanzigtausend Euro, dazu jedes Jahr fünfzehn bis zwanzig Prozent davon für den Unterhalt. Der Unterschied ist so groß, dass die individuelle Lösung einen echten Grund braucht, nicht nur eine Vorliebe.
Drei Gründe halten dieser Prüfung erfahrungsgemäß stand. Erstens ein Arbeitsablauf, den kein Produkt am Markt abbildet, weil er der Grund ist, warum Ihr Geschäft anders funktioniert als das der Wettbewerber. Zweitens Daten, die Sie aus rechtlichen oder vertraglichen Gründen selbst halten müssen. Drittens Nutzergebühren, die mit Ihrem Wachstum so stark steigen, dass sie die Baukosten irgendwann überholen, was sich in einer Tabelle über drei Jahre in zwanzig Minuten nachrechnen lässt.
Trifft keiner dieser drei Gründe zu, sagen wir das auch. Linkysoft lehnt Anfragen ab oder verkleinert sie deutlich, wenn ein fertiges Werkzeug oder eine schlankere Umsetzung die bessere Wahl ist, denn ein System, das gar nicht hätte gebaut werden sollen, liegt nie im Plan, egal wie gut es geführt wird. Für viele Vorhaben reicht eine gut gemachte Website mit sauberer Umsetzung völlig aus, und wenn Sie die Zahlen dahinter vergleichen möchten, helfen unsere Beiträge zum Thema Budget beim Rechnen.
Wenn Sie ab Montag nur drei Gewohnheiten mitnehmen, dann diese: jede Woche eine Vorführung, in der Sie selbst klicken, einmal im Monat ein neues Auszählen der verbleibenden Punkte samt der daraus folgenden Wochenzahl, und einmal im Quartal die nüchterne Frage, ob das System mehr einbringt, als es kostet. Damit haben Sie mehr Kontrolle über Ihr Projekt als die meisten Auftraggeber, ohne eine einzige Zeile Programmcode zu verstehen. Und falls Sie eine zweite Meinung zu einem laufenden Vorhaben möchten, bevor daraus ein größeres Problem wird, schreiben Sie uns: Wir sehen uns Ihre Zahlen an und sagen Ihnen, was wir an Ihrer Stelle tun würden, auch wenn die Antwort lautet, nichts weiter zu bauen.
