Wie können Programmieragenten Engineering, Produkte und Design neu gestalten?

Das Übersetzungsbüro von Shen ist ein Übersetzungsteam unter 36Kr, das sich auf Technologie, Geschäft, Arbeitsplatz und Lebensbereiche konzentriert und vor allem neue Technologien, neue Ansichten und neue Trends aus dem Ausland vorstellt.

Herausgeberhinweis: Code ist zu einem billigen Warenartikel geworden, und PRD (Produktanforderungsdokument) wird zu überflüssigem Papier. Wenn Programmierintelligenzen die "Implementierungskosten" eliminieren, verschiebt sich die Engstelle der Softwareentwicklung von der Codeerstellung zur intensiven Prüfung. In diesem Prozess der Rollenkollaps musst du entweder zu einem allumfassenden Bauherrn evolvieren oder die Schutzmauer des Systemdenkens verteidigen. Der Artikel ist eine Übersetzung.

Für Softwareunternehmen liegt der Kern von EPD (Engineering, Produkt und Design) darin, hochwertige Software zu entwickeln. Obwohl die Rollen klar definiert sind, ist das endgültige Ziel die Erstellung von funktioneller Software, die geschäftliche Probleme löst und für Benutzer nutzbar ist. Letztendlich ist alles, was produziert wird, Code. Wir müssen erkennen, dass die Ergebnisse, die die EPD-Funktionen aufbauen, im Wesentlichen Code sind, denn... Die Entstehung von Programmierintelligenzen hat die Codeerstellung plötzlich extrem einfach gemacht. Wie wird dies die Rollen in EPD ändern?

Veränderung des Prozesses:

• Das PRD (Produktanforderungsdokument) ist tot

• Die Engstelle verschiebt sich von der "Implementierung" zur "Prüfung"

• Lang lebe das PRD

Auswirkungen auf die Rollen:

• Allrundler sind wertvoller denn je

• Programmierintelligenzen werden zur Pflicht

• Gute PMs werden ausgezeichnet, mediocre PMs werden schlecht

• Jeder muss Produktgefühl haben

• Die Anforderungen an die Spezialisierung sind höher

• Du musst entweder ein Bauherr (Builder) oder ein Prüfer (Reviewer) werden

• Jeder glaubt, dass Programmierintelligenzen seine Rolle am meisten unterstützen - und sie haben alle recht

Das PRD ist tot

Vor der Claude-Ära war das PRD (Produktanforderungsdokument) der Mittelpunkt der Softwareentwicklung. Der EPD-Prozess sah grob wie folgt aus:

• Jemand (meist ein Produktmanager) bekommt eine Idee

• Der Produktmanager schreibt das PRD

• Das Designteam erstellt ein Prototypenbild basierend auf dem PRD

• Das Engineeringteam verwandelt den Prototypen in Code

Dies ist keine feste Regel (in Start-ups sind diese Schritte oft miteinander verzahnt, und hervorragende Bauherren können mehrere Aufgaben gleichzeitig bewältigen), aber es ist die Lehrbuchmethode der Entwicklung.

Dieses Modell war notwendig, weil die Entwicklung von Software (und die Erstellung von Prototypen) viel Zeit und Energie erfordert. Daher wurden spezielle Funktionen geschaffen, um diese Aufgaben effizienter zu erledigen. Mit zunehmender Spezialisierung stieg auch der Bedarf an interfunktioneller Kommunikation. Das PRD war die Grundlage für diese Kommunikation. Es startete den gesamten Prozess und floss dann wie ein Wasserfall in das Design, wandelte feine Worte in eine schöne Benutzeroberfläche und ein reibungsloses Benutzererlebnis um und wurde schließlich vom Engineeringteam in die Realität umgesetzt.

Programmierintelligenzen haben dies alles verändert. Sie können direkt aus einer Idee funktionelle Software generieren. Wenn ich (und andere) sagen, dass "das PRD tot ist", meinen wir eigentlich, dass das traditionelle Softwareentwicklungsmuster, das mit der Schreibung eines PRD beginnt, veraltet ist.

Die Engstelle verschiebt sich von der "Implementierung" zur "Prüfung"

Jeder kann jetzt Code schreiben, was bedeutet, dass jeder Produkte entwickeln kann. Dies bedeutet jedoch nicht, dass das entwickelte Produkt eine gute Architektur hat, das richtige Problem löst oder einfach zu bedienen ist. Engineering, Produkt und Design sollten die Prüfer und Richter in diesen Bereichen werden. Das Problem ist, dass der generierte Code nicht immer "exzellent" ist. Die Rolle von EPD besteht darin, zu prüfen und sicherzustellen, dass er "exzellent" ist. "Exzellent" hat mehrere Bedeutungen:

