Serie: Kann man ein Projektmanagement-Tool selbst bauen?Teil 1
Kann man ein Projektmanagement-Tool selbst bauen? Vier Wege und ihre Grenzen
Über diese Serie
„Kann man ein Projektmanagement-Tool selbst bauen?“ ist eine Serie in sechs Teilen für alle, die überlegen, sich ein eigenes Tool mit einer Tabellenkalkulation, einem No-Code-Tool oder mit KI zu bauen. Die Teile lassen sich in beliebiger Reihenfolge lesen.
- Kann man ein Projektmanagement-Tool selbst bauen?Dieser Artikel
- Wir haben eine KI ein Issue-Tracking-Tool bauen lassenIn Kürze
- Der Weg von „Es läuft“ zu „Es ist nutzbar“In Kürze
- Die eigentliche Arbeit beginnt nach dem BauenIn Kürze
- Was ein Eigenbau wirklich kostetIn Kürze
- Wer selbst bauen sollte – und wer kaufen sollteIn Kürze
Jedes Mal, wenn das Team wächst, steigt die monatliche Rechnung für Ihr Tool. Funktionen gibt es reichlich, aber Sie nutzen nur wenige davon. Und irgendwie passt es nie ganz zu der Art, wie Ihr Team arbeitet.
Also bitten Sie ein KI-Tool: „Bau mir eine App für das Issue-Tracking“ – und nach wenigen Minuten bekommen Sie Code für etwas, das ganz danach aussieht.
„Wäre es nicht schneller, einfach unser eigenes zu bauen?“
Mit KI ist es heute eine deutlich realistischere Option, ein Projektmanagement-Tool selbst zu bauen.
Dieser Artikel vergleicht vier Wege, ein solches Tool zu bauen, und zeigt Aufwand und Grenzen der einzelnen Wege. Die kurze Antwort vorweg: Ja, Sie können ein Projektmanagement-Tool selbst bauen. Die eigentliche Frage ist, wie viele Personen es nutzen, wie lange und wer es repariert.
Hinweis: Dieser Artikel stammt vom Entwickler von GeckoFlag. GeckoFlag ist ein Issue-Tracking-Tool, das sein Entwickler zunächst für den eigenen Gebrauch gebaut und dann zu einem Produkt gemacht hat. In dieser Serie schreiben wir aus der Sicht von jemandem, der so ein Tool gebaut hat – mit den guten wie mit den schwierigen Seiten.
Warum man ein eigenes Tool bauen möchte
Die Gründe, über ein eigenes Tool nachzudenken, sind verschieden. Sehen wir uns zuerst jeden Grund an und fragen, ob ein Eigenbau ihn tatsächlich löst.
| Grund für einen Eigenbau | Löst ein Eigenbau das? |
|---|---|
| Die monatlichen Kosten sind zu hoch | Rechnet man die Zeit für Bau und Pflege mit ein, ist es am Ende vielleicht nicht günstiger (die Rechnung machen wir in Teil 5) |
| Zu viele Funktionen, um gut damit zu arbeiten | Manche fertigen Tools haben nur sehr wenige Einstellungen. Dafür müssen Sie nicht unbedingt selbst bauen |
| Es passt nicht zu unserer Arbeitsweise | Hier hilft ein Eigenbau am meisten. Je ungewöhnlicher Ihr Arbeitsablauf, desto mehr lohnt sich ein eigenes Tool |
| Wir wollen unsere Daten im Haus behalten | Manche fertigen Tools werden auf Ihrem eigenen Server installiert |
| Das Bauen macht Spaß, oder wir wollen dabei lernen | Das ist Grund genug für einen Eigenbau |
Lautet der Grund „zu teuer“ oder „zu viel“, kann die Suche nach einem anderen fertigen Tool das Problem lösen. Ist Ihr Arbeitsablauf dagegen ungewöhnlich und nichts passt, oder ist das Bauen selbst das Ziel, dann ist ein Eigenbau sinnvoll.
Ein klarer Grund erleichtert auch die Wahl zwischen den folgenden Wegen.
Es gibt vier Wege, ein Tool zu bauen
Grob gesagt gibt es vier Wege, ein Projektmanagement-Tool zu bauen.
| Weg | Was Sie brauchen | Passender Umfang | Wichtigste Grenzen |
|---|---|---|---|
| Tabellenkalkulation | Grundkenntnisse in Tabellenkalkulation | Eine bis wenige Personen, kurzfristig | Stößt an Grenzen, wenn Personen und Aufgaben zunehmen |
| No-Code-Tool | Den Dienst bedienen können | Wenige Personen bis kleines Team | Die Kosten steigen meist mit der Zahl der Personen. Abhängig von Änderungen am Dienst |
| Code schreiben | Programmierkenntnisse und Zeit | Hängt davon ab, wie Sie bauen | Bauen und Reparieren kosten Zeit |
| Von KI bauen lassen | KI gut anleiten können | Hängt davon ab, wie Sie bauen | Sie haben am Ende Code, den Sie selbst nicht lesen können |
Mit jedem dieser Wege lässt sich die Grundform bauen: Aufgaben anlegen, ihnen eine verantwortliche Person und eine Frist geben und ihren Status ändern. Die Unterschiede zeigen sich, wenn mehr Personen es nutzen und wenn Sie später etwas reparieren müssen. Sehen wir uns die Wege nacheinander an.
Mit einer Tabellenkalkulation bauen
Am einfachsten geht es mit Excel oder Google Tabellen. Für eine minimale Lösung reichen vier Spalten:
- Aufgabe: eine Aufgabe pro Zeile
- Verantwortlich: wer sie erledigt
- Frist: bis wann
- Status: aus einer Drop-down-Liste gewählt, etwa nicht begonnen, in Arbeit oder erledigt
Mit einer bedingten Formatierung, die überfällige Zeilen einfärbt, sehen Sie Verzögerungen auf einen Blick. Für eine bis wenige Personen und ein Projekt, das in einigen Monaten abgeschlossen ist, reicht das oft.
Wenn aber Personen und Aufgaben zunehmen, gerät die Tabelle nach und nach an ihre Grenzen. Es gibt keinen Ort, an dem der Verlauf einer Aufgabe festgehalten wird, und wer als verantwortliche Person eingetragen wird, bekommt keine Benachrichtigung.
Siehe auchDie Grenzen der Arbeit mit einer Tabellenkalkulation erklären wir ausführlich in Teil 2 unserer Einsteigerserie „Das erste Projektmanagement-Tool“: „Wo stößt eine Excel-Liste an ihre Grenzen?“
Mit einem No-Code-Tool bauen
Mit No-Code-Tools wie Notion oder Airtable legen Sie eine Datenbank an und zeigen sie als Liste, Kanban-Board, Kalender und so weiter an. So können Sie ohne Programmierung ein System für das Issue-Tracking zusammenstellen.
Ihre Stärken: Sie können frei Felder hinzufügen und mit wenig Aufwand ein ansprechendes Aussehen erreichen. Sie können einen Aufbau ausprobieren, der zu Ihrer Arbeit passt, und ihn nach und nach anpassen.
Achten Sie dagegen auf Folgendes:
- Die Kosten steigen meist mit der Zahl der Personen: Viele dieser Dienste rechnen nach Nutzerzahl ab, sodass Sie am Ende etwa so viel zahlen wie für ein fertiges Tool.
- Nur wer gebaut hat, versteht den Aufbau: Schnell kennt nur noch die Person, die das System gebaut hat, die Zusammenhänge zwischen den Feldern.
- Sie sind vom Dienst abhängig: Jede Änderung an Funktionen oder Preisen des Dienstes trifft Sie direkt.
Mit selbst geschriebenem Code bauen
Wenn Sie programmieren können, können Sie das Tool von Grund auf bauen. Das gibt Ihnen die größte Freiheit, und Sie können es genau auf Ihre Arbeit zuschneiden. Außerdem ist es ein hervorragendes Lernprojekt.
Zeit kosten dabei aber nicht die sichtbaren Teile wie die Aufgabenliste oder das Eingabeformular. Es sind die Teile, die man auf dem Bildschirm nicht sieht:
- Anmeldung und Passwortverwaltung
- Berechtigungen: wer was sehen und tun darf
- Die Speicherung der Daten und der Schutz vor Datenverlust
Dazu kommt, dass Sie nach dem Start alles selbst übernehmen: Fehler beheben und mit Updates von Server und Programmiersprache Schritt halten. Es ist nicht ungewöhnlich, dass die Pflege mehr Zeit kostet als das Bauen.
Von KI bauen lassen
Der Weg, der derzeit die meiste Aufmerksamkeit bekommt: die KI den Code schreiben lassen. Bitten Sie sie, „eine App zu bauen, in der ich Aufgaben anlegen und jeder eine verantwortliche Person, eine Frist und einen Status geben kann“, und vielleicht läuft nach wenigen Stunden schon etwas auf dem Bildschirm.
Ohne Programmierkenntnisse etwas Lauffähiges zu bekommen, ist eine große Veränderung. Auf eines sollten Sie aber achten.
Wenn Sie den erzeugten Code nicht lesen können, können Sie ihn nicht reparieren, sobald ein Fehler auftritt. Fragen Sie die KI noch einmal, wird der Fehler vielleicht behoben, aber etwas anderes geht kaputt. Um zu erkennen, was wo kaputtgegangen ist, müssen Sie Code eben doch lesen können.
Wie Sicherheit und Rechte an KI-geschriebenem Code geregelt sind, hängt außerdem von den Bedingungen des genutzten Dienstes und davon ab, wie Sie das Ergebnis verwenden. Wenn Sie es beruflich nutzen, prüfen Sie die Nutzungsbedingungen des KI-Dienstes, den Sie verwenden.
SerieWie weit man mit KI tatsächlich kommt, testen wir in Teil 2: „Wir haben eine KI ein Issue-Tracking-Tool bauen lassen“ (in Kürze)
Wie es bei uns war
Auch GeckoFlag begann als Tool, das sein Entwickler mitten in der Kundenarbeit zu bauen anfing, weil er etwas wollte, das zu seiner Arbeitsweise passt. Gebaut hat es der Entwickler, der zugleich Webdesigner und Engineer ist, mit CakePHP, einem PHP-Framework.
KI (Claude) kam durchgehend intensiv zum Einsatz, von Vorschlägen zur Umsetzung bis zum Testen. Trotzdem dauerte es viel länger als erwartet, von der ersten „lauffähigen“ Version zu etwas zu kommen, das viele Menschen jeden Tag nutzen können. Was auf diesem Weg passiert ist, erzählen wir im Lauf dieser Serie.
Die Wahl hängt davon ab: wie viele Personen, wie lange und wer repariert
Welchen der vier Wege Sie wählen, hängt weniger von den Funktionen ab als davon, wie Sie das Tool nutzen. Mit drei Fragen – wie viele Personen, wie lange und wer repariert – ergibt sich diese grobe Orientierung:
| Wie viele Personen | Wie lange | Wer repariert | Passende Wahl |
|---|---|---|---|
| Eine bis wenige | Einige Monate | Wer es nutzt | Eine Tabelle kann reichen |
| Ein kleines Team | Ein Jahr oder länger | Wer es gebaut hat, bleibt im Team | No-Code oder mit KI selbst bauen |
| Auch externe Personen | Viele Jahre | Wer es gebaut hat, geht vielleicht | Ein fertiges Tool ist eine Überlegung wert |
Und wenn Ihr Arbeitsablauf so ungewöhnlich ist, dass kein fertiges Tool passt, ist ein Eigenbau (Code schreiben oder von KI bauen lassen) eine Überlegung wert, unabhängig von Teamgröße oder Zeitraum.
Diese Tabelle ist nur eine grobe Orientierung. Auch für eine Person oder ein kleines Team gibt es Situationen, in denen ein Tool die Arbeit erleichtert.
Achten Sie besonders auf die letzte Zeile. Externe Personen nutzen es, es wird über Jahre genutzt, die Person, die es gebaut hat, wechselt vielleicht die Aufgabe oder geht. Trifft auch nur einer dieser Punkte zu, lesen Sie Teil 3 und die folgenden Teile, bevor Sie mit dem Bauen beginnen.
Was zwischen „Es läuft“ und „Es ist nutzbar“ liegt
Wer mit einem eigenen Tool beginnt, merkt oft auf halber Strecke: Zwischen „es läuft“ und „viele Menschen können es lange nutzen“ liegt eine große Lücke.
An Folgendes denkt man zum Beispiel kaum, solange man die ersten Bildschirme baut:
- Was jedes Mitglied sehen darf: Externe Personen sollen nur dieses eine Projekt sehen
- Ein vergessenes Passwort zurücksetzen: Die Personen sollen es selbst per E-Mail zurücksetzen können
- E-Mail-Benachrichtigungen: Personen sollen benachrichtigt werden, wenn ihnen eine Aufgabe zugewiesen oder ein Kommentar hinzugefügt wird
- Datensicherungen: Der Verlauf Ihrer Aufgaben soll auch bei einem Serverausfall nicht verloren gehen
All das wird nötig, sobald mehr Personen das Tool nutzen. Und mit jedem Punkt, den Sie bauen, gibt es mehr zu prüfen und mehr zu reparieren.
Wer diese Punkte vor dem Start kennt, schätzt den Zeitaufwand ganz anders ein.
SerieDie Punkte, die man erst nach dem Eigenbau bemerkt, fassen wir in Teil 3 als Checkliste zusammen: „Der Weg von ‚Es läuft‘ zu ‚Es ist nutzbar‘“ (in Kürze)
Zusammenfassung
- Ein Projektmanagement-Tool lässt sich auf vier Wegen bauen: mit einer Tabellenkalkulation, mit einem No-Code-Tool, mit selbst geschriebenem Code oder von KI gebaut
- Ein Eigenbau hilft am meisten, wenn Ihr Arbeitsablauf ungewöhnlich ist und nichts Fertiges passt, oder wenn das Bauen selbst das Ziel ist
- Welchen Weg Sie wählen, hängt davon ab, wie viele Personen es nutzen, wie lange und wer es repariert
- Zwischen „es läuft“ und „viele Menschen können es lange nutzen“ liegt eine große Lücke
Ein Eigenbau ist keineswegs eine unvernünftige Entscheidung. Wer aber schon vor dem Start bedenkt, was nach dem Bauen kommt, erspart sich Umwege.
Beim nächsten Mal lassen wir eine KI eine App für das Issue-Tracking bauen und sehen, wie weit sie kommt. Am Ende der Serie teilen wir als Entwickler, der sein eigenes Tool gebaut hat, unser Fazit: selbst bauen oder kaufen?
Wie sich das Aufgabenmanagement selbst verändert, wenn Sie KI bei der Arbeit nutzen, erklären wir in Teil 1 unserer Serie „Aufgabenmanagement für Teams, die mit KI arbeiten“: „Braucht man mit KI noch ein Task-Management-Tool?“