Ich sehe eine Reihe ähnlicher Links, aber keiner scheint eine Lösung zu haben, meistens "das sollten sie nicht tun". Ich stimme zu, aber bitte lesen Sie weiter:
Szenario: 800.000 Seiten Dokumente, Erzählung (z. B. E-Mails)/Kontoauszüge/Recht (z. B. Optionsvereinbarungen). Wir sind ein kleines Team mit nur 2 Ermittlern (von denen einer hauptsächlich für die Produktion verantwortlich ist), 1 Finanzperson und 1 juristische Person (zusammen mit einigen Verwaltungsassistenten und externen Spezialisten). Wir haben mehrere laufende Projekte (denken Sie an verschiedene Fälle in verschiedenen Gerichten in verschiedenen Ländern).
Die Sache ist die, dass die 800.000 Seiten an Dokumenten noch nicht vollständig überprüft wurden (zu diesem Zeitpunkt vielleicht 50 %). Also entscheiden wir uns für ein Arbeitsprodukt (Montag; Person 1 erledigt x bis Freitag), aber am Dienstagnachmittag haben wir unweigerlich einige zusätzliche Unterlagen aufgedeckt.
Zu oft verändert diese Dokumentation die ganze Geschichte, verändert den Blickwinkel, den wir brauchen, um darauf zu kommen, verändert die Beziehungen. Bis Dienstagnachmittag fordern die verschiedenen Rechtsteams (die wenig Nachforschungen anstellen) verschiedene Arbeitsergebnisse in Bezug auf diesen neuen Fund an. Mein Ermittler/Arbeitsprodukt-Champion hebt mit vollem Herzen ab, und (Sie haben es erraten) bevor es (allzu oft) erledigt ist, haben wir noch mehr Informationen, die Dinge ändern oder eine Weiterleitung verursachen. Es ist Wahnsinn.
Wir verarbeiten manchmal 2-3.000 Seiten/Tag. Sie können also sehen, wie selbst ein paar Bomben darin Chaos wie kein Morgen verursachen, und doch machen sie tatsächlich weniger als 1 % der gesamten Dokumente aus.
Wie sollen wir damit umgehen? Zwingen Sie eine Woche durch, um zu beenden, was wir begonnen haben? Was ist, wenn es nutzlos oder falsch ist? Mit der Produktion warten, bis die Untersuchung abgeschlossen ist? Meistens folgt es einem bestimmten Thread, der selbst zu neuen Enthüllungen führt, UND wir haben Verjährungsfristen für die Einreichung dieses und jenes. Mehr Personal einstellen? Es würde Monate dauern, bis sie genug Traktion erlangten, um nützlich zu sein, und raten Sie mal, wer sie trainieren müsste?
Wir haben es mit Kanban versucht – die Tafeln waren innerhalb von ein oder zwei Wochen voller Unsinn. Eine "Überholspur" mit hoher Priorität zu haben, war eine gute Idee ... bis sie es nicht war. Ein Burndown-Diagramm sieht aus wie ein Plateau, nachdem Sie sich um zusätzliche Aufgaben gekümmert haben und wie viele unvollendet geblieben sind ... Der Kunde (und eigentlich der Product Owner) möchte, dass jemand diesen verrückten (mit freundlichen Grüßen) verwaltet, aber er möchte seine nicht wirklich ändern Gewohnheiten (die meistens papierbasiert sind ... habe ich erwähnt, dass wir all diese Dokumente drucken und manuell überprüfen??)
Alle Ratschläge und Perspektiven dazu (insbesondere mit Modellen oder Beispielen oder tatsächlichen "Do this" -Vorschlägen) sind sehr, sehr geschätzt.
TL;DR: Das Management will mehr Kontrolle, mehr Arbeitsprodukt, mehr Wert pro $.
Die Mitarbeiter möchten die ständige Nacharbeit vermeiden, eine Vorstellung von der Gesamtstrategie haben und sehen, wie ihr Arbeitsprodukt tatsächlich versendet wird
Ich möchte zeigen, dass sich die beiden oben genannten nicht gegenseitig ausschließen und dass es eine Möglichkeit gibt, diese Bedürfnisse gut miteinander zu verbinden, ohne den Arbeitsablauf stark zu bremsen, Meetings zu verschwenden usw. Ich kann sehen, dass diese drei Wünsche vernünftig sind und rational, aber es gibt gerade einen ernsthaften Grind zwischen ihnen..
Mein erster Schritt wäre zu fragen, wie Sie Kanban machen?
Kanban ist das Go-to-Tool für sich schnell ändernde Anforderungen. Das Grundprinzip „Habe ein Board, habe ein WIP, priorisiere täglich“ ist unglaublich einfach. Kanban ist jedoch wirklich schwer gut zu machen. Aus diesem Grund starte ich neue Teams fast immer zuerst mit Scrum, damit sie anfangen können, die Grundlagen agiler Vorgehensweisen zu erlernen.
Eine Sache, nach der es sich anhört, ist ein Aussortieren des „Rückstands“ oder der Anforderungen. Wenn sich die Dinge ändern, wenn Sie etwas Neues entdecken, müssen Sie fragen, ob der vorhandene Rückstand noch gültig ist. Bei einem normalen Softwareprojekt coache ich Teams, dass alles, was älter als 6-12 Monate ist, entfernt werden sollte. Wenn es wichtig war, wird es noch einmal erwähnt. Für Ihr Projekt würde ich sagen, dass mehr als ein Monat alt ist, um entfernt zu werden.
Zweitens ist die Klarheit Ihres Backlogs oder Ihrer User Stories. Sie müssen immer fragen: "Für wen ist das?" und "Warum interessiert es sie?". Wir tappen sehr schnell in die Falle zu sagen „Ich brauche einen Bohrer!“, wenn wir in Wirklichkeit ein 1/2 Loch in einem Stück Holz brauchen. Ein Bohrer ist nur der gebräuchlichste Weg, um dieses Loch zu bekommen.
Ich würde Ihnen raten, zu Kanban als Basis zurückzukehren. Denken Sie an die rigorose Aussortierung des Rückstands und die Klarheit des Rückstands. Wenn Sie auf ein Problem stoßen, führen Sie eine „Fünf-Warum“-Analyse des Problems durch und behalten Sie immer Ihren Benutzer im Auge.
Ich denke, die einfache Aussage Ihres Problems ist, dass Sie zum Planen zumindest in der Lage sein müssen, die Anzahl der Dinge zu zählen, die Sie tun müssen. Sie haben jedoch derzeit keine Basisnummer außer 800.000 und 50 %.
Ich denke auch, dass Sie versuchen, Projektmanagement auf etwas anzuwenden, das nach Prozessmanagement klingt. Vielleicht ist es ein bisschen von beidem. Ich vermute.
Wenn Sie mehr Leute brauchen, wird der Verantwortliche fragen, wie viele und Sie haben keine Ahnung. Völlig verständlich, aber Sie müssen in der Lage sein, vernünftig nach etwas zu fragen.
Werkzeuge: Die alten Stand-by-Werkzeuge wie der „Parkplatz“ oder die Problemliste kommen einem in den Sinn. Google-Tabellenkalkulationen sind ein großartiges Tool, um diese mit geringen Investitionen in die Einrichtung von etwas Besserem zu verwalten. Es ist immer noch ein Alptraum für Tabellenkalkulationen, aber die Zusammenarbeit funktioniert sofort und ist kostenlos. Sie müssen Probleme protokollieren, priorisieren und die höheren Prioritäten bearbeiten. Sie müssen Spalten für Fälle, Gerichte usw. haben, damit Sie die Dinge in einen Eimer packen können.
Option eins, schätzen Sie die Basis ein: Angesichts der Dringlichkeit, die Sie auszudrücken scheinen, würde ich mit dieser gehen.
Im Moment haben Sie vielleicht eine zumindest anekdotische Vorstellung davon, wie viele nachfolgende Ermittlungen stattfinden, wenn Sie beispielsweise eine 100-seitige Fallakte durchsehen. Konzentrieren Sie sich nicht darauf, dass diese Zahl perfekt ist. Denken Sie am besten, in der Mitte, am schlechtesten. Normalerweise haben Teams am Ende das schlechteste Plus, BTW. Geh damit. Also 200 Fälle, 50 sind am besten, 75 sind mittel, 75 sind am schlechtesten. Das sollte Personenstunden entsprechen.
Option zwei – bessere Schätzung: Lassen Sie mindestens eine Person die letzten 50 % der Dokumente durcharbeiten. Seiten lesen, Probleme protokollieren und weitermachen. Das gibt Ihnen eine Zählung der, sagen wir, "Tier-1"-Probleme. Ihr Team kann wahrscheinlich leichter abschätzen, wie viele untergeordnete Probleme von jedem dieser Typen auftreten werden.
Gehen Sie vor: Jedes Mal, wenn Sie einen neuen Fall erhalten, muss dieser gesichtet werden, damit Sie ihm eine anfängliche Arbeitsbelastung zuweisen können.
Also im Rückblick: a.) Strukturieren Sie Ihr Issue / Work Tracking mit einem supereinfachen Tool b.) Schätzen Sie die Arbeit mit einem Best-, Middle-, Worst-Case-Modell ab und leiten Sie daraus die benötigten Leute ab c.) Bestimmen Sie, ob Sie mehr Leute brauchen und wie lange, das wird dauern d.) Gehen Sie vorwärts, sortieren Sie alles Neue, fügen Sie es der Arbeitsbelastung hinzu, passen Sie die Arbeit, die Zeitplanung und andere Prioritäten von dort an an.
Das sind meine Ideen, wenn man bedenkt, was Sie mir gesagt haben. Entschuldigung, wenn das ein riesiges "duh" ist.
Agile Methoden sind darauf ausgelegt, mit sich ändernden Geschäftsrealitäten fertig zu werden. Nicht wie allgemein gesagt wechselnde Anforderungen.
Es ist ein subtiler Unterschied, aber einer, der mir in Ihrem Fall wichtig erscheint.
Ein Wasserfallansatz wäre, alle Dokumente zu sammeln (einen Plan zu erstellen), bevor man mit der Arbeit beginnt (den Plan umsetzt).
Das Risiko im Geschäft mit diesem Ansatz, den Agile anspricht, besteht darin, dass während der Umsetzung oder späteren Planungsstadien etwas in der realen Welt geschieht, was den Plan ungültig macht. Nehmen wir an, ein Deal scheitert oder ein neuer Markt öffnet sich und somit scheitert das ganze Projekt.
Agile adressiert dies, indem kleine Bits schnell erledigt werden. Aber jedes Bit liefert einen Wert, weil der Zustand der Welt zu diesem Zeitpunkt bekannt ist. Sie können deutlich sehen, ob die Arbeit richtig ist oder nicht. Wenn sich später etwas ändert, verliert die Arbeit möglicherweise an Wert, aber das Tempo der Veränderung wird durch Ereignisse in der realen Welt bestimmt. Ereignisse, die nicht planbar sind.
In Ihrer Situation passieren die Änderungen jedoch in dem Tempo, in dem Sie die Dokumente lesen und verstehen. Eine bekannte Aufgabe, die vor dem Ende des Projekts abgeschlossen wird.
Ein kleines bisschen Arbeit bringt Ihnen also keinen Wert, wenn es falsch ist, Sie werden bis zum Ende nicht wissen, ob es richtig ist und möglicherweise einen NEGATIVEN Wert hat!
Für Sie ist Agile ein risikoreicher Ansatz. Im Wesentlichen darauf zu setzen, dass sich glücklicherweise mehr Bits als richtig herausstellen, als die Zeit, die Sie damit verbringen, die falschen zu reparieren.
Ich würde vorschlagen, dass Sie zuerst die gesamte Dokumentation lesen und dann die Arbeit erledigen.
Dies ist möglicherweise keine reine agile Empfehlung. Aber ausgehend von Ihrem Problem würde ich Folgendes für diese völlig dynamische Umgebung vorschlagen.
Ich habe den Eindruck, dass Sie mehr Struktur in Ihrem Projekt brauchen. Strukturieren Sie es in:
Unterprojekte, zB:
Projektphasen, z
verschiedene Prototypen
Für jedes Teilprojekt müssen Sie einen Projektauftrag erstellen, der die Ziele und Nichtziele dieses Teils klar definiert.
Gerade die ersten Prototypen müssen nicht alle Anforderungen erfüllen. Sie könnten zum Beispiel wie folgt definieren:
Prototypen:
Der Vorteil dabei ist, dass Sie für die ersten Samples mit einer sehr begrenzten Anzahl von Basisanforderungen arbeiten können. Diese Anforderungen sollten ziemlich robust sein und sich nicht zu sehr mit der Zeit ändern. Sie können ein laufendes System erhalten, in dem Sie mehr erfahren können. Wenn Sie Ihren Sponsor davon überzeugen können, dass Sie auf dem richtigen Weg sind, können Sie Ihr Team für den Bau der ausgereifteren Prototypen aufstocken.
Aber der wichtigste Schritt ist zunächst, eine solche Struktur und die Entwicklungs-Roadmap zu generieren. Dies wird einen erheblichen Planungsaufwand bedeuten. Kommunizieren, diskutieren und stimmen Sie diesen Plan mit Ihrem Team und den anderen Stakeholdern ab. Es ist entscheidend, dass jeder weiß, was ihn wann erwartet.
Bearbeiten 1
Ich habe gerade gesehen, dass Sie Ihre Frage mit "agil" markiert haben. Mein Vorschlag ist nur ein klassischer PM-Ansatz. Vielleicht ist Agilität einfach nicht das richtige Werkzeug für Ihre Anforderung. Sie könnten agile Elemente in einigen Arbeitspaketen verwenden, aber ich habe Zweifel, dass Sie sich nur auf die agile Methodik für den gesamten Entwicklungspfad verlassen können.
Bearbeiten 2
Einige Anmerkungen zur Art der Anforderungen:
Bei der Materialbelastung ist mit widersprüchlichen Anforderungen zu rechnen. Besonders, wenn Sie die Nachfrage der Stakeholder berücksichtigen. Zum Beispiel: Man kann kein perfektes Auto bauen, das die Anforderungen aller Autokunden erfüllt. Der eine Kunde will einen Ferarri Spider, der andere einen Volkswagen Multivan. Sie müssen entscheiden, welche Anforderungen erfüllt werden sollen.
Erwarten Sie nicht, dass Sie von Anfang an das richtige Design erstellen können. Dass jede Codezeile, jede Schraube und jeder Prozessor von Anfang an richtig gewählt ist. Die Produktentwicklung ist oft ein iterativer Prozess, sodass Sie Ihr Design mehrmals überarbeiten müssen.
Einige Anforderungen sind ziemlich robust. ZB gesetzliche Anforderungen. Manche schweben mehr. Versuchen Sie zunächst mit den robusten Anforderungen zu beginnen.
Wenn Sie die ersten Prototypen haben, wird dies die Anforderungen Ihrer Stakeholder beeinflussen. Vielleicht hat ein Stakeholder ein Problem A und fordert daher als absolutes Muss die Lösung X umzusetzen. Wenn Sie jedoch Ihr Produkt entwerfen, finden Sie möglicherweise eine elegantere Lösung Y für Problem A, an die der Stakeholder nicht gedacht hat. Wenn der Stakeholder Y sieht, ändert er möglicherweise seine Meinung und X ist kein Muss mehr. Der Schlüssel liegt darin, die Probleme der Beteiligten zu verstehen und Lösungen zu finden, anstatt zu versuchen, jede gewünschte Funktion zu implementieren.
Bearbeiten 3
Das Scannen des Materials ist erstmal ok. Aber ich würde nicht versuchen, alle Anforderungen im ersten Durchlauf zu extrahieren. Ich würde versuchen, mir ein Bild davon zu machen, was in den einzelnen Abschnitten Ihres Materials ungefähr behandelt wird.
Ich würde anfangen, einen Teil des Papiers zu scannen und dann entscheiden, entweder:
"In diesem Kapitel scheinen die größten Herausforderungen für mein Konzept zu liegen. Ich werde diese Lösungen in einer frühen Phase untersuchen und implementieren / Prototypen (Welche?)", ODER
"Dies scheint keine zu hohen Anforderungen zu sein. Ich kann mein Design in einer späteren Phase an diese Anforderungen anpassen."
dKen
Joel Bancroft-Connors
dKen
Apalala
Gryph
Apalala
Venture2099
Gryph
Venture2099
Gryph
Gryph
Venture2099