Hier würde ich nach seitlichen Lösungen suchen. Sagen Sie ganz klar, dass Sie ihre Eingabe nicht schätzen und sie nicht erhalten. Aber (wie Sie berichtet haben) - verbringen Sie viel Zeit damit, die Idee zu validieren, aber erklären Sie , warum die Lösung nicht funktioniert, und verschwenden Sie viel Zeit und erhalten Sie nur sehr wenig Wert.

Ich habe viel Erfolg damit gehabt, das Gespräch so zu führen, dass ich meine eigenen Ziele erreicht habe. Mein Ziel ist es, (1) das Problem zu bestätigen und zu klären (2) die Kriterien für eine Lösung zu klären (3) einen Ansatz zu überprüfen, der zu einer endgültigen Antwort führt

Problem bestätigen

Hier fange ich also an - ich beginne nicht damit, ob die Lösung funktioniert oder nicht, ich beginne damit, die vollständigen Details des Problems zu erhalten, die in Ingenieursprache (nicht in Analystensprache) geklärt werden ). Ich weiß nicht genau, wie die Probleme vor Ihrer Haustür auftreten - Telefonanrufe können sich stark von zeitverzögerten Anrufen wie E-Mail oder Trouble-Tickets unterscheiden.

Aber in jedem Fall möchte ich klarstellen, dass Sie ihren Beitrag und die Art des Problems sehr ernst nehmen. Aber normalerweise habe ich gerne eine Checkliste und es macht mir nichts aus, den Benutzern zu sagen, dass ich diese ausfüllen muss, bevor wir zum Lösungsteil kommen:

• Was haben Sie gesehen, dass das falsch war / Schlecht?
• Waren die Daten oder die Art und Weise, wie sie präsentiert wurden?
• Was haben Sie getan, als sie auftraten?
• Was hält Sie davon ab?
• Kommt es zu einem anderen Zeitpunkt vor? Kannst du es wieder schaffen? Können Sie mir Schritte geben, damit ich es wieder schaffen kann?
• Was ist hier die Priorität? (sollte etwas mit "Was hält Sie davon ab?" korrelieren)

Ich weiß, dass es verrückt klingt, aber stellen Sie auch sicher, dass die Benutzer genau wissen, dass Sie Notizen machen und alles auf den Punkt bringen. Umschreiben Sie, was Sie zurück gehört haben, und stellen Sie sicher, dass Sie es richtig verstanden haben. Eine Reihe von Schnellfeuerfragen, die oberflächlich gestellt werden, werden eine feindliche Antwort hervorrufen. Ein tiefes Gespräch über das Problem wird die Angst lindern, dass Sie nichts dagegen unternehmen werden.

Es muss etwas auf dem richtigen Weg bleiben, aber wenn Sie zu "Was haben Sie versucht zu tun?" und "Was können Sie mit diesem Problem nicht anfangen?" - Lassen Sie es ein wenig in die Welt der Analysten gehen. Während Sie das Problem nicht "auf ihre Weise" lösen können, müssen Sie das Problem auf eine Weise lösen, die für sie funktioniert, und das bedeutet, dass Sie mehr als ein wenig darüber wissen müssen, was sie zu tun versuchen. Es ist ein matschiger Raum - Sie können hier unendlich viel Zeit verbringen, und kluge Leute LIEBEN es, darüber zu sprechen, was sie tun - also gibt es einige Arbeiten, die das Gespräch darüber leiten.

Klären Sie die Anforderungen einer Lösung stark>

Sofern das Problem nicht umwerfend klar ist, gibt es wahrscheinlich zahlreiche verfügbare Lösungen. Eine Lösung für den Analysten ist jedoch nicht unbedingt machbar, und eine Lösung für den SW-Entwickler ist für viele eigentlich keine Lösung für den Analysten. Nebenschritt das Gespräch "Ich habe Recht / Sie haben Recht" und sprechen Sie über die Anforderungen für die Lösung.

