Wie kann ich einen Kollegen ermutigen, Probleme zu melden und diese Probleme zu beschreiben, aber keine Lösungen vorzuschlagen?

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

Ich hatte viel Erfolg damit, das Gespräch zu leiten, um meine eigenen Ziele zu erreichen. Mein Ziel ist es, - (1) das Problem zu bestätigen und zu klären (2) zu klären, was die Kriterien für eine Lösung sind (3) einen Ansatz zu prüfen, der zu einer endgültigen Antwort führt

Problem bestätigen

Das ist also, wo ich anfange – ich beginne nicht damit, ob die Lösung funktionieren wird oder nicht, ich beginne damit, alle Details des Problems zu erhalten, die in Ingenieurssprache (nicht Analystensprache) geklärt werden. Ich weiß nicht genau, wie die Probleme zu Ihrer Haustür kommen - Telefonanrufe können sich sehr von etwas mit Zeitverzögerung wie E-Mail oder Trouble-Tickets unterscheiden.

Aber in allen Fällen möchte ich klarstellen, dass Sie ihren Beitrag und die Natur 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 falsch/schlecht gesehen?
• Was sind die Daten oder die Art und Weise, wie sie präsentiert wurden?
• Was hast du gemacht, als es passierte?
• Was hält Sie davon ab?
• Passiert es zu einem anderen Zeitpunkt? Kannst du es noch einmal machen? Können Sie mir Schritte geben, damit ich es wiederholen kann?
• Was hat hier Priorität? (sollte etwas korreliert sein mit "was hält dich davon ab?")

Ich weiß, es klingt verrückt, aber stellen Sie auch sicher, dass die Benutzer sich bewusst sind, dass Sie sich Notizen machen und alles aufschreiben. Paraphrasieren Sie, was Sie gehört haben, und vergewissern Sie sich, dass Sie es richtig verstanden haben. Ein Haufen Schnellfeuerfragen, die oberflächlich gestellt werden, wird eine feindselige Antwort hervorrufen. Ein intensives Gespräch über das Problem wird die Angst lindern, dass Sie nichts dagegen tun werden.

Es muss etwas auf dem richtigen Weg bleiben, aber wenn Sie zu "Was haben Sie versucht zu tun?" und "Was können Sie nicht tun, wenn dieses Problem auftritt?" - Lassen Sie es ein wenig in die Welt des Analytikers eintauchen. Sie können das Problem zwar nicht auf „ihre Art“ lösen, aber Sie müssen das Problem auf eine Weise lösen, die für sie funktioniert, und das bedeutet, dass Sie mehr als nur ein bisschen darüber wissen müssen, was sie zu erreichen versuchen. Es ist ein matschiger Raum – Sie können unendlich viel Zeit hier verbringen, und kluge Leute LIEBEN es, über das zu sprechen, was sie tun – also gibt es einige Arbeit, um das Gespräch darüber zu führen.

Klären Sie die Anforderungen an eine Lösung

Sofern das Problem nicht verblüffend klar ist, gibt es wahrscheinlich zahlreiche verfügbare Lösungen. Aber eine Lösung für den Analysten ist nicht unbedingt machbar, und eine Lösung für den SW-Entwickler ist nicht unbedingt eine Lösung für den Analysten. Weichen Sie dem „Ich habe Recht/Sie haben Recht“-Gespräch aus und sprechen Sie über die Anforderungen an die Lösung.

Manchmal kann ich es in zwei Teile aufteilen: - Wenn ich dir etwas schnelles und schmutziges geben würde, was wäre die absolut kleinste Änderung, die ich vornehmen könnte, um dich zufrieden zu stellen? - Wenn ich einen Zauberstab hätte und ihn sofort ohne Zeit und Mühe reparieren könnte - wie sähe die Lösung aus?

