Wir prototypisieren per Code. FrontTalks Vortrag

Schöne Ferien, Freunde! Zur Vorbereitung auf den Beginn des neuen Arbeitsjahres stellen wir eine Reihe von Materialien der FrontTalks 2018-Konferenz fertig. Dies ist ein Vortrag von Andrei Salomatin filipovskii_off - einem Entwickler von Polychops. Andrei bietet einen ausgewogenen Ansatz für das Prototyping: sich von Handwerkern, die Aufträge ausführen, zu Forschern zu entwickeln - zu lernen, wie man mit Unsicherheit umgeht und möglicherweise die Vernunft auch ohne einen klaren Plan aufrechtzuerhalten.

Quantitatives Feedback sind AV-Tests, binäre Ergebnisse, wenn entweder Option A oder Option B gewinnt. Das ist alles, was wir aus quantitativen Zyklen erhalten können. Es ist, als wären wir in einem dunklen Raum und nichts ist sichtbar, aber wir haben einen Laserpointer. Von Zeit zu Zeit leuchten wir in den Ecken darauf, markieren einige Punkte und verstehen, was in ihnen ist.

Was möchten wir stattdessen? Ein Benutzer, der diesen dunklen Raum beschreibt, der ihn viel besser kennt als wir.

- Hallo allerseits! Ich möchte über Prototyping sprechen: Warum Prototypen herstellen, was wir daraus ziehen und wie man sie anhand von Beispielen herstellt.





Ich werde mit einer kleinen Geschichte beginnen. 2012 bin ich diesem Startup beigetreten, einem wunderbaren Hirsch. Wir hatten so etwas wie eine Werbeplattform, ich kam als Java-Entwickler. Es ist klar, dass großes Verkehrsaufkommen, interessante Aufgaben, das Team einfach verrückt ist - alles ist wunderbar. Wir arbeiten seit ungefähr acht Monaten, Kopf auf der Tastatur, wir machen sehr coole Funktionen, wir drehen schnell alles um. Aber im Jahr 2013 geht der Hirsch Hufe hoch.

Was ist passiert? Ich habe sehr lange darüber nachgedacht, bin dann als Frontend- und Backend-Entwickler für verschiedene Unternehmen gearbeitet, dann war ich Teamleiter, dann Produktmanager. Er arbeitete sowohl in Startups als auch in Outsourcing-Unternehmen, in großen Unternehmen. Hauptsächlich auf Startups ausgerichtet.



Ich habe auch einige dieser Projekte gemacht. Ich hatte das Glück, an MoscowJS, Frontend Union Conf und RadioJS zu arbeiten. Vielleicht haben wir uns irgendwo mit dir gekreuzt. Jetzt mache ich Code Podcast, einen Podcast auf Englisch über gängige Konzepte in der Programmierung, und Polychops, ein Projekt für Musiker, das in einem Browser arbeitet und Ihnen hilft, das Instrument zu üben, mehr Zeit und Übung zu bekommen.

Was ist mit HeyMoose passiert? Das Unternehmen hatte sehr kluge Leute, die jetzt als leitende Entwickler bei Microsoft arbeiten oder STOs geworden sind. Wir haben das getan, was wir am besten konnten: Wir haben komplexe technische Probleme schnell und interessant gelöst. Aber etwas ist schief gelaufen.



Und bei vielen Unternehmen, insbesondere bei Startups, geht etwas schief. Startups brennen meistens aus zwei Gründen aus: Entweder verstehen sie das Produkt nicht, irgendwo vermissen sie das Produkt oder ihnen geht das Geld aus. Sehr oft geht ihnen das Geld aus, weil sie nach einem Produkt suchen und es nicht lange genug finden können.

Aber warum wird die kundenspezifische Entwicklung in Outsourcing-Unternehmen nicht geschlossen? Oder warum schließen große Unternehmen nicht? Sie scheinen langsamer zu sein. Die Teams dort sind in der Regel zumindest weniger motiviert. Was ist der Unterschied? Die Arbeitsmechanismen sind die gleichen: In der kundenspezifischen Entwicklung schreiben wir TK oder fragen TK von Kunden, sie malen es für uns, geben es uns, wir machen Modelle, Code, wir schreiben es - der gleiche Prozess. Was ist in einem Startup, dass es in großen Unternehmen Randpraktiken geben kann. Trotzdem. Warum brennen Startups aus?

