Präambel
Eine mittelgroße russische Bank verfügt über eine Internetbank für Physiker und Anwälte, Websites und mobile Anwendungen. Und es gibt auch eine Unterteilung, die all diese Wirtschaft begleitet und entwickelt. Hier kommt der junge Leiter, der seit mehr als 3 Jahren in dieser Organisation arbeitet und in dessen Auftrag diese Geschichte sein wird.
Hintergrund
Die Bank ist modern, die Prozesse sind nach ITIL aufgebaut, auf den ersten Blick sieht alles aus wie ein Lehrbuch. Wie Sie dem Titel des Artikels entnehmen können, werden wir nur einen Teil des Prozesses "Änderungen vornehmen" ansprechen, der uns interessiert.
Problem
Alles in diesem Prozess war bis auf einen Moment ausgezeichnet, nämlich der Analyst hat die Entwicklungszeit mit dem Kunden vereinbart - dem Eigentümer des Produkts "Internetbank juristischer Personen, Web + mobile Kanäle", im Folgenden einfach als Kunde bezeichnet. Der Kunde hat die vor ihm oder unter seiner Teilnahme geleistete Arbeit immer verstanden und akzeptiert, nämlich:
- Klärung und Formalisierung seiner Anforderungen. Er sah direkt, wie aus seinen zwei Textzeilen eine Kundengeschichte, ein Prototyp und schließlich eine Aussage für einen Entwickler entstand.
- Alle Arten von Tests. Er sah riesige Testlisten.
- Dokumentieren. Er konnte sich die Anzahl der Seiten mit Text und Bildern (Diagramme) ansehen.
- Aber in Bezug auf die Entwicklung fühlte der Kunde immer einen Trick, es schien ihm, dass ein böser (und tatsächlich gutherziger) bärtiger Teamleiter, der seine Einschätzung abgab, nur sieht, wie man 50 Prozent zusätzliche Stunden dort eintritt, ohne sich die Mühe zu machen, SL zu treffen und zu bekommen Motivation durch KPI. Dieses Problem musste der junge Führer lösen.
Entscheidung
Schritt 1. Wie man die Entwicklungsdauer in absoluten Zahlen berechnet Es
gab viele Ideen, eine davon: Eine Bewertung basierend auf zuvor erledigten Aufgaben ist besser als nichts, aber:
- mühsam, jedes Mal eine retrospektive Analyse durchzuführen
- Nicht alle Aufgaben können mit Analoga abgeglichen werden.
Was ist, wenn Sie nicht die gesamte Aufgabe übernehmen, sondern jede in die endgültigen Arbeitskomponenten für unser System aufteilen (im gesamten Artikel werden wir die Internetbank der juristischen Personen, Web + mobile Kanäle, anrufen)?
In unserem Fall stellte sich Folgendes heraus:
- Ändern des Seitenlayouts
- Neue Dokumentenseite erstellen
- Abschluss des Formulars, Anzeige eines neuen Formularfelds aus der Datenbank
- Typische Kontrolle
- Komplexe Steuerung (komplexer nicht trivialer Algorithmus)
- DB-Schemaerweiterung
- SMS-Mailing-Skript
- Skript zum Versenden per elektronischer Signatur
usw. Zu Beginn der Positionen waren es ungefähr 20 und infolgedessen etwas mehr als 80.
Um die Arbeitsintensität jedes Blocks abzuschätzen, wurde eine Einheit erfunden - die Standardeinheit der Arbeitskosten (MEZ). SET ist ein abstraktes Maß für die Arbeitsintensität, es hat keine physikalische Bedeutung, es kann so genannt werden, wie Sie möchten. Durch eine retrospektive Analyse (für die letzten 3 Monate) haben wir (ich, der Systemanalytiker und der Teamleiter) alle Aufgaben in endgültige Komponenten unterteilt und die Komplexität jeder dieser Aufgaben proportional geschätzt (si). Das Ergebnis ist in der Tabelle (Tabelle 1) aufgeführt.
Jetzt können wir jede Aufgabe in SETs bewerten, zum Beispiel:
- Ziel: Implementierung eines Feedback-Formulars auf der Hauptseite des Systems, das für Kunden angezeigt wird, die kein Feedback gegeben haben. Das Formular zeigt Folgendes an:
- Bewertungsskala in Form von Sternen, durch Klicken auf die Sie eine Bewertung von 1 bis 5 abgeben können,
- ein Freiform-Eingabefeld mit einer Länge von 500 Zeichen,
- Wenn Sie auf die Schaltfläche Senden klicken, auf die die Daten in die entsprechende Datenbanktabelle geschrieben werden, wird das Formular geschlossen, ohne die Seite neu zu laden.
- Ermittlung der einfachsten Maßnahmen nach Tabelle 1 .:
- Erstellen einer Tabelle in einer vorhandenen Datenbank, Schreiben einer Formularanzeigelogik - 0,2 MEZ
- Formularlayout, 2 Felder + Vollständigkeitsprüfung - 1 MEZ
- Schreiben einer asynchronen Anforderung an die Serverseite, Schreiben einer Serverfunktion zum Schreiben in die Datenbank, - 1 SET
- Berechnung der Arbeitsintensität in SETs: 1 + 1 + 0,2 = 2,2 MEZ
Danach wurde der Begriff Produktivität (p) eingeführt, der die Produktivität jeder Entwicklerkategorie definiert (Tabelle 2).
Nun ist es möglich geworden, die Entwicklungsdauer jeder Aufgabe anhand der Formel zu schätzen: Fahren wir
mit unserem Beispiel fort
4. Bestimmung der Arbeitsdauer für einen Mitarbeiter der Kategorie Senior:
2,2 (MEZ) / 1,5 (MEZ / Tag) = 1,6 Tage
Dauer 1,6 Tage
Wir gehen davon aus: Mit Full-Stack-Entwicklern ist nur einer von ihnen an der Lösung jedes einzelnen Problems beteiligt.
Der Kunde mochte die Bewertungsmethode so sehr, dass er anbot, den Rest der Arbeitsphasen zu bewerten:
- Klärung der Anforderungen
- Implementierungsplanung
- Prüfung und Dokumentation
Im Verhältnis zur Entwicklungszeit wurden folgende Koeffizienten eingeführt (Tabelle 3):
Nun war es möglich, die Dauer jeder Stufe zu schätzen: die
gesamte Dauer der Änderungen am System gemäß der Formel:
zum Beispiel:
4. Bestimmung der Arbeitsdauer für einen Mitarbeiter (Analyst und Entwickler) der Kategorie Senior:
0,2 * 2,2 / 1,5 + 0,3 * 2,2 / 1,5 + 2,2 / 1,5 + 0, 2 * 2,2 / 1,5 = 0,3 + 0,44 + 1,6 + 0,3 = 2,64 Tage
Dauer 2,64 Tage
Als Ergebnis haben wir eine ziemlich verständliche Methodik erhalten, die Hauptversammlung (der Kunde, ich, der Systemanalytiker und der Teamleiter) hat beschlossen, sie auszuprobieren, die ersten Ergebnisse werden fortgesetzt ...