Когда кто-либо становится руководителем разработки, на него непременно обрушивается огромное количество новых, неожиданных задач, и для адаптации непременно требуется время. Однако период адаптации однажды завершится, и тогда встанет вопрос, как же развиваться дальше. Не менее актуальным является вопрос подготовки сотрудника к будущей роли руководителя. Как работать с разработчиком, чтобы из него как можно быстрее получился будущий лидер?

Мы выбрали пути развития руководителей разработки темой следующего Team Leader Meetup, который пройдёт вечером 28 ноября в московском офисе Яндекса. Обсудить эту тему можно будет с экспертами из крупных IT-компаний. Регистрация ещё открыта.

В этот раз нашими экспертами стали:

• Николай Крапивный, руководитель бекенд-разработки, Badoo
• Роман romas1982 Ивлиев, CTO, mos.ru
• Александр Поломодов, руководитель отдела исследований и разработки, Tinkoff.ru
• Борис Тоботрас, директор центра программных решений, Инфосистемы Джет
• Виктор Ламбурт, руководитель направления рекомендательных продуктов, Яндекс
• Игорь Кураленок, генеральный директор, Лига Экспертов

Сегодня на Хабре мы задаём им ряд вопросов, чтобы задать тон будущей дискуссии:

1. Какие советы вы бы дали вашему коллеге – сильному разработчику, который недавно, буквально вчера, стал тимлидом? С каких конкретных, понятных действий ему стоило бы начать свою работу в новой должности?
2. Какие книги или статьи вы бы порекомендовали прочитать руководителю разработки? А какие ресурсы имеет смысл изучать на регулярной основе?
3. Сколько времени стоит уделять работе над техническими задачами, а сколько – над задачами, связанными с управлением коллективом? На что ещё может или должен тратить своё время тимлид?

Николай Крапивный, руководитель бекенд-разработки, Badoo

Какие советы вы бы дали вашему коллеге – сильному разработчику, который недавно, буквально вчера, стал тимлидом? С каких конкретных, понятных действий ему стоило бы начать свою работу в новой должности?

Я бы рекомендовал для начала:

• Понять, за что он теперь отвечает и каковы его основные обязанности как тимлида
• Согласовать с руководителем основные цели и задачи для него и его команды
• Поговорить с членами команды, разобраться как работает команда сейчас
• Посмотреть доклад про делегирование и научиться это делать
• Регулярно выделять время на чтение статей, книг, просмотр докладов по новым для него областям ответственности

Какие книги или статьи вы бы порекомендовали прочитать руководителю разработки? А какие ресурсы имеет смысл изучать на регулярной основе?

Для руководителя разработки рекомендую к прочтению:

• «How Google Works» by Eric Schmidt
• «Work Rules» by Laszlo Bock
• «The Goal» by Eliyahu M. Goldratt

На регулярной основе считаю, что стоит следить за материалами и выступлениями с Teamlead Conf и других тематических митапов (например, тимлидских митапов Badoo)

Так же много полезных ссылок и обсуждений можно найти в тематических каналах в Телеграмме: https://t.me/leadgr и https://t.me/TeamLeadTalks

Сколько времени стоит уделять работе над техническими задачами, а сколько – над задачами, связанными с управлением коллективом? На что ещё может или должен тратить своё время тимлид?

Считаю, что здесь нет единственного верного ответа. Задача лида как раз в том и заключается, чтобы оценить конкретную ситуацию и решить для себя, как распределить свое время, чтобы добиться максимального результата.

В моем идеальном мире чем меньше времени у лида уходит на управление командой (в управление я включаю и технические и менеджерские функции) – тем лучше. Считаю, что залог успеха и дальнейшего роста для лида – построить команду, которая работает эффективно с минимальным его участием. В таком раскладе лид может и должен вкладывать освободившееся время в поиск новых полезных идей и проектов за пределами текущей области ответственности.

Роман Ивлиев, CTO, mos.ru

Какие советы вы бы дали вашему коллеге – сильному разработчику, который недавно, буквально вчера, стал тимлидом? С каких конкретных, понятных действий ему стоило бы начать свою работу в новой должности?

