Hintergrund
Ich arbeite in einem Softwareentwicklungsteam in einem großen Unternehmen, dessen Hauptgeschäft nicht Software ist. Wir versuchen, uns „agil“ zu entwickeln, aber das steht oft im Widerspruch zu der eher bürokratischen und schwergewichtigen Managementstruktur, in der wir arbeiten. Sowohl bei uns als auch bei der Geschäftsleitung herrscht allgemeine Unzufriedenheit über unsere Fähigkeit, Fristen einzuhalten, aber nicht so schlimm, dass von uns erwartet wird, unbezahlte Überstunden zu leisten.
Ich bin Entwickler mit 6 Jahren Erfahrung, davon 4 bei diesem Unternehmen, bin begeistert von meiner Arbeit und möchte unsere Situation verbessern. In meiner Freizeit beschäftige ich mich manchmal mit Entwicklungspraktiken und neuen Programmiersprachen. Ich glaube, ich bin eifrig und sachkundig genug, um zur Verbesserung der Produktivität des Teams beizutragen, bin mir jedoch der Grenzen meines Wissens aufgrund meiner relativen Unerfahrenheit und mangelnden Managementverantwortung bewusst. Ich gehe nicht gut mit Konflikten um und neige dazu, entweder zurückzuweichen oder zu aggressiv zu reagieren.
Situation
In einem kürzlichen Scrum-Meeting kam unser QA-Leiter (nennen wir ihn „John“) herein und beschwerte sich, dass wir keine Kommentare zu unserem Issue-Tracker hinzufügten, wenn wir sie von einem Status zum nächsten verschoben, forderte uns auf, dies zu tun, und erklärte dies sei „nicht verhandelbar“ und nannte dies als notwendig für externe Prüfungs- und Akkreditierungszwecke. Müde von ähnlichem Verhalten von John in der Vergangenheit (er ist der Administrator des Problemverfolgungsservers und nimmt häufig Änderungen vor, um uns dazu zu bringen, auf eine bestimmte Weise zu arbeiten), und ziemlich sicher, dass externe Akkreditierungen in Bezug auf nicht so vorgeschrieben sind Workflow, lachte ich und fragte halb im Scherz: "Können wir es verhandelbar machen?". (Zugegebenermaßen nicht der klügste Schritt, den ich jetzt anerkenne.) John sagte rundheraus nein. Ich fragte, ob er in unserem internen Wiki auf irgendetwas hinweisen könnte, das uns sagen würde, welche Art von Kommentaren gemacht werden sollten und wann/wo, aber er sagte, dass es einfach "gesunder Menschenverstand" sei. Ich entgegnete, dass er „offensichtlich bestimmte Anforderungen an die Prüfung im Sinn hat. Es folgte ein hitziges, aber relativ belangloses Hin und Her.
Auf dem Weg aus dem Scrum-Meeting waren John und ich hinten dran. Außer Hörweite vom Rest des Teams sagte er zu mir, dass er „ein bisschen mit mir plaudern“ würde, da ich „feindselig“ sei. Er hat das nicht durchgezogen, aber ich war den ganzen Nachmittag nervös und habe darauf gewartet, dass er es tut.
Der Hauptgrund für meine Einwände war/ist, dass John, soweit ich weiß, als Leiter der QA nicht befugt ist, dem Entwicklungsteam solche Anweisungen zu erteilen. In Bezug auf die Verwendung von Issue-Trackern bin ich dafür, nützliche Informationen zu veröffentlichen, aber im Interesse der Erhaltung eines guten Signal-Rausch-Verhältnisses bin ich absolut gegen "Stempel" -Kommentare, die nur als Übung zum Ankreuzen von Kästchen dienen. Mir ist bewusst, dass externe Audits bestimmte Anforderungen an uns stellen, die erfüllt werden müssen, aber ich denke, dass John diese Anforderungen (absichtlich oder nicht) mit seiner eigenen Meinung darüber, wie wir arbeiten sollten, vermengte. Mir geht es weniger um das Thema als vielmehr um den Grundsatz, dass wir als Team als Profis behandelt werden sollten, die Verantwortung für unseren eigenen Workflow übernehmen können.
Am nächsten Morgen erklärte ich meinem direkten Vorgesetzten die Situation, um Ratschläge zur Lösung der Situation zu erhalten, wobei er meiner Einschätzung zustimmte, dass John seine Grenzen überschreitet. Danach schickte ich eine E-Mail an John, um meine Einwände besser zum Ausdruck zu bringen, machte ihm aber keine Vorwürfe wegen seiner Autorität oder anderweitig in dieser Situation. Dies führte zu einem Treffen nur zwischen uns beiden, bei dem er erklärte, dass es häufig Fälle gibt, in denen wir Funktionen auf eine Weise implementiert haben, die von den angegebenen Akzeptanzkriterien abweicht, was zu Verwirrung im Testteam führt. Ich war mir dessen nicht bewusst und stimmte ihm zu, dass es gut wäre, solche Kommunikationsprobleme innerhalb der Abteilung zu lösen.
Am Tag nachdem John jedoch einen Wiki-Beitrag verteilt hatte, kam er leider viel näher an die mündliche Beschwerde heran, die er in unserem Scrum-Meeting vorgebracht hatte. Es scheint, als hätte er einiges von dem, was ich gesagt habe, übernommen, indem er versprach, "offen für Vorschläge" zu sein, aber er hat immer noch so viel Wert auf Anforderungen bezüglich externer Audits gelegt, ohne explizit zu sagen, was sie sind, dass mein Gesamteindruck ist, dass er es ist verbreitet genug FUD, damit wir in seiner vorgeschriebenen Weise arbeiten. Leider ging er nur am Rande auf die wirklich guten Punkte zu Kommunikationsproblemen ein, die er mir bei unserem privaten Treffen mitteilte.
Meine Analyse
Ich denke, dass John sich so verhält, weil er wirklich glaubt, dass seine Ideen unsere Produktivität verbessern werden (im Gegensatz zu einer zynischen Machtübernahme um ihrer selbst willen), genau wie ich glaube, dass meine Ideen es tun würden. Die beste Lösung für solche Probleme ist ein pragmatischer Kompromiss zwischen seinen Ansichten und denen von uns als Entwicklerteam, aber ich bin mir nicht sicher, wie ich ihn dazu bringen kann, sich auf diese Weise mit uns zu beschäftigen. Ich habe den Eindruck, dass andere Teammitglieder ähnlich frustriert mit ihm sind, aber er setzt sich durch, weil es oft einfacher ist, sich seinen Launen zu beugen, als ihn vom Gegenteil zu überzeugen.
Ich habe andere Fragen auf dieser Website gelesen, um mich darauf vorzubereiten, diese zu stellen, und habe viele vernünftige Ratschläge von "Wie man Freunde gewinnt und Menschen beeinflusst" gesehen, die darauf hindeuten, dass ich versuche, meine Bedenken in einer kooperativeren Weise zu präsentieren, die dies zulässt beide Parteien nachgeben, ohne das Gesicht zu verlieren. All meine Erfahrungen mit ihm lassen mich jedoch glauben, dass dies niemals produktiv sein kann, während er fälschlicherweise glaubt, dass er das letzte Wort darüber hat, wie wir unsere Arbeit erledigen.
Die Frage
Wie kann ich dazu beitragen, das Kräfteverhältnis zwischen unserem Team und diesem Kollegen so zu korrigieren, dass wir Vereinbarungen treffen können, die für alle Parteien am besten sind, ohne unnötige Konflikte zu verursachen oder sich unprofessionell zu verhalten?
Es ist klischeehaft, aber die Antwort ist, der größere Mann zu sein.
Sie glauben, dass Johns Absichten gut sind, das ist der Schlüssel. Seien Sie sein Fürsprecher. Geben Sie ihm keine Chance, Sie als antagonistisch hinzustellen. Wenn er ehrlich glaubt, dass das Hinzufügen von Kommentaren die Produktivität verbessert, dann spielen Sie mit.
Wenn Sie das nächste Mal ein Problem verschieben, überlegen Sie genau, ob es einen sinnvollen Kontext gibt, den Sie als Kommentar hinzufügen können. Wirklich, wirklich, ehrlich – denken Sie genau nach. Nur weil etwas für Sie offensichtlich ist und sich so anfühlt, als sollte es für jeden offensichtlich sein, ist es das oft nicht. Und selbst wenn dies der Fall ist, sind Informationen oft kurzlebig, schweben verbal herum und sind in E-Mail-Threads vergraben. Verfügt die nächste Person, die dieses Problem bearbeitet, auch wenn sie gerade aus einem zweiwöchigen Urlaub gelandet ist, über alle Informationen, die sie benötigt, um direkt an Ort und Stelle mit dem Problem fortzufahren? Wenn nicht, aktualisieren und kommentieren Sie, bis sie es tun. Es gelten die Grundsätze der Pfadfinder: Lass es in einem besseren Zustand, als du es vorgefunden hast, es spielt keine Rolle, wer daran schuld ist. Irren Sie sich immer auf der Seite von Unterannahmen und Überkommunikation.
Nun, wenn Ihre Version der Ereignisse richtig ist und John falsch liegt, werden Sie sehr schnell auf ein Problem stoßen, bei dem buchstäblich nichts verbessert werden könnte. Jetzt schlagen Sie zu: "John, hast du eine Sekunde Zeit? Das war es, wovon ich gesprochen habe. Ich bin hier völlig ratlos, was soll ich hier kommentieren?" Seien Sie NICHT aggressiv oder hämisch, das ist eine ehrliche Frage: Denken Sie daran, John will nur das Beste für das Team.
Wenn Sie das ein paar Mal gemacht haben und John zu kurz gekommen ist, fügen Sie beiläufig einen Abschnitt zu Johns Wiki-Seite mit dem Titel „Ausnahmen“ hinzu und ordnen die Ausnahmen ein. Wenn dieser Abschnitt mit von John genehmigten Ausnahmen wächst, wird es ihm peinlich, und er wird seine Position revidieren, sie weniger starr machen. John wird erkennen, dass Sie ein vernünftiger Typ sind, und Ihre Bedenken in Zukunft eher berücksichtigen.
Und wenn Sie am Ende nicht bei einer solchen Liste von Ausnahmen landen, hatte John vielleicht doch Recht, und seine Vorschläge, so unbeholfen und unhöflich sie auch sein mögen, haben Ihre Arbeit tatsächlich verbessert – und Sie standen ihr nicht im Wege.
Dies wird keine beliebte Antwort sein oder etwas, das Sie hören möchten. Ich denke, dass das eigentliche Problem in diesem Satz genau hier gekapselt ist:
Ich denke, dass ein großes Problem in unserem Unternehmen darin besteht, dass uns (Entwicklern) so viel vorgeschrieben wird, dass dies jeden Antrieb und jedes Verantwortungsgefühl erstickt, unsere Produktivität zu verbessern.
Es hört sich so an, als hätte Ihr Arbeitsplatz viele Regeln und Bürokratie und eine allgemeine Kultur, die einen Teil der Freude am Programmieren erstickt, und das ist (verständlicherweise) sehr frustrierend. Es hört sich also so an, als würden Sie auf Johns Bitte einschlagen – nicht, weil seine Bitte wirklich eine große Sache ist, sondern weil Sie frustriert sind und er nicht in Ihrer direkten Befehlskette steht, sodass er leicht zu verprügeln ist.
Johns Bitte ist vernünftig und durch einen tatsächlichen Bedarf motiviert. Externe Audits und Akkreditierungen sind ein berechtigtes Anliegen für einen Leiter der QA-Abteilung und seine Vorgesetzten im oberen Management (auch wenn Ihr Unternehmen diese nicht streng durchführt). Wenn jemals ein Audit durchgeführt wird und ein Problem mit fehlerhafter Software gefunden wird, die durch Ihren Bugtracker schlüpft, oder (schlimmer) eine Sicherheitslücke, die durch Ihren Bugtracker gesegelt ist, und es keine Kommentare gibt, die einen Kontext für den Denkprozess des Programmierers liefern könnten, dann ist die Optik sehr schlecht für John und seine QA-Abteilung. Das erste, was sie wissen wollen, ist: "Warum kommentieren Ihre Programmierer keine Fehlerkorrekturen?" Und seine beste Antwort wird sein: "Weil ich sie davonkommen ließ, es nicht zu tun." Das ist keine akzeptable Antwort.
Es ist nicht so, dass John dich um etwas Beschwerliches bittet. Wenn der Fehler lautete "Schaltfläche ist deaktiviert, wenn das Kontrollkästchen angeklickt wurde; sollte nicht deaktiviert werden", dann fügen Sie einfach einen Einzeiler hinzu (genau wie Sie es (hoffentlich) in Subversion / Git tun: "feste Schaltfläche - nicht mehr deaktiviert, wenn das Kontrollkästchen angeklickt wird "). Wenn Sie es von der Swimlane „In Bearbeitung“ in die Prüfung „Vollständig/Abnahme“ (oder was auch immer der Prozess Ihres Unternehmens ist) verschieben, geben Sie John einfach einen einzeiligen Kommentar. Sogar ein dummer / Boilerplate-Kommentar. Das Wichtigste, was Johns braucht, ist ein Einblick in den Kopfraum des Programmierers. Es dauert ungefähr 10 Sekunden und hilft, ein berechtigtes Bedürfnis zu befriedigen.
Es hört sich so an, als ob Ihr Unternehmen gute Software schreiben (zumindest versuchen ) möchte, weshalb es die Gehälter Ihrer QA-Abteilung zahlt. Der Kampf gegen die Fähigkeit Ihrer QA-Abteilung, Ihr Unternehmen vor fehlerhafter Software zu schützen (selbst wenn sie es (Ihrer Meinung nach) nicht richtig macht), lässt es für das Management so aussehen, als seien Sie schwierig und arbeiten gegensätzlich zu einem gültigen Unternehmen brauchen. Ihr Chef wird diesen Kampf nicht führen, weil er weiß, dass es eine hoffnungslose Kampagne ist. Ihr Unternehmen wird Ihre QA-Abteilung nicht davon abhalten (zu versuchen), ihre Arbeit zu erledigen. Und Johns Argument ("Wir brauchen dieses kleine Ding, um revisionssicherer zu sein") ist stärker als Ihres ("Er ist nicht mein Boss").
Als Entwickler sind Sie sicherlich bereits mit dem Konzept von jemandem vertraut, der weiß, was er will und was nicht richtig ist, aber keine klaren und offensichtlichen Regeln formulieren kann, die dies beschreiben. Die Ironie, dass Ihr QA-Leiter nicht in der Lage ist, Anforderungen für diese Kommentare zu einer Statusänderung zu schreiben, ist reichlich, aber es hilft Ihnen nicht, Ihre Arbeit zu erledigen.
Ich schlage vor, Sie wenden sich an den Kollegen und bieten an (fragen Sie, ob es in Ordnung ist, schlagen Sie vor, dass Sie beide) eine Reihe guter und schlechter Beispiele für Kommentare zu dem gestarteten Wiki hinzufügen. Schlagen Sie laut vor, gemeinsam daran zu arbeiten, bevor das Wiki aktualisiert wird. Da Sie inhaltslose Gummistempelkommentare nicht mögen, können Sie einige davon („bereit zum Testen“, „Codierung abgeschlossen“, „wie heute in Scrum besprochen“) auf die schlechte Seite setzen, und mit etwas Glück wird Ihr QA-Leiter vorschlagen einige für die gute Seite, die Probleme angehen, die die neue Regel zu verhindern versucht ("Verschieben zu Test, obwohl Kategorien nicht alphabetisch sind - der Kunde hat zugestimmt, dass wir das nicht brauchen", "zurück zum Code, weil der Kunde jetzt möchte, dass alle Spalten zentriert sind" ) oder in der Vergangenheit gemocht hat.
Sie sollten mit aus dem Meeting kommen
Was kann es weh tun?
Dies ist die Aufgabe Ihres Managers. Wenn das Team ein Problem mit einem Mitglied hat, sollte dies dem Manager bereits aufgefallen sein. Wenn nicht, machen Sie ihn/sie darauf aufmerksam.
Alles, was sich auf den Arbeitsablauf und die Teammoral auswirkt, sollte dem Vorgesetzten zur Klärung übergeben werden. Das ist der professionelle Weg, nicht um den heißen Brei herumreden oder eigene Protokolle erstellen. Es ist eine der Hauptrollen des Managers.
rauben
Keschlam
rauben
Eintauchen