Timlid ist Sergeant in der IT-Abteilung

Manchmal scheint es, dass das Timlid jemand oder etwas wie Snark aus dem Gedicht von Lewis Carroll ist: Es existiert zweifellos, ist vielseitig und widersprüchlich, beschrieben in seinen alltäglichen und geschäftlichen Erscheinungsformen, aber trotz allem ist es ein Rätsel. Um zu verstehen, wie wichtig diese Rolle (Teamleiter, nicht Snark) für Ingenieurteams ist, wer sie besser einsetzen kann und welche Fallstricke in der Teamführung verborgen sind, verspricht Saint TeamLead Conf 2018 zu helfen, die vom 24. bis 25. September in St. Petersburg stattfinden wird .

Einen Monat vor der Veranstaltung sprachen wir ohne Formalitäten mit dem technischen Direktor des Mos.ru-Projekts Roman Ivliev , der das Saint TeamLead Conf 2018-Programmkomitee leitet. Im Gespräch: Wer sind die Teamleiter, wie man sie richtig vorbereitet, wen und worauf sie sich vorbereiten sollten, was sie sollten ein Kreis ihrer Verantwortlichkeiten sein und vieles mehr.

Hilfe

Roman Ivliev wurde 1982 geboren. 2005 absolvierte er die Abteilung für Kybernetik des Moskauer Instituts für technische Physik. Mehr als 15 Jahre in der IT. Spezialisierung: hohe Arbeitsbelastung, Management in Technologieteams, Schulung.

Letzte Arbeitsorte:
• 2009–2013 zunächst leitender Ingenieur, dann Projektmanager bei Kaspersky Lab (er war für die Unterstützung und Entwicklung von Unternehmensstandorten verantwortlich - sowohl b2c als auch b2b).
• 2014–2016 - Direktor der Informationstechnologie Banki.ru
• Ende 2016 übernahm er die CTO-Position im Mos.ru-Projekt.

- Seit fast zwei Jahren sind Sie CTO im Mos.ru-Projekt und haben zuvor viele Jahre hauptsächlich in kommerziellen Organisationen gearbeitet. Wie unterscheidet sich Ihrer Erfahrung nach die Arbeit als technischer Direktor in einer Regierungsstruktur von der Arbeit in derselben Position in der Wirtschaft?

- Berücksichtigen Sie aus Sicht der Produktionsprozesse, dass es keinen signifikanten Unterschied gibt. Das Task-Setting-System unterscheidet sich nicht wesentlich von dem in Handelsbüros. Der Unterschied in der Größenordnung: Normalerweise ist ein Regierungsprojekt ein riesiger Mechanismus. An seiner Arbeit sind viele Menschen beteiligt, die das Recht haben, Entscheidungen zu treffen und zu treffen. Zum Vergleich: Wenn wir in Banki.ru fünf interne Projekte entworfen haben, können in Mos.ru etwa zwanzig Personen an einem vergleichbaren Projekt beteiligt sein. In einer Regierungsorganisation ist die IT-Abteilung beim Aufbau externer Kommunikation etwas schwieriger: Es kommt vor, dass Sie versuchen, einen halben Tag lang die richtige Person zu finden - einfach weil das Personal groß ist. Aber mit denen, mit denen Sie regelmäßig interagieren müssen, auch durch die Integration von Diensten, sind wir auf einem kurzen Weg: Wir haben uns kennengelernt.

In jeder Ecke des Moskauer Ministeriums für Informationstechnologien (DIT) und in anderen Strukturen, mit denen wir interagieren müssen, unseren eigenen Spielregeln und unseren Problemen, wie in jeder großen Organisation, zumindest in derselben Sbertekh. Unser Mos.ru unterscheidet sich nicht wesentlich vom Markt für B2C-Services - außer dass wir kein Geld verdienen.

Natürlich sind wir immer noch vom Gesetz abhängig. Und wenn wir einen bestimmten Dienst in elektronische Form übersetzen oder einen neuen Dienst veröffentlichen, dann nur, wenn es einen geeigneten rechtlichen Rahmen gibt. Nehmen wir an, wir gleichen die Rechte derjenigen aus, die im Internet und über die Registrierung beim Zahnarzt Aufzeichnungen machen. Innerhalb der Abteilung liegt dies nicht in unserem Verantwortungsbereich. Manchmal haben wir die Veröffentlichung aufgrund ähnlicher Umstände verschoben, die wir nicht beeinflussen konnten. Obwohl das Geschäft jetzt das gleiche Chaos ist.



