Хабрахабр

Как развиваться руководителю разработки

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

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

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

  • Николай Крапивный, руководитель бекенд-разработки, 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

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

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

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

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

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

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

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

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

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

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

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

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

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

Александр Поломодов, руководитель отдела исследований и разработки, 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. Как ему с небольшой командой единомышленников удалось переизобрести жанр мультипликации, создав шедевры, трогающие миллионы детей и взрослых по всему миру.

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

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

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

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

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

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

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

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть