Wie überzeugen Sie das Management, einen Prototyp wegzuwerfen?

Ich liebe das Prototyping als schnelle und effektive Möglichkeit, eine Benutzeroberfläche vor einen Benutzer zu stellen.

Häufig stört das Management jedoch, und der Prototyp wird mit Tritten und Schreien in die Entwicklung des Hauptstroms hineingezogen.

Wie schaffen Sie es, dass das Management dies nicht tut?

Verwenden Sie ein Tool wie Microsoft SketchFlow oder erstellen Sie Ihren Prototyp in einer anderen Sprache oder Plattform, sodass eine Integration in die Hauptentwicklung nahezu unmöglich ist.

Es gibt auch einen joelonsoftware-Aufsatz über das Zeigen von Screenshots und Prototypen, in dem er unimplementierte und unbearbeitete Aspekte als offensichtlich gebrochen / unimplementiert erscheinen lässt, um zu verdeutlichen, wo noch gearbeitet werden muss.

Wichtige Folgerung Zwei. Wenn Sie einem Nicht-Programmierer einen Bildschirm zeigen, dessen Benutzeroberfläche zu 100% schön ist, wird er denken, dass das Programm fast fertig ist.

...

Was können Sie dagegen tun? Sobald Sie das Eisberggeheimnis verstanden haben, ist es einfach, damit zu arbeiten. Verstehen Sie, dass es bei allen Demos, die Sie in einem abgedunkelten Raum mit einem Projektor machen, nur um Pixel geht. Wenn Sie können, erstellen Sie Ihre Benutzeroberfläche so, dass unfertige Teile unfertig aussehen. Verwenden Sie beispielsweise Skizzen für die Symbole in der Symbolleiste, bis die Funktionalität verfügbar ist. Während Sie Ihren Web-Service erstellen, sollten Sie in Betracht ziehen, Features von der Homepage wegzulassen, bis diese Features erstellt sind. Auf diese Weise können die Benutzer beobachten, wie die Startseite von 3 Befehlen auf 20 Befehle wechselt, wenn mehr Dinge erstellt werden.

Versuchen Sie also, Ihre Prototypen in Photoshop anstatt in Visual Studio oder in einem ähnlichen Format zu erstellen.

Prototyp nicht mit Arbeitscode. Prototyp mit Bleistift und Papier, oder einem Software - äquivalent .

Das Verwenden von Mockups fühlt sich an wie Zeichnen, aber da es digital ist, können Sie es einfach optimieren und neu anordnen. Teams können ein Design entwerfen und es im Verlauf eines Meetings in Echtzeit durchlaufen.

Das Verwenden von Papier hat den Vorteil, dass Teammitglieder problemlos darauf zugreifen können, und jeder versteht, dass es sich nur um ein leeres Blatt Papier handelt. Dies lässt es weniger wertvoll erscheinen.

Beeinträchtigen Sie niemals die Qualität Ihres Codes.

Das Schreiben von Junk-Code ist eine falsche Wirtschaft.

Wie andere Poster vorgeschlagen haben, können Sie dies erreichen, indem Sie spezielle Tools für Mock-ups verwenden.

Es gibt jedoch verschiedene Gründe, Prototypen zu bauen. Manchmal können Sie zeigen, was Sie brauchen, ohne Code zu schreiben, aber oft ist dies nicht der Fall. Ein Stakeholder möchte möglicherweise, dass Sie die technische Machbarkeit eines Features demonstrieren.

Bauen Sie so schlank wie möglich, um die Funktion zu demonstrieren / das Konzept zu beweisen. Lass alles andere weg.

Stellen Sie für eine UI-Funktion sicher, dass Sie nichts auf dem Server entwickeln - berühren Sie sie überhaupt nicht. Entwickle wieder eingebaute Mocks / Fakes.

