- Главная
- →
- Новости
Открываем доступ к докладам тимлидов на HIghLoad++ 2017
Для этого обзора мы выбрали четыре наиболее популярных выступления. Приятного чтения, а обсуждать тему тимлидов вы продолжим через пару недель на конференции для тимлидов и про тимлидов — TeamLead Conf.
Goth2Boss: ломка и отходняки при переходе из инженера в тимлиды
Артём Каличкин
Для меня (анализ этого доклада нам любезно предоставил Роман Ивлиев) это открытие года — на мощной технологической конференции первое место занимает доклад, хоть и от технаря, но про УПРАВЛЕНИЕ. Конечно, можно рассуждать на тему того, что гуманитарии более охотно ставят оценки, и они по умолчанию более лояльная аудитория, но факт остаётся фактом.
Рассказ про особенности и проблемы при переходе от инженера к руководителю. В докладе можно выделить две части. Первая, которая раскрывает тему доклада — про проблемы при переходе из инженерного состава в руководящий, и вторая — советы руководителям о том, как выращивать и ухаживать за новоиспеченными руководителями. На самом деле, проблематика, которая рассматривается, охватывает все уровни иерархической лестницы, т.к. “болячки” характерны для перехода на любой следующий уровень управления.
Всегда интересно слушать профессионала, который честно и открыто делится опытом, причём, как удачным, так и неудачным.
Первый и очень крутой совет звучит как — “Будьте честными, относительно того, что у вас получается хорошо, и что вы умеете”. Артём рекомендует провести сеанс самоанализа и честно (это очень важно) понять, где есть ваши слабые стороны, чтобы ни при каких условиях не использовать их, ну или, как минимум, не использовать их в первую очередь. Если у вас хорошая память, вы неплохой коммуникатор — используйте эти качества.
Если же вас всё-таки угораздило стать руководителем, то надо быть готовым к тому, что на вашем пути обязательно встретятся следующие неприятные моменты:
1. Жгучее желание прикрывать своих сотрудников от внешних угроз
(в Корпорации Добра есть специальный термин Shit Umbrella, который очень ярко иллюстрирует этот поведенческий паттерн).
С точки зрения Артёма это одно из величайших зол для команды и для руководителя, т.к. подразделение становится для внешнего мира чёрным ящиком, маскируются проблемы, уровень критичности к себе и своим ошибкам понижается. Всё это приводит к снижению качества и интереса к работе.
Любая ситуация, которая выводит человека из зоны комфорта, стимулирует его подключать дополнительные ресурсы и работать максимально эффективно и продуктивно. Хотите получить это — закрывайте зонтик, хоть и не сразу. Кстати, о том, как закрыть зонтик правильно, есть вопрос и ответ после основного доклада.
В качестве совета-иллюстрации Артём приводит эпизод из жизни своего коллеги, который в случае факапа, приходил в команду и говорил — “Мы облажались”. Здесь важно то, что нет кого-то конкретного, кто провинился. В итоге команда сплачивается, мобилизуется и исправляет то, что стало причиной этого прихода.
2. Сложности восприятия отложенных результатов
Здесь речь идёт о том, что у инженера есть вполне себе конкретный результат работы, который может быть достигнут в обозримые сроки и осознан. Что же касается руководителя, то тут всё сложнее, т.к. сама суть руководства не подразумевает объективности оценки действий руководителя. Вряд ли кто-то может сказать однозначно: “Да, мы внедрили процессы успешно”.
Чаще можно услышать эпитеты “в целом”, “достаточно”, “почти” и т.д. Т.е. конечный результат может быть достигнут и будет достигнут, но не сразу, а, главное, что всё время, пока результата нет, руководителя преследует ощущение, что ничего не происходит и некоторая неуверенность, что то, что делается - делается в направлении достижения цели.
3. Стремление к выработке идеальных решений
Важно помнить, что “лучшее — враг хорошего”. К сожалению, текущие реалии таковы, что руководитель вынужден практически в 100% случаев принимать решения в условиях нехватки информации, времени на анализ или отсутствия ресурсов на выработку того самого идеального решения.
Звучит немного странно, но Артём утверждает, что, если вы приняли идеально-правильное решение, значит, вы где-то что-то обязательно упустили. И, как минимум, потратили слишком много времени на его выработку. От себя добавлю — такие решения принимаются достаточно часто, но это, скорее, везение и большой опыт.
4. Уместный слайд
Бич всех новоиспеченных руководителей — желание делать всё самому и, вообще, что-то делать руками. Очень важный момент — важно отличать проблему делегирования от желания работать руками. Далеко не всегда желание работать руками связано с отсутствием умения делегировать. Большинству просто нравится выполнять инженерную работу и немного снижать ту самую “профессиональную ломку”. Крайне полезный совет — работайте руками, но смещайте направление своей деятельности с тактических задач к стратегическим. Цитата: “Бывших инженеров не бывает”.
Вторая часть рассказа посвящена вопросам взращивания и поиска руководителей внутри подразделения: поиск, тестирование компетенций, вербовка, а главное — поддержка на первых этапах становления нового руководителя. Нельзя бросать человека, каким бы крутым он не казался.
В завершение приведу мой хит-парад эпизодов из этого рассказа:
1 место
Артём приводит пример того, как он и его подопечный год пробовали создать руководителя, но в итоге признали, что это всё не то, и инженер остался инженером. При этом особо отмечает, что должна быть легенда на случай провала, когда придётся коллективу объяснять, почему человек вернулся на прежнюю позицию (мой личный опыт подсказывает, что это наиболее сложная задача в такой ситуации).
2 место
На втором месте расположился эпизод, когда к удивлению части аудитории внезапно звучит фраза: "Быть инженером куда прикольнее на самом деле, а переход в руководители — не переход в страну розовых пони".
3 место
Ну, и замыкает пьедестал рассказ о том, что спустя 10! лет, ничто человеческое не чуждо. Пруфпик.
Остаётся отметить, что 25 минут вопросов и ответов после окончания доклада в очередной раз продемонстрировали востребованность темы управления и карьерного роста в ИТ.
Как стать тимлидом
Андрей Рыжкин
Во втором докладе из нашего дайджеста Андрей Рыжкин (компания AGIMA) описывает собственноручно формализованную процедуру выращивания тимлидов внутри команды, попутно предостерегая разработчиков о том, что же изменится в их жизни, если они перейдут на "темную сторону", т.е. в руководители.
Как отмечают в своих докладах многие участники конференции, новоиспеченному тимлиду придется привыкнуть к тому, что времени на разработку и интересные задачи, связанные с какими-то исследованиями, у него уже не останется. Кроме того, придется выйти из комфортного потокового режима работы — как-то уживаться в мире с параллельными задачами, прилетающими одновременно по нескольким каналам, а также с большим количеством коммуникаций и планированием.
В своем докладе Андрей Рыжкин дает некоторые советы, как справиться с непривычной ситуацией и не перегореть под давлением ответственности, а, может, и оставить себе задел на дальнейшее развитие (хотя по его данным 90% тимлидов так и останавливаются на этом уровне).
Доклад будет интересен не только сегодняшним разработчикам, метящим в тимлиды, но и руководителям, которые пытаются вырастить в коллективе себе замену. Им Андрей поможет ответить на вопросы: кого стоит взять в тимлиды? На какие качества надо обратить внимание? Стоит ли возлагать эти обязанности на самого лучшего разработчика в команде?
По опыту докладчика, чтобы прогнозировать вероятный успех персонажа в роли тимлида, ему достаточно обладать всего тремя качествами: эмпатией к команде, решительностью и технической компетенцией. Но все не так просто: на старте тимлиду нужна помощь, которую иногда можно обеспечить через правильные привычки внутри коллектива. Один из обсуждаемых примеров — так называемый "санитарный день" (а на самом деле — санитарные часы) — время, выделенное для написания отчетов и планирования. Практики, принятые в AGIMA и подробно описанные в докладе, подсказывают, с какой стороны, вообще, можно подступиться к решению проблем тимлида.
Естественно, рассмотрена и другая сторона вопроса — "косяки" неопытного тимлида, с которыми можно и нужно бороться (как один из примеров — любовь к закапыванию в длинных задачах). В ходе вопросов после доклада обсудили и процесс обучения остальной части команды, как правильно взаимодействовать с тимлидом.
В дополнение Андрей Рыжкин предложил список литературы, которая будет полезна будущему тимлиду. Эту ссылку вы еще встретите в презентации спикера, но мы решили вынести ее в наш анонс.
Все, что тимлид должен знать о найме и увольнении
Степан Овчинников
Следующий доклад переводит нас к теме ежедневных обязанностей тимлида. Несмотря на то, что кадрами в компаниях, как бы, занимается HR-отдел, будущий непосредственный руководитель нового сотрудника должен участвовать в найме — в конце концов, ему потом руководить этим человеком. Степан Овчинников (компания Интерволга) дает выжимку полезной информации о том, куда смотреть и за что хвататься тимлиду, который включился в процесс сбора команды.
Представленный опыт был получен в компании с 60 сотрудниками (32 из которых — программисты), реализующей заказные проекты на Bitrix, что, как бы, ограничивает его применимость. Однако с определенными оговорками приведенные рекомендации можно использовать в самых разных ситуациях.
Докладчик прошелся по всем основным моментам работы с персоналом со стороны тимлида: найме, мотивации и даже увольнении (хоть это и считается в современном мире кощунством). Высказал рекомендации, что спрашивать на собеседовании, чтобы вскрыть мотивацию и выявить неадекват, предложил пути для поддержания уже нанятых сотрудников в состоянии повышенной мотивации, подсказал, как лучше уволить человека, чтобы не взбудоражить остальную команду.
Ценность доклада в том, что в нем даны вполне конкретные советы — что делать, чтобы собрать команду и не растерять ее. К примеру, Степан рекомендует периодически вести неформальные разговоры с коллегами, чтобы следить за их настроением и вовремя заметить назревающие проблемы. Еще одна полезная рекомендация — постоянно повышать сложность задач, чтобы избавить разработчиков от скуки. А если это по каким-то причинам невозможно (поменять технологии в большинстве компаний не так просто), сотруднику можно выделить время на профессиональный рост.
За остальными идеями советуем обратиться к докладу. Там все рекомендации дополнены весьма красочными примерами из жизни.
Кстати, и тут не обошлось без обсуждения типичных проблем начинающего тимлида, например, любви к глубокому погружению в любой вопрос или боязни увольнений своих подчиненных. Так что с точки зрения формирования образа тимлида доклад дополняет два предыдущих.
Команда как высоконагруженная система
Антон Потапов
В своем докладе Антон Потапов (компания Ingram Micro) проводит аналогию между командой разработчиков и проблемным высоконагруженным приложением, чтобы разъяснить типичным интровертам, как разобраться во взаимодействии людей. Специалист считает, что по аналогии с тем, как решаются проблемы в программном продукте, можно справиться с командными сложностями. И приведенные в докладе примеры — его личный опыт по решению вполне конкретных проблем.
В докладе разобран, например, такой типичный паттерн как перегруженный тимлид, который занимается мелкой текучкой и накапливает "технический долг" перед решаемой задачей. Для устранения этой проблемы по аналогии с балансировкой нагрузки в команде был выделен так называемый Exception man, задача которого — обслуживать все входящие обращения, защищая команду от внешних раздражителей. А чтобы расшарить в команде экспертизу, статус Exception man стал "переходящим" (каждый "дежурит" по неделе). Это принесло свои плоды и, кстати, вызвало немалый интерес аудитории, присутствовавшей на докладе.
Аналогичным образом Антон разобрал и другие типичные ситуации — перегрузку команды, которая срывает сроки, опять же, накапливает технический долг, предлагая вместо нормальных решений костыли; наличие людей с уникальными навыками, что ставит под угрозу решение задачи при больничных, отпусках и увольнениях; непрозрачные статусы разработки и т.п. По каждой ситуации предлагается аналогия из мира разработки и ее интерпретация в терминах команды. Также даются довольно очевидные, но не всегда применяемые советы, например, использование единого списка улучшений.
Тема интересна?
Обсуждать тему тимлидов вы продолжим через пару недель на конференции для тимлидов и про тимлидов — TeamLead Conf. Подключайтесь!
