Wie wir Projekte bei JetBase schätzen

Jeder weiß, dass eine genaue Schätzung von Webentwicklungsprojekten wichtig ist, aber die Frage ist, wie man sie erreicht. Mein Name ist Sergey und ich bin CTO bei JetBase. Jeden Tag schätze ich Hunderte von Projekten und donnerstags leite ich eine Teamleiter-Schule, in der separate Lektionen der Schätzung gewidmet sind.

In unserer Agentur haben wir eine Methodik für die Schätzung entwickelt und verfeinern diese ständig. Heute möchte ich meine Beobachtungen und Erfahrungen mit allen Interessierten teilen. Seien Sie auf echte Beispiele aus der Praxis und nicht weniger Statistiken und Zahlen vorbereitet.

Ich schreibe diesen Artikel für alle, die sich für das Thema interessieren, aber hauptsächlich für meine Kollegen, die Teamleiter, und auch für unsere Kunden, die sich täglich an unsere Vertriebsabteilung wenden und Preise anfragen. Eine genaue Projektkostenkalkulation ist für diese beiden Personengruppen entscheidend.

Ich habe oft die Frustration sowohl von Anfängern in der Teamleitung als auch von Kunden erlebt. Neue Teamleiter fühlen sich frustriert, wenn sie mit unzureichenden Kundendaten konfrontiert werden und Angst haben, zusätzliche Fragen zu stellen, während Kunden wiederum ratlos sind, wenn sie bestimmte Zahlen sehen. Beide benötigen eine perfekte Schätzung, aber ist dies leicht zu erreichen? Lassen Sie uns herausfinden, was die wahre Geschichte ist.

Beginnen wir mit einer Geschichte über einen Kunden, der sich einmal an uns wandte, um eine soziale Plattform zu erstellen, die bestehenden und beliebten Streaming-Anwendungen wie Instagram und TikTok ähneln sollte. Die angegebenen Anforderungen waren, wie so oft in 95 % der Fälle, recht allgemein, und wie üblich gab es keine Erwähnung der Geschäftsziele des Projekts.

Es war nicht schwer zu erraten, dass das Geschäftsziel des Projekts der Verkauf von Werbung war. Der übergeordnete Wunsch des Kunden war es, zu wissen, wie viel Zeit und Geld es kosten würde, dieses Ziel zu erreichen. Nun, wir könnten ungefähre Zahlen wie 3 Jahre und 1 Million Dollar nennen, aber das ist überhaupt nicht unser Ansatz.

Das Ziel unseres Unternehmens ist es, qualitativ hochwertige Arbeit zu leisten, und die Aufgabe des technischen Teams ist es, nicht nur eine Schätzung abzugeben, sondern die Anforderungen zu analysieren und die Umsetzung des Projekts im Zeitverlauf, in Sprints und Phasen zu skizzieren.

Wir zielen darauf ab, die für das Projekt wesentlichen Aufgaben zu bewerten, uns auf den Kern des Projekts zu konzentrieren. Im Laufe der Jahre ist uns klar geworden, dass dieser Ansatz realistischer und praktischer ist, als grobe Schätzungen abzugeben und dann zu versuchen, diese einzuhalten. Außerdem ist die Ära der schlüsselfertigen Produktentwicklung vorbei.

Heutzutage werden alle Produkte iterativ entwickelt, entwickeln sich in der Umgebung, im Raum.

Zurück zu dem Kunden, der eine Plattform wie TikTok erstellen wollte: Erstens glaube ich persönlich, dass das Kopieren des Weges eines anderen nicht der zuverlässigste Weg ist. Aus unserer Sicht schlagen wir vor, kein TikTok zu erstellen, mit anderen Worten, es überhaupt nicht zu erwähnen. Stattdessen schlagen wir vor, das Projekt anhand seines Wesens zu analysieren, seine Geschäftsziele zu beschreiben, die Schmerzpunkte der Benutzer anzusprechen und herauszufinden, wie das Produkt die Probleme der Benutzer lösen kann.

Mit anderen Worten: ein MVP erstellen, testen, Änderungen vornehmen. Erst dann wird klar, was die Plattform tatsächlich darstellen wird. Am Ende könnte sie sich komplett von TikTok unterscheiden, vielleicht eher wie Snapchat.

Nun kommen wir zum Wesentlichen – wie der Schätzungsprozess bei JetBase aussieht. Wir haben bereits ausführlich über die Schätzung im Artikel „Software-Entwicklungsschätzung: Ein umfassender Leitfaden“ geschrieben.

Hier sind die drei Hauptphasen, aus denen der Schätzungsprozess besteht (es wird Theorie geben, aber danach werden Sie alles in der Praxis sehen):

Schätzungsphasen:

Phase 1. Erhalt von Initialdaten vom Kunden mit Wireframes, einem Briefing von JetBase.io

