Ein Code-Rundgang ist absolut Zeitverschwendung. Versuchen Sie, die Dinge auf ein zwei- oder dreiseitiges Dokument mit einem oder zwei Diagrammen zu reduzieren, das Ihre aktuelle Arbeit zusammenfasst. Lassen Sie Fachjargon so weit wie möglich weg. Sie möchten die Person nur in den "Ball Park" bringen, ohne sich dabei zu erschöpfen.

Es ist vollkommen in Ordnung, ein paar Stunden Zeit zu verlangen, um eine SCHRIFTLICHE Zusammenfassung zu erstellen. Legen Sie einen Schwerpunkt auf SCHRIFTLICH, da dies Ihnen hilft, sich nicht immer wieder zu wiederholen (und mit jeder Runde frustrierter zu werden). Stellen Sie sicher, dass Sie für ein Publikum der 8. Klasse schreiben (lächeln), und damit meine ich, dass der Leser nur grundlegende Konzepte versteht.

Viel Glück.

Ein Teil der Arbeit bei so etwas besteht darin, zu kommunizieren, wie die Benutzererfahrung aussehen wird. Dies kann häufig ein ebenso wichtiger Bestandteil der Spezifikation sein wie die Funktionalität. Darüber hinaus regt es die Benutzer von Domain-Experten dazu an, tiefer über ihre Anforderungen nachzudenken, und kann Sie genauer leiten.

Ich bin überrascht, dass niemand die Erstellung von "Wireframes" - oder "Mock-up" -Schnittstellen erwähnt hat. Es gibt spezielle Tools dafür, aber es kann so einfach sein, etwas mit einem Bildbearbeitungsprogramm zusammenzustellen. Modelle werden früh im Projektlebenszyklus erstellt, damit Benutzer und Entwickler etwas gemeinsam haben, über das sie sprechen können. Es verhindert, dass Benutzer blind sind, und fördert das Vertrauen, dass Sie alle "auf derselben Seite" sind.

Ich habe festgestellt, dass Sie sich die Zeit nehmen, um Modelle zu erstellen oder sogar Zeichnungen eines Benutzers zu skizzieren. Die Benutzeroberfläche zwingt Benutzer (und mich), über das zu lösende Problem und alternative Lösungen nachzudenken. Dies führt häufig zur Entdeckung von Randfällen und sogar zu neuen Funktionen.

Das Speichern der Benutzeroberfläche für den letzten Fall ist altmodisch. Sie werden überzeugender sein, wenn Sie Ihren Stakeholdern etwas geben können, das sie im Leben des Projekts über EARLY sehen und begründen können. Das bedeutet nicht, dass Sie zuerst die Benutzeroberfläche implementieren müssen. Kommunizieren Sie einfach auf die eine oder andere Weise, wie es zu Beginn des Prozesses aussehen wird.

Wenn ich in dieser Situation bin und eine spontane Präsentation erforderlich ist, nehme ich einen Stift und gehe zum Whiteboard. Befolgen Sie dann diese Schritte.

• Ich erkläre das allgemeine Problem, das ich versuche aus geschäftlicher Sicht zu lösen und zu betonen, warum dies notwendig ist.

• Ich sage ihnen, dass ich verschiedene mögliche Lösungen recherchiert und analysiert habe, wobei ich mich darauf konzentriere, welche die besten hat Verhältnis von Kosten zu Nutzen.

  Hier ist ein Beispiel: Die Verwendung eines Schlüsselwertspeichers wäre schön, weil er schnell ist, aber alle anderen kennen nur MySQL und es gibt keinen Systemadministrator, der beim Einrichten eines Redis hilft. Sie würden nicht weiterkommen, und der Nutzen ist wirklich nicht groß. Es fühlt sich besser an, aber wir müssten um etwa 500% wachsen, bevor die MySQL-Lösung messbar langsamer wird.

  All dies ist das technologische Äquivalent zu der Aussage, dass die datenbankgesteuerte Lösung billiger ist, mehr pragmatisch, die schneller umgesetzt werden kann. Manager verstehen Welten wie billig , pragmatisch und schnell .

  Was Sie tatsächlich getan haben, ist im Grunde eine Kosten-Nutzen-Analyse, nur viel technischer. Alles, was Sie ihnen sagen, ist das Ergebnis.

