JH Rainwater "Wie man Katzen weidet" (Teil 2): ​​Alles, was technisch zu meistern bleibt

Wir teilen weiterhin Auszüge aus dem Survival Guide für Anfänger-Techlides von J. H. Rainwater. In der ersten Reihe haben wir darüber gesprochen, mit welcher Art von Entwicklern der Manager normalerweise arbeiten muss. Versuchen wir nun zu verstehen, was wir mit dem ganzen Zoo anfangen sollen. Organisatorische Aktivitäten in einem technischen Team lassen sich in zwei Teile aufteilen - mehr oder weniger native Dinge (wie Codeüberprüfungen und Architekturmanagement) und alles, worauf sich das Leben eines Programmierers nicht vorbereitet hatte - das Verwalten von Personen und Prozessen. Beschäftigen wir uns zuerst mit einem Fremden.

Priorisierung

Das erste, was einen frisch gebackenen Anführer normalerweise niederschlägt, ist eine Lawine unterschiedlichster Informationen. Dieser Sachverhalt ist ganz logisch: Derjenige, der an der Spitze des Teams steht, ist in seinem Rahmen weniger geschlossen und in mehr Prozesse involviert, aber es wird nicht einfacher. Infolgedessen beginnt sich der technische Leiter häufig zu zerstreuen. Angesichts seiner Pflicht, auf jedes Signal zu reagieren, ergreift er alles auf einmal, springt von einer Aufgabe zur nächsten und verpasst das, was am meisten Aufmerksamkeit erfordert.

Es gibt nur einen Ausweg: Diesen Informationsstrom herauszufiltern, die direkt mit der Hauptaufgabe zusammenhängenden Elemente zu trennen (einen Code veröffentlichen, der die kommerziellen Anforderungen erfüllt, mit einer vereinbarten Frist) und den Hauptdatenstrom an das Backlog zu senden. Zunächst sind die Kriterien für eine solche Sortierung jedoch möglicherweise nicht eindeutig. Für Anfänger scheint absolut alles wichtig.

Erschwerend kommt hinzu, dass viele Reize Emotionen anregen, die die vernünftige Einschätzung der Bedeutung und Dringlichkeit eines Problems beeinträchtigen. Die eingehenden Signale können Interesse erregen (es wurde eine merkwürdige Anomalie im Code festgestellt), Schuldgefühle (der Designer erinnert sich, dass er bereits mehrmals um die Implementierung der Funktion gebeten hat, die er implementieren möchte), Befürchtungen (der Benutzer äußert sich unzufrieden mit dem Update).

Um alle Anfragen und Informationen erfolgreicher zu systematisieren, empfiehlt der Autor die Verwendung der folgenden Matrix für deren Verarbeitung:

• Wie wirken sich die neuen Daten auf den Projektumfang, die Entwurfsentscheidung und den Projekttermin aus?
• Ist die Informationsquelle zuverlässig? Wenn nicht, kann es ignoriert werden?
• Soll ich sofort auf den Eingang der Informationen reagieren oder kann ich etwas warten?
• Wo und wie können Informationen gespeichert werden, damit sie bei Bedarf schnell adressiert werden können?
• Was ist die Gültigkeitsdauer der Informationen? Wann wird es irrelevant?
• Wie vergleichen sich diese Informationen mit dem, was bereits über das Projekt bekannt ist?

Wie Sie sehen, hilft diese Matrix in mehrfacher Hinsicht dabei, Körner von der Spreu zu trennen: Entfernen Sie offen gesagt nutzlose oder unzuverlässige Informationen, entfernen Sie alles, was sonst noch bewegt werden kann, und bewerten Sie die Wichtigkeit von Informationen ausschließlich für das aktuelle Projekt. Fragen zu Timing und Speichermethoden deuten jedoch darauf hin, dass die derzeit nicht relevanten Informationen nicht als prinzipiell irrelevant abgetan werden sollten - dies ist ein weiteres Extrem, das das Team langfristig zur Stagnation führen wird. Wir werden später mehr darüber sprechen, wenn wir die Konzepte „Führung“ und „Führung“ diskutieren.

Ausgedehnte Projekte