- Was steckt hinter der Fassade von Mos.ru?

- Mos.ru ist das Tor. Ein Portal, das eine ganze Reihe von Diensten zusammenbringt. Unter ihm gibt es einen Newsroom, der über Ereignisse in der Stadt schreibt und ein Plakat unterhält. Es gibt Abschnitte, zu deren Einhaltung wir gesetzlich verpflichtet sind, beispielsweise Informationen zu Rechtsakten und zur Struktur der Regierung. Diese Teile der Ressource werden auch von speziell geschulten Personen besetzt. Wir bereiten sie auf die Mechanismen des Content Managements vor, sie nutzen es.

Noch in unserem Verantwortungsbereich liegen digital-spezielle Projekte. Von frisch gemacht für den Zaryadye Park.

Wir haben relativ gesehen ein volles Fahrradteam. Wir nehmen etwas von der Seite, wenn auch selten. Andere Dienste, die in der Domain www.mos.ru leben , aber nicht von uns, sondern von anderen Abteilungen von DIT entwickelt wurden, sind aufgrund interner Integrationen auf der Website verfügbar. Wir verstecken sie vor dem Benutzer, damit für ihn jeder Übergang innerhalb des Portals nahtlos verläuft. Wenn Sie auf Mos.ru sitzen, können Sie sich leicht in einem anderen System befinden. Wenn Sie jedoch nicht in den Seitencode gelangen, werden Sie nichts bemerken.

Dieselben Stadtverwaltungsdienste (auf die über unsere Website zugegriffen werden kann) arbeiten in einem separaten Team. Ihre Dienstleistungen beschränken sich wiederum auf branchenspezifische IT-Systeme: Gesundheitswesen, Soziales usw.

- Wie viel ist ein großes Team unter Ihrer Aufsicht an der technischen Unterstützung des Portals beteiligt?

- Zwanzig Menschen in Entwicklung. Mit einem Dutzend Tests, einschließlich derer, die an der Automatisierung beteiligt sind. Fügen Sie hier das Ausbeutungsteam und DevOps hinzu. Insgesamt hängen bis zu fünfzig die genaue Anzahl und Zusammensetzung von den aktuellen Umständen und der Belastung ab.

- Wie ist Ihre technische Managementhierarchie aufgebaut? Wie sind die Verantwortungsbereiche aufgeteilt?

- Wir haben drei Hauptbereiche: Entwicklung, Test, Betrieb. Der Betrieb ist wiederum in sauberen Betrieb und DevOps unterteilt. Darüber hinaus werden diejenigen unterschieden, die mit Rechenzentren interagieren, und diejenigen, die sich mit Automatisierung beschäftigen, aber sie haben viele gemeinsame Aufgaben, so dass ich sie nicht in verschiedenen Lagern züchte.

Das Testen wird nach dem Schema „Testen als Service“ durchgeführt. Es gibt eine Gruppe von Testern und ihren Chef. Sie sind nominell an Teams gebunden, aber tatsächlich nicht ihre Mitglieder. Bei Bedarf übertragen wir Tester von Aufgabe zu Aufgabe: Diese Jungs sind funktionsübergreifend. Die Ausnahme ist mobil. Wir haben spezielle Leute geschickt, um mobile Anwendungen zu testen und zu versuchen, sie nicht umsonst zu ziehen: Ihre Arbeit hat eine ausgeprägte Spezifität.

Wir haben auch DevOps as a Service: Aufgaben werden festgelegt, priorisiert und dann durch die Devops ausgeführt, die auch für einige Teams nicht eng festgelegt sind. Ebenso funktioniert der Betrieb.

Die Entwicklung ist jedoch in Teams in Funktionsbereichen unterteilt. Wir haben zwei Arten von Teams. Der erste ist hoch spezialisiert. Insbesondere derjenige, der die Suche durchführt. Es berührt nicht das Frontend und die GUI, sondern nur das Backend. Ihre eigenen Algorithmen sägen, über maschinelles Lernen nachdenken, Zauberer, Hinweise, Statistiken, Analysatoren und Tippfehler korrigieren. Sie sitzen auf ihrem Technologie-Stack und verbinden sich über die API mit Mos.ru. Der Suchdienst ist mit einem beliebigen Teil des Portals verbunden. Ein separates Team landete in Richtung mobiler Anwendungen. Sie hat ihr eigenes Backend.

Beide Teams interagieren mit der „Kernentwicklung“ von DevOps, Tests und Betrieb.

Die zweite Art von Befehlen sind diejenigen, die separate Mos.ru-Module erstellen und unterstützen, einschließlich der GUI. In der Regel sind es jeweils fünf mit maximal sechs Mitarbeitern, je nach Richtung. In diesen Minigruppen gibt es eine klare Unterteilung in Front-End und Back-End: In unserem Fall hat es sich als effektiv erwiesen. Die meisten Backender sind Full-Stack-Entwickler, aber ich lasse sie nicht auf zwei Tanzflächen gleichzeitig drehen. Jedes dieser Teams hat einen Teamleiter.

- Also klang dieses Wort. Und was macht so ein Timlid?

- Erstens ist er ein Stratege in seinem Frontbereich - er überwacht die Einhaltung der von uns festgelegten Spielregeln. Darauf - unter anderem - Aufgabenzerlegung, Codeüberprüfung, retrospektive Organisation, Anfängerausbildung.

In militärische Reihen übersetzt, ist dies jemand wie ein Sergeant - der Truppführer. Er ist befugt und hat das Recht, Entscheidungen im Rahmen der von uns gemeinsam verabschiedeten technologischen Lösungen und Standards zu treffen.

Außerdem sind meine Teammitglieder Teil des Architektenteams. Dies ist keine formalisierte und nicht ständig funktionierende Struktur: Sie entsteht, wenn das Bedürfnis reift, sich technologisch etwas Neues auszudenken. Dann werden sich alle Teamleiter, Leiter der Test- und Betriebsabteilungen und alle anderen, die an den Änderungen von entscheidender Bedeutung sind, mit mir treffen. Spezialisten mit unterschiedlichen Kompetenzen, mit unterschiedlichen Ansichten zur Technologielandschaft, mit unterschiedlichen Positionen setzen sich in einen Kreis. Sie diskutieren kontroverse Themen, legen Vereinbarungen fest, entwickeln eine Architektur oder Lösung - und sind anderer Meinung.

Bis vor kurzem wurden in Banki.ru und in Mos.ru ausschließlich „Rücken“ aus meinen Teamkollegen geworfen. In der Regel übernahm ein leitender Backend-Entwickler diese Rolle. Aber im Moment habe ich bereits zwei Teamleiter vom Frontend.

Alles ändert sich. Wir mussten uns an die aktuellen technologischen Realitäten anpassen und bekamen als Ergebnis das, was wir Gilden nennen.

Hier ist die Sache: Es ist für den Spitzenreiter schwierig, den Überblick darüber zu behalten, was 2018 in der Backend-Welt passiert, und umgekehrt. Wir haben erkannt, dass Menschen auf horizontaler Ebene zusammenarbeiten müssen, sich in informellen Vereinigungen ohne direkte Unterordnung engagieren müssen, aber mit Status - wie Reihen in Geheimgesellschaften, so etwas wie ein „Meister der Back-End-Ordnung“. Die Träger solcher „Titel“ sind Personen, die de facto angewandte Managemententscheidungen treffen: Werden wir auf PHP 7.2 umsteigen, werden wir Angular entwickeln oder ist es besser, sich auf React zu verlassen.

Gilden versammeln sich regelmäßig - getrenntes Frontend, separates Backend. Sie sammeln sich und finden heraus, wer gut und wer schlecht ist, was jetzt modisch und cool ist. Sie argumentieren, ob Webpack wirklich ein langweiliger Hut ist, der eine Menge von allem sammelt, was unnötig ist, oder nur lernen muss, wie man damit umgeht. Sie laufen einfach nicht von leer nach leer über, sondern kommen am Ende zu einer praktischen Lösung.

Letztendlich ersetzt das Architektenteam meinen Systemarchitekten. Ja, ich habe keinen Systemarchitekten.

- Welchen Platz nimmt der Teamleiter in Ihrem Team ein? Berichtet er direkt an den CTO oder gibt es Manager auf mittlerer Ebene?

- Wir haben kein mittleres Level - es ist einfach so passiert. Nach der Logik der Dinge sollte es zwischen den Teamleitern und mir einen Entwicklungsmanager geben. Tatsächlich gibt es Chefs in der Test- und Betriebsabteilung, und ich persönlich leite die Entwicklung. Daher berichten mir die Timlids direkt.

