Timlid oder Hin und zurück

Unter den Entwicklern gibt es diejenigen, die nicht nur schönen Code schreiben, sondern auch effektive Praktiken erstellen möchten, die die Teamarbeit vereinfachen. Einige sind deprimiert, nachdem sie die geschätzten Lorbeeren des Zeitlids erhalten haben, in einen Strudel ständiger Kommunikation geraten sind, alltägliche Probleme gelöst haben und, oh mein Gott, die Gelegenheit verloren haben, denselben schönen Code zu schreiben. Und unser AppsCast- Gast Sergei Boishtyan ging den anderen Weg und kehrte, nachdem er die Realitäten des Lebens des Teamleiters gekostet hatte, in die Reihen der Ingenieure zurück. Warum Timlidismus nicht jedermanns Sache ist und warum Wachstum im Dialog mit Sergey nicht immer ein neues „kleines Ding“ auf dem Ärmel ist.



Alexey Kudryavtsev: Hallo allerseits. Sergey, erzähl mir ein paar Worte über dich?

Sergey Boishtyan: Im Moment bin ich ein leitender Entwickler, ich war ein leitender, technischer Experte und nur ein Entwickler. Ich arbeite in Avito, davor in Tinkoff.

Daniil Popov: Lassen Sie uns zunächst klären, wer der Entwickler ist, welche Verantwortung er hat und was er bei der Arbeit tut.

Über die Entwicklerrolle

Sergey Boishtyan: Entwickler ist in erster Linie eine Rolle, keine bestimmte Position. Es gibt viele Leute in der IT, die gleichzeitig andere Funktionen entwickeln und ausführen können.

Zu Beginn der Reise konzentriert sich der Spezialist auf die Entwicklung und baut dann Verantwortung auf: Er trifft sich mit Testern, Designern und trifft architektonische Entscheidungen.

Entwickler - eine Rolle, in der ein Ingenieur bei der Implementierung von Produktfunktionen hilft.

Dies ist entweder ein Produkt für den Endbenutzer oder direkt für Entwickler. Zum Beispiel habe ich in den letzten anderthalb Jahren Produkte für Entwickler innerhalb des Unternehmens hergestellt.

Daniil Popov: Wofür ist der Entwickler verantwortlich?

Sergey Boishtyan: Die CI / CD-Praxis wird immer beliebter und es liegt in der Verantwortung des Entwicklers, die Funktion zu übernehmen, selbst zu implementieren, Automatisierungstools zum Testen zu verwenden oder mit der Person in Kontakt zu treten, die sie testet und ihre Veröffentlichung kontrolliert.

Daniil Popov: Kurz gesagt: Bringen Sie die Aufgabe in Jira von ToDo zu Closed durch alle 500 Status.

Sergey Boishtyan: Wenn Sie vom Gegenteil ausgehen, dann sind die Entwickler nicht die Ingenieure, denen ihre Funktion egal ist. Solche Personen senden Pull-Anfragen, sind jedoch nicht daran interessiert, Funktionen freizugeben. Sie möchten den Code nicht ändern oder Konflikte beseitigen.

Über die Bedeutung des Teams

Daniil Popov: Die Aufgabe des Entwicklers ist es, sicherzustellen, dass Benutzer die Qualität und Effizienz des Codes genießen. Was ist dann ein Team, welche Aufgaben löst es? Unterscheiden Sie zwischen Arten von Teams?

Sergey Boishtyan: Sie können Teams betrachten, bei denen sich die Mitarbeiter in ihren funktionalen Verantwortlichkeiten unterscheiden, und Teams, bei denen sich die Mitarbeiter in ihrer Verantwortung unterscheiden.

Ich bin ein Fan von Universalteams, in denen jeder über ein bestimmtes Fachwissen verfügt, aber weiß, wie man alles macht, und Engpässe automatisiert werden. In solchen Teams sind die Menschen gleich, kommunizieren ständig und treffen gemeinsam Entscheidungen.

Es gibt Teams, in denen jedes seinen eigenen Verantwortungsblock hat. In ihnen schreibt der Entwickler erstens den Code und unterstützt gegebenenfalls den Tester, der für die Qualität des Produkts verantwortlich ist.

Alexei Kudryavtsev: Ich habe gehört, dass dies nicht agil ist.

Sergey Boishtyan: Im Prinzip kann dies eine normale Geschichte sein, die sich historisch entwickelt hat. Aber ich persönlich mag es, wenn es Leute im Team gibt, die ähnliche Verantwortlichkeiten haben und die Verantwortung je nach Sprint gemischt ist. Jetzt hat unser Team mehr als zehn Services in der Entwicklung, jeder benötigt sein eigenes Fachwissen und Wissen. In einem Sprint machst du eine Sache, in einer anderen eine andere, und auf jeden Fall musst du kommunizieren, da Wissen und Entwicklung ständig ausgetauscht werden. Wenn Sie nur Entwickler, Tester oder Designer sind, graben Sie nur in eine Richtung.

Daniil Popov: Ich persönlich mag das Konzept des „gemeinsamen Codes - gemeinsame Verantwortung“ nicht. Es scheint, dass diese Praxis dazu führt, dass niemand verantwortlich ist. Was denkst du?

Sergey Boishtyan: Kürzlich bin ich in dem Buch auf einen Satz gestoßen: „Wenn es mehr als ein verantwortliches Team gibt oder überhaupt nicht, wird nichts passieren, da niemand Verantwortung übernehmen möchte.“

Ich mag den Ansatz, wenn alles gemeinsam ist, aber Sie haben einen klaren Fokus für eine Woche oder einen Monat.

Wenn wir einen Sprint planen, ist jeder für seinen Teil verantwortlich, entwickelt ihn und erkennt, dass er es tun sollte. Natürlich kann bei häufigen Änderungen der Verantwortlichen viel Zeit für den Kontextwechsel aufgewendet werden. Gleichzeitig gibt es immer einen OUNER einer bestimmten Funktionalität, der das Backlog verwaltet. Wie lange diese Verantwortung darauf liegt, hängt vom Produkt ab.

Alexei Kudryavtsev: Ich glaube, dass das Teilen von Verantwortung nicht funktioniert. Wenn jemand mit der Initiative nach denen sucht, die zur Sache kommen wollen, wird er sie nicht finden, da jeder denkt, dass jemand anderes dies tun wird.

Sergey Boishtyan: Um die gemeinsame Verantwortung endgültig zu begraben, werde ich ein Beispiel aus dem Leben geben. Normalerweise gibt es eine Pull-Anfrage, die eine Art Modul „berührt“. Wenn dieses Modul keine Verantwortung trägt, werden alle Prüfer, die glauben, dass der andere einen nützlicheren Kommentar hinterlassen wird, kurz hineinschauen. Infolgedessen wird der Code zu einem Hash. Und die Antworten auf die Fragen "Warum ist es so?" Erscheinen: "Ich habe es getan, niemand hat mir etwas geantwortet, ich habe entschieden, dass es effektiv ist", und dann entwickelt sich daraus der Satz "es ist so passiert, fass es nicht an".

Über die Grundaufgaben eines Teamleiters

Daniil Popov: Wir nähern uns allmählich dem Konzept des „Führens“ als Person, die diese Verantwortung auf sich selbst konzentriert. Was sind die Verantwortlichkeiten einer solchen Person?

Sergey Boishtyan: Blei ist auch eine Rolle. Seine Aufgaben variieren je nachdem, in welchem ​​Team er ist. Wenn es sich um ein Team handelt, in dem alle gleich sind, führt der Leiter die Teammitglieder, da es für sie oft schwierig ist, einen Konsens zu erzielen. Dann besteht die Hauptaufgabe des Lead darin, Streitigkeiten zu einem produktiven Ende zu bringen. Wenn eine Frage auftaucht, schließen Sie sie so schnell und effizient wie möglich. Blei hilft anderen, ihre Meinung zu äußern, und bleibt unparteiisch, da sie auch über Fachwissen verfügen. Von außen mag es scheinen, dass Scrum-Master diese Rolle spielen können. Nach meinem Verständnis ist der Scrum-Master im Allgemeinen auf der Seite und kann Besprechungen erleichtern, aber ich möchte, dass diese Rolle beim Teamleiter bleibt.

Wenn die Funktionen im Team klar voneinander getrennt sind, wird der Teamleiter auch zu der Person, der der Prozess gehört. In jeder Phase versteht er, wer was tut und was dafür verantwortlich ist.

Sie sagten mir oft, dass Teamleiter eine Art Dach zwischen einem Unternehmen und einem Team ist, weil jeder nur seinen Block kennt, aber ich möchte eine Person haben, die über den aktuellen Status des Produkts Bescheid weiß.

Alexei Kudryavtsev: Ich habe den Eindruck, dass die Führung alles macht. Sie sind Architekt, Scrum-Master und müssen Menschen finden und fördern können. Dies ist eine riesige Sammlung. Dies ist nicht eine Rolle, sondern mehrere. Wo ist die Wahrheit hier?

Daniil Popov: Das Wichtigste ist, dass Sie nicht gleichzeitig programmieren.

Alexei Kudryavtsev: Nun, Sie versuchen es.

Daniil Popov: Das Schlüsselwort ist "versuchen". Ich habe drei Zeilen geschrieben, sie haben dich abgelenkt und das wars.

Sergey Boishtyan: Blei ist eine Person, die Löcher in ein Team stopft . Jedes Team, unabhängig vom Format, hat Probleme, und die Verantwortung für sie muss auf jemanden übertragen werden.

Alexei Kudryavtsev: Es scheint mir, dass der Leiter mit Menschen und ihrer Motivation zusammenarbeitet, aber es gibt einen separaten Architekten, der für den Code verantwortlich ist.

Daniil Popov: Ich unterscheide zwischen den Konzepten „Teamleiter“ und „Technisches Team“. Tehlid ist die Person, die für die technische Seite des Produkts verantwortlich ist: welche Bibliotheken, Muster zu verwenden, welche Infrastruktur anzuwenden ist. Bei Timlid geht es um Personalmanagement. Diese Rollen überschneiden sich nicht. Sie können versuchen, diese Rollen zu kombinieren, aber es ist sehr schwierig, der Architektur und 1: 1 parallel zu folgen.

Timlid ist der Teamleiter, der das Team in eine glänzende, benutzerfreundliche Zukunft führt.

Sergey Boishtyan : Kehren wir zur Definition von „Team“ zurück, bei der viele Leute eine Sache tun. Um etwas effizient zu machen und ein Team zu bleiben, benötigen Sie einen Teamleiter, der ein einziges Ganzes aus unterschiedlichen Ingenieuren formuliert und es ermöglicht, das Potenzial aller zu nutzen und das Produkt besser zu machen.

Daniil Popov: Wenn es in einer Fabel einen Timlid über einen Schwan, einen Flusskrebs und einen Hecht gegeben hätte, hätten sie ihn dorthin gezogen, wo er sollte.

Woher kommen die Timlids?

Daniil Popov: Es ist interessant zu verstehen, wie sie zu Teamleitern werden. Ich warf vier Wege. Erstens: Der Teamleiter ernennt den besten Entwickler. Zweitens: Ernennen Sie die erfahrensten. Drittens: Ernennung für andere Verdienste, aber nicht für was. Nun, die vierte Option, wenn der Entwickler selbst an die Spitze geht. Welche dieser Optionen halten Sie für sinnvoll?

Sergey Boishtyan: Ich werde mit meiner Erfahrung beginnen. Irgendwann wollte ich mehr Verantwortung haben und Einfluss darauf nehmen, was geschah. Ich habe oft etwas angeboten und schließlich festgestellt, dass man nicht anbieten kann, aber sofort auf der anderen Seite sein kann. Sie sagten mir, dass ich pünktlich nachgedacht habe, seit das Projekt begonnen habe, und sie gaben mir die Möglichkeit, mich als Teamleiter zu versuchen. Es gab die Hypothese, dass ich als verantwortungsbewusster Entwickler ein guter Teamleiter sein würde.

Sie haben zwei Möglichkeiten: Wenn die Initiative von Ihnen kommt und wenn sie von außen kommt. In meinem Fall kam sie von mir, aber ich sah die gegenteilige Situation in den benachbarten Teams. Sie nahmen einen erfahrenen Entwickler aus dem Team und argumentierten, dass er die Kultur bereits kenne und zu kommunizieren weiß. Niemand lehnte ab, wie sie denen anboten, die verstanden, dass wenn nicht er, dann niemand anderes.

Daniil Popov: Ich habe die gegenteilige Erfahrung. Mein Teamleiter ging weg und sie machten mich zum Teamleiter. Es wird angenommen, dass ein erfahrener Entwickler ein guter Teamleiter wird, aber dies ist eine grundsätzlich falsche Annahme. Kürzlich habe ich die Idee gelesen, dass man den besten Entwickler verliert und einen schlechten Manager bekommt, wenn man den besten Entwickler zum Teamleiter macht. Stimmen Sie zu

Sergey Boishtyan: Es klingt nach der Wahrheit. Ich habe nicht so viele gute Teamleiter getroffen. Als Menschen mochte ich sie alle, aber oft war ich nicht glücklich darüber, wie sie ihre Rolle spielten. Es schien mir, dass ich es besser machen kann. Jetzt, da ich weiß, dass ich es nicht kann, habe ich klare Kriterien für einen guten Vorsprung gebildet.

Wenn Sie Menschen zuhören können, wissen, wie man aufgeschlossen ist und wie man die Gedanken anderer Menschen vermittelt, dann ist dies bereits auf halbem Weg. Der Rest kommt mit Übung. Aufgrund des ständigen Stresses lernen Sie Zeitmanagement und Aufgabenpriorisierung.

Wenn jemand weiß, wie man kommuniziert, den Fokus hervorhebt und über gute technische Fähigkeiten verfügt, werde ich ihm auf jeden Fall raten, sich in der Rolle des Teamleiters zu versuchen.

Wachstumsprobleme

Daniil Popov: Und wohin soll man sich weiter bewegen? Leiter Mobile, CEO, CTO?

Sergey Boishtyan: Warum irgendwohin ziehen?

Daniil Popov: In unserem postsowjetischen Raum gibt es die Meinung, dass man immer irgendwo wachsen muss. Wenn Sie nicht wachsen, hat das Leben umsonst gelebt. Und Sie können nur mit einer Erhöhung der Position mit einer neuen Linie wachsen. Das habe ich auch schon früher gedacht und dann festgestellt, dass dies ein optionaler Weg ist. Was bedeutet Wachstum für Sie?

Sergey Boishtyan: Einmal habe ich über die Klassifizierung von Einflussbereichen einer Person gelesen, bei denen Wachstum eine Zunahme eines der Einflussbereiche bedeutete - beruflich, finanziell, sozial, familiär und gesundheitlich. Vor sechs Monaten habe ich den Schwartz Value Questionnaire kennengelernt. Dann konnte ich nicht verstehen, ob ich ein Führer sein will oder nicht. Ich suchte nach Fragebögen und Tests und versuchte herauszufinden, welcher der Bereiche für mich wichtig ist. Ob ich ein berühmter Entwickler oder ein großes Gehalt sein möchte oder eine Work-Life-Balance, und es ist mir egal, auf welchem ​​Niveau ich bin.

Laut dem Schwartz-Fragebogen stellte sich heraus, dass es für mich wichtig ist, professionell zu sein, Anerkennung zu haben und eine Familie zu haben. Mir wurde klar, dass ich gerne an einer technisch herausfordernden Aufgabe arbeite, eine Präsentation mache oder in einem Podcast aufzeichne. Wenn Sie sich jedoch für die Vorbereitung einer Rede oder die Ausführung einer Aufgabe bei der Arbeit entscheiden müssen, werde ich mich für Letzteres entscheiden.

Es ist wichtig zu verstehen, dass diese Werte dynamisch sind. Es kommt nicht vor, dass du dein ganzes Leben lang ein cooler Profi sein willst. Irgendwann werden Sie den Punkt erreichen, erneut an der Umfrage teilnehmen und es stellt sich heraus, dass Ihre Priorität jetzt die Familie ist.