Manchmal kann ich es in zwei Teile aufteilen: - Wenn ich Ihnen schnell und schnell etwas geben würde dreckig, was ist die absolut kleinste Änderung, die ich vornehmen könnte, um dich zufrieden zu stellen? - Wenn ich einen Zauberstab hätte und ihn jetzt ohne Zeitaufwand reparieren könnte - wie würde die Lösung aussehen?

Von dort aus fällt es normalerweise der Softwareperson zu, diese Lösungen als Anforderungen neu zu definieren. Obwohl Analysten wirklich kluge, sachliche und informationsbewusste Personen sind, sind sie keine Softwareentwickler und verstehen nicht die sehr spezifische Fachsprache, die bei der Gestaltung einer Benutzererfahrung verwendet wird. Daher stelle ich normalerweise fest, was meiner Meinung nach an den Anforderungen der beiden Lösungen offensichtlich ist - "muss sein" ist alles, was sowohl im absoluten Minimum als auch in der vergoldeten Option liegt. "Willst du haben" ist nur die ideale Lösung. Ich bitte um zwei Datenstücke, weil ich oft viele versteckte "Ich brauche es überhaupt nicht, es ist nur meine Annahme" -Dinge in diese "Bare-Minimum" -Lösung aufdeckte, die nie auftaucht in der "nice to have" -Lösung.

Genau wie Entwickler Dinge über Benutzer annehmen, machen Benutzer oft Annahmen darüber, was "einfach" ist - normalerweise sind sie anständig und wollen sich nicht die Mühe machen, also fragen sie nach dem, was sie für "einfach" halten. und dann werden Sie gestresst, wenn Sie ihnen sagen, dass ihre Lösung überhaupt nicht einfach ist ...

Wie ist das?

Normalerweise ist eine einfache Änderung etwas, das die Entwickler und Benutzer können sich an dieser Stelle am Telefon einigen ... aber ich wette, dass der von Ihnen beschriebene Grad an Frustration normalerweise nicht von diesem Typ ist.

Der Entwickler benötigt möglicherweise etwas Zeit, um etwas zu erstellen. Dies ist jedoch ein guter Zeitpunkt, um Prototypen, Screenshot-Beispiele und andere Ideen an den Benutzer zurückzusenden, bevor es zu einem schweren Heben kommt. Es ist wie bei einem mini-agilen Projekt - werfen Sie etwas auf sie und erhalten Sie einen Einblick, ob es funktioniert, bevor Sie wirklich etwas implementieren und testen.

Hier Zeit zu nehmen ist in Ordnung. Ich weiß, dass ich immer den Druck verspüre, etwas auf ein Whiteboard zu schreiben und damit fertig zu sein ... aber dies ist die Zeit, in der Sie eine Sekunde innehalten und es sich wirklich überlegen können, bevor Sie das Unmögliche versprechen. Ich habe festgestellt, dass ein paar Momente zum Nachdenken tatsächlich Vertrauen schaffen, da sie zu diesem Zeitpunkt erkennen, dass das Problem nicht "einfach" ist, aber Sie sind genauso bemüht, eine Lösung zu finden wie das Problem zu beheben.

Fazit

Dies schafft normalerweise viel Vertrauen. Sie haben nie "Nein" gesagt, "Sie liegen falsch" oder "Ihre Ideen sind absolut unmöglich", also haben Sie nie den Groll aufgebaut, der durch das Aussperren entsteht. Die Leute mögen es normalerweise, die Details ihrer Probleme, ihre Träume von einem perfekten Produkt und Meinungen zu etwas zu geben, das noch nicht hergestellt wurde - also fragen Sie nicht nach etwas Verrücktem.

Ich habe festgestellt, dass Menschen (auch hochrangige Personen) sehr selten erwarten, dass Sie das tun, wonach sie fragen, ohne Fragen, Bedenken oder alternative Ideen. Tatsächlich erkennen die meisten klugen Leute, dass es eine Runde Fragen geben muss, bevor sie fortfahren.

Es ist nur, wie Sie die Fragen beschleunigen und welche Sie stellen.

