So steigern Sie die Entwicklungseffizienz mithilfe der Constraints-Theorie

Guten Tag!

Ich möchte einen kleinen Exkurs in die praktische Anwendung der Randbedingungstheorie für die IT anbieten. Und zwar in Bezug auf die Berechnung des „Durchsatzes“ der Abteilung für die Entwicklung unternehmensinterner Software.

Über das CBT (Theory of Constraints) und das Mega-Buch "Goal" von Elia Goldratt wurde viel geschrieben, auch über Habré, damit ich gleich zur Sache komme.

Die Abteilung, für die ich verantwortlich bin, unterstützt und entwickelt mehrere sogenannte "Inhouse" -Informationssysteme, hauptsächlich WMS und TMS - Lager- und Transportmanagementsysteme. Weiterhin werde ich mich nur auf diese Systeme und nur einen Teil des Geschäfts konzentrieren - die Dienstleistungen eines Logistikunternehmens.

Täglich werden ein Dutzend neue Aufgaben in unser Postfach eingegeben, von denen viele mit "Dringend!", "Wichtig!" usw.

Gegenwärtig ist der Rückstand auf rund siebenhundert Aufgaben unterschiedlicher Komplexitätsklassen angewachsen.

Um dieses Volumen irgendwie zu verwalten, haben wir ein System von Prioritäten eingeführt, das sich nach dem Grad des Einflusses auf das Geschäft richtet:

A - Systemausfälle oder Probleme, die es nicht ermöglichen, die vertraglichen Verpflichtungen (für das Hauptgeschäft) vollständig zu erfüllen.

B - Aufgaben im Zusammenhang mit dem Umsatzwachstum des Unternehmens - dh der Ankunft neuer Kunden.

C - Aufgaben im Zusammenhang mit der Verbesserung der Rentabilität, dh Aufgaben zur Optimierung der Produktivität (Gesamtsysteme, Arbeitsprozesse, Mitarbeiter, Produktionswachstum usw.).

D - Verbesserungen auf Wunsch unserer Kunden (Berichte, Integration mit Transportunternehmen usw.).

Innerhalb dieser Kategorien gibt es eine andere Unterteilungsebene (A1, A2, ...), für die Zwecke des heutigen Artikels ist dies jedoch nicht wesentlich.

Logischerweise sollte die Ausführung der Aufgaben in der folgenden Reihenfolge erfolgen: ABCD.

In der Praxis ist ein Entwicklungsplan das Ergebnis einer Vielzahl von Kompromissen. Zum Beispiel stehen Aufgaben der Kategorie D häufig ganz oben im Rückstand (Kundenorientierung, ja).

Das heißt, das Prioritätssystem gibt in der Tat nur eine allgemeine Richtung für die Planung vor, erlaubt es jedoch nicht jedem, die Frage objektiv zu beantworten: "Warum dauert meine Aufgabe nicht so lange?"

Wir haben auch das Problem von kleinen und großen Kunden, die ungefähr die gleiche IT-Ressource ausgeben. Theoretisch sollten dickere Kunden Vorrang haben, aber Sie sollten auch keine kleinen Kunden verlassen. Außerdem erfordert ein kleiner Kunde häufig besondere Aufmerksamkeit, als würde er nicht zwei Gazellen pro Woche, sondern zumindest einen Containerzug versenden.

Nachdem wir dies verstanden haben und verstanden haben, dass das Unternehmen eine kommerzielle Organisation und keine Wohltätigkeitsorganisation ist und in erster Linie rentabel sein muss, haben wir uns entschlossen, das Planungssystem mithilfe der Restriktionstheorie zu pumpen.

Die Einschränkung in unserem Fall ist die Entwicklungsressource.

CBT führt ein neues Konzept für den Geschäftsdurchsatz ein, eine bedingte „Umsatzgenerierungsrate“, die kontinuierlich erhöht werden sollte. Im Gegensatz zu den Kosten ist das Wachstum der Passage theoretisch nicht durch irgendetwas begrenzt und kann (kann) zur Unendlichkeit tendieren.