Der nächste Schmerzpunkt ist die Beurteilung von Volumen und Arbeitsbedingungen. Auch hier ist das „Schwimmen“ in diesem Bereich für einen Anfänger-Techlide für einige Zeit fast unumgänglich - Erfahrung ist erforderlich, um alle Komponenten des Projekts auf einmal überprüfen zu können, ohne etwas zu verpassen, und vom ersten Versuch an, für jede Art von Arbeit geeignete Bedingungen festzulegen, einschließlich ungewohnter Bedingungen. Aber selbst die gesammelten Erfahrungen retten einen bestimmten Fehler nicht und können nicht auf Null reduziert werden. Die äußerste Genauigkeit bei der Arbeitsplanung wird durch zwei Gesetze behindert, die Humphrey treffend formuliert hat:

Jeder Prozess dauert länger als erwartet. Es erscheint immer etwas, an das Sie nicht gedacht haben.

Auf dieser Grundlage ruft der Autor dazu auf, das Problem philosophisch zu behandeln. Höchstwahrscheinlich können Sie in erster Näherung weniger offensichtliche Funktionen oder unvorhersehbare Komplikationen nicht berücksichtigen und benötigen eine zusätzliche Ressource, die Sie nicht hypothekarisch belastet haben. Für solche Überraschungen muss man sich vorbereiten und ein Team bilden - um die Leute zu lehren, schnell wieder aufzubauen, um "Löcher zu flicken", um ihnen ein wenig Zeit für unvorhergesehene Umstände zu lassen. Was auf keinen Fall getan werden kann, ist, natürliches Wachstum als Notfall zu betrachten und die Schuldigen zu suchen, insbesondere in anderen Abteilungen (und dies sieht immer besonders verlockend aus). Sie säen also nur Feindschaft zwischen den Teams und tun nichts, um das Problem zu lösen.

Dennoch sollte man nicht in völligen Fatalismus verfallen: Das Wachstum des Projekts ist dennoch das Ergebnis von Planungsfehlern. Sie werden sie nicht vollständig beseitigen können, aber Sie können und sollten die Konzentration verringern.

Wenn wir die Gesetze von Humphrey auf die Realität des Programmierers übertragen, wird deutlich, dass die Planung aus zwei Gründen nachlässt: unzureichende Detailanalyse und unnötig optimistische Schätzungen der Dauer des Softwareproduktdesigns. Der Optimismus unter den Managern schwankt normalerweise auf natürliche Weise: Wenn Sie mehrmals die Fristen brechen, werden Sie zwangsläufig auf Nummer sicher gehen. Was das Detail angeht, so bringt diese Fähigkeit auch Erfahrung mit, aber es lohnt sich von Anfang an, sich einen allgemeinen Überblick darüber zu verschaffen, wie die Roadmap aussehen sollte.

Wenn Sie beispielsweise ein Projekt starten, das mit einem solchen Dokument ausgestattet ist, liegen viele Naturkatastrophen und Probleme vor Ihnen:



Wenn die Roadmap der folgenden Stichprobe ähnlicher ist, steigen die Chancen auf ein zufriedenes Ergebnis erheblich:



Neben diesen beiden Gründen listet Rainwater einige zusätzliche Risikofaktoren auf, die Robert Glass, Autor eines traurigen Buches über Katastrophenprojekte im IT-Bereich, hervorhob:

• Unzureichende Spezifikation der Projektziele
• Anwendung der Technologie neu für dieses Unternehmen
• Jährliche / fehlende Projektmanagement-Methodik
• Mangel an führenden Experten in der Gruppe
• Vertragsunterbrechung durch Hard- / Softwarehersteller

Gemeinsame Sprachsuche

Sie denken vielleicht, dass wir über Kommunikationsfähigkeiten kommunikativer Talente sprechen - aber nein, die Bedeutung des Titels ist viel wörtlicher. In verschiedenen Unternehmen werden Teams von Programmierern aus unterschiedlichen Gründen gebildet. Wenn Sie Glück haben, sind Sie möglicherweise für Personen verantwortlich, die mit Ihrem nativen Technologie-Stack arbeiten. Sehr oft stoßen wir jedoch auf gemischte Teams, in denen verschiedene Mitarbeiter verschiedene Sprachen sprechen. Solche Verwirrung macht dem Führer manchmal das Leben schwer.

