Das klassische Lastenheft gilt oft als unverzichtbarer Startpunkt für ein Elektronikprojekt. Doch in der Realität erweist sich dieses Vorgehen häufig als unflexibel. Anforderungen sind noch unklar, die Anwendung ist komplex, und die optimale technische Lösung steht noch nicht fest.
Bei PICKPLACE setzen wir deshalb auf einen anderen Weg: Wir beginnen mit dem Dialog – und entwickeln gemeinsam mit dem Kunden eine fundierte, aber anpassungsfähige technische Basis. Das Ziel ist es Kundenideen zu formulieren, die wir final in elektronische Produkte umsetzen.
Viele unserer Kunden haben eine konkrete Idee oder ein technisches Ziel, aber noch kein detailliertes Lastenheft. Das ist für uns kein Hindernis – im Gegenteil: Oft entstehen die besten Lösungen im Gespräch. Der frühe Austausch ermöglicht es, Ziele einzugrenzen, technische Möglichkeiten zu prüfen und das Projekt von Anfang an richtig aufzusetzen.
Anstatt ein vollständiges Lastenheft zu fordern, beginnen wir mit einem technischen Gespräch. Darin klären wir den Kontext, das Umfeld, funktionale Anforderungen und wichtige Rahmenbedingungen. Aus dieser Basis entwickeln wir ein erstes Grobkonzept, das später durch Dokumente und technische Spezifikationen konkretisiert wird.
Der Vorteil dieses Vorgehens: Es bleibt Raum für Weiterentwicklung. Anforderungen können im Laufe des Projekts angepasst werden, ohne den gesamten Prozess zu blockieren. Durch regelmäßige technische Reviews stellen wir sicher, dass wir immer nah an den tatsächlichen Bedürfnissen des Kunden bleiben – und dass diese auch dokumentiert sind.
Wir arbeiten also nicht ohne Dokumentation, sondern setzen sie gezielt ein: zur Abstimmung, zur Validierung und zur Absicherung für beide Seiten. So entsteht eine technische Spezifikation, die nicht auf Annahmen basiert, sondern auf gemeinsam entwickeltem Verständnis.
Als Partner für Entwicklung und Fertigung betrachten wir die gesamte Produktrealisierung als Einheit. Bereits in der Konzeptphase achten wir auf Dinge wie Bauteilverfügbarkeit, thermische Machbarkeit und Testbarkeit. Das Ziel ist klar: Die Lösung muss nicht nur technisch funktionieren, sondern auch wirtschaftlich in Serie gebracht werden können.
Diese Denkweise – Design for Manufacturing – fließt in jeden unserer Entwicklungsschritte ein. Weil wir selbst fertigen, kennen wir die typischen Hürden und können sie von Beginn an vermeiden.
Natürlich braucht ein Projekt am Ende eine klare Beschreibung der Anforderungen und des Umfangs. Doch diese entsteht bei uns nicht auf Verdacht, sondern aus dem Prozess heraus. Sobald technische Fragen geklärt sind, erstellen wir ein strukturiertes Angebot mit den abgestimmten Spezifikationen. Diese Dokumentation ist nicht nur sauber formuliert, sondern auch fachlich fundiert und abgestimmt auf die reale Umsetzung.
Die unten dargestellte Grafik zeigt unseren typischen Entwicklungsprozess in zwei Varianten: oben klassisch-linear mit einem Lastenheft als Startpunkt, unten unser iterativer, dialogbasierter Ansatz.
Entwicklungsprozess bei PICKPLACE
Im klassischen Modell beginnt das Projekt mit einem vollständigen Anforderungskatalog. Alle Spezifikationen müssen vorab fixiert sein, bevor Entwicklung überhaupt beginnen kann. Diese lineare Herangehensweise wirkt zunächst geordnet, bringt aber hohe Risiken mit sich: Wird etwas übersehen, ist eine spätere Korrektur aufwendig oder teuer. Anpassungen sind oft nicht eingeplant. Unser Modell setzt daher früher an: Statt das Device von vorne bis hinten zu Beginn des Projekts durchzuspezifizieren, beginnen wir mit der Spezifikation der gemeinsamen Zusammenarbeit. Die Grenzen und Übergaben werden definiert, sowie die Erwartungshaltung beider Parteien an das Projekt.
Erst im Folgenden entwickeln aus diesem Set an Anforderungen gemeinsam mit dem Kunden die konkrete Lösung. Zwischen jeder Phase – Spezifikation, Architektur, Design, Inbetriebnahme – finden technische Reviews mit dem Kunden statt. Diese Feedbackschleifen sind der entscheidende Unterschied: Sie ermöglichen nicht nur Transparenz und Mitgestaltung, sondern führen auch zu einem besseren technischen Ergebnis.
Statt ein einziges finales Dokument zu schreiben, entstehen entlang des Prozesses mehrere abgestimmte Zwischenstände. So stellen wir sicher, dass Anforderungen und Umsetzung jederzeit übereinstimmen. Die Abstimmungen sind dokumentiert und werden laufend weiterentwickelt – gemeinsam, Schritt für Schritt.
Die o.g. Grafik benennt dabei explizit die begleitenden Dokumente und Prüfobjekte in unserem Prozess:
PROJECT REQUIREMENTS: Die gemeinsam erarbeiteten funktionalen und nicht-funktionalen Anforderungen an das Produkt.
DOCUMENT PLAN: Eine strukturierte Übersicht, welche technischen und organisatorischen Dokumente im Projekt entstehen sollen.
DEFINITION OF DONE: Eine verbindliche Festlegung, wann ein Entwicklungsschritt als abgeschlossen gilt – inklusive Kriterien für technische Funktionalität, Dokumentation und Review-Freigabe.
PROJECT REVIEW: Der geplante Zeitpunkt zur Gesamtabnahme bzw. zur strategischen Kurskorrektur im Projektverlauf.
Parallel dazu wird inhaltlich zwischen Hardware- und Softwarepfad differenziert:
HARDWARE REQUIREMENTS und SOFTWARE REQUIREMENTS spezifizieren die jeweiligen Anforderungen getrennt nach Gewerken – etwa in Bezug auf Schnittstellen, Performance, Energieverbrauch oder Echtzeitverhalten.
HARDWARE TEST und SOFTWARE TEST beschreiben die konkreten Maßnahmen zur Prüfung der jeweiligen Entwicklungsstände. Hierzu gehören sowohl automatisierte als auch manuelle Tests, z. B. Funktionstests, Integrationstests oder Simulationen.
Alle genannten Punkte sind nicht nur interne Schritte, sondern werden mit dem Kunden gemeinsam abgestimmt. Das heißt: Jeder dieser Begriffe steht für ein transparentes, prüfbares Element im Projektverlauf.
Iterativ und nach Prozess entstandener SoM
Wir bei PICKPLACE glauben nicht an starre Pflichtenhefte – wir glauben an fundierte Technik, gute Gespräche und an Lösungen, die sich gemeinsam entwickeln lassen. Deshalb setzen wir auf Struktur statt Bürokratie, auf Spezifikation statt Spekulation und auf Austausch statt Vorgabe.