Teamleadconf

До единственной профессиональной конференции только для тимлидова 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.Выходите на свет рампы вместе с нами!

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

Историями о профессиональных сообществах сейчас вряд ли кого-то удивишь. Гильдии образуют по разным причинам: кто-то из интереса, кто-то чтобы быть в тренде, а кто-то из-за недостатка общения на профессиональные темы. Это история о том, как бизнес-направление компании ЦФТ, Денежные Переводы Online, желая производить больше и быстрее, в очень короткий срок утроило штат инженеров, которых не успели нормально заонбордить, и в итоге чуть не уронили качество продукта и не сожгли ключевых членов команды.

Доклад в виде пошагового рецепта QA-лидам, fullstack feature team-лидам, SM и всем тем, кто решает задачу эффективной настройки процессов команд, представила на конференции TeamLead Conf 2020 Head of Android QA одного из флагман-продуктов компании ЦФТ Надежда Потаенко.

Продукт ЦФТ Золотая Корона в 2016 году прочно стояла на позиции самой крупной системы денежных переводов без открытия счета на территории России и СНГ. В момент, о котором пойдет повествование, у пользователей появилась возможность начать отправлять переводы не только офлайн, но и через веб и мобильные фронты.

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

Стало понятно, что продукт взлетел, и его надо срочно развивать. Именно высокая востребованность продукта заставила ЦФТ очень быстро вырасти. За три года команда разработки продукта Денежные Переводы Online увеличилась с 7 до 200+ человек. В какой-то момент старые производственные процессы просто перестали работать. Сотрудники вынуждены были отправиться на поиски новых конфигураций.

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

Для кого готовим?

Гильдия, о которой мы поговорим это 25 QA Android инженеров. Если вы не имеете отношения к качеству, это не страшно. Рекомендации, которые вы увидите здесь, легко портируются как на команду разработки, так и на команду аналитики. Информация может быть полезна даже agile-гуру и вообще всем людям, которые ищут точку опоры для создания профессионального сообщества, но пока что ее не нашли.

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

Что было в холодильнике?

Шел 2016 год, и в компании стал развиваться продукт, который начал активно зарабатывать деньги. Ранее этот продукт разрабатывала сравнительно небольшая команда из 20 человек (4 компонентные команды: Backend, Web, iOS, Android), все сидели в славном городе Томске и были экспертами в продукте. Казалось, все идет просто идеально!

Но как это часто бывает, заказчик с этим согласен не был. В 2017 году он начал задавать вопросы о том, почему продукт так долго релизят?

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

Настал 2018, и боги провозгласили год найма и новых рук. Компания начала расти, причем не только в Томске, но параллельно в Новосибирске и в Питере. На графике видно, что в конце 2018 появилось 130 инженеров в 3 локациях, а в 2019 их стало больше 200. Это около 30 команд, которые сейчас совместно пилят один и тот же продукт: Денежные Переводы Online.

От такого роста ожидали увеличение скорости разработки и сокращение TTM, но получили совершенно иную картину.

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

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

• Не успевали качественно онбордить

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

• Разный уровень hard skills в разных локациях

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

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

Другой пример: в Новосибирске инженеры считали, что побегать за аналитиком и дожать из него недостающую информацию это ОК. В Питере ребята сказали: Ну нет! Должен быть четкий Definition of Ready. Мы ни за кем бегать не будем!

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

• Релизила по-прежнему одна команда

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

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

В какой-то момент Надежда поняла, что надо спасать коллег по цеху.

Шаг 1: Перемешать и поставить на плиту

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

• Повысить степень причастности и ответственности;

• Выровнять уровень понимания бизнес-логики продукта.

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

Шаг 2: Довести до кипения

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

Например, что-то тестили, попали на незнакомый flow, испугались, завели баг, кинули его в чат Android: кто-нибудь потом разберется. А на самом деле просто заехала новая фича, поменялся flow, а тест-кейсы еще не актуализировали.

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

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

Как тушить все это, было непонятно.

Шаг 3: Остудить, еще раз перемешать

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

• Выработать единый подход к регрессу;

• Найти способы ускорить регресс;

• Восстановить качество релизов;

• Делиться друг с другом экспертизой в продукте.

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

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

А еще ей хотелось сформулировать цель совместной работы.

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

Качественно и быстро это отсылки к желаемому сокращению ТТМ и к восстановлению уровня качества.

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

Мозговой штурм был построен на базе книги 5 пороков команды Патрика Ленсиони. И на него было потрачено около 8 часов.

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

Когда участники встречи разъезжались, заряд community был такой мощный, что все говорили: Эге-гей! Да мы следующий регресс вообще за день бахнем!.

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

Шаг 4: Выпекать до готовности

В команде Денежных Переводов Online договорились проводить регулярные встречи гильдии раз в 2 недели.

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

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

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

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

Канал коммуникации очень простой: QA-инженеры раз в две недели встречаются онлайн в Microsoft Teams.

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

Осторожно! Горячо!

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

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

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

Шаг 5: Сбрызнуть соком лимона

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

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

В команде появился такой wishlist:

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

Но проблемы начались с самого первого митапа.

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

С тех пор в команде договорились, что все на 100% должны четко понимать, что именно будет обсуждаться.

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

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

Шаг 6: Дать отдохнуть

В ДП Online решили отправлять сотрудников в командировки для того, чтобы они начали встречаться не только онлайн, но и лично. Когда появилась страничка графика поездок, очередь туда выстроилась до конца 2020 года. И все, естественно, хотели в Питер, ведь две другие локации находились в Сибири.

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

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

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

Профиты командировок:

• Для продукта: быстрый шаринг экспертизы;

• Для инженеров: сменить обстановку, пообщаться с иногородними коллегами.

За счет командировок сотрудникам QA-сообщества ДП Online удалось выработать единый подход к регрессу и найти способы ускорить его, восстановить качество релизов и делиться друг с другом экспертизой в продукте.

Что дальше?

В 2020 году в ЦФТ появились новые цели саморазвития гильдии.

• Коммуникация с QA-гильдиями других платформ продукта;

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

• Ежемесячные публикации блога с обзором новостей платформы и сообщества.

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

Есть и продуктовые цели.

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

Выводы в цифрах и фактах

На картинках активности, которые пробовали применять в QA-сообществе ДП Online.

Рост качества, произошедший на почве работы сообщества, напрямую отразился на количестве hot fixов на число выпущенных версий.

И немного статистики релизов продукта за 2018-2019 годы. Внизу красным подсвечены hot fixы. В 2018 году в ДП Online было нормой раз в 3-4 релиза выпустить hot fix. С 2019 года, когда начала собираться гильдия экспертов, hot fixов почти нет. За весь 2019 год выпустили всего 4. Причем речь не о клиентских, а о технических hotfixах, например, когда какое-то событие было потеряно в Google Analytics.

Кроме того, активности, которые были направлены на решение продуктовых проблем, принесли несколько положительных сайд-эффектов:

• Тюнинг soft skills;

• Единое информационное поле;

• Здоровая конкуренция;

• Новые лиды.

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

Программный комитет 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!

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

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

С другой стороны, совсем без инструментов, документации и дедлайнов справиться с проектом не получится. Это Дмитрий Ильенков из 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 еще открыт прием докладов. Мы помогаем спикерам во всех вопросах выступления, в том числе учим выступать и как подготовить презентацию. А в Программном комитете ваши заявки просматривают и отбирают опытные спикеры, неоднократно выступавшие на разные темы и эксперты в своих направлениях. Выходите на свет рампы вместе с нами!

Любой 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 ждет вашидоклады.

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