Erstellen Sie in sechs Schritten ein Proof of Concept

Heute initiieren Unternehmen Softwareprojekte schneller und komplexer als je zuvor. Die Unternehmensressourcen sind begrenzt und neue Initiativen können kostspielig sein, und genau hier helfen Proof-of-Concept-Projekte.

Um neue Initiativen zu testen und zu validieren, greifen IT-Teams zunehmend auf Proofs of Concept zurück. Wenn sie sinnvoll eingesetzt werden, verfeinert ein Proof of Concept Ideen, deckt Probleme auf, weckt die Kreativität und maximiert den Projekterfolg. Wenn Teams Kompromisse berücksichtigen und bestimmte Schritte umsetzen, können sie den Nutzen von Proof-of-Concept-Projekten steigern.

Was ist ein Proof of Concept?

In der IT ist ein Proof of Concept (PoC) – auch als Proof of Principle bekannt – ein eingeschränkter Machbarkeitsnachweis, der wesentliche Elemente eines vorgeschlagenen Technologieprojekts demonstriert, testet oder validiert. Das Projekt selbst könnte die Entwicklung und Bereitstellung neuer Software, das Hinzufügen oder Ersetzen von Hardware, das Ausprobieren eines neuen Geschäftsdienstes oder sogar die Änderung von Geschäftsabläufen oder Plattformen sein.

Erfolgreiche PoCs ermitteln wichtige Informationen:

• Benutzerakzeptanz: Mit PoCs werden Benutzerakzeptanz und Feedback gesammelt. Die Ergebnisse können auf neue Funktionen oder wichtige Änderungen hinweisen, die die Akzeptanz erhöhen und die Wettbewerbsfähigkeit und den Marktanteil des Produkts steigern.
• Betrieb/Methoden: Ein Unternehmen, das eine neue Software entwickelt, möchte vielleicht neue Methoden ausprobieren. Im Rahmen von PoC-Projekten werden der Funktionscode und die Hardwareinfrastruktur in begrenztem Umfang prototypisch getestet. Beispielsweise um neue Methoden zu validieren, die Sicherheit zu gewährleisten, die Leistung zu bewerten und praktische Pläne für die Skalierbarkeit zu formulieren.
• Kompatibilität/Interoperabilität: Ein Unternehmen, das eine Aktualisierung der Unternehmenssoftware plant, kann einen PoC durchführen, um sicherzustellen, dass die neue Plattform mit der aktuellen Infrastruktur zusammenarbeiten kann, um Ausnahmen zu ermitteln, Abhilfemaßnahmen zu bestimmen und die Gesamtkompatibilität der neuen Komponente zu beurteilen.
• Leistung (Performance): Um die Leistung zu überprüfen, können Unternehmen PoCs nutzen. Beispielsweise testet ein PoC eine API und ihre Hardwareinfrastruktur unter simulierter Last, um die Leistung zu validieren, oder den Ersatz eines veralteten Servers bewerten, um sicherzustellen, dass geschäftskritische Arbeitslasten auf dem neuen Server angemessen ausgeführt werden.
• Workflows: Um die Verfügbarkeit des Anbieters zu überprüfen, die Funktionalität von Backups und Wiederherstellungen zu testen und wichtige Informationen zu sammeln, kann ein Unternehmen, das die Implementierung eines neuen Workflows plant, einen PoC durchführen.

Vorteile des Proof of Concepts

PoCs sind für alle Elemente des Unternehmens nützlich: Benutzer, Interessengruppen, Investoren und das Projektteam. Ein gut durchdachtes PoC bringt eine Reihe von Vorteilen:

Risikominimierung

Die Kosten für moderne IT-Projekte haben viele Unternehmen risikoscheu gemacht. Es ist einfacher, Geld auszugeben, wenn die Erfolgserwartung hoch ist. PoCs stellen sicher, dass ein Projekt erfolgreich sein wird, bevor es tatsächlich in Angriff genommen wird. Das kann Unternehmensleitern helfen, die Investition in unternehmenskritische oder risikoreiche Projekte zu rechtfertigen.

Frühzeitige Rückmeldung und Neuausrichtung

Einige PoC-Ergebnisse weisen darauf hin, dass das vorgeschlagene Projekt Probleme aufweist. Das bietet die Möglichkeit, diese zu beheben, bevor erhebliche Ressourcen in das gesamte Projekt investiert werden. Wenn das Projekt nicht mehr zu retten ist, können die Teams es deaktivieren, es auf einen neuen PoC umleiten oder ganz aufgeben.

Erkennen neuer Möglichkeiten

PoC-Projekte können zu Innovationen führen. Beispielsweise kann die Evaluierung einer neuen Softwarefunktion dazu führen, dass die Implementierung der Funktion völlig neu überdacht wird. Einige PoCs demonstrieren neue Technologien und Prototypen, die für Investorengespräche wertvoll sein können, zum Beispiel um das Budget für eine neue Technologieinitiative zu sichern.

Nachteile von Proof of Concepts