Von da an fällt es normalerweise der Software-Person zu, diese Lösungen als Anforderungen neu zu definieren. Obwohl Analysten wirklich kluge, sachliche und informationsbewusste Menschen sind, sind sie keine Softwareentwickler und verstehen den sehr spezifischen Jargon nicht, der in den Methoden zum Entwerfen einer Benutzererfahrung verwendet wird. Daher sage ich normalerweise, was ich für offensichtlich über die Anforderungen der beiden Lösungen halte - "Must Haves" sind sowohl das absolute Minimum als auch die vergoldete Option. „Want to have“ nur in der idealen Lösung. Ich bitte um zwei Datenstücke, weil ich oft eine Menge versteckter Dinge vom Typ "Ich brauche es überhaupt nicht, es ist nur meine Vermutung" in dieser "Mindestmaß" -Lösung aufdecke, die nie auftaucht in der "nice to have"-Lösung.

Genauso wie Entwickler Dinge über Benutzer annehmen, machen Benutzer oft Annahmen darüber, was "einfach" ist - normalerweise sind sie anständig und wollen nicht stören, also fragen sie nach dem, was sie für "einfach" halten, und werden dann gestresst, wenn Sie es sagen ihnen ist ihre Lösung gar nicht so einfach...

Wie ist das?

Normalerweise ist eine einfache Änderung etwas, auf das sich Entwickler und Benutzer an dieser Stelle am Telefon einigen können ... aber ich wette, dass der Grad der Frustration, den Sie beschreiben, normalerweise nicht so hoch ist.

Daher kann es sein, dass der Entwickler etwas Zeit braucht, um etwas zu basteln. Aber dies ist eine gute Zeit für Prototypen, Screenshot-Beispiele und andere Ideen, um sie dem Benutzer zurückzugeben, bevor es zu schwerem Heben kommt. Es ist wie ein Mini-Agile-Projekt – werfen Sie etwas auf sie und erhalten Sie einen Einblick, ob es funktioniert, bevor Sie wirklich etwas implementieren und testen.

Sich 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 werden … aber dies ist die Zeit, in der Sie für eine Sekunde innehalten und wirklich nachdenken können, bevor Sie das Unmögliche versprechen. Ich habe festgestellt, dass es tatsächlich Vertrauen aufbaut, wenn man sich einen Moment Zeit nimmt, um hier nachzudenken, denn an diesem Punkt erkennen sie, dass das Problem nicht „einfach“ ist, aber Sie sind genauso engagiert, eine Lösung zu finden, wie sie es tun, das Problem zu beheben.

Fazit

Das baut in der Regel viel Vertrauen auf. Du hast nie „nein“, „du liegst falsch“ oder „deine Ideen sind absolut unmöglich“ gesagt, also hast du nie den Groll aufgebaut, der entsteht, wenn du ausgeschlossen wirst. Die Leute geben normalerweise gerne Details zu ihren Problemen, ihren Träumen von einem perfekten Produkt und Meinungen zu etwas ab, das noch nicht hergestellt ist - Sie fragen also nicht nach etwas Verrücktem.

Ich habe festgestellt, dass Menschen (sogar hochrangige Menschen) sehr selten erwarten, dass Sie das tun, worum sie bitten, ohne Fragen, Bedenken oder alternative Ideen. Tatsächlich erkennen die meisten klugen Menschen, dass es eine Fragerunde geben muss, bevor sie fortfahren.

Es kommt nur darauf an, wie Sie die Fragen stellen und welche Sie stellen.

Ich denke nicht, dass die Tatsache, dass sie Korrekturen vorschlagen wollen, ein Problem ist, ich denke, das ist sogar sehr gut, denn manchmal kann es funktionieren, und wenn sie aus demselben Grund ständig nicht funktionieren, kann es einen Versuch wert sein Beheben Sie diese Einschränkung.

Was trainiert 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 Wege zur Behebung von Problemen nachzudenken, aber sie müssen auch darauf vertrauen, dass die Technik ihren Job macht, und wenn die Idee nicht funktioniert, müssen sie nicht wissen, warum sie gewonnen hat nicht funktionieren, nur dass ihre Bemühungen zu helfen nicht einfach ignoriert werden.

(Vollständige Offenlegung – ich bin ein sehr erfahrener Datenanalyst.)

