Знакомьтесь, это Дима. Он тимлид и отвечает за техдолг и код-ревью, за планирование и технические процессы, за выполнение разработчиками задач в срок — мотивирует, нанимает и, если надо, увольняет. Дима хочет работать только над важными задачами, но работает над миллионом самых разных, постоянно думает о работе и не высыпается. У него все горит: сроки, задачи, время и самооценка. Дима в аду.
Знакомая ситуация? Для Алексея Катаева (deusdeorum) — точно. Алексей больше 15 лет занимается веб-разработкой как backend, frontend, fullstack-разработчик и тимлид. Сейчас Алексей работает в Skyeng и как-то раз ему удалось сделать из команды суперкоманду — лучшую в компании. И с тех пор Алексей занимается тем, что создает в Skyeng суперкоманды на постоянной основе. Как он это делает, в расшифровке доклада, который участники TeamLead Conf 2019 назвали лучшим на конференции.
Рекомендуем посмотреть видео, если есть время, — Алексей заряжает энтузиазмом к переменам. А статья лучше подходит, чтобы просмотреть основные тезисы задуматься о чем-то, что раньше всегда ускользало.
С Димой вы уже знакомы. Раньше он был хорошим разработчиком — брал каждый день по 3 задачи и делал их до конца — это ведь самое главное. Зеленая плашка рядом с Димой — это индикатор ада в его жизни.
Что дальше происходит с Димой? Если вы считаете, что он становится тимлидом и ада становится чуть больше, то вы угадали. К Диме приходит продакт и говорит: «Пойдем планировать Q2! Когда будет задача 1653? У нас скоро релиз!» И ада становится чуть больше.
А потом приходит CTO: «Нам нужно нанять еще одного разработчика. Что у тебя с техническим долгом? И вот еще опросник в Google Doc — заполни его, пожалуйста!» И ада стало еще больше.
Потом пришли разработчики: «Мы хотим расти! Увеличь нам зарплату!» И Дима начинает гореть.
Все приводит к тому, что Дима не высыпается. С утра он идет в душ и думает о разработчике и продакте, и о том, что и кому он наобещал. Задачи теряются — либо Дима о них забыл, либо они где-то далеко в бэклоге и не будут выполнены никогда.
Локально это может привести к плохим последствиям, когда Дима скажет: «Всё! Я больше не буду тимлидом! Я просто хочу делать свои задачки, отстаньте от меня!» Или сорвет задачу, потому что их много, а Дима один — трудно держать фокус на всем. В итоге мы потеряем кучу денег или что-нибудь вовремя не зарелизим.
Я расскажу, как убрать ад из жизни и создать суперкоманду. В конце по традиции будут бонусы.
Skyeng — это 17 команд разработки, каждая из которых работает над своим продуктом независимо. Чаще всего в команду, кроме разработчиков, входят, как минимум, продакт и тимлид.
Продакт ставит бизнес-цели — у него есть видение продукта, он отвечает за деньги, которые мы зарабатываем и тратим, и общается со всеми заказчиками и клиентами.
Тимлид, то есть Дима, отвечает за техническую стратегию, технические решения, техдолг — за все техническое. Он — технический лидер. Еще тимлид — это project manager. У нас нет выделенной роли project, поэтому тимлид отвечает за планирование и все процессы: за то, что задачи выполняются нужными разработчиками и не зависают в статусах. Тимлид — лидер и наставник, работает с людьми: нанимает и увольняет, развивает и общается, ведет за собой и мотивирует.
Посмотрим на задачи, которые делает Дима. Я разделяю их на:
В моей классификации важные задачи — это инвестиции с долгой окупаемостью. Это ресурсы, которые мы тратим на команду сейчас, чтобы улучшать её на длинной дистанции. Это задачи руководителя, которые может или должен делать только он. Конечно, Дима хочет делать только важные задачи, а все остальные — нет.
Да, вы сразу подумали, что надо все делегировать и автоматизировать, и наступит счастье. Дима тоже знает, что это надо делать, но почему-то это не работает. Возможно причина в том, что Дима работает 10 часов в день, а на выходных, когда его наконец никто не мучает в Slack, он доделывает важные задачи. На делегирование тоже нужно время — ведь всем нужно долго объяснять, что и как — лучше самому все сделать. Чтобы автоматизировать, тоже нужно время — надо писать какой-то код, а времени не хватает даже на создание репы.
Это путь, который все знают, но никто не делает. Но есть другой путь, похожий, который я прошел.
Сначала нужно найти низко висящие фрукты — очень простые задачи, на которые уходит больше всего времени, но от которых также просто избавиться. Вы знаете эти задачи, а если нет — помогут ворклоги.
Скорее всего, это будет работа с обращениями. По моему опыту, тимлиды тратят много времени, чтобы отвечать на вопросы разработчиков, продактов, CTO, заказчиков — Slack всегда переполнен сообщениями. Сейчас расскажу, как легко избавиться от этого шума.
Когда я пришел в команду биллинга тимлидом, я сразу сказал, что не отвечаю ни на один вопрос. Я создал канал #billing, сказал, что все вопросы туда, и поставил в статусе «Не отвечаю в личке».
В Slack я заменил красную иконку, чтобы моя точка не горела никогда, и назначил дежурных — кто-то же должен отвечать людям в этом канале. Дежурных можно выбрать из числа разработчиков или QA. Я составил для QA график и попросил отмечать нужных разработчиков, если дежурные не может ответить сам. Команде я тоже сказал не смотреть в этот канал — там ад, а мы просто работаем.
Потом я увидел, как пишут обращения люди:
— Ааа!!! Ничего не работает, ничего не платится! Деньги исчезли! Мы все умрем!
Поэтому я написал правила, как писать обращения в саппорт. Потом мы быстро закодили бота, который пишет эти правила при входе в канал.
Кстати, мы не пишем ботов сами. Никто из команды не тратит на это время. На это у нас выделены два человека в компании, а иногда мы заказываем работу у фрилансеров. Это дешево и быстро. Там нет никаких требований к качеству кода — этого бота с правилами мы заказали и получили за пару часов.
Итого: за час я избавился от траты кучи лишнего времени для ответов на вопросы. Да, кто-то обиделся, наверное, но зато можно делать другие дела.
Как еще улучшить это решение?
Раздел FAQ. Попросите дежурных написать ответы на самые популярные вопросы и составить короткую инструкцию, чтобы не тратить время на ответ.
Контроль качества. Посмотрите на крутой саппорт, позаимствуйте идеи. Я сделал контроль качества просто: сказал дежурному писать раз в неделю количество обращений, на сколько вопросов мы ответили, а сколько проблем не решили.
Потом мы интегрировали еще одного бота, который во всех каналах по эмоджи анализирует, обработано ли обращение, и постит такой же дайджест-канал аля SLA по обращениям.
Как я уже говорил, можно отдавать задачи разработчикам, QA, ботам. Но когда нанимаешь крутых спецов в команду, платишь им кучу денег, то неудобно просить их делать ерунду типа переноса документов из одного Google Doc в другой, субтитров, растасовки файлов. И делаешь сам, что еще глупее.
Поэтому в Skyeng есть специальный отдел административных ассистентов. Это внутренний YouDo, но с отличиями.
Мы делегируем ассистентам много задач. Например, классификацию обращений — просмотреть тысячу обращений за год и разбить их по категориям. Мы пишем видео всех наших встреч: daily, meetups, ретроспективы, и кто-то должен расфасовать их по командам и по папкам. Теперь это делают ассистенты, и всегда можно посмотреть любую встречу за любой день.
Потом Дима решил еще оптимизировать свой тайм-менеджмент и прочитал книгу Максима Дорофеева «Джедайские техники». Из книги Дима взял кучу лайфхаков. Он решил в конце каждого дня вести чек-лист: что делал сегодня, что сделал важного и что сделает лучше.
Дима ведет чек-лист и его вроде бы нужно анализировать в конце дня, но не получается. Почему? Потому что во вторник упал прод, Дима всю ночь его чинил, и теперь у него голова не работает.
Здесь все довольно тривиально. Используем автоэскалации — настраиваем специального бота. В Skyeng это OpsGenie, который звонит нам ночью, если сломался прод и заставляет починить. Но ведь мы как раз хотим уйти от этого и не вставать ночью!
Дежурство настроено по эскалации: если разработчик не взял проблему, то бот будет звонить тимлиду. На следующий день тимлид разберется почему разработчик не встал. Но это будет бесполезно, если разработчик через 10 минут, как проснется, сам начнет звонить тимлиду.
Поэтому мы даем доступ всем дежурным ко всем диагностическим инструментам сразу: Kibana, Sentry, New relic, а также root-доступ к серверам, и пишем краткую документацию, как этим пользоваться, где смотреть и что чинить.
Правда, это не работает в команде биллинга — там слишком много денег, но во всех остальных командах присутствует. Мы пишем специальный документ «Panic doc» — что делать, если все сломалось. Когда ночью просыпаешься, все лежит, аллерты сыпятся и вообще не понимаешь, что делать, есть простой Google Doc на одну страницу, где по шагам расписано, как поступать в данной ситуации.
Возвращаясь к чек-листу. Теперь Дима выспался и может анализировать по записям, что он сделал важного за последние дни: 3 июня — ничего, 4 июня — ничего, 5 июня — ничего. Это классическая ситуация, у меня такое часто бывает. Главное, быть честным с собой и не вписывать в чек-лист ерунду, которую делал 5 минут.
Дима смотрит, что вообще он делал сегодня:
Весь день какие-то встречи!
Вы ждете, что я сейчас скажу: «А давай делегируем встречи!» Это решение «в лоб», которое мы рассмотрим на примере технического ревью.
Если Дима скажет: «Макс, ты завтра проводишь техническое ревью», то, скорее всего, оно не получится. Дима два года проводил технические ревью, он прочитал статьи, у него есть куча опыта — было бы странно это терять.
Как я организую технические ревью в команде? Весь свой опыт я постарался формализовать — написал документ, как я провожу технические ревью. Кстати, это мне помогло сформулировать некоторые вещи. Я написал основу, в которой были:
На документ я потратил 40 минут. Мой лайфхак, как быстро писать документы: накидал основу, показал всем тимлидам в компании и получил кучу комментариев. В результате в этой инструкции мы объединили опыт всего Skyeng, потому что было много интересных предложений.
Что дальше? Нельзя просто кинуть, как банкой тушенки, в человека этим документом: «Проводи техническое ревью по этому алгоритму!» Так не работает. Я спросил, кто хочет проводить техническое ревью — оказалось, вся команда! Мы сделали расписание и начали проводить ревью по очереди.
Здесь важно не исключать себя из процесса, потому что невозможно хорошо сделать то, что ты сам не делаешь идеально. Тимлид должен быть включен, смотреть, как все происходит и прокачивать себя тоже.
Я видел эту ошибку много раз, если ты сам не принимаешь участия и не делаешь на 10 из 10, то получится плохо.
Мы стали проводить техническое ревью по очереди и собирать обратную связь: после каждой встречи каждому участнику приходил опросник, где он оценивал и процесс встречи, и ведущего по категориям «интересно», «конструктивно», «все мнения услышаны» и «свободный фидбэк».
Последний пункт самый важный. Там были интересные и смешные вещи: «Не могу сходу придумать, куда улучшать. Бесят орущие дети, но они всегда бесят» — специфика удаленной команды. Но были и полезные предложения: «Перед записью решения стоит всех заставить замолчать и еще раз озвучить выводы».
Мы провели несколько раундов по кругу, улучшаясь и улучшаясь, пока стало некуда улучшаться. Алгоритм тоже меняли в процессе. После этого выбрали тех, кто проводит технические ревью лучше — ввели роль фасилитатора. Мы также автоматизировали этот процесс и написали бота, который вместо тимлида проводит опрос, формирует расписание технических ревью в нужное время. Сейчас хотим в бэклоге даже часть самой встречи автоматизировать, заменив ведущего на бота.
В результате Дима избавился от необходимости проводить все встречи. Вроде появилось время, но все равно, когда на технических встречах коллеги не могут прийти к общему мнению, они просят Диму подключиться к разговору и помочь разрешить технический конфликт.
Но Дима прочитал хайповую книгу Рэя Далио «Принципы» и решил, что нужно сформулировать технические принципы, которые помогут принимать решение без его участия — формализовать их.
Мы собрались всей командой биллинга, я набросал основу этих принципов, мы долго обсуждали их, голосовали, улучшали. В итоге получился список из 12 принципов. Вот три из двенадцати: что для нас важно — качество кода или скорость разработки, можно ли аутсорсить нашу разработку и думаем ли мы о последствиях?
Ответы команды биллинга показали, что биллинг за все хорошее и против всего плохого: мы всегда за качество, аутсорсить нельзя и думаем о последствиях.
Но есть команды в компании, где ответы на эти вопросы другие. Например, для команды платформы важна скорость — не то, чтобы они пишут плохой код, но важна скорость проверки гипотез. Аутсорсить не только можно, но и нужно — они действительно аутсорсят свой продукт. Последствия тоже важны, как и биллингу, потому что если платформа лежит — финансовые потери огромны.
Но есть десятки других команд, которые не думают о последствиях, и это нормально для их продуктов.
Также мы сформулировали принципы работы и зафиксировали их на бумаге. Юваль Ной Харари в «Homo Deus. Краткая история завтра» писал, что мысли обладают особой магией, когда они записаны, а не просто произнесены. Поэтому мы записали то, что для нас важно.
Например, мы не делаем ничего зря, общаемся культурно и открыто говорим о проблемах и рисках. Это наш самый главный принцип — мы не молчим на встречах.
Когда я подводил итоги, то посчитал среднеквадратичное отклонение по голосованию и вывел самые противоречивые принципы, где мы не приходим к общему мнению.
Слава богу у нас не демократия и работает принцип принятия принципов: «тимлид может выбирать принципы». Поэтому первый пункт вычеркнули, а второй оставили.
Остались только те, в которых приходится участвовать, потому что там рассматриваются действительно сложные или неописанные кейсы. Но тогда и принципы тоже можно дополнить.
Приходит продакт и мучает Диму — от этого-то мы не избавились.
Я фанат Kanban, потому что он как раз позволяет это сделать. На мой взгляд, конвейер выглядит так: есть колонки, мы пушим задачи.
Все уже слышали о боте Арсении. Бот пропушивает задачи из колонки в колонку и каждое утро пишет: «Ты не заревьюил, ты не зарелизил.»
Я увидел, что это работает не всегда, потому что некоторые задачи неделями висят в колонке ожидания. Например: «Жду ответа Алексея из команды инфраструктуры», а Алексей вообще не знает, что задача его ждет. И Арсений тоже не знает, что Алексей не знает.
Поэтому я ввел роль пушера, которую подсмотрел из 2ГИС. Я был у них в гостях, где мне рассказали, что у них есть человек, который каждое утро пропушивает задачи. Он смотрит на доску и спрашивает, можно ли это сделать быстрее, можно ли сейчас это как-то протолкнуть?
Я выполнял эту роль сам, пока не понял, что глаз замыливается — вроде бы уже помню, что кто-то кого-то ждет, не буду об этом спрашивать, да и времени нет. Поэтому мы пришли опять к тому же — сделали эту роль по расписанию.
Дежурный свежим утренним взглядом смотрит на доску и пропушивает задачи. Каждую неделю мы его меняем. Роль пушера тоже может выполнять не тимлид, ее вполне можно распределить.
Вы сделали рабочий механизм: есть Kanban-доска, все задачи прозрачны, но их 40 штук. Продакту лень на это смотреть, ему интересно, когда у него будут безакцептные платежи.
В SCRUM есть Demo day —это что-то похожее на спринт-demo. Мы перенесли идею в Kanban, и теперь каждую пятницу проводим встречу, на которой человек 7 минут рассказывает, что он сделал. Причем нельзя говорить, что чинил продакшен или настраивал окружение — то, что мы говорим на ежедневных митингах, а только, какие задачи из плана действительно зарелизились.
Чтобы мне не приходилось напоминать людям это делать, я сделал шаблон презентации, на котором крупно написано:
Если на фоне этого шаблона располагать свои задачи — невозможно вставить туда какую-то ерунду.
В этом же шаблоне есть слайд «Что я сделаю на следующей неделе», который должен быть в следующей презентации для сравнения между обещанным и реально выполненным.
Так мы распределили часть задач тимлида.
Теперь я расскажу об эксперименте, который провожу сейчас. Не могу пока сказать, успешный ли он, но мне нравится, поэтому спешу с вами поделиться.
В грубом приближении флоу разработки в Skyeng выглядят так: цель — план — проблемы — решения — технические решения. Раньше мы всегда делали так.
Продакт и тимлид ставят цель на квартал, сами придумывают оптимальный план её достижения и красиво презентуют план команде.
Дальше мы собираем команду и вместе придумываем самый дешевый и быстрый способ решения, например: «А давайте вообще не кодить!». Технические решения мы принимаем в маленькой группе во время технического ревью, как я уже говорил.
Схема работает, мы ее долго использовали. Но недавно в одной команде мы попробовали отойти от стандарта, что, как мне кажется, работает интереснее.
Продакт отвечает за бизнес и ставит цель: «Наша цель — увеличить конверсию в 2 раза» или «Уменьшить отказы платежных систем на 10%». А вот дальше схема меняется.
Мы поделили команду на маленькие проектные подкоманды. Каждой подкоманде дали свою цель и предложили подумать самим, как ее достичь. Тимлид и продакт теперь просто консультанты.
Мы посвятили целую встречу презентации планов. Раньше на таких встречах продакт рассказывал свои планы, и его мало кто слушал. Теперь разработчики презентуют свои планы по достижению целей. С техническими решениями все осталось как прежде.
Я реализовал эту схему, потому что думаю, что так можно увеличить мотивацию. Когда не кто-то тебе сказал: «Вот план, он сработает», а ты сам придумал решение, ты отвечаешь за результат и даешь своего рода обещание, то уже не можешь сказать, что это вообще нельзя сделать, если сам презентовал команде свой план 3 месяца назад.
Так мы избавили тимлида почти от всей рутины, распределив все, что можно. Хотя какая-то часть рутинной работы осталась, но он может использовать больше времени на более важные вещи.
Мотивация команды. Я убежден, что одна из обязанностей руководителя — приходить каждое утро и говорить:
— Ребята, мы фигачим! Вот наш продукт, вот наши цели, вот наша культура!
Так мы передаем людям свою энергию, культуру и заряд. Если тимлид тухлый, то и команда такая же. Примеры я видел много раз.
Найм и увольнение. Эти функции делегировать дорого и сложно. Тимлид — единственный, кто видит всю команду целиком. Это важный рычаг, который у него есть, чтобы влиять на производительность и команду.
1:1, как двустороннее средство связи. Так тимлид поддерживает обратную связь со своей командой. Он уже не так погружен во все процессы, и у него должен быть канал обратной связи. По нему тимлид выуживает проблемы из разработки.
Революционные изменения. Классные зрелые команды сами могут вносить изменения на кайдзен-встречах. Но разработчики не видят всю картинку целиком. Они сфокусированы на своих задачах и проектах, и не должны тратить на это время. Тимлид на то и нужен, чтобы придумать нечто невероятное.
— Давайте разделим команду на две части, или донаймем еще 10 человек, или перепишем бэкенд с PHP на Go.
Такие вещи не посетят голову обычного разработчика.
Вернемся к Диме, у которого изначально все горело. Мы помогли ему избавиться от огня. Сейчас Дима оптимизировал свое время, и его стало хватать на важные задачи.
Сразу оговорюсь — я рассказал о своем опыте построения суперкоманды в одной статье, но невозможно это сделать так же быстро — это не неделя, не две и не три. По моему опыту — минимум год уйдет, чтобы построить эти процессы. Рутина все равно будет, нужно долго анализировать вашу ситуацию и потихоньку прививать команде ответственность. Вы не можете сразу сказать: «Завтра проводим стендап, я больше ничего не делаю — делайте все сами!»
Так все развалится — двигайтесь по шагам. Возможно, кто-то сможет пройти путь быстрее, но на нашем опыте это еще ни у кого не получалось. Если получилось у вас — напишите в комментариях, ваш опыт будет интересен.
Теперь поговорим о том, чем Диме занять освободившееся время. Можно ездить по конференциям и рассказывать об успехах. Но я сторонник того, что все время нужно инвестировать в те самые важные вещи — апгрейдить команду.
Механизм тимлида — это его команда. Инвестируйте в механизм, дирижируйте командой как оркестром и улучшайте ее.
Всего их четыре. Принципы. Это 12 наших технических принципов и 12 принципов работы. Конечно, они вам не подойдут, но будет от чего отталкиваться. Книгу тоже советую прочитать, но она очень толстая, а тут маленький файлик. Выстраданный алгоритм технического ревью — то, как мы проводим технические обсуждения. Он тоже может пригодиться. Шаблон демо-дня и правила обращений в канал. Возможно, вам что-то пригодится для организации поддержки.
Хотите получить бонусы к докладу — напишите Алексею в telegram (@ax8080) или в Facebook. Еще Алексей ведет telegram-канал Тимлид Леонид, в котором собирает полезные материалы и делится своими тимлидскими наблюдениями.
Знакомая ситуация? Для Алексея Катаева (deusdeorum) — точно. Алексей больше 15 лет занимается веб-разработкой как backend, frontend, fullstack-разработчик и тимлид. Сейчас Алексей работает в Skyeng и как-то раз ему удалось сделать из команды суперкоманду — лучшую в компании. И с тех пор Алексей занимается тем, что создает в Skyeng суперкоманды на постоянной основе. Как он это делает, в расшифровке доклада, который участники TeamLead Conf 2019 назвали лучшим на конференции.
Рекомендуем посмотреть видео, если есть время, — Алексей заряжает энтузиазмом к переменам. А статья лучше подходит, чтобы просмотреть основные тезисы задуматься о чем-то, что раньше всегда ускользало.
С Димой вы уже знакомы. Раньше он был хорошим разработчиком — брал каждый день по 3 задачи и делал их до конца — это ведь самое главное. Зеленая плашка рядом с Димой — это индикатор ада в его жизни.
Что дальше происходит с Димой? Если вы считаете, что он становится тимлидом и ада становится чуть больше, то вы угадали. К Диме приходит продакт и говорит: «Пойдем планировать Q2! Когда будет задача 1653? У нас скоро релиз!» И ада становится чуть больше.
А потом приходит CTO: «Нам нужно нанять еще одного разработчика. Что у тебя с техническим долгом? И вот еще опросник в Google Doc — заполни его, пожалуйста!» И ада стало еще больше.
Потом пришли разработчики: «Мы хотим расти! Увеличь нам зарплату!» И Дима начинает гореть.
Все приводит к тому, что Дима не высыпается. С утра он идет в душ и думает о разработчике и продакте, и о том, что и кому он наобещал. Задачи теряются — либо Дима о них забыл, либо они где-то далеко в бэклоге и не будут выполнены никогда.
Локально это может привести к плохим последствиям, когда Дима скажет: «Всё! Я больше не буду тимлидом! Я просто хочу делать свои задачки, отстаньте от меня!» Или сорвет задачу, потому что их много, а Дима один — трудно держать фокус на всем. В итоге мы потеряем кучу денег или что-нибудь вовремя не зарелизим.
Я расскажу, как убрать ад из жизни и создать суперкоманду. В конце по традиции будут бонусы.
Intro
Skyeng — это 17 команд разработки, каждая из которых работает над своим продуктом независимо. Чаще всего в команду, кроме разработчиков, входят, как минимум, продакт и тимлид.
Продакт ставит бизнес-цели — у него есть видение продукта, он отвечает за деньги, которые мы зарабатываем и тратим, и общается со всеми заказчиками и клиентами.
Тимлид, то есть Дима, отвечает за техническую стратегию, технические решения, техдолг — за все техническое. Он — технический лидер. Еще тимлид — это project manager. У нас нет выделенной роли project, поэтому тимлид отвечает за планирование и все процессы: за то, что задачи выполняются нужными разработчиками и не зависают в статусах. Тимлид — лидер и наставник, работает с людьми: нанимает и увольняет, развивает и общается, ведет за собой и мотивирует.
Посмотрим на задачи, которые делает Дима. Я разделяю их на:
- важные задачи;
- задачи, которые можно делегировать или автоматизировать, чтобы их выполнял кто-то другой, но нужно потратить на это время;
- рутина — простые задачи, которые приходится выполнять обязательно.
В моей классификации важные задачи — это инвестиции с долгой окупаемостью. Это ресурсы, которые мы тратим на команду сейчас, чтобы улучшать её на длинной дистанции. Это задачи руководителя, которые может или должен делать только он. Конечно, Дима хочет делать только важные задачи, а все остальные — нет.
Решение на поверхности
Избавляемся от всей рутины, делегируем все, что можно делегировать, автоматизируем все, что можно автоматизировать.
Да, вы сразу подумали, что надо все делегировать и автоматизировать, и наступит счастье. Дима тоже знает, что это надо делать, но почему-то это не работает. Возможно причина в том, что Дима работает 10 часов в день, а на выходных, когда его наконец никто не мучает в Slack, он доделывает важные задачи. На делегирование тоже нужно время — ведь всем нужно долго объяснять, что и как — лучше самому все сделать. Чтобы автоматизировать, тоже нужно время — надо писать какой-то код, а времени не хватает даже на создание репы.
Это путь, который все знают, но никто не делает. Но есть другой путь, похожий, который я прошел.
Избавляемся от рутины
Сначала нужно найти низко висящие фрукты — очень простые задачи, на которые уходит больше всего времени, но от которых также просто избавиться. Вы знаете эти задачи, а если нет — помогут ворклоги.
Я веду ворклоги каждый день, записываю все, что сделал, а потом анализирую.
Обращения и вопросы
Скорее всего, это будет работа с обращениями. По моему опыту, тимлиды тратят много времени, чтобы отвечать на вопросы разработчиков, продактов, CTO, заказчиков — Slack всегда переполнен сообщениями. Сейчас расскажу, как легко избавиться от этого шума.
Когда я пришел в команду биллинга тимлидом, я сразу сказал, что не отвечаю ни на один вопрос. Я создал канал #billing, сказал, что все вопросы туда, и поставил в статусе «Не отвечаю в личке».
В Slack я заменил красную иконку, чтобы моя точка не горела никогда, и назначил дежурных — кто-то же должен отвечать людям в этом канале. Дежурных можно выбрать из числа разработчиков или QA. Я составил для QA график и попросил отмечать нужных разработчиков, если дежурные не может ответить сам. Команде я тоже сказал не смотреть в этот канал — там ад, а мы просто работаем.
Потом я увидел, как пишут обращения люди:
— Ааа!!! Ничего не работает, ничего не платится! Деньги исчезли! Мы все умрем!
Поэтому я написал правила, как писать обращения в саппорт. Потом мы быстро закодили бота, который пишет эти правила при входе в канал.
Кстати, мы не пишем ботов сами. Никто из команды не тратит на это время. На это у нас выделены два человека в компании, а иногда мы заказываем работу у фрилансеров. Это дешево и быстро. Там нет никаких требований к качеству кода — этого бота с правилами мы заказали и получили за пару часов.
Итого: за час я избавился от траты кучи лишнего времени для ответов на вопросы. Да, кто-то обиделся, наверное, но зато можно делать другие дела.
Как еще улучшить это решение?
Раздел FAQ. Попросите дежурных написать ответы на самые популярные вопросы и составить короткую инструкцию, чтобы не тратить время на ответ.
Контроль качества. Посмотрите на крутой саппорт, позаимствуйте идеи. Я сделал контроль качества просто: сказал дежурному писать раз в неделю количество обращений, на сколько вопросов мы ответили, а сколько проблем не решили.
Потом мы интегрировали еще одного бота, который во всех каналах по эмоджи анализирует, обработано ли обращение, и постит такой же дайджест-канал аля SLA по обращениям.
Дима отказался отвечать на вопросы, переложил эту обязанность на плечи QA, написал правила обращения в саппорт, создал FAQ и контролирует качество работы поддержки — ада в жизни стало меньше.
Административные ассистенты
Как я уже говорил, можно отдавать задачи разработчикам, QA, ботам. Но когда нанимаешь крутых спецов в команду, платишь им кучу денег, то неудобно просить их делать ерунду типа переноса документов из одного Google Doc в другой, субтитров, растасовки файлов. И делаешь сам, что еще глупее.
Поэтому в Skyeng есть специальный отдел административных ассистентов. Это внутренний YouDo, но с отличиями.
- Заранее подписанный NDA. У всех есть доступы во все корпоративные Google Doc, вам не придется тратить на это время.
- Контроль качества. Есть специальный человек, который отвечает за качество работы ассистентов. Их долго нанимали, обучали и увольняли, если они плохо работали.
- Чёткий регламент постановки задач административным ассистентам. В Trello есть формат карточки, который создается за одну минуту — вуаля! — простые задачи выполняются. Причем это доступно не только тимлидам, но и разработчикам. Любой может воспользоваться услугами административного ассистента.
Мы делегируем ассистентам много задач. Например, классификацию обращений — просмотреть тысячу обращений за год и разбить их по категориям. Мы пишем видео всех наших встреч: daily, meetups, ретроспективы, и кто-то должен расфасовать их по командам и по папкам. Теперь это делают ассистенты, и всегда можно посмотреть любую встречу за любой день.
Мы еще уменьшили количество рутины в жизни Димы за счет административных ассистентов, регламента их работы и контроля качества.
Джедайские техники
Потом Дима решил еще оптимизировать свой тайм-менеджмент и прочитал книгу Максима Дорофеева «Джедайские техники». Из книги Дима взял кучу лайфхаков. Он решил в конце каждого дня вести чек-лист: что делал сегодня, что сделал важного и что сделает лучше.
Дима ведет чек-лист и его вроде бы нужно анализировать в конце дня, но не получается. Почему? Потому что во вторник упал прод, Дима всю ночь его чинил, и теперь у него голова не работает.
Починка продакшена
Здесь все довольно тривиально. Используем автоэскалации — настраиваем специального бота. В Skyeng это OpsGenie, который звонит нам ночью, если сломался прод и заставляет починить. Но ведь мы как раз хотим уйти от этого и не вставать ночью!
Поэтому мы создаем расписание дежурных и убираем себя из этого графика. Тимлид не должен просыпаться ночью.
Дежурство настроено по эскалации: если разработчик не взял проблему, то бот будет звонить тимлиду. На следующий день тимлид разберется почему разработчик не встал. Но это будет бесполезно, если разработчик через 10 минут, как проснется, сам начнет звонить тимлиду.
Поэтому мы даем доступ всем дежурным ко всем диагностическим инструментам сразу: Kibana, Sentry, New relic, а также root-доступ к серверам, и пишем краткую документацию, как этим пользоваться, где смотреть и что чинить.
Правда, это не работает в команде биллинга — там слишком много денег, но во всех остальных командах присутствует. Мы пишем специальный документ «Panic doc» — что делать, если все сломалось. Когда ночью просыпаешься, все лежит, аллерты сыпятся и вообще не понимаешь, что делать, есть простой Google Doc на одну страницу, где по шагам расписано, как поступать в данной ситуации.
Возвращаясь к чек-листу. Теперь Дима выспался и может анализировать по записям, что он сделал важного за последние дни: 3 июня — ничего, 4 июня — ничего, 5 июня — ничего. Это классическая ситуация, у меня такое часто бывает. Главное, быть честным с собой и не вписывать в чек-лист ерунду, которую делал 5 минут.
Дима смотрит, что вообще он делал сегодня:
- Утренний митинг.
- Техническое ревью — так у нас называется техническое обсуждение задач.
- 1:1 с Олегом.
- Ретроспектива или кайдзен.
Весь день какие-то встречи!
Вы ждете, что я сейчас скажу: «А давай делегируем встречи!» Это решение «в лоб», которое мы рассмотрим на примере технического ревью.
Техническое ревью
Если Дима скажет: «Макс, ты завтра проводишь техническое ревью», то, скорее всего, оно не получится. Дима два года проводил технические ревью, он прочитал статьи, у него есть куча опыта — было бы странно это терять.
Как я организую технические ревью в команде? Весь свой опыт я постарался формализовать — написал документ, как я провожу технические ревью. Кстати, это мне помогло сформулировать некоторые вещи. Я написал основу, в которой были:
- Ответ на вопрос, зачем вообще проводить техническое ревью.
- Алгоритм по шагам.
- Советы для ведущего, например, как не допустить холивара на встречах.
- Шаблоны: для голосования, для задач, для расписания, чтобы все было в одном стиле, и человеку не приходилось бы писать все заново.
- Примеры success story: задача была описана так, мы ее отревьюили, и стало так, как должно быть.
На документ я потратил 40 минут. Мой лайфхак, как быстро писать документы: накидал основу, показал всем тимлидам в компании и получил кучу комментариев. В результате в этой инструкции мы объединили опыт всего Skyeng, потому что было много интересных предложений.
Что дальше? Нельзя просто кинуть, как банкой тушенки, в человека этим документом: «Проводи техническое ревью по этому алгоритму!» Так не работает. Я спросил, кто хочет проводить техническое ревью — оказалось, вся команда! Мы сделали расписание и начали проводить ревью по очереди.
Здесь важно не исключать себя из процесса, потому что невозможно хорошо сделать то, что ты сам не делаешь идеально. Тимлид должен быть включен, смотреть, как все происходит и прокачивать себя тоже.
Я видел эту ошибку много раз, если ты сам не принимаешь участия и не делаешь на 10 из 10, то получится плохо.
Мы стали проводить техническое ревью по очереди и собирать обратную связь: после каждой встречи каждому участнику приходил опросник, где он оценивал и процесс встречи, и ведущего по категориям «интересно», «конструктивно», «все мнения услышаны» и «свободный фидбэк».
Последний пункт самый важный. Там были интересные и смешные вещи: «Не могу сходу придумать, куда улучшать. Бесят орущие дети, но они всегда бесят» — специфика удаленной команды. Но были и полезные предложения: «Перед записью решения стоит всех заставить замолчать и еще раз озвучить выводы».
Мы провели несколько раундов по кругу, улучшаясь и улучшаясь, пока стало некуда улучшаться. Алгоритм тоже меняли в процессе. После этого выбрали тех, кто проводит технические ревью лучше — ввели роль фасилитатора. Мы также автоматизировали этот процесс и написали бота, который вместо тимлида проводит опрос, формирует расписание технических ревью в нужное время. Сейчас хотим в бэклоге даже часть самой встречи автоматизировать, заменив ведущего на бота.
В результате Дима избавился от необходимости проводить все встречи. Вроде появилось время, но все равно, когда на технических встречах коллеги не могут прийти к общему мнению, они просят Диму подключиться к разговору и помочь разрешить технический конфликт.
Но Дима прочитал хайповую книгу Рэя Далио «Принципы» и решил, что нужно сформулировать технические принципы, которые помогут принимать решение без его участия — формализовать их.
Технические принципы
Мы собрались всей командой биллинга, я набросал основу этих принципов, мы долго обсуждали их, голосовали, улучшали. В итоге получился список из 12 принципов. Вот три из двенадцати: что для нас важно — качество кода или скорость разработки, можно ли аутсорсить нашу разработку и думаем ли мы о последствиях?
Ответы команды биллинга показали, что биллинг за все хорошее и против всего плохого: мы всегда за качество, аутсорсить нельзя и думаем о последствиях.
Но есть команды в компании, где ответы на эти вопросы другие. Например, для команды платформы важна скорость — не то, чтобы они пишут плохой код, но важна скорость проверки гипотез. Аутсорсить не только можно, но и нужно — они действительно аутсорсят свой продукт. Последствия тоже важны, как и биллингу, потому что если платформа лежит — финансовые потери огромны.
Но есть десятки других команд, которые не думают о последствиях, и это нормально для их продуктов.
В каждой команде должны быть свои принципы, которые зависят от продукта и команды.
Принципы работы
Также мы сформулировали принципы работы и зафиксировали их на бумаге. Юваль Ной Харари в «Homo Deus. Краткая история завтра» писал, что мысли обладают особой магией, когда они записаны, а не просто произнесены. Поэтому мы записали то, что для нас важно.
Например, мы не делаем ничего зря, общаемся культурно и открыто говорим о проблемах и рисках. Это наш самый главный принцип — мы не молчим на встречах.
Когда я подводил итоги, то посчитал среднеквадратичное отклонение по голосованию и вывел самые противоречивые принципы, где мы не приходим к общему мнению.
Личная жизнь важнее, чем Skyeng.Люди поделились поровну на тех, для кого личная жизнь важнее, и тех, для кого — компания.
- Домашнее дома, рабочее — на работе. Мы не «оффтопим»!
Слава богу у нас не демократия и работает принцип принятия принципов: «тимлид может выбирать принципы». Поэтому первый пункт вычеркнули, а второй оставили.
Дима разобрался с техническим ревью, с техническими и принципами работы и не участвует во всех встречах.
Остались только те, в которых приходится участвовать, потому что там рассматриваются действительно сложные или неописанные кейсы. Но тогда и принципы тоже можно дополнить.
Пушер
Приходит продакт и мучает Диму — от этого-то мы не избавились.
Задача Димы — не отвечать быстро на все эти вопросы и идти мучать разработчиков по цепочке, а построить механизм, где задачи решаются сами и сами улетают в прод.
Я фанат Kanban, потому что он как раз позволяет это сделать. На мой взгляд, конвейер выглядит так: есть колонки, мы пушим задачи.
Все уже слышали о боте Арсении. Бот пропушивает задачи из колонки в колонку и каждое утро пишет: «Ты не заревьюил, ты не зарелизил.»
Я увидел, что это работает не всегда, потому что некоторые задачи неделями висят в колонке ожидания. Например: «Жду ответа Алексея из команды инфраструктуры», а Алексей вообще не знает, что задача его ждет. И Арсений тоже не знает, что Алексей не знает.
Поэтому я ввел роль пушера, которую подсмотрел из 2ГИС. Я был у них в гостях, где мне рассказали, что у них есть человек, который каждое утро пропушивает задачи. Он смотрит на доску и спрашивает, можно ли это сделать быстрее, можно ли сейчас это как-то протолкнуть?
Я выполнял эту роль сам, пока не понял, что глаз замыливается — вроде бы уже помню, что кто-то кого-то ждет, не буду об этом спрашивать, да и времени нет. Поэтому мы пришли опять к тому же — сделали эту роль по расписанию.
Дежурный свежим утренним взглядом смотрит на доску и пропушивает задачи. Каждую неделю мы его меняем. Роль пушера тоже может выполнять не тимлид, ее вполне можно распределить.
Kanban + Demo
Вы сделали рабочий механизм: есть Kanban-доска, все задачи прозрачны, но их 40 штук. Продакту лень на это смотреть, ему интересно, когда у него будут безакцептные платежи.
В SCRUM есть Demo day —это что-то похожее на спринт-demo. Мы перенесли идею в Kanban, и теперь каждую пятницу проводим встречу, на которой человек 7 минут рассказывает, что он сделал. Причем нельзя говорить, что чинил продакшен или настраивал окружение — то, что мы говорим на ежедневных митингах, а только, какие задачи из плана действительно зарелизились.
Чтобы мне не приходилось напоминать людям это делать, я сделал шаблон презентации, на котором крупно написано:
На 99% выполненное — не сделано.
Если на фоне этого шаблона располагать свои задачи — невозможно вставить туда какую-то ерунду.
В этом же шаблоне есть слайд «Что я сделаю на следующей неделе», который должен быть в следующей презентации для сравнения между обещанным и реально выполненным.
Так мы распределили часть задач тимлида.
Новая схема
Теперь я расскажу об эксперименте, который провожу сейчас. Не могу пока сказать, успешный ли он, но мне нравится, поэтому спешу с вами поделиться.
В грубом приближении флоу разработки в Skyeng выглядят так: цель — план — проблемы — решения — технические решения. Раньше мы всегда делали так.
Продакт и тимлид ставят цель на квартал, сами придумывают оптимальный план её достижения и красиво презентуют план команде.
Дальше мы собираем команду и вместе придумываем самый дешевый и быстрый способ решения, например: «А давайте вообще не кодить!». Технические решения мы принимаем в маленькой группе во время технического ревью, как я уже говорил.
Схема работает, мы ее долго использовали. Но недавно в одной команде мы попробовали отойти от стандарта, что, как мне кажется, работает интереснее.
Продакт отвечает за бизнес и ставит цель: «Наша цель — увеличить конверсию в 2 раза» или «Уменьшить отказы платежных систем на 10%». А вот дальше схема меняется.
Мы поделили команду на маленькие проектные подкоманды. Каждой подкоманде дали свою цель и предложили подумать самим, как ее достичь. Тимлид и продакт теперь просто консультанты.
Мы посвятили целую встречу презентации планов. Раньше на таких встречах продакт рассказывал свои планы, и его мало кто слушал. Теперь разработчики презентуют свои планы по достижению целей. С техническими решениями все осталось как прежде.
Я реализовал эту схему, потому что думаю, что так можно увеличить мотивацию. Когда не кто-то тебе сказал: «Вот план, он сработает», а ты сам придумал решение, ты отвечаешь за результат и даешь своего рода обещание, то уже не можешь сказать, что это вообще нельзя сделать, если сам презентовал команде свой план 3 месяца назад.
Так мы избавили тимлида почти от всей рутины, распределив все, что можно. Хотя какая-то часть рутинной работы осталась, но он может использовать больше времени на более важные вещи.
Важные функции тимлида
Мотивация команды. Я убежден, что одна из обязанностей руководителя — приходить каждое утро и говорить:
— Ребята, мы фигачим! Вот наш продукт, вот наши цели, вот наша культура!
Так мы передаем людям свою энергию, культуру и заряд. Если тимлид тухлый, то и команда такая же. Примеры я видел много раз.
Найм и увольнение. Эти функции делегировать дорого и сложно. Тимлид — единственный, кто видит всю команду целиком. Это важный рычаг, который у него есть, чтобы влиять на производительность и команду.
1:1, как двустороннее средство связи. Так тимлид поддерживает обратную связь со своей командой. Он уже не так погружен во все процессы, и у него должен быть канал обратной связи. По нему тимлид выуживает проблемы из разработки.
Революционные изменения. Классные зрелые команды сами могут вносить изменения на кайдзен-встречах. Но разработчики не видят всю картинку целиком. Они сфокусированы на своих задачах и проектах, и не должны тратить на это время. Тимлид на то и нужен, чтобы придумать нечто невероятное.
— Давайте разделим команду на две части, или донаймем еще 10 человек, или перепишем бэкенд с PHP на Go.
Такие вещи не посетят голову обычного разработчика.
Вернемся к Диме, у которого изначально все горело. Мы помогли ему избавиться от огня. Сейчас Дима оптимизировал свое время, и его стало хватать на важные задачи.
Сразу оговорюсь — я рассказал о своем опыте построения суперкоманды в одной статье, но невозможно это сделать так же быстро — это не неделя, не две и не три. По моему опыту — минимум год уйдет, чтобы построить эти процессы. Рутина все равно будет, нужно долго анализировать вашу ситуацию и потихоньку прививать команде ответственность. Вы не можете сразу сказать: «Завтра проводим стендап, я больше ничего не делаю — делайте все сами!»
Так все развалится — двигайтесь по шагам. Возможно, кто-то сможет пройти путь быстрее, но на нашем опыте это еще ни у кого не получалось. Если получилось у вас — напишите в комментариях, ваш опыт будет интересен.
Теперь поговорим о том, чем Диме занять освободившееся время. Можно ездить по конференциям и рассказывать об успехах. Но я сторонник того, что все время нужно инвестировать в те самые важные вещи — апгрейдить команду.
Основной принцип — мы должны заниматься не тушением пожаров и не фиксом конкретных проблем, а работать над механизмом.
Механизм тимлида — это его команда. Инвестируйте в механизм, дирижируйте командой как оркестром и улучшайте ее.
Бонусы
Всего их четыре. Принципы. Это 12 наших технических принципов и 12 принципов работы. Конечно, они вам не подойдут, но будет от чего отталкиваться. Книгу тоже советую прочитать, но она очень толстая, а тут маленький файлик. Выстраданный алгоритм технического ревью — то, как мы проводим технические обсуждения. Он тоже может пригодиться. Шаблон демо-дня и правила обращений в канал. Возможно, вам что-то пригодится для организации поддержки.
Хотите получить бонусы к докладу — напишите Алексею в telegram (@ax8080) или в Facebook. Еще Алексей ведет telegram-канал Тимлид Леонид, в котором собирает полезные материалы и делится своими тимлидскими наблюдениями.
А мы тем временем уже готовимся к следующей TeamLead Conf — в Санкт-Петербурге 23–24 сентября. Ищем новых спикеров, выбираем актуальные вопросы со знакомыми экспертами. Вот примерный список тем, которым мы хотим уделить внимание в программе питерской конференции:
- Процессы, планирование, управление.
- Персональная работа с сотрудником.
- Выстраивание команды и внутренних отношений.
- Взаимодействие со стейкхолдерами.
- Личностный рост.
Подробнее расскажу в одном из следующих постов, но вы уже подавайте доклады, если какой-то из перечисленных тернистых путей уже пройден. Если сомневаетесь, можете сначала написать мне или кому-то еще из Программного комитета — обсудим, подскажем, поможем.