Bei allen potenziellen Vorteilen bringen PoC-Bemühungen auch mögliche Nachteile mit sich:

Kosten

PoC-Projekte kosten Personalzeit, die von anderen Projekten abgezogen wird, sowie den damit verbundenen Support und den Kauf von Tools und Cloud-Ressourcen. PoC-Kosten sind ein Faktor, den das Unternehmen einkalkulieren muss, auch wenn sie nur einen Bruchteil der Kosten eines vollständig realisierten IT-Projekts ausmachen.

Einschränkung der Kreativität

Stakeholder und PoC-Teammitglieder tappen leicht in die Falle, nur den PoC zu unterstützen. X ist das, was wir sehen wollen, also ist X das einzige, was wir diskutieren werden. Durch solche Einschränkungen werden wertvolle Gelegenheiten für Kreativität verschenkt.

Umfangserweiterung

Wenn sich die Projekte als Reaktion auf neue und unerwartete Anforderungen der Interessengruppen weiterentwickelt, kann es bei PoC-Projekten zu einer schleichenden Ausweitung des Umfangs kommen. Die Ausweitung des Umfangs verschiebt die Zielvorgaben für den Abschluss von PoC-Projekten und führt zu einem höheren Ressourcenverbrauch als erwartet.

Schritte für ein erfolgreiches PoC-Projekt

In der Regel umfassen PoC-Initiativen sechs gemeinsame Schritte:

1. Rechtfertigung

Der erste Schritt in jedem PoC-Ansatz besteht darin, den Bedarf, die Zuweisung von Tools, Talenten und die erforderliche Zeit zu bestimmen. Einige Geschäfts- und IT-Führungskräfte können fragen, ob die Risiken eines Verzichts auf ein PoC größer sind als die erforderliche PoC-Investition.

2. Umfang

Der nächste Schritt konzentriert sich auf Ziele, spezifische Erfolgskriterien und Messgrößen, die das Team überprüfen und mit den Beteiligten teilen kann. Die Diskussionen über den Umfang konzentrieren sich auch auf den Aufbau eines funktionierenden PoC-Teams, das die richtigen Interessengruppen und technischen Mitarbeiter einbezieht.

3. Entwurf

Das ist die Phase der Projektplanung. Der PoC-Projektumfang wird in der Entwurfsphase in einen umsatzbaren Plan umgewandelt, der überprüft, genehmigt, budgetiert, ausgeführt und bewertet werden kann. Oft ist die Entwurfsphase kurz, aber es ist wichtig, Interessengruppen und PoC-Teammitglieder einzubeziehen, um Vertrauen in den Plan zu entwickeln.

4. Ausführung

Das Team baut hier das PoC-Projekt auf und führt es in Übereinstimmung mit dem Projektplan durch. Das kann so einfach sein wie die Beauftragung eines Grafikdesigners mit der Erstellung von Attrappen oder so komplex wie die Einrichtung einer funktionalen Betriebsumgebung für eine umfassende Plattformbewertung. Je nach Umfang und Komplexität des PoC-Projekts kann eine Ausführungsphase zwischen Stunden und Wochen dauern.

5. Feedback

Die Ausführung erzeugt Feedback, das die Teams in dieser Phase zur Kurskorrektur nutzen können. Das Feedback von Nutzermeinungen, Metriken, Benchmarks und anderen Maßnahmen kann im PoC selbst behandelt werden. Auf diese Weise überarbeiten die Teammitglieder den Umfang und die Entwurfsschritte und nehmen Änderungen vor. Wenn beispielsweise eine neue Benutzeroberfläche oder eine Funktion für die Benutzer keinen Sinn ergibt, kann das Team das Design überarbeiten und neue Ergebnisse suchen.

6. Berichterstattung

Sobald der PoC abgeschlossen ist, werden die Ergebnisse und Testdaten präsentiert. Häufig umfasst die Berichterstattung Kosten- und Budgetdaten, die für die vollständige Projektimplementierung verwendet werden. Etwaige Bedenken oder Probleme werden diskutiert, was möglicherweise zu neuen oder alternativen PoC-Bemühungen führt. In der Regel nutzen die Stakeholder die abschließende Berichterstattung als Grundlage für die vollständige Projektplanung und -genehmigung. PoC-Misserfolge können zu einer erneuten Prüfung, Verzögerung oder Stornierung des Projekts führen.

Best Practices für Proof of Concepts

PoC-Projekte erfordern eine ordnungsgemäße Planung und Durchführung in einer kontrollierten Umgebung, die in der Regel vom Produktionsbetrieb getrennt ist. Daher gibt es bestimmte PoC Best Practices, die sorgfältig berücksichtigt werden müssen.

Die folgenden Best Practices gehören zu Software-PoCs:

• duplizierte Daten/Applikation: In der Regel ist moderne Software auf den Zugriff auf Geschäftsdaten angewiesen. Um den Betrieb zu gewährleisten, ohne die tatsächlichen Produktionsdaten zu berühren, benötigen PoCs doppelte Daten und sogar Softwareplattformen, wie zum Beispiel doppelte SQL- oder NoSQL-Datenbanken.
• duplizierte Infrastruktur: PoC-Software muss auf Servern installiert werden und benötigt Zugriff auf das Unternehmensnetzwerk. Damit der PoC-Netzwerkverkehr nicht mit dem Produktionsverkehr interagiert, muss die Infrastruktur dupliziert werden. Um die erforderlichen Umgebungselemente zu implementieren, verwenden Entwickler regelmäßig DevOps-Techniken oder arbeiten mit IT-Betriebsmitarbeitern zusammen.
• Anschaffung neuer Tools/Workflows: Neue Software erfordert neue Entwicklungs-, Test- und Bereitstellungs-Tools. Die Teams müssen diese Elemente als Voraussetzung erwerben und einsetzen.
• Verstehen von Metriken/KPIs: PoC-Planer müssen die Software-Metriken und -KPIs verstehen, die in das PoC-Projekt einfließen werden, und sicherstellen, dass alle Softwareinstrumente, die zur Messung und Dokumentation des Softwareverhaltens benötigt werden, vorhanden sind.

Auch für Hardware-PoCs gibt es eine Reihe von Best Practices:

• Verstehen der Systemanforderungen: Neue Unternehmenshardware kann bestimmte Anforderungen an Stromversorgung, Kühlung, Montage, Anschlüsse oder andere physische Anforderungen stellen. Die Teams sollten sicherstellen, dass die PoC-Bereitstellungsumgebung diese Anforderungen erfüllt.
• Verstehen der Umgebung: Neue Hardware dient einem bestimmten Zweck. Ein PoC stellt sicher, dass die neue Hardware testbar ist. Wenn das Unternehmen beispielsweise PoC auf einem PCIe-NVMe-Speichergerät testen möchte, muss ein nicht produktiver Server mit einer geeigneten internen Schnittstelle verfügbar sein, auf dem das neue Gerät installiert wird.
• Benchmark-Test: Um sich mit dem Hardwaremanagement vertraut zu machen, sollten die IT-Mitarbeiter die neue Hardware testen, sobald eine Betriebsumgebung eingerichtet ist. Testen Sie dann die Integration mit bestehenden Verwaltungsplattformen und anderen wichtigen Unternehmensanwendungen, um die Interoperabilität zu überprüfen. Schließlich sollte die Hardware auf Betrieb, Leistung und Zweckmäßigkeit geprüft werden.
• Sicherstellung der Hardwareisolierung: PoC-Tests sollten niemals mit dem Produktionsbetrieb in Kontakt kommen. Planen Sie daher eine duplizierte Hardwareinfrastruktur ein, die außerhalb der Produktion existiert: beispielsweise ein isoliertes Server-, Speicher- und Netzwerksegment.
• Verstehen der Benchmarks: Häufig wird wie bei Software-Metriken und -KPIs auch die Hardwareleistung durch softwarebasierte Benchmarking-Tools quantifiziert. Für Hardwaretests und -validierung sollten geeignete Benchmarking-Tools zur Verfügung stehen.

Nicht jede Best Practice gilt für jedes PoC. Wenn diese Faktoren im Vorfeld berücksichtigt werden, können PoC-Projekte jedoch effektiver sein.

Andere Validierungstechniken

PoCs sind nicht das einzige verfügbare Mittel zur Validierung. Zu den anderen Validierungstechniken gehören folgende:

• Ein Mockup ist ein nicht funktionsfähiges Muster eines geplanten Produkts zur Veranschaulichung von Ideen und Konzepten. Mockups können einfache Handzeichnungen oder grafische Renderings sein. Entwickler bilden eine neue Benutzeroberfläche in Form einer Reihe von Zeichnungen nach und holen das Feedback der Beteiligten ein, bevor sie mit dem Prototyp fortfahren oder Änderungen vornehmen.
• Prototypen sind erste Muster des geplanten Produkts, das Ideen und Konzepte demonstriert, bevor sie umgesetzt werden. Je nach Zweck des Prototyps oder der Reife des Projekts kann der Prototyp funktional oder nicht funktional sein. Prototypen sind auch ein wirksames Mittel, um Ideen auszutauschen und helfen oft, Akzeptanz, Fehler und Versäumnisse frühzeitig im Entwicklungszyklus zu erkennen.
• Minimal-funktionierende Produkte (Minimum Viable Products, MVPs) sind eine frühe Produkt-Iteration, die über genügend grundlegende Merkmale und Funktionen verfügt, um das Produkt zu demonstrieren, aber nicht alle geplanten Fähigkeiten enthält. MVPs sind eng mit iterativen oder kontinuierlichen Entwicklungsmethoden verknüpft. Sie erfordern mehr Investitionen als ein Prototyp oder PoC, aber sie begrenzen das Risiko und ermöglichen es dem Unternehmen, ein funktionierendes Produkt auf dem Markt einzusetzen, um frühes Feedback zu erhalten und Verbesserungen vorzunehmen.