Was ist Ghost%?

Die Baseline

E ist der geschätzte Aufwand im ausgewählten Umfang und Zeitraum in Referenzstunden einschließlich des zugeteilten Überlaufs. D ist die Anzahl der Entwicklertage im ausgewählten Modus. S = Share ÷ 100: Bei Share = 100 % ist S gleich 1. Die standardmäßige Ghost-Basis beträgt 3 Referenzstunden pro Entwicklertag. Sie ist eine gemeinsame Grundlage für den Vergleich der Leistung, nicht die Länge des gesamten Arbeitstags. Wenn die Oberfläche die Auswahl einer anderen Basis ermöglicht, setzen Sie diese anstelle von 3 ein. Raw Ghost% verwendet S = 1.

Im Spread-Modus zählt D Daten mit positiv zugeteiltem Aufwand, einschließlich zulässiger Wochenenddaten. Ein Tag ohne Commits kann zählen, wenn das Modell Aufwand dort platziert; ein Tag ohne zugeteilten Aufwand zählt nicht, und ein Commit mit null Aufwand allein fügt keinen Spread-Tag hinzu. Dies sind modellierte Daten, keine beobachteten Arbeitstage.

Der FTE-Modus verwendet die Aktivitätsspanne des Entwicklers im ausgewählten Umfang: vom ersten Datum mit Aufwand bis zum letzten Commit-Datum, einschließlich Commits mit null Aufwand. Diese Spanne wird mit dem ausgewählten Zeitraum geschnitten; gezählt werden Wochentage, auch ohne Commits oder Aufwand, sowie Wochenenddaten mit positivem Aufwand. Teamansichten können diese Spanne außerdem auf Zeiträume der Teamzugehörigkeit begrenzen. Berichte mit Mitarbeiterkalender verwenden einen separaten Nenner: verfügbare Minuten aus dem konfigurierten Zeitplan, Datumsüberschreibungen und Abwesenheiten, geteilt durch 480 Minuten pro Vollzeittag. Sie verwenden dieselbe 3-Stunden-Norm und Share-Anpassung; die standardmäßigen Spread- und FTE-Tageszahlen ändern sie nicht.

Was Share anpasst

Share ist eine manuell festgelegte Zuteilung von 0 % bis 100 %, standardmäßig 100 %. Behandeln Sie 100 % als normale Vollzeit-Entwicklerrolle, nicht als acht Stunden Tipparbeit. Die 3-Stunden-Baseline lässt bereits Raum für den üblichen nicht programmierenden Teil dieser Rolle. Senken Sie Share bei einer geringeren Zuteilung zur bewerteten Entwicklungsarbeit, etwa bei Teilzeit oder zusätzlichen Aufgaben; ziehen Sie den üblichen nicht programmierenden Teil des Tages nicht erneut ab.

Der Aufwand umfasst das Verstehen des relevanten Codes, den Lösungsentwurf, die Umsetzung, Selbsttests und notwendige Korrekturen. Share zieht diese Tätigkeiten nicht noch einmal ab. Eigenständige Reviews der Arbeit anderer, Mentoring, Meetings und Arbeit ohne Spur im analysierten Code werden nicht direkt gemessen. Eine Führungskraft nimmt die Anpassung an den Kontext der Rolle vor.

Share verändert den angepassten Ghost%-Wert durch Division. Geschätzter Aufwand, zugeteilte Zeitachse, Raw Ghost%, Tageszahlen und Kosten bleiben unverändert. Bei Share = 0 % ist der angepasste Ghost%-Wert nicht verfügbar, nicht null oder unendlich. Auch ein ungeklärter Share-Wert macht ihn nicht verfügbar. Dieser Coding Share ist vom experimentellen KI-Spuren-Anteil getrennt, der an anderer Stelle im Produkt angezeigt wird.

Beispiele für Einzelpersonen

Bei der Standardnorm ergeben E = 30 Referenzstunden und D = 10 Tage mit Share = 100 % einen Wert von 100 %: 30 ÷ (10 × 3 × 1) × 100. Bei gleichem E und D, aber Share = 50 %, beträgt der angepasste Ghost%-Wert 200 %; Raw Ghost% bleibt 100 %. Bei Share = 0 % ist der angepasste Ghost%-Wert nicht verfügbar, die 30 Referenzstunden bleiben erhalten.

Der ausgewählte Modus ist entscheidend: 6 Referenzstunden auf einem Datum ergeben im Spread-Modus 200 %. Liegt dieses Datum in einer FTE-Spanne von 20 Wochentagen, beträgt FTE Ghost% bei Share = 100 % 10 %. Dieselbe Codeleistung wird mit unterschiedlichen Tageszahlen verglichen; keines der Ergebnisse rekonstruiert die tatsächliche Arbeitszeit.

Team- und Repository-Gesamtwerte

