company_banner

Инструментарий тимлида от e-mail до канбан-доски

    В этот раз на 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 сентября в Питере.
    • +27
    • 8,2k
    • 5
    Конференции Олега Бунина (Онтико)
    689,81
    Конференции Олега Бунина
    Поделиться публикацией

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

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

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

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

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

        Самое читаемое