👩🏾‍🤝‍👨🏿 ♂️ 🍆 Vom Entwickler zum Manager und umgekehrt 💅 🍜 🥥

Im Winter 2012 schlug ein Kollege vor, dass ich, ein C ++ - Programmierer mit fünfjähriger Erfahrung, die erste Anwendung für Android schreibe. Ein Jahr später begann ich, ein kleines Team von mobilen Entwicklern zu leiten, und seitdem ist die Größe meiner Teams stetig gewachsen. Aber letztes Jahr, nach 2 Jahren als Leiter der mobilen Entwicklungsabteilung, habe ich mit meiner Lieblings-IDE wieder Staub geblasen.

Lassen Sie uns Ihnen sagen, wie es auf der anderen Seite war, warum ich im Alter von 30+ (Spoiler) zu den Entwicklern zurückgekehrt bin und es nicht bereue.

Weg zu Android-Entwicklern

Android, das zu dieser Zeit eine Spielerei in meiner Provinzstadt war, schien mir ein weiteres lustiges „Spielzeug“ zu sein, mit dem man es sicher fallen lassen und zum üblichen Qt zurückkehren konnte. Und so fing alles an: Ein Freund brachte die Idee einer einfachen Anwendung zur Bilanzierung von Einnahmen und Ausgaben auf den Tisch, wir begannen sie in unserer Freizeit zu sehen, und sechs Monate später war MVP zur Veröffentlichung bereit.

Unser Money Keeper hatte ein eher primitives Design, aber eine gut durchdachte UX: Einnahmen oder Ausgaben wurden mit einem Klick erfasst - tippen Sie auf das Kategoriesymbol und öffnete sofort ein Fenster zur Eingabe des Betrags.

Ich erinnere mich sehr gut, wie ich Download-Statistiken gesehen habe: Die erste Person, die meine Anwendung heruntergeladen hat, war jemand aus Ägypten. Und dieser hat die Anwendung in derselben Woche nicht gelöscht, sondern weiter verwendet!

Nach und nach, mehrere Dutzend Downloads pro Tag, wuchs das Publikum, die Bewertung wuchs, die ersten positiven Bewertungen erschienen. Zu sagen, dass es inspirierte, war herunterzuspielen. Ich antwortete auf die Bewertungen auf dem Markt, plante eine Weiterentwicklung basierend auf den Wünschen der Benutzer, einfach weil meine Anwendung von den Benutzern benötigt wird, danken sie und setzen fünf. Und all unsere Werbung war in einem einzigen Beitrag auf w3bsit3-dns.com.

Es war auch bemerkenswert, wie sehr sich die mobile Entwicklung von der Entwicklung eingebetteter Systeme und Desktop-Anwendungen unterscheidet, an denen ich zuvor gearbeitet habe. Der Anwendungspfad zum Benutzer und sein Feedback ist sehr kurz. Das Publikum ist riesig und alles, was Sie tun, sollten Sie zumindest gut machen, sonst wird die Anwendung von niemandem benötigt und die ganze Arbeit kann weggeworfen werden.

Wie ich ein Teamleiter wurde, "weil jemand etwas fällig ist"

Die Anwendung wuchs und wurde komplizierter, eine kostenpflichtige Version mit zusätzlichen Funktionen erschien. Mein Paar Hände für die Entwicklung von zwei Anwendungen hat aufgehört zu reichen, insbesondere angesichts der Tatsache, dass ich sie in meiner Freizeit aus dem Hauptwerk geschrieben habe. Es gab kein spezielles Budget für die Einstellung von Mitarbeitern, da die Monetarisierung nicht so viele Einkommen brachte.

Wir lehnten die Idee ab, eine kostenlose Anwendung für eine kostenpflichtige „einzufrieren“, weil wir die dankbare Benutzergemeinschaft, aus der wir die ganze Zeit Energie und Ideen für die Entwicklung bezogen hatten, nicht enttäuschen wollten. Aus diesem Grund haben wir uns entschlossen, ein kleines Gehalt für zwei Männer anzunehmen, die weit von der Entwicklung entfernt waren, und uns verbrannt, um darin einzubrechen. Es wurde beschlossen, sie auf meinem Weg zu führen, aber mit einem signifikanten Unterschied: Ich musste ihnen beibringen, wie man sich in der Welt des grünen Roboters bewegt und navigiert und ihnen alle Unebenheiten und Löcher zeigt, die ich auf dieser Straße kannte.

