Привет, Хабр! Меня зовут Алексей Топчий, я руководитель направления Ценообразования в X5 Tech. В разработке чуть больше 20 лет. Работал на многих проектах и технологиях. Из известных – Сбер и Яндекс. В Х5 мы с командой делаем очень большую, высоконагруженную систему. Когда-то, в самом начале карьеры, меня сделали руководителем. В тот момент я совсем не был готов к этому. Сегодня расскажу, к чему это привело, как в дальнейшем сложилась моя карьера и жизнь, как я ушёл, а потом снова вернулся к руководству, но уже с новыми навыками и скиллами. Больше 20 лет назад я был молодым, достаточно компетентным разработчиком, и мне предложили стать руководителем отдела разработки. Казалось, что это следующий этап моего развития, поэтому я согласился. Никакого бэкграунда или подготовки у меня не было. А дальше начались приключения. Мой отдел состоял из четырёх опытных сотрудников значительно старше меня. Мне 20 лет, а им по 40+. Они дольше, чем я работали в компании, и в целом дольше существовали в роли разработчиков. Мой опыт и компетенции были для них совсем не авторитетными. В результате, когда я ставил задачи, меня могли шутливо игнорировать или объявлять какую-то испанскую забастовку. Так начались проблемы. Меня самого смущало то, что я вообще не подозревал, чем должен заниматься руководитель. Контролирует выполнение задач Мне казалось, что руководитель должен контролировать выполнение задач. Это классический чайка-менеджер, подходящий к сотруднику каждые 10 минут, спрашивающий как дела и когда будет готова задачка. Дольше всех сидит в офисе Вторая обязанность руководителя – дольше всех сидеть в офисе, потому что если он приходит позже, то он не будет понимать, если его сотрудники опаздывают или  уходят с работы раньше. Они должны находиться восемь часов на рабочем месте, чтобы успевать делать свои задачи. Делает самые важные задачи Так как я знаю лучше всех, как сделать ту или иную задачу, я должен делать самые важные и критичные участки. Вот только мой опыт был не столь серьёзным как у подчинённых. Да и набор скиллов не дотягивал до любого из них. В итоге я задерживался на работе, брал на себя непомерное количество задач, разрывался между постановкой задач и собственной работой. Это всё привело к тому, что начались проблемы в семье из-за задержек на работе, в коллективе появилась демотивация и общий разброд. Через какое-то время я сбежал от этого всего в командировку в Санкт-Петербург, где провёл несколько месяцев. Это немного отодвинуло меня от команды и руководства. После этой командировки я уволился и перешёл в другую компанию. Из всего этого я сделал вывод, что фокусировка на процессе «что делать восемь часов на рабочем месте» — приводит лишь к непонятным задачам и непонятному руководству. А когда руководитель сам не знает, что делать, сотрудники не знают ещё больше, чем он. В тот момент, да и сейчас, я увидел такой трек развития в разработке: Архитектор — это человек, который придумывает решения, проектирует и потом, может быть, внедряет. Ограничения архитектора: всё равно те решения, которые он проектирует, он вынужден внедрять руками. А любой ручной труд ограничен по времени. В сутках 24 часа, сделать что-то больше, чем за 8-14 рабочих часов, мы не сможем. Архитектор, который не внедряет свои решения, рано или поздно отрывается от земли. При внедрении его решений команда понимает, что они не ложатся на ландшафт. Их становится трудно внедрять и появляются сложности. В целом, если архитектор не внедряет руками свои решения, они перестают быть удобными и хорошими. Тимлид — это человек, который руководит командой. Он отвечает за развитие людей, менторство. Может частично отвечать за процессы, забирать на себя какие-то задачи деливери менеджера. Это про людей, про менеджмент. Техлид — это человек, который вырастает в технического директора, в СТО. Он, на мой взгляд, не занимается людьми. Он занимается технологиями, строит технический road map проекта. Следит за тем, чтобы не рос техдолг, чтобы устаревшие технологии вовремя заменялись на новые, заведует инфраструктурой. Общее для всех этих людей в их развитии то, что со временем они всё равно сталкиваются с необходимостью руководить. Тимлиду, архитектору, техлиду приходится искать помощь у других людей, у своей команды, чтобы сделать больше и повысить масштаб проектов. После демотивирующей истории с неудачным руководством я считал, что у меня нет таланта и способностей руководить. В это время я посещал достаточно известный тогда форум IXBT.COM, там была тема «Куда уходить из разработки?». На полном серьёзе люди обсуждали историю, что можно открыть магазин и торговать колбасой. Это всё больше приносит денег, меньше стресса и, наверное, более интересно. Если не хочешь схватить инфаркт, можно пойти в это дело. Я немного загорелся этой идеей и хотел попробовать открыть свой бизнес. Во всяком случае, переключиться на другую деятельность. Может быть, там у меня получится лучше. Опыт у меня был следующий. Я открыл на Вайлдберриз маленький магазин одежды. Шил спортивные костюмы и пытался их продать. Как я это делал? Я тратил на это всего час-два в день, а все задачи делегировал опытным людям. Костюмы за меня пошили где-то в Ростове, доставку тоже сделали другие люди, да ещё и оформили всё в Москве. И даже поставкой на маркетплейс занималась другая команда. Всё делали за меня. Весь цикл занял порядка месяца. Тогда я и понял, что все задачи можно делегировать. Для владельца бизнеса достаточно выполнять только какие-то ключевые действия, которые кроме него никто не может выполнить. Все остальные задачи за вас может сделать кто-то другой. Мой следующий опыт — запуск стартапов. Хотя это сильно сказано. Скорее, небольшие сервисы. Один был для России, другой для рынка США. Фишка сервиса, связанного с телемедициной, была в том, что вся коммуникация с клиентом, бронирование, оплата и видеоконсультации проводились прямо на платформе. На тот момент подобных сервисов в России не было, но несмотря на то, что платформа была идеально сделана технологически, когда мы запустились — клиентов и денежного потока не было. Потому что не докрутили маркетинг и не проанализировали рынок. Получается, что как бы совершенна технологическая платформа ни была, если нет клиентов и маркетинга, проект не взлетит. Ещё у меня был опыт запуска образовательного курса в крупной компании. Я был продюсером курса по веб-разработке. В мои обязанности входил подбор персонала, построение плана, валидация гипотез о том, как этот курс должен выглядеть. В результате курс не был запущен, он полностью провалился из-за того, что мы делали его порядка полугода, и ни на одном из этапов не приходили к директору, то есть к владельцу. Думали, что мы делаем всё хорошо. Когда мы пришли через полгода к заказчику для демонстрации того, что мы сделали, он посмотрел и сказал, что это совсем не то, что он ожидал, и мы можем расходиться. Получается, если мы не работаем по agile, по маленьким итерациям, и не собираем обратную связь от того, кто платит деньги, скорее всего, наш продукт будет неудачным. Сходил я во все тяжкие, посмотрел, набрался опыта и в итоге вернулся в разработку. Понял, что тот опыт, который я получил, даст мне буст к управлению и позволит другими глазами посмотреть на эту всю историю. Из всего этого опыта я вынес следующие уроки. Правило Парето гласит, что 20% усилий дают 80% результата. Руководитель не обязан 8 часов в день заниматься чем-то, не понимая, чем. Ему достаточно решить 20% вопросов, которые дадут 80% результата. При старте бизнеса, работы с командой или нового проекта руководитель, как правило, многое может делать своими руками, потому что только он понимает цель, что и как надо делать. Но если он дальше продолжает идти в эту историю, его рук не хватит, и он опять скатится к тому, что у него всего 8-14 часов рабочего времени. Для масштабного проекта это полный провал.  Поэтому руководитель смотрит, какие задачи можно делегировать, находит людей, которые это могут сделать за него, и обучает их до того уровня, чтобы качество выполнения задач соответствовало его ожиданиям. Когда вы научили своих сотрудников делать что-то с нужным вам качеством, а иногда и лучше вас, можно делегировать все задачи. Основную идею руководства я почерпнул из книги Элияху Голдратта «Цель», в которой описывается человек, выстраивающий процессы на производстве. Основная идея была в том, что он находил какие-то узкие горлышки и их расшивал. Задача руководителя — смазывать механизм. Не делать что-то руками, а находить, где в механизме простаивают задачи, где сейчас узкое место, и как это исправить. Это может быть разное решение – от найма сотрудников до ручного выстраивания процессов. Так у меня изменился взгляд на agile-ритуалы. Когда-то я работал в одной крупной организации, у которой agile вывешен прямо на флаг. Сама ретроспектива, основной ритуал в agile, был повинностью, с которой все старались убежать. Она была в пятницу в конце рабочего дня. Мы под разными предлогами задерживались на рабочем месте, чтобы поработать, а когда начиналась ретроспектива, уходили домой или под всеми возможными предлогами уходили с ретроспективы. На данный момент я понимаю, что ретроспектива — это один из ключевых моментов командной работы. Она позволяет понять, где узкие места, на которые руководителю нужно обратить внимание. Заботиться об устранении этих узких мест нужно не только руководителю, но и всей команде. Когда мы в ретроспективе рассматриваем колонку «Что перестать делать?», мы выявляем те места, которые нас тормозят. Дальше мы также командным разумом придумываем, как эти места устранить. 1:1 — это тоже микроретроспектива, но только уже с одним человеком. Мы смотрим, что этому человеку мешает работать, что его демотивирует, и таким же образом итеративно устраняем эти моменты. Сейчас у меня совершенно поменялся взгляд на руководство по сравнению с тем, что был. Я понимаю, что фокус у руководителя должен быть на цели. Руководителю необходимо знать, какого результата должна достичь его команда, в какие сроки, какое должно быть качество. Концентрация на результате позволяет видеть узкие места, мешающие достижению цели и сконцентрироваться на них. Скорость команды тоже важна. Один из самых интересных, серьёзных проектов, которым я горжусь, это проект «Ценообразование» в Х5. Это сервис, который считает цены для почти 25 000 магазинов ежедневно. Там колоссальные объёмы данных, нагрузки и влияние на бизнес. Этот сервис мы делали полтора года небольшой командой из 10 человек. За его реализацию немногие хотели браться, так как было непонятно, как его делать. А мы командой, построенной с нуля, всё реализовали, выпустили в прод, и сейчас сервис хорошо работает. У меня был опыт руководства десятками разных команд. Каждая команда — это живой организм. Все команды разные, в каждой разные люди и стремления. Все команды по-своему хороши, и в чём-то непохожи друг на друга. Ко всем командам у меня сохранилось тёплое, даже немного романтическое отношение. По встречам 1:1 или ретроспективам, в целом, я сужу о том, в правильном ли направлении двигаюсь. Насколько ведут меня к цели те инсайты, тот опыт, который я почерпнул и пытаюсь внедрять в свою жизнь и практику. Если мне в обратной связи люди говорят, что я делаю не то, или они недовольны, наверное, это звоночек о том, что я иду куда-то не туда. По моему опыту, обратная связь говорит о том, что я двигаюсь в правильном направлении. Со всеми членами команды, с людьми, с которыми я общаюсь, у меня очень тёплые отношения. Можно их даже квалифицировать как дружеские. В целом кажется, что люди во всех командах счастливы работать вместе, в том числе и со мной. Все люди разные, ваш первый опыт руководства и дальнейшие пути могут быть совсем не таким как мой. Те моменты, которые я осветил, это мой опыт. Необязательно, что у вас будет точно так же. Если в первый раз не получилось руководить, это не значит, что у вас нет таланта или вам это не подходит. Скорее всего, нужно что-то докрутить, переключить фокус, и всё может получиться. Второе — это зачем вообще нужно руководство. У человека весьма ограниченный набор возможностей. За выделенные рабочие часы и в целом за жизнь мы можем своими руками сделать не так много. А чтобы повысить масштаб проектов, изменить мир, как бы пафосно это не звучало, необходимо руководство командами. Чем больше команда, тем больше те изменения, которые мы можем сделать. Руководство в целом — это не какой-то талант. Это переключение фокуса с того, что делать 8 часов, на то, какого результата нужно достичь. А путь к результату — это смазка узких мест, помощь другим членам команды в их задачах и непрерывное развитие как процессов, так и команды, и отдельных людей.  Разработчик