Финальная книга на тему разработки публичных API: «API как искусство: разработка, поддержка, интеграция» [2025] — Сергей Константинов. Книга бывшего руководителя сервиса «Яндекс.Карты», которую можно назвать самой практичной, самой приземлённой и наиболее требовательной к квалификации читателя.

В отличие от книг, про которые я писал в предыдущих постах, она начинается сразу с девелоперской точки зрения. Как хороший архитектор, автор предлагает различные варианты реализации API, а потом говорит: «Миша, всё фигня, давай по новой» — и объясняет, почему.

Книжку нужно читать внимательно, так как автор часто приводит ссылки на свои же рассуждения и выводы из предыдущих глав. Однако для ленивого читателя он приводит методички по различным моментам проектирования API — например, «Вот 30 правил хорошего API», — тщательно поясняя, почему считает именно так.

Из интересного: поскольку автор работал в «Яндекс.Картах», он уделил целый раздел разработке SDK и UI-клиентских библиотек. Разработчикам, которые занимаются только server-side API, этот раздел, возможно, не нужен, но тем, кому это актуально, подобный материал нигде, кроме этой книги, не найти.

Отдельно хочется отметить, что автор позволяет себе язвительные ремарки по поводу некоторых решений публичных API. Эти комментарии раскрывают его большой опыт и подтверждают, что он действительно «повидал некоторое дерьмо».

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

Поэтому я бы сказал так: первой книгой по проектированию API стоит читать «Проектирование веб-API» от Лоры Арно. А уже на эту базу — книгу Сергея с большим количеством практических примеров и кейсов из реальной жизни.

Это хорошая книга, которая заслуживает покупки и прочтения!

P. S. Возможно, в следующих изданиях книги стоит части 4 и 6 перенести в начало, вместо их текущей позиции. Тогда книжка будет идти от простого к сложному более предсказуемо.

Прочитал книжку, которую можно скорее назвать методичкой в силу её небольшого размера: «A Practical Approach to API Design» Кейта Кейси и Джеймса Хиггинботама, 2014 года. Это неплохой материал для понимания, что такое публичное API и каких принципов и паттернов стоит придерживаться при его проектировании.

Однако стоит уточнить, что книга по текущим меркам уже довольно старая — ей 12 лет. Поэтому некоторые главы посвящены рассуждениям, почему один подход лучше другого, причём эти сравнения сегодня во многом утратили актуальность: один стандарт проиграл, а другой де-факто стал общепринятым.

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

Читать этот материал в целом уже нет особого смысла, поскольку Лоре Арно в своей книге «Проектирование веб-API» прямо опирался на эту работу (и сам это указал). Поэтому лучше сразу уделить время книге Арно: в ней материал раскрыт в широком обучающем формате. К тому же книга Арно вышла в 2019 году и содержит более актуальную информацию.

Прочитал книжку «API Design Patterns» от бывшего разработчика Google — JJ Geewax, и это, на удивление, полностью ненужная книжка.

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

Особенно доставляет, что на большинство вопросов автор приводит несколько подходов, но не даёт никакого обоснования, где и когда нужно применять тот или иной подход. «Просто есть несколько вариантов — выбирай мудро» (с).

По самому предложенному варианту API тоже есть вопросы, ибо за свою 12-летнюю карьеру и знакомство с множеством реализаций API я ни разу не видел того, что предложил автор. Возможно, это внутренняя штука от Google, которая не стала широко используемой, но в Google её используют.

Ну и самое главное — в книге нет никакой целостности. Словно автор просто брал какую-то тему, писал про неё 6–8 страничек, потом брал новую тему и снова писал 6–8 страничек. И какой-то связи между этими главами нет.

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

Мне не так часто в последнее время попадаются книги, где есть что-то ценное, кроме пары идей, которые автор повторяет по 10 раз разными словами. Однако книга «Проектирование веб-API» от французского разработчика веб-стандартов и публичных API Арно Лоре прямо сильно порадовала. 

Фактически это такая книга-чеклист, где автор поднимает вопросы создания публичного API и делится тем, что API должно учитывать при разработке. Помимо этого он приводит свои таблички, которые использует при согласовании веб-API, и делится опытом использования инструментов в практическом поле. 

Отдельно автор уделяет внимание использованию формата OpenAPI (бывший Swagger), который автор сам и развивал как активный участник OpenAPI-сообщества. Это немного иронично, ибо автор опубликовал эту книгу в 2019 году, а в 2022 году ушёл работать в Postman, которые развивают фактически конкурирующий стандарт. 

В своей книге автор делится ссылками на разные ресурсы, которые помогают разрабатывать публичное API. Однако на текущий момент большая часть этих ресурсов либо закрыта, либо находится в заброшенном виде. Ибо ИИ сейчас неплохо решают вопросы «страха перед белым листом» и неплохо советуют по подходам. 

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

