Vor kurzem, durch einen guten Menschen angeregt, entstand die Idee, jede Artikel mit einer kurzen Zusammenfassung zu versehen. Nicht einfach eine Anmerkung oder ein Köder, sondern eine wirkliche Zusammenfassung. So, dass man den Artikel auch ganz weg lassen könnte.
Ich habe es ausprobiert und es hat mir unglaublich gut gefallen. Aber das ist egal – das Wichtigste ist, dass es den Lesern gefallen hat. Die, die lange aufgehört hatten zu lesen und mich als Schreiberling bezeichnet hatten, fangen wieder an. Ein anderer guter Mensch hat mir geraten, auch für jeden alten Artikel eine kurze Zusammenfassung zu schreiben. Ich habe zugestimmt und schreibe jetzt nebenbei diese Kurzfassungen. Ich habe sie Shorts genannt.
Ich möchte Ihnen einige dieser Shorts zu mehreren Publikationen anbieten. Vielleicht finden Sie etwas Nützliches für sich.
Die Katze ist gestorben, der Schwanz ist ausgefallen.
Besprechungen verlaufen sehr oft ergebnislos. Man kommt zusammen, plaudert und geht wieder auseinander.
Die Ergebnisse oder Produkte einer Besprechung sind Entscheidungen. Allerdings gibt es die meistens nicht. Und wenn sie da sind, sind sie nicht immer von guter Qualität.
Wenn eine Besprechung zeitlich begrenzt ist und eine Entscheidung unbedingt getroffen werden muss, ist die Entscheidung oft von niedriger Qualität.
Wenn das Meeting nicht zeitlich begrenzt ist und bis zur Entscheidungsfindung dauert, wird jede Entscheidung akzeptiert, solange das Meeting beendet ist.
Wenn eine Entscheidung im Meeting getroffen wird, wird sie angenommen – einfach weil das Gehirn das schätzt, was es sich ausgedacht hat.
Das Verständnis für die geringe Qualität der Entscheidung kommt später, aber dann ist es bereits zu spät.
Um eine effektive Entscheidung zu treffen, ist es besser, sich nicht an der Diskussion zu beteiligen, sondern still zuzuhören.
Erstens wird das Gehirn nicht mit dem Finden von Antworten beschäftigt sein.
Zweitens gibt es nicht den Druck, eine Entscheidung zu treffen.
Nach dem Meeting kann man in Ruhe nachdenken und eine Entscheidung treffen. Diese wird von höherer Qualität sein.
Das Wichtigste: Im Meeting schweigen und zuhören. Um den Anwesenden keine Sorgen zu bereiten, kann man sagen, dass dies eine bewusste Haltung ist.
→
Latente Parasiten
Grundsätzlich gibt es zwei Ansätze zur Aufgabenstellung und zur Kontrolle der Ausführung: parasitär und symbiotisch.
Der symbiotische Ansatz besteht darin, sicherzustellen, dass die Aufgabe gelöst wird.
Der parasitäre Ansatz besteht darin, sicherzustellen, dass die Aufgabe NICHT gelöst wird.
Der symbiotische Ansatz ist direkt und unkompliziert, aber schwierig umzusetzen. Daher kommt er selten vor.
Die Aufgabe wird so formuliert, dass alles klar ist – Ziele, Ressourcen und Einschränkungen.
Die Kontrolle wird so durchgeführt, dass die Aufgabe definitiv gelöst wird.
Der symbiotische Ansatz bedeutet, einen Teil der Verantwortung (insbesondere den größeren) für die Lösung der Aufgabe beim Aufgabenersteller zu belassen.
Der parasitäre Ansatz ist kompliziert und ausgeklügelt, aber einfach umzusetzen. Daher kommt er häufig vor.
Die Aufgabe wird so formuliert, dass nichts klar ist. Je weniger klar, desto besser.
Kontrolle sollte idealerweise überhaupt nicht stattfinden.
Der Aufgabenersteller trägt keinerlei Verantwortung; alle "Probleme" werden dem Ausführenden aufgebürdet.
Das Ziel des parasitären Ansatzes: Manipulation, übersteigertes Ego, Selbstbestätigung. Daher kommt er häufig in der Arbeit von Mentoren mit neuen Mitarbeitern vor.
Der symbiotische Ansatz ist natürlich besser.
→
Messungen vs. Illusionen
Wenn man den Prozess und die Ergebnisse seiner Tätigkeit ohne Messungen bewertet, wird man immer falsch liegen.
Die Bewertung ohne Zahlen hängt von der Stimmung ab. Schlechte Stimmung – es scheint, dass Sie schlecht arbeiten. Gute Stimmung – im Gegenteil.
So kann man eine Woche lang schlecht arbeiten und am Freitag ein Ergebnis präsentieren, das den Anschein erweckt, die gesamte Woche sei gut verlaufen.
Prinzipiell gibt es zwei Arten von Metriken: quantitative und alternative (von Programmierern auch bekannt als Boolesche).
"Aufgabe fristgerecht erledigt" – das ist Boolesch. Dasselbe gilt für "Teil ist gut" (ein alternatives Qualitätsmerkmal, wenn es keine messbaren Zahlen gibt).
"Wir arbeiten gut", "Wir erfüllen unseren Plan", "Ich bin großartig" – das sind ebenfalls Boolesche.
Auf Bewertungen wie Boolesch ist es schwierig, ein Management aufzubauen. Es wird empfohlen, so schnell wie möglich zu quantitativen Metriken überzugehen.
Boolesch schafft Bürokratie und Formalismus. Beispielsweise kann die fristgerechte Erledigung von Aufgaben durch verlängerte Fristen, das Erfinden von Aufgaben oder das Durchführen von IBD erreicht werden.
Um basierend auf Booleschen Indikatoren zu managen, muss man viel Zeit investieren – für Meetings, Analysen usw. Denn die Informationen sind einfach zu wenig.
Es wird empfohlen, sowohl den Prozess als auch das Ergebnis zu messen. Dann wird das Bild am vollständigsten.
Für Programmierer wird die Methode "Planning Poker" aus Scrum empfohlen.
→
Das ist Sparta
Angenommen, Sie sind Programmierer und haben eine schwierige Aufgabe bekommen. Sie glauben jedoch, dass die Aufgabe unnötig und schädlich ist.
Typisches Verhalten in einer solchen Situation: die Aufgabe im öffentlichen Raum zur Diskussion stellen. Sie schicken sie zur Genehmigung an den Vorgesetzten, starten ein internes Projekt, dokumentieren es im System usw.
An diesem Punkt beginnt alles zu scheitern. Die Person, die die Aufgabe gebracht hat, möchte nicht als Idiot dastehen. Sobald sie im öffentlichen Raum ist, wird sie sich verteidigen.
Es ist wichtig, nicht das Gesicht zu verlieren, im politischen Sinne. Das Wichtigste in der Politik ist es, niemals seine Fehler einzugestehen. Man kann nichts tun, aber man sollte keine anerkannten Fehler haben.
Die Person wird alles daran setzen, zu beweisen, dass der Programmierer der Bösewicht, Idiot und Gegner des Wandels ist. Und der Programmierer wird die Aufgabe letztendlich dennoch lösen müssen.
In einigen Fällen wird die Person alles so organisieren, dass der Programmierer die Aufgabe überhaupt nicht löst. Dann ist die Person 'der Gute', während der Programmierer völlig 'der Böse' ist (sowohl im Widerstand als auch im letztlichen Versagen).
Es gibt mehrere Lösungen.
Erstens – werden Sie Business-Programmierer, setzen Sie sich mit angrenzenden Bereichen auseinander und bestimmen Sie selbst, was automatisiert werden muss und wie.
Zweitens – der Artikel über den Chief Change Officer. Zum Beispiel der Entwicklungsdirektor.
Drittens – nicht aufmucken und einfach das tun, was gesagt wird.
Viertens – der Weg Spartas, schnelle Eliminierung von Lösungen. Besser bekannt als fail fast, fail cheap (scheitere schnell, scheitere günstig).
Wichtig ist, keine Öffentlichkeitsarbeit zu fördern. Sagen Sie der Person: "Lass uns nicht viel Zeit verschwenden, lass uns einen Prototyp erstellen und sehen, ob die Lösung tragfähig ist oder nicht."
Ein Prototyp wird nicht viel Zeit in Anspruch nehmen. Im Erfolgsfall profitieren beide – sowohl von einer funktionierenden Lösung als auch von politischen Punkten.
Im Falle des Misserfolgs wird niemand leiden. Und die Person wird eine bessere Meinung über den Programmierer haben.
→
Surrogate
Die Wirtschaft hat eine Abneigung gegen 1C und ihre Produkte, Webentwickler, QM-Systeme, Buchhaltung, Ökonomen, Entwicklungsprojekte, Scrum, TOC, Controlling, KPIs und Motivation Systeme.
Unternehmen lieben es, ihre Rentabilität durch Automatisierung zu steigern, den Umsatz durch Online-Marketing zu erhöhen, die Produktqualität zu verbessern, ein einfaches und klares Bild des Geschäfts in Zahlen zu erhalten, Prognosen über den Unternehmenszustand aufzustellen, die Effizienz tatsächlich zu steigern, die Projektdurchführung um das 2- bis 4-Fache zu beschleunigen, die Gewinne deutlich zu steigern und Bestände zu reduzieren, ein präzises Managementsystem zu haben sowie ein klares und verständliches System zur Bewertung der Unternehmenslage und zur Arbeitsbewertung, das es ermöglicht, die Hälfte der Manager zu entlassen.
Unternehmen lieben es, ihre Geschäftsziele zu erreichen. Unternehmen mögen keine Surrogate.
Ein Surrogat ist, wenn man darum gebeten wurde, ein Geschäfts-Ziel zu erreichen, aber ein Automatisierungsprojekt, eine Website, einen Haufen Papier, ein Team unverständlicher Mitarbeiter oder unlesbare Berichtstexte erhalten hat.
Ein Surrogat ist, wenn das Ziel unterwegs durch ein Mittel zum Zweck ersetzt wurde. Und alle haben das Ziel gemeinsam vergessen.
Die Produktion von Surrogaten beruht auf drei Säulen: Formalismus, Schritt-für-Schritt-Vorgehen und Klientelismus.
Formalismus bedeutet, die Ziele auf Papier zu bringen und sie zu zerlegen. Tatsächlich wird dabei der Fokus von dem großen Ziel auf kleine Details verschoben. An das Ziel erinnert sich niemand mehr – alle diskutieren die Einzelheiten.
Schrittweise — das ist eine langsame Geschwindigkeit des Übergangs von Zielen zu Mitteln. Zu Beginn wird das Ziel manchmal noch diskutiert. Doch allmählich, Schritt für Schritt, wird immer seltener darüber gesprochen. Bis der Auftraggeber schließlich ganz vergisst, dass es das Ziel gibt, während er sich in den Details verliert.
Die gegenseitige Absicherung besteht darin, dass alle Auftragnehmer in etwa gleich handeln. Es gibt keinen Automatisierer, der tatsächlich den Gewinn steigert. Daher hat der Auftraggeber kaum andere Optionen.
Was tun?
Vermeiden Sie Surrogate und den ersten Schritt auf dem Weg zu deren Schaffung: Formalismus. Das gilt zumindest für interne Projekte. Setzen Sie ein Ziel und sprechen Sie ständig mit dem Ausführenden darüber. Auch über das Maß, Ressourcen, Pläne usw. — das ist ebenfalls wichtig. Aber das Wichtigste ist das Ziel.
Andernfalls wird sich der Fokus zwangsläufig verschieben, und Sie erhalten ein weiteres Surrogat.
→
Wladimir Klitschko
Es gibt einen Boxer — Vladimir Klitschko. Er hat eine Besonderheit — die ständige Verwendung des Jab. Nun, d.h. häufiger als bei anderen Boxern.
Der Jab hält den Gegner ständig unter Druck und erschöpft ihn.
Die wichtigsten Merkmale des Jab von Klitschko: relative Einfachheit in der Ausführung und Beständigkeit.
Viele Autoren sprechen darüber, dass kontinuierlich durchgeführte, nützliche, aber einfache Handlungen einen großen Nutzen bringen können.
Ich habe auch beschlossen, es auszuprobieren. Ich habe ein einfaches System zur Erfassung erstellt – welche Aufgaben ich heute erledigt habe.
Es geschah in einer Fabrik. Ich habe während des Mittagessens gearbeitet (ich mache keine Pause), also 1 Stunde am Tag. Ich habe das gemacht, was andere nicht tun (man sagt, das führt zum Erfolg).
Ich habe die Prüfungen eines selbstlernenden Systems eingestellt, Ideen zur Entwicklung ausgearbeitet, fremde Ideen umgesetzt, Automatisierungsaufgaben konfiguriert, Code refaktoriert und optimiert.
Jeden Tag – eine beliebige Aufgabe aus dieser Liste. Eine Aufgabe erledigt – großartig. Man kann auch mehrere machen.
Ich habe drei Monate lang Beobachtungen angestellt. In dieser Zeit habe ich 30 Prüfungen durchgeführt, 200 Ideen entwickelt, 80 fremde Ideen umgesetzt, automatisierte Prozesse für zwei Abteilungen aufgebaut und drei großartige Optimierungen vorgenommen.
Cool, oder? Das ist ja "nebenbei". Kann ich jedem empfehlen.
→
Flexibles Surrogat
Mit dem Begriff "Scrum" werden mindestens zwei Entitäten bezeichnet: Philosophie und Framework.
Die Philosophie oder der Arbeitsansatz ist in dem Buch von Jeff Sutherland beschrieben.
Das Framework, d.h. der Handlungsalgorithmus, wird im Dokument mit dem Titel Scrum Guide beschrieben.
Die Philosophie hat sich in ein Framework verwandelt, weil die Autoren der Philosophie damit Geld verdienen wollten (nach eigenen Aussagen).
Das Framework ist im Vergleich zur Philosophie stark vereinfacht. Das Hauptaugenmerk liegt auf der Vereinfachung, genauer gesagt, das Ziel wurde vollkommen ausgeklammert.
Das Ziel der Philosophie: die Beschleunigung der Ergebniserreichung. Und zwar um ein Vielfaches. Im Buch gibt es Beispiele für eine Beschleunigung um das Achtfache.
Das Ziel des Frameworks: dass Sie Scrum haben. Es steht dort so geschrieben: Wenn Sie nach Anleitung handeln – haben Sie Scrum, brechen Sie die Anleitung – haben Sie kein Scrum.
Das Framework sieht keine Beschleunigung der Ergebniserreichung vor, überhaupt nicht.
Die Menschen, die Scrum unterrichten oder implementieren, arbeiten mit dem Framework. Sie erklären und implementieren einen Algorithmus, der zu keinen Ergebnissen führt, außer "Wir haben jetzt Scrum".
Die Essenz ist klar. Die Philosophie zu verkaufen, ist sehr schwierig. Ein Framework ist einfacher.
Das Framework ist ein Produkt. Es hat, wie es sich gehört, eine "Verpackung" durchlaufen. Es ist einfach, verständlich, es gibt Unterstützung und viele Fachleute. Kommt Ihnen das bekannt vor?
Alles ist gut, nur das Ergebnis – das gibt es nicht.
Wenn der Auftraggeber mit der Philosophie von Scrum nicht vertraut ist, wird ihn die Implementierung des Frameworks durchaus zufriedenstellen.
Wenn der Kunde mit der Philosophie von Scrum vertraut ist, wird er von der Einführung des Frameworks enttäuscht sein – es wird keine Beschleunigung bei der Erreichung der Ergebnisse geben.
Es wird cool, modern und zeitgemäß sein, aber keine Geschäftsziele werden erreicht (außer dem Ausgeben des Budgets für „etwas Neues“).
Was tun? Die Philosophie von Scrum studieren. Sie basiert auf der japanischen Management-Philosophie für Qualität, deren Kern die Messung und kontinuierliche Verbesserung ist.
Leider muss man viel denken, experimentieren, beobachten und, leider, arbeiten. Wenn Ihnen das nicht passt, nehmen Sie das Framework.
→
Quelle: habr.com