Wenn Sie sich bemühen müssen, die Benutzeroberfläche an den Stil der übrigen Anwendung anzupassen, sollten Sie sich nicht darum kümmern. Wenn es ohne Aufwand gut genug aussieht, ändern Sie die Farben, um es hervorzuheben, oder sogar ein Wasserzeichen, um zu zeigen, dass es sich um einen Prototyp handelt.

Ich habe festgestellt, dass die wahrscheinlichsten Täter, die Prototypen in Produktionscode verwandeln, Verkäufer sind. Sie verkaufen Ihr Produkt an einen neuen Kunden - ohne diese neue Funktion hätte der Kunde nicht unterschrieben. Man kann ihnen keine Vorwürfe machen, sie haben Ziele. Sei vorsichtig mit ihnen; Stellen Sie sicher, dass Sie nicht die Dinge herausnehmen, die darauf hinweisen, dass es sich um einen Prototyp handelt. Sie müssen sich behaupten - sie sollten Kunden wahrscheinlich sowieso nicht irreführen.

Ihr Management könnte anfangen, Sie zu zwingen, einen Prototyp Stück für Stück in Produktionscode umzuwandeln. Wenn Sie meinem ersten Rat gefolgt sind, niemals beschissenen Code zu schreiben, sollten Sie kein Problem haben. Allmählich bauen Sie die Software ohne Kompromisse auf.

Wenn das Management Sie dann dazu zwingt, die Qualität zu reduzieren, müssen Sie sich fragen, warum. Sind sie passiv? schwach? verzweifelt? Keines dieser Dinge ist ein guter Grund, in einem Unternehmen zu bleiben.

Wirklich ziemlich einfach. Sagen Sie ihnen, dass sie am Ende ihren Lieblingskunden verlieren würden, wenn sie dieses buggy Chaos zur Schau stellen würden.

Und ja, bitte sie, ihr Risiko einzugehen, wenn sie es wirklich besser wissen.

Zum Schluss: Sagen Sie bitte nicht, dass der Prototyp bestimmte Fehler A, B und C aufweist. Dann müssten Sie diesen Fehler beheben, und das Management wird behaupten, dass sie Energie in die Vorbereitung der Softwareproduktion gesteckt haben.

Die Chancen stehen gut, dass diese Performance-Boni und zukünftigen Aktienzuteilungen heutzutage zuhören werden.

Umgehen Sie das Problem an erster Stelle. BEENDEN SIE ES NICHT. Damit meine ich, dass es nicht hübsch aussieht oder so aussieht, als würde es zu vorhandenen Stilen auf der Website passen. Das Ziel ist einfach, die gröbste Arbeitsversion davon zu erhalten, damit Sie sehen können, dass der grundlegende Ablauf der Benutzeroberfläche funktioniert. Wenn Sie vorhandenen Site-Stil darauf anwenden oder ihn übermäßig polieren, wird davon ausgegangen, dass Sie ihn einfach "einstecken" können. Management ist wie Pakleds von Star Trek. Sie wollen nur, dass Sie "es schaffen". Je bereiter du es scheinst, desto bereiter werden sie denken, dass es so ist.

Wenn das Ihr Problem nicht löst, suchen Sie sich einen Job bei mindestens einem Unternehmen mit einem bekannten Markennamen für ein Jahr. Tragen Sie Ihre E-Mail-Adresse und Ihre Nummer in einen Online-Lebenslauf ein, und Sie bekämpfen die Personalvermittler mit einem Stock. Dadurch können Sie mit dem Vertrauen eines Entwicklers, der weiß, was sie tun, und der einen neuen Job bekommen kann, zu ihnen "absolut nicht" sagen morgen, wo hoffentlich Ihr Fachwissen in dieser Angelegenheit ernst genommen wird.

Ich arbeite derzeit an einer Codebasis, die nicht zwei, sondern einen Triple-Stack-Whammy aus Rails, .NET und Java enthält. Der Grund, warum wir die Rails in Angriff genommen haben, war, dass ein Prototyp in Rails hergestellt wurde und der Spitzenreiter der Firma sagte: "Mach es!". Wir müssen manchmal nein sagen. Solange wir es nicht die ganze Zeit tun, sollten sie uns ernst nehmen.

