Wenn Sie als Entwickler arbeiten, sehen Sie immer wieder, wie Teamleiter auf einem Haufen Anrufe sitzen, für alles verantwortlich sind, so viel Code schreiben wie Sie und gleichzeitig kein Geld mehr haben. Entweder ideologische oder Idioten werden sich dafür entscheiden.
Ich bin kein Idiot, meine Ideen drehen sich nicht um Geschäftswerte, also abonnieren Sie mich nicht. Aber wir werden nicht immer danach gefragt. Zuerst wurde ich als erster und einziger Entwickler für ein wiedergeborenes Startup eingestellt, dann wurde mir gesagt, ich solle mehr Leute einstellen, und dann war ich für drei Entwickler, zwei Tester und einen Analysten verantwortlich.
Kurz gesagt, alles ist noch schlimmer als es von außen aussah.
Jeden Tag warten sechs Personen darauf, dass Sie ihnen sagen, was sie tun sollen. Dann werden Sie ihnen sagen, wie es geht, und dann werden Sie auch bewerten, ob Sie es gut gemacht haben. Die siebte Person am Ende des Tages wird auch fragen, was Sie selbst getan haben. In dem Sinne, dass Sie sich selbst codiert haben und was jeder der Menschen getan hat, für die Sie verantwortlich sind.
Ich habe mich hier einmal beschwert, dass die Anrufe eine Krücke sind, mit der Sie kontrollieren können, ohne sich damit zu beschäftigen, und jetzt bin ich wieder einmal davon überzeugt, dass ich Recht hatte. Sie kommen mit einer Frage zu mir - und ich habe keine Ahnung, was ich beantworten soll. Wir rufen uns gegenseitig an, und eine Person entlockt ohne meine Teilnahme eine Antwort aus meinem unglücklichen Gehirn. Ich bin auch nicht bereit, meine Fragen zu formulieren - ich habe keine Ahnung, was ich sie stellen soll. Also rufe ich einfach an und beobachte, wie sich alles beruhigt. Und noch besser - ich stelle sicher, dass sie sich gegenseitig anrufen, ohne mich. Seit einem Monat kann ich eine ziemlich einfache Aufgabe nicht mehr abschließen, weil mein Gehirn von den Führungsaufgaben und vor allem von der Tatsache, dass ich nicht weiß, wie ich sie ausführen soll, erschöpft ist.
Ich dachte, okay, so sollte es sein. Ich habe nicht studiert, um Manager zu werden. Dann schaute ich auf meine Vergangenheit, erinnerte mich an alle meine Hinweise und plötzlich wurde mir klar - niemand studierte! Keiner von ihnen wusste, wie man damit umgeht. Sie maskierten es auch mit endlosen Telefonanrufen und Aufschub. Sie wussten nicht, was sie mir antworten sollten, sie wussten nicht, wohin wir gingen, sie wussten überhaupt nicht, was los war und wer was tat.
Als ich zwei Monate lang eine einfache Aufgabe erledigte und jeden Tag lügte, dass ich große Schwierigkeiten hatte und es dort ein ernstes Problem gab - und dann stellte ich eine Pull-Anfrage für vier über Nacht skizzierte Dateien -, schalt mich niemand, nicht weil es ihnen leid tat. Sie hatten einfach keine Ahnung, was ich dort tat. Und sie sahen sich meinen Code Zeile für Zeile an - um der Benennung auf den Grund zu gehen und saftige Anti-Muster zu finden -, aber sie gingen nicht darauf ein. Weil es keine Zeit gibt, sich damit zu beschäftigen, möchte ich nicht, und es ist nicht klar, warum.
Alle meine früheren Chefs haben Agilität angenommen und vergöttert - es ist eine große Reihe von Krücken, ein Spiel, das einer Gruppe von Menschen hilft, die keine Ahnung haben, was los ist, so zu tun, als wäre alles in Ordnung, und wir bewegen uns vorwärts.
Ich arbeitete mit einheimischen Teamleitern aus der Provinz zusammen, die in seriösen Teams nicht einmal zum Layout zugelassen wurden. Ich arbeitete mit coolen Entwicklungsmanagern ausländischer Top-Unternehmen zusammen und mit Leuten, die jemand als echte Genies in der Programmierung betrachtete.
Und alle, wenn es um Management ging, saßen auf dem Arsch. Ich habe die Regeln dieses Spiels in meinem ersten Job mit Agile gelernt. Wir riefen uns jeden Morgen an und alle sagten, was sie taten, taten und tun werden. Beim ersten solchen Anruf kam mir die Idee, dass ich mich melden und beweisen sollte, dass ich mein Brot nicht umsonst esse. Ich begann eine lange, sehr lange Rede über meine Aufgabe und erklärte ausführlich, warum sie noch nicht fertig war und womit ich jetzt zu kämpfen habe. Ich wurde in der Mitte unterbrochen: „Phil, willst du etwas von uns? Nein? Okay, wir haben alle herausgefunden, wer als nächstes kommt? "
Die Person, die uns kontrollierte, musste nur eines wissen - ob ich ihm heute Probleme bereiten würde oder nicht. Muss er heute Zeit mit mir verbringen? Bevor ich anfing zu sprechen, hatte er bereits die perfekte Rede für mich im Kopf: "Alles, was diesem Plan entspricht." Jede andere Entwicklung von Ereignissen ist für ihn rein böse.
Es gibt noch eine andere Option. Als das Problem nicht von mir, sondern von anderen Teilen des Systems zu ihm gebracht wurde, ist der agile Zeitplan schlecht, und jetzt kann er bei seinem Treffen für Leads nicht sagen, dass alles nach Plan läuft - und wird auch zu einem Problem von jemandem. Das macht mich automatisch zu seinem Problem und er klopft an die PM.
Wir fangen an, über etwas zu diskutieren, und wir verstehen beide - wir müssen einen Weg finden, um keine Probleme mehr zu sein. Es hat nichts mit dem Produkt oder Projekt zu tun. Wir haben ein verdammtes Ticket, das wir umziehen müssen. Und wir bewegen es - auf einfachste Weise. Wir reparieren es mit dem Code, setzen es in das Norepro, setzen das Label "blockiert von" - was auch immer. In diesem Moment ist uns das Produkt absolut egal, wir haben ein Ticket. Oder viele Tickets.
In jedem Team, in dem ich gearbeitet habe, gab es zwei Realitäten. Eine Realität ist ein echtes Produkt und echte Menschen, die es verbessern, weil sie es wollen. Und dann war da noch Jira, der absolut parallel zu all dem existiert. Und die einzige Person, die den tatsächlichen Status des Projekts mit den Karten synchronisieren kann, ist der Teamleiter.
Alle Teamleiter, mit denen ich zusammengearbeitet habe, wissen nicht, wie es geht - und sie wollen es nicht. Sie arbeiten so, wie sie arbeiten, und sie verwenden Jiru, um ihre Führungsverantwortung als erfüllt zu betrachten. Schließlich schauen sich Leute, die Teamleiter bewerten, Jira an, nicht das Produkt. Und Leute, die sich das Produkt ansehen, können nur neue Tickets für die Jira generieren. Sie können keine Programmierer bewerten. Aber Jira beeinflusst nichts! Ich habe schreckliche Produkte gesehen, deren Kanban-Board in einwandfreiem Zustand war, und großartige Produkte, die drei Monate lang Tickets in der Spalte „bei der Arbeit“ mit dem Titel „Projekt erstellen“ hatten.
Das Argument „Ich habe gesehen“ ist nicht sehr gut, aber es wird es tun, weil ich mir ziemlich sicher bin, dass Sie alles auch gesehen haben.
Im weitesten Sinne sollte ein Teamleiter sicherstellen, dass Menschen, die wirklich arbeiten wollen, keine Probleme haben. Und Leute, die weder rausschmeißen noch in die erste Kategorie versetzt werden wollen. Der ganze Schmerz des Managements liegt in der zweiten - es gibt noch viel mehr. Und niemand macht etwas mit ihnen. Nur ein Entwickler kann angemessen feststellen, ob ein Entwickler gut funktioniert. Dies ist eine sehr verständliche Geschichte - Sie müssen seine Pull-Anfragen gründlich prüfen und sich mit seinen Aufgaben befassen, und es gibt ein Problem: Sie kostet so viel Zeit, wie es kosten würde, alles selbst zu erledigen. Kurz gesagt, keine Option.
Daher waren es reine Manager, nicht Entwickler, die beschlossen, schlechte Entwickler zu identifizieren. Sie entwickelten eine Reihe von Systemen mit Tickets, Charts, allerlei Leistungsbeurteilungen und einem solchen Hut. Und es würde sogar bei einigen dummen funktionieren. Aber selbst die schlimmsten Entwickler sind intelligent genug, um dieses System zu täuschen. Nun, Sie wissen, wie es gemacht wird. Sie messen alles in Tickets, oder? Cool. Ich werde das "Neugestalten der Oberfläche des X-Formulars" in zehn Aufgaben im Stil "Fixieren der Beschriftung in der Y-Schaltfläche" zerlegen. Der gleiche Arbeitsaufwand, mehr Tickets. Der Teamleiter würde mir für solche Feinheiten ins Gesicht treten.
Aber im gegenwärtigen System wird er das niemals tun. Denn je mehr Tickets geschlossen sind, desto weniger Probleme gibt es. Zweitens ist es selbst genug geladen, um in meine Tickets und meinen Code zu graben. Drittens macht er es selbst - aufgrund seiner Führungsaufgaben fehlt ihm auch die Kraft, gute Leistungen zu erbringen. Und viertens, und das ist das Wichtigste, kann er einer der Menschen sein, die nicht arbeiten wollen.
Dies ist meine Erfahrung, die Erfahrung aller meiner Bekannten - aber es gibt Ausnahmen. Es gibt Unternehmen, in denen der Entwicklungsprozess wirklich gut funktioniert. Ich sage dir warum - sie haben im Lotto gewonnen. Es stellte sich heraus, dass viel mehr Menschen arbeiten wollen - mit Menschen wie Ihnen, die es nicht schaffen, wird alles gut gehen. Sie verwenden sogar Management-Lametta mit Boards für Unternehmen, und ihre Leistung ist sowohl durch JIR als auch durch intuitive Metriken deutlich sichtbar. Und wenn ihre nicht entwickelten Manager in die Quere kommen, haben sie ein großartiges Produkt hinter sich, das ihnen das Recht gibt, diese sprechenden Köpfe in die Hölle zu schicken.
Solche Teams replizieren sich selbst - während des Einstellungsprozesses genehmigen sie intuitiv nur Personen wie sie und sie haben genug Gewicht im Unternehmen, um HRs, die ihre „Metriken“ und Psychologie spielen, keine entscheidenden Worte zu geben.
Aber solch ein Team ist fantastisches Glück. Und was normalerweise passiert, ist dies. Für zehn Personen haben Sie zwei, die arbeiten möchten. Einer von ihnen ist ein Teamleiter und der andere gibt auf. Die Entwicklung funktioniert schlecht und Manager kommen, um sie zu beheben. Und von diesem Moment an wird es keine Chance mehr geben. Manager werden einen Prozess um Jira aufbauen und die Kontrolle über Dinge übernehmen, die sie überhaupt nicht verstehen. Sie werden eine Einstellung von Leuten aufbauen, von deren Arbeit sie nichts wissen, sie werden dort bestehende Entwickler einladen, die ChSV amüsieren, diesmal in den Zeitbericht einloggen und zufälliges Feedback geben. Und dann entscheiden sie - wen sie einstellen wollen - auch nach dem Zufallsprinzip. Menschen, die arbeiten wollen, werden von Zeit zu Zeit in solche Teams eintreten, in denen sie sich entweder in Faulenzer verwandeln oder keine Wurzeln schlagen.
Ich meine nicht, dass Manager Idioten sind und nichts tun können. Sie wissen immer noch, wie man damit umgeht. Aber nicht von Entwicklern. Entwickler können nur von einem Entwickler gesteuert werden, der wirklich weiß, wie man verwaltet. Eine solche Person wird das Team mit einem beliebigen Verhältnis von Bereitschaft und Unwillen zur Arbeit fixieren.
Das einzige Schade ist, dass sie fast nicht existieren. Um ein guter Entwickler zu werden, muss man klug sein und viel lernen. Um ein guter Manager zu werden, muss man Talent und viel Lernen haben. Und wie groß ist dann die Chance, dass eine Person diese beiden Eigenschaften kombiniert? Das ist dasselbe. Gleichzeitig sind die meisten Teamleiter in der Branche zu ihnen geworden, denn jemand sollte es tun. Absolut zufällig.
Ich denke, Sie müssen lernen zu verstehen, dass Entwicklung eine Fähigkeit ist, Management die zweite Fähigkeit und Entwicklungsmanagement die dritte Fähigkeit, die Teile der ersten umfasst. Und dies sollte separat untersucht werden. Und sehr methodisch und effizient. Bis wir dies tun, werden wir Entwickler haben, die Entwickler nicht verwalten können, und Manager, die Entwickler nicht verwalten können.
Werbung
Viele Kunden haben bereits die Vorteile der epischen Server von Vdsina erkannt .
Dies sind kostengünstige VDS mit AMD EPYC-Prozessoren und einer CPU-Kernfrequenz von bis zu 3,4 GHz. Mit der maximalen Konfiguration können Sie fast jede Idee verwirklichen - 128 CPU-Kerne, 512 GB RAM, 4000 GB NVMe. Sie können auch bestellen!
