Wie kann ich Kollegen dazu bringen, einige meiner Ideen zu unterstützen? [Duplikat]

Ich bin ganz neu an meinem Arbeitsplatz und möchte einige Änderungen ansprechen. Die meisten dieser Änderungen würden die Umgebung auf Industriestandards für diesen Bereich, die Softwareentwicklung, bringen.

Wie kann ich diese Änderungen vorschlagen und die Zustimmung / Zustimmung meiner Kollegen erhalten, ohne mich so früh in unserer Arbeitsbeziehung zu entfremden, indem ich so aussehe, als würde ich versuchen, die Kontrolle zu übernehmen?

Möglicherweise finden Sie diese Antwort nützlich . workshop.stackexchange.com/questions/9703/…
@gnat ähnlich, aber nicht duplizieren, dies deckt einen viel breiteren Bereich ab, wie und nicht nur sollte ich . Antworten darauf können meines Erachtens einen größeren Umfang haben als nur für „Neulinge“.
Achten Sie darauf, Ihre Kollegen nicht zu beleidigen. Bedenken Sie, dass es sehr gute Gründe dafür geben kann, dass die Dinge so sind, wie sie sind. Lernen Sie diese und überlegen Sie dann , welche Low Hanging Fruits Ihren Kollegen tatsächlich helfen könnten . Diese Dinge werden höchstwahrscheinlich sehr willkommen sein.
@SpikyBlue Nach meiner Lektüre konzentrieren sich Antworten in vorgeschlagenem Dupe tatsächlich darauf, wie ich anstatt sollte (und das fühlt sich für mich richtig an)
Wenn Sie möchten, dass andere Ihre Idee kaufen, müssen Sie sie verkaufen (Wortspiel beabsichtigt)

Antworten (4)

Es gibt ein paar Methoden, die Sie berücksichtigen sollten, wenn Sie Änderungen in einem Unternehmen vorschlagen. Unabhängig von Ihrer Position im Unternehmen.

1. Spielen Sie nicht das Schuld-Spiel

Spielen Sie niemals das Spiel der Schuld. Auch wenn man sieht, dass alle Probleme von einer Person herrühren. Das Spiel der Schuldzuweisungen wird ein ganzes politisches Durcheinander in der Arbeitsumgebung aufwirbeln, ohne das Sie viel besser dran sind.

Schlagen Sie stattdessen alle Ihre Verbesserungen objektiv als teamweite Ziele vor.

2. Vertrauen ist der Schlüssel

Bevor Sie überhaupt daran denken, diese Änderungen vorzuschlagen, gehen Sie alles selbst durch, schreiben Sie Ihre Ideen auf und gehen Sie sie dann immer wieder durch. Konzentrieren Sie sich nicht nur darauf, welche Änderungen vorgenommen werden sollen, sondern auch darauf, wie Sie diese Änderungen vorschlagen werden.

Die Änderungen müssen einfach und leicht erscheinen. Wenn Sie 20 Minuten und 3 Seiten brauchen, um eine einzelne Änderung detailliert zu beschreiben, ist es wahrscheinlich zu lang und kompliziert mit zu vielen potenziellen Fehlerpunkten, als dass die Leute es glauben wollen.

Achten Sie auf Schwachstellen in Ihren eigenen Argumenten, stellen Sie sicher, dass Sie Antworten haben, und stellen Sie sicher, dass es gute Antworten sind. "Ich weiß nicht" kann ein Killer sein, wenn Sie versuchen, die Leute dazu zu bringen, Ihre Änderungen zu akzeptieren.

Vertrauen ist der Schlüssel, Sie müssen so aussehen, als wüssten Sie, was Sie tun, und Sie müssen so aussehen, als wüssten Sie, wie es geht. Wenn Sie Ihren Veränderungen nicht vertrauen, werden die Menschen Ihnen auch nicht vertrauen.

3. Bottom-up-Ansatz

Bevor Sie dem CEO Ihre Ideen vorschlagen, müssen Sie überprüfen, ob der Rest des Unternehmens überhaupt mit Ihnen einverstanden ist.

Beginnen Sie mit den Menschen um Sie herum, mit denen Sie täglich zusammenarbeiten, sprechen Sie mit ihnen über Ihre Ideen und sehen Sie, was sie denken. Sehen Sie, was ihnen gefällt und was nicht, und sehen Sie, ob sie zustimmen, dass Ihre Änderungen das Beste wären.

Gehen Sie dann zu Ihrem Vorgesetzten, zeigen Sie ihm Ihre Änderungen, zeigen Sie ihm, dass Sie vom Rest des Teams unterstützt werden. Zeigen Sie ihm, dass es in seinem besten Interesse ist, diese Veränderungen voranzutreiben, und Sie werden seine Unterstützung haben.

4. Befolgen Sie das richtige Protokoll

Versuchen Sie nicht, die Waffe zu überspringen und vorzuschlagen, dass Ihre Änderungen an der Spitze der Kette wie eine gute Idee erscheinen mögen, aber wenn sie nicht die richtigen internen Prozesse durchlaufen haben, dann sind Sie im Nachteil.

Diese internen Prozesse stellen sicher, dass jeder, der es sehen und ihm zustimmen muss, die Möglichkeit erhält, seinen Beitrag zu leisten, seine Bedenken anzusprechen und Verbesserungen vorzuschlagen.

Sich von Ihrem Team einzukaufen, ist ein schwieriges Spiel. Es geht darum, sicherzustellen, dass sie sich einbezogen fühlen und dass sie das Gefühl haben, dass ihre Stimme gehört wird. Es geht darum, das richtige Verfahren einzuhalten, damit die Änderung kugelsicher ist, wenn sie die Menschen erreicht wer kann da was machen.

Seien Sie ein Fachexperte

Aber am wichtigsten ist, dass Sie viel darüber wissen müssen, wenn Sie die Änderung vorschlagen, sind Sie wahrscheinlich die Person, die alle Fragen und Bedenken bezüglich der Änderung beantworten muss. Wenn Sie die Fragen nicht beantworten oder die Bedenken zerstreuen können, verlieren Sie die Unterstützung.

Die Wahl zwischen Bottom-up oder Top-down würde sowohl von der geografischen Lage als auch von der Unternehmenskultur abhängen. Ich habe zum Beispiel gehört, dass man in Asien fast immer von unten nach oben vorgehen sollte, aber in den USA muss man mehrere Faktoren berücksichtigen, also gibt es keine eindeutige Anleitung.

Es ist wirklich wichtig, zu vermeiden, ein Besserwisser zu sein. Wenn Sie sich überlegen fühlen, wird sich niemand geneigt fühlen, Ihnen zuzuhören. Schuldzuweisungen sind oft auch nicht wirklich konstruktiv. Ich denke, zuerst müssen Sie eine gute Beziehung zu Ihren Kollegen aufbauen. Versuchen Sie danach, Momente zu finden, in denen Sie diese Art von Programmierfehlern diskutieren können. Um dann objektiv zu beweisen, warum manche Dinge schlecht sind, ist die Verwendung objektiver Argumente hier wirklich der Schlüssel, um die Diskussion von „aber so machst du die Dinge gerne, ich mache so weiter wie bisher“ fernzuhalten. Einige Dinge, wie die Codierungsstandards, könnten ein gutes Thema für eine Mitarbeiterversammlung sein.

Seien Sie bereit, geduldig zu sein. Veränderung dauert lange. Und denken Sie immer daran, dass Sie sich irren könnten :).

Ohne zu sehr auf Verhaltensänderungstheorien oder andere Sozialwissenschaften einzugehen, hatte ich eine ähnliche Erfahrung bei einem Softwareunternehmen. Ich war weniger als ein Jahr dort und fand mich in der Verantwortung für die Prozessqualitätssicherung wieder. Manchmal war es umständlich, neue Arbeitsgewohnheiten in oft undefinierte Prozesse zu integrieren, und es konnte auch sehr entmutigend sein, wenn meine gründlich recherchierten Vorschläge in Ungnade fielen.

Hier sind einige Hinweise, die ich aufgegriffen habe:

Geschäftswert

Es besteht keine Notwendigkeit, etwas zu ändern, wenn es der Organisation keinen erkennbaren Nutzen bringt. Seien Sie bereit, empirische Untersuchungen oder Berichte zu den Prozessbereichen bereitzustellen, die Sie aktualisieren möchten, und bereiten Sie, wenn möglich, einen Metrikerfassungs- und Analyseplan vor. Vielleicht verfolgt Ihr Unternehmen beispielsweise bereits, wie lange es dauert, Fehler zu beheben. Wenn die Fehler a, b und c vor Ihren Methoden im Durchschnitt x Zeit in Anspruch genommen haben, können Sie vielleicht beweisen, dass die Behebung der Fehler d, e und f im Durchschnitt weniger Zeit in Anspruch genommen hat. In der Softwareentwicklung gibt es eine Menge, die in die Metrikanalyse einfließt, und wenn Sie daran interessiert sind, mehr zu erfahren, würde ich empfehlen, sich mit Goal, Question, Metric (GQM) zu befassen .

