Привет и добро пожаловать!

Меня зовут Анатолий Панов, сейчас я работаю в Авито на позиции СТО вертикали Товары. Ещё со школы я мечтал стать программистом и писать компьютерные игры, но жизнь как-то занесла меня в менеджеры 🙂

Я в индустрии больше 15 лет. Управлял как небольшими командами 5-7 человек, так и довольно большими 300+. Но это всегда были очень крутые команды профессионалов. За это время решал и интересные менеджерские задачи, такие как запуск большого количества команд с нуля, с выстраиванием найма, сохранением культуры, и внедрением scrum и Agile подходов. Так и классные инженерные задачи, где нужно было строить массштабируемые архитектуры работающие под большой нагрузкой.

Я завёл этот канал, потому что хочу делиться своим опытом, по большей части управленческим, на чуть более регулярной основе чем выступление на конференциях. Надеюсь он будет полезен вам при решении задач и развитии карьеры.

Сегодня в 17:00 я выступаю с докладом Моя попытка №2: как я делал техстратегию на YaTalks. Я расскажу про свой опыт подготовки технической стратегии для своей команды Авито.Товары, о том что сработало, а что нет, какой получился фреймворк и результаты.

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

Базовые мысли
- Writing an engineering strategy Will Larson
- Solving the Engineering Strategy crisis Will Larson
- Хорошая стратегия, плохая стратегия Ричард Румель

Хороший сборник рецептов и техник, которые можно использовать для создания контента для стратегии. Это уже продвинутый уровень, когда подбираешь инструмент под задачу. Technology Strategy Patterns: Architecture as Strategy Eben Hewitt.

Если нужно ещё больше, то на github есть сборник Awesome Engineering Strategy

Выкладываю презентация с выступления на YaTalks "Моя попытка №2: как я делал техстратегию"

Приветствую, дорогие подписчики! Прошу прощения за долгое молчание. Период новогодних праздников, Performance Review и калибровок — он такой. Я надеюсь прийти к регулярному ведению канала в скором времени.

Тем не менее, хочу поделиться вот чем.

Вынырнуть из операционного процесса и посмотреть в будущее — значит, поставить конкретные цели и сделать видение проекта одинаковым и ясным для всех участников его реализации. Двумя словами — создать техстратегию.

Как её разрабатывать, интегрироваться с другими стратегиями компании и как оценивать успешность, я рассказал в подкасте Devone. Делюсь ссылкой и благодарю коллег из QIWI за приглашение!

В июне в Сочи прошла конференция для CTO "South HUB". Это мероприятие проводится уже в третий раз, но мне удалось поучаствовать только в этом году.

Я давно перестал посещать Team Lead Conf и менеджерские митапы, так как нового и интересного для меня контента там практически не появляется. Вы скажите "но кроме контента, есть ведь ещё и нетворк", и это бесспорно так! Но у ребят которые приезжают на подобные мероприятия вызовы и задачи сильно отличаются от моих. На этом фоне South HUB выгодно выделяется. Организаторам удалось собрать очень крутое комьюнити и программу. Столько контактов в записной книжке и идей я ещё ни с одного мероприятия не увозил.

Если вы тоже давно не были на классных менеджерских эвентах, рекомендую подумать про South HUB в следующем году 😃

Кроме просто участия в South HUB, мне ещё посчастливилось открывать конференцию своим выступлением.

Я рассказал о том как росла команда разработки Авито, о том какие у нас были вызовы. Про наши менеджерские инструменты и практики, которые помогли нам на этом пути.

На слайдах было много QR-кодов со ссылками наш playbook на GitHub. Для читателей канала - бонус в виде удобных ссылок 🙂
- Матрица компетенций инженера
- Матрица компетенций технических менеджеров
- Technical Design Review (TDR)
- Team Maturity Model
- Avito Platform as a Service (PaaS)
- Общее описание процесса найма

Если после просмотра выступления у вас остались вопросы или хочется больше деталей про инструменты или подходы, то приходите в комментарии 🙂

