Komm auf dich selbst ... oder die Regeln der Kommunikation in einem Team

    Post-Antwort auf den Artikel "Come on! @ # Mit Ihrer" Toxizität " . "


    Wenn ich den Ratschlägen dieses Artikels folgen würde, würde es ausreichen, dass ich Emotionen zeige und dem Autor sage "Komm schon ... du verstehst nichts!".


    Dies würde jedoch nicht dazu beitragen, meine Idee zu vermitteln. Schauen wir uns das mal genauer an.


    Zitat 1:


    Wenn ein Mensch inkompetent ist, muss er dies klar verstehen und darf seine zarten Gefühle nicht zum Nachteil aller anderen schützen.

    Ich bin mit der Grundlage dieser Aussage nicht einverstanden. Ich glaube, dass eine Person nicht kompetent oder inkompetent sein kann. Ein solcher verallgemeinerter Schwarz-Weiß-Ansatz funktioniert in der Praxis nicht. Sogar der am meisten gepumpte Senior kann einige Dinge nicht wissen. Umgekehrt haben Junioren manchmal großartige Ideen.


    Zu Persönlichkeiten wechseln („Sie sind nicht kompetent!“) Eine Überprüfung anstelle spezifischer Argumente zu codieren, ist zu einfach. Wenn Sie so ein schlauer Senior sind, arbeiten Sie hart und erklären Sie, warum an dieser Stelle des Codes alles anders sein sollte. Du kannst es nicht erklären - es ist besser, nichts zu schreiben, weil du es möglicherweise selbst nicht ganz verstehst.


    Gleichzeitig ist es natürlich notwendig, über bestimmte Probleme im Code zu sprechen.


    Ein normaler Mensch ist gerne bereit, eine begründete Position zu besprechen. Und er wird negative Gefühle der Feindseligkeit auf sich nehmen. Wer würde jemals mit einem giftigen Teammitglied arbeiten wollen?


    Zitat 2:


    Kann eine Person Ihnen immer wieder einen Code mit denselben Fehlern senden und muss höflich und mit einem Lächeln antworten?

    Wenn jemand immer wieder Fehler macht und nicht versucht, irgendwie zu wachsen, muss er gefeuert werden. Sprechen Sie mit dem Teamleiter über dieses Thema. Aber Hysterie ist sowieso nicht nötig. Naja, einfach weil es nicht helfen wird.


    Negative Emotionen können nur negative Emotionen hervorrufen. Und es werden keine Fehler im Code in irgendeiner Weise korrigiert.


    Zitat 3:


    Je größer die Verantwortung im Beruf ist, desto größer sollte die Stressresistenz sein.

    Ich habe mit der Produktionsumgebung gearbeitet und nachts Probleme behoben. Oft war es Stress (besonders, wenn Sie diese Abteilungen leiten und für diese gesamte Kollektivfarm verantwortlich sind).


    Und ich möchte mit aller Verantwortung erklären: Niemand mag Stress, auch wenn er es aushält. Jeder versucht immer, Stress abzubauen.


    Zum Beispiel:


    • Konfiguration der Überwachung, rechtzeitige Warnung von Servern, dass Probleme vorliegen
    • Codeüberprüfung durch automatische und manuelle Prüfung
    • Backups von Datenbanken zur Überprüfung der Wiederherstellbarkeit
    • usw.

    Kurz gesagt, wir reduzieren potenzielle Probleme so schnell wie möglich.
    Das heißt Stress ist eigentlich schlecht . Auch für die stressresistentesten Menschen.


    Dieselbe Person, die keinen Stress mag, wird wahrscheinlich alles richtig machen, alles überprüfen, den Strohhalm legen und keine tödlichen Fehler machen.


    Zitat 4:


    Zweifellos ist es nicht hinnehmbar, einen Kollegen wegen mangelnder Kenntnisse zu beleidigen, aber das offensichtliche Format „Ihr Code ist schlecht, ich werde jetzt die Gründe im Detail erläutern und Ratschläge erteilen“ wird bereits als toxisches Verhalten angesehen.

    Nun ja, das ist es. "Dein Code ist schlecht" ist ein bedeutungsloser Satz, man könnte sofort mit Tipps beginnen und noch besser Fragen klären, warum dies getan wurde und nicht anders.


    Nachwort


    Stress beeinträchtigt die Leistung. Wenn ein Mitarbeiter Angst hat, einen Code für eine Überprüfung anzugeben, arbeitet er nicht mit Begeisterung, generiert keine Ideen, ist dem Unternehmen nicht treu usw.


    Leicht zu googelnde Studien zeigen, dass die Leistung bei Überschreitung eines bestimmten Stressniveaus stark abnimmt.


    Im Allgemeinen wurde die Höflichkeit bei der Arbeit in einer Gruppe noch nicht erfunden, lange bevor Codeüberprüfung und Programmierung allgemein in Mode kamen. Eine Reihe von Artikeln über "Teamfähigkeit", die in keiner Weise mit der IT zu tun haben.


    Die besten Ideen entstehen in einer günstigen Atmosphäre.


    Nehmen Sie zum Beispiel die Regeln des Brainstormings: Zuerst wirft jeder Ideen, und Sie können sie überhaupt nicht kritisieren. Und erst dann folgt eine ausführliche Diskussion.


    Das heißt, wir sind alle Menschen. Menschen mögen es nicht, wenn jemand auf ihre Fehler hinweist. Selbst der korrekteste Überprüfungscode sieht oft wie eine öffentliche Auspeitschung aus. Nun, nicht ärgern!


    In jenen Teams, in denen ich als Teamleiter tätig war, habe ich den himmelhohen Verhaltenskodex zur Codeüberprüfung eingegeben (noch bevor diese Herde in Mode war). Nämlich: Höflichkeit, Verbot von Befehlstönen, Verbot der Erörterung persönlicher Eigenschaften, nur begründete Kommentare usw. In strittigen Situationen entscheidet die Mehrheit.


    Übrigens ist es die Mehrheit, nicht das Timlid / Techlide. Da die Lesbarkeit von Code und andere Dinge für das gesamte Team wichtig sind, ist es das Team, das in Zukunft mit diesem Code arbeiten wird. Und nicht derjenige, der sich für den klügsten hält.


    Diese einfachen Maßnahmen haben die Stimmung im Team deutlich verbessert.


    Warum reden jetzt alle über CoC und Teamwork? Denn im Allgemeinen vergeht die Zeit einzelner Genies. Ein durch Synergien geeintes Team wird jedes Problem lösen. Ich habe mit einem gesprochen, mit einem anderen gesprochen - und der Grund des Problems ist gelöst. Soft Skills werden von Tag zu Tag wichtiger.


    Es gibt Leute, die noch nie in einem engen Team gearbeitet haben und sich nicht vorstellen, was für ein Nervenkitzel das ist.


    Ja, eigentlich kreuzige ich hier, mach weiter ...


    (PS Das Emoticon am Ende des letzten Satzes wurde von den Moderatoren entfernt. Ich möchte niemanden beleidigen, es ist nur ein Witz.)


    Jetzt auch beliebt: