Wie kann ich berechtigte Bedenken äußern und Kritik üben? (und lassen Sie sie berücksichtigen, akzeptieren und / oder letztendlich ansprechen)

• persönlich.
• One- on-one.
• Und nur für Dinge, die wirklich wichtig sind.

Was Sie erkennen müssen, ist, dass Sie es sind wird nicht wesentlich ändern, wie andere Entwickler Code. Abgesehen von der Religion, jemals vom Gelassenheitsgebet gehört? Wie der Code anderer Entwickler größtenteils außerhalb Ihrer Kontrolle liegt und immer sein wird, und je früher Sie damit einverstanden sind, desto besser für alle.

Vielleicht habe ich bereits ruiniert die Chance, eine herzliche Arbeitsbeziehung mit einigen Entwicklern zu haben. Wie ändere / behebe ich das? (Wie andere mich wahrnehmen, hören Sie mir noch einmal zu.)

Ja, Sie haben vielleicht erstaunliche technische Fähigkeiten, aber Sie lernen immer noch wirklich die Fähigkeiten der Menschen. Einfühlen. Wenn Sie das nächste Mal über Kritik nachdenken, die Sie möglicherweise als Versuch ansehen, anderen zu helfen, sich zu verbessern, denken Sie zuerst aus der Perspektive ihrer Bedürfnisse darüber nach. Was brauchen Ihre Kollegen? Respekt für ihren Code, Anerkennung, einen einfachen und unterhaltsamen Arbeitstag. Geben Sie ihnen das und Sie werden anfangen, die Dinge in Ordnung zu bringen.

Wie kann ich berechtigte Bedenken äußern und Kritik üben? (und lassen Sie sie berücksichtigen, akzeptieren und / oder letztendlich ansprechen)

Überlegen Sie, wie Sie dies ansprechen. Glauben Sie, dass es nur einen Weg gibt, Dinge zu tun, und wenn es nicht so ist, muss es falsch, arm oder suboptimal sein? Es kann viele Möglichkeiten geben, Dinge zu tun, und es kann sein, dass Sie die Perspektive eines anderen hier für einen Punkt nicht verstehen.

Überlegen Sie, wie gut Sie diese Gewohnheiten aus 7 Gewohnheiten hochwirksamer Menschen verwenden:

  Gewohnheit 1: Seien Sie proaktivHabit 2: Beginnen Sie mit dem Ende in MindHabit 3: Stellen Sie die ersten Dinge an die erste Stelle p> Beachten Sie, Gewohnheiten 2,4 und 5 für einige, die hier in Ihrer Umgebung möglicherweise eine Überlegung wert sind. Welches spezifische Ende möchten Sie, wenn Sie Bedenken äußern? Wie gut verstehen Sie die Kompromisse, Dinge auf verschiedene Arten zu tun? Einige Unternehmen müssen möglicherweise schwierige Entscheidungen treffen. Auch wenn Sie aus der akademischen Welt kommen, in der viel Zeit bleibt, um die Dinge gut zu machen, ist dies nicht unbedingt die Art und Weise, wie Unternehmen in der realen Welt arbeiten.  
 
 Vielleicht habe ich bereits die Chance auf eine herzliche Zusammenarbeit mit einigen Entwicklern ruiniert. Wie ändere / behebe ich das? 
 
 
  Wie man Freunde gewinnt und Menschen beeinflusst hat einige Ideen, die Sie sorgfältig prüfen sollten: 
 
 
 Grundlegende Techniken im Umgang mit Menschen 
 
 
 Kritisieren, verurteilen oder beschweren Sie sich nicht. 
 
 Geben Sie ehrliche und aufrichtige Wertschätzung. 
 
 Erwecken Sie bei der anderen Person einen eifrigen Wunsch. 
 
 Zeigen Sie anderen niemals, dass Sie nicht daran interessiert sind, was sie zu sagen haben. 
  ol> 
 Sechs Möglichkeiten, Menschen zu mögen Sie 
 
 
 werden wirklich interessiert an anderen Menschen. 
 
 Lächeln. 
 Denken Sie daran, dass der Name einer Person für diese Person der süßeste und wichtigste Klang in jeder Sprache ist. 
 
 Seien Sie ein guter Zuhörer. Ermutigen Sie andere, über sich selbst zu sprechen. 
 
 Sprechen Sie über das Interesse der anderen Person. 
 
 Geben Sie der anderen Person das Gefühl, wichtig zu sein - und tun Sie es aufrichtig. 
  ol> 
 Zwölf Möglichkeiten, Menschen für Ihre Denkweise zu gewinnen 
 
 
 Der einzige Weg, das Beste aus einem Argument herauszuholen, besteht darin, es zu vermeiden. 
 
 Zeigen Sie Respekt vor dem anderen Meinungen der Person. Sagen Sie niemals "Sie liegen falsch". 
 
 Wenn Sie sich irren, geben Sie es schnell und nachdrücklich zu. 
 
 Beginnen Sie freundlich. 
 
 Beginnen Sie mit Fragen, auf die die andere Person mit Ja antworten wird. 
 
 Lassen Sie die andere Person viel reden. 
 
 Lassen Sie die andere Person das Gefühl haben, dass die Idee ihre oder ihre ist. 
 
 Versuchen Sie ehrlich, die Dinge aus der Sicht der anderen Person zu sehen. 
 
 Seien Sie mit den Ideen und Wünschen der anderen Person sympathisch. 
 
 Appellieren Sie an die edleren Motive. 
 
 Dramatisieren Sie Ihre Ideen. 
 
 Stellen Sie sich einer Herausforderung. 
  ol> 
 Seien Sie führend: So ändern Sie Menschen, ohne Beleidigungen zu erregen oder Ressentiments zu erregen 
 
 
 Beginnen Sie mit Lob und ehrlicher Wertschätzung. 
 
 Machen Sie indirekt auf die Fehler der Menschen aufmerksam. 
 
 Sprechen Sie über Ihre eigenen Fehler, bevor Sie die andere Person kritisieren. 
 
 Stellen Sie Fragen, anstatt direkte Befehle zu erteilen. 
 
 Lassen Sie die andere Person das Gesicht wahren. 
 
 Loben Sie jede Verbesserung. 
 
 Geben Sie der anderen Person einen guten Ruf, dem sie gerecht werden kann. 
 
 Verwenden Sie Ermutigung. Lassen Sie den Fehler leicht zu beheben erscheinen. 
 
 Machen Sie die andere Person glücklich darüber, was Sie vorschlagen. 
  ol> 
 Zeigen Sie jemals, wo die Dinge richtig laufen? Erkennen Sie jemals gute Arbeit, die andere leisten? Wenn nicht, könnte ich leicht erkennen, wo Sie viele Probleme verursachen, wenn Sie versuchen, Dinge einzubringen, ohne zu wissen, wie gut oder nicht so gut das für dieses Team und diese Situation ist. Einige Best Practices sind möglicherweise nicht immer großartig, da nicht an jedem Ort eine Umgebung vorhanden ist, in der Sie über ein scheinbar unbegrenztes Budget und Zeit verfügen, um Dinge mit der neuesten Technologie, großartigen Maschinen und ohne enge Fristen zu erledigen. 

Herzlichen Glückwunsch. Wenn Sie es nutzen können, haben Sie die Möglichkeit, Ihre Karriere in die Stratosphäre zu starten.

Welche Art von Dingen sehen Sie in den Lebensläufen hochqualifizierter Ingenieure? Könnten es Dinge sein, wie Praktiken in einem Team von Grund auf neu zu implementieren, Teamkollegen zu schulen usw.? Sie haben keine Gelegenheit, diese Dinge in einem Team zu tun, das bereits beim Joel-Test hohe Punktzahlen erzielt. Die Landung in einem Team von Leuten, die sich nicht um diese Dinge kümmern, ist ein Segen in der Verkleidung - es gibt all diese Dinge im Bereich Senior Engineering, die darauf warten, erledigt zu werden, und genau eine Person, die sich darum kümmert, sie zu tun p> Wenn Sie diese Gelegenheit nutzen möchten, müssen Sie Ihr Denken etwas anpassen.

1. Stellen Sie fest, dass Ihre Teamkollegen sich nie so sehr um Codequalität und bewährte Methoden kümmern wie Sie tun es. Ihre Erwartungen wurden durch Websites wie diese geweckt, die implizieren, dass die meisten Entwickler sich ständig bemühen, das Neueste und Beste zu lernen und Dinge im Einklang mit "Best Practices" zu tun. Die Realität ist, dass die Dinge, die uns alle hier interessieren, nicht einmal auf dem Radar der überwiegenden Mehrheit der Programmierer registriert werden. Lernen Sie zu akzeptieren, dass Ihre Änderungen zunächst wahrscheinlich klein sind, aber jede Änderung, die die Dinge verbessert, ist von Bedeutung.
2. Lernen Sie, über die POV darüber nachzudenken. Ja, theoretisch klingt es großartig, Dinge einfach von Grund auf neu zu schreiben, um eine gute Codequalität zu erzielen. Aber das Schreiben von schlechtem Code ist schwer , und Sie fordern sie auf, Stunden und Stunden des Wegwerfens wegzuwerfen. Darüber hinaus ist Ihr neuer Code nicht fehlerfrei, sodass ein vollständiger QS-Prozess überarbeitet werden muss. Selbst wenn Sie keine vollständige Neufassung befürworten, besteht die Natur des schlechten Codes darin, dass alles, was Sie in einem Bereich berühren, das gesamte Kartenhaus zum Erliegen bringen kann, sodass selbst das Refactoring ein hohes Risiko birgt. Ihre Erfahrung zeigt ihnen das Risiko, Dinge zu reparieren, aber nicht die Belohnungen.
3. Ihr aktueller Ansatz funktioniert bereits (aus ihrer Sicht). Sie erfüllen bereits alle Erwartungen Das Management hat davon, ohne Ihre neuen Ideen zu verwenden. Denken Sie daran, Ihr Manager hat keine Ahnung, wer richtig und wer falsch ist. Er weiß jedoch, wer viel Umsatz generiert hat und wer nicht. Ich vermute, Sie könnten in diese letztere Kategorie fallen. Denken Sie auch daran, dass Ihr Manager, um eine Änderung zu unterstützen, sich auf die Idee einarbeiten muss, dass die Entwickler und Praktiken, die er die ganze Zeit unterstützt hat, falsch sind. Dies ist schwer für ihn, da er seine eigene Geschichte neu bewerten und die Geschichte der Menschen, die er wahrscheinlich mag, negativer beurteilen muss.
ol>

Hier sind einige Dinge, die Sie tun können, um zu bauen Vertrauen Sie und verbessern Sie Ihre eigene Situation.

1. Wenn möglich, lassen Sie Ihre eigene Anwendung oder Ihr eigenes Subsystem arbeiten. Normalerweise macht es den Leuten nichts aus, wenn Sie sauberen Code in Ihrem eigenen Bereich implementieren - sie sind einfach nicht daran interessiert zu ändern, was sie tun. Legen Sie alle Ihre Enten in eine Reihe, damit Ihr Sandkasten zum Leuchten bereit ist, wenn jemand darauf schaut. Dokumentieren Sie alles, führen Sie Tests durch, wenn Sie können usw. Als ich dies zum ersten Mal tat, ging ich in den Urlaub - dies war nach dem angeblichen Liefertermin, aber vor einem neuen Termin - und hinterließ ein Handbuch für andere Entwickler benutze mein System. Während ich weg war, lief alles reibungslos. Darüber hinaus hat dieses Subsystem den Ruf, das zuverlässigste in der gesamten Anwendung zu sein.
2. Finden Sie höfliche Wege, um Leute dazu zu bringen, Dinge richtig zu machen. Dies ist einfacher, wenn Sie über ein eigenes Subsystem oder eine eigene Anwendung verfügen. Als mein Chef beispielsweise sagte, "wir sollten wahrscheinlich über die Verwendung der Versionskontrolle nachdenken", versetzte ich alle meine Websites umgehend sowohl lokal als auch im Netzwerk in die Versionskontrolle, und die Benutzer mussten die Versionskontrolle verwenden, wenn sie wollten, dass ihre Updates weitergegeben werden zu allen Umgebungen. Wenn jemand kommentierte, dass etwas, das im Wiki hätte sein sollen, nicht richtig war, würde ich antworten, dass ich die relevanten Informationen dort nicht gefunden habe - und ich würde anbieten, sie hinzuzufügen.
3. Sie müssen tatsächlich besser, schneller und fehlerfreier sein als Ihre Mitarbeiter. Ich habe unser gesamtes Framework in einer neuen Sprache umgeschrieben, und selbst während ich das tat, konnte ich aggressive Fristen einhalten und mein Framework hat Dinge getan, von denen das alte nie geträumt hat. Kurzfristig musste ich jedoch jedes Mal, wenn es einen Fehler im neuen Framework gab, den das alte Framework nicht hatte, unangenehme Fragen beantworten, warum. Langfristig hat sich herausgestellt, dass sich das Framework blitzschnell entwickelt und weitaus fehlerfreier ist. Die Herausforderung besteht jedoch darin, dass Sie und Ihr Framework so lange überleben.
4. Lernen Sie die Frameworks kennen, in denen Sie sich schwach fühlen. Wenn Sie als Architekt auftreten möchten (und um dieser Herausforderung zu begegnen, müssen Sie dies werden), müssen Sie die dahinter stehenden Konzepte verstehen. Möglicherweise möchten Sie sie "wie sie sind" verwenden, aber wenn Sie Ihre eigenen Architekturlösungen erstellen möchten, müssen Sie verstehen, warum vorhandene funktionieren.
5. Beachten Sie, dass Sie wahrscheinlich weitermachen müssen um den vollen Nutzen aus dem zu ziehen, was Sie erreichen werden. Da sich Ihre Teamkollegen wahrscheinlich nie um die Codequalität per se kümmern werden, ist es unwahrscheinlich, dass Sie aufgrund von Leistungen in dem Bereich, in dem Sie sich befinden, geschätzt oder entschädigt werden. Was Sie jetzt tun, ist, wertvolle Erfahrungen zu sammeln, die Sie mit Glück gesammelt haben, und diese Erfahrungen werden dann in Ihren Lebenslauf aufgenommen, um Ihnen mehr Geld und vor allem einen Platz in einem Team mit denselben Werten zu verdienen Sie tun es.
ol>

Siehe auch meine Antwort in Wie man konstruktiv ist und Probleme in einer unkonstruktiven Umgebung löst.

Es scheint, als hätten Sie beim Schreiben der Frage herausgefunden, dass die Dinge, die Sie getan haben, nicht funktionieren. Also, wenn Sie es noch nicht getan haben, hören Sie auf, sie zu tun. Es spielt keine Rolle, ob Sie technisch richtig lagen oder ob das, was Sie getan haben, in einer anderen Umgebung funktioniert hat: Es war nicht produktiv, also hören Sie auf.

Beziehen Sie sich meiner Meinung nach auf Ihre Fragen, unabhängig davon In Bezug auf die Rechte und das Unrecht der Situation müssen Sie eine Weile schweigen, Ihren Kollegen und Ihrem Vorgesetzten zuhören und sich als jemand etablieren, der erfolgreich an dem arbeiten kann, worum er gebeten wird, und der produktive Arbeitsbeziehungen mit anderen aufbauen kann Teammitglieder. Wenn viel gearbeitet wird, wird wahrscheinlich erwartet, dass die Teammitglieder die Ladung übernehmen und das Boot nicht schaukeln.

Wie kann ich berechtigte Bedenken äußern und Kritik üben? (und lassen Sie sie berücksichtigen, akzeptieren und / oder letztendlich ansprechen)

Stellen Sie sich zuerst auf. Sie können Ihre technischen Ideen natürlich nicht an Ihre Kollegen weitergeben und das gesamte Team beeinflussen, sondern sie so oft wie möglich in Ihrer täglichen Arbeit einsetzen. Wenn Sie zeigen, dass Sie Ihre Arbeit schneller und zuverlässiger erledigen als Ihre Kollegen, sind Sie in Zukunft in einer guten Position, um Ihre Ideen zu vermitteln.

Ich hatte kürzlich eine ähnliche Erfahrung, bei der ich meinen Manager nicht überzeugen konnte, meine Ideen zu übernehmen, sondern sie selbst verwendete. Am Ende des Projekts bemerkte der Manager, dass das Projekt gut verlaufen war, und kommentierte darauf (ohne dass ich frage). Wenn Ihr Vorgesetzter oder Ihre Kollegen Ihre gute Arbeit nicht bemerken und dann nicht bereit sind, darüber zu diskutieren, haben Sie keine Hoffnung darauf, dass Ihre Ideen als egal angesehen werden.

Vielleicht Ich habe bereits die Chance auf eine herzliche Zusammenarbeit mit einigen Entwicklern ruiniert. Wie ändere / behebe ich das? (Wie andere mich wahrnehmen, hören Sie mir noch einmal zu)

Das bezweifle ich. Die meisten Menschen wollen nur Kollegen, die ihren Job machen und mit denen sie auskommen können. Wenn sich herausstellt, dass Sie aus Sicht Ihrer Kollegen beides sind, sehe ich kein Problem. Der Schlüssel ist, ob Sie aufhören können zu reden und anfangen zuzuhören. Ich mache noch einmal kein Urteil über die technischen Rechte und das Unrecht der Situation. Wenn Sie mit Ihren technischen Ideen Recht haben, können Sie in anderen Unternehmen erfolgreich sein.

Mit Blick auf die Zukunft ist meiner Meinung nach eine wichtige Frage, wie viel Sie lernen. Nehmen wir an, Sie etablieren sich, hören auf zu reden und hören mehr zu. Wie viel lernen Sie dann von Ihren erfahreneren Kollegen, technisch und in Bezug auf die Art und Weise, wie Projekte verwaltet werden, wie Geschäfte getätigt werden usw.? Sind Sie dann in der Lage, produktive Diskussionen mit Kollegen über die von Ihnen geleistete Arbeit und schließlich über die Arbeit des gesamten Teams mit Diskussionen zu führen, bei denen Sie alle etwas lernen? ?

Als ich sagte, dass Ihre Ideen mit "Traue dem Internet nicht" und "Erfahrung" konterkariert wurden, fiel mir in Ihrem Beitrag etwas auf. Anscheinend haben Sie viele Interessen und Ideen und möchten in einem leistungsstarken Team sein. Wenn Sie sich nach der Anpassung Ihrer Talk-Listen-Balance nicht in einer Umgebung befinden, in der eine ehrliche und offene Diskussion über Ideen über Jahre hinweg geschätzt wird, ist dies möglicherweise nicht der richtige Ort für Sie. Natürlich ist es in der Zwischenzeit sinnvoll, mit der Arbeit und Ihren Kollegen fortzufahren.

(Ich habe bewusst versucht, diese Antwort angesichts des Kommentars von Pheonixblade9 unter nicht softwarespezifisch zu machen die Frage.)

Bei zwei Gelegenheiten wurde ein Problem zwischen mir und einem anderen Entwickler zu hitzig und konfrontativ. Ich baue meine Standpunkte auf, indem ich online nach den besten Codierungsmethoden recherchiere und ihnen E-Mails schreibe und zur Diskussion einlade Alles, was mit "Traue dem Internet nicht" und "Erfahrung" konterkariert werden muss.

Eines der Dinge, die eine neue Person, die in eine Branche eintritt, lernen muss, ist Demut. Die Aussagen "Traue dem Internet nicht" und "Erfahrung" sind tatsächlich völlig gültig, ob du das noch weißt oder nicht. Genauer gesagt, Sie scheinen Köpfe gegen Menschen zu stoßen, die viel mehr Erfahrung haben als Sie ... Sie werden es einfach nicht mögen, wenn eine viel jüngere Person in ihr Gesicht kommt.

In ihren Augen, Sie Haben Sie nicht die "Kampfnarben", die entstehen, wenn Sie eine unheilige Anzahl von späten Nächten damit verbringen, Ihren Kopf gegen eine Wand zu schlagen und zu versuchen, etwas zu reparieren, das einfach hätte funktionieren sollen. Sie haben wahrscheinlich stundenlang nicht dort gesessen und sich einen Code wie var x = 1 + 1; angesehen und waren verblüfft darüber, warum das Programm darauf besteht, dass x tatsächlich gleich 3 ist. Sobald Sie fertig sind Dies nicht nur einmal, sondern über einen Zeitraum von Jahren, dann stellen Sie fest, dass das Internet oft falsch ist. Dass die vorgestellten Ideen und Konzepte gute Lösungen sein könnten ... aber in sehr spezifischen Situationen.

Ich weiß, dass ich eine große Anzahl von Nachwuchskräften gesehen habe, die sich beeilen, um das Neueste umzusetzen, worüber sie gelesen haben. oft von einem anderen Junior geschrieben, ohne die Konsequenzen zu verstehen. Ich habe auch einige späte Nächte damit verbracht, ein Projekt zu retten, als ich gerufen wurde, um das Chaos zu beseitigen. Zu diesem Zweck habe ich eine Richtlinie entwickelt: "Wenn Sie es nicht im Klartext erklären und mich davon überzeugen können, dass dies das vor uns liegende Problem löst, verstehen Sie es nicht genug und gehören daher nicht dazu."

Das heißt, der Schlüssel hier liegt wirklich darin, wie Sie die Dinge angehen. Einem Entwickler, der mehrmals in der Nähe war, zu sagen, dass er falsch liegt, wird einfach nie funktionieren. Der Versuch, dies mit einem Link zu einem Artikel zu rechtfertigen oder sogar zu sagen "Martin Fowler sagte ...", funktioniert wieder nicht. Erfahrene Leute lernen, einen Code oder einen Ansatz nach seinem Verdienst zu beurteilen, nicht danach, wer der Bote ist.

Stattdessen müssen Sie dies aus einer völlig anderen Richtung angehen. Lassen Sie sie nämlich Ihnen beibringen, warum Ihre Idee falsch ist. Dies ist im Wesentlichen eine umgekehrte Psychologie, und wenn Sie sie bitten, auf Ihre Mängel hinzuweisen (was sie gerne tun werden), wird eines von zwei Dingen passieren. Entweder werden sie erkennen, dass ihr Ansatz schlecht ist, und werden Ihnen am Ende zustimmen, oder sie werden Sie darüber aufklären, warum Sie falsch liegen. Beides sollte eine willkommene Situation sein.

Sehen Sie sich die folgenden Gespräche an:

Schlechter Weg

Sie :: "Bob, du hättest das Inversion of Control-Muster verwenden sollen
hier, sagt Martin Fowler in seinem Artikel unter www.wherever.com. Was du getan hast, muss komplett neu geschrieben werden."
Bob :: "Es funktioniert einwandfrei. Haben Sie keine Klasse, um Refactor zu werden? Vielleicht CS 101?"
Sie :: "Aber er sagte. .. "
Bob ::" Sei weg, welp! " abgesehen von Jim: "Was bringen sie diesen Kindern bei?"

Nicht gerade ein guter Ansatz, da Bob sofort in die Defensive gerät. Außerdem zeigt es, dass Ihnen einfach die Erfahrung und damit die Glaubwürdigkeit fehlt, indem Sie nur einen Verweis auf die Meinung eines anderen verwenden, um Ihre Aussage zu rechtfertigen. Wenn Sie jedoch so etwas getan haben:

Besser

Sie :: "Bob, was wäre das? Sie denken darüber nach, hier ein IoC-Muster zu verwenden? Würde dies nicht das Testen erleichtern? Wir könnten einen Konfigurationsparameter festlegen, damit wir wissen, in welcher Umgebung es sich befindet, und all diesen anderen Code entfernen. "
Bob :: "Vielleicht ... Natürlich verstehen nicht viele Leute, wie man IoC richtig macht, und haben normalerweise wirklich schwer lesbaren Code. In diesem Fall hätte ich lieber etwas, das war leichter zu verstehen."

Viel besserer Ansatz. Sie haben einen Vorschlag gemacht und einen klaren Grund dafür angegeben, warum dies gilt, während Sie auf Bobs Erfahrung zurückgreifen. Anstatt in der Defensive zu sein, ist Bob jetzt verlobt und wird natürlich versuchen, Sie zu "erziehen". Noch wichtiger ist, dass Sie die Möglichkeit haben, detailliertere Angaben zu machen, um seine Besorgnis zu zerstreuen. Während der Diskussion könnte er seine Meinung ändern oder Sie werden einige der Fallstricke mit dem, was Sie lesen, lernen. In jedem Fall sollten Sie etwas Wichtiges lernen.

Um die Probleme an diesem Punkt zu beheben, müssen Sie drei Dinge tun. Hören Sie zunächst auf, das Internet zu zitieren. Zweitens Fragen stellen, keine Aussagen machen. Drittens wissen Sie, wovon Sie sprechen, bevor Sie es ansprechen. Dies bedeutet, dass Sie tatsächlich mit dieser "Codierungspraxis" spielen und sie in einem Testprojekt verwenden, damit Sie wissen, was daran falsch ist.

