Schlechter Rat an den Entwickler: Was tun, um das Management zufrieden zu stellen?

Wie im vorherigen Artikel versprochen , drehen wir die Situation in die entgegengesetzte Richtung. Ich war nicht nur Entwickler, sondern auch führend auf verschiedenen Ebenen. Ich habe bereits erwähnt, dass ich in letzter Zeit Glück für Teams und Kollegen hatte. Aber für die ganze Zeit passierte alles.

Bild

(Grigory Oster)

Lassen Sie uns darüber sprechen, von welchen Entwicklern das Management träumt. Dieses Mal werde ich als abstrakter Manager auftreten ...

Zu Beginn eines Projekts ...


Wussten Sie, dass die höchste Fähigkeit eines Managers darin besteht, Entscheidungen mit minimalen Anfangsinformationen zu treffen? Halten Sie uns, Führungskräfte, nicht davon ab, diese Fähigkeit zu trainieren. Befolgen Sie diese Taktik:

  • Nennen Sie die nebligen Daten, aber sprechen Sie überhaupt nicht darüber.
  • Wenn wir fragen, ob die vorgeschlagenen Verbesserungen die vorhandenen Module nicht beschädigen, schweigen Sie zur Not und machen Sie einen mysteriösen Gesichtsausdruck!
  • Wenn Sie über die bevorstehenden Probleme des Projekts sprechen, bieten Sie niemals Ihre Lösungen an. Denken Sie daran, wir brauchen Fragen von Menschen, keine Lösungen für Menschenoptionen.
  • — , , ? 48- , 10 , .
  • — , .

Wenn Sie zum Zeitpunkt der Festlegung der Aufgabe zum Kunden zugelassen wurden, um ihm klärende Fragen zu stellen, lernen Sie aus DDoS-Angriffen - geben Sie Ihr Bestes. Der Kunde erwartet von Ihnen mindestens 50 Nachrichten mit Fragen, vorzugsweise im Detail - er wird Ihre Leistung im Epistolary-Genre zu schätzen wissen. Sie müssen keine Screenshots oder Videos anhängen - lassen Sie sie Ihre Nachricht entschlüsseln, auch wenn sie nur "Hallo!" Enthält. und ein langes "Tippen ...".

Denken Sie daran: Der Client und der Endbenutzer sind unterschiedliche Personen. Kommunizieren Sie niemals mit Endbenutzern und versuchen Sie nicht, sie sich vorzustellen! Wenn Tante Masha an der Kasse 25 Textzeilen auf dem Monitor sehen sollte, platzieren Sie sie ruhig, ohne auf die Bildschirmgröße zu achten. Lassen Sie die Lupe nehmen, wenn sie nicht mag.

Sagen Sie uns niemals, welche spezifischen Aufgaben innerhalb des Projekts gelöst werden. Sprechen Sie nur über Lösungsmethoden. Und es ist in allen Details wünschenswert - wie sonst würde CTO heute Nacht friedlich schlafen?

Erwähnen Sie in Ihrer Geschichte keinesfalls Geld, Zeit oder andere Kennzahlen, die andere verstehen. Schließlich kann sogar die Sekretärin des Regisseurs Geschichten über die verwendeten abstrakten Strukturen in Benutzerszenarien und die genaue Höhe des Gewinns, den wir erzielen, übersetzen. Verwenden Sie daher bei der Bewertung von Aufgaben das abstrakteste Mengen-System. Denken Sie daran, 1 Boa Constrictor ist 38 Papageien!

Ernten Sie so viele Überraschungen wie möglich. Neben der Zeit, um das Problem zu lösen, sind auch kostenpflichtige Abonnements oder Tools erforderlich, über die wir erst im letzten Moment Bescheid wissen. Wir lieben die Fallstricke und werden gerne vor der Veröffentlichung nach einem Ausweg aus der Sackgasse suchen. Mein Kunde und ich lieben es, das zugewiesene Budget wöchentlich zu erhöhen und es in allen Fällen ständig zu koordinieren. Führen Sie Ivan Tsarevich nach Beginn der Geschichte nach jeder Aktualisierung der Informationen darüber, wo Koshcheevs Tod gespeichert ist, durch eine neue Iteration.

Perfekter Code ...