1. Пришла пора качать софт-склиз. Инженерия – это хорошо, но теперь есть люди, с которыми надо работать в совершенно иной манере. Инженерия уходит на второй план. Можно читать, можно слушать лекции, можно всё вместе. Много информации на эту тему не бывает.
2. Усвоить, что ты больше не разработчик. Кодирование будет отходить на второй план. Будет ломка, но это неизбежно. Соответственно нужно определиться, какие технические работы остаются за тобой, выбрать только самое важное. Остальное начать раздавать коллегам.
3. Срочно искать замену на своё место. Ведь раз ты стал лидом – где-то образовалась дыра вместо хорошего инженера, и она о себе напомнит в первом же проекте :))
4. Сразу создать себе режим. Поначалу на всё дико не хватает времени, нужно сильно больше уделять времени планированию. И ловить себя на том, что что-то происходит не по плану. Импульсивность принятия решений будет преследовать первое время. Ну и желание закодить всё :)
5. Сразу начинать строить карту коммуникаций и налаживать связи. На уровне лида количество общения сильно больше, лучше бы сразу знать по каким вопросам к кому обращаться.

Какие книги или статьи вы бы порекомендовали прочитать руководителю разработки? А какие ресурсы имеет смысл изучать на регулярной основе?

Хороших книг много, остановлюсь на основных, как мне кажется.

• Брукс. «Мифический человеко-месяц, или Как создаются программные системы» – её просто надо прочитать, потому что это классика.
• Том Демарко и Тимоти Листер. «Человеческий фактор. Успешные проекты и команды» – эти ребята вообще крутые, их можно прочитать целиком, что подвернётся под руку. Кроме этой я бы ещё отметил «Балдеющие от адреналина и зомбированные шаблонами. Паттерны поведения проектных команд».
• Патрик Ленсиони. «Пять пороков команды. Притчи о лидерстве». Патрик – крут, его тоже можно читать по мере возможностей.
• Рейнвотер. «Как пасти котов», но этот труд на любителя. Среди тех, с кем мне довелось обсудить эту книгу, мнения разделились.

Обязательно что-то про переговоры, про эмоциональный интеллект и умение общаться с людьми. Можно Гевина «Договориться можно обо всём», Гоулстона «Я слышу вас насквозь», «Не рычите на собаку» от Карен Прайор.

С ресурсами сложнее. Обычно я нахожу интересные материалы на Медиуме, Хабре, GeekTimes, infoq.com, блогах уважаемых людей вроде Джоела Спольски. Я подписан на несколько управленческих каналов, где постоянно проскакивают интересные ссылки, я их смотрю, а заодно изучаю ресурс, на котором они размещены. Так можно найти множество не очень известных сайтов и блогов, но с очень неплохим контентом. Можно читать vc.ru, рассылка Мегаплана иногда подкидывает неплохие материалы.

Сколько времени стоит уделять работе над техническими задачами, а сколько — над задачами, связанными с управлением коллективом? На что ещё может или должен тратить своё время тимлид?

Всё очень зависит от того, как устроен проект, команда, компания. Я встречал совершенно разные пропорции, но чаще всего это что-то типа 100% времени на технические задачи и 46% времени на управление :))) Заканчивается это всегда одинаково нехорошо. Имхо, в реальности самая верная пропорция выглядит примерно так. Время на технические задачи — это 100% минус время на управление коллективом. 100% — это не 8 часов, если что. У каждого свои 100%. Другими словами, цифра плавает.

Обязательно нужно тратить время на самообразование, расширение кругозора в смежных областях (продукт и проджект-менеджмент; если ты бекенд — потыкать палочкой фронт, тестирование, эксплуатацию, ну и наоборот, конечно же), поддержание технической формы — новые фреймворки, библиотеки, языки, всё что так или иначе касается работы. Иначе есть риск потерять авторитет среди инженеров. Нужно посещать митапы и конференции, дабы расширять кругозор и искать ответы на свои вопросы.

Александр Поломодов, руководитель отдела исследований и разработки, Tinkoff.ru

Какие советы вы бы дали вашему коллеге — сильному разработчику, который недавно, буквально вчера, стал тимлидом? С каких конкретных, понятных действий ему стоило бы начать свою работу в новой должности?

Остановиться и ответить себе на вопросы:

