Get best of the week

Kanban-Methode: Verstehen Sie Ihren Prozess als kollektiven Lernprozess

Vorwort


In der russischsprachigen Fachgemeinschaft der Prozessmanager gibt es nur sehr wenig Literatur zur Kanban-Methode in russischer Sprache. Wir haben beschlossen, diese Ungerechtigkeit zu korrigieren, und wir werden die aus unserer Sicht wichtigsten Artikel auf Russisch veröffentlichen, die die Entwicklung der Methode beeinflusst haben.

Verstehen Sie Ihren Prozess als kollektiven Lernprozess


Und der erste Artikel in der Reihe darüber, wie Sie effizienter eine Visualisierung Ihrer Arbeitsprozesse erstellen und ein Board wahrnehmen können. Der Autor des Originalartikels ist Alexei Zheglov und ist hier zu finden .

Es gibt einen allgemeinen Trend und den Wunsch, die Arbeit kollektiver zu gestalten. Wenn ich jedoch die Mitarbeiter im Büro auffordere, einen Prozess ihrer Arbeit zu zeichnen, bieten sie häufig Folgendes an (ich vereinfache):


In dieser Ansicht bilden die Arbeiter ein Förderband, aber ihre Arbeit sieht nicht wirklich wie ein Fließband aus. Beispielsweise kann ein Softwareentwickler eine logische Inkonsistenz in der Anforderungsspezifikation erkennen und die Arbeit an Business Intelligence zurücksenden. Ein Qualitätsingenieur (QS) kann dasselbe tun, wenn er erstellte Software testet. Der Analyst aktualisiert die Spezifikation und sendet die Aufgabe an die Qualitätssicherung zurück. QA kann einen Fehler darin finden und ihn an den Entwickler zurücksenden. Ein Implementierungsspezialist findet möglicherweise etwas im Code, das die Zustellung verhindert. Dann nimmt der Entwickler die notwendigen Änderungen vor. Jetzt muss der Code erneut getestet werden, damit er zur Qualitätssicherung zurückkehrt und anschließend zur Implementierung zurückkehrt.

Eine solche Interaktion findet nicht nur zwischen einzelnen Teammitgliedern statt, sondern (wichtig) auch zwischen Unternehmensabteilungen, Services und funktionsübergreifenden Teams. Daher zeichnen die Benutzer viele Pfeile, die in verschiedenen Konfigurationen verbunden sind, um alle diese Programme anzuzeigen.

Einige versuchen, diesen Prozess auf einer Tafel zu visualisieren, die sie "Kanban" nennen:


Dann fragen sie sich: Was ist, wenn der Tester beispielsweise das Arbeitselement an den Analysten oder Entwickler zurücksendet? Sollte die Karte an Ort und Stelle bleiben oder sich bewegen? Was ist, wenn wir ein WIP-Limit haben (diese Nummern befinden sich in den Spaltenüberschriften)? Was ist, wenn diese Spalte bereits bis zum Limit gefüllt ist, sollte eine andere Karte zurückgehen?

Gibt es einen besseren Weg?


Diese Frage ist weit verbreitet und beruht auf einem Missverständnis der Art der professionellen Servicearbeit. Anstelle einer Reihe von Übertragungen zwischen spezialisierten Jobs geht es hauptsächlich darum, Informationen zu erstellen und Wissen zu sammeln. Dies wird zu einem Hindernis, wenn versucht wird, den Prozess wie ein Flussdiagramm aussehen zu lassen. Sowie eine Einschränkung beim Versuch, es nach der Ausführung der Arbeit zu visualisieren.

Im Beispiel der Bereitstellung neuer Funktionen eines Softwareprodukts kann das folgende Wissen erstellt werden (nicht unbedingt in dieser Reihenfolge):

  • genaue Konfiguration der Arbeitsumgebung (Betriebssystem, Webserver, Datenbankserver, Software von Drittanbietern)
  • Schlüsselbeispiele für das Verhalten der entwickelten Funktionalität, Anwendungsfälle, Akzeptanzkriterien, ausführbare Spezifikationen usw.
  • ( , . .)
  • -
  • : , , ..
  •   , .