Sprechen Sie mit Ihren Kollegen

Neue Vorgehensweisen vorzuschlagen, kann Ihre Kollegen entfremden und Ihnen, wie Paul Hiemstra betont, den Ruf eines Besserwissers einbringen (niemand mag Besserwisser). Nehmen Sie sich etwas Zeit, um mit Ihren Kollegen zu sprechen und fragen Sie, warum sie die Dinge so tun, wie sie es tun. Es könnte sein, dass sie sehr gute Gründe haben, aber es besteht auch eine gute Chance, dass sie wissen, dass die Dinge besser sein könnten. Versuchen Sie, Veränderungsprozesse zu einer Teamleistung zu machen, die von innerhalb der Organisation kommt und nicht als von außen auferlegte Veränderungen. Weitere Informationen finden Sie unter Organisationskultur und kulturelle Assimilation .

Richtige Zeit und Ort

Zu viel zu schnelle Veränderung führt zu Widerstand. In unserem kleinen Unternehmen hatten wir jeden Monat Retrospektive-Meetings, nachdem wir unsere Updates an unseren Kunden geliefert hatten. Dies war der perfekte Zeitpunkt, um zu sagen: „Ich habe bemerkt, dass wir diesen Monat einige Probleme mit x hatten. Ich habe mich damit befasst und von vielen Leuten in einer ähnlichen Situation gelesen, die mit y Erfolg hatten. Ist jemand interessiert beim Ausprobieren?" Änderungen einzeln einzuführen, kann allen die Möglichkeit geben, den neuen Prozess zu üben und sich damit vertraut zu machen, bevor sie etwas Neues ausprobieren. Außerdem kann es hilfreich sein, eine Änderung einzuführen, wenn ein wenig Luft zum Atmen vorhanden ist und nicht mitten in einem Sprint.

Optionen bereitstellen

Das kommt von Gesprächen mit Gleichaltrigen, und es ist ziemlich einfach. Sagen Sie, wenn Ihr Unternehmen keine Versionskontrolle anbietet, sagen Sie nicht einfach „OK, so installieren Sie Git …“ Wenn es um Aktualisierungsprozesse geht, ist es gut, Optionen bereitzustellen. Führen Sie die Organisation erneut mit dem Git-Beispiel in Versionskontrollkonzepte ein: Was ist das und welche Vorteile hat es? Sprechen Sie dann über die verschiedenen Optionen und wie sie miteinander verglichen werden. Steigen Sie nicht einfach mit Ihrem Lieblingswerkzeug ein, weil Sie sich damit am wohlsten fühlen; Es geht darum, der Organisation die Freiheit zu geben, mit verschiedenen Optionen zu experimentieren und zu spielen. Verdammt, ich habe viele Gespräche mit Kollegen über neue Tools geführt, die mit "Hey, schau dir dieses neue Spielzeug an, das ich habe!"

TL;DR

Sprechen Sie mit Ihren Kollegen, bevor Sie versuchen, ihre Arbeitsweise zu ändern, und seien Sie bereit zu beweisen, warum es sich lohnt, etwas zu ändern.

Zusätzlich zu dem, was von Paul Hiemstra gesagt wurde:

Xaisoft, auf jeder Dienstalters-/Hierarchieebene gibt es eine Grenze für Dinge, die Sie ändern können. Ein Junior-Entwickler/-Ingenieur kann Änderungen an Routinen vorschlagen, aber er/sie muss von fast allen Beteiligten als eine sehr kluge Person wahrgenommen werden, damit die Änderung erfolgreich ist. Mit zunehmender Erfahrung erweitert sich der Umfang der möglichen Änderungen. Das größte Potenzial, Veränderungen voranzutreiben, liegt jedoch in Positionen des mittleren Managements.

Allerdings muss man sich fragen:

  • Lohnt sich die Änderung, die ich vorschlage?

  • Was werden die negativen Auswirkungen der Änderung sein?