• Что от меня ждут на новой должности.
• Кто и какие роли сейчас исполняет в команде:
  
  • Кто входит в список заказчиков команды (он один или их много)
  • Кому надо будет отчитываться
  • Какие сотрудники уже есть в команде
  • С кем придется коммуницировать горизонтально (другие лиды разработки, лиды инфраструктуры, тестирования, ...)
• Какие цели стоят перед командой и какие ожидания от результатов ее деятельности

Дальше, учитывая результаты ответов на эти вопросы, надо составить план, кому сдать старые обязанности и как принять новые. Нужно учитывать, что после перехода на позицию тимлида общения станет больше, а вот времени на разработку — меньше. Очень важно учитывать критерии успеха, по которым ты сам и твой руководитель поймут, что ты успешно справляешься с новой должностью.

Если переходить ко второму вопросу про конкретные и понятные действия, то могу сказать, что такого списка понятных действий, который универсально подходит ко всем ситуациям нет, а значит вам придется самому составить такой список, исходя из вашей ситуации.

Какие книги или статьи вы бы порекомендовали прочитать руководителю разработки? А какие ресурсы имеет смысл изучать на регулярной основе?

Я бы выделил книгу Фредерика Брукса «Мифический человеко-месяц». Это классика о проблемах команды в крупных проектах, в которой подробно разобран проект компании IBM по разработке OS 360. Также считаю очень полезными книги от Тома Демарко, в особенности «Человеческий фактор» и «Паттерны поведения проектных команд». А на закуску я бы посоветовал книгу Дж. Ханк Рейнвотер «Как пасти котов».

Среди онлайн ресурсов я почитываю поток Управление на Хабре и знакомлюсь с выступлениями в потоках по управлению на крупных конференциях, таких как РИТ, Highload++, Codefest и остальных.

Одним из моих увлечений является разработка в широком смысле слова, включая управление командами разработки. И свои мысли, впечатления от прочитанных книг, посещенных конференций и митапов я публикую на своей странице в фейсбуке. Возможно, эта страничка вам будет полезна.

Сколько времени стоит уделять работе над техническими задачами, а сколько — над задачами, связанными с управлением коллективом? На что ещё может или должен тратить своё время тимлид?

Нельзя четко сказать, в каком соотношении распределять время между техническими задачами и командой, т.к. это сильно зависит от конкретной команды и ее задач. В общем, можно сказать, что решение технических задач становится вторичным по отношению к тому, чтобы команда работала эффективно. По-моему мнению, тимлид должен тратить время на:

• работу с внешними заказчиками и выступать в качестве интерфейса команды для окружающего мира
• организацию процесса разработки и ритмичной поставки кода
• повышение эффективности членов команды — обучение и консультации коллег
• собеседование новых ребят при росте команды
• решение технических задач (написание кода, ревью,...)

Борис Тоботрас, директор центра программных решений, Инфосистемы Джет

Какие советы вы бы дали вашему коллеге — сильному разработчику, который недавно, буквально вчера, стал тимлидом? С каких конкретных, понятных действий ему стоило бы начать свою работу в новой должности?

Я сказал бы ему: дорогой друг, перед тобой стоит страшно интересная задача: включить в свою картину мира не только технологию, но и людей, и проекты, и их сложные отношения. Это позволит тебе решать качественно более сложные задачи, которые ведущий разработчик в одиночку решить не может. Для этого нужно научиться видеть не только то, что мы делаем в повседневной проектной работе, но и то, для чего мы это делаем, как и почему.

Предположим, что свежеиспечённый тимлид попадает в этом качестве в новый для себя проект. Начать можно с получения ответов на конкретные вопросы:

• Как устроен проект, на котором работает команда? Какую цель он должна достичь, кто и как будет судить о её достижении?
• Кто входит в команду? Что это за люди, каков их опыт, специализация, особенности их работы?
• С кем взаимодействует команда? Что в проекте ждут от разработки, и что она, в свою очередь, ждёт от смежных команд (аналитики, QA, архитекторы, sales force, инженерная поддержка)?
• С кем взаимодействует лично тимлид? Чего от него ждёт менеджер проекта, чего от него ждёт команда, чего от него ждут лиды смежных команд? Какие они видят проблемы в разработке?
• В каком состоянии находится проект? Где мы сейчас, что уже сделано и что осталось? Мы молодцы или нет, и почему? Какие сейчас есть известные проблемы в проекте — технические, организационные, человеческие?