• Zeichnen Sie den Prozess in einem Diagramm, wiederum aus geschäftlicher Sicht . Der Benutzer wird von hier kommen. Sie machen Sachen. Daten gehen diesen Weg. Hier befindet sich eine Box, die die neue Geschäftslogik ausführt. Es spricht auf diese Weise mit der Datenbank. Es gibt eine Schnittstelle zu unserem bestehenden Produkt. Sei nicht sehr technisch. Normalerweise verstehen sie, dass es irgendwo eine Datenbank gibt. Das haben sie schon einmal gehört.

  Wenn Sie den Prozess kennen und ihn visualisieren können, wird dem Manager mitgeteilt, dass Sie Zeit investiert haben, um ihn zu überdenken . Durch die Benutzer- oder Geschäftsorientierung kann der Manager die Visualisierung verfolgen.

• Erklären Sie, in welcher Reihenfolge Sie die Teile in diesem Diagramm erstellen. Welche sind vorhandene Infrastruktur. Welche sind neu? Wer wird welche bauen?

• Erklären Sie, was noch zu tun ist. Gibt es Abhängigkeiten in anderen Abteilungen? Der Kundendienst muss über die neue Schaltfläche informiert werden, nach der Kunden möglicherweise fragen, und Sie haben bereits Aufgaben dafür erstellt, sobald das neue Produkt für Tests verwendet werden kann.

• Fragen Sie, ob sie glauben, Sie hätten etwas vergessen. Geben Sie dem Manager den Stift und lassen Sie ihn in das Diagramm zeichnen, wenn er möchte.

• Kreuzen Sie Dinge an, die bereits im Diagramm ausgeführt wurden. Sagen Sie ihnen, welche Teile groß und welche klein sind. Sie müssen keine reellen Zahlen oder Schätzungen angeben. Das Diagramm zu sehen und zu wissen, dass diese Box fertig ist, war eine Menge Arbeit, und es sind noch drei weitere Schnörkel übrig, bei denen es sich jeweils um kleine Aufgaben handelt. Dies gibt einen guten Überblick, ohne in das Mikromanagement einzusteigen.

Das funktioniert normalerweise bei mir. Es muss nicht supertechnisch sein. Der Schlüssel soll sachkundig erscheinen . Sie müssen den Eindruck erwecken, dass Sie genau wissen, wovon Sie sprechen. Auf diese Weise verstehen sie, dass Sie an dem Projekt beteiligt sind und Fortschritte machen. Die Visualisierung hilft zu verstehen, wie weit Sie gekommen sind.

Ich finde Ihr Szenario schwer vorstellbar. Sie arbeiten an einem sehr technischen Problem, aber Ihr Chef ist nicht technisch oder versteht nicht, woran Sie arbeiten?

Es hört sich so an, als würden Sie an Nanotechnologien arbeiten und Ihr Chef versteht es nicht eine Sache darüber. Warum konnten Sie nicht etwas zu dem Effekt sagen: "Ich bin gerade in Stufe X und muss Y zeigen. Wenn Sie bis Z warten, kann ich Ihnen A, B und C zeigen?" Warum muss diese Erklärung so komplex und schwierig sein, dass sie selbst in der Hypothesenphase in keiner Form oder Form erklärt werden kann?

Ich schlage auch vor, einen Issue-Tracker einzusetzen. Auf diese Weise kann Ihr Chef Ihren Fortschritt sehen und möglicherweise wissen, wann etwas präsentiert werden kann. Sie können sagen: "Ich habe es in Jira und schätze, dass es in 3 Wochen fertig sein wird." Er versteht möglicherweise keinen Code, kann aber möglicherweise einen Issue-Tracker verstehen.

Zeigen Sie die Prototypen und erklären Sie, warum Sie Prototypen / Experimente benötigen, anstatt die erste zweckmäßige Lösung als gut genug zu betrachten, während Sie Literatur / Erfahrung konsultieren, um die minderwertigen herauszufiltern.

Denken Sie daran, dass nicht alles muss zu Tode optimiert werden. Manchmal muss optimiert werden, wie schnell Sie eine funktionierende Lösung liefern können.

Und mit der Erfahrung sollte sich die Fähigkeit, das Verhalten des Algorithmus für einen Datensatz vorherzusagen, verbessern und die Notwendigkeit zum Testen sollte sich verringern, es sei denn, Sie sind es ein neuartiges Problem ansprechen.

Es wäre unmöglich, ihm die Tiefe der Lösung und das, woran ich gearbeitet habe, zu erklären.

Aber genau das müssen Sie tun. Das Problem, das Sie haben, ist, dass Ihre Manager der Meinung sind, dass sie nicht nur verstehen sollten, was Sie arbeiten, sondern dass sie tatsächlich können und es an Ihnen liegt um sie von dieser Vorstellung abzubringen.

