🦒 ✍🏼 🗒️ Auf Dornen und Sternen auf dem Weg zur Optimierung von Entwicklungsprozessen 😱 👩🏽‍🍳 🧝🏿

Träume, Träume

An kalten Herbstabenden versammelten wir und die Entwickler von 3D-Visualisierungsanwendungen in der Küche ... tranken Kaffee ... und dachten darüber nach ... über die Referenzorganisation der Entwicklung.

- Meine Freunde arbeiten agil für mich: Sprints, Story Points, alles ...
- Ja, wir würden zumindest überprüfen ...

Tatsache ist, dass es damals bei uns nicht sehr glatt war. Zum Beispiel war das Speichern von Projekten in Git sehr ungewöhnlich:

Es gab mehrere Repositories, und jeder Teil enthielt einen Teil des Projekts.
Einige Repositories waren üblich, einige bezogen sich nur auf einige Projekte, andere nur auf eines.
Um eine Arbeitskopie zu erhalten, mussten Sie den Inhalt aller Repositorys herunterladen und in bestimmten Ordnern ablegen.

Da wir mit 3D-Grafiken arbeiten und dann das Konzept „Steuerelemente + Vorlagen (die Position von Elementen auf dem Bildschirm, die Logik von Übergängen)“ verwendeten, waren die Dinge wie folgt:

Bei der Arbeit an Steuerelementen wurden Commits mit grundlegenden Steuerelementen an das Repository und möglicherweise mit Ressourcen an das Repository gesendet (wenn die bereits verwendeten dreidimensionalen Modelle an anderer Stelle verwendet werden müssten).
Bei der Arbeit mit Steuerelementen und Vorlagen (z. B. wenn der Hintergrund in der Anwendung unter dem Hilfefenster ersetzt werden musste) mussten die Bilder mit Ressourcen in das Repository hochgeladen und das Layout im Repository mit Vorlagen bearbeitet werden. Wenn der Hintergrund mit einem Skin (einzelner Stil) erstellt wurde, können 3 Repositorys beteiligt sein.

Bei diesem Ansatz waren Codeüberprüfungen ein Luxus für die Kosten:

Die Entwicklung wurde in einem einzigen Zweig durchgeführt.
Änderungen an einer Aufgabe betrafen mehrere Repositorys und die Verfolgung der Commits für welche Aufgabe war sehr problematisch.

Aufgrund der mangelnden Fähigkeit, aus Fehlern zu lernen, Erfahrungen auszutauschen und den Code des anderen während der Überprüfung zu analysieren, konnten Entwickler ihre Fähigkeiten nicht schnell genug verbessern. Und um Anwendungen "schneller" zu entwickeln, war es notwendig. Um die Entwicklungsgeschwindigkeit auf einem akzeptablen Niveau zu halten, wurden bei jedem neuen Projekt Mitarbeiter mit Aufgaben beauftragt, die ihren Aufgaben in früheren Projekten ähnlich waren. Das heißt, Wenn jemand zuvor mit einer 3D-Karte gearbeitet hat, hat er immer wieder Aufgaben im Zusammenhang mit Karten erhalten, oder wenn jemand einmal die „Diagramm“ -Komponente entwickelt hat, war er zum Scheitern verurteilt. Und das hat seine eigene Logik, weil schneller wird die Aufgabe von jemandem realisiert, der auf ähnliche oder identische Aufgaben gestoßen ist. Infolgedessen stellte sich heraus, dass sich die Entwickler auf bestimmte Dinge spezialisiert haben und nicht austauschbar sind.

Die Entwicklungsmethoden und ein klarer Workflow wurden aus mehreren Gründen ebenfalls nicht angewendet. Ausgehend von der Tatsache, dass hierfür viel Zeit aufgewendet werden musste, um alle Konzepte und Entwicklungsprozesse zu durchdenken, endete dies damit, dass es einfach niemanden gab, der sie brachte. Weder ich als zuletzt angekommener Angestellter noch die Jungs hatten die Befugnis, sich neu zu organisieren. Und es blieb nur zu murren und zu träumen.

"Wo ein Traum ist, gibt es immer eine Chance"