Muss sagen, dass ich Veränderung um der Veränderung willen zutiefst nicht mag, Management-Modeerscheinungen und Schlagworte hasse. Alles , was die etablierten Routine- und Standardarbeitsabläufe am Arbeitsplatz stört, senkt die Produktivität und wirkt sich unmittelbar nachteilig auf das Endergebnis aus, während positive Auswirkungen (falls vorhanden) verzögert werden . Denk darüber nach.

EDIT: Wie üblich sind Änderungen ein zweischneidiges Schwert. Wenn Sie technologisch deutlich hinter dem neuesten Stand zurückbleiben, verlieren Sie sehr oft. Wenn Sie die Arbeitsweise Ihrer Organisation kontinuierlich ändern, geraten die Menschen um Sie herum unter Stress und verlieren möglicherweise das Vertrauen. Die beste Lösung für den technologischen Teil des Problems ist, wenn die Mitarbeiter daran gewöhnt sind, auf dem neuesten Stand der Technik zu bleiben. Bei der internen Struktur und den Abläufen klappt es leider nicht – hier braucht es eine gewisse Stabilität und Freiheit von vordergründigen Management-inspirierten „Reorganisationen“, um produktiv zu sein.


Hier die Schlussfolgerungen:

  • Bitte beginnen Sie mit Veränderungen bei sich selbst.

  • Gewinnen Sie etwas Respekt von Ihren Kollegen; Versuchen Sie nicht, anderen Revolutionen aufzuzwingen, es sei denn, Sie sind sich ihres Erfolgs einigermaßen sicher.

  • Berücksichtigen Sie immer mehrere Möglichkeiten zur Verbesserung und führen Sie eine Kosten-Nutzen-Analyse durch, bevor Sie mit unausgegorenen Vorschlägen zu einem Meeting kommen.

Aus diesem Grund habe ich in meinem Beitrag gesagt: "Es gibt noch mehr ...". Ich habe den Code erst seit 2 Tagen gesehen und die Dinge, die ich erwähnt habe, waren nur einfache Dinge. Dabei geht es nicht so sehr um diese Dinge, sondern darum, andere objektiv von alternativen Wegen zu überzeugen. Ich habe nur ein paar Beispiele gegeben. Ich habe nur einmal Codierungsstandards erwähnt, aber ich würde nicht sagen, dass irgendetwas oberflächlich ist. Alles beeinflusst alles.
Ich muss sagen, ich bin anderer Meinung, dass alles, was die etablierte Routine stört, die Produktivität senkt. Beispielsweise hat die Einführung einer Versionskontrolle einen geringen bis mäßigen negativen Einfluss auf die Produktivität am Frontend, mit einer relativ kurzfristigen viel höheren Rendite.
@AmyBlankenship - Bitte berücksichtigen Sie die Zeit, die für die Installation von VCS und das Einführen der neuen Routine aufgewendet wird. Es gibt eine vorübergehende negative Spitze; manchmal ist es eine rein psychologische Störung. Wird es einige Zeit später von echten Verbesserungen überschwemmt? Hängt davon ab ... Das andere Problem hier ist die Anzahl der Störungen pro Zeiteinheit. Ständige Störungen bauen Stress und Unsicherheit auf.
Hm, in der Situation, die ich mir vorgestellt habe (meine eigene Erfahrung), war es bereits installiert, aber niemand benutzte es. Die andere Seite der Medaille ist, dass die Weigerung, Änderungen vorzunehmen (oder dies zu langsam zu tun), bedeutet, dass Sie nicht genügend Bandbreite haben, um die erforderlichen inkrementellen Änderungen vorzunehmen. So schreiben die Leute zum Beispiel immer noch auf ASP Classic HTML, das 2007 veraltet war.
@AmyBlankenship - in Ordnung, unterschiedliche Annahmen zu VCS. Es gibt keinen Standard dafür, wie groß Veränderungsquanten sein sollten, da sich Branchen und Organisationen und Fähigkeiten unterscheiden. Wenn die Mitarbeiter daran gewöhnt sind, auf dem neuesten Stand zu bleiben, ist der technologische Teil des Problems gelöst; nicht so bei organisatorischen Änderungen (stellen Sie sich vor, Ihr Titel, Ihre Stellenbeschreibung und Ihr direkter Vorgesetzter ändern sich 6 Mal im Jahr).
Das OP spricht nicht über organisatorische Veränderungen (oder, würde ich vermuten, über Mitarbeiter, die daran gewöhnt oder daran interessiert sind, mit dem neuesten Stand Schritt zu halten).