Eine der Aufgaben des Leiters ist es, alle Aktivitäten des Teams zu überwachen, um sicherzustellen, dass der gesamte Code, der in die Welt geht, funktioniert, qualitativ hochwertig und ohne übermäßige Komplexität. Wenn Sie nicht mit den Tools vertraut sind, die Ihre Untergebenen beim Entwickeln verwenden, sind Ihnen die Hände gebunden. Sie können Code-Überprüfungen nicht unabhängig durchführen. Sie werden erst in der Testphase über schwerwiegende Fehler informiert, die den gesamten Arbeitsrhythmus beeinträchtigen. Grob gesagt ist es viel einfacher, an der Nase herumzufahren.

Was ist in dieser Situation zu tun? Im Allgemeinen gibt es zwei Möglichkeiten. Wenn die Menge der Sprachen und Technologien nicht zu groß und änderbar ist, können Sie keine Zeit verlieren und versuchen, sie zumindest auf einem Grundniveau zu meistern. Dies ist vielleicht der beste Ausweg. Sie müssen sich also nicht auf jemanden verlassen, sondern erhalten Informationen direkt. So können Sie das „tote Telefon“ vermeiden, wenn Sie Funktionen, Anforderungen und Fristen besprechen.

Wenn es nicht möglich ist, die erforderlichen Sprachen selbst zu lernen, müssen Sie nach Möglichkeiten suchen, diese Verantwortung zu delegieren. Bilden Sie den Kern der Assistenten, die Ihnen objektives und ehrliches Feedback zu jeder unbekannten Technologie geben können (wenn nur ein Mitarbeiter diese besitzt, funktioniert diese Methode natürlich nicht).

Die Vertiefung Ihres Wissens in technologischen und werkzeugbezogenen Fragen ist auch aus einem anderen Grund nützlich - nur so können Sie im wahrsten Sinne des Wortes zum technischen Vorreiter werden. In seinem Terminologiesystem unterscheidet der Autor die Begriffe „Manager“ und „Leiter“. Ein Manager ist einer, der die Arbeit organisiert, alltägliche Probleme löst und dafür sorgt, dass die aktuellen Aufgaben rechtzeitig und ordnungsgemäß erledigt werden. Ein Leader ist ein Stratege, der außerhalb der Kontrollfristen denkt, die allgemeine Bewegungsrichtung für sein Team festlegt, die Messlatte höher legt, überdenkt und Prozesse optimiert. Natürlich erfordert eine solche visionäre Arbeit im Entwicklerteam eine gute Kenntnis des Technologiemarktes. Im Hintergrund schätzt der technische Leiter ständig, dass das aktuelle Toolkit veraltet ist und ausgetauscht werden muss, überwacht neue Produkte und hat gleichzeitig eine hinreichende Perspektive, um ihre tatsächlichen Vorzüge zu beurteilen (und nicht in das Stunt-Syndrom zu fallen).

Im ersten Teil des Artikels haben wir darüber gesprochen, dass der Leiter sich keine Sorgen machen muss, dass er die Arbeit mit Technologie aufgeben wird - und für diejenigen, die Leiter markieren, ist dies in der Tat so. Aber hier ist es sinnvoll, die Warnung von der gleichen Stelle aus zu wiederholen: nicht gleichzeitig hoffen, den Verantwortlichkeiten des Managers zu entgehen. Management beinhaltet die Balance zwischen den beiden Rollen, die manchmal in Konflikt geraten, aber fast gleich bleiben (Management ist etwas minderwertig) und für das Überleben des Teams notwendig sind. Verbessern Sie Ihre organisatorischen Fähigkeiten zu Ihrem Vorteil - je weniger Zeit eine Routine benötigt, desto schneller wachsen Sie als technischer Experte. Wenn alltägliche Aufgaben dem Zufall überlassen werden, herrscht Chaos, in dem es keine Strategie mehr gibt.

Flock Kommissionierung

Nun wenden wir uns dem zweiten Block von Problemen zu - der berüchtigten Arbeit mit Menschen. Beginnen wir von vorne: Bevor Sie über die Verwaltung einer Personalressource sprechen, müssen Sie herausfinden, wo Sie sie erhalten. Selbst wenn Sie das etablierte Team haben, wird sich früher oder später die Frage nach der Einstellung von Mitarbeitern stellen. Zuvor haben wir die Arten von Programmierern analysiert und auf diejenigen hingewiesen, die zuerst verfolgt werden sollten. Jetzt müssen Sie verstehen, wie Sie handeln müssen, um die erforderlichen Eigenschaften der Kandidaten zu identifizieren und nicht von ihrer Wahl enttäuscht zu werden.