Само выступление можно посмотреть здесь, а следующим постом выложу слайды.

Меня часто спрашивают: "Зачем нам техническая стратегия в постоянно меняющемся мире?". Действительно, зачем планировать на 3-5 лет вперёд, если каждый год возникают кризисы, пандемии, конфликты, а в будущем и вовсе могут появиться неожиданные угрозы?

Техническая стратегия – это не жёсткий свод правил. Это направление, которое помогает нам адаптироваться и развиваться. Стратегия должна быть живой и поддаваться корректировке, чтобы соответствовать меняющимся условиям.

Поэтому я считаю, что стратегия необходима. Но её реализация должна быть гибкой.

Что такое гибкая стратегия? Это как Scrum. Этот метод разработан для достижения целей в условиях хаоса. Мы движемся итеративно, постоянно проверяя, не сбились ли с пути. Стратегия в быстро меняющемся мире очень похожа на этот подход. Мы должны двигаться спринтами, отслеживать прогресс в каждом спринте, и если цель утратила актуальность из-за внешних факторов, это нормально – нужно остановиться и поставить новую цель, учитывая новые обстоятельства.

Устали от Беспорядка в Заметках? Попробуйте Zettelkasten и метод PARA для их идеальной организации

Я давний пользователь Evernote и активно им пользовался для ведения заметок. Одна из его главных фишек — удобство и быстрота сохранения контента из интернета в заметку, чем я активно пользовался и насобирал много полезной информации, которой так никогда и не воспользовался 🙂 Кроме статей, мой Evernote хранил в себе фотографии слайдов с конференций, копии списков рекомендаций книг на разные темы, конспекты из книг, статей, видео, устаревшие данные и документы и т.п.

В прошлом году один мой бывший коллега познакомил меня с программой Obsidian и методом ведения заметок Zettelkasten. Привет тебе, Никита, если вдруг ты это прочитаешь :). Мне стало интересно, и я начал читать разные статьи и книги по теме. Нашёл, что есть и другие похожие методы, например, Вечно зеленые заметки (Evergreen notes). Вся эта тема называется Личная Система Управления Знаниями или Personal Knowledge Management (PKM).

Что в них такого классного? Эти методы помогают их создателям думать. Их главная фишка — атомарность заметок, то есть заметки должны быть максимально короткими. Такая атомарная заметка содержит в себе только одну мысль или понятие. Дальше ты начинаешь связывать эти заметки между собой. Когда создаёшь новую заметку, нужно прям сесть и подумать, с какими другими заметками в моей базе она может быть связана, и связать её через ссылки, записав в заметке, как они связаны и почему. Если связь сложная и требует отдельного объяснения, то она вообще может быть достойна создания новой заметки. В итоге получается такой большой граф заметок, похожий на второй мозг, где нейронные связи — это ссылки заметок друг на друга. И за счёт визуализации этих связей может появляться новое знание или неочевидные связи между похожими идеями из разных областей.

Вторым открытием для меня стал метод PARA из книги «Building a Second Brain» by Tiago Forte. Он смотрит на заметки немного под другим углом. Тиаго говорит, что вся наша взрослая жизнь — это обычно какие-то проекты или области интересов. Например, написать этот пост — это небольшой проект, или запланировать отпуск — тоже проект. Отличительная черта проекта — его конечность и ограниченность во времени. Писательство и путешествия могут быть областями моих интересов. Здесь уже нет конца, и пока мне эти темы интересны, я могу изучать материалы и улучшать себя довольно долгое время. В этой концепции заметки должны помогать нам заканчивать проекты и быть полезными в рамках наших областей интересов. Задача — сделать так, чтобы когда я сел писать статью или начал планировать новую поездку, вся нужная информация была у меня под рукой и мне не нужно было тратить много времени на её поиск.

Что изменилось после моего знакомства с этими методами ведения заметок? В моих заметках появилась понятная мне структура. Мой внутренний перфекционист уже только от этого радостно потирает ладошки 🙂

Но кроме этого, мне показалось отличной идеей объединить эти два подхода.