Etwas kniffliger ist das Einreichungsschema der Devops. Anfangs wollte ich sie auch mit meinem Chef in eine separate Gruppe aufteilen, aber die Jungs und ich überlegten und entschieden, dass dies eine zusätzliche Verbindung zum Management war. Sie haben DevOps anstelle des Kanban-Chefs hinzugezogen, weshalb sie äußerst zufrieden sind.

- Wann sind Sie als Teamleiter in der Entwicklung zum ersten Mal auf eine solche Einheit gestoßen? Wann war meine persönliche Erfahrung davon überzeugt, dass diese Funktion nützlich ist?

- 2008 haben meine Kollegen und ich in einem Verteidigungswerk gerissene Software geschrieben. Einmal haben wir uns die Nase vergraben, weil es offensiv einfach war: Ein Team von zehn Entwicklern kann nichts produzieren, sondern nur betrügen und fluchen. Dann entstand zum ersten Mal in meinem Leben der Ausdruck „Gruppenleiter“ - eine Art Prototyp eines Teamleiters.

Das Team von Ingenieuren war zweigeteilt, wobei jeder der beiden Gruppen eine verantwortliche Person zugewiesen worden war. Ich war einer von ihnen. Der Leiter einer anderen Gruppe und ich begannen, interne Entwicklungsprozesse aufzubauen und die Interaktion zwischen den Hälften unseres Miniteams zu debuggen. Gemeinsam haben wir das Kollektiv vom Typ „Herde“ in zwei effektive Kampfeinheiten verwandelt. Sie begannen, Aufgaben zwischen ihnen zu verteilen und dieselben Aufgaben zu priorisieren, längere Zeiträume zu planen und am Ende die Arbeit der Teams zu synchronisieren, um Ausfallzeiten zu vermeiden.

In Banki.ru war die Struktur der technischen Abteilung ebenfalls „zellular“: Die Teams darin wurden von Teamleitern kontrolliert, und die meiste Zeit mit fünf von ihnen kontaktierte ich direkt, ohne einen Entwicklungsmanager. Genau wie jetzt in Mos.ru.

Zuvor waren bei Kaspersky Lab, wo ich für die Arbeit der Unternehmensstandorte verantwortlich war, mehrere Teams unter meiner Leitung tätig - multidisziplinär mit unterschiedlichen technologischen Stapeln. Ohne die Timlids wäre ich dort durch meinen Verstand verletzt worden - die Anführer der Gruppen, die mich vor der Qual gerettet haben, die mit dem Aufbau eines technologischen Panoramas in allen Details verbunden ist. Ich habe mit ihnen auf der Ebene der Ideologie und der Gesamtkoordination der Prozesse interagiert. Der Aufbau der Spielregeln - wie man eine Codeüberprüfung durchführt, ob man den Jüngeren hilft, ob man die Ältesten betrügt usw. - blieb auf ihrem Gewissen.

Und noch einmal ungefähr das Gleiche: Mit wem haben die Timliden noch verglichen, wenn nicht mit Sergeanten? In den Staaten hält die ganze Armee an ihnen fest. Ich kann auch nicht ohne meine "Sergeants" leben. Eher kann ich, aber mit Schmerzen und durch ein Stumpfdeck. Sie sind meine Augen, Ohren, Hände. Sie sind die ersten, die meine Wünsche, Vorschläge und Anweisungen "zu den Massen" tragen und dafür sorgen, dass all dies umgesetzt wird.

- Ist ein Teamleiter Ihrer Meinung nach eher ein Beruf oder eine situative Rolle in der Organisation, analog zum Scrum Master?

- Ich habe jetzt beide im Team. Es ist eine Sache, wenn die Aufgaben eines Teams im Grunde die gleichen sind und sich die Leute in einem einzigen Rhythmus bewegen. Eine andere ist, wenn in einem Team n Probleme parallel gelöst werden, wobei n die Anzahl der Ingenieure in einem Team überschreiten kann. Im zweiten Fall hat der Teamleiter die Möglichkeit, sich auch nur vorübergehend in einen natürlichen Administrator zu verwandeln, der diese Aufgaben "weiterleitet". Für mich ist dies sowohl eine Rolle als auch ein Beruf.

