Wie effektiv man ein gutes Design in großen Meetings „verkauft“

Oft habe ich eine traurige Tragödie erlebt. Folgendes passiert:

1. Eine Überprüfung des Teamdesigns für ein neues Projekt.
2. Ich sehe ein einfaches Design mit einigen Löchern.
3. Ich erwähne beiläufig die Löcher und Möglichkeiten, sie zu vermeiden.
4. Die Warnungen werden ignoriert mit Kommentaren wie "das 'niemals' im wirklichen Leben passieren"
5. Schließlich passieren die Dinge, die "niemals" passieren werden
6. Eine Entwurfsprüfung des Notfallteams für ein defektes Projekt.

Also was mache ich? Mit der Einstellung "Ich habe es dir gesagt" können keine Freunde gewonnen und keine Menschen beeinflusst werden. Manchmal vergehen Jahre und die Kommentare aus Schritt 3 werden sowieso vergessen. Ich möchte definitiv nicht der nervige Schädling sein, der die Welt an die Fallstricke erinnert. Ich lehne mich oft zurück und sehe zu, wie die Titanic nach Europa segelt.

Es ist frustrierend, schlechte Designs voranzutreiben. Es ist auch frustrierend, dass ich andere offenbar nicht von der drohenden Gefahr des aktuellen Pfades überzeugen kann. Bei Teambesprechungen, bei denen jeder unterschiedliche Begriffe versteht, schneide ich am schlechtesten ab. Auch neigen Ego dazu, Vernunft und Gedanken zu gewinnen. Ich suche nach guten Taktiken, um Gruppen zu überzeugen, einige neue und komplizierte Ideen zu verwenden.

Wenn möglich, schlagen Sie Änderungen vor, die einem Projekt keine nennenswerte Zeit hinzufügen. Versuchen Sie zu betonen, dass eine spätere Überarbeitung viel schmerzhafter sein wird, wenn sie jetzt nicht durchgeführt wird. Es wird schwieriger sein, Ihr Team davon zu überzeugen, dass eine völlig neue Richtung besser ist, da dies wahrscheinlich das Projekt verzögert usw.

Versetzen Sie in einer Besprechung keine Personen in den Verteidigungsmodus, sie kämpfen nur gegen Sie, um der Gewinner zu sein. Sie werden sich nicht darauf einigen können, dass die Erde rund ist. Dies ist eine normale Politik (zB bei FoxNews)

Es hilft wirklich, den Respekt anderer Entwickler zu haben. Wenn Sie der neue Typ im Team sind, denke ich, dass Sie SOL sind. Bauen Sie also einfach einen Team-Repräsentanten auf und versuchen Sie wirklich, ein Level zu erreichen, bei dem Sie nicht von Anfang an entlassen werden. Natürlich, wenn Sie immer pessimistisch sind, dann werden Sie einfach als der "negative" Typ bezeichnet.

Achten Sie darauf, dass Sie bei einfachen Dingen (die sich nicht auf die Zeitpläne auswirken) die beste Arbeit leisten. Wenn Sie die Mühe in Ihre unmittelbare Ausgabe stecken (z. B. das Erstellen von Testfällen oder das Erhalten einiger einfacher (aber cooler) Funktionen), werden andere Leute möglicherweise bemerken, dass Ihr Code zuverlässig funktioniert und dem Test der Zeit standhält. Wenn du ihnen ein paar nette Tricks mit dem Code zeigst, überlegen sie sich zweimal, ob sie dich vor allen Leuten niederschießen sollen.

Schließlich stimme ich zu, dass Sie die Routine "Ich habe es Ihnen gesagt" nicht ausführen möchten, aber versuchen Sie auf jeden Fall, Ihrem Chef / Tech-Lead Hinweise zu geben, wenn Sie tatsächlich Recht haben. Senden Sie möglicherweise eine alte E-Mail mit Ihren alten Kommentaren erneut. Fragen Sie sie, ob dies zur Lösung des "neuen" Problems beitragen würde. Wenn Sie dies nicht tun, werden sie sich nicht einmal daran erinnern, dass Sie derjenige waren, der es zum ersten Mal erwähnt hat. Irgendwann werden sie den Hinweis bekommen, dass Sie nicht nur versuchen, in den Meetings zu protzen. Das nächste Mal werden sie zweimal überlegen, ob sie dich umhauen sollen, besonders wenn es darum geht, dass dein "altes" Design jetzt das derzeit kaputte ersetzt.

Versuchen Sie, einen Ruf als die Person aufzubauen, die identifizieren kann, was funktionieren wird, und nicht nur, was Ihrer Meinung nach in einigen seltenen Fällen ein Problem darstellt. Wenn Sie diese potenziellen Probleme sehen, betrachten Sie sie einfach als Fußnote, die möglicherweise später behandelt werden muss.

In Gemeinden werden die Leute verrückt. Erwähnen Sie Ihre Bedenken einer Schlüsselperson außerhalb des Meetings. Sie sehen dies als weniger bedrohlich an und nehmen sich möglicherweise die Zeit, Ihre Argumentation anzuhören, anstatt darüber nachzudenken, wie sie das Design verteidigen. Es kann auch länger dauern, bis sie Ihnen die Umstände erklären, unter denen Sie möglicherweise einen gültigen Punkt haben, aber eine Behandlung in Version 1.0 ist nicht möglich.

Schlüssel! Nehmen Sie an der Besprechung teil und verstehen Sie genau, was für eine Agenda Ihr direkter Vorgesetzter hat. Vielleicht sehen sie dies als ein kleines Projekt und das Letzte, was sie bei dem Treffen brauchen, ist ein Neinsager, der sich Zeit nimmt, um sich von wichtigeren Themen zu lösen. Bitten Sie sie, Ihnen zu helfen.

Wenn Sie sie beeinflussen möchten, sprechen Sie außerhalb des Designtreffens mit ihnen darüber. Andernfalls denken sie nur, dass Sie versuchen, von ihnen "Punkte zu sammeln". Viele Leute wollen niemals echte Diskussionen in einer Besprechung mit einem "Publikum" führen.

Ich verstehe nicht, wie sehr sich diese Situation von einem einzelnen Entwickler mit einem ahnungslosen Chef unterscheidet. Leider habe ich die Anzahl der Fälle, in denen ich "überzeugt" war, ein Projekt auf eine bestimmte Art und Weise zu bauen und es zu versenden, trotz meiner Warnungen vor dem bevorstehenden Untergang, verloren. So können Sie nicht nur bauen, sondern die sprichwörtliche Titanic ganz alleine in einen Eisberg segeln.

Wie Sie beschrieben haben, waren meine Warnungen längst vergessen, als die Teile in den sprichwörtlichen Eimer fielen. Manchmal ging es (zum Glück für mich) Monate oder länger schlecht, nachdem ich nicht mehr an dem Projekt beteiligt war. Leider dachte mein Nachfolger, dass ich verrückt sein muss, da man darauf wetten kann, dass der Chef jede Hand bestritt :)

Wie auch immer, eine Gruppe von 'überzeugten' Programmierern kann genauso ahnungslos sein wie ein Chef mit spitzen Haaren, manchmal sogar noch mehr, weil sie selbstbewusst ahnungslos sind, wie Jeff O erwähnt . In diesem Fall haben Sie ausreichend Zeit, um die Probleme zu beheben. Versuchen Sie nicht, eine einzige Stimme der Vernunft über einen kollektiven Hirnfurz hinweg zu hören. Wenn Sie das effektiv tun können, ist Ihr Platz im Kongress, nicht hinter einer Schreibtischschreibsoftware.

Da Taten mehr sagen als Worte, können Sie:

• Zeigen Sie (mit Testszenarien), warum das Design unter normalen Umständen fehlschlägt. Dies wird wahrscheinlich zu einer kleineren Besprechung führen, in der Sie als Präsentierender anwesend sind, und ist wahrscheinlich alles, was Sie brauchen, um gehört zu werden.

• Zeigen Sie ein konkurrierendes Produkt, das adäquat auf das eingeht, was die Gruppe für "Eckfälle" hielt. Sie werden erstaunt sein, inwieweit Google beispielsweise Fehler in seinem Tabellenkalkulationsprogramm antizipiert.

