Es ist eine bekannte Tatsache, dass IT-Projekte mit einer alarmierenden Rate scheitern (einige Umfragen legen nahe, dass die Ausfallrate mehr als 60% beträgt). In der Regel versuchen Projektmanager, sich von diesen Fehlern zu "erholen", indem sie entweder ihre Ressourcen auf zusätzliche Stunden reduzieren oder die Qualität der Ergebnisse beeinträchtigen (den Testaufwand verringern, den Umfang reduzieren usw.). Leider wird die Softwarequalität von den Geschäftsführern nicht als sehr wichtig erachtet.
Ich frage mich, ob das auch für andere Berufe gilt? Wie werden Projekte zum Beispiel in der Bauindustrie gehandhabt, wo die Kosten für Ausfälle sehr hoch sind und wo ein einzelner Fehler katastrophal sein kann? Mega-Engineering-Projekte wie die Eurotunnel- und Petronas-Türme erforderten die Errichtung von Tausenden von Menschen und Milliarden von Dollar, und dennoch wurden die meisten dieser Projekte erfolgreich innerhalb oder manchmal sogar früher abgeschlossen.
Können wir etwas darüber lernen, wie Projekte in anderen Branchen geplant und verwaltet werden?
Nehmen wir eine Brücke als Beispiel und vergleichen Sie sie mit Software.
Die Brücke wird weniger externe Spezifikationen haben. Es wird einige ziemlich genaue Spezifikationen haben, aber viele davon werden intern sein (wie Materialstärken).
Es wird von Leuten entworfen, die wissen, dass das Brückendesign nicht übermäßig schnell sein soll. Im Allgemeinen erhalten Bauingenieure mehr Respekt von ihrem Management als Softwareentwickler. Die Bauingenieure werden außerdem in einem viel eingeschränkteren Problembereich arbeiten. Es gibt nicht annähernd so viele Möglichkeiten, eine Brücke als ein Inventarsystem zu erstellen.
Wenn das Design fertig ist, werden sich ein oder mehrere lizenzierte professionelle Techniker darauf abmelden. Dies bedeutet echte Verantwortung zu übernehmen. (Alternativ wird kein PE seine Lizenz auf seine Solidität setzen, und das Design wird nirgendwohin gehen.) Dies geschieht nicht in Software, teilweise weil der Problembereich so unbeschränkt ist.
Endlich wird die Brücke gebaut, und das wird Monate dauern und viel schweres Gerät. Software wird zunächst mit einem Compiler erstellt und mit billigen Werkzeugen unbegrenzt reproduziert. Es gibt hier eine große psychologische Bedeutung: Menschen neigen dazu, Projekte so zu betrachten, als hätten sie ein signifikantes Design und bedeutende Herstellungsschritte, und wenn die Herstellung zu trivial ist, neigen sie dazu, einen Teil des Designs als Fertigung zu betrachten.
Wenn Software eher wie Bauingenieurwesen wäre, würden wir für die meisten Dinge Standardverfahren benötigen, die angemessen und zuverlässig sind. Wir würden Ingenieure brauchen, um diese Praktiken zu studieren und bereit zu sein, zu zertifizieren, dass Software entweder richtig entworfen wurde oder nicht, und in der Tat müssten wir Projekte, die nach diesen Praktiken durchgeführt wurden, fast vollständig zuverlässig machen. Wir würden dort mehr formelle Verantwortung übernehmen müssen. Wir würden mehr externen Respekt brauchen, weil Manager, die es nicht wagen werden, ein $ 10 Millionen Bauprojekt durch Einmischung wegzuwerfen, oft keine Bedenken haben, ein $ 20 Millionen Software-Projekt zu verpfuschen.
Kurz gesagt, Software ist zu unausgereift, um als Bauingenieur zu arbeiten.
Ich denke, der größte Unterschied besteht darin, dass sie nie in Betracht ziehen würden, ein Projekt mit den gleichen schäbigen Anforderungen zu starten, die wir bekommen. Vielleicht sollten wir damit aufhören und die Leute zwingen, wirklich zu definieren, was sie wollen, bevor wir anfangen, es zu programmieren.
wollte ich, dass wir als Branche auf einen lausigen Job hinzuzufügen drängt zurück mit einem neuen Zeitplan und Budget, wenn die Anforderungen (wie sie sind) ändern. Wir begannen hier viel mehr von dieser Push-Back zu tun, den Kunden zu sagen, wie viele Stunden (und mehr Geld) die angeforderte Änderung würde, und fügte hinzu, die beiden zusätzlichen Tage, die die exisitng Frist zu tun und macht sie in einem Antrag auf Änderung formell gestellt . Die Anzahl der angeforderten Änderungen an den anfänglichen Anforderungen sank drastisch, sobald wir darauf bestanden, dass Kosten für die Änderung anfallen würden. Diese Änderung bewegte auch uns von einer Kostenstelle zu einem Profit Center in der Gesellschaft, wie wir eine Menge zusätzlicher Arbeit taten, aber den Kunden nicht mehr als die anfängliche Schätzung geladen wird.
Eine Lektion, die man aus dem Ingenieurwesen lernen kann: respektiere die nicht-funktionalen Anforderungen .
Funktionale Anforderungen sind schwer genug, da sie erwarten, dass die Benutzer, Entwickler, Analysten und alle anderen Beteiligten in der Lage sind, zu definieren, was für ein Geschäft erforderlich ist.
Nicht-funktionale Anforderungen sind die Dinge, die Ingenieure und technische Leute erwarten, für die funktionale Menschen blind sein können. Es ist sehr einfach, die Nichtfunktionalen zu übersehen oder herunterzuspielen. Einige PMs, mit denen ich in der Vergangenheit zusammengearbeitet habe, wollten nichts von Nicht-Funktionalen hören, weil sie nicht direkt an geschäftliche Bedürfnisse gebunden sein konnten und Aufgaben eingeführt wurden, die die Kriterien "pünktlich und im Budget" bedrohten.
>Beispiel
Funktionale Anforderung : Das Luxusschiff muss X Passagiere transportieren können
Nichtfunktionale Anforderung : Schiff, das groß genug ist, um X zu befördern Anzahl der Passagiere muss Y-Einheiten dick sein, um die Integrität auch bei Aufprall auf Eisberge aufrechtzuerhalten
Zählen der Kosten
Warum beachten Software-PMs nicht-funktionale Anforderungen? Denn die Kosten für eine solche Respektlosigkeit sind für das Engineering anders als für die Softwareentwicklung.
Kosten der Missachtung nicht funktionaler Anforderungen in meinem Schiffsbeispiel : Verlust des Lebens.
Kosten für die Nichtberücksichtigung von Nichtfunktionals in der Software : etwas Schwaches, was technische Schulden genannt werden, die später von Leuten bezahlt werden, die lange vom Projektteam entfernt sind, und die Abschlussboni des Projektteams.
Zugegeben, meine Beispiele sind simpel. Nicht alle technischen Schwächen führen zum Tod, während einige fehlerhafte Software sicherlich können (Avionik, medizinische oder Verkehrskontrollsysteme sind ein paar Beispiele). Aber ich denke, Sie haben die Idee.
Es gibt einen Unterschied zwischen Softwareentwicklung und Konstruktion oder Bauindustrie - eine Spezifikation kann immer geändert werden.
Auf dem Wasser gehen und sich entwickeln Software aus einer Spezifikation ist einfach wenn beide eingefroren sind.
- Edward V Berard ( von hier )
Zu Beginn des " Extreme Programming Applied finden Sie detailliertere Erläuterungen zu den Unterschieden im Projektmanagementansatz > "Buch.
Tags und Links project-management