Darüber hinaus streitet der Markt immer noch darüber, wer der Timlid-Vogel im Prinzip ist und welche Grundfunktionen er hat. Jeder hat eine Konfiguration, die am besten zu ihm passt. Häufiger kommen sie sogar von den Aufgaben, die in einem bestimmten Team gelöst werden müssen. Zum Beispiel habe ich bei Banki.ru die Auswahl des Personals an meine Teamleiter delegiert: Sie waren ausreichend „aufgeklärt“, um während des Interviews die richtigen Fragen zu stellen, nicht nur um die Qualifikationen des Kandidaten zu bestimmen, sondern auch um seine Soft Skills zu testen. Nach und nach pumpten die Jungs und wandten sich von gewöhnlichen technischen Führern des ersten Ranges zu Einheiten der folgenden Stufen. Bei Mos.ru kamen wir nach und nach zum selben System. Die Jungs selbst studieren den Lebenslauf, schauen sich die Kandidaten an und führen technische Interviews. Ich besuche diese Bühne oft als Zuschauer.

Existiert Timlid als Beruf, ist die Frage nachzufüllen. Ist der Teamleiter ein Beruf? Absolut. Nur in der Raketenwissenschaft ist eine und in der Programmierung eine andere unter dem Gesichtspunkt der Funktionen, die ihr Vertreter ausführt, und des Aufgabenbereichs, den sie ausführt. In dem Unternehmen, in dem sich fünf Mitarbeiter in der Entwicklung befinden, einer. Im Büro für 250 Mitarbeiter - ein weiterer.

Das gleiche gilt für den Scrum Master. Niemand stört ihn, ein Back-End, Front-End, Tester oder sogar ein technischer Redakteur zu sein. Die Hauptsache ist die Fähigkeit, Menschen zusammenzubringen, sie richtig einzustellen und zu organisieren, die Entropie so weit wie möglich zu reduzieren und Kollegen zu ermutigen, sich in einem einzigen Rhythmus und in eine Richtung zu bewegen.

- Lass uns deine perfekte Welt besuchen. Wenn ein Team einen Produktmanager, einen Projektmanager und alles in allem umfasst, wo liegt die Verantwortung des Teamleiters? Neigt Timlid eher zu "Design" als zu "Produktivität"?

"Er ist näher am Design, ja." Aber Geschäft ist Geschäft, und interne Engineering-Prozesse sind interne Engineering-Prozesse. Alles Salz ist, dass sein Hauptverantwortungsbereich die Organisation der Arbeit in der „Zelle der Gesellschaft“ ist, die das Endprodukt produziert.

Genauer gesagt hat der Teamleiter zwei Schwerpunkte. Die erste ist die Organisation der Arbeit im Mikrokollektiv, von der Erfassung der Eingabedaten bis zur Übermittlung des Ergebnisses. Die zweite ist die Bereitstellung sozialer Interaktionen innerhalb des Teams und die Herstellung der Verbindung mit der höchsten IT-Führung. Wenn es eine klare Tendenz in die eine oder andere Richtung gibt, ist es Müll.



- Was muss der Timlid kontrollieren?

- Erstens möchte er sicherstellen, dass die Spielregeln, die auf Unternehmensebene, in der Einheit oder in der Gruppe der Mitarbeiter festgelegt wurden, bei seinem Clearing eingehalten werden. Es gibt Regeln für die Erstellung eines Codes, die Pflege der Dokumentation und die Durchführung allgemeiner Ereignisse - was bedeutet, dass jeder diese befolgen sollte.

Zweitens gibt er technische Anleitungen: Er ist verantwortlich für die Zerlegung von Aufgaben, deren Implementierung in der Entwicklung mit dem Ziel, ihre Implementierung so einfach und verständlich wie möglich zu gestalten und ihre Implementierung tatsächlich zu überwachen. Es grenzt an die unterschätzte und äußerst wichtige Funktion des Teamleiters - um die Vollständigkeit der Eingabedaten für das Team sicherzustellen. Ich habe diese Leute als Filter am Eingang zu ihrer Minigruppe: Wenn ein Team anstelle von TK einen expliziten Bullshit bekommt, drückt sein Teamleiter auf das Projekt oder Produkt, bis er die richtigen Anforderungen formuliert.

Bei Bedarf führt das Team durch Ausnutzungsressourcen wie den Netzwerkzugriff. Und natürlich versteht er, wie der Teil des Systems, an dem seine Teamkollegen beteiligt sind, strukturiert ist, und für ihn ist klar, wie Integration funktioniert. Andernfalls kann er die Aufgaben für die Test- und Betriebsabteilungen im Namen seines Teams nicht korrekt formulieren.