• Wiederholen Sie das letzte Projekt, für das eine Woche vor dem geplanten Versand eine Grunderneuerung erforderlich war.

Mit anderen Worten, der erste Schritt, egal was Sie tun, ist es, mit Einzelpersonen oder einer (viel) kleineren Gruppe umzugehen. Wenn Ihre Bedenken wirklich zutreffen, bin ich sicher, dass sie in ein oder zwei Wochen in der Entwicklung besser ankommen werden. Vermeiden Sie einfach, wie Sie bemerkt haben, die Haltung "Ich habe es Ihnen gesagt".

Wenn möglich, überprüfen Sie den Entwurf vor (oder sogar nach) der Besprechung und sprechen Sie privat mit den Designern. Wenn Sie Leute in einer Besprechung vor all ihren Kollegen abschießen, werden sie in der Regel sofort defensiv und verschlossen gegenüber Ihren Vorschlägen und können zu einem Ruf als "Trouble Maker" werden, auch wenn Sie glauben, dass Sie hilfreich sind.

Eine gute (aber oft schwierige) Möglichkeit, "Kritik" zu äußern, besteht darin, Leitfragen zu stellen. Lassen Sie die andere Person versuchen, Ihre Frage zu beantworten und den Fehler selbst zu erkennen. Dann scheint es viel eher ihre eigene Idee zu sein und sie werden sie mit größerer Wahrscheinlichkeit vorantreiben. Auch dies funktioniert am besten in privaten Gesprächen, kann jedoch in einer Besprechungssituation eine diplomatischere und effektivere Möglichkeit sein (Hinweis: Vermeiden Sie Auseinandersetzungen oder lange Diskussionen, um die Teilnehmer der Besprechung zu überzeugen. Machen Sie sich einfach ein Bild und versuchen Sie es Es ist vielleicht besser, nach dem Treffen loszulassen und sich mit den Designern zu unterhalten, um "etwas zu klären, was ich nicht ganz verstanden habe", als der Typ zu sein, der eine einfache 30-minütige Arbeit geleistet hat treffe mich den ganzen Morgen ")

Ein anderer Ansatz besteht darin, Ihre Vorschläge (diplomatisch) per E-Mail an den leitenden Designer (oder eine relevante, aber kleine Verteilerliste) zu senden. Es kann Ihnen dabei helfen, Ihre Ideen zu überdenken, und gibt Ihnen auch einen "Papierpfad", um jede "Ich habe es Ihnen gesagt" -Situation in der Zukunft zu unterstützen ignoriert. Aber wenn es so schlimm wird, arbeiten Sie wahrscheinlich nicht in der richtigen Firma.)