Bei den Entwicklern verwenden wir die Angabe der Arbeitsstunden in Rubel als Maß für den Durchgang.

Der Algorithmus sieht ungefähr so ​​aus:

1. Für jede Aufgabe ist es notwendig, die wirtschaftlichen Auswirkungen der Umsetzung zu bewerten. Dies kann eine Einsparung von Arbeitsstunden oder eine Einsparung einer anderen Ressource sein (z. B. knappe Quadratmeter im Expeditionsbereich oder Palettenplätze im Lagerbereich oder Ladestunden). Wünschenswert in Tausend Rubel / Jahr. Der Kunde hat eine solche Beurteilung vorzunehmen. Wenn er dies nicht alleine kann, wird er sich an seinen Vorgesetzten wenden.
2. Nachdem die Aufgabe hinsichtlich ihrer Wirkung bewertet wurde, geht sie an die Timlid-Studie oder an einen der Unterzeichner. Als Ergebnis erhalten wir eine gewisse vorläufige Schätzung der Kosten.
3. Teilen wir die erste in die zweite, erhalten wir genau die Passage - die Geschwindigkeit, mit der der Effekt erzielt wird.
4. Wir ordnen die Aufgaben im Rückstand in absteigender Reihenfolge der Übergänge.
5. Schneiden Sie ein Stück Rückstand über dem nächsten Plan / Sprint ab.

Zum Beispiel gibt es ein Problem, dessen Auswirkung der Kunde auf 100 Tausend Rubel geschätzt hat. pro Monat oder 1,2 Millionen Rubel. Im Jahr.
Für die Implementierung benötigen wir 40 Stunden Entwicklungszeit.
Der Durchlauf beträgt folglich 1200/40 = 30 konventionelle Einheiten.

Für eine andere Aufgabe, die erwartete Wirkung von 50 Tausend Rubel. pro Monat, aber die Implementierung wird 100 Stunden dauern. Insgesamt 600 Tausend Rubel / 100 = 6 c.u.

Am Ende werden wir beide Aufgaben erledigen. Aber zuerst die erste und dann die zweite.

Zurück zu den Prioritätskategorien bilden wir einen separaten Korrekturstrom (Kategorie A), starten dann neue Kunden (Aufgaben werden gemäß den bestehenden Fristen geplant), und der Rest der Zeit wird von der Entwicklung eines neuen Systems zur Bewertung der Bestehens bombardiert.

Der Vorteil dieser Technologie ist, dass es objektiv ist. Trotz aller Annahmen - wie der Kunde den Effekt eingeschätzt hat, Ungenauigkeiten bei der Bewertung der Komplexität, die Ebene des Entwicklers, der es implementieren wird - vermittelt es ein reales Bild wichtiger und unwichtiger Aufgaben aus geschäftlicher Sicht.

Und was ist mit Kategorie D, fragst du? Wie ist der Wunsch des Kunden, insbesondere der Kleinen? Wie haben sie sich in das neue Schema eingefügt?

Diese Frage ist noch offen.

Um ein objektives Bild zu erhalten, ist es auch erforderlich, die wirtschaftlichen Auswirkungen zu bewerten, jedoch bedingt indirekt. Das heißt, die Reputation des Unternehmens, Kundenorientierung, potenzielles Geschäftswachstum von diesen Kunden, gute Referenzen anziehen. Es gibt subtilere Fragen, wir besprechen zusammen mit dem Vertrieb und dem Kundendienst, wie diese Indikatoren digitalisiert werden können.

Das ultimative Ziel ist es, ein objektives, transparentes System für die Erstellung von Aufgaben zu erhalten, mit dem Sie die Nutzung der Entwicklungsressource maximieren können. Vielleicht kann man als Harmonie nur danach streben, aber die Beschränkungstheorie besagt eindeutig, dass das „Ziel“ erreichbar ist.

Irgendwie so.

Bis zum nächsten Teil des Rebusses werde ich das Ergebnis teilen.

PS: Bis auf weiteres werden die Themen Refactoring und verschiedene Infrastrukturaufgaben nicht behandelt. Wir werden später darauf zurückkommen.