Der Autor gibt folgende Empfehlungen für Interviews:

• Geben Sie dem Kandidaten eine Testaufgabe. Stellen Sie einem potenziellen Mitarbeiter eine Aufgabe, die er entweder sofort lösen muss, oder bringen Sie sie zu sich nach Hause und lösen Sie sie bis zum Fälligkeitsdatum.
• Stellen Sie sicher, dass Sie eine mündliche Prüfung der Fähigkeiten des Kandidaten durchführen, damit Sie sowohl sein Wissen als auch die Fähigkeit, in einer stressigen Situation klar zu denken, bewerten können.
• Notieren Sie so weit wie möglich die Pflichten des gewünschten Mitarbeiters und alle Aufgaben, die er ausführen muss, und geben Sie diese Liste dem Kandidaten zur Überprüfung. So wird das Gespräch sofort objektiver und in der Regel offener.
• Beschränken Sie sich nicht auf eine Besprechung. Es ist sehr gut, wenn der Kandidat nicht nur mit Ihnen, sondern auch mit dem oben genannten „Kern“ kommuniziert - Ihren Assistenten, Stellvertretern, führenden Entwicklern im Team. Aber es lohnt sich nicht, eine Show mit dem ganzen Team zu arrangieren, das ist schon zu viel.
• Die Überprüfung persönlicher Eigenschaften, typologische Tests und dergleichen sind ein möglicher, aber optionaler Schritt. Greifen Sie nur dann darauf zurück, wenn der Kandidat keine Einwände hat und Sie über zuverlässige Bewertungsinstrumente verfügen.

Apropos Einstellung, man kann nur die Kehrseite erwähnen - die Entlassung von Arbeitern, die das Team herunterziehen. Hier nimmt Rainwater eine ziemlich harte Position ein und rät ohne zu zögern, diejenigen loszuwerden, die sich als inkompetent oder problematisch erwiesen haben. Die beste Position ist die Politik einer Warnung: Sie gibt einer Person die Möglichkeit, sich zu verbessern, lässt jedoch keinen Missbrauch dieses Rechts zu. Wenn ein Mitarbeiter in die „schwarze Liste“ geraten ist und Sie ein Gespräch mit ihm geführt haben, müssen Sie seine weiteren Erfolge mit besonderer Sorgfalt überwachen. Dies erfordert zusätzlichen Aufwand, so dass eine dritte Chance bereits eine ungerechtfertigte Verschwendung darstellt.

Darüber hinaus leidet nicht nur die abstrakte „gemeinsame Sache“ in der Regel unter der Nachlässigkeit eines Teammitglieds, sondern auch an ganz bestimmten Personen, die seine Fehler korrigieren oder sich damit abfinden müssen, dass er die Ergebnisse ihrer Arbeit verdirbt. Übermäßiger Genuss wird daher auf seine Kosten bezahlt und stärkt wahrscheinlich nicht Ihre Führungsposition.

Arbeitsorganisation der Mitarbeiter

Komfortables Wohnumfeld

Das Buch widmet diesem Aspekt große Aufmerksamkeit. Die maximale Produktivität Ihrer Mitarbeiter zu erreichen, liegt in der direkten Verantwortung des Marktführers. Eine hohe Produktivität erfordert jedoch eine hohe Konzentration. Eine Konzentration ist unmöglich, wenn der Programmierer von allen Seiten irritiert ist. Daher muss der Leiter alles in seiner Macht Stehende tun, um dem Team gute Arbeitsbedingungen zu bieten.

Die spezifischen Empfehlungen für die Gestaltung eines Büros, die Rainwater an bestimmten Orten gibt, klingen etwas idyllisch (z. B. in einem separaten Büro für einen Bruder), und an bestimmten Orten klingen sie wie Echos einer fernen und schwierigen Vergangenheit (jeder Entwickler muss seinen eigenen Computer haben). Das allgemeine Prinzip bleibt jedoch weiterhin vernünftig und anwendbar: Damit Programmierer bei ihren Aktivitäten Erfolge erzielen können, müssen sie die Möglichkeit haben, einerseits einige Zeit in einem Team zu arbeiten und andererseits nur eine Gehirnwäsche durchzuführen. Zum einen benötigen Sie entsprechend ausgestattete Trainingsräume: Besprechungsräume mit Projektoren, Freizeitmannschaften (idealerweise) mit den berüchtigten Tennistischen oder Spielkonsolen. Zum anderen muss der verfügbare Raum so organisiert werden, dass die Menschen durch Lärm, Flimmern, Gerüche und andere störende Faktoren möglichst wenig abgelenkt werden. Wenn die Bedingungen schlecht sind, lassen Sie Mitarbeiter, insbesondere diejenigen, die wertvoll und zuverlässig sind, von zu Hause aus arbeiten.

