Всем привет! На этой неделе, каналом буду рулить я, Федоров Никита, известный как @nik3r.

По традиции представлюсь и расскажу немного о себе. В IT кручусь уже больше 8 лет. Последний год работаю в Avito как техлид юнита Billing. Отвечаю, как можно понять из названия юнита, за биллинговую систему, а так же за оплату услуг и интеграции с платежными провайдерами. До Avito работал техлидом в компании RuCenter, отвечал за разработку практически всего веба.

Предыдущие ведущие, @glamcoder и @dumtest, высоко подняли планку качества постов, поэтому буду стараться не опускать её и делиться максимально полезным контентом.

Обсуждать увиденное тут призываю в чатике для тимлидов "Боль Тимлида" (https://t.me/TeamLeadTalks), я там тоже есть. Если есть желание обсудить что-то лично, пишите мне, с удовольствием отвечу тоже (@nik3r).

Для разминки поговорим немного про такую важную штуку, как целеполагание.

В Авито, для работы с целями, мы уже несколько лет активно используем систему OKR, которая внедрена на уровне всей организации. Про то, как это устроено у нас, очень подробно рассказал Денис Дудоров на одном из митапов: https://www.youtube.com/watch?v=49Yz59e2yfc

На тему OKR написано огромное количество статей и гайдов. Приведу несколько:
• https://medium.com/@robingop/целеполагание-с-помощью-okr-7934ac3d7303 - хорошая вводная статья, объясняющая что такое OKR и зачем они нужны.
• https://habr.com/company/wrike/blog/329272/ - хорошая статья с конкретными примерами.
• https://rework.withgoogle.com/guides/set-goals-with-okrs/steps/introduction/ - гайд от гугла по постановке целей используя OKR (en).

И в догонку - шаблон OKR для быстрого старта. Отлично подойдет, если захотите попробовать внедрить у себя в команде/компании:
https://docs.google.com/spreadsheets/d/1-5y32GQKyshg9GUXjIreyuzI0DXnPOmv9BHqeurY4G0/edit#gid=0

А вот про следующий подход, как мне кажется, знают не многие, потому что информации о нем в интернете представлено очень мало. Это то, как устроено целеполагание в небезызвестной Spotify. В определенный момент времени, они отказались от постановки целей через OKR и разработали собственный фреймворк стратегического планирования «Spotify Rhythm».

Если кратко описывать его, то можно выделить 3 основные сущности, которые используются для определения целей во всей компании:

Company beliefs - основа модели, описание видения того, каким будет мир вокруг компании через 3-5 лет.
North Star - верхнеуровневые цели компании на ближайшие 2 года.
Bets - конкретные инициативы и проекты. Они бывают разного уровня - компании, функциональные или рыночные. Для запуска нового проекта, используется фреймворк DIBB (Data-Insights-Belief-Bet).

Чуть более подробно посмотреть можно на слайде с одной из презентаций: https://blog.crisp.se/wp-content/uploads/2016/06/Spotify-Rhythm-Agila-Sverige.pdf

Небольшая статья о преимуществах работы по такому подходу: https://hackernoon.com/place-your-bets-4022b732ba4c

Сегодня хочется поговорить про инженерную культуру Google, компании, которая подарила миру невероятное количество инструментов, практик, подходов и продуктов.

Начнём, пожалуй, с такой важной темы как инцидент-менеджмент. А если конкретнее, то про анализ инцидентов и предупреждение их в будущем.

Рано или поздно, любая компания переходит на стадию, когда подход «быстро поднятое, упавшим не считается» перестаёт работать, потому что каждая минута простоя сервисов выливается в крупные финансовые потери. И бизнес не хочет, чтобы такие количество таких инцидентов в будущем было минимальным. Google, как очень крупной компании, это было сверхактуально и они разработали свой подход к сбору и анализу ошибок - написание postmortem’ов.

Что это такое: это детальный документ, в котором описываются все подробности случившегося инцидента: статус, impact, как решели проблему, как развивался инцидент с подробным таймлайном, конкретные action items и уроки, которые вынесли из него. Многие компании подхватили эту практику и используют у себя. Хорошим тоном считается публикация postmortem’ов в открытый доступ, для того, чтобы другие компании могли учиться не только на своих ошибках, но и на чужих.

Что почитать на эту тему:
• https://landing.google.com/sre/sre-book/chapters/postmortem-culture/ - оригинальная статья от Google
• https://landing.google.com/sre/sre-book/chapters/postmortem/ - пример конкретного Postmortem’a.
• https://github.com/danluu/post-mortems - большая подборка postmortem’ов от разных компаний, собранных в одном месте и сгруппированных по типам проблем.

Автор последнего поста не очень часто обновляет подборку, но в pull request’ах можно найти свежие ссылки от сообщества.

Небольшое чтиво перед сном, в продолжение предыдущей истории. В Авито у нас тоже есть практика написания Postmortem’ов на инциденты. Но, очевидно, что сами себя они не заполнят, не оценят убытки и не определят конкретные action items. А ещё нужно их как-то классифицировать и понимать, какой инцидент нужно разбирать, а какой нет. Для этого нужен определенный процесс.

За основу мы взяли процесс LiveSite Review, родившийся в недрах компании Microsoft. Это часть большой культуры LiveSite. Про неё мы поговорим чуть позже. Вернёмся к инцидентам. На LSR мы выносим инциденты, которые соответствуют хотя бы одному из следующих критериев: привели к потере денег, деградации сервиса или потере данных. Заводится тикет в Jira, который назначается на техлида определенного юнита (обычно на того, в чьей зоне ответственности произошёл инцидент). Он либо сам заполняет postmortem, либо делегирует кому-то из команды.

В раз в неделю, овнер процесса LiveSite Review, составляет список инцидентов на разбор и собирает на встречу людей, которые так или иначе связаны с ними. На эту встречу приходят с уже заполненными Postmotem’ами и совместно челленджат action items - действительно ли они помогут избежать проблем в будущем. После встречи action items берутся в работу.

Это если очень кратко. Там на самом деле много нюансов и полный рассказ про процесс тянет на отдельный доклад. Возможно, @etolstoy, как один из тех, кто внедрял его, расскажет на близжайших конференциях :)