Jeder in einem professionellen Service kann seine eigene Wissensliste erstellen, die er in seinem Lieferprozess erstellt. Wenn die Arbeit abgeschlossen ist, ist all dieses Wissen bereits vorhanden, aber wenn wir gerade erst anfangen, an den Bedürfnissen des Kunden oder der Anfrage nach der Lieferung von etwas zu arbeiten, fehlt dies alles.

Wenn wir versuchen würden, den Prozess der Anhäufung dieses Wissens zu visualisieren, könnte das Ergebnis folgendermaßen aussehen:


In diesem Beispiel dominiert die Spezifikationsarbeit in einem frühen Stadium des Lieferprozesses. Geschäftsanalysten können eine Funktionsanalyse, Zerlegung und Verfeinerung von Anforderungen durchführen. Gleichzeitig können aber auch andere Fachkräfte einen Beitrag leisten. Tester können dabei helfen, Akzeptanzkriterien in ausführbare Tests umzuwandeln. Bereitstellungsspezialisten und Entwickler können die Auswirkungen auf die Codebasis und die Infrastruktur bewerten.

Diese Aktivität erzeugt am Anfang viel Wissen, aber am Ende verblasst sie. Wir können nicht endlos bis zur Lieferung analysieren. Somit wird die Entwicklung von Code irgendwann zum Hauptweg, um Wissen anzusammeln.

Natürlich fällt der größte Teil der Codeentwicklung auf die Schultern der Entwickler, aber auch andere können helfen. Die Anforderungen müssen möglicherweise noch geklärt und geklärt werden (Hallo Analyst). Der Tester kann teilweise vorgefertigte Software nehmen, testen und dem Entwickler Feedback geben. Entwickler können mit Implementierungsspezialisten zusammenarbeiten, um festzustellen, wie sich neu auftretende Änderungen auf die Bereitstellung auswirken.

Aber diese Aktivität wird verblassen. Wir können keine weiteren Fortschritte erzielen, indem wir den Code polieren. Also fahren wir mit dem Testen fort.und konzentrieren Sie sich auf die Behebung verbleibender Fehler. Eine andere Aktivität im Studium des Wissens beginnt zu dominieren. Tester sind dafür verantwortlich, benötigen jedoch Hilfe von Entwicklern, Fehlerbehebungen und anderen Spezialisten.

Beachten Sie, dass die drei Wendepunkte im neuen Prozessdiagramm keine Übertragungen zwischen Funktionsspezialisten oder Abteilungen sind. Dies sind Änderungen der dominanten Aktivität und entsprechende Änderungen des Interaktionsmusters.

Fazit


Wir müssen Prozesse nicht als Netzwerk von Spezialisten und als Übertragung von Autorität betrachten. Wenn wir versuchen, unsere Prozesse visuell zu visualisieren, müssen wir sie nicht in Form von Blöcken darstellen, die Spezialisten darstellen, und viele Pfeile, die sie in alle Richtungen verbinden.

Stattdessen können wir unseren Lieferprozess als Informationsbeschaffung und Wissensschaffung betrachten. Wenn wir uns die Frage stellen, welche Aktionen wir ausführen, um Wissen zu sammeln, um das zu liefern, was wir liefern , können wir unseren Prozess als eine Folge gemeinsamer Aktionen visualisieren.

Was kommt als nächstes?


In den nächsten Artikeln möchte ich Beispiele für die Reflexion des Prozesses der Wissensakkumulation für Prozesse außerhalb der Welt der Softwareentwicklung geben.

Ich muss eine Reihe von Artikeln als Empfehlungen vorbereiten: Wie ein Prozessspezialist mit professionellen Serviceteams eine Reflexion von Prozessen erstellen kann . Für diejenigen, die Kanban-Systeme verwenden, hat dieser Ansatz mehrere Vorteile beim Entwurf und Betrieb dieser Systeme.

Vielen Dank an Aleksey Pimenov undStepev.

More articles:


All Articles