Frage:
Wie man einen Nicht-Programmierer bittet, mich bei Programmieraufgaben nicht zu beraten
FunnyJava
2018-06-18 13:28:38 UTC
view on stackexchange narkive permalink

Ich habe dieses Problem mit einem ansonsten sehr angesehenen Kollegen, der die Position eines Beraters / Testers in meinem Team innehat. Da sie zweimal in den Jahren im Unternehmen waren, in denen ich hier gearbeitet habe, haben sie großartige Erfahrungen mit der Funktionsweise gesammelt und können in dieser Hinsicht sehr hilfreich sein. Sie kennen auch einige technische Dinge - aber keine Programmierung.

So weit so gut. Es gibt jedoch einige Reibereien zwischen uns, wenn wir zusammenarbeiten müssen, und ich möchte die Dinge wirklich regeln und nicht frustriert werden, wenn dies geschieht.

Obwohl sie sehr gut darin sind, was sie tun, stören sie manchmal die Arbeitsweise von I . Lassen Sie mich erklären: Sie werden sehr ängstlich und ungeduldig, wenn sie (manchmal fälschlicherweise) annehmen, dass ein Problem dringend oder schwer zu beheben ist. Sie gehen sogar in Längen wie das Erraten des tatsächlichen Fehlers und das Auffordern, bestimmte Funktionen / Codes zu untersuchen, wenn ich bereits festgestellt habe, dass das Problem an anderer Stelle liegt. Oder sie geben mir Ratschläge zu sehr einfachen Algorithmen (mit anderen Worten, wie ich codieren soll), nach denen ich nicht gefragt habe. Sie respektieren oft nicht den geschätzten Aufwand, den ich ermittelt habe (was logisch ist, weil sie keine Codierung kennen, aber immer noch sehr frustrierend, da ich selbst viele Jahre im Projekt bin). Sie versuchen oft, mich an die mir zugewiesenen Fehler zu erinnern und fragen mich häufig nach den Fortschritten, die ich gemacht habe (mit anderen Worten, sie spammen mich, wenn ich versuche zu arbeiten). Dieses ganze Verhalten macht die Dinge öfter schlimmer als nicht.

Ich weiß es wirklich zu schätzen, dass sie mir anstelle der anderen Entwickler die dringendsten und manchmal kompliziertesten Probleme zuweisen. Aber ich bin auch eine ängstliche Person und Multitasking beeinträchtigt meine Produktivität. Wenn ich nicht übermäßig nervös bin und nicht sehr oft von Codierung zu Kommunikation wechseln muss, habe ich den Code viel früher bereit, als ich sollte. Aber wenn ich häufig unterbrochen werde, verlangsamt sich meine Arbeit. Ich mag auch keine unnötigen Kommentare darüber, wie ich codieren soll, da dies impliziert, dass ich nicht weiß, wie ich meine Arbeit machen soll. Ich habe ihnen bereits gesagt, dass sie mich nicht unterbrechen müssen, und versucht zu implizieren, dass Ratschläge zur Codierung unnötig sind, aber ohne Erfolg.

Ich habe versucht, sie über etwas zu beraten, das ihre Pflichten betrifft. und sie erinnerten mich zu Recht daran, dass es ihre Aufgabe war. Sie sind sich also der Grenzen der Position jedes Teammitglieds bewusst, aber leider nicht ihrer eigenen.

Meine Frage lautet: Wie soll ich ihnen vermitteln, dass unsere Zusammenarbeitstechnik nicht funktioniert? Mein Ziel ist es, effektiver zusammenzuarbeiten.

HINWEIS: Sie beziehen sich auf eine einzelne Person. Sup>

