Когда кто-либо становится руководителем разработки, на него непременно обрушивается огромное количество новых, неожиданных задач, и для адаптации непременно требуется время. Однако период адаптации однажды завершится, и тогда встанет вопрос, как же развиваться дальше. Не менее актуальным является вопрос подготовки сотрудника к будущей роли руководителя. Как работать с разработчиком, чтобы из него как можно быстрее получился будущий лидер?
Мы выбрали пути развития руководителей разработки темой следующего Team Leader Meetup, который пройдёт вечером 28 ноября в московском офисе Яндекса. Обсудить эту тему можно будет с экспертами из крупных IT-компаний. Регистрация ещё открыта.
В этот раз нашими экспертами стали:
Сегодня на Хабре мы задаём им ряд вопросов, чтобы задать тон будущей дискуссии:
1. Какие советы вы бы дали вашему коллеге – сильному разработчику, который недавно, буквально вчера, стал тимлидом? С каких конкретных, понятных действий ему стоило бы начать свою работу в новой должности?
2. Какие книги или статьи вы бы порекомендовали прочитать руководителю разработки? А какие ресурсы имеет смысл изучать на регулярной основе?
3. Сколько времени стоит уделять работе над техническими задачами, а сколько – над задачами, связанными с управлением коллективом? На что ещё может или должен тратить своё время тимлид?
Какие советы вы бы дали вашему коллеге – сильному разработчику, который недавно, буквально вчера, стал тимлидом? С каких конкретных, понятных действий ему стоило бы начать свою работу в новой должности?
Я бы рекомендовал для начала:
Какие книги или статьи вы бы порекомендовали прочитать руководителю разработки? А какие ресурсы имеет смысл изучать на регулярной основе?
Для руководителя разработки рекомендую к прочтению:
На регулярной основе считаю, что стоит следить за материалами и выступлениями с Teamlead Conf и других тематических митапов (например, тимлидских митапов Badoo)
Так же много полезных ссылок и обсуждений можно найти в тематических каналах в Телеграмме: https://t.me/leadgr и https://t.me/TeamLeadTalks
Сколько времени стоит уделять работе над техническими задачами, а сколько – над задачами, связанными с управлением коллективом? На что ещё может или должен тратить своё время тимлид?
Считаю, что здесь нет единственного верного ответа. Задача лида как раз в том и заключается, чтобы оценить конкретную ситуацию и решить для себя, как распределить свое время, чтобы добиться максимального результата.
В моем идеальном мире чем меньше времени у лида уходит на управление командой (в управление я включаю и технические и менеджерские функции) – тем лучше. Считаю, что залог успеха и дальнейшего роста для лида – построить команду, которая работает эффективно с минимальным его участием. В таком раскладе лид может и должен вкладывать освободившееся время в поиск новых полезных идей и проектов за пределами текущей области ответственности.
Какие советы вы бы дали вашему коллеге – сильному разработчику, который недавно, буквально вчера, стал тимлидом? С каких конкретных, понятных действий ему стоило бы начать свою работу в новой должности?
Какие книги или статьи вы бы порекомендовали прочитать руководителю разработки? А какие ресурсы имеет смысл изучать на регулярной основе?
Хороших книг много, остановлюсь на основных, как мне кажется.
Обязательно что-то про переговоры, про эмоциональный интеллект и умение общаться с людьми. Можно Гевина «Договориться можно обо всём», Гоулстона «Я слышу вас насквозь», «Не рычите на собаку» от Карен Прайор.
С ресурсами сложнее. Обычно я нахожу интересные материалы на Медиуме, Хабре, GeekTimes, infoq.com, блогах уважаемых людей вроде Джоела Спольски. Я подписан на несколько управленческих каналов, где постоянно проскакивают интересные ссылки, я их смотрю, а заодно изучаю ресурс, на котором они размещены. Так можно найти множество не очень известных сайтов и блогов, но с очень неплохим контентом. Можно читать vc.ru, рассылка Мегаплана иногда подкидывает неплохие материалы.
Сколько времени стоит уделять работе над техническими задачами, а сколько — над задачами, связанными с управлением коллективом? На что ещё может или должен тратить своё время тимлид?
Всё очень зависит от того, как устроен проект, команда, компания. Я встречал совершенно разные пропорции, но чаще всего это что-то типа 100% времени на технические задачи и 46% времени на управление :))) Заканчивается это всегда одинаково нехорошо. Имхо, в реальности самая верная пропорция выглядит примерно так. Время на технические задачи — это 100% минус время на управление коллективом. 100% — это не 8 часов, если что. У каждого свои 100%. Другими словами, цифра плавает.
Обязательно нужно тратить время на самообразование, расширение кругозора в смежных областях (продукт и проджект-менеджмент; если ты бекенд — потыкать палочкой фронт, тестирование, эксплуатацию, ну и наоборот, конечно же), поддержание технической формы — новые фреймворки, библиотеки, языки, всё что так или иначе касается работы. Иначе есть риск потерять авторитет среди инженеров. Нужно посещать митапы и конференции, дабы расширять кругозор и искать ответы на свои вопросы.
Какие советы вы бы дали вашему коллеге — сильному разработчику, который недавно, буквально вчера, стал тимлидом? С каких конкретных, понятных действий ему стоило бы начать свою работу в новой должности?
Остановиться и ответить себе на вопросы:
Дальше, учитывая результаты ответов на эти вопросы, надо составить план, кому сдать старые обязанности и как принять новые. Нужно учитывать, что после перехода на позицию тимлида общения станет больше, а вот времени на разработку — меньше. Очень важно учитывать критерии успеха, по которым ты сам и твой руководитель поймут, что ты успешно справляешься с новой должностью.
Если переходить ко второму вопросу про конкретные и понятные действия, то могу сказать, что такого списка понятных действий, который универсально подходит ко всем ситуациям нет, а значит вам придется самому составить такой список, исходя из вашей ситуации.
Какие книги или статьи вы бы порекомендовали прочитать руководителю разработки? А какие ресурсы имеет смысл изучать на регулярной основе?
Я бы выделил книгу Фредерика Брукса «Мифический человеко-месяц». Это классика о проблемах команды в крупных проектах, в которой подробно разобран проект компании IBM по разработке OS 360. Также считаю очень полезными книги от Тома Демарко, в особенности «Человеческий фактор» и «Паттерны поведения проектных команд». А на закуску я бы посоветовал книгу Дж. Ханк Рейнвотер «Как пасти котов».
Среди онлайн ресурсов я почитываю поток Управление на Хабре и знакомлюсь с выступлениями в потоках по управлению на крупных конференциях, таких как РИТ, Highload++, Codefest и остальных.
Одним из моих увлечений является разработка в широком смысле слова, включая управление командами разработки. И свои мысли, впечатления от прочитанных книг, посещенных конференций и митапов я публикую на своей странице в фейсбуке. Возможно, эта страничка вам будет полезна.
Сколько времени стоит уделять работе над техническими задачами, а сколько — над задачами, связанными с управлением коллективом? На что ещё может или должен тратить своё время тимлид?
Нельзя четко сказать, в каком соотношении распределять время между техническими задачами и командой, т.к. это сильно зависит от конкретной команды и ее задач. В общем, можно сказать, что решение технических задач становится вторичным по отношению к тому, чтобы команда работала эффективно. По-моему мнению, тимлид должен тратить время на:
Какие советы вы бы дали вашему коллеге — сильному разработчику, который недавно, буквально вчера, стал тимлидом? С каких конкретных, понятных действий ему стоило бы начать свою работу в новой должности?
Я сказал бы ему: дорогой друг, перед тобой стоит страшно интересная задача: включить в свою картину мира не только технологию, но и людей, и проекты, и их сложные отношения. Это позволит тебе решать качественно более сложные задачи, которые ведущий разработчик в одиночку решить не может. Для этого нужно научиться видеть не только то, что мы делаем в повседневной проектной работе, но и то, для чего мы это делаем, как и почему.
Предположим, что свежеиспечённый тимлид попадает в этом качестве в новый для себя проект. Начать можно с получения ответов на конкретные вопросы:
Что делать в первую очередь?
Какие книги или статьи вы бы порекомендовали прочитать руководителю разработки? А какие ресурсы имеет смысл изучать на регулярной основе?
Брукс, «Мифический человеко-месяц». Ни-че-го не изменилось за прошедшие пол-века.
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 нет универсального рецепта.
На что ещё может или должен тратить своё время тимлид?
Следующая встреча, на которую ещё можно зарегистрироваться, состоится 28 ноября 2018 года в московском офисе Яндекса. На ней можно будет задать вопросы докладчикам и поделиться своим опытом.
К сожалению, не доступен сервер mySQL