Тимлид

До единственной профессиональной конференции только для тимлидова TeamLead Conf 2021 осталось совсем немного 29 и 30 апреля она распахнет свои двери для всех, кто хочет повысить скилл в сфере управления. В этой статье мы приоткроем завесу тайны и расскажем о том, что вас ждет.

О самых выдающихся и полезных докладах, о вариантах участия в конференции, мерах защиты от коронавируса (куда уж без них в наше время?) и о том, как тимлидам справиться с условиями удаленной работы рассказал руководитель программного комитета TeamLead Conf 2021 Роман Ивлиев.

Расскажи о себе: кто ты, чем занимаешься и как принял решение присоединиться к программному комитету?

На текущий момент я являюсь техническим директором портала Mos.ru. Я с самого начала участвовал в создании TeamLead Conf, а со второй конференции стал руководителем программного комитета.

Мне интересна эта сфера. Она не совсем техническая, на TeamLead речь идет об управлении. А конференций об управлении на таком уровне в 2018 году России не было. Сейчас это модная тема: есть обучающие курсы, куча школ. Но началось все после нас. Современные курсы для тимлидов в Geekbrains и Skillbox появились буквально полтора года назад.

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

Первая конференция, как мне кажется, была совсем небольшой: в ней приняли участие около 400 человек. А дальше шло по нарастающей. На пике популярности в Москве к нам приходили 1200 или 1300 слушателей. И даже сейчас, когда многие сидят по домам, интерес к этой сфере есть.

Хотя, надо сказать, народ стал ленивым. А конференция это все-таки тяжелый труд, если ты идешь на нее как полагается: все слушаешь, что-то записываешь, ищешь какие-то идеи.

В чем особенность конференции в этом году? Ходят слухи о том, что ее будет интересно посетить не только тем, кто работает в IT.

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

У нас была идея попробовать такой формат, поскольку появилась конференция TechLead, которая утащила на себя всю технологическую составляющую.

В свое время мы пытались собирать на TeamLead Conf, в том числе, и технологии. У нас была попытка сделать технологичный трек. Но оказалось, что тем, кому интересны технологии, не интересно управление, а тем, кому интересно управление, плевать на технологии, в той или иной степени. Раз уж такое разделение произошло, мы подумали: если мы уже отпилили всю технологическую составляющую, есть ли принципиальная разница между людьми, которые управляют айтишниками, и людьми, которые управляют, допустим, маркетологами или дизайнерами? Методы и подходы одинаковые, люди тоже. Единственная специфика это сам производственный процесс.

Поэтому конференция в этом отношении более гуманитарная, чем все предыдущие версии.

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

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

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

Максимальная вместимость площадки: около 1200 человек. А мы можем позвать не более 50%.

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

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

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

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

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

А дальше уже помогает литература, общение с живыми людьми, применение всего этого на сотрудниках, с которыми ты работаешь.

Как таковой, тусовки на конференции нет. Это не HighLoad, куда приезжают из года в год, чтобы просто пообщаться друг с другом, выпить пива и обсудить актуальные вопросы. Мы создали чат Боль тимлида, который должен был стать этой точкой притяжения. Но если говорить объективно, там есть актив в 30-50 человек, которые постоянно мутят воду, поднимают какие-то вопросы, отвечают на них, ругаются друг с другом и т.д. А еще есть 4 тысячи человек, которые просто это читают.

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

Все IT сообщество соскучилось по оффлайновым мероприятиям. Каков настрой у спикеров, рвутся ли они в бой? И как быть тем участникам, кто все-таки не сможет прийти? Есть онлайн-альтернатива очному посещению?

Многие спикеры, которые приедут к нам, уже переболели ковидом. Наверное, около 90 процентов подтвердили свое участие, оставшиеся долечиваются, договариваются с семьями и т.д.

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

У нас будет гибридный формат конференции: участников ждет свой контент и свои активности и онлайн, и оффлайн.

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

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

И у онлайн, и у оффлайн аудиторий будут уникальные активности. Например, мы никогда не транслируем онлайн происходящее на митапах. Это довольно сложно сделать, ведь их формат общение с залом. Мы пробовали, получается так себе. А в онлайн появится возможность поговорить с экспертами. Все секреты раскрывать не буду: откроем их на конференции.

Думаю, онлайн с нами надолго. И это очень перспективное направление, если правильно к нему подойти. Например, компаниям, которые работают за Уралом, очень дорого везти своих сотрудников в Москву. Теоретически, если оффлайн нормально состыкуется с онлайном, аудитория вырастет.

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

Расскажи подробнее о докладах, принятых в программу конференции. Что полезного из них могут вынести гости TeamLead Conf?

Неинтересные доклады мы просто не принимаем. У нас достаточно злобный программный комитет в том плане, что мы очень требовательны к докладам, и всегда стараемся выбирать лучшее. В этот раз, например, к нам придут ребята из НовосибирскЭнергосбыт. И интересно даже просто послушать, что люди, работающие в другой области, живут примерно по тем же правилам. Они расскажут о том, как они сокращали Time To Market.

Есть хороший доклад о том, как можно развалить любую команду. Обычно люди очень хорошо учатся на таких примерах, потому что их тут же примеряешь на себя. Успех примеряется плохо, потому что ты, конечно, самый умный, и у тебя самые большие победы.

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

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

Есть более приземленные доклады. Например о том, как правильно работать с совещаниями. Удаленные совещания вещь специфическая, и не все их нормально посещают.

На удаленке бывает сложно удержать фокус. Когда у тебя в Зуме становится много экранчиков, половину людей ты просто не видишь. Особенно тех, кто сидит с выключенными камерами и микрофонами. Они может вообще ушли картошку чистить, а ты рассчитываешь на то, что они слушают со всем вниманием.

Будет нетрадиционный для нас докладчик из X5 Retail Group (это компания, управляющая продуктовыми торговыми сетями Пятерочка, Перекресток, Карусель и Чижик). Он расскажет про карьерные уровни. Интерес в том, что это карьерные уровни в необычной для нас сфере. Мы привыкли к тому, что IT это Яндекс, Mail, Badoo, Авито, еще 10 известных компаний. В стране это 5% айтишников, а остальные 95% люди, которые работают совершенно в другом мире.

Только представьте, сколько людей работают на налоговую, чтобы сделать сервис Налог.ру, или все личные кабинеты МосЭнергоСбытов. Даже у человека, который собирает в маленьком городке показания для домофонов есть свой персональный кабинет, и кто-то его программировал.

Мы привыкли, что интернет это всякие публичные сайты и магазинчики. А есть еще огромная гора приватного интернета, про которую редко кто-то рассказывает. И наконец-то появился шанс об этом послушать.

Есть доклады от представителей известных компаний: Kaspersky Lab, Тинькофф банк, Evrone это наши постоянные докладчики.

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

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

Будут подниматься вопросы, связанные с планированием, со стратегией развития сотрудников, с подготовкой команд и ничего IT-специфичного. Если ты не айтишник, тебе тоже будет интересно. Конечно, есть доклады, которые про айтишников, но их меньше, чем было раньше. В этом году стало больше более популярных и общедоступных вещей.

Один из докладов конференции называется Команда мира. Счастливая удаленка и инструменты, которые сработают. А как вообще удаленная работа сказалась на деятельности тимлидов? Стало проще, или сложнее выстраивать работу с сотрудниками? И как настроиться на то, что теперь (хотя бы на какое-то время) удаленка часть жизни?

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

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

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

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

В общем, где-то нужно убавить коммуникацию, где-то наоборот нарастить. Каждый решает эти вопросы по-своему. Я знаю примеры, когда сотрудники находятся в режиме созвона весь день. Они работают с включенными камерами и микрофонами. Создается впечатление, что все сидят в одной комнате. С моей точки зрения, это ненормально. Но есть и такой подход. Причем, как люди утверждают, что это их мотивирует. Я за них безумно рад, но сам бы от такого одурел. Как будто ты в рабочее время находишься в Доме-2.

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

Почему ты сам посещаешь конференции? Часто ли выступаешь как спикер?

Стараюсь посещать. Во-первых, ищу на них новых докладчиков, а во-вторых, просто узнаю о новинках. Многие конференции посещаю из-за тусовки, тот же HighLoad. Туда приходят много ребят, с которыми я редко вижусь в других местах.

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

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

В онлайн так не получается. Я могу послушать доклады и выпить кофе с булочкой и дома. Но посмотреть, что предлагают партнеры, прочитать книги, которые принесли, поболтать с кем-то лично не выйдет.

С возрастом становится сложнее выбирать мероприятия, потому что растет опыт. На каждой конференции можно найти всего 1-2 интересных мне доклада, из которых можно что-то вытащить для себя.

Что обычно советуешь своим подопечным, чтобы их выступления стали лучше? Есть ли лайфхаки, которыми можно поделиться в открытую?

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

Есть два типа людей, которые посещают конференции. Первые приходят для того, чтобы понять: они двигаются в правильном направлении. Особенно это касается HighLoad и других технических конференций. А есть люди, которые реализуют обратные цели. Они переживают, что делают все неправильно, приходят на конференцию, а их действия это мейнстрим!

Поэтому очень важно не врать. В моменте, когда ты врешь, ты можешь сам себе поверить. Это когнитивное искажение 1. Ты рассказываешь, как все офигенно, и веришь в это, в моменте. А на самом деле все не так, и ты бессмысленно тратишь время.

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

Совет номер два: до конференции обязательно нужно зачитать свой доклад кому-то, и лучше пару раз. Как он звучит у тебя в голове, и как его воспринимают другие люди это совершенно разные вещи. Бывает, что я целый месяц думаю перед тем, как начать рисовать слайды, обсуждаю их с кем-то, выслушиваю мнения, что-то корректирую. Есть те, кто делает это с колес. Да, можно выйти вообще без подготовки, но будут ли счастливы слушатели?

Последний вопрос. Если бы тебе нужно было посоветовать своему другу пойти в этом году на TeamLead Conf, какие слова бы ты подобрал? Почему он должен посетить ее именно в 2021 году?

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

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

Придя на оффлан конференцию, ты выделяешь время на обучение. Ты не можешь никуда уйти. Максимум, что можно сделать это сесть поработать в коридоре. Но я считаю, что это не слишком умный поступок.

Я всегда рад, когда ребята из моей компании просятся на какую-нибудь конференцию. Как минимум, это говорит о том, что люди хотят развиваться. Для специалиста любое проявление интереса очень важный критерий того, что он профи. Если человек не проявляет интереса, даже не почитывает Хабр, это уже не специалист.

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

На конференциях все радостно идут на контакт. Можно поболтать за обедом, или в коридоре.

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

Московская конференцияTeamLeadConf 2021 в этом году пройдет 29 и 30 апреля вRadisson Slavyanskaya. Расписаниеконференции уже готово.Билетыв продаже. Присоединяйтесь!

А если вы хотите еще и выступить, спешите подать доклад на питерскую конференциюSaint TeamLead Conf 2021.Выходите на свет рампы вместе с нами!

Хотите бесплатно получить материалы предыдущей конференции для тимлидов? Подписывайтесь на нашу рассылку.

Мы хотим расти не только внутри в компании, но чтобы за её пределами это имело какой-то смысл. Наши руководители хотят простых инструментов и переговоров, чтобы как-то выдерживать диалоги на тему Хочу роста! или Хочу еще +X денег! А компания в то же самое время хочет развития компетенций и большей автономии сотрудников.

В Wargaming Platform смогли учесть интересы всех трех сторон им помогли карьерные уровни и в развитии людей, и в формирования к ним ожиданий. Wargaming Platform это инженерная организация, которая решает общие проблемы для разных игр (тех же Танков, Кораблей, Самолетов): как залогиниться, как заплатить, как написать тикет в саппорт, как сделать что-то еще общее для всех игр. Илья Росляков занимается в ней тем, что разруливает ситуации между руководителями и сотрудниками на тему роста и развития, и в том числе руководит несколькими командами разработки, DevOps практикой. Сегодня он расскажет, как в компании внедряли его инициативу о карьерных уровнях и что получилось в результате.

Почему мы вообще подумали, что нам карьерные уровни помогут?

В целом, у нас уже был развитый институт People Management: люди делали perf-review, one-on-one, встречались, разговаривали о развитии то есть почва для карьерных уровней уже была готова. Мотивация роста у каждого, конечно, была своя: кто-то хотел денег, кто-то признания, а кто-то растил собственную автономию. Путь у всех был разный, но главное люди уже хотели расти.

В то же самое время наши эйчары выяснили, что в компании более 75% профессионалов, т.е. каждый несомненный эксперт в своем деле, и в то же время среди них:

• Первые 40% были не автономны и нуждались в развитии то есть им постоянно была нужна помощь руководителя и/или коллег, чтобы делать их обычную работу.

• А другие 40% были автономны в собственной работе, но не отвечали за развитие других. Они сами были автономны, но вокруг трава не расти!

То есть с точки зрения компании только 20% сотрудников - гуд. Тогда мы изучили опыт топовых IT-компаний: ко такой тимлид, техлид и что происходит в Big 4 (Google,Amazon, Apple,Facebook) чтобы людей правильно направлять не только в нашем взаимодействии, но и в целом по жизни. По ходу дела мы также поняли, что у нас есть много людей, которые делают похожую работу то есть, генерализация тоже будет иметь смысл.

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

Зачем это руководителям?

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

Зачем это компании?

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

Зачем это сотрудникам?

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

Остальные опции связь с внешним миром, открытость в переговорах тоже здесь доступны. И это еще и возможность почелленджить своего руководителя. Ты приходишь и говоришь: Хм, а вот в Google не так А FaceBook иначе делает Понятно, что это не всегда конструктивная беседа, но вы начали говорить хотя бы это уже круто.

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

Решение

Карьерные уровни можно было бы представить как-то так:

Если бы на самом деле это не было совсем по-другому. С грейдами их тоже невозможно сравнить, потому что в грейдах формула заработной платы выглядит так:

ЗП = компания + регион + (роль + карьерный уровень + ЗП-вилка) = грейд

А у нас нет четких зарплатных вилок для пары роль - карьерный уровень. Карьерные уровни ничего не меняют в том, как работает зарплата. Они просто появляются, а смена зарплаты возможна, если срабатывает триггер (event):

• Смена роли;

• Смена карьерного уровня;

• Смена внутри уровня: изменение обязанностей, перф.

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

На внешние мы не можем повлиять:

• Рынок он такой, какой есть: одни люди становятся дороже, другие дешевле.

• Есть бюджеты. Если компания не стала фундаментально больше зарабатывать и бюджет не увеличился, то, очевидно, фундаментально зарплата не поменяется.

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

На что-то мы влиять можем:

• Очевидно, что на роли, карьерные уровни, на свой перф. Перф это raw performance человек просто больше работы делает. Или по другому: average как человек в среднем работает.

• На нашу стабильность вообще на нашу жизненную синусоиду, среднеквадратическое отклонение, насколько нас колбасит в работе.

Так что у нас очень сложно сделать вывод о зарплате людей из их карьерного уровня. Но карьерные уровни реально отражают интересы трех сторон сотрудников, руководителей и компании. Это тот самый трёхсторонний договор, который мы в итоге подписали.

Плоский граф требований

Мы начали с инженеров, потому что в них разбираемся. Мы написали много смартованных требований, типа: Коммуникация занимает не более, чем 20% времени инженера. И дальше для каждого уровня добавлялись новые:

Но в какой-то момент мы поняли, что зашли куда-то не туда. Что же пошло не так?

• Требования многократно наследовались. Кто писал код на каком-нибудь ООП, знает чтобы развернуть наследование очень далеко назад, нужен просто взрыв мозга, чтобы разобраться: Так, а кто сеньор? Вот этот? А он еще от миддла что-то наследует. жесть, в общем.