Versuchen Sie, nur perfekten Code für den perfekten Code zu schreiben. Dies ist beim ersten Mal nicht erforderlich. Wenn Sie es eilig haben, schreiben Sie schnell, wiederholen Sie den Vorgang und wiederholen Sie den Vorgang. Denken Sie daran: Wiederholung ist die Mutter des Lernens. Wenn der Code dreimal umgeschrieben wurde und sich zumindest geringfügig vom Ideal unterscheidet, beginnen Sie dringend mit dem Refactoring als Teil einer kleinen Aufgabe, die für diese nicht gilt. Besser noch, übertragen Sie Ihren Code in eine andere Bibliothek oder ein anderes Framework. Lassen Sie den Code modisch und jugendlich sein. Die Hauptsache ist, dass in keinem Fall alle diese Prozesse als separate Aufgaben formuliert werden können. Und dann plötzlich vermuten wir, dass etwas für das Projekt nicht ideal war? Solche Dinge werden am besten kurz vor der Veröffentlichung erledigt. In diesem Moment arbeitet das gesamte Team viel schneller!

Apropos Refactoring. Es funktioniert effizienter, wenn Sie gleichzeitig die Mechanismen im Code ändern, um nicht zweimal dorthin zu klettern. Denken Sie daran, dass solche Prozesse so viele Komponenten wie möglich betreffen sollten. Warum Zeit in einzelnen Modulen verbringen? Nur so sehen Sie aus wie ein Held, der alle gerettet hat! Andere Entwickler werden sich freuen, die Überraschungen der neuen Mechanismen zu entdecken, wenn sie sie in den Fuß schießen.

Der perfekte Code sollte richtig formatiert sein. Versuchen Sie, Dateien mit maximaler Größe zu erstellen, die viele Bildschirme belegen und mehrere Komponenten gleichzeitig enthalten. Wenn Sie diesem Designstil folgen, können Sie Zusammenführungskonflikte heldenhaft überwinden und sich lange Zeit mit Kollegen einverstanden erklären, deren Änderungen wichtiger waren. Der Code sollte den längsten Nudeln ähneln, ohne dass Zeit damit verschwendet werden muss, kleine, unbedeutende Dateien zu erstellen. Überlegen Sie sich für eine Funktion einen Dateinamen - was könnte schmerzhafter sein?

Der perfekte Code, den Sie erstellt haben, ist nicht erforderlich, um Tests durchzuführen. Sie können nur über die Notwendigkeit sprechen, die Abdeckung auf 100% zu bringen, aber in Wirklichkeit reichen 10% aus. Um mit Ihnen Schritt zu halten, fügen Sie einige Tests hinzu, die tatsächlich nichts überprüfen. Dann müssen sie nicht aktualisiert werden.

Wenn sich plötzlich herausstellt, dass eine schnell geschriebene Lösung nicht oder nicht wie erwartet funktioniert, können Sie den Systemarchitekten, die API, den Serveradministrator usw. für alles verantwortlich machen. Es ist klar, dass Ihr idealer Code nur funktionieren kann. Denken Sie an die Hauptsache: Wir wissen wie Sie, dass ein idealer Programmierer nur unter idealen Bedingungen im luftleeren Raum arbeiten kann. Und wenn Sie abgelenkt sind, keine Informationen rechtzeitig geben, unverständliche TK schreiben, können Sie im Allgemeinen nicht dafür verantwortlich sein, dass das implementierte Modul die Geschäftsaufgabe nicht erfüllt. Richtig, das Geschäft liegt in unserer Verantwortung. Es ist ratsam, alle Namen der Schuldigen bis zum Stichtag aufzubewahren, sie werden später benötigt, jetzt lenken Sie die Führer nicht ab.

Wenn wir über die Notwendigkeit sprechen, MVP schnell freizugeben, können Sie unsere Versuche, das Projekt zum Nachteil von Qualität und Geschwindigkeit zu beschleunigen, ignorieren. Trotzdem wissen sie, dass man mit einer guten Idee jederzeit auf den Markt kommen kann. Die Zeit spielt keine Rolle. Lassen Sie die Konkurrenten scheißen, und wenn Sie den perfekten Code schreiben, wird unser MVP in 5 Jahren steigen. Und all diese Jahre werden Investoren gerne dafür bezahlen, mit ihrem Geld ein Meisterwerk zu schaffen.