Denken Sie zum Schluss daran, dass Sie manchmal "falsch" liegen können. Die Leute, mit denen Sie sprechen, haben möglicherweise ein klareres oder vollständigeres Verständnis ihres Designs als Sie und haben gute Gründe für ihren Ansatz (zum Beispiel wurde ich kürzlich von einem Teammitglied beschuldigt, ein "ineffizientes" Design zu erstellen, aber Es war ein bewusstes Design, da ich wusste, dass die Leistung noch akzeptabel sein würde, aber die Entwicklungskosten halbiert würden - es war eher eine Geschäftsentscheidung als eine Entscheidung über die Codequalität. Versuchen Sie einfach, offen für die Ideen anderer zu sein. Manchmal ist eine schlechte Idee aus Gründen, die Sie nicht berücksichtigt haben, eine gute Idee.

Wenn Sie auf das Szenario "Das wird niemals passieren" stoßen, erinnern Sie sie an alle früheren Zeiten, in denen sie die "Das wird niemals passieren" -Elemente reparieren mussten. Aber du musst aufpassen, dass du nicht so rüberkommst wie "Ich habe es dir gesagt". Ich finde es am effektivsten, frühere Probleme (und wie teuer und schmerzhaft sie zu beheben waren) zur Sprache zu bringen, um zu diskutieren, warum Sie der Meinung sind, dass wir jetzt etwas für dieses Projekt tun sollten wird nie passieren "Zitat.

Ich denke, vielleicht ist Ihr Problem, dass Sie sagen, Sie erwähnen beiläufig einen Weg, um ein Problem zu vermeiden. Vielleicht sollten Sie mit mehr Informationen bewaffnet sein und ihnen detaillierter zeigen, warum dies ein Risiko für das System darstellt. Manchmal heißt das, das Thema in einem zweiten Meeting zur Sprache zu bringen, nachdem Sie Zeit hatten, ein wenig nachzuforschen. Erstellen Sie einen Business Case für die Kosten, die später anfallen.

Klingt so, als ob Sie am besten daran arbeiten, sich eine Team-Lead-Position zu sichern. Nutzen Sie diese Möglichkeiten, um auf die Kräfte hinzuweisen, die Sie gesehen haben und die vermieden werden könnten. Sie sollten Ihr aktuelles Team dabei nicht verkaufen müssen.

Das "beiläufige" in "Lässig die Löcher erwähnen" scheint ein Problem zu sein. Versuchen Sie, einen notierten Prozess zur Analyse von Projektrisiken zu verwenden (oder einzubringen, falls er nicht vorhanden ist). In der Regel ist das Ergebnis einer Risikoanalyse-Besprechung eine einfache zweispaltige Tabelle: Das Risiko und die vereinbarte Strategie zur Risikominderung ("Wir denken, dass niemals etwas passiert") sind eine akzeptable Minderung. Wichtig ist, das aktuelle Denken aufzuzeichnen zu dem Thema zu der Zeit). Stellen Sie sicher, dass Ihre Probleme als Risiken erfasst werden. Risiken sollten regelmäßig überprüft werden. Es besteht die Möglichkeit, dass sich schon lange vor dem Eintreten der Krise einige Personen zu Ihrem Standpunkt geäußert haben; Wir wären wahnsinnig, so weiterzumachen wie dieser "Katalysator". Längerfristig ist ein Papierpfad ein nützlicher Beweis dafür, dass "wir scheinen hier ein institutionelles Problem zu haben" und dass wir Einstellungen zum Design oder was auch immer geändert haben.

So setzen Sie Ihre Idee (n) um

Erstens in Besprechungen beziehen sich Probleme auf Herausforderungen. Sie beheben Probleme, Sie überwinden Herausforderungen. Herausforderungen sind gute Dinge, Probleme nicht.

Beginnen Sie langsam und wenden Sie diese Technik bei jeweils einer Herausforderung an. Wenn Sie das nächste Mal möchten, dass Ihr Chef eine Ihrer Ideen übernimmt, gehen Sie wie folgt vor:

• Entwickeln Sie drei ähnliche, aber unterschiedliche Ansätze
• Sagen Sie Ihrem Chef, dass Sie seine Hilfe bei etwas brauchen
• Erklären Sie, dass Sie nicht sicher sind, welche der drei Methoden die beste Vorgehensweise zur Lösung des Problems ist
• Bitten Sie ihn / sie, Ihnen bei der Auswahl eines der drei zu helfen

1. Das ist extrem mächtig. Was Sie tun, ist, Entscheidungen zu treffen, die kein Ultimatum sind. Ultimaten werden öfter nicht abgeschossen, weil es nicht ihre Idee ist und es nur eine Option gibt.

2. Ihre Verwendung von Wörtern ist hier sehr wichtig. " Ich brauche deine Hilfe ".

3. Lassen Sie den Chef "A", "B" oder "C" wählen. Lassen Sie den Chef die Option "D" erstellen, indem Sie Abschnitte aus "A", "B" und "C" herausziehen. Was Sie tun, ist, Ihren Chef eine Wahl treffen zu lassen.

An dieser Stelle ist es Ihnen egal, welche Option er auswählt, denn es sind alles Ihre Ideen. Er wird denken, dass er das Problem tatsächlich löst, weil Sie die Entscheidung seiner überlassen.

Habe Proof of Conceptvon deiner Idee umgesetzt. Wenn Sie Ihrem Team etwas zeigen, das funktioniert und das aktuelle Problem löst, wird es den Mitarbeitern gefallen.