В Evernote я уже интуитивно группировал заметки по проектам и областям интересов. Метод PARA дал мне недостающие компоненты, и теперь, делая это осознанно, я смог больше заметок разложить по проектам. В заметках стало больше порядка, и мне стало проще ориентироваться в моих записях.

Идеи Zettelkasten и Вечно зеленые заметки помогли мне более качественно подходить к изучению какой-то темы. Теперь, читая статью или смотря видео, я делаю полезные мне заметки-конспекты. Потом делаю постобработку этих конспектов, выделяя из них атомарные заметки с идеями и понятиями. И все эти заметки стало удобно линковать с областями моих интересов или проектами, так как по ним тоже появились свои заметки и пространство, где их будет легко найти в будущем.

Single Team Oriented Service Architecture

Долгое время я выстраивал архитектуру и команды вокруг неё, руководствуясь следующими принципами:
- Строить архитектуру на базе сервисов.
- У каждого сервиса должна быть команда, которая за него отвечает.
- Одна команда может отвечать за много сервисов, но много команд не могут отвечать за один и тот же сервис.
- Команда отвечает за разработку сервиса целиком и за его эксплуатацию во всех окружениях.
- Каждый сервис сам отвечает за хранение своих данных.
- Каждый сервис обеспечивает публичный контракт для своих потребителей с помощью удобного и хорошо документированного API и SLA для него.

И вот недавно я узнал, что кто-то придумал всему этому название — Single Team Oriented Service Architecture (STOSA).
Теперь можно всем рассказывать, что я пользуюсь известным фреймворком 🙂

Нужны ли современному CTO навыки продуктового и бизнес-управления?

В разговорах с коллегами уже несколько раз всплывала тема о необходимости для CTO навыков продуктового и бизнес-управления. Нужны ли они современному CTO или нет?

Я считаю, что нужны. И, судя по тому, что я вижу на рынке, это сейчас один из самых востребованных навыков.

Всё, связанное с разработкой, долгое время оставалось уделом энтузиастов, поэтому сейчас на рынке много людей, которые отлично разбираются в технологиях, но мало тех, кто при этом хорошо разбирается в бизнесе и продукте. Сейчас бизнес хочет не просто партнёра, который будет хорошо понимать его запросы и уметь переводить с языка бизнеса на язык разработки и обратно, но человека, который благодаря своей технической экспертизе сможет развивать бизнес и продукт.

Когда я только начал свой путь в Авито, я инвестировал много времени и усилий, чтобы получить продуктовые и бизнесовые знания. Что мне это дало?

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

Если вы сейчас думаете, что стоит изучить, чтобы быть конкурентным на рынке, то навыки продуктового и бизнес-управления определённо стоит включить в этот список.

Несмотря на то что в Авито мы используем гибкие подходы к разработке, у нас всё равно появились проджект-менеджеры и проектные офисы. Завтра с коллегами проведём интересный круглый стол на эту тему. Заходите послушать трансляцию.

Сегодня участвовал в панельной дискуссии с коллегами из Сбера, Самолёта и УБРиР на тему "Проектное управление в ИТ: олдскул или вы просто не умеете его варить?".

Мысли, которые звучали на дискуссии и которые меня зацепили:
- Несмотря на гибкие подходы в разработке, проджекты и проекты никуда не исчезли.
- Проджекты подключаются к большим проектам, где участвует много команд и разных департаментов. Командам требуется много синхронизации сроков и усилий, или есть аутсорс, или аутстафф, или много сложных стейкхолдеров.
- Больших проектных офисов в компаниях спикеров не осталось, проджекты работают децентрализовано. В некоторых компаниях есть центры экспертизы, которые помогают поддерживать общие практики управления проектами.
- Роль проджекта размылась, и сейчас это больше роль, которую может выполнять кто-то из команды: продукт-менеджер, тимлид или отдельный человек — проджект.
- Точно так же со скрам-мастерами: в новых командах они есть, а потом это становится ролью кого-то из команды. Скрам-мастера начинают отдаляться от команд и делать более сложные и масштабные задачи.
- Какие навыки нужны проджекту? Главный — ему не должно быть всё равно. Кроме этого, понимание гибких методологий и немного технической экспертизы. Ну и управление проектами, конечно.
- Почему 50% проектов проваливается? Пожимают по срокам, на которые не согласна команда. Но тут ещё вопрос: а почему это плохо? Если была нормальная коммуникация со стейкхолдерами, проект в целом успешен и запущен, и всем ок, то не всё ли равно?
- Почему PMO часто оторваны от реальности и делают бесполезное? Им не хватает продуктового подхода в своей работе. Если думать о пользователях и решать их проблемы, то всё будет хорошо.