• Aus Sicht des Engineeringsystems: Ist die Architektur sinnvoll? Ist der Code skalierbar, leistungsstark und robust?

• Aus Sicht des Produkts: Ist die Überlegung gründlich? Löst es die Probleme der Benutzer?

• Ist das Design gut? Ist die Benutzeroberfläche einfach und intuitiv?

Da die Kosten für die Erstellung der ersten Codeversion so niedrig sind, sehen wir, dass es mehr Prototypen gibt. Diese Prototypen werden zum Mittelpunkt und werden gemeinsam von Produkt, Engineering und Design geprüft.

Das Problem ist - es ist zu einfach, Code zu generieren. Früher hat es viel Zeit gedauert, Code zu schreiben, daher mussten Sie als Prüfer nur eine begrenzte Anzahl von Projekten zu einem bestimmten Zeitpunkt prüfen. Jetzt kann jeder Code schreiben, was bedeutet, dass die Anzahl der laufenden Projekte stark ansteigt. Wir haben gesehen, dass die Engstelle (in allen drei Funktionen) zur "Prüfung" geworden ist - d.h. die Prototypen zu erhalten und sicherzustellen, dass sie "gut" sind.

Lang lebe das PRD

Die Zeit der Softwareentwicklung vor Claude mit vordefiniertem PRD ist vorbei. Aber die Dokumente, die die Produktanforderungen beschreiben, sind immer noch von großer Bedeutung.

Nehmen wir an, jemand bekommt eine Idee und entwickelt schnell einen Prototypen. Wie kommt dieser Prototyp in die Produktionsumgebung? Er muss von den anderen Mitgliedern von EPD geprüft werden. In diesem Prozess ist es immer hilfreich und oft sogar unerlässlich, ein schriftliches Dokument zu haben. Wenn andere prüfen, wie können sie wissen, ob ein Codeabschnitt ein Versehen oder beabsichtigt ist? Das hängt von der Absicht ab. Daher ist eine Art von Absichtskommunikation erforderlich. Ich denke, dass der traditionelle PRD-Prozess (PRD → Prototyp → Code) tot ist, aber der Text, der die Produktanforderungen beschreibt, ist immer noch lebendig. Bevor es an die Prüfung übergeben wird, sollte dieses verknüpfende Dokument ein unverzichtbarer Begleiter des Prototyps sein.

Das Standardformat ist ein Dokument, aber es gibt derzeit auch einige interessante Ideen, wie die Kommunikation der Anforderungen durch die Freigabe des Prompts (Hinweiswort), der zur Erstellung der Funktion verwendet wurde. Was wäre, wenn zukünftige PRDs nur strukturierte, versionierte Prompts wären?

Allrundler sind wertvoller denn je

Unter Allrundlern verstehe ich Personen, die ein scharfes Gespür für Produkt, Engineering und Design haben. Diese Personen waren immer wertvoll und sehr einflussreich, aber durch die Unterstützung von Programmierintelligenzen wird ihr Wert noch verstärkt. Warum? Weil Kommunikation der schwierigste Teil aller Schritte ist und die Geschwindigkeit verlangsamt. Eine Person, die Produkt, Design und Engineering gleichzeitig beherrscht, kann aufgrund der Einsparung von Kommunikationskosten schneller vorankommen als ein dreiköpfiges Team.

Früher, als die "Implementierung" die Engstelle war, musste der Allroundler immer noch mit anderen kommunizieren, um seine Arbeit zu erledigen. Jetzt muss er nur noch mit der KI kommunizieren. Dies bedeutet, dass er allein eine viel größere Wirkung entfalten kann als früher.

Programmierintelligenzen werden zur Pflicht

Da Programmierintelligenzen die Implementierungskosten senken, ist ihre Verwendung unvermeidlich. Personen, die diese Intelligenzen nutzen können, können unabhängig von anderen mehr Aufgaben erledigen:

• PMs, die Intelligenzen nutzen, können direkt Prototypen entwickeln, um Ideen zu validieren, ohne lange auf die Schreibung von Spezifikationen warten zu müssen;

• Designer, die Intelligenzen nutzen, können direkt im Code iterieren, anstatt nur in Figma herumzuspielen;

• Ingenieure, die Intelligenzen nutzen, können ihre Energie von der "Implementierung" auf das "Systemdenken" lenken.

Die Nutzung von Programmierintelligenzen ist unumgänglich, denn es ist nicht schwer. Wenn Sie dies nicht tun, werden Sie von Personen ersetzt, die es können.

Gute PMs werden ausgezeichnet, mediocre PMs werden schlecht