Auch Datenanalysten sind Entwickler. Beginnen Sie, sie mit dem gleichen Respekt zu behandeln, den Sie einem anderen Entwickler entgegenbringen würden, der an einer Anwendung arbeitet, die mit Ihrer verwandt ist. Das sind sie. Natürlich sollten sie Vorschläge machen. Natürlich sollten Sie die Freiheit haben, Ihre eigenen Reparaturen vorzunehmen. Sie wissen Dinge über die Anwendung, die sie nicht wissen, aber sie wissen Dinge darüber, wie die Daten außerhalb Ihrer Anwendung verwendet werden. Arbeiten Sie gemeinsam an Lösungen, die den Bedürfnissen beider Gruppen entsprechen.

Wenn sie häufig Vorschläge machen, bedeutet dies, dass Ihre Lösungen ihnen wahrscheinlich häufig Probleme bereitet haben. Sie müssen mehr darüber erfahren, warum die Lösungen, die Sie haben, für sie nicht funktionieren, und sich ihre Vorschläge ernsthaft anhören und versuchen, eine Mittelweglösung zu finden, die beiden Gruppen das bietet, was sie brauchen.

Wenn die Vorschläge etwas mit der Struktur der Datenbank zu tun haben (einschließlich Dinge wie Einschränkungen, Fremdschlüssel, Tabellenstrukturen), dann sind sie die Experten und Sie sollten sehr genau zuhören. Manchmal verbessern Dinge, die Ihnen das Leben unbequemer machen, die Qualität der Daten drastisch, was für die Leute, die Berichte und Datenexporte für die Kunden schreiben müssen, sehr wichtig ist. Es ist ziemlich peinlich, dem Kunden zu erklären, warum Sie beispielsweise doppelte Datensätze haben, weil die Anwendungsentwickler keine Kontrolle über die Dateneingabe eingeführt haben. Wenn die Daten aus regulatorischen Gründen verwendet werden, kann dies über das Peinliche hinaus zu ernsthaften rechtlichen Problemen für die Organisation führen.

Ich habe oft gesehen, wie Entwickler nur kurzfristig entwerfen, was für mich am schnellsten und einfachsten ist. Beim Zugriff auf Daten ist dies eine verlorene Strategie, da schlechte Daten oder eine schlechte Datenbankleistung weitaus kritischer sind. Häufig sehen Anwendungsentwickler die wirklichen 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 eine gute Lösung zu sein scheint, wenn nur jeweils ein Datensatz eingegeben oder die 15 Datensätze abgerufen werden sollen, die Sie auf einem Bildschirm anzeigen möchten, ist keine gute Lösung für die Personen, die den Who-Datensatz später konsumieren müssen.

Also hören Sie sich die Vorschläge an und nehmen Sie sie ernst. Wenn ein Anwendungsentwickler bei einem anderen Projekt einen Vorschlag machen würde, weil Ihr Produkt seines betrifft, würden Sie ihn nicht ernst nehmen? Würden Sie es ablehnen, sich mit ihm zu unterhalten, um zu erklären, warum das nicht funktioniert, oder um andere Möglichkeiten auszuloten? Datenanalysten verdienen die gleiche Behandlung.

Dies ist eine großartige Frage, die in allen Organisationen, für die ich gearbeitet habe, gestellt wurde. Bei der Lösung des Problems ist es wichtig, im Hinterkopf zu behalten, dass die meisten Leute, die Lösungen anbieten, denken, dass sie hilfreich sind, ohne sich der zusätzlichen Kleinarbeit bewusst zu sein, die erforderlich ist, um mit lösungsbasiertem Feedback umzugehen. Die Wurzel des Problems ist natürlich kulturell, kann aber typischerweise auf zwei Dinge reduziert werden:

1. Ein Mangel an Verständnis für Ihren Prozess
2. Verwirrung über die Rollen/Fähigkeiten der verschiedenen Teams und/oder Teammitglieder

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 Akteure sind an verschiedenen Stellen involviert? Was ist Ihr Iterationszyklus? Wo sind Ihre Checks and Balances? Eine kurze Präsentation/Gespräch darüber, wie die beweglichen Teile zusammenpassen, ist entscheidend für die Teams, um ein gegenseitiges Verständnis und Respekt für den Prozess zu entwickeln. Diese Diskussion bildet die Grundlage für Ihr nachfolgendes (und gezielteres) Gespräch über Teamrollen.

