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

Итак, по доброй традиции у нас будет 6 основных направлений нанесения пользы. Ниже их «говорящие» названия:

  • Личное развитие. 
  • Работа с командой. 
  • Инструментарий тимлида.
  • Развитие осознанности.
  • Трансформационные изменения в процессах и людях.
  • Выстраивание технологического процесса. 

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



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

Итак, о каких инструментах мы будем говорить в Питере в этот раз.

Рецепты классного тимлида: инструменты, подходы, практики

Дмитрий Ли из Badoo


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

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

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

Как мы создавали карту развития для разработчиков

Сергей Черепанов из FSD


Я почти уверен, что многие пробовали строить индивидуальные карты развития, строить планы обучения, планы «прокачки». В своём рассказе Сергей Черепанов поделится реальным опытом создания и внедрения карты развития, которая кроме всего прочего является инструментом, помогающим заботиться о разработчиках. История от начала и до сего дня:

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

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

Правильная обратная связь как инструмент тимлида

Руслан Остропольский из DocDoc


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

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

Сказка про репку, или Как рождаются правильные задачи

Антон Костерин из Тинькофф


Лично я считаю, что правильно поставленная задача — это две трети от общего результата. Кто из вас не сталкивался с задачами-тостами, задачами, которые состоят из одного заголовка и пары общих фраз? Сколько сил и времени потрачено на переделку того, что было сделано неверно из-за плохой формулировки? Вот про это и поговорим вместе с Антоном Костериным из Тинькофф-банка. Поищем ответы на следующие вопросы:

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

Ну и в тему секции посмотрим на инструментарий по работе с задачами: валидацию, техническую декомпозицию, линковку задач, оценку трудозатрат и технических рисков, приоритизацию.

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

Пробуем (на людях) экономику, психологию и теорию игр

Игорь Луканин из СКБ Контур


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

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

В инженерном подразделении Контура работает 1200 человек. Это примерно 90 команд, распределённых по 9 городам, или работающих удалённо. Игорь Луканин в своём докладе расскажет о том, как предлагать людям и командам «правила игры», которые выгодны для них и решают ваши задачи. На самом деле, есть множество случаев, когда достаточно правильно задать правила игры, а затем со временем сработает теория игр и люди (команды), преследуя собственные интересы и добиваясь собственной выгоды, поступят так, как нужно вам. Звучит заманчиво?

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

Частотная диаграмма в Канбан. Как отвечать на вопрос «Когда?»

Артём Расскосов из SkyEng


Про Канбан в этот раз будет два доклада. Первый от Алексея Пименова про сам метод, о нём я напишу чуть позже, и рассказ Артёма Расскосова о поиске ответа на извечный вопрос менеджеров «Когда».

На подобные вопросы Артём с коллегами честно описывали техническое решение задачи и выставляли оценку, но это не спасало. Задачи, оцененные в 2 дня, попадали на продакшн через 4. Проблема в том, что ребята оценивали время разработки, и это было не то, что нужно заказчику.

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

Инструменты управления рисками в продуктовом бэклоге

Александр Лебедев из Новых облачных технологий


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

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

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

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

Лично мой опыт говорит, что «последняя миля» — это самый напряжённый участок с точки зрения рисков и сложности планирования.

Знания и компетенции в команде: найти, увидеть, прокачать

Алексей Трошин из ФИНАМ


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

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

Как общаться по e-mail и эффективно работать с почтой

Евгений Рыжков из PVS-Studio


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

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

Евгений Рыжков понял, что его коллеги не умеют общаться по электронной почте, и выступил на внутренней конференции с докладом о том, как правильно это делать. Хотя большая часть была на его взгляд «и так понятно», большинство коллег узнало много нового. Но что важнее — постепенно общение по почте в PVS-Studio стало налаживаться, понимание с внешним миром сильно выросло.

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

«Мы посовещались, и я решил». Как принимать решения командой

Леонид Савченков из Яндекса


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

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

Приходите на этот доклад, если:

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

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

Не твоя — вот ты и бесишься! Управляем не своими подчиненными

Игорь Катыков из Тинькофф


Тема про все те же стороны менеджмента — постановку задач и делегирование, контроль, мотивацию — но с позиции, когда ты как бы не совсем начальник сотрудника. То есть либо это вообще сотрудник из другой команды, либо твои менеджерские полномочия размыты, как во всяком «аджайле и бирюзе». А ведь такое встречается всё чаще и чаще. Часто приходится «занимать» рабочую силу, ещё чаще просить кого-то помочь. А что если ваша задача была направлена в другую команду, где свои приоритеты и правила игры?

Игорь Катыков поделится опытом:

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

Мы постарались собрать рассказы на разные темы и сделать картинку с инструментами наиболее полной. Смотрите на своё окружение, свои задачи и трудности, подбирайте инструменты и приходите слушать о них на Saint TeamLead Conf 23 и 24 сентября в Питере.

Комментарии (5)


  1. vasyan
    19.08.2019 19:26

    Жили раньше без тимлидов и горя не знали. Были девелоперы, которые код писали, были проджект-менеджеры, которые таски создавали и приоритетами ведали, они же за косяки отвечали перед вышестоящим менеджементом. Теперь наплодили сущностей: тимлид, техлид, продакт, проджект. Теперь полномочия размыты до ужаса, каждый синьор себя тимлидом считает и указывает остальным, что делать, но при этом ни разу не отвечает за косяки. Менеджеры удалились в планирование непонятно чего и совершенно потеряли связь с «землёй». Разницу между тимлидом и техлидом не могут пояснить даже самые прожженные HR, а уж тем более не могут объяснить, где кончаются задачи тимлида и начинаются задачи HR.

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


    1. lotse8
      20.08.2019 09:47

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


    1. argisht123
      20.08.2019 11:13

      Есть такая маза.


    1. Gargonde
      20.08.2019 11:13

      Я думаю, что все как-то так строится:
      PM project manager — общается с заказчиком и его цель что бы заказчик был доволен и исполнителю хватило имеющихся ресурсов
      TeamLead — распределяет задачи от PM по команде. Цель выполнить задачи в срок. И эта задача порождает проблему «где кончаются задачи тимлида и начинаются задачи HR.» Потому что TeamLead нужно что бы команда была довольна.
      TechLead — для меня новая сущность, но по сути, я начал встречать случаи, когда архитектор знает как построит систему, но не в курсе всех новых технологии, что может значительно повлияет на процесс. А вот вроде как TechLead — шарит в технологиях и может направить команду на путь истинный
      ProductManger — это кто??

      Хотелось узнать версии и предположения других людей


      1. vasyan
        20.08.2019 11:29

        Ну вот, например, про продуктов и проджектов
        habr.com/ru/company/hygger/blog/352880
        Вот про техлидов
        habr.com/ru/post/270259