Stellen wir uns zunächst eine hypothetische Situation vor: Ein Produktmanager kommt zu uns und fragt, ob wir ein Metronom hinzufügen können, das im Browser funktioniert, einen Ton mit einem periodischen Intervall und eine synchronisierte Visualisierung erzeugt, sodass verschiedene Lichter im Tempo des Eins-zu-Eins-Metronoms funkeln. Und damit all dies korrekt ist, unabhängig davon, was auf dem Computer, anderen Prozessen usw. geschieht.



Wer ist zu 100% sicher, dass wir dies mit dem Browser und der Browser-API tun können? Keine einzige Person. Wer ist zu 80% sicher, dass wir das wahrscheinlich können? 3-4 Hände. Wer ist sicher 50 bis 50? Die Mehrheit. Wer ist sicher, dass wir das überhaupt nicht können? Ehrlich gesagt.

Das folgende Beispiel. Angenommen, wir arbeiten in einem anderen Unternehmen an einer mobilen Bank. Wir denken mehr über das Produkt nach und halten es für notwendig, die Anzahl der Benutzer zu erhöhen, die unsere mobile Bank nutzen. Wir haben eine Funktion entwickelt: Jetzt kann der Benutzer einen Kauf teilen oder ein Konto in sozialen Netzwerken auffüllen. Geld ist zu ihm gekommen, er ist so auf Facebook - schau, das Geld ist zu mir gekommen. Denken Sie, dass dies dazu beitragen wird, mehr Benutzer anzulocken? Wer ist sich da 100% sicher? Keiner. Wer ist sich zu 100% sicher, dass uns das in keiner Weise hilft? Zwei oder drei Hände. Der Rest ist irgendwo dazwischen.



Und das letzte Beispiel. Wir machen einen Cloud-Service, eröffnen unser Unternehmen. Der Cloud-Service sammelt Protokolle von Projekten, vom Frontend und Backend in kleinen und mittleren Unternehmen, aggregiert sie, maschinelles Lernen, KI und all das. Wir werden es verkaufen. Wer ist sicher, dass dies 100% Erfolg oder 100% Verlust ist? Ein paar Leute.



Auf all diese drei Fragen gibt es nur eine richtige Antwort: "wahrscheinlich". Wir sind uns zu 50–80% sicher, welche Antworten auf einige der Fragen vorliegen. Viel hängt vom Kontext, von der Implementierung ab. Das gleiche Metronom mit Visualisierung - ich habe daran gearbeitet, Sie können es nicht in allen Kontexten zum Laufen bringen: zum Beispiel mit Bluetooth-Kopfhörern. Es kann jedoch für zwei oder drei allgemeine Fälle durchgeführt werden. Nach meinem Verständnis ist dies „wahrscheinlich“ - und es gibt einen Grund, warum Startups geschlossen werden, für die HeyMoose die Hufe hochgezogen hat. Vielleicht tun wir etwas Gutes oder verschwenden nur Zeit. Und wir können nicht verstehen, wie sicher wir in dem sind, was wir tun.

Ein bisschen Theorie. Was ist der Unterschied zwischen kundenspezifischer Entwicklung und Startups? Der Unterschied liegt im Kontext. Wir befinden uns in diesem Kontext der Unsicherheit, wir haben eine Erfolgswahrscheinlichkeit und eine Misserfolgswahrscheinlichkeit. Es ist, als ob wir versuchen, die gleichen Methoden und Praktiken anzuwenden, wenn wir am Boden laufen und wenn wir im Weltraum ohne Schwerkraft laufen. Es scheint, dass wir rennen, aber nichts passiert. Was machen wir falsch?

Diese Unsicherheit kommt aus drei Hauptbereichen. Es kommt vom Markt - weil wir nicht genau wissen, welche anderen Unternehmen an der Protokollaggregation beteiligt sind. Vielleicht wurde dieser Markt bereits von jemandem erobert? Welche Demografie auf dem Markt, wie hoch sind die Preise? Unsicherheit kann von einem Produkt herrühren. Wir wissen nicht, welches Problem unser Kunde hat und wie er es lösen kann. Dies ist ein Beispiel von einer mobilen Bank. Wir scheinen Verständnis zu haben, sind uns aber nicht sicher, ob Benutzer dieses Problem haben und wie sie es lösen können.