Die Reihenfolge im Projekt ...


Ihre Aufgabe ist Ihre Persönlichkeit. Kreatives Durcheinander wird unseren Augen Gewicht verleihen. Die Fähigkeit, ein Chaos aufzubauen und es in einem ziemlich chaotischen Zustand zu halten, ist so wertvoll, dass wir sogar Projekte von Hand zu Hand übertragen, um den Grad der Störung zu erhöhen. Sobald das Chaos sein Maximum erreicht hat, werden wir Sie mit einem neuen Projekt belohnen!

Wenn Sie verstehen, dass sich im Projekt ein vollwertiges Durcheinander gebildet hat, Sie aber noch nicht umgezogen sind, beginnen Sie entweder, Ihre technischen Schulden mit Ihren Pfoten einzudämmen, oder fragen Sie selbst nach einem anderen Projekt. Vielleicht haben wir die Situation einfach nicht verfolgt.

Alles, was im Team passiert, muss durch uns gehen. Selbst wenn Sie sich dazu entschließen, mit dem Tester zu rauchen, stimmen Sie ihm über den Projektmanager zu. Es ist jedoch besser, den CTO daran zu beteiligen. Wir fühlen uns unnötig, wenn sich niemand über unsere Kollegen beschwert, Streitigkeiten innerhalb der Arbeitsgruppe nicht löst oder Arbeitsregeln einführt.

In Designfragen ist es ratsam, nur in PM zu schreiben. Dies wird alle Spuren unserer Aktivitäten vor dem höheren Management verbergen und uns gleichzeitig zwingen, die erarbeiteten Lösungen anderen Teilnehmern des Prozesses erneut zu erzählen. Wir lieben es so sehr!

Probleme lösen ...


Wenn Sie das Problem behoben oder den Fehler behoben haben, überprüfen Sie auf keinen Fall Ihre Lösung. Schreien Sie „Hurra“ und rennen Sie so schnell und weiter wie möglich vom Arbeitsplatz weg! So übergeben Sie die Aufgabe schneller und finden für das Team eine Lektion für die erste Hälfte des nächsten Sprints - Sie korrigieren die Pfosten der gerade gelieferten Aufgabe. Was wichtig ist, Sie berauben auch nicht die Arbeit Ihrer Testkollegen. Eine Reihe von Fehlern, die durch die neue Krücke in der Lösung verursacht wurden, ist das beste Geschenk am Freitagabend! Checken Sie in Ihrem Code nur einen erfolgreichen Fall ein, Sie sind ein Optimist.

Die richtige Reihenfolge der Aktionen bei der Lösung eines Problems:

  • TK lesen, Notizen ignorieren,
  • rauchen, um die Details zu vergessen,
  • schnell und ohne zu zögern nur die Grundfunktionen implementieren,
  • Übergeben Sie die Aufgabe genauso schnell
  • Erhalten Sie Revisionen mit klarer Entschlüsselung ungelesener TK-Notizen.
  • Beheben Sie das Problem in 3-4 Iterationen.

Kein Refactoring im Nachhinein, kein Kämmen von Code. Lassen Sie die Variablen im Moment der Einsicht so aufrufen, wie es Ihr linkes Bein wollte, und der Code bleibt schlecht gelesen. Sie müssen das später nicht verstehen! Trainieren Sie, um Ihren Code sofort zur Überprüfung zu bringen - Sie sind ein guter, aber empfindlicher Typ.

Zum jetzigen Zeitpunkt ist es unmöglich, Beweise dafür zu erstellen, dass die Aufgabe abgeschlossen wurde (oder sie erstellen manchmal ein Video, um über das Projekt zu schreiben, wie das Modul startet ...). Möglicherweise bemerkt der Tester keine Unstimmigkeiten mit dem TOR, oder die Aufgabe wird an eine andere gesendet, während Sie sich vorerst bei einer neuen Aufgabe entspannen können.