In dieser Phase führt unser Entwicklerteam unter der Leitung eines Teamleiters eine Analyse des Projekts durch, die nicht nur das Verständnis technischer Aspekte, sondern auch die Identifizierung des Projektkerns beinhaltet. Oft impliziert dies ein Geschäftsziel. Zum Beispiel möchte ein Kunde möglicherweise eine Website für die Registrierung von Konferenzteilnehmern oder eine App mit Empfehlungen für vegetarische Rezepte erstellen. Im ersten Fall ist das Ziel der Ticketverkauf, im zweiten der Abonnementverkauf.

Phase 2. Erstellen der Projektarchitektur, Aufschlüsselung in Unteraufgaben

Wenn wir in der ersten, zuvor beschriebenen Phase das Wesen des Projekts – den Kern – verstehen wollen, dann zerlegen wir hier, in der zweiten Phase, diese große Projektidee in kleine Teile, während wir gleichzeitig die konstruktiven Funktionen visualisieren. Mit anderen Worten, wir zerlegen die große Aufgabe in Unteraufgaben und erstellen die Projektarchitektur. Diese Phase ist entscheidend und unvermeidlich. Es gibt viele Arten der Zerlegung in Unteraufgaben, aber darüber sprechen wir ein anderes Mal.

Die Visualisierung des Projektworkflows und der Architektur schafft Vertrauen bei allen Beteiligten, insbesondere bei denen, die erhebliche Mittel investieren. Bei JetBase unterzeichnen wir Verträge mit unseren Kunden erst, nachdem wir die Projektworkflows durch große, mittlere und kleine Aufgaben akribisch dargelegt haben. Dies gewährleistet die Sicherheit unserer Kunden und fördert ein klareres Verständnis in unserer Zusammenarbeit.

Phase 3. Projektschätzung nach Arbeitsumfang, Rollen, Verantwortlichkeiten und Stunden.

Hier beginnt die eigentliche Schätzung – das Setzen der i-Punkte und das Streichen der t-Striche. In dieser Phase müssen Sie Ihren mathematischen Verstand einsetzen und nichts Wichtiges übersehen; jeder numerische Wert beeinflusst den endgültigen Betrag. Gleichzeitig sollten Sie nicht vergessen, dass die Projektschätzung nicht nur Wissenschaft, sondern auch Kunst ist, und vieles davon abhängt, wie Sie durch die Zahlen und Tabellen den Kern des Projekts erkennen können, für das all diese akribische Arbeit geleistet wird.

Sicherlich muss man aus Fehlern lernen, aber in der Teamleiter-Schule, in der ich dienstags unterrichte, gebe ich in einer praktischen Stunde ein Beispiel für eine präzise Schätzung. Dies ist ein reales Beispiel aus dem Portfolio von JetBase, wo wir die Stunden mit höchster Genauigkeit geschätzt haben. Ein Wunder? Nein, nur eine Mischung aus Wissenschaft und Kunst und viel akribischer Arbeit. Für diese Schätzung haben wir zwei Wochen gebraucht, und das ist ein relativ kurzer Zeitraum.

Während der Analysephase stellten wir fest, dass der Kern des Projekts die Teilnehmerregistrierung für Offline-Spiele ist. Dies war in den anfänglichen Daten des Kunden nicht explizit angegeben, ist aber von Anfang an entscheidend zu wissen. Dann nahmen wir diese anfänglichen Daten vom Kunden und seine Wireframes und teilten das Projekt in Module auf, die beschreiben, was auf hoher technischer Ebene getan werden muss, zum Beispiel:

• Erstellen der ersten Anwendung
• Datenbank verbinden
• Projektentitäten erstellen
• Konfiguration für externe Dienste einrichten usw.

Als Nächstes muss jedes Modul in Funktionen und Unterfunktionen mit einer detaillierten Beschreibung für Frontend und Backend aufgeteilt werden. Schauen wir uns ein reales Beispiel an. Hier ist eine Seite aus dem genannten Projekt.

Ein unerfahrener oder unengagierter Teamleiter könnte diese Seite grob schätzen und, sagen wir, 8 Arbeitsstunden veranschlagen. Man kann ihre Perspektive verstehen, da Kunden oft Entwickler für eine schnelle und endgültige Projektzahl ansprechen und ungern lange warten.

Aber bei JetBase verfolgen wir diesen Ansatz nicht. Wir investieren mehr Zeit in die Schätzung, erzielen aber ein genaueres Ergebnis. So sieht unsere Schätzung für die erwähnte Seite aus:

Der Punkt ist, dass es für zukünftige Projektspezialisten viel einfacher ist, Unterfunktionen zu schätzen, da es sich um eine technisch klare und verständliche Aufgabe handelt, die der Teamleiter während der Schätzungsphase identifiziert. Hier liegt das Geheimnis präziser Schätzung – in der akribischen Zerlegung.

