Haftungsausschluss: Heute werden wir nur über erfolglose Projekte sprechen, daher werden wir keine Namen, Passwörter und Besucherzahlen nennen.
Alle fehlgeschlagenen Fälle aus der Erfahrung von mir und meinem Freund können je nach Problemquelle in drei Typen unterteilt werden:
1. Arbeiten mit Stakeholdern
Der Grund für viele Projektprobleme ist, dass wir den Kunden nicht hören oder hören. Dies ist besonders zu Beginn besonders wichtig, wenn die Gefahr besteht, dass die Antwort auf die Frage "Warum wird das Projekt initiiert?" Verpasst wird.
Fall 1
Wir standen vor einer einfachen Aufgabe - alle möglichen Finanztransaktionen im Rahmen von Verträgen zu blockieren, die nicht im Unternehmen vereinbart wurden. Wir haben die Auswirkungen berechnet und, wie es uns schien, alle Risiken bearbeitet. Während der Diskussion argumentierte der Hauptbenutzer jedoch, dass dies nicht funktionieren würde: "Wir werden einen Produktionsprozess haben." Es klang wie eine Ausrede, und der Hauptkunde bestätigte unsere Hypothese und bestand darauf, es einfach zu tun.
Am X-Day haben wir die Funktionalität gemäß unseren Plänen gestartet, und ungefähr anderthalb Stunden später rief unser Hauptkunde, nicht sehr gut gelaunt, an und bat darum, alles zurückzusetzen: „Es funktioniert nicht!“.
Wie war es notwendig?Hören Sie auf die Anliegen des Benutzers, der die Besonderheiten der Organisation von innen kennt, und erarbeiten Sie diese Risiken. Es gibt immer die Möglichkeit, Optionen zu finden, die für jeden geeignet sind.
Fall 2
Es war ein funktionierender Kunde, der die Aufgabe und das System, die wir konzipiert hatten, perfekt verstand. Wir haben jedoch das Interesse der IT-Abteilung an der Umsetzung dieses Projekts nicht berücksichtigt und sind ziemlich spät zu ihnen gekommen: in der Phase der Entwicklung der Architektur. Ich musste das Projekt überarbeiten und die Frist für die Lieferung verschieben. Wir haben Zeit, Geld und Ansehen verloren, indem wir den Einfluss und die Fähigkeiten eines funktionierenden Kunden überschätzt und die internen Beziehungen zwischen den Abteilungen eines großen Unternehmens unterschätzt haben.
Wie war es notwendig? Alle Beteiligten von Anfang an in die Arbeit am Projekt einzubeziehen und ihre Interessen trotz der Zusicherungen des Kunden zu berücksichtigen.
Fall 3
Und dies war ein Fall, der fast erfolglos wurde. Der funktionale Kunde, vertreten durch den CEO, wollte die Kostenrechnungsmethode ändern, und nach allen Berechnungen hätte der Effekt der Änderungen erheblich sein müssen. Das Team aus dem Finanzblock war bereit für Änderungen, und als die Aufgabe die IT-Analysten erreichte, war die Entscheidung bereits getroffen. Und hier haben wir das Richtige getan und gefragt: Warum? Wie wird es funktionieren? Wer wird den Prozess unterstützen? Wie haben Sie den Effekt bewertet?
Infolgedessen wurde der Effekt unter Berücksichtigung von Änderungen im ERP-System und der Kosten für die Wartung des Prozesses und des Tools neu berechnet. Der Effekt „verschwand“ nicht nur im Geld, sondern es wurden auch zusätzliche Risiken entdeckt. Das Projekt wurde abgeschlossen, und für Mitarbeiter der internen Automatisierungsabteilung wurde es zur Regel, zu Beginn Fragen zu stellen, auch wenn die Aufgabe vom CEO kam.
Schlussfolgerungen
- Suchen Sie immer nach einem Grund, Zweck, Effekt. Argumentieren Sie Ihre Position. Wie ein Freund von mir (Klassenmanager) sagt: "Hören Sie zu, verkaufen Sie nicht ... Dann hören Sie noch einmal zu ... und verkaufen Sie erst dann";)
- Lebe eines Tages mit direkten Anwendern des Produkts und lerne ihre Routine im Detail kennen. Dies wird dazu beitragen, alle möglichen Nuancen zu antizipieren.
- Arbeiten Sie alle Risiken ab, die für Sie, den funktionalen Kunden und jede interessierte Person von Bedeutung sind. Achten Sie besonders auf die negativsten Kunden / Benutzer gegenüber dem Projekt. Sie wissen eindeutig etwas! ;)
- Verpassen Sie keinen einzigen Teilnehmer im Prozess. Es kann nicht ein Teilnehmer am Prozess teilnehmen, und die IT-Abteilung muss immer berücksichtigt werden!
2. Beschreibung der Anforderungen
Das Allerheiligste für jeden Analytiker ist eine Beschreibung der Anforderungen. Betrachten wir Fehler in diesem Bereich in den beiden anderen Fällen.
Fall 1
Eines der Entwicklungsteams erhielt ein Projekt, das überarbeitet werden musste. Das System wurde mit einer Dokumentation geliefert, in der die Beschreibung der Logik des Systems mithilfe von SQL-Abfragen geschrieben wurde. Zu Beginn der Arbeiten war das System bereits ernsthaft überarbeitet worden, und SQL-Abfragen waren nicht mehr relevant. Ich musste Zeit mit Reverse Engineering verbringen, um die Logik und Funktionalität des Systems zu verstehen.
Wie war es notwendig? Überprüfen Sie die Dokumente erneut auf Relevanz und Übereinstimmung mit dem Entwicklungsstand des Projekts. Besonders wenn es an andere Entwickler weitergegeben wird.
Fall 2
Es war ein interessantes Projekt, alle Prozesse innerhalb der Organisation zu automatisieren. Das Projekt umfasste 5 Systeme verschiedener Klassen, die miteinander integriert werden mussten, damit der Prozess ohne Unterbrechung fortgesetzt werden konnte. Das Team entwarf die Architektur der Lösung für ungefähr zwei Monate, als ich mit dem Projekt verbunden war.
Während der Kommunikation mit dem Kunden wurde mir klar, dass er es auf die eine und die Entwickler auf die andere Weise sieht. Dies waren die Mindestvereinbarungen in Worten, die das Projekt vollständig veränderten. Ich musste von vorne anfangen und alle Anforderungen von Grund auf durcharbeiten: Warum? Was? Wie?
Wie war es notwendig? Beschreiben Sie nicht nur klar die Anforderungen für die Implementierung von Prozessen und Teilprozessen (wie es funktionieren wird), sondern auch, wie das Endergebnis aussehen wird.
Schlussfolgerungen
Oft haben Teams Angst vor Kundenkommentaren und laufen, um sich zu entwickeln, wenn sie "gut, so ähnlich" hören. Wir können davon ausgehen, dass Sie mit dem Kunden nur dann eine gemeinsame Sprache gefunden haben, wenn er selbst begonnen hat, Anpassungen mit eigenen Händen vorzunehmen. Einige Leute finden es bequem, Texte zu lesen, andere haben Diagramme und wieder andere haben Schnittstellenlayouts. Es lohnt sich, alles auszuprobieren, bis Sie eine gemeinsame Sprache gefunden haben, auch wenn es sich um „Zeichnungen auf Servietten“ handelt.
3. Entwicklung einer Idee, eines Produkts oder einer Lösung
Dies sind Geschichten über das Produktmanagement, wenn die Idee den Geist überflutet und alles andere keine Rolle spielt.
Fall 1
Wir hatten ein großartiges Produkt zur Automatisierung von Routineaufgaben innerhalb eines Unternehmens: von der Eingabe von Informationen bis zur Beantwortung von Fragen von Mitarbeitern. Und alles war großartig: Wir haben die ersten Kunden gefunden, den Markt verstanden - es schien, als gäbe es dort viel Geld - wir haben ein paar Projekte gestartet und sie erfolgreich abgeschlossen. Und in diesem Moment öffneten wir unsere Augen: Niemand berechnete die Kosten für die Unterstützung der Lösung. Und es löschte alle möglichen Versuche, Geld auf Null zu verdienen.
Wie war es notwendig? Berechnen Sie sorgfältig alle Aspekte des Projekts: von der Entwicklung bis zur Lösungsunterstützung.
Fall 2
Eine andere Geschichte ist, als wir den Markt nicht erarbeitet haben. Es wurde eine Idee für ein gutes Produkt gefunden, das keine Konkurrenten auf dem Markt hatte, aber Kunden. Mindestens einer, und er war bereit zu zahlen und zu investieren. Wir sind in dieses Projekt eingestiegen und hatten keine theoretische Grundlage für die Entwicklung solcher Funktionen, aber wir haben es geschafft.
Und nachdem sie mit dem Produkt auf den Markt gekommen waren, stellten sie fest, dass es nicht umsonst war, dass es keine Wettbewerber gab. Viele Menschen vernachlässigen diese Funktion trotz aller garantierten Effekte.
Wie war es notwendig? Überlegen Sie, warum es in einem so profitablen Marktsektor keine Wettbewerber gibt, und gehen Sie der Wahrheit auf den Grund.
Schlussfolgerungen:
Überprüfen Sie die Realisierbarkeit des Projekts im Rahmen nicht eines Kunden, sondern der Wettbewerbsfähigkeit - entsprechend der aktuellen Marktsituation.
Kultur des Scheiterns
Um Schwierigkeiten zu überwinden und nicht wieder in sie verwickelt zu werden, müssen Sie einen Grund finden. Meistens liegt es in der Kultur des Scheiterns, die in Organisationen akzeptiert wird. Es gibt zwei schlechte Möglichkeiten, um auf Fehler in Organisationen zu reagieren:
- Verurteilung / Bestrafung
Wenn wir Fehler verurteilen, töten wir die Initiative. Mitarbeiter haben Angst, kreativ zu sein und nur sichere Entscheidungen zu treffen. Dies führt zu einer Stagnation im Unternehmen.
Lösung: Definieren Sie Grenzen für Fehler. Es ist notwendig, eine Ressource für die Manifestation von Initiativen zuzuweisen und diese an Kontrollpunkten zu überprüfen. Verfolgen Sie den Erfolg des Projekts anhand strenger Kriterien, die im Voraus vereinbart wurden. - Schweigen
Diese Taktik führt dazu, dass dieselben Fehler immer wieder wiederholt werden. Dies führt wiederum zum Verlust der Position des Unternehmens in den Augen von Kunden, Wettbewerbern und dem Markt.
Lösung: Aufbau eines Systems des Erfahrungsaustauschs zwischen Mitarbeitern. Die Diskussion möglicher Lösungen für Fehler führt letztendlich zu einer Methodik, die hilft, diese Fehler zu vermeiden.
Vernünftige Reflexion hilft bei der Entwicklung, aber dies ist kein Grund, sich nur mit Versagen zu umgeben. Achten Sie auf Ausgewogenheit, denn das Lernen aus erfolgreichen Projekten macht viel mehr Spaß