Zu den obligatorischen Mindestannehmlichkeiten gehört auch eine moderne, hochwertige Ausstattung, die der Entwickler nach eigenem Ermessen konfigurieren kann. Wenn die Autos schwach und veraltet sind, müssen Sie nicht über technologische Durchbrüche sprechen, und Sie haben nicht nur einen leisen, störungsfreien Betrieb. Für Testprogramme sollten spezielle Geräte zugewiesen werden, die die Standardbenutzereigenschaften wiedergeben.

Arbeitszeit

Das von uns skizzierte Aufgabenspektrum des technischen Beraters legt nahe, dass sich die Dauer seines Arbeitstages nahezu verdoppeln sollte. Aber hier musst du vorsichtig sein. Das Problem ist, dass der Manager selbst mit seinem Arbeitsregime unfreiwillig den Ton für die gesamte Abteilung vorgibt. Wenn Sie zu spät sitzen, gehen die Mitarbeiter davon aus, dass auch von ihnen etwas Ähnliches erwartet wird. Infolgedessen kann die Verarbeitung in das Fleisch und Blut Ihrer lokalen Kultur eindringen - und dies ist mit Problemen behaftet.

Erstens wird nicht jeder mit dieser Situation zufrieden sein. Zuallererst wird die Verarbeitung diejenigen treffen, die durch zusätzliche Verpflichtungen belastet sind, zum Beispiel familiäre. Wenn es viele solcher Leute gibt, ist die Situation im Team angespannt. Nun, und zweitens weist der Autor, wie viele andere auch, darauf hin, dass zusätzliche Arbeitsstunden die Produktivität mit größerer Wahrscheinlichkeit beeinträchtigen - sowohl aufgrund von Müdigkeit als auch aufgrund einer geringeren Motivation. Es ist klüger, von der Schule effektive Arbeit im Unterricht zu fordern, als Gewohnheiten einzuführen, die zu Burnout führen.

Aufgabenverteilung und -überwachung

Seien wir ehrlich: Selbst ideale Bedingungen und ein schonender Zeitplan werden die Menschen nicht dazu ermutigen, sich selbst zu organisieren und fleißig zu arbeiten. Unter anderem wird ein Chef benötigt, um die Arbeit zu verteilen und sicherzustellen, dass sie ausgeführt wird. Ein Teil Ihrer Zeit sollte mit Kontrolle belegt sein - dies trägt übrigens auch zur Konzentration bei.

Der Autor rät, die „Berichtsperioden“ nicht zu sehr für die Untergebenen aufzuteilen, sie nicht mit ständiger Beobachtung und täglicher Forderung nach Ergebnissen zu ersticken. Es ist sinnvoller, für jede Woche eine Aufgabenliste zu erstellen und den Arbeitsaufwand für denselben Zeitraum zu bewerten. In besonders heißen Zeiten müssen die Listen aufgrund dringender Probleme und Änderungen der Prioritäten auch in diesem kleinen Intervall angepasst werden. Der Leiter muss all diese Veränderungen im Auge behalten (und in der modernen Realität - und sie in die entsprechenden Buchhaltungssysteme einfließen lassen).

Wenn eine Führungskraft zu einem „ausländischen“ Team mit einem bereits festgelegten Arbeitsrhythmus kommt, ist es sinnvoll, jeden Mitarbeiter zu bitten, seine üblichen Aufgaben auf die gleiche Weise zu malen. Eine solche Dokumentation kann viele interessante Dinge enthüllen - nicht nur wer und was involviert ist und wie die Geschäftsführung zuvor gearbeitet hat, sondern auch, was die Leute im Allgemeinen über ihre Verantwortlichkeiten denken.