Das Verständnis der eigenen Rolle ist innerhalb einer Organisation unerlässlich, aber ebenso wichtig ist der Respekt vor Fachwissen. Es hört sich so an, als hätten Sie hervorragende Teams, aber ihr Verständnis davon, wo ihr Fachwissen in den Prozess passt, wird missverstanden. Es wird hilfreich sein, das Problem als Gruppe anzugehen, indem die Übergabe vom Analysten an den Ingenieur visualisiert und diskutiert wird. Stellen Sie sicher, dass das Team einige Diskussionen über die Effizienz führt, die durch eine straffere Gestaltung des Feedback-Zyklus erzielt wird. Ihr Team sollte in der Lage sein, von Folgendem auszugehen: Problem – Ingenieur vorgeschlagene Lösung (ggf. zusätzliches Feedback einholen) – Entwicklung. Auch dies ist ein guter Ort, um wesentliche Teile Ihres Prozesses hervorzuheben: Codeüberprüfung, Iterationszyklen, Benutzertests usw., damit jeder dem Team und den Checks and Balances vertrauen kann, die Sie in Ihren Prozess eingebaut haben.

Eine andere Strategie, die ich verwendet habe, ist die „Ich habe deinen Rücken“-Strategie. Die Beziehung zwischen Analysten und Ingenieuren kann sich wirklich festigen, wenn die Menschen das Gefühl haben, dass sie sich gegenseitig unterstützen. Wenn Analysten ihre Bemühungen darauf konzentrieren, Probleme, Anforderungen und gute Berichte zu verstehen, können sie die Ingenieure von dem Stress und der Ablenkung befreien, die durch das Zurücktreten entstehen. Wenn Sie die Analysten davon überzeugen, wie wichtig ihre Rolle ist, wird das Stolz aufbauen und ihnen helfen, konzentriert zu bleiben.

Und schließlich tritt häufig ein drittes Problem auf, wenn Teams, die Feedback geben, die von Entwicklungsteams verwendete Terminologie vermissen lassen (z. B. Fehler, Verbesserung, neue Funktion). Dieses Problem kann normalerweise schnell durch eine einfache Präsentation behoben werden, in der die Unterschiede erklärt, die vereinbarten Definitionen veröffentlicht und Mechanismen für Feedback erstellt werden. Dieses Problem scheint nicht zu Ihrer speziellen Situation zu passen (es passt eher zu Kundendiensteinheiten, die Feedback geben), aber ich fand es erwähnenswert.

Geben Sie ihnen im Berichtstool zwei Felder:

Please Describe The Issue in Detail
[                                         ]

If you desire, please add a suggested fix
[                                         ]

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 kontrollieren können : Ihre. Verwenden Sie ihre Lösungsbeschreibung, um zu einer Beschreibung des Problems zu gelangen, und führen Sie sie dann zu einer Beschreibung einer Lösung, die Anforderungen entspricht, die ihnen nicht bekannt sind.

Wenn sie zum ersten Mal mit einer Lösung zu Ihnen kommen, fangen Sie nicht an, darüber zu sprechen, warum es nicht funktionieren wird. 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 die Anforderungen erfüllt oder Technologien verwendet, die ihnen möglicherweise nicht bekannt sind. Wenn sie immer noch widersprechen, beschreiben Sie erst 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 bekommen. Streben Sie auf jeden Fall danach, die Kommunikation so effizient wie möglich zu gestalten, aber wenn Sie Zeit für die Schulung Ihrer Analysten aufwenden müssen, 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 bereitstellen. 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üsstest du näher darauf eingehen.

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 beim Versuch, Ihre Lösung zu implementieren, im Nachteil sein, wenn Sie mir nicht sagen, warum. Ich schätze, 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 zu Wikipedia-Ärzten geworden, nachdem sie ihre Symptome ein paar Stunden online recherchiert haben. Nun ermutigt und fordert das Modell für die Diagnose sogar Benutzer-(Patienten-)Feedback. Sie haben jetzt Patienten, die Vergiftungsdiagnosen mit Sachen stellen, die sie online lesen.