Всем привет! Сегодня мы затронем одну холиварную тему, за которую, возможно, меня закидают шапками.
Мы очень много говорим про t-shape. В этот канале даже было несколько постов про то, как развивать горизонтальные компетенции у инженеров. Но за бортом всегда оставался вопрос - куда же тишейпиться техлиду? Кажется, что ответ очевиден - в продукт. О нем и поговорим.

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

И так, что почитать?

1. База
https://simulator.gopractice.ru - интерактивный курс по управлению продуктом на основе данных от Олега Якубенкова. По своему опыту могу сказать, что это лучшее вложение денег в образование, которое я когда-либо делал.

2. Unit economics
https://khanin.info/blog/85 - хорошая вводная статья про юнит-экономику. Вообще можно почитать блог автора статьи, пишет достаточно годные вещи.
https://medium.com/@MBGilroy/early-stage-saas-unit-economics-596c90af23e6 - юнит-экономика для стартапов

3. Customer Development
https://www.ozon.ru/context/detail/id/34432645/ - прекрасная книга, которая рассказывает что такое cusdev, как правильно его проводить и интерпретировать результаты. Советую начать погружение в тему именно с нее.

4. User stories
https://medium.com/@alexandertvar/как-писать-user-story-2410093b23c2 - хорошая статья, про то, как правильно писать User Stories.
https://www.lucidchart.com/blog/how-to-create-a-user-story-map - в дополнение к предыдущей.

5. Value proposition
https://optinmonster.com/32-value-propositions-that-are-impossible-to-resist/ - для лучшего понимания, что такое ценностное предложение, нужно смотреть на примеры. В этой статье разобраны 32 VP от разных компаний.