• Навыки были разрознены, и строчка каждый раз была новой. Они визуально очень сильно различались, и при этом записаны были тоже сильно по-разному: где-то про языки, где-то про коммуникации. Это было очень сложно читать.

• Критерии были бинарными (смартовыми). Смарт это хорошо, но не в случае с людьми. Представляете, вдруг выясняется, что у кого-то какой-то процесс занимает 19% времени но зачем и как он это считал?! Но даже если посчитал вот он приходит к руководителю: У меня 19 А надо 21 и начинается bullshit.

Двумерная матрица

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

У нас получилось 7 уровней по горизонтали от 1 до 7. Это было лучше, но все же кое-что снова было не так:

• Семь уровней компетенций были неразличимы между собой. Например, уровень знаний на четверочку по семибалльной шкале что это значит? У нас никто так и не смог до такой степени глубоко прочувствовать все эти сферы, чтобы делить от 1 до 7.

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

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

Трехмерная матрица

Всего в этой табличке у нас было 42 строчки. Мы добавили веса, чтобы убрать дискретность всё стало гибко, подробно, но... стало просто ничего не понятно. Люди за пределами рабочей группы вообще перестали понимать, о чем мы разговариваем.

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

Двумерная матрица и линейка

Мы выделили 6 ключевых компетенций:

1. Знания,

2. Sharing,

3. Инновации,

4. Сложность задач,

5. Цель/Просто задачи,

6. Автономный менеджмент.

И описали для каждой те минимальные требования, которые удовлетворят карьерный уровень. Уровни же определили просто: 0 нет компетенции, 2 сформированная компетенция и т.д. Но снова не пошло, так как выяснилось, что описания уровней компетенций бессодержательны например, что такое conscious, я и сам с ходу забыл.

Тогда мы изучили крупные компании типа Google, Electronic Arts и т.д. и оттуда позаимствовали некоторые названия компетенций. Но все еще не хватало точности в определении, какого же уровня каждый сотрудник.

Area of Effect (AoE)

И тут мы подумали мы же игровая компания в конце концов! И ввели понятие Area of Effect (AoE), который измеряет постоянное и позитивное бизнес-влияние компетенции в текущей компании. Звучит длинно, а на мы соединили 6 компетенций и AoE от 1 до 5:

1 Сам человек, например, у него sharing прокачан только в себя;

2 Это что-то на команду. Сами решайте, что для вас команда например, это постоянная группа людей.

3 Несколько команд или несколько неопределенных групп людей;

4 Бизнес-unit. Например, мы считаем у себя в Wargaming, что это Platform. Но у кого-то это будет целая компания. Если кратко, то это достаточно крупная и независимая бизнес-организация со своими P&L и пр.

5 Очевидно, мир.

Как проверить, например, что такое Innovation 4? Это когда я могу выти и на весь бизнес-unit сказать: Иван Иванович инноватор масштаба нашей компании!, и если на галерке никто не заржал, то это, глядишь, и правда. Если заржал, то: Ну, ладно, инноватор вон тех Что?! Я понял. Двоечка.

Калибровка

Но когда мы начали маппить наших инженеров между разными компаниями, там такая дичь началась: тут все P4, а там все P5! Поэтому мы ввели калибровку для P4 и выше это помогло, хотя и не на уровне мира. Потому что никто не калибрует уровень P2 среди компаний карьерные уровни в них разные и с этим ничего не сделать. Но максимальный карьерный уровень может быть одинаковый, потому что он глобальный и инженеры из The Big Four задали нам верхний предел.

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

А польза-то какая?

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

В остальном мы все еще в процессе наблюдения и настройки. Мы все еще смотрим, насколько руководители работают с карьерными уровнями, насколько сотрудники понимают эти уровни и насколько они им помогли расти профессионально (не карьерно). Поэтому мы еще будем докручивать и досчитывать два пункта:

• Руководителям понятен подход и они им пользуются;

• Сотрудники знают, как могут расти довольные своим профессиональным ростом через год.

А пока я покажу вам на примерах, как работают карьерные уровни.

Примеры для инженерных компетенций

Knowledge

Что ожидается от инженера? Самое простое это knowledge. Это не какой-то knowledge в вакууме типа: Умею писать на Python, но ничего не знаю про базенки и vim никогда не открывал. Это знание какой-то специфики, которое в принципе трудоустраиваемое.

Ноль это отсутствие знания. А для единички, например, мы решили, что это около двух лет коммерческого опыта. Двойка это эксперт уровня команды в какой-то технологии, например, главный питонист в команде на 7 человек, главный эксперт в БД, в Кубе, в чем-то еще. А дальше с тройки по пятерку просто scale, например, тройка главный в нескольких командах, четверку по knowledge заработал бы главный эксперт в Python в бизнес-unit, а пятерку core-контрибьютор PostgreSQL.

Sharing

Sharing самая простая штука это насколько мы шерим.

Единичка это человек, который отвечает на вопросы. К нему подошли: Поможешь? Да. Он готов разговаривать. Если кто-то накрывается полотенцем и не отвечает, то это ноль. Начиная с двойки и в пятерку опять простой scale. Двойка шерит знания проактивно, и замечу, постоянно, с пользой для компании. То есть это не просто человек, который ходит и кричит: Перепишем все на OCaml! (Зачем, почему, мы вообще на 1С тут) должна быть польза, и она должны быть хоть как-то измерима, хотя бы каким-то экспертным мнением и в текущей компании, а не где-то в воображаемом мире. Это также может быть человек, который онбордит новичков в команде, причем по собственной инициативе. Пример пятерки это постоянный спикер на внешних интернациональных конференциях.

Innovation

Инновации это когда вы в компании предлагаете что-то полезное (польза определяется постфактум), и делаете это периодически.

Нолик, получается, ничего не улучшает. Единичка улучшает внутри себя, например, свои собственные методы работы. Двоечка улучшает внутри команды. Предложили что-то в команде, оно зашло о, несем в другие команды. Можно затащить в компанию то, что не является уникальным какой-то процесс, например, people performance process в компанию это будет уже четверочка, потому что с точки зрения компании это уникальная инновация. Пятерка это тот, кто изобрел React.js и вытащил его в мир.

Complexity

Есть восхитительное и непонятное определение: сложность это преодоление начальной неопределенности. Но в целом, это способность человека из каких-то двух мутных слов перейти к действиям.

Отработать пятерку это создать компанию по сути дела, у меня это написано как Реализовать Platform. Четверка это тот, кто понял, как реализовать части этой компании, например, из чего состоит Platform: биллинг мы должны считать, большие фичи пилить, метод взаимодействия определить. Тот же TrackingID наш внутренний туллинг, считающий, как разные игры утилизируют наше железо это четверка отработал и внедрил его. И дальше по аналогии та же двоечка реализует какой-то спайк в Agile, например, маленький research на неделю, на две, на три.

Goals/tasks

Цели и задачи это уже про координацию, когда человек может драйвить что-то. Допустим, решили делать мобильные игры, и кто-то это драйвит, а кто-то драйвит в пределах этого процесса драйва например, стабильность платформы. У тройки это выражается, например, в задачке по мониторингу scalability внутри команды.

Autonomy/management

Для роста инженерам менеджмент-скиллы тоже нужны очень сложно расти профессионально, если никому ничего не рассказывать и не доводить до конца. Если вы ходили на Менеджмент 3.0 это единичка это тот человек, который взял задачку, декомпозировал ее, проинформировал про решение, пошел делать и в принципе сделал. То есть это достаточно автономный человек, но его надо проверять иногда он может уйти в какой-то поток.

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

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

Оценка карьерного уровня

Для каждого уровня мы сформировали краткие определения:

• P7 это неопытный специалист;

• P6 это вполне уже самостоятельный человек для типичных задач;

• P5 это полностью автономный эксперт, инженер. Он все уже может сам сделать и кого-то еще менторит в команде;

Начиная с четверки начинаются люди, которые развивают других людей:

• P4 это тот, кто развивает других P5 по сути дела, то есть тех самых автономных профессионалов;

• P3 развивает P4 и т.д.

Плюс тут еще важен scale. На уровне P2 мы ожидаем, что человек развивает нам примерно 100 P5. А это означает, что в компании на 10 человек быть P2 вообще нельзя но можно, если вы, например, развиваете локальное community питонистов, где 100 сеньоров. P1 это бог.

Теперь расскажу, как меняются ожидания в зависимости от уровня.

Минимальные требования

Плюс для каждого уровня мы определили минимальные требования:

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

Если Р7 начинает учиться, то к следующему уровню (P6) у него уже должны подняться знания, он должен стать более автономным и начать отвечать на вопросы:

К уровню P5 наш студент уже вырос во всем и начал инновировать (прекрасное русское слово!). P4, как и P3, тоже растёт во всем параметрам:

А вот дальше интересно. P2 это, наверное, уже техдиректор, 100+ человек в компании. Это первый человек, который вышел на мир. Фактически мы ожидаем от него, что он начинает шарить инфу прямо на пятерочку в пределах всего мира. Эт тот человек, который компанию представляет уже на мировой арене и инновирует в масштабах всей компании. И P1, наконец, канонизированный техдиректор, бог он всё.

Что с этим делать на практике? Давайте посмотрим на примерах.

Пример оценок

• Про Лео можно сказать, что это в целом ровный чувак, который нормально шарит не в смысле в чем-то разбирается, а шарит информацию.

• Раф в чем-то прикольно разбирается, а в чем-то лучше своих коллег, и он массово учит людей. Это просто mass DDoS teacher людей!

• Майк очень автономный человек, который координирует какие-то задачки, он очень самостоятельный.

• А Дон не просто самостоятельный, он еще и сложные задачки решает самостоятельно вообще молодец!

• Кейси же человек-идея. У него всегда есть идеи, причем полезные, и это важно. Это человек постоянная полезная идея в своей компании.

Дальше появляется странная математика.

Благодаря минимальным требованиям, мы можем недостаток одного балла в какой-то компетенции компенсировать баллами сверх минимума из других. Например, если у вас не хватает sharing на единичку, то это можно компенсировать +1 knowledge и +1 complexity. Потому что и knowledge, и complexity у человека имеются сверх наших ожиданий на этом уровне.

Пример плана развития

Благодаря плану развития, вы можете сказать человеку, как ему развиваться: Ммм, Элис, тебе нужно начать рассказывать о том, чем ты занимаешься. Это типовой портрет Элис, которая недавно пришла в компанию. Она в принципе во всем шарит, но пока никто не знает, кто такая Элис. Как правило, для нее план развития просто живи, выживай, рассказывай о своей жизни.

Кто такой Боб? Боб что-то классно знает, но, блин, никто не знает Боба! Он никому не рассказывает, чем он занимается. Он роняет задачки, которые в него вбрасывают. Вообще непонятно, кстати, как мы поняли, что он шарит? Кто-то сделал best guess, видимо. План развития Боба: Чувак, вылезай из угла.

У Пита вообще сложная жизнь. Он в чем-то лучше разбирается, у него неплохие идеи, но задачи ему лучше вообще не давать, их только вместе с PM стоит ему отправлять. У него много проблем.

А дальше магия. Мы собрали команду из этих ребят, и вдруг выяснилось, что у команды все нормально. Они друг друга сбалансировали и нигде нет провалов. Даже knowledge по команде в целом лучше, чем у соседей. Так этим туллингом можно балансировать между собой разные команды:

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

Вспомогательные механики

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

Карьерная лестница

Что такое карьерная лестница? Это что-то внутри software engineering либо внутри саппорта.

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

Карьерная карта

Я здесь в качестве примера привел P4 инженеров. А кто такой P4 Python разраб? Это же профессионал бэк-разработка и вообще software-инженерия. Но в целом это можно применить не только к инженерам.

Краевые случаи

Я описал наш путь в общем, но есть и краевые случаи, давайте их тоже рассмотрим.

A M-manager vs. a P-professional или лид внезапно

• Ключевая ценность: родитель или воспитатель в садике.

• Направление роста по соглашению с руководителем.

P (professional стрим) и M (manager) у нас отдельные карьерные пути, и это отдельный рост. Типовой запрос от внезапного лида обычно бывает: О, я кто P или M? То есть человек ждет, что я ему по методологии отвечу, но правильный ответ ты сам реши, кто ты.

Тут важен тот самый вопрос кем вы видите себя через 5 лет. Если вы собираетесь расти как профессионал, смотрите в P и растите там. Собираетесь расти как менеджер растите как M. Это зависит только от вас и вашей договорённости с руководителем.

Смена карьеры

• Роль определяется ключевой ценностью сотрудника.

Бывают кейсы, когда, например, QA-инженер P5 переходит в software engineering и у него падает карьерный уровень, он становится P7 либо P6. Это нормальная ситуация, и здесь нужно смотреть, какая у него ключевая ценность. Если он все еще трудоустроен, потому что в принципе в прошлом был хорошим QA, то возможно, какое-то время его стоит оценивать как QA. Если его взяли на software инженера и неважно, какой он QA ставьте ему P7 и растите как software инженера. То есть важно, вообще почему он у вас работает до сих пор.

Оценка новичков

• Делается на основе интервью и обсуждения ожиданий с руководителем.

Кто такие новички? Это люди с рынка, которых вы собеседуете. Тут важно с ними просто договариваться. Вы же не скажете им: Я беру тебя на P4 или на P5. Они такого не понимают. Но вы должны с ними договариваться о каких-то ожиданиях через какой-то срок. Это практически проект онбординга человека. Вы ожидаете от P4 вот это, и с этим человеком на входе договариваетесь: этого я ожидаю через полгода. Если через полгода не случилось, вы даунгрейдите человека это либо ошибка найма, либо самого человека. Но все равно нужно какой-то кредит доверия выдавать людям и договариваться.

Уровни в других компаниях

Прошлый уровень кандидата влияет только на его ожидания и зависит от:

• места компании на рынке,

• методологии которую использует компания,

• специфики технологий в компании.

Уровни в других компаниях другие. Есть компании, где ключевая сфера технологии (Google), а у кого-то e-commerce, и т.п. Очевидно, что нельзя, поменяв компанию, перейти на тот же уровень, потому что требования просто разные. Мы формулировки наших требований отправляем внешним рекрутерам в другие компании и спрашиваем: Эти люди у вас кто, судя по этим текстовым требованиям? Так мы делаем исследование рынка в текстовой форме.

То есть если к вам приходит человек с уровнем P2, то это влияет только на его ожидания и амбиции. Но вам толку от этого нет.

Понижения при внедрении карьерных уровней

• Это дар богов, освещающий путь.

Если вы будете внедрять карьерные уровни, и у всех станет минус 1 уровень, даунгрейд это прекрасно, это дар богов. Вы были P4-лидом, а теперь говорите: Я сеньор, и у меня P6 и это значит, что у вас будет четко обговоренный с руководителем план роста. У вас есть легко просматриваемые зоны роста, и это клево. Мы же не понижаем зарплату, мы этот инструмент используем именно для роста.

Недостижимые уровни или как попасть в Р1

• Вся жизнь между P6 и P5 это норма. Выше стресс и переработки.

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

Уровни и свобода личности

• Расти можно кем угодно. Но кто-то может быть не нужен компании.

Это очень противоречивый раздел, по формулировке ничего не понятно. Но это про открытость.

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

Влияние на интервью

• Уровни помогут понять рынок и спланировать бюджет;

• Уровни могут быть рекламой компании.

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

Локальное внедрение

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

• Знать уровни во внешнем мире,

• Понимать, что важно компаниям в целом,

• Создать инструменты переговоров и оценки,

• Изучить ошибки в эволюции.

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