Und es gibt Implementierungsprobleme. Ein Beispiel mit einem Metronom. Wir wissen nicht zu 100%, ob dies theoretisch möglich ist oder nicht.

Oder ein anderes Beispiel. Wir haben kein Problem mit dem Markt oder dem Produkt, wenn wir ein Heilmittel gegen Krebs erfinden, das nur eine Pille ist - akzeptiert und gesund. Es gibt jedoch eine Vielzahl von Unsicherheiten bei der Umsetzung dieser Pille. Wir befinden uns im Nebel des Krieges, aber gleichzeitig verhalten wir uns so, als ob der Nebel nicht existiert, weil wir dieselben Prinzipien haben, die in der kundenspezifischen Entwicklung funktionieren. Wir bewegen sie einfach in unseren Kontext der Unsicherheit.

Wir tun so, als ob dieser Nebel nicht existiert, es gibt keine Unsicherheit. Und wir versuchen, die Zukunft vorherzusagen. Als ich anfing, als Produktmanager zu arbeiten, war ich nach dem Entwicklungsprozess beeindruckt, wie viel Wahrsagerei der Produktmanager produzieren sollte. Wenn Sie dem Regisseur oder jemand anderem Bericht erstatten, müssen Sie zuversichtlich aussehen und sagen, dass wir dies oder jenes tun, den Markt bis September erobern, alles wird weh tun. All dies - gut gemacht, ich habe alles durchdacht. Obwohl ich tatsächlich verstehe, dass nichts davon existiert, rate ich nur auf den Karten und versuche, damit sicher auszusehen. Wir haben keine Arbeitskultur mit Unsicherheit und Wahrscheinlichkeit. Um wie Experten auszusehen, müssen wir ständig um einen guten Ruf kämpfen, zuversichtlich sein, darüber sprechen, was wir tun sollten, anstatt was wir überprüfen sollten oder worüber wir uns nicht sicher sind.

Wir, insbesondere Entwickler, neigen immer noch dazu, über das nachzudenken, was wir wissen, verstehen und kontrollieren können. Als Entwickler planen wir sehr gerne Architekturen, denken über die Zukunft nach, wiederholen uns nicht, programmieren Muster und so weiter.

Darunter leiden auch Designer. Sie denken gerne über die Zukunft nach, erstellen perfekte Layouts usw. Wir sind Experten, obwohl wir in Wirklichkeit möglicherweise jemand anderes werden müssen.

Wie gehen wir mit Unsicherheit um? Welche Kampfmethoden haben wir? Die erste Methode ist die wichtigste - alle Karten auf den Tisch zu legen, um zuzugeben, dass wir uns über kein Problem sicher sind. Wir sind uns vielleicht zu 50% sicher, aber um die Hypothese zu testen, brauchen wir zwei Tage. Warum testen wir dann nicht einfach die Hypothese? Wir können zu 90% sicher sein, dass das Produkt abheben wird, aber wir brauchen acht Monate, um dieses Produkt zu implementieren und die Hypothese zu testen. Gehen wir einfach nachsehen? Oder überlegen wir uns, wie wir die Unsicherheit auf 90 oder 100% reduzieren können?

Dies ist der erste Weg. Es ist notwendig, ein Abzeichen für diese Unsicherheit aufzuhängen, um zu sagen, wie groß oder klein sie ist, wie viel Arbeit erforderlich ist, um sie zu lösen usw.

Der zweite Weg, an dem die Menschheit in den letzten 500 Jahren gearbeitet hat, ist die wissenschaftliche Methode. Es ist nicht perfekt, es hat seine eigenen Fehler, aber dies ist der beste Mechanismus, den wir derzeit haben. Die wissenschaftliche Methode besagt: Um die Unsicherheit aufzulösen, müssen wir zunächst eine Hypothese aufstellen, die auf unseren Schlussfolgerungen basiert, dann über ein Experiment nachdenken, das diese Hypothese bestätigt oder widerlegt, dann ein Experiment durchführen, die Zahlen betrachten und verstehen, ob unsere Hypothese wahr ist.