Sie müssen mit ihnen wie mit einem anderen Ingenieur sprechen und keine Pause machen, um etwas zu erklären. Lassen Sie sich von ihnen unterbrechen und Fragen stellen und beantworten Sie sie dann in etwas weniger Fachsprache, bis Sie einen Punkt erreichen, an dem sie verstehen oder (wahrscheinlicher) aufgeben.

Das Problem, das sie haben, ist ein Mangel an Vertrauen getrieben von mangelndem Wissen. Die meisten Menschen mögen es nicht, etwas nicht zu wissen, besonders wenn dieser Mangel an Wissen Vertrauen erzwingt. Und darin verlieren sie das Gefühl der Kontrolle und in vielen Fällen der Autorität. Meiner Meinung nach können Sie kein direktes Vertrauen aufbauen, aber Sie können Respekt vor Ihrem Wissen und Ihren Fähigkeiten aufbauen. Mir ist klar, dass es hart erscheinen mag, aber der einfachste Weg, dies zu tun, besteht darin, sie daran zu erinnern, dass Sie über die Fähigkeiten verfügen, die ihnen fehlen, um Ihre Arbeit zu erledigen.

Ich schlage nicht vor, dies zu tun alles andere als hilfsbereit und höflich , aber ich glaube, Sie haben sie wahrscheinlich verhätschelt, indem Sie es niedergeschlagen haben. Und wenn sie Sie bitten, Ihre Einschätzung zu stützen, stehen Sie dazu.

Es ist auch eine gute Idee, Ihren Fortschritt und Ihren erwarteten Zeitplan mitzuteilen.

In Ihrem OP haben Sie beispielsweise Ihren sechsstufigen Workflow beschrieben. Können Sie kurz (ihm / ihr) alles beschreiben, was sich in einer dieser Phasen der Fertigstellung befindet? Können Sie vorhersagen, wann als nächstes Fortschritte erzielt werden? Und so weiter.

Ich glaube nicht, dass Sie per se Ihren Prozess oder Ihren Fortschritt rechtfertigen müssen: wenn dies nicht bereits geschehen ist Wisse, dass du ein großartiger Ingenieur bist, du wärst nicht da. Sie können jedoch einen effektiven Statusbericht erstellen.

Denken Sie daran, was der Manager möchte und braucht. und nicht. Eine ausführliche technische Erklärung wäre für ihn / sie nutzlos ... dafür sind Sie da. Der Manager ist da, um das Projekt zu verwalten, den Vorgesetzten den Status zu melden und sicherzustellen, dass Sie über das verfügen, was Sie für eine effektive Arbeit benötigen.

Obwohl ich vielen Antworten zustimme, begegnen Sie gelegentlich jemandem, der sich einfach weigert zu glauben, dass Sie irgendwelche Arbeiten ausgeführt haben, es sei denn, er sieht ein fertiges Produkt. Sie müssen sich daran erinnern, dass viele nicht-technische Leute keine Ahnung haben, wie viel Code für die Herstellung eines Produkts erforderlich ist. Sie denken, die letzte Seite in der Anwendung ist das Ganze. Wenn es also keine Seite gibt, wurde keine Arbeit geleistet.

In diesem Fall überschwemme ich sie mit dem Code, den ich gemacht habe, und der Dokumentation der Forschung, die ich gemacht habe. Nachdem Sie ihnen gezeigt haben, dass Sie Tausende von Codezeilen, Hunderte von von Ihnen eingerichteten Datenbanktabellen und Hunderte von Forschungsseiten haben, lassen sie Sie in Ruhe. Der Schlüssel dazu ist nicht, den Code oder die Recherche Schritt für Schritt zu erklären, sondern ihnen nur zu zeigen, wie viel davon vorhanden ist, und ihnen anzubieten, ihn mit ihnen durchzugehen (sie werden im Allgemeinen entscheiden, dass sie dies nicht wirklich einmal tun müssen (

Beachten Sie, dass dies ein Sonderfall ist, den Sie nicht für den durchschnittlichen nicht-technischen Manager tun möchten, sondern nur für diejenigen, die sich weigern zu glauben, dass Sie etwas getan haben, nachdem Sie mehrmals versucht haben, auf nicht-technischer Ebene zu erklären.

Ich musste dies einige Male tun, um einen komplexen Fehler zu beheben, und die nicht-technische Person versteht nicht, warum Sie dies nicht in fünf Minuten tun können.

Nachdem sie die Komplexität des Codes gesehen haben (die sie nicht verstehen und die sie daher sehr einschüchtern), lernen sie im Allgemeinen, Ihrem Urteil zu vertrauen.