p.s. делитесь своими книгами и ресурсами по проектированию api, которые вам понравились

Как вы знаете, мобильный интернет стал нестабильным последнее время, поэтому в поезде у меня появилась возможность посмотреть, что же я там скачивал почитать, когда появится время. И наткнулся на книгу: «Founders at Work [Stories of Startups' Early Days]» — 2008 года. Фактически эта книга рассказывает про яркие, выстрелившие стартапы в долине с 1980 по 2006 год примерно.

И знаете, хотя большинство из этих стартапов либо были куплены и растворены в других компаниях, либо обанкротились спустя некоторое время после выхода книги, сами истории мне понравились, в силу того, что можно сравнить то, о чём думали люди, и что по факту случилось спустя 20–25 лет.

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

Также подчёркиваются преимущества долины, где одни и те же люди по цепочке выстраивают свои компетенции и получают деньги на развитие своих идей фактически от одних и тех же инвестиционных фондов. Что ярко кричит — приезжай в долину, именно тут делаются успешные стартапы.

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

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

Есть ли смысл от курсов по Cursor AI?

Для программирования с помощью ИИ в настоящий момент программисты используют среду разработки Cursor AI (форк Visual Studio Code с чатом с той или иной моделью ИИ).

Если вы до этого работали в любой среде разработки (VS Code, IDEA, PHPStorm, Goland, Eclipse, NetBeans), то кроме чата с ИИ-моделью и раздела ИИ в настройках среды — вы ничего не увидите.

Само взаимодействие с ИИ-моделью происходит ровно так же, как это делается на страницах Grok, OpenAI, GigaChat. Вы пишете запрос с промптами и получаете какой-то результат.

__

Так вот, я решил собрать небольшое MVP-приложение на языке, который я знаю недостаточно хорошо. Ожидал, что ИИ поможет преодолеть зону некомпетенции и получить то, что я хочу.

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

 Я подумал, что, возможно, я что-то делаю не так, и решил посмотреть, как грамотные спецы с Udemy, которые ведут курсы по разработке с помощью ИИ, работают в Cursor AI.

 Я взял три курса: 

 • Getting Started with Cursor AI

 • Cursor AI for Beginners AI Coding Crash Course

 • Vibe Code a Chrome Extension with Cursor AI 

В итоге во всех трех курсах мне рассказали документацию Курсора, показали, как они ловко и умело делают MVP с минимальной бизнес-логикой, и на этом всё. Круто!

__

И что по итогу: 

 1) Все три курса по ИИ оказались откровенной халтурой. Всё то же самое можно найти на официальном сайте Cursor AI или на YouTube бесплатно и без воды.

  2) При создании своих MVP они делали ровно то же, что и я. Поэтому проблема с тем, что ИИ написал мне лапшу — это проблема ИИ, а не того, как именно я писал запросы.

📕📖📚 "Управление победоносной командой" — звучит как отличное название, поэтому я решил ознакомиться со свежей книгой по управлению командами от бывшего бейсбольного тренера, а ныне тренера по лидерству и командной динамике: Трента М. Кларка.

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

Для валидации своих советов он говорит фразу: "Либо вы делаете всё правильно и ваша команда побеждает, либо она проигрывает, и тогда ваши советы не стоят ничего. Моя команда становилась чемпионом три раза".

Стиль изложения максимально напоминает книгу "45 татуировок менеджера" Максима Батырева, которую многие называют жёсткой, что подчёркивает, что человек пришёл из спорта, где высокие ставки и высокая награда за результат, и какие-либо оправдания не принимаются.

__

В основе "Управление победоносной командой" лежат три взаимосвязанных столпа: командная работа, мотивация, стратегия.

Кларк начинает с анализа командной работы не как модного слова, а как осознанной практики, закалённой в горниле соревнований. Он вспоминает ключевые моменты из своей карьеры в MLB — например, сплочение аутсайдеров во время изнурительных плей-офф, — чтобы показать, как доверие и взаимозависимость превосходят индивидуальное звёздное сияние.

Эти истории подчёркивают главный принцип: настоящие команды процветают благодаря SPARC — Духовности, Продуктивности, Ответственности, Обязанности и Обучаемости, — концепции, разработанной Кларком для формирования устойчивости.

Для бизнес-лидеров это означает создание среды, где сотрудничество побеждает изоляцию, подобно слаженной защите на поле, выполняющей двойной аут под давлением.

___

Если вам понравилась книга Батырева, либо вам импонирует "красный" менеджмент, то книгу могу вам порекомендовать к ознакомлению.

📕📖📚Прочитал на этих выходных книгу: "Lead Developer Career Guide" от Shelley Benhoff от 2025 года. Это книга-гайд по тому, как нужно строить карьеру ведущего разработчика, или в российской терминологии тимлида. Причем не такого тимлид-менеджер, а гибрида управления и техскиллов.

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