Wenn die Aufgabe beispielsweise mehrdeutige Momente enthält, ist nicht bekannt, ob das Eingabefeld gleichzeitig nur englische oder russische Buchstaben akzeptieren soll. Sie können die Fragen je nach Geschmack und Lebenserfahrung selbst beantworten. Da es nicht in der Arbeitserklärung steht, sollte dies für alle offensichtlich sein!

Und testen Sie niemals Hypothesen zu einem kleinen Teil der Aufgabe, sonst denken Ihre Kollegen, dass Sie Zweifel haben!

Wenn Sie es mit einer Aufgabe zur Freigabe eilig haben und wissen, dass einige Funktionen später ausgeführt werden müssen, müssen Sie keine Zeit damit verbringen, eine Aufgabe im Projektmanagementsystem festzulegen. Es ist besser, eine Notiz direkt in den Kommentaren zum Code zu machen und niemandem davon zu erzählen. Umso interessanter wird es, technische Schulden zu machen. Es wird das Gefühl geben, dass es viele davon gibt und Sie für das Projekt immer noch sehr gebraucht werden.

Bewahren Sie nicht mehr als die Hälfte der Dateien im Projekt-Repository auf! Kein Wunder, dass weltweit so viele verschiedene Lagerorte erfunden wurden. Es ist wichtig, die verbleibenden Dateien gleichmäßig zwischen den persönlichen Repositories der Mitarbeiter und beispielsweise der Dokumentation zu platzieren (nicht einmal unbedingt für das aktuelle Projekt). Das „geheime Wissen“ über das Projekt wird also zu gleichen Teilen im Team aufgeteilt und jeder wird unersetzlich sein. Und dann wird ein Neuling im Projekt kommen und es in dem bereits implementierten schnell herausfinden. Etwas, dem Sie an ihrem Platz nicht widerstehen können - jeder wird sofort durch billigere Jones ersetzt.

Jedes Projekt sollte geheimes Wissen haben, das von Mund zu Mund weitergegeben wird. Nur so können Sie ein Bild seufzen und spuckend sagen: "Oh, diese Junes arbeiten seit einer Woche, aber sie wissen nichts über das Projekt. Treten Sie zurück, machen Sie es selbst! "

Wenn Sie sich verpflichtet haben, eine Aufgabe von Jira auszuführen, ist es absolut nicht obligatorisch, diese zu kennzeichnen. Wir sind Medien - wir werden erraten, was Sie gerade tun, aber gleichzeitig werden wir den aktuellen Stand des Projekts erraten. Übrigens können wir dies mit der aufgewendeten Zeit tun - wir müssen nirgendwo etwas schreiben, wir werden die Anzahl der geleisteten Arbeitsstunden herausfinden und Ihr Gehalt berechnen.

Kommunikation zum Projekt ...


Hast du schon von Omnichannel gehört? Kommunikation ohne Aufteilung in verschiedene Kanäle ist der neueste Trend. Seien Sie im Trend! Wenn Sie Fragen haben, schreiben Sie eine PM an einen Boten. Es ist besser persönlich, kein Arbeiter - damit er weiß, dass Sie nicht hinter den neuesten Trends dieser Welt stehen. Aber Projektteams in Slack und anderen Boten werden am besten verwendet, um lustige Bilder mit Katzen und persönliche Gespräche zu senden.

Seien Sie zu spät für regelmäßige Treffen 15-20 Minuten. Besser noch, haben Sie ein Mikrofon aus der Sowjetzeit und WLAN nicht am Arbeitsplatz. Lassen Sie alle auf Ihr Quaken hören, es ist wie bei abstrakten Gemälden - jeder hört, was er hören möchte. Und bei der Tageszeitung können Sie alle Fragen stellen, die Sie zum Projekt haben. Wenn nicht genügend Designprobleme vorliegen, fügen Sie mehr offtopic hinzu. Im schlimmsten Fall kann man immer etwas Abstraktes fragen. Ein so gutes Beispiel zeigt am besten, warum Sie nicht gerne telefonieren und warum Sie besser nicht daran teilnehmen.

Vergessen Sie nicht, jeder Mensch hat Highspeed-Bluetooth im Kopf. Wenn Sie sich also schon alles in Ihrem Kopf vorgestellt haben, übertragen Sie einfach dieses Bild. Wörter können nur kleine Details erklären, die auf dem Bild nicht sichtbar waren. Lassen Sie sie versuchen, Sie zu verstehen, das ist ihre Aufgabe.

