Ist ein von Entwicklern angetriebenes Produkt eine gute Sache?

Ich arbeite in einem Unternehmen, in dem der CEO das Produktteam leitet, das Features nachbildet und den Entwicklern zur Verfügung steht, um diese Features dann umzusetzen. Es gibt natürlich einige Iterationen, die Meinungen der Entwickler werden respektiert. Aber ich frage mich, wie effektiv dieser Prozess ist.

Jason Calacanis schrieb gerade :

Die Zuckerberg-Doktrin: Entwickler entwickeln Produkte mit einer im Vergleich zu Produktmanagern und Designern deutlich verbesserten Geschwindigkeit und Funktionalität, die potenzielle Fehler und Nachteile aufwiegen.

...

Dann hat es mich wirklich beeindruckt: Entwickler-gesteuerte Startups produzieren Produkte immer schneller.

Das liegt auf der Hand: Unsere nichttechnischen Leute führen Diskussionen und Debatten, während Zuckerberg sein nächstes Feature programmiert. Deshalb konnte niemand mit Facebook mithalten!

Während MySpacers darüber diskutierten, wie sie ihr Produkt iterieren sollten, versuchte Facebook es einfach.

Funktioniert das in der Praxis tatsächlich besser?

Produkte sollten kundenorientiert sein.

Wenn Ihre Kunden Softwareentwickler sind und Sie Ihr eigenes Produkt verwenden (was Sie auf jeden Fall tun sollten), dann können Sie vermutlich Ihr eigener bester Kunde sein.

Aber als Entwickler wird Ihre Perspektive bereits durch das beeinträchtigt, was unter der Haube passiert. Der Kunde muss Ihnen mitteilen, dass Ihre Arbeit mit der Benutzeroberfläche oder dem Anwendungsworkflow doof ist und keinen Sinn ergibt.

Als Entwickler müssen Sie die richtigen Fragen an die Stakeholder stellen, damit Sie Ihre Erfahrung mit deren Wünschen kombinieren können, um das bestmögliche Produkt zu produzieren.

Als Entwickler würde ich gerne glauben, dass wir einen besseren Job machen als Manager und Designer. Aber ich denke nicht, dass Sie verallgemeinern können.

Eines der Probleme bei Entwicklern, die das Design erstellen, besteht darin, dass sie möglicherweise nicht mit den Bedürfnissen der Endbenutzer in Kontakt stehen und nicht in der Lage sind, den richtigen Leuten die richtigen Fragen zu stellen. Ein Manager und insbesondere ein guter Designer sind möglicherweise besser in der Lage, dies herauszufinden.

Ich denke jedoch, dass es nicht um die Menschen geht, sondern darum, wie sie sich dem Problem nähern. Der Ansatz, der funktioniert, besteht darin, Dinge zu entfernen und umzusetzen, anstatt endlose Besprechungen abzuhalten und Bäume zu fällen, um das "ideale" Design zu finden. Es ist wirklich der Agile versus Waterfall überarbeitet.

(Es sollte klar sein, dass Facebook ein Beispiel dafür ist, wie man Dinge NICHT auch macht. Beispielsweise bringt ihre unbekümmerte Herangehensweise an Datenschutzfragen sie in rechtliche Schwierigkeiten ...)

IMHO, ich würde sagen, Sie haben teilweise recht. Es klingt vernünftig. Dies gilt jedoch möglicherweise nicht für alle Produkte / Software. Also, ich würde es so ausdrücken. Ein Designer sollte eine Person mit viel Entwicklungserfahrung sein UND nicht nur das - die Person sollte immer noch programmieren und nicht nur entwerfen.

Kurze Antwort: manchmal.

Lange Antwort: Kundenorientierte Entwicklung funktioniert, wenn Sie wissen, wer Ihre Kunden sind und was sie wollen.

Entwicklerorientierte Entwicklung hat Vorteile für Leute, die noch nicht wissen, dass sie sie nützlich finden werden. Mit anderen Worten, manchmal können Kunden nicht immer wissen, was sie wollen. Neue Anforderungen können sich aus einer vorhandenen Erfahrung ergeben, wie mangelhaft ein vorhandenes Produkt ist. Es gab keine Kunden für Facebook, Zuckerberg schuf ein Produkt, eine Antwort vor der Frage. Facebook ist mittlerweile etabliert und wird von seinen Kunden beeinflusst. Bevor es erstellt wurde und während der Erstellung, war es eine von Entwicklern betriebene Idee.

Kundenorientierte Entwicklung ist ideal für etablierte, möglicherweise ausgereifte Produkte, die Geld verdienen, oder für neue Iterationen des Produkts auf demselben Markt, bei denen das Ignorieren der Kundenwünsche für zukünftige Einnahmequellen äußerst nachteilig wäre.