• Мама я тимлид

• Как пасти котов. Наставление для программистов, руководящих другими программистами

• Карьера Software Engineering Manager

И все это приводит меня к мысли, что если разные авторы из разных стран на разных языках пишут примерно одни и те же инструкции, то позиция тимлида достаточно четко описывается и регламентируется. И уже можно говорить о некотором стандарте отрасли для тимлидов.

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

p.s. Что касается самой книги, то характерно для США идет большой фокус на эмоциях и комфортной атмосфере в команде. Достаточно интересная статистика и инфографика. Плюс некоторые рекомендации, в каких отраслях есть запрос на тимлидов и юнит-лидов.

🐺🐺🐺Они бегут так, словно их подгоняет чья-то злая воля.

Примерно месяц смотрел, как трекать время на своих задачах, чтобы не попадать в прокрастинацию (ситуация, когда времени прошло много, а работы сделано преступно мало).

Какие варианты рассмотрел:

Pomodoro Tracker — идея самая очевидная, но отказался от него, потому что приходилось часто перетыкивать софт, и это меня отвлекало. Хотя журнал логов по трекеру был удобен.

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

В итоге остановился на гравитационном таймере: https://www.ozon.ru/product/rxsm-taymer-elektronnye-1-sht-1249814540/

Кубик с шестью гранями: четыре грани отсчитывают время по 5, 10, 30 и 60 минут, пятая грань останавливает таймер, шестая — сбрасывает его в ноль. Чтобы переключить время, достаточно повернуть кубик другой стороной. Понравился.

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

Краткий обзор: https://vr-2.ozone.ru/vod/video-56/01JCGT9FNBPT7RSEHP8DTKGZC5/asset_1_h264.mp4

Совсем недавно была новость, что Amazon увольняет 14 тысяч менеджеров. И эта новость подавалась в апокалиптических тонах — будто конец уже близко, всё загибается, и пора бежать спасаться. Однако не стоит верить провокационным заголовкам; важно уметь правильно интерпретировать ситуацию.

Что мы знаем про Amazon:

• В Amazon работает около 1,5 миллионов сотрудников.

• Компания известна своими регулярными увольнениями неэффективных работников.

Теперь давайте посчитаем. Если каждый менеджер управляет от 5 до 10 человек, в среднем возьмём 7. Сколько же менеджеров потребуется для штата в 1,5 миллиона?

Для этого представьте себе дерево, где на нижнем уровне будет 1,5 миллиона «листьев», а все остальные уровни — менеджеры. Возводим число 7 в разные степени и смотрим результаты:

7⁰ = 1
7¹ = 7
7² = 49
7³ = 343
7⁴ = 2401
7⁵ = 16807
7⁶ = 117649
7⁷ = 823543
7⁸ = 5764801

Уже на восьмом уровне количество «листьев» превышает общее число сотрудников Amazon. Поэтому вернёмся на седьмой уровень — там примерно 800 тысяч «листьев».

Предположим, что у некоторых менеджеров подчинённых больше семи, такое бывает в функциональных подразделениях.

Теперь сложим количество менеджеров с нулевого уровня до шестого и подсчитаем итог:1+7+49+343+2401+16 807+117649 =137 257;

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

Итак, увольнение 14 тысяч менеджеров — это примерно 10% от общего числа управленцев, тех самых неэффективных сотрудников, которых Amazon ежегодно сокращает.

Таким образом, новость перестаёт казаться сенсационной и становится обычной практикой. Так что всегда сохраняйте ясность ума и не поддавайтесь панике.

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

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

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

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

И дальше проводится обзор того, какие инструменты есть, для чего их можно использовать, какие есть бест-практисы в области ИИ и так далее.

Собственно есть парочка вопросов:

1. Используете ли вы лично какие-то ИИ-инструменты для работы?

2. Требует ли компания от вас, чтобы вы согласовывали использование ИИ?

3. Считаете ли важным регламентировать использование ИИ-инструментов?

4. Есть ли у вас в компании формальные правила использования ИИ в виде регламента?

Дополнительное образование для менеджера в IT

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

Сейчас на рынке есть три дополнительных типа образования для менеджера:

Различные программы MBA для топ-менеджеров и руководителей. Все это стоит от 1,1 миллиона рублей и выше, занимает примерно год и проводится ведущими вузами столицы, включая Сколково. https://www.skolkovo.ru/programmes/skolkovo-mba

Изучив программы, пришло понимание, что это для ребят, кто метит в CEO и CTO позиции, для тимлидов и юнит-лидов выглядит избыточно.

Программы профессиональной переподготовки от ведущих вузов столицы. Тут в целом программа ложится на рабочие обязанности классического "проект-менеджера" и выдается официальный диплом вуза о переподготовке.