Das aktuelle Modell Ihrer Fehlerberichterstattung erlaubt oder ermutigt wahrscheinlich sogar zu viel Feedback vom Fehlerberichterstatter, wodurch Sie gezwungen sind, 21 Fragen mit Ihren Analysten zu spielen. Ich würde empfehlen

1. Richten Sie einen formal dokumentierten Fehler-/Fehlermeldeprozess/-verfahren ein, der die beteiligten Akteure und ihre jeweiligen Rollen klar umreißt

2. Investieren Sie in Tools/Methoden, die eine gewisse Distanz zwischen Ihnen und den Analysten schaffen (zumindest JIRA). Die Distanz/Trennung fördert ein gewisses Maß an Kapselung zwischen den beteiligten Parteien. Wenn der größte Teil der Problemverfolgung/-meldung über ein Forum wie JIRA oder IMO erfolgt, wird es der Problemmelder weniger bequem finden, wahrscheinliche Lösungen zu scherzen/zu diskutieren (vorausgesetzt, die Rollen innerhalb des Systems sind richtig definiert). Ihr Team kann sich grundsätzlich auf die wichtigen Teile eines bestimmten JIRA konzentrieren und sich nicht um die zeitaufwändigeren Diskussionen kümmern

Ich habe mich ursprünglich gefragt, ob es in den Gruppen eine Trennung zwischen dem gibt, was meine Firma "Fehler" und "Verbesserungen" nennt. Ziemlich oft kann ein Problem in eine der beiden Kategorien eingeordnet werden, aber viele passen besser in die eine oder andere. Informationen werden als falscher Datentyp zurückgegeben: Fehler. Der Analyst möchte die Möglichkeit haben, Daten beim Abrufen zwischen den Typen konvertieren zu lassen: Verbesserung. Vielleicht schlugen die Analysten im Rahmen von Verbesserungsanfragen Lösungen vor. Einige Kommentare des OP zu der Frage und die verschiedenen Antworten implizieren, dass dies möglicherweise ein 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 auseinandersetzen müssen, bis hin zur Analyse von Arbeitsabläufen 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 denke natürlich nicht, dass dies eine vollständige oder beste Antwort ist, aber es ist zu lang für einen Kommentar!

Die richtige Lösung dafür ist eine Bug-Tracking-Datenbank, in der die Analysten nicht nur Fehler melden, sondern auch ihre Ideen als Funktionsanfragen einreichen können (anstatt Zeit damit zu verschwenden, mit Ihnen darüber zu diskutieren). Es könnten einige Diamanten zwischen den Kohlestücken dort sein.

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

[D]ihre Vorschläge sind aufgrund anderer Softwareanforderungen, mit denen die Analysten nicht vertraut sind, oft nicht in Software umsetzbar.

Die Analysten sagen Ihnen nicht wirklich, welche Art von Code Sie schreiben sollen? Lassen Sie sie die Lösungen in Bezug auf Anwendungsfälle beschreiben. Dinge, die als Bugfix kurzfristig nicht umsetzbar erscheinen, können mit der richtigen Planung und Investition von Ressourcen machbar sein.

Bei Software ist es schwierig, Ideen zu bekommen, also sollten Sie so viele Köpfe wie möglich auswählen.

Vielleicht wäre die beste Lösung, sie zu ermächtigen, Ideen zu entwickeln, die tatsächlich umsetzbar sind, basierend auf den Einschränkungen, die Sie verwalten, um dies zu tun, könnten Sie die Dokumente mit dem Umfang und den Grenzen des Projekts optimieren.

Falls die Ideen weiterhin überwältigend sind, könnte die Implementierung eines Formats zum Einreichen von Fehlern einschließlich eines möglichen Korrekturfelds (das Sie ignorieren könnten) der richtige Weg sein.