Der gesamte Ghost%-Wert in Dashboard- und öffentlichen Repository-Zusammenfassungen ist ein aufwandsgewichteter Mittelwert der individuellen Prozentsätze: Σ(Eᵢ × Ghost%ᵢ) ÷ ΣEᵢ. Der Prozentsatz jeder Person verwendet bereits deren eigene Tageszahl und Share. Er ist weder der gesamte Teamaufwand geteilt durch 3 noch eine zusammengefasste Personen-Tages-Rate oder ein einfacher Mittelwert der Personen. Lesen Sie den ausgewählten Umfang und Modus zusammen mit dem Gesamtwert.

Beispiel: A hat 30 Referenzstunden über 10 Tage (100 %) und B hat 15 über 10 Tage (50 %), beide bei Share = 100 %. Das aufwandsgewichtete Gesamtergebnis ist (30 × 100 + 15 × 50) ÷ 45 = 83,33 %. Würden ihre gemeinsamen 45 Stunden durch 20 Personentage und anschließend durch 3 geteilt, ergäben sich 75 %, eine andere Kennzahl. Positiver Aufwand einer Person, deren angepasster Ghost%-Wert nicht verfügbar ist, macht auch das angepasste Gesamtergebnis nicht verfügbar; Personen mit null Aufwand tragen kein Gewicht bei.

Aufwand über die Zeit verteilen

Die Zeitachse ist ein Modell dafür, wie der geschätzte Aufwand verteilt werden könnte, keine Beobachtung des tatsächlichen Arbeitszeitpunkts. Die normale Zuteilung hat eine gemeinsame Kapazität von 5 Referenzstunden pro Person und Tag über alle Repositories und E-Mail-Aliasse in einem Workspace hinweg. Commits mit demselben Autorendatum werden gruppiert, und frühere Zuteilungen verbrauchen diese Kapazität.

Das aktuelle Zuteilungsfenster umfasst 14 Kalenderdaten: das Commit-Datum und die 13 vorherigen Daten, möglicherweise vor dem ersten Commit oder dem ausgewählten Berichtszeitraum. Das Commit-Datum ist auch am Wochenende zulässig; frühere Samstage und Sonntage werden übersprungen. Überlauf bleibt erhalten und wird in der modellierten zeitlichen Verteilung berücksichtigt. Dieser berechnete Überlauf ist keine beobachtete Mehrarbeit. Berichtsfilter wählen die Daten aus, denen Aufwand zugeteilt wurde; eine Änderung des sichtbaren Zeitraums verschiebt nicht den gesamten Aufwand eines Commits in diesen Zeitraum.

Die Zuteilungskapazität von 5 Stunden und die Ghost-Baseline von 3 Stunden dienen unterschiedlichen Zwecken. Die Kapazität legt Referenzaufwand auf die Zeitachse; die Baseline wandelt die tägliche Referenzleistung in eine relative Produktivitätsschätzung um. Keine der beiden Zahlen erfasst den tatsächlichen Arbeitstag eines Entwicklers. Daten werden in der Zeitzone der Projektion interpretiert. Ältere Workspaces und gespeicherte Analysen können eine frühere Verteilungsregel beibehalten; diese Parameter beschreiben die aktuelle Regel.

So lesen Sie Ghost%

Die angezeigten Bereiche vergleichen die Leistung mit der ausgewählten Referenz-Baseline. Verwenden Sie dauerhafte Muster und den Kontext der Rolle zur Interpretation:

• 120 % und mehr – über der Referenz-Baseline.
• 100 % bis 120 % — auf Baseline-Niveau oder darüber.
• 80 % bis 100 % — leicht unter der Baseline.
• Unter 80 % — deutlich unter der Baseline.

Was ein Ergebnis über 100 % bedeutet

Über 100 % bedeutet, dass die geschätzte Codeleistung die Baseline für die ausgewählte Tagesbasis und den Share-Wert übersteigt. KI-Unterstützung kann eine Ursache sein, neben Erfahrung, Werkzeugen und der Art der Arbeit. Ein hoher Ghost%-Wert allein beweist weder KI-Nutzung noch Codequalität oder geschäftliche Wirkung.

Was Ghost% nicht ist

Dies ist eine modellbasierte Schätzung der individuellen Codeproduktivität mit Unsicherheit. Sie misst weder tatsächliche Arbeitsstunden noch Sorgfalt, Fähigkeit, Codequalität, geschäftliche Wirkung oder sämtliche Arbeit außerhalb der analysierten Änderungen. Verwenden Sie sie, um dauerhaft geringe Beiträge zu untersuchen und starke Entwickler zu erkennen, mit unabhängiger Prüfung und Kontext zur Rolle. Sie darf nicht die alleinige oder primäre Grundlage für Einstellung, Vergütung, Beförderung oder Kündigung und kein automatisiertes Urteil über eine Person sein.

DevGhost verwendet den Git-Verlauf und Git-Änderungen. Es benötigt weder Zeiterfassung noch Bildschirmaufnahmen oder Keystroke-Logging.