Привет!
Я Николай Крапивный, руководитель отдела server-side-разработки в Badoo.
Недавно мы дружной командой ездили на конференцию Lead Dev в Нью-Йорк, посвящённую управлению разработкой. Среди спикеров были представители Google, IBM, Slack и других компаний. По сложившейся у нас в отделе хорошей традиции хочу поделиться впечатлениями, мыслями, обзором докладов и некоторыми материалами, которые привёз с конференции.
Год назад я уже был на конференции Lead Dev в Лондоне, и она меня не очень впечатлила. Набор докладов показался мне далеко не самым сильным — было много «воды» и выступлений ни о чём. В этом году расписание выглядело гораздо внушительнее, включая доклад от Michael Lopp, VP Engineering Slack и автора книги Managing Humans, о которой наш коллега Дима Марущенко yojick отзывался исключительно восторженно. В общем, расписание интриговало, и за неимением большого количества конференций по техлидской тематике было решено дать Lead Dev ещё один шанс и заодно, что греха таить, воспользоваться возможностью посетить Нью-Йорк. В качестве спойлера скажу, что в этом году мне понравилось существенно больше (поэтому я и решил написать этот отчёт).
О конференции
Организаторы, лондонские ребята (а точнее девчата) под названием White October, помимо Lead Dev, организуют ещё несколько IT-конференций, в основном в Англии (подробнее можно почитать на их сайте: https://www.whiteoctoberevents.co.uk/). Делают они это хорошо, ибо к организации конференции вообще никаких вопросов нет: еды/ пива достаточно, Wi-Fi работает, атмосфера дружелюбная и позитивная.
Конференция проходила в самом центре Нью-Йорка во вторник, 24 апреля. На мой взгляд, не самое удобное расписание, учитывая, что многим участникам в Нью-Йорк долго лететь и, по факту, лететь нужно ради одного дня. Очевидно, расчёт был на американскую публику, и, в общем, так и получилось — людей из Европы было немного, и в основном это были организаторы, которые прилетели из Лондона. А русскоговорящих среди участников я вообще не встретил.
Расписание состояло из четырёх блоков:
- Большой доклад (30—40 минут).
- Маленький доклад (10 минут).
- Ещё доклад на 30—40 минут.
- Обед/ Кофе-брейк.
На самом деле, это лучшее расписание, которое я когда-либо видел, — большинство маленьких докладов были откровенно неинтересными, так что я использовал отведённое на них время, фиксируя основные мысли предшествующих больших докладов. Организаторы, я думаю, задумали эти вставки в том числе для «обкатки» неопытных спикеров, что, наверное, тоже полезно.
Запомнилось, что на экране рядом со слайдами были субтитры. Не уверен, что это сделано исключительно для слабослышащих (и это здорово), — возможно, ещё и для тех, кто не владеет языком настолько, чтобы воспринимать 100% информации на слух (что не менее здорово).
Отдельно хочется сказать про спикеров и подготовку докладов. Все большие доклады были просто на отлично: классные слайды, спикер рассказывает ясно, чётко, от души, никаких заминок и проблем, слушать — одно удовольствие. Если честно, даже создавалось впечатление, что выступающие на конференции — профессиональные спикеры (что, возможно, не так далеко от истины).
О докладах
— Revitalizing a cross-functional product organization, Deepa Subramaniam и Lara Hogan
Две девушки являются основателями компании, которая занимается консультированием в областях построения процессов и формирования команд для других компаний. Они поделились основными принципами построения правильной культуры и процессов в компании. Нового в докладе для меня было немного, но я нашёл для себя ценность в структурированном взгляде на то, что мы и так делаем. Вкратце, по мнению авторов, к успеху можно прийти, если:
- Определить этапы процесса разработки и для каждого этапа определить три вещи: какие документы должны быть созданы, какие митинги собраны, что должно являться результатом этапа. На примере Badoo: на этапе идеи у нас формируется PRD-файл, собирается встреча продуктологов и инженеров (kick-off meeting), результатом является принятая инженерами в работу задача.
- Чётко обозначить и разграничить зоны ответственности: для процесса разработки жёстко определить, какой кусок кто делает (продуктолог, дизайнер, разработчик, аналитик), особое внимание обращая на сложные моменты, по которым чаще всего возникают разногласия.
- Не избегать неприятных дискуссий. В целом в этом пункте было многовато «воды», но идея в том, что коммуникация между менеджером и сотрудником крайне важна (особенно если это негативный фидбек), и при её отсутствии плохо всем.
- Создать в компании здоровый микроклимат. Лара показала наработки HR-команды из Etsy: как они у себя пропагандируют конструктивное и дружелюбное общение. Понравилось, взял на вооружение.
- Больше общекорпоративных каналов коммуникации. All hands, запуск проектов, корпоративные новости — всё это становится тем более важно, чем больше компания. Сложно не согласиться.
Слайды доклада доступны здесь: https://speakerdeck.com/lara/revitalizing-a-cross-functional-product-organization
— Traps on the Path to Microservices, George Woskob, ThoughtWorks
Самый честный доклад про микросервисы, который я когда-либо слышал! Товарищ из ThoughtWorks (той самой ThoughtWorks, в которой работает Мартин Фаулер) вначале похвастался тем, что распилил уже не один монолит и что знает всё про микросервисы. А потом прошёлся по «болевым точкам» перехода от монолита к микросервисам. Вкратце доклад можно сформулировать так: «Они обещали нам рай с микросервисами, а в реальности чаще всего получается такой адище, что лучше уж оставаться на монолите». Например, как-то так, по мнению автора, выглядит типичный процесс перехода на микросервисы:
Дальше был рассказ об основных препятствиях, которые ждут тех, кто всё-таки решит двигаться в сторону микросервисов. По мнению автора, это:
- недооценка стоимости перехода — возможно, многим этого вообще делать не нужно;
- централизация (причём как техническая (куча общего кода), так и административная: общие релизы, единые точки принятия решений);
- пренебрежительное отношение к монолиту — оверинжиниринг микросервисов.
В общем, доклад годный, видно, что парень в теме и никаких иллюзий не питает.
Очень жду видео, чтобы порекомендовать всем к просмотру. А слайды доклада доступны здесь: https://www.slideshare.net/GeorgeWoskob/traps-on-the-path-to-microservices-lead-dev-2018
— The Critical Career Path Conversation, John Riviello, Comcast
Всегда завидовал ребятам, у которых есть возможность остановиться на каком-то жизненном этапе, подумать на тем, что с ними случилось, и сделать из этого целый доклад. В общем, этот доклад — история про карьерный путь «инженер — менеджер — инженер». Да, докладчик побыл менеджером и решил вернуться обратно к работе инженером, причём в той же компании. Нужно сказать, что случай нечастый и заслуживает как минимум уважения.
В докладе автор красочно развеял мифы про менеджеров («стать менеджером — это круто», «у менеджеров меньше работы», «быть менеджером — это такая же работа, как программирование» и другие) и описал, почему он решил, что это не его. Первая часть про превращение из инженера в менеджера понравилась, очень точно описаны переломные моменты (делегирование, сложности работы с людьми, более долгосрочные цели). Вторая часть, про возвращение обратно в инженеры, понравилась не очень, особенно расстроила отсылка к статистике «только N% людей могут быть менеджерами». Статистики вида «не только лишь все могут делать то-то» вообще не очень вписываются в мою жизненную концепцию «Если очень захотеть, можно в космос полететь», поэтому не могу поддержать автора. В конце был слайд со списком книг/ сайтов, которые больше всего помогли автору на менеджерской позиции — за это ему большое спасибо, сохранил себе для изучения в будущем:
Слайды доклада доступны здесь: https://www.slideshare.net/JohnRiv/the-critical-career-path-conversation
— Improving Reliability with Error Budgets and Site Reliability Engineering, Liz Fong-Jones, Google
Доклад девушки-SRE из Google о том, как они подходят к отказоустойчивости своих приложений. Тема очень крутая, видно, что Google системно подходит к этому вопросу и достаточно мощно развил это направление. Доклад представлял из себя попытку донести максимально много информации из книги Site Reliability Engineering за 30 минут. Было заметно, что этого времени очень мало для такого количества мыслей и идей, и иногда возникало желание остановить докладчика и попросить время на обдумывание того, что было сказано. Немного спасало то, что Андрей Гоменюк AHDREN в своё время читал эту книгу, поэтому какие-то базовые идеи были мне знакомы.
Основная мысль доклада строится вокруг того, что у всех сервисов должны быть выстроены ключевые показатели доступности (SLI, SLO, SLA, подробнее о них тут), и по каждому из них должен быть определён бюджет (на сколько мы можем себе позволить выходить за показатели, например, в месяц). Как только бюджет превышается, принимаются меры/ вкладывается время в предотвращение отказов вплоть до замораживания релизов. Не буду пытаться пересказать книгу — советую прочитать (я лично добавил её в свой список must-read).
— The New Manager Death Spiral, Michael Lopp, Slack
Это тот самый доклад, ради которого мы и поехали на конференцию. Однако он оказался скорее воодушевляющим, чем полезным с практической точки зрения.
Основные мысли: нужно больше делегировать, нужно друг другу помогать расти и развиваться, нужно учиться, учиться, и ещё раз учиться. В общем, за всё хорошее против всего плохого. Если не делать всего хорошего, то начинается «спираль смерти»: как снежный ком, всё накапливается, и становится всё хуже и хуже. Короче, доверяйте сотрудникам, живите в мире и согласии — и будет вам счастье. С автором чрезвычайно сложно поспорить, поэтому вышел после доклада окрыленный и с твёрдым ощущением, что этот мир ещё можно спасти. Но так как что конкретно нужно для этого сделать, не понял, просто пошёл на следующий доклад.
— Bowerbirds of Technology: Architecture and Teams at Less-than-Google Scale, Sam Kitajima-Kimbrel, Nuna
Большую часть доклада автор доносил до слушателей следующую мысль: не нужно бездумно делать так, как делают крутые дядьки из Google, Facebook, Amazon и т. д. Осознавайте масштаб своего проекта и принимайте максимально эффективные решения с учётом этого. Например, если гиганты могут себе позволить перевести всё на микросервисы, на каждый выделить по отдельной команде или написать заново свою платформу для клауда, то некрупным конторам такое часто не нужно: неплохо бы использовать то, что есть, и не гнаться за гигантами. В принципе, больше про доклад сказать нечего. Мысль здравая, всё так и есть.
— The Continuous Culture, Kim van Wilgen, ANVA
На мой взгляд, лучший доклад конференции. Где-то в середине выступления девушка-докладчик упомянула о том, что в их системе ~2М строк кода на PHP и ~8М — на COBOL. После этого не уважать их просто нельзя. Но, кроме шуток, доклад был про основные принципы, позволяющие организации максимально быстро производить продукт. Они следующие:
- максимально частые релизы готового функционала;
- максимальная гибкость в планировании, не строить продуктовых планов на год вперед
- максимальная автоматизация ручной работы;
- максимальная автономность административной структуры (отказ от единых точек принятия решений, которые не позволяют масштабировать компанию);
- continuous learning (становиться лучше каждый день, стимулировать рост команды);
- снижение рисков через автоматизацию тестирования (пирамида тестирования и их взгляд на неё);
- меньше зависимостей, меньше связности (плавные релизы, canary builds, feature flags).
Доклад очень понравился, наверное, потому, что большинство озвученных принципов очень близки культуре Badoo, и мы стараемся делать всё практически так же. Кроме того, доклад ещё раз доказал: неважно, на каком языке ты пишешь (можно делать хорошо и на COBOL) — были бы правильные ценности в голове.
Из новых интересных идей понравился подход к нашей давней проблеме — ускорению большого количества медленных функциональных тестов. Весь набор функциональных тестов они разделили на три группы. В первую попали тесты, проверяющие критичные для бизнеса вещи, тесты того, что сейчас разрабатывается, и тесты самых нестабильных мест кода; эта группа тестов запускается как можно раньше/ чаще. Во вторую группу вошли тесты менее критичных с точки зрения бизнеса и более стабильных частей кода; они запускаются уже на более поздних стадиях разработки. В третью группу вошли тесты функционала, потеря которого на некоторое время допустима; эту группу они вообще выкинули и заменили на мониторинг. Идея понравилась, хотелось бы к нашим проектам прикрутить.
Слайды доклада доступны здесь: https://www.slideshare.net/KimvanWilgen/20180424-the-lead-developer-ny-the-continuous-culture
— Make the Right Thing the Easy Thing: How to Design Systems and Processes Teams Actually Follow. Jason Lengstorf, IBM
Последний доклад, о котором хочется поговорить. Бородатый парень из IBM рассказывал про вещи, которые считает важными для построения правильных процессов в команде. Основные мысли можно выделить следующие:
- Системные проблемы нужно решать не костылями, а процессами, которые предотвращают их в будущем.
- Вводимые процессы должны быть удобны, как чемодан на колёсиках (без колёсиков, как без процессов, неудобно).
- Избегать единых точек отказа в команде — вещей, которые знает/ умеет только один человек.
- Идеальная система ввода человека в строй — он пришёл и в первый же день начал приносить пользу компании. К ней нужно стремиться.
Отдельно хочется отметить красивые слайды и несколько классных метафор, которыми оперировал автор. Например:
- Элегантное название для bus factor (без намёка на то, что кого-то собьёт автобус) — Vacation tolerance.
- Модель слона и всадника для формирования правильных процессов.
- Yak shaving — процесс решения проблем, никак не связанных с решением задачи (девел не работает, место на диске закончилось, нет тестового телефона). И его нужно системно минимизировать.
И вдобавок ко всему этому автор поделился интересной книжкой. В общем, классный доклад, было интересно слушать.
Слайды доклада доступны здесь: https://jlengstorf.github.io/presentations/make-the-right-thing-the-easy-thing/#/
Выводы
Конференция понравилась. Остался доволен.
Отдельное спасибо за компанию нашим ребятам, вне конференции тоже было весело. :)
Автор: Николай
