Wie man einen Nicht-Programmierer bittet, mich bei Programmieraufgaben nicht zu beraten

Question

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>}

Answer 1

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.

Answer 2

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. “

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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)
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

2. Saubere Sprache (Technik)
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!

Answer 14

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