Однако, изучив программы, пришло понимание, что во многих местах все делается через образовательный портал в заочном формате с тестами для галочки. И не выглядит, что там ты реально сможешь получить что-то большее, чем прочитав книгу "Настольная книга проект-менеджера". Исключением является программа от БАУМКИ, где все выглядит серьезно, но и цена — 130 тысяч рублей. https://do.bmstu.ru/napravleniya-obucheniya/upravlenie-proektami/upravlenie-it-proektami-v-it/

Курсы менеджеров в IT от частных контор. Это Стратоплан, Отус, Скиллбокс, Нетология, Яндекс Практикум и другие курсы. Естественно, это все — неофициальные сертификаты, которые котируются исключительно субъективно. Где-то отзывы хорошие от людей, прошедших курсы, а где-то говорят, что курсы были бесполезными, с информацией не большей, чем в рядовой книге. https://stratoplan-school.com/team/

Что по итогу:

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

Почему нам нужна смелость и безрассудство

После того как человек сталкивается с какой-то критической ситуацией, где его технические или организационные решения привели к проблеме, которая стоила команде много времени и сил на устранение, он может словить антипаттерн: «Замороженный троглодит».

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

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

Или когда отдел продукта просит выкатить какой-то новый функционал, который в целом ОК, но без тщательного регресса, который может сорвать запланированные активности, человек боится давать добро, хотя все бизнес-кейсы проверены, остаётся лишь место неожиданности.

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

Чтобы преодолеть появление этого антипаттерна, необходимо:

1. Снизить значимость ошибки. То есть если все регламенты выполнены, задача прошла тестирование, но при выкатке случилась какая-то проблема, то окей — это допустимый риск, с которым мы готовы работать. Это не повод вызывать команду и отчитывать её за ошибку.

2. Проговаривать значимые риски. Если вы соглашаетесь делать работу, которая может вызывать проблему, то проговорите три-четыре самых крупных риска и регламент компенсационных работ. Если после разговора не возникает ощущение, что это слишком опасно, — вперёд!

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

4. Решение нетипичных ситуаций — тоже опыт. Когда человек поймёт две-три ситуации, когда нужно было разбираться с кодом, который как-то неправильно работает на продакшене, то в четвёртый раз он уже без стресса сможет оперативно решить проблему, ведь он будет к этому готов.

Но к чему геройство…

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

Должен же тимлид смотреть Merge Request (Pull Request)? 

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

• контролировать качество кода программистов команды;

• следить за соблюдением принятых стандартов;

• управлять рисками кодовой базы команды;

• обучать участников команды через ревью их кода;

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

Однако что делать, если у вас кросс-функциональная команда, состоящая из двух бэкендеров, пары фронтендов, QA и аналитика? Нужно ли вам просматривать все их MR? Сможете ли вы адекватно оценить код на PHP, код на React + TypeScript и автотесты на Python? Очевидно, что нет. 

Для разрешения данной ситуации вы можете:

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

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

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

 Как поступить?

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

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

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

То есть программисты из других команд могут не разбираться в вашем домене, но они способны проверить, что код не делает ничего лишнего и корректно функционирует в рамках проекта (при нагрузке, сущностях, подходах). А факт рандомности ревьювера и фиксации апрува, не позволит им проводить ревью формально.

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

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

P.s. Рекомендую: Эволюционная архитектура - автоматизированное управление программным обеспечением - Нил Форд`

Как тимлиду работать со своим руководителем (engineering manager)

Проактивное донесение информации

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

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

Обсуждайте свой перфоманс

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

2. От чего зависит ваша продуктивность (какие показатели от вас ожидают). Тут мы уже переходим к числовым оценкам, а не каким-то субъективным впечатлениям. Чтобы вы могли улучшать свою работу, вам нужны эталонные значения и ваши текущие цифры.

Составляйте отчеты

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

Показывайте, что вы можете брать на себя ответственность

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

После того, как вы становитесь лидом, у вас резко возрастает объем информации, который нужно обрабатывать. В этом помогут следующие инструменты:

Календарь. Используйте его, чтобы планировать встречи со своей командой, проводить встречи один на один, общаться с другими отделами в ходе согласований, бронировать время для себя (обед или сессия какой-либо работы). Обязательно используйте автоматические напоминания. Главное помните, что календарь - это не список дел.

To-Do-List. Создавайте приортизированные списки дел, которые необходимо выполнить в течение дня или недели. Заносите туда даже самые банальные вещи, которые кажутся глупыми: "Проверить борду спринта". Чем меньше вы будете держать в голове, тем проще вам будет сосредоточиться на деле.

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

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

Сделайте работу с этими инструментами ежедневным ритуалом, и вам станет гораздо легче работать.