Versuchen Sie es aus einer anderen Perspektive. Wenn Sie nicht in der Lage sind zu gewinnen, verursachen Sie keine Reibung.

Sie können Ihr Alter nicht ändern Sachverstand. Das steht an erster Stelle.

Es spielt keine Rolle, was Sie von Ihrem Können halten oder wie die Qualität Ihrer Arbeit ist. Weil Kommunikation die Antwort ist, die Sie erhalten. Für Ihr spezielles Problem ist es wichtig, was sie über Sie denken.

Lösen Sie das zuerst. Und es wird viel einfacher sein, sich für Verbesserungen einzusetzen, die Sie für angemessen halten.

Zu Ihren Fragen:

1. Das braucht Zeit, beeilen Sie sich nicht und bleiben Sie ruhig.

   Es geht darum, die richtige Zeit und die richtige Zeit zu finden der richtige Ort, um solche Fragen zu stellen. Niemand mag eine kluge Person und die Leute hören nicht zu und ignorieren nicht, was Sie sagen, weil sie glauben, dass Sie eine sind.

   In einer Arbeitsumgebung haben Sie zwei Jobs. Die Arbeit, die Sie täglich erledigen, und die zweite ist die, bei der Sie Beziehungen und Vertrauen aufbauen.

   Wenn Sie also gut in Ihrem Job sind und respektvoll, möchten Sie ein Problem ohne das ansprechen Respekt und Unterstützung Ihrer Mitarbeiter werden höchstwahrscheinlich niemand zuhören und Sie sind der Ungewöhnliche.

   Der beste Rat, den ich sagen kann, ist Geduld. Sie haben versucht, ein Problem anzusprechen, und es lief nicht wie geplant. Machen Sie also eine Verschnaufpause und lassen Sie sich nicht stören. Arbeiten Sie langsam an einem anderen taktischen Ansatz, wenn Sie das Problem so stark ansprechen möchten. Vielleicht sehen andere Leute das auch so, Sie müssen sie nur finden. Es braucht Zeit.

2. Laden Sie diese Entwickler zu einem abendlichen Drink ein. Sag diesmal, es liegt an dir. Die meisten der besten Arbeitsbeziehungen finden außerhalb des Büros statt. Trinken Sie ein paar Drinks und entspannen Sie sich. Sie werden feststellen, dass die Leute besser zuhören, wenn sie nicht im Büro sind und entspannt. Besonders in einer Bar. Sprechen Sie über gängige Dinge wie Sport oder Filme oder Haustiere oder was auch immer. Die Leute werden viel besser mit dir umgehen.

   Vielleicht sprechen Sie nach einiger Zeit, wenn Sie wieder etwas von der Arbeit trinken gehen, über das Problem mit dem Codierungsstandard. Nach meiner Erfahrung werden Sie eine bessere Veränderung für jemanden ertragen, der zuhört, was Sie zu sagen haben.

ol>

Viel Glück

Möglicherweise irren Sie sich in Bezug auf Ihre Bedenken, und die von Ihnen angesprochenen Probleme mit der Codequalität wurden von informierten und erfahrenen Ingenieuren speziell ausgewählt.

Stellen Sie sich das folgende Szenario vor:

Ein Team steht unter dem Druck des Managements, ein Projekt zu beschleunigen, und aufgrund dieses Drucks verkürzt es die Design- und Entwicklungszeit.
Um die Wunde mit Salz zu versorgen, stellt das Management billige unerfahrene Teammitglieder ein, mit der Erwartung, dass sich dieser Wille verbessern wird Teamproduktivität, aber alles, was dieses neue Mitglied tut, ist sich über die Qualität des Codes und die Designauswahl zu beschweren.

Ich sage nicht, dass dies Ihre Geschichte ist, aber es könnte sein.

Denken Sie daran, dass dies Menschen sind, mit denen Sie jeden Tag arbeiten müssen - seien Sie respektvoll und rücksichtsvoll, die Geschichte enthält möglicherweise mehr - Sie werden auf lange Sicht besser bedient und lernen mehr wenn Sie schnell loben und nicht schnell kritisieren.