Bild

Ich habe keine Angst , auf schwierige Aufgaben zu übernehmen)

Ich wollteandere Leute teilten meine Begeisterung für die Entwicklung, und selbst zwei Paar Hände waren für uns eindeutig nicht überflüssig. Ich ging zu ihnen nach Hause, erklärte, lehrte, beriet, half. Ich habe Aufgaben gestellt und deren Umsetzung überprüft. Also wurde ich leise ein kleiner aber Manager.

Die Anwendung musste jedoch geschlossen werden ... Ich ging zu einem Startup, dann zu einem anderen und kam dann zur Produktentwicklung in einem großen Unternehmen. Überall dort, wo nicht genügend Leute für die Hauptrolle anwesend waren, gab es ein ungefähr ähnliches Szenario: „Sie haben den Themenbereich herausgefunden, sich mit dem Team angefreundet, sind nicht gegen Führungsarbeit und haben überhaupt solche Erfahrungen? Versuchen wir, Aufgaben für andere Personen festzulegen. Zumindest in diesem Sprint ... “

Aber es gab noch einen weiteren wichtigen Aspekt: Ich dachte an die Zukunft - und es schien neblig.Vor sehr langer Zeit bin ich auf einen Artikel über das Durchschnittsalter von Entwicklern gestoßen. Es heißt, dass die "Spitzenkarriere" des Entwicklers auf 27 Jahre fällt. Ich bemerkte ähnliche Artikel - und fragte mich unwillkürlich: Was werde ich als Entwickler zum Beispiel mit 32 tun, wenn „eine junge Scheiße kommt, die uns vom Erdboden wischt“? Ist es nicht besser, langsam den Weg zu Managern zu beschreiten und das „30-Jahre-Problem“ selbst zu lösen?

Meine Prinzipien als Timlida

Als ich C ++ aufgab und zu Android ging, hatte ich bereits mit verschiedenen Führungskräften zusammengearbeitet und wusste genau, welche Art von Führungskraft ich sein wollte. Und später in völlig anderen Teams: Produkt (bestehend aus Analysten, Designern, Entwicklern, Testern) und Entwicklungsteams - ich habe versucht, nicht von meinen Prinzipien abzuweichen.

Müssen mit denen arbeiten, die sind

Ein Student mit brennenden Augen, der nach einiger Zeit auf den richtigen Weg geschickt wird, kann mehr Vorteile für das Projekt bringen als ein „Rockstar“.

Bei einem der Projekte entschied ich, dass es Zeit war, sich vom bekannten MVP + Dagger + RxJava-Bundle zu entfernen und in der Produktion die Tools zu testen, die Google zur Erstellung moderner mobiler Anwendungen empfiehlt. Wir planten, die empfohlene Architektur nur mit Jetpack und Kotlin mit Coroutines zu implementieren.

Alle erfahrenen Entwickler und Chefs drehten ihre Finger am Tempel und sagten, dass wir mit einem Team von zwei Jones, die noch nie etwas von dem von mir ausgewählten Stapel verwendet hatten, das Projekt füllen würden und die Verantwortung persönlich bei mir liegen würde. Aber diese beiden Joons waren erfreut, dass sie mit dem zusammenarbeiten würden, was Android-Entwickler erst gestern im Blog geschrieben haben.

Bild

Ja, natürlich haben wir am Anfang eine Reihe von Kinderkrankheiten bei Alpha-Versionen von Bibliotheken entdeckt ...

Aber die Jungs haben hart gearbeitet, sind in die Quelle geklettert und haben Probleme mit Github studiert, nachts profiliert und am Ende haben wir:

sauberer, stabiler und pflegeleichter Code,
erfolgreiches Produkt in der Produktion,
und eine Menge von unschätzbarer Erfahrung.