Нужны ли матрицы компетенций?

Существует два диаметрально противоположных мнения: — «Дичь какая-то, мы тут все снежинки, нам такое не подходит» и — «Это супер удобно, не понимаю, как люди живут без них».

На мой взгляд, матрицы компетенций — это основа всех HR-практик, без которой невозможно масштабироваться.

Я действительно не понимаю, как люди могут обходиться без них, если в команде разработки есть хотя бы 30 человек. На таком уровне уже точно появляются джуны, мидлы и сеньоры. Появляются тимлиды, и им всем необходимо отвечать на вопросы о том, как расти и как их нанимать.

А если команда насчитывает более 300 человек, возникает вопрос о справедливой зарплате для каждого и гарантии того, что менеджеры без постоянного надзора смогут нанимать и повышать сотрудников так же, как это делал бы я.

Здесь матрица компетенций выступает как ориентир для всех. Если это живой инструмент, то на него опираются при найме, составлении планов развития и многом другом.

В «Авито» нам удалось построить такую рабочую и живую систему на базе матриц компетенций, которая успешно зарекомендовала себя за последние пять лет, позволив нам вырасти с 300 до 2000 инженеров.

Сегодня мы записывали подкаст с командой cloud.ru на тему масштабирования команд и того, как менеджеру расти вместе с командой, начиная с тимлида и дорастая до CTO.

Огромное спасибо Мише Трифонову за приглашение и интересный, душевный разговор. Мы записали два часа материала, из которых нужно оставить всего один. Посмотрим, что останется после монтажа :)

Одна из интересных мыслей, озвученных в разговоре, — это ответ на вопрос, как стать CTO и продолжать расти вместе с командой. Для этого нужно быть человеком, которому не все равно, брать на себя ответственность за сложные проекты и доводить их до конца. При этом важно не забывать, что по мере роста от тимлида до менеджера менеджеров и далее до CTO у вас должны меняться фокусы и подходы.

Менеджеры с синдромом отличника и делегирование

Часто менеджерами становятся самые лучшие и самые умные сотрудники. В разработке это вообще стало стандартным мемом: "был хороший инженер, а теперь плохой менеджер".

Часто это происходит из-за того, что люди не могут начать делегировать. "Я же могу сделать это лучше, зачем кому-то за это платить? Потом еще и переделывать придется!"

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

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

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

Привет, Яндекс!

На этой неделе я присоединился к команде Яндекса на позицию CTO Геосервисов.

За 6,5 лет в Авито удалось сделать многое. Запустить три вертикали, каждая из которых выросла с нуля до ста инженеров. Развить Авито Доставку и вертикаль Товары. Собрать сильную команду инженеров и менеджеров. Перестроить направление приёма платежей в полноценный финтех-сервис с кошельками, кредитами и сложными транзакционными сценариями. Разработать и внедрить множество HR-практик для инженерной команды Авито. И многое другое.

Многие коллеги спрашивали меня: "Толя, всё же было классно, ты на пике, зачем уходишь?". В Авито действительно крутая команда, по которой я буду скучать, но после всего сделанного душа просит новых вызовов :)

Пару лет назад я смотрел выступление Лёши Шаграева "Уйти красиво: как покинуть любимую компанию с пользой для всех".

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

Я благодарен за всё, что было в Авито, но пора двигаться дальше. Посмотрим, что получится в Яндексе.