Подготовка к конференции TeamLead Conf 2021 вышла на финишную прямую до конференции остался всего месяц. Билеты раскупаются, мест становится все меньше. Поторопитесь с решением, чтобы попасть в офлайн-формат. На сайте конференции вы можете познакомиться с программой и спикерами.

А купив билет, вы можете получить в подарок мастер-класс Максима Дорофеева Как все успевать? На МК количество мест тоже ограничено мы должны соблюдать противоэпидемиологические меры и создавать дистанцию в залах. Поэтому гарантия участие в мастер-классе только предварительная запись.

До встречи на конференции TeamLead Conf 2021!

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

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

Эмоциональный интеллект: введение

Эмпатия это одна из составляющих эмоционального интеллекта (EQ). Поэтому я предлагаю начать разговор с него.

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

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

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

Американский социальный психолог Питер Саловей рассматривает пять главных областей эмоционального интеллекта:

1. Знание своих эмоций. Мы понимаем, что чувствуем.

2. Управление эмоциями. Мы понимаем, что чувствуем, и умеем справляться с этим.

3. Мотивация для самого себя. Мы понимаем, что нужно чувствовать, чтобы достичь поставленной цели.

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

5. Поддержание взаимоотношений. Мы понимаем свои и чужие эмоции и можем контролировать их при коммуникации.

Теперь, когда у вас есть общее понимание контекста, можно приступить к разговору об эмпатии.

Что такое эмпатия и почему она нужна разработчику?

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

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

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

Эмпатию часто практикуют в UI/UX дизайне, чтобы представить возможные пользовательские действия и реакции. В таком же ключе можно использовать эмпатию и в написании кода, но поможет она и в личном общении. Вот короткий список моментов, когда, по моему мнению, развитая эмпатия будет полезна разработчику:

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

• процесс написания кода нужно помнить, что мы пишем код для людей, а не для машин, и с вашим кодом будут потом работать другие люди;

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

• общение с коллегами тут, думаю, всё понятно и без объяснений.

Как начать работать над прокачкой эмпатии?

Так как я не психолог и не коуч, то рецептов на все случаи жизни у меня нет. Но есть и советы, которые я успел вычитать в источниках:

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

• Разберитесь со своими эмоциями. Даже испытывать гнев это нормально, важно это осознавать и быть в состоянии объяснить другим, почему вы его чувствуете. Есть уйма приложений, где вы можете фиксировать изменение своего настроения и описывать его причину.

• Будьте честными с собой и другими, постарайтесь понять, что повышает вам настроение. Не упражняйтесь в пассивной агрессии, а скажите всё как есть. Очень круто, когда вы понимаете, что должны чувствовать для того, чтобы справиться со своими страхами / нелюбимыми задачами или же войти во всеми любимый поток, где забываешь обо всём и погружаешься в решение задачи.

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

• Старайтесь понять эмоцию вашего собеседника и соответственно реагировать. Это непросто, но, если вы начнёте лучше понимать свои эмоции, вам откроется и эмоциональный мир людей вокруг.

С тех пор как я стал больше внимания уделять развитию эмоционального интеллекта, в моей жизни произошли такие изменения:

• мне стало проще понимать решения или желания других людей, как в команде, так и в семье;

• я понял, из-за чего избегал определённых разговоров и ситуаций, какие эмоции они вызывали и как влияли на мою самооценку. Я смог понять, что же давит на мою уверенность в решениях, и исправить это;

• упростилось прогнозирование действий или решений других людей;

• я легче нахожу мелкие радости, которые могут сделать мой день ярче и продуктивнее;

• мне стало проще и приятнее договариваться с людьми.

Какие изменения развитие эмоционального интеллекта и эмпатии принесёт в вашу личную и профессиональную жизнь не берусь судить. Но советую как минимум поинтересоваться этой темой.

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

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

С другой стороны, совсем без инструментов, документации и дедлайнов справиться с проектом не получится. Это Дмитрий Ильенков из Project Management Club и автор канала @pmclub на конференции TeamLead Conf 2020 наглядно показал в своем выступлении. И там же познакомил нас с p3express с простым фреймворком для проектов любого размера. Этот минималистичный, но системный фреймворк для управления проектами предлагает 37 понятных шагов от идеи проекта до работы с выгодами по его завершению.

Большинство проектов, с которыми мы встречаемся практически каждый день, начинаются очень невинно с небольшой задачки, может быть, даже с просьбы:

Ты был на TeamLead Conf? Поделись, пожалуйста, с командой инсайтами!

Можешь помочь обновить сайт?

И мы помогаем, нам несложно. Но через какое-то время у просьбы почему-то появляется дедлайн. А чуть позже оказывается, что поделиться инсайтами означает провести двухдневный тренинг, а сайт уже не нужно обновлять но нужен новый сайт!

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

Но несмотря на это, мы можем снова и снова браться за небольшие с виду проекты-просьбы, пока в какой-то момент не остановимся и не подумаем: Блин, я же через это проходил, меня же уже просили что-то немножко сделать, это же был проект! Возможно, сейчас это тоже проект и я буду управлять им как проектом? Но почему так получается? Почему мы этого не делаем, хотя знаем, что раз за разом подписываемся под проекты? Почему мы игнорируем проектное управление вместо того, чтобы избежать всех проблем с дедлайнами и ресурсами, спланировав и оценив наши действия?

Этому есть несколько причин.

Проекты проходят мимо радаров

Многие проекты просто пролетают незамеченными. Кажется, что они недостаточно большие т.е. бюджет у них недостаточно большой. Либо проектный офис их не замечает, потому что их нет в каком-нибудь списке приоритетных проектов, а то, что они оттягивают ресурсы с приоритетных проектов это неважно.

Много букв

Другая проблема давайте честно, управление проектами действительно ассоциируется со страшными вещами. Многие ставят знак равенства между управлением проектом и PMBOK. Редко кто PMBOK читал полностью от первой до последней страницы, и если это случилось, то скорее всего, это был PMP.

Я очень люблю PMBOK, и я PMP. Я был президентом Московского Chapter PMI. Но шестой PMBOK это 700 страниц, это реально много. Во-первых, ты их и сам не прочитаешь, а во-вторых, ты не заставишь, а тем более не убедишь прочитать их команду. А в-третьих, кто хочет для небольшого проекта использовать 700 страниц проектной методологии? Есть желающие? Обычно не находятся.

Нам уже было больно

Третья проблема: к вам в компанию приходили консультанты по управлению проектами? Я за последние полгода два раза столкнулся с абсолютно одинаковой историей в двух разных компаниях. К ним приходили консультанты, писали методологию и десятка полтора шаблонов.Люди пробовали заполнить эти 15 шаблонов, но даже 15 шаблонов это очень много. Им было больно, у них не получилось, им не понравилось. Они теперь ходят и рассказывают: проектное управление не работает! Хотят ли они попробовать еще раз? Спасибо, нет.

Возникает вопрос:

Что делать?

Что делать, чтобы управлять проектами как проектами, чтобы использовать лучшие практики и понятную канву, которую придумали до тебя, которая будет работать на тебя и которая будет работать еще дальше, когда ты ее адаптируешь?

Решением будет использовать более простые решения. Тот же самый PMI, правообладатель того самого PMBoK, у которого в шестой версии 700 страниц, в стратегии 2.0 прямо написал: Пришло время легковесных фреймворков. Седьмой PMBoK (я сейчас пишу к нему комментарии), который, надеюсь, выйдет в этом году, в части стандарта занимает только 37 страниц чувствуете разницу? Проще нужно, проще!

И я хочу рассказать как раз о простом, но при этом системной фреймворке, который придумали мои партнеры Надер Кей Рад (Nader K Rad) и Фрэнк Тёрли (Frank Turley). Надер как раз в числе авторов этого короткого классного PMBoK.

p3express

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

В чем его фишка?

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

В управлении проектами этого категорически не хватало до сих пор. Даже мой любимый PMBoK или очень красивый британский PRINCE2 никогда ни в одном месте не отвечают тебе на простой вопрос: что нужно делать завтра? Они пишут, что лучше делать так, есть принципы и процесс, следуй процессу, но завтра мне что сделать?

p3express это пошаговый алгоритм:

• Последовательно проходим 37 шагов, начиная от подготовки;

• Заходим в циклы, в которых работаем

• Выходим на закрытие проекта

• И дальше к пост-проектным активностям, когда извлекаем выгоды:

Шаг это не то же самое, что весь процесс, это не страшно и не долго. Шаг это может быть конкретное действие или рекомендация, или чек-лист, который нужно пройти. При этом выполнение шага не навязывается, потому что разные и проекты, и компании, и команды внутри компаний:

Контекст имеет значение, поэтому наполнение вы адаптируете сами. За счет этого p3express становится одновременно:

• Тиражируемым есть понятная система, ты берешь и переносишь ее;

• Адаптируемым за счет универсальности он подходит к проектам любого размера: от совсем небольших до более крупных.

Пройдем по шагам от начала до конца и посмотрим, 37 шагов это много или мало? Спойлер: немного.

Подготовка проекта

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

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

А01. Определить спонсора

Подготовка начинается с того, что мы определяем, кому этот проект вообще нужен. В проектном менеджменте есть спонсор (куратор) проекта это человек, который заинтересован в результатах проекта и готов на него выделять ресурсы, не обязательно деньги. Это могут быть еще компетенции, экспертизы, какие-то связи. Это может быть кто-то из топов вашей компании или product owner. Главное, чтобы этому человеку нужны были результаты проекта и он был готов в него вкладываться не каждый день работать в проекте, но вкладываться и поддерживать его.

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

От чего это возникает? Есть разные варианты. Например, проект изначально был действительно никому не нужен, поэтому он умирает.

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

Третьей причиной (из-за которой лично мне больно) бывает то, что приходишь в компанию и спрашиваешь, есть ли у ваших проектов спонсор? Они отвечают: Да! У всех наших проектов есть спонсор. Это генеральный директор. У меня была своя история, когда я на эту ловушку попался. Я презентовал проект руководству компании, проект одобрили и даже дали подразделение в придачу. Я подумал все круто! А через какое-то время мне влетело еще несколько проектов, на меня повесили кучу рутины, а замруководителя, который меня курировал, сказал: Оставьте себе этот проект как хобби. Я посмотрел, как проект чахнет и ушел.

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

А02. Составить резюме

Здесь мы отвечаем на очень простые вопросы:

• Что мы хотим получить в результате проекта?

• Зачем это нам нужно?

• Сколько у нас есть на это времени и денег?

• Что может пойти не так? Другими словами какие риски могут возникнуть.

Ответы на эти вопросы мы упаковываем в простой одностраничный документ это и называется резюме проекта. И эти ответы дают нам понятную пользу: задают вектор проекта и его границы.

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

А03. Определить лидера проекта

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

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

А04. Развернуть рабочее пространство

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

А05. Определить команду

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

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

Возможно, вы встретите кого-то на TeamLead Conf, кто сможет вам помочь. Люди достаточно охотно делятся экспертизой нам нравится чувствовать себя востребованными и полезными. Не пренебрегайте этой ролью, находите людей, которые помогут вам не повторять их ошибки, не наступать на их грабли. Не обязательно на full-time и за деньги, но привлекайте такую экспертизу в команду, чтобы сделать проект сильнее.

А06. Планирование проекта

Здесь мы декомпозируем проект, неважно, в каком формате иерархическая структура, бэклог, PBS из PRINCE2 любым способом, но это нужно сделать. Это позволяет нам потом приоритизировать продукты, которые получаем в рамках создания итогового продукта, повышать управляемость проекта и качество наших оценок.

Здесь же мы продолжаем работать с рисками. Не забывайте про выявление рисков (они вам обязательно встретятся) и про план, как мы будем реагировать на них.

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

А07. Определить внешних исполнителей

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

А08. Провести аудит подготовки

Еще одна особенность p3express это поддержка здоровья проекта. Мы любим что-то контролировать, или по крайней мере стараемся поддерживать проект в русле смотреть, чтобы он сильно не отклонялся от сроков и бюджета. Но почему эти отклонения происходят? У всего есть какая-то причина. Если мы действительно хотим поддерживать наш проект в русле, нам нужно искать проблему до того, как она становится уже пост-мортемом типа: да, мы не успеваем.

И первое в здоровом проекте это чек-лист Аудит подготовки. Перед тем, как принять окончательное решение запускаем проект! ответьте на несколько простых вопросов:

• У нас есть резюме проекта?

• Оно доступно команде?

• Мы развернули рабочее пространство?

• У членов команды есть доступ?

Шаблоны вопросов предлагает p3express, но вам нужно их адаптировать под себя, чтобы они принесли реальную пользу.

А09. Да/нет

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

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

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

А10. Провести kick-off

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

А11. Фокусированная коммуникация

Коммуникация на этом шаге нужна для того, чтобы ваш проект не был партизанским. Если вы делаете проект, а никто не понимает, что вы делаете, то в итоге вы можете обнаружить, придя к финансистам насчет платежа, что они вообще не в курсе вашего проекта и никакие деньги на него не закладывали.

Не надо партизанить, коммуницируйте о проекте с теми, к кому он может относиться.

Циклы

Закончив с подготовкой проекта, переходим в циклы, где мы делаем работу. По сути, циклы это аналог того же спринта в Scrum. Каждый цикл начинается с планирования.

Планирование цикла

А12. Обновить планы

Мы провели небольшой опрос в Telegram: из 180 тимлидов около 30% назвали главным своим челленджем в ушедшем году постоянную смену приоритетов.

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

А13. Определить внешних исполнителей

Используйте обновление планов и для того, чтобы в целом переоценить отношение к проекту, к рискам, пересмотреть какие-то задачи и отношение к внешним исполнителям. Бывает непонятно, в какой момент отказываться от подрядчиков: сначала вроде слишком рано (они же потом, наверное, что-то пришлют), а потом может быть слишком поздно их менять. Этот шаг поможет держать ситуацию под контролем и не упустить момент, когда нужно сменить подрядчиков или привлечь новых на появившиеся задачи.

А14. Да/нет

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

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

Итак, если решение положительное, то переходим к следующим шагам.

А15. Провести kick-off цикла

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

А16. Фокусированная коммуникация

Коммуницируем наши планы на этот цикл и переходим дальше к работе. Расскажите о достигнутых результатах, возникших рисках. Попросите помощи, если она нужна.

Еженедельные действия

Еженедельные действия направлены на то, чтобы удерживать проект в русле.

А17. Оценить прогресс

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

Что нужно проверить?

1. Метка-статус vs комментарии. Проверьте, соответствует ли метка-статус комментариям к продукту. Противоречий быть не должно. Для наглядности и простоты вы можете, например, использовать цветовые метки: зелёная продукт готов, жёлтая продукт в работе, красная продукт не готов/проблема с продуктом.

2. Результаты vs контрольные точки. У вас могут быть контрольные точки как по всему проекту, так и по элементам конфигурации проекта. Проверьте, все ли точки пройдены вовремя? Вы не пропустите важный дедлайн?

3. Результаты vs бюджет. Сравните план по использованию бюджета с фактическими данными. Если перерасход, то по какой причине? Сделали больше запланированного или причина серьёзнее? Если бюджет не освоен откуда взялась экономия?

4. Сопоставьте прогресс с другими проектами. Вы работаете не в вакууме: какие-то отставания критичны, а какие-то нет, если в связанных проектах всё стоит.

5. Слушайте, что говорят. Слухи расходятся быстро, и в них может быть правда. В рабочем пространстве всё идеально, а коллеги сочувственно смотрят в вашу сторону? Что-то идёт не так.

А18. Работать с отклонениями

Работаем с найденными отклонениями (если требуется наше активное участие):

1. Убедитесь, что вы собрали полную и достоверную информацию;

2. Проранжируйте проблемы по важным для вас критериям например, срочность/критичность;

3. Выберите наиболее острые проблемы;

4. Соберите дополнительную информацию;

5. Решайте проблемы на своем уровне или выносите их на уровень спонсора;

6. Помните, ваша задача решить проблему, а не найти крайних.

А19. Еженедельная встреча

Не нужно их превращать в решение всех проблем (проблемы можно решать до). Здесь мы убеждаемся, что команда продолжает работать над проектом, а не над его отдельными частями. Это частая проблема, когда исполнители зарываются в конкретные задачи, и уже не создают общий продукт, а играют с какими-то технологиями в своей задаче, любуются ею. Это здорово, но нужно убедиться, что все работают по-прежнему над одним проектом.

А20. Еженедельный аудит

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

А21. Фокусированная коммуникация

Пройдя аудит, мы снова направляем фокусированную коммуникацию, потому что то, что мы проговорили на встрече это здорово, но отправить follow-up еще лучшая практика. Иначе все забывается и путается.

Теоретически эти действия должны занять пару часов. На практике мне довелось выступать в роли спонсора проекта, где нашим подрядчиком была одна небольшая американская студия. Они делали нам сайт. Раз в неделю мы созванивались. Они шарили экран с доской проекта. Мы проходили все задачки:

Сделано? Сделано. ОК.

Не сделано? Смотрим почему. Но ни о чем не спорим, ничего глубоко не обсуждаем, просто тэгаем того человека, который может решить эту проблему и внести вклад в обсуждение.

Такие звонки у нас длились полчаса максимум, и 15 минут из этого времени уходили на Как дела? Мы так рады с вами работать! все эти американские любезности. То есть мы успевали всё обсудить за 15 минут. После созвона лидер проекта направлял коммуникацию команде, что происходит в части работы с этим подрядчиком.

Это действительно идеальная история, и каждая может быть такой. Почему так обычно не получается? Да потому что проблема возникает на этапе получения информации. Информация о проекте, которой мы располагаем, часто бывает не релевантной. Вопрос как мы ее измеряем, как ее визуализируем, что используем (метод освоенного объема, диаграмма сгорания, еще что-то) это вторичный вопрос. Важнее вопрос: насколько мы и команда делаем работу над проектом прозрачной, насколько у нас постоянно есть доступ к этой информации? Все любят пользоваться таск-трекером на словах. На деле разные ситуации бывают.

Почему мы плохо пользуемся такими инструментами?

1. Один вариант команда не понимает, как ими пользоваться технически. По дефолту нельзя рассчитывать, что все всё понимают, все прочитали инструкцию. Нет, людям нужно помочь и немножко их обучить.

2. Второй вариант люди не очень понимают, зачем это надо. Тоже можно объяснить.

3. Третья ситуация смешнее и страшнее. Я ее наблюдал сам.

Вице-президент компании решил всех перевести на Trello. Сначала он говорил про прозрачность, потом про контроль, но начал очень бодро! Он выбрал команду, которая действительно эффективно работала и эффективно пользовалась Trello не просто досочкой в три столбца, у них все было классно. Он попросил лидера этой команды всем показать, как работать в Trello. Лидер команды действительно показал, провел даже не митап, а небольшое обучение. Он пошел на шаг дальше и объяснил, зачем это нужно, как хорошо управлять проектами, он вообще молодец!

Но вице-президент на эту встречу не пришел это был первый звоночек. Второй звоночек был, когда его помощник нам сам создал доски и направил туда приглашения. Через пару недель вице-президент спрашивает: А что вы не ведете ваши доски?, но сам при этом так и не зарегистрировался в Trello.

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

Ежедневные действия

Это даже не шаги, а рекомендации к ежедневным действиям. Каждый день мы сталкиваемся с какими-то новыми задачами, проблемами и рисками. RICs это риски, проблемы, запросы на изменения. Тот же наш опрос тимлидов показал, что одна из проблем это постоянно прилетающие новые задачи. И это неизбежно.

Что можно делать?

А22. Зафиксировать RICs

Если вы что-то запомнили это не фиксация, потому что, во-первых, вы забудете это, во-вторых это вас перегружает, а в-третьих у каждого своя память. Если в проекте больше одного человека, то запоминание одним не считается. Фиксируем RICs, и для этого тоже есть шаблон.

А23. Реагировать на RICs

Мы на них обязательно реагируем. Если не можем справиться с проблемой сами, не стесняемся ее эскалировать, потому что лучше эскалировать проблему, а не провал и/или катастрофу.

А24. Принять готовые продукты

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

Вы согласны, что мультизадачность это проблема? А вы считаете себя достаточно эффективным в мультизадачности? Мы часто переоцениваем свою эффективность в этом режиме исследование Дэвида Мейера показывает, что даже минутное переключение до 40% снижает наше продуктивное время.

А почему возникает мультизадачность? Это происходит не только потому, что нам постоянно прилетают новые задачи, но и потому что мы не закрываем старые.

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

Принимайте результаты работы как можно чаще!

Закрытие цикла

Каждый цикл мы открываем и закрываем.

Закрытие цикла состоит из трех шагов:

А25. Оценить удовлетворённость заказчика и команды

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

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

Приведу пример. История случилась со мной буквально неделю назад. Приходит письмо с адреса одного из наших партнеров: Объясните, как мы можем вернуть денежные средства ни здравствуйте, ни пожалуйста, ни подписи. Думаю нормально же общались, что случилось, почему деньги вернуть? Оказывается, сотрудница бухгалтерии отправила письмо по ошибке.

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

А26. Запланировать улучшения

Прогресс сам по себе не придет. Нужно понять, где можно работать лучше, что для этого нужно сделать.

А27. Фокусированная коммуникация

На этом шаге можно получить commitments по улучшениям от команды, коммуницировать эти решения и в следующем цикле уже работать над ними.

Закрытие проекта

А28. Передать продукт

Вы уверены, что передавая продукт, вы его передаете правильным людям? Со мной случилась (к счастью, это было давно) очень забавная история. Компания, где я работал, решила внедрить довольно дорогую систему бизнес-аналитики. Купили 5 лицензий.

Результат:

• Сколько из них пошли пользователям? Всего одна, две отдали айтишникам, две топам.

• Сколько человек обучили пользоваться этой системой? Одного из айтишников (самого хитрого). Он стал носителем сверх-знаний и не потерялся через полгода стал начальником отдела по работе с этой системой.

Система, кстати, все равно не взлетела, потому что это криво: я пользователь, а у меня нет ни лицензии, ни навыков работы.

Поэтому убедитесь, что вы передаете продукт тем людям, которые будут с ним работать, что они умеют с ним работать, понимают как, а также, что у них есть нормальный путь эскалации каких-то проблем. Саппорта бывает недостаточно. Доводить до работы с условиями договора не стоит, но убедитесь, что люди понимают, что делать, когда что-то идет не так.

А29. Передать проект

Проект нужно передавать так же, как и продукт. Проект может быть закончен для лидера проекта и для команды, если это временная команда. Но компания просто выбросила деньги, чтобы вы собрались, что-то сделали и ушли? Тогда проще было заказать. А что с извлеченными уроками? Что с поддержкой продукта, который вы создали? Что с тем же самым заказчиком кто будет продолжать контакт?

Здесь самое время выйти на первый план спонсору проекта, который был активен в начале проекта на этапе подготовки и где-то незримо был рядом с нами в процессе проект нужно передать тому, кто (в отличие от лидера проекта) с ним останется дальше.

И в идеале именно этот человек проходит следующие шаги.

А30. Оценить удовлетворённость заказчика и команды

Последний раз оценивается удовлетворенность заказчика и команды.

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

А31. Провести аудит проекта

В целом оценивается эффективность управления проектом.

А32. Извлечь уроки

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

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

А33. Отметить окончание проекта

Можно сколько угодно говорить про выгорание, но если человек приходил на работу, делал-делал проект, не спал ночами и, завершив проект, пошел домой, поспал, вернулся и у него новый проект это похоже на день сурка, причем паршивый день сурка. Не надо этого допускать. Умейте радоваться жизни Work Hard & Play Hard, отмечайте с командой все достижения, а окончание проектов тем более.

А34. Фокусированная коммуникация

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

После проекта

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

А35. Оценить полученные выгоды

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

Мы об этом часто забываем. В презентациях часто красиво написано: Внедрение CRM сократит ваши расходы на отдел продаж на 100%! Мы сократим расходы на ФОТ!. Подождите, сокращение расходов на ФОТ это значит, кого-то уволили. Это называется disbenefits то, что для кого-то хорошо, для кого-то плохо.

А36. Спланировать дополнительные действия

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

А37. Фокусированная коммуникация

Коммуницируйте эту информацию. Можете ли вы честно сказать, что в курсе, какую пользу принесли ваши проекты за последние два года не теоретически? Ситуация, когда люди работают-работают, но не могут точно сказать, не работают ли они в стол это еще одна упущенная возможность:

• По мотивации;

• По улучшению проекта. Люди должны понимать, что от них ожидают;

• По борьбе с бесполезными проектами.

Есть статистика от The Standish Group, сколько процентов фич никогда не используется. Такой статистики по проектам я не нашел, но к нам часто приходят с бесполезными проектами, которые мы тем не менее делаем. Но без коммуникации и измерений мы не можем потом сказать: Нам кажется, что ты нам только бесполезные проекты приносишь.

Измеряйте выгоды, коммуницируйте!

Выводы

Мы прошли все 37 шагов это оказалось не так много. И они все уместились на доске в нескольких колонках:

Я действительно люблю p3express. Мне нравится, что им просто пользоваться, что я могу пользоваться им не один, а управлять проектом вместе с командой, потому что объяснить, как это делать в p3express достаточно просто.

Пробуйте p3express на небольших проектах в вашей компании, пробуйте на своих pet-project, пробуйте масштабировать, раскатывать и помогать другим.

Simplicity is the ultimate sophistication!

Московская конференция TeamLead в этом году пройдет 29 и 30 апреля в Radisson Slavyanskaya. На конференции будет огромное количество информации, общения, обсуждений для тимлидов команд любых размеров и направлений. Не только для IT-сферы, не только для больших корпорация или маленьких старпапов. О том, как строить (и перестраивать) культуру в компании, как развиваться самому и помогать в этом команде, как решать конфликты для всех с профитом, про бизнес-процессы, коммуникацию, карьеру и многое другое вы получите максимальную концентрацию тимлидского опыта на чел/час и кв.м.

Расписание конференции уже готово.Билеты уже в продаже. Можно участвовать как онлайн, так и по старинке, общаясь вживую. Присоединяйтесь!

Но если вы хотите еще и выступить, на питерскую конференцию Saint TeamLead Conf 2021 еще открыт прием докладов. Мы помогаем спикерам во всех вопросах выступления, в том числе учим выступать и как подготовить презентацию. А в Программном комитете ваши заявки просматривают и отбирают опытные спикеры, неоднократно выступавшие на разные темы и эксперты в своих направлениях. Выходите на свет рампы вместе с нами!

В связи со скорым стартом онлайн-курса "Team Lead" приглашаем всех желающих записаться на открытый демо-урок Первые шаги тимлида на новом месте. На вебинаре участники вместе с экспертом обсудят:
С чего начать работу новоиспеченному лиду?
На какие процессы стоит обращать внимание?
В каких местах кроются quick wins для быстрого роста?

А сейчас предлагаем к прочтению традиционный перевод интересного материала.

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

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

Одна из причин этого наше стремление найти всему простое объяснение. Как общество, мы превозносим простоту. Мы требуем ее от нашего правительства, коллег, друзей и даже семьи.

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

С другой стороны, простое объяснение, такое как утверждение, что коронавирус был изготовлен в лаборатории, также обеспечивает когнитивный якорь. Если что-то так легко понять, как это может быть неправдой? Особенно, когда альтернатива требует оценки сложных взаимодействий между биологическим, психологическим, социальным и неизвестным.

Сопротивление таким простым объяснениям сложной проблемы требует от нас гораздо большего. Это заставляет нас остановиться, взглянуть шире на ситуацию, прикинуть уровень сложности и осознать пределы нашего понимания это пугает. Принятие чего-то сложного это акт смирения в признании неизвестного.

Всё должно быть сделано просто насколько возможно, но ничуть не проще. Это высказывание Эйнштейна неправильно цитируют, упуская из вида последнюю часть, но ничуть не проще, или как он сказал самом деле: адекватное представление базовой единицы опыта (the adequate representation of a single datum of experience). Я думаю, что Эйнштейн пытается сказать, что цель не простота, а понимание.

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

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

Хомский (Chomsky) и Герман (Herman), вероятно, наиболее известны тем, что описали, как подобные методы работают в пропаганде. Они утверждают, что, ограничивая параметры дискуссии, мы фактически вырабатываем одобрение общественности. Что, на мой взгляд, работает как для общества, так и для организаций.

Например, можно упростить сложный набор идей в крылатую фразу, с которой трудно не согласиться, например Сделаем Америку снова великой (Make America great again), Надежда (Hope), Перемены (Change), Мир (Peace) и т. д. Это заставляет нас ощущать глубину дискуссии где-то на уровне детского бассейна; когда на самом деле ее глубина подобна океану. Поддерживаете ли вы наши войска? это не тот же вопрос что Поддерживаете ли вы политику, связанную с войной, в которой они сражаются?. Хомский говорит, что вы должны НАЧАТЬ, сказав: Ну, я НЕ не поддерживаю войска, но к тому времени вы уже проиграли.

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

Простота идеальное средство радикализации монистической мысли.

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

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

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

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

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

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

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

Если вам интересно узнать больше о сложности, о том, как ее разбить на части и как с ней работать, я думаю, вам будут интересны следующие ресурсы:

Cynefin framework отправная точка для работы со сложностью

A Leader's Framework для принятия решений

Можете ли вы упростить сложность?

На Media ч. 1 - Согласие на производство (подкаст)

Узнать подробнее о курсе "Team Lead".

Смотреть вебинар Первые шаги тимлида на новом месте.

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

Всё это я проговаривал на вебинаре в Хекслете тут https://www.youtube.com/watch?v=y_HkXvFovAc

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

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

Шаг номер 0. Зачем?

Итак, вам предложили стать тимлидом или вы сами захотели им стать. Что надо сделать в первую очередь?Хорошенько подумать, а надо ли оно вам.

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

Я общался с многими состоявшимися специалистами в этой профессии и все они говорят примерно одно и то же:

• Кто-то туда идет, потому что ему нравится работать с людьми, помогать им, развивать их. Тут безусловно найдется поле для деятельности. Море работы с людьми, развитие команды, помощь соседним отделам и т.д.

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

Ложные цели, на которые не надо вестись:

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

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

• Повышение уровня ЧСВ. Ничего особо крутого в этой должности нет. Это просто очередная должность чуть выше рядовой. Как ефрейтор или сержант в армии. Вроде лычка есть, но хвалиться особо нечем, и вокруг куча таких же.

Второе, на что надо обратить внимание при рассмотрении данной должности: тимлиды бывают разные.

Каждая компания вкладывает в эту позицию свой уникальный смысл. Где-то нуженполуменеджер-полуразработчик, где-то техлид/архитектор, где-то пипл менеджер и т.д.

Советую заранее узнать, что же именно от вас требуется.

Спойлер: 80-90% вакансий на российском рынке -полуменеджер-полуразработчик. Формально говорится, что 60-70% времени надо писать код, а 30-40% менеджерить. При небольших размерах команды и порядочном работодателе это может неплохо работать. Лично у меня где-то сейчас 40 на 60 получается делить код с менеджементом. Хотя я чувствую, как при разрастании команды код отодвигается от меня всё дальше и дальше.

Однако при недобросовестном или просто непонимающем работодателе, от вас будут ожидать примерно 100% менеджмента и 100% написания кода. Постарайтесь узнать об этом как можно раньше, чтобы СБЕЖАТЬ.

Шаг номер 1. Знание - сила!

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

Про тимлидство существуют сотни статей, видео, книг, курсов и т.д. Фильтровать нужно тщательно.

Прилагаю список того, что мог бы порекомендовать я из более-менее основательного. Статьи и какие-то выступления с конференций вы можете найти и отобрать самостоятельно.

• М. Уоткинс "Первые 90 дней".Хорошая и вдумчивая книга о том, как успешно адаптироваться к переходу на новую должность.Чем заняться в первые 90 дней.И о том, что эта адаптация, как системный процесс, нужна не просто конкретному индивиду, а всей компании в целом.

• Дж. Ханк Рейнвотер "Как пасти котов". Книга для начинающих или будущих управленцев вполне хороша и толкова (пусть и немного стара). Однако для людей с опытом, наверное, будет немного кэпской.

• Ф. Брукс "Мифический человеко-месяц".Расскажет об управлении проектами: как надо, как не надо, и почему 9 женщин за 1 месяц не смогут родить ребенка. Есть мнение, что книга несколько устарела, тем не менее, если вы в этом не очень разбираетесь, то она обогатит вас полезными идеями.

• Э. Голдратт. "Цель. Процесс непрерывного совершенствования".Классический художественный роман, объясняющий на разных примерах теорию ограничения систем. Чтиво интересное и полезное.

• Д. Ким, К. Бер, Д. Спаффорд."Проект "Феникс". Роман о том, как DevOps меняет бизнес к лучшему".Очень интересная и поучительная книга, которая в художественном формате рассказывает о том, как в ИТ подразделении улучшают процессы работы, приходят к DevOps идеологии и спасают бизнес.

• Т. ДеМарко "Deadline. Роман об управлении проектами". Еще одна книга в художественном формате. Легкое и интересное чтение об управлении ИТ проектами.

• Т. ДеМарко, Т. Листер "Вальсируя с Медведями".Порекомендовал бы эту книгу для средних и крупных проектов. Излечивает от наивности, открывает глаза на происходящее. Показывает, что случиться может много чего и рассказывает, как с этим жить и работать.

• М. Дорофеев "Джедайские техники. Как воспитать свою обезьяну, опустошить инбокс и сберечь мыслетопливо".Книга не про программирование, но программистам, тимлидам, менеджерам точно пойдёт на пользу. Очень толковая книга по личной эффективности, организации задач и т.п.Всем настойчиво рекомендую.

• М. Ильяхов, Л. Сарычева "Новые правила деловой переписки".Замечательная книга. Смело её рекомендовал бы и разработчикам, и менеджерам, и вообще примерно всем.О том как в переписке быть толковым, уважительным, приятным и эффективным. Очень многим этого не хватает.

• А. Орлов "Джедайские техники конструктивного общения". Коротко, по делу, с примерами.Однозначно рекомендую. И в работе пригодится, и в быту.

• М. Гоулстон "Как разговаривать с мудаками". Книга придаёт понимание того, что не все проблемные отношения и коммуникации можно разрешить рациональными доводами, и что делать в таких случаях. Ну и о себе можно задуматься тоже:)

• Роадмап тимлидаhttps://tlroadmap.io/Очень полезный инструмент, который поможет разобраться, какие бывают требования к тимлидам, понять, что с ними делать и как подтягивать свои знания. Также подойдет как хороший инструмент для того, чтобы обговорить со своим руководителем на начальном этапе работы, что же конкретно от вас ожидается.

• Курсерный курсhttps://www.coursera.org/specializations/product-managementДолгий и основательный курс, который покрывает всё про управление проектами. Выявление требований, план рисков, декомпозиция и распределение задач, аджайл техники и прочее. Вы справедливо можете заметить, что этот курс нужен менеджерам проектов, а не тимлидам. Теоритечески - да, а на практике возможно, что если у вас менеджер проекта и есть, то в каких-то деталях он может не очень разбираться. Тогда понадобится ваше участие.

• Регулярные двухнедельные тимлидские конференции от ребят из подкаста Podlodkahttps://podlodka.io/tlcrewТам много хороших докладов и душевное отзывчивое комьюнити, с которым можно порой пообсуждать в деталях то, за что обычно деньги берут на платных индивидуальных консультациях.

Шаг номер 2. Общий план первоначальных действий

От теории переносимся к практике.

Первым делом необходимо разобраться: кто руководитель, кто заказчики, кто кому подчиняется, а кто нет. Желательно всё записать, а еще лучше составить визуальную схему а-ля mindmap, глядя на которую будет видна общая картина всех отделов и действующих лиц.

Далее, когда вы поняли официальную часть, надо погрузиться в неофициальную.

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

Какие назначить первые встречи, чтобы во всё это погрузиться?

Первым делом встретьтесь 1 на 1 с руководителем и, используя роадмап тимлидаhttps://podlodka.io/tlcrew, обговорите конкретные ожидания от вашей позиции. Главное помнить, что в роадмапе указано не "всё, что должен знать и делать тимлид", а "всё, что могут требовать от тимлида в разных компаниях", т.е. это объединение подмножеств хотелок из разных компаний. Так что, когда вам начальник скажет: "Ну, вроде выглядит норм, давай-ка всем занимайся," - вашей задачей будет ему объяснить, что всем заниматься невозможно физически и нужно проанализировать конкретную ситуацию, проект, команду, выделить наиболее важные области, которые вы и возьмете на себя.

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

• взглянуть на текущую ситуацию с разных сторон;

• узнать какую-то историю, которая творилась еще до вас;

• проанализировать самих людей;

• понять ожидания этих людей от вас.

Шаг номер 3. Распространенные проблемы. Предупрежден - значит вооружен

Здесь я коротко рассмотрю типичные проблемы и как с ними бороться.

Проблема с внешними коммуникациями

• Авторитет и субординация в команде.

  Если вы становитесь тимлидом в старой команде, то вам повезло - это довольно легкий вариант. Раз вас поставили на эту позицию, значит, у вас уже есть какой-то авторитет и доверие к вашей работе. Остается развивать и поддерживать это. Лично я стараюсь работать даже простым разработчиком так, чтобы это было профессионально, качественно и без халтуры. Требую этого от себя и призываю к этому коллег. Так что, становясь тимлидом в такой команде, по сути ничего не меняю и всё это дальше нормально работает.

  Если вы приходите тимлидом в новую команду - это более серьезный вызов. Тут вам придется показать максимум своих профессиональных и политических качеств, чтобы заслужить авторитет и доверие.

• Отношения с руководством.

  Есть такая штука, как матрица доверие-прозрачность.

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

• Общение с заказчиками.

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

Проблема с самим собой

• Синдром самозванца.

  Часто кажется, что вы не потянете, вы не компетентны, вас вот-вот раскроют, вы самозванец. Но подумайте об этом в другом ключе. Тимлид - позиция важная. Она оказывает большое влияние на проект и на бизнес. А бизнес не дурак, он абы кому эту позицию предлагать не станет. Следовательно, раз предложили, то объективно в вас что-то такое подходящее разглядели. Ваша задача проговорить все сомнения и ожидания с руководителем, чтобы все вокруг точно понимали, в чем вы уверены, в чем сомневаетесь, в чем совсем не разбираетесь.

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

  Даже если вдруг окажется, что у вас не получается быть тимлидом, вы всегда можете (обговорите этот момент с руководством заранее) откатиться обратно, и в этом нет ничего плохого или стыдного. Хуже - совсем не попробовать, боясь неудачи, чем попробовать и зафейлиться. Даже негативный опыт будет очень ценным для вас, ведь только так вы сможете понять, точно ли вам надо работать на этой позиции. Сейчас мне сложно вспомнить, где именно и кем проводился опрос, но вроде статистика была такова, что около 30% тимлидов откатывается обратно в разработку. Так что искать себя, пробовать, заниматься тем, к чему душа лежит - это нормально.

• Меньше пишешь код, теряешь позиции на рынке среди технарей.

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

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

Проблема с объемом работы

• Неумение и страх делегировать.

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

  От таких проблем спасет делегирование и ситуационное лидерство. С делегированием всё понятно, всё менее важное, что можно делегировать - надо делегировать, дабы сосредоточиться на чем-то более важном, что можете сделать только вы на своей позиции. А ситуационное лидерство поможет вырастить самостоятельных специалистов, которым можно без боли в сердце делегировать разные задачи.

• Микроменеджмент ичайка менеджмент.

  Тоже большие проблемы не только начинающих, но и продолжающих. Если микроменеджмент растет из страха делегирования, то чайка менеджмент растет скорее из лени и безалаберности. Бороться нужно усердной работой над собой и самоанализом на тему "а не фигню ли я делаю, как менеджер?".

• Остается мало времени на повышение квалификации.

  Действительно, у тимлидов в среднем остается меньше времени, чем у рядовых разработчиков, чтобы что-то изучить, завести пет проект и т.д. Какой-то серебряной пули тут нет. Кто-то выделяет себе немного времени на работе, кто-то в дороге до/с работы, кто-то по вечерам. Главное, что я могу тут посоветовать - внимательно выбирать то, чему вы планируете учиться, и учиться правильно, без сумбура и иллюзий компетентности.

• А чему учиться-то, хардам, или софтам?

  Замечательный вопрос. Конечно, как начинающему тимлиду, я бы рекомендовал окунуться в бескрайний океан софт скиллов и менеджмента, потому что это именно то, чего у вас было мало, как у разработчика, и то, чего от вас ждёт работодатель.

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

Проблемы со здоровьем ментальным и физическим

• Гигиена труда и образ жизни.

  Чтобы вы не заболевали, не выгорали, не чувствовали, что жизнь проходит мимо, я хочу дать несколько советов:

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

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

  - Помните, что за пределами монитора и работы тоже существует жизнь. Иначе можно в какой-то момент понять, что в последние N лет кроме дедлайнов, тасок в жире, проектов и заказчиков вы ничего и не видели, хотя мечтали (возможно) о чем-то другом.

• Важность рефлексии, что в работе, что в быту.

  Очень важно думать о том, что и как вы делаете, что в рабочих моментах, что в бытовых. И неплохо бы делать это не стихийно, а систематически. Порой нас так затягивает рабочая и бытовая рутина, что мы барахтаемся в этом болоте, даже не замечая его. А регулярность подходов к рефлексии заставят систематически вытаскивать голову из болота, глядеть по сторонам, понимать, что мы делаем, зачем и как, а также насколько мы этим всем удовлетворены.

Шаг номер 4. Полезные качества для тимлида

Полезные качества, которые надо в себе взращивать:

• Умение не сойти с ума при многозадачности.

  Обычно у тимлидов очень много разных задач по всем фронтам. Например, утром нужно встретиться с заказчиком, в обед обсудить задачу с командой, на полдник написать 100500 писем, на ужин пообщаться с глазу на глаз с начальником, а еще хотелось бы кой-чего и самому подкоммитить. И это еще легкий день. Заказчиков обычно много, так же как и задач, встреч и всего остального. Так что умение сохранить разум в режиме многозадачности - важное умение.

  Тут поможет умение выделять приоритетные задачи, а менее приоритетные делегировать и правильно контролировать.

  Умение разговаривать на языке собеседника.

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

  Умение говорить "нет".

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

  Дисциплина.

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

• Эмпатия.

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

Шаг номер 5. Что делать дальше?

• Продолжайте учиться.

  Самообразование в этой сфере не заканчивается никогда. Индустрия быстро бежит вперед, так что нужно не просто учиться, а делать это регулярно и довольно интенсивно.

  Лично я тут не вижу каких-то легких путей или срезания углов. Да, можно с умом выбирать, чему именно сейчас необходимо учиться, в каком темпе это надо делать, но факт остается фактом - придется уделять этому много времени и сил.

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

• Продолжайте (или начинайте) общаться с разными людьми в индустрии.

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

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

• Всегда критически мыслите.

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

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

Дополнительные материалы

Какие-то темы я не стал подробно раскрывать, потому что и текст получился бы слишком длинным, да и я уже писал об этом ранее в своем телеграм-канале. А копипастить, или повторяться не хочется.

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

• Матрица доверие-прозрачность https://t.me/general_it_talks/78

• Ситуационное лидерство https://t.me/general_it_talks/59

• Чайка-менеджмент, микроменеджмент https://t.me/general_it_talks/28

• Обучение, приоритеты и иллюзию компетентности в этом деле https://t.me/general_it_talks/60 https://t.me/general_it_talks/41 https://t.me/general_it_talks/116

• Овертаймы и подбор темпа работы https://t.me/general_it_talks/42 https://t.me/general_it_talks/61

• Теория разбитых окон https://t.me/general_it_talks/48

Успехов!

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

3июня, 15:00 МСК, онлайн.
Регистрация https://miro-event.timepad.ru/event/1650491/

Эксперты

• Максим Гребенщиков, Miro;

• Евгений Кот,Wrike;

• Алексей Шаграев, Google;

• Давид Роганов, Яндекс.Практикум.

Задать вопросы экспертам и обсудить тему можно втелеграм-чате, добавляйтесь.

Тема

В рамках серии митапов "Инженер заходит в бар" продолжаем исследовать траектории профессионального развития разработчиков. На этот раз поговорим про переход из инженера в руководителя команды.

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

Ты соглашаешься и начинается: проводишь больше времени на митингах, чем за написанием кода; нужно делатьperformance review, 1-to-1 и прочую психологию с социологией; мысленно примеряешь на себя стереотип "Был хороший разработчик, стал плохой руководитель".

На митапе поговорим с ребятами, кто был в такой ситуации и как-то справился.

Обсудим:

• момент перехода что было самое сложное и что помогло преодолеть;

• отложенные сложности какие были проблемы по мере накопления тимлидского опыта;

• следующие шаги после тимлидства кто куда пошёл дальше, почему именно туда.

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

Серия "Инженер заходит в бар"

Мы делаем митапы для тех, кто умеет программировать и столкнулся с осознанием, что IT не только про программирование. Кроме кода есть люди, с которыми нужно договариваться. Есть сверхскоростные темпы изменения технологий и рынка. Нужно постоянно учиться новому. Есть желание делать нужное. "Инженер заходит в бар" митапы для тех, кто задумывается о процессах в IT, независимо от своей роли.

Мы собираем вместе инженеров поговорить на профессиональные не инженерные темы: как расти внутри компании, токсичность, синдром самозванца, коммуникации инженеров с бизнесом и другие.

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

Все выпуски серии.

Организаторы

Мы инженеры изMiroи DevRel-бюро Долгушев и Сторожилов. Мы много общаемся с разными IT-компаниями и видим, насколько по-разному все отвечают на схожие вопросы. Нам интересно разобраться, увидеть систему (или её отсутствие) и обсудить всё это с другими инженерами. Ну и просто поговорить с интересными людьми об их опыте.

Регистрация https://miro-event.timepad.ru/event/1650491/

Термин бережливого производства (Lean) в настоящее время на слуху. Мы все знаем результаты применения данной идеи в компании Toyota, которые позволили выпускать малые партии комплектующих точно в срок (Just-In-Time, JIT).

В книге Microsoft Secrets (1995 года) авторы (Кузумано и Ричард Селби) описали подходы контроля качества схожие с Lean применяемым в Toyota.

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

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

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

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

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

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

Отправная точка

Изначально в команде применялась несколько упрощенная методология Scrum. Ниже приведу ее описание.

Набор артефактов:

1. Project backlog журнал требований, реализуемых в рамках проекта, обнаруженные в процессе эксплуатации инциденты. Обычно требования оформляются в виде User Story. В качестве инструмента для верхнеуровневого планирования использовали Excel. Там же, для удобства, чтобы все было в одном месте, на отдельной странице сделали диаграмму Ганта и диаграмму сгорания.

2. Sprint backlog журнал требований и инцидентов реализуемых за спринт.

3. Scrum-доска. В качестве инструмента использовали доску Trello с расширением Plus For Trello для контроля трудоемкости.

Роли в команде:

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

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

3. Команда разработчиков состоит из опытных разработчиков и новичков, которые повышают свои компетенции в процессе участия на проекте.

4. Команда консультантов сотрудники погруженные в бизнес-процессы заказчика. Занимаются подготовкой требований, взаимодействием по требованиям и бизнес-процессам с конечными пользователями, консультируют конечных пользователей, тестируют разработанную функциональность.

Совещания:

1. Ежедневный митинг команды.

2. Ретроспектива в конце спринта.

3. Ежеквартальные ретроспективы.

Параметры спринта:

1. Продолжительность: 1 месяц.

2. Ежедневные обновления продуктивной системы по итогам завершения работ по блокам задач.

Данный подход использовался на большинстве проектов, динамика при использовании была положительная.

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

Хьюстон, у нас проблемы

Явные проблемы заметили на втором месяце этапа ОПЭ (опытно-промышленной эксплуатации), когда новые требования по дефектам начали закрывать время затраченное на запланированные дефекты и пожелания. Фактически мы стояли на месте. Вероятность успеха сделать все вовремя стремилась к 0.

Для исправления ситуации было решено провести экстренную ретроспективу и собрать все существующие проблемы.

Удалось выявить следующие точки улучшения:

1. Сильный перегруз разработчиков. Стабильное превышение 8-часового рабочего дня, выход на работу в выходные. Снижена мотивация, нарастает напряжение в команде.

2. Недостаточное качество итогового кода, требуется повысить контроль качества.

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

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

5. Много времени уходит на разработку и доработку, консультанты простаивают.

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

А что думает заказчик? Заказчик недоволен динамикой реализации требований. Но готов рассмотреть вариант с четким и прогнозируемым планом.

Именно в этот момент появилась идея использовать подход JIT для улучшения текущей ситуации.

Какие преимущества Agile-Lean мы попробуем использовать в нашем проекте

Основываясь на описании бережливого производства, можно выделить не только сильные, но и слабые стороны для бережливой разработки.

Сильные стороны:

1. Получение результата в ограниченное время.

2. Устранение ненужных действий, которые могут снизить стоимость.

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

4. Гибкость проекта, возможность его корректировки под требования заказчика.

Слабые стороны:

1. Большие требования к вовлеченности команды в процесс.

2. Строгая документация, что несколько противоречит принципам Agile, когда продукт важнее документации.

3. Необходимость детального планирования перед каждым спринтом.

4. Необходимо выделять сотрудников, которые будут следить за процессом, при этом не будут участвовать в производстве, что ослабит команду.

5. Продолжительность процесса разработки может вырасти, необходимо быть к этому готовым.

В процессе адаптации к текущему проекту мы постарались минимизировать слабые стороны за счет более простого документирования (мини-техпроекты, создаваемые разработчиками), упрощенного планирования с небольшим числом участников, договорились с заказчиком работать на результат.

Адаптируем 7 принципов Lean

Согласно методологии Lean для разработки программных продуктов, выделяется 7 основных принципов:

• Исключение потерь. Потерями считается все, что не добавляет ценности для потребителя: излишняя функциональность; ожидание (паузы) в процессе разработки; нечеткие требования; бюрократизация; медленное внутреннее сообщение.

• Акцент на обучении. Короткие циклы разработки, раннее тестирование, частая обратная связь с заказчиком.

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

• Предельно быстрая доставка заказчику. Короткие итерации.

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

• Интегрирование. Передать целостную информацию заказчику. Стремиться к целостной архитектуре. Рефакторинг.

• Целостное видение. Стандартизация, установление отношений между разработчиками. Разделение разработчиками принципов бережливости. Мыслить широко, делать быстро, ошибаться мало; учиться стремительно.

Проанализировав принципы, сформировали 7 своих, которые подошли к нашей текущей ситуации и должны были помочь закрыть существующие проблемы:

1. Убрать ненужное

Под ненужным будем понимать следующее:

1. Все, что не приносит пользы конечным пользователям. Сюда относятся непонятные и несрочные требования, редко проявляющиеся дефекты. Мы их откладываем или отказываемся вовсе после согласования с заказчиком.

2. Ненужный код, дублирование кода.

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

4. Программные дефекты. Любые дефекты появляются, когда код не проходит достаточную проверку качества.

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

Что мы сделали, чтобы решить задачу:

1. Детальная проработка требований и согласование описания требований с тимлидом разработки, дополнительная расшифровка требований тимлидом на понятный для разработчиков язык.

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

3. Повышение взаимодействия разработчиков, консультантов и тимлида. Регулярные встречи 1:1, еженедельные встречи для мини-обучения и небольших вебинаров, еженедельная упрощенная ретроспектива для обсуждения и решения на месте текущих сложностей.

4. Формирование задач из набора требований в рамках одного реализуемого процесса. Расчет: разработчик загружен на одну задачу не менее 8 часов.

2. Создавать знания и обмениваться ими

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

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

3. Повышение качества кода

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

Для повышения качества были приняты следующие предложения:

1. Парное программирование. Непосредственное взаимодействие тимлида с разработчиками, совместный анализ требований, проектирование, решение сложных задач.

2. Степень готовности (Definition of Done, DoD). Задача считается завершенной только в том случае, когда разработчик обсудил реализацию с тимлидом и провел демонстрацию разработанной функциональности консультанту, который закреплен за данной задачей.

3. Максимальное количество задач в работе (Work In Progress, WIP) каждого разработчика. У разработчика в работе и в тестировании суммарно не может быть больше 3-ех задач. Если разработчик отправил на тестирование все 3 задачи, то он обязан довести эти задачи до публикации в продуктивную систему, для этого активно взаимодействует с консультантами, отвечает на возникающие вопросы, помогает в процессе тестирования.

4. Сокращение спринтов

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

Поэтому решили сделать ряд ограничений на спринт:

1. Спринт длится 1 рабочую неделю.

2. На спринт планируется трудоемкость, которую сможет закрыть команда разработки (на основе собранной статистики за предыдущие cпринты). Дополнительно закладывается время на устранение критических дефектов.

3. Все реализованные доработки тестируются на специальной копии продуктивной системы с продуктивными данными (PreProd), и только после успешной проверки публикуются на продуктивную среду (Prod).

4. Публикация на продуктивный стенд выполняется только один раз в последний день спринта.

5. После каждого спринта собирается сокращенная ретроспектива на 30 минут для сбора фидбека с команды.

5. Расширение полномочий команды

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

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

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

6. Не торопиться с принятием решений

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

Решение принятое под воздействием эмоций может породить к большому числу проблем.

7. Регулярная оптимизация процесса

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

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

Для реализации данного принципа с тимлида команды разработки были сняты все задачи по разработке и переданы команде, объем задач на спринт был сокращен, т.к. команда разработки фактически ослабла.

Тимлид команды теперь выступает в качестве наставника:

1. Организует периодическое обучение, разбор сложных ситуаций.

2. Инициирует передачу опыта между разработчиками.

3. Помогает консультантам в формировании требований, а разработчикам в реализации этих требований.

4. Занимается развитием разработчиков и расширением их компетенций.

5. Занимается подбором и развитием инструментария, повышающего эффективность процесса разработки.

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

Основная проблема бережливого производства отодвигание сроков

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

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

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

Итоги

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

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

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

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

1. Обеспечить единую общую среду общения и обмена знаниями.

2. Организовывать совместные видеоконференции, желательно с камерой, чтобы видеть эмоции участников.

3. Не пренебрегать неформальным общением.

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

По итогам внедрения Lean получили следующие количественные изменения:

1. Скорость разработки стала прогнозируемой и составила примерно 4 крупные задачи (до 6 часов на задачу в среднем) на сотрудника в неделю, ранее мощность команды в среднем составляла до 2-3 завершенных задач в неделю на сотрудника. Да, задачи крупные и это не совсем по Agile, но это помогло в нашей ситуации.

2. Сократилось количество публикаций примерно вдвое. На самом деле это существенная экономия времени, поскольку процесс публикации многоэтапный и затрагивает большое множество сотрудников.

3. Уменьшилось вдвое количество задач, возвращаемых на доработку.

4. Еженедельно закрывалось по 3 крупные задачи из техдолга.

5. Втрое уменьшилось количество дефектов, фиксируемых конечными пользователями.

Данный опыт планируется транслировать на другие проекты компании.

Спасибо за внимание, коллеги! Хотелось бы увидеть в комментариях ваш опыт использования Agile-Lean (или их адаптации) на ваших проектах.

Итак вы захотели оценить положение дел в команде. Оказались только что назначенным лидом или выдохнули после первого сданного проекта, который сделали не только собственными руками. Прежде чем бросаться за новый проект, задумались:

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

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

Теперь вы не только пишете код в большее количество рук. Вы ищете внутри команды технических лидеров и даете им реализовать свои амбиции, что дает рост людей. Чувствуете разницу?

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

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

Этап развитиякоманды

Если вы только что наняты или переведены, то попробуйте применить одну из моделей например модель групповой динамикиТакмена. В четырех словах: формирование команды, притирка, работа над принятыми ранее ролями, но уже конструктивно и собственно работа над задачами.

Если же вы сами набрали команду, то не стоит подразумевать, что путешествие по стадиям формирования будет происходить само собой, оставляя вас наблюдателем, потому как путешествие по модели, допустим, Такмена это далеко не вот этот график:

Скорее вот такой:

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

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

Что с этим делать?В первую очередь это инструмент рефлексии. Не столь важен ответ, сколько попытка построить кривую и попутно понять, что происходило с вами в последние месяцы.

Отпуски, переработки, дежурства

Эти составляющие выносятся за скобки рабочего процесса, считая что отпуск отнимает пропорциональный кусок ресурсов, а переработки дают прирост на 150200% и требуют только компенсации в разумный срок. На деле нелинейность складывается не только из первого порядка причин вроде батарейка разряжается или вливание в работу после отпуска, но и второго страдающей групповой работы людей разного состояния. Уставший менеджер не тянет бодрого аналитика, выгорающий бэкендер не может договориться с полным энтузиазма фронтендером.

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

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

Предыстория побед и поражений

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

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

Что делать?Добавлять новых героев в свой эпос, интересоваться не только решением задач, но и тем, как и какими эмоциями эти задачи были решены.

Текущие конфликты

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

А вот иррациональные конфликты или полный штиль повод присмотреться.

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

Цели и задачи стоящие перед командой и отдельными участниками

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

Это могут быть задачи развития от HR, всякие наследованные KPI, задачи на аналитику или обучение от соседних отделов, цели гильдии, например бэкендеров, выступления.

Для команды это могут быть OKR реализуемых проектов, внешние договоренности.

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

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

Договоренности и обязательства

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

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

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

Самостоятельность

По большей части самостоятельность это мера обратно пропорциональная вашей авторитарности. Как и необязательность зависимость от решений разрушает связи внутри команды. Зачем решать что-то вместе, если можно обратиться к начальнику?

Что измерять?

Представим рычаг, груз авторитета с одной стороны и независимость с другой. Где вы? Даже команда с высокой степенью зрелости может быть задавлена высокой авторитарностью. Куда будет двигаться опора решать вам, но текущее положение можно оценить по принимаемым решениям и вашем положении (или вашего предшественника) в них.

Искренность и токсичность

Можно много ссылаться на индустриальные стандарты токсичности, профессиональный юмор и критическое мышление, но кто будет спорить с тем, что команда верящая в свою пользу, более функциональна?

Что важно?Отслеживать вектор демотивации и не делать преждевременных действий. Вытаскивать конструктивную критику из юмора и трезво смотреть на нее.

Неформальные взаимодействия

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

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

Обучение

Уточните планы и ресурсы для обучения в компании. Наблюдайте за тем, как разработчики делится идеями и новостями индустрии. Ваше восприятие обучения зависит от роли и опыта.

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

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

Концентрация знаний

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

Стоит беспокоиться?Это не повод для суеты и насильного обмена опытом со всеми участниками. Можно как минимум осведомлять о существования атланта который держит важный сервис своей спиной, а еще лучше фасилитировать обмен опытом внутри команды.

Трансформация

Запущена ли трансформация ролей, процессов? Она может быть формальная например изменение оргструктуры, либо неформальная, когда вы приходите в новую команду и проясняете текущее положение дел, собираетесь пойти думать и вдруг кто-то вспоминает: А! Мы тут задумали перепилить воркфлоу, так что все что я говорил с понедельника станет не актуально. Предыдущий лид был согласен, ты же знаешь?.

Для чего?Выждать если необходимо или возглавить изменения. Иногда это повод для того, что бы отложить выводы о состоянии команды до окончания изменений.

Производительность

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

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

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

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

Попробуйте применить разные линзы для взгляда на команду. Если вы любите больше формализации, процессов и индикаторов попробуйте методику Health Checkот Spotify.

Будучи разработчиком, я выработал в себе привычку читать доки и мануалы систематически и в большом объеме. Сейчас я руковожу отделомiOSразработки вCardsmobileи практически не пишу код, но привычка осталась.Статей про менеджмент написано не меньше, чем по программированию. И начитавшись публикаций на очередную такую тему, я кое-что понял: зря я не читал их, пока активно кодил. Ведь в моей команде всегда есть как минимум один менеджер и хорошо было бы разбираться в том, что он делает. Хотя бы немного. Ведь если он делает свою работу плохо, то лучше подыскать нового?

Люди увольняются не из-за плохой работы, а из-за плохих руководителей.Исследование Герцберга показывает, что вторым по значимости негативным фактором, влияющим на мотивацию, является плохое руководство. Первый политика компании и бюрократия, что на самом деле является следствием плохого руководства.

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

Не всегда получается однозначно сформулировать, кто такой хороший руководитель и какими навыками он должен обладать. Бывает и так, что у руля компании стоит человек с уникальными компетенциями и визионерским началом, но при этом деструктивным менеджерским стилем. После прочтения этой статьи вам станет понятнее, почему Стив Джобс, к примеру, был плохим руководителем.

6стилей менеджмента

Существует множество классификаций менеджерских стилей. Больше других мне нравится классификация Дениэла Гоулмана,опубликованная вHBRв 2000 году. В ней выделяется 6 стилей:

• авторитарный,

• авторитетный,

• демократический,

• образцовый,

• товарищеский,

• обучающий.

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

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

Хорошие и плохие стили

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

Из графика видно, что самый правильный стиль авторитетный. Однако не спешите делать выводы. На самом деле не всё так однозначно. Во-первых, многие успешные менеджеры были авторитарны. К примеру, 2002 стал очень удачным годом дляTheNewYorkTimes: газета выиграла вв 7 из 13 номинаций Пулитцеровской премии.В том году компанией руководил человек, отличающийся авторитарным стилем Хауэлл Рейнс. Однако он был смещен со своего поста уже в 2003 году.

Более близким нам всем примером авторитарного менеджера является Стив Джобс. Хотя на самом деле исследователине могут четко классифицировать его стиль(и это целый материал для отдельной статьи, доказывающей, что Джобс хороший менеджер), онближе всего к авторитарному. Авторитарный стиль статистически плохой, а значит и Джобс статистически плохой руководитель. Однако только он смог вывестиAppleиз кризиса в конце 90-х и обеспечить попадание в топ-3 самых дорогих компаний в мире в 2011 году.

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

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

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