Sie müssen wachsen und sich entwickeln, um glücklich zu sein.

Es ist nur so, dass Menschen oft wachsen und sich in die falsche Richtung entwickeln, weil sie nicht erkennen, was für sie wirklich wichtig ist.

Alexei Kudryavtsev: Es stellt sich heraus, dass es am wichtigsten ist zu verstehen, wo Sie wachsen.

Über die Vor- und Nachteile der Teamführung

Daniil Popov: Lassen Sie uns herausfinden, was Ihnen in Ihrer Rolle gefallen hat und was nicht.

Sergey Boishtyan: Zuerst erkläre ich etwas mehr, warum ich ein Führer werden wollte. Als ich zur Entwicklung kam, war ich von dem, was ich bekam, begeistert. Dann stieg ich in das Team ein und Probleme mit Pull-Anfragen aufgrund von Missverständnissen und Missverständnissen. Ein rationales Gespräch hat nicht geklappt, aber im Inneren bestand der Wunsch, alles effizient zu erledigen. In solchen Situationen rief ich um Hilfe, aber er war nicht genug für alle.

Mir kamen die Gedanken in den Sinn, dass das Team allgemein anerkannte Prinzipien und Praktiken haben sollte, die entweder vom Team oder vom Leiter entwickelt wurden. Ich dachte, dass ich für die Rolle des Teamleiters Praktiken entwickeln werde, die allen gefallen, denen alle schnell zustimmen und die nicht mehr in Konflikt geraten. Mit einem solchen Gedanken im Kopf fing ich an, Bücher über Verhandlungen zu lesen, und stieß auf Schopenhauer . Es war eine gute Idee, dass Menschen keine Argumente hören können und unabhängig zu Schlussfolgerungen kommen müssen. Indem Sie Ihre Meinung durchsetzen, verursachen Sie nur den Wunsch, sich zu verteidigen.

Also habe ich gelernt, vor allem mir selbst Fragen zu stellen. Ich habe beschlossen, dass eine der lustigen Aufgaben des Leads darin besteht, Menschen bei der Beantwortung von Fragen zu helfen, die sie sich nicht stellen. Ich war mir sicher, dass ich, nachdem ich ein Führer geworden bin, weiterhin Code schreiben werde, nur Praktiken erstellen werde und alles in Ordnung sein wird.

Alexei Kudryavtsev: Ich verstehe, dass Sie Code schreiben wollten, aber wie Sie wollen.

Sergey Boishtyan: Ich wollte schnell Code schreiben.

Daniil Popov: Es scheint mir, dass dies eine normale Motivations- und Führungsposition ist, wenn Sie etwas anbieten und die Leute Ihnen zustimmen. Sie haben es geschafft, Ihre Gedanken der Öffentlichkeit zu vermitteln, sie hat Sie akzeptiert, Sie in ein gepanzertes Auto gesetzt, und jetzt sind Sie bereit, die Menschen voranzubringen.

Sergey Boishtyan: Auf welche Probleme bin ich gestoßen? Ich hatte Glück, dass ich niemanden verdrängen oder kämpfen musste. Ich bin gerade als Leiter eines neuen Projekts gekommen, habe Leute in das Team rekrutiert, sie haben meine Prinzipien akzeptiert, aber irgendwann sind Leute im Team erschienen, die mir nicht ganz zustimmten.

Daniil Popov: Haben Sie sie eingestellt?

Sergey Boishtyan: Ja, es ist passiert. Ich lernte sprechen und kommunizieren, entwickelte aber in mir keine Selbstkritik und Objektivität gegenüber meinen eigenen Ideen. Ich kam zu dem Schluss, dass wir unsere Gedanken nicht fördern sollten, sondern verstehen sollten, welche Gedanken richtig sind, und sie fördern sollten. Es war nicht einfach. Wir hatten ständig Streitigkeiten. Es gab eine Person im Team mit den richtigen Gedanken, die er nicht vermitteln konnte, und meine Aufgabe war es, sie für ihn zu vermitteln, und natürlich hatte ich mein eigenes Ego und meinen eigenen Standpunkt.

