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