Ich denke nicht, dass die Tatsache, dass sie Korrekturen vorschlagen möchten, ein Problem ist. Ich denke, dass dies in der Tat sehr gut ist, weil es manchmal funktioniert und wenn sie aus dem gleichen Grund ständig nicht funktionieren, kann es sein Es lohnt sich zu versuchen, diese Einschränkung zu beheben.

Was geschult werden muss, ist das Vertrauen, dass der Ingenieur, wenn er sagt, dass es nicht funktioniert, nicht erklären muss, warum. Sie sollten für ihren Vorschlag gedankt und ermutigt werden, weiterhin über mögliche Möglichkeiten zur Behebung von Problemen nachzudenken, müssen aber auch darauf vertrauen, dass das Engineering seine Aufgabe erfüllt, und wenn die Idee nicht funktioniert, müssen sie nicht wissen, warum sie gewonnen hat funktioniert nicht, nur dass ihre Bemühungen, zu helfen, nicht einfach ignoriert werden.

(Vollständige Offenlegung - Ich bin ein sehr erfahrener Datenanalyst.)

Datenanalysten sind ebenfalls Entwickler. Behandeln Sie sie mit dem gleichen Respekt, den Sie einem anderen Entwickler entgegenbringen würden, der an einer Anwendung arbeitet, die mit Ihrer Anwendung zusammenhängt. Das sind sie. Natürlich sollten sie Vorschläge machen. Natürlich sollten Sie frei sein, Ihre eigenen Korrekturen vorzunehmen. Sie wissen Dinge, die sie nicht über die Anwendung wissen, aber sie wissen Dinge, die Sie nicht darüber wissen, wie die Daten außerhalb Ihrer Anwendung verwendet werden. Arbeiten Sie gemeinsam an Lösungen, die den Anforderungen beider Gruppen entsprechen.

Wenn sie häufig Vorschläge machen, bedeutet dies, dass Ihre Lösungen wahrscheinlich häufig Probleme für sie verursacht haben. Sie müssen mehr darüber erfahren, warum die Lösungen, die Sie haben, für sie nicht funktionieren, ihre Vorschläge ernsthaft anhören und nach einer Mittelweglösung suchen, die beiden Gruppen das bietet, was sie benötigen.

Wenn die Vorschläge etwas mit der Struktur der Datenbank zu tun haben (einschließlich Einschränkungen, Foriegn-Schlüsseln, Tabellenstrukturen), sind sie die Experten, und Sie sollten sehr genau zuhören. Manchmal verbessern Dinge, die das Leben für Sie unbequemer machen, die Qualität der Daten drastisch, was für die Menschen sehr wichtig ist, die Berichte und Datenexporte für die Kunden schreiben müssen. Es ist ziemlich peinlich, dem Kunden zu erklären, warum Sie doppelte Datensätze haben, zum Beispiel, weil die Anwendungsentwickler keine Kontrollen für die Dateneingabe vorgenommen haben. Wenn die Daten aus regulatorischen Gründen verwendet werden, kann dies über peinliche rechtliche Probleme für das Unternehmen hinausgehen.

Ich habe oft Entwickler gesehen, die kurzfristig entworfen haben und nur darüber nachgedacht haben, was für mich am schnellsten und einfachsten ist. Beim Zugriff auf Daten ist dies eine verlierende Strategie, da schlechte Daten oder schlechte Datenbankleistung weitaus kritischer sind. Oft sehen Anwendungsentwickler die tatsächlichen Leistungs- und Datenprobleme nicht, weil sie keine Berichte mit Tausenden von Datensätzen abrufen müssen. Sie müssen dem Kunden keine schlechten Daten erklären. Was als gute Lösung erscheint, wenn Sie nur einen Datensatz gleichzeitig eingeben oder die 15 Datensätze abrufen möchten, die Sie auf einem Bildschirm anzeigen möchten, ist keine gute Lösung für die Personen, die den who-Datensatz später verwenden müssen.