In der Entwicklung, insbesondere im Front-End, haben wir die einmalige Gelegenheit, diese Experimente mit sehr hoher Geschwindigkeit durchzuführen. Diese Methode wird als Prototyping bezeichnet. Prototyp ist ein Weg, um mit Unsicherheit umzugehen. Dies ist keine Produkterfindung, keine Schaffung eines Ideals, das Benutzer verwenden werden. Dies ist eine Gelegenheit, mehr über die Welt um uns herum zu erfahren. Wir lernen dies, indem wir Illusionen erzeugen. Der Prototyp ist eine Illusion, kein Produkt. Es ist, als würden wir die Kulisse auf der Theaterbühne oder auf der Bühne für Filme bauen. Dies ist nur eine Illusion. Ziel ist es, die Unsicherheit zu reduzieren.

Prototyping funktioniert in zwei Kontexten: im Kontext der Implementierung, wenn wir aus Sicht der API theoretisch nicht wissen, ob es möglich ist oder nicht, und im Kontext des Produkts, wenn wir nicht wissen, welches Problem der Benutzer hat und wie es zu lösen ist. Prototyping funktioniert in der Marktforschung nicht wirklich - Excel gibt es dafür.

Der Punkt ist, dass wir bei der Arbeit an einem Prototyp die Denkweise als Experten aufgeben müssen. Wir müssen diese Programmiermuster vergessen, wir müssen vergessen, wie wir ideale Produkte herstellen - weil wir dies nicht tun. Wir versuchen, die Forschung anzukurbeln, wir werden Wissenschaftler.



Anstatt Architekturen zu durchdenken, müssen wir einen Weg finden, um sehr schnell zu iterieren. Anstatt sich der Zukunft anzunähern und darüber nachzudenken, müssen Sie in kurzer Zeit darüber nachdenken, wie Sie dies jetzt tun können.

Anstatt über Ihren Ruf nachzudenken, darüber, was passieren wird, wenn ich sage, dass ich sicher oder nicht sicher bin ... Stattdessen muss ich meinen Ruf aufgeben und Neulinge werden. Dunce. Wie machen wir das? Welche spezifischen Dinge können wir anwenden, um Neulinge zu werden?



Der erste und wichtigste Punkt ist das Feedback. Noch bevor wir unseren Prototyp planen, ein Layout oder etwas anderes zeichnen, überlegen wir, wem wir diese Modelle oder Prototypen zeigen, wie wir das Produkt testen und was wir aus diesem Experiment herausholen wollen. Je kürzer diese Rückkopplungsschleife ist, desto besser für uns.

Ein Beispiel aus dem Privatleben. Productive Mobile ist das Unternehmen, für das ich kürzlich gearbeitet habe. Als Startup haben sie eine Plattform entwickelt, mit der Sie eine mobile Anwendung von einer Website aus per Drag & Drop erstellen können. Wir haben es an große Unternehmen verkauft, weil sie Produkte wie SharePoint oder SAP haben, die nicht auf einem Mobiltelefon verwendet werden können. Wir haben ihnen eine Option angeboten: Sie können eine mobile Anwendung basierend auf einer realen Site erstellen, beispielsweise in einer Woche. Das Problem ist, dass wir ein sehr starkes Entwicklungsteam und einen sehr langen Verkaufszyklus hatten. Wenn Sie ein Produkt eines Unternehmens der Größe von Daimler oder BMW verkaufen, beträgt der Verkaufszyklus mindestens 8 Monate. In dieser Zeit kann ein Team talentierter Entwickler viel einreichen.

Was haben wir getan und was hat uns geholfen? Wir haben ein Mini-Team von Benutzern in unserem Unternehmen zusammengestellt, die das Produkt verwendet haben. Und die Anzahl der Funktionen, die wir begonnen und veröffentlicht haben, hat abgenommen. Gleichzeitig wurde die Qualität der Funktionen n-mal erhöht. Und als wir zu unserem Benutzer kamen und sagten, wir hätten eine solche Plattform, versuchen wir es aus irgendeinem Grund. Notsituationen hörten auf, als wir so waren: Wir haben nicht darüber nachgedacht, das ist etwas Neues. Wir haben angefangen, Features zu entwickeln, die tatsächlich Ergebnisse bringen. Dies liegt daran, dass wir einfach die Rückkopplungsschleife reduziert haben.

