Ich befinde mich in einer misslichen Lage. Ich bin ein Entwickler und mir wurde die Entwicklungsarbeit für ein Projekt übertragen, das einen Papier-Workflow in einen elektronischen Workflow umwandelt. Das kleine Unternehmen, für das ich arbeite (ca. 200 Mitarbeiter), legt großen Wert auf „Lean Culture“ und fördert den Input von Arbeitnehmern auf allen Ebenen. Ich habe gemischte Meinungen darüber gehört, ob Input tatsächlich unterhalb der Managementebene gesammelt wird, also fühlt sich dieses Projekt vielleicht deshalb unangenehm an.
Einige Hintergrundinformationen: Derzeit werden Bestellungen auf Papierbestellformularen an eine bestimmte Abteilung einer Abteilung gesendet. Der Bereichsleiter sortiert nach Priorität und weist die Aufträge den Bedienern in diesem Bereich auf der Grundlage ihrer Qualifikationen und aller anderen Details zu, die berücksichtigt werden müssen.
Der neue Prozess leitet Bestellungen über eine neue Webanwendung an diesen Abteilungsbereich weiter, anstatt dass der Bereichsleiter die Papierbestellformulare physisch sortiert und sie bestimmten Benutzern zur Bearbeitung übergibt. Die Anwendung enthält eine Logik zur Bestimmung der Priorität, und den Benutzern wird Arbeit basierend auf ihren Qualifikationen zugewiesen. Die Zuordnungslogik wird im Antrag enthalten sein, und Qualifikationen können vom Bereichsleiter geändert werden.
Ich bin besorgt über dieses Projekt, weil mir in gewisser Weise die Rolle des Projektmanagers übertragen wurde, indem ich für die Erfassung der Anforderungen verantwortlich bin. Meine Befugnisse sind jedoch begrenzt. Die Abteilungsleiter haben die meisten Anforderungen gestellt und mir gesagt, wen ich in die Besprechungen einbeziehen soll. Der Abteilungsleiter war an den Besprechungen beteiligt, aber ich habe das Gefühl, dass der Abteilungsleiter normalerweise bei Vorschlägen abgewiesen wird, wobei die Abteilungsleiter sagen, dass sie sicherstellen möchten, dass „die 95 % der Fälle, die unkompliziert und vorhersehbar sind, von behandelt werden die Anwendung". Ich weiß nicht, woher die 95 % der unkomplizierten Fälle kommen, und ich weiß nicht, wie sie feststellen, dass die Punkte, die der Abteilungsleiter vorbringt, außerhalb dieser "95 %" liegen.
Der Abteilungsleiter ist der einzige Benutzer der Anwendung, der beauftragt wurde. Keiner der Betreiber wurde engagiert. Um auf die detaillierten Anforderungen einzugehen, fanden gerade Besprechungen mit Entwicklern und dem Leiter der IT-Abteilung statt (der zwar über ein breites Wissen über Prozesse verfügt, aber wahrscheinlich nicht genug, damit die meisten Anforderungen vom Leiter der IT-Abteilung kommen). Mit den Abteilungsleitern und dem Abteilungsleiter für die Abteilung der Abteilung, auf die sich dies auswirkt, wurden Folge- und Klärungstreffen abgehalten.
Ich habe den Leiter der IT-Abteilung gefragt, ob ich den Bereichsleiter und die Benutzer beschatten könnte, um den aktuellen Prozess besser zu verstehen, und er erlaubt es mir widerwillig, wollte aber sicherstellen, dass ich es verstehe und dem Bereichsleiter das Verständnis weitergeben, dass wir " nur auf die 95% konzentriert". Ich habe das Gefühl, dass jede Eingabe, die ich vom Bereichsleiter und den Benutzern erhalte, abgeschossen wird, weil die ganze 95%-Sache sehr willkürlich erscheint.
Ich möchte, dass dieses Projekt erfolgreich ist, und ich möchte nicht, dass die Benutzer oder der Abteilungsleiter das Gefühl haben, dass sie gezwungen sind, eine neue Anwendung zu verwenden, die ihre Anforderungen nicht effektiv erfüllt. Wie kann ich die Abteilungsleiter am effektivsten davon überzeugen, dass die von den Benutzern angegebenen Bedürfnisse wichtig genug sind, um in die Anforderungen aufgenommen zu werden? Ich habe auch das Gefühl, dass ich Gefahr laufe, den Abteilungsleiter und die Abteilungsleiter zu enttäuschen und/oder Konflikte zwischen ihnen zu verursachen, wenn es mir nicht gelingt, die Nachricht vom IT-Abteilungsleiter an den Abteilungsleiter weiterzuleiten, dass das Shadowing keine Garantie dafür ist, dass der Input I erhalten wird in die "95% der einfachen Fälle" fallen und es in die Anforderungen schaffen.
Das Sammeln von Anforderungen von Benutzern ist nicht nur eine Anforderung an sich, um das Risiko zu minimieren, ein Produkt zu entwickeln, das nicht funktioniert, sondern Sie erhöhen auch Ihr Risiko in Bezug auf Änderungsresistenz. Widerstand tritt sekundär zu einer Änderung selbst auf, unabhängig davon, ob das Produkt für sie funktioniert oder nicht, aber wenn das Produkt nicht funktioniert, verschärfen Sie den Widerstand und verlieren die Glaubwürdigkeit für die Korrekturen.
Ich vermute, dass der Lead versucht, Kosten und Verzögerungen zu minimieren, die auftreten können, wenn sich die Benutzer verloben, oft aufgrund von Meinungsverschiedenheiten, Machtkämpfen, Politik usw. Aber das läuft auf eine Art Bezahlung jetzt oder später und auf die Bezahlung hinaus später wird die 10-fache Menge.
Die 95%-Sache ist ein Ablenkungsmanöver. Sie können es nicht messen und haben keinen wirklichen Einfluss darauf, wie die Benutzer das Produkt annehmen werden. Diese Art des Denkens ist ein großes Risiko für Ihren Erfolg, da „Finish“ willkürlich ist.
Meine Empfehlung ist, die Risiken zu eskalieren, die Ihnen Ihre Intuition sagt, und, wenn Sie dazu in der Lage sind, das Projekt zu stoppen, bis alle mit einer bewährten Methode der Anwendungsentwicklung an Bord kommen können.
Vicky Laidler
Bart van Ingen-Schenau
Puh