Und wenn Sie jedes Modul, wie im Beispiel der oben besprochenen Seite, weiter zerlegen und dann alle Risiken und damit verbundenen Aufgaben berechnen, erhalten Sie eine saubere und zuverlässige Schätzung.

Nachfolgend werde ich ein Beispiel für eine schlechte Schätzung geben, und um die gesamte Geschichte über eine gute Schätzung abzuschließen, kann ich sagen, dass das Erreichen der sogenannten Ideal- oder Reinheit nicht so schwierig ist. Es ist für alle Beteiligten des Prozesses durchaus möglich und sogar notwendig. Wie Steve McConnell in seinem Buch „Software Estimation: Demystifying the Black Art“ sagte:

„Eine gute Schätzung ist eine Schätzung, die eine ausreichend klare Sicht auf die Projektrealität bietet, um der Projektleitung gute Entscheidungen darüber zu ermöglichen, wie das Projekt gesteuert werden muss, um seine Ziele zu erreichen.“

Bevor wir bei JetBase das aktuelle Niveau an Schätzungsexpertise erreichten, haben wir Fehler gemacht. Wir haben gelernt, uns durch sie zu verbessern, und glücklicherweise gab es nicht zu viele. Jetzt werde ich kurz ein Beispiel für eine schlechte Schätzung erwähnen, damit Sie verstehen, wo die Risiken liegen und warum es eine traurige Geschichte für Team und Kunden ist.

Hintergrund:

Einmal wandte sich ein Kunde an uns, um ein Online-Lernportal für Schauspieler und Profis der Filmbranche zu erstellen. Anfänglich waren nur sehr wenige Daten verfügbar, aber wir schätzten das Projekt dennoch, was zu einer festen Gesamtschätzung führte.

Ergebnis:

Wie bereits erwähnt, haben wir einen Festpreis für das Projekt angeboten. In Wirklichkeit haben wir jedoch das geschätzte Budget überschritten, da sich herausstellte, dass mehr Zeit für die Arbeit benötigt wurde. Obwohl unser Kunde dagegen keine Einwände hatte, entstand das Problem, als er keine Zahlungen für die Arbeitsphasen (Sprints) leistete, was ihm ermöglichte, das Projekt am Ende vollständig abzulehnen.

Folglich mussten wir das gesamte Projekt neu bearbeiten, was den doppelten Aufwand erforderte, aber wir wurden für unsere Arbeit nicht entschädigt. Wir arbeiteten ohne Bezahlung, um unseren Ruf zu schützen, während unser Kunde seine kostbare Zeit verlor und von seinen Erfahrungen in der Webentwicklung enttäuscht war. Fehler sollten kompensiert werden.

Wo die Fehler lagen:

• Der Kunde stellte zu Beginn unzureichende Daten zur Verfügung.
• Wir nutzten keine agilen Methoden.
• Der Kunde bezahlte die Arbeitsphasen nicht und war daher nicht in die Zwischenergebnisse involviert.
• Wir gaben einen Festpreis an, anstatt Sprints zu schätzen (wir hätten die zuvor beschriebene Methode der genauen Schätzung verwenden können).

In Bezug auf die beiden oben genannten Beispiele für Schätzungen ist offensichtlich, dass bestimmte Strategien und Praktiken entscheidend für eine genaue Schätzung in der Webentwicklung sind.

Aus diesen Fällen ergeben sich mehrere wichtige Schlussfolgerungen:

• Festpreis-Schätzungen sollten vermieden werden, da sie oft die tatsächlichen Bedürfnisse des Produkts nicht genau widerspiegeln.
• Kundenanfragen stimmen oft auch nicht mit der Realität des Projekts überein.
• Mehr Eingangsdaten zu Beginn führen zu einer besseren Schätzgenauigkeit.
• Je akribischer die Zerlegung der Aufgaben, desto genauer die Schätzung.
• Effektive Kommunikation, wie die Einbindung von Kunden in regelmäßige Demo-Überblicke und Planungssitzungen, ist entscheidend für fundierte Entscheidungen und eine effiziente Produktentwicklung.

Darüber hinaus möchte ich betonen, dass das Problem der genauen Schätzung und generell alle technischen Probleme nicht nur technische Probleme sind, um die sich die IT-Branche kümmern sollte. Kunden und Unternehmen müssen ebenfalls involviert sein; dann wird es mehr grünes Licht für akribische Schätzungen geben, was zu beidseitigem Nutzen und weniger Bedarf an ungeschickten Festpreisansätzen führt.

Ich hoffe, mein Artikel war sowohl für IT-Profis als auch für Stakeholder hilfreich, die ein Webentwicklungsteam suchen. Kontaktieren Sie uns gerne, wenn Sie eine Projektschätzung benötigen – wir werden unser Bestes tun, um sie auf Ihre spezifischen Bedürfnisse zuzuschneiden.

Quelle: Business’s ‘It’s not my problem’ IT problem.