Drittens signalisiert ein solcher Führer bei Fehlern jeglicher Art, mit denen er selbst nicht fertig werden kann, sie sofort und macht Menschen darauf aufmerksam, die das Problem lösen können. Wenn das Team keine Zeit hat, tritt er, nachdem er es kaum entdeckt hat, zu seinem Chef und gibt ohne Trostlosigkeit zu: „Wir haben keine Zeit, weil wir„ unterschätzt “werden“ und bietet ihm Lösungen an.

In Mos.ru, der Stichprobe von 2018, ist der Teamleiter dafür verantwortlich, dass die beim Team eingegangenen Aufgaben innerhalb des festgelegten Budgets mit der aktuellen Zusammensetzung der Spezialisten pünktlich abgeschlossen werden. Das ist ideal. Etwas schlägt fehl - er bringt sofort ein Problem heraus, das er mit seinen verfügbaren Ressourcen nicht bewältigen kann, und „drückt“ es zusammen, bis es innerhalb des Teams oder ein oder zwei Ebenen höher gelöst ist. Zumindest lässt es den problematischen Prozess nicht alleine.

Somit ist der Teamleiter ein vollwertiger technischer Manager, kein Anhängsel aus der Kategorie „Lass es sein“.

- Welche anderen Aufgaben können oder sollten der Pflege eines Timlids übertragen werden?

- Timlids erfüllen einen anderen Teil ihrer Funktionen ziemlich oft, nur abhängig von den Umständen, schenken sie ihnen von der Organisation mehr oder weniger Aufmerksamkeit. Zum Beispiel eine Anpassung der Entwicklungsmethodik: Sie als Teamleiter sehen am besten, ob die für alle ausgewählte Methodik speziell für Ihre Site geeignet ist. Es stellt sich oft heraus, dass nein. Stellen Sie sich vor, jeder sägt eine GUI und Sie sind eine Servicekomponente. Offensichtlich sind Ihre Prozesse überhaupt nicht die gleichen wie die Ihrer Nachbarn.

, «» : , , - «- ». HR-. , , , . . HR- .

, . , - . .

. - , , , . : , . , : «- , - ».

, — , , — . . , Mos.ru . , . - , . , «» , , , : , . , : , , .

— «», ?

— , - . , . . — , , - . , code review, - , . , (, ). , Vue.js, PostgreSQL 10 «» . , , -, .

, . , , : , Sphinx Avito. .

, , — - , . . , , , .

- , . , , , .

— , ? , back-end front-end .

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

— — , — ? , ? «»?

— , . . - , - — . . , , , . , IT — , . . : , .

CTO . — , ? , « — — » — , , , ? .

— , , , ?

— , . , - . — . , . .

, , . . , : « PHP, Go, - -». , , .

, «», : , , .

. - , . - « ». , , .

— . . — . HR-. , . , ? , , . , , — - .

— . , . — .

, soft skills, , , , . , ? , . : .

— «» «-». , , . , ? ?

— , . — — . , : « ». , . , — . . Saint TeamLead Conf : , «», «».

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

, , : : « , , — - ».

— ? ?

— , , soft skills. , , , , , .

, , , , , . — , , .

— , , , ? ?

— - . , . 7±2, , , , , ( ). -, — -.

— , ? ?

— : , .

:
• . , , , , , .
• , , , , , , .
• , , .



— , IT , ?

- Nein! . , «» IT-. , , : , «» .

TeamLead Conf, , «», , , , — , , — .

, , . , Mos.ru , . : . Banki.ru , , , , ; - .

— . , , , , review. .

, Saint TeamLead Conf, — . , , , , , .

— , TeamLead Conf , , ? ?

— , , , - . , .

— , .

— IT , «» ? ?

— . . , - - . , . - .

— ? « », , - ?

— . , - : , , , IT-, . , « », .

«» — HighLoad++ , ++, «» — Whale Rider Aletheia Business. « »: , , , .

, Saint TeamLead Conf . , ?

Die Materialien des Frühjahrs TeamLead Conf wurden vollständig auf unserem YouTube-Kanal veröffentlicht . Es wird auch ein Video der neuen Konferenz erscheinen, aber in einigen Monaten. Abonnieren Sie, wenn Sie nicht missen möchten.

Alle unsere Neuigkeiten rund um Management und Unternehmertum sammeln wir im Newsletter. Es beinhaltet: Veröffentlichung von Artikeln und Transkripten, offene Videos, coole Redner und andere nützliche Dinge. Bei Interesse anmelden .