Aber ja, was auch immer Sie mit einem Prototyp tun, stellen Sie sicher, dass er wirklich hässlich beginnt.

Mach dir keine Sorgen.

Wenn Sie sich hinsetzen und UI-Steuerelemente für einen "Prototyp" werfen, gibt es genau keinen Grund, warum Sie dieses Design jemals automatisch wegwerfen sollten. Wenn es gut genug war, um das Management zu zeigen, ist es ein guter Ausgangspunkt, um das "echte" Programm zu programmieren.

Der Übergang von einem Prototyp zu einer "polierteren" Benutzeroberfläche sollte nichts anderes als eine Reihe völlig gerechtfertigter Schritte sein. Sie mussten eine zweite Schaltfläche hinzufügen. Sie haben Feedback von Benutzern erhalten, dass sie die Bestellung als verwirrend empfunden haben. Die Standardgruppe Ihrer Organisation hat eine geringfügige Änderung vorgeschrieben. Sie mussten die Größe eines Textfelds für die Internationalisierung ändern.

Kein einziger dieser Gründe ist "nun, es war nur ein Prototyp". In UI-Design oder in Code oder schriftlich kann alles für immer leben. Und diejenigen, die nicht alle sind, sollten sehr gute Gründe haben, sie zu töten.

Und das Management kümmert sich wahrscheinlich nicht darum.

Wenn der Grund dafür, dass Sie nicht einfach Ihre Benutzeroberfläche auf den vorhandenen Code umgestellt haben, "Ich musste ihn in unserem richtigen Framework neu schreiben", sollte dies ein ausreichender Grund sein. Andernfalls sollten Sie wahrscheinlich eine Diskussion über das UI-Framework selbst führen, aber das ist eine andere Frage.

Früher hatte ich dieses Problem, bis mir klar wurde, dass es kein Problem war, sondern eine Möglichkeit, mich von den veralteten Entwicklungsstandards zu befreien, die den meisten Geschäften auferlegt wurden.

Sie teilen Ihrem Management mit, dass Sie einen Prototyp schreiben, wählen die für Sie am besten geeigneten Technologien für diesen Problembereich aus und schreiben die Software mit dem vollständigen Wissen, dass sie in die Produktion einfließen wird.

Sie entgehen der Langeweile von "Anwendungen müssen in Java 1.6 mit Web (teure J2EE-Engine nach Wahl des Managements einfügen)" und sinnlosen Namensstandards usw.

Meine aktuellen Prototypensprachen sind "php" (das sich perfekt für Hochleistungsproduktionsumgebungen eignet - fragen Sie einfach Facebook) und die sehr elegante Kombination von Groovy / Java mit Tomcat oder Jetty.

Die Groovy / Java-Kombination eignet sich hervorragend für eine schnelle Entwicklung. Groovy ist schön, schnell zu entwickeln, funktioniert aber wie eine geriatrische Schnecke, es ist jedoch trivial einfach, leistungskritische Abschnitte in Java zu re-faktorisieren. Wenn Sie die Anwendung an Tomcat oder Jetty senden, müssen Sie sich nie wieder mit EJBs und anderen J2EE-Horrors befassen.

Der Hauptvorteil eines funktionierenden Prototyps gegenüber einer Skizze, wie sie von mehreren Postern vorgeschlagen wird, ist das Feedback der Benutzer. Prototypen sind eine großartige Möglichkeit, das Unternehmen wirklich in das Design einzubeziehen. Sobald sie bemerken, dass sie Dinge sagen können wie "Sollte dieses Feld nicht auf dem Hauptbildschirm sein" und hey presto! Dort wird es auf dem Hauptbildschirm bei der nächsten Demo angezeigt, die sie öffnen und in das Design einbinden, indem sie jahrelange wertvolle Geschäftserfahrung in das Projekt einbringen.