Bei einem anderen Projekt kam ein sehr cooler Entwickler ins Team, der sich nicht sofort mit dem gesamten Team anfreundete, sondern die Aufgaben perfekt absägte. Die Jungs kontaktierten ihn durch Schmerzen, Tränen und Chefs, und jemand sagte sogar, dass es besser wäre, jeden Juni anstelle von ihm zu nehmen, aber am Ende reduzierte ich die Live-Kommunikation zwischen ihnen auf das notwendige Minimum und alles wurde ruhig.

Sie müssen auch mit "Rockstars" arbeiten, egal wie schwierig es manchmal ist.

Natürlich gibt es Leute, die ihren Job nicht wissentlich machen: Jemand denkt, dass er zum "Chef, der alles für mich tun wird", jemand es kann oder will einfach nicht funktionieren. Wenn Gespräche und Zeit nicht helfen, sollten Sie keine Angst haben, sich von diesen zu trennen.

Ich arbeite nicht mit Untergebenen, sondern mit Menschen

Jeder hat seine eigenen Umstände, Bedürfnisse, Temperamente und Stimmungen. Einmal, bevor sie einen schwierigen Sprint bestanden hatte, kam ein Testermädchen, von dem alle auf das Ergebnis der Endprodukttests warteten, wegen eines Skandals mit ihrem Ehemann, der keine sauberen Socken finden konnte, wütend zur Arbeit. Frist, dies ist nicht der erste Tag intensiver Tests, aber hier ist es. Sie hatte überhaupt nicht die Stimmung zu arbeiten. In dieser Situation war es möglich zu zerschlagen, zu fordern und zu bedrohen. Aber ich habe versucht, es zu verstehen und die Ressourcen anderer Tester so zu verteilen, dass die Lücke geschlossen wird. Nach einem halben Tag kühlte es ab und wir investierten erfolgreich in Zeit.

Bild

Wer vor den Ferien während der Arbeitszeit nicht auf anderen Baustellen saß, ließ den ersten einen Monitor auf mich werfen)

Oder eine andere Geschichte: Ein Kollege hörte einige Tage vor den Ferien auf, etwas zu tun, einfach weil er mit den letzten Versammlungen für eine Radtour nach Europa beschäftigt war, die er fast ein Jahr lang vorbereitet hatte. Das ganze Jahr über hat er akribisch Arbeitsaufgaben erledigt und hier - als Ersatz. Und ich gab ihm diese zwei Tage. Nach zweiwöchigen Ferien kehrte er ausgeruht zurück und machte sich im gleichen Tempo an die Arbeit, aber ich schaffte es nicht, die Beziehung im Team zu zerstören.

In einer schwierigen Situation wird niemand vorwärts gehen, wenn ich nicht führe

In einem für mich neuen DevOps-Team habe ich mich einige Monate lang mit der Bereitstellung von CI „dynamisiert“, und die Entwickler haben die Implementierung offen sabotiert, ohne den Argumenten über ihre Nützlichkeit zuzustimmen. Es ist nicht so, dass sie faul rückläufig waren, es schien mir nur, dass sie in der Umgebung, in der CI richtig vorbereitet wurde, nicht funktionierten.

Ich umarmte mich mit Google, saß abends und wählte die Einstellungen aus. Allmählich wurden DevOps und die Entwickler in den Prozess einbezogen. Infolgedessen konnten wir CI und die erforderlichen Bindungen für das Erstellen und Verteilen von Anwendungen konfigurieren, was schnell und leise zum Standard für verschiedene Teams im Unternehmen wurde.

Schließe ich die Lücken in der Organisation von Prozessen durch persönliches Eingreifen und Mikromanagement? Könnte sein. Aber es scheint mir, dass es in einer solchen Pattsituation zwei Extreme gibt: „Ziehen Sie die Schrauben fest“, entfernen Sie sich immer mehr vom Team und werden Sie zum „Chef“, oder versuchen Sie, einer Person zu helfen, wenn es für sie schwierig ist, selbst wenn sie ihre Arbeit abgeschlossen hat und „seine“ wird. Aber sie lassen "ihre" nicht in Schwierigkeiten.

Sie müssen sich selbst entwickeln und alle im Team entwickeln

Typischer Arbeitsplatz einer Führungskraft.

Je länger ich in einem Projekt saß, desto mehr spürte ich, dass die moderne Entwicklung an mir vorbeischwebte. Ein Stapel von Technologien, Sprachen und Frameworks wurde vor einigen Jahren ausgewählt und hat sich seitdem nicht wesentlich geändert. Dies war auf ewige brennende Daten, schwaches Geschäftsinteresse zurückzuführen, aber vor allem auf die Angst der Entwickler vor etwas Neuem, wenn es ein so bekanntes altes gibt.

Es kam zu dem Punkt, dass es den neu akzeptierten Entwicklern verboten war, in Kotlin zu schreiben, weil die führenden Programmierer ihn nicht kannten und nicht die Zeit fanden (nicht finden wollten?), Ihn zu unterrichten. Diese Probleme wurden ganz einfach gelöst: Ich hielt technische Gespräche, Meetings und Kurse zu Themen, die für das gesamte Team interessant waren. Für Entwickler ist es einfacher und interessanter, eine Woche lang eine Technologie für ein Haustierprojekt zu sortieren und den Rest darüber zu erzählen, als sie blind in die Produktion zu ziehen.

Und für ein Unternehmen ist es einfacher, eine Gehaltserhöhung für eine Person zu rechtfertigen, die etwas Neues und Nützliches für das gesamte Unternehmen studiert und einführt.

Von Entwicklungsproblemen kann man nicht weit kommen

Sobald Sie die Probleme der Entwickler mit technischen Schulden, Plattformfunktionen und der Interaktion zwischen verschiedenen Teilen des Systems nicht mehr verstehen, sinkt der Prozentsatz der Sprints.

Es gab Fälle, in denen Manager wirklich überrascht waren, dass es unmöglich war, eine iOS-Anwendung an Silvester zu veröffentlichen, weil die Apple-Rezensenten an einigen Feiertagen waren. Designer verstehen manchmal die Probleme von Android-Entwicklern mit dem Satz auf verschiedenen Bildschirmen nicht. Backender, die zuvor noch nicht mit mobilen Clients gearbeitet haben, müssen erklären, dass sie anstelle von JSON keinen Fehler in Form einer HTML-Seite angeben müssen.

Und wenn Sie solche Momente bei der Entwicklung des Systems oder seines Teils „durchschauen“, können die Konsequenzen für die Fristen sehr bedauerlich sein.

Bild

Oh, wie viel Gutes kann man einfach erreichen, wenn man technische Lösungen übernimmt. Und selbst wenn sie die Aufgaben zum Verteilen geben - Sie können Berge rollen!

Habe ich es geschafft zu führen?

Ich nehme nicht an zu sagen, dass dies die richtigen Prinzipien sind. Ich weiß nicht einmal, ob sie dem entsprechen, was sie in den Büchern über Personalmanagement schreiben, weil ich keine von ihnen gelesen habe. Ich urteile nach mehreren Tatsachen:

Die Beziehungen im Team verbesserten sich. Wenn es vor mir Skandale mit der Klärung der Beziehungen zu den Behörden gab, dann mit mir - maximal kleine Scharmützel.
Im Allgemeinen passen wir in Sprints. Sogar das Unmögliche. Und wenn sie nicht passten, dann nicht so sehr, dass der Kunde wütend war. Das ist natürlich das Verdienst des Teams. Aber wahrscheinlich ein bisschen meins. Ich habe immer versucht, alle Risiken zu berücksichtigen und die Aufgabenplanung unter Berücksichtigung dieser Risiken durchzuführen.
Wir haben die Produkt- und Entwicklungsprozesse ständig überarbeitet und verbessert, die technische Verschuldung ist gesunken.
Entwickler wuchsen an Rang und Gehalt.
Meine direkte Anleitung war auch hübsch.

Okay, was ist mit den Nachteilen der Führung?

Für mich sind sie:

Je mehr Sie Manager sind, desto weniger Entwickler. Egal, wie Sie versuchen, die Feinheiten des technischen Teils des Projekts im Auge zu behalten, sie entziehen sich Ihnen jeden Tag weiter und weiter. Und je größer das Team und je aktiver die Entwicklung, desto schneller. Allmählich wurde das Volumen neuer Informationen über Android und iOS auf das Lesen von Versionshinweisen neuer Betriebssystemversionen und einigen Artikeln über Habré pro Monat reduziert.
. — , . , “” . .
. . , . - - , .
. , . , 2-3 . - — 70-80% !