Ein Beispiel mit einem Metronom, dem Polychops-Projekt, an dem ich gerade arbeite. Zunächst haben wir in kurzer Zeit ein Video erstellt, das wir irgendwo im Internet gepostet haben. Darin haben wir gefragt, wie Ihnen dieses Konzept gefällt, was Sie darüber denken. Bewertungen zufolge haben wir nicht nur geschätzt, wie interessant dies ist. Wir haben immer noch Hinweise, mit denen wir sprechen können, die wir zu Anrufen, Interviews, zum Ausprobieren eines Prototyps usw. einladen können.

Wir versuchen sehr früh Feedback zu bekommen. Und nicht irgendein Feedback, sondern qualitativ, nicht quantitativ.



Was ist der Unterschied? Quantitatives Feedback sind AV-Tests, binäre Ergebnisse, wenn entweder Option A oder Option B gewinnt. Das ist alles, was wir aus quantitativen Zyklen erhalten können. Es ist, als wären wir in einem dunklen Raum und nichts ist sichtbar, aber wir haben einen Laserpointer. Von Zeit zu Zeit leuchten wir in den Ecken darauf, markieren einige Punkte und verstehen, was in ihnen ist.

Was möchten wir stattdessen? Ein Benutzer, der diesen dunklen Raum beschreibt, der ihn viel besser kennt als wir. Wir brauchen qualitativ hochwertige Interviews, Anrufe und etwas anderes, um Informationen von Benutzern in erweiterter Form zu erhalten.



Ein Beispiel für ein Unternehmen, das stark auf quantitatives Feedback angewiesen ist, ist Booking.com. Meiner Meinung nach gibt es auf ihrer Website etwas zu arbeiten.

Einer der Prototypen des Projekts, an dem ich arbeite, ist eine Funktion, mit der eine Person sich selbst aufnehmen und gleichzeitig selbst reproduzieren kann, wie sie unter dem Metronom gespielt hat - gut oder schlecht. Wir haben diese Funktion erfunden, weil wir von Personen, die den Prototyp getestet haben, um Qualitätsfeedback gebeten haben. Einer der Leute schrieb, dass alles großartig ist, ich mag den Teil mit dem Metronom, aber es wäre cool, diesen Track mit dem Metronom als Audiospur zu exportieren. Wir sind so - es ist unlogisch, warum? Er sagt: "Ich füge dies in mein Programm für die Arbeit mit Musik ein, schreibe mich dann auf und kann dann hören, ob ich in den Rhythmus komme oder nicht." Wir sind so - es ist brillant.

Aber anstatt nur zu exportieren, haben wir beschlossen, die Hypothese zu testen. Wir haben mit Leuten gesprochen und gefragt, ob sie überhaupt auf sich selbst hören, wenn sie mit dem Metronom spielen. Viele sagten, ja, wir haben oft ein Programm - ein Metronom, ein anderes Programm - einen Diktiergerät am Telefon oder woanders, wir nehmen nur auf und hören uns selbst zu. Wir sind so - wir sind Programmierer, wir können dies in einer Anwendung kombinieren. Als Ergebnis haben wir diese Funktion erhalten. Wir hätten es nie erraten, wenn wir nur AV-Tests durchgeführt hätten.



Der wichtigste Teil des Prototyps ist die Schnittstelle. Im globalen Sinne. Wenn wir einen Service mit einer API haben, ist unsere Schnittstelle eine API, mit der der Benutzer interagiert. Wenn wir an einem Metronom arbeiten, ist unsere Schnittstelle der visuelle Teil und der Ton. Wenn wir nur an einer mobilen Anwendung arbeiten, ist unsere Schnittstelle eine visuelle Schnittstelle. Im Prototyp ist die Schnittstelle der einzige wichtige Teil. Alles andere, was wir fälschen können, durch Plüsch ersetzen.

Ein weiteres Beispiel von Productive Mobile. Irgendwann haben wir beschlossen, die interne API in diesem Drag & Drop-Editor für mobile Anwendungen neu zu schreiben. Mit der API kann JS einige komplexe Teile Ihrer mobilen Anwendung wiederbeleben. Als Produktmanager konnte ich einfach eine Spezifikation schreiben und sie den Entwicklern geben. Ich bin sicher, dass in maximal einem Monat alles fertig, getestet und wunderbar sein würde. Aber wir haben uns entschlossen, einen anderen Weg zu gehen. Wir haben gerade die API, die wir in unserem Kopf hatten, auf Papier dokumentiert und dieses Papier an Personen weitergegeben, die mobile Anwendungen erstellt haben. Sie fragten: Wenn Sie eine solche API hätten, wie würden Sie Ihre Anwendungen theoretisch erstellen?