Образцовый стиль

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

Приобразцовомстиле руководитель ставит высокие требования к себе самому и к своим подчиненным. Например, в Кошельке старший инженер не только решает сложные задачи, но и регулярно выступает на митапах, пишет статьи, обучает менее опытных коллег, думает над тем, как улучшить процессы код-ревью, проектирует фичи, затрагивающие все iOS-команды (у нас их на данный момент 5), отвечает за технические метрики (крэш-фри, время запуска приложения), а также участвует в формировании процессов найма. А от перечисления всех обязанностей лида платформы меня бросает в холодный пот. Всё это звучит очень сложно, но на практике, при достижении определённого уровняразвития, это делается уже на автомате. А ещё мы всецело выступаем за дистрибутивную честность.

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

Чем же плох такой стиль? Руководитель может быть нетерпим к тем, кто его стандартам не соответствует. Станет давить насотрудников, чтобы дотянуть их уровень до своего представления, или, наоборот, выполнять работу за них самостоятельно, если они не успевают в жесткие сроки. Это, в свою очередь, может привести к другому негативному эффектусиндрому установки на неудачуи исчезновению мотивации и инициативы усотрудников.

Мы понимаем все негативные эффекты такого подхода, поэтому не ожидаем от каждого сотрудника, что он будет техлидом. Наша карта компетенций подразумевает очень широкое распределение по уровням: от тех, кто только стал мидлом, до уровней principal, techlead, platform lead.

Обучающий стиль

Мы стараемся мотивировать всех на рост. Для этого у нас выстроен честный и прозрачный процесс. У нас есть понятная карта компетенций, разбитая по навыкам и уровням, везде есть примеры того, что можно делать для достижения определенного уровня. И для каждого мы строим индивидуальный план развития на полгода. У всех он разный, кто-то ориентируется на продвижение в одной компетенции за раз, кто-то хочет развивать сразу несколько. И это уже является элементомобучающегостиля управления.

Мы верим в то, что сможем достигать крутых результатов, если будем развивать индивидуальные навыки своих сотрудников. Для этого каждые полгода мы проводим performance review. Оно включает в себя отзывы от коллег, self-review и 1-1 с руководителем для рефлексии. После этого мы составляем план на полгода таким образом, чтобы сотрудник знал, что ему делать для улучшения своих навыков. Каждый пункт этого плана является целью и ставится по фреймворку SMART. Например, если одной из целей является крупный рефакторинг, то мы определяем definition of done этого рефакторинга. Так он станет конкретным и измеримым. Планируем объём работ: реально ли закончить этот рефакторинг за 3-6 месяцев? И думаем о том, какую пользу он принесет компании.

Демократический стиль

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

Такой подходможет помочь при принятии непопулярных решений. Если по какой-то причине руководителю понадобилось списывать время в задачи, то он может внедрить эту обязанность двумя способами. Авторитарный путьзаставить всех списывать время, демократическийсобрать всех, объяснить проблему и то, почему её решение важно для компании. Не предлагать решения, а вместо этого попросить команду решить эту задачу на совместном обсуждении. Это займет время, но в конце концов команда сама придёт к решению, что списывать времяединственный рабочий вариант и примет его (если это действительно так). Таким образом, руководитель добивается полной осознанности и понимания этого процесса со стороны команды, снимает стресс, ведь все будут понимать, что трекинг времени нужен не для того, чтобы наказать кого-то за уход с работы на 20 минут раньше, а для того, чтобы лучше планировать, попадать в оценки и не перерабатывать.

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

Авторитетный стиль

Справиться с этой проблемой помогает авторитетный стиль. Авторитетный лидерон как самый энергичный таксист на районе, который знает все новости города, где выпить самый вкусный кофе, куда поехать в поисках приключений и какой номер телефона у Людочки из бюро находок в аэропорту; самый полезный человек, с которым вы когда-либо могли завести знакомство. Так и авторитетный лидер обладает наиболее полным и четким видением стратегии компании, знает, зачем и что мы делаем, способен замотивировать самого Тони Робинсона и в некоторых случаях дажеШайя ЛаБафа.

Это самый крутой стиль лидерства, если верить исследованиям в статье Гоулмана. На самом деле он частичновключает в себявседругиестили. Авторитетный лидер описываетDefinitionofSuccessи говорит, что нужно сделать, чтобы добиться успеха. Может показаться, что он авторитарен, но на смену принуждению и контролю диктаторского подхода приходит мотивация и свобода в выборе средства достижения результата. Как и при образцовом стиле, авторитетный лидер требователен к себе и своим сотрудникам, но, если сотрудник не справляется с поставленной задачей, это является не поводом его слить, а точкой роста и поводом применить обучающий стиль.

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

Товарищеский стиль

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

Работать в команде, управляемой товарищеским стилем, очень приятно. Это я вам по личному опыту говорю. Вы каждый день приходите на работу, где все ваши коллегиочень приятные люди, где вы не переживаете за настроение своего руководителя, ведь он никогда не проявляет своего недовольства результатами вашей работы. На такую работу хочется приходить, даже когда вы устали и не хотите работать. С утра выпьете кофе с коллегами, в обед начистите кому-то рожу вМорталКомбате и со спокойной душей пойдете играть в кикер. Завтра нагоните свой график.

Всё это выглядит очень увлекательно до некоторых пор: пока стендапы не превращаются в бесполезный ритуал, похожий на спор продавцовAvonи свидетелей Иеговы:

Я накосячил, не успел закрыть задачу, не попадаю в сроки, постараюсь закрыть тикет как можно скорее.

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

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

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

Далеко не каждая компания может позволить себе полагаться исключительно на товарищеский стиль. Если на косяки сотрудников закрывать глаза, то рано или поздно косячить станет нормойк этому проще станут относиться и сами сотрудники. На самом деле это не нужно никому: скорость работы команды упадёт,и от этого пострадает компания, а сотрудники расслабятся, будут медленнее развиваться или даже терять свои навыки. Самые сильные уйдут в другие компании ради собственного развития.

Авторитарный стиль

Давайте представим себе ужасную ситуацию. Через неделю дедлайн проекта, приуроченного к важной дате. Это может быть праздник (Новый год, 8 марта) или распродажа (Черная пятница или 11.11). Переносить дату релиза нельзя, в этом случае проект окажется никому не нужен. Однако вы построили диаграмму сгорания по проекту, и она четко указывает его окончание: ровно через 3 недели после необходимой даты.

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

Что остается делать в таком случае? Засучить рукава, обновитьIDEдо актуальной версии и засесть самому писать код? Очевидный пример образцового стиля. И, наверное, это и есть лучше решение для тимлида небольшой команды, но что делать руководителю, у которого в подчинении несколько команд? Замыкаться на однойплохая идея. Проект не будет готов, если в срок успеет одна команда из десяти.

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

Обучать людей банально нет времени.

Ситуация выглядит патовой. Мы перепробовали всеописанные вышестили, кроме одного. Быть может, воспользоваться мозгами команды? Устроить консилиум. Одна головахорошо, а девятьгидра! Я уверен, что, привлеки я коллективный разум к решению этой головоломки,мы найдем лучший выход из ситуации. И работать никто сверхурочно не будет, и качеством, возможно, не придется жертвовать. Но решение будет найдено слишком поздно. Принять сложное коллективное решениеэто как очередь за колбасой отстоять. Место занимать нужно за неделю, а в процессе, возможно, придется с кем-то подраться. Единственное применение коллективного разума в этой ситуации может быть в стиле мы тут подумали, и я решил. И это совершенно не демократический стиль. Этот стиль называется авторитарным. И для него даже собирать никого не нужно. Если вы уже знаете, как выйти из этой ситуациивыходите. Раздайте всем чёткие инструкции и следите за их исполнением. Не думал, чтокогда-нибудь это скажу, но микроменеджментнаш друг (осталось вырвать эти слова из контекста и меня можно будет недурно дискредитировать за такое).

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

Алгоритм подбора подходящего руководителя

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

1.Какие из стилей предпочитаете лично вы, как сотрудник?

2.Какой стиль подходит команде, которую вы рассматриваете в данный момент?

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

4.Какой стиль использует руководитель?

5.Способен ли он менять свой стиль?

О том, как ответить на эти вопросы мы поговорим ниже, а пока разберемся, как интерпретировать ответы:

1.Запишите ответ на первый вопрос, скорее всего у вас выйдет несколько предпочтительных стилей.

2.Стили из вопросов 2-4 должны быть из списка ваших предпочтительных.

3.Ответы на вопросы 2 и 4 должны совпадать.

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

Как понять, какой из стилей предпочтителен для вас

Это самый трудный вопрос, ответ на который вам придется найти самостоятельно. Отведите себе время на рефлексию после прочтения статьи.

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

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

Какой стиль подходит команде

Если команда или компания сейчас находятся в критическом состоянии или состоят сплошь из мудаков, то предпочтительнее авторитарный стиль. Если вы делаете что-то уникальное, например, нейросеть, которая будет запускать мозг человека в баночке в далёкий космос для изучения инопланетянами, то, скорее всего, члены командыуникальные специалисты, и будут хорошо себя чувствовать при образцовом стиле. Команда, состоящая сплошь из джунов, скорее всего выдаст лучший результат при обучающем стиле. Если у компании офлайн-бизнес, аITявляется всего лишь вспомогательным отделом, то я бы предпочел товарищеский стиль: интересной работы не будет, так хотя бы условия будут максимально комфортными. Во всех остальных случаях лучше справится авторитетный.

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

Какой стиль будет подходить команде черезN-время

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

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

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

Альтернативным способом получить такую информацию является собеседование. Если вы хотя бы раз проходили собеседование в любую компанию, то наверняка слышали вопросы вроде: Кем вы видите себя через 5 лет?, Назовите ваши слабые стороны и т.д. Очевидно, что все эти вопросы задают не с целью потянуть интервью подольше, они нужны для определения софт-скиллов. На самом деле такими вопросами можно многое узнать о мотивации кандидата, составить его психологический портрет. Такого рода вопросы это мощный инструмент, который можно использовать и в обратную сторону. Не упускайте свою возможность задать вопросы, когда вам дают слово, попросите о дополнительной сессии с будущим начальником, коллегами. Задавайте вопросы, пока не сформируете полное представление о стиле руководства в компании. Конечно, этими техниками нужно уметь пользоваться, и если вы не знакомы с софт-скилловой стороной проведения собеседований, почитайте про интерпретациюфраз-маркеров, фреймворкиSTARиPARLA. Как и в случае с любым другим инструментом, чем больше вы будете практиковаться, тем лучше у вас будет получаться.

Стиль спускается каскадно от топ-руководителей

Есть один важный нюанс. Скорее всего, вы не идете на работу в маленький стартап, где вашим руководителем будет сам основатель. Это значит, что у вашего руководителя будет ещё как минимум один руководитель на уровень выше. Если ваш непосредственный руководитель милейший человек, который всегда за своих орлов, а его руководитель авторитарный деспот с усами, то так или иначе вы будете ощущать авторитарную нотку управления на себе. Если кто-то из директоров вздумает установить в офисе камеры и будет лично следить за тем, кто уходит на 15 минут раньше положенного, то никто вам не поможет. Каким бы подходящим ни был ваш тимлид, он будет не в силах спасти вас от бушующего СТО. Именно поэтому при собеседовании нужно задавать вопросы по фреймворкуSTARилиPARLA, узнавать отзывы бывших сотрудников. Важно не то, что говорят руководители, а то, как они поступают.

Заключение

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

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

Ну правда, зачем? Задача тимлида сделать всё, чтобы команда работала эффективно. Зачем быть искренним и эмпатичным, если люди это ресурс, и вы умеете ими управлять?

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

С этого и начну.

Самосознание

Эмпатия помогает отлавливать, что вы чувствуете, что с вами происходит, когда вы слушаете другого человека. Здоровое обращение к своим чувствам, проживание контактов с другими людьми помогает не выгореть, что очень важно при работе тимлида. Я уже упоминала, что риск выгорания больше у тех, кто много взаимодействует с людьми. А от тимлида все чего-то ждут, чего-то хотят. И когда мы уходим на большую дистанцию от своих переживаний, мы можем очень быстро выгорать. Особенно часто это случается, когда вы забываете про собственную психологическую гигиену. Забываете спросить: А что я сейчас чувствую? Что со мной происходит? А как мне это?

Понимание мотивации и интересов сотрудников

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

Сейчас часто можно встретить в наших тимлидских чатах такое мнение: самая главная мотивация человека деньги. Не спорю. Деньги это круто. Но кроме денег есть ещё что-то, что нас может мотивировать ничуть не меньше. Те, кто работает в топовых компаниях, или ходил на собеседование в топовые компании, знает, что иногда кандидат приходит на понижение. Потому что он хочет попасть именно в эту команду, к этому тимлиду. И он идёт на понижение зарплаты, порой даже значительное. Потому что у него есть какая-то мотивация кроме денег, и она преобладает. Например, работать в значимой команде и заработать какой-то статус: я попал, например, в компанию А, я там был разработчиком. Об этом важно не забывать.

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

Была такая история у коллеги: он был крутым разработчиком, и компания была уверена, что раз он такой крутой разработчик, он станет таким же крутым тимлидом. Его главная особенность была в том, что он невероятно, чуть ли не фанатично верил в продукт, который они делали, социально значимый продукт с хорошими инвестициями. Он стал тимлидом и достаточно быстро набрал команду из 7 человек. В течение 5 месяцев у них не было проблем, они хорошо перформили на его мотивации и на его отношении к продукту, и всё было здорово.

Но постепенно всё начало разваливаться: команда вносила что-то своё, свои идеи, критиковала продукт, говорила, что здесь что-то не так, здесь что-то не то И тимлид попадал в ситуацию непонимания: в каком смысле что-то не то? Мы делаем с вами вот такой продукт, это же так здорово! Почему вы к этому не относитесь так же, как я? Он не мог даже подумать, что другой человек, разработчик из его же команды, может отличаться по своей мотивации от него самого. Он был уверен, что все в команде смотрят на мир такими же глазами, как он.

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

Разрешение конфликтов

Эмпатическое слушание помогает работать с конфликтными ситуациями, потому что вы встаёте на место другого человека, пытаетесь понять, чем он руководствовался в той или иной ситуации. Вы можете делиться своим видением ситуации и задавать сотруднику вопросы коучингового характера не какие-то заумные, конечно. Вы его можете направить, сказать: Слушай, у вас сейчас с вашим коллегой-разработчиком конфликт; давай посмотрим, что произошло, почему произошло. Какая мотивация была у твоего коллеги, какая у тебя.

Чтобы в управлении командой быть качественным, необходимо

• качественно проживать свои эмоции

• понимать, что в каждом случае вы хотите получить

• как вам важно эту ситуацию разрулить

• чему вы сможете своих сотрудников в связи с этим обучить

Когда вы научитесь соотноситься с тем, что вы сами чувствуете, проживать это на уровне вас самих, вам это поможет не вступать в какие-то конфликты, потому что вы сможете вовремя себя отловить: Вот сейчас я раздражён, потому что устал, а не потому, что этот разработчик не вовремя ко мне подошёл и что-то мне не так сказал. Мне просто нужно сейчас посидеть одному в тишине. И не сорвётесь на него.

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

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

В PropellerAds решили пойти по принципу нет человека нет проблемы и отказались от роли тимлидов. Как компании удалось это провернуть, не только не потеряв ни одного руководителя, но и успешно привлекая тимлидов из других компаний, в своем докладе на конференции TeamLead Conf 2020 рассказал глава продуктового отдела PropellerAds Яков Беккер.