Es lohnt sich übrigens, zu spät ins Büro zu kommen, wenn Sie in unserem Gebiet arbeiten. Nur so können Sie einen Eindruck von Ihrer Wichtigkeit gewinnen. Und niemals davor warnen, zu spät zu kommen. Dies zeigt, dass Sie es eilig hatten, d. H. verwöhne dein Bild von einem ruhigen Guru.

Wenn Sie Ihren Arbeitsplatz verlassen, müssen Sie sich nicht um die Anordnung der Status in Slack oder anderen Instant Messenger kümmern. Jeder, der in Ihrer Abwesenheit schreibt (und eine Benachrichtigung einleitet), gibt einen Grund für einen langen und nachdenklichen Fluch an, dass Sie in Ihrer persönlichen Zeit abgelenkt werden. Wo sonst würden Sie einen solchen Grund finden? Lassen Sie Manager und Kollegen lernen, ihre schnellen Fragen vor Beginn Ihres offiziellen Arbeitstages zu sammeln (an diesem Tag gibt es etwas zu besprechen).

Erfahrungsaustausch ist überflüssig. Wenn Sie dennoch einen Link zu einem Artikel oder Framework im Bildungskanal in Slack veröffentlichen, müssen Sie keine Beschreibung dafür vornehmen. Lass es eine Suche für Kollegen sein. Sie wollen neues Wissen - lassen Sie sie sich anstrengen und verstehen, was Sie ihnen zugeworfen haben. Und es spielt keine Rolle, dass dies möglicherweise nicht ihr Gebiet ist. Und teilen Sie auf keinen Fall Ihre Projektbeobachtungen, interessanten Entscheidungen, Fehler und lehrreichen Schlussfolgerungen mit. Entwickler zu Entwickler Wolf. Sie müssen konkurrieren und dürfen keine gemeinsame Teamerfahrung entwickeln! Und ja, ich hätte es fast vergessen! Wenn Sie einen längeren Artikel finden, lesen Sie ihn nicht selbst, sondern legen Sie ihn Ihren Kollegen vor, vielleicht sind sie interessiert.

Die Arbeit anderer Entwickler kann und sollte kritisiert werden. Sie müssen an jeder Kleinigkeit etwas auszusetzen haben. Verwechseln Sie Kritik und Kritik einfach nicht. Es ist notwendig, ausführlich und geschmackvoll zu kritisieren (und vorzugsweise so abstrakt wie möglich, zum Beispiel: „Ihr Code ist schrecklich“), aber die Überprüfung so schnell wie möglich durchzuführen - klicken Sie auf das grüne Häkchen, ohne auf den Code zu schauen und keine Kommentare zu hinterlassen. Und dann müssen einige konstruktive Gründe für die Unzufriedenheit formuliert werden.

Übertragen Sie uns alle Verantwortung für Ihre Motivation und Weiterbildung. Wir ruhen uns schon für Sie aus, sogar Helmfotos aus verschiedenen Resorts. Lassen Sie sich auch von uns selbst motivieren. Es ist klar, dass im Projekt alle Aufgaben interessant sind und wir nur aus Schaden eine Routine für Sie finden. Und wir arrangieren absichtlich Anstürme, weil Sie in diesem Modus besser arbeiten. Wir schreiben Sie jedoch auch nicht aus Schadengründen in Kurse ein. Sie übertragen alle Ihre Bedürfnisse über Bluetooth, das in Ihr Gehirn integriert ist, an uns. Wir empfangen sie, ignorieren sie jedoch. Sie müssen nicht in Worte gefasst werden, wir fühlen sie trotzdem.

Gegen Ende des Projekts ...


Wenn wir Sie bitten, das Projekt dem Kunden zu zeigen, bereiten Sie sich auf keinen Fall im Voraus auf die Demonstration vor. Es ist allen klar: Wenn das Projekt auf Ihrem Laptop gestartet wurde, bedeutet dies, dass es zu 100% funktioniert und überall gestartet wird. Wir haben alle Glück!

Wenn der Kunde nach den Ergebnissen der Demonstration unglücklich ist und Sie einen bevorstehenden Konflikt verspüren, müssen Sie den Kunden in die Hölle schicken. Er versteht einfach nichts. Der Manager muss nicht informiert werden. Ein Konflikt mit einem Kunden ist übrigens der beste Grund, uns um mehr Geld zu bitten. Wir werden gerne zustimmen!

Das Erscheinungsdatum ist eine Fiktion. Wir lieben es einfach, diese Daten im Kalender zu markieren. In der Tat fehlt Managern, insbesondere auf der Fernbedienung, die Kommunikation. Die Verschiebung der Veröffentlichungstermine ist der beste Weg, um schnell 3-5 Meetings einzuberufen, an denen die Teilnehmer nicht teilnehmen möchten.

Wenn sich die Situation im Projekt erwärmt, ist es Zeit, Gerüchte aufzulösen, dass bald alles zusammenbrechen wird. Widme so viele Kollegen wie möglich deinen Annahmen, verbreite mehr Negativität. Wenn die Gerüchte gerechtfertigt sind, motiviert uns ihre Verbreitung, die Situation mit der Welle eines Zauberstabs zu korrigieren. Und wenn nicht gerechtfertigt, freuen wir uns, dass Sie noch in guter Verfassung sind.

Übrigens, wenn die Gerüchte nicht helfen, geraten Sie im Chor in Panik. Dies ist die konstruktivste Lösung. An diesem Punkt können Sie anfangen, böse Dinge über das Unternehmen zu sprechen, nicht nur innerhalb, sondern auch außerhalb (zum Beispiel bei Interviews). Dies wird definitiv dazu beitragen, die finanzielle Situation auszugleichen und starke Kollegen in Ihre Kollegen zu bringen!

Gegen Ende des Projekts können Sie es laut und effektiv verlassen und den Grund für das Verlassen des Projekts als zu niedriges Gehalt angeben, obwohl Sie seit so vielen Jahren im Projekt sind und für uns keine neuen Technologien berühren. Fühlen Sie sich frei, zu den Konkurrenten zu gehen - sie werden es zu schätzen wissen. Unsere Lieblingsaufgabe ist es, eine Woche vor der Veröffentlichung nach neuen Spezialisten zu suchen. Vergessen Sie uns nicht, wenn Sie zu einem anderen Unternehmen wechseln.

Erzählen Sie allen von einer Seite des Problems. Schweigen Sie über Ihre „Exploits“ und teilen Sie uns mit, welche Manager unfair sind. Versuchen Sie nicht, uns zu verstehen, sagen Sie es Außenstehenden. NDA hat sich Feiglinge ausgedacht!

Alle Fallstricke sollten nur als letztes Mittel gemeldet werden - wenn das Projekt nicht in Produktion gehen kann. Dies ist die beste Teambildung, wenn das Team in der Nacht vor einer wichtigen Veröffentlichung oder bereits in der Produktion gemeinsam das Feuer löscht. Entziehen Sie sich und dem Team dieses Vergnügens nicht!

Wenn Sie immer noch eine Veröffentlichung im Team erlebt haben und ein Fehler aufgetreten ist, können Sie am Ende der Warteschlange sicher Fehler in die Produktion einfügen. Sie sollten die gleiche Priorität haben wie alle anderen. Lass sie sich anstellen!

Nun, und wissen Sie, dass in der Nacht, nachdem der Entwickler zur Tankstelle ernannt wurde, bei ihm tiefe Metamorphosen auftreten. Er vergisst alle Bedürfnisse der Entwickler, wird kurzsichtig, autoritär, dumm und unzugänglich. Deshalb verstehen wir - Manager, Manager und Tankstellen - Sie, die Entwickler, so schlecht.

Artikelautor: Eugene Wetsel (imater)

PS Wie beim letzten Mal hat meine Geschichte nur gespenstische Übereinstimmungen mit der Realität. Und die Moral lautet: Berücksichtigen wir all diesen Sarkasmus und bauen Beziehungen im Team auf.

PPS Wir veröffentlichen unsere Artikel auf mehreren Runet-Websites. Abonnieren Sie unsere Seiten auf VK, FB, Instagram oder dem Telegrammkanal, um mehr über alle unsere Veröffentlichungen und andere Maxilect-Nachrichten zu erfahren.

All Articles