Unklare Aufgaben auf der Arbeit

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Unklare Aufgaben auf der Arbeit

      New

      Eines vorweg: Ich kann selbstständig arbeiten, sehr gut sogar.
      – Wenn man mir ein mathematisches/physikalisches Problem gibt und die einzige Aufgabe bzw. das einzige Ziel ist, dieses Problem irgendwie zu lösen und Ergebnisse/Lösungen vorzuweisen, und mir ansonsten volle Freiheiten und keinerlei Vorgaben gibt, wie ich es lösen soll, habe ich keine Schwierigkeiten.
      – Wenn man mir genaue(!) Anweisungen (man denke an eine To-Do-Liste) gibt, wie ich ein Problem lösen soll, welche Programmiersprachen/Bibliotheken ich verwenden soll, welche Parameter als konstant angenommen werden sollen und weche nicht, etc. habe ich ebenfalls kein Schwierigkeiten.

      Meine Schwierigkeiten fangen zwischen diesen beiden Extremen an:
      Wenn der Chef eine „bestimmte“ Vorstellung davon hat, was ich wie machen soll oder was das Ziel des Projektes sein könnte, dies immer wieder aber nur vage andeutet, ständig relativiert, ständig seine vagen Andeutungen ändert, und das eigentliche Ziel unklar bleibt – und es andererseits meine Aufgabe sein soll, mir Aufgaben selbst zu geben und Probleme selbstständig zu lösen.

      Im Endeffekt bedeutet das für mich, dass ich mir selbstständig erarbeiten soll, was der Chef momentan für Vorstellungen hat und was er von mir erwartet, woran ich jetzt gerade arbeiten soll.
      Tatsächlich geht fast meine ganze Energie darauf, herauszufinden, was der Chef überhaupt will, und für die eigentliche Bearbeitung der Aufgabe bleibt keine Energie mehr.


      Momentan ist es so, dass wir uns im Projekt noch in der Forschungsphase befinden, wo wir (5 Leute insgesamt) zunächst Informationen über das gestellte Problem sammeln.
      Nach meinem Verständnis bedeutet das u.a. bisherige Messdaten, vorige Ergebnisse ähnlicher Projekte, Publikationen/Literatur, theoretische Modelle usw. zusammensuchen und den großen Zusammenhang zu verstehen.

      In fast jedem Meeting ist aber die Rede von der „ersten Version“ (das gestellte Problem soll mit einer selbst geschriebenen Software gelöst werden), die wir „bald“ (seit Wochen ...) zu programmieren anfangen sollen.
      Es wird angedeutet, dass diese erst mal mit A oder B statt C implementiert werden soll. Dann soll x vielleicht oder vielleicht auch nicht als konstant angenommen werden. Wir benutzen vielleicht Python oder C++. Fast alles wird mit einem „mal schauen“ erwähnt – geschaut wurde bisher nie.
      – Es gibt keine Konkretisierungen oder offenen Diskussionen, was diese „Version 1“ nun alles können oder machen soll, wie Aufgaben im Team verteilt werden und wann wir damit anfangen.
      Oft hatte ich sogar während des Meetings den Eindruck (so hörte es sich jedenfalls an), dass wir (4 ohne den Chef) längst an dieser Version arbeiten sollen. Aber ohne Einigung, wie sie nun aussehen soll, kommt mir so etwas sinnlos vor. Ich hatte auch mal einen Kollegen direkt gefragt, woran er gerade bzgl. Version 1 arbeite, und er meinte nur, dass er da schon mal „herumspielt“ habe – mit dieser Information konnte ich nicht viel anfangen.

      Mir fällt es sehr schwer aus solchen und vielen Andeutungen wie etwa
      „x und y sollte später noch gemacht werden, wir machen das aber erst mal anders“ (Ja, wie anders? Und was heißt später?),
      „modulo, schau mal nach xy und yz, was es da so gibt [...] xy und yz brauchen wir in der ersten Version nicht, vielleicht später, mach erstmal abc“ (Soll ich jetzt erst nach xy und yz schauen oder abc machen? Wann später brauchen wir xy und yz?)
      „in der endgültigen Version soll es so und so aussehen ...“ (Ja, wir sind noch bei Version 1, wann wird endlich klar, wie die aussehen soll?)
      „modulo, schau dir mal ABC an“ ... ich lese mich wochenlang in das Thema ein und am Ende wird es nie wieder erwähnt und interessiert niemanden
      usw. usf.
      ...
      Am Ende weiß ich nicht, woran ich arbeiten soll, soll ich „herumspielen“ wie der Kollege, soll ich weiter recherchieren und wenn ja was?

      Wenn ich ihm Team-Meeting nochmal nachfrage, was ich jetzt eigentlich machen soll, bekomme ich wieder nur dieselben Andeutungen und nichts Klares. Es ist so anstrengend und frustrierend, ich merke, dass mich Fragen nicht weiterbringen, weil sie nur ausweichend beantwortet werden und irgendwann fehlt mir einfach die Energie und Motivation zum 10. Mal dieselbe Frage (ggf. anders formuliert) zu stellen, in der Hoffnung endlich eine brauchbare Antwort zu bekommen.

      Meine Vorschläge im Team-Meeting, dass man wirklich einmal aufschreibt, wie diese „erste Version“ aussehen soll, führten auch zu nichts. Ich wurde vom Chef damit vertröstet, einmal dass der Server noch nicht bereit sei, dann dass das an sich jetzt auch noch nicht notwendig sei und wir das „später“ mal machen könnten, wenn das Projekt größer wird (Wann, bei Version 100?).


      Bereits bei früheren Jobs an der Uni oder in der Softwareentwicklung hatte ich diese Schwierigkeiten. Mir fällt es schwer hier festzustellen, warum ich (und wirklich nur ich als einziger im Team) immer wieder auf diese Schwierigkeiten stoße.

      Ich kann mir folgende Ursachen vorstellen:

      1. Bin ich ungeeignet für den Job, weil es integraler Bestandteil des Jobs ist, aus vagen Andeutungen selbstständig Aufgaben zu erarbeiten?
      Letztendlich muss man von jemandem mit Hochschulabschluss erwarten können, dass er selbstständig arbeitet.

      2. Liegt es am Autismus?

      3. Oder hatte ich bisher einfach nur Pech mit den Jobs, und die Kommunikation ist einfach schlecht und sollte bei einem guten Job nicht so sein?

      Ich habe eigentlich schon den Eindruck, dass es hauptsächlich am Autismus liegt, da ich hin und wieder von anderen Autisten mitbekommen habe, dass sie ähnliche bis gleiche Schwierigkeiten im Job hatten. Meine Vermutung ist, dass Nichtautisten solche Andeutungen wie oben beschrieben intuitiv erfassen können und gar nicht diese ganze Energie aufwenden müssen, um sich mühsam zu erarbeiten, was der andere will.
      In diesem Fall würde sich anbieten, mich an die Schwerbehindertenvertretung zu wenden und um Hilfe zu bitten, aber mir ist durchaus klar, dass das nur bis zu einem gewissen Grad möglich ist – denn letztendlich wird von einem Hochschulabsolventen natürlich selbstständige Arbeit erwartet und vermutlich gehört dort einfach dazu, dass man das mit ein paar Andeutungen schafft.

      Wie sind eure Erfahrungen mit Aufgaben auf der Arbeit (besonders IT, Uni, andere MINT-Bereiche)? Wie schätzt ihr diese Situation ein bzgl. der Ursachen (1, 2, 3)?
      Habt ihr euch mit so einem Problem schon einmal an die Schwerbehindertenvertretung oder den Integrationsfachdienst gewandt und konnte man euch helfen?
    • New

      Das klingt nach der allseits verbreiteten Führungsschwäche der Führungskräfte in der Wissenschaft… es reicht halt nicht als Projektleiter Ahnung vom Thema zu haben, aber gerade in der Wissenschaft rutscht man ja eher so nach oben in der Hierarchie ohne dass man die nötigen Zusatzqualifikationen beigebracht bekommt. Also es liegt am Chef, nicht an Dir, und damit auch nicht am Autismus.
      Mein Vorschlag: tu so als wäre es wie im ersten von Dir beschriebenen Fall, es gibt ein grob umrissenes Problem und Du denkst dir die beste Lösung aus mit den Methoden Deiner Wahl. Gut wäre den anderen Projektmitarbeitern dann zu sagen was Du zu tun gedenkst.
      Viel Glück und viel Erfolg.
    • New

      Hallo Modulo,

      aktuell bin ich auch frustriert, weil die Arbeitsoranisation an meiner jetzigen Stelle katastrophal ist.

      Mittlerweile kann ich meine Prioritäten und Aufgaben so setzen dass ich klar komme.
      Ich habe versucht so weit es geht wenig Kommunikationsaufwand für das beste Ergebnis zu haben.

      Ich Zitiere aus der Karrierebibel:
      Etwas, das jeden Tag aufs neue die Motivation eines Mitarbeiters ruinieren kann, ist Zeitverschwendung. Stundenlange Meetings, die am Ende keinen ersichtlichen Fortschritt erzielen oder völlig nichtssagende E-Mails, deren Bearbeitung unnötige Zeit kostet.

      Besteht denn die Möglichkeit dass du mit deinem Chef persönlich die von dir hier so gut aufgelisteten Punkte besprechen kannst?

      Letzendlich handelt es sich doch um ein Projekt für eine Software, also wie wäre es mit der Smart Regel?
      agile-master.de/smart-ziele-projektmanagement/
      Entscheidung. Das Problem ist die Entscheidung.
      - Matrix Reloaded, Neo
    • New

      @modulo Ganz genau !

      Entweder, Du kannst frei konzipieren oder es gibt klare Anweisungen, nach denen gearbeitet werden kann, alles dazwischen ist Murks.
      Das hat nichts mit Autismus zu tun sondern mit vernünftiger Herangehensweise.

      Ich nutze Python, zwar nur für Datenanalysen, aber auch da muss ich wissen, was exakt gewünscht ist, entweder inhaltlich oder konkret. Wenn man exakt arbeitet, kann man das nicht irgendwie tun.

      Zu Deiner Situation habe ich eine Verständnisfrage und eine Idee.

      Zuerst die Frage: Deine Beschreibung klingt, als ob das Arbeiten eher ein "Stochern im Nebel" (RW) ist als eine sinnvolle Projektarbeit. Wieso stört das nur Dich ?
      Oder halten sich die anderen zurück, weil sie sich darauf verlassen, dass Du es klärst mit Eurem Vorgesetzten ?

      Die Idee: es gibt einen Termin oder ein zeitliches Ziel (vor Corona wäre das beispielsweise eine Messe gewesen), zu dem grob gesagt "irgend etwas zu sehen" sein muss.

      Mein Mann ist Softwareentwickler und da kommt es vor, dass für eine Messe "was neues her muss" und dann wird mitunter eine Oberfläche erstellt und ein paar Spieldaten erzeugt, so dass der Kunde etwas zu sehen bekommt. Und sobald Kunden das Programmteil dann bestellen, wird die eigentliche Funktionalität und die Anbindung an das eigentliche Hauptprogramm programmiert.

      Ist es möglich, dass so eine Situation dahinter steckt, dass also im Grunde egal wie und womit etwas vorzeigbares erstellt werden soll, weil es irgendwem gezeigt werden soll?
      Und dann nach und nach das eigentlich Programm entwickelt?
    • New

      Ich bin derzeit in der gleichen Situation. Was heißt derzeit - seit fast einem Jahr.


      modulo wrote:

      Tatsächlich geht fast meine ganze Energie darauf, herauszufinden, was der Chef überhaupt will, und für die eigentliche Bearbeitung der Aufgabe bleibt keine Energie mehr.
      Ich glaube, genau der Satz beschreibt mein Problem recht gut. Ich habe nun schon in mehreren Gesprächen versucht, das ganze für mich angenehmer zu gestalten. Ich kann entweder Aufgaben abarbeiten oder eben wenn noch was unklar ist mir selbst ein Konzept machen. Aber ich arbeite derzeit in einem Team, in dem das sehr ungeplant und alles so vor sich hin läuft. Und nur wenn wirklich mal was dringend ist, macht sich einer der Produktmanager die Arbeit, zu sagen, was er will. Das mit den ewig nach hinten geschobenen Versionen haben wir auch. Und sehr viele Ideen, die jeden Monat neu priorisiert werden und wo man doch nix anfangen soll, weil die Idee ja noch nicht fertig ist, aber alle reden von der ersten Version, die ja nur als Prototyp dienen soll. Dieser dauernde Widerspruch im Management und diese dauernden Marketing-Phrasen, wo die Leute eigentlich selbst merken müssten, dass sie das nicht schaffen, was sie da verkaufen, nerven.

      Mein größtes Problem ist mittlerweile nicht mal meine Arbeit. Sondern dass die Kollegen gemerkt haben, dass ich mir die Arbeit dann selbst strukturiere (was viel Energie kostet) und dann zu mir rennen, wenn sie selbst nichts mehr zu tun haben oder nicht wissen, was aktuell zu tun ist. Ich hätte kein Problem damit, die Arbeit zu vergeben, aber dann bin ich wieder im Konflikt damit, dass das ja eigentlich nicht meine Rolle ist und es heißt, ich soll das nicht tun und mir auch nicht einfach was suchen. Auf der anderen Seite steht der Chef-Chef der druck macht, dass wir mehr arbeiten sollen und immer noch mehr Leute ins Projekt holt. Ich bin dauernd im Konflikt zwischen verschiedenen Leuten eingebunden, die ihre Ressourcen nicht so organisieren können, dass es halbwegs ordentlich und produktiv voran geht. Und die den Leuten keine Kompetenzen zutrauen, selbst etwas zu entscheiden und eben bei jeder Entscheidung mit reden wollen. Ich hab von meiner Rolle her keine Entscheidungskompetenzen, werde dann doch dauernd wieder zu Entscheidungen gezwungen, die ich eigentlich nicht treffen sollte, damit es irgendwie weiter geht.

      Meine Entscheidung dazu ist Anfang dieser Woche gefallen: Ich bin ab spätestens 1. Oktober nicht mehr in dem Projekt. Vielleicht komme ich auch früher raus, aber das ist eben das, was ich sicher mit meiner Kündigungsfrist machen kann. Was ich danach mache, weiß ich noch nicht, aber wenn ich so weiter mache, habe ich die Befürchtung, dass ich in spätestens einem Jahr langfristig ausfalle mit Burnout o.ä.

      Die technische Arbeit macht mir ja Spaß, aber dieses ganze Management stresst einfach nur noch.
      Wird schon ​„Katzen sind sinnlos. Was macht denn Sinn im Zusammenleben mit nem Lebewesen, das keine Sekunde Bock auf dich hat? Da könntest du auch heiraten“ - Martin Rütter

      The post was edited 1 time, last by hundefreund ().

    • New

      Wenn das Projekt so weiter läuft, dann wird daraus das typische "fährt an die Wand Projekt". Nahezu alle Anforderungen sind dafür bereits gegeben.

      Nimm das Heft in die Hand (RW) und strukturiere das Semmelsurium aus unstrukturierten Aufgabenteilen. Du hast ja selbst festgestellt, dass in deinem Team keiner weis, woran der andere gerade arbeitet und niemand sich so wirklich verantwortlich fühlt. Das darf so nicht mehr lange weitergehen sonst fährt das Projekt mit Höchstgeschwindigkeit an die Wand.

      Bekommst du Chaos als Aufgabe, dann strukturiere das Chaos und es ist dann weniger chaotisch. So erhälst du einen Überblick und das dient der "Ordnung".

      Das kannst du nicht nur in der IT verwenden, sondern funktioniert auch in anderen Lebensbereichen. Das weiss ich aus Erfahrung.

      Strukturiere es dir und erstelle dir eine Liste mit offenen Aufgaben. Das kann z.B. so aussehen:

      - Festlegung welche Sprache verwendet wird. Erfolgt im Team ohne Chef, weil es im wurscht ist, solange am Ende die Software als Ergebnis raus kommt.

      - Interview des Chefs, welche Features in Version 1 mindestens Implementiert sein müssen. Am Ende solltest du eine Feature List für Version 1 haben. Alles was später integriert werden soll ist dann ein Kandidat für Version 2. Das Interview führts du am besten mit deinem Chef allein. Schreib dir vorher alle Fragen auf, die beantwortet sein müssen, damit die Entwicklung von Version 1 theoretisch starten kann.

      - Mit der Featurelist marschierst du zu deinen Team Mitgliedern und führst quasi ein Team internes Meeting durch.
      Einleitungsbeispiel: Ich war so frei und habe geklärt welche Features wir in Version 1 rein packen sollen. Achso, das spielen auf der Codespielwiese ist somit abgeschlossen. Danach stellst du die Features vor und sammelst Ideen deiner Teammitglieder. So steht dann schon mal ein Ideenpool zur Verfügung der in einem zweiten Meeting auf pro und contra abgeklopft wird und am Ende alle sagen: So machen wirs.

      - Als nächstes wäre z.B. der API Entwurf dran.

      So gehst du Schritt für Schritt weiter vor.

      Mach dir das Projekt, wie du es brauchst, damit am Ende ein erfolgreiches Projekt draus wird.
    • New

      Das kenne ich, ich habe im Studium ständig Gruppenarbeiten. Mittlerweile nutze ich mein Studium bewusst in erster Linie v.a. für das Lernen, wie man in Gruppen bzw. Gruppenarbeit zurechtkommt. Der Rest ist natürlich schon Lernen für Klausuren, aber damit habe ich im Vergleich kein Problem.
      In Praktika ist es auch so - schlimm fand ich das früher während und kurz nach der Schule, wo mir noch nicht so wie heute halbwegs bewusst war, wie ich so ticke - andere Praktikanten (so sie denn nicht gewollt faul waren), liefen sofort los, taten hie und da dies und das, zu aller Zufriedenheit - und ich, die ich mit normalen Schuldingen wie lernen/Noten keine Probleme hatte wurde ganz verzweifelt, weil die Regeln bei Praktika bzw. Arbeit völlig anders zu sein schienen als in der Schule. Stand dann entweder rum oder fragte ständig, wie ich denn helfen könnte (besser als nichts, aber andere wusste das scheinbar ohne zu fragen).
      In den Studiums-Gruppenarbeiten komme ich halbwegs klar, wenn ich das "Ruder in die Hand nehme" und selbst das Wichtigste mache. Ich brauche meist viel mehr Zeit dazu als vorgesehen und mache noch alles mögliche außenraum dazu, aber anders geht es irgendwie nicht bzw. nach jahrelanger Erfahrung ist das so für mich das kleinste Übel. Vage Angaben kann ich auch überhaupt nicht haben. Andererseits geht das auch den meisten anderen Studenten so, die fragen noch viel mehr Dinge nach als ich (welche Schriftgröße? Haben Sie ein Beispiel?)
    • New

      Lachatte wrote:

      In Praktika ist es auch so - schlimm fand ich das früher während und kurz nach der Schule, wo mir noch nicht so wie heute halbwegs bewusst war, wie ich so ticke - andere Praktikanten (so sie denn nicht gewollt faul waren), liefen sofort los, taten hie und da dies und das, zu aller Zufriedenheit - und ich, die ich mit normalen Schuldingen wie lernen/Noten keine Probleme hatte wurde ganz verzweifelt, weil die Regeln bei Praktika bzw. Arbeit völlig anders zu sein schienen als in der Schule. Stand dann entweder rum oder fragte ständig, wie ich denn helfen könnte (besser als nichts, aber andere wusste das scheinbar ohne zu fragen).
      So ging es mir auch. In der Schule oder im Studium bin ich im Großen und Ganzen zurechtgekommen. Die Berufswelt scheint aber nach völlig anderen Regeln zu funktionieren, die einem keiner verrät. Oft habe ich mir zu Beginn des Schuljahres die Schulbücher schon durchgelesen und habe mich dann im Unterricht gelangweilt, weil ich vieles schon wusste. Mehr praxisnahe Inhalte oder überhaupt eine Prüfung, wo die individuellen Stärken und Defizite liegen, wäre da sinnvoller gewesen.


      Lachatte wrote:

      In den Studiums-Gruppenarbeiten komme ich halbwegs klar, wenn ich das "Ruder in die Hand nehme" und selbst das Wichtigste mache.
      Das klappt bei mir auch am besten, auch jetzt im Beruf. Wenn man anderen die Führung überlässt, muss man sich in deren System einfügen, was erfahrungsgemäß schlecht funktioniert.
    • New

      Klingt, als ob ihr einen schlechten Manager habt, der selbst keine Ahnung von Projektmanagement, Requirements Engineering u.Ä. hat.

      Eine Möglichkeit könnte sein, die Entwicklung agil zu gestalten, da die vollständigen Anforderungen bisher noch gar nicht klar sind. Führt ein Backlog mit User-Stories ein, in denen der Anforderungssteller grob beschreibt, was erwartet wird. Wenn man das festgehalten hat, kann entweder der Anforderungssteller mehr Details zur Umsetzung geben (z.B. eine Definition of Done) oder aber ihr arbeitet mit den vorhandenen Informationen los und ändert später um, wenn sich die Anforderungen ändern.

      Dann kann man auch das Minimal Viable Product (MVP) viel besser abgrenzen, indem man definiert, welche User-Stories alles umgesetzt sein müssen.

      Einen Server zum Festhalten der Anforderungen braucht es nicht. Das geht im Zweifel auch erstmal in einer Excel-Tabelle oder einer Wikiseite (falls ihr sowas wie ein Intranet habt).
    • New

      aehxy wrote:

      Eine Möglichkeit könnte sein, die Entwicklung agil zu gestalten, da die vollständigen Anforderungen bisher noch gar nicht klar sind.
      Das Problem bei Managern ist, dass sie unter „Agil“ meist einfach nur „ohne Plan“ verstehen. Und genau das ist Agile Entwicklung nicht.

      In der agilen Enwicklung wird sehr viel geplant, nur wird halt nicht ins Detail geplant. Du kannst das vergleichen wie mit einer neuen Stadt: Man legt erst den groben Grundriss und die Hauptstraßen fest, dann macht man sich an die Planung eines Virtels, baut dort die Straßen, dann wird jedes Haus einzeln geplant und gebaut. Der Unterschied zur klassischen Entwicklung ist eben nur, dass der Plan mit der Zeit entsteht. Aber man hat eben einen und man hat immer für die nächsten Wochen eine gut geplante Arbeit.


      aehxy wrote:

      Führt ein Backlog mit User-Stories ein, in denen der Anforderungssteller grob beschreibt, was erwartet wird. Wenn man das festgehalten hat, kann entweder der Anforderungssteller mehr Details zur Umsetzung geben (z.B. eine Definition of Done) oder aber ihr arbeitet mit den vorhandenen Informationen los und ändert später um, wenn sich die Anforderungen ändern.
      Du bist Manager, oder? :d Genau so wird agile Entwicklung aus Entwicklersicht ein Chaos. Denn die User-Stories sind dann meist zu ungenau geschrieben. Dazu wird dann ja meist eine Rolle eingeführt (du nanntest sie „Anforderungssteller“), also jemand spezielles im Team, der die Stories verwaltet und dessen Aufgabe es ist, sie zu verfeinern. Und jedes mal, wenn man nun also nichts mehr zu tun hat, muss man zu der Person rennen und betteln, dass sie wieder ein paar Sories so weit verfeinert, dass sie bearbeitbar sind. Und dann noch drei mal erklären, warum das so technisch nicht klappt oder warum man erst etwas anderes vorher machen muss. Und genau dieses vorgegebene Chaos ist es, was mich stört und was @modulo und einige andere hier anscheinend auch stört.

      In einer guten agilen Entwicklung werden die Aufgaben gemeinsam von den Entwicklern geschrieben. Die Anwender / Endnutzer geben (ggf. indirekt über den „Anfoderungssteller“) nur Funktionswünsche vor. Aber die technische Umsetzung und das ganze in einzelne Aufgabenpakete zu zerlegen und zu gewichten machen die Entwickler. Deshalb schreiben auch die Entwickler die entsprechenden User-Stories und legen die Akzeptanzkrierien für jedes Ticket fest. Denn der „Anfordeurngssteller“ weiß oft nicht mal, was wie viel Aufwand ist und was alles voneinander abhängt. (Bei Managern ist dies unbeliebt, denn in der Theorie braucht ein perfekt arbeitendes agiles Team keinen Manager).
      Wird schon ​„Katzen sind sinnlos. Was macht denn Sinn im Zusammenleben mit nem Lebewesen, das keine Sekunde Bock auf dich hat? Da könntest du auch heiraten“ - Martin Rütter

      The post was edited 2 times, last by hundefreund ().

    • New

      hundefreund wrote:

      Du bist Manager, oder? :d Genau so wird agile Entwicklung aus Entwicklersicht ein Chaos. Denn die User-Stories sind dann meist zu ungenau geschrieben. Dazu wird dann ja meist eine Rolle eingeführt (du nanntest sie „Anforderungssteller“), also jemand spezielles im Team, der die Stories verwaltet und dessen Aufgabe es ist, sie zu verfeinern. Und jedes mal, wenn man nun also nichts mehr zu tun hat, muss man zu der Person rennen und betteln, dass sie wieder ein paar Sories so weit verfeinert, dass sie bearbeitbar sind. Und dann noch drei mal erklären, warum das so technisch nicht klappt oder warum man erst etwas anderes vorher machen muss. Und genau dieses vorgegebene Chaos ist es, was mich stört und was @modulo und einige andere hier anscheinend auch stört.
      In einer guten agilen Entwicklung werden die Aufgaben gemeinsam von den Entwicklern geschrieben. Die Anwender / Endnutzer geben (ggf. indirekt über den „Anfoderungssteller“) nur Funktionswünsche vor. Aber die technische Umsetzung und das ganze in einzelne Aufgabenpakete zu zerlegen und zu gewichten machen die Entwickler. Deshalb schreiben auch die Entwickler die entsprechenden User-Stories und legen die Akzeptanzkrierien für jedes Ticket fest. Denn der „Anfordeurngssteller“ weiß oft nicht mal, was wie viel Aufwand ist und was alles voneinander abhängt. (Bei Managern ist dies unbeliebt, denn in der Theorie braucht ein perfekt arbeitendes agiles Team keinen Manager).

      Ich habe in meiner beruflichen Laufbahn einige Positionen gehabt, vom Programmierer, über Architektenrollen bis hin zum Management.

      Soweit ich es verstanden habe, ist hier das vordergründige Problem, dass es keinerlei tatsächliche Arbeitsorganisation gibt. Mein Vorschlag war auch nicht, ziellos und ohne Planung loszuarbeiten, sondern eben die bisher vorhandenen Anforderungen zu sammeln und diese dann im Folgenden herunterzubrechen und auszudetaillieren. Klar ist das nicht nach Standard, aber in einem Unternehmen, in dem es aktuell offenbar an sämtlicher Organisation mangelt, muss man eben mit kleinen Schritten anfangen und von da aus weitergehen.

      Als Einzelperson am Ende der Nahrungskette wird man selten in der Lage sein, die komplette Organisation zu verändern, aber man kann bereits mit realistisch umsetzbaren(!) kleinen Schritten eine spürbare Verbesserung erreichen. Und der erste realistische Schritt kann sein, dass man die vorhandenen Anforderungen abfragt, aufschreibt und auflistet. Wenn man Anforderungen hat, die bereits detailliert genug sind, um damit was anzufangen, kann man mit der ersten Umsetzung beginnen. Über Anforderungen, die noch zu grob sind, kann man wieder drüber gehen in der Hoffnung, sie mehr ausdetailliert zu bekommen, soweit, dass eine Umsetzung möglich wird.

      Klar wäre es super, direkt eine ordentliche Organisationsstruktur zu haben. Aber selbst wenn das nicht der Fall ist, will man ja irgendwann mal loslegen.

      The post was edited 1 time, last by aehxy ().