Что делать в первую очередь?

• Познакомиться детально с тем, кто что и где делает.
• Разобрать backlog, прочитать весь проектный трекер, посмотреть в последние коммиты и ревью.
• Разобраться с методологией ведения проекта (code style, VCS/ветки, сборки, workflow в трекере, поддерживаемые версии, выдаваемые артефакты).
• Детально осознать архитектуру разрабатываемой системы с её историей (какие решения принимались и почему).

Какие книги или статьи вы бы порекомендовали прочитать руководителю разработки? А какие ресурсы имеет смысл изучать на регулярной основе?

Брукс, «Мифический человеко-месяц». Ни-че-го не изменилось за прошедшие пол-века.
Alan, Colston, The Programmers' Stone.

Сколько времени стоит уделять работе над техническими задачами, а сколько — над задачами, связанными с управлением коллективом? На что ещё может или должен тратить своё время тимлид?

Вряд ли тут есть какие-то рецепты. Ну, давайте от фонаря: 70% на технику, 30% на людей. Но эта пропорция меняется от размера команды. Если в команде 15 человек (чудовищно много IMHO на одного лида), пропорция 5%/95%.

Тимлид, кроме «внутренних» задач (техника + люди), решает ещё «внешние»: управление скоростью разработки и скоупом проекта, совместно с менеджментом планирует работу в проекте, предсказывает занятость разработчиков

Виктор Ламбурт, руководитель направления рекомендательных продуктов, Яндекс

Какие советы вы бы дали вашему коллеге — сильному разработчику, который недавно, буквально вчера, стал тимлидом? С каких конкретных, понятных действий ему стоило бы начать свою работу в новой должности?

В первую очередь я бы посоветовал узнать, что стало с предыдущим тимлидом и что ждет от вас ваш новый руководитель. После этого поговорить с каждым членом команды, узнать про их ожидания и проблемы, а также постараться понять их страхи.

Какие книги или статьи вы бы порекомендовали прочитать руководителю разработки? А какие ресурсы имеет смысл изучать на регулярной основе?

Нас в этом интервью много и, наверняка, мои коллеги назовут важные книги, касающиеся непосредственно управления разработкой. Поэтому я воспользуюсь моментом и упомяну три важные книги из совсем, казалось бы других областей.

Эд Кэтмелл. Корпорация гениев. Как управлять командой творческих людей

Книга написана основателем Pixar. Читая, поражаешься насколько мудр, тактичен и одновременно смел был автор. Как ему с небольшой командой единомышленников удалось переизобрести жанр мультипликации, создав шедевры, трогающие миллионы детей и взрослых по всему миру. Как Эд Кетмелл наладил диалог со Стивом Джобсом, защитив команду и использовав опыт Стива на благо роста Pixar.

Рассказывая историю рождения шедевров, автор вспоминает, что все они по началу были крайне неуклюжи, будто новорожденные. Ничего не стоило раздавить их сразу после рождения. И лишь терпение, любовь и огромное число итераций позволило идеям окрепнуть и превратиться в оскароносные фильмы.

А еще Эд рассказывает, как создавать атмосферу, в которой люди открыто высказывают критические мнения, а критикуемые с радостью используют эту возможность для улучшения своих творений.

Вот бы и нам так уметь, правда?

David Keirsey. Please Understand Me II: Temperament, Character, Intelligence

Во втором издании David Keirsey системно и наглядно рассказывает о том, почему люди часто поступают совершенно не так, как вы того ожидаете. Выясняется, что люди одной профессии, находящиеся в одном социокультурном контексте, могут совершенно по разному принимать решения, ценя совершенно разные вещи. И это происходит постоянно, с любимой, с детьми, с родителями и, конечно, в командах разработки.

Не смотря на некоторую критику, типология MBTI помогает лучше понимать людей, рационализировать их поступки и строить более сбалансированные команды.

Дэниел Канеман. Думай медленно… Решай быстро

Основоположник психологической экономической теории увлекательно рассказывает о когнитивных искажениях с которыми мы живем, их не замечая. В книге полно примеров, демонстрирующих, что мы с вами чертовски не рациональны и нами можно легко манипулировать.

Книга не только учит распознавать подобные манипуляции, но и заставляет серьезно призадуматься стоит ли делать то или иное, казалось бы, очень рациональное перераспределение обязанностей.

Сколько времени стоит уделять работе над техническими задачами, а сколько — над задачами, связанными с управлением коллективом? На что ещё может или должен тратить своё время тимлид?

Должен признаться, что давно не работал над по-настоящему техническими задачами.

Игорь Кураленок, генеральный директор, Лига Экспертов

Какие советы вы бы дали вашему коллеге – сильному разработчику, который недавно, буквально вчера, стал тимлидом? С каких конкретных, понятных действий ему стоило бы начать свою работу в новой должности?

• Начни смотреть по сторонам. Замечай, что делают люди в группе, как они это делают, что их радует, что огорчает. Обращай внимание на все нюансы, которые составляют микроклимат в коллективе, за который ты теперь отвечаешь. Твое знание своих ребят и девчат позволяет создавать синергию, а не мешать друг другу.
• Перестань писать код. Кроме двух исключений: когда он определяет вектор развития или задает моду. К первому относятся архитектурные решения, которые задают тон разработке и позволяют держать ее вектор в нужном направлении. Второй — те вещи, которые перестанут делать все, если перестанешь делать ты: тесты, ветки, правильные практики и прочие мелочи, которые делать всем лень, но без которых все разваливается.
• Не пытайся исправить все видимые ошибки, начиная жизнь с чистого листа или внедряя процесс из книги. Взгляды разработчика и тимлида существенно отличается, и то, что в роли разработчика тебе кажется вредным, может оказаться тем гвоздем, на котором все висело. Делай изменения медленно и последовательно. Не торопись, все успеешь.
• Отдавай и делегируй. Твоя задача — не делать все самому, а сделать так, чтобы задача была сделана. Более того, одним из очень важных мотиваторов является ответственность. Отдав ее кусочек в надежные руки, ты не только будешь менее загруженным, но и мотивируешь члена своей команды. Но, если уж отдал, помни, что отдал ты не только ответственность, но и делегировал часть полномочий по принятию решений.

Какие книги или статьи вы бы порекомендовали прочитать руководителю разработки? А какие ресурсы имеет смысл изучать на регулярной основе?

Мне в свое время очень понравился труд Alistair Cockburn «Agile software development». Всячески его рекомендую. Очень советую практику работы со студентами: сам готовишь себе кадры + приходится держать себя в тонусе, так как зубастые студенты не дают расслабиться, задавая каверзные вопросы :)

Сколько времени стоит уделять работе над техническими задачами, а сколько — над задачами, связанными с управлением коллективом? На что ещё может или должен тратить своё время тимлид?

Столько, сколько нужно, чтобы группа справлялась с поставленными задачами. Если через неделю релиз, то странно заниматься управлением, а если через месяц одна из девушек уходит в декрет, странно заниматься техническими задачами. Все случилось одновременно? Значит, ты мало занимался управлением :) Если серьезно, то все зависит от состава группы и задач, которые перед нею ставятся, IMHO нет универсального рецепта.

На что ещё может или должен тратить своё время тимлид?

• На рекламу своих людей. Чем больше твоих ребят знают другие команды, тем выше авторитет группы и понимание того что вы делаете. Чем меньше люди знают, чем вы занимаетесь, тем больше им кажется, что вы ничего не делаете :))
• На взаимодействие со смежниками (соседними группами, например). Как мне кажется, сюда уходит сильно больше времени, чем на технические задачи и на управление вместе взятые, но это существенно зависит от размера компании и роли группы.
• На планирование траектории развития: как всей группы, так и отдельных людей. Если ты не можешь ответить на классический вопрос про «как ты себе представляешь свою роль через 3 года» — это не только твоя проблема.
• На поиск кадров. Никогда не останавливайся в поиске кадров, всегда имей в запасе 1-2 человека на примете, даже если сегодня у тебя нет открытой позиции.

Следующая встреча, на которую ещё можно зарегистрироваться, состоится 28 ноября 2018 года в московском офисе Яндекса. На ней можно будет задать вопросы докладчикам и поделиться своим опытом.