- In frühen Geschäftsphasen mit häufigen Veränderungen ist es klug, Probleme zunächst mit der einfachsten Lösung schnell zu lösen und bei erkennbaren Grenzen die Anforderungen neu zu bewerten und dann zu ersetzen oder zu ergänzen
- Google Sheets ist in einem sich schnell verändernden Umfeld ein wirksames Mittel zur Problemlösung und bietet gegenüber der Entwicklung komplexer Tools Vorteile bei der tatsächlichen Nutzbarkeit und der Vermeidung von Verschwendung
- Der Autor blickt darauf zurück, in der Praxis zu schnell dedizierte Systeme statt allgemeiner Werkzeuge gebaut und dabei die Unsicherheit des Scopes übersehen zu haben, was Zeit verschwendete
- Der Kernansatz lautet: mit der kleinsten und einfachsten Lösung beginnen → den Scope durch echte Arbeit verstehen → bei Bedarf schrittweise verbessern – eine Strategie des kleinen Starts und der Iteration
- Allerdings lässt sich nicht jedes Problem mit Tabellen lösen; angemessen ist ihr vorübergehender Einsatz, bis der Scope sichtbar wird, und wichtig ist eine kluge Auswahl passend zum organisatorischen Kontext
Die einfachste Wahl zur Problemlösung
- Bei jedem Problem ist es wichtig, zuerst die am leichtesten anwendbare Lösung zu wählen
- Wenn diese Methode nicht mehr zum Geschäft passt, braucht es einen Ansatz, die bestehende Lösung entsprechend neuer Anforderungen zu verbessern oder nach Alternativen zu suchen
- In dem Umfeld, das der Autor erlebt hat, war es in den meisten Fällen die beste Vorgehensweise, ein neues Google Sheet zu erstellen
Schnelllebiges Startup-Umfeld und der Nutzen von Tools
- Etwa vor 9 Monaten trat er seinen Job an, doch die Vorfreude darauf, neue Tools und Services für ein kleines Unternehmen in der Anfangsphase zu bauen, verflog
- In einem Umfeld, in dem sich die Geschäftsrichtung alle 2 Monate änderte, wurden viele Projekte begonnen und dann wieder aufgegeben
- In vielen Fällen investierte man Zeit und Aufwand in unnötig komplexe Projekte, obwohl sich das Problem leicht mit einem Google Sheet hätte lösen lassen
Beispiele für Zeitverschwendung
-
Admin-Panel für Frachtmanagement
- 2 Monate Aufwand für Entwurf und Entwicklung eines Admin-Panels zur Verwaltung und Nachverfolgung eingehender Fracht für das Geschäft
- Ziel war es, Paket- und Kundendaten zu kategorisieren und besser zu verwalten
- Dieses Admin-Panel wurde zweimal benutzt und danach nie wieder
- Es hätte sich leicht durch ein Google Sheet ersetzen lassen und wird dafür aktuell auch genutzt
-
MVP zur automatischen Zollberechnung
- 3 Wochen Aufwand für ein MVP eines Angebotsystems, das bei der Bestellung bestimmter Produkte Zoll und Steuern automatisch berechnet
- Da Steuern und Zölle in Simbabwe sehr komplex sind, könnte man den Customer Journey verbessern, wenn Kundinnen und Kunden den exakten Zahlbetrag kennen, und den Prozess beschleunigen, weil nicht auf Antworten eines Drittanbieters für Zollabwicklung zu jeder Anfrage gewartet werden muss
- Am Ende wurde die Steuer- und Zollklassifikation eines Wettbewerbers angesehen und in ein Google Sheet kopiert und dort genutzt
-
Auswahlprozess für ein CRM
- 2 Monate Aufwand für Recherche, Meetings (jeweils über 1 Stunde) und Suchen nach einem guten CRM für das Unternehmen
- Funktionen und Preise verschiedener CRM-Systeme wurden verglichen und analysiert
- Am Ende entschied man sich für die kostenlose Version von Oddo, die im Unternehmen jedoch kaum genutzt wurde
- Überraschenderweise stellte sich vor einigen Wochen heraus, dass in Google Sheets bereits eine CRM-Vorlage integriert ist
Prinzipien des Google-Sheets-Ansatzes
- Ein Google Sheet zu erstellen ist nicht für jedes Problem die beste Lösung, aber in der Situation des Autors oft schon
- Häufig befindet man sich in einer Lage, in der man den vollständigen Umfang des Problems vor Beginn der eigentlichen Arbeit nie kennen kann
- Das bedeutet nicht, dass Projekte nicht geplant werden sollten
- Das Team sollte Workflows und benötigte Informationen besprechen, aber den vollständigen Umfang des Problems kennt man erst, wenn die eigentliche Arbeit beginnt
- Sobald der gesamte Umfang des Problems sichtbar ist, kann man beginnen, eine passende Lösung zu bauen oder die vorhandene zu verbessern
- Im besten Fall hilft dieser Ansatz, Zusatzaufwand für Funktionen zu vermeiden, die man nicht braucht, und im schlechtesten Fall verhindert er, Zeit in ein Projekt zu investieren, das scheitern wird
- Um den vollständigen Umfang des Problems zu verstehen, war es bisher am besten, mit der kleinsten, einfachsten und grundlegendsten Lösung zu starten und danach bei Bedarf zu iterieren
Grenzen und worauf man achten sollte
- Dieser Ansatz hat auch Nachteile; in manchen Organisationen werden zum Beispiel alle Transaktionen und Informationen in Tabellen mit Tausenden von Zeilen erfasst
- Google Sheets ist nur nützlich, bevor der vollständige Umfang des Problems erkannt wurde
- Man braucht Erfahrung und Urteilsvermögen dafür, welche Probleme sich mit einem Google Sheet lösen lassen
- Im Vordergrund sollte stehen, keine Zeit zu verschwenden und Tools zu entwickeln, die tatsächlich genutzt werden können
- Allerdings ist das kein Rat, der für alle gilt, deshalb sollte jede Person je nach eigener Situation sorgfältig abwägen
Fazit
- Mit dem geringstmöglichen Aufwand und der einfachsten Lösung zu beginnen und nur bei Bedarf zu erweitern oder auszubauen, ist eine sehr geeignete Strategie für Startups oder Umfelder mit vielen Veränderungen
- Persönliche Entwicklungsexperimente kann man frei betreiben, aber im Geschäft ist es wichtig, nur das wirklich Nötige zu bauen und keine Zeit und Energie auf Unnötiges zu verwenden
3 Kommentare
Ich stimme im Grunde auch zu, aber im Moment nutze ich für die anfängliche Baseline lieber Notion Database als Google Sheets. Es ist ähnlich, aber letztlich richtet sowieso nur eine Person das Template ein. Wenn andere dann auf dieser Grundlage die Daten verwalten, lässt sich ein chaotischer Zustand vermeiden. Es ist zwar App Script unterlegen, aber Automatisierungen lassen sich etwas einfacher umsetzen. Der Schwierigkeitsgrad beim initialen Setup ist vielleicht ein ganz kleines bisschen höher, aber nicht wesentlich, und bei Dingen wie Flexibilität scheint es ähnlich zu sein. Außerdem ist inzwischen sogar eine Rechteverwaltung auf Zeilenebene möglich, also gut.
Ich denke, dass Notion gut ist, weil die Lernkurve niedrig ist.
Hacker-News-Kommentare
Das wird immer übersehen. Tabellenkalkulationen vereinen an einem Ort eine Datenbank, eine schnelle und einfach anpassbare UI sowie eine iterative und leicht zu debuggende Umgebung für Datenverarbeitung. Es ist ein Tool, das praktisch alle Angestellten weltweit bereits verstehen und benutzen, und es gibt den Erstellern die Freiheit, Dinge so umzusetzen, wie sie wollen. Auch die Portabilität ist hervorragend. Ich bin überzeugt, dass es gerade für Menschen, die nicht programmieren können, ein besonders kreatives und mächtiges Werkzeug ist. Natürlich hat diese Freiheit auch Nachteile, aber unabhängig von Debatten darüber, ob alles online sein sollte oder welcher Vendor besser ist, hat meine tiefe Zuneigung zu Tabellenkalkulationen kein bisschen nachgelassen. Ich halte sie für das beste Authoring-Tool, das wir je gebaut haben. Ein vergleichbares Modell ist für mich HyperCard. Es war eine flexible Werkbank, mit der sich verschiedenste Apps, Daten und UX miteinander verknüpfen ließen. Ich wünschte, HyperCard würde für immer in Erinnerung bleiben
Stimmt, die Einstiegshürde bei Tabellenkalkulationen ist wirklich niedrig. Ich erfasse sogar mitten auf dem Feld per Handy Wachstumsdaten meiner Pflanzen in Google Sheets. Selbst bei schwachem Empfang speichere ich das im Offline-Modus und synchronisiere es später zu Hause. Auch wenn die Aufzeichnungen chaotisch sind, ist das immer noch viel besser als gar nichts. Landwirtschaft braucht viele Daten, lebt aber überraschenderweise in einer datenarmen Umgebung. Der Lernzyklus ist ein Jahr lang, und jedes Jahr ist anders
Für Leute, die programmieren können, macht Appscript Tabellenkalkulationen fast zu einer Superkraft. Falls das jemand nicht weiß: Man muss für Google Sheets nicht einfach nur JS in der eingebauten Web-IDE schreiben (wobei selbst das ziemlich brauchbar ist). Mit
claspkann man in einer lokalen IDE mit Typescript entwickeln, im Build-Prozess nach JS kompilieren und direkt in die Tabellenkalkulation deployen. Wenn die Toolchain einmal eingerichtet ist, ist auch die Developer Experience (DX) ziemlich ordentlichStimme stark zu. Der Wert einer Werkbank, in der Datenbank + UX + Logik in einem integriert sind, ist der Kern der Apps, die wir immer wieder neu bauen. Deshalb wird auch Visual Basic weiterhin benutzt. Natürlich ist das nicht die beste Methode, sobald die Richtung klar feststeht, aber um schnell zu iterieren und die echten Anforderungen herauszufinden, ist es kaum zu übertreffen
Ich fände es gut, wenn es einen besseren Weg gäbe, Tabellenkalkulationen als Datenbank-Backend zu nutzen. Ein großer Teil dessen, was die meisten Menschen mit Tabellenkalkulationen machen, wäre in einer Datenbank besser aufgehoben. Aber Datenbanken erfordern mehr Schulung, und bei unzureichender Schulung können die Ergebnisse sogar schlechter ausfallen als mit Tabellenkalkulationen
Ich habe mich immer gefragt, warum es keinen realistischen Migrationspfad gibt, um schrittweise von Tabellenkalkulationen zu einer vollwertigen Datenbank mit Custom UI zu wechseln. Tabellenkalkulationen stehen direkt vor dieser Rolle, und mit ein paar essenziellen Funktionen (strukturierte Daten, natives SQL, Custom-UI-Elemente, IDE-Integration usw.) müsste das eigentlich möglich sein
Das erinnert mich an den Beitrag "Ask HN: Is the world run by badly updated Excel sheets?". Um die Grenzen von Tabellenkalkulationen wirklich selbst zu erleben, braucht man Erfahrung. Es gibt keine Versionsverwaltung, keine Tests. Für unveränderliche und kurzlebige Aufgaben sind sie gut, aber wenn sich etwas laufend weiterentwickeln muss, wird es problematisch. Siehe https://news.ycombinator.com/item?id=33611431. In dem Thread gab es diesen Kommentar: Am Ende passt sich im Unternehmen jeder der Arbeitsweise des Excel-Eigentümers an. Wenn es einem nicht gefällt, macht man eben selbst eine neue Excel-Datei und kopiert alles hinein, also verwaltet es jeder selbst. Ein Projektmanager, den ich kenne, verbrachte seinen Alltag damit, unterschiedliche Spreadsheet-Versionen verschiedener Autoren aufeinander abzustimmen
Als ich in den 2000er-Jahren in den USA als Coder anfing, dachte ich, mein Job bestehe darin, Tabellenkalkulationen auf Windows-Netzlaufwerken, um die sich ständig jemand liebevoll kümmern musste, in Web-Apps umzuwandeln. Trotzdem laufen noch immer viele Unternehmen erstaunlich gut auf Basis von Tabellenkalkulationen. Irgendwann kommt das Skalierungsproblem, und dann muss man auf eine App umsteigen, aber besser etwas fertig bekommen als vor lauter Perfektionsanspruch gar nichts zu liefern
Es hieß, es gebe „keine Versionsverwaltung“, aber tatsächlich hat auch Excel Versionsverwaltungsfunktionen. Mit „Änderungen nachverfolgen“ kann man Änderungen anderer annehmen oder ablehnen. Nur benutzen Leute, die ihre Arbeit mit Rube-Goldberg-artiger Spreadsheet-Automatisierung erledigen, diese Funktion fast nie. Wenn man sie braucht, ist sie da
Ich habe oft gesehen, dass Probleme entstehen, wenn Informationen über mehrere Tabellenkalkulationen verstreut sind. Die Beteiligten wissen dann häufig nicht, in welcher Datei welche Information steckt und welche die maßgebliche ist. Dann aktualisiert jemand nur Datei A, ohne dass andere es merken, während jemand anderes nur an B arbeitet — solche Konflikte passieren ständig. Das Problem lag weniger an der eigentlichen Software oder den Daten als an der Art, wie die Dateien im Projekt verwaltet wurden. Komplexe Shared Folders, irgendwo im Netzwerk liegengelassene Dateien — ein regelrechtes Verwaltungs-Labyrinth
Ich stimme dem Rat zu: „Nutze zur Problemlösung immer den einfachsten Weg, und wenn dieser Weg nicht mehr zum Geschäft passt, verbessere ihn entsprechend den neuen Anforderungen oder suche eine alternative Lösung.“ Man sollte sich darauf konzentrieren, das aktuelle Problem zu lösen; über mögliche oder gewünschte künftige Probleme im Voraus zu grübeln, trifft selten ins Schwarze. Die aktuelle Lösung kann in Zukunft ungeeignet werden, aber wie genau, lässt sich nur schwer vorhersagen
Es ist zwar schwer vorherzusagen, in welcher Hinsicht eine Lösung künftig ungeeignet wird, aber man kann die aktuelle Lösung trotzdem so wählen, dass sie künftige Lösungen nicht blockiert oder behindert. Es ist gut, Optionen offen zu halten und Situationen zu vermeiden, in denen man einem Anbieter so ausgeliefert ist, dass man nicht mehr wegkommt
Ein typischer vorhersehbarer Fall von späterer Untauglichkeit ist die vollständige Abhängigkeit von einem bestimmten Vendor, sodass man aus dem Service gedrängt wird oder immer höhere Preise hinnehmen muss. Das ist ein durchaus vorhersehbares Problem
Wenn man ein Problem so löst, dass man den gesamten Problemraum abdeckt, ohne dafür mehr Arbeit zu investieren, kann die Lösung mit kleinen Anpassungen auch wechselnde Anforderungen auffangen und wird dadurch robuster. So deckt man ganz natürlich auch zukünftige Probleme mit ab
Ich arbeite bei einem bekannten großen Unternehmen in den USA. Unsere Abteilung ist stark von zwei Tabellenkalkulationen abhängig. Sie haben drei Übernahmen meines Werks überlebt. Als ich vor sieben Jahren anfing, waren sie schon alte Formulare. Vor zwei Jahren wollte ein neuer Manager das Ganze in ein unternehmensweites System überführen, scheiterte aber, und bald soll auch dieses System wieder durch ein neues ersetzt werden. Aber ich vermute, dass wir auch 2027 noch mit den Tabellenkalkulationen arbeiten werden
Ich bin Ex-Google-Mitarbeiter. Fünf Jahre lang habe ich praktisch alle Aufgaben — Projektmanagement, CRM, Quartalsplanung, Reporting, Interviews, Finanzen — ausschließlich mit Sheets erledigt (intern hieß es Trix). Nicht bloß, weil es ein Google-Produkt war (Produkte von Wettbewerbern wurden ebenfalls reichlich genutzt). Der überwältigende Vorteil war, dass sich Tabellenkalkulationen schnell genug bauen ließen, um Ziele zu erreichen, sodass man sich auf das Wesentliche der Arbeit konzentrieren konnte
Zu der Meinung von jemandem mit „9 Monaten im Job“: Ob richtig oder falsch, für so eine entschiedene Aussage nach noch nicht einmal einem Jahr Berufserfahrung gehört schon einiges an Chuzpe dazu. Was OP übersehen hat, ist die Wahrheit hinter „Nichts ist so dauerhaft wie ein Provisorium“. Dass man zunächst eine schnelle, improvisierte Lösung wählt, ist nur dann vertretbar, wenn man den gesamten Lebenszyklus dieser Lösung vollständig kontrolliert. Wenn man etwas hastig auf Bitte von jemandem erstellt und dann nach und nach immer neue Einsatzzwecke darauf gestapelt werden sollen … dann plädiere ich entschieden für ein Tool mit etwas höheren upfront cost
Über die Formulierung „einmal alle paar Monate …“ bei dem Problem musste ich fast lachen. Der Autor hat grundsätzlich recht, dass man Dinge nach Möglichkeit mit einfachen Tools erledigen sollte. Am besten ist es, wenn man vorhandene Tools unverändert weiterverwenden kann und sie den Bedarf ausreichend abdecken. In der Praxis ändern sich Business-Anforderungen tatsächlich oft alle paar Monate, sodass man dem Effekt „Das Provisorium wird zur Dauerlösung“ entkommen kann. Aber bei den meisten endet es damit, dass man Jahre später immer noch aufräumt, und das Szenario „wenn es nötig wird, schreiben wir es neu“ funktioniert fast nie. Und der Autor hat ein Jahr später oder darüber hinaus eben noch nicht selbst erlebt
Gerade der Teil mit „alle paar Monate …“ ist mir besonders aufgefallen. Ich frage mich, ob das auf Grundlage von vielleicht vier eigenen Erfahrungen gesagt wurde
Für Leute, die von großen Tabellenkalkulationen genug haben, war MS Access eine ziemlich brauchbare Lösung. Es brachte mehr Struktur und Wartbarkeit als Tabellenkalkulationen, ohne Zugänglichkeit und Entwicklungsaufwand zu opfern. Man konnte auch ohne viel Programmierwissen großartige UIs bauen. Und heute, 20 Jahre später, weiß ich ehrlich gesagt nicht einmal genau, was Access ersetzt hat
Ich stimme OP vollkommen zu. Ein Punkt noch: Wenn Anforderungen für Google Sheets zu komplex werden, ist Google Colab (oder ein Jupyter notebook) der nächsthöhere Schritt. Bevor ich eine richtige App baue, frage ich mich immer: 1. Geht das einfach mit einer Tabellenkalkulation? 2. Wenn nicht, geht es mit einem Jupyter notebook? Übrigens ist auch die Integration zwischen Sheets und Colab hervorragend
Ich finde, ein jupyter notebook ist ein viel größerer Komplexitätssprung, als einfach ein python script zu schreiben. Auch in einem python script kann man Kommentare schreiben, und diese Art von „lokalen Webserver laufen lassen und Code Block für Block ausführen, um Kommentare anzusehen“ sagt mir nicht besonders zu
Ich würde gern wissen, wie man etwas, das bisher in einem google sheet war, zu einem colab notebook aufrüstet. Mit dem Python-Paket
gspreadkann man zwar die Rohdaten des Sheets einlesen, aber bestehende Diagramme oder interaktive Elemente direkt in ein jupyter notebook zu übernehmen, scheint schwierig. Wahrscheinlich muss man sie am Ende neu bauenGoogle Apps Script ist ebenfalls eine gute Alternative. Schon mit einfachen Skripten für Dinge wie Datenimport kann man ziemlich viel erreichen
Eines der größten Probleme in der Business-Automatisierung ist die Lücke zwischen sogenannter „Shadow IT“, Low-Code-Plattformen und vollwertigen „offiziellen“ Projekten. Zwischen „mal eben mit Google Form zusammenklicken“ und „eine React-App mit CI/CD, Tests und CDN aufsetzen“ fehlt ein vernünftiger Migrationspfad. Stattdessen gibt es nur inkompatible Walled-Garden-Alternativen
Ich erledige mein komplettes Finanzmanagement mit Google Sheets. Ich habe mir sogar eine eigene Expense-Tracker-UI gebaut und über Jahre mehr als 5.000 Ausgaben erfasst. Kürzlich habe ich per vibe coding außerdem ein Web-UI-Tool mit einem Google Service Account gebaut und es als PWA umgesetzt, damit ich es auch auf dem Handy nutzen kann. Für einfache Anwendungsfälle (vor allem Single-User-Anwendungen) reicht Google Sheets statt einer DB völlig aus