!

Egal wie es Ihnen an einem Ort gefällt, Sie müssen irgendwann gehen. Und irgendwann fing ich an, nach einem neuen Job zu suchen. Vorhersehbar wollte ich in ein noch größeres Unternehmen einsteigen, um die Entwicklung fortzusetzen.

Das nächste Skype-Interview fand statt: 10 Interviewer, 2 Stunden , Anforderungen - Kenntnisse des technischen Teils der Senior Developer-Ebene und der Fähigkeit, Menschen zu verwalten. Und nach 2 Stunden wurde mir klar, dass ich im Umgang mit Menschen fast nichts weiß. Zumindest kenne ich die Theorie nicht und stütze mich nur auf meine Prinzipien und Erfahrungen.

Es sah ungefähr so aus:

— ?

— .

— ?

— , . , .

— ?

— …

— , scrum kanban?

— .

— ?

— …

Gut und so weiter. Ich habe die Theorie nicht bestanden. Es ist mir irgendwie gelungen, umzusetzen, aber die Grundprinzipien zu erklären, warum auf die eine oder andere Weise getan werden musste - nein. Nach dem Interview wurde mir klar, dass ich meine Obergrenze in der Amateur-Management-Liga erreicht hatte und dass es nicht funktionieren würde, weiter auf zwei Stühlen zu sitzen. Um mich zu entwickeln, musste ich entscheiden, wohin ich gehen möchte.

Bild

Dies ist mein aktuelles Auswärtsteam für Remote-Mitarbeiter. Mindestens eine weitere Person ging den gleichen Weg: ging zu Teamleitern und kehrte bewusst zu den Entwicklern zurück.

Der erste Weg führt zu Managern. Lesen Sie trotzdem die sehr richtigen Bücher. Sehen Sie sich Videos an und nehmen Sie an Management-, Planungs- und Motivationskonferenzen teil. Die professionelle Managerliga hat ihre eigenen Regeln und Besonderheiten.

Zweiter Weg- Tauchen Sie in die Entwicklung ein und holen Sie nach Möglichkeit über die Jahre des Managements auf.

Nun, der dritte Kompromiss besteht darin, die Theorie zu „ziehen“ und zu versuchen, weiterhin „in der Mitte“ zu sein und noch einige Jahre „in Amateuren“ zu hängen.

Und dann erinnerte ich mich, wie alles begann. Mit dem Gefühl, dass Sie die Welt verändern und etwas Nützliches für andere tun. Selbst wenn Sie den Knopf grün gestrichen haben und er für Tausende von Benutzern etwas schöner wurde. Auch wenn ich einen Tippfehler korrigiert habe. Und wenn Sie bereits eine Funktion heruntergespült haben, die von den Benutzern lange erwartet wurde, und Ihnen in den Kommentaren dafür gedankt wird, ist dies nur eine Explosion von Emotionen und guter Laune für ein paar Tage!

Habe ich durch meine Arbeit als Manager ein so starkes Gefühl erfahren? Ich denke nicht. Auch wenn Kunden, Team und Führungskräfte Sie loben. Und wenn Benutzer die erwartete Funktion loben, ist dies natürlich in erster Linie demjenigen zu verdanken, der sie vorbereitet, gesägt, getestet und angezeigt hat. Und ziemlich viel - meins als Manager.

Deshalb habe ich einen angenehmen Arbeitsplatz gefunden, schreibe Code und bereue es bisher nicht.
Gibt es Leben in Entwicklern mit 32? Es gibt!

PS

Was hat mir als Entwickler die Erfahrung von Führung gegeben?

Jetzt verstehe ich Business und PMA auch ohne Worte besser. Oft weiß ich, welche Frage sie mir stellen wollen.
Ich plane die Zeit und Aufgaben kompetenter unter Berücksichtigung von Risiken.
Kontrast. Nachdem ich gesehen hatte, wie es auf der anderen Seite war, wurde mir klar, was ich an diesem mag.

Vom Entwickler zum Manager und umgekehrt