Sie nahmen ein anderes Papier und überprüften alles darauf. Ohne Implementierung. Die API funktionierte zu diesem Zeitpunkt nicht. Wir haben also 5-10 Iterationen durchgeführt, bevor uns klar wurde, wie die API aussehen sollte. Wir haben viel Zeit für die Implementierung gespart. Nachdem wir das Formular verstanden hatten, dokumentierten wir die Spezifikation und implementierten sie. Alles ist wunderbar geworden.



Ein weiteres Beispiel aus dem Metronom. Die allererste Idee für Polychops ist ein Metronom für die Arbeit mit Polyrhythmen. Wir haben den ersten Prototyp in ungefähr 20 Minuten hergestellt und auf Flash geschrieben. So sah er aus. Es gab sogar ein Geräusch. Wir haben es einfach anderen Musikern gezeigt und gefragt - wie gefällt es dir überhaupt? Dies ist das einzig Wichtige.



Dann haben wir ein echtes Metronom im Browser erstellt, es hat funktioniert, Animation, bla bla, alles ist wunderschön.


Aber es dauerte ungefähr anderthalb Monate, und der vorherige Prototyp dauerte 20 Minuten.

Konzentrieren Sie sich auf die Schnittstelle.



Verwenden Sie ein Design-System, um Zeit zu sparen. Ein kurzes Beispiel von Polychops.



Links ist der erste Prototyp, bei dem wir nur alle Tasten selbst durchdacht haben. Nach einiger Zeit entschieden wir, dass wir ein Menü, Navigation, Dropdowns, etwas anderes brauchten. Wir könnten uns hinsetzen und mit den Designern jedes Dropdown, jeden Knopf durchdenken, aber dies ist eine enorme Menge an Zeit, die wir im Prinzip nicht aufwenden müssen. Deshalb haben wir das fertige Designsystem genommen, das Materialdesign genommen, sie haben alles perfekt dokumentiert. Geschraubt, alles ist gut.



Stehlen. Stehlen Sie nicht von Mitbewerbern. Es ist sinnlos, von Wettbewerbern zu stehlen. Wenn etwas für Wettbewerber funktioniert, müssen Sie es nicht überprüfen, sondern nur kopieren. Stehlen Sie von Produkten, die parallel zu Ihren sind, die nicht genau Ihr Produkt sind, aber etwas Ähnliches.



Ein weiteres Beispiel von Polychops. Die Aufnahmeschnittstelle wird praktisch von vorhandenen Soundprogrammen wie Logic geleckt. Natürlich haben wir es stark vereinfacht, aber die Leute verstehen bereits, wie man Logik verwendet, was bedeutet, dass sie verstehen können, wie man Polychops verwendet.

. , . .



: , . , , .



, , . , , . , , , , , . .



— . , , . , .



, , — . . , React . React, React. , , , Redux Apollo, . . .



— . , , — . , - , . , , , , , . -, . . -, , — , . , , , , , .



, , . . , . — , , .

, . , . . , . . . — , . , .

? « ?» — , . Was hat das gebracht?



. , . . 10% , , 10%, , — .

. , 90% , . , , 10%. — , . .

, . Productive Mobile , . , , - , .

. React, — React Native. , , — React, React Native. - : «, React Native, , ». .

? . , , 10 React Native , React Native-. , - , , . , , , «write once — use anywhere». Android iOS . . , , , . — , - , - . — .

, , … ?

Polychops - , . , , , , , . - , , . . .

Ich hoffe du wirst es selbst versuchen. Vielleicht arbeiten Sie nicht in einem Startup, aber Ihr Unternehmen hat Projekte, bei denen Unsicherheit besteht. Für mich ist es wichtig, dass Sie darüber nachdenken, mit Ihrem Team, Ihren Managern sprechen, darüber nachdenken, wie Sie mit Unsicherheit arbeiten und wie Sie Ihre Prozesse aufbauen, damit sich der Entscheidungsprozess verbessert und Sie keine Zeit mehr mit Dingen verschwenden, die nicht benötigt werden.

Wenn Sie erfolgreich sind und ein großartiges Produkt herstellen, hoffe ich, dass ich irgendwann einer Ihrer sehr zufriedenen Benutzer sein werde. Vielen Dank.