Hören Sie sich die Vorschläge an und behandeln Sie sie ernst. Wenn ein Anwendungsentwickler in einem anderen Projekt einen Vorschlag machen würde, weil Ihr Produkt seins beeinflusst, würden Sie ihn dann nicht ernst nehmen? Würden Sie es ablehnen, ein Gespräch mit ihm zu führen, um zu erklären, warum das nicht funktioniert, oder um andere Möglichkeiten zu erkunden? Datenanalysten verdienen die gleiche Behandlung.

Dies ist eine großartige Frage, die in allen Organisationen, für die ich gearbeitet habe, aufgetaucht ist. Bei der Lösung des Problems ist zu berücksichtigen, dass die meisten Lösungsanbieter glauben, dass sie hilfreich sind, ohne die zusätzliche Arbeit zu bemerken, die für den Umgang mit lösungsbasiertem Feedback erforderlich ist. Die Wurzel des Problems ist natürlich kulturell, kann aber in der Regel auf zwei Dinge reduziert werden:

1. Unverständnis für Ihren Prozess
2. Verwirrung über die Rollen / Fähigkeiten von Die verschiedenen Teams und / oder Teammitglieder
ol>

Es mag zunächst offensichtlich erscheinen, aber zu verstehen, wie die Entwicklung in Ihrem Shop funktioniert, ist für alle Teams von entscheidender Bedeutung. Wie sieht der Entwicklungsprozess von oben aus? Welche Spieler sind an verschiedenen Punkten beteiligt? Was ist Ihr Iterationszyklus? Wo sind Ihre Checks and Balances? Eine kurze Präsentation / Konversation darüber, wie die beweglichen Teile zusammenpassen, ist entscheidend für Teams, um ein gegenseitiges Verständnis und Respekt für den Prozess zu entwickeln. Diese Diskussion bildet die Grundlage für Ihr anschließendes (und gezielteres) Gespräch über Teamrollen.

Das Verständnis der eigenen Rolle ist innerhalb einer Organisation von wesentlicher Bedeutung, aber ebenso wichtig ist der Respekt vor Fachwissen. Es hört sich so an, als hätten Sie exzellente Teams, aber ihr Verständnis, wo ihr Fachwissen in den Prozess passt, wird missverstanden. Es hilft, das Problem als Gruppe anzugehen, indem Sie die Übergabe vom Analysten an den Ingenieur visualisieren und diskutieren. Stellen Sie sicher, dass das Team einige Diskussionen über die Effizienz führt, die durch eine Optimierung des Feedback-Zyklus erzielt wird. Ihr Team sollte in der Lage sein, Folgendes zu tun: Problem - Lösungsvorschlag des Ingenieurs (bei Bedarf zusätzliches Feedback erhalten) - Entwicklung. Auch hier ist dies ein guter Ort, um wesentliche Teile Ihres Prozesses hervorzuheben: Codeüberprüfung, Iterationszyklen, Benutzertests usw., damit alle dem Team und den in Ihren Prozess eingebauten Checks and Balances vertrauen können.

Eine andere Strategie, die ich verwendet habe, ist die Strategie "Ich habe deinen Rücken". Die Beziehung zwischen Analysten und Ingenieuren kann sich wirklich festigen, wenn Menschen das Gefühl haben, sich gegenseitig zu unterstützen. Wenn sich Analysten darauf konzentrieren, Probleme, Anforderungen und eine gute Berichterstattung zu verstehen, können sie die Ingenieure von dem Stress und der Ablenkung befreien, die sich aus dem Zurücktreten ergeben. Wenn die Analysten wissen, wie wichtig ihre Rolle ist, werden sie stolz und helfen, konzentriert zu bleiben.

Und schließlich tritt häufig ein drittes Problem auf, wenn Teams, die Feedback geben, die von Entwicklungsteams verwendete Terminologie fehlen (z. Fehler, Verbesserung, neue Funktion). Dieses Problem kann normalerweise schnell durch eine einfache Präsentation behoben werden, in der die Unterschiede erläutert, die vereinbarten Definitionen veröffentlicht und Mechanismen für Feedback erstellt werden. Dieses Problem scheint nicht zu Ihrer speziellen Situation zu passen (es stimmt besser mit den Kundendienstabteilungen überein, die Feedback geben), aber ich dachte, es wäre erwähnenswert.