Давайте поговорим о том, кому нужен тимлид? Вопрос риторический, поскольку ответ на него знают все: тимлид нужен в первую очередь руководству.

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

Тимлид необходим руководству, которое просто обожает так называемую игру на гармошке, когда начальники спускают вниз задачи, а потом собирают статус.

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

Что еще, кроме предоставления статуса и спуска распоряжений вниз, хочет от тимлида руководство?

Ожидание: функции тимлида

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

Руководство надеется, что тимлид будет управлять процессами в команде, и станет выполнять роль менеджера продукта или проекта. Хотят, чтобы он понимал domain.

Кроме того, тимлид должен отвечать за качество. Багов быть не должно, особенно в продакшен. Руководитель не хочет, чтобы его разбудили в 3 часа ночи, чтобы уведомить, что все упало и не работает. Очень удобно, когда есть человек, который отвечает за такие вещи и знает, как все оперативно исправить.

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

Кого же нужно найти?

Руководители ищут некого сказочного единорога мира кода, который должен уметь делать все. Но в реальности его не существует.

Реальность: проблемы в работе тимлида

В реальности тимлидом назначается не человек, который обладает всеми перечисленными скилами, а просто лучший разработчик. Обычно он не только не умеет делать всего остального, но и банально не знает к чему ему нужно стремиться. С другой стороны, от него требуют результата, которого он всеми силами пытается достичь, чтобы оправдать доверие руководства. Что мы получаем:

• Вся ответственность ТОЛЬКО на тимлиде;

Наверное, самая большая проблема в том, что на тимлиде лежит весь груз ответственности.

• Отсутствие делегирования;

Часто тимлид перестает делегировать, потому что боится за качество и результат. Или он не умеет делегировать и не понимает, как делать это правильно. Многие думают, например, что делегирование это просто спускание тасков вниз.

• Mикроменеджмент;

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

• Слабое руководство вызывает недовольство команды;

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

Вся команда только и говорит о том, как плох тимлид.

• Тимлид выгорает;

На тимлиде куча ответственности, есть проблемы, которые нужно решать, команда им недовольна. И при этом он работает по 12 часов. Человека нужно спасать. Если спасти не удалось, он уходит из компании.

• Проблемы при уходе тимлида из компании;

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

• 25% лучших разработчиков не пишут код.

Представьте, что у вас были звезды разработки. Они писали код, а теперь его не пишут. Это ситуация 25% лучших разработчиков не пишут код должна приводить в ужас любого CTO.

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

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

И есть другая команда:

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

Конечно, на деле все не так ужасно: есть хорошие тимлиды. Но стать единорогом в этой сфере очень тяжело. Есть большое количество курсов и тренингов, есть TeamLead Conf с огромным количеством возможностей учиться. Все это помогает нам вырастить хороших тимлидов и исправить проблемы, описанные выше.

Но в PropellerAds структура управления устроена по-другому, и это работает.

Решение: самоорганизующиеся команды

В PropellerAds есть продуктовые команды, которые стоят в центре системы компании. В них входят:

• Владелец продукта (Product Owner) это человек, который разбирается в продукте, работает с бизнесом, строит бэклог, менеджерит риски, пишет User Story и прочее;

• Разработчики, scrum-мастер;

• Тестировщики;

• DevOps.

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

Где же руководители? Они есть у каждой функциональной группы (PO, разработчиков, тестировщиков, DevOps).

Что такое функциональный руководитель? Это тренер функции: тренер разработчиков, тренер тестировщиков и т.д. В его задачу входит растить своих людей и поддерживать их уровень.

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

Распределение обязанностей в команде

Кто занимается разработкой кодом, дизайном, архитектурой?

Разработчики.

Кто занимается продуктом?

В продуктовой компании это очень важный вопрос. Например, стоит задача создать кабинет для рекламодателя. Нужно разговаривать с заказчиками каждый день. В PropellerAds PO этого направления ездит на профильные конференции, общается с рекламодателями, делает Customer Development, проводит вебинары.

Кто занимается управлением процессами в команде?

В PropellerAds нет выделенной роли scrum-мастера. Эту роль чаще всего играет не senior-разработчик, а тот, кому это интересно. Например, QA, DevOps или middle-разработчик (junior не может). Это должен быть человек, которому интересно этим заниматься.

Кто управляет инцидентами?

Логично выделить для этого DevOps-инженера.

Что с единой точкой входа?

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

Кто занимается наймом, ростом и мотивацией людей?

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

Почему все так здорово? Функциональные менеджеры целыми днями ведут планы персонального развития, делают one-on-one, правильно проводят квартальные ревью, никого не обижают. Они видят свою роль в том, чтобы их команде было хорошо, а отдельным людям было приятно работать в PropellerAds, чтобы специалисты развивались и через 3 года стали лучшими инженерами. Это одна из самых важных целей функционального менеджера.

Их задача заключается в развитии людей и в продвижении по эффективности.

Из-за того, что есть роли (PO ответственен за продукт, QA за инциденты и пр.) может показаться, что ответственность лежит на определенных людях. На самом деле, это не так, ее несет вся команда.

В компании используют Slack. как вы думаете, кого кастуют в случае инцидента? Чаще всего не конкретного человека, а всю команду. Например, кастуют команду Core, и отвечают три человека: PO, разработчики и QA каждый по своим вопросам. То есть точкой входа становится не конкретный человек, а команда.

Структура управлением бизнеса

Как в PropellerAds управляют бизнесом? Есть руководитель направления, например, определенного формата рекламы. У него в подчинении маркетинг, продажа и оптимизация. И этому руководителю выделяются 1-2 продуктовых команды, чтобы они выполняли 90-95% его тасков, и ему не пришлось искать помощь на стороне.

Получается эффективно, потому что команды понимают, для кого они работают, а заказчик понимает, кто для него работает.

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

Структура управления технологией

В PropellerAds есть функциональный менеджер разработки R&D-менеджер.

Он организовал четыре направления и нашел тех, кто согласился их вести. Во главе направлений встали senior, каждый из них лидер. Кто-то ведет ротацию, кто-то данные, кто-то фронтенд, кто-то back office.

R&D-менеджер собирается с командами, строит технологическую стратегию, презентует ее на стратегической сессии и т.д.

Решение: все проблемы устранены

Что получила компания в итоге:

• Ответственность всех членов команды от нее стало очень сложно спрятаться;

• Несколько человек в команде являются точкой входа;

• Командная работа вместо микроменеджмента;

• Команды довольны руководством;

• Лидеры не выгорают;Выгорают обычно от того, что человек занимается нелюбимым делом, или не способен сделать то, что от него требуют.

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

• 25% лучших разработчиков снова ПИШУТ код.И это просто вау!

Проблемы

Выше нарисована, казалось бы, идеальная картина. И все же в PropellerAds есть определенные проблемы.

Проблема командной ответственности

Бывает, в одной из десяти команд, коллективную ответственность воспринимают так, будто ответственности не несет никто. И вот кастуешь команду из восьми человек по какому-то вопросу, а ответа нет. Пропустили Sprint Goal и это никого не волнует. Раньше по этому поводу нервничал бы хотя бы тимлид.

Управлять тимлидом легче, чем целой командой: его можно мотивировать, или поменять.

Эта проблема решается просто: в команде должно быть 2-3 лидера.

Обычно PO лидер по определению. Он строит продукт: как же он может не быть лидером? Остаются еще два: например, QA и разработчик. То есть должны быть ребята, которые тащат команду на себе, не потому что им сказали это делать, а оттого, что им самим это нравится они чувствуют азарт. В большинстве команд так и происходит.

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

Проблема управления матричной структурой

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

Без тимлидов в компании становится сложнее. Но можно наладить успешное взаимодействие, если есть три важные вещи.

• Доверие;

Очень важно доверять друг другу, потому что иначе команда не сможет функционировать.

• Независимость;

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

• Пассивный контроль.

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

Проблемы карьерного роста

Тимлид, должность которого упразднили в компании, может остаться этим недоволен.

Давайте задумаемся, чего хочет человек, который мечтает стать тимлидом:

• Иметь авторитет и, как результат, получить влияние и независимость;

• Саморазвиваться;

• Зарабатывать больше денег.

Чтобы получить все это, можно построить карьеру внутри компании.

Карьера разработчика в PropellerAds

С тимлидами в компании было бы движение по иерархической лестнице. У них не было бы другого пути: хотели они или нет, но должны были бы превратиться в мифического единорога. И чем лучшими тимлидами они могли стать, тем дальше могли продвинуться по карьерной лестнице. И если CTO уволится, то получится получить его место! Но часто ли вы видели увольняющегося CTO?

Сейчас в PropellerAds можно стать функциональным менеджером. У СТО есть команда из шести человек: Head of Analytics, R&D менеджер, Head of QA и люди, которых можно назвать руководителями высшего звена.

Можно стать техлидером, или product-менеджером, они всегда нужны: каждый квартал что-то происходит. Как этого добиться? Поинтересуйтесь продуктом, domain, клиентами, сходите на курс, предложите себя.

Если вы middle-девелопер, можно стать scrum-мастером, или коучем.

Кроме того, можно вырасти в business owner.

Все в руках сотрудников.

Изменение структуры

Легко ли создать структуру, которая сложилась в PropellerAds? Относительно тяжело. Гораздо проще организовать иерархию тимлидов.

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

TeamLead Осень 2020 пройдет 29 и 30 апреля 2021 года. Приобретайте билеты и становитесь частью единственной профессиональной конференции только для тимлидов.

А программный комитет Saint TeamLead Conf 2021 ждет вашидоклады.

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

Может показаться, что тимлида подбор затрагивает весьма косвенно это вотчина рекрутеров. Тимлид человек простой: дал задачу, провел парочку интервью, выбрал лучшего и всё. Вы великолепны. Но размышлять в таком ключе вредно, если не сказать опасно. На деле зачастую выходит так, что хорошие кандидаты почему-то идут работать к конкурентам, а все шишки традиционно валятся на рекрутера. Но я считаю так: невиновных в этом случае нет. А в идеале за подбор в команду отвечает непосредственно тимлид. В этой статье я поделюсь опытом в подборе и собственными инсайтами на этот счет.

Про ошибку найма и ответственность

Что я понял на своем опыте: ошибка в найме это большой урон для компании и команды.

Только подумайте: целых две недели уходят на поиски рекрутер тратит свои часы, руководитель и команда отвлекаются от задач, смотрят резюме и ходят на собеседования, команда к нему привыкает, а через месяц оказывается, что вы друг другу не подходите. Или проходят недели и месяцы, а человек все не находится. Это плохо влияет на деньги (зарплата рекрутера, стоимость рекламы для привлечения и пр.), на HR-бренд работодателя, на настроение в команде и нагрузки: задачи, которые пока не выполняются, ложатся на других ребят. Вот тут пора понять, что наём это всегда командный проект.

Ключевой персонаж в этом проекте не рекрутер, а тимлид. Именно он изначально формирует задачу, на нем ответственность за окончательно принятое решение, даже если при этом голосует вся команда.

Для себя я это формулирую так: ответственный за подбор я, а рекрутер это мои руки в найме.

Когда рекрутер пинает тимлида и команду разработки это нормально

Воронка подбора это зеркало найма, то, как он проходит у вас в компании. Поэтому воронка бывает разной: у кого-то шесть-семь этапов, а у кого-то все двадцать. В разработке hh.ru воронка выглядит так:

Заявка на подбор скрининг резюме рекрутером согласование кандидатов техническими специалистами интервью с командой тестовое задание (опционально) повторное интервью оффер.

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

Какие возникали проблемы и как мы их решали? У нас постоянно подвисали кандидаты на этапе согласования с техническими специалистами: ребята заняты своими задачами, отложили просмотр резюме на вечер, а потом забыли. Через неделю посмотрели, да только уже поздно сфера конкурентная, за это время часть соискателей получили другие предложения. Мы поняли, что нужно менять подход, чтобы такие косяки не вылезали и рекрутер не делал работу по два раза.

В результате сели за круглый стол: я, команда, рекрутер. И нарисовали схему:

• как идет процесс

• кто за что отвечает

• какие максимальные сроки у нас заложены под каждый этап

Решили, что если накапливается определенное количество нерассмотренных кандидатов, то рекрутер пишет в общий чат и не стесняется нас пинать. Если кандидат нереально хорош, то может отправить прямо ссылкой кандидат горящий, важно не потерять!.

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

А еще от зависаний нас спасает сервис из экосистемы hh.ru облачная CRM для рекрутмента Talantix. В ней можно прописать сроки под каждый этап воронки, и, если кандидат начинает подвисать, система сама напомнит. Это удобно не только разработчикам, рекрутер тоже доволен ведь у него куча задач, и иногда можно в суматохе забыть нас дернуть. А тут CRM сама подсказывает, освобождая от части рутины.

Кандидаты у нас долго не залеживаются, поэтому приложил скриншот из соседнего отдела:

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

Выбрасываем все лишнее

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

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

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

У рекрутеров в ходу есть такой мем;)

Заявка на подбор и текст вакансии это не одно и то же

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

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

Тут важно соотнести свои ожидания с подсказками рекрутера, который лучше вас знает ситуацию на рынке труда.

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

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

Слышал истории о том, что тексты вакансий составляются по схеме: нашли что-то похожее на hh.ru, немного подправили, дописали побольше технологий, опубликовали. При этом список требований у джуниора как для мидла со стажем. Не делайте так! Обязательно возле некритичных требований указывайте в скобках будет плюсом, иначе вы будете очень долго искать человека, и от этого будет нехорошо не только рекрутеру, но и самому отделу.

История из жизни Как мы искали мидл-разработчика

Как-то искали iOS мидла в команду. Откликов мало и находятся вообще не те люди. Сели за круглый стол, все обсудили и поняли: то, что мы готовы предложить, нерелевантно требуемому опыту. Поменяли всего одну цифру (указали 3 года), и процесс пошел. Мой совет: будьте внимательны к каждой строке вакансии одна цифра или фраза могут в несколько раз сузить воронку.

Также полезно анализировать воронку на продвинутом уровне. Я регулярно смотрю в Talantix, все ли у нас хорошо. Сразу видно, на каких этапах срезаются кандидаты. Например, выясняется, что входящих откликов много, а техническое интервью проходят единицы. Что тут может быть? Например, плохо прописали заявку с рекрутером, и он не тех ищет/не те откликаются. Тогда нужно вместе пересмотреть требования и переписать текст вакансии.

Идеальные вопросы для интервью какие они?

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

Совет: идите в ногу со временем и не задавайте вопросы типа Кем вы видите себя через 5 лет или Собираетесь ли вы в декрет. Вряд ли вам ответят правду, зато такие вопросы негативно влияют на ваш HR-бренд. Спросите лучше о мотивации или о том, в каком направлении кандидат хочет развиваться. Это будет корректней и информативней для вас.

История из жизни Как мы проворонили хорошего кандидата

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

Лайфхаки

После интервью мы обычно созваниваемся с командой, делимся впечатлениями и вместе принимаем решение.

Вот несколько наших секретов:

• У нас есть общий чат, где прямо во время интервью можно написать Мне кандидат нравится, давайте еще вот это спросим.

• Мы используем таблицу технических навыков, которую можно заполнять прямо во время интервью отмечать, что есть и чего нет.

• Кандидату по результатам отвечаем не сразу, а на следующий день, чтобы можно было поспать со своим выбором.

• Попробуйте провести ретроспективу по процессу найма.

• Смотрим на бюджет: если кандидат хороший, но сильно выше бюджета, а при этом есть слегка уступающие варианты с другим ценником это влияет на выбор.

Вместо заключения

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