Der Inhalt dieser Listen wird natürlich in vielerlei Hinsicht von den Fähigkeiten der Mitarbeiter und den Anforderungen des Unternehmens bestimmt. Bei alledem geht das Buch jedoch auf die Idee ein, dass es notwendig ist, Aufgaben so weit wie möglich zu drehen - der Entwickler sollte nicht von Woche zu Woche dasselbe tun. Dafür gibt es mehrere Gründe. Erstens hilft es, ein gesundes Klima im Team aufrechtzuerhalten: kein Ärgernis, weil jemand ständig die unangenehmsten oder umgekehrt interessantesten Dinge bekommt, weniger Gefühl von Routine und Eintönigkeit bei der Arbeit. Zweitens müssen Programmierer intellektuell in guter Verfassung bleiben - eine Vielzahl von Aufgaben wird dazu beitragen. Schließlich ist bei einem solchen Wechsel ein Minimum an Aufwand erforderlich, um eine Bank zu bilden.

Der Reinwater misst der Bank einen hohen Stellenwert bei. Die Hauptidee dabei ist, dass im Falle einer Krankheit, eines Urlaubs, einer Entlassung oder eines vorzeitigen Todes eines der Entwickler Personen in das Team aufgenommen werden sollten, die in der Lage sind, ihre Funktionen zu erfüllen - zumindest für diesen Zeitraum, bis sie einen Ersatz einstellen. Dies stellt nicht nur den reibungslosen Betrieb der Abteilung sicher, sondern vermeidet auch einige andere Probleme (zum Beispiel die akute Abhängigkeit des Unternehmens von Assistenten). Dementsprechend ist es notwendig, das Interesse der Mitarbeiter an relevanten Technologien in jeder Hinsicht aufrechtzuerhalten, um die Zusammenarbeit und Teilnahme an "ausländischen" Projekten zu fördern.

Übrigens ist der Chef selbst nicht vor herabfallenden Ziegeln geschützt. Überlegen Sie sich daher, sobald Sie sich daran gewöhnt haben, wen Sie zu Ihrem Nachfolger machen würden. Dies ist nicht nur eine Rückversicherung, sondern auch eine gute Übung für die Delegation von Aufgaben - bei der Vorbereitung eines Nachfolgers müssen Sie sich unabsichtlich überlegen, welche Arbeit für andere am einfachsten und sichersten ist. Beim Stöbern wird dieses Wissen sehr nützlich sein.

Und das Letzte: Bisher ging es hauptsächlich um die Interessen der Mannschaft und der Vorgesetzten, aber vergessen Sie nicht, dass wir immer noch mit Menschen zusammenarbeiten. Persönliche Vorlieben und Eigenschaften der Mitarbeiter sollten nach Möglichkeit berücksichtigt werden. Sie sollten keine besondere Mobilität von jemandem erwarten, der kaum von einem zum anderen wechseln kann, Sie sollten aus Gründen der Gerechtigkeit die Bremsen nicht zu einer Aufgabe schicken, die er nicht zu bewältigen fürchtet und so weiter. Auch hier stützen wir uns auf die These, dass wir unsere Mitarbeiter sorgfältig überwachen und gut kennen müssen.

Motivation und Ermutigung

Aber genug über die Peitschen, lassen Sie uns über das Angenehmere sprechen - diese Lebkuchenplätzchen, die Programmierer von der Arbeit bekommen sollten. Rainwater nennt die folgenden Lebkuchensorten (in der Reihenfolge ihrer Priorität): Gehalt, beruflicher Aufstieg, freundliches Wort und schließlich abstraktes Corporate Regalia.

In Bezug auf die Vergütung sind Manager, die die Entwicklung verlassen haben, nicht zu wählerisch, sondern fallen häufig ins Gegenteil und überschätzen die Erwartungen der Mitarbeiter. Berücksichtigen Sie bei der Festlegung der Tarife die folgenden Faktoren: Produktivität, Erfahrung, Effektivität, Aktualität der Aufgaben, aktueller Durchschnittskurs, Marktbedingungen und Unternehmensstandards. Ein häufiger Fehler besteht darin, die Gehälter im Voraus zu erhöhen, in der Hoffnung, dass dies die Arbeitnehmer dazu ermutigt, alles zu geben. , – , .

, , , . , , .

– . , , , (, , «»). . – , . , , , .

, . – , -, , , , . : , . « » , . ( – ) – .