Von hier aus entstand ein interner Konflikt, als es einerseits so aussah, als ob man einen Gedanken vermitteln kann, dann ist es richtig, und andererseits weiß man einfach, wie man besser spricht als andere. Ich habe eine Weile gebraucht, um das zu realisieren. Zu diesem Zeitpunkt wuchs das Team auf und ich verlor Zeit beim Schreiben von Code. Ich fragte mich, warum ich das alles tat.

Ich nehme rationale Gedanken von Menschen, helfe, sie zu vermitteln, und mache selbst nichts - wie nützlich ist das? Es kann für mich nützlicher sein, diese Gedanken als Entwickler zu realisieren?

Dann dachte ich darüber nach, was für mich wichtiger war. Ich begann, bei der Kommunikation zu punkten und die Infrastrukturaufgaben der Automatisierung zu übernehmen. Während ich das tat, begannen Konflikte im Team. Außerdem bemerkte ich, dass mein technisches Absinken begonnen hatte. Wenn Sie den Code lange Zeit nicht schreiben, scheinen Sie hinter der Branche zu stehen: Ein Artikel wurde veröffentlicht, aber Sie haben ihn nicht gelesen, eine Konferenz wurde abgehalten, und Sie haben es nicht geschafft, den Code zu verlassen. Es begann zu zerquetschen. Ich kam zu dem Schluss, dass ich kein Teamleiter sein werde, bis ich ein Ingenieur wurde, der viel weiß und versteht.

Zurück zu den Entwicklern

Alexei Kudryavtsev: Hat es Sie nicht erschreckt, dass Sie, nachdem Sie die Leads bei den Entwicklern gelassen haben, die Aussicht auf Wachstum verloren haben und bis zum Ende Ihrer Tage ein leitender Entwickler sein werden?

Sergey Boishtyan: Ich hatte keine Zweifel und langen Gedanken. Dies häufte sich und irgendwann hatte ich das Gefühl, dass Teamführung kein Vergnügen war. Ich überlegte, wie ich sein könnte, wer ich sein könnte, erkannte, dass ich nur ein Entwickler sein konnte, und stimmte dieser Idee zu.

Ich habe nicht versucht, alles auf einmal zu lösen, sondern versucht, in den Zustand zurückzukehren, wenn ich glücklich war.

Daniil Popov: Sie sagten, Sie wurden Teamleiter, weil Sie der Meister der Entscheidungen sein wollten. Als Sie wieder Entwickler wurden, wurden Sie wieder Performer. Stört es dich immer noch?

Sergey Boishtyan: Es war ein großes Unbehagen. Es gab zwei Möglichkeiten: entweder sich mit dem zu versöhnen, was Ihnen gesagt wird, oder zu lernen, es anderen zu sagen, damit Sie gehört werden und Ihre Meinung ändern. Ich fing wieder an, die Qualitäten zu entwickeln, die ich in der Rolle des Teamleiters aufgepumpt hatte, aber jetzt nicht mit dem Ziel, einen Konsens zu erreichen, sondern mit dem Ziel, die Meinung zu kommunizieren, damit sie sie hören und die Motivation der Person verstehen können.

Das Problem mit meinem Team war, dass der Teamleiter nicht wusste, wie er seine Gedanken vermitteln sollte, und ich erkannte, dass meine Aufgabe darin bestand, ihm zu helfen, mir die Bedeutung seiner Worte zu vermitteln und andere Lösungen mit Vernunft vorzuschlagen.

: , ?

: « » , . , , , , — , .

?

: — . , ?

: , , .

. , .

, , .

: , .

: , .

: , , . , .

: TED, , . - , . , , , . , , , . . — , . — .

: . , ?

: : , .

: , , ?

: , , , , , . , , , IT.

: !

: CTO.

: CTO — , .

: , , . .

, — developer advocate.

, .

, . , , , , , .

, , , , .

: , CTO , .

: , , .

— : - .

: .

, , , , - .

, , , .

: , , ?

: . . , , . , . , . .

Tipps

: . , , — , , — .

: , . , , , .

— : , , , .

, , . , .

— , , .

- , , . , , .

: : , .

Saint AppsConf CI/CD. , soft skills , . , , .