Geben Sie im Berichterstellungstool zwei Felder an:

  Bitte beschreiben Sie das Problem im Detail [] Wenn Sie möchten, fügen Sie bitte einen Lösungsvorschlag hinzu []  

Dann ignorieren Sie einfach das zweite Feld im Backend.

;)

Der Versuch, sie dazu zu bringen, ihren Kommunikationsstil zu ändern, wird bestenfalls ein harter Kampf sein. Sie müssen sich auf die Seite des Gesprächs konzentrieren, die Sie steuern steuern können: Ihre. Verwenden Sie die Beschreibung einer Lösung, um zu einer Beschreibung des Problems zu gelangen, und führen Sie sie dann zu einer Beschreibung einer Lösung, die den Anforderungen entspricht, die ihnen nicht bekannt sind.

Wenn sie zum ersten Mal mit einer Lösung zu Ihnen kommen, Sprechen Sie nicht darüber, warum es nicht funktioniert. Sprechen Sie zuerst darüber, warum sie glauben, dass es funktionieren würde. Führen Sie dieses Gespräch, um eine gute Beschreibung des Problems zu erhalten. Schlagen Sie dann eine Alternative zu ihrer Lösung vor, die den Anforderungen entspricht oder Technologien verwendet, die ihnen möglicherweise nicht bekannt sind. Wenn sie immer noch Einwände erheben, beschreiben Sie nur dann , warum ihre Lösung nicht durchführbar ist.

Es ist auch hilfreich, diese Art von Gesprächen nicht als "festgefahren" zu betrachten. Es ist ein wichtiger Teil des Jobs und einer der Gründe, warum Sie diese nicht-technischen Kurse belegen mussten, um einen Abschluss zu erhalten. Bemühen Sie sich auf jeden Fall, die Kommunikation so effizient wie möglich zu gestalten. Wenn Sie jedoch Zeit damit verbringen müssen, Ihre Analysten zu schulen, sollten Sie dies nicht als Zeitverschwendung betrachten.

Seien Sie dankbar, dass Sie nicht nur Lösungen erhalten, ohne das Problem selbst zu identifizieren.

Stellen Sie sicher, dass Sie eine Erklärung für die von Ihnen implementierte Lösung angeben. Sie müssen nicht jedes mögliche Szenario abdecken, aber Sie könnten etwas über ihre Vorschläge erwähnen. Bei den meisten Problemen sollten sie herausfinden können, warum Sie es auf Ihre Weise tun mussten. Wenn nicht, müssten Sie dies näher erläutern.

Betrachten Sie dies als Teil des Lernprozesses. Wenn ich denke, dass die Dinge 1-2-3 erledigt werden sollten und Sie einen Grund für 3-2-1 haben, werde ich bei dem Versuch, Ihre Lösung zu implementieren, im Nachteil sein, wenn Sie mir nicht sagen, warum. Ich vermute, was Sie tun, ist sehr kompliziert und es ist wichtig, dass alle Beteiligten auf derselben Seite sind.

Dies scheint ein Fehler im Prozess der Problemberichterstattung in Ihrer Organisation zu sein.

Nehmen Sie zum Beispiel einen Arztbesuch. Viele Menschen sind dank einiger Stunden Online-Recherche ihrer Symptome zu Wikipedia-Ärzten geworden. Das Diagnosemodell fördert und erfordert sogar Benutzer- (Patienten-) Feedback. Sie haben jetzt Patienten, die Diagnosen mit online vergifteten Informationen vergiften.

Das aktuelle Modell Ihrer Fehlerberichterstattung erlaubt oder ermutigt wahrscheinlich sogar zu viel Feedback vom Fehlerreporter, sodass Sie 21 Fragen mit Ihren Analysten spielen müssen . Ich würde empfehlen,