Für mich als Person, die seiner Arbeit nicht gleichgültig gegenübersteht, war es natürlich das Ziel, die Situation zu ändern. Was ist sonst der Sinn meiner Tätigkeit, wenn ich die bestehenden Prozesse nicht positiv beeinflussen und Menschen solche Arbeitsbedingungen bieten kann, unter denen sie ihre Fähigkeiten offenbaren und sich verbessern können? Die Entwicklung derjenigen, die die Anwendung erstellen und die auf Papier projizierte Idee verkörpern, zum Leben erweckt, ist die Entwicklung beider Projekte und des gesamten Unternehmens.

Eine gute Chance zur Erreichung des Ziels war die Entwicklung eines neuen Visualisierungsmoduls unserer Plattform. Dieses Projekt war nicht wie die anderen, weil Es war nicht die Entwicklung einer Anwendung auf der Plattform, sondern die Implementierung eines Teils der Plattform selbst. Daher waren wir hier nicht an das seltsame Konzept gebunden, Projekte in vielen Git-Repositories zu speichern und mit ihnen zu arbeiten, was mir eine großartige Gelegenheit schien, Codeüberprüfungen einzuführen.

Hier übrigens, was wir gemacht haben

Und eines schönen Wintermorgens griff ich den Projektarchitekten mit einem Vorschlag an, Gitflow einzuführen. Anfangs hielt er meine Idee für widersprüchlich, aber es gab Gründe dafür: Einige Standardmodelle sind nicht immer geeignet. Im Kommunikationsprozess wurde jedoch die am besten geeignete Option für dieses Projekt entwickelt, die wir jetzt erfolgreich einsetzen.

Unser modifizierter Gitflow lautet wie folgt:

Es gibt einen Hauptzweig (wir haben ihn Master genannt, aber Sie können einen beliebigen Namen angeben, um nicht verwirrt zu sein).
In Jira gibt es einen Sprint, der aus Rückstandsaufgaben besteht, die von einem Mikroziel vereint werden.
Der Entwickler nimmt die Aufgabe aus der Liste der offenen Aufgaben im Sprint in Bearbeitung und erstellt einen Feature-Zweig vom Master, der den Aufgabencode im Namen seines Feature-Zweigs angibt (z. B. PLAYER-55).
Sobald die Arbeit an der Aufgabe abgeschlossen ist, reicht der Entwickler seine Arbeit zur Überprüfung ein: Erstellt über Gitlab eine Zusammenführungsanforderung zum Master und überträgt die Aufgabe bei Überprüfung an Jira mit einem Link zur Zusammenführungsanforderung im Kommentar.
Wenn die Überprüfung abgeschlossen ist und alle Diskussionen geschlossen sind, wird die Aufgabe in Jira geschlossen, der Feature-Zweig wird in den Master zusammengeführt und gelöscht.
Wenn nach der Überprüfung Kommentare vorhanden sind - In Jira wird die Aufgabe aus der Überprüfung wiederentdeckt und der Algorithmus wird von Anfang an ausgeführt, außer dass der Feature-Zweig bereits erstellt wurde.

Wenn alle Aufgaben geschlossen sind, treten wir in die Release-Phase ein:

Der Release-Zweig wird vom Master weg aufgerufen, der zweistellig genannt wird, z. B. Release-3.0, wobei 3 die Versionsnummer des Projekts und 0 die Nummer des Release-Zweigs ist (der nächste Release-Zweig heißt Release-3.1 usw.). );
Weitere Tests des Release-Kandidaten werden durchgeführt (normalerweise die Entwicklung kleiner Demos);
Wenn beim Testen keine Fehler gefunden wurden, ist der Release-Kandidat für die Produktion bereit: Das letzte Commit im Release-Zweig ist mit einem aus 3 Ziffern bestehenden Produktions-Tag gekennzeichnet (z. B. prod-3.0.0, wobei 3 die Projektversionsnummer 0 ist - Release-Zweignummer, 0 - Produktionsversionsnummer), dann bleibt der Release-Zweig im Master stecken und wird im Gegensatz zum klassischen Gitflow nicht gelöscht.
Wenn immer noch Fehler gefunden werden, werden sie in Jira als Fehler registriert. Der Fehlerbehebungsprozess ähnelt der Arbeit mit einer Aufgabe im Feature-Zweig (er wird nur ab Release, nicht vom Master überprüft). Wenn alle Fehler geschlossen sind, setzen wir das Produktions-Tag. Die Version wird an das Produkt ausgegeben und der Release-Zweig wird in den Master zusammengeführt, ohne gelöscht zu werden.

Falls Fehler in der Produktion gefunden werden, gibt es auch eine Vereinbarung:

Die Arbeit an solchen Fehlern wird auch im Release-Zweig dieser Version des Verkaufs durchgeführt. Wenn die Änderungen dringend sind, werden sie als Hotfix markiert und direkt im Release-Zweig mit Teamleitern ausgeführt.
Andernfalls ähnelt die Arbeit an solchen Fehlern der Arbeit an Fehlern, die im Release Candidate gefunden wurden.

Warum genau Gitflow und genau das?

Das Eingeben von Feature-Zweigen ist eine Möglichkeit, eine Überprüfung einzuführen, mit der Sie Erfahrungen austauschen, die allgemeine Teamqualifikation verbessern und vor allem vermeiden können, dass Code von geringer Qualität in das fertige Produkt gelangt, das keinen gemeinsamen Stil hat, schwer zu verstehen und voller Fehler ist.
Ich denke, viele Leute sind mit der Situation vertraut, in der das Projekt gemäß den Vorgaben und Spezifikationen bewertet wird, ein Budget dafür zugewiesen wird, Sie die Funktionalität gemäß den Anforderungen in der Dokumentation implementieren, aber hier wird aus dem Nichts jemand von den Chefs erscheinen und Sie hören: „Oh, aber Fügen wir hier ein paar Einhörner hinzu, die dem Kunden gefallen werden. “,„ Und können Sie die Gelegenheit nutzen, einen Freund in dieser Region anzurufen, indem Sie auf eine Region auf der Karte klicken? Es wird eine Bombe sein, fahren Sie fort “,„ Wir müssen eine Legende hinzufügen “,„ Jetzt muss die Legende entfernt werden und auch die Signaturen “,„ Das Entfernen von Signaturen war überflüssig, geben Sie sie zurück. “ Und das alles ist "kostenlos ohne Registrierung und SMS". Und dann stellt sich bei der Berechnung der tatsächlichen Kosten heraus, dass die Entwicklung mit einer so geringen Anzahl von Aufgaben zu viel Zeit gekostet hat (schließlich werden „Anfragen“ in Jira normalerweise nicht registriert, da nicht jeder Entwickler den Chef ablehnen oder ihn zur Registrierung seiner „Anfrage“ schicken kann. ", Und das kann verstanden werden). Durch die Einführung der Regel zum Benennen einzelner Zweige mit Jira-Code und die Unfähigkeit, Zweige ohne Bindung an Jira zum Master zusammenzuführen, werden nicht registrierte Arbeiten und Konflikte vermieden, die auftreten können, wenn der Entwickler mit dem Herunterladen von Rechten beginnt und Sie die "Anfrage" als Aufgabe in Jira ausfüllen müssen. Außerdem können Sie sich ein klares Bild davon machen, wie viel Arbeit tatsächlich geleistet wurde (Aufgaben in Jira werden durch den ihnen zugeordneten Code bestätigt, Code durch Kommunikation mit der registrierten Aufgabe).
Die Verbindung von Gitflow mit Jira im Hinblick auf die Aktualisierung des Aufgabenstatus hilft, eine Situation zu vermeiden, in der mehrere Personen dieselbe Aufgabe ausführen. Wenn Sie den Status entsprechend der Gitflow-Phase aktualisieren, werden alle feststellen, dass solche und solche Aufgaben bereits ausgeführt oder überprüft werden. Für sie gibt es bereits Funktionszweige, in die Code geschrieben ist, und Sie müssen sie nicht übernehmen. Es ist auch klar ersichtlich, wer was tut und was funktioniert, kann sich gegenseitig beeinflussen, welche der Jungs sollten sich häufiger an eine bestimmte Implementierung wenden und sich darauf einigen, damit bei einer Fusion die Codekonflikte nicht für eine lange und schmerzhafte Zeit gelöst werden müssen.
Da wir eine Plattform zum Erstellen von Anwendungen entwickeln, sollten Sie berücksichtigen, dass die fertigen Produkte von jemandem von unserer Politik abhängen, alte Versionen der Plattform zu unterstützen und neue einzuführen. Es ist möglich, dass einige Benutzer der Plattform aus irgendeinem Grund die neueste Version der Plattform verwenden und einen Fehler im Zusammenhang mit der Plattform finden. Wenn wir Release-Zweige löschen, können wir unseren Benutzern in einer solchen Situation nicht helfen, insbesondere wenn die Funktionen, die sie in ihrer Version verwenden, in der neuen Plattformimplementierung gelöscht oder geändert werden. Dementsprechend können Sie durch Speichern von Release-Zweigen Benutzern Unterstützung bieten, die nicht mit der neuesten Version der Plattform arbeiten.

Was ist mit Agile?

Wie Sie wahrscheinlich bereits bemerkt haben, näherten wir uns langsam den Prinzipien der agilen Scrum-Entwicklung, beginnend mit der Aufteilung der Aufgaben in Sprints für Mikroziele.

Als nächstes wurden Planning Poker, Story Points, Teamgeschwindigkeitsanalyse und Retrospektive vorgestellt.
Durch die Teilnahme an Planning Poker und die Zuweisung von Story Points zu Aufgaben kann das Team das Projekt, die Struktur seiner Architektur, das, was wir im Allgemeinen anstreben und was das Ergebnis sein sollte, ganzheitlicher betrachten. Menschen erhalten die Möglichkeit, systemisch und nicht nur im Rahmen ihrer Aufgaben zu denken. Dies wirkt sich sowohl auf ihre Entwicklung als Fachkräfte als auch auf das Projekt selbst positiv aus:

Es werden neue nützliche Funktionen angeboten, da Entwicklern klarer wird, was und wo im Allgemeinen verbessert werden kann.
häufiger werden Fehler und Mängel festgestellt, die erst zum Zeitpunkt des Betriebs der Plattform deutlich erkennbar werden können.

Aufgrund der Verfügbarkeit von Daten zur Anzahl der im Sprint erledigten Aufgaben und den entsprechenden Story Points wird es möglich, die Geschwindigkeit des Entwicklungsteams zu analysieren, um in Zukunft kompetentere Planungs- und Zeitschätzungen durchführen zu können.

Es stimmt, dass diesbezüglich im Rahmen unseres Projekts ein gewisser Ärger herrscht: Die Zusammensetzung des Teams ändert sich sehr oft, da einige Entwickler regelmäßig für dringende Projekte weggenommen werden und diese durch freie Projekte ersetzen. Aus diesem Grund wird die Geschwindigkeitsschätzung jedes Mal zurückgesetzt. Unter solchen Bedingungen ist es fast unmöglich zu zählen. Die einzige Möglichkeit, die sie gefunden haben, besteht darin, Daten zu jeder Komposition für 3-4 Sprints zu sammeln und dann zu versuchen, den Durchschnittswert zu ermitteln.

"Und lass uns schnell gehen" oder 3 vollwertige Demo-Anwendungen für einen Monat

Natürlich hat niemand die Anwendungsentwicklung abgebrochen. Vor allem, wenn sie notwendig sind, um die globalen Ziele des Unternehmens zu erreichen. Besonders wenn es sehr dringend benötigt wird. Und in letzter Zeit hat der Bedarf an einer schnellen Implementierung von Demo-Anwendungen für Shows erheblich zugenommen.

Nachdem ich in einem neuen Paradigma gearbeitet hatte, wollte ich natürlich überhaupt nicht zu alten Gesprächen zurückkehren. Dann entschieden wir uns, Teile des neuen Visualisierungsmoduls zu verwenden (als integriertes System war es noch nicht vollständig auf diese Aufgaben vorbereitet), wobei wir die Prinzipien seiner Entwicklung als Leitfaden verwendeten.
Da sich noch nicht alle Entwickler mit dem Workflow-Thema befassten und die Anpassung der Mitarbeiter an das neue Entwicklungsgerät ein großes Risiko hinsichtlich des Zeitpunkts unserer „brennenden“ Demos darstellte, haben wir versucht, einen bestimmten „Mittelweg“ zwischen der Vergangenheit und hoffentlich der Zukunft zu finden. Infolgedessen geschah Folgendes mit der teilweisen Verwendung der Prinzipien des neuen Visualisierungsmoduls für Demos:

Kleine Teams. 2-3 Entwickler, Designer, Tester und Manager.
Parallele Entwicklung (zuvor wurden zuerst Steuerelemente erstellt, dann Vorlagen mit dem Erscheinungsbild und der Logik der Anwendung).
Verwenden von Aufgaben wie Story in Jira. Da es keine klaren Spezifikationen und TK gab, sammelte ich alle verfügbaren Informationen zum erwarteten Verhalten und Erscheinungsbild der Anwendung und fügte alles in Story ein. Dann wurden sie an ihnen getestet, was eine positive Reaktion unter den Testern hervorrief, da alle Informationen an einem Ort gesammelt wurden, aber gleichzeitig in funktionale Teile unterteilt wurden, was die Überprüfung erleichterte. Und das gesamte Team musste keine offiziellen Texte lesen, um die Aufgabe richtig zu verstehen und abzuschließen. Im Gegensatz zu Word-Dokumenten mit Spezifikationen wurde Story schneller aktualisiert, die Benutzer erhielten schnell Beschreibungen mit neuen Verbesserungen und begannen dementsprechend, sie schneller zu implementieren.
Gitflow mit Entwicklungs- und Master-Zweigen, jedoch ohne Funktion:

Die gesamte Entwicklung wurde im Entwicklungszweig durchgeführt. Um jedoch das Vorhandensein nicht registrierter Aufgaben auszuschließen, muss jedes Commit mit dem Aufgabencode von Jira gekennzeichnet sein, in dessen Rahmen es ausgeführt wurde.
Als alle für das Release geplanten Aufgaben gelöst waren, wurde ein neuer Build zusammengestellt: Der Teamleiter führte eine Überprüfung des Entwicklungszweigs durch, und wenn alles in Ordnung war, wurden die Änderungen mit der Zuweisung eines Tags mit der Build-Nummer zum Master zusammengeführt. Wenn während der Überprüfung grobe Fehler und Unregelmäßigkeiten aufgedeckt wurden, wurde der Code zur Überarbeitung gesendet und erst nach Eingabe und erneuter Überprüfung in den Master übernommen.
Builds wurden mit zwei Ziffern nummeriert, z. B. 0,1 - dies ist immer die Nummer des ersten Testbuilds, wobei 0 - zur Produktionsversion gehörend bedeutet, 1 - Buildnummer. Bei der Anzahl der nächsten Test-Builds erhöhte sich die letzte Ziffer, bis der Tester und der Manager zu dem Schluss kamen, dass der Build für die Ausgabe in der Produktion bereit ist. Wenn dies der vierte Testbuild (0,4) war, wurde es dementsprechend der erste Produktionsbuild (1,0) und das entsprechende Tag wurde in den Hauptzweig eingefügt. Wenn in der Produktion Fehler festgestellt werden und der Produktionsbuild zur Bearbeitung gesendet wurde, erhöht sich auch die zweite Ziffer, wenn alle nachfolgenden Builds (1.1, 1.2 usw.) nummeriert werden.

So haben wir im Laufe eines Monats drei vollwertige Demo-Anwendungen implementiert, die wir positiv bewertet haben und die weiterhin nützlich sind. Bisher konnten wir solche Funktionen nicht so schnell und mit so vielen Mitarbeitern im Team implementieren.

Meiner bescheidenen Meinung nach

Was denke ich persönlich darüber?

Dass die Organisation von Prozessen das Ergebnis wirklich beeinflusst und dass das Hören der Welt der Entwicklungspraktiken, die von den Entwicklern selbst erfunden und an ihnen orientiert wurde, nicht nur „stilvoll, modisch, jugendlich“ ist, sondern notwendig (nachdem wir die Demos zum ersten Mal seit mehreren Jahren der Praxis bestanden haben, haben wir den Rest fortgesetzt Projekte und saß erst in der Nacht weitere 2 Wochen nach der Lieferung und schwitzte das Gesicht des Haufens, der vom Kunden entdeckt wurde (beschämende Mängel).
Das Ausmaß an Chaos, Missverständnissen und Stress bei Projekten mit einem klaren Workflow ist geringer (die Mitarbeiter sind besser mit relevanten Informationen ausgestattet und wissen, wo sie diese bei Bedarf erhalten können).
Der richtige Einsatz von Projektmanagement-Tools wirkt sich auf die Entwicklung der Projekte selbst und ihrer Teilnehmer aus (aufgrund der Optimierung der Entwicklung in Gitlab, Jira, der Einführung der Prinzipien des agilen Scrums wurde es möglich, Erfahrungen in einem Team auszutauschen, Fähigkeiten in einem Team zu pumpen, häufiger wurden Wissen und Erfahrungen von Junior-Teamleitern übertragen und mittlere Entwickler).

Hier ist das Geheimnis

Trotz der obigen Schlussfolgerungen wurde mir noch etwas anderes klar:

- Nicht jeder ist bereit für das, wovon er träumt.

Manchmal, wenn wir etwas von der Seite betrachten, scheint es uns, dass dies etwas Gutes, Nützliches, Notwendiges für den Erfolg, Richtiges und Referenz ist. Aber der Traum ist es wert, Wirklichkeit zu werden, wie wir ihn verstehen: "Das habe ich mir nicht vorgestellt." Also in der Arbeit: Es scheint, dass Sie jetzt solche Bedingungen haben, unter denen "normale Unternehmen" arbeiten, und Sie werden gedeihen. Aber leider. Und es kommt vor, dass Sie, ohne Energie zu sparen, versuchen, den Menschen etwas zu geben, von dem sie als Erfolgsgarantie geträumt haben, aber ein Wunder geschieht nicht: Die Arbeit wird immer noch nicht in hoher Qualität ausgeführt, und Sie verstehen, dass Sie möglicherweise das Typische von jemandem akzeptiert haben Worte der Unterstützung für ein Küchengespräch für echte Bestrebungen und Träume.

Bei der Einführung neuer Regeln und Prinzipien wurden wir nicht nur mit positiven Rückmeldungen und Ergebnissen konfrontiert, sondern auch mit einer negativen Wahrnehmung dessen, was geschah. Für einige schien die Arbeit mit Jira und Gitlab viel Aufhebens zu sein, und diese Wahrnehmung zu ändern war äußerst schwierig, bis die Leute auf eine problematische Situation stießen, die aufgrund des Ignorierens des allgemein akzeptierten Workflows auftrat. Einige Aufgaben wurden immer noch nachlässig ausgeführt, Beschreibungen in Story und Problemstellungen wurden nicht berücksichtigt oder als „persönliche Anfragen“ wahrgenommen und trotz der Registrierung bei Jira mit einer klaren Aussage nicht ausgeführt.Im Allgemeinen wurden immer noch Builds mit schlechter oder unangemessener Implementierung der Einstellungen festgestellt, und einige Fehler wurden von Build zu Build erneut geöffnet. Obwohl das Endergebnis in allen Demos positiv war, dachte ich immer noch darüber nach, dass es uns mit den für die Arbeit Verantwortlichen, die sich um das höchstmögliche Ergebnis kümmern, gelungen ist, nicht nur die erforderlichen Funktionen zu implementieren, sondern auch neue Funktionen einzuführen, die Anwendung zu optimieren und "Füge Ryushechek hinzu." Und mit Teams, in denen es sich jemand leisten konnte, zu faul zu sein, oder die weniger daran interessiert waren, ein Ergebnis von höchster Qualität zu erzielen, haben wir auf zusätzliche Anfrage des Kunden nach der Lieferung nur die Grundfunktionalität und einige kleine Funktionen implementiert.

Und dann kam mir vielleicht meine wichtigste Schlussfolgerung:

- Kein Prozess, keine Technologie - der wahre Schlüssel zum Erfolg, sondern diejenigen, die die Idee kreieren, kreieren, in die Realität umsetzen - Menschen und ihre Einstellung zu ihrer Arbeit. Ein Musiker, der seine Seele in seine Arbeit steckt, wird das Publikum beeinflussen und selbst das billigste und unbequemste Instrument spielen. Und gib ihm Stradivari - er wird das Publikum verrückt machen. Und es gibt diejenigen, denen selbst der Stradivarius zumindest die neueste Entwicklung der führenden Werkzeughersteller bietet - alles wird nicht klingen.

Sie können Menschen komfortable Bedingungen und Spitzentechnologien bieten, aber am Ende erhalten Sie ein unbefriedigendes Ergebnis ihrer Aktivitäten, weil "und so geht es". Und es ist möglich, dass Sie, wenn es nicht die erfolgreichsten und manchmal sogar die kompetentesten Implementierungstechnologien behindert, ein anständiges Ergebnis erzielen, weil diejenigen, die es erreicht haben, es sich nicht leisten können, unfertige oder schlecht erledigte Arbeiten zu übergeben. Und es ist sehr wichtig, solche Teammitglieder zu erkennen, zu unterstützen, ihnen zuzuhören und günstige Bedingungen für ihre Aktivitäten zu schaffen.

Technologie und die Organisation von Prozessen wirken sich wirklich auf das Ergebnis aus und sind sehr wichtig, aber der Hauptschlüssel zum Erfolg liegt in talentierten, verantwortungsbewussten und entwicklungsorientierten Menschen.