В этот раз на TeamLead Conf мы решили собрать докладов на целый поток больше. В сентябре в Питере впервые будет три параллельных трека докладов для тимлидов и про тимлидов. С одной стороны это связано с тем, что мы растём и развиваемся, с другой стороны — тематика конференции нам это позволяет, а разнообразие направлений работы и развития тимлида рекомендуют как можно более широко и глубоко освещать эту деятельность.
Итак, по доброй традиции у нас будет 6 основных направлений нанесения пользы. Ниже их «говорящие» названия:
Сегодня поговорим об инструментарии тимлида. В эту секцию традиционно попадают доклады, которые так или иначе связаны с систематизацией, алгоритмизацией и автоматизацией различных обязанностей тимлида, начиная от учёта и постановки задач и заканчивая картами развития, чеклистами, программами фасилитации встреч и т.д. и т.п. В общем всё, что так или иначе помогает тимлиду в работе.
Инструментарию тимлида в этот раз будет посвящено больше десяти докладов. С моей точки зрения это вполне соответствует положению дел в индустрии. Поскольку лиды в большинстве своём инженеры, то методы решения даже не инженерных задач у них всё равно близки к инженерным.
Итак, о каких инструментах мы будем говорить в Питере в этот раз.
Уверен, многие из вас читали и продолжают читать книги об управлении, ходить на конференции, соглашаться (а чаще не соглашаться:)) с советами спикеров и кивать головами на докладах. Но почему-то на практике этими советами мало кто пользуется.
Часто это происходит, потому что со сцены нам говорят, в чем развиваться и каким нужно быть, но что именно делать и какие действия предпринять — понятно далеко не всегда. Нужна конкретика!
Дмитрий Ли покажет реальные практики, полученные опытным путем, и даст рецепт, который поможет взглянуть на привычные процессы и подходы со стороны. В программе беседы: прозрачность в целях, порядок в работе с повседневными задачами, собственный рост и развитие членов команды, формы эффективного общения.
Я почти уверен, что многие пробовали строить индивидуальные карты развития, строить планы обучения, планы «прокачки». В своём рассказе Сергей Черепанов поделится реальным опытом создания и внедрения карты развития, которая кроме всего прочего является инструментом, помогающим заботиться о разработчиках. История от начала и до сего дня:
И многое другое из реального опыта использования этого инструмента.
Обратная связь, пожалуй, — лучший инструмент в работе с сотрудниками. К сожалению, не все им успешно пользуются, не умеют или не понимают как, зачем. Скажете, что уже говорили про это и не раз? Всё так, но тема настолько специфическая и часто уникальная для конкретных команд, руководителей и сотрудников, что мы посчитали её достойной быть поднятой ещё раз.
В докладе Руслан Остропольский поделится своей точкой зрения на то, что считать эффективной обратной связью, как её давать, в каком виде и когда. А главное, какие ошибки можно встретить при работе с этим инструментом и как их избежать.
Лично я считаю, что правильно поставленная задача — это две трети от общего результата. Кто из вас не сталкивался с задачами-тостами, задачами, которые состоят из одного заголовка и пары общих фраз? Сколько сил и времени потрачено на переделку того, что было сделано неверно из-за плохой формулировки? Вот про это и поговорим вместе с Антоном Костериным из Тинькофф-банка. Поищем ответы на следующие вопросы:
Ну и в тему секции посмотрим на инструментарий по работе с задачами: валидацию, техническую декомпозицию, линковку задач, оценку трудозатрат и технических рисков, приоритизацию.
Все мы в разной степени привыкаем работать в IT-компаниях с сильной инженерной культурой, плоской иерархией, сформулированными ценностями, самоорганизацией инженеров внутри команд и суверенитетом команд внутри инженерного подразделения. Посмотрите вокруг себя и выберите любые пункты по вкусу.
Но как влиять на суверенные команды и людей, которые тебе не подчиняются? Помогут законы экономики, элементы социальной психологии и равновесие Нэша — одно из ключевых понятий в теории игр.
В инженерном подразделении Контура работает 1200 человек. Это примерно 90 команд, распределённых по 9 городам, или работающих удалённо. Игорь Луканин в своём докладе расскажет о том, как предлагать людям и командам «правила игры», которые выгодны для них и решают ваши задачи. На самом деле, есть множество случаев, когда достаточно правильно задать правила игры, а затем со временем сработает теория игр и люди (команды), преследуя собственные интересы и добиваясь собственной выгоды, поступят так, как нужно вам. Звучит заманчиво?
Вместе посмотрим на примерах, как это работает в Контуре: как получилось упростить найм с помощью свободного рынка труда внутри компании и пофиксить все уязвимости безопасности с помощью социального давления.
Про Канбан в этот раз будет два доклада. Первый от Алексея Пименова про сам метод, о нём я напишу чуть позже, и рассказ Артёма Расскосова о поиске ответа на извечный вопрос менеджеров «Когда».
На подобные вопросы Артём с коллегами честно описывали техническое решение задачи и выставляли оценку, но это не спасало. Задачи, оцененные в 2 дня, попадали на продакшн через 4. Проблема в том, что ребята оценивали время разработки, и это было не то, что нужно заказчику.
В итоге Артём с командой проделали длинный путь, прежде чем нашли хорошее решение, которое устроило и заказчиков и разработку. Именно об этом решении и будет рассказ: что пробовали, почему это не давало нужных результатов, с какими проблемами сталкивались. Рассмотрим частотную диаграмму и как, используя этот инструмент, можно заменить оценку задач на соглашение об уровне обслуживания.
Руководство по SCRUM говорит нам, что за бэклог отвечает Владелец продукта. Тем не менее, у тимлида есть уникальные знания по проекту. И инструменты, с помощью которых он может влиять на содержимое бэклога.
При правильном подходе, и имея нужные инструменты, в силах тимлида сделать так, чтобы:
В своём докладе Александр Лебедев расскажет про практики работы с продуктовым бэклогом со стороны тимлида на основе личного опыта. Поговорим о том, как снижать риски по входящим от бизнеса запросам, и об особенностях жизни замыкающей команды в длинной цепочке.
Наверняка, многие и вас сталкивались с вопросами: а что же моя команда знает и умеет, какие есть знания и в чьих головах они сосредоточены, как грамотно показать точки роста или объяснить принимаемые решения по распределению работ и задач.
Однажды Алексей Трошин столкнулся с этими вопросами и в процессе поиска ответов нашёл подход, ставший простым инструментом. С ним видны узкие места в документировании продуктов и в областях знаний членов команды. С ним есть возможность принимать правильные решения в наполнении пустот и развитии недостающих компетенций. Алексей расскажет, как пришёл к этому решению и покажет, как им можно пользоваться, и какие задачи можно с его помощью решать.
В век чатиков и мессенджеров электронная почта, казалось бы, должна была потерять свои позиции. Но, к счастью, этого не произошло и вряд ли произойдёт. Все сложные и ответственные решения и поручения по-прежнему ходят через электронную почту. Даже в среде, далёкой от enterprise.
Общение в почте радикально отличается от общения в мессенджерах, и далеко не все умеют переключаться с чатиков на почту, писать правильные и понятные письма. И здесь речь идёт как про понимание самих правил написания писем, так и про технические аспекты.
Евгений Рыжков понял, что его коллеги не умеют общаться по электронной почте, и выступил на внутренней конференции с докладом о том, как правильно это делать. Хотя большая часть была на его взгляд «и так понятно», большинство коллег узнало много нового. Но что важнее — постепенно общение по почте в PVS-Studio стало налаживаться, понимание с внешним миром сильно выросло.
Даже если вы умеете общаться по почте, то приходите на доклад, чтобы узнать, о чем обязательно стоит рассказать вашим коллегам, чтобы избежать всех тех проблем, которые преодолел Евгений и его команда.
Извечная проблема почти во всех командах — принятие решений. Консенсус не всегда возможен, голосование часто не работает, часто случаются споры и недопонимание, что приводит к единоличному принятию решения лидером. Иногда это оправдано, но чаще всего нет.
Леонид Савченокв расскажет о практиках проведения встреч, которые помогают принимать решения командой, так, чтобы его разделяли все члены команды, и оно содержало в себе вклад каждого участника.
Приходите на этот доклад, если:
Узнаем от Леонида несколько простых и понятных практик фасилитации, позволяющих решать эти проблемы. Расширим инструментарий себя как ведущего встреч, собраний и церемоний.
Тема про все те же стороны менеджмента — постановку задач и делегирование, контроль, мотивацию — но с позиции, когда ты как бы не совсем начальник сотрудника. То есть либо это вообще сотрудник из другой команды, либо твои менеджерские полномочия размыты, как во всяком «аджайле и бирюзе». А ведь такое встречается всё чаще и чаще. Часто приходится «занимать» рабочую силу, ещё чаще просить кого-то помочь. А что если ваша задача была направлена в другую команду, где свои приоритеты и правила игры?
Игорь Катыков поделится опытом:
Итак, по доброй традиции у нас будет 6 основных направлений нанесения пользы. Ниже их «говорящие» названия:
- Личное развитие.
- Работа с командой.
- Инструментарий тимлида.
- Развитие осознанности.
- Трансформационные изменения в процессах и людях.
- Выстраивание технологического процесса.
Сегодня поговорим об инструментарии тимлида. В эту секцию традиционно попадают доклады, которые так или иначе связаны с систематизацией, алгоритмизацией и автоматизацией различных обязанностей тимлида, начиная от учёта и постановки задач и заканчивая картами развития, чеклистами, программами фасилитации встреч и т.д. и т.п. В общем всё, что так или иначе помогает тимлиду в работе.
Инструментарию тимлида в этот раз будет посвящено больше десяти докладов. С моей точки зрения это вполне соответствует положению дел в индустрии. Поскольку лиды в большинстве своём инженеры, то методы решения даже не инженерных задач у них всё равно близки к инженерным.
Итак, о каких инструментах мы будем говорить в Питере в этот раз.
Рецепты классного тимлида: инструменты, подходы, практики
Дмитрий Ли из Badoo
Уверен, многие из вас читали и продолжают читать книги об управлении, ходить на конференции, соглашаться (а чаще не соглашаться:)) с советами спикеров и кивать головами на докладах. Но почему-то на практике этими советами мало кто пользуется.
Часто это происходит, потому что со сцены нам говорят, в чем развиваться и каким нужно быть, но что именно делать и какие действия предпринять — понятно далеко не всегда. Нужна конкретика!
Дмитрий Ли покажет реальные практики, полученные опытным путем, и даст рецепт, который поможет взглянуть на привычные процессы и подходы со стороны. В программе беседы: прозрачность в целях, порядок в работе с повседневными задачами, собственный рост и развитие членов команды, формы эффективного общения.
Как мы создавали карту развития для разработчиков
Сергей Черепанов из FSD
Я почти уверен, что многие пробовали строить индивидуальные карты развития, строить планы обучения, планы «прокачки». В своём рассказе Сергей Черепанов поделится реальным опытом создания и внедрения карты развития, которая кроме всего прочего является инструментом, помогающим заботиться о разработчиках. История от начала и до сего дня:
- Как ребята внедряли карты развития для фронтендеров.
- Как при помощи карты помогают перейти от джуна к мидлу и выше.
- Как такие карты помогли всей команде перейти к более эффективной совместной работе.
- Как проводятся интервью участников внутри команды для валидации и закрепления знаний.
И многое другое из реального опыта использования этого инструмента.
Правильная обратная связь как инструмент тимлида
Руслан Остропольский из DocDoc
Обратная связь, пожалуй, — лучший инструмент в работе с сотрудниками. К сожалению, не все им успешно пользуются, не умеют или не понимают как, зачем. Скажете, что уже говорили про это и не раз? Всё так, но тема настолько специфическая и часто уникальная для конкретных команд, руководителей и сотрудников, что мы посчитали её достойной быть поднятой ещё раз.
В докладе Руслан Остропольский поделится своей точкой зрения на то, что считать эффективной обратной связью, как её давать, в каком виде и когда. А главное, какие ошибки можно встретить при работе с этим инструментом и как их избежать.
Сказка про репку, или Как рождаются правильные задачи
Антон Костерин из Тинькофф
Лично я считаю, что правильно поставленная задача — это две трети от общего результата. Кто из вас не сталкивался с задачами-тостами, задачами, которые состоят из одного заголовка и пары общих фраз? Сколько сил и времени потрачено на переделку того, что было сделано неверно из-за плохой формулировки? Вот про это и поговорим вместе с Антоном Костериным из Тинькофф-банка. Поищем ответы на следующие вопросы:
- Как должны появляться задачи, отвечающие интересам заказчика — цепочка от глобальной цели компании до постановки задачи с разбиением на слои. Зоны ответственности и выделение порождаемых артефактов.
- Какие проблемы и боли тимлида и команды разработки случаются из-за плохих, неправильных, неполных постановок задач.
- Каковы критерии корректно поставленной задачи, состав минимально необходимой постановки для достижения успешного результата.
Ну и в тему секции посмотрим на инструментарий по работе с задачами: валидацию, техническую декомпозицию, линковку задач, оценку трудозатрат и технических рисков, приоритизацию.
От себя хочу добавить, что корректная и правильно поставленная задача мотивирует на её решение, и мощно демотивирует в обратном случае.
Пробуем (на людях) экономику, психологию и теорию игр
Игорь Луканин из СКБ Контур
Все мы в разной степени привыкаем работать в IT-компаниях с сильной инженерной культурой, плоской иерархией, сформулированными ценностями, самоорганизацией инженеров внутри команд и суверенитетом команд внутри инженерного подразделения. Посмотрите вокруг себя и выберите любые пункты по вкусу.
Но как влиять на суверенные команды и людей, которые тебе не подчиняются? Помогут законы экономики, элементы социальной психологии и равновесие Нэша — одно из ключевых понятий в теории игр.
В инженерном подразделении Контура работает 1200 человек. Это примерно 90 команд, распределённых по 9 городам, или работающих удалённо. Игорь Луканин в своём докладе расскажет о том, как предлагать людям и командам «правила игры», которые выгодны для них и решают ваши задачи. На самом деле, есть множество случаев, когда достаточно правильно задать правила игры, а затем со временем сработает теория игр и люди (команды), преследуя собственные интересы и добиваясь собственной выгоды, поступят так, как нужно вам. Звучит заманчиво?
Вместе посмотрим на примерах, как это работает в Контуре: как получилось упростить найм с помощью свободного рынка труда внутри компании и пофиксить все уязвимости безопасности с помощью социального давления.
Частотная диаграмма в Канбан. Как отвечать на вопрос «Когда?»
Артём Расскосов из SkyEng
Про Канбан в этот раз будет два доклада. Первый от Алексея Пименова про сам метод, о нём я напишу чуть позже, и рассказ Артёма Расскосова о поиске ответа на извечный вопрос менеджеров «Когда».
На подобные вопросы Артём с коллегами честно описывали техническое решение задачи и выставляли оценку, но это не спасало. Задачи, оцененные в 2 дня, попадали на продакшн через 4. Проблема в том, что ребята оценивали время разработки, и это было не то, что нужно заказчику.
В итоге Артём с командой проделали длинный путь, прежде чем нашли хорошее решение, которое устроило и заказчиков и разработку. Именно об этом решении и будет рассказ: что пробовали, почему это не давало нужных результатов, с какими проблемами сталкивались. Рассмотрим частотную диаграмму и как, используя этот инструмент, можно заменить оценку задач на соглашение об уровне обслуживания.
Инструменты управления рисками в продуктовом бэклоге
Александр Лебедев из Новых облачных технологий
Руководство по SCRUM говорит нам, что за бэклог отвечает Владелец продукта. Тем не менее, у тимлида есть уникальные знания по проекту. И инструменты, с помощью которых он может влиять на содержимое бэклога.
При правильном подходе, и имея нужные инструменты, в силах тимлида сделать так, чтобы:
- входящие задачи были проработанными и их было просто спланировать (вы же помните про репку и правильно поставленные задачи? — и снова возвращаемся к этой важной теме);
- негодные задачи исчезали на подходах, до того, как команда их даже увидит;
- вероятность трудовых подвигов во имя внезапного дедлайна оставалась минимальной.
В своём докладе Александр Лебедев расскажет про практики работы с продуктовым бэклогом со стороны тимлида на основе личного опыта. Поговорим о том, как снижать риски по входящим от бизнеса запросам, и об особенностях жизни замыкающей команды в длинной цепочке.
Лично мой опыт говорит, что «последняя миля» — это самый напряжённый участок с точки зрения рисков и сложности планирования.
Знания и компетенции в команде: найти, увидеть, прокачать
Алексей Трошин из ФИНАМ
Наверняка, многие и вас сталкивались с вопросами: а что же моя команда знает и умеет, какие есть знания и в чьих головах они сосредоточены, как грамотно показать точки роста или объяснить принимаемые решения по распределению работ и задач.
Однажды Алексей Трошин столкнулся с этими вопросами и в процессе поиска ответов нашёл подход, ставший простым инструментом. С ним видны узкие места в документировании продуктов и в областях знаний членов команды. С ним есть возможность принимать правильные решения в наполнении пустот и развитии недостающих компетенций. Алексей расскажет, как пришёл к этому решению и покажет, как им можно пользоваться, и какие задачи можно с его помощью решать.
Как общаться по e-mail и эффективно работать с почтой
Евгений Рыжков из PVS-Studio
В век чатиков и мессенджеров электронная почта, казалось бы, должна была потерять свои позиции. Но, к счастью, этого не произошло и вряд ли произойдёт. Все сложные и ответственные решения и поручения по-прежнему ходят через электронную почту. Даже в среде, далёкой от enterprise.
Общение в почте радикально отличается от общения в мессенджерах, и далеко не все умеют переключаться с чатиков на почту, писать правильные и понятные письма. И здесь речь идёт как про понимание самих правил написания писем, так и про технические аспекты.
Евгений Рыжков понял, что его коллеги не умеют общаться по электронной почте, и выступил на внутренней конференции с докладом о том, как правильно это делать. Хотя большая часть была на его взгляд «и так понятно», большинство коллег узнало много нового. Но что важнее — постепенно общение по почте в PVS-Studio стало налаживаться, понимание с внешним миром сильно выросло.
Даже если вы умеете общаться по почте, то приходите на доклад, чтобы узнать, о чем обязательно стоит рассказать вашим коллегам, чтобы избежать всех тех проблем, которые преодолел Евгений и его команда.
«Мы посовещались, и я решил». Как принимать решения командой
Леонид Савченков из Яндекса
Извечная проблема почти во всех командах — принятие решений. Консенсус не всегда возможен, голосование часто не работает, часто случаются споры и недопонимание, что приводит к единоличному принятию решения лидером. Иногда это оправдано, но чаще всего нет.
Леонид Савченокв расскажет о практиках проведения встреч, которые помогают принимать решения командой, так, чтобы его разделяли все члены команды, и оно содержало в себе вклад каждого участника.
Приходите на этот доклад, если:
- вас не устраивает пассивность вашей команды во время принятия ключевых решений;
- вы хотите, чтобы никто не тупил в телефон или ноутбук во время командных встреч;
- вы сталкиваетесь с ситуацией вроде «а я говорил, что это работать не будет, но меня не послушали».
Узнаем от Леонида несколько простых и понятных практик фасилитации, позволяющих решать эти проблемы. Расширим инструментарий себя как ведущего встреч, собраний и церемоний.
Не твоя — вот ты и бесишься! Управляем не своими подчиненными
Игорь Катыков из Тинькофф
Тема про все те же стороны менеджмента — постановку задач и делегирование, контроль, мотивацию — но с позиции, когда ты как бы не совсем начальник сотрудника. То есть либо это вообще сотрудник из другой команды, либо твои менеджерские полномочия размыты, как во всяком «аджайле и бирюзе». А ведь такое встречается всё чаще и чаще. Часто приходится «занимать» рабочую силу, ещё чаще просить кого-то помочь. А что если ваша задача была направлена в другую команду, где свои приоритеты и правила игры?
Игорь Катыков поделится опытом:
- Как получать добро других руководителей на подключение не своих сотрудников.
- Как добыть от сотрудника результат, а не отписку «мне некогда было заниматься твоим, это же второстепенно».
- Как получить довольного сотрудника, который и позже будет рад тебе помочь.
Мы постарались собрать рассказы на разные темы и сделать картинку с инструментами наиболее полной. Смотрите на своё окружение, свои задачи и трудности, подбирайте инструменты и приходите слушать о них на Saint TeamLead Conf 23 и 24 сентября в Питере.
vasyan
Жили раньше без тимлидов и горя не знали. Были девелоперы, которые код писали, были проджект-менеджеры, которые таски создавали и приоритетами ведали, они же за косяки отвечали перед вышестоящим менеджементом. Теперь наплодили сущностей: тимлид, техлид, продакт, проджект. Теперь полномочия размыты до ужаса, каждый синьор себя тимлидом считает и указывает остальным, что делать, но при этом ни разу не отвечает за косяки. Менеджеры удалились в планирование непонятно чего и совершенно потеряли связь с «землёй». Разницу между тимлидом и техлидом не могут пояснить даже самые прожженные HR, а уж тем более не могут объяснить, где кончаются задачи тимлида и начинаются задачи HR.
Я понимаю стремление бизнеса сделать фулстек-тимлида, который будет и аналитиком и мендежром и UI и Back, но что-то в, итоге, получается хаос ответственности.
lotse8
Все идет согласно первому закону Паркинсона:
— чиновник стремится множить подчинённых, а не соперников;
— чиновники создают друг другу работу.
argisht123
Есть такая маза.
Gargonde
Я думаю, что все как-то так строится:
PM project manager — общается с заказчиком и его цель что бы заказчик был доволен и исполнителю хватило имеющихся ресурсов
TeamLead — распределяет задачи от PM по команде. Цель выполнить задачи в срок. И эта задача порождает проблему «где кончаются задачи тимлида и начинаются задачи HR.» Потому что TeamLead нужно что бы команда была довольна.
TechLead — для меня новая сущность, но по сути, я начал встречать случаи, когда архитектор знает как построит систему, но не в курсе всех новых технологии, что может значительно повлияет на процесс. А вот вроде как TechLead — шарит в технологиях и может направить команду на путь истинный
ProductManger — это кто??
Хотелось узнать версии и предположения других людей
vasyan
Ну вот, например, про продуктов и проджектов
habr.com/ru/company/hygger/blog/352880
Вот про техлидов
habr.com/ru/post/270259