Kommentare sind nicht für eine ausführliche Diskussion gedacht.Diese Konversation wurde [in den Chat verschoben] (https://chat.stackexchange.com/rooms/79069/discussion-on-question-by-funnyjava-how-to-ask-a-non-programmer-not-to-berate mich).
Es hört sich so an, als würde er versuchen, in die Rolle eines Projektmanagers zu schlüpfen.Gibt es bereits einen engagierten Projektmanager in Ihrem Team?Wenn ja, oder irgendein Vorgesetzter, würde ich ihm das mitteilen ... Sie haben bereits den Eins-zu-Eins-Ansatz ausprobiert.
Da keiner von uns weiß, wer Sie sind, und somit keiner von uns weiß, wer die betreffende Person ist, warum nicht _he_ oder _she_ sagen?Es ist nicht sexistisch, ein einziges Geschlecht zu verwenden, wenn Sie über eine bestimmte Person sprechen.
@kyralessa Wie können Sie wissen, dass diese Person, auf die sich das OP bezieht, das Pronomen "sie" nicht bevorzugt, wenn auf sie Bezug genommen wird?Sie können nicht davon ausgehen, dass "er" oder "sie" hier angemessen sind.Es wäre cis-geschlechtsnormativ für Sie anzunehmen, dass beides hier am besten geeignet ist.
@Kyralessa, Das OP hat möglicherweise versucht, keine unnötigen Hinweise auf die Identität zu geben.
Die Verwendung von "sie" vermeidet auch geschlechtsspezifische unbewusste Vorurteile. Der Wortlaut hier wird durch die Verwendung von "sie" nicht unverständlich gemacht, und ich denke nicht, dass sich eine Änderung in "er" oder "sie" wahrscheinlich erheblich verbessern wirddie Frage.
Aus persönlicher Erfahrung: Wenn Sie an Ihrer Kommunikation arbeiten und die Situation richtig erklären, werden sie verstehen, dass der schnellste Weg zu einer Lösung darin besteht, Sie arbeiten zu lassen.- Oder ihre Hauptmotivation ist vielleicht, dass Sie nicht schnell arbeiten, aber sie genießen Diskussionen mit Ihnen mehr als andere Aufgaben und sind in Ordnung, wenn Sie länger mit ihnen reden?
@Falco nein, sie wollen so schnell wie möglich Korrekturen.Deshalb geraten sie in Panik.
@Snow Englisch kann grammatikalisch ziemlich rau und dennoch verständlich sein.Ist "verständlich" der einzige Standard?Die Verwendung von "sie" als Singularpronomen führt zu Gewalt gegen die Sprache.Wenn Leute gegen ein geschlechtsspezifisches Singularpronomen der 3. Person protestieren, empfehle ich, auf Ungarisch zu wechseln, wo das Singularpronomen der 3. Person für ihn, sie und es dasselbe ist.Englisch hat so etwas nicht;"sie" ist es nicht.
Sie glauben nicht, dass Sie ihre Probleme so schnell lösen können oder können, wie sie es brauchen, und versuchen daher, Ihnen zu helfen, Ihre Bearbeitungszeit zu verbessern.Ich würde vorschlagen, dass Sie einige Zeit damit verbringen, herauszufinden, warum dies so ist und wie es verbessert werden kann.
@user1602: Sie empfehlen wirklich, auf dieser Seite auf Ungarisch zu wechseln ??!
Vierzehn antworten:
#1
+77
Jeremy French
2018-06-18 13:59:13 UTC
view on stackexchange narkive permalink

Es hört sich so an, als gäbe es viele Probleme, von denen viele mit der Kommunikation zusammenhängen.

Tägliche Standups könnten dabei helfen. Sie sind ein Werkzeug aus der agilen Welt. Auch wenn Sie keiner agilen Methodik folgen, können Sie sie dennoch nützlich finden.

Ganz einfach, jedes Mitglied des Teams steht zu Beginn des Tages zusammen und sagt, woran sie gestern gearbeitet haben, woran sie an diesem Tag arbeiten wollen und was sie aufhält. Ihre QS-Person sollte sich darum kümmern, damit sie weiß, was los ist, und Fragen stellen kann, um Prioritäten bei der Arbeit zu setzen.

Ein Issue-Tracker Jira, Trello usw. kann verwendet werden, um eine zu erstellen Aktueller Status der Probleme. Wenn Sie dies als primäre Informationsquelle beibehalten, müssen Sie dies weniger per E-Mail tun. (Wenn Sie eine haben, verweisen Sie einfach weiter auf Fragen und lehnen Sie die direkte Beantwortung ab.)

Der aktuellste Status des Problems befindet sich bitte unter Link zu Problem Überprüfen Sie dies auf Aktualisierungen.

Eine offene Diskussion über Kommunikation und Kontextwechsel Dies ist direkter als die anderen Ansätze, könnte sich aber sehr lohnen. Es kann sein, dass der Tester keine Ahnung hat, wie störend die Kontextumschaltung für einen Programmierer ist. Unterstützen Sie es mit Beweisen, wenn Sie müssen. Es ist klar, dass Sie beide dasselbe Ziel haben, aber es ist nicht klar, ob der Nicht-Programmierer weiß, wie sich die Unterbrechungen auswirken.

Verwenden Sie einen Projektmanager (eine Person) Ein Vermittler, der die Programmierer vor Unterbrechungen schützt, kann helfen. Ein guter Projektmanager kann der QS-Person helfen, indem er die relative Priorität der verschiedenen Arbeitsbereiche anzeigt sowie neue Probleme aufgreift und priorisiert, ohne dass die Programmierer sofort wechseln müssen. (Ein schlechter wird dies leider nicht tun, sondern Sie direkt kontaktieren, so dass Sie doppelt so viele Unterbrechungen haben)

Schließlich wäre es gut, wenn Sie die Seltenheit einer guten QS-Person schätzen könnten. Es hört sich zwar so an, als würden sie Ihre Arbeit nicht schätzen, aber ich denke, dass Sie sie möglicherweise nicht schätzen. Eine gute Qualitätssicherung mit fundiertem Wissen und Leidenschaft für ein Produkt ist eine sehr seltene Sache. Ich bin sicher, dass es falsch positive Ergebnisse gibt, bei denen sie die falsche Ursache des Problems identifizieren, aber ich gehe davon aus, dass sie oft helfen, indem sie vorschlagen, wo etwas schief gelaufen ist. Die Tatsache, dass sie ungefähr wissen, wie das System funktioniert, ist ein großer Bonus. Ich bin sicher, Sie würden sie vermissen, wenn sie gehen würden.

"(Wenn Sie eine haben, verweisen Sie einfach weiter auf Fragen und lehnen Sie es ab, direkt zu antworten.)" Das ist eigentlich ziemlich schrecklich für das Arbeitsumfeld, niemand mag es, wenn Sie den passiv aggressiven Weg gehen.Es ist besser, eine Antwort zu geben, sie aber auch an den Issue-Tracker weiterzuleiten. Machen Sie es lästig, damit sie lernen.
* Beweise (nicht genug Wiederholungen, um eine so kleine Bearbeitung vorzunehmen)
@kevin Dies ist * keine * passive aggressive Aktion.Wenn es jemanden gibt, der für das verantwortlich ist, was in einem bestimmten Zeitraum erledigt wird, ist es Standard, Personen an ihn zu verweisen.Der Versuch, eine solche Person zu umgehen, ist höchst unprofessionell.
@Cronax Lesen Sie die Antwort und meinen Kommentar noch einmal. Ich antwortete auf einen Teil über das Verweisen von Personen auf einen Issue-Tracker, ohne ihre Frage zu beantworten. Das ist sehr unprofessionelles und kindisches Verhalten.Ich würde Ihnen zustimmen, wenn es eine engagierte Person gäbe, aber es ist eine giftige Präsenz in der Arbeitsumgebung, den Leuten zu sagen, sie sollen es in den Rückstand aufnehmen, ohne zu versuchen, von Angesicht zu Angesicht mit ihnen zu kommunizieren.Dies ist ein sicheres Zeichen dafür, dass Sie nicht in der Lage sind, Probleme im Team professionell zu lösen.
@kevin Ich würde argumentieren, dass es bei einem Problem-Tracker selbst unprofessionell ist, eine E-Mail an den Entwickler zu senden, anstatt das Problem zuerst zu überprüfen.Sie können dasselbe Problem in einem anderen Kontext betrachten: Was tun Support-Abteilungen als Erstes bei nahezu jedem Webdienst?Zeigen Sie auf die FAQ.
@NemesisX00 Aber ist das ein Grund, die gleiche Art von Unprofessionalismus zurückzugeben?Wenn jemand zu mir über dieses oder jenes kommt, sage ich etwas in der Art von "Ich werde sehen, ob es noch in Jira ist, kannst du einen Blick mit mir werfen" und mache es dann und dort mit ihnen.Während ich nachschaue, ob das Problem noch besteht, kann ich es beantworten, wenn ich die Antwort weiß.Es gibt der Person, die nach einer Lösung fragt, das Problem, wenn es noch nicht vorhanden war, mit allen relevanten Informationen und hält alle miteinander zufrieden.
+1.Allein der Link zu "The Multitasking Myth" (und die daraus verlinkten Seiten) ist eine positive Bewertung wert (da erzwungener Kontextwechsel ein großer Teil des OP-Problems ist).
Warum der Tippfehler auf dem Wort "Economist" in Ihrem Profil, Jeremy?
1+ bei den "Daily Standups"!Allein die Tatsache, einem Team Raum und Zeit zu geben, um darüber zu sprechen, was heute passieren wird, macht viele Diskussionen unnötig.
Jeremy, ich weiß, dass dies geringfügig ist, aber was die täglichen Stand-ups betrifft: Nicht jeder kommt zur gleichen Zeit zur Arbeit (diese Person kommt zum Beispiel mindestens 3 Stunden nach mir an), wäre es also nicht so effizient, sich abends zu treffen?Auf diese Weise können wir auch darüber diskutieren, was tagsüber passiert ist.Gibt es einen besonderen Grund dafür, dass diese Treffen früh am Tag stattfinden?
@FunnyJava Die meisten Stand-Ups sind früh, um Folgetreffen zu ermöglichen.Stand-Ups sollten nicht länger als 5 Minuten dauern und niemals Details besprechen.Ich verfolge die Zeit in Standups und wenn ein Update zu einer Diskussion wird, erinnere ich die beteiligten Personen daran, dass sie nach dem Standup ein kleines Meeting haben können.Ein weiterer Grund ist, wie es sich anfühlt: Ein frühes Aufstehen fühlt sich an wie "hier ist, was ich gestern getan habe und heute fange ich damit an".Ein später Standup fühlt sich an wie "hier ist der heutige Bericht und hier ist mein Plan morgen".Der eine ist optimistischer und der andere wie ein Bericht
@slebetman In meinem Fall ist dies nicht wichtig.Wie ich im vorherigen Kommentar erwähnt habe, variieren die Ankünfte der Teammitglieder, so dass das Meeting nicht zu einer Standardstunde stattfinden konnte (sicherlich nicht vor Mittag) und mich wahrscheinlich trotzdem unterbrechen würde.Jeremy, kannst du späte Stand-ups in deiner Antwort berücksichtigen und wie wären sie effektiver?
#2
+46
gnasher729
2018-06-18 17:26:03 UTC
view on stackexchange narkive permalink

Erzählen Sie ihm die Geschichte des Automechanikers, der gefragt wurde, wie viel er berechnet. Seine Antwort war: "Es sind 25 US-Dollar pro Stunde. Es sind 35 US-Dollar, wenn Sie zuschauen, 45 US-Dollar, wenn Sie Ratschläge geben, und 55 US-Dollar, wenn Sie versuchen, zu helfen. “

-1 Dies ist nicht besonders hilfreich und wird höchstwahrscheinlich den Kollegen des OP antagonisieren.
+1 dis lustig, aber @camden_kid ist richtig, das ist wirklich ein schlechter Rat.
Dies ist eine der besten Möglichkeiten, um sich im Arbeitsbereich Feinde zu machen.
@closetnoc Es gibt Raum für Humor, aber wir müssen uns daran erinnern, dass Humor und Sarkasmus im Internet nicht immer gut gelesen werden können, insbesondere wenn nicht jeder fließend Englisch spricht.Dies wurde [zuvor in Meta besprochen] (https://workplace.meta.stackexchange.com/questions/4212/is-there-any-room-for-humor-in-the-answers-and-comments-how-viel), und die Antwort ist, dass Humor in Ordnung ist, solange Sie explizit angeben, was ernst genommen werden soll oder nicht, und die Frage dennoch in einfachem Englisch beantworten.
Ich bin der Meinung, dass diese Antwort besser aufgenommen würde, wenn sie eine alternative Antwort hätte, falls der Mitarbeiter von OP keinen Witz verstehen könnte.
@DavidK vereinbart.Ich mische Humor mit einer Antwort.Ein bisschen albern und ernst.Sarkasmus, Snarkiness, Pseudo-Rants usw. waren alle ein Teil meines Arsinals, wenn auch mit viel Freundlichkeit.Es funktioniert bisher bei mir.Es wäre gut, einfach eine kurze und prägnante Antwort hinzuzufügen.Genau!Prost!!
Dies kann völlig funktionieren, aber nicht als eigenständige Antwort.Es ist lustig und illustrativ und könnte als Nachtrag dienen."Wenn Sie Probleme haben, meinen Standpunkt über Unterbrechungen zu verstehen, die meine Arbeit beeinträchtigen, ist hier ein Witz über Mechanik ..."
Theoretisch ist diese Antwort wirklich gut, um zu demonstrieren, wie einfach es sein könnte, und ich schätze es.Ich bin nicht einverstanden mit den Kommentaren, dass der Kollege verärgert sein würde - ich denke, es besteht eine gute Chance, dass er den Humor (und den Punkt) bekommt und sein Verhalten widerspiegelt.Angesichts des Schreibens des OP ist er jedoch nicht diese Art von Person, die eine solche Antwort auf sie gibt.Wenn er es wäre, würde das anfängliche Problem nicht existieren.Dennoch könnte die Lösung einfacher sein, als das OP annimmt.
@IgorSoloydenko Nicht unbedingt.Ich bin mir über das OP nicht sicher, aber ich bin mir ziemlich sicher, dass der QS-Ingenieur, bei dem ich arbeite, ein gutes Lachen daraus machen würde.Natürlich sind die Lieferung und der Sinn für Humor der anderen Person wichtig (ebenso wie ihre aktuelle Stimmung). Unser QS-Ingenieur und ich scherzen die ganze Zeit miteinander, aber wir kennen uns schon lange und wir wissen beideEs macht alles Spaß.In der Lage zu sein, miteinander zu scherzen, hilft tatsächlich dabei, Freunde am Arbeitsplatz zu finden, wenn dies mit dem richtigen Takt richtig gemacht wird.
Wenn sie gut gemacht sind, können Metaphern über Code Wunder wirken.Ich erinnere mich, dass ich einem Kunden, der ständig spontan nach neuen, nicht verwandten Funktionen fragte, einmal erklärt habe, dass das Erstellen eines Programms dem Bauen eines Hauses gleicht und dass das Bitten, die Wand ein Stück weiter zu bewegen, tatsächlich war, sobald eine Wand vorhanden istBitten Sie darum, eine Mauer einzureißen und eine neue zu bauen.Der Kunde kann am nächsten Tag ein langes Meeting abhalten, nachdem er endlich verstanden hat, dass alle Teile miteinander verbunden sind und dass die Software bei der Planung viel besser und schneller erstellt wird als im laufenden Betrieb.
#3
+25
Old_Lamplighter
2018-06-18 17:59:59 UTC
view on stackexchange narkive permalink

Ich bin auf genau das gestoßen, was ich getan habe.

Hinweis: Tun Sie dies nur, wenn keine Dringlichkeit besteht und Sie Zeit haben.

Andernfalls habe ich auch festgestellt, dass Analogien verwendet und Dinge in Begriffen ausgedrückt werden, die die Person versteht Dies ist der beste Weg, um der Person das Verständnis zu erleichtern.

Sie können eine Automobilanalogie verwenden, wenn Sie möchten. Sie können ihm sagen, dass Ihr Mechaniker das Problem erst diagnostizieren muss, bevor er weiß, was los ist, und dass nur, weil Ihr Motorlicht eins ist, dies nicht bedeutet, dass Ihr Auto im Begriff ist zu sterben. Es könnte bedeuten, dass Ihr Tankdeckel nicht richtig sitzt. Gleiches gilt für die Behebung von Fehlern mit Programmen. Die Tatsache, dass es eine gibt, bedeutet nicht, dass es schwierig zu beheben ist oder dringend ist.

Der QA-Typ weiß, was ein großes Problem ist und was nicht.Was der QA-Typ nicht weiß, ist, wie groß die Codeänderung sein würde oder was geändert werden müsste.
+1 für die Untersuchung des [Mahn-Krüger-Effekts] (https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect).Wenn die inkompetente Person tatsächlich sehen kann, wie viel sie nicht weiß, dass Sie es tun, wird sie sich viel sicherer fühlen, wenn sie Ihnen Entscheidungen anvertraut.
@DavidThornley, das ist genau der Punkt, den ich angesprochen habe, aber Sie können gerne Ihre eigene Antwort geben.
Ich vermeide es, ihnen Code zu erklären / zu zeigen (sie bestehen normalerweise sowieso darauf).Der Grund dafür ist, dass sie sich dann sicherer fühlen, wenn sie erraten, wo das Problem liegt, und dies macht die Sache für mich noch schwieriger.
@FunnyJava - Indem Sie die Haltung einnehmen, die Sie gerade beschrieben haben, verschlimmern Sie das Problem tatsächlich.Der Versuch, sich selbst und Ihren Code abzuschirmen, baut Wände auf und beeinträchtigt die Kommunikation.
Ich habe ein Problem damit, während der Arbeit unterbrochen zu werden und nicht generell zu kommunizieren.Ich schütze meinen Code nicht, ich arbeite sowieso mit anderen Entwicklern am gleichen Code, es ist einfach nicht meine Aufgabe, einen Berater über Code zu unterrichten.
@FunnyJava Ihre Aufgabe ist es, die Arbeit zu erledigen.Als Projektmanager brauchte ich meine Berichte von jemandem, der mit Excel nicht vertraut war.Es war auch nicht in meiner Stellenbeschreibung, ihm zu helfen, aber raten Sie mal, wer seine Berichte danach vor allen anderen erhalten hat.Manchmal brauchen Sie einen kreativeren Ansatz
@DavidThornley stimmte Ihnen zu und kritisierte Ihre Antwort nicht.
#4
+16
Jay
2018-06-18 21:33:19 UTC
view on stackexchange narkive permalink

Diese Person versucht nur zu helfen, schießt ihnen nicht in den Fuß. Alles, was Sie sagen müssen, ist:

"Ich habe diesen [Namen der Person], danke dafür Ihre Hilfe. Ich werde Sie wissen lassen, wenn ich Fragen habe. "

Wenn sie sofort mit mehr Hilfsbereitschaft zurückkommen, wiederholen Sie sich. Unterhalten Sie keine langen Gespräche über das Update, insbesondere wenn Sie sie als nicht hilfreich empfunden haben. Dies wird sie nur ermutigen, jetzt und in Zukunft weiter zu reden.

Wenn sie Sie immer noch belästigen, müssen Sie ihnen nur zeigen, dass sie mit harten Fakten zu diesem Thema falsch liegen. P. >

[Name der Person], ich verstehe, was Sie über 'A' sagen, aber ich weiß, dass das Problem wirklich mit 'B' zusammenhängt, wie ich sehe (Protokolle, Ereignisse, Daten usw.) Beweise es. Im Moment muss ich mich wirklich konzentrieren, um alles zusammenzubringen und eine Lösung zu finden.

Es gibt einen bestimmten Persönlichkeitstyp, der eine Idee oder einen Vorschlag noch lange nach dem Wechsel des Themas oder dem Beenden des Gesprächs zum Ausdruck bringen muss.Ich denke, viele Leute in diesem Thread verstehen das entweder nicht oder verstehen nicht, wie sehr dies ein Problem verursacht.Sätze, wie Sie sie vorschlagen, sind gute Techniken für den Umgang mit dieser Art von Persönlichkeit.und eskalieren bei Bedarf.
Mir ist bewusst, dass sie versuchen zu helfen.Ich habe unzählige Male getan, was Sie gesagt haben. Das Ergebnis war, dass sie jedes Mal hartnäckiger zurückkehrten, bis sie meine Konzentration endgültig ruiniert haben und ich widerstrebend nachgebe, zu erklären, was ich tue / tun werde, anstatt es zu tun.
@FunnyJava, Ich habe meine Antwort aktualisiert, um Ihnen einige zusätzliche Gedanken für die ständige Belästigung zu geben, insbesondere wenn Sie eine Ahnung haben, was los ist.
@FunnyJava: Wenn diese Techniken nicht funktionieren, ist es Zeit, das Management einzubeziehen.Wenn sie nicht helfen, bedeutet dies, dass Ihr Management ineffektiv ist und Sie kritischer darüber nachdenken müssen, wie lange Sie in dieser Position bleiben möchten.
#5
+11
Hoàng Long
2018-06-18 22:34:02 UTC
view on stackexchange narkive permalink

Ich bin mir nicht sicher, ob dies hilft, aber so gehe ich mit Situationen wie Ihrer um:

Situation A. Wenn Ihr Kollege Ihnen ein Problem vorlegt:

1. Hören Sie dieser Person zu

Was auch immer Sie tun, hören Sie zuerst zu. Hören Sie sich ihr Problem an: keine Reaktion, kein Kommentar, kein Chatten am Telefon. Bleiben Sie von Angesicht zu Angesicht, wenn Sie können.

Dadurch fühlt sich die andere Person respektiert und erleichtert Ihnen das Leben .

2. Denken Sie ein bisschen nach.

Versuchen Sie, jedes Wort zu verstehen, das sie sagen. Glauben Sie mir, ich dachte oft, ich hätte eine Idee vollständig verstanden, aber später lief es anders.

Atmen Sie tief ein und geben Sie sich etwas Zeit, um zu verarbeiten, was sie sagen. Fahren Sie dann mit dem nächsten Schritt fort.

3. Wiederholen Sie ihre Ideen in Ihren eigenen Worten.

Erklären Sie ihre Probleme auf eine Weise, die Sie beide verstehen können. Wenn es zu viele Punkte gibt, versuchen Sie, eine kurze Notiz zu machen und sie Punkt für Punkt zu zitieren. Wenn es unklare Informationen gibt, lassen Sie sie klären. Zum Beispiel:

  • Wenn ich das richtig verstehe, meinen Sie, dass sich die Schaltfläche in der oberen linken Ecke des Bildschirms befinden muss?
  • Sie meinen, dass unser Programm erheblich langsamer ist mit bestimmten Eingaben. Lassen Sie uns noch nicht über den Algorithmus sprechen. Welche Art von Eingabe verursacht die Verzögerung? Können Sie mir ein Beispiel geben?
  • Sie denken also, dass dieses Problem heute vor der Veröffentlichung behoben werden muss. Ist es richtig?

Beachten Sie, dass es in Schritt 1 => 3 darum geht, die Meinung der anderen Person zu verstehen . Sie haben hier keine Eingabe, außer vielleicht einige Beispiele, um ihre Probleme zu klären.

Es mag viel aussehen, aber Schritt 1 => 3 dauert oft nicht länger als 2 Minuten

4. Folgen Sie mit einer Antwort / Klarstellung

Nachdem Sie nun alle Informationen von ihrer Seite haben, können Sie Ihre Antwort perfekt formulieren. Beispiel:

  • Ich habe geglaubt, dass die Schaltfläche aufgrund einer kürzlich vorgenommenen Änderungsanforderung nach oben rechts auf dem Bildschirm verschoben wurde, aber ich habe mich möglicherweise geirrt. Lassen Sie mich das überprüfen und ich werde mich später bei Ihnen melden.
  • Das Programm ist also erheblich langsamer, wenn die Eingabe eine negative Zahl ist. Hmm, interessant. Ich glaube, ich habe eine Idee, wo das Problem liegt, sie bezieht sich möglicherweise nicht auf unseren Algorithmus. Lassen Sie mich einen kurzen Blick darauf werfen und ich werde Sie aktualisieren.
  • Bei unserem letzten Meeting habe ich mich daran erinnert, dass diese Funktion erst in der nächsten Version benötigt wird. Darauf bin ich zuversichtlich. Wenn Sie immer noch besorgt sind, können wir die Besprechungsnotiz erneut überprüfen, um sicherzugehen.

Situation B. Um zu vermeiden, dass Sie unterbrochen werden, wenn Sie "im Fluss" sind. stark>

Kollege X : Hey, ich denke, Sie sollten sich diesen Fehler T4235 ansehen. Ich glaube, es ist in der Suchfunktion und es ist nur eine schnelle Lösung. Können Sie mir helfen?

Ich : Ok. Darfst du ein wenig warten? Ich bin im Fortschritt dieser T100-Funktionen, die wir brauchen, um diesen Sprint zu liefern. Ich werde Sie vor dem Mittagessen erreichen und wir können diskutieren.

oder

Ich : Geben Sie mir 15 Minuten. Ich bin mitten im T100. Ich werde mich danach darum kümmern.

Der beste Fall ist: Sie können ein festes Zeitfenster für die Kommunikation einrichten . Dies kann vor dem Mittagessen, am Ende des Tages oder direkt nach einer wöchentlichen Besprechung erfolgen. Wenn Leute mit einem nicht dringenden Problem zu Ihnen kommen, bitten Sie sie, alle ihre Fragen zu sammeln und zu Ihrem Zeitfenster zurückzukehren. Auf lange Sicht wird es für Sie beide eine Zeitersparnis sein: Sie können mit Ihrem Flow weitermachen und sie erhalten die beste Unterstützung, wenn Sie am besten darauf vorbereitet sind.

Ich denke, der Mitarbeiter ist ein bisschen neurotischer als Sie denken.Ich begegne regelmäßig Menschen, die einfach immer denken, dass ihre Ideen richtig sind und nicht wissen, wann sie aufhören sollen.Der obige Ansatz funktioniert für diese Art von Person einfach nicht.
"Um nicht unterbrochen zu werden, wenn Sie" im Fluss "sind." Ich möchte vermeiden, dass ich diesen kleinen Chat überhaupt durchgehen muss.Es hat sowieso keine Auswirkungen: Sie werden mich später wieder unterbrechen, um zu sehen, was ich tue.
@AndrewRondeau: gibt es keine Silberkugel, die für alle Situationen gelten kann, aber ich denke, wir können zumindest dem Freund mit der guten Absicht eine Chance geben, sich zurückzuziehen.Wenn nicht, dann ist es einfach: Sei höflich und doch fest (aus Davids Antwort entnommen).Wir alle müssen die "Hilfe" irgendwann ablehnen.
@FunnyJava: Nun, zumindest auf diese Weise können Sie den Zeitpunkt festlegen, zu dem Sie das Problem effektiv lösen können.Wer weiß, vielleicht finden sie innerhalb dieser Zeit die Antwort selbst und rufen Sie nicht einmal wieder an.Ich habe hier jedoch Bedenken: Wenn der einzige Grund, warum sie zu Ihnen kommen, * zu sehen, was ich tue *, dann denke ich nicht, dass Sie sie unterhalten müssen.Wenn sie ein berechtigtes Anliegen haben, ist dies ein weiteres Problem
Eine geplante Zeit ist in Ordnung, aber ich weiß nicht, ob sie das akzeptieren wollen.Sie wollen wissen, was das Problem ist / wenn ich es gefunden habe, damit sie wieder raten können / beruhigt werden und sich entspannen können.Ich habe unzählige Male erklärt, dass ich zu ihnen komme, wenn ich etwas finde, aber es hatte nicht viel Wirkung.
Sieh aus, als ob du in einer schwierigeren Situation bist als ich dachte.Weißt du warum sie das tun müssen?Haben sie keine anderen Arbeiten zu erledigen?
Möglicherweise haben sie im Moment selbst nicht viel Arbeit.Meine Vermutung (und der anderen Teammitglieder) ist, dass sie zu ängstlich sind, dem Kunden zu missfallen, und wenn sie nicht genau wissen, wie es läuft, werden sie ängstlicher.
Wenn dies der Fall ist, können wir es meiner Meinung nach ruhig und verständnisvoll ausdrücken.Etwas in der Art von "Ich schätze Ihre Besorgnis über ..., aber ich kann meine Arbeit nicht effektiv erledigen, wenn jemand von hinten zuschaut. Dies liegt in meiner Verantwortung und ich werde mich sehr bemühen, sie zu erfüllen."Sagen Sie es ruhig und untermauern Sie Ihre Worte mit echten Fakten über die Zeiten, die Sie liefern.Sei wieder höflich und doch fest.Du kannst es schaffen.
#6
+7
David
2018-06-18 20:36:28 UTC
view on stackexchange narkive permalink

(zu lang für einen Kommentar ...)

@JeremyFrench macht einen guten Vorschlag für einen Projektmanager, aber ich glaube nicht, dass er weit genug geht.

In In den meisten Umgebungen - das heißt, unabhängig von der verwendeten Softwareentwicklungsmethode - muss die Qualitätssicherung nicht feststellen, ob ein Problem dringend ist oder nicht. (Es liegt auch nicht an den Entwicklern.) Diese Verantwortung liegt beim Projektmanager, Produktbesitzer usw. (Wir sprechen schließlich darüber, dem Zeitplan Arbeit hinzuzufügen.) Und der Projektmanager / Produktbesitzer sollte Schwierigkeiten haben (Kosten) bei der Priorisierung von Arbeitselementen berücksichtigen.

In Umgebungen, in denen Rollen, Befugnisse und Verantwortlichkeiten nicht so genau definiert sind, wie sie sein sollten, ist dies meiner Erfahrung nach für QC / QA nicht ungewöhnlich Mitarbeiter, um Fehlerkorrekturen zu priorisieren (auch wenn sie nicht neu sind), neue Anforderungen zu erfinden, vorhandene neu zu schreiben usw. - unabhängig davon, ob Sie einen Issue-Tracker verwenden oder nicht.

Daher wäre mein Vorschlag: Wenn ein solcher Fehler entdeckt wird:

  • Sagen Sie Ihrem Kollegen, dass Sie ihn untersuchen werden, und bieten Sie an, das Problem dem Projektmanager / Produktbesitzer zu melden, wenn Sie Ihre Recherche abgeschlossen haben . (Bieten Sie also an, mit ihnen zu arbeiten, anstatt eine defensive Haltung einzunehmen.)

  • Führen Sie nur minimale Untersuchungen zu den potenziellen Kosten durch. Mit "minimal" meine ich das Problem so weit wie möglich zu dokumentieren, ohne Ihre bestehenden geplanten Verpflichtungen zu beeinträchtigen (ich würde nicht mehr als 15 Minuten vorschlagen). Geben Sie in die Kosten die Anzahl der Funktionen an, die erneut getestet werden müssen.

  • Je nachdem, ob Sie die Kosten leicht ermitteln können, können Sie bei Bedarf eine der folgenden Angaben machen Wenden Sie sich an das Projekt- / Produktmanagement (oder wenn sie sich an Sie wenden):

  • "Die Qualitätssicherung hat diesen Fehler gefunden. Ich gehe davon aus, dass die Behebung etwa eine Woche dauern wird, und wir ' Anschließend müssen alle Berichte erneut getestet werden. "

  • "QA hat diesen Fehler gefunden. Ich habe ein paar Minuten damit verbracht, ihn mir anzusehen, und habe wirklich keine gute Idee, was ihn verursacht. Ich würde mindestens ein oder zwei Tage brauchen, um ihn zu untersuchen."

In beiden Fällen können Sie dem Management die Entscheidung über die Priorität überlassen. (Wenn Ihr Mitarbeiter darauf besteht, dass dies ein Punkt mit hoher Priorität ist und Sie nicht einverstanden sind, können Sie dies in Ihre Erklärung gegenüber dem Management aufnehmen: "X scheint zu glauben, dass dies sofort behoben werden muss. Ich bin nicht sicher, ob ich damit einverstanden bin, weil Es gibt solche und solche Problemumgehungen, und der Aufwand wird wahrscheinlich die nächste Version zurückschieben. "

Wenn Ihr Mitarbeiter Vorschläge hat, was das Problem verursacht:

  • Wenn sie Vorschläge machen, bevor Sie die Gelegenheit hatten, sich damit zu befassen, sagen Sie, dass Sie keine Gelegenheit haben, Nachforschungen anzustellen, aber dass Sie ihren Vorschlag unter Beratung nehmen.
  • Wenn sie danach Vorschläge machen Sie hatten Gelegenheit, sich damit zu befassen, und sagen, dass Sie mit Ihrer Einschätzung des Problems vertraut sind.

Wenn Ihr Mitarbeiter Vorschläge zur Behebung des Problems macht :

  • Wenn Sie keine Gelegenheit hatten, Nachforschungen anzustellen, sagen Sie, dass die genaue Art des Problems nicht ermittelt wurde.

  • Wenn Sie nachgeforscht haben, sagen Sie, dass Sie betrogen sind Seien Sie höflich in Ihrem vorgeschlagenen Fix.

Seien Sie höflich, aber fest.

Update / Klarstellung:
Wenn neu Code erfüllt nicht die Anforderungen, das ist fast immer ein Problem mit hoher Priorität. Ich gehe davon aus, dass diese Fehler nicht von dieser Art sind, sondern vielmehr:

  • vorhandene Fehler;

  • Szenarien (möglicherweise) Randfälle), die das Design des neuen Codes nicht berücksichtigt;

  • usw.

Ich bin nicht sagen, dass diese Art von Problemen automatisch eine niedrige Priorität haben - nur, dass Entscheidungen bezüglich ihrer Priorität nicht von den Entwicklern und / oder Testern getroffen werden sollten.

Aber es kommt darauf an - wenn der Fehler vorhanden ist, ist es sicher eine geschäftliche Entscheidung, wie er priorisiert werden soll.Wenn sich der Fehler in einer neuen Arbeit befindet, die zum ersten Mal getestet wird, hat er meistens (automatisch) hohe Priorität, da er die Ausführung / Annahme dieser Story blockiert, es sei denn, Sie möchten argumentieren, dass die Akzeptanzkriterien dies tun solltengeändert werden, um dieses Verhalten zu berücksichtigen.
@user3067860 Es hängt von der Art des Fehlers ab.Wenn der neue Code nicht den Anforderungen entspricht, würde ich zustimmen, dass er eine hohe Priorität haben sollte.Die Tatsache, dass es Meinungsverschiedenheiten über die Priorität gibt - und der Versuch, dem OP den Vorteil des Zweifels zu geben - lässt mich glauben, dass dies nicht der Fall ist.
Wir haben ähnliche Möglichkeiten, mit der Situation umzugehen.Diese kommen dem, was ich sage und tue, sehr nahe.Aber das oben Genannte auszudrücken, während ich höflich und fest bin (oder nicht, wenn ich dafür zu müde bin), hat bei mir nicht funktioniert.
#7
+5
Andrew Rondeau
2018-06-19 00:57:27 UTC
view on stackexchange narkive permalink

Kurze Antwort : Sie müssen einen Satz wie "[Name]] finden. Ich verstehe dieses Problem. Ich schätze Ihre Vorstellung von [Hypothese]. Sie haben es mir erklärt. Jetzt ist es so." Ich bin an der Reihe, diese Aufgabe zu übernehmen. "

Lange Antwort : Wenn Sie Ihre Frage lesen, ist es wirklich schwer zu wissen, wie die Person ist, mit der Sie arbeiten. Ich treffe regelmäßig Leute, die einfach nicht wissen, wie man mit Programmierern arbeitet. und viele der Antworten in diesem Thread verstehen Ihr Problem auch nicht.

Es hört sich so an, als würden Sie mit einem Persönlichkeitstyp arbeiten, der nicht versteht, wann Sie aufhören sollen, Ideen freiwillig zur Verfügung zu stellen, und Sie Ihren folgen lassen besondere Rolle. Diese Leute verpassen oft die höflichen Gesprächsanreize, um aufzuhören, und wiederholen dieselbe Idee viele Male, selbst wenn dies unangemessen ist.

Nach meiner Erfahrung passieren solche Dinge, wenn das Management unreif ist oder fehlt . In einem solchen Fall sollte Ihr Manager helfen können. auch wenn es nur darum geht, Sie über Ihren Kollegen zu coachen. In Wirklichkeit muss Ihr Manager Ihrem Kollegen erklären, dass er Ihnen in Ihrer Rolle vertrauen muss. Ihr Manager muss erklären, dass er einmal seinen Standpunkt klarstellen und dann zu seiner Rolle im Team zurückkehren muss.

Wenn Ihr Manager nicht helfen kann oder will, empfehle ich eine 20-30-minütige Pause eins zu eins mit deinem Kollegen. Erklären Sie, dass Sie ein professioneller Softwareentwickler sind und dass Sie deren Input schätzen. Stellen Sie dann fest, dass sie einmal ihren Standpunkt vertreten müssen, und vertrauen Sie darauf, dass Sie mit Ihrer Rolle umgehen können. Erklären Sie, dass es Ihre Aufgabe ist, diese Probleme weiter zu diagnostizieren und zu lösen.

Rufen Sie möglicherweise ein Beispiel auf, in dem Ihr Kollege weiterhin eine Idee oder Hypothese ausgearbeitet hat. Erklären Sie, wann es für Ihren Kollegen angemessen wäre, seinen Gedankengang zu beenden und Sie Ihre Aufgaben wahrnehmen zu lassen.

Wenn Ihr Kollege das nächste Mal eine Idee drückt, sagen Sie etwas Ähnliches wie den oben vorgeschlagenen Satz. Wenn dies nicht funktioniert, beziehen Sie das Management erneut ein. Wenn Ihr direkter Manager nicht hilft, ist es Zeit, über Ihren Manager zu eskalieren.

Es ist wichtig zu wissen, dass dies Situationen sind, die zu erhöhten Stimmen und verlorenen Gemütern führen.

[Bearbeiten ] Es ist auch wichtig zu verstehen, dass dieser Persönlichkeitstyp oft verletzte Gefühle hat, wenn sie ihre Ideen nicht weiter wiederholen dürfen. Das ist nicht dein Problem. Sie müssen die Reife entwickeln, um zusammenzuarbeiten und zu vertrauen. Dazu gehört auch, dass sie wissen, wann sie ihren Standpunkt vertreten und weitermachen müssen. Es ist nicht vernünftig, dass sie in einer solchen Situation persönlich beleidigt werden.

Das ist ziemlich aufschlussreich."... solche Dinge passieren, wenn das Management unreif ist oder fehlt" - direkt vor Ort!Tatsächlich hat diese Person informell die Verantwortung eines Projektmanagers übernommen (der „echte“ Projektmanager ist sehr verständnisvoll, arbeitet aber nicht viel an diesem Projekt).
"Der 'echte' Projektmanager ist sehr verständnisvoll, arbeitet aber nicht viel an diesem Projekt": Ist das Projekt wichtig?Wenn dies der Fall ist, wird dies die Aufmerksamkeit des Managements auf sich ziehen und Sie können sicherstellen, dass sie Ihren Kollegen coachen.Ansonsten ist es vielleicht Zeit weiterzumachen.
#8
+3
employee-X
2018-06-19 00:10:49 UTC
view on stackexchange narkive permalink

Es scheint, dass das meiste Problem für Sie darauf zurückzuführen ist, dass Ihr Workflow unterbrochen wird. Es hört sich auch so an, als würde Ihr Kollege mehr Kommunikation erwarten, als Sie derzeit geben. Vor diesem Hintergrund können Sie einen Weg finden, Ihren Kollegen für eine Lösung zu gewinnen.

Workflow

Suchen Sie einen Workflow, der für Sie funktioniert, und bitten Sie ihn, ihn zu respektieren . Richten Sie Richtlinien ein und bitten Sie sie, Sie dabei zu unterstützen, maximal produktiv zu sein. Formulieren Sie dies als ein Problem, das Sie haben und bei dem sie Ihnen helfen können, damit sie das bekommen, was sie brauchen.

Dieser Ansatz vermeidet Schuld oder Beleidigung und gibt Ihrem Kollegen die Kontrolle, um Ihnen zu helfen, seine / ihre Probleme zu lösen Ihre Bedürfnisse - und genau das wollen sie schließlich.

Sie können beispielsweise Richtlinien für die Meldung eines Fehlers und die Häufigkeit der Überprüfung des Fortschritts festlegen. (Hinweis: Wenn Sie proaktiv eine Schätzung für einen bestimmten Fix abgeben könnten - bevor Ihr Kollege eine Erinnerung sendet -, müssen Sie Ihren Mitarbeiter möglicherweise nicht einmal explizit um eine Änderung bitten.)

Vielleicht Sie können die "Statusaktualisierungs" -E-Mails durch eine einmal tägliche 10-minütige Besprechung ersetzen.

Kommunikation

Verfügt Ihr Team über ein gutes Produkt zur Problemverfolgung (z. B. Jira)? oder Microsoft Planner)? Wenn Sie leicht veröffentlichen können (1) woran Sie gerade arbeiten und (2) wie Sie Dinge priorisiert haben, könnte dies einer Menge helfen. 1 sup> Das Aktualisieren von a dauert 3-5 Minuten Fehleranforderung und tritt auf, wenn Sie bereit sind, Aufgaben zu wechseln.

Es hört sich so an, als würde Ihr Mitarbeiter versuchen, ein solches Tool durch ein E-Mail-Abfragesystem zu ersetzen. Wie bereits erwähnt, können Sie, wenn Sie kein Tool verwenden können, mindestens ab und zu (sogar einmal am Tag) eine Besprechung von 5 bis 10 Minuten abhalten, um die Prioritäten zu synchronisieren.

1 sup> Besser noch, fragen Sie sie, was für sie wichtig ist. Selbst wenn Sie bereits eine Idee haben, fördert dies ein gegenseitiges Gefühl von Partnerschaft und Teamarbeit.

Über Priorität

Es ist wichtig zu wissen, dass das Zuweisen von Prioritäten eine Geschäftsaktivität und keine technische Aktivität ist, auch wenn die Details möglicherweise alle technisch sind. Daher sollten ein technischer Benutzer und ein nicht technischer Benutzer in der Lage sein, sich auf die Prioritäten zu einigen, sofern beide die Geschäftsanforderungen kennen und in Bezug auf diese Anforderungen effektiv kommunizieren können.

Darüber hinaus Jede Meinungsverschiedenheit über Prioritäten führt zu einem Missverständnis oder einer Fehlkommunikation darüber, wie Geschäftsziele beeinträchtigt werden (im Falle eines Fehlers), und hat nichts mit Codierung zu tun. 2 sup>

Um Missverständnissen vorzubeugen, sollten Sie die Prioritäten in Bezug auf die betroffene Geschäftsfunktionalität und nicht die technischen Aspekte besprechen. Das stellt Sie und Ihren Kollegen auf die gleiche Stufe und entlastet sie von den technischen Teilen.

Darüber hinaus bietet dies einen Mechanismus, um Dritte anzusprechen, wenn Sie nicht zustimmen können. Wenn Sie das Problem in Bezug auf konkurrierende Geschäftsprioritäten festlegen, können Sie auf den tatsächlichen Stakeholder - oder vielleicht auf Ihren Projektmanager oder Chef - verweisen und sagen: "Wenn Sie X (Geschäftsfunktion) anstelle von Y priorisieren möchten ( Geschäftsfunktion), bitte sprechen Sie mit so und so. "

2 sup> Dies setzt voraus, dass sowohl Sie als auch Ihr Kollege die Geschäftsprioritäten tatsächlich kennen und in Ihrem jeweiligen Bereich kompetent sind Jobs.

Versuchen, Ihren Job zu erledigen / Halten Sie Ihre Hand

Ich würde empfehlen, das Problem auszuwählen, das für Sie wichtiger ist. Wenn Ihr Kollege versucht zu erklären, was zu tun ist, aber nicht in einer Weise, die Ihren Workflow beeinflusst, würde ich sagen, leben Sie zumindest vorerst damit. Es könnte bedeuten, dass Ihre 10-minütige Besprechung stattdessen 20 Minuten dauert. Wenn Sie jedoch sagen können: "Okay, aber sprechen Sie bitte während der Besprechung mit mir", wird der Schaden für Ihre Effektivität zumindest begrenzt.

Drücken zurück könnte Ihren Kollegen etwas verärgern und Sie daran hindern, ihn zu "engagieren", um die größeren Probleme zu beheben.

Ich gehe davon aus, dass das Workflow-Problem für Sie wichtiger ist, obwohl es (vielleicht) etwas weniger ausgeprägt ist. Ich habe auch keinen soliden Rat zu diesem Teil.

#9
+2
blurry
2018-06-18 22:32:15 UTC
view on stackexchange narkive permalink

Ich neige dazu, in bestimmten Gesprächen über unterschiedliche Meinungen zu Dingen etwas intensiv zu sein. Ein Beispiel für mich waren Kommentare. Während ich mit den meisten Menschen ziemlich gut in Kontakt stehe, begegne ich einigen Menschen mit einem ähnlichen Persönlichkeitsmerkmal, aber der entgegengesetzten Meinung.

Wenn dies passiert, versuche ich zuerst, mich nach der Reibung in die Person zu drehen. Steigerung der Interaktion und Bereitstellung von mehr Dingen, um herauszufinden, wie man besser mit ihnen arbeiten kann. Oft funktioniert dies nicht.

Was ich dann tue, ist, Meinungsverschiedenheiten passiv zu minimieren und nur kritische Probleme oder Bedürfnisse mit ihnen anzusprechen. Dies reduziert "Entzündungen", wenn Sie es so sehen wollen; Das bedeutet, dass Fackeln weniger wahrscheinlich sind. Es hilft auch, weil ich, wenn ich mit ihnen über ein Problem sprechen möchte, wirklich eine Meinung von ihnen brauche. und echt zu sein ist immer gut.

Ich sehe, das scheint keine Antwort zu sein. Aber im Grunde sage ich " hör auf, ihm Dinge zu erzählen, die er nicht wissen muss " oder " hör auf, zu versuchen, Probleme mit ihm zu diskutieren oder zu lösen, es sei denn, du denkst, er wird hilfreich sein . "

Dies alles sagte, ich neige dazu, jemand zu sein, der Menschen als Resonanzboden benutzt und nach uninformierten oder unkonventionellen Ideen sucht, weil es mir eine andere Herangehensweise an das Problem gibt; Es kann also sein, dass Sie ihm einfach zuhören möchten, wenn er eine unkonventionelle oder unwahrscheinliche Idee hat.

Dies ähnelt dem Ansatz, den ich bisher versucht habe."... hör auf zu versuchen, Probleme mit ihm zu diskutieren oder zu lösen, es sei denn, du denkst, er wird hilfreich sein."- bestimmt!Ich habe versucht, sie so wenig wie möglich zu kontaktieren, um keine Möglichkeit für Spam zu bieten, aber selbst dieses kleine löst eine Reihe anderer Nachrichten aus, wahrscheinlich weil sie denken, ich suche nicht in die richtige Richtung oder so ...
#10
+2
Guy Schalnat
2018-06-19 23:33:19 UTC
view on stackexchange narkive permalink

Andere haben sich mit Unterbrechungen und Kontextwechsel befasst, und dazu gibt es einige gute Antworten. Ich werde mich an den Tester wenden, der versucht, den Code zu reparieren.

Es hört sich so an, als würde Ihr Tester gerne programmieren lernen, gerne Rätsel lösen und nach Feedback suchen ( und Lernen), ohne eine wirkliche Ahnung zu haben, wie es ist, professionell zu programmieren. Zeigen Sie es ihnen.

Als Warnung war es nicht der produktivste Tag, wenn es darum ging, Fehler zu beheben, aber es hat sich auf lange Sicht immer ausgezahlt.

Was Sie wollen, ist, einen der Fehler (vorzugsweise einen, bei dem der Tester falsch war) zu nehmen und dem Tester zu zeigen, was Sie tun müssen, um das Problem zu lösen. Dies funktioniert am besten, wenn Sie Dinge tun können, die der Tester nicht tun kann, z. B. den Debugger verwenden oder in die Datenbank schauen.

Laden Sie die Person an Ihren Schreibtisch ein und sprechen Sie über das Problem. Erklären Sie dann, was Sie tun, wenn Sie mit der Behebung beginnen.

Nehmen wir an, ich habe ein dreistufiges System. Browser, Server, Datenbank. Angenommen, ich habe einen Fehler, bei dem ein Formular ausgefüllt, veröffentlicht und dann zurückgelesen wird. Die Daten werden beim Zurücklesen nicht angezeigt.

Das erste, was ich tun würde, ist das Duplizieren das Problem. Als zweites würde ich sehen, wie die Datenbank aussieht. Zu diesem Zeitpunkt weiß ich, ob das Problem darin besteht, in die Datenbank zu schreiben oder daraus zu lesen. Das dritte, was ich tun würde, ist, mit einem Debugger in die Mitte des Servers zu springen, um zu sehen, wie die Daten dort aussehen. Als nächstes würde ich mir die Daten ansehen, wenn sie an die Datenbank oder den Browser gesendet werden. Und so weiter. Ich werde auf den Punkt eingrenzen, an dem die Daten beschädigt wurden.

Der Punkt ist dies. Was ich nicht tue, ist zuerst über "was" das Problem zu spekulieren, denn das kann mich in die Irre führen. Ich benutze zuerst meine Tools, um herauszufinden, wo das Problem aufgetreten ist, normalerweise indem ich die Daten auf halbem Weg zwischen dem bekannten guten und dem schlechten Zustand (und irgendwo, wo ich sie effizient betrachten kann) betrachte und wiederhole bis ich das Problem auf ein kleines Stück Code eingegrenzt habe. Sobald ich "wo" kenne, kann ich Haltepunkte an der Stelle setzen und durchgehen und "was" entdecken. Dabei finde ich möglicherweise sogar andere potenzielle Fehler in dem Code, den ich gleichzeitig beheben kann, und finde heraus, was erneut getestet werden muss.

Wenn Sie im Dunkeln Pfeile auf ein Ziel werfen, Es ist einfacher, das Licht einzuschalten, als zu erraten, wo sich das Ziel befindet, und zu hoffen, dass Sie die Marke treffen.

Und dann ermutigen Sie Ihren Tester, mit seinem Manager darüber zu sprechen, Programmierer zu werden. Wir brauchen mehr gute Programmierer auf dieser Welt.

#11
  0
user1306322
2018-06-19 15:31:56 UTC
view on stackexchange narkive permalink

Wenn Sie dazu in der Lage sind, versuchen Sie dieses Experiment (und schreiben Sie es schriftlich ein, um einen Mail-Trail zu erhalten):

Jedes Mal, wenn sie darauf bestehen, dass Sie alles fallen lassen, was Sie tun, und das tun, was sie tun Ich möchte, dass Sie genau das tun und die Ergebnisse in ein oder zwei Wochen mit Ihrem normalen Arbeitsmuster vergleichen. Setzen Sie sich dann mit ihnen zusammen und besprechen Sie die Vor- und Nachteile beider Ansätze mit tatsächlichen Statistiken darüber, wie viel Arbeit Sie leisten können und wie zufrieden das Management mit den Ergebnissen der einzelnen Ansätze ist.

Es besteht immer die Möglichkeit, dass sich daraus Ergebnisse ergeben Vielleicht ist es gar nicht so schlecht, aber falls es so läuft, wie Sie es erwarten, werden Sie wahrscheinlich nicht mehr so ​​oft wie jetzt von ihnen gestört.

#12
  0
David
2018-06-19 21:44:09 UTC
view on stackexchange narkive permalink

Die direkte Anbindung an die Qualitätssicherung sollte in Ihrem Ermessen liegen und nicht umgekehrt. Unterbrechungen können Sie sich nicht leisten. Dies muss der Qualitätssicherung vom Projektmanager klar gemacht werden, sofern dies zu Ihrer Unternehmenskultur passt. Wenn nicht, müssen Sie möglicherweise versuchen, die Unternehmenskultur zu ändern.

Isolieren Sie sich mit einem besseren Workflow. Ich würde empfehlen, sich gute Bug-Tracking-Datenbanken anzusehen, wenn Sie noch keine haben. Sprechen Sie mit dem Projektmanager und erklären Sie, wie diese Unterbrechungen Ihren Fortschritt dramatisch verlangsamen und Stress verursachen. Wenn möglich, trennen Sie die Qualitätssicherung in einem anderen Bereich des Gebäudes.

Nach meiner Erfahrung in der Qualitätssicherung für ein Videospielunternehmen bestand meine Aufgabe darin, Fehler im Bug-Tracker zu finden, zu replizieren, zu detaillieren und zu klassifizieren. Die Rolle des Programmierers hat diese behoben. Der Projektmanager (in diesem Fall der Produzent) stupste die Programmierer an, wenn kritische Fehler offen blieben. Als QS konnte ich mich an den Projektmanager wenden, wenn ich etwas für dringend hielt. Ich würde die Programmierer nicht direkt stören, aber sie kamen oft und sprachen mit mir.

Sie sind im selben Team. Wie einige der anderen Antworten festgestellt haben, erleichtert eine gute Qualitätssicherung Ihre Arbeit erheblich. Ich würde sogar vorschlagen, einen Punkt zu machen, um nach Belieben mit ihnen zu sprechen, um zu sehen, wie die Stimmung ist, da nicht alles im Text klar zum Ausdruck kommt.

Als Testmitarbeiter finde ich Ihren ersten Absatz sehr widersprüchlich.Was gibt Ihnen das Gefühl, dass es für Programmierer in Ordnung ist, den Tester zu unterbrechen, aber nicht umgekehrt?Warum kann sich der Programmierer "keine Unterbrechungen leisten", der Tester jedoch?Wir sitzen alle im selben Boot.Erfolgreiche Teamarbeit und Zusammenarbeit bedeuten, dass wir manchmal etwas von unserer individuellen Bequemlichkeit aufgeben müssen.
@Mirosław Ich habe nie gesagt, dass es für einen Programmierer in Ordnung ist, einen Tester zu unterbrechen.Nichts hindert sie daran, per E-Mail zu fragen, ob sie mit ihnen sprechen möchten.Ich denke auch, ich sollte hinzufügen - Programmierer sind oft tief in Gedanken über extrem komplexe Probleme.Ihre Arbeit ist Denken, nicht Tippen.Indem Sie sie unterbrechen, haben Sie im Grunde genommen zerstört, wie viel Zeit sie für extrem geistig anstrengende Arbeit aufgewendet haben. Ich denke, wir können uns alle darauf einigen, dass Unterbrechungen schlecht sind.
#13
  0
Paul Sobocinski
2018-06-20 18:59:44 UTC
view on stackexchange narkive permalink

Meine Antwort wird anders sein als die meisten hier.

Viele der anderen Antworten konzentrieren sich darauf, was Ihr Kollege oder nicht sein sollte tun.

Ich werde stattdessen vorschlagen, was Sie tun können.

Schauen Sie sich zunächst die positiven Aspekte an. Dies ist ein sachkundiger Mitarbeiter, der wirklich zusammenarbeiten und Ihnen bei Ihrer Arbeit helfen möchte. Sie erwähnen nichts, was darauf hindeutet, dass sie absichtlich versuchen, Sie zu behindern. Sie tun dies nur, weil sie nicht verstehen, wie sie Ihnen am effektivsten helfen können.

Hier kommen Sie ins Spiel. Es ist Zeit, ein ehrliches, offenes und objektives Gespräch mit ihnen darüber zu führen . Einfach, oder?

Ist es eigentlich nicht. Aus diesem Grund gibt es viele Ressourcen, die Ihnen dabei helfen, dies zu erreichen. Hier einige Beispiele:

  1. Entscheidende Gespräche (Buch)
  2. ol>

    Ich habe dieses Buch gelesen und finde seinen Rahmen hilfreich, um produktive Diskussionen mit Teammitgliedern zu führen: https://www.goodreads.com/book/show/15014.Crucial_Conversations

    1. Saubere Sprache (Technik)
    2. ol>

      Ich weiß weniger darüber, daher kann ich keine konkreten Ressourcen bereitstellen. Dies war ein beliebtes Thema bei einer kürzlich von mir besuchten Konferenz: https://en.wikipedia.org/wiki/Clean_Language

      TLDR: Zusammenarbeit ist schwer. Glücklicherweise sind Sie nicht die erste Person mit dieser Herausforderung. Es gibt Ressourcen, die helfen können. Versuchen Sie auch, "produktive Konflikttechniken" oder "Konfliktlösungs-Frameworks" zu googeln. Vermeiden Sie einfach oberflächliche Artikel und finden Sie etwas mit Substanz (wie einen Kurs oder ein Buch), das Ihnen einige konkrete Werkzeuge gibt.

      Hoffe, das hilft!

#14
-5
Mr Heelis
2018-06-19 19:42:27 UTC
view on stackexchange narkive permalink

Kannst du nicht versuchen, einen Witz daraus zu machen?

"Ich hörte, wie ein Tester einem Entwickler einmal sagte, er habe ihn Jahre später als 4. Beule auf der Autobahn gefunden."

"Sie müssen mein niedriges Gehalt wirklich mögen, wenn Sie es sind Ich versuche immer, meinen Job zu machen. "

" whoa there horsey, wir haben noch nicht einmal so viel erreicht nimm nimm Zucker "dann" nein warte, ich werde Tony fragen, er wird dir sagen, wie du deinen Kaffee willst "

Ich weiß, dass es vielleicht nicht dein Stil ist," meine erstaunliche Art von Witz "zu sein. , und es ist nicht lustig, es sei denn, Sie lachen beide, wie Sie es sagen. Aber bringen Sie ihn zum Lachen, und es wird ihm nichts ausmachen, das versichere ich Ihnen. .. wenn Sie nicht wissen, wie Sie das sagen sollen

"Ich wünschte, ich wüsste einen Witz, dann würde ich es Ihnen sagen, damit ich Sie nicht in die Eier schlagen muss"

Er ist wahrscheinlich ein Rücksitzfahrer in anderen Teilen seines Lebens. Die meisten Leute werden über solche Dinge lachen, wenn sie tief im Inneren wissen, dass Sie sie mögen

Die Tatsache, dass dies vermerkt ist, tut mir leid für Sie. Ich bin seit 25 Jahren Entwickler, und ja, ich war viele Male in dieser Situation und habe mich nie mit jemandem gestrittenund hatte nie dieses Problem .. rate mal warum? .. weil ich in der Lage bin, einen Witz daraus zu machen .. ihr müsst aufhören, so komisch zu sein und den richtigen Rat zu schikanieren .. ihr könnt nicht "alles Technische" bekommenMit solchen Dingen ... verwenden Sie keine "Checkliste" und "Gruppengruppen" und "Verwalten einer Person". Sie beheben dies, indem Sie die Person gewinnen. FFS. Das Leben ist nicht gelöst. 001010010010010 Ich fühle mich ehrlichEntschuldigung für euch alle
oder anders ausgedrückt: Alle (falschen) + ^ + ^ + ^ LOVED UP THUMBS-Antworten sagen (in der Tat) "Übernimm die Kontrolle zurück und ändere die andere Person". Die richtige Antwort lautet: "Gib auf, es zu versuchen."alles kontrollieren und aufhellen und nicht wertvoll sein, wenn man freundlich auf nicht anstößige Weise nach Grenzen fragt "


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 4.0-Lizenz, unter der er vertrieben wird.
Loading...