einen formal dokumentierten Prozess / ein Verfahren zur Fehler- / Fehlerberichterstattung einzurichten, in dem die beteiligten Spieler und ihre jeweiligen Rollen klar umrissen sind.

1. Investieren Sie in Tools / Methoden, die eine gewisse Distanz zwischen Ihnen und den Analysten schaffen (zumindest JIRA). Die Entfernung / Trennung fördert ein gewisses Maß an Kapselung zwischen den beteiligten Parteien. Wenn der größte Teil der Problemverfolgung / -berichterstattung über ein Forum wie JIRA, IMO erfolgt, ist es für den Problemberichterstatter weniger bequem, wahrscheinliche Lösungen zu erörtern / zu diskutieren (angesichts der richtigen Definition der Rollen innerhalb des Systems). Ihr Team kann grundsätzlich auf die wichtigen Aspekte eines bestimmten JIRA achten und nicht auf die zeitaufwändigeren Diskussionen

ol>

Ich habe mich ursprünglich gefragt, ob es in den Gruppen eine Trennung zwischen dem gibt, was mein Unternehmen "Fehler" und "Verbesserungen" nennt. Sehr oft kann ein Problem in eine der beiden Kategorien eingeteilt werden, aber viele passen besser in die eine oder andere. Informationen werden als falscher Datentyp zurückgegeben: Fehler. Analyst möchte, dass Daten beim Abrufen zwischen Typen konvertiert werden können: Verbesserung. Vielleicht schlugen die Analysten im Rahmen von Verbesserungswünschen Lösungen vor. Einige Kommentare des OP zu der Frage und den verschiedenen Antworten deuten darauf hin, dass dies möglicherweise Teil des Problems ist, aber nur ein kleiner Teil.

Halten Sie einige gruppenübergreifende Seminare ab. Sie können von einer Erläuterung der verschiedenen Software, mit der sich die Entwickler befassen müssen, bis hin zu Analysten-Workflows reichen. Nehmen Sie sie auf Video auf, damit auch neue Mitarbeiter sie sehen können. Ich denke, das würde beiden Gruppen helfen zu verstehen, was möglich ist und was nicht.

Ich glaube nicht, dass dies eine vollständige oder die beste Antwort ist, aber es ist zu lang für einen Kommentar!

Die richtige Lösung hierfür ist eine Fehlerverfolgungsdatenbank, in der die Analysten nicht nur Fehler melden, sondern auch ihre Ideen als Funktionsanforderungen einreichen können (anstatt Zeit damit zu verschwenden, sie mit Ihnen zu diskutieren). Unter den Kohlestücken befinden sich möglicherweise einige Diamanten.

Wenn jemand eine oder zwei sehr gute Ideen hat, können Sie diese als Merkmal in den nächsten Meilenstein aufnehmen.

[T] Ihre Vorschläge können aufgrund anderer Softwareanforderungen, mit denen die Analysten nicht vertraut sind, häufig nicht in Software implementiert werden.

Die Analysten sagen Ihnen nicht, welche Art von Code Sie schreiben sollen ? Lassen Sie sie die Lösungen anhand von Anwendungsfällen beschreiben. Dinge, die kurzfristig als Bugfix nicht umsetzbar erscheinen, können mit der richtigen Planung und Investition von Ressourcen erledigt werden.

In Software ist es schwierig, Ideen zu erhalten, daher sollten Sie so viele Köpfe wie möglich auswählen.

Vielleicht wäre die beste Lösung, sie zu befähigen, Ideen zu generieren, die basierend auf den von Ihnen verwalteten Einschränkungen tatsächlich umsetzbar sind. Zu diesem Zweck können Sie die Dokumente mit den Bereichen und Grenzen des Projekts optimieren.

Falls die Ideen weiterhin überwältigend sind, kann die Implementierung eines Formats zum Übermitteln von Fehlern einschließlich eines möglichen Fixfelds (das Sie möglicherweise ignorieren) der richtige Weg sein.