Gutes Produktdenken ist wertvoller denn je - Sie können wirklich nützliche Dinge entwickeln. Schlechtes Produktdenken ist dagegen destruktiver denn je. Selbst wenn jemand eine schlechte Produktidee hat, kann er mit einem Prototypen vor Ihnen auftauchen, aber es kann sich um eine nutzlose oder schlecht konzipierte Funktion handeln. Diese Prototypen erfordern jetzt mehr Prüfung - von Engineering, Produkt und Design. Dies verbraucht viel Zeit und Ressourcen. Darüber hinaus kann die Einführung dieser Prototypen in die Produktionsumgebung zu einer Trägheit führen ("Da es ja schon geschrieben ist, fügen wir es einfach hinzu!"). Dies birgt das Risiko, dass das Produkt schlechter oder überladen wird.

Systemdenken ist eine Kernkompetenz, die trainiert werden muss

In einer Welt mit geringen Ausführungskosten ist Systemdenken der Schlüssel zur Differenzierung. Sie sollten sich darauf konzentrieren, Ihr Systemdenken zu verbessern und klare mentale Modelle in bestimmten Bereichen aufzubauen:

• Engineering: Ein ausgezeichnetes mentales Modell für die Architektur von Services, APIs und Datenbanken;

• Produkt: Ein ausgezeichnetes mentales Modell für das, was die Benutzer wirklich brauchen (und nicht was sie nur sagen, dass sie wollen);

• Design: Ein ausgezeichnetes mentales Modell für die Gründe, warum bestimmte Dinge richtig aussehen und funktionieren.

Systemdenken war immer wichtig - was hat sich geändert? Die Implementierungskosten sind stark gesunken. Dies bedeutet, dass es einfacher denn je ist, etwas umzusetzen, aber das bedeutet nicht, dass es gut ist. Gutes Systemdenken ermöglicht es Ihnen, sicherzustellen, dass Sie das Richtige von Anfang an bauen und auch später die Arbeit anderer prüfen können. Beides bedeutet, dass es noch wichtiger wird, ein guter Systemdenker zu sein.

Jeder muss Produktgefühl haben

Programmierintelligenzen benötigen immer noch jemanden, der ihnen sagt, was sie tun sollen. Wenn Sie sie anweisen, etwas Falsches zu bauen, produzieren Sie nur Müll für die Prüfung anderer. Das Wissen, was man den Intelligenzen bauen lassen soll (d.h. "Produktgefühl") ist eine Grundvoraussetzung, sonst werden Sie das gesamte Team behindern. Dies gilt für Engineering, Design und (offensichtlich) die Produktrolle.

Ein Großteil der Arbeit von EPD besteht jetzt darin, Prototypen zu prüfen. Wenn Sie Produktgefühl haben, ist die Prüfung viel einfacher, auch wenn Sie Design oder Engineering prüfen. Wenn Sie kein Produktgefühl haben, benötigen Sie ein äußerst detailliertes Produktdokument zusammen mit dem Prototypen. Wenn Sie Produktgefühl haben, können Sie mit minimalen Spezifikationen die Absicht der Funktion verstehen und so die Kommunikation, Prüfung und Lieferung beschleunigen.

Die Anforderungen an die Spezialisierung sind höher

Sie müssen wissen, wie man Programmierintelligenzen verwendet und Produktgefühl haben. Alle Rollen verschmelzen. Rollenüberlappungen gab es schon immer. Design und Produkt sind schon lange untrennbar - in Unternehmen wie Apple und Airbnb fungieren Designer auch als Produktmanager. Die Rolle des "Design Engineers" ist auch in Unternehmen wie Vercel sehr beliebt.

Dies bedeutet nicht, dass es keinen Platz für Spezialisierung gibt. Ein erfahrener Ingenieur, der nur über Systemarchitekturen nachdenkt, ist immer noch wertvoll. Ebenso ein PM, der nicht "vibe coding" gelernt hat, aber ein klares mentales Modell für die Probleme der Kunden und die Schwerpunkte des Bauens hat. Dies gilt auch für Designer, die in Figma Benutzerpfade und Interaktionen verstehen und simulieren können.

Aber die Anforderungen an die Spezialisierung sind viel höher. Sie müssen nicht nur in Ihrem Bereich hervorragend sein, sondern auch eine sehr schnelle Prüfgeschwindigkeit und ausgezeichnete Kommunikationsfähigkeiten haben. Und es gibt in jedem Unternehmen möglicherweise nicht so viele solche Stellen.

Entweder werden Sie ein Entwickler oder ein Prüfer

Wir sehen in EPD zwei verschiedene Arten von Rollen auftauchen.

Erste Art: Entwickler (Builder). Diese Personen haben ein gutes Produktdenken, können Programmierintelligenzen gut nutzen und haben ein grundlegendes Designgefühl. Unter den gegebenen Einschränkungen (Testsuite, Komponentenbibliothek) können sie kleine Funktionen von der Idee zur Umsetzung bringen und lauffähige Prototypen für große Funktionen