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

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

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

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

Tech Lead, Team Lead, Engineering Manager – разобраться, кто из них за что отвечает и каким полномочиями обладает, бывает непросто. Более того, разные компании порой вкладывают совершенно разные понятия в одни и те же названия должностей. Где-то Team Lead отвечает за техническую составляющую проекта, где-то руководит процессами, а где-то от него ожидают еще работы с людьми.

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

О чем мы поговорим:
– кто такие Tech Lead, Team Lead, Engineering Manager на примере крупных компаний;
– как распределяются зоны ответственности между ними и какие полномочия выделяются;
– зачем нужно такое разделение в целом и как это работает как система;
– какие нужны скиллы, и как происходит рост в каждой из этих ролей;
– как это работает в Badoo.

87% DS-проектов не доходят до прода.

Попытки выстроить процесс в AI-продукте при помощи практик, работающих в классическом Software Engineering, проваливаются.

Ключевые проблемы: сложно взаимодействовать с заказчиком-профаном в AI, множество проблем с доступом, верификацией, трансформацией и валидацией данных, тяжело отслеживать и объяснять результаты AI/ML и т.д.

Мы обсудим, как правильно построенный процесс DS-проекта может помочь исправить ситуацию.

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

Меня зовут Александр, я direction lead в Lamoda. За 10+ лет стажа в IT неоднократно собирал команды с нуля и в процессе собрал для себя набор полезных в онбординге практик.

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

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

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

Что делать, если людей собрали, но они так и не стали командой? Возможно ли это изменить, не прибегая к радикальной мере «всех разогнать и собрать заново»?

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

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

Представим, что ты не тимлид команды, а тренер покемонов и уже набрал себе несколько. В твоих покеболах:
* парочка джунов — чармандеров, которые бесконечно достают вопросами, отвлекают от работы и пару раз своим хвостом подожгли прод;
* сеньор — мьюту, которому постоянные переработки и изменения в команде не пошли на пользу. Ему чужды OKR, Scrum и прочие хипстерские штуки, и он думает как сбежать. Компания без этих бесконечных встреч, с зарплатой повыше и новыми амбициозными задачами его бы устроила;
* мидл — снорлакс, который занимается только тем, что ест и спит. А работает над задачей, только если ты пинаешь его каждые 5 минут.
* один очень-очень токсичный разработчик — коффинг. Он создает переизбыток разгильдяйства и драмы, что потом взрывает команду. Даже простую задачу делает месяцами, демотивируя остальных; постоянно ноет, разочарован в компании и в своей жизни; на работу приходит к обеду, игнорируя встречи команды.

В такой конфигурации вам явно не стать Мастером Покемонов и в турнирах не побеждать. Что же делать?

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

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

Найм в IT — задача не самая тривиальная, и этим часто приходится заниматься тимлидам и инженерам. Я расскажу про то, как собрать крутую команду из ничего без помощи HR’ов и бюджета на высокие зарплаты. С чего начать? Как понять, сколько и на какие позиции сотрудников нанимать? Как правильно делать отбор? В докладе будет всё про найм айтишников: от поиска кандидатов и проведения собеседований до оценок инженеров и психологических аспектов ввода новых людей в команду.

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

Меридит Белбин в эмпирических исследованиях построил ролевую модель команды и описал варианты сильных и слабых команд. Часть из них актуальна для IT-команд, и я на опыте наблюдал проявления разных описанных эффектов. Именно на практических кейсах IT будет фокус доклада, ранее (http://mtsepkov.org/Belbin-COMAQA) я просто рассказывал книгу.

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

Примерно два года мы в Wargaming, Platform работаем над внедрением карьерных уровней и наконец вышли на финишную прямую. Я поделюсь тем, что у нас получилось, и вы даже сможете покритиковать - потому что мы за открытость и объективность. А ещё поделюсь найденными нами ответами на наиболее сложные по нашему опыту вопросы:
* Как связаны карьерные уровни и зарплата?
* Зачем вообще нужны карьерные уровни?
* Как продать карьерные уровни руководству?
* Как внедрить карьерные уровни?
* Чем отличаются грейды и карьерные уровни?
* Как привнести пользу и не нанести вред открытостью?
* Как лавировать между уровнями рынка, Гугла и внутри компании?
* Как договориться до минимальных, но достаточных определений уровней?

Мне все говорят: с джуниорами невозможно работать.

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

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

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

Что делать?

Использовать лёгкие фреймворки. Например, p3express. О нём и будем говорить.

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

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

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

Мы много раз слышали, что одна из основных задач руководителя — это мотивация своих сотрудников.
Однако наш опыт показывает, что даже самые усердные попытки “осчастливить” свою команду не всегда заканчиваются успешно. Мы платим больше, даем новые должности, оплачиваем дорогое обучение, а они все равно недовольны или уходят. Почему?

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

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

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

Хотите узнать, что делать, если ваш инженер сказал: "Нам нужно поговорить..."? Тогда вам сюда!

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

Всё хорошо, но однажды вы попадаете в интересную историю, как и я. Например, вы заметите, что перестали находить общий язык с более молодыми или более взрослыми сотрудниками. Вы полезете в интернет за быстрым лекарством и найдете его — "Теория поколений". Прочитаете массу статей на эту тему, где представители старших поколений изображают из себя гуру в Поколениях, они сравнивают 3-4 Поколения (пользуясь не всегда проверенными фактами), строят свои модели на этот счёт и учат вас, как взаимодействовать с людьми, основываясь только на своих выводах.
Является ли это правдой? Чему можно верить? Есть ли какие-то исследования и цифры, подтверждающие/опровергающие данные умозаключения?

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

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

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

У нас в компании в единый момент времени в работе около 30-ти проектов на разных стадиях, и я расскажу через призму нашего опыта, как мы научились системно управлять рисками на разных уровнях. Покажу часть нашей системы по управлению рисками и расскажу, как она помогла нам снизить процент просроченных проектов с 31% до 7% в 2019 году.
Я расскажу только про практику, никакой теории, которую можно прочитать в интернете, у меня не будет. Только кейсы, только хардкор!

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

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

В Level.Travel для решения этих проблем мы выбрали метод геймификации, создав собственную вселенную “Левелизации”, которая регламентирует весь процесс производства фич — от проработки концепции до заведения багов. Уже год мы живём в режиме социального эксперимента в жанре исторического фэнтези, в который вовлечено несколько десятков разработчиков, и готовы поделиться результатами.

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

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

Разработка программ проклята. Проклятье называется «нулевая цена копирования» и заставляет нас раз за разом решать новые задачи и оценивать сроки по «чуйке» опытных разработчиков. Десять лет мы в Evrone учились работать с полностью удаленной командой, проводили эксперименты и выстраивали процессы. Этот доклад – рассказ о том, что у нас получилось и что вы можете использовать в своей практике. Для каждого из ключевых вопросов руководителя разработки я покажу, как мы быстро получаем ответы с помощью промежуточных цифровых следов, используя разнообразные инструменты и подходы: начиная от традиционных JIRA с видеозвонками и заканчивая нашей собственной ERP.

Доклад опирается на следующий тезис: профессиональное развитие — важнейший мотиватор в работе.

Если вы согласны с этим тезисом, то приглашаю обсудить на докладе такой инструмент управления, как personal development plan, он же — индивидуальный план развития (ИПР). Я расскажу про его цель, структуру и прилагаемый процесс реализации и контроля.

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

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

Мы в PropellerAds пошли кардинально другим путем — у нас НЕТ тимлидов. Как говорят, "нет человека — нет проблемы".

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

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

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

Я очень часто слышу, что "оценивать задачи от 15 минут до 2 часов" сложно, ненужно и вообще невозможно.
И как же я устал!

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

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

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

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

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

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

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

Обо всем этом и будет доклад в виде пошагового рецепта QA-лидам, fullstack feature team-лидам, SM и всем тем, кто решает задачу эффективной настройки процессов команд, работающих совместно над одним продуктом.

Как всё работает во "Вкусвилле":
- автономность команд,
- самостоятельность, вовлечённость и осознанность сотрудников,
- непривычный подход к управлению,
- система обещаний,
- мировоззрение, основанное на доверии,
- ответственность за результат,
- вдохновляющие примеры из жизни компании.

ManyChat – компания, которая за 4 года выросла с 6 до 100 человек и прошла несколько этапов развития. За это время мы успели поработать в функциональных командах по SCRUM, поделились на кросс-функциональные, внедрили методологию LeSS и переросли её.

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

В докладе я расскажу, какую роль играет Definition of Done в работе команд, как OKRs помогают в достижении целей и на каких этапах роста внедрение LeSS наиболее эффективно.

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

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

- Стили принятия решений.
- Динамика принятия совместных решений в командах.

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

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

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

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

Речь не о волшебной таблетке, а о практиках, которые чаще срабатывают, чем нет.

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

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

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

Планирование. Как много в этом слове для сердца тимлида слилось!

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

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

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

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

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

В разговоре со многими руководителями и HR'ами зачастую проскальзывает мысль, что всем сотрудникам безусловно нужно развивать soft skills, то есть различные нетехнические навыки. Сами сотрудники, особенно инженеры, не всегда в этом уверены :), но логика в этом есть. Реальность, однако, состоит в том, что по работе приходится довольно часто и много общаться с коллегами — отечественными и зарубежными, руководством, заказчиком. И это все приводит к большому количеству сложных коммуникационных задач и проблем, которые люди пытаются решать. Получается не всегда хорошо, легко и безболезненно.
Люди делают не то, что от них ожидаешь, не так и не тогда. Понимают задачи по-своему, недостаточно ответственно относятся к срокам, проявляют непонимание, когда все на 100% ясно и т.д.

В рамках мастер-класса мы разберем, как можно непонятные soft skills разложить в понятные системы и схемы, которые а) работают и б) легко воспроизводятся при попытке объяснить коллегам. В основе мастер-класса лежит схема конструктивной конфронтации, предложенная Энди Гроувом, одним из основателей компании Intel, и существенно доработанная создателями Школы менеджеров Стратоплан.

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

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

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

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

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

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

Для каких ситуаций.
Когда вам как тимлиду нужно, чтобы каждый член вашей команды включил голову и сердце на 100%.

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

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

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