Die gesamte Serie lesen
Dieser Artikel ist Teil einer ausführlichen Anleitung dazu, wie wir mit Quilters physikgestützter Layout-Automatisierung einen Computer auf Basis des NXP i.MX 8M Mini nachgebaut haben.
Über die Abstimmung in Hardware-Teams lässt sich leicht sprechen. Sie zu erreichen ist schwierig.
Die meisten Entwicklungsorganisationen wissen bereits, dass sie besser kommunizieren müssen. Sie wissen, dass Hardware, Software, Systementwicklung, Fertigung und Führung aufeinander abgestimmt bleiben müssen. Sie wissen, dass Dokumentation wichtig ist. Sie wissen, dass Produktteams und technische Teams nicht in entgegengesetzte Richtungen rudern sollten. Trotzdem tritt in der Hardwareentwicklung immer wieder dieselbe Frustration auf: kluge Menschen, gute Absichten, echter Einsatz – und dennoch gerät das Projekt vom Kurs ab. Termine verschieben sich. Prioritäten werden unscharf. Teams beginnen, unterschiedliche Varianten desselben Problems zu lösen.
Jacob Freking ist Ingenieur für drahtlose HF-Systeme und hat in Bereichen wie Antennendesign, Tests, Leistungsanalyse, Integration und der Umsetzung in Startups gearbeitet. Er bietet einen hilfreichen Blick auf das Problem. Aus seiner Sicht beginnen Schwierigkeiten oft weniger mit mangelnder Kompetenz als mit widersprüchlichen Vorstellungen von Erfolg. Ingenieure können hervorragend sein. Führungskräfte können ihre Aufgabe ernst nehmen. Stakeholder können vernünftig handeln. Ein Programm gerät dennoch ins Stocken, wenn alle auf etwas leicht Unterschiedliches hin optimieren.
„Es scheint eine fehlende Abstimmung zwischen der jeweiligen Programmleitung und ihren letztlichen Stakeholdern zu sein.“
In diesem Satz steckt mehr, als es zunächst scheint. Freking beklagt sich nicht allgemein über die Kommunikation am Arbeitsplatz. Er benennt ein konkretes Fehlermuster in der Entwicklung. Ein Stakeholder möchte vielleicht etwas, das schnell verfügbar, nützlich und gut genug ist, um daraus zu lernen. Ein Führungsteam, das von älteren, starreren Programmen geprägt ist, definiert Erfolg möglicherweise weiterhin über lückenlose Dokumentation, größtmögliche Gründlichkeit und das Ziel, beim ersten Versuch alles richtig zu machen. Jede dieser Positionen hat ihre eigene Logik. Probleme entstehen, wenn beide gleichzeitig gelten, unausgesprochen bleiben und nicht miteinander in Einklang gebracht werden.
Auch gute Ingenieure können eine schlecht abgestimmte Organisation aufbauen
Besonders wertvoll an Frekings Interview ist, dass er das Problem nicht auf Schuldzuweisungen reduziert. Er beschreibt scheiternde Teams nicht als faul oder unernsthaft. Er beschreibt sie als Empfänger widersprüchlicher Signale. Einer Gruppe wird möglicherweise gesagt, sie solle schnell vorankommen, während sie nach Gewohnheiten geführt wird, die für ein langsameres und konservativeres Umfeld entstanden sind. Einem Team wird vielleicht gesagt, dass Iteration wichtig sei, und anschließend wird es so beurteilt, als wäre Perfektion beim ersten Versuch das eigentliche Ziel. Solche Spannungen erzeugen nicht nur Stress. Sie verschwenden Entwicklungsaufwand.
„Die Stakeholder wollen vielleicht, dass etwas schnell fertig wird … es soll funktionieren, aber ihnen geht es darum, schnell etwas zu bekommen, das die meisten Anforderungen erfüllt.“
„Wenn Sie ein Führungsteam hinzuholen, das an traditionellen Programmen gearbeitet hat und dessen Erfahrung darin besteht, Dinge richtig zu machen, egal wie lange es dauert, dann bleibt genau das letztlich sein Ziel.“
Von dort aus breitet sich das Problem nach unten aus. Hardware-Ingenieure, Softwareteams und Systementwickler betrachten das Projekt zunehmend unter unterschiedlichen Anreizen. Reviews dienen weniger der Entscheidung als der Übersetzung zwischen Sichtweisen. Die Dokumentation wächst, die Klarheit aber nicht unbedingt mit ihr. Niemand liegt wirklich falsch. Vollständig aufeinander abgestimmt ist aber auch niemand.
Frekings übergeordnete Beobachtung ist unbequem, gerade weil sie so alltäglich ist: Die Abstimmung in Hardware-Teams scheitert selten in einem dramatischen Moment. Meist erodiert sie durch unausgesprochene Unterschiede beim Tempo, beim akzeptablen Risiko und bei der Frage, was als „fertig“ gilt. Das entspricht einer grundsätzlichen Realität der Systementwicklung. In den Leitlinien der NASA wird der Systemingenieur als die Person beschrieben, die das technische Team anleitet, die Kommunikation sicherstellt, es überwacht und koordiniert und dabei die Wechselwirkungen zwischen Technik, Kosten und Zeitplan in einem komplexen System ausbalanciert. Dieselben Leitlinien betonen, dass ein Systemansatz Hardware, Software und die Integration menschlicher Faktoren zusammenführen muss, statt sie als getrennte Themen zu behandeln.
Abstimmung ist kein weiches Thema. Sie ist technisch.
In vielen technisch geprägten Kulturen wird Abstimmung noch immer der „menschlichen Seite“ des Unternehmens zugerechnet und nicht der Entwicklungsarbeit. Frekings Interview weist in die entgegengesetzte Richtung. Er wirkt durch und durch technisch orientiert, und doch lautet eine seiner klarsten Beobachtungen: Die Umsetzung hängt davon ab, ob das Team tatsächlich dieselben Dinge für wichtig hält.
„Es geht einfach darum, herauszufinden, worauf es der Person ankommt, für die man das Projekt macht.“
„Je besser man das definiert hat, desto besser kann man es umsetzen.“
Das ist kein Managementjargon. Es ist eine Design-Randbedingung. Jedes Hardwareprogramm arbeitet ohnehin unter expliziten Vorgaben wie Leistung, Geometrie, Herstellbarkeit, Kosten und Zeitplan. Freking argumentiert, dass organisatorische Klarheit in dieselbe Kategorie gehört. Wenn das Team nicht weiß, ob es auf Lerngeschwindigkeit, Risikominimierung, vollständige Dokumentation oder reine Leistungsfähigkeit hin optimiert, werden technische Entscheidungen immer wieder auseinanderlaufen.
Sein eigener beruflicher Weg erklärt, warum er das Problem so klar erkennt. Freking beschreibt die HF-Arbeit als einen Bereich, in dem er „das Beste aus all den verschiedenen Arten von Problemen“ mitbekommt und bei Diskussionen über das Systemdesign „zu einem zentralen Knotenpunkt“ wird: Er spricht mit Embedded-Teams, Software-Algorithmikern, Signalverarbeitungsgruppen und anderen HF-Spezialisten. Wer aus dieser Position arbeitet, sieht mehr als hervorragende Einzelleistungen. Er sieht die Qualität der Schnittstellen. Er sieht, wo Übergaben scheitern. Er sieht, wo Teams aufhören, einander zuzuhören.
Bei der Iteration zeigt sich, ob die Abstimmung trägt
Frekings treffendste Aussage über das Verhalten von Teams ist vielleicht diese:
„Beim ersten Durchlauf wird man immer etwas lernen. Und je schneller man es lernt, desto schneller kann man darauf aufbauen, iterieren und es richtig machen.“
Dieser Satz gehört ins Zentrum jeder ernsthaften Diskussion über die Abstimmung in Hardware-Teams. Teams, die sich tatsächlich über den Wert der Iteration einig sind, können schneller und klarer entscheiden. Teams, die über Iteration sprechen, sich insgeheim aber an Perfektion beim ersten Versuch messen, würgen häufig ihre eigenen Lernschleifen ab.
Hardware verschärft diese Spannung, weil reale Systeme teuer und physisch sind und sich oft langsamer überarbeiten lassen als Software. Die Versuchung besteht deshalb darin, die erste Version übermäßig abzusichern. Ein reifes Team tut das Gegenteil: Es schützt den Lernwert der ersten Version. Zur Vorstellung, dass beim ersten Mal alles perfekt funktionieren werde, sagt Freking klar: „Das wird niemals der Fall sein.“ Er lehnt damit keine Gründlichkeit ab. Er verwirft eine falsche Prämisse, die der Umsetzung schadet.
Seine Äußerungen an anderer Stelle im Interview stützen dieselbe Haltung. Bei der Diskussion über Designoptimierung sagt er, Ingenieure müssten erkennen, wann etwas „gut genug“ ist und sie zum nächsten Schritt übergehen sollten. Denn eine Realität übermäßig zu optimieren, die Hardware niemals erreichen wird, ist selbst eine Form von Fehler. Dieselbe Logik gilt für Teams. Abstimmung bedeutet nicht, ein perfektes Organigramm oder eine makellose Prozesslandkarte zu schaffen. Sie bedeutet, genügend gemeinsame Orientierung herzustellen, damit die nächste Iteration etwas Nützliches vermittelt.
Die Abstimmung in der Hardwareentwicklung scheitert an den Schnittstellen
Funktionsübergreifende Abstimmung klingt abstrakt, bis sie auf eine echte Schnittstelle trifft. Dann wird sie schmerzhaft konkret.
Ein Hardware-Team braucht möglicherweise ein bestimmtes Tempo, ein Softwareteam ein anderes. Die Fertigung achtet vielleicht auf eine andere Risikokategorie als die Systementwicklung. Freking und Cody sprechen ausdrücklich über dieses übergreifende Muster mangelnder Abstimmung zwischen Abteilungen – darunter Hardware- und Softwareteams, die in unterschiedlichem Tempo oder mit unterschiedlichen Entwicklungszielen arbeiten. Cody merkt an, dass dieses Problem in Hardware-Interviews ständig auftaucht. Freking stimmt zu, dass gute Führungskräfte sowohl technisches Fundament als auch Verständnis dafür brauchen, wie Menschen arbeiten, wenn sie alle in dieselbe Richtung führen wollen.
„Man braucht technische Erfahrung, um alle in die richtige Richtung auszurichten. Aber vor allem muss man alle davon überzeugen können, dass diese Richtung die richtige ist.“
Dieser Gedanke verdient besondere Aufmerksamkeit. Die Abstimmung in Hardware-Teams lässt sich weder allein durch Charisma noch allein durch Prozesse lösen. Rein zwischenmenschliche Führung reicht nicht aus. Rein technische Führung ebenfalls nicht. Freking beschreibt eine Verbindung beider Fähigkeiten: genügend technisches Verständnis, um die Bedeutung von Kompromissen zu erkennen, und genügend Menschenkenntnis, um einem Team zu helfen, den aktuell entscheidenden Kompromiss anzunehmen. Die NASA-Leitlinien zur Systementwicklung formulieren es ähnlich. Sie beschreiben Systementwicklung als Kunst und Wissenschaft, organisatorische, kostenbezogene und technische Wechselwirkungen mit einem breiten, fachübergreifenden Blick auszubalancieren, statt aus der Sicht einer einzelnen Disziplin.
Die Ingenieurausbildung weist bereits in diese Richtung
Ein Grund für das wiederkehrende Problem ist, dass viele Ingenieure in ihrer Ausbildung technische Exzellenz deutlicher zu würdigen lernen als schlüssige Zusammenarbeit. Doch die Standards der Ingenieurausbildung erkennen zunehmend an, dass anspruchsvolle technische Arbeit beides erfordert. Die aktuellen Akkreditierungskriterien von ABET besagen, dass ingenieurwissenschaftliche Studiengänge das „systematische Streben nach Verbesserung“ in einem „dynamischen und wettbewerbsorientierten Umfeld“ fördern sollen.
Frekings eigene Überlegungen zur Ausbildung vertiefen diesen Punkt. Er argumentiert, dass echte Ingenieurkompetenz weit über die Grundlagen eines grundständigen Studiums hinausgeht. Vieles vom wichtigsten Lernen geschehe im Beruf, wo Systeme, Randbedingungen und zwischenmenschliche Realitäten unvermeidlich werden. Auch stärker autodidaktischen Wegen steht er offen gegenüber – gerade weil berufstätige Ingenieure ständig weiterlernen müssen, statt die formale Ausbildung als Abschluss ihrer Entwicklung zu betrachten.
Zusammengenommen legen diese Sichtweisen eine hilfreiche Neubewertung nahe: Die Abstimmung in Hardware-Teams ist keine zweitrangige Tugend des Arbeitsalltags. Sie gehört zur ingenieurfachlichen Reife. Wer die Schnittstelle zwischen Teilsystemen versteht, aber nicht die Schnittstelle zwischen Teams, übersieht noch immer einen Teil des Systems.
Wie bessere Abstimmung in Hardware-Teams aussieht
Freking bietet kein einzelnes Allheilmittel an. Das macht seine Sicht glaubwürdiger, nicht weniger glaubwürdig. Abstimmung ist schwierig, weil jedes ernsthafte Programm konkurrierende Anforderungen enthält: Zeitplan, Budget, technischen Anspruch, Erwartungen der Stakeholder und Teamdynamik. Cody bringt es im Interview auf den Punkt: Eine technische Führungskraft habe vielleicht „fünf Quarters zur Verfügung“, während die Budgetplanung drei und das Produktteam vier wolle. Frekings Antwort ist bescheiden, aber aufschlussreich: Man wählt, was zu diesem Zeitpunkt am besten ist.
Für Hardware-Teams ergeben sich daraus einige praktische Wahrheiten.
Gemeinsame Prioritäten sind wichtiger als abstrakte Einigkeit. Teams müssen nicht jeden Kompromiss mögen. Sie müssen aber verstehen, welcher die aktuelle Phase bestimmt.
Iteration muss geschützt werden. Die Lerngeschwindigkeit bricht ein, wenn Perfektion beim ersten Versuch zum unausgesprochenen Maßstab wird.
Die Verantwortung für Schnittstellen darf nicht unklar bleiben. Jemand muss die Übersetzung zwischen Hardware, Software, Systementwicklung und Führung übernehmen.
Technische Führung muss nachvollziehbar sein. Ingenieure tragen Entscheidungen eher mit, wenn sie die Begründung erkennen können und nicht nur die Autorität dahinter.
Freking überzeugt hier, weil er die Welt der realen Entwicklungsarbeit nie verlässt. Er verwandelt Abstimmung nicht in Motivationsrhetorik. Er bindet sie an die Umsetzung.
Warum das für Hardware Rich Development wichtig ist
Frekings Interview passt zu Hardware Rich Development, weil es Ingenieurarbeit als physisch und sozial zugleich betrachtet. Hardware besteht aus Geometrien, Materialien, Toleranzen, Messungen und Leistungsbudgets. Sie besteht aber auch aus Übergaben, Annahmen, Rollengrenzen und der Qualität der Kommunikation zwischen Menschen, die unter Druck etwas bauen wollen. Seine Perspektive ist wertvoll, weil er versteht, dass diese Realitäten nicht getrennt sind. Sie gehören zum selben System.
Viele Teams leiden nicht unter einem Mangel an Intelligenz. Sie leiden darunter, dass zu viele unausgesprochene Zielfunktionen gleichzeitig wirken. Freking benennt das klar. Er gibt dem Problem eine technische Form. Und er weist auf die eigentliche Lösung hin: definieren, worauf es ankommt, sich daran ausrichten und die Iteration ihre Arbeit tun lassen.