Entwicklerorientierte Entwicklung ist eine Nebentätigkeit im Bereich Prototyping und fällt in den Bereich von Google 20%, wobei die Entwickler 20% ihrer Arbeitszeit für eigene Projekte aufwenden.

Um ein gutes Produkt zu entwerfen, benötigen Sie viel Wissen über die Problemdomäne. Ein allgemein öffentliches Produkt wie Facebook kann von Entwicklern angetrieben werden, da es auch ein Problem löst, das Entwickler haben: Wie man sich mit Freunden verbindet und mit ihnen in Kontakt bleibt usw. Dasselbe gilt umso mehr für Produkte, die sich an Softwareentwickler richten: Entwickler wissen was Eine IDE sollte und wie.

Aber für viele andere Problembereiche wissen Entwickler oft einfach nicht genug. Trotz allgemeiner Einsichten und einiger Erfahrung werden sie häufig dazu tendieren, coole Funktionen oder Funktionen zu implementieren, die einfach zu implementieren sind, aber für den Kunden nicht viel Wert schaffen und das Produkt komplexer machen. Dies sind Fälle, in denen Produkte von Domain-Experten gesteuert werden sollten.

Ich denke, dies ist eindeutig der beste Ansatz für ein entwicklerorientiertes Produkt (wie AWS oder Visual Studio), aber ich bin nicht sicher, ob dies eindeutig der bessere Ansatz im Allgemeinen ist. Normalerweise sehe ich Dinge in umgekehrter Richtung: Entwickler stehen herum und argumentieren den besten Ansatz, während die nicht-technischen Leute schnell Entscheidungen treffen. Persönlich bin ich geneigt zu sagen, dass die richtige Antwort irgendwo in der Mitte liegt. Es sollte einen Produktmanager geben, der die Möglichkeit hat, eine allgemeine Richtung festzulegen, die die Entwickler dann implementieren.

Von Entwicklern gesteuerte Software ist in den meisten Fällen möglicherweise besser als von Managern gesteuerte Software. Manager sehen den größten Nutzen in Funktionen (meistens Modefunktionen), die in einer Anzeige gut aussehen oder in einer Rede verwendet werden können. Entwickler sehen unterschiedliche Werte: Leistung, geringere Fehler, schlankes Design, Wartbarkeit. Das führt fast zu einer besseren Software.

Aber das Beste wäre benutzergesteuerte Software. Benutzer wissen genau, was sie brauchen, was ihnen hilft, ihre eigentliche Arbeit zu erledigen. Das wäre das Ideal.

Was ist, wenn Sie Produkte schneller produzieren, als niemand verwenden möchte?

Die Konzentration auf ein einzelnes Attribut (Funktionalität, Time-to-Market, Preis, Qualität usw.) kann für einen bestimmten Zeitpunkt sinnvoll sein. Zum Beispiel hat Apple das iPhone und das iPad aus der Tür gehetzt. Die Qualität litt etwas, aber es war sehr wichtig, der Erste zu sein.

Ich denke, es tut Ihnen weh, wenn Sie sich auf lange Sicht nur auf einen Aspekt konzentrieren.

NEIN, es sei denn, es löst ein Problem der realen Welt

• Programmierer lieben es normalerweise, Probleme zu lösen, manchmal zu Problemen, die es noch nicht gibt :)
• Programmierer machen normalerweise schreckliche GUIs, weil es ein sekundärer Gedanke ist
• Die meisten Benutzerprobleme sind nicht mit Programmiererproblemen identisch .
• Somit ist ein vom Programmierer angetriebenes Produkt normalerweise gut für andere Programmierer, aber nicht so gut für Benutzer.

Auch ein Hinweis auf Facebook:

Der Erfolg von Facebook-Büchern hat nichts mit seinen technischen Vorzügen zu tun. Es handelt sich eher um eine Huckepack-Idee, die gerade richtig groß und schneebedeckt wurde. Facebook und andere kommen nur einmal in einem "Google Blue Moon" vor.

Jedoch:

• Wenn ein Programmierer ein echtes "Benutzer" -Problem hat, eines, das kein Programmiererproblem ist. Dann ist es wahrscheinlich, dass es eine sehr gute Sache ist. Wenn der Stakeholder auch der Entwickler ist , ist dies in Bezug auf das Problem eine ideale Situation für eine großartige Produktlösung.

(Oh Gott ... wo habe ich gerade etwas gelesen wie "Ich habe eine großartige Idee! Alles was ich brauche ist ein Entwickler." Es war innerhalb einer Woche, denke ich. Wie auch immer ...)

Tolle Ideen sind ein Dutzend. Auf die Umsetzung kommt es an. Wenn der Entwickler die großartige Idee hat, kann er sie einfach umsetzen.