Ich bin ein junger UX-Spezialist. Ich habe an ein paar echten Projekten an der Universität gearbeitet, aber ich war nicht wirklich in sie investiert, es gab nicht so viel Druck, sie richtig hinzubekommen.
Seit anderthalb Jahren arbeite ich an meinem ersten richtigen Job. Es ist eine Greenfield-Entwicklung bei einer staatlichen Institution. Sie haben mich zwar hauptsächlich als Entwickler eingestellt, aber sie haben mich ausgewählt, weil sie wollen, dass ich meine Fähigkeiten in Softwareentwicklung und UX einsetze.
Meine einzige Quelle für das Sammeln von Anforderungen war bisher der Product Owner. Ich fand immer, dass sie sich sehr für das Projekt einsetzt und viel Zeit dafür aufwendet. Alle im Team (ich als Vollzeit-Junior-Entwickler und mein Chef, der eine Projektmanagement-Rolle hat) haben eine sehr gute Beziehung zu ihr entwickelt, und ich hatte immer das Gefühl, dass wir vier zusammen auf ein gemeinsames Ziel hinarbeiten.
Letzte Woche habe ich angefangen, Usability-Tests durchzuführen. Und nach dem zweiten Test war ich so voller schlechter Nachrichten, dass ich beschloss, dass wir die anderen Tests verschieben müssen. Ich habe ein Krisentreffen einberufen, als ich noch völlig verzweifelt war (jetzt merke ich, dass es ein Fehler war).
Was ich aus den Tests gelernt habe, waren zwei Probleme: Erstens stoßen die Benutzer auf so viele Probleme, dass meine Schätzung des Arbeitsaufwands auf Designebene viel zu niedrig ist. Zweitens wollen unsere Benutzer unsere Anwendung nicht. Wenn sie es verwenden würden, würden sie es als zu viel Arbeit für zu wenig Rendite empfinden. Aber sie sind tatsächlich aktiv dagegen, die Art von Informationen zu dokumentieren, die die Anwendung von ihnen benötigt.
In der Krisensitzung informierte ich das Team über die Probleme und erwartete, dass wir anfangen werden, gemeinsam daran zu arbeiten, die Situation irgendwie zu beheben und eine Lösung zu finden, die in der kurzen Zeit, die uns bleibt, umgesetzt werden kann, indem wir andere Teile einer echten Lösung prüfen die "nächste Veröffentlichung"-Liste. Stattdessen sagten sowohl mein Chef als auch der Product Owner, dass wir nichts ändern und einfach nach dem „ursprünglichen Plan“ weiterarbeiten sollten. Sie sind beide überrascht, dass ich mich so für den Systemerfolg einsetze.
Bezüglich des zweiten Problems sagte die Produkteigentümerin, dass sie diese Datenbank für die Benutzer erstellt, und wenn sie „zu egoistisch“ sind, Informationen darin einzugeben, ist das ihr Problem, es ist ihr egal, ob ein einzelner Datensatz darin landet.
Was das erste Problem angeht, sagte ich ihnen, dass mein ursprünglicher Plan nicht gewesen sei „an der Benutzeroberfläche zu arbeiten, bis es wie ein fertiges Konzept in meinem Kopf aussieht“, sondern „an der Benutzeroberfläche zu arbeiten, bis die Benutzer eine angemessene Rate von haben Aufgabenerfolg". Ich kann also nicht einfach weiterarbeiten und die Deadline einhalten; Vielmehr muss ich wahrscheinlich einige der komplizierteren Funktionen (die am meisten Verwirrung stiften) herausschneiden und das OK des Produkteigentümers benötigen, um sie zu entfernen, und ein Brainstorming darüber, wie wir die Nützlichkeit der Anwendung ohne diese kompliziert erhalten können Merkmale. Sie weigert sich absolut, Funktionen wegzulassen, und sagt, dass ich die Software so liefern muss, wie sie es will, und wenn die Benutzer zu dumm sind, sie zu benutzen, ist ihr das egal. Wir waren beide so verwundet, dass wir ohne die ausgleichende Moderation des Projektleiters
Meine Projektmanagerin unterstützt die Idee, so zu liefern, wie sie ist, weil sie befürchtet, dass jede große Änderung so spät dazu führen kann, dass wir die Frist verpassen.
Ich verstehe die Position meiner Chefin, und ich muss sowieso tun, was sie mir sagt. Aber es fällt mir wirklich schwer, weil ich nicht weiß, wie. Mein Kriterium, meine Arbeit für abgeschlossen zu erklären, wurde verboten, und ich habe kein anderes. Ich versuche mich irgendwie daran zu gewöhnen, aber es ist schwer, nicht das zu tun, was meiner Meinung nach getan werden muss.
Was die Product Owner betrifft, so kann ich kein Verständnis für ihre Position finden, so sehr ich mich auch bemühe. Wenn ihr Systemerfolg egal ist, was interessiert sie dann? Warum hat sie das Projekt überhaupt initiiert? Auf welches Ziel arbeiten wir hin?
Ich sehe jetzt, dass ich mich dem Erfolg des Systems viel mehr verschrieben habe, als ich gedacht hatte. Es ist eine Kombination aus
Da ich vier starke Motivatoren habe, bezweifle ich, dass ich mich an einen Punkt bringen kann, an dem ich dem Systemerfolg so gleichgültig gegenüberstehe wie dem Product Owner und dem Projektmanager. Aber ohne diese Gleichgültigkeit ist jede Stunde, die ich damit verbringe, das Schwein mit Lippenstift zu schminken, quälend und demotivierend. Ich habe mich am Wochenende beruhigt, aber ich weiß bereits, dass ich am Montagmorgen um 9:00 Uhr in eine kognitive Dissonanzzone eintreten werde.
Was kann ich tun, damit ich dieses Projekt bis zur Freigabe durchstehen kann, ohne mich in eine psychische Störung zu versetzen?
Willkommen in der Arbeitswelt!
Darf ich Ihnen ein paar Slogans anbieten?
Im Ernst, dies ist wahrscheinlich Ihre erste Begegnung mit einem realen System. Die wichtigsten und am schwersten zu verstehenden Komponenten realer Systeme sind die Menschen. Wird es für die Leute Ihres Softwarepakets – Ihre beabsichtigten Benutzer – schwierig sein, es anzuwenden? Wahrscheinlich. Spielt es eine Rolle, wie schwer es zu benutzen ist? Möglicherweise nicht. Dies sind Regierungsangestellte, die ihre Arbeit erledigen, keine Hipster, die zum Spaß Apps auf ihre Geräte herunterladen. Sie werden Ihr System verwenden, wenn ihre Vorgesetzten sie dazu anweisen.
Veränderungen bedrohen die Menschen. Information ist Macht, und neue Informationssysteme versprechen manchmal eine Umverteilung der Macht. Das bedeutet Unsicherheit. Die Leute, mit denen Sie Ihre Usability-Tests durchgeführt haben, reagieren möglicherweise auf so etwas. Und glauben Sie mir, viele ihrer Reaktionen sind möglicherweise nicht bewusst. Die UX-Schwierigkeiten, die Sie beobachten, können auf die Zurückhaltung zurückzuführen sein, diese neue Sache anzunehmen.
Lassen Sie sich von niemandem sagen, dass Sie sich keine Gedanken mehr über die Benutzerfreundlichkeit machen sollen. Aber akzeptieren Sie gleichzeitig die Weisheit Ihres Product Owners (es ist tatsächlich Erfahrungswissen, auch wenn das schwer zu erkennen ist) darüber, was für Ihr Projekt gut genug ist.
Sie werden viel lernen, wenn Sie dieses Pferd den ganzen Weg über die Rennstrecke reiten. Sie können Beziehungen zu einigen der Benutzer aufbauen und ihre Beweggründe herausfinden. Sie können den Rollout eines unvollkommenen Systems beobachten und daraus lernen. Sie lernen den Rollout-Rhythmus kennen und lernen, wie wichtig es ist, ein wenig subversiv zu sein, um Systemen Exzellenz zu verleihen.
Sie wirken wie ein Systemdenker. Das ist eine sehr seltene Eigenschaft; Bitte kultivieren Sie es. Besorgen Sie sich ein Exemplar von The Fifth Discipline von Peter Senge und lesen Sie es, während Sie dieses Projekt verfolgen.
Du sagst das; Betonung von mir:
Meine Projektmanagerin unterstützt die Idee, so zu liefern, wie sie ist, weil sie befürchtet, dass jede große Änderung so spät dazu führen kann, dass wir die Frist verpassen.
Und sagen Sie dies; Betonung wieder von mir:
Was die Product Owner betrifft , so kann ich kein Verständnis für ihre Position finden, egal wie sehr ich mich bemühe. Wenn ihr Systemerfolg egal ist, was interessiert sie dann? Warum hat sie das Projekt überhaupt initiiert? Auf welches Ziel arbeiten wir hin?
Ein Projektmanager zu sein, bedeutet für Sie, dass jemand auch der Product Owner ist . Das ist nicht der Fall. Als Projektmanagerin ist ihr Maßstab nicht die Qualitätssicherung – was eigentlich der Kern dessen ist, worum es Ihnen geht – sondern das Gesamtmanagement des Projekts.
Das heißt – und ich gebe nur ein Pseudobeispiel – nehmen wir an, dies ist das Kriterium auf höchster Ebene, mit dem sie sich befasst:
Dann ist ihre Arbeit erledigt.
Jetzt werden Sie sich vielleicht wundern, dass dies ein abgeschlossener Job sein kann, wenn das Endprodukt so schlecht ist und so leicht verbessert werden kann. Aber auch das ist nicht die Aufgabe des Projektmanagers.
Dies ist das grundlegende bürokratische Rätsel, mit dem sich jeder Entwickler auseinandersetzen muss, wenn er mit einem Projekt oder Projektmanager zu tun hat. Manchmal verstehen sie die Grundlagen eines Problems nicht. Und es gibt keine Möglichkeit, das zu lösen … Aber eins …
Qualitätssicherung.
Jetzt denken Sie vielleicht, dass Sie – als Entwickler – glauben, dass Sie die Qualitätssicherung in Ihren Prozess einbeziehen, aber das meine ich nicht.
Was ich meine ist, dass irgendwie – auf höheren Ebenen als Ihrem Projektmanager – das Konzept angesprochen werden muss, dass es eine Qualitätssicherungsphase im Prozess geben muss. Nun, wie macht man das? Unklar. Und hier ist warum.
Der Grund, warum so viele Projekte in solchen dysfunktionalen Zuständen enden, ist entweder:
Im Grunde müssen Sie sich hier der harten Realität stellen, dass Sie zwar in Bezug auf die Qualitätsprobleme Recht haben, aber keine wirkliche Macht haben, Dinge zu ändern.
Und – das ist der Schlüssel – wenn Sie sich entscheiden, härter zu arbeiten oder zusätzliche Stunden zu arbeiten, um diese Probleme zu lösen, könnten Sie mit Gegenreaktionen konfrontiert werden. Das heißt, während Sie das Projekt verbessert haben, wird es im schlimmsten Fall niemanden interessieren oder so beleidigt sein, dass Sie „aus der Reihe tanzen“, sie werden einen Weg finden, Sie einfach dafür zu bestrafen, dass Sie es gewagt haben, zusätzliche Arbeit zu leisten.
Ja, das klingt nach BS. Und ja, es ist BS. Und ja, am Ende des Tages gewinnt niemand wirklich. Aber leider tritt in manchen Arbeitsumgebungen die Leidenschaft für den Job hinter bürokratischen Unsinn und allgemeine Dysfunktionalität zurück.
Das Beste, was Sie tun können, ist, realistisch zu bleiben und zu versuchen, nicht jedes Projekt wie einen besonderen magischen Diamanten oder ähnliches zu behandeln. Und ja, es ist demoralisierend. Aber rate mal was? Aus diesem Grund erstellen viele Menschen unabhängig von der Arbeit Nebenprojekte, um ihre Fähigkeiten uneingeschränkt auszudrücken.
Für Ihre eigene berufliche Gesundheit ist es vielleicht am besten, Ihr Programmierleben zwischen den Dingen aufzuteilen, die Sie wirklich für die Arbeit tun, und den Dingen, die Sie wirklich für sich selbst tun.
Radu Murzea
HLGEM
pmf
gnasher729
Itsme2003