Это далеко не все, тема очень глубокая. Если интересно, накидаю еще - напишите об этом в чатик тимлидов (https://t.me/TeamLeadTalks).

Всем привет! Немного запоздалый вечерний пост. Не буду сильно грузить чтивом, а поделюсь небольшой подборкой видео на разные темы.

https://youtu.be/-LvCJpnNljU - рассказ о том, как устроен процесс разработки в Microsoft в командах работающих над Visual Studio. Очень рекомендую к просмотру.

https://www.youtube.com/watch?v=TNGkMvggc7I&t=1642s - Kanban не стоит на месте, а продолжает развиваться и эволюционировать. Хороший доклад от Леши Пименова с последнего AgileDays про то, что новенького в методе. Бонусом идут несколько полезных инструментов.

https://youtu.be/5Etw2TpEKlk - доклад Алексея Паршукова с митапа тимлидов в Skyeng. Классная история про масштабирование разработки и переход от функциональных команд к кросс-функциональным.

Всем пятницы! В последние дни, в чатике Боль Тимлида горячо обсуждают тему тестирования. Не буду капитанить и рассказывать про общеизвестные вещи типа пирамиды тестирования, а расскажу про два процесса, которые мы внедрили у себя в Авито.

Zero Bug Policy
@dumtest в предыдущих постах уже упомянул этот подход. В авито мы внедрили его около года назад и работает он на ура. Для того, чтобы это завелось, нужно выполнить два условия:

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

https://medium.com/qualityfaster/the-zero-bug-policy-b0bd987be684 - хорошая вводная статья, с которой можно начать погружение.
https://medium.com/swlh/how-we-got-to-zero-bugs-and-implemented-a-zero-bug-policy-c77ee3f2e50b - история внедрения техники в одной из компаний

Risk-base Testing
Интересная практика, достаточно популярная на западе и не очень на просторах бывшего СНГ. Мы начали применять ее относительно недавно и только в одном юните в качестве эксперимента, поэтому говорить о результатах рано. Статьи подобрал хорошие, поэтому не буду их подробно пересказывать:

https://www.performance-lab.ru/blog/testirovanie-na-osnove-riskov - основательная статья с подробным описанием самой практики, а так же истории ее возникновения.

https://www.softwaretestinghelp.com/risk-management-during-test-planning-risk-based-testing/ - будет хорошим дополнением к предыдущей статье, содержит примеры.

Всем привет!
С одобрения автора канала, расскажу про свой небольшой pet project, которым занимаюсь в свободное время последние два года: https://qase.io. Это облачная Test Case Management System (пока без standalone версии). Проект потихоньку развивается и уже можно полноценно использовать его в работе.

Что есть сейчас:
* Работа с тесткейсами и сьютами
* Общие шаги для кейсов (shared steps)
* Составление тест планов
* Тестовые прогоны по планам
* Работа с дефектами
* Интеграции с Jira и Redmine (на подходе Slack и YouTrack)

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

Про новый функционал периодически рассказываю в телеграм канале https://t.me/qaseio и в блоге на медиуме https://medium.com/qase. Фидбэк и вопросы по приложению можно кидать мне напрямую - @nik3r 🙂

Подходит к концу мое дежурство в качестве ведущего на этом канале. Напоследок хочется рассказать про одну интересную штуку. Кто-то может читал её - «Гайд для новых сотрудников Valve» - https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployeeHandbook.pdf. Что же в нем примечательного? А то, что те инструменты и практики, которые сейчас горячо обсуждаются на коференциях у нас, на западе давно само собой разумеющееся. Холократия, самоорганизующиеся команды, performance review и так далее. Все это у них было в 2012. И думаю, что много чего нового есть сейчас.

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

Всю эту неделю с вами был @nik3r. Надеюсь, что не разочаровал и вы нашли для себя что-то действительно полезное.

Фб: https://www.facebook.com/nikita.fedorov.351
Почта: [email protected]

Привет, это @dumtest! Воспользуюсь тишиной и подкину достаточно интересный с моей точки зрения материал - https://labs.spotify.com/2014/09/16/squad-health-check-model/ - рассказ (с примерами, которые можно скачать) Spotify о squad health check model (каждый переведёт в меру своей испорченности). Суть в том, что ребята выбрали для оценки несколько самых важных критериев деятельности команды, придумали светофорную градацию состояний и вынесли на доску для наглядности. Имхо просто и очень наглядно.

Всем привет! Эту неделю канал буду вести я, Андрей Гоменюк.
Немного обо мне. Начинал с сайтов на CMS больше 10 лет назад, потом пара стратапов про конструкторы сайтов, а с 2011 работаю в бэкэнде Badoo. Последние года 3-4 на должности тимлида.

И сразу к делу!

В первой статье на сегодня автор делится впечатлениями о книге “Как работает Google”. Основные мысли посвящены тому, что при найме нужно искать тех, кто постоянно учится (learning animals), и как потом их удерживать. Мысль про поиск тех, кто постоянно учится, кажется простой и правильной, но как таких искать? По своему опыту, большинство компаний на собеседованиях просто убеждаются в том, что у человека есть нужные знания. Некоторые засчитывают за плюс, если человек не знал, но вопросами/рассуждениями пришел к ответу. Единицы специально заводят человека туда, где у него нет ответов, и наблюдают. Собственно, сама статья здесь https://medium.com/@gilligan_conor/the-learning-animals-how-training-your-staff-retains-them-4481ca43a3dc, но и саму книгу рекомендую.

Вторая статья посвящена культуре в компании. Если в двух словах, то автор строит модель 2х2, где по одной оси отложены навыки/компетенции, а по другой ценности/культурное соответствие. Получаются 4 квадрата: классные и компетентные, классные и некомпетентные, компетентные засранцы и некомпетентные засранцы. Автор рассматривает в отдельности все 4 квадрата, но на мой взгляд, самая важная идея - не держать в компании компетентных засранцев. Я бы даже перефразировал так: как только вы поняли, что человек в культуру не вписывается, с ним надо расставаться, каким бы компетентным он ни был. А еще проще: научиться понимать на этапе собеседования, впишется человек в компанию или нет. Сама статья здесь https://medium.com/s/company-culture/your-companys-culture-is-who-you-hire-fire-and-promote-c69f84902983.

Интересно, а без какого (одного) качества вы точно не готовы взять человека на работу? И есть ли качества, при наличии которых вы точно не возьмете человека на работу?
Предлагаю все обсуждения и ответы на вопросы переносить в чатик "Боль Тимлида" (https://t.me/TeamLeadTalks), либо лично @andreygomenyuk.

Полагаю, все здесь знают, что такое 1-1 (или one on one, 1:1, один-один, тет-а-тет). Я считаю, что этот формат общения — один из самых важных инструментов в рукаве тимлида/руководителя, но очень недооценен. Про него обе сегодняшние статьи.

Мне 1:1 довольно долго не заходил, пока я где-то не наткнулся на хороший материал про этот формат (к сожалению, найти его уже не могу). Основная идея в том, что он предназначен не для получения статуса по задачам от подчиненного, а для обсуждения успехов, неудач, планов и т.д. Если сделать 1:1 откровенными, честными, открытыми, то можно будет узнавать о людях очень много такого, чего в обычной обстановке они бы не рассказали: свои взгляды на карьеру, чего хочется, что не нравится. Вам, как руководителю, остается только использовать эту информацию для роста человека и предотвращения кризисов. Статья уровня “сейчас я научу вас жизни”, но в ней есть интересные мысли. https://medium.com/@zackbloom/youre-doing-one-on-ones-wrong-dfc27f36f204

Наверное, не сильно ошибусь, если скажу, что большинство тимлидов и руководителей на этом канале так или иначе вышли из разработки/тестирования/администрирования, в общем, люди с техническим бэкграундом. По своему опыту, таким людям не всегда легко дается открытое общение с начальством/подчиненными. Следующая статья как раз про то, что хорошие 1:1 получаются тогда, когда вам “неловко”: вы перешагиваете через себя и рассказываете о своих мыслях, мечтах, планах, неудачах. В статье есть примеры вопросов/тем, которые подталкивают к открытому общению. https://medium.com/@mrabkin/the-art-of-the-awkward-1-1-f4e1dcbd1c5c (есть вторая часть про то, как получать честный фидбек о себе — тоже рекомендую).

От себя хочу добавить, что большинство менеджерских инструментов, включая 1:1, можно применять снизу вверх. Если вы считаете, что 1:1 с вашим руководителем могут проходить эффективнее, сами предложите поменять формат. Если вы видите, что вашему руководителю не о чем с вами поговорить, заведите разговор сами, например, расскажите, каким вы видите свой рост, как вы развиваетесь, спросите совета по застрявшим проектам/задачам и т.д.

А вы считаете 1:1 полезными? (Отвечайте отрицательно, если не проводите/с вами не проводят).

Пока в группе “Боль тимлида” не утихают страсти по поводу “performance review”, самое время поделиться статьями на эту тему.

Не смотря на разное отношение, в некоторых компаниях такой способ оценки сотрудников практикуется. Первая статья содержит ряд идей, без которых, по мнению автора, ревью будет приносить больше вреда, чем пользы. Мысли на самом деле довольно простые: перфоманс ревью должно быть в первую очередь про результаты, а не про деятельность (тот, кто больше делает, не факт, что приносит больше пользы), хорошие оценки не ведут к развитию человека, а плохие, не подкрепленные качественным фидбеком, не улучшают ситуацию и т.д. Если честно, мне не зашли “Best Practices” из статьи, возможно, я их просто не понял. Но всё, что до них, считаю годным. https://hackernoon.com/how-to-do-performance-reviews-2f0e8cd170da

В нашей компании перфоманс ревью существует с 2011 года, а за основу был взят процесс Google. С тех пор мы его несколько раз модифицировали (например, самое большое изменение: мы сделали маленькие ежемесячные ревью, которые привязаны к результату здесь и сейчас, и позволяют человеку сразу получать бонус за проделанную работу, и большие полугодовые ревью, которые нацелены на долгосрочные результаты и рост сотрудников). Я ни в коем случае не утверждаю, что наша схема - “правильная”, но для нас она работает. Пожалуй, самая актуальная и подробная информация есть в этой статье: https://habr.com/company/badoo/blog/331570/, либо в докладе с хайлоада: https://www.youtube.com/watch?v=qDzlqNicZ8g.

Я считаю, что самый важный скилл тимлида/менеджера/руководителя - time management. Именно он определяет, будет ли у вас время для роста и развития, или вы будете вечно заняты разгребанием завалов, решением текущих проблем, а чувство перегруженности не будет покидать вас. На эту тему есть множество книг, статей, докладов, где рассказывают о конкретных инструментах и практиках, но по факту, базовыми являются простые идеи, которые описаны в сегодняшней статье: временем управлять нельзя, можно управлять только тем, на что вы его тратите. Поэтому все сводится к умению приоритезировать: продвигать важное, избавляться от неважного, выделять то, что должно быть сделано сегодня (завтра, к конкретному числу). https://www.meme-arsenal.com/memes/a17827e7a1a800d60f20ff9a84f73b8e.jpg
Статья: https://medium.com/thrive-global/why-you-really-dont-have-a-time-management-problem-82eb6e31ffc9

Отличный способ разгрузить свой список задач, выкроить время на себя, а заодно и людей научить чему-то новому - делегирование. Если вы считаете, что делегирование - это поставить на человека задачу, то это не совсем так. В следующем докладе рассказывается о том, что же такое делегирование, когда его нужно применять и что мешает это делать правильно. Если коротко, то ключевые ошибки: делегирование группе без конкретного ответственного, отсутствие у человека возможности (инструментов) для достижения цели, отсутствие цели/срока/приоритетов, передача ответственности (ответственность остается на вас). Вообще, в докладе довольно много информации, всю не передашь, поэтому рекомендую посмотреть: https://www.youtube.com/watch?v=1bZ9EJ8o7Io

Люди с техническим бэкграундом чувствуют себя комфортнее, когда у них есть алгоритмы, правила. Начинающие тимлиды начинают создавать для себя и своих девелоперов различные инструкции, а при общении со своими руководителями просят конкретные ответы, как им нужно поступить в конкретной ситуации. С опытом инструкции и алгоритмы в работе заменяются здравым смыслом, инструменты начинают использоваться по-назначению (а не потому что они есть у соседа). Но есть один “алгоритм”, который я бы назвал, если не самым фундаментальным в работе любого руководителя, то как минимум одним из - это ситуационный менеджмент.

Если кто-то смотрел вчерашний доклад про делегирование, то теория там кратко рассказана. Если нет, то можно прочитать следующую статью. Если сжато, то часто руководители выбирают какой-то один стиль управления (авторитарный, демократический или либеральный). Таких руководителей сразу видно: они либо слишком мягкие, либо слишком жесткие, либо слишком безучастные. Настоящие же профи (какими мы все хотим стать) умеют подбирать стиль под ситуацию/человека/задачу. Я не буду пересказывать, как это делается, просто приведу пример из статьи, где показаны четыре варианта постановки задачи в четырех разных ситуациях:
- Приказ: я решил запустить новый проект, вот что ты должен сделать.
- Продажа: я решил запустить новый проект, сейчас я расскажу тебе, почему он так важен, и как ты сможешь запустить его.
- Участие: нам нужно запустить новый проект, давай ты подготовишь план и стратегию, а потом обсудим.
- Делегирование: нам нужно запустить новый проект, ты лучше меня знаешь, как и что для этого сделать.
https://medium.com/swlh/why-your-team-calls-you-a-micro-manager-behind-your-back-bae4b0a9e0be

Выходные - время отдыха, поэтому статьи будут просто “за жизнь” и по одной в день.

В сегодняшней статье автор делится мудростью о том, как ему удалось добиться хороших результатов в своей компании, не смотря на то, что в индустрии продукты становятся все хуже, сотрудники и пользователи несчастны, а серебряные пули, типа скрама, тянут всех вниз, а происходит все это из-за плохих руководителей (что-то мне это напоминает… кстати, про негативное влияние перфоманс ревью в статье тоже есть). Статья большая, в ней много интересных мыслей (и гуглить никто не отправляет, если вы понимаете, о чем я), некоторые из них:
- Нужно настороженно относиться к топ-перформерам (чаще всего они добиваются высокой скорости разработки путем создания тех долга и выбором плохих технических решений)
- Нужно совмещать разработку с рефакторингом, иначе вы не будете успевать устранять тех долг (это похоже на правило бой-скаута: нужно оставлять после себя код лучше, чем он был)
- Поощрять владение кодом (типичная позиция тим лидов: повышать бас-фактор, окуная людей во все места в коде, но это снижает качество, инициативу и скорость разработки)
- Разработка и управление - разные вещи. Вы не лучше/умнее ваших девелоперов только потому, что вы управляете ими. Не нужно создавать у девелоперов ложное ожидание того, что “повышение” в менеджеры - это прогресс их карьеры. Они должны идти в менеджмент, только если действительно хотят этого.
https://medium.com/@billjordan1/the-quiet-crisis-unfolding-in-software-development-cffbdafbf450

Жена предлагала запостить сегодня статью про work-life balance, но мне она не зашла.

Сегодняшняя статья тоже очень длинная, но она объясняет, откуда же берутся плохие руководители, и как жить дальше (да, там есть принцип Питера про уровень некомпетентности, но он не рассматривается в качестве основной причины). Вот часть причин, которые, по мнению автора статьи, делают менеджера плохим управленцем (в статье есть и еще):
- люди подсознательно оценивают в других то, в чем хороши сами (в статье был пример про ревью кода: если тимлид - лучший ревьюер на деревне, для него ревью кода станет главным фактором в оценке своих сотрудников)
- тот факт, что они уже в чем-то хороши, затмевает их слабые стороны и усложняет разностороннее развитие
- некоторые считают, что они прекрасно справляются со своей работой (потому что они лучше всех знают, как правильно ревьюить код, просто команда какая-то плохая попалась - не хотят учиться этому)
- в своих неудачах люди привыкли винить обстоятельства, вместо того, чтобы сделать выводы и научиться чему-то
- некоторые менеджеры слишком оторваны от того, чем занимается команда (со стороны менеджера это выглядит как высшее проявление доверия и свободы, но в этом есть свои минусы).
Тому, как жить дальше, посвящена маленькая глава, причем довольно расплывчато, но я сделал из нее такой вывод: если вам что-то не нравится в вашем руководителе - донесите это до него, предложите, что он может изменить (начать что-то делать, перестать что-то делать).
https://medium.com/@jswilder16/how-to-better-manage-your-poor-manager-50b96d944957

На этом моя неделя заканчивается, с вами был @andreygomenyuk, пока!

Подкастов не бывает много. Встречайте еще один, от создателей одноименного митапа. Тема первого выпуска – профессиональное выгорание.
http://bit.ly/2RVOt4B