Блог Никиты Ульшина

Тридцать замечаний LLM ради одного нужного вопроса

Wed, 07 Oct 2026 00:00:00 GMT

Недавно я отдал LLM описание фичи и получил 30 замечаний. Полезным оказалось одно. Но если бы мы его пропустили, переделка после реализации, по моей оценке, стоила бы 3–4 дня разработки. На ревью всех замечаний у меня ушло около получаса.

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

Почему именно аналитика? Неясное поведение затрудняет декомпозицию, оценку и тестирование. А уточнение фичи после реализации может стоить очень-очень дорого. О том, почему полезно душнить над деталями, я уже писал ранее.

Конечно, раннее уточнение тоже требует времени. Какие-то неизвестные вещи всё равно вылезут только при реализации. Если слишком сильно увлечься аналитикой, можно потерять больше времени, чем сэкономить.

Для начала достаточно вгрузить аналитику в контекст и поставить модели конкретную задачу:

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

Можно добавить вопросы, которые направят проверку:

Что должно произойти, если операция выполнена лишь частично?
Одинаково ли описано поведение для разных участников и компонентов?
Какой результат позволит однозначно проверить, что эта фича работает?

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

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

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

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

Sun, 04 Oct 2026 00:00:00 GMT

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

Какие-то идеи захватывают внимание и воображение, некоторое время радуют интеллект – но исчезают, не оставив следа в поведении и восприятии мира. А другие же подобны взрыву гранаты в голове, после которого мозг приходится пересобирать заново. В чём же разница между ними?

Раньше я наивно думал, что любую идею можно насильно «запихнуть» себе в голову. Я искал и изучал техники эффективного обучения, активно применял их в жизни – а воз быстрее от этого не двигался. Ни написание мешка заметок (и даже эссе), ни практика с последующей рефлексией не помогали долгосрочным изменениям поведения.

Интеллектуального интереса недостаточно для изменений

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

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

Конечно, у этого есть свои плюсы. Мой кругозор стал очень широким и я легко мог оперировать множеством различных идей, поддерживая интересные дискуссии. Но на словах-то мы все Львы Толстые, не так ли?

Продолжив размышлять, я осознал ещё одну ключевую вещь. И заключалась она в том, что…

Трансформационные идеи не приходится «запихивать» себе в голову

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

И никогда, ни разу мне не пришлось такую идею «запихивать» себе в голову. Скорее уж наоборот: эти идеи так «чесали череп изнутри», вызывали такой интеллектуальный дискомфорт, что мне буквально приходилось искать возможность дать им выход.

Выходили эти идеи в виде заметок, эссе, докладов, обсуждений и приседания на уши жене с очередной гениальной мыслью (Даша, спасибо, что терпишь мои «приходы» все эти годы). Я называл их «идеи-котики», потому что как котик приходит в дом и селится там, не спрашивая разрешения, так и эти идеи врывались в голову без стука и оставались в ней навсегда.

Но было и ещё одно отличие…

Трансформационные идеи делают больно

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

А идеи, повлиявшие на меня, могли даже не быть интересными. Зато они «макали меня носиком» в какие-то вещи, которые я раньше не замечал (или отказывался замечать). Каждая из таких идей наступала мне на больную мозоль и заставляла чувствовать себя не очень хорошо (никогда не забуду, как впервые прочитал про дихотомию контроля у стоиков и увидел, сколько переживаний у меня вызывают неподвластные мне вещи). Интересными они становились со временем (и то далеко не всегда).

Стоит уточнить, что под «болью» я подразумеваю состояние дискомфорта, которое вызывает осознание идеи. Оно может проявляться в виде раздражения, печали, местами даже подавленности или просто в мысли «Господи, как мне дальше жить после осознания этого».

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

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

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

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

Как я понял, что пора внедрять агентов в разработку

Fri, 02 Oct 2026 00:00:00 GMT

Меня долго беспокоил простой вопрос: как ограничивать агентов и вести с ними продолжительную командную работу над большим проектом? Поэтому с внедрением я не спешил. Но продолжал наблюдать, что меняется.

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

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

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

В итоге индустрия ответила: появились SDD, гардрейлы, сендбоксинг и ещё много чего. Работа с агентами стала безопаснее, а сам процесс разработки обогатился подходящей методологией и полезными артефактами на будущее. Для меня критерием готовности оказалось не то, что модели стали лучше писать код, а то, что появились способы ограничивать, направлять и проверять их работу.

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

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

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

Озвученная дата автоматически становится обязательством

Wed, 30 Sep 2026 00:00:00 GMT

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

Происходит это обычно так:

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

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

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

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

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

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

Технофитнес: как эффективно прокачивать hard skills

Mon, 28 Sep 2026 00:00:00 GMT

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

О чём выступление

Какие заблуждения о развитии hard skills усиливают тревогу.
Почему технические навыки полезнее рассматривать как набор отдельных умений, а не как единый показатель формы.
Как выбирать навык и строить под него образовательную траекторию.
Как получать технический рост из code review, RFC, менторства и других рабочих задач.
Как работать с книгами, статьями, конференциями и LLM без бесконечного накопления информации.

Доклад записан в ноябре 2025 года. За прошедшее время LLM стали заметно сильнее, поэтому детали построения образовательного трека я бы сейчас уточнил. Основной принцип не изменился: сначала нужно понять, какой конкретный навык и для какой задачи вы развиваете, а уже потом выбирать источник и способ практики.

«Масштабированный скрам. Как организовать гибкую разработку в крупной компании», Крэг Ларман, Бас Водде

Fri, 25 Sep 2026 00:00:00 GMT

Одна из моих текущих задач — выстраивание процесса разработки на несколько команд в одном продукте с последующим масштабированием этих практик на все остальные продукты, разработкой которых я управляю. В прошлый раз при решении этой задачи я умудрился переизобрести LeSS (Large-Scale Scrum). В этот раз я не стал мудрить и решил использовать те практики, которые уже хорошо себя зарекомендовали.

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

О чём книга

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

Три идеи, которые я забрал себе

При масштабировании делить нужно работу, а не продукт. LeSS предполагает, что все команды работают в едином продуктовом бэклоге и едином ритме, а с требованиями помогает справиться единый владелец бэклога. Такой подход помогает не превратить команды в отдельные «мини-продукты со своим миром». Меня эта идея зацепила тем, что при масштабировании очень легко неосознанно размножить локальные бэклоги и получить несколько правильных приоритетов одновременно. Общий бэклог заставляет выбирать, что важнее для продукта целиком.
В LeSS менеджер становится не просто «передастом» работы, а учителем. Задача менеджера — распространять правильные паттерны мышления и по сути выращивать культуру организации. Поэтому от менеджеров в LeSS ожидается, что они будут целенаправленно уделять время обучению и коучингу своих людей. Это та работа, которая (по моим личным ощущениям) даёт огромный профит с точки зрения человеческих ресурсов: сотрудники получают положительное внимание и растут.
Задача команды — поставить фичу клиенту. Фича — это единица ценной функциональности. Здесь речь уже о границе ответственности. В функционально разделённых организациях я многократно встречал ситуацию: бэкенд закончил свою часть, передал работу дальше и формально всё сделал правильно, только клиент ценности не получил. При этом за фичу целиком уже никто не отвечает.

Мои впечатления

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

В книге смешались в кучу кони, люди, «Дао Toyota», ТОС, теория массового обслуживания и ещё невесть что. При чтении книга показалась мне несвязной и слабо структурированной. К счастью, навыки предварительного анализа и скимминга сэкономили мне кучу времени.

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

Не повторяйте моих ошибок. Если вам вдруг нужно внедрить LeSS (или вы просто хотите познакомиться с ним) — вот два замечательных ресурса:

LeSS Brochure — краткое, но ёмкое и наглядное описание LeSS в 8 страниц.
LeSS Rules — буквально шпаргалка по LeSS.

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

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

Mon, 21 Sep 2026 00:00:00 GMT

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

Я люблю читать книги.

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

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

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

⭐️ Что такое «усвоенная идея»?

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

Для меня «усвоенная идея» – это идея, которая настолько прочно встроилась в мою голову, мышление и систему ценностей, что начала влиять на моё поведение, решения и мировоззрение. По сути, это идея, ставшая частью меня самого.

Примером такой усвоенной идеи являются «толстые хвосты» из творчества Нассима Талеба. В своих книгах он часто говорит о нелинейной природе вероятности, а «толстыми хвостами» называет маловероятные события (находящиеся слева/справа на кривой нормального распределения) с аномально мощными последствиями. Переварив эту идею, я перестал смотреть на маловероятные события только с точки зрения вероятности их наступления и начал задумываться ещё и о рисках, которые они создают (въедливый читатель тут к месту упомянет «чёрных лебедей» и будет прав, но это эссе не о теории вероятности в жизни).

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

⭐️ Область усвоения идей

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

Тогда я задумался: а что же кардинально отличало те идеи, которые залетели мне в голову и крепко там засели? Ответ пришёл в виде книги Оливера Беркмана «Четыре тысячи недель на всё», которая внезапно потрясла меня и дала возможность поискать ответ на вопрос выше. Ведь потрясение не на ровном месте произошло.

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

Из этой ситуации я вывел следующую гипотезу: усваиваются только те мысли и идеи, которые попадают в существующее напряжение в жизни. Этим напряжением может быть сильная личная потребность найти ответы, дискомфорт, боль, затруднение, недопонимание. Но главная отличительная черта напряжения – высокая степень личной значимости.

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

// Неплохо я развлекаюсь на выходных, да? :)

С агентами «я не знаю» перестало означать «я не могу»

Fri, 18 Sep 2026 00:00:00 GMT

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

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

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

Благодаря этому я перестал прокрастинировать многие задачи на автоматизацию. Например, наконец-то поигрался с DevEx на пет-проекте и нормально запустил интеграционные тесты в монорепозитории с микросервисами. Раньше откладывал это с мыслью: «Опять в Bash лезть».

Этот пример не делает меня универсальным специалистом. Он показывает, насколько дешевле стало осваивать соседние инструменты.

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

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

Coding agents упёрлись в SDLC

Thu, 17 Sep 2026 00:00:00 GMT

+240% коммитов, +30% релизов: coding agents упёрлись в SDLC

В сентябре NBER опубликовал работу о влиянии AI-инструментов на разработку. Авторы сопоставили публичную активность более 500 тысяч разработчиков на GitHub с телеметрией этих инструментов. У пользователей автономных агентов оценённый накопительный эффект на число коммитов достиг 240%. На уровне проектов он составил 80%, на уровне релизов — 30%.

Разрыв важнее самой большой цифры. Агент может быстро написать код, но изменение ещё нужно проверить, встроить в систему и выпустить. По мере распространения coding agents, то есть агентов программирования, узким местом становится весь цикл разработки и поставки ПО. Обычно его называют SDLC.

240% внизу цепочки, 30% наверху

Работа NBER (https://www.nber.org/papers/w35275) охватывает несколько поколений AI-инструментов. По мере перехода от автодополнения к интерактивным и автономным агентам оценённый эффект на число коммитов рос. Выше по производственной цепочке прирост быстро сдувался.

Наблюдаемый результат	Оценённый накопительный рост
Коммиты	на 240%
Проекты	на 80%
Релизы	на 30%

Оценённое изменение активности после внедрения разных поколений AI-инструментов: эффект резко уменьшается по мере движения от написанных строк к релизам. Результаты показаны накопительно — от autocomplete к синхронным и затем автономным агентам. Для автономных агентов отдельной оценки числа релизов нет, поскольку релизы измерялись на уровне репозитория. Источник: Mert Demirer, Leon Musolff и Liyuan Yang, «Writing Code vs. Shipping Code», NBER Working Paper 35275, редакция сентября 2026 года.

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

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

У исследования хватает ограничений. Оно наблюдательное. Пользователей AI сопоставляли с разработчиками, похожими по прошлой активности, в той же календарной неделе годом ранее. Часть телеметрии закрыта, а публичный GitHub плохо представляет внутреннюю разработку компаний. Двое авторов раньше работали в Microsoft и сейчас консультируют компанию.

При всех оговорках мне нравится выбор верхней метрики. Авторы посмотрели на проекты с релизами, а не остановились на числе коммитов. Коммит описывает пользу разработки примерно так же, как число деталей на сборочном участке описывает выпуск автомобилей. Если сборка и контроль качества не успевают, деталей становится больше. Готовых машин — почти нет.

Очередь уже видна в ревью

LinkedIn столкнулся с похожим эффектом у себя. Вместе с объёмом кода от агентов росло время до первого человеческого ревью у самых медленных десяти процентов запросов. Компания построила собственную систему проверки кода (https://www.linkedin.com/blog/engineering/ai/high-signal-ai-code-review-that-adapts-to-your-codebase-at-scale). За обычную неделю она проводит больше 79 тысяч ревью примерно для 40 тысяч запросов на слияние кода в 7,5 тысячи репозиториев.

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

Production-инфраструктура AI Code Review в LinkedIn: события из GitHub проходят через устойчивую очередь и Kubernetes worker pool, где параллельно работают multi-agent reviews. За обычную неделю система проводит больше 79 тысяч ревью примерно для 40 тысяч запросов на слияние кода в 7,5 тысячи репозиториев. Источник: LinkedIn Engineering, Figure 3.

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

Работа переехала из написания в проверку

Лонгитюдное исследование разработчиков (https://arxiv.org/abs/2605.23135) помогает понять, чем теперь занят человек. Авторы провели два опроса с интервалом в шесть месяцев. В первой волне осталось 158 подходящих участников, во второй — 101, а сопоставимую выборку составили 95 человек.

82% опрошенных пользователей AI сообщили, что тратят меньше времени на написание кода. Статистически значимым оказался общий сдвиг от создания к проверке. Рост каждого отдельного вида проверочной работы подтвердить не удалось. Авторы назвали новый набор занятий supervisory engineering. Человек направляет агента, оценивает результат и исправляет ошибки.

Опрос измеряет восприятие участников, а данные собирали в 2024 и 2025 годах. Инструменты с тех пор успели измениться. Но результат согласуется с главным ограничением из работы NBER. Генерация кода ускоряется сильнее, чем человеческая проверка.

Ту же картину показала DORA в исследовании 2025 года (https://dora.dev/research/ai/gen-ai-report/dora-impact-of-generative-ai-in-software-development.pdf) на ответах почти пяти тысяч специалистов. Рост использования AI на 25% был связан с ускорением ревью кода на 3,1%. При этом пропускная способность поставки снизилась на 1,5%, а стабильность — на 7,2%.

DORA тоже использовала опрос и статистическую модель, поэтому причинность здесь не доказана. Авторы предполагают, что AI увеличивает размер изменений. Код появляется быстрее, партии растут, крупные изменения дольше проверяются и чаще ломаются. Старый совет выпускать маленькими порциями от этого стал полезнее.

Есть и неудобный контрпример. В рандомизированном эксперименте METR (https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) 16 опытных разработчиков открытых проектов выполнили 246 реальных задач. С AI-инструментами начала 2025 года они работали на 19% медленнее, хотя сами считали, что ускорились. Более поздний эксперимент METR (https://metr.org/blog/2026-02-24-uplift-update/) дал слабый сигнал ускорения, но исследователи признали оценку ненадёжной из-за отбора участников и параллельной работы с агентами.

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

Агент становится частью производственной системы

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

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

Личный инструмент	Управляемая часть SDLC
Инструкция в текущей сессии	Версионированная спецификация и критерии приёмки
Контекст одного разработчика	Общий контекст продукта с правилами доступа
Права пользователя	Минимальные права и изолированная среда
Проверка внимательностью автора	Автоматические проверки и ревью по уровню риска
Смена модели без отдельного контроля	Тесты качества и постепенное развёртывание
Оценка по времени и числу запросов	Оценка по релизам, стоимости и повторной работе

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

Atlassian описывает тот же сдвиг со стороны управления процессом. В опросе более 1100 инженеров и руководителей разработки (https://www.atlassian.com/blog/company-news/the-agentic-pivot) 94% руководителей сообщили, что их организации используют AI. 74% увидели ускорение генерации кода, но 78% команд продолжают проверять выросший поток обычным ревью коллег.

По тому же опросу, 88% руководителей считают нужной управляемую инженерную систему для AI. Построили её 19%. Ещё 6% сообщили о формальном и широком внедрении AI как стандарта во многих частях SDLC. У второй цифры критерий строже, поэтому напрямую сравнивать их нельзя.

Следом Atlassian анонсировала управляемые циклы работы агентов (https://www.atlassian.com/blog/jira/governed-agent-loops), общий контекст кода, централизованные стандарты, автоматическую выдачу задач, проверку изменений и метрики. На момент анонса часть возможностей находилась в открытой бете, часть была доступна по приглашениям.

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

Что должно находиться вокруг агента

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

1. Описанная задача

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

2. Общий контекст

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

3. Граница исполнения

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

4. Проверки

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

5. История решений

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

6. Обратная связь после релиза

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

Метрики для нового узкого места

Скорость агента мало говорит о скорости поставки. Полезнее измерять потери между стадиями.

Агент принял задачу.
Создан запрос на слияние кода.
Автоматические проверки прошли.
Изменение принято после ревью.
Изменение попало в релиз.
Релиз обошёлся без отката и последующего исправления.

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

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

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

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

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

Новые исследования и практические примеры такой инфраструктуры я складываю в телеграм-канал «Никита Ульшин про IT» (https://t.me/ulshinblog). Там же буду разбирать, как меняется работа инженеров и руководителей по мере взросления coding agents.

Два ИИ-радара для наблюдения за IT-индустрией

Wed, 16 Sep 2026 00:00:00 GMT

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

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

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

искать изменения, уже созревшие и способные повлиять на мои решения;
ловить ранние сигналы того, что может изменить практику через 6–12 месяцев.

Поэтому теперь у меня два радара:

«Значимые изменения» ищет доказанное «Было → стало» и приносит максимум три результата;
«Ранние сигналы» собирает проверяемые гипотезы и оценивает их потенциальное влияние.

Оба радара помнят контекст предыдущих выпусков и не повторяются. Промпты лежат в конце поста.

Как отличаются результаты

Выход этих промптов мне уже нравится. Например, на этой неделе оба радара зацепились за agentic development, и разница между ними хорошо видна.

Значимое изменение: агенты превращаются в управляемую часть SDLC. Исследование NBER показывает, что ускорение написания кода вскрывает ограничения на остальных этапах, а другое исследование — что работа разработчика смещается к направлению и проверке AI. Появляются и инструменты управления этим процессом — например, governed agent loops от Atlassian. Для меня это означает, что пора подзабить на скорость написания кода и сосредоточиться на инфраструктуре агентной разработки.

Ранний сигнал: проверка становится главным ботлнеком агентной разработки. Генерация дешевеет, но review, тестирование, контроль безопасности и архитектуры масштабируются хуже. Гипотеза радара: через 6–18 месяцев команды будут отличаться не моделью, а качеством своего harness — спецификаций, проверок и ограничений. Эта мысль совпадает с тем, что мне принёс радар значимых изменений.

Конечно, LLM может что-то пропустить. Но прочитать весь поток самостоятельно я всё равно не смогу (и не хочу). Настройка заняла у меня несколько недель, зато теперь два выпуска отнимают 30–40 минут в неделю и оставляют время поразмыслить над найденным.

Промпты

Промпт «Значимые изменения»


# Значимые изменения

Подготовь еженедельный дайджест «Значимые изменения в IT».

## Цель

Ты — мой фильтр значимых изменений в IT-индустрии.

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

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

Единица анализа — изменение, а не новость или релиз. Лучше найти 0–3 значимых изменения, чем перечислить 15 интересных событий. Отсутствие значимых изменений — нормальный результат.

Главный критерий: высокий signal/noise ratio при низкой стоимости чтения.

## Период и состояние наблюдения

Ищи новые события после предыдущего успешного запуска. Если предыдущий запуск недоступен, используй последние 7 дней.

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

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

Для проверки кандидатов используй контекст последних 30 дней по adoption, production cases, independent experience и benchmarks. При необходимости смотри до 90 дней назад, чтобы проверить наличие структурного сдвига. Не проводи три отдельных исследования.

## Этап 1. Широкий scan

Поверхностно проверь каждую область:

- AI-assisted engineering;
- architecture и distributed systems;
- databases, storage и data infrastructure;
- cloud, compute, networking и runtime infrastructure;
- platform engineering, CI/CD, build systems и DX;
- observability, reliability и incident engineering;
- security и software supply chain;
- languages, compilers и runtimes;
- testing, verification и correctness;
- engineering productivity, organization и SDLC;
- standards, protocols и interoperability;
- hardware/software boundary и economics вычислений.

Защищайся от AI-bias: плотность публикаций не означает значимость изменений. Проверь сопоставимые non-AI сигналы и оценивай их по тем же критериям.

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

## Этап 2. Отбор кандидатов

Перед глубоким исследованием сформулируй для кандидата:

- что было раньше;
- что стало теперь;
- какое решение, практика, trade-off или economics могли измениться.

Если содержательного «Было → стало» нет, отбрось кандидата.

При оценке учитывай:

- Practice change;
- Magnitude;
- Evidence;
- Reach;
- Persistence;
- Trade-off shift;
- Economics.

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

Считай шумом:

- minor releases;
- небольшие benchmark improvements без практических последствий;
- fundraising и partnerships;
- product announcements без изменения практики;
- wrappers;
- demos и previews без evidence;
- frameworks без adoption;
- viral repositories;
- social trends;
- одиночные мнения.

## Этап 3. Проверка evidence

Глубоко исследуй только кандидатов, прошедших первичный фильтр.

Для подтверждения факта изменения предпочитай:

- официальную документацию и release notes;
- repositories и issues;
- standards и regulatory documents;
- academic papers;
- технические whitepapers с прозрачной методологией.

Для подтверждения значимости ищи:

- production case studies;
- postmortems;
- независимые benchmarks;
- воспроизводимые эксперименты;
- независимый engineering experience;
- adoption data;
- industry research;
- измеримые economics и operational consequences.

Разделяй доказательство факта и доказательство значимости. Источник производителя может надёжно подтвердить release, pricing, deprecation или breaking change, но не собственную значимость. Vendor whitepaper без прозрачной методологии считай слабым evidence.

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

## Классификация

### A — значимое изменение

Присваивай A, только если одновременно выполнены условия:

- есть содержательное «Было → стало»;
- изменились практика, решение, trade-off или economics;
- появилась новая дельта после прошлого запуска;
- влияние достаточно широкое или устойчивое;
- есть минимум два разных типа evidence;
- хотя бы одно подтверждение независимо от автора или производителя изменения.

### B — перспективный сигнал

Присваивай B, если потенциальное влияние велико, но пока не хватает одного или нескольких оснований для A:

- adoption;
- production evidence;
- независимого подтверждения;
- масштаба;
- устойчивости;
- ясного изменения практики.

### C — шум

К C относится всё, что не прошло порог A или B. Пункты C в дайджест не включай.

При сомнении выбирай более низкую категорию.

## Hard triggers

Отдельно отмечай события, требующие внимания независимо от A/B:

- критические vulnerabilities;
- breaking changes;
- deprecations;
- существенные изменения pricing, limits или access;
- применимое regulation.

Включай Hard trigger, если он относится к известному из контекста стеку или продукту. Не угадывай используемый стек. Если стек неизвестен, включай только общеотраслевые Hard triggers.

Для подтверждения факта Hard trigger достаточно авторитетного первичного источника. Отдельно укажи неопределённость последствий, если независимого evidence ещё нет.

## Формат выпуска

Время чтения — 5–10 минут.

Максимум:

- 3 изменения категории A;
- 2 сигнала категории B;
- короткий раздел Hard triggers при необходимости.

Если изменений категории A нет, начни ответ точной фразой:

«Значимых изменений за период не обнаружено.»

После неё можно вывести перспективные сигналы и Hard triggers.

### Для каждого A

1. Название и зрелость.
2. Что изменилось, включая «Было → стало».
3. Влияние на практику и решения.
4. Industry significance и relevance для технического руководителя и инженера.
5. Evidence, ограничения и причина классификации A.
6. Дельта относительно прошлого наблюдения.
7. Действие: игнорировать, наблюдать, экспериментировать, планировать изменение или действовать сейчас.
8. От 2 до 5 сильных источников.

### Для каждого B

1. Что наблюдается и какое изменение может за этим стоять.
2. Почему potential impact велик.
3. Чего не хватает для A.
4. Что подтвердит или опровергнет сигнал.
5. Дельта и рекомендуемое действие.
6. От 1 до 3 источников.

### Для Hard trigger

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

Заверши короткой строкой:

«Охват: X/12 областей. Пробелы: нет / список непроверенных областей и причина.»

## Финальная проверка

Перед ответом удали каждый пункт, у которого нет:

- содержательного «Было → стало»;
- изменения решения, практики, trade-off или economics;
- новой информации относительно прошлых выпусков;
- evidence, соответствующего заявленной категории.

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

Промпт «Ранние сигналы»


# Ранние сигналы

Подготовь выпуск «Радар ранних сигналов в software engineering и IT-индустрии».

## Цель

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

Ищи ранние технические траектории, которые через 6–18 месяцев могут заметно повлиять на:

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

Единица анализа — гипотеза об изменении, а не новость, релиз или новая технология.

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

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

## Период и горизонт

Ищи новую информацию после предыдущего успешного запуска. Если предыдущий запуск недоступен, используй последние 7 дней.

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

Основной горизонт гипотезы — 6–18 месяцев. Более далёкие идеи включай только при очень высоком potential impact и уже наблюдаемой технической траектории. Не рассматривай прогнозы на 5–10 лет.

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

## Этап 1. Широкий scan

Поверхностно проверь каждую область:

1. AI-assisted engineering;
2. architecture и distributed systems;
3. databases, storage и data infrastructure;
4. cloud, compute и networking;
5. platform engineering и developer infrastructure;
6. reliability, observability и operations;
7. security и software supply chain;
8. programming languages, compilers и runtimes;
9. testing и verification;
10. standards, protocols и interoperability;
11. hardware/software boundary;
12. engineering productivity и organization.

AI — одна из областей, а не основной источник сигналов. Перед финальным отбором проверь сопоставимые non-AI области по тем же критериям. Не вводи искусственную квоту: все итоговые сигналы могут относиться к AI, если они действительно сильнее.

Заверши scan, когда все 12 областей проверены поверхностно и каждый найденный кандидат либо отброшен, либо передан на проверку.

## Этап 2. Формирование гипотез

Хороший ранний сигнал указывает хотя бы на одно из изменений:

- новая capability;
- новый workflow;
- новая primitive или abstraction;
- повторяющийся паттерн у независимых игроков;
- снятие фундаментального ограничения;
- смена архитектурного trade-off;
- изменение economics;
- новый failure mode или риск;
- новый ecosystem pattern;
- research result с практическим следствием.

Для каждого кандидата сформулируй:

1. Наблюдение: какие проверяемые факты появились.
2. Гипотезу: какой структурный сдвиг может происходить.
3. Механизм: почему наблюдение способно привести к этому сдвигу.
4. Bottleneck: какое сегодняшнее ограничение может исчезнуть или ослабнуть.
5. Последствие: какое инженерное решение или практика изменится.
6. Условия проверки: какие события подтвердят или опровергнут гипотезу.

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

Считай шумом:

- очередную AI-модель без новой capability или economics;
- небольшой benchmark gain;
- minor feature;
- viral GitHub repository;
- demo без механизма влияния;
- wrapper;
- framework без новой идеи или ecosystem signal;
- fundraising и partnership;
- opinion, futurology и AGI speculation;
- vendor narrative без технической траектории;
- тему, интересную только своей новизной.

## Этап 3. Проверка

Глубже проверяй только финалистов, способных войти в выпуск или изменить статус watchlist.

Для discovery используй:

- papers и preprints;
- technical whitepapers;
- engineering blogs;
- release notes;
- open-source projects;
- GitHub discussions и issues;
- standards work;
- conference write-ups;
- Hacker News, Reddit и экспертные блоги;
- первые production reports;
- технические demos.

Социальная сеть, demo или заявление производителя могут породить гипотезу, но не должны быть её единственным основанием.

Разделяй:

- факты — должны подтверждаться источниками;
- гипотезу — может иметь низкую уверенность;
- potential impact — оценивается при условии, что гипотеза подтвердится.

Для включения сигнала нужно:

- два слабых независимых признака; либо
- один сильный ранний признак с прозрачным механизмом.

Независимые признаки должны происходить от разных участников или типов evidence, а не пересказывать один анонс. Сильным признаком может быть воспроизводимый технический результат, изменение стандарта, работающая primitive или ранний production case.

Не требуй production-grade evidence. Ищи минимальный набор данных, достаточный для проверки фактов, механизма и текущего статуса. Останови поиск, когда дополнительный источник с низкой вероятностью изменит решение.

## Статусы watchlist

Активные статусы:

- NEW — сигнал впервые прошёл фильтр.
- RISING — появились новые независимые подтверждения или траектория ускорилась.
- STABLE — гипотеза остаётся актуальной, но содержательной дельты нет.

Переходные статусы:

- FADING — adoption не происходит, bottleneck сохраняется, результаты не воспроизводятся или ecosystem не формируется.
- GRADUATED — evidence стало достаточно, чтобы передать сигнал на проверку в основной дайджест значимых изменений.

FADING и GRADUATED сообщай один раз, затем удаляй из активного watchlist. GRADUATED становится кандидатом для основного дайджеста, но не получает категорию A автоматически.

Активный watchlist включает только NEW, RISING и STABLE. Максимум — 10 сигналов.

Не исследуй STABLE заново без новой информации.

## Отбор

В основной выпуск включай максимум три сигнала со статусом NEW или RISING.

Не заполняй лимит искусственно. Если новых или усилившихся сигналов нет, напиши:

«Новых сильных ранних сигналов за период не обнаружено.»

Potential impact оценивай как средний, высокий или очень высокий. Сигналы с низким impact не включай.

Personal relevance оценивай по известному контексту. Не угадывай мой стек или задачи. Если контекста недостаточно, пиши: «не определена».

## Формат выпуска

Весь выпуск должен читаться за 5 минут.

### Ранние сигналы

Для каждого NEW или RISING:

#### [Название гипотезы]

Статус / Potential impact / Уверенность / Personal relevance / Действие

**Что наблюдается:** 1–2 предложения с проверяемыми фактами и независимыми признаками.

**Гипотеза:** возможный структурный сдвиг одним предложением.

**Механизм и bottleneck:** какое ограничение может исчезнуть и почему это становится возможным.

**Если подтвердится:** как изменятся engineering practice или решения через 6–18 месяцев.

**Почему ещё рано:** главные неизвестные, ограничения и причины возможного провала.

**Что наблюдать дальше:** 2–3 конкретных события, которые подтвердят или опровергнут гипотезу.

**Источники:** 1–3 наиболее полезных источника.

Допустимые действия:

- просто наблюдать;
- прочитать первоисточник;
- попробовать за 30–60 минут;
- провести небольшой эксперимент.

### Переходы watchlist

Выводи только изменения:

- `[сигнал] — FADING`, потому что…
- `[сигнал] — GRADUATED`, потому что… Кандидат для основного дайджеста.

Не повторяй здесь RISING: он уже описан в основном разделе.

### Активный watchlist

Покажи до 10 активных сигналов одной строкой на каждый:

`[сигнал] — NEW / RISING / STABLE — следующее наблюдаемое условие`

### Охват

`Проверено: X/12 областей. Пробелы: нет / список областей и причина.`

## Финальная проверка

Перед ответом удали сигнал, если:

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

Убедись, что non-AI области проверены до финального отбора.

ИИ убрал из моей работы передышки

Mon, 14 Sep 2026 00:00:00 GMT

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

В последнее время я снова выкраиваю время на разработку. Что-то удаётся делать на работе, что-то — по вечерам в пет-проекте. Сначала списывал усталость на обычное «руководитель решил ещё и вечером поработать», но эффект повторялся.

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

У меня появилась рабочая гипотеза: ИИ убрал из процесса длинные участки исполнения уже принятого решения, которые всегда были для меня самой лёгкой частью. Из цикла «подумал — написал — протестировал — поревьюил — порефакторил» ушла часть про «написал». Даже тестирование сильно изменилось. Теперь ИИ легко и быстро настукивает код, а на человеке остаются постановка задач, выбор решения, проектирование и анализ результата.

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

Думать и проектировать мне всегда нравилось больше, чем писать код. Но это самая энергозатратная часть работы. Раньше передышкой становилась реализация того, что я уже придумал. Теперь этой передышки нет: из процесса создания ПО выпала часть, где не нужно постоянно анализировать код и требования.

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

Агент может работать без передышки. Я — нет.

Как я возвращаю паузы

Я придумал простое правило: как только запустил задачу в агенте, физически убираю руки от компьютера и встаю. Вместо «ещё одной задачи» разминаюсь, делаю пяток бёрпи, жмякаю кота или приседаю с дочкой на руках.

Ожидание ответа агента ощущается как свободное время, которое можно немедленно заполнить. Руки сами тянутся открыть ещё одну вкладку. Такой режим похож на бег: можно сильно разогнаться на старте, но долго в таком темпе не пробегаешь.

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

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

ИИ должен экономить мои силы, а не помогать мне эффективнее их сжечь.

Я прочитал 150 книг и решил читать меньше

Fri, 11 Sep 2026 00:00:00 GMT

За последние полтора года я прочитал около 150 книг и в итоге решил отказаться от режима «книга в неделю». Большинство прочитанного, по моим ощущениям, не стоило потраченного времени.

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

Осознать проблему мне помогли рождение дочери и «Четыре тысячи недель на всё» Оливера Беркмана. Дочь мощно срезала количество свободных сил, а книга напомнила: я всё равно не успею изучить все интересные идеи в мире. Да и не нужно.

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

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

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

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

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

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

Например, сейчас я размышляю о следующих вещах:

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

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

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

Поднимаем SDD на уровень продукта

Wed, 09 Sep 2026 00:00:00 GMT

Spec-driven development хорошо работает, пока продукт помещается в один репозиторий. У нас это не так: фронт и бэк живут в разных монорепах, а общая фича начала превращаться в две разные спеки.

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

Недавно в OpenSpec появились Stores — отдельные Git-репозитории для общих specs и changes, на которые могут ссылаться кодовые репозитории. Наши бэк и фронт живут в разных монорепах, поэтому модель хорошо ложится на продукт.

На выходе мы получаем довольно интересный docs-as-code:

Аналитик пишет общие proposal и specs.
Разработка и QA ревьюят их и при необходимости добавляют designs и tasks.
Реализация остаётся в репозиториях с кодом.
Где хранить designs и tasks (в общей репе или у каждой команды отдельно), пока не решили — проверим оба варианта.

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

Конечно, OpenSpec — это просто инструмент. Нам всё ещё нужно определить ownership документации, настроить её обновление и написать кастомные скиллы. К тому же Stores пока в бете.

Я же посмотрю на результат через пару месяцев. Если команды продолжат использовать общую спеку при изменении продукта, эксперимент сработал.

Большинство AI-новинок не стоит вашего времени

Mon, 07 Sep 2026 00:00:00 GMT

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

Я уже видел несколько финалов технологического хайпа. Блокчейн почти исчез из повседневной IT-повестки. ML перестал быть магическим словом и стал обычным инструментом для подходящих задач. Микросервисы остались, но вместе с хайпом испарилась вера, что ими нужно обмазать вообще всё (я и сам не раз вливал сервисы обратно в монолит).

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

Как и в любой хайповой теме, новые AI-инструменты появляются быстрее, чем люди успевают их освоить. Большая их часть исчезает из информационного поля раньше, чем успевает пригодиться. Если смотреть не на количество релизов, а на сам процесс разработки, за последний год я вижу мало устойчивых изменений: модели стали лучше писать код, а SDD и harness engineering получили распространение. Всё.

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

Я отстаю не от AI-разработки, а от её новостной ленты и трачу время только на то, что пережило первые несколько месяцев хайпа.

// А вы пробуете новые AI-инструменты сразу или ждёте, пока индустрия отфильтрует шум?

«Четыре тысячи недель на всё», Оливер Беркман

Fri, 04 Sep 2026 00:00:00 GMT

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

О чём книга

Книга заставляет читателя задуматься над вопросом: куда он хочет потратить 4000 недель жизни, которые ему отпущены? Беркман показывает, почему увлечение тайм-менеджментом и продуктивностью без понимания себя — это дорога в никуда и рассматривает альтернативные способы относиться к своему времени.

Три идеи, которые я забрал себе

Мы относимся к времени как к ресурсу, которым можем управлять. Это приводит к тому, что мы стараемся каждую минуту тратить «с пользой» и пилим себя, если текущее действие не приносит выгоды в будущем. Такое отношение заставляет нас жить в будущем, в ожидании того, что однажды все усилия окупятся и всё станет шоколадно. А тем временем жизнь проходит мимо.
Чем более эффективными мы становимся — тем сильнее взвинчиваем требования по эффективности к самим себе. Многие современные инструменты экономят нам время, но мы тут же забиваем его другой работой (все же думали, что мы будем меньше программировать с ИИ?). Поэтому попытки «овладеть своим временем» — это ловушка.
Антипод страха упущенной выгоды (FOMO) — это радость упущенной выгоды. Если бы выбирать было не нужно, ни один выбор не имел бы смысла. Радость появляется, когда сознательно отказываешься от всего остального ради того, что делаешь сейчас.

Мои впечатления

У меня зреет пост о том, что в мире не так много книг, которые стоит читать. Так вот, «Четыре тысячи недель на всё» — одна из таких книг.

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

«Четыре тысячи недель на всё» заставила меня подумать: а что мне на самом деле просто нравится делать? А от чего я могу отказаться и забить? И после этого я впервые за долгое время смог чувствовать себя хорошо, когда укачивал дочь и смотрел финал инта по доте или когда просто вечером играл в PS. Похоже, это продолжение моей старой попытки научиться отдыхать, но Беркман помог лучше понять источник проблемы.

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

Не каждый рабочий день обязан быть великим

Mon, 31 Aug 2026 00:00:00 GMT

Всю прошлую неделю Алису Никитичну мучили газики. О чём она сообщала маме и папе яростным «Уаааа» посреди ночи.

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

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

День с низким уровнем энергии всё ещё может быть полезным. Просто для этого нужно принять своё текущее ограничение. Мне это позволило изменить состав работы: вместо задач типа «подумать» и «покреативить» я переключился на накопившуюся работу с понятным следующим шагом.

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

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

«Шум. Несовершенство человеческих суждений», Дэниель Канеман и др.

Fri, 28 Aug 2026 00:00:00 GMT

Два опытных интервьюера могут поговорить с одним кандидатом и прийти к противоположным выводам, причём оба будут уверены, что оценили его объективно. Почему так?

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

О чём книга

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

Три идеи, которые я забрал себе

Даже в одинаковых ситуациях разные люди выносят разные суждения. Например, судья, выносящий суждение, подвержен своим предубеждениям, предубеждениям коллег, влиянию руководства, голоду и жажде, окружающей среде и ещё множеству факторов. И каждый из них так или иначе влияет на его финальное решение. Эта непредсказуемая вариативность человеческих решений и называется шумом.
«Правило мудрости толпы» хорошо работает для защиты от шума, но его сложно применить в одиночестве. Зато можно применить технику внутренней толпы: вынести суждение, найти несколько правдоподобных объяснений его ошибочности, проанализировать свой первоначальный вывод и дать альтернативный ответ. Этот подход заставляет более широко посмотреть на проблему и снизить влияние шума.
Люди часто используют ответ на более лёгкий вопрос, когда им на самом деле нужно ответить на более сложный. Например, в процессе найма один интервьюер смотрит, насколько человек ему нравится, второй — насколько уверенно человек отвечает, третий — решает ли человек задачу ожидаемым способом. И в результате каждый отвечает на свой вопрос, из-за чего мнения расходятся.

Мои впечатления

«Шум» — это огромное, глубокое, многолетнее исследование того, насколько же плохо мы с вами на самом деле принимаем решения. Канеман и его коллеги рассмотрели проблему шума в решениях со всех сторон (и результаты немного пугают). Можно с уверенностью утверждать, что влияние шума есть в любом человеческом решении, даже самом незначительном.

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

Я считаю «Шум» таким же must read, как и «Думай медленно, решай быстро». Особенно книга пригодится руководителям и всем, кто регулярно нанимает, оценивает людей или принимает решения в условиях неопределённости.

Много аутпута, мало ауткама

Wed, 26 Aug 2026 00:00:00 GMT

Красивая презентация. Вдохновляющая речь. Слово «стратегия» вместо запятой. Завтра мы завоюем весь рынок! А через несколько месяцев оказывается, что воз и ныне там.

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

Делать красивые презентации и рассказывать вдохновляющие речи на самом деле приятно. Это способ почувствовать себя крутым и умным. За такую деятельность часто хвалят: человек выглядит умным и амбициозным ещё до того, как что-то сделал. А ещё это безопасно.

Действовать же рискованно, потому что сразу же появляется множество способов облажаться: Можно получить отказ. Идея может не взлететь. Ключевой человек покрутит пальцем у виска и свалит с проекта. “Ой, а что-то они не покупают наш продукт, а как же так?” Или просто окажется, что навыков для реализации описанных амбиций не хватает.

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

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

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

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

// Ставьте 🗿, если прямо сейчас вспомнили такого стратега.

Кандидатов много, нанять почти некого

Mon, 24 Aug 2026 00:00:00 GMT

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

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

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

А в итоге на входе получаем:

Senior-разработчика, который не помнит, что такое репликация;
человека с тонкой настройкой gRPC в резюме, который не знает про буферизацию;
специалиста с «5 годами опыта на Golang», который не помнит синтаксис языка.

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

Компании в первую очередь сокращают слабых сотрудников — и они оказываются на рынке.
Хорошие специалисты смотрят на рынок и думают: «Ну нахер, я лучше тут посижу спокойно».

Если вдруг вы, как и я, сейчас активно нанимаете, то предлагаю нам просто обняться и страдать. По крайней мере в нашей воронке большой поток не упростил найм, а добавил работы. Но большой поток — не повод нанимать людей, которые не справятся с работой.

Раньше у нас был дефицит откликов. Теперь — дефицит подходящих людей. А это совсем другая проблема.

Дочь против игрового перфекционизма

Sun, 23 Aug 2026 00:00:00 GMT

Я всегда немного недолюбливал игры с открытым миром. Мне всегда хочется выполнить все сайд-квесты, посетить все точки на карте (горите в аду, вопросики на Скеллиге) и собрать все коллекции. Но обычно игра надоедает мне гораздо раньше, чем я успеваю всё это сделать. Например, по этой причине я не прошёл Baldur’s Gate 3 — к третьему акту я уже просто задолбался в неё играть.

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

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

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

В общем, приятно я вчера в Dying Light 2 погонял, рекомендую. А сегодня болею за Team Spirit :)

🧹 — пока на карте остался хоть один вопросик, я не успокоюсь 🏃 — побочки подождут, мне пора спасать мир

An Elegant Puzzle by Will Larson

Fri, 21 Aug 2026 00:00:00 GMT

Блог Уилла Ларсона я почитываю довольно давно. Мне нравится его стиль письма и идеи, которые он высказывает о руководстве техническими подразделениями (и периодически я у него что-то утаскиваю в работу).

Я прекрасно знал, что он написал несколько книг, но при этом не читал ни одной из них. И недавно я решил исправить эту ситуацию, прочитав самую популярную из его книг – «An Elegant Puzzle», о которой я слышал много хорошего от уважаемых людей. Мне всегда интересно посмотреть на управление с новой стороны, а мнение Уилла Ларсона я уважаю, так что книга обещала стать очень интересной.

О чём книга

Уилл Ларсон рассматривает менеджмент (и в частности инженерный менеджмент) как элегантный пазл, в котором нужно аккуратно подбирать нужные кусочки и вставлять их на место. Его книга – это серия таких кусочков, которые читатель может «вставить» в свои проекты.

В книге раскрываются следующие темы:

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

Три идеи из книги

Исправление ситуации в команде – процесс медленный. Команда, которая захлёбывается под потоком задач и грудой технического долга, не сможет стать сверхпроизводительной за месяц. Проблемы команды обладают инерцией: найм, техдолг, процессы и ожидания меняются с разной скоростью, поэтому управленческое решение и наблюдаемый результат разделены месяцами. Руководитель должен запастись терпением и упорно вести команду к лучшей жизни (попутно защищая от попыток разломать всё, что он сделал).
Хороший процесс не компенсирует неправильный состав команды. По сути, поставить правильного человека на правильное место — одна из главных задач руководителя. Например, если вы соберёте команду полностью из джунов и дадите им правильные архитектурные процессы, то на выходе всё равно получится big ball of mud, потому что состав команды не соответствует задаче.
Стратегия — это один из хороших способов выравнивания нескольких команд. Стратегия даёт конкретное направление для того, чтобы преодолеть ограничения выбранной цели, а также даёт общий взгляд на то, чем мы все тут занимаемся. Ларсон регулярно делает отсылки к книге Румельта «Хорошая стратегия, плохая стратегия» (только делает это менее абстрактно и показывает, как её применять на практике). Если команды не выравнивать, то получится лебедь, рак и щука, как в ситуации из предыдущего поста.

Мои впечатления

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

Читать книгу легко и интересно. В словах Уилла Ларсона сквозит огромный опыт, и есть ощущение, что каждый совет из книги он действительно прожил сам (что тоже большая редкость в современном чтиве). При этом книга скорее будет полезна руководителям среднего звена и выше, а не тимлидам – проблемы в ней рассматриваются более верхнеуровневые.

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

Почему быстрые команды не делают организацию быстрой

Wed, 19 Aug 2026 00:00:00 GMT

Один из самых важных показателей команды – это скорость её поставки. Об оптимизации этого параметра все вокруг говорят уже давным-давно (да я и сам целый лонгрид про расшитие бутылочных горлышек написал). Все стараются улучшать качество процессов, CI/CD, развивать своих инжеров.

Но иногда можно заметить забавный парадокс: в подразделении несколько команд, которые прекрасно и быстро работают, но общая поставка всё равно еле ползёт.

Как же так получается?

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

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

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

Граф зависимостей

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

И в этом графе нужно очень хорошо разбираться, потому что производительность подразделения определяется не только скоростью самих команд, но и тем, как они связаны и взаимодействуют между собой. Можно ускорить одну команду на 50% и не получить общего ускорения, потому что она на каждые два дня работы будет неделю ждать смежников.

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

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

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

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

Где проблемы, Лебовски?

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

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

Производительность подразделения зависит не только от высокой производительности каждой команды в отдельности, но и от того, насколько они не мешают друг другу поставлять ценность (кстати, похожую модель хорошо разбирает книга «Team Topologies»). Быстрые команды не обязательно делают организацию быстрой. Иногда главная оптимизация — не ускорить команды, а убрать лишние зависимости между ними.

Как LinkedIn построил AI Code Review на всю компанию

Mon, 17 Aug 2026 00:00:00 GMT

Как LinkedIn построил AI Code Review на всю компанию (https://www.linkedin.com/blog/engineering/ai/high-signal-ai-code-review-that-adapts-to-your-codebase-at-scale)

Последнее время читаю столько хороших технических материалов, что даже подумываю возродить ТехноФитнес — в основной блог они просто не влезают. Сегодня хочу поделиться шикарной статьёй о том, как в LinkedIn построили AI Code Review.

С распространением AI-агентов разработчики начинают писать больше кода, и bottleneck постепенно переезжает в Code Review. В LinkedIn это стало видно по росту P90 времени до первого человеческого ревью. А масштаб там огромный: больше 10к активных репозиториев и десятки тысяч PR в неделю.

Для меня как для руководителя разработки эта тема особенно важна. Если ускорить написание кода, но не масштабировать контроль качества, то либо появится огромная очередь из изменений, либо требования к ревью начнут деградировать (все же делали LGTM на 5к строк, да?). А дальше кодовая база довольно быстро поедет куда-то не туда.

Инженеры из LinkedIn поэтому построили собственную multi-agent систему AI Code Review. Сейчас она делает 79к ревью в неделю примерно по 40к PR, а её рекомендации принимаются разработчиками в 63,9% случаев.

⭐️ Интересные идеи

➡️ Мультиагентное ревью. Главная проблема AI Code Review — не найти максимум замечаний, а не заспамить разработчика мусором. Поэтому несколько независимых агентов параллельно ревьюят PR, а оркестратор объединяет и перепроверяет результаты. Совпадение между моделями повышает confidence. Цена — больше токенов, вычислений и latency.

➡️ Контекст кодовой базы важен. Хороший AI Reviewer должен знать не только язык, но и конкретную систему. В LinkedIn для этого используют трёхуровневую систему правил: глобальные, репозиторные и use-case-specific. Отсюда неприятный вывод: качество AI Review напрямую упирается в качество формализованных знаний о системе (пиши доки, бл&ть!).

➡️ AI Reviewer – это отдельная инженерная система. У него есть SLA, observability, staged rollout и eval перед изменениями. Ревью стартует примерно через 90 секунд, большинство проверок заканчивается меньше чем за 10 минут. Лайки под комментариями авторы считают vanity metric. Вместо этого они проверяют, внёс ли разработчик рекомендацию в merged code. На выборке из 5230 комментариев в 90,1% случаев удалось уверенно определить результат. При этом acceptance rate для logic errors достигает 80%, а для concurrency bugs в их выборке вообще был 100%.

➡️ Feedback loop из продовых инцидентов. LinkedIn хочет анализировать SEV0/SEV1-инциденты и автоматически превращать найденные failure patterns в новые правила Code Review. Получается замкнутый цикл: сломали прод → разобрали причину → научили reviewer ловить похожую ошибку до мержа.

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

Приятного чтения!

➖➖➖➖➖➖➖➖➖➖➖ 📝 @ulshinblog

Team Topologies, 2nd Edition by Matthew Skelton, Manuel Pais

Fri, 14 Aug 2026 00:00:00 GMT

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

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

О чём книга

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

В книге раскрываются следующие темы:

в чём проблема с традиционными структурами команд;
почему так важен закон Конвея и что такое обратный манёвр Конвея;
4 фундаментальные топологии команд;
модели взаимодействия команд между собой;
эволюция оргструктуры под потребности бизнеса.

Три идеи из книги

Думать, что архитектуру можно долго поддерживать в отрыве от структуры команд, — фундаментальная ошибка. Разрыв между архитектурой и структурой команд будет виден на всех уровнях разработки. Я думаю, на этом месте скупую слезу пустят те, кто работает с «отделом корпоративной архитектуры».
Один из ключевых факторов эффективности команд — неблокирующие зависимости. Например, очень сложно эффективно поставлять фичи, если их тестирует отдел QA, который находится чёрт его знает где и имеет свои процессы/приоритеты/взгляд на вещи. Или другая, более частая проблема — неправильно разделённые зоны ответственности, где одна команда вынуждена ждать другую (иногда месяцами). Проблема не в самом наличии зависимостей, а в зависимостях, которые регулярно блокируют поток работы одной команды решениями другой.
Платформенные команды нужны для того, чтобы расчистить путь продуктовым командам и снять с них лишнюю когнитивную нагрузку. Хорошая платформа убирает много трения в процессе разработки и релиза. К сожалению, не все платформы это понимают и навязывают свою «философию», что приводит к аккуратному избеганию их возможностей разработчиками.

Мои впечатления

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

С другой стороны, книга показалась мне удивительно водянистой. Сложилось ощущение, что её ключевые идеи можно было уложить в страниц 20–30, но для издательства нужно было нарастить объём. Поэтому треть книги занимают бесполезные case studies, а сами главы изобилуют историями, восхваляющими Team Topologies.

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

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

Я управляю гневом или гнев управляет мной?

Wed, 12 Aug 2026 00:00:00 GMT

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

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

Несколько месяцев назад я столкнулся с человеком, который блокировал важный для меня процесс. Я несколько раз пытался договориться спокойно: приводил аргументы, отрабатывал возражения, предлагал альтернативы. Не работало. Человек занимал позицию «будет либо по-моему, либо никак».

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

Сработало — не значит правильно

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

И у решения оказалась цена. Процесс я сдвинул, но отношения ухудшил: человек затаил на меня обиду.

Поэтому я не хочу превращать этот случай в управленческую технику «если не слушают — наори». Результат объясняет, почему я так поступил, но не делает способ здоровым или универсальным.

Важна не вечная невозмутимость

После этого случая у меня исчезло убеждение «руководителю нельзя злиться». Теперь для меня важнее другой вопрос:

Я управляю гневом или гнев управляет мной?

Самоконтроль в моей картине мира — не обязанность всегда выглядеть спокойным. Это способность заметить эмоцию, выбрать реакцию и принять её последствия.

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

Как не втягиваться в чужую истерику

Mon, 10 Aug 2026 00:00:00 GMT

А я человек гневливый.

— Джейсон Стэтхем, «Гнев человеческий»

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

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

Проблема этого подхода в ресурсоёмкости. После боя приходится успокаиваться и восстанавливаться, а время, которое могло уйти на работу, пропадает впустую.

Альтернатива от Эпиктета

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

Неумение пользоваться разумом Эпиктет рассматривает не как моральный порок, а как несчастье. На такого человека не нужно злиться — ему можно сочувствовать.

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

Но сочувствие меняет не собеседника, а моё восприятие происходящего. Я действительно могу быть причиной недовольства, однако способ его выражения — не моя ответственность. Это понимание снижает желание дать сдачи.

Человеку в истерике сложнее рассуждать и воспринимать логику. Поэтому сначала нужно вывести разговор из эмоций, а уже потом продолжать обсуждение. На практике способы разные:

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

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

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

Вернуться к своим целям

Когда истерика приходит не от конкретного собеседника, а из всего инфополя, мне помогают два вопроса:

Как эта информация влияет на мои цели и средства их достижения?
Что мне нужно сделать в связи с ней?

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

Эти вопросы не запрещают эмоции. Они помогают отделить то, что требует действий, от того, что просто съедает внимание.

Engineering Leadership: The Hard Parts by Juan Pablo Buriticá, James Turnbull

Fri, 07 Aug 2026 00:00:00 GMT

Название этой книги заставило меня улыбнуться, потому что я искренне сомневаюсь, что в работе руководителя есть «easy parts». В работе руководителя очень много трудностей – кризисы, дедлайны, разгребание бардаков (в некоторых случаях оставленных предыдущим руководителем). И во всём этом нужно сохранять спокойствие и человечность.

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

О чём книга

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

В книге раскрываются следующие темы:

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

Три идеи из книги

Хаос – это не только стресс и боль, но ещё и кузница сильнейших профессионалов. Можно годами управлять даже очень большой, но статичной структурой и ничему толком не научиться. Буквально один год в хаосе может дать больше, чем пять лет обычной работы.
Главный риск в хаосе – это не ошибка, а бездействие. В хаотичном окружении бывает довольно трудно направлять команду, потому что всё вокруг постоянно меняется. Но если у команды вообще нет никаких целей, то любые потрясения будут бить по ней ещё сильнее. Поэтому лучше иметь хоть какие-то цели и адаптировать их под обстоятельства.
Команды выгорают не от тяжёлой работы, а от бессмысленности происходящего. Люди могут выдерживать сложные, нагруженные недели и овертаймы, если понимают, ради чего они стараются. Если смысла в работе нет, то команда скатится в постоянное тушение пожаров и выгорание.

Мои впечатления

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

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

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

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

Книгу рекомендую к прочтению. Мне было полезно.

Как закончить спор, в котором оба правы

Mon, 03 Aug 2026 00:00:00 GMT

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

Конфликты и споры внутри команды нормальны. Как пишет Патрик Ленсиони в книге «5 пороков команды», отсутствие конфликтов может означать, что участникам вообще всё равно, что происходит. Это хуже самого спора.

Проблемы начинаются, когда конфликт:

затягивается;
переходит на личности;
затрагивает всё больше участников.

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

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

Я прервал перепалку и напомнил несколько вещей:

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

После этого спор, длившийся почти час, сошёл на нет. За следующие десять минут коллеги договорились.

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

Простая техника, которая снижает накал эмоций

Mon, 27 Jul 2026 00:00:00 GMT

Недавно я писал обзор на книгу Дэвида Бернса «Терапия настроения». Сама книга мне очень понравилась, и я зацепил из неё несколько практических идей для тестирования.

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

Бернс в книге предлагает несколько практик для того, чтобы эффективно работать с такими состояниями. Одна из них — метод «трёх колонок». Она предназначена для того, чтобы в моменты сильных чувств суметь их проанализировать, выявить искажения и тем самым снизить градус накала.

Суть её очень проста. В сложном/негативном состоянии нужно:

Записать ситуацию в двух словах (что конкретно произошло).
В первую колонку выписать свои автоматические мысли (прям как идёт, без фильтрации).
Во вторую колонку для каждой мысли выписать присущие ей когнитивные искажения (список Бернс даёт в книге, я себе даже распечатал).
В третью колонку для каждой мысли выписать рациональный ответ (не «правильный», а такой, в который я сам верю).

Несмотря на кажущуюся простоту, техника оказалась удивительно эффективной. Я применял её в следующих ситуациях:

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

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

У техники есть важное ограничение: она снимает симптомы, а не корневую причину. То есть проработка текущего состояния снижает градус накала эмоций (в расширенной версии техники есть колонки с оценкой интенсивности чувств), но не гарантирует, что подобные ситуации не будут триггерить в дальнейшем. Для глубокой проработки Бернс предлагает технику «падающей стрелы», о которой я как-то отдельно напишу.

AI Agents in Action, Second Edition by Micheal Lanham

Fri, 24 Jul 2026 00:00:00 GMT

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

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

К счастью, на эту тему уже начала появляться качественная литература.

О чём книга

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

В книге раскрываются следующие темы:

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

Три идеи из книги

Начинайте строить агентную систему с минимального и самого простого решения. Как и в целом в инженерной практике, не надо сразу городить Годзиллу с лазерными пушками на спине — начните с решения базовой проблемы и добавляйте сложности, если система хорошо справляется. Задайте жёсткие ограничения в самых важных точках, а в остальных местах предоставьте свободу.
У любой агентной системы должен быть механизм сбора обратной связи от пользователей. Такая ОС является не просто «свистелкой», а механизмом реального постоянного улучшения работы агента. Конечно, сырой фидбек пользы не принесёт, и его нужно корректным образом очистить и обработать, но без него можно забыть о развитии качества системы.
Агентский цикл без жёсткого стоп-сигнала — это скрытый инцидент на проде. Каждая итерация жрёт токены, увеличивает косты и добавляет времени обработки. В процессе разработки можно крутить агента до бесконечности, но на проде всегда должна быть отсечка для слишком большого количества итераций.

Мои впечатления

Книга очень крутая. Во-первых, автор реально раскладывает всю базу работы LLM в объёме, достаточном для понимания построения агентных систем. Во-вторых, в книге минимум воды и максимум пояснений, что в последнее время редкость (да, даже инженерные книги «заливают» ради объёма). В-третьих, в книжке есть куча примеров кода, который демонстрирует различные техники, о которых автор рассказывает.

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

Если в вашем продукте используются агенты — рекомендую прочитать прямо не откладывая. Как минимум систематизируете знания, как максимум — увидите «пороховые бочки» на своём проде.

Высокая скорость иногда маскирует плохую инженерию

Wed, 22 Jul 2026 00:00:00 GMT

Скорость разработки не бесплатна. За ускорение обычно приходится платить компромиссами: урезанным объёмом, дополнительными ресурсами, накопленным техническим долгом или повышенным риском.

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

Тогда система через некоторое время предъявляет счёт:

не держит нагрузку или выпадает из SLA;
падает на релизах;
требует недели на добавление простой фичи;
отдаёт значительную часть capacity команды багам.

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

Эта проблема особенно заметна во время развитой кодогенерации через ИИ. Со стороны команда может выглядеть невероятно производительной: «мы тут за три недели всю систему переписали». Но количество написанного кода ничего не говорит о том, выдержит ли система нагрузку, можно ли её сопровождать и насколько дорого будет следующее изменение.

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

Как выключить голову на выходных

Mon, 20 Jul 2026 00:00:00 GMT

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

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

Выключить возможность работать

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

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

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

Создать среду для переключения

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

Баня. По эффекту сопоставима с тренировкой: после неё я физически не могу напрягаться.
Массаж. Работает не хуже, но попасть к хорошему мастеру сложнее.
Долгая прогулка в парке. При работе из дома невозможно убрать из поля зрения рабочий стол, а несколько часов вдали от него помогают прочистить голову.

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

Разрешить себе отдых

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

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

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

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

«Не усложняй. Управление проектами по методу P3.express», Дмитрий Ильенков, Валерия Ильенкова

Fri, 17 Jul 2026 00:00:00 GMT

Люблю я книги с интересными историями. Приходит ко мне как-то в личку уважаемый Игорь Беляев и говорит: «Какая же топовейшая книга! У меня это уже книга года в персональном рейтинге». Книгу я, само собой, прихранил в ридлист — читать всякое по проектному управлению я люблю, всегда что-то удаётся выдернуть.

А через некоторое время Игорь приносит мне информацию о том, что на проекте Димы Ильенкова PMClub есть запрос на написание обзоров книг. «Ну, это судьба!» — подумал я и оставил заявку. Вскоре ко мне в личку зашёл, собственно, Дима и предложил прочитать его книгу.

Поскольку я и так собирался это делать, получилось объединить приятное с приятным.

О чём книга

Книга — это практичное, понятное и максимально прикладное руководство по применению методологии P3.express для управления проектами. В книге описаны основные принципы, этапы и шаги методологии, а также даны инструкции по их применению.

В книге раскрываются следующие темы:

Что вообще такое P3.express и на каких принципах она строится
Как запускать проект так, чтобы не было мучительно больно его финалить
Как превратить проектный план в повседневную работу
Как закрыть проект так, чтобы его не было стыдно вспомнить
Что нужно сделать после закрытия проекта (и почему это не про «быстрее схватить новый проект»)

3 идеи из книги

Одна из первейших задач при запуске проекта — определить его спонсора. Нет смысла начинать, если непонятно, кто согласует видение проекта, его планы и кто будет поддерживать проект в непростых ситуациях (которые обязательно возникнут). Я на практике часто встречал проекты, в которых с виду все заинтересованы, но конкретного спонсора нет. При первой же непростой ситуации начинается полный бардак.
Для «отстрела» нежизнеспособных проектов в P3.express есть повторяющийся шаг «Go/No-Go». Его выполнение заключается в ответе на вопрос: выполняет ли проект поставленные задачи или же катится «по инерции»? Руководители проектов часто попадают в ловушку невозвратных затрат и не могут «слезть с мёртвой лошади». Этот шаг предназначен для того, чтобы как можно раньше прекращать заниматься бесполезной деятельностью.
Празднуйте завершение проекта! Хвалите и благодарите себя, людей вокруг, всех сопричастных. Даже если проект не идеален — всё равно отметьте хорошую работу (свою и окружающих). Простые слова благодарности могут поднять и сохранить людям мотивацию на следующий проект, наполнить их энтузиазмом и поддержать, если текущий проект оказался не совсем удачным. Нам всем стоит поучиться праздновать свои успехи и достижения.

Мои впечатления

Книга мне крайне понравилась сразу по нескольким причинам.

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

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

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

Короче, «Не усложняй» — редкий бриллиант хорошей и качественной литературы по проектному управлению. Очень рекомендую к прочтению!

Страх — худший инструмент руководителя

Wed, 15 Jul 2026 00:00:00 GMT

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

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

Куда уходит внимание

У взрослого человека есть выбор, как реагировать на угрозу:

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

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

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

Давление начинает кормить само себя

Когда мотивация и качество падают, любитель угроз часто усиливает давление. Люди ещё больше закрываются, допускают больше ошибок и перестают приносить плохие новости. Руководитель видит ухудшение и получает новое подтверждение своей версии: «Без угроз они вообще не работают».

Так инструмент создаёт проблему, которую якобы должен решать.

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

Если хочется сильную и самостоятельную команду, сначала стоит перестать перенаправлять её силы на самозащиту. Подробнее об этом я рассказываю в выступлении «Как перестать демотивировать людей».

Способность адаптироваться к изменениям

Mon, 13 Jul 2026 00:00:00 GMT

В одну и ту же реку нельзя войти дважды.

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

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

Адаптация не равна одобрению

Я называю адаптацией способность сознательно выбирать своё поведение в новых обстоятельствах, опираясь на собственные цели и понимание ситуации.

Это не обязанность радоваться любому изменению и немедленно искать в нём пользу. Некоторые перемены приносят реальные потери, требуют времени на проживание или заслуживают сопротивления.

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

В этом смысле адаптация для меня — метанавык. Он нужен при смене работы, переезде, рождении ребёнка и изменениях внутри профессии. Ситуации разные, но вопрос один: что теперь находится в моей власти?

Что помогает мне возвращать выбор

Готового рецепта и тренировочного плана у меня нет. Есть несколько опор, которыми я пользуюсь сам.

Дихотомия контроля

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

Личная стратегия и цели

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

Вопрос 10/10/10

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

Проверка собственных убеждений

Я использую логику и техники из книги Дэвида Бернса «Терапия настроения», чтобы замечать автоматические мысли и проверять их. Иногда перемена сама по себе не так страшна, как история, которую я успел вокруг неё построить.

Вопрос о выгоде

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

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

«Атомные привычки», Джеймс Клир

Fri, 10 Jul 2026 00:00:00 GMT

Сегодня у меня в обзоре книга довольно особенная. Причин тому две:

Я уже читал её несколько лет назад, и она мне понравилась.
Именно на этой книге я показывал многие темы и упражнения из практикума «Инфосушка».

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

И много принципов в построении своих привычек я почерпнул ещё во время первого прочтения книги «Атомные привычки». А хорошие книги стоит время от времени перечитывать с новым опытом.

О чём книга

Книга посвящена фреймворку автора о том, как выявлять и изменять свои привычки маленькими шагами.

В книге раскрываются следующие темы:

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

Три идеи из книги

К истинному изменению поведения приводят только изменения в личности. Очень часто мы начинаем пытаться формировать новые привычки на базе мотивации, но они «отваливаются», как только истощается сила воли. Простой пример: я большой любитель спорта и получаю удовольствие от тренировок, поэтому моя привычка к занятиям физкультурой не отваливается. А вот многие мои знакомые с огромным трудом запинывают себя в зал.
До создания новых привычек сначала нужно осознать уже существующие. Это очень важный момент, которым я лично часто пренебрегал — а зря. Если желаемая новая привычка сильно конфликтует со старой, то мне будет очень тяжело её внедрить. И наоборот — новые привычки довольно удобно привязывать к старым, уже существующим и укрепившимся в поведении.
Люди, у которых «всё круто с дисциплиной и самоконтролем», зачастую не применяют эти самые дисциплину и самоконтроль. Они просто создают себе правильное окружение, в котором находятся правильные стимулы. Например, дома за рабочим местом я только работаю или учусь — я никогда здесь не играю, не смотрю развлекательные видосики и так далее. Поэтому у меня моментально включается нужный настрой.

Мои впечатления

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

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

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

Книгу рекомендую. Вы точно посмотрите на свои привычки новыми глазами, а возможно, даже сможете изменить что-то в своём поведении в желаемую сторону.

Музыка во взрослом возрасте: как не бросить через месяц

Mon, 06 Jul 2026 00:00:00 GMT

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

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

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

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

Подберите инструмент, который нравится сам по себе

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

Так вот, 90% времени вы будете слышать не «песенки», а исключительно тот инструмент, на котором вы играете. Поэтому вам должно нравиться звучание инструмента самого по себе. Если инструмент «не ваш» – удовольствие от игры будет весьма сомнительным.

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

Найдите хорошего преподавателя

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

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

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

Не загоняйте себя палкой

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

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

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

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

«Внутри AI. Как это работает», Рональд Кнойзель

Fri, 03 Jul 2026 00:00:00 GMT

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

В фундаменте работы современного AI я уже разобрался, и довольно основательно — несколько интересных книг, курсы и так далее. Но в моём арсенале инструментов остался незакрытый пробел: нет ничего, что помогло бы объяснить «на пальцах» тему устройства AI людям, которые не погружены в сложную математику и даже IT в целом. А иногда такие задачи возникают.

Поэтому я и взял почитать книгу «Внутри AI. Как это работает».

О чём книга

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

В книге раскрываются следующие темы:

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

Три идеи из книги

Данные — это всё. Хорошие данные приводят к появлению хороших моделей, плохие данные приводят к плохим моделям. Модели умеют экстраполировать, переобучаться и делать ещё много всяких интересных вещей, опираясь на входной датасет. Поэтому первое, с чем нужно качественно работать, — это базовые данные для обучения.
Одна из самых весёлых проблем в обучении модели — это переобучение. Оно заключается в том, что моделька выявляет некоторые паттерны в датасете, привязывается к ним и начинает на их основе работать. Например, если в датасете есть только фото, сделанные в солнечную погоду, то модель может с треском провалиться на фотках пасмурных дней. Решается эта проблема более разносторонними датасетами.
Любая модель — это чистая математика. Сами по себе модели зачастую даже не «понимают», с чем они работают, потому что внутри всё сводится к числам: весам, смещениям, вероятностям и так далее. Даже современные LLM на самом деле просто предсказывают появление следующего токена (это довольно сложный процесс, но «мышления» там нет).

Мои впечатления

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

Я бы рекомендовал почитать эту книжку в двух случаях:

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

Если же вы уже строите агентные системы на рабочих или даже пет-проектах, то книга вряд ли расскажет вам много нового. Но если вы используете условный клодкод и не понимаете, как оно работает «под капотом», — книга «Внутри AI. Как это работает» станет хорошей отправной точкой.

Цена хай-перформера: сколько стоит удержать звезду в команде

Wed, 01 Jul 2026 00:00:00 GMT

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

Такие люди — редкие звери. Гораздо чаще встречается абсолютно нормальная и прозаичная ситуация, в которой человек хочет спокойно работать в рабочее время и спокойно не работать в нерабочее. Он может отлично справляться со своими задачами, просто у него «глаза не горят».

Когда очередной руководитель говорит мне о желании «набрать хай-перформеров», я всегда задаю один и тот же вопрос: «А ты готов расплачиваться за это?»

Зарплаты недостаточно

Мой вопрос многих ставит в тупик. «В смысле — расплачиваться? У них же зарплата есть», — отвечают они.

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

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

Цена для руководителя

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

В какой-то момент «долг» превращается в «банкротство»: человек приходит с оффером в руках, и удерживать его уже поздно.

Расплачиваться — не значит бесконечно придумывать привилегии или обещать рост, которого нет. Это значит:

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

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

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

20 книг для профессионального роста разработчика

Tue, 30 Jun 2026 00:00:00 GMT

У меня уже накопилось довольно значительное количество обзоров книг в канале. Поэтому я решил сделать несколько подборок хороших книг для представителей разных профессий. Сегодня предлагаю список из 20 книг «на почитать» для профессионального и карьерного роста инженеров разработки ПО.

Архитектура и системы

«Designing Data-Intensive Applications, 2nd edition», Martin Kleppmann — чтобы разобраться в устройстве систем данных и компромиссах распределённых решений.
«Создание микросервисов», Сэм Ньюмен — про границы сервисов, их взаимодействие и эволюцию архитектуры.
«Фундаментальный подход к программной архитектуре», М. Ричардс, Н. Форд — про архитектурные характеристики и выбор между конкурирующими требованиями.
«Эволюционная архитектура», Нил Форд и др. — про управляемое изменение архитектуры и fitness functions.
«Распределённые системы», Брендан Бёрнс — про паттерны построения распределённых систем на основе Kubernetes.
«System Design. Подготовка к сложному интервью», Алекс Сюй — про базовые задачи проектирования масштабируемых систем.
«Site Reliability Engineering», Б. Бейер и др. — про практики надёжности и эксплуатации систем в Google.
«Чистый дизайн», Кент Бек — про эмпирический подход к проектированию и управлению сложностью кода.

Инженерная культура и практики

«Делай как в Google», Титус Винтерс и др. — про инженерные практики разработки больших и долгоживущих систем.
«Accelerate», Nicole Forsgren и др. — про связь практик поставки с производительностью IT-организации.
«Грокаем безопасность веб-приложений», Малкольм Макдональд — про основные классы уязвимостей и способы защиты от них.
«Continuous API Management», Mehdi Medjaoui и др. — про управление API на протяжении всего жизненного цикла.
«AI-инженерия», Чип Хьюен — про создание прикладных систем на базе foundation models.

Карьера и рост

«Карьера Software Engineering Manager», Джеймс Стэньер — про переход от разработки к управлению инженерной командой.
«Хватит мечтать, займись делом», Кэл Ньюпорт — про карьерный капитал и развитие редких профессиональных навыков.
«Эссенциализм», Грег МакКеон — про выбор главного и отказ от лишнего.

Мышление и решения

«Цель», Элияху Голдратт — про ограничения системы, поток и локальные оптимизации.
«The Poker Mindset», Matthew Hilger, Ian Taylor — про решения в условиях неопределённости и отделение качества решения от результата.
«Критическое мышление», Том Чатфилд — про анализ аргументов, информации и собственных выводов.
«Тирания показателей», Джерри Мюллер — про побочные эффекты измерений и управление метриками.

Приятного чтения!

«Новый одноминутный менеджер», Кен Бланшар и Спенсер Джонсон

Fri, 26 Jun 2026 00:00:00 GMT

Я люблю читать старые книги, которые всё ещё популярны. Часто оказывается, что описанные в них идеи более чем актуальны на сегодняшний день (например, моей любимой книге по чтению более 100 лет).

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

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

О чём книга

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

В книге раскрываются следующие темы:

Как применять Одноминутные цели для выравнивания работы с людьми.
Что такое Одноминутная похвала и почему она так эффективна.
Как проводить Одноминутные наставления, если сотрудник ошибся.

3 идеи из книги

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

Мои впечатления

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

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

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

Как AI меняет кибербезопасность

Wed, 24 Jun 2026 00:00:00 GMT

Инфополе вокруг меня бурлит от обсуждений того, как AI меняет разработку. Но меняются и другие направления.

Я участвовал в кибербитве Standoff на стороне команды «синих» — защитников. В этот раз команды могли использовать любых агентов. «Синие» применяли их для расследований и составления отчётов, а «красные» — для проникновения в инфраструктуру.

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

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

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

Реализация атаки заняла двадцать шагов.

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

Раньше сложность атаки сильнее ограничивалась количеством человеческих рук. Теперь часть работы можно распараллелить между агентами. Это не делает специалиста ненужным: кто-то всё ещё должен выбрать цель, спроектировать цепочку, проверить каждый шаг и отвечать за результат. Но производительность подготовленной команды меняется.

AI меняет не только разработку. После участия в Standoff мне стало сложнее считать это отвлечённым разговором о будущем: в кибербезопасности изменения уже можно наблюдать в работе обеих сторон.

Каким человеком я стану, если справлюсь с этим?

Mon, 22 Jun 2026 00:00:00 GMT

Ни от одного человека в мире я не огребал люлей сильнее, чем от Жеки.

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

Я не знаю, что он во мне разглядел, но в какой-то момент просто сказал: «Теперь ты работаешь со мной». И понеслась.

Жека не давал мне спуску. Не прощал ошибок. Руки у меня постоянно были синие, а рёбра болели, потому что не всё получалось заблокировать. Я ненавидел каждую тренировку, но продолжал терпеть и раз за разом возвращался в зал, чтобы выползти из него с проклятиями.

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

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

В моей жизни далеко не всегда всё идёт гладко. Чего уж там: иногда я чувствую себя феноменальным неудачником, у которого не получается 99% задуманного. Но в трудные моменты я всегда думаю о том, каким человеком стану, если успешно справлюсь с тем, что навалилось сейчас.

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

А Жека потом дважды выиграл чемпионат мира среди ветеранов.

A Philosophy of Software Design by John Ousterhout

Fri, 19 Jun 2026 00:00:00 GMT

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

Чем сильнее развиваются технологии – тем важнее становятся фундаментальные навыки (и тем больнее бьёт по голове их отсутствие). Одним из таких навыков у инженеров является написание понятного и поддерживаемого кода. С массовым распространением вайбкодинга отсутствие этого навыка у инженеров плавно ведёт нас в горящую бездну отвратительного софта.

Самая известная книга на тему написания хорошего ПО – «Чистый код» Роберта Мартина. В ней много здравых и интересных идей, но она мне всегда казалась несколько однобокой и надуманной (я пробовал описанные техники в реальных проектах, и получалась изрядная фигня). И наконец-то у меня дошли руки до ещё одной книги о том, как создавать хорошее, качественное, поддерживаемое ПО – «A Philosophy of Software Design» за авторством John Ousterhout.

О чём книга

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

В книге раскрываются следующие темы:

тактическое vs стратегическое программирование;
как создавать «глубокие» модули;
управление исключениями для снижения сложности;
техника «двойного дизайна»;
применение комментариев для снижения сложности.

3 идеи из книги

Одним из симптомов сложности является когнитивная нагрузка. Код с высокой сложностью трудно понимать, поэтому разработчикам приходится тратить на этот процесс больше времени. А многим не хватает сил/времени/мотивации нормально разобраться, в результате чего изменения приводят к багам и прочим проблемам.
Простой код = код, который легко понять. Просто написать работающий код недостаточно. Каждый инженер должен думать о долгосрочном развитии и поддержке системы, над которой он работает. Иногда быстрое тактическое решение может ухудшить дизайн системы, и такие решения имеют свойство накапливаться. Поэтому инженерам стоит выделять 10–20% своего времени на совершенствование дизайна. Это и есть стратегическое программирование.
Комментарии должны описывать нюансы, которые не очевидны при чтении кода. «Самодокументирующийся код» – это фантастический зверь, который в реальной жизни практически не встречается. При этом комментарии, которые просто дублируют код, тоже только увеличивают когнитивную нагрузку. Хорошие комментарии улучшают дизайн системы за счёт упрощения её понимания для других людей.

Мои впечатления

Книга Оустерхаута показалась мне гораздо более жизненной и практичной, чем «Чистый код». Во многом мысли авторов конфликтуют – и этот конфликт интересен, потому что на самом деле правильного ответа нет и чувство прекрасного у каждого своё.

Сейчас я бы рекомендовал читать «Чистый код» и «A Philosophy of Software Design» парой, друг за другом. Такой подход позволит не просто слепо копировать практики, а посмотреть на разные взгляды ветеранов разработки ПО и аргументированно выбрать лучшее для себя.

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

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

Душнить над деталями — это профессионализм

Mon, 15 Jun 2026 00:00:00 GMT

Недавно на работе получил в личку занятный вопрос по одной из встреч: «А что там час обсуждать? Там же всего одна апишка».

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

Почему разработчики такие душные

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

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

Быстрый груминг не всегда хороший знак

Меня настораживают ситуации, когда обсуждение задачи пролетает под лозунгом «да тут всё понятно». Часто проблемы обнаруживаются уже после того, как решение написано и цена уточнения выросла.

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

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

«Просто добавим параметр»

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

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

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

«Терапия настроения», Дэвид Бернс

Fri, 12 Jun 2026 00:00:00 GMT

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

К запросу на эту книгу я пришёл довольно неожиданно. Я в последнее время посвящаю много внимания развитию личной устойчивости и снижению стресса (а ещё я периодически переключаюсь между режимами Роршаха в тюрьме и тревожного пирожочка). В этом мне здорово помогают труды стоиков, которые, однако, не всегда получается легко и просто переложить на практику.

Я вышел в ~~интернет~~ LLM с этим запросом и в ходе небольшого ресёрча получил ряд рекомендаций по книгам, которые помогли бы мне переложить правильные идеи на практику. Первой из них стала именно «Терапия настроения».

О чём книга

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

В книге раскрываются следующие темы:

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

Три идеи из книги

Все наши настроения создаются тем, как мы интерпретируем происходящее. А интерпретируем мы его с помощью когниций — восприятия, ментальных установок, убеждений. И то, как мы себя чувствуем здесь и сейчас, определяется тем, в каких терминах мы думаем о себе, окружающем мире и происходящем.
Хаос в голове зачастую вызывают когниции, которые содержат грубые когнитивные искажения. Например, сверхобобщение и катастрофизацию («аааа, о боже, я чуток ошибся, меня уволят, я умру бомжом»). Избавляясь от подобных паттернов мышления, мы автоматически улучшаем своё настроение. Свою самооценку не нужно повышать, её нужно перестать понижать.
Мы изначально обладаем здоровой самооценкой, но сами загоняем её в негативную яму. И да, это делаем мы сами — никто другой не может взять и понизить нашу самооценку. Занятно, что схожий тезис про мотивацию я выдвигал в докладе «Как перестать демотивировать людей».

Мои впечатления

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

Хотя я назвал книгу учебником, это не скучный академический талмуд, который действует как хорошее снотворное. Бернс даёт некоторое количество теории для понимания тех идей, которые он выдвигает. Но в книге даже терминов практически нет, просто понятные объяснения и иллюстрирующие их истории из практики автора.

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

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

Люди не вмещаются в 4 буквы

Wed, 10 Jun 2026 00:00:00 GMT

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

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

Возьмём DISC. Лично я могу привести примеры из своей жизни по каждому из квадрантов. То же видел у коллег и сотрудников. Мне возражают, что DISC описывает «преобладающие» черты. Но для меня это всё равно остаётся гипотезой, а не готовым знанием о человеке.

Основная опасность типологий в том, что они дают иллюзию быстрого понимания. Ярлык «красный» по DISC начинает подменять наблюдения за человеком.

Что работает для меня

Вместо готового типа я наблюдаю за поведением человека:

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

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

Когда типология может пригодиться

Типологии - грубо упрощённые модели. Они могут напомнить, что люди разные и к каждому нужен свой подход. Ещё они годятся как источник гипотез: «В ситуации А человек повёл себя Б. Возможно, в ситуации В он проявит поведение Г».

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

Задача закончена, когда она работает на проде

Mon, 08 Jun 2026 00:00:00 GMT

End-to-end ответственность: что отличает сеньора от «перекладывателя кода».

– Мы тут тааакую фичу запилили за неделю, навайбкодили! – О, крутяк, а где можно потыкать? – Ну, эээ, понимаешь, оно ещё там на деве, короче, ты запроси доступ…

Это практически дословный (и довольно свежий) диалог из моей практики. Не сказать, что LLM-ки в разработке привнесли в этом плане что-то новое – проблемы с критериями готовности я встречал всегда. Похоже, пора поговорить о том, что означает «задача закончена» и где на самом деле находится точка «запилили фичу».

Когда работа над фичей считается завершённой?

Короткий ответ – никогда. Если подумать чуть дальше рамок «написать код», то оказывается, что фича – это ещё и тестирование, раскатка, дальнейшее сопровождение и даже вывод из эксплуатации. Любая фича в любом продукте – это живая сущность, которая постоянно изменяется и эволюционирует.

Но такой ответ вряд ли удовлетворит среднего разработчика (и даже тимлида), которым нужен некоторый критерий завершённости. Я для себя сформулировал его так:

Фича закончена = фича выкачена в прод на всех клиентов и активно используется.

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

За что ещё отвечает разработчик, помимо написания кода

Конечная задача разработки – поставлять ценность для бизнеса в виде потока фич. Фича «на деве», «на стейджинге» и даже «сделана, но скрыта под фича-флагом» = фича не работающая и не приносящая пользы. Следовательно, есть целый пласт работ помимо написания кода, который нужно делать для успешной поставки и который обычно все дружно игнорируют, пытаясь в очередной раз «ускорить разработку LLM-ками».

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

Звучит немного сложнее, чем просто «навайбкодили фичу», не так ли? А это я ещё намеренно опустил пострелизную работу с фичей (за которую больше отвечают продакты). Тем не менее, такая end-to-end ответственность в моей картине мира является обязательным атрибутом senior-разработчика. И она намного ценнее, чем знание очередного модного фреймворка.

Как вовремя переоценить место работы

Wed, 03 Jun 2026 00:00:00 GMT

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

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

Квартальная рефлексия о работе

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

Я задаю себе всего три простых вопроса:

Какие у меня сейчас цели в жизни? Что для меня важно?

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

Помогает ли текущее место работы в моём продвижении к целям или мешает им?

Моё отношение к работе очень простое: партнёрство. Я приношу пользу бизнесу, а бизнес помогает мне некоторым образом достигать моих целей. Если же я вижу, что текущее место работы не продвигает меня к целям (или, хуже того, отодвигает) — это повод задуматься, что я делаю не так.

Расту ли я на текущем месте работы профессионально? Есть ли перспективы карьерного роста?

Этот вопрос является следствием предыдущего. У меня есть интересная особенность: я очень быстро расту и всегда голоден до интересных задач, поэтому в стагнирующих местах быстро начинаю скучать. К тому же мой профессиональный и карьерный рост важны для повышения моей ценности на рынке (мы же не бесплатно работаем, правда?). Если я на текущем месте стагнирую — это повод поискать себе новые челленджи. Но если я и стагнирую, и не имею перспектив карьерного роста — то это уже повод посмотреть в рынок.

Стоит ли оно того?

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

Регулярные ответы на эти вопросы помогают мне раньше заметить, что я засиделся. Но сама рефлексия не принимает за меня решение: она лишь вовремя возвращает вопрос в поле зрения.

«Карьера разработчика. Стафф — круче, чем Senior», Таня Рейли

Fri, 29 May 2026 00:00:00 GMT

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

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

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

О чём книга

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

В книге раскрываются следующие темы:

Как развить у себя навык панорамного мышления и применять его в работе
Основы управления крупными проектами
Как подавать положительный пример и влиять на подражателей (которые обязательно появятся)
Как заниматься самообразованием, если технический уровень уже довольно высок

3 идеи из книги

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

Мои впечатления

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

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

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

Почему сильные инженеры выиграют от LLM больше остальных

Wed, 27 May 2026 00:00:00 GMT

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

Постепенно я пришёл к выводу: LLM ускоряет инженера, но направление движения по-прежнему задаёт сам инженер.

Ускорение масштабирует исходный уровень

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

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

Слабая инженерная база тоже ускоряется. Непонимание границ модуля, рисков изменения или устройства тестов теперь можно размножить на гораздо больший объём кода.

Требования к профессионализму растут

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

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

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

Лучший вайбкодер - тот, кто способен оценить результат и без LLM под рукой.

Два сбоя Cloudflare: что пошло не так и как они это чинят

Mon, 25 May 2026 00:00:00 GMT

Два сбоя Cloudflare: что пошло не так и как они это чинят

Вроде на дворе уже май, а в памяти ещё свежи два масштабных сбоя Cloudflare: 18 ноября и 5 декабря 2025 года. Представьте, сколько денег потеряли бизнесы, зависимые от Cloudflare, и сколько нервных клеток было сожжено в эти дни.

Cloudflare опубликовала подробные пост мортемы, почему это произошло. Но они на этом не остановились и (как и положено при хорошем пост мортеме) начали внедрять изменения, чтобы подобных сбоев больше не произошло. План они назвали «Code Orange: Fail Small» и суть его заключалась в том, чтобы стать более устойчивыми к ошибкам или отключениям, защитившись от масштабных сбоев.

Интересные идеи

Оба сбоя произошли по схожим причинам: массовый деплой изменений в конфигурации сразу на все ЦОДы. Оказалось, что Cloudflare довольно внимательно подходят к релизам изменений в коде (куча quality gates, канареечные релизы и так далее), а конфиги раскатывают «как есть». После сбоев они решили применить для релиза конфигов модель релиза кода.

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

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

Для меня ключевой тейк этой статьи заключается в поводе подумать о том, что стоит провести pre-mortem и подумать: где нам будет мучительно больно, если вдруг продакшену станет очень плохо? Я уверен, что у каждого читателя в голове сразу всплывёт пара-тройка идей (например, у меня всплыли наши долгие получения доступов к продовым ns кубера).

Приятного чтения!

https://blog.cloudflare.com/fail-small-resilience-plan/

«Думай как римский император», Дональд Робертсон

Fri, 22 May 2026 00:00:00 GMT

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

Вот и сейчас наступил момент, когда мне снова захотелось коснуться стоиков. Книгу Дональда Робертсона «Думай как римский император» мне рекомендовали не раз, поэтому она и стала ответом на мой вопрос «Чего бы почитать из современного по стоицизму?»

О чём книга

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

В книге раскрываются следующие темы:

Как познать свои ценности и следовать им
Как обуздать свои желания
Как научиться переносить трудности, дискомфорт и боль
Как победить свои гнев и страх

Три идеи из книги

Стоики не подавляли эмоции, а учились посредством разума преобразовывать нездоровые эмоции в здоровые. Для этого они проводили анализ происходящей ситуации и отделяли реальность от своих додумок. Этот процесс был похож на современную психотерапию: стоик находил свои убеждения, вызывающие нездоровые эмоции, и подвергал их критическому рассмотрению, в результате чего убеждения трансформировались.
Чувство, что за нами наблюдают, помогает развить осознанность и скорректировать поведение. Но здесь важно создавать себе правильный настрой: наблюдатель ни в коем случае не должен быть враждебным. Это может быть некоторый образ требовательного, но заботливого и внимательного ментора, целью которого является рост его подопечного. Например, я часто вспоминаю своего первого тренера (а сейчас у меня на рабочем столе для этого стоит бюст Марка Аврелия).
Мы не властны над ситуациями, но властны над своим отношением к ним. Стоики понимали, что мир непредсказуем и всё, что мы можем – это фокусироваться на собственных действиях, принимая любой результат. И точно так же с нами может произойти всё, что угодно. Но мы вольны выбирать своё отношение и поведение в любом случае, и именно этот выбор определяет стоика.

Мои впечатления

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

Также довольно интересно было посмотреть на контекст, в котором ковался характер Марка Аврелия и создавались его «Размышления» – это помогло мне лучше понять ценность и суть этой книги.

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

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

Как снова полюбить читать художку

Sun, 17 May 2026 00:00:00 GMT

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

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

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

Читайте то, что вам нравится, пока вам не понравится читать

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

У всех этих книг одна и та же проблема: они написаны не для подростков, которые ещё толком ничего в жизни не видели и не понимают.

Чтобы получать удовольствие от чтения во взрослом возрасте, нужно понять одну простую вещь: никто нас уже не заставляет дочитывать то, что не по душе. Будь это хоть трижды классика, будь это хоть лучшая книга в мире — если ей сейчас не время и не место в вашей жизни, нет ничего плохого или страшного в том, чтобы отложить её на будущее (которое, возможно, никогда не наступит).

Читайте ради удовольствия

Ещё одно убеждение, которое мешает получать удовольствие от чтения художки, звучит так: «читать нужно только умные книги».

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

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

Не старайтесь запоминать прочитанное

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

Вспомните это состояние: судорожное и мучительное запихивание в себя очередной книги, потому что «по ней завтра будут спрашивать» и «ещё сочинение потом писать». Это уж точно не про удовольствие от чтения.

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

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

«Разверните ваш корабль», Дэвид Марке

Fri, 15 May 2026 00:00:00 GMT

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

После прочтения «Человеческого фактора» я захотел ещё больше закопаться в тему менеджмента здорового человека: как управлять людьми и достигать результатов без превращения в деспота, дятла или микроменеджера.

«Разверните ваш корабль» давно болталась у меня в списке, а затем LLM порекомендовала её как один из материалов под мой запрос. Я проанализировал содержание и заинтересовался.

О чём книга

Дэвид Марке рассказывает, как менял привычную армейскую модель лидерства на атомной подводной лодке и с какими трудностями столкнулся.

В книге раскрываются следующие темы:

как перейти от модели «лидер и последователи» к модели «лидер и лидеры»;
как изменение формулировок влияет на мышление людей;
как не вернуться к старому поведению в кризисный момент.

3 идеи из книги

В кризис сложнее всего не скатиться в старую модель поведения и не начать раздавать приказы. Модель «лидер и лидеры» требует терпения, особенно в начале внедрения: подчинённым может потребоваться время, чтобы разобраться в ситуации. Но именно в такие моменты модель и закрепляется в поведении.
Один раз сказать что-то недостаточно. Нужно повторять людям один и тот же тезис снова, снова и снова. Да, это скучно и обременительно, но это один из немногих способов донести свои идеи и убеждения до окружающих.
Модель «лидер и лидеры» строится на передаче людям ответственности за их зоны влияния. Передача ответственности подразумевает не только самостоятельность людей, но и максимальное невмешательство лидера. Контроль можно и нужно оставить.

Мои впечатления

Если вы читали мои посты про чтение, то эта книга — отличный инструмент для практики предварительного анализа и скимминга. Потому что в страницы этого «бестселлера New York Times» протекла вся вода, в которой плавала подводная лодка автора.

Идеи в книге здравые и хорошие. Проблема лишь в том, что их буквально пара штук и они размазаны на 300 страниц мемуаров, тщательно причёсанных редакторами. Если вы хоть раз общались с военными, то «цитаты» подчинённых автора изрядно порадуют.

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

Генти генбуцу: руководителю иногда нужно пройти процесс самому

Wed, 13 May 2026 00:00:00 GMT

Если хочешь решить проблему, сначала нужно увидеть её своими глазами.

В «Дао Toyota» Джеффри Лайкера есть принцип «генти генбуцу»: для глубокого понимания проблемы человек отправляется в место её возникновения и наблюдает за происходящим лично, а не полагается только на отчёты, графики и презентации.

Отчёт неизбежно теряет детали

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

Поэтому в отчёте или пересказе часть контекста неизбежно теряется. Личное наблюдение тоже субъективно и не делает решение автоматически правильным. Но оно возвращает детали, которые трудно передать словами, и позволяет задать вопросы прямо во время процесса.

Как я прошёл релиз сам

Я часто слышал жалобы вроде «релизиться сложно». Поскольку скорость релизов — моя прямая ответственность, я закатал рукава и несколько раз самостоятельно прошёл весь процесс. Сказать, что у меня сгорело пониже поясницы, значит сильно смягчить ситуацию.

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

Смог бы я найти эти изменения по отчёту «релизиться сложно»? Не факт.

Болезненная поставка часто говорит не только о пайплайне, но и о состоянии всей системы разработки. Эту связь я подробнее разобрал в заметке «Деплой как зеркало организации».

Руководителю иногда нужно спуститься в процесс

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

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

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

«Человеческий фактор: успешные проекты и команды», Том ДеМарко

Fri, 08 May 2026 00:00:00 GMT

С творчеством Тома ДеМарко я, как и многие другие, начал знакомиться с книги «Deadline». Книга показалась мне очень интересной, и я утащил много идей для практики, поэтому сделал себе заметочку на будущее: посмотреть другие книги автора.

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

О чём книга

Книга посвящена тому, как строить продуктивную разработку и сильные, эффективные команды. И несмотря на солидный возраст книги, собранные в ней идеи практически не утратили актуальности.

В книге раскрываются следующие темы:

как эффективно управлять человеческим ресурсом, а не просто «загонять его»;
как офисная среда влияет на продуктивность команд (спойлер: в среднем очень плохо);
как подбирать подходящих людей;
как делать из группы людей команду.

3 идеи из книги

Самые серьёзные проблемы в нашей работе носят не технологический, а социологический характер. Если внимательно рассмотреть причины провала проекта, то вряд ли вы увидите там «нам не хватило современных технологий». Более вероятно, что причинами станут человеческие взаимоотношения, ошибки и неудачные решения.
Многие офисы предоставляют своим сотрудникам шумные, тесные и крайне подверженные внешним воздействиям рабочие места, на которых невозможно работать, не испытывая раздражения. Меня всегда бесили опенспейсы: обязательно найдётся какой-то нехороший человек, проводящий созвон в шумоподавляющих наушниках, постоянно что-то мелькает в поле зрения, про запахи я вообще молчу. И было всего пару мест, где работать в офисе было кайфово (во многом благодаря тому, что нас сидело 3–4 человека в кабинете).
Общая стоимость замены сотрудника — от четырёх с половиной до шести его зарплат. Если человек работает на одном месте два года, то стоимость его замены составит примерно 20% его пребывания здесь. Текучка — это ОЧЕНЬ дорого, особенно если уходят действительно толковые кадры.

Мои впечатления

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

За последние много лет в управлении людьми особо ничего не изменилось, и книги ДеМарко это отлично иллюстрируют. Да, сейчас нас не отвлекает каждые три минуты звонок телефона (и вообще, вы когда последний раз у кого-то телефон на рабочем месте видели?). А постоянные уведомления из мессенджеров? Лучше бы уж телефон звонил…

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

Designing Data-Intensive Applications, 2nd Edition by Martin Kleppmann, Chris Riccomini

Fri, 01 May 2026 00:00:00 GMT

Обзор первого издания книжки с кабанчиком был одним из первых книжных обзоров на моём канале (если кому интересно, как это выглядело почти 3 года назад — вот ссылка на пост). Я эту книгу всегда любил и высоко ценил, перечитывал несколько раз, поэтому после новости о переиздании был очень рад.

Конечно, я добрался до неё не сразу, но и затягивать не стал. Мотивацию читать второго кабанчика объяснить очень просто — на мой вкус, это одна из лучших книг по system design (и точно лучшая книга по проектированию приложений с большим потоком данных).

О чём книга

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

В книге раскрываются следующие темы:

как эффективно хранить и получать данные;
как обеспечивать сохранность данных (репликация, шардирование);
детальный разбор устройства транзакций;
особенности работы с данными в распределённых системах;
batch- и stream-обработка: особенности выстраивания.

Три идеи из книги

Сейчас на рынке появляются HTAP-базы данных (гибрид транзакционной и аналитической модели). Но часто оказывается, что «под капотом» у них всё так же две разные системы: одна для транзакционной обработки, а вторая — для аналитической. Это важно понимать при анализе конкретного решения.
Для многих БД непрактично останавливать весь процесс работы с целью резолва конфликта данных, поэтому они сохраняют обе версии и продолжают работать. При следующем запросе этих данных такая база возвращает обе версии клиенту, предоставляя ему самому выбрать метод решения конфликта.
Ошибки сети довольно редки, но приложение должно уметь справляться с ними. Особенно это важно в сложных геораспределённых системах, где сеть будет лагать и отваливаться гораздо чаще, чем в каком-нибудь небольшом кластере кубера, развёрнутом в одном ЦОДе. Этими ошибками часто пренебрегают, из-за чего вылезают неприятные баги.

Мои впечатления

Второй кабанчик стал намного лучше для меня как для читателя.

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

Во-вторых, сам контент был изрядно переписан и стал более «удобоваримым». Мне показалось, что книгу стало проще понимать (особенно в части разных весёлых аномалий). Хотя, может, это я просто стал умнее :)

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

The AI-Driven Leader by Geoff Woods

Fri, 24 Apr 2026 00:00:00 GMT

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

Моя деятельность ощутимо преобразилась с AI. Теперь у меня есть Claude, в котором заряжено пару десятков проектов под разные контексты. AI помогает мне искать информацию, анализировать, думать, принимать решения. И поэтому я постоянно ищу новые интересные способы его применения. С целью «стащить чужие идеи» я и взял почитать книгу с заманчивым названием «The AI-Driven Leader. Harnessing AI to Make Faster, Smarter Decisions» by Geoff Woods.

А ещё мы выбрали её следующей в нашем менеджерском книжном клубе, так что выбора у меня, в общем-то, и не было.

О чём книга

Книга посвящена тому, кто такой AI-driven leader, как им стать и как привнести в свою организацию AI-first-подходы. Основная задача, которую ставит перед собой автор, — показать смену майндсета, которую нужно совершить лидеру для перехода к AI-first.

В книге раскрываются следующие темы:

особенности мышления AI-driven-руководителя;
как встроить AI в свою повседневную работу прямо сейчас;
как принимать более качественные решения с помощью AI;
стратегия привнесения AI в свою организацию и работу сотрудников.

Три идеи из книги

Вместо вопроса «Как мне решить эту проблему?» начните задавать себе вопрос «Как AI может помочь мне решить эту проблему?». Автор предлагает это как один из переходных шагов к AI-driven-лидерству. Сама по себе идея мне понравилась: AI может дать хорошую отправную точку для любой проблемы.
Рассматривайте AI как помощника в мышлении, а не замену ему. Я этот тезис повторял, повторяю и буду повторять: AI может быть очень полезной балалайкой для того, кто и без него прекрасно может справиться. Нельзя отдавать ему функцию своего мышления — он должен лишь помогать.
Генерация идей — одна из самых сильных (и полезных для меня лично) функций AI. Он может генерировать дополнительные идеи к уже существующим, отсеивать слабые или бесполезные, накидывать новые и неочевидные и даже челленджить мои когнитивные искажения.

Мои впечатления

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

Самое ценное, что я вытащил из книги, — это пачку промптов и идей, как их можно применить в разных контекстах (от анализа требований и проработки ценности фичей до подготовки к 1-1 с сотрудниками). Книга довольно наглядно показывает, что современный руководитель может применить AI в огромном количестве будничных задач и тем самым повысить качество и скорость своей личной работы.

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

Алгоритм фильтрации контента: тратим 5 минут, чтобы сэкономить 5 часов

Wed, 22 Apr 2026 00:00:00 GMT

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

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

Подбор материалов под цель

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

90% статей в интернете – жуткий SEO-текст (а сейчас ещё и нейрослопа добавилось).
В остальных 10% есть пережёвывание известных фактов или прописных истин без опыта (или пересказ чужих идей).
С любыми видео такая же проблема (хуже всего в этом плане подкасты).

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

Подбор материалов – самая простая и быстрая часть, особенно в текущий век LLM-ок. Сейчас 80% поиска у меня сводится к следующему паттерну:

Запрашиваю в Perplexity подбор материалов по заданной теме с использованием только высококачественных источников.
Заглядываю в материалы и выбираю те, что кажутся адекватными (знали бы вы, сколько мусора в некоторых «исследованиях»…).
Прошу Perplexity подобрать похожие по качеству материалы.
Повторяю это N раз.

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

Анализ материалов

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

Для книг: читаю аннотацию, содержание, введение и заключение.
Для статей: читаю 1–2 вводных абзаца, подзаголовки и 1–2 последних абзаца.
Для докладов: читаю описание доклада, пролистываю презентацию.
Для видео: читаю описание и таймкоды (при наличии).

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

Этот подход позволяет буквально за минуты сэкономить себе часы жизни и огромное количество внимания, потому что отсекает всё неинтересное, бессмысленное и нерелевантное. Из 30 найденных материалов я забираю в работу 3-4. А с ростом количества «нейрослопа» в интернете я стал любить его ещё сильнее.

В следующем посте поговорим о том, как подготовиться к эффективной работе с материалом. Приятного чтения!

«Радикальная прямота. Как управлять людьми, не теряя человечности», Ким Скотт

Fri, 17 Apr 2026 00:00:00 GMT

Мне всегда было легко находить с людьми общий язык. Это проявилось ещё в возрасте 2-3 лет, когда я бегал по больнице (где работала моя мама) и развлекал пациентов весёлой болтовнёй.

Но для руководителя находить общий язык – это не только приятно болтать, но ещё и говорить не самые приятные вещи. Многим начинающим тимлидам сложно и страшно давать обратную связь, да и опытным руководителям это не всегда просто даётся. Я всегда стремлюсь улучшить свои коммуникативные навыки, поэтому и заинтересовался книгой «Радикальная прямота».

О чём книга

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

В книге раскрываются следующие темы:

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

3 идеи из книги

Быть ответственным – значит иногда бесить людей. Думаю, иногда у моих подчинённых периодически дёргается глаз от моих «тупых» вопросов. Мне самому не всегда приятно их задавать (мы же все хотим нравиться другим людям), но моя работа в том числе заключается в том, чтобы быть требовательным. А требовательность бесит.
Иногда, чтобы получить хорошее мнение или сделать разговор более интересным, нужно выразить такое мнение, которое покажется возмутительным. Это помогает встряхнуть участников беседы и вырвать их из привычного контекста. И тогда людям могут прийти неожиданные и очень интересные идеи.
Радикальная честность начинается с простого уважения к окружающим и обычной добропорядочности. Этот инструмент нужен для того, чтобы все лучше сотрудничали и делали общее дело, а не для выражения личных чувств и эмоций. Цель честных коммуникаций – взаимная выгода, а не конфликты на пустом месте.

Мои впечатления

В целом мне книга понравилась. Да, это типичный бестселлер Нью Йорк Таймс с морем воды и кучей вдохновляющих речей, но базовая мысль в ней здравая. Радикальную прямоту я считаю отличным, рабочим и крайне полезным инструментом. Мой горький опыт показывает, что гораздо хуже работать с людьми, которые улыбаются тебе в лицо и согласно кивают головой, чтобы потом сказать или сделать совсем иное.

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

К прочтению рекомендую всем, так как все мы работаем в коллективах (но особенно рекомендую руководителям). Хорошим дополнением станет «Ненасильственное общение».

ROI разработки: почему фичи стоят месяц, а приносят ноль

Mon, 13 Apr 2026 00:00:00 GMT

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

Активное внедрение LLM во все этапы разработки ясно показало то, что и так было очевидно всем более-менее опытным руководителям: написание кода не является бутылочным горлышком. Если команда делает бесполезные и слабо продуманные задачи, то с LLM она начнёт делать х2 бесполезных и слабо продуманных задач.

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

GIGO

Старый принцип гласит: «Garbage in — garbage out» (мусор на входе — мусор на выходе). Можно сколько угодно докручивать и оптимизировать процессы разработки, но если продукт никому не нужен — увы, никакую проблему это не решит.

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

Зачем мы делаем эту фичу?
Какая у неё ценность?
Кто потребитель этой фичи?
Как она позволит продукту зарабатывать больше денег?

Помню, приходит ко мне как-то бизнес-аналитик с идеей фичи. Фича классная и красивая, попахивает месяцем разработки. И задаю я ему простой вопрос: «Сколько человек будет потенциально этим пользоваться и как часто?»

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

Одним этим разговором мы резко повысили ROI фичи за счёт того, что снизили её стоимость в разработке. 4 часа и 4 недели — значительная разница.

Когда стоимость команды перестаёт быть абстракцией

Для разработчика не думать о деньгах нормально: у него и без финансовых потоков задач хватает. Для руководителя это становится опасно, потому что без стоимости работы все задачи легко начинают выглядеть одинаковыми.

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

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

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

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

А у нас всё важное!

На этом этапе обсуждения мои братья по духу и стартапам могут сказать, что у них вообще нет неважных фич. Добро пожаловать в клуб, друзья! Прямо сейчас в моём рабочем проекте просто нет неважных задач — последние полгода мы с командой добродушно посмеиваемся, что у нас всё «high crit blocker».

В таких условиях ещё важнее думать про ROI, ведь чем быстрее мы поставим нашим клиентам core value фичи — тем выгоднее всем. Практически всегда, практически в любой фиче можно срезать жирок / срезать углы / обойтись небольшим костыльком на будущее и тем самым увеличить ROI. Простейший запрос в LLM типа «вот описание фичи, что из неё можно выкинуть нахрен без потери ценности?» уже даёт много интересной пищи для размышлений.

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

Культура «разгребания жоп»: как мы сами растим хаос

Fri, 10 Apr 2026 00:00:00 GMT

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

Любой мало-мальски адекватный врач всегда говорит, что болезни проще предупреждать, чем лечить. С рабочими проблемами ситуация примерно такая же: гораздо проще и дешевле некоторую гипотетическую жопу оставить гипотетической, хорошенько подумав (желательно не один раз), чем потом её «героически» разгребать.

Почему так трудно предотвращать жопы?

Вспомните человека, который вам последний раз говорил (возможно, своим видом) «я же говорил(-а)». Представили? Вот он, типичный предотвратитель жоп в глазах общественности.

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

Другое дело с героическим разгребателем жоп. О, это настоящий народный герой, который с блеском в глазах кидается в пламя проблем и вытаскивает их на своём многострадальном горбу. За это ему потом воздают почести (и таблетки от гипертонии в юном возрасте). И все счастливы. Счастливы, да?

Позитивное подкрепление разгребания жоп

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

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

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

Как по-настоящему отдохнуть

Fri, 03 Apr 2026 00:00:00 GMT

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

Отдых должен снижать нагрузку

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

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

Так устроены мои любимые способы отдыха:

массаж и баня;
медитация;
растяжка по готовой тренировке;
художественная книга, если она не требует напряжённого анализа.

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

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

Расслабляться внутри рабочего дня

После хорошего отдыха у меня есть отдельная проблема: я начинаю работать как не в себя и быстро выжигаю накопленную энергию. Короткие перерывы сами по себе ситуацию почти не меняли.

Тогда мне попалась «Расслаблячка» Максима Дорофеева - практика, похожая на медитацию с последовательным расслаблением тела. В первый раз я просто уснул, поэтому после обеда лучше сразу заводить таймер.

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

Это мой личный способ восстанавливаться внутри дня, а не медицинская рекомендация.

Первые дни отпуска ещё не отпуск

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

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

Если продолжать в отпуске «читать полезные книги», следить за новостями и проверять рабочие чаты, поток нагрузки не снизится. Голове будет сложнее замедлиться.

Неделя или две

За 2,5 года я почти всегда отдыхал по неделе. Выходил из отпуска с желанием ещё немного почиллить, но в целом вроде бы было нормально.

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

Тогда я впервые за долгое время уехал на две недели. Контраст оказался огромным. Первая неделя ушла на то, чтобы затормозить и выдохнуть. Глубокий отдых для меня начался после этого. К концу второй недели я дошёл до состояния «как же задолбало ничего не делать». Для меня это хороший признак восстановления.

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

Главный критерий для меня прост: если после отдыха мне лучше, значит, это был отдых. Если нет, стоит менять нагрузку, форму или длину отдыха, а не уговаривать себя, что я ведь «ничего не делал».

Если дом стал офисом, выйти из дома

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

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

Выгрузить незавершённые дела

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

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

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

Как выйти из клуба гениальных советчиков

Mon, 30 Mar 2026 00:00:00 GMT

Одним из моих любимых персонажей в «Криминальном чтиве» всегда был мистер Вульф. Кстати, угадайте, кто второй?

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

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

Почему реализация сложнее

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

Мистера Вульфа отличают два качества, которые я ценю в людях и стараюсь развивать в себе:

у него есть идеи, как решить чужую проблему;
он умеет воплотить эти идеи в жизнь.

Он не ищет ветряные мельницы, с которыми можно сражаться. Его паттерн прост: к нему обращаются с проблемой, и он берёт ответственность за решение.

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

По-настоящему ценными становятся люди, которые не только знают, как «правильно», но и помогают довести решение до результата.

«Креативный программист», Ваутер Грунефелд

Fri, 27 Mar 2026 00:00:00 GMT

Работа программиста, несмотря на всю свою инженерную серьёзность, насыщена творчеством. Да, есть множество хороших практик и всё такое, но многие вещи невозможно сделать «правильно», потому что этого самого «правильно» просто не существует в природе.

Тем не менее, многие мои знакомые убеждены, что креативности нет места в техническом искусстве разработки ПО. Я с ними в этом всегда был не согласен – можно придумывать и реализовывать очень креативные штуки на вполне себе стандартных компонентах (этому меня научила вышка по радиоэлектронике). И вот я нашёл томик аргументов в пользу этого утверждения – книгу Ваутера Грунефелда «Креативный программист».

О чём книга

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

В книге раскрываются следующие темы:

Что вообще такое творческое мышление.
Связь знаний и творчества.
Как общение и ограничения влияют на творчество.
Методики творчества и творческого состояния ума.
Влияние критического мышления на творчество.

3 идеи из книги

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

Мои впечатления

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

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

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

Искренне рекомендую немного отвлечься от душной технины и почитать эту книгу. Она того стоит.

Предсказуемость как фундамент доверия

Mon, 23 Mar 2026 00:00:00 GMT

Когда-то у меня был коллега-SRE, с которым было невыносимо тяжко договариваться. Почти любой разговор вызывал страдания. Но если мы всё-таки договорились, я мог спокойно заниматься своими делами: коллега был человеком слова, и взятая им работа будет сделана.

Доверял ли я ему? Безусловно.

Симпатия легко притворяется доверием

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

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

Предсказуемый коллега выполняет обещанное. Если не может - предупреждает заранее. Если взялся за задачу - не бросает её молча на полпути.

Симпатия остаётся важной. Работать среди надёжных мудаков тоже удовольствие ниже среднего. Но приятное общение не должно подменять способность положиться на человека.

Обман ломает больше одной договорённости

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

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

Команде я объяснил решение прямо: у сотрудника было поддельное резюме и две работы. Этого оказалось достаточно.

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

Доверие строится из наблюдаемого поведения

Красивые слова о командности сами по себе ничего не дают. Доверие появляется из повторяющегося опыта: человек говорит, что сделает, выполняет это или заранее сообщает об изменениях.

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

Для рабочей команды доверие начинается с простой уверенности: слово человека что-то значит.

«Чистый дизайн. Практика эмпирического проектирования ПО», Кент Бек

Fri, 20 Mar 2026 00:00:00 GMT

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

«Хороший» код — вообще штука очень неоднозначная. Есть некоторые общепринятые правила и нормы, а дальше начинается система уровня «Легенды и мифы Древней Греции» — каждый верит в свой пантеон убеждений.

Мне всегда доставляло удовольствие эти убеждения изучать и разбирать: в IT работают умные люди, у которых много умных идей, и зачастую убеждения человека на чем-то основаны (кроме «Чистой архитектуры» — это прям вольные фантазии теоретика ПО). С целью разбора таких подходов я и взял почитать книжку Кента Бека — ветерана разработки ПО, приложившего руку к ряду важных вещей в индустрии.

О чем книга

Книга представляет собой методичку с концентрированным опытом Бека в области очистки кода. Он приводит примеры «грязи» в коде и рассказывает, как и зачем их удалять в весьма прагматичном стиле.

В книге раскрываются следующие темы:

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

3 идеи из книги

Очистка помогает перенести в код понимание, полученное с трудом. Больше всего времени в разработке занимает не написание кода, а его чтение. В процессе чтения мы накапливаем понимание, поэтому будет весьма выгодно потратить немного времени, чтобы зафиксировать свой труд — перенести это понимание в листинги проекта.
Иногда для проведения хорошей очистки нужно сначала свалить всё в кучу. Есть такой антипаттерн — дробление кода на излишне мелкие части (это еще Мартин в «Чистом коде» пропагандировал, кстати). Так вот, иногда подобные осколки кода нормально порефакторить просто невозможно, потому что понимание в голове не складывается. В таком случае можно просто заново собрать их в одну кучу, понять и переделать нормально.
Программистам платят не только за реализацию текущего поведения, но и за те возможности, которые открываются дальше. Вспомните свою работу: фичи едут «паровозиком», одна за другой, опираясь на предыдущие реализации. Так вот, программный дизайн дает возможность проще и быстрее менять поведение системы в будущем, что ускоряет поставку новых фич.

Мои впечатления

Эта книжка (я бы ее скорее методичкой назвал) — маленький, но крайне интересный концентрат взглядов Кента Бека на программный дизайн. При этом автор явно лишен перфекционизма и смотрит на мир шире: например, он аргументированно показывает, что вкладываться в защиту от багов может быть невыгодно с точки зрения как разработки, так и бизнеса.

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

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

Как разобрать проблемы спринта без токсичности и духоты

Wed, 18 Mar 2026 00:00:00 GMT

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

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

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

Icebreaker

Важности этой штуки меня научила работа на первом проекте в Т-Банке (Лена, если ты это читаешь — спасибо, твои айсбрейкеры всегда были бесподобны).

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

Смысл его — немного «растопить лёд» людей и включить их в общение. В моём случае это 5–7 минут на практику «опиши спринт одним мемом». Вещь простая, но каждый раз включается такое народное творчество, что я смеюсь до слёз. Эта простая практика помогает чуть-чуть снять напряжение и расслабиться.

«Парусник»

Саму ретроспективу я провожу по модели парусника. Суть её в том, что мы изображаем нашу команду как кораблик, плывущий к некоторой цели. Метафоры используются следующие:

Корабль — наша команда.
Остров вдалеке — наша цель.
Солнце — что нас порадовало.
Попутный ветер — что или кто нам помогал.
Якорь — что тащило нас назад.
Подводные скалы — какие есть риски на нашем пути.

Для ретро мы используем доску в Холсте, всё вышеописанное — это просто одна картинка с моими комментариями на ней. Мысли накидываем в виде стикеров в соответствующей области. На это обычно хватает 10 минут.

Action points

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

Предварительно мы тратим 5 минут на голосование: все участники с помощью ограниченного количества стикеров (5 штук на человека) отмечают те карточки, которые кажутся им наиболее важными. После чего мы копируем эти карточки в отдельное пространство рядом и начинаем обсуждение.

Ключевой вопрос к любой проблеме: «Что мы можем сделать, чтобы эта проблема решилась?» Не всё и не всегда зависит от нас. Иногда единственное доступное действие — зафиксировать риск, поднять его выше или пересобрать план. Мы фокусируемся на своей зоне влияния, а не делаем команду виноватой в любой внешней проблеме.

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

А как же «техника Х»?

Есть ещё целый мешок всяких полезных техник по проведению ретро: обзор поставки, Mad-Sad-Glad, «разбор факапов» и так далее. Все эти техники классные и рабочие, но при одном условии: вы чётко понимаете цель ретро. В противном случае можно скакать с техники на технику и не добиваться никакого результата.

Как принимать сложные решения по одному шагу

Mon, 16 Mar 2026 00:00:00 GMT

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

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

Каково следующее правильное действие?

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

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

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

Поэтому, когда полное решение не даётся, я спрашиваю себя:

Каким будет моё следующее правильное действие?

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

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

Как решение затронет других?

В управлении почти не бывает решений без побочных эффектов. Любое решение руководителя касается других людей.

Поэтому второй вопрос я беру из золотого правила нравственности:

Поступаю ли я с другими так, как хотел бы, чтобы поступали со мной?

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

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

«AI-инженерия. Построение приложений с использованием базовых моделей», Чип Хьюен

Fri, 13 Mar 2026 00:00:00 GMT

В последнее время я стараюсь поглубже влезть в такие темы, как ML и AI. Причина проста — в рабочем проекте активно используются и разрабатываются фичи на базе обоих видов технологий. А руководить разработкой того, в чём не разбираешься — задачка со звёздочкой (и без смысла).

Поэтому я с переменным успехом прохожу курс по ML. И по этой же причине я взял книгу о том, как строить приложения с использованием базовых моделей. Мне не очень интересно, как написать свой GPT, но разбираться в устройстве и принципах работы LLM — довольно полезно и увлекательно.

О чём книга

Книга посвящена тому, как адаптировать базовые LLM (и LMM) модели для создания AI-приложений. Она помогает понять, стоит ли вообще разрабатывать приложение на базе AI, какая модель нужна, как её выбрать, что с ней потом делать и так далее.

В книге раскрываются следующие темы:

Как вообще появилась AI-инженерия
Как создаются и обучаются LLM-модели
Как оценивать качество работы AI-систем
Улучшение результатов работы приложения: промпт-инжиниринг, RAG, дообучение
Оптимизация AI-приложений

3 идеи из книги

Первый шаг к системной разработке серьёзного AI-приложения — это не выбор модели, а разработка системы оценки качества работы. Без оценки, которая поможет отслеживать сбои, отклонения и неожиданные аномалии, будет невероятно сложно развивать продукт. Помножьте это на вероятностную природу самих LLM, и поймёте, насколько это непростой процесс. Между тем для бизнеса всё ещё важен ROI, и приложение должно доказывать свою полезность.
Один из методов снизить косты на модель — разбить рабочий процесс на шаги и использовать более слабую модель для более простых задач. Чаще всего даже просто разбиение запроса на подзапросы увеличит эффективность, а использование более простой модели сделает обработку одного запроса дешевле.
Дообучение модели может улучшить её способность решать одни задачи, но вместе с этим ухудшить способность решать другие задачи. Если модель используется универсально, для решения множества задач — дообучение может навредить многим рабочим процессам, поэтому заниматься им нужно внимательно и осторожно.

Мои впечатления

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

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

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

Мыслительная жвачка: как непринятые решения жрут ваш мозг

Mon, 09 Mar 2026 00:00:00 GMT

Вроде только проснулся, а голова уже квадратная и гудит. Мысли жужжат как рой пчёл, накатывает тревога, и настроение на день уже испорчено.

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

Жвачка непринятого решения

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

Мне как-то понадобилось пройти одно лечение. Я несколько недель никак не мог приступить. Каждый день в голове варился суп из мыслей «надо начать, пора начать». В какой-то момент я принял решение и сделал следующее правильное действие. На следующий день жвачка исчезла: теперь я был в новом процессе.

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

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

Когда решение пока нельзя принять, я стараюсь записать вопрос и вернуться к нему в определённое время. Запись не решает проблему, зато помогает не пережёвывать её каждые пять минут.

Когда решение принято только головой

Бывает сложнее. Решение вроде принято и даже начало исполняться, но сомнения не пропадают. Я называю такие решения недопринятыми.

Лет восемь назад я решил закончить с тхэквондо за полгода до аттестации на чёрный пояс. У меня появились травмы, несовместимые с этим спортом.

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

Тренировки я прекратил, но ещё несколько меся размышлял, правильно ли поступил. С затуханиями эта мысль возвращалась годами.

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

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

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

Blameless culture: как перестать искать виноватых и начать чинить системы

Fri, 06 Mar 2026 00:00:00 GMT

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

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

Blameless culture. Как правильно работать с инцидентами, Андрей Синицын

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

Доклад не про сами post mortem, а про безобвинительную культуру, которая является фундаментом. Если на post mortem искать виноватых и раздавать наказания, то работать они не будут никогда.

Интересные идеи

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

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

Action Items с post mortem пробивают все бэклоги и имеют критический приоритет. Для команды инфраструктуры, от которой зависит целый огромный бизнес, такой подход — норма. Для обычных команд разработки некоторые action items могут быть менее приоритетными. Тем не менее кто-то должен следить за тем, чтобы они были выполнены.

How to run a great incident post-mortem

How-to по blameless culture — отличное продолжение предыдущего доклада. Автор по сути даёт простой фреймворк обсуждения на post mortem без поиска виноватых и взаимных обвинений.

Мне понравился подход «второй истории»: сначала говорим про очевидные ошибки, а потом закапываемся в системные штуки, которые эту ошибку допустили. Это позволяет копать глубже, чем просто «давайте ещё один алерт повесим».

Postmortem Culture: Learning from Failure

Шикарная статья от Google о их философии проведения post mortem. В ней чётко видно, что организация использует post mortem для исправления ошибок и взаимного обучения (например, есть рубрика «post mortem месяца», в которой раз в месяц хорошо написанный документ распространяется на всю организацию).

Статья скорее предназначена для формирования правильного отношения к post mortem. Тем не менее она будет очень полезна на старте и даёт пачку классных идей для дальнейшего развития культуры.

Также у Google есть отличный пример post mortem.

Incident postmortems

В целом handbook по управлению инцидентами от Atlassian очень крут, и в нём много чего полезного. Конкретно эта статья — прекрасная методичка того, как проводить post mortem. Она даёт ответы на конкретные вопросы: кто, что, где, как и так далее. В том числе в ней содержится довольно хороший (хоть и объёмный) шаблон post mortem, который можно использовать в своих проектах.

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

Всем желаю blameless post mortem и стабильных систем!

// Поделитесь, пожалуйста, в комментариях, как вам такой формат?

Токены не бесплатные: где ломается экономика AI-продукта

Mon, 02 Mar 2026 00:00:00 GMT

В обсуждениях AI-продуктов много разговоров о возможностях моделей и мало разговоров о деньгах. Пока компания проверяет гипотезу, это легко пропустить. Проблема начинается, когда эксперимент превращается в продукт и руководители спрашивают: «Где деньги, Лебовски?»

Токены становятся переменной себестоимостью

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

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

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

Среднее скрывает неприятный хвост

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

Поэтому считать полезно не абстрактный «токен», а законченный пользовательский результат:

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

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

Оптимизация начинается с ограничений продукта

Экономика AI-продукта не сводится к выбору самой дешёвой модели. Иногда выгоднее сократить контекст, ограничить число шагов, вынести часть работы в обычный код или вовремя остановить исследование. Где-то дорогая модель окупается качеством, а где-то не окупается вообще.

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

Как не дать ИИ-хайпу сожрать здравый смысл

Mon, 23 Feb 2026 00:00:00 GMT

Вокруг ИИ хватает противоположных прогнозов: от полного отрицания возможностей технологии до уверенности, что она вот-вот заменит всех. Крайние позиции часто объединяет одно — недостаточная компетентность в вопросе.

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

Откуда дровишки?

Есть ли у человека подтверждённый практический опыт в том, о чём он говорит?
Достаточен ли этот опыт для сделанного вывода?
Понимает ли человек базу под собственным опытом? Написать «свой GPT» с помощью LLM не означает понять, как создаются модели.
Какие явные и скрытые допущения есть в утверждении? Чем они обоснованы?
Насколько человек заинтересован в конкретном выводе? Когда руководитель AI-компании говорит, что ИИ захватит мир, полезно помнить, на чём он зарабатывает.

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

Проверить себя тем же фильтром

Эти вопросы я задаю и себе. Самый надёжный способ улучшить собственные выводы — повышать компетентность. Поэтому я читаю книги о построении моделей и приложений на базе AI, а ещё прошёл на работе базовый курс по ML. Мозги скрипели особенно громко: десять лет математики не видали.

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

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

«Эволюционная архитектура», Нил Форд и др.

Fri, 20 Feb 2026 00:00:00 GMT

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

Я наблюдал такие истории несколько раз, и мне всегда было интересно: как поддерживать архитектуру в качественном состоянии? Рисование «квадратиков» и сотрясание воздуха на созвонах не помогают — нужны реальные действия. Поэтому я решил прочесть (очередную) книгу Нила Форда и его коллег — «Эволюционная архитектура».

О чём книга

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

В книге раскрываются следующие темы:

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

3 идеи из книги

Данные должны эволюционировать вместе с кодом. Я неоднократно встречал системы, где разработчики создавали изящные сервисы по канонам DDD, но все они обращались к единой базе данных. В итоге получался «распределенный монолит». Проблема в том, что данные мигрировать гораздо сложнее, чем код, поэтому проектирование изменений стоит начинать именно с них.
Влияние DevOps на архитектурную гибкость. Практики DevOps напрямую ускоряют эволюцию системы: чем быстрее и прозрачнее процесс поставки, тем легче внедрять архитектурные изменения, делая их атомарными. Проще говоря, появляется возможность «есть слона по частям», что значительно упрощает любую трансформацию.
Механизмы контроля характеристик. По мере развития системы необходимы инструменты, оценивающие влияние изменений на ключевые параметры. Если архитектура поддерживает фитнес-функции, архитектор может определить критерии пригодности, которые будут автоматически защищать критически важные характеристики системы.

Мои впечатления

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

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

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

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

Почему я чищу подписки: метод «проверки рублём»

Wed, 18 Feb 2026 00:00:00 GMT

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

Я высвобождаю своё внимание.

Внимание тоже приходится тратить

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

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

С контентом сложнее. Источник может нравиться и приносить удовольствие, а цену потребления трудно измерить.

Проверка рублём

Поэтому я задаю себе один вопрос: «Если бы этот источник завтра стал платным, я бы стал за него платить?»

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

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

«Head First. Архитектура ПО», Марк Ричардс и др.

Fri, 13 Feb 2026 00:00:00 GMT

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

В этот момент я задумался: а нет ли у меня в запасе книги, которая была бы одновременно простой, понятной и достаточно информативной для людей, которые не занимаются разработкой напрямую? Готового ответа не приходило, потому что я такие книги давно не читаю (неинтересно). Но я вспомнил о «Head First Архитектура ПО» за авторством Марка Ричардса (который написал целую пачку книг по архитектуре) и его друзей.

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

О чём книга

Книга – это введение в построение архитектуры ПО (по рецептам Ричардса и компании). Она проводит читателя от самых азов архитектуры к построению довольно сложных систем.

В книге раскрываются следующие темы:

Что такое архитектурные характеристики
Какие бывают архитектурные стили и в чём их отличия
Как делить систему на логические компоненты
Что такое микросервисная архитектура и чем она отличается от событийной

Мои впечатления

Традиционный раздел с идеями я пропустил, потому что в книге для меня не было ничего особенно нового и неожиданного (разве что я от души посмеялся над весьма ироничным советом «не использовать аббревиатуры просто так»).

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

Опытному инженеру книга вряд ли будет полезна, однако мидлам я бы рекомендовал начинать своё знакомство с архитектурой именно с «Head First Архитектура ПО». Она даст качественное понимание многих базовых концепций, в которые потом при желании можно будет углубиться.

Рекомендую!

Как сократить поток сообщений без потери контроля

Wed, 11 Feb 2026 00:00:00 GMT

Как руководитель, я постоянно получаю целый ворох уведомлений: личные сообщения, упоминания, треды в каналах, которые нужно мониторить, Telegram, почта… Наверняка что-то ещё забыл.

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

Сообщения — это следствие, а не причина

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

Например, если в команде часто спрашивают: «Дайте ссылку на Grafana», — имеет смысл закрепить её в общем чате. А если вопросы вызывает какой-то процесс (например, релиз на прод), можно написать простой ранбук с последовательностью действий. Такие решения просты в реализации, но они отлично отсекают лишние вопросы.

Писать понятно

Частая причина долгих переписок — плохо структурированный запрос. Все мы знаем эту ловушку: «Помоги, пожалуйста, тут буквально на 10 минуточек». Точно так же и в тексте: чем хуже сформулирован запрос, тем дольше продлится выяснение деталей. Добавьте к этому асинхронность мессенджеров — и получите переписку на несколько дней.

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

Не писать там, где это не нужно

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

Не отвечать сразу

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

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

Описанные приёмы я применяю постоянно. Да, они вряд ли создадут абсолютную тишину в эфире — я слабо верю, что в моей работе это возможно. Но мне это и не нужно. Вполне достаточно чувства, что я «мету свою сторону улицы» и подаю команде хороший пример.

Деплой как зеркало организации: что релизы говорят о процессах

Mon, 09 Feb 2026 00:00:00 GMT

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

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

Слабая поставка — кошмарная работа

Мне несколько раз доводилось работать в организациях с плохо выстроенными процессами поставки, и каждый раз это был путь через страдания. Сборки релиза занимали колоссальное время, на этапе тестирования всплывали неожиданные баги, сами релизы «падали» в процессе выкатки, а после деплоя еще несколько дней с прода прилетали инциденты, которые приходилось экстренно чинить.

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

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

Как DevOps влияет на процессы

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

Нисходящую спираль можно развернуть. Но для этого нужно:

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

Вот почему методология DevOps неразрывно связана с культурой: она не только про технологии, но и про людей. Хотя со стороны кажется, что меняются лишь технические аспекты, на деле эти трансформации затрагивают «культурный код» компании. Если команда стремится работать в комфортной среде и создавать качественный продукт, это неизбежно отразится и на процессах, и на результате.

«Жемчужины разработки. Чему мы научились за 50 лет создания ПО», Карл Вигерс

Fri, 06 Feb 2026 00:00:00 GMT

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

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

О чём книга

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

В книге раскрываются следующие темы:

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

3 идеи из книги

Требования — это фундамент. Все команды должны серьёзно относиться к работе с требованиями. Пренебрежение ими приводит к потере времени из-за переделок, хаотичным коммуникациям, конфликтам и снижению качества итогового продукта.
Избегайте расстановки приоритетов «по децибелам». Часто идей гораздо больше, чем ресурсов, а стейкхолдеры постоянно конфликтуют. В таких случаях возникает соблазн прислушаться к тому, кто кричит громче всех. Но это слабая стратегия. Гораздо эффективнее использовать объективные методы приоритезации.
Время, потраченное на проектирование, окупается отсутствием исправлений в будущем. Этот урок я освоил на практике (и довольно болезненно). Всегда есть искушение сказать: «Да всё понятно, погнали код писать!». Но при реализации любой мало-мальски сложной фичи это почти всегда приводит к багам. Конечно, не стоит вылизывать всё до идеала, но и крайность «быстрой разработки» не менее опасна.

Мои впечатления

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

Книга вряд ли станет для вас сборником откровений. Но она напоминает о простых и невероятно важных вещах, о которых мы часто забываем: требованиях, проектировании и командной работе.

Рекомендую к прочтению на досуге — как минимум приятно проведёте время. Также можно изучать отдельные уроки выборочно — контекст вы не потеряете.

Почему расширение команды снижает её общий КПД

Wed, 04 Feb 2026 00:00:00 GMT

Начинающих тимлидов часто приучают к мысли, что инженерные команды должны быть небольшими: магическое число семь, two-pizza team и всё такое.

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

Один человек не даёт линейного прироста

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

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

Растёт и число профессиональных конфликтов. Это не обязательно обмен «любезностями». У инженеров просто чаще расходятся взгляды на решения, и на согласование уходит время.

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

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

Когда пора думать о разделении

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

Я бы смотрел на несколько признаков:

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

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

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

«System Design II. Распределённые системы», Алекс Сюй и Сан Лэм

Fri, 30 Jan 2026 00:00:00 GMT

Сегодня у меня немного необычный обзор. Необычен он тем, что моё имя впервые попало на обложку (пусть пока и не в качестве автора). Когда ко мне пришли коллеги из ИД «Питер» и предложили дать краткий комментарий к продолжению одной из самых известных книг по System Design, я согласился не раздумывая.

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

О чём книга

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

Несколько интересных кейсов из книги:

Google Карты;
агрегация рекламных кликов;
лидерборд в реальном времени;
платёжная система;
фондовая биржа.

Мои впечатления

Логичнее всего читать это издание как продолжение первой части, но при этом оно вполне самодостаточно: любая задача понятна и без общих советов по прохождению интервью. При этом «System Design II» мне в некотором роде понравилась даже больше, так как она фокусируется не на самом алгоритме собеседования, а на решении прикладных задач.

Конечно, в разборах учтены не все нюансы (это физически невозможно уместить в одну книгу). Но Сюй не изменяет себе: материал подан просто, понятно и читается довольно легко. Книга точно поможет инженерам расширить кругозор и обнаружить «слепые пятна», в которые стоит углубиться.

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

Как настроить внимание под себя

Mon, 26 Jan 2026 00:00:00 GMT

Книга Криса Бэйли «Гиперфокус» подтолкнула меня к простому эксперименту: убирать смартфон из поля зрения и наблюдать, стану ли я меньше отвлекаться.

Почти все уведомления на смартфоне я отключил ещё лет пять назад. Но даже без них в телефоне всегда есть «что-то интересненькое».

Убрать раздражитель

Для проверки идеи я решил:

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

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

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

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

Отвлечение может работать на меня

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

Когда разбираю такие входящие, я спрашиваю себя: «Это отвлечение работает на меня или против меня?» Например:

оповещение о сбое - оставил;
напоминание об отдыхе на компьютере - оставил;
такое же напоминание на часах - отключил;
пару Telegram-каналов с мемами - убрал в отдельную папку.

Перерыв тоже часть настройки

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

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

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

«Гиперфокус», Крис Бэйли

Fri, 16 Jan 2026 00:00:00 GMT

Перед Новым годом мне стало интересно поисследовать тему сфокусированной работы. Я прочитал три книги, на две из которых уже написал обзоры: «Украденный фокус», Йоханн Хари «Неотвлекаемые», Нир Эяль

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

О чём книга

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

В книге раскрываются следующие темы:

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

Три идеи из книги

Мы не только то, что мы едим. Мы ещё и то, на что мы обращаем внимание. Внимание не бесконечно — это один из самых ценных ресурсов для хорошей жизни. Если мы тратим его на потребление третьесортного контента, то вряд ли нашей голове от этого будет хорошо (это как питаться «дошиками»).
Начинать нужно не с навыка концентрироваться, а с формирования намерения. Если я не понимаю, чем занимаюсь сейчас и зачем мне это нужно, то и концентрации не достичь — на чём я концентрироваться-то буду? Лучший способ повысить концентрацию на практике — понять, какого результата я хочу добиться.
Расфокусировка действенна только тогда, когда применяется сознательно. Если я уплываю в свои мысли, чтобы отвлечься от текущей деятельности, — это не продуктивная расфокусировка. А если я вполне осознанно запускаю свои мысли в свободное плавание и фиксирую то, что всплывает, — тогда результат будет положительным.

Мои впечатления

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

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

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

P.S. У меня есть идея немного разбавить свой пятничный формат интересными статьями и видео, которые я изучаю. В них часто бывает замечательный контент, который я не хочу обходить стороной. Как вам идея? Делитесь в комментариях 🙂

Руководитель управляет процессами

Mon, 12 Jan 2026 00:00:00 GMT

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

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

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

Начать со своей модели управления

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

Убеждение «команде нужен погонщик» особенно опасно тем, что объясняет любую проблему одинаково. Срок сорван - люди плохо работали. Качество упало - люди невнимательны. Задачи застряли - нужно сильнее надавить.

Такая модель экономит руководителю размышления, но скрывает реальные причины.

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

Поэтому перед тем, как «чинить команду», полезно проверить собственное объяснение проблемы. Если неудовлетворительный результат показывает вся команда, версия о внезапном нашествии лоу-перформеров выглядит слабее версии о плохой системе работы.

Искать потери, а не виноватых

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

К ней относится всё, чего команда не собиралась делать:

поднять упавший прод;
срочно исправить критический баг;
взять в спринт очередную ASAP-задачу;
переделать решение из-за пропущенного требования;
потратить два дня на релиз, который должен был занять два часа;
помочь «на десять минут», которые незаметно съели полдня.

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

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

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

Хватит начинать, начните заканчивать

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

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

Принцип Stop Starting, Start Finishing переносит внимание на завершение уже начатого. На практике это может выглядеть так:

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

Подробнее работу с такими ограничениями я разбираю в лонгриде «Как найти ограничение и ускорить поставку».

Чем тогда управляет руководитель

Руководитель управляет условиями, в которых команда делает работу:

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

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

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

Если команда работает без руководителя

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

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

Но автономность команды — не доказательство бесполезности руководителя. Наоборот, это один из результатов его работы.

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

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

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

О новогодних чудесах

Mon, 29 Dec 2025 00:00:00 GMT

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

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

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

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

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

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

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

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

«Неотвлекаемые», Нир Эяль

Fri, 26 Dec 2025 00:00:00 GMT

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

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

О чём книга

Книга посвящена особенностям нашей психики, из-за которых мы постоянно отвлекаемся. Она богата как описаниями этих механизмов, так и практическими идеями по их преодолению.

В книге раскрываются следующие темы:

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

Три идеи из книги

Отвлечение — это следствие, а не причина. Мы часто перекладываем ответственность на гаджеты, не задумываясь, почему сместили на них фокус. Чаще всего мы отвлекаемся потому, что подсознательно хотим «сбежать» от текущей задачи. Например, идём посмотреть свежие мемчики, потому что в таске требования не описаны толком и над ними нужно подумать.
Причина «побега» — дискомфорт. Если мы его испытываем, то пытаемся уйти туда, где его якобы нет. К такому поведению относится и имитация бурной деятельности (ИБД): бесконечные рабочие чаты, уточнение мелких вопросов и прочая болтология. ИБД создаёт иллюзию продуктивности, хотя на деле это просто форма прокрастинации.
Чтобы понять отвлечение, нужно знать, от чего вы отвлекаетесь. Один из инструментов здесь — таймбоксинг (разбиение календаря на временные слоты под конкретные задачи). Только имея четкий план, вы сможете честно ответить себе на вопрос: «От чего именно я сейчас пытаюсь сбежать?»

Мои впечатления

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

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

Автор также напоминает: технологии — это благо при правильном применении. Важно лишь помнить, кто в доме хозяин, и заставлять их служить себе, а не наоборот.

Итог: Книга мне понравилась. Она понятная, глубокая и подталкивает к анализу причин своих трудностей, вместо того чтобы просто предлагать слепое копирование очередных «лайфхаков».

Как перестать демотивировать людей

Mon, 22 Dec 2025 00:00:00 GMT

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

О чём выступление

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

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

«Украденный фокус», Йоханн Хари

Fri, 19 Dec 2025 00:00:00 GMT

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

Сейчас я неспешно прорабатываю книгу «Путь джедая» Максима Дорофеева, и она мне уже ощутимо помогает. Тем не менее мне стала интересна тема фокуса и развития навыка концентрироваться на задаче (хотя на самом деле там целая куча поднавыков). Поэтому я решил углубиться и почитать фоном известную литературу на эту тему. И первой на очереди стала книга с говорящим названием — «Украденный фокус».

О чём книга

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

В книге раскрываются следующие темы:

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

Три идеи из книги

Скорость vs Качество. Мы убедили себя, что можем наращивать скорость потребления и обработки информации без последствий. Но на самом деле увеличение скорости быстрее расходует наши силы, а погружение и размышления требуют времени. Отчасти поэтому я не верю в скорочтение, например. :)

Экономика внимания. Сон — проблема для капиталистического мира, потому что во сне человек ничего не производит и не потребляет. Низкий стресс, кстати, тоже является проблемой, потому что в стрессе люди более склонны к компульсивным действиям (и в частности — к покупкам). Если все резко начнут нормально спать и отдыхать, прибыль корпораций снизится, а они этого не хотят.

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

Мои впечатления

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

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

Всё время чтения в воздухе висел вопрос: «Окей, а делать-то что?» То, что плохой сон, стресс и переключения внимания негативно влияют на концентрацию — вещи вполне очевидные. Но автор не ставит перед собой задачи помочь читателю изменить жизнь. По моим ощущениям, его целью было написать книгу о своём нытье и недовольстве «злым миром» вокруг. :)

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

«Дао Toyota», Джеффри Лайкер

Fri, 12 Dec 2025 00:00:00 GMT

Эта книга лежала у меня в бэклоге довольно давно. Тема бережливого производства интересна, а уж в контексте эффективной разработки IT-продуктов — и подавно. Тем не менее у меня до неё систематически не доходили руки, и всегда находилось что-то более «горящее».

Волшебным пинком оказался книжный клуб для руководителей на новой работе (куда я вписался в тот же миг, как узнал о его существовании). «Дао Toyota» была выбрана темой следующей встречи (которая состоится через пару недель). На самой встрече мы будем обсуждать книгу, поэтому прочитать её нужно заранее. Что я и сделал :)

О чём книга

Книга посвящена философии, на которой строится производственная система (и успех) Toyota. Автор рассказывает об основных принципах этой философии и приводит примеры их применения в повседневной работе заводов.

В книге раскрываются следующие темы:

история семьи Тоёда и становление компании;
в чём заключается суть философии Toyota;
на каких принципах основана эта философия;
как начать применять методы Toyota в своей организации.

3 идеи из книги

Главный секрет Toyota заключается не в отдельных приёмах, методах или принципах, а в том, что все они работают как единая система. Во многом по этой причине проваливаются попытки внедрить бережливое производство — люди используют инструменты, не понимая их связи с другими инструментами.
Бережливое производство фокусируется на действиях, которые создают добавленную ценность для потребителя. Всё остальное Toyota считает потерями и старается либо вовсе убрать, либо свести к минимуму. И первый вопрос всегда один: «Чего ждёт от этого процесса потребитель?»
Одним из источников потерь является перегрузка (как людей, так и оборудования). Если заставлять всё и вся вокруг работать на пределе возможностей, это неизбежно ведёт к деградации производительности и снижению качества (а в условиях производства это ещё и небезопасно). Перегрузка ведёт к авариям и дефектам.

Мои впечатления

Если бы «Дао Toyota» писали для современного читателя, то получилось бы примерно 15–20 «бестселлеров New York Times». Книга очень плотная как по идеям, так и по их смыслу.

Автор не просто показывает основные принципы, на которых зиждется философия Toyota, — он также старается показать их взаимосвязь, совместное применение и то, как они выстраиваются в единую, целостную систему. Также в книге много отличных примеров применения этих принципов.

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

Конечно, практики Toyota затруднительно взять и переложить на разработку ПО, которой всю сознательную карьеру занимается ваш покорный слуга. Однако идеи «Дао Toyota» довольно универсальны и практикоприменимы — над ними стоит как минимум хорошенько подумать. И тем не менее, у меня остались вопросы, ответы на которые я хочу поискать в других книгах по бережливому производству в IT.

Баги в голове, которые мешают расти

Mon, 08 Dec 2025 00:00:00 GMT

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

О чём выступление

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

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

«Общаться с ребёнком. Как?», Юлия Гиппенрейтер

Fri, 05 Dec 2025 00:00:00 GMT

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

Книгу Юлии Гиппенрейтер мне рекомендовало уже несколько весьма уважаемых мною людей. Но при этом у меня всё время на подкорке крутился вопрос: «Как книга по общению с детьми поможет мне в работе? Тут же взрослые люди, с ними общение строится совершенно иначе».

Книга показала мне, что я прав лишь отчасти.

О чём книга

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

В книге раскрываются следующие темы:

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

Три идеи из книги

Не вмешивайтесь в дело, которым занят ребёнок, даже если он что-то делает «неправильно» (только если это «неправильно» не угрожает его здоровью). Тем самым вы даёте ему сигнал: «С тобой всё в порядке, ты справляешься!» Но если ребёнок просит о помощи — будьте готовы её оказать.
Если поведение ребёнка вызывает у вас отрицательные переживания — сообщите ему об этом через «я-высказывания». Не следует держать негатив в себе — ничем хорошим это не закончится (чаша терпения имеет свойство переполняться). Вместо «ты»-части сообщения можно использовать обезличенное высказывание («Меня раздражает это твоё хныканье!» → «Меня раздражает, когда дети хнычут»).
Детям не просто нужны правила поведения — они ждут их. Наличие однозначных правил делает их жизнь понятной и предсказуемой, что, в свою очередь, создаёт чувство безопасности. Зачастую дети протестуют не против самих правил, а против силовых методов их внедрения.

Мои впечатления

Книга вызвала у меня две сильные эмоции: огорчение и удивление.

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

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

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

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

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

Бесценный клад с идеями, рекомендую!

ИИ — это вторая пара рук, а не мозг

Wed, 03 Dec 2025 00:00:00 GMT

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

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

Как ИИ стал моим помощником

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

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

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

Однажды благодаря такому помощнику я два месяца писал на Python, хотя раньше на нём не программировал.

Руки, а не мозг

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

Мои агенты поэтому играют довольно приземлённые роли:

корректор расставляет знаки препинания;
критик даёт обратную связь;
джун-программист пишет небольшие куски кода по готовому ТЗ;
узкий специалист смотрит на задачу с нужной стороны.

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

Где начинается опасная подмена

Граница проходит между «я использую ИИ для решения своих задач» и «ИИ думает за меня».

Я всё чаще слышу формулировки вроде «я провёл анализ через ИИ», «ИИ это так аргументирует» или «мне ИИ это посоветовал». Проблема не в самом инструменте, а в перекладывании на него конечной ответственности.

LLM очень исполнительны. Они дадут ответ почти на любой вопрос, даже если сам вопрос неверен. Но только человек может остановиться и спросить: «Я вообще ту проблему решаю? Зачем мне это нужно? Какие у меня допущения?»

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

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

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

Что мне дал год 12-недельного планирования

Mon, 01 Dec 2025 00:00:00 GMT

Примерно год назад у меня появилось ощущение бардака в жизни. Вроде работаю много, дела всякие-разные делаю — но как-то не складываются они у меня в одну картинку. С виду всё было гладко: я ставил цели и двигался к ним. Но внутри всё равно оставалось ощущение, что что-то идёт не так.

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

Вот что я понял за год практики.

Видение важнее списка целей

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

В объём я всё равно не попадаю

В первый же спринт я запланировал раза в два больше, чем смог выполнить. Учёл ошибку — и во втором спринте недопланировал. Эти качели продолжаются до сих пор: идеально попасть в объём не получилось ни разу. Но 12-недельное планирование предназначено не для идеального прогноза.

Маленькие действия тоже считаются

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

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

Я до сих пор не научился нормально проводить недельную и итоговую рефлексию. Не умею качественно организовывать 13-ю неделю и отмечать достигнутые результаты. Но даже в урезанном виде система решает мою задачу.

Бывали и недели вообще без целей и планов: из-за болезни, усталости или высокого уровня неопределённости. Это не разрушило систему. Иногда можно забить, а затем вернуться.

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

«Лидер и племя», Дэйв Логан, Джон Кинг и Хэли Фишер-Райт

Fri, 28 Nov 2025 00:00:00 GMT

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

Исключением не является и работа, на которой мы точно так же сбиваемся в племена (некоторые компании свои подразделения даже называют «трайбами»). И задача лидера в таком племени — растить и развивать его. Этой теме и посвящена книга «Лидер и племя».

О чём книга

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

В книге раскрываются следующие темы:

Пять уровней племени и как себя ведут люди на этих уровнях.
Что важно людям на каждом из уровней.
Как переходить с уровня на уровень.
Как стабилизироваться на новом уровне.

3 идеи из книги

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

Мои впечатления

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

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

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

Чему можно научиться у плохого руководителя

Wed, 26 Nov 2025 00:00:00 GMT

Иногда полезно вернуться к основам — просто чтобы понять, как далеко ты на самом деле успел утопать. Вот и на новой работе я попал на тренинг (отличный, кстати!) по обратной связи.

Тема для меня не слишком новая — пару собак я уже прожевал, — но в тренинге принимал самое активное участие. Отчасти в надежде понять что-то новое для себя, отчасти — в надежде помочь понять что-то новое другим.

Отличительной особенностью этого тренинга было обсуждение теории прямо «на ходу». Тренер подталкивал участников разбираться в разных компонентах и нюансах обратной связи, высказывать своё мнение, делиться опытом и так далее. А опыта работы с обратной связью у меня накопилось немало. Например, я уже писал, как защищаться от неконструктивной обратной связи. Поэтому я начал травить разные байки из своей жизни.

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

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

Давать обратную связь.
Принимать обратную связь.
Развивать сотрудников.
Заниматься планированием.
Договариваться с бизнесом.
Планировать работу.
Проектировать архитектуру.
Принимать решения.
Не принимать решения.
И многое-многое другое…

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

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

Наставничество в кайф: как учиться самому, обучая джунов

Mon, 17 Nov 2025 00:00:00 GMT

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

О чём выступление

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

Accelerate by Nicole Forsgren, Jez Humble, Gene Kim

Fri, 14 Nov 2025 00:00:00 GMT

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

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

Книга Accelerate посвящена именно этой теме.

О чём книга

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

В ней раскрываются следующие темы:

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

Три идеи из книги

В качестве основных метрик производительности поставки авторы отмечают lead time, частоту релизов и время на восстановление после ошибки или сбоя. Первые две метрики, по сути, показывают, как быстро и часто команда может поставлять ценность, а третья — как быстро она может исправить косяк, случайно проскочивший на прод :)
Высокопроизводительные команды много вкладывают в автоматизацию своих процессов в целом и тестирования в частности. Они стараются уменьшить количество повторяющейся ручной работы, чтобы вместо этого заниматься поставкой ценности.
Болезненность деплоев можно рассматривать как прокси на общий уровень страданий команды. Если раскатывать изменения тяжело и больно, то команда с высокой долей вероятности будет страдать и показывать низкие результаты и в процессе разработки. Также авторы обнаружили, что болезненные деплои часто идут рука об руку с низкой организационной производительностью и слабой культурой.

Мои впечатления

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

А вот вторая половина книги содержит описание методов исследования. Наверное, это нужно было бы для научной статьи, но в книге выглядит как седло на корове. Лично мне эта информация не дала никакой дополнительной ценности, но если вам очень захочется докопаться до авторов — можете почитать :)

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

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

Синдром самозванца: какие достижения я отказываюсь признавать

Wed, 12 Nov 2025 00:00:00 GMT

Однажды я выступал на TeamLeadConf. Давно хотел попасть на эту конференцию и несколько месяцев готовил доклад.

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

Но где-то в середине доклада в голову влетела шальная мысль:

Я же какую-то херню несу. Что за ужас, меня сейчас на смех поднимут!

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

Я не знаю, как гарантированно избавляться от таких сомнений. Иногда мне помогает развернуть их вопросом:

Какие свои результаты и достижения я сейчас отказываюсь признавать?

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

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

Иногда сомнение указывает не на отсутствие компетентности, а на достижение, которое я ещё не успел присвоить.

Event Sourcing: ключевые принципы и реализация на NestJS

Wed, 12 Nov 2025 00:00:00 GMT

Доклад о том, какие задачи решает Event Sourcing и какой сложностью приходится платить за полную историю изменений системы. На примере NestJS я пошагово превращаю обычное CRUD-приложение в приложение, построенное вокруг событий.

О чём выступление

Что такое Event Sourcing и в каких задачах он может быть полезен.
Какие возможности даёт хранение истории событий: восстановление состояния, анализ изменений и более прозрачная отладка.
Какие сложности и типичные ошибки появляются при работе с событиями.
Как постепенно внедрять Event Sourcing в уже существующее приложение.
Почему этот паттерн не стоит воспринимать как «серебряную пулю».

Event Sourcing полезен не сам по себе, а как осознанный архитектурный компромисс. Перед внедрением стоит проверить, действительно ли проекту нужна полная история изменений и готовы ли команда и инфраструктура платить за неё дополнительной сложностью.

Как я на собственных нервах проверил бесполезность теории

Mon, 10 Nov 2025 00:00:00 GMT

Я уже неоднократно писал, что потребление большого количества информации переоценено: знать не значит делать. Подробнее об этом — в материале «Как учиться осмысленно». А на прошлой неделе я получил очередной неприятный урок от жизни на эту тему.

Я и моя бессонница

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

Все привычные методы борьбы с бессонницей уже испробованы:

кот потискан;
книжка почитана;
комната проветрена;
медитация помедитирована;
даже мелатонин выпит.

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

Как я завтра вообще буду функционировать после такого количества сна?
А что, если я вообще не смогу уснуть?

Эмоционально я тревожусь и подгораю пониже поясницы. И ничего не могу с этим поделать.

Знать «как правильно» недостаточно

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

Только нихрена мне это осознание не помогает, и я продолжаю тревожиться и злиться.

То, что я знаю, как «правильно», вовсе не означает, что смогу применить это знание. Уже хорошо, что я вообще вспомнил нужные идеи и попытался ими воспользоваться. Но успех не гарантирован.

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

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

Зато даже мерзкая бессонница может дать возможность проверить идеи на практике.

А первый рабочий день в итоге прошёл отлично.

«Первые 90 дней», Майкл Уоткинс

Fri, 07 Nov 2025 00:00:00 GMT

Было бы удивительно, если бы, готовясь к выходу на новое место, я не прочитал соответствующую книгу, не так ли?

Книга «Первые 90 дней» давно лежала у меня в бэклоге, но повода взяться за неё не было. А тут она неожиданно всплыла — и я решил обогатиться чужим опытом эффективного онбординга.

О чём книга

Это руководство по успешному прохождению первых 90 дней в руководящей должности. Оно подойдёт как при выходе на новую работу, так и при переходах внутри компании.

В книге раскрываются следующие темы:

Продвижение себя на новом месте
Разработка личной программы адаптации
Рецепты получения первых побед
Составление и выравнивание плана на первые 90 дней
Эффективная работа с подчинёнными

3 идеи из книги

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

Мои впечатления

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

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

«Как управлять интеллектуалами. Я, нерды и гики», Майкл Лопп

Fri, 31 Oct 2025 00:00:00 GMT

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

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

О чём книга

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

В книге раскрываются следующие темы:

Как проводить эффективные совещания
Плюсы и минусы стратсессий
Как слушать людей и зачем реально нужны 1:1
Перевод с менеджерского на человеческий

3 идеи из книги

Руководитель, который не проводит 1:1, живёт в своём информационном пузыре и в заблуждении, что информация о состоянии дел в команде материализуется из воздуха. 1:1 нужны для того, чтобы держать руку на пульсе команды и поддерживать выбранную стратегию.
Умалчивать информацию может быть опасно, потому что «слухами земля полнится». Иногда лучше донести людям неполную информацию, чем дать им возможность самостоятельно додумывать то, что до них докатилось где-то в курилке. Я об этом феномене рассказывал в докладе на Podlodka TeamLead Crew.
Заткнись и слушай. Боже Свароже, как же некоторые менеджеры любят поговорить. Иногда возникает чувство, что человек просто упивается звуками собственного голоса. Но по-настоящему ценный навык — это слушать. А желательно ещё и слышать, что тебе на самом деле говорят. Но с открытым ртом слушать невозможно.

Мои впечатления

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

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

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

В продуктовых интервью смотри на действия

Wed, 29 Oct 2025 00:00:00 GMT

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

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

Желание ещё не является проблемой

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

Поэтому в интервью мне важнее смотреть не на красивое желание, а на прошлое поведение:

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

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

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

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

Руководитель — это состояние души

Mon, 27 Oct 2025 00:00:00 GMT

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

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

Работу тимлида не напоминает? Мне — очень:

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

Видимо, руководитель — это образ мышления, который въедается до мозга костей. Из матчей я частенько выходил с посредственным K/D, зато с 30–40 возрождениями. Мне было некогда играть на себя: я был слишком занят игрой на команду.

Впрочем, как и в работе.

«48 законов власти», Роберт Грин

Fri, 24 Oct 2025 00:00:00 GMT

Я слышала о вас столько гадостей, что сразу поняла: вы — замечательный человек!

(с) Фаина Раневская (но это не точно)

Я редко беру книги просто потому, что о них много кто говорит. Это просто не соответствует моим потребностям в самообучении. Но обзоры на «48 законов власти» я видел в разных каналах, и эти обзоры были далеко не комплиментарными. Авторы обвиняли эту книгу в цинизме, лицемерии, грязи и прочих вещах.

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

О чём книга

Автор описывает 48 «законов», которые нужны человеку, стремящемуся к власти и влиянию. Эти законы представляют собой набор моделей мышления, поведения и принятия решений в разных ситуациях. Также приводятся примеры соблюдения и несоблюдения этих законов с их последствиями.

В книге раскрываются следующие темы:

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

Три идеи из книги

Самый важный навык — это владение своими чувствами. Эмоциональные реакции на ситуацию редко приводят к положительным последствиям (зачастую всё равно наоборот). А самая разрушительная эмоция — гнев, потому что он затуманивает разум и мешает ясно видеть вещи.
При любой возможности старайтесь превратить врага в друга. Заключите с ним мир, найдите способы служить и помогать друг другу. Так можно и от неприятелей избавиться, и свою сеть контактов укрепить хорошими людьми.
Не терпи в окружении людей негативных — и в особенности вечно всем недовольных. Недовольство и негатив похожи на вирус, который быстро распространяется, заражая умы и души. Совет звучит очень цинично, пока не вспомнишь хотя бы одного типичного «нытика», который никогда не решает своих проблем.

Мои впечатления

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

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

Описанные Грином 48 законов — это инструменты, а не руководство к действию. А результаты применения любого инструмента в первую очередь зависят от того, в чьих руках он находится и какими намерениями руководствуется этот человек. Сами по себе они не хорошие и не плохие. И даже в такой циничной книге можно найти идеи, которые хороши и применимы для добрых дел.

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

Правило одной книги: короткий путь к глубинной рекомендации

Wed, 22 Oct 2025 00:00:00 GMT

Недавно я вычитал технику, которая помогает учиться у других людей. Она заключается в одном вопросе: «Если бы ты мог посоветовать мне одну-единственную книгу, то какую и почему?»

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

Объяснение «почему» показывает, какую ценность из книги вынес сам собеседник. Возможно, вы её уже читали, но не заметили того, что увидел он. Так рекомендация превращается в начало содержательного разговора.

Я опробовал вопрос на нескольких людях, и результат меня приятно удивил.

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

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

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

Модель ответственности руководителя

Mon, 20 Oct 2025 00:00:00 GMT

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

В подкасте Катя предложила следующую модель ответственности руководителя: «Я → бизнес → команда». Эта модель мне понравилась и показалась логичной, поэтому давайте разберём её подробнее.

Я

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

Любой руководитель (да и не только) всегда и везде в первую очередь несёт ответственность за самого себя. И это его главная зона ответственности, потому что в неё входит куча всего важного:

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

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

Поэтому начинать нужно с себя.

Бизнес

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

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

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

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

Команда

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

Описанная модель не линейна. Она предназначена для расстановки приоритетов. Вряд ли команда, которая регулярно продалбывает сроки, будет довольной и счастливой: ей просто не дадут работать в комфортной обстановке. А если руководитель за себя не очень-то отвечает, то последствия могут быть совсем плачевными.

Модель появилась в разговоре с ведущими подкаста «Вы хотите об этом поговорить?». Сам выпуск — «Тимлид тоже человек: о чувствах, найме и шагах назад».

Тимлид тоже человек: о чувствах, найме и шагах назад

Mon, 20 Oct 2025 00:00:00 GMT

Разговор о человеческой стороне работы тимлида: смысле работы, тревоге из-за состояния рынка, обучении взрослых и границах ответственности руководителя.

О чём разговор

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

Модель «Я → бизнес → команда», которую Катя предложила в разговоре, я отдельно разобрал в заметке «Модель ответственности руководителя».

«Deadline. Роман об управлении проектами», Том ДеМарко

Fri, 17 Oct 2025 00:00:00 GMT

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

К тому же книги про управление проектами с каждым годом опыта и каждым прожитым проектом становятся всё интереснее и интереснее (в одном из постов я рассказывал, как углубилось моё понимание «Цели» Голдратта со временем). Поэтому я люблю периодически перечитывать что-то из прошлого.

О чём книга

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

В книге раскрываются следующие темы:

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

Три идеи из книги

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

Мои впечатления

Несмотря на «художественный» стиль написания, книга ДеМарко даёт много пищи для размышлений. Каждая глава фактически посвящена одному из нюансов управления проектами и заканчивается полезными выводами, которые главный герой записывает себе в блокнотик.

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

Я рекомендую эту книгу всем руководителям, но особенно — тем, кто только встаёт на этот путь. Книга ДеМарко убережёт вас от некоторых дорогих ошибок.

Как всё успевать без стресса, дедлайнов и бессонных ночей

Wed, 15 Oct 2025 00:00:00 GMT

Когда я опубликовал свой график выступлений на конференциях, то несколько раз получил один и тот же вопрос: «Как ты это успеваешь?»

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

Чему меня реально научил университет

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

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

Проблем было две:

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

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

С текучкой я справлялся неплохо, но из графика длинных проектов заметно выбивался. Тогда я решил распределить работу на более долгий срок. Цель была простой: каждую неделю понемногу приближать завершение каждого проекта. Я перестал гнаться за объёмом в моменте и сосредоточился на том, чтобы за каждый подход делать небольшой инкремент.

Нагрузочное тестирование

Через год система прошла стресс-тест. На третьем курсе за один семестр мне нужно было сделать:

52 лабораторные работы;
4 семестровые работы;
2 курсовые работы;
2 проекта на параллельном обучении.

Бонусом шла текучка: домашние задания в университете и академии, а ещё работа, которой я оплачивал учёбу.

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

Как я применяю этот подход сейчас

Диплом магистра я защитил десять лет назад, но «размазывание работы тонким слоем» осталось одним из моих любимых способов вести большие проекты.

Например, работу над докладами я начинаю за несколько месяцев до конференции:

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

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

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

Признание не заменяет деньги, но удерживает людей

Mon, 13 Oct 2025 00:00:00 GMT

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

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

Людям важно, чтобы их работу замечали

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

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

Благодарить стоит конкретно. Не «ты молодец» вообще, а «спасибо, что заранее поднял проблему и помог нам не сорвать релиз». Тогда человек понимает, какое именно действие оказалось полезным.

Хорошее отношение влияет на решение остаться

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

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

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

Где заканчивается доброта

Хорошее отношение не компенсирует низкую зарплату, отсутствие роста, перегрузку или плохие решения руководителя. Если человеку говорят «ты молодец», но годами игнорируют его условия работы, благодарность превращается в издёвку.

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

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

«Грокаем безопасность веб-приложений», Малкольм Макдональд

Fri, 10 Oct 2025 00:00:00 GMT

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

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

О чём книга

Книга посвящена различным уязвимостям веб-приложений и способам защиты от них. Также в ней описаны принципы и подходы к проектированию безопасных веб-приложений, множество best practices и советы по повышению безопасности.

В книге раскрываются следующие темы:

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

Три идеи из книги

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

Мои впечатления

Книга достаточно приятная и интересная, но очень базовая. По уровню она напоминает мне скорее серию Head First от O’Reilly: подходит для первого знакомства с темой, но недостаточна для глубокого понимания. Например, раздел про шифрование, на мой вкус, написан слишком поверхностно и требует дополнительного изучения.

Опытный инженер вряд ли найдёт здесь много нового (хотя лично я узнал о паре довольно экзотических атак). Но для специалистов уровня junior/middle книга может быть полезной: она в простой форме доносит основы безопасности веб-приложений.

Рекомендую к прочтению, но с оговорками. А если знаете хорошие книги по инфобезу — пишите в комментариях, хочу продолжить копать тему.

Переговоры любят подготовку

Wed, 08 Oct 2025 00:00:00 GMT

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

Почему нужно готовиться даже к «простым» разговорам

Но бывают ли вообще в природе простые разговоры? Мне кажется, что нет. У информации в процессе разговора есть много способов исказиться: Я мог подумать одно, а сказать другое. Собеседник мог услышать вообще третье, а интерпретировать как четвёртое.

Помните детскую игру «испорченный телефон»? Даже при двух собеседниках есть несколько точек искажения. Что уж говорить о передаче информации между несколькими людьми? Каковы шансы сохранить её в первозданном виде? Мне кажется — нулевые.

Как готовиться

В докладе я предлагаю следующий фреймворк:

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

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

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

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

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

Устойчивая коммуникация: как быть понятым сверху и снизу

Wed, 08 Oct 2025 00:00:00 GMT

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

О чём выступление

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

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

Неидеальное решение конфликта

Mon, 06 Oct 2025 00:00:00 GMT

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

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

Я пробовал всё, что знал:

разговаривал с ними один на один;
давал конструктивную обратную связь по BOFF;
предлагал другие способы общения;
сажал за стол переговоров и предлагал договориться.

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

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

Ротация была не наказанием

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

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

После ротации конфликты прекратились, и команда снова стала стабильно работать.

Мирить всех не было моей обязанностью

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

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

«Критическое мышление», Том Чатфилд

Fri, 03 Oct 2025 00:00:00 GMT

Критическое мышление (которое точнее было бы назвать навыком критического анализа) — важная часть как моей работы, так и повседневной жизни. Оно пригождается мне и при принятии рабочих решений, и при чтении всякого-разного в Telegram на отдыхе.

Я искренне считаю критическое мышление одним из важнейших метанавыков и стараюсь всячески его развивать, потому что каждая новая техника сразу же находит применение. Именно поэтому я и взялся за книгу Тома Чатфилда «Критическое мышление» — хотел обогатить свой арсенал мыслительных инструментов.

О чём книга

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

В книге раскрываются следующие темы:

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

3 идеи из книги

Критическое мышление — это не только умение докопаться до сути или найти слабости в чужой аргументации, но и способность признать свою неправоту и пересмотреть взгляды. Оно работает в обе стороны.
Главный враг критического мышления — спешка. Для полноценного анализа нужны время, внимание и спокойствие (чего нас часто стараются лишить различные манипуляторы). Быстрые решения часто оказываются ошибочными.
Мы склонны считать мир более упорядоченным и закономерным, чем он есть на самом деле. Не в каждом событии, мнении или даже аргументе обязательно есть логика. Люди в целом поступают эмоционально и нередко крайне нелогично.

Мои впечатления

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

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

Конечно, «Критическое мышление» не содержит абсолютно всего, что нужно для успешного анализа. Как минимум, стоит почитать ещё труды по логике и, например, того же Канемана. Но я очень рекомендую эту книгу всем — особенно в наш век информационного шума, когда умение фильтровать информацию становится незаменимым.

Почему полезные привычки умирают и как их спасти

Wed, 01 Oct 2025 00:00:00 GMT

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

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

Хуже всего в этот момент начать пилить себя за лень.

Три вопроса перед стартом

Теперь перед новой практикой я отвечаю себе на три вопроса:

Зачем она мне и какого результата я хочу?
Подходит ли мне именно этот инструмент?
Какого объёма достаточно, чтобы получить пользу и не перегрузиться?

Цель помогает понять, нужна ли практика вообще. Второй вопрос оставляет место для альтернатив: тот же бег можно заменить, если вы, как и я, не любите бегать. Третий задаёт уровень «достаточно».

Minimum Viable Practice

Я называю этот подход Minimum Viable Practice - минимально рабочей практикой.

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

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

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

Похожую логику маленьких устойчивых изменений я разбирал в обзоре книги «Атомные привычки».

«Тирания показателей», Джерри Мюллер

Fri, 26 Sep 2025 00:00:00 GMT

Метрики — это очень интересная вещь. С одной стороны, количественные показатели могут приносить огромную пользу, указывая на проблемы. С другой — возведение метрик в абсолют приводит к неожиданным (и чаще всего негативным) последствиям.

А некоторые вещи вообще нельзя измерить. Как измерить мотивацию? Проактивность? Увлечённость своим делом? И разве невозможность измерения делает их неважными? Конечно же, нет.

Книгу Джерри Мюллера я хотел прочитать уже давно. Я на своей шкуре несколько раз ощутил, как одержимость метриками, цифрами и прочими KPI может превращать крутые вещи в тихий ужас. Тем интереснее было изучить этот вопрос.

О чём книга

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

В книге раскрываются следующие темы:

Последствия чрезмерного увлечения метриками
Типичные ошибки при работе с метриками
Когда метрики действительно полезны
Как создавать полезные метрики

3 идеи из книги

Оценка результатов на основе показателей приводит к игнорированию всех прочих частей работы.
Все знают мем про индусский код, но почему-то упорно забывают про тот же эффект при составлении собственных показателей эффективности.
Закон Гудхарта: любой количественный показатель ненадёжен.
Если на основании метрики мы начинаем, например, вознаграждать или наказывать людей, то метрика гарантированно станет объектом махинаций и манипуляций — даже в ущерб всему остальному.
Не всё важное можно измерить, не всё измеримое важно.
Вклад многих работников в деятельность организации состоит, в том числе, из вещей неизмеримых: творческих идей, поддержки коллег, обучения и многого другого. Нет ничего плохого в измерении продуктивности. Проблемы начинаются тогда, когда шкала становится слишком однобокой и не учитывает всё остальное.

Мои впечатления

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

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

В жизни каждого из нас так или иначе есть метрики. Рекомендую почитать эту книгу на досуге — вы посмотрите на них совсем другими глазами.

«Фундаментальный подход к программной архитектуре», Марк Ричардс, Нил Форд

Fri, 19 Sep 2025 00:00:00 GMT

Эту книгу я хотел прочитать довольно давно. Как-то так сложилось, что с творчеством Ричардса и Форда я начал знакомство с книги Software Architecture: The Hard Parts — книга хорошая.

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

О чём книга

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

В книге раскрываются следующие темы:

Что такое архитектурное мышление и в чём его отличия?
Какие существуют архитектурные свойства и как их применять?
Основные архитектурные стили, их преимущества и недостатки
Soft skills архитектора ПО

3 идеи из книги

Один из главных врагов программных систем — неизвестные неизвестности. Это та информация, которую мы не знаем и одновременно не знаем, что нам это неизвестно. Поэтому Big Design Up Front может не работать: любая неизвестная неизвестность может всё сломать.
Архитектор должен уметь переводить свои слова с технического на бизнес-язык. Заказчики редко думают в терминах надёжности, масштабируемости или доступности — им гораздо ближе термины «конкурентное преимущество», «запросы клиентов» и «сроки поставки».
Архитектор не должен застревать в излишней перестраховке. Нужно стремиться к балансу между качеством принятого решения и его скоростью. «Вылизывание» решения до идеала может стоить очень дорого.

Мои впечатления

Книга не совсем базовая (для этого они отдельно написали Head First Software Architecture, пока не читал), но для опытного инженера она довольно понятна. При этом книга покрывает как базовые архитектурные штуки типа стилей или свойств, так и различные техники взаимодействия, ведения переговоров и т. д. (например, мне понравился раздел по риск-менеджменту для архитекторов).

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

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

Сушим работу: как разработка может перестать быть исполнителем

Wed, 17 Sep 2025 00:00:00 GMT

В моём докладе про управление в кризис много эмоций вызвала тема «сушки» работы. Разработке эта парадигма непривычна: стандартный процесс выглядит как «нате требования — пилите, Шура».

«Сушка» подразумевает, что требования можно обсуждать и менять. То, что принёс бизнес-заказчик, — не истина в последней инстанции, а исходная версия решения.

Сначала понять потребность

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

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

Ответы показывают, что нужно реализовать полностью, а что можно упростить или отложить.

Это совместная работа с продуктом

Этому подходу я научился, запуская собственные стартапы. Они не взлетели, зато привычка экономно обращаться с объёмом работы осталась.

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

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

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

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

«Распределённые системы», Брендан Бёрнс

Fri, 12 Sep 2025 00:00:00 GMT

Тяжесть — это хорошо. Тяжесть — это надёжно. (с) Борис Бритва

В последнее время меня увлекают книги по надёжности систем. Эта тема очень обширная, и её интересно изучать, потому что знания по надёжности постоянно пригождаются в работе. Поэтому я с большим удовольствием прочитал новую, недавно вышедшую книгу Брендана Бёрнса — «Распределённые системы». Мне было интересно узнать, какие такие паттерны распределённых систем на базе Kubernetes автор предлагает использовать.

О чём книга

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

В книге раскрываются следующие темы:

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

3 идеи из книги

Один из самых простых и полезных паттернов — Sidecar. Суть его в том, что мы можем «подцепить» к поду ещё один контейнер, содержащий любую нужную нам функциональность. Например, этот контейнер может парсить логи другого контейнера и отправлять их в систему логирования. Некоторые другие паттерны в книге основаны на Sidecar.
При проектировании контейнеров важно понимать, возможна ли ситуация множественной обработки. В частности, в системах пакетной обработки может возникнуть ситуация, когда один и тот же чанк данных возьмут в обработку несколько рабочих машин. Это нужно учитывать при проектировании системы.
Добавление кэша в систему часто приводит к тому, что система оказывается намертво зависима от него. Часто это выглядит так: добавили кэш для ускорения, постепенно нагрузка растёт — и в какой-то момент система просто ляжет в случае отказа кэша. Я как-то в работе «развязывал» такой узелок и могу сказать, что это крайне нетривиальная задача.

Мои впечатления

Книга оказалась достаточно интересной. Местами я ехидно хихикал с того, как автор переизобретает названия паттернов банды четырёх и некоторые другие термины (например, retry storm он окрестил «грохочущим стадом»). Тем не менее, изложенные в книге паттерны и способы их применения полезны и применимы на практике. Отдельный плюс — спеки, которые можно скопировать себе и поиграться при желании.

В книге есть и некоторые спорные моменты. Например, автор в одной главе рассказывает, как дорого стоят FaaS-вычисления при частом вызове, а в другой предлагает использовать их для сервиса аутентификации с немаленькой такой нагрузкой.

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

«Новые принципы делового общения», Кэл Ньюпорт

Fri, 05 Sep 2025 00:00:00 GMT

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

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

О чём книга

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

В книге раскрываются следующие темы:

Какой вред нам нанесло повсеместное распространение электронной почты.
Почему общение по почте и в мессенджерах — это не работа.
Как защитить своё внимание в мире постоянной болтовни.

3 идеи из книги

Обсуждать рабочие вопросы и решать их — это разные вещи, зачастую конфликтующие. Сколько я видел болтологий вокруг дел, которые просто нужно взять и сделать — не счесть. Конечно, иногда без обсуждения не обойтись, но всему нужно знать меру.
Компании увязают в «более эффективных коммуникациях», хотя на самом деле самая эффективная коммуникация — та, которой не было. Есть куча продуктов для упрощения поиска в почте и мессенджерах, для написания саммари, ещё для бог весть чего. Но они, по сути, исправляют последствия информационного шума, а не работают с его источником.
Когда вы действительно работаете, а не дёргаетесь по каждому сигналу мессенджера, продуктивность труда значительно увеличивается. А восемь часов работы становятся довольно трудной задачей. Но такой подход позволяет производить намного более качественный продукт.

Мои впечатления

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

Вместе с тем книга очень водянистая. Идей немного, зато всякие истории и исследования занимают огромный объём. Если убрать всю воду, то, по моим ощущениям, книжку можно уместить в пару ТГ-постов. Это не значит, что читать её не стоит — очень даже наоборот. Просто рекомендую пропускать «водичку», которую автор местами переливает по кругу.

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

«System Design. Подготовка к сложному интервью», Алекс Сюй

Fri, 29 Aug 2025 00:00:00 GMT

В продолжение темы книг по system design я решил сделать обзор на уже прочитанную (и недавно перечитанную) книгу Алекса Сюя «System Design. Подготовка к сложному интервью».

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

О чём книга

Книга содержит алгоритм прохождения собеседования по архитектуре и примеры подобных собеседований. Также Сюй верхнеуровнево касается тем масштабирования систем для работы под высокой нагрузкой.

В книге раскрываются следующие темы:

Сценарий прохождения собеседования по дизайну.
Какие вопросы нужно обязательно задать интервьюеру.
Примеры проектирования систем «как бы на собеседовании».

Три идеи из книги

Разберитесь в задаче до начала проектирования. Эту ошибку я много раз видел на опыте: кандидат бросается проектировать систему, толком не разобравшись даже с функциональными требованиями. Чаще всего такой подход приводит к тому, что систему приходится переделывать.
Нет правильных или неправильных ответов. Конечно, у интервьюера в голове есть некоторое «эталонное решение», но оно не является единственно правильным. Важно не просто предложить какое-то решение, а ещё и обосновать его.
Проектируйте от общего к частному. Иногда кандидаты закапываются в какие-то малозначимые детали и в итоге не завершают проектирование системы в целом. Сначала предложите верхнеуровневую архитектуру, а потом уже занимайтесь детализацией.

Мои впечатления

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

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

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

Предохранители от выгорания

Wed, 27 Aug 2025 00:00:00 GMT

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

Это не медицинские рекомендации. Если состояние пугает или долго не меняется, лучше обратиться к специалисту.

О чём выступление

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

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

О доверии к взгляду со стороны

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

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

О помощи другому человеку

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

Похожий принцип работает в семье: начать с наблюдения и вопроса «Как я могу тебя поддержать?» Дальше решает сам человек.

О дневнике

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

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

Подробнее эволюцию своего дневника я описал в отдельной заметке.

О границе между работой и отдыхом

Чтобы не следить за чатами в отпуске, я разбирался, чего именно боюсь. Одним из страхов было пропустить что-то по-настоящему важное. Я договорился с сотрудниками, что в крайнем случае они мне позвонят. Этого оказалось достаточно, чтобы перестать читать всё подряд.

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

Задачи напрямую от клиента: где начинается хаос

Mon, 25 Aug 2025 00:00:00 GMT

Недавно в комментариях прилетел вопрос:

А если постановки задач нет вообще, на проекте около 20 человек — это может работать или это заранее плохой процесс? В моём случае задачи шли напрямую от клиента к разработчикам, а менеджер только определял, что брать в работу и кому отдать.

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

Прямой контакт не равен хаосу

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

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

нет общего контекста, и каждый член команды предоставлен сам себе;
нет общей приоритизации, поэтому все задачи нужны «вчера»;
размыта ответственность за то, что именно команда обещала сделать.

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

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

Когда лёгкий процесс достаточен

В маленьком стартапе или личном проекте можно обойтись без тяжёлой бюрократии. Но вопросы всё равно остаются теми же: кто определяет приоритет, где зафиксировано ожидаемое поведение и кто отвечает за итоговое обещание клиенту.

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

Что делать разработчику внутри такого процесса

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

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

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

«Критическая цепь», Элияху Голдратт

Fri, 22 Aug 2025 00:00:00 GMT

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

Я считаю эту оценку не вполне справедливой (хотя доля правды в ней есть). Управление проектами — это сложное искусство, которое включает в себя много всего (поэтому PMBoK такой толстенный). Ну а методики управления проектами — отдельная большая тема.

Мне как руководителю тема управления проектами особенно интересна. А ещё мне интересен Голдратт. И на пересечении этих двух интересов оказалась следующая его книга — «Критическая цепь».

О чём книга

Как и все предыдущие книги, «Критическая цепь» — это бизнес-роман о технике управления проектами по методу критической цепи. В этот раз главный герой преподаёт на курсе в программе MBA. Его студенты борются с проблемами завершения проектов на работе, а его работодатель борется с бесполезностью программы MBA (ха-ха).

В книге раскрываются следующие темы:

Почему подстраховка по времени не спасает проекты от провала;
Почему внешне успевающие проекты могут «продолбать» дедлайн в самом конце;
Как применять теорию ограничений для управления проектами.

3 идеи из книги

Большую часть времени любого проекта занимает простаивание. Люди, наученные горьким опытом, закладывают в проект много подстраховки, и в итоге какие-то части проекта зачастую просто ждут, пока выполнятся другие части.
Опоздание одного элемента цепи передаётся следующему элементу. Отчасти поэтому в проектах так много подстраховки: руководители закладывают вероятность того, что нужные результаты им поставят с опозданием. Одно незначительное отклонение — и мы получаем эффект домино по всему проекту.
Стремление к локальной оптимизации вредит проекту, потому что завершение отдельных заданий само по себе не имеет ценности. Ценность имеет только полностью завершённый проект.

Мои впечатления

Скажу честно — книга мне понравилась, но вызвала много вопросов. Мне не хватило примеров, приведённых Голдраттом, и захотелось посмотреть на применение этого метода в реальной жизни.

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

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

Как остановить бессмысленные задачи

Wed, 20 Aug 2025 00:00:00 GMT

Бесполезная работа есть у всех. Часто её больше, чем хотелось бы.

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

Muda muda muda muda muda

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

Я определяю бесполезную работу как то, что не нужно делать сейчас или вообще. Проверяю простым вопросом: «Нахрена мне это делать?» Если внятного ответа нет, останавливаюсь и думаю дальше.

А работать-то когда?

Любую задачу можно поставить под сомнение, причём надолго. Цель вопроса не в том, чтобы улететь в философские дали, а в короткой паузе перед действием.

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

А если соскочить нельзя?

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

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

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

В крайнем случае смысл можно сместить с самого отчёта на договорённость: «Я делаю это, потому что руководителю нужен результат». Но сначала всё же полезно остановиться и спросить «нахрена?» — возможно, задача исчезнет или станет сильно меньше.

«System Design. Пережить интервью», Чжиюн Тань

Fri, 15 Aug 2025 00:00:00 GMT

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

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

О чём книга

Книга разделена на две части. Примерно треть посвящена ходу собеседования и базовым техникам проектирования: сбору требований, анализу подводных камней, масштабированию и другим основам. Остальные две трети занимают разборы Flickr, CDN, Airbnb и других систем.

Из книги можно узнать:

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

Три идеи из книги

Продумайте и обсудите снижение функциональности системы при сбоях. На интервью обычно проектируется высоконагруженная система, поэтому нужно учитывать ошибки и отказы её компонентов.
Не забудьте про логирование, мониторинг и алертинг. Делать сложную архитектуру без наблюдаемости — медленное самоубийство. Необязательно проектировать каждую деталь: достаточно обозначить решение и углубиться, если интервьюер попросит.
Не стесняйтесь спрашивать: «Есть ли другие пользовательские требования?» Интервьюер выступает в роли заказчика и помогает собрать требования. Из-за нервов легко упустить небольшое, но значимое ограничение.

Что мне не понравилось

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

Разборы систем понравились ещё меньше. Эта часть показалась мне перегруженной ненужными деталями, а некоторые решения вызвали вопросы. Большинство кейсов не привносят ничего нового: мессенджер и ленту Twitter уже только ленивый не проектировал.

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

Стоит ли читать

Если вы ещё ничего не читали по системному дизайну, лучше начать с книги Алекса Сюя: она понятнее и лучше структурирована. «Пережить интервью» стоит использовать как дополнение и выбирать только те главы, которые закрывают конкретный пробел в подготовке.

Почему хорошие идеи встречают сопротивление

Wed, 13 Aug 2025 00:00:00 GMT

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

Мы обсуждали этот вопрос полчаса и пришли к неприятному выводу: качества самой идеи недостаточно.

Идея может прийти не вовремя

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

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

Вы можете решать не ту проблему

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

Поэтому перед презентацией решения полезно проверить:

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

Подробнее эту проверку я разбираю в материале «Как расти через рабочие проблемы».

Критика показывает чужие ограничения

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

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

Это не делает любую критику правильной. Но превращает её из порции хейта в данные для следующей версии решения.

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

«Идеальный питч», Орен Клафф

Fri, 08 Aug 2025 00:00:00 GMT

Питчить что-то мне приходится регулярно. Это может быть идея продукта, которую нужно донести до руководства, заявка на доклад, которую нужно объяснить программному комитету, или фильм на воскресный вечер, который нужно «продать» жене (последнее — сложнее всего).

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

О чём книга

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

В книге раскрываются следующие темы:

фрейм-контроль и его роль в презентации идей;
статус и как его использовать для питча;
пошаговый алгоритм презентации своей идеи.

Три идеи из книги

Питч должен быть простым, понятным и наглядным. Собеседник пропустит мимо ушей 90% информации, поэтому нужно помочь ему понять вашу идею. Для этого стоит упрощать подачу и убирать лишнее. Если человек заскучает, то с высокой долей вероятности питч провалится.
Победа любит подготовку. 90% трудностей при питче можно предусмотреть заранее: кто будет слушать, как слушатели относятся к теме, каков характер аудитории, какие вопросы могут задать и так далее.
В питче должна быть ровно одна идея, которая останется в голове собеседника. Питч — это тоже публичное выступление, пусть и небольшое. Много вложить в него не получится — собеседник всё равно забудет бо́льшую часть рассказа через пару часов. Нужна одна ёмкая, цепкая идея.

Мои впечатления

Книга довольно интересная. С одной стороны, Клафф предлагает отличные практики: про тот же фрейминг было полезно почитать, особенно с воспоминаниями из собственного опыта. Также он предлагает понятные и рабочие методики. Не знаю, работают ли они на миллионных сделках, но в моих задачах точно пригодились (тот же фрейм власти я пару раз крайне успешно «сбивал» с людей).

Больше всего меня смутило обоснование подхода теорией триединого мозга (которая про рептильный мозг и вот это всё). Теория давно и успешно опровергнута, но при этом слишком удобна для объяснения некоторых вещей неискушённому читателю. Впрочем, на идеи автора это никак не влияет. Мне кажется, что можно было объяснить проще, но тогда нельзя было бы «питчить» книгу через «научные методы», не так ли?

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

Как развивать сотрудников через неопределённость и не быть тираном

Wed, 06 Aug 2025 00:00:00 GMT

После одного выступления меня спросили: «Как подталкивать сотрудников к развитию, если они этого не хотят?» В вопросе зашит парадокс: развивать людей надо, а они не хотят.

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

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

Уровень неопределённости зависит от опыта

Не всем членам команды нужен одинаково детальный Definition of Done.

Стажёры требуют максимально разжёванного результата и подсказок.
Джуны уже лучше понимают проект, но всё ещё нуждаются в наставничестве.
Мидлы способны работать с умеренной неопределённостью и замечать «белые пятна».
Сеньоры справляются с задачами высокого уровня неопределённости и могут сами сформулировать DoD.

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

Договаривайтесь открыто

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

Перед такой задачей лучше обсудить:

Хочет ли человек развиваться в этом направлении?
Какая цель у этого эксперимента?
Что он уже умеет и где может потребоваться помощь?
Какая поддержка будет доступна?
Как и когда мы подведём итоги?

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

Не бросайте людей в воду

Неопределённость — нагрузка. Если давать её постоянно, можно получить выгорание и потерю доверия вместо роста. Сотрудник должен знать, что в любой момент может обратиться за помощью, получить разъяснение или пересобрать договорённость.

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

Continuous API Management by Mehdi Medjaoui et al.

Fri, 01 Aug 2025 00:00:00 GMT

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

Примером ответа на этот вопрос может служить Amazon, который постулирует: «делать все API так, будто они публичные». Проблема в том, что это очень дорого. И я решил разобраться в вопросе более детально.

О чём книга

Книга посвящена управлению (руководству) разработкой API. Под API авторы подразумевают не интерфейс взаимодействия, а сервисы, выполняющие полезные для клиентов функции. Основу книги составляют пять элементов управления: продуктовая перспектива, правильные команды, руководство, зрелость продукта и проектирование ландшафта.

В книге раскрываются следующие темы:

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

Три идеи из книги

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

Мои впечатления

Книга оказалась довольно интересной. Авторы топят за продуктовый подход в создании сервисов, что является здравой идеей – я видел слишком много «сервисов ради сервисов».

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

Ещё мне зашёл фокус на удобстве API. Этим разработчики заморачиваются довольно редко, а зря. Авторы утверждают, что удобные API гораздо чаще становятся популярными. Тезис спорный – вряд ли кто-то будет пользоваться удобными и хорошо описанными, но бесполезными API. Но посыл про хороший DX я считаю очень важным, потому что средняя документация вызывает у меня страдания.

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

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

«Эссенциализм», Грег МакКеон

Fri, 25 Jul 2025 00:00:00 GMT

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

Я поставил перед собой задачу: делать меньше, не теряя в качестве и результатах. И эта задача оказалась на порядок сложнее, чем «собрать тудушник и календарик».

Занявшись этой задачей, я вспомнил про отличную книгу — «Эссенциализм». Я уже читал её несколько лет назад, и тогда она дала мне в руки волшебный вопрос: «Зачем?». Столкнувшись с той же задачей, я решил перечитать её с новым пониманием и опытом.

О чём книга

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

В книге раскрываются следующие темы:

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

Три идеи из книги

Научитесь расставлять акценты в своей жизни. Или за вас это сделает кто-то другой. Если мы сами не управляем своим временем, вниманием, направлением деятельности и смыслами, то кто-то обязательно займёт это вакантное место. Если мы не можем выбрать, на что направить своё время и энергию, за нас это сделают другие: начальство, коллеги, клиенты или даже члены семьи.
Эссенциалист рассматривает больше вариантов выбора, потому что выбирает более тщательно. Он хочет вложить свои силы и время в 1–2 проекта, поэтому тратит больше ресурсов на анализ и выбор, чем обычный человек.
Главный актив, который нам доступен, — это мы сами. Мы должны достаточно вкладывать в себя: здоровье, физическое и моральное состояние, обучение. Тело и дух должны быть в порядке, иначе мы не сможем ни адекватно работать, ни двигаться к своим целям.

Мои впечатления

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

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

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

3 вида задач, которые воруют твои силы и время

Wed, 23 Jul 2025 00:00:00 GMT

В субботу в рамках круглого стола на Dream Teamlead нам задали прекрасный вопрос: «Какой совет вы бы дали себе в начале карьеры руководителя?»

Мой ответ звучал так: «Половина работы, которая кажется тебе важной, на самом деле — бесполезная хрень». А мои коллеги мудро добавили: «Осталось понять, какая именно половина».

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

Что такое бесполезная работа

Под бесполезной работой я подразумеваю следующие вещи:

Задачи, которые можно было вообще не делать.
Задачи, которые можно было сделать в меньшем объёме.
Задачи, которые можно было сделать проще.

Во всех трёх случаях ресурсы тратятся нерационально. В первом случае всё очевидно: если задача не несёт ценности, то время и силы на неё тратятся зря. Отсекать такие задачи помогает, к примеру, техника «5 нахрена».

А вот с меньшим объёмом и упрощением всё интереснее.

Достаточно хорошо

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

Особенно остро эта проблема ощущается в задачах, результат которых чётко не определён. Например, на этом «горят» многие начинающие авторы каналов: нет критериев хорошего поста, поэтому они продолжают дорабатывать материал до мифического идеала. Другой классический пример — рефакторинг уже работающей задачи на пару дополнительных дней.

Для каждой задачи нужно определить целевой результат (да, тот самый definition of done). Как только он достигнут — задачу можно спокойно закрывать и двигаться к следующей.

Упрощай

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

Мы часто делаем какие-то вещи по привычке, не задумываясь о том, что это можно было бы сделать с меньшими затратами сил и/или времени. Эта проблема особенно актуальна для тех из нас, кто перегружен задачами — нам просто не хватает внимания, чтобы остановиться и подумать о своей работе.

Для того чтобы упростить задачу, нужно заметить возможность упрощения. Иногда это происходит как озарение в процессе работы: делая задачу, я внезапно понимаю, что её можно упростить или автоматизировать. Но гораздо эффективнее замечать потенциал для упрощения ретроспективно, анализируя проделанную работу.

Важно не просто делать меньше. Важно перестать делать то, что не нужно.

От хаоса в голове к системе анализа своего дня

Mon, 21 Jul 2025 00:00:00 GMT

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

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

v1: просто выгрузка

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

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

Это состояние мне настолько понравилось, что я повторил написание дневника на следующий вечер. И ещё раз. И ещё.

v2: короткая рефлексия

Спустя пару месяцев постоянных записей я понял: дневник прижился. Но текущий метод перестал меня устраивать. Он занимал довольно много времени (писать каждый день по полчаса перед сном утомляло), при этом не всегда давал желаемый выхлоп.

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

Что я сегодня делал? Почему это важно?
Что я сегодня понял и осознал о себе и мире?
Что в будущем буду делать по-другому?

Я старался отвечать на эти вопросы коротко и по существу, не вдаваясь в художественные детали (всё-таки не мемуары пишу). Ответы на них сократили время написания дневника примерно наполовину, а ощущения стали приятнее – важные события дня теперь были как на ладони.

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

v3: заметки в течение дня

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

В этот блок я просто записывал все мысли, идеи и штуки «на подумать», которые происходили в течение дня. У меня периодически происходят ситуации, которые неплохо бы отрефлексировать в спокойной обстановке – для этого и был предназначен этот блок.

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

v4: утренние вопросы

Следующая трансформация дневника у меня произошла, когда я стал увлекаться философией стоиков. Одной из ежедневных практик Марка Аврелия были утренние страницы, в которых он настраивал себя на предстоящий день. Я взял эту практику себе на вооружение и добавил следующие вопросы:

Как я себя чувствую? Какое у меня состояние и настроение?
Какие три главных дела я должен сделать сегодня?
Какие трудности меня поджидают и как мне подготовиться к ним?

Эта практика уже имела очень интересное влияние на меня. Первый вопрос помогал мне осознать своё состояние и планировать из него (а то раньше я грешил тем, что нагружал себя работой, будучи заболевшим или невыспавшимся). Второй вопрос помогал настроить фокус на день. Третий вопрос помогал «подстелить соломку» на трудности предстоящего дня.

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

v5: замечать хорошее

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

v42: гибкая система

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

«Проект „Феникс“. Роман о том, как DevOps меняет бизнес к лучшему», Кевин Бер и др.

Fri, 18 Jul 2025 00:00:00 GMT

«Я не понимаю, почему на неё все дрочат, честно говоря» (с) Андрей Синицын

Про эту книгу я слышал уже много раз, причём она постоянно мелькает в подборках книг для тимлидов. Я поддался любопытству и решил прочитать её, чтобы разобраться, откуда столько восторженных отзывов. Тем более что недавно я прочитал «Site Reliability Engineering. Надёжность и безотказность как в Google», и мне хотелось расширить своё восприятие роли DevOps в бизнесе.

О чём книга

Книга — это бизнес-роман о том, как страдающая компания по производству и продаже автомобильных запчастей выбирается из глубокого кризиса. По формату очень напоминает «Цель» (к которой есть несколько отсылок). Главный герой внезапно становится руководителем, чья задача — сделать так, чтобы технологическое состояние компании позволило ей успешно конкурировать на рынке.

В книге раскрываются следующие темы:

Как можно применить теорию ограничений к работе IT-отдела
Как выстраивать надёжность с помощью стандартизации процессов
Почему так важно постоянное совершенствование процессов
Что вообще такое «работа» и какая конкретно работа важна

3 идеи из книги

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

Мои впечатления

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

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

В целом книга не является «открывающей глаза» или «полной озарений», а в некоторых аспектах ещё и морально устарела (они там с bare metal на виртуалки пытаются переехать). Но читается она интересно, довольно легко (несмотря на корявый перевод) и содержит довольно много полезных идей.

Хорошая книга для отдыха от серьёзной литературы с пользой. Если хочется погрузиться в DevOps как управленческую практику — это хорошее и ненапряжное начало.

«Site Reliability Engineering. Надёжность и безотказность как в Google», Б. Бейер и др.

Fri, 11 Jul 2025 00:00:00 GMT

Одна из важнейших зон ответственности технического руководителя — обеспечение надёжности. Если вы сделали прекрасный, полезный для людей продукт, но ваши серверы лежат — считайте, что продукта нет.

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

О чём книга

Книга представляет собой сборник статей и транскрипций выступлений на тему надёжности от инженеров из Google. Для удобства читателя они разбиты на четыре раздела: введение в SRE, принципы, практики и управление.

В книге раскрываются следующие темы:

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

3 идеи из книги

“Скучность” ПО является его достоинством. Вряд ли кто-то захочет работать в среде, где программа может вести себя как попало. Чем более предсказуемы наши системы — тем лучше всем вокруг.
Упреждающий подход к авариям: SRE-инженеры в Google часто устраивают учебные сбои и ломают собственные системы, чтобы найти несовершенства в процессах мониторинга, алёртинга и устранения сбоев.
RPS — плохая метрика. Разные запросы имеют разные потребности в вычислительных ресурсах. Стоимость запроса может изменяться от целого ряда факторов. RPS однозначно стоит использовать для мониторинга нагрузки, но этот показатель не должен быть единственным.

Мои впечатления

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

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

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

В целом, книга достаточно хороша, чтобы погрузиться в проблему построения надёжных, отказоустойчивых систем и организовать базовую работу команды SRE. Это скорее инженерная философия Google, чем учебник. Рекомендую читать главы выборочно — всё подряд читать не стоит.

Как расти через рабочие проблемы

Mon, 07 Jul 2025 00:00:00 GMT

Ко мне периодически приходят инженеры с одним и тем же запросом: «Я хочу расти. Что для этого почитать, посмотреть или поделать?»

Мой короткий ответ: в первую очередь стоит искать задачи на вырост в текущей работе.

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

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

Искать проблему, а не ждать задачу

Когда сложные задачи приносят на блюдечке, расти легко. Но рассчитывать на это как на стратегию наивно. В какой-то момент любая работа становится привычной, а готовые вызовы заканчиваются.

Здесь проходит одна из границ между миддлом и сеньором. Миддл учится хорошо решать поставленные задачи. Сеньор умеет сам находить проблемы и предлагать решения.

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

Журнал проблем

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

Еженедельная рефлексия

Раз в неделю я просматриваю журнал и отвечаю себе на несколько вопросов:

Что тормозит или бесит меня в работе?
Что регулярно расстраивает команду?
Куда уходит много времени при скромном результате?
Что мешает нам работать заметно быстрее?
Как убрать это препятствие надолго?

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

Проверить, что проблема стоит решения

Не всё, что раздражает, действительно важно. Если чинить всё подряд, получится бодрая деятельность без заметного результата.

Перед тем как предлагать изменения, я проверяю три вещи:

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

После этого нужно проработать решение:

сколько оно стоит;
есть ли более дешёвые альтернативы;
какие новые риски и трудности оно создаст;
соответствует ли цена решения масштабу проблемы.

Идею полезно приносить тому, кто распределяет ресурсы, уже вместе с этим анализом. Большинство предложений всё равно отклонят. Тогда важно собрать обратную связь: чего не хватило, какие риски оказались неприемлемыми и что стоило доказать лучше.

Упражнение для первой инициативы

Однажды ко мне на менторинг пришёл коллега с запросом на развитие в сторону техлида или архитектора. Мы договорились не искать ещё один список книг, а пройти весь процесс на реальной проблеме:

Составить список того, что можно улучшить в команде.
Для каждой проблемы описать ущерб.
Предложить несколько решений.
Оценить пользу, стоимость и способ внедрения каждого варианта.
Принести разбор на ревью и доработать его.
Показать предложение тимлиду, собрать обратную связь и реализовать выбранное улучшение.

Сам я возвращаюсь к похожему упражнению раз в неделю или две. Регулярность здесь важнее размера первой инициативы: маленькое законченное улучшение быстрее учит замечать проблемы, договариваться и доводить решение до результата.

Три проблемы разного масштаба

Десять минут на релизную документацию

Во время релиза ответственному нужно было смотреть метрики и логи, проверять состояние подов в Kubernetes и вспоминать команды kubectl. Каждый раз ссылки и команды приходилось искать заново.

Я добавил в документ процесса релиза нужные ссылки, команды и короткую инструкцию. Это заняло около десяти минут, зато упростило релизы и онбординг всех, кто подключался к процессу.

До двадцати процентов эпика на переделки

В одной команде регулярно возникали сложности при интеграции фронтенда и бэкенда. Не хватало полей, появлялись новые требования, а иногда требовались заметные переделки.

Я посмотрел несколько последних эпиков и оценил задачи, которые заводились уже после начала разработки. Доработки могли занимать до двадцати процентов эпика.

В качестве решения я предложил API-first: спецификацию API стали проектировать после дизайна, но до разработки, и согласовывать обеими сторонами. Фронтенд и бэкенд смогли работать независимее, а число переделок заметно сократилось.

Больше полугода на изменение процесса

Самой крупной инициативой стал переход нескольких команд на trunk-based development. Бизнес был недоволен скоростью поставки, а интеграция изменений в большом монолите регулярно приносила баги.

Я изучил последние релизы: сколько времени занимала поставка и сколько дефектов появлялось в зависимости от её объёма. Простых решений не нашлось, потому что требовалась серьёзная переработка CI/CD.

Главным аргументом стала невозможность масштабирования. Подключение ещё одной команды при старом процессе окончательно остановило бы релизы. После споров решение приняли.

Переход занял больше полугода. В результате команды стали чаще синхронизировать код, количество багов на релиз снизилось на порядок, а дефекты из-за конфликтов исчезли.

Рост начинается с наблюдательности

Профессиональный рост остаётся ответственностью самого человека. Руководитель может помочь, но он не обязан постоянно подбирать интересные задачи.

Рабочие проблемы дают всё необходимое для развития: реальные ограничения, цену ошибки, необходимость договариваться и измеримый результат. Нужно научиться их замечать, проверять и доводить решения до внедрения.

«Рецепты чистого кода», Максимилиано Контьери

Fri, 04 Jul 2025 00:00:00 GMT

Ну что, отдохнём немного от софтов и побалуемся вкусным техническим контентом? Не думали же вы, что я только софтовые книги читаю, правда?

Всякого интересного технического я читаю довольно много. Но раньше редко делился этим в блоге — всё казалось как-то не к месту. Даже отдельный канал для технички завёл. Однако недавно понял, что сам себя перемудрил. Я же технический руководитель, как-никак. Так что буду писать обо всём понемногу.

Книга Контьери попалась мне в руки случайно. В одном приятном коммьюнити есть технический книжный клуб, участница которого пожаловалась, что никак не может дочитать эту книгу и запросила совместное чтение на спор. Я вызвался помочь :)

О чём книга

Книга посвящена тому, как делать код более чистым и поддерживаемым. В ней содержится 25 глав, каждая из которых раскрывает некоторый набор принципов разработки.

В книге затрагиваются следующие темы:

Чем плохи анемичные модели и как их сделать лучше.
Как уменьшать сложность кода.
Как упрощать условные операторы.
Работа с техническим долгом и исключениями.

3 идеи из книги

Правило наименьшего удивления: при взаимодействии программная система должна вести себя предсказуемо для пользователя. Как разработчик, я должен создавать интуитивно понятный код, с которым другим разработчикам будет легко взаимодействовать.
Использование утверждений вместо отрицаний. Частенько в коде попадаются методы/переменные/функции, которые “не-что-то”. Утвердительные названия проще читаются, поэтому такие наименования лучше менять на “что-то”.
Проблема йо-йо: когда для понимания кода приходится перемещаться вверх-вниз по иерархии классов. Сейчас я с кайфом пишу на Go, который лишён этой проблемы (и полон других). Но раньше (особенно на .NET) разобраться с источником проблемы могло быть очень непростой задачей.

Мои впечатления

Скажу сразу честно: книга — кусок тихого ужаса. Я не знаю, пробовал ли автор на практике сам то, что написал, но выглядит это всё жутко. Штош, про плохие книги тоже нужно говорить.

Начну с того, что все примеры написаны на разных языках. Одни проблемы актуальны только для JS, другие — только для Python, третьи — ещё для чего-то. Читать это как минимум неудобно, особенно если не знаком хотя бы с азами синтаксиса.

Дальше. Книга вызывает ощущение, что сам автор никогда толком не писал код (я даже погуглил — так оно и оказалось). Идеи надёрганы из кучи разных книг и собраны в группы по смыслу. Но если посмотреть на картину целиком, то она не складывается. А если начать применять сразу все рекомендации из книги, то вам, вероятно, руки на код-ревью оторвут :)

Короче говоря, рекомендую держаться подальше от этой поделки. Лучше почитать Чистый код Мартина и Объектно-ориентированное конструирование Мейера, на которые так активно ссылается автор. Эти книги хотя бы написаны программистами, которые реально код писали.

Что делать, если сотрудник просел по перформансу

Thu, 03 Jul 2025 00:00:00 GMT

Когда человек начинает работать хуже, руководителю легко навесить на него ярлык лоуперформера. Ярлык упрощает картину, но не помогает понять, что произошло и можно ли ситуацию изменить.

Поэтому моя первая задача — не решать, плохой ли передо мной человек, а описать наблюдаемое поведение и его последствия для команды.

Не торопитесь с диагнозом

Если человек работал нормально, а потом внезапно просел, скорее всего, его поведению есть объяснение. Человек мог устать, выгореть, заболеть, заскучать, столкнуться с личными проблемами или не справляться с изменившейся ролью.

Некоторое время стоит понаблюдать, но не затягивать молчание. Если просадка продолжается, нужен разговор. Я описываю, что вижу, объясняю, как это влияет на работу, и даю сотруднику возможность показать свою картину.

Соберите план изменений

Если одного разговора недостаточно, следующий шаг — план по улучшению эффективности. Название не так важно. Важно, чтобы в нём были:

причина проблемы или рабочая гипотеза о ней;
конкретные и наблюдаемые ожидания;
задачи на период плана;
срок, когда мы оценим результат;
регулярные синхронизации;
поддержка со стороны руководителя;
понятные последствия, если договорённости не будут выполнены.

Ключевая работа здесь на руководителе: понять причину, задать реалистичный срок, подобрать задачи и не превращать план в формальную процедуру перед увольнением.

Не забывайте о команде

Проблема одного сотрудника влияет не только на его руководителя. Если человек систематически не выполняет обязанности, остальные получают его работу, смещённые сроки и сигнал, что ожидания необязательны. Это может бить по морали сильнее самой просадки.

Но и другая крайность опасна. Если руководитель тратит всё внимание только на проблему, сильные сотрудники остаются без поддержки и возможностей для роста. Время менеджера ограничено, и его нужно делить между восстановлением просевшего сотрудника, развитием сильных и работой над системой.

Когда пора расставаться

Если ожидания ясны, поддержка дана, срок достаточен, а изменений нет, нужно переходить к заранее озвученным последствиям. Иначе план теряет смысл, а команда — доверие к руководителю.

Быстрое решение не всегда означает мгновенное увольнение. Оно означает не затягивать ни диагностику, ни план, ни решение после его завершения.

Руководитель не умеет читать мысли

Mon, 30 Jun 2025 00:00:00 GMT

Вы умеете читать мысли? Вот и я не умею. Руководители тоже не умеют, но люди продолжают ждать, что кто-то сам заметит их проблемы, догадается о карьерных планах и всё исправит.

Кто-то стесняется говорить, кто-то боится показаться слабым или навязчивым. Но результат один: важная информация остаётся в голове одного человека, а остальные принимают решения без неё.

О проблемах стоит говорить до взрыва

Проблемы и внутренние конфликты имеют неприятное свойство: раздражение накапливается, а затем чаша терпения переполняется в самый неподходящий момент.

Поныть в пятницу за рюмкой чая недостаточно. Если проблему может решить руководитель, коллега или другой конкретный человек, нужно рассказать её именно ему: описать ситуацию, свой взгляд и возможные варианты решения.

Это может быть страшно и неприятно. Зато такое действие хотя бы создаёт шанс что-то изменить. Как минимум напряжение становится явным, а в хорошем сценарии проблема действительно решается.

С карьерными планами работает так же

Недавно ко мне на консультацию пришёл человек и сказал: «Я хочу стать тимлидом». Я спросил, что по этому поводу думает его текущий руководитель и обсуждал ли он это вообще с кем-то на работе. В ответ — тишина. Человек даже не задумался, что это лучшая отправная точка.

Хороший руководитель должен помогать людям развиваться, но невозможно растить человека в нужную ему сторону, если он не говорит, чего хочет. Можно выдавать какие-то задачи «на развитие», но это будет натягивание совы на глобус.

Если хотите стать тимлидом — скажите тимлиду и попросите менеджерские задачи. Если хотите стать сеньёром — обсудите критерии с руководителем и попросите помощи у действующего сеньёра. В худшем случае вы раньше узнаете, что желаемого роста в текущей команде или компании не будет, и сможете скорректировать стратегию.

Если нужна помощь, изменения или рост — говорите об этом словами через рот. Никто не обязан догадываться, что у вас в голове.

Почему руководители бросают менеджмент — и возвращаются?

Sat, 28 Jun 2025 00:00:00 GMT

Разговор о том, почему переход из разработки в управление не обязан быть необратимым. Я рассказываю, как выгорел от менеджмента, вернулся к программированию, а через год снова стал тимлидом — уже с другим пониманием роли и собственных ограничений.

О чём разговор

Как признать, что управление больше не подходит, и разрешить себе сделать паузу.
Что возвращение к разработке помогло мне понять о себе и работе руководителя.
Почему через год я снова выбрал роль тимлида.
С какими проблемами сталкивается руководитель в быстро растущей компании.
Что компании могут сделать, чтобы удерживать тимлидов от выгорания и бегства «в код».
Как оценить собственное желание уйти из менеджмента, не считая смену траектории поражением.

Похожую тему — право руководителя на чувства и осознанный шаг назад — мы обсуждали в подкасте «Тимлид тоже человек».

«Стоики побеждают», Маркос Васкес

Fri, 27 Jun 2025 00:00:00 GMT

Если после просмотра нашего квартирника вам захотелось глубже погрузиться в тему стоицизма — держите отличную книгу.

Иногда хочется не Сенеку, а живого и современного собеседника. Если автор крут, то создаётся ощущение, будто я с ним поговорил на эти темы, а не просто книжку прочитал.

Книгу Васкеса мне рекомендовали несколько раз, и вот я сдался. Но между книгами стоиков я делаю значительные перерывы, чтобы идеи успевали отлежаться в голове и найти себе место в жизни. И недавно я понял, что хочется свежатинки.

О чём книга

Книга посвящена не глубоким рассуждениям на тему стоицизма, а конкретным практикам для применения этой философии в своей жизни. Автор рассматривает стоические принципы и взгляды на мир, плавно переводя их в конкретные упражнения и практики.

В книге раскрываются следующие темы:

Основные принципы стоицизма
Как поддерживать и развивать трезвое мышление
Как действовать активно и дисциплинированно
Инструменты стоика

Три идеи из книги

Вместо зацикленности на результате нужно фокусироваться на действии и привычках. Результаты от нас не зависят, фиксация на них — путь к раздражению, тревоге и унынию. Сосредоточиться на правильных действиях и получать от них удовлетворение гораздо продуктивнее.
Многие проблемы возникают из-за автоматических негативных мыслей и предубеждений. Они, в свою очередь, вызывают сильные эмоции и непродуктивное поведение. Стоики отслеживали подобные мысли и критически пересматривали их, освобождаясь от власти автоматизма. Этот же принцип применяется в современной психотерапии.
Привычки не удастся изменить, если пытаться изменить только поведение и не менять самосознание. Проблема всяких «атомных привычек» в том, что они забывают: человек — не робот. Если не меняешь отношение к себе и миру, то поведение откатится.

Мои впечатления

Несмотря на небольшой объём, читал я эту книгу довольно долго. В ней много хороших идей, и мне хотелось рассмотреть их все. Автору хорошо удалось объединить современные достижения психологии и стоический подход.

Особенно мне понравилось, что книга очень прикладная. В ней почти нет абстрактных рассуждений, зато много практических идей и полноценных руководств к действию. Последняя глава полностью посвящена стоическим инструментам и написана на уровне «бери и делай». При этом теоретической части достаточно, чтобы понять смысл того или иного действия.

Мне книга дала несколько хороших идей и практик. Например, я дополнил свой дневник парочкой интересных (и временами неприятных) вопросов. Я бы не рекомендовал начинать изучение стоицизма с этой книги (пальму первенства пока всё ещё держит книга Массимо Пильюччи «Как быть стоиком»), но в качестве второй — зайдёт очень хорошо.

Эта книга не про «подумать», а про «работать над собой». А это, как известно, больно.

Менеджер-стоик: античные практики современного управления

Wed, 25 Jun 2025 00:00:00 GMT

Дискуссия о том, как идеи стоицизма применимы в повседневной работе руководителя. В ней встретились практики управления и профессиональные философы: Женя Антонов, Александр Саликов и Ирина Райт из Школы стоицизма и я.

О чём разговор

Как отличать то, на что руководитель может повлиять, от того, что находится вне его контроля.
Может ли негативная визуализация снижать страх перед неудачей.
Как пауза между событием и реакцией помогает в сложной коммуникации.
Где проходит граница между принятием реальности и пассивностью.
Какие стоические практики можно использовать для рефлексии и сохранения внутренней опоры.

Формат квартирника позволил зрителям направлять разговор своими вопросами, поэтому это не лекция о философии, а спор о её применимости к реальным проблемам руководителей в IT.

Продолжить знакомство с темой можно в моих обзорах книг «Как быть стоиком» и «Стоики побеждают».

«Психология влияния», Роберт Чалдини

Fri, 20 Jun 2025 00:00:00 GMT

Все хотят влиять на людей. Кто-то — чтобы лучше продавать товары и услуги. Другие просто хотят больше власти и влияния.

Уметь оказывать влияние для меня важно в работе. Поэтому я и взялся читать книгу Роберта Чалдини «Психология влияния». Я читал её несколько лет назад и тогда понял не очень много. Сейчас же я решил перечитать её с новым пониманием и новым подходом к чтению.

О чём книга

Чалдини рассказывает о 7 принципах влияния. Их используют и продавцы, и хорошие переговорщики, и даже секты. Несмотря на простоту, эти принципы опираются на фундаментальные человеческие ценности, что делает их применение очень эффективным.

В книге раскрываются следующие темы:

Часто встречающиеся уловки продавцов и манипуляторов.
Как не стать жертвой обмана и манипуляции.
Как манипулировать совестью и навязывать обязательства.
Как располагать к себе людей.

Три идеи из книги

Один из принципов — правило взаимности. Мы ненавидим быть должными. Поэтому, если тебе что-то «дарят», ты автоматически хочешь отдать в ответ. На этом принципе строится взаимодействие в обществе: давать что-то другим безопасно, эгоистичные люди порицаются. Сразу вспоминаются кришнаиты, которые «дарят» книгу :)
Нам нравятся люди, похожие на нас. Этот принцип можно использовать в разных целях: например, можно наладить отношения с коллегой, если найти схожие интересы, или стать более эмпатичным, находя общие черты с другими людьми. А можно и манипулировать подобным образом.
Социальное доказательство лучше всего работает, когда мы получаем положительное подкрепление от людей, похожих на нас. Вряд ли программиста можно заманить сообщением вида «тысячи маркетологов по всему миру…». Чем сильнее идентификация с подтверждающей аудиторией, тем проще человеку поддаться на ловушку толпы.

Мои впечатления

Закрою сразу вопрос этичности. Книга — максимально этичная. Чалдини не только даёт сами инструменты влияния, но и показывает их использование как во благо, так и во вред. При этом одна из целей книги — научить читателя видеть эти манипуляции и противодействовать им.

Инструменты — это просто инструменты. Всё зависит от намерений человека, в чьих руках они оказались.

Теперь о книге. Она великолепна. Чалдини собрал действительно рабочие принципы влияния, которые можно применять хоть каждый день. Вопрос этичности применения остаётся за читателем, но сам автор топит за противодействие манипуляциям и защиту от них.

При этом книга довольно трудная. Её не получится просто проскользить глазами — контент плотный, примеров и пояснений много. Но усилия, затраченные на разбор написанного, стоят того.

Я считаю, что книгу стоит прочитать всем, кто контактирует с людьми (то есть вообще всем). Как минимум — научитесь видеть различные манипуляции в жизни. Как максимум — сами станете манипулятором, которому люди ещё и спасибо говорить будут.

Лидерство в трудные времена: как управлять командой в кризис

Wed, 18 Jun 2025 00:00:00 GMT

Доклад о том, как руководить командой в кризисе, когда привычные процессы перестают работать, сроки срываются, а давление растёт. Он построен на историях из моих проектов: часть кризисов мы прошли успешно, часть — нет.

О чём выступление

Как отличить кризис от системной проблемы, которую давно не решают.
Почему команда в хаосе ищет опору прежде всего в руководителе, а не в процессе.
Как сохранять прозрачность и расставлять приоритеты, когда всё кажется срочным.
Как «сушить» объём работы до того, что действительно несёт ценность.
Почему руководителю нужно следить за собственным состоянием и искать поддержку.
Какие непопулярные решения может потребовать кризис и чем за них придётся заплатить.

Главная мысль доклада: если лидер сломался, управленческие инструменты ему уже не помогут. Личная устойчивость не заменяет приоритизацию, честную коммуникацию и решения, но без неё воспользоваться ими не получится.

Каких софтовых навыков не хватает моему сотруднику?

Tue, 17 Jun 2025 00:00:00 GMT

Круглый стол руководителей из крупных IT-компаний о софт-скиллах, которые влияют на результат сотрудника и его карьерный рост. Участники сравнивают требования разных компаний и обсуждают, как отличить действительно полезный навык от модного, но переоценённого.

О чём разговор

Какие софт-скиллы стали критичными для работы в IT.
Какие навыки помогают специалисту расти в карьере.
Какие софт-скиллы переоценены и почему.
Можно ли измерить влияние таких навыков на результат команды.
Как руководителю понять, какой навык стоит развивать у конкретного сотрудника.

Мою позицию о роли этих навыков в технической карьере можно прочитать в заметке «Техлид без софт-скиллов — это миф».

«Идеальный командный игрок», Патрик Ленсиони

Fri, 13 Jun 2025 00:00:00 GMT

Хорошую команду невозможно сколотить из людей, которые не умеют работать в команде. Эта идея кажется очевидной. Но можете ли вы сходу ответить, какие именно качества делают человека командным игроком?

В поисках ответа на этот вопрос я и взял книгу Патрика Ленсиони «Идеальный командный игрок». Ранее я читал другую его книгу — «Пять пороков команды», и она мне понравилась своей структурностью и интересным форматом, а также дала много пищи для размышлений.

«Идеальный командный игрок» тоже написана в жанре бизнес-романа с пояснительными теоретическими главами в конце. Сначала читаешь историю, а потом допниками дополняешь понимание — очень удобно.

О чём книга

Книга продолжает историю одного из героев «Пяти пороков команды», который решил выйти из IT и пойти управлять строительным бизнесом. Он внезапно оказывается в ситуации вида «пан или пропал» и понимает, что затащить два огромных проекта можно только командной работой…

В книге раскрываются следующие темы:

Какими тремя качествами обладает идеальный командный игрок?
Как распознать, что сотруднику не хватает одного из качеств?
Как помочь людям становиться идеальными игроками?
Как сочетать эту модель с пятью пороками команды?

3 идеи из книги

Три ключевых качества командного игрока: скромность, жажда деятельности, чуткость. Скромность означает умение не перетягивать одеяло внимания на себя (а вовсе не умалчивание достижений), жажда деятельности говорит сама за себя, а чуткость — это эмоциональный интеллект и навыки коммуникации.
Если не увольнять ослов, то начнут уходить те, кто ослами не являются. Ослами герои книги называют людей, далёких от командной работы. В примере Ленсиони рассказывает о том, как люди уходили из-за скилловой, но крайне неприятной в общении проектной менеджерки.
Люди могут делать что-то не со зла. Например, хорошие специалисты могут быть излишне резкими в общении только потому, что не понимают, как это выглядит со стороны и воспринимается другими людьми. Задача команды — помочь им развить нужные навыки.

Мои впечатления

Модель Ленсиони мне показалась достаточно простой и гибкой. Она настолько проста, что кажется обыкновенным здравым смыслом. И тут мне сразу же вспоминается Годратт, который говорил, что самые правильные вещи в конечном счёте кажутся просто здравым смыслом.

Сама книга хорошо и наглядно показывает, как выглядит работа с человеком, у которого недостаёт одного из трёх качеств. Это не означает, что у всех сотрудников все эти качества должны быть «вкачаны» на максимум — мы люди, у каждого будут свои перекосы. Но полное отсутствие любого из них может быть разрушительным.

Книга небольшая и приятно читается (я прочитал её в самолёте, пока летел домой с CodeFest). Художественная составляющая проста и наглядна, а автор и не планировал писать «Войну и мир». Некоторые сценки из книги даже вызывали у меня флешбеки.

Рекомендую к прочтению, если у вас уже есть опыт руководства. Идеи Ленсиони хороши сами по себе, но гораздо лучше ложатся на набитые граблями шишки.

Говорить о своих достижениях — не хвастовство

Mon, 09 Jun 2025 00:00:00 GMT

Другие люди не обязаны замечать наши достижения. Они не обязаны нас хвалить и вообще обращать внимание на то, что мы что-то сделали.

Звучит сурово, но люди не умеют читать мысли и в первую очередь думают о себе — что совершенно нормально. Более того, мы живём в таком потоке информации, что периодически забываем даже о собственных делах. Заметить значимую работу другого человека бывает действительно сложно.

Говорить о результатах — нормально

Меня с детства учили: «Не хвастайся, хвастаться нехорошо, хвастунов никто не любит». Только под определение хвастовства в моём информационном поле попадали и вполне здравые сообщения о своих достижениях.

Из страха быть осуждённым человек может умалчивать о значимой работе. Это вредит и ему самому — никто не догадается, — и окружающим, которым результат мог бы оказаться полезен.

Это ещё и помощь руководителю

Представьте руководителя с широким контекстом, кучей работы и постоянным потоком информации. Чтобы самостоятельно заметить чьё-то достижение, ему нужно выделить внимание, проанализировать работу человека и понять, что в ней было значимым.

Сообщая о своих результатах, вы облегчаете эту работу. То же самое с коллегами: если вы сделали полезную для них штуку, рассказать о ней — не бахвальство, а нормальная передача информации.

Грань, конечно, тонкая. Я для себя выделил простое правило: констатировать факты и свои чувства, не приукрашивая результат и не превознося себя.

Например: я выступил с докладом на CodeFest, получил рейтинг 4,87 из 5 и очень этим горжусь. Здесь есть факты и моя реакция. Но стоит добавить «я порвал аудиторию» и «люди рукоплескали стоя», как нормальная коммуникация начинает превращаться в хвастовство.

Не стесняйтесь говорить о своих результатах. Так другим людям проще понять, что вы сделали и чем это может быть полезно.

«Наука нечтения», Рустам Агамалиев

Fri, 06 Jun 2025 00:00:00 GMT

Как минимум пять человек поймали меня на CodeFest с вопросами о том, как я читаю. Пришла пора раскрыть завесу тайны!

Первое, с чего я начинал свой рассказ, — я не придумал ничего нового. Я просто понял, что не умею читать, и нашёл способ этому научиться.

Так уж сложились обстоятельства, что мой учитель недавно взял и опубликовал книгу о том, как нужно эффективно читать (или, точнее, не-читать) книги. И, конечно же, я её про-не-читал буквально через пару недель после публикации.

О чём книга

Книга посвящена методу не-чтения. Суть его заключается в том, что внимательный и требовательный читатель гораздо больше не читает, чем читает. Метод направлен на то, чтобы извлекать суть из книг, получая ответы на свои вопросы без пустой траты времени и сил.

В книге раскрываются следующие темы:

Чем настоящее чтение отличается от того, которому нас учили в школе?
Почему так важно готовиться к чтению и как это делать?
Как превратить развлекательное чтение в образовательное?
Техники, которые помогают качественнее читать и осмыслять прочитанное.
Бонус-глава о том, как читать художественную литературу.

3 идеи из книги

Результат чтения гораздо важнее количества прочитанных книг. Число просмотренных страниц не имеет никакого значения само по себе; важны только изменения, которые произошли в жизни после чтения и осмысления прочитанного.
Не-чтение основывается на избирательности. В первую очередь читатель должен понять, какую цель он хочет достичь и какие источники ему в этом помогут. Его задача — совсем не потребление новой информации и не удовлетворение эго циферкой прочитанных книг. Экономия сил и времени достигается за счёт осознанного выбора: что нужно читать, а что можно пропустить.
Для реальных изменений в жизни просто читать книги недостаточно. Нужно ещё обдумывать идеи, экспериментировать с ними, находить им место в своей жизни и личной системе знаний. Тогда и только тогда новая информация будет усваиваться, запоминаться и влиять на жизнь читателя.

Мои впечатления

Не буду юлить — я всё-таки изрядно предвзят и к автору, и к книге. В своё время обучение у Рустама в корне изменило мой подход к чтению и самообразованию. И хотя у меня сейчас не всегда хватает времени и сил на написание заметок по прочитанному, я глубоко осознаю и ощущаю важность осмысления и применения новой информации.

Книга показывает альтернативный взгляд на чтение и выводит из привычной модели «читаем от корки до корки, а потом пересказываем прочитанное», которую нам отчаянно вбивали в головы с первого класса. Автор предлагает другой подход к чтению — через осознанность, продуманную подготовку и глубокую работу с полученными в результате чтения идеями.

Я руководствуюсь изложенными в книге принципами каждый день, при чтении любого материала. Конечно, мне ещё далеко до уровня Рустама, но применение даже части инструментов (при условии понимания общей системы) сильно улучшило качество моего чтения.

Рекомендую однозначно, даже если вы не читаете книги. Вы совсем иначе взглянете на все окружающие тексты.

Выбирайте знания, которые можно унести с собой

Wed, 04 Jun 2025 00:00:00 GMT

Сейчас можно развиваться почти в любом направлении: вокруг полно книг, тренажёров, курсов и менторов. Эта доступность создаёт новую проблему — проблему выбора.

Хорошо, когда есть понятные точка А, точка Б и список навыков между ними. На практике точка Б часто размыта, критерии развития непонятны, а возможных направлений слишком много. Особенно сложно выбирать, когда текущие навыки уже на хорошем уровне: углубляться дальше дорого, но и альтернативы неочевидны.

Я всю жизнь страдал жгучим любопытством. Иногда кажется, что мне интересно вообще всё. Но с ростом моего островка знаний ширилось и осознание океана неизвестности, поэтому выбирать всё равно приходилось.

Переносимость как критерий

В книге Скотта Адамса «Теория везения» — дурацкий перевод, не отражающий сути, — я нашёл полезный критерий. Если конкретной цели сейчас нет, для развития стоит выбирать наиболее универсальные знания и навыки: те, которые можно применять в разных областях жизни.

Возьмём переговоры. Они нужны не только на работе: в переговорной ситуации можно оказаться даже в отпуске, торгуясь за магнитики. Широта применения делает вложения в этот навык выгодными.

А знания конкретного фреймворка применимы только в одной области, а иногда даже в одной компании или команде. Они могут быть необходимы прямо сейчас, но вероятность унести их с собой заметно ниже.

Не все узкие знания бесполезны

Из этого легко сделать поспешный вывод, будто узкопрофильные знания не нужны. Нужны, ещё как. Важно понимать их область применения и необходимую глубину. Язык программирования обычно имеет смысл изучать глубже, чем конкретную библиотеку, но и библиотека может быть лучшим вложением, если без неё не решить текущую задачу.

Переносимость — не единственный критерий и не повод игнорировать специализацию. Это способ выбрать направление, когда явной цели нет, а расти хочется. В долгую я предпочитаю вкладываться в навыки, которые переживут смену проекта, роли и компании. Например, одной из самых удачных инвестиций для себя я считаю развитие критического анализа информации.

«Камасутра для оратора», Радислав Гандапас

Fri, 30 May 2025 00:00:00 GMT

В этом году у меня довольно бурно идёт работа с публичными выступлениями: доклады (наконец-то) начали попадать в программы конференций, выступаю я относительно регулярно, плюс наложилось внутреннее обучение по выступлениям. Тема для меня всё-таки относительно новая, поэтому я постоянно ищу любые советы и идеи, как сделать свои доклады лучше.

Конечно же, я не мог пройти мимо книги одного из самых известных спикеров России — Радислава Гандапаса. Этот человек зарабатывает на жизнь публичными выступлениями, поэтому его опыт в этой области я считаю ценным и интересным.

О чём книга

Книга посвящена основам публичных выступлений. Автор задаётся целью научить читателя не просто выступать публично, но ещё и получать от этого удовольствие (прекрасный посыл, я считаю).

В книге раскрываются следующие темы:

Как работать с волнением перед выступлением?
Как подготовить хорошее выступление?
Как устанавливать контакт с аудиторией и вовлекать её?
Как отвечать на каверзные вопросы?

Три идеи из книги

При анализе прошедшего выступления сосредоточьтесь на том, что у вас получилось хорошо. Поиск ошибок закрепляет мнение о себе как о слабом спикере. Нужно найти свои фирменные сильные стороны и использовать их. 2, Блестящий финал получается, если последние фразы выступления перекликаются с первыми и таким образом замыкают круг. Подтверждаю на своём опыте как слушателя: от таких выступлений всегда остаются приятные впечатления.
Не выступайте перед людьми, а разговаривайте с ними. Скучные лекторы-всезнайки всем ещё в университете оскомину набили.

Мои впечатления

Начну с хорошего. В книге я встретил несколько действительно интересных и необычных идей, которые можно применить на практике. Например, поиск своих сильных сторон как спикера при пост-анализе выступления — я почему-то обычно только ошибки ищу. Также я утащил некоторые идеи по взаимодействию с аудиторией и поддержанию вовлечённости.

Но вау-эффекта книга не произвела. Довольно много воды и бахвальства, а вторая половина вообще состоит из многословных вопросов и ответов. Плюс некоторые метафоры Гандапаса показались мне, кхм, излишне яркими.

В целом книжка достойна того, чтобы начинающие спикеры просмотрели её и взяли себе на вооружение некоторые идеи. Да и опытные докладчики могут найти себе парочку нововведений. Но хорошее обучение по публичным выступлениям и большое количество практики она, конечно, не заменит.

«100 ошибок Go и как их избежать», Тейва Харшани

Fri, 23 May 2025 00:00:00 GMT

Давайте немного отдохнём от менеджмента, софтов и вот этого вот всего — с хардкорным кодом! Как-никак, я до сих пор каждый день пишу код. Последние полтора года я программирую на Golang, и мне очень нравится этот язык.

Конечно же, базовые книжки я прочитал ещё на стадии изучения языка. Но с тех пор как-то руки не доходили почитать что-то конкретно про Go — я больше читал про архитектуру, распределённые системы и базы данных. И тут произошло неожиданно приятное событие: ко мне пришли ребята из издательского дома «Питер» и предложили сделать обзор на обновлённое издание книги «100 ошибок Go».

Конечно, я не мог отказаться от обзора очередной интересной книги. Тем более что «100 ошибок Go» — книга не для новичков. Но обо всём по порядку.

О чём книга

Как следует из названия, книга посвящена разбору 100 примеров ошибок и неэффективной работы в языке Golang. Глобально ошибки разбиты на смысловые разделы: организация кода, обработка ошибок, конкурентность и так далее.

Что можно узнать из книги:

Как грамотно использовать интерфейсы.
Как выстрелить себе в ногу, перепутав длину и ёмкость среза.
Чем всё-таки отличается конкурентность от параллелизма.
Как создать race condition с помощью оператора append.
И многое другое :)

3 идеи из книги

В Go интерфейс создаётся на уровне клиента. Это непривычно для программистов типа меня, которые обычно определяют интерфейс как абстракцию доступа. Проблема в том, что интерфейсы в Go реализуются неявно, и поэтому код не должен навязывать абстракцию своим клиентам.
Называть пакеты в Go нужно ещё тщательнее, чем переменные. Именование пакета должно быть кратким, ёмким и отражать его возможности. Пакеты похожи на namespace из C#, и одновременно не являются ими. Знали бы вы, сколько мы времени на код-ревью тратим, придумывая нейминг пакетов…
Обработка ошибки должна быть выполнена ровно один раз. Знаю-знаю, всегда есть соблазн сделать что-то и передать ошибку дальше, но это не идиоматично. Если код обработал ошибку, то она не должна «лететь» дальше. Является ли дополнительное логирование обработкой — решайте самостоятельно :)

Мои впечатления

Книга мне очень понравилась. Она далеко не такая простая и примитивная, как базовые руководства по Go, и посвящена разным хитрым нюансам языка. Некоторые ошибки довольно очевидны, если внимательно пройти A Tour of Go, но многие другие дали мне достаточно интересной пищи для размышлений.

Большой плюс книги — куча интерактивных примеров кода, которые можно запихнуть в Go Playground и поэкспериментировать (я провёл несколько весьма интересных экспериментов с конкурентностью). При этом код написан очень ясно, лаконично и снабжён комментариями, поэтому читать его легко и приятно.

Отдельный плюс — перевод книги. Он достаточно хорош: в процессе чтения я не спотыкался на словах и не ловил ступор. Технические книги в целом переводить непросто, и переводчики «100 ошибок Go» хорошо справились со своей задачей.

Если вы только начинаете изучать Go — скорее всего, книга вам покажется тяжеловатой. Но более опытным ребятам она, по моему мнению, зайдёт очень хорошо.

Теория ограничений в разработке: как ускорить поставку без новых людей

Wed, 21 May 2025 00:00:00 GMT

Когда инженер только становится тимлидом, у него появляется понятная цель: заставить всё вокруг работать максимально эффективно. Технический бэкграунд даёт о себе знать: привычка оптимизировать никуда не девается.

Поэтому полная загрузка каждого выглядит правильным и экономически оправданным решением. На своём опыте я увидел, как такая локальная оптимизация ухудшила поставку, перегрузила QA и создала больше багов. И как после этого мы всё-таки ускорили поставку примерно на 30% без новых людей.

Как мы ухудшили поставку

Однажды моей команде потребовалось нарастить поставку. Первая мысль была простой: нужно оптимизировать время работы программистов. Мы изменили процессы, снизили затраты времени, и разработчики действительно начали закрывать больше задач.

Круто же? Не круто. Поставка команды стала хуже.

Мы сделали то, что делают многие команды: ускорили один участок системы, не посмотрев на поток целиком. Разработчики начали быстрее передавать задачи в тестирование. QA было меньше, система была сложной, и ребята не успевали переваривать поступающую работу.

После ускорения разработки нагрузка выросла ещё сильнее. Тестировщики стали спешить, уставать и пропускать баги. Мы одновременно ухудшили скорость поставки и качество системы.

Система работает со скоростью ограничения

В незавершённом продукте нет ценности. Код бесполезен, пока не окажется в продакшене и не начнёт приносить пользу клиентам. До этого его нужно отревьюить, протестировать и выкатить.

Если ограничение находится не в разработке, нет смысла ускорять только разработчиков. Они перегрузят следующий этап, а незавершённой работы станет больше.

Эту модель Элияху Голдратт подробно объясняет в книге «Цель». Там же я взял практическую эвристику: перед бутылочным горлышком всегда скапливается работа.

Первым правильным решением было перестать копать. Мы отказались от идеи запихнуть в работу максимум фич и начали отталкиваться от загрузки QA. Тестировщики смогли спокойно делать свою работу, а у разработчиков появилось время на техдолг и изучение соседних областей.

Изначальную проблему это не решило: скорость поставки осталась прежней. Зато мы перестали её ухудшать и увидели настоящее ограничение.

Как мы искали бутылочное горлышко

На доске всё выглядело просто до боли: в Ready for QA висело в среднем по десять задач, периодически число вырастало до пятнадцати. Но одного скопления работы недостаточно, чтобы объявить этап ограничением.

Мы проверили гипотезу несколькими способами:

Посмотрели динамику Ready for QA за несколько недель и cycle time для этого статуса. Он оказался самым большим в жизненном цикле задачи, а входящий поток был выше исходящего.
Провели ретроспективы о трудностях в поставке. Тестировщики жаловались на нагрузку, разработчики — на то, что задачи долго висят в тестировании и из-за этого приходится разруливать конфликты.
Послушали дейлики. Там регулярно звучали просьбы протестировать какую-то задачу в приоритете, потому что она блокирует следующую.

Сразу несколько сигналов указывали на один этап. Поэтому мы достаточно уверенно признали тестирование ограничением.

Первая гипотеза не всегда будет верной. Например, в другой моей команде самый долгий cycle time был у статуса Ready for release. Но это не делало частоту релизов ограничением. Долгий статус нужно сопоставлять с потоком работы и обратной связью команды.

Как ускорить ограничение

Первым делом я запросил дополнительных тестировщиков. Начальство ответило в стиле «денег нет, но вы там держитесь». Пришлось строить систему вокруг тестирования доступными способами.

Мы смотрели на четыре рычага:

Не перегружать ограничение работой, которую оно всё равно не успеет сделать.
Ускорить прохождение задач через него.
Убрать с ограничения то, что могут сделать другие.
Увеличить ресурс ограничения, если это станет доступно.

Мы уже перестали перегружать QA фичами. Теперь нужно было ускорить тестирование за счёт более свободного ресурса разработки.

У нас уже была автоматизация, но самих тестов не хватало. Тестировщикам постоянно не хватало времени на их написание. Параллельно мы прикинули, сколько задач возвращается из тестирования на доработку, и поняли, что повышение качества входа тоже может нас ускорить.

В итоге мы изменили процесс:

в Definition of Ready добавили тест-кейсы, которые QA помогали описывать до начала разработки;
в Definition of Done добавили автотесты на описанные в требованиях сценарии;
завели для разработчиков задачи на рост общего покрытия приложения автотестами.

Гипотеза была такой: описанные тест-кейсы упростят работу программиста, автотесты снизят число возвратов из QA, а растущее покрытие уменьшит число багов в целом. Ресурс тестировщиков сместится в начало процесса, но это окупится на самом тестировании.

Что получилось

Пару спринтов команда привыкала к новому процессу. Потом появилась обратная связь: программисты радовались, что задачи реже возвращаются на доработку, тестировщики — что в задачах меньше багов и растёт покрытие.

Поставка ускорилась примерно на 30%. С опытом команды и ростом количества автотестов показатель продолжал расти. Бонусом баги в продакшене со временем снизились практически до нуля.

Главный вывод из этой истории не в том, что всем нужно срочно писать больше автотестов. У другой команды ограничение будет в другом месте. Смысл в том, чтобы не оптимизировать самый заметный или знакомый участок, а найти реальное ограничение и подчинить ему весь поток.

Ограничение переместилось

После ускорения QA мы действительно стали поставлять больше фич. И тут перестал справляться другой элемент системы: подготовка требований со стороны бизнеса.

Продакт работал с несколькими командами и привык к определённому темпу. Рост нашей производительности создал ему внезапную проблему. Пока он адаптировался, мы с довольными лицами разгребали техдолг и докручивали автоматизацию.

Так я на практике увидел ещё одну важную вещь: бутылочное горлышко в системе есть всегда. Когда мы расшиваем одно, ограничение перемещается в другое место. Поэтому ускорение потока не заканчивается одной победой. После каждого улучшения нужно снова смотреть на систему целиком.

Как учиться осмысленно: от вопроса к проверке реальностью

Sun, 18 May 2025 00:00:00 GMT

Формат обучения в школе и институте — верный способ привить человеку отвращение к мысли о том, чтобы учиться чему-то новому. Я довольно долго искал собственные принципы самообразования, потому что в IT невозможно бесконечно ехать на старых знаниях.

Со временем у меня сложился процесс: понять, зачем мне знание, письменно обдумать идею, найти ей место в собственном опыте, проверить реальностью и только после этого решить, стоит ли тащить её дальше.

Если собрать процесс целиком, получится семь этапов:

Выбрать область или вопрос, с которым я хочу разобраться.
Собрать книги, статьи и другие материалы по теме.
Отобрать из них наиболее полезные и выстроить очередь.
Перед чтением определить, какой ответ я ищу.
Читать нелинейно и выбрасывать всё, что не работает на цель.
Переформулировать важные идеи, проверить их логику и перенести в свой контекст.
Превратить подходящую идею в действие и проверить её жизнью.

Это не обязательный конвейер для каждой книги. Отдельные шаги можно пропускать, а сам процесс постоянно меняется. Его задача — не усложнить чтение, а не дать потраченному времени уйти в никуда.

Зачем мне это знать?

Этот вопрос я начал использовать в развлекательных целях. Когда я менял работу и проходил собеседования, то периодически сталкивался с интервьюерами, которые задавали крайне нетривиальные, если не сказать извращённые, вопросы.

В какой-то момент мне это надоело, и я начал спрашивать в ответ: «А зачем мне это знать?» Эффект оказался неожиданным: часто интервьюеры не могли дать внятного ответа. Либо начиналось бормотание, либо появлялись общие фразы вроде «ну это каждый уважающий себя программист должен знать».

Позже я развернул вопрос на себя. Заметил, что читаю книги и статьи, прохожу курсы, но не всегда понимаю, зачем это делаю.

Первым делом начал пропускать части курсов, которые уже знал или не считал нужным изучать. Потом увидел, сколько необязательной воды встречается в статьях и книгах. А затем перед любым материалом стал спрашивать себя: «Что я хочу узнать?»

После этого многие потенциально интересные материалы начали отваливаться ещё до чтения. По оглавлению книги или описанию курса я понимал, что ответа на мой вопрос внутри нет. Так я сэкономил кучу сил и времени, а учиться стало интереснее.

Читать книгу необязательно по порядку

Перед чтением я коротко отвечаю себе на три вопроса:

Что я хочу узнать?
Зачем мне это?
В каких главах или разделах могут лежать ответы?

Затем начинаю не с первой страницы, а с интересующей главы. Если для неё не хватает контекста, возвращаюсь назад и нахожу нужный фрагмент. Потом могу перескочить ближе к концу или снова в начало.

Я отношусь к книге примерно как к документации библиотеки: не читаю от корки до корки, а ищу ответ на конкретный вопрос. Точно так же можно работать со статьями, докладами, подкастами и исследованиями.

Главное препятствие — страх пропустить важное. Я десятилетиями привыкал читать каждое слово, поэтому не жду, что новый паттерн закрепится за пару подходов. До сих пор иногда возвращаюсь к старой модели.

Мне помог другой вопрос: что именно я называю важным и что случится, если это пропустить? Ключевую мысль современной книги часто можно понять по аннотации и содержанию. Деталь, к которой я пока не готов, всё равно может не зацепиться за опыт, даже если прочитать её трижды.

Это не гарантия, что ничего ценного не потеряется. Это осознанный обмен: я принимаю риск пропустить часть материала, чтобы не тратить ограниченное внимание на всё подряд.

Хочешь научиться — пиши

В последнее время я наблюдаю возрождение тренда на конспектирование умных книг. По моему опыту, конспект часто превращается в перенос слов автора в тетрадь читателя, минуя его мозги.

Когда я начал писать собственные заметки, то обнаружил, что гораздо лучше понимаю и запоминаю идеи. Подтверждение этой мысли нашёл в книге Сергея Поварнина «Как читать книги»: мысль автора нужно переварить и усвоить, сделав своей.

Поэтому мои заметки редко состоят из сухой теории. Обычно это смесь идеи, личного опыта и собственного мнения. Я пытаюсь понять, что мысль значит именно для меня и какое место может занять в моей жизни.

Если я выделил какой-то отрывок, значит, он чем-то зацепил: натолкнул на размышление, вызвал воспоминание или просто развеселил. Ответ на вопрос «Зачем я это выделил?» часто оказывается ценнее самого отрывка.

Письмо заставляет критически рассмотреть идею со всех сторон. В процессе вскрываются слабые места, недопонимание и недосказанность, которые подталкивают к дальнейшему исследованию. Так информация перестаёт быть чужим текстом и становится предметом собственного мышления.

То же относится к чужому опыту. Слепое копирование поведения опасно: действия человека выросли из его знаний, навыков, ограничений и логики принятия решений. Если выдернуть практику из этого контекста, можно получить бессмысленный ритуал.

Чтобы учиться на чужом опыте осознанно, я пытаюсь восстановить всю цепочку:

какая перед человеком стояла задача;
какие действия он предпринял;
какие гипотезы лежали в их основе;
что подтвердилось, а что нет;
к каким выводам человек пришёл.

Обычно для этого достаточно поговорить с автором опыта и помучить его вопросами «как?» и «почему?». Низкорисковые типовые практики можно скопировать и докрутить по ходу дела. Чем выше цена ошибки, тем важнее сначала разобраться в контексте.

Читать легко, а думать — больно

Само чтение — довольно простой процесс. Иногда у автора тяжёлый слог или в тексте много терминов, но суть не меняется. Гораздо сложнее понять, зачем я читаю эту книгу и что собираюсь сделать с прочитанным.

«Читать быстрее» подкупает простотой и измеримостью. Можно сказать: «Я прочёл X книг за год». А какой линейкой измерять качество чтения?

Размышление противоречит задаче читать больше. Оно тратит время и силы, может вызвать головную боль и вообще не получиться. Куда проще вернуться к старой модели и проглотить ещё пяток книг.

Но именно размышление даёт альтернативные варианты поведения. Когда я оцениваю значимость идеи и вспоминаю ситуации, где она могла бы пригодиться, в голове появляются крючки. В похожей ситуации в будущем я могу вспомнить заметку и попробовать другую модель действий.

Так заметка превращается в часть цикла обучения: идея создаёт возможное поведение, применение даёт новый опыт, а опыт приносит новое понимание и следующую заметку. В этой парадигме количество прочитанных книг почти ничего не значит. Важны идеи, которые я обдумал и которым нашёл применение.

Сколько книг по боксу нужно прочитать, чтобы побить Майка Тайсона?

Даже качественно переработанная идея может оказаться ошибочной. Знание — ещё не навык.

Можно прочитать книгу по боксу и очень подробно представить, как выигрываешь соревнования. Но это не приблизит к реальному месту на пьедестале. Аналогичные рассуждения при желании легко провести с Камасутрой.

Люди, которые приравнивают концептуальное знание к умению, могут быть опасны для себя и окружающих. Они знают, как всё «правильно» организовать, но уклоняются от вопроса: «А ты это пробовал?» В мягкой форме я многократно наблюдал такое у различных agile-коучей: теория стройная, но реальность раз за разом ломает гениальные идеи.

Есть только один способ проверки: применить идею в деле и посмотреть, выдерживает ли она столкновение с окружающим миром. Для теоретика крушение прекрасной модели болезненно. Для практика проверка — самая интересная часть: можно найти слабые места, доработать идею или отбросить её и пойти исследовать дальше.

Именно изменение действий я считаю лучшим признаком того, что обучение сработало. Синтетический тест может проверить знания, но не показывает, начал ли я что-то делать иначе.

С физическими навыками это видно сразу. С абстрактными сложнее, но принцип тот же. Знать список когнитивных искажений — прикольная эрудиция. Поймать искажение в собственном решении — уже навык. Философская идея тоже проявляется через изменение образа мышления, мотивации или действия.

Как спроектировать тест идеи

С понятными идеями работать легко: сделай А, затем Б и посмотри на результат. Например, книга по продуктивности предлагает записывать все дела, чтобы не перегружать рабочую память. Начинаем записывать и наблюдаем.

Но большинство идей не имеют простой прикладной формы. Возьмём более абстрактную: «Регулярная похвала поддерживает моральный дух и мотивацию команды». Сколько раз хвалить? Как долго? Как понять, что моральный дух действительно изменился?

Когда я хочу протестировать идею, задаю себе два вопроса:

Где и в каком контексте я могу её применить?
Какие у меня ожидания от применения?

Я не считаю идею проработанной, пока не понимаю, куда её можно приткнуть. А если не знаю ответа — зачем она мне сейчас?

Многие идеи разваливаются уже при проектировании теста. Полноценно проверять каждую долго и дорого, поэтому предварительным испытанием для меня стала обратная связь.

Пока я работаю с идеей в одиночку, она существует в ограниченном контексте. Другой человек может увидеть несостыковки и границы применимости. Но для такого разговора нужен собеседник, чьему мнению я доверяю и который не боится, как говорит мой руководитель, «накидать мне хуёв в панамку». Иначе обратная связь превратится в поглаживание идеи.

Как довести идею до практики

После обработки заметок я снова просматриваю их с одним вопросом:

Где и как я могу применить эту идею в своей жизни?

Если фрагмент вызывает мысль «хочу попробовать», я создаю короткую заметку о практике. Обычно в ней пять частей:

Суть идеи. Основная мысль и её значение для меня в одном-двух абзацах.
Что буду делать. Конкретные действия и условия их применения.
Источник. Место, куда можно вернуться за контекстом.
Срок наблюдений. Без дедлайна идеи легко зависают.
Связанные идеи. Необязательный раздел, который помогает собрать практики в систему.

Описание занимает три-пять минут. Самая сложная часть — придумать наблюдаемое действие.

В том же файле я веду журнал рефлексии и пишу только тогда, когда есть что зафиксировать: получилось, пошло через одно место, забыл применить или понял что-то новое.

После дедлайна закрываю практику. Если идея не прижилась, разбираю причину. Если опыта достаточно, оцениваю полученную ценность и решаю, стоит ли развивать практику дальше. Новые вопросы снова отправляют меня к поиску материалов — так цикл замыкается.

Сколько теории достаточно

Из предыдущих рассуждений легко сделать вывод, будто я анти-теоретик и предлагаю меньше читать, а больше экспериментировать. Это другая крайность.

Теория без практики мертва, практика без теории слепа. Джун, который учится только на собственном опыте, в лучшем случае будет долго изобретать велосипеды. В худшем — наговнокодит так, что проще всё переписать. С электриком последствия недостатка теории могут оказаться ещё заметнее.

Универсальной пропорции теории и практики я не нашёл. Опытным путём пришёл к принципу: знать нужно достаточно, чтобы начать действовать.

Я могу отложить книгу прямо во время чтения и сделать что-то с уже полученной информацией: изменить календарь, написать сообщение или попытаться объяснить жене очередную гениальную мысль. Не коплю максимум информации, а начинаю работать с ней.

При этом стараюсь делать эксперименты простыми, небольшими и короткими. Их задача не доказать непоколебимость идеи, а получить первую обратную связь от мира и продолжить обучение.

Зачем так заморачиваться

Всё перечисленное — лишь инструменты. Они делают свою работу в умелых руках. Но зачем эти руки за них взялись, каждому придётся решить самостоятельно.

Мой собственный ответ менялся. Сначала я просто хотел лучше понимать прочитанное. Затем — рассуждать об идеях и применять знания в жизни. Потом формулировка стала другой: получать ответы на свои вопросы и менять жизнь через чужой опыт.

Но в одном я уверен: мне важно получать радость от процесса. Мне нравится писать посты и заметки, наблюдать, как мысли превращаются в текст. Нравится анализировать и рассуждать.

Думать интересно, но ещё интереснее принести идею в реальный мир и подумать её вместе с другими людьми. Так у меня появились канал, статьи и доклады. Каждый пост и каждый доклад — идея, которой мне хотелось поделиться.

Готового ответа на вопрос «Зачем заниматься самообразованием?» у меня нет. Мой ответ продолжит меняться вместе с целями. Но без собственного ответа обучение легко превращается в бесконечное потребление контента без смысловой нагрузки.

Как я обрабатываю прочитанное

После чтения у меня остаётся файл с выделенными фрагментами. Я даю им заголовки, в которых своими словами формулирую суть. Заадно проверяю идею:

чем обосновано утверждение автора;
есть ли в нём логика;
каковы границы применения;
что идея меняет в моей жизни;
где и как я могу её применить.

На этом этапе чужой текст либо рассыпается, либо превращается в мою мысль, которой можно найти место в жизни.

Как найти на это время

Я не жду свободных двух часов. Разбиваю работу на маленькие законченные пакеты, которые помещаются в 5-15 минут: прочитать несколько страниц, озаглавить пару фрагментов, набросать заметку или подправить черновик.

Когда появляется полчаса или больше, я уже не трачу его на механическую подготовку. Могу сразу перейти к углублённой работе с уже подготовленными заметками.

Три режима чтения

Не каждую книгу я открываю ради одной и той же цели. Для себя я выделяю три режима.

Проблемно-ориентированное чтение. У меня есть конкретная задача, и я ищу в материале ответы. Например, хочу лучше писать на Go и выбираю книгу под свои вопросы.
Интеллектуальное фланирование. Читаю без чёткого запроса, чтобы встретить неожиданные идеи и расширить насмотренность.
Чтение ради удовольствия. Беру тёмное фэнтези, завариваю чай и ни во что прочитанное не собираюсь превращать.

Ни один режим не лучше остальных: у них разные задачи. Проблемы начинаются, когда я называю самообразованием чтение без цели, а затем жду от него прикладного результата.

Перед новой книгой я спрашиваю себя, что хочу получить на выходе. Ответ определяет и выбор материала, и глубину работы с ним.

Скимминг как предварительный фильтр

Нон-фикшн редко приходится читать одинаково внимательно от первой до последней строки. Чтобы понять структуру и найти значимые места, я использую скимминг.

Сначала читаю начало и конец абзаца или раздела. По ним решаю, нужно ли возвращаться и разбирать середину. Иногда двух предложений хватает, иногда приходится читать весь фрагмент.

Это не скорочтение. Я не пытаюсь быстрее двигать глазами, а постоянно принимаю решение о ценности следующего куска текста. Поэтому скимминг требует внимания и на усталости работает хуже.

Во время такого просмотра я отмечаю мысли, которые:

можно применить на практике;
хочется обдумать;
вызвали заметную эмоциональную реакцию.

Задача скимминга не в том, чтобы любой ценой прочитать меньше. Он помогает решить, куда стоит вложить глубокое внимание.

«Пять пороков команды», Патрик Ленсиони

Fri, 16 May 2025 00:00:00 GMT

Некоторые книги стоит перечитывать раз в несколько лет. К таким я отношу, например, все труды Нассима Талеба. Но не все книги обязаны быть настолько же сложными, чтобы приносить пользу.

Первый раз «5 пороков команды» я читал где-то пять лет назад. Я тогда уже больше года управлял своей первой командой и в целом неплохо справлялся. Книга мне понравилась, но не зажгла, оставив послевкусие типа: «С тезисами согласен, звучит хорошо».

Но недавно, на обучении для руководителей, я вновь коснулся модели Ленсиони. И на этот раз она показалась мне гораздо более глубокой, чем на первый взгляд. Поэтому я взял первоисточник и приступил к чтению.

О чём книга

Книга посвящена пяти основным порокам, которые мешают группе людей стать командой. К ним относятся: взаимное недоверие, уход от конфликта, безответственность, нетребовательность и безразличие к результату. Также в книге показано, как эти пороки мешают команде работать эффективно.

В книге раскрываются следующие темы:

Как каждый из пороков негативно влияет на команду?
Как исправлять эти пороки?
Какие упражнения могут сблизить и сплотить команду?

3 идеи из книги

Члены команды должны рассматривать коллективные результаты как счёт в футбольном матче. В хорошей команде выигрывают или проигрывают все одновременно. Если в команде возможны ситуации, где кто-то выигрывает, а другие нет, то это не команда, а группа.
Не соглашайся, но выполняй. Иногда обсуждения проблем и попытки прийти к единому мнению могут парализовать работу команды. В таких случаях самая эффективная стратегия — не согласиться с решением, но подчиниться ему, будто согласен. Решения команды должны быть выше конкретного человека.
Ссора и спор — это две разные вещи. Спор (конструктивный) является нормальной частью работы и направлен на то, чтобы улучшить конечный результат команды. Ссора же — это конфликт, который вредит доверию и командному духу, никак не помогая двигаться к цели.

Мои впечатления

В этот раз книга Ленсиони произвела на меня гораздо большее впечатление. Я думаю, что сказывается прожитый опыт — многие ситуации, которые автор описывает в книге, были мне уже знакомы (местами прямо флешбеки возникали).

Модель Ленсиони неидеальна, как и любая другая модель. Но это не лишает её полезности. Особенно мне понравилось рассматривать, как пороки взаимосвязаны и один порождает другой. Например, из недоверия вытекает безответственность и нетребовательность, которые, в свою очередь, порождают уход от конфликта и безразличие к результату.

Конечно, связи там чуть сложнее, но ключевая мысль — любой порок команды создаёт усиливающую петлю обратной связи для других пороков. Фактически, можно получить каскадный эффект: возникновение одного порока создаёт второй, который создаёт третий, который…

Я бы рекомендовал прочитать эту книгу тимлидам, у которых уже есть некоторый опыт. Новичкам она вряд ли будет полезна — идеи могут показаться классными, но слишком уж абстрактными. Лично я понял эту книгу гораздо лучше, когда набрался всякого-разного (не всегда приятного) опыта.

«Поток. Психология оптимального переживания», Михай Чиксентмихайи

Sat, 10 May 2025 00:00:00 GMT

Одной из точек пересечения книги «Драйв» и «Почему они не работают?» является концепция потока. Обе книги характеризуют поток как одно из наиболее продуктивных и высокомотивированных состояний.

Конечно же, мне стало интересно разобраться в потоке из первоисточника, потому что пересказы Пинка и Фаулер довольно скудные и вряд ли отображали картину целиком. Поэтому я решил завершить своё небольшое исследование темы мотивации книгой Михая Чиксентмихайи “Поток”.

О чём книга

Книга полностью посвящена состоянию потока. Однако при этом Чиксентмихайи раскрывает тему довольно широко, рассматривая в том числе роль потока и психической саморегуляции в современном мире.

В книге раскрываются следующие темы:

Как жить более качественно и счастливо?
Как взаимосвязь личности и внимания влияет на человека?
Что такое состояние потока и как в нём оказаться?
Чем полезно состояние потока для психики?
Как получать удовольствие от всего, что делаешь?

Три идеи из книги

Человек может сделать себя счастливым или несчастным вне зависимости от того, что происходит в окружающем мире. Всё зависит от восприятия происходящих событий, направленности внимания и развитости внутренней саморегуляции.
Качество жизни можно улучшить с помощью двух стратегий: подстраивая внешние обстоятельства под свои цели и подстраивая свои цели под внешние обстоятельства. Эффективнее всего будет использовать обе в разных пропорциях.
Настоящее удовольствие мы получаем от деятельности, которая требует от нас вложений сил и концентрации внимания. При этом деятельность должна быть достаточно сложной, чтобы пришлось напрягаться, но преодолимой. Тогда мы полностью вовлекаемся в этой деятельности и погружаемся в неё с головой, входя в состояние потока.

Мои впечатления

Чиксентмихайи писал в то время, когда книги больше 200 страниц считались чем-то естественным. Поэтому не постеснялся и написал очень обстоятельный труд о счастье, состоянии потока и роли сосредоточенного труда во всём этом.

Книга – трудная. Сама концепция потока достаточно проста, понятна и узнаваема. Но Чиксентмихайи пошёл гораздо дальше темы “как получать удовольствие от работы”. Они поднимает такие важные темы, как счастье, получение удовольствия от жизни в целом и своей деятельности в частности, развитие личности через труд и многое другое.

“Поток” содержит много мудрых мыслей. Настолько много, что я до сих пор не успел до конца разгрести все заметки, собранные в процессе чтения. Но эта книга, на мой взгляд, стоит потраченных усилий. Она помогает увидеть смысл и радость в своей повседневной деятельности, а это положительно сказывается на личной мотивации.

«Драйв. Что на самом деле нас мотивирует», Дэниел Пинк

Fri, 02 May 2025 00:00:00 GMT

Тема мотивации меня внезапно увлекла. Книга Сьюзен Фаулер «Почему они не работают?», о которой я писал на прошлой неделе, лишь раззадорила мой интерес. Мотивация стала понятнее, но вопросы ещё оставались (и много), поэтому я продолжил копать.

Книгу Дэниела Пинка «Драйв» я уже читал несколько лет назад. Тогда она мне показалась не очень примечательной – много воды, много “волшебных таблеток”, крайне много отсылок к Канеману и Чиксентмихайи. Однако я победил свой скепсис, напомнив себе о том, что теперь у меня есть новые навыки исследования, и принялся за чтение.

О чём книга

Книга посвящена двум основным темам. Первая – несостоятельность метода “кнута и пряника” (автор называет его Мотивация 2.0) в современных реалиях. Вторая тема – Мотивация 3.0 (термин, который придумал сам автор), в рамках которой рассказываются факторы мотивации современного человека.

В книге раскрываются следующие темы:

Как появился метод кнута и пряника?
Почему метод кнута и пряника не работает в современном мире?
К чему приводит неуместное применение кнута и пряника?
Что такое внутренняя и внешняя мотивация?
Какие факторы способствуют укреплению и поддержанию внутренней мотивации?

Три идеи из книги

Зарплата является не мотивирующим, а базовым фактором. Люди должны зарабатывать себе на жизнь, и достойная, справедливая оплата их труда является основой для развития мотивации, а не самой мотивацией.
Чем сильнее стимул, тем хуже может оказаться конечный результат по причине сверхзацикленности. Человек настолько сильно увлекается вознаграждением, что перестаёт думать о качестве своей работы и конечном результате, всеми силами стремясь получить награду.
Возможность выбора задач — важный компонент внутренней мотивации. Люди ценят свободу, поэтому возможность выбирать, чем именно заняться на работе, может мотивировать лучше денег и похвал.

Мои впечатления

Прочитав книгу Пинка, я полез гуглить год издания и обнаружил, что «Почему они не работают?» Сьюзен Фаулер вышла на 7 лет позже. Фаулер многое позаимствовала из книги Пинка, в том числе взяла его “Мотивацию 3.0” и немного докрутила под себя.

Конечно, читать «Драйв» после «Почему они не работают?» — так себе идея. Сейчас я понимаю, что стоило делать это в обратном порядке. Пинк сформулировал отличную, стройную теорию новой мотивации, а Фаулер хорошо расширила и дополнила её мотивационными состояниями и факторами саморегуляции.

Я по-прежнему вижу, что Пинк многое взял из других книг. Но сделано это уместно и гармонично вписывается в общую структуру его идей. Однако раздел про мотивирование сотрудников мне показался откровенно слабым. Возможно, это связано с тем, что сам Пинк толком никогда никем не руководил (что, впрочем, не умаляет ценности его идей).

В общем, для прокачки своего уровня работы с мотивацией рекомендую прочитать «Драйв» для понимания Мотивации 3.0 и дополнить его «Почему они не работают» – для понимания мотивационных состояний, техник саморегуляции и способов применения этих новых подходов к мотивации.

А книги по мотивации у нас ещё не закончились — оставайтесь на связи.

Про онбординг с Двумя Иванами

Sun, 27 Apr 2025 00:00:00 GMT

Разговор об онбординге: зачем он нужен, за что отвечает тимлид и как помочь новичку начать работу без плавания с привязанным к ноге камнем.

О чём разговор

Какую роль в онбординге играет тимлид.
Как парное программирование помогает новичкам.
Почему оффбординг тоже важен.
Можно ли быть играющим тренером в большой команде.

После записи я успел обкатать одну из идей: парное программирование помогло при погружении в новый проект.

Что я считаю минимумом на старте

Когда-то я потратил две недели на попытки развернуть проект локально. Потом девопс сказал, что на моём M1 он просто не запустится. Меня оставили разбираться одного, и мы все за это заплатили.

На старте я делаю три вещи:

Объясняю, что вопросы нормальны и помогают быстрее погрузиться. Заадно они показывают, где сам онбординг нужно улучшить.
Говорю, к кому идти за ответами. В идеале назначаю бадди.
Обозначаю ожидания на первое время и ставлю регулярные встречи для обмена обратной связью.

Главное - не оставлять новичка в гордом одиночестве разбираться со всеми проблемами.

«Почему они не работают? Новый взгляд на мотивацию сотрудников», Сьюзен Фаулер

Fri, 25 Apr 2025 00:00:00 GMT

Благодаря усилиям различных горе-предпринимателей и горе-руководителей термин “мотивация” стал почти таким же ругательным, как “целеполагание”. Но при этом тема человеческой мотивации невероятно глубока и интересна.

Я всегда задавался вопросом: что нами движет? Как мы создаём и обретаем смыслы своей деятельности? На разных этапах жизни я получал разные ответы, и сейчас настало время очередного витка моих попыток понять, как человеки (в частности – я сам) мотивируются помимо кнута и пряника.

Моё путешествие длиной в три книги началось с “Почему они не работают?” за авторством Сьюзен Фаулер. Так уж вышло, что на работе я сейчас прохожу глубокое обучение для руководителей, и тема мотивации заинтересовала меня особенно сильно.

О чём книга

Я думал, что книга посвящена мотивации сотрудников, но это оказалось так лишь отчасти. Львиная доля книги посвящена модели человеческой мотивации и разнице мотивационных статусов. Основной посыл книги заключается в том, что руководитель должен научиться работать со своей мотивацией, прежде чем лезть к подчинённым. “Познай самого себя” в действии.

В книге раскрываются следующие темы:

Почему метод кнута и пряника не работает?
Какие у нас есть мотивационные статусы и чем они отличаются?
Какие компоненты должны быть обязательно для обеспечения оптимальной мотивации?
Как связаны психологическая саморегуляция и мотивация человека?
Как помогать подчинённым находиться на оптимальных уровнях мотивации?

3 идеи из книги

Люди мотивированы всегда, вопрос только в качестве этой мотивации. Один человек гонится за внешними регалиями или бежит от чего-то, а другой делает работу, которая совпадает с его ценностями. С виду они будут делать одно и то же, но разница в состоянии колоссальная.
Традиционные методы кнута и пряника улучшают краткосрочные результаты, но ухудшают долгосрочные. Исследования показали, что при появлении внешних стимулов люди прикладывают дополнительные усилия, но затем идёт спад. А ещё те же исследования показали падение креативности, появление зашоренности взгляда и сильнейшую демотивацию, если желаемого достичь не удалось.
Три главных компонента мотивации – автономия, принадлежность, компетентность. Людям важно самим принимать решения и чувствовать доверие, делать нечто большее, чем они сами и успешно справляться с рабочими задачами. При этом отсутствие любого из компонентов вызывает эффект домино и рушит всё остальное.

Мои впечатления

Книга просто великолепна. Это вам не Тони Роббинс со своими призывами “ты можешь всё”. Это скорее Джордж Карлин, которые утверждал, что с мотивацией у вас всё нормально, раз вам хватило её на то, чтобы дойти до книжного магазина и купить книгу по мотивации.

Фаулер даёт несколько классных посылов. Первый заключается в том, что люди мотивированы всегда, вопрос только чем и как. Из этого посыла вытекает понимание, что кнут и пряник могут вообще не сработать или сработать в обратную сторону, поэтому копать нужно глубже.

Второй посыл заключается в том, что менеджеры не умеют работать с мотивацией сотрудников, потому что не понимают её природу и не умеют работать со своей личной мотивацией. И это замечание абсолютно справедливо, потому что работа с мотивацией фактически сводится к набору навыков. Если менеджер не отработал эти навыки на себе и не прожил этот опыт, то как он может применить их к другим людям? Правильно, никак.

В книге ещё целое море интересных мыслей – компоненты мотивации, роль и применение саморегуляции для смены мотивационных статусов, проведение мотивационных бесед и так далее. Поста не хватит, чтобы всё описать, но скоро вас ждёт серия моих размышлений на тему мотивации.

Книгу считаю строго обязательной для тимлидов, но всем остальным тоже рекомендую – здорово помогает пересмотреть свои взгляды на работу.

«Хорошая стратегия, плохая стратегия», Ричард Румельт

Fri, 18 Apr 2025 00:00:00 GMT

Стратегия всегда была мне интересна. Особенно если учесть, что сейчас под этим словом понимают всё что угодно, кроме самой стратегии.

В какой-то момент мне надоело встречать «стратегию» в самых странных контекстах, и я решил разобраться в теме. Для этого взял книгу Ричарда Румельта «Хорошая стратегия, плохая стратегия». Цель была конкретной: понять, что вообще можно считать стратегией и чем хорошая отличается от плохой.

Книга оказалась непростой, но задачу выполнила. Слово «стратегия» стало для меня гораздо понятнее, а вокруг внезапно обнаружилось много плохих, просто отвратительных стратегий. Хотя большинство из них вообще не стратегии, а абстрактные хотелки и художественный вымысел.

О чём книга

Румельт разбирает стратегию в бизнесе: даёт ей определение, раскладывает на составляющие и показывает, как вырабатывать и применять её для развития компании.

Книга отвечает на четыре основных вопроса:

что такое стратегия и из чего она состоит;
как распознать плохую стратегию;
откуда хорошая стратегия берёт силу;
как развивать и применять стратегическое мышление.

Три идеи, которые я забрал

Плохая стратегия хуже, чем отсутствие хорошей. Стратегия фокусирует силы и внимание. Если направление выбрано неверно, организация не просто стоит на месте, а сосредоточенно движется не туда.
Плохая стратегия часто прячется за шумом. Пустые цифры, красивые графики, громкие лозунги и прочий словесный мусор создают видимость серьёзной работы. Хорошая стратегия устроена проще: в ней есть конкретная ключевая проблема и понятный способ с ней работать.
В основе хорошей стратегии лежит диагноз. Сначала нужно понять корень проблемы, а уже потом фокусировать ресурсы на конкретных тактических целях. Без диагноза хорошую стратегию не построить. Эта же мысль хорошо показана в книге Голдратта «Цель-2».

Мои впечатления

«Хорошая стратегия, плохая стратегия» даёт понятные признаки плохой стратегии и на хороших примерах показывает, что происходит, когда организация фокусируется не на том. Я вытащил из книги много идей, которые продолжаю обдумывать до сих пор.

А ещё Румельт хорошо показывает, почему лидеру мало быть харизматичной «говорящей головой». В сложные времена на одном красноречии выехать вряд ли получится: нужно увидеть ключевую проблему и направить ограниченные ресурсы на её решение.

Книгу настоятельно рекомендую тем, кто хочет разобраться в стратегии, а не просто использовать это слово в презентациях.

Как защищаться от неконструктивной обратной связи

Wed, 16 Apr 2025 00:00:00 GMT

Проблема неконструктивной обратной связи в том, что её редко дают конструктивно. Обычно её впихивают в человека насильно — вне зависимости от его желания и готовности воспринимать.

Нет единственно правильной модели поведения в такой ситуации. Кому-то комфортно вступать в жёсткую конфронтацию, а для другого это смерти подобно. Мне пришлось искать собственный способ.

Сначала вернуть себе выбор

Когда эмоции берут верх, я перестаю действовать осознанно и начинаю реагировать. Поэтому стараюсь заметить страх, гнев или обиду и либо взять паузу, либо выйти из конфликта.

Это не значит, что получатель обратной связи обязан сохранять ледяное спокойствие, пока на него нападают. Пауза нужна не для удобства нападающего, а чтобы вернуть себе выбор дальнейшей реакции.

Работу с эмоциями полезно развивать отдельно. Мне в этом помогли книги «Эмоциональный интеллект» Дэниела Гоулмана и «Ненасильственное общение» Маршалла Розенберга.

Логика плюс эмпатия

Раньше в конфликте я превращался в разгневанную фурию по щелчку пальцев. Атака означала одно: противника нужно стереть с лица земли.

Такой подход неоднократно защищал меня в подростковом возрасте, но в профессиональной деятельности начал мешать. Сначала я заменил агрессию логикой. При следующей попытке руководителя «дать обратную связь» разбил её в пух и прах, показав бесполезность и непроработанность.

Формально я защитился, но осталось ощущение, что в методе не хватает элемента. Им оказалась эмпатия. Руководитель не хотел мне навредить. Он считал, что помогает, просто я был с этим не согласен.

Когда я добавил попытку понять цель другого человека, неконструктивная обратная связь разделилась для меня на разные случаи:

человек хочет помочь, но не умеет — тогда можно объяснить свой взгляд и указать на ошибки;
человек критикует из-за собственных страхов — тогда разговор полезнее развернуть к его мотивации;
человек продолжает нападать — тогда можно поставить границу и закончить разговор.

Не принимать чужое мнение автоматически

Когда ни логика, ни эмпатия не помогают, мне помогает простая стоическая мысль: слова становятся оскорблением, когда я сам принимаю их в этом качестве.

Сказанное другим человеком остаётся его частным мнением. Я могу рассмотреть полезную часть, могу не согласиться и вправе в любой момент выйти из коммуникации.

Такой подход не делает плохую обратную связь хорошей. Он помогает не отдавать собеседнику управление моей реакцией.

Проверить содержание обратной связи

Даже после спокойного разговора чужое мнение не обязано становиться моим. Я проверяю его по нескольким признакам:

есть ли конкретные наблюдения и факты;
понимает ли человек контекст деятельности, которую оценивает;
относится ли критика к действиям, а не к личности;
пытается ли собеседник помочь разобраться или просто хочет ужалить.

Готовое решение от автора обратной связи не обязательно. Иногда честного «это вызывает у меня такую реакцию, но я не знаю, как исправить» вполне достаточно для полезного разговора.

Кейс: «Твоя команда плохо работает»

Однажды руководитель начал наш 1–1 со слов: «Твоя команда плохо работает». При этом не было ни конкретных примеров, ни критериев «плохо», ни понимания, что с этим делать.

Мы были в хороших отношениях, поэтому вместо конфликта я начал задавать уточняющие вопросы:

откуда взялась эта обратная связь и кто её автор;
по каким наблюдениям был сделан вывод;
как руководитель проверил его перед разговором со мной.

Выяснилось, что так сказал один из коллег моего руководителя. Сам руководитель не знал, на чём основан вывод, и не проверил его. Когда я показал метрики команды, он просто развёл руками.

Эта ситуация показала мне цену посредничества в некачественной обратной связи. Руководитель не просто передал неконструктивную критику. Он не попытался разобраться в деталях и защитить меня и команду от бездоказательного обвинения. Так вместе с этой обратной связью он выбросил заметную часть моего доверия к нему.

В тот раз я взял на себя работу по формированию чужой обратной связи и понял, что в ней нет оснований. Но получатель не обязан всегда делать эту работу. Если автор не может описать факты и желаемое изменение, его мнение можно не принимать.

«Цель-2. Дело не в везении», Элияху Голдратт

Fri, 11 Apr 2025 00:00:00 GMT

Книгу Голдратта «Цель» я читал как минимум трижды:

Первый раз — ещё будучи разработчиком. Тогда она мне показалась просто интересной.
Второй раз — когда я где-то год провёл в тимлидах. Тогда она показала мне дырки в моём понимании построения рабочего процесса.
Третий раз — недавно. Я просто убедился, что эта книга всё-таки шедевр.

И тем не менее, я много лет игнорировал прямое продолжение (а ведь есть ещё и третья часть). Недавно я понял, что пришло время двигаться дальше — и таки взялся за неё. Я подошёл к чтению без ожиданий: мне просто интересны дальнейшие приключения Алекса Рого.

О чём книга

«Цель-2» также написана в жанре бизнес-романа. Алекс Рого, герой первой части, получил повышение и управляет несколькими бизнесами, находящимися в крайне плачевном положении. Он узнаёт, что бизнес решает продать его группу компаний, чтобы улучшить свой кредитный рейтинг, и начинает выкручиваться…

В книге раскрываются следующие темы:

Что такое «мыслительные инструменты» Голдратта?
Как подходить к решению конфликтов, которые на первый взгляд неразрешимы?
Как Алекс Рого выкрутился из этой непростой ситуации?

3 идеи из книги

Не пытайся избежать конфликта путём компромисса. Голдратт утверждает, что любой конфликт имеет решение, которое устроит обе стороны и устранит изначальную причину конфликта. Компромисс — это просто способ оставить обе стороны неудовлетворёнными.
Начинать размышления стоит с установления причинно-следственных связей. Вокруг может происходить много всего, поэтому тщательный анализ происходящего будет лучшей отправной точкой — так можно увидеть, например, что многие явления вызваны одной небольшой проблемой.
Для достижения амбициозной цели нужно начать с перечисления препятствий. Это контринтуитивно, но все действия, направленные на достижение цели, обычно нужны именно для преодоления каких-то препятствий. Выявив препятствия, будет гораздо проще выделить необходимые для их преодоления действия.

Мои впечатления

Книгу я прочитал запоем.

Во-первых, она просто интересная. Голдратт умудрился феноменально красиво запихнуть обучающие материалы в увлекательную историю. Побольше бы такой литературы.

Во-вторых, мне было действительно интересно посмотреть на практические примеры применения «мыслительных инструментов» ToC. Конечно, книга является художественным вымыслом, но Голдратт приводит довольно значительные и ощутимые проблемы, которые не вызывают ощущения надуманности.

Начинающему тимлиду вся эта обвязка, скорее всего, не пригодится. Опыт решения сложных, конфликтных ситуаций — лучший друг при чтении этой книги. Я утащил себе несколько идей по применению инструментов и жгучее желание изучить их поподробнее — уж больно перспективными они мне кажутся.

Однозначно рекомендую!

«Будда, мозг и нейрофизиология счастья», Йонге Мингьюр Ринпоче

Fri, 04 Apr 2025 00:00:00 GMT

С медитацией у меня сложные отношения — целая Санта-Барбара. То мы вместе и счастливы, то расстаёмся в слезах, то я изменяю ей с приставкой. Но тема всегда меня интересовала.

В одном обучении по личной энергии я встретил такую идею: возьмите любой инструмент отдыха и станьте в нём экспертом. После этого я снова вернулся к медитации и понял, что собрал в голове кучу мифов. Я решил хорошенько разобраться в этом вопросе, поэтому в качестве учителя выбрал тибетского ламу, который на этой теме собаку съел (в переносном смысле, конечно).

О чём книга

Книга посвящена различным видам медитации в буддийской традиции. Она подробно объясняет, что такое медитация, зачем она нужна и как её практиковать. Всё это дополнено личным опытом автора и результатами научных исследований о влиянии медитации на психику человека. Попутно немного затрагиваются некоторые аспекты буддизма.

В книге раскрываются следующие темы:

Почему мы не чувствуем себя счастливыми.
Как наши внутренние переживания и отношение к миру искажают восприятие реальности.
Что такое медитация и как её правильно практиковать.
Этапы (уровни) медитативной практики.

Три идеи из книги

Мы вполне можем изменить свой ум и его поведение. Это базовая идея, которую нужно принять, чтобы медитация «заработала». Сама по себе медитация — всего лишь практика наблюдения и размышления. И только вера в возможность перемен делает её инструментом внутренней трансформации.
Для медитации нужно отказаться от всех ожиданий. На самом деле, все качества, необходимые для практики, — гибкость ума, любопытство, раскрепощённость, покой, открытость — уже есть внутри нас. Никаких дополнительных условий не требуется.
Самый эффективный способ освоить медитацию — не долгое сидение в позе лотоса, а множество коротких подходов в течение дня. Регулярное успокоение ума даст больше пользы и сформирует позитивное отношение к практике. А вот стремление сидеть подолгу, скорее всего, приведёт к скуке и раздражению (с чем я столкнулся в прошлых попытках освоить медитацию).

Мои впечатления

«Будда, мозг и нейрофизиология счастья» — редкая книга, читать которую физически уютно и приятно. Сквозь строки ощущается огромный опыт и сострадание Ринпоче, который явно хочет помочь каждому и сделать этот мир лучше.

При этом книга прекрасно объясняет природу и смысл медитации, избавляя её от мистического флёра и множества мифов. Например, мне очень откликнулся подход коротких медитаций («успокаивать ум много раз в день»). Я попробовал его на практике — и он действительно сработал! А ведь раньше у меня в голове сидел миф (бездумно взятый у какого-то «гуру»), что первые 20 минут медитации — это просто подготовка, которая даже не считается.

В бурном, шумном, подвижном современном мире сложно найти островок спокойствия. Но эта книга научила меня, что покой доступен всегда и везде. Достаточно закрыть глаза и сделать несколько глубоких вдохов.

1-1 с Васей Мельниковым. Как перестать беспокоиться и начать делегировать

Mon, 31 Mar 2025 00:00:00 GMT

Разговор с Васей Мельниковым о делегировании: почему руководитель не масштабируется в одиночку, как ослабить контроль и где проходит граница между передачей задачи и отказом от ответственности. Вася руководит платформенной командой UI в Сбере, а до этого успел побыть предпринимателем, маркетологом и full-stack-разработчиком.

О чём разговор

Как делегирование появилось и закрепилось в практике Васи.
К чему приводит привычка руководителя тащить всё на себе.
Как справиться с желанием контролировать каждую деталь.
Как помочь людям брать на себя дополнительные задачи.
Что руководителю нельзя делегировать.

Я смотрю на эту тему с двух сторон: работал под началом микроменеджеров и сам грешил микроменеджментом в начале пути тимлида. Поэтому в разговоре есть не только принципы, но и ошибки, через которые мы учились делегировать.

«Препятствие как путь», Райан Холидей

Fri, 28 Mar 2025 00:00:00 GMT

После прочтения книги Райана Холидея «Эго — это враг» я остался очень доволен. Его стиль — типично американский: берём одну идею и рассматриваем её со всех сторон. И, несмотря на небольшие недостатки в виде воды и излишней драматизации, книга мне понравилась.

Поэтому я решил дать шанс другой книге этого автора. Выбор пал на «Препятствие как путь» (лучи добра Холидею за формулировку главной идеи книги прямо в заголовке). Мне было интересно изучить его мысли на тему того, как стоики относились (и относятся) к препятствиям на своём жизненном пути.

О чём книга

Книга пытается всесторонне ответить на вопрос: как воспринимать препятствия в жизни и как действовать в трудностях. Это чистейшая стоическая тема: не абстрактные рассуждения, а прикладная мудрость.

В книге раскрываются следующие темы:

Альтернативный взгляд на трудности и способы его выработки.
Как действовать при возникновении препятствий?
Стоическое отношение к неудачам.
Дисциплина воли и мышления.

3 идеи из книги

Препятствия становятся препятствиями только через наше восприятие. На самом деле события не бывают хорошими или плохими сами по себе — их таковыми делает наше отношение. Многие проблемы мы создаём себе сами.
Преодоление сложностей делает нас сильнее. Это называется посттравматическим ростом — переосмыслением тяжёлых ситуаций и поиском в них позитивной стороны. Трудности — не враг. Враг — восприятие, которое не даёт увидеть в них возможности.
Некоторые препятствия преодолеть невозможно, и это нормально. Отрицать это было бы безумием. В таких случаях стоит подумать, как повернуть обстоятельства себе на пользу. В любом хаосе всегда есть возможности, их просто нужно увидеть.

Мои впечатления

Книга оставила приятное впечатление. Идея рассматривать препятствия как путь к росту разобрана глубоко и с примерами. При этом текст читается легко и приятно. Идеальное чтиво для тех, кто хочет почитать «что-то из стоиков», но не готов корпеть над Марком Аврелием.

Минусы те же, что и у предыдущей книги Холидея: много воды, сгущение красок, однобокий взгляд на некоторые вещи. Это не портит впечатление, но важно не забывать подключать критическое мышление и самостоятельно осмысливать идеи.

Рекомендую как приятное дополнение к более серьёзной литературе.

Делайте невидимую работу видимой

Wed, 26 Mar 2025 00:00:00 GMT

Частенько у меня возникает ощущение, что я устал несоизмеримо объёму проделанной работы. Кажется, будто ничего толкового не сделал, а силы куда-то ушли.

Часть управленческой и интеллектуальной работы плохо оставляет следы. Разговор помог человеку принять решение. Несколько часов ушли на сбор контекста. Изученный материал изменил решение, но не превратился в отдельный артефакт. Всё это требует внимания и сил, однако в конце дня легко выглядит как «ничего не сделал».

Я долго смешивал такую работу с обычным потреблением информации и думскроллингом. Но разница важна: не вся усталость доказывает полезную работу, и не каждая полезная работа производит осязаемый результат.

Оставить след

Мне помогает делать результат видимым. Обзоры книг оставляют след от чтения. Обзоры статей и докладов — от изученных материалов. Посты — от мыслительного процесса.

Для будничной работы я использую три вопроса:

Что конкретно я только что сделал?
Почему это было важно?
Что я буду делать дальше?

Ответы не превращают любую активность в полезную работу. Зато помогают отделить сделанное от информационного шума, зафиксировать результат и не потерять следующий шаг.

Если отвечать письменно, в конце дня появляется нормальный ответ на вопрос: «А чем я вообще сегодня занимался?» Для руководителя, чья работа часто состоит из разговоров, решений и устранённых препятствий, такой журнал особенно полезен.

Журнал результатов для карьеры

Хорошо работать и ждать, когда кто-то всё заметит, ненадёжно. Люди вокруг заняты своими задачами, и их внимания на чужие успехи может не хватить.

Поэтому я записываю свои результаты в отдельную заметку, а затем смотрю, куда их можно применить:

добавить в резюме;
использовать как аргумент на пересмотре зарплаты или позиции;
превратить в пост, статью или доклад;
положить в копилку для другой цели.

Журнал помогает признать собственный результат, вернуть себе уверенность в несамый вклад и не растерять готовые доказательства своей работы.

Пу-пу-пудкаст про спорт

Mon, 24 Mar 2025 00:00:00 GMT

Разговор о том, какое место физическая активность занимает в жизни руководителя и как спортивный опыт влияет на отношение к работе, нагрузке и команде.

В разговоре участвовали Артём Арюткин, Антон Тарасов, Максим Ульянов, Женя Антонов и я. У всех оказался разный спортивный опыт: тхэквон-до, бокс, велоспорт, грепплинг, кроссфит и плавание.

О чём разговор

Какое место спорт занимает в жизни менеджера.
Чем отличается спортивный опыт участников.
Как индивидуальные виды спорта сочетаются с командной работой.

«Руководство астронавта по жизни на Земле», Кристофер Хэдфилд

Fri, 21 Mar 2025 00:00:00 GMT

Знакомство с этой книгой связано для меня с довольно любопытной историей. Её порекомендовал мне Женя Антонов (который по ночам — Тимлид Очевидность) в рамках обсуждения моей заявки на CodeFest этого года. В его рекомендации было столько искренних эмоций, что я не стал откладывать в долгий ящик и взялся за эту книгу почти сразу после разговора.

Основной задачей при чтении было исследование вопроса личной стойкости перед трудностями и влияния подготовки на преодоление жизненных испытаний. И кто же раскроет эту тему лучше, чем человек, вся жизнь которого заключается в подготовке к работе, где каждая мелочь может оказаться смертельно опасной?

О чём книга

Книга — это автобиография Криса Хэдфилда, канадского астронавта с впечатляющей карьерой. 4000 часов в космосе — это вам не шутки. Однако изюминка книги заключается в том, что автор делится своими ментальными моделями, которые помогли ему достичь таких выдающихся результатов.

В книге раскрываются следующие темы:

Процесс и принципы подготовки астронавтов.
Личные ментальные модели Хэдфилда, которые помогали ему справляться с трудностями.
Модели лидерства и руководства в команде астронавтов.
Как ходят в туалет на МКС.

Три идеи из книги

Подготовка и действия не должны зависеть от удачи или неудачи конечного результата. Нужно быть готовым к любому исходу ситуации и фокусироваться на том, что находится в вашей власти. Похожий принцип описан в книге «The Poker Mindset».
Самой опасной является та беда, к которой вы не готовы. Беда не приходит одна — всегда есть вероятность целого каскада проблем, вызванных первой (возможно, даже небольшой) проблемой.
Ранний успех — ужасный учитель. Он вознаграждает человека за недостаточную подготовку. Если позволить ему вскружить себе голову, падать может быть очень больно. Эго дуреет от такой прикормки (см. обзор на книгу «Эго — это враг»).

Мои впечатления

Книгу я прочитал взахлёб.

Во-первых, я люблю космос и всё, что с ним связано. Нет, я не мечтал быть космонавтом, но документалки про чёрные дыры и газовые гиганты смотрел, смотрю и буду смотреть.

Во-вторых, она написана в живом, лёгком и ярком стиле. У Хэдфилда отличное чувство юмора и приятная подача, поэтому его мемуары читаются легко и интересно.

В-третьих, в книге содержится кладезь ценных принципов и примеров их применения в реальной жизни астронавта. Но важнее то, что эти принципы универсальны, и применять их может любой, даже очень далёкий от космоса человек.

Книгу очень рекомендую. Вы получите примеры прекрасных ментальных моделей и просто удовольствие от чтения биографии интересного, неординарного человека. А я, в свою очередь, взял оттуда несколько идей для грядущего доклада, заявку на который успешно приняли в программу конференции. Не пропустите анонс :)

Взгляд на себя со стороны

Mon, 17 Mar 2025 00:00:00 GMT

Принимать обратную связь бывает неприятно. Наше эго стремится защитить нас от боли, которую вызывает осознание своих ошибок и заблуждений.

Однако без обратной связи мы крайне ограничены в своём восприятии. Даже на физическом уровне наш угол обзора составляет 180 градусов, и мы не можем увидеть себя со спины. А иногда это может быть критически важно.

Недавно со мной произошёл интересный случай, который заставил меня переосмыслить понятие обратной связи на новом уровне. Я тренировался с тренером и показывал ему свою технику плавания кролем. После пары недель тренировок я чувствовал, что правой рукой работаю довольно неплохо и технично, а левая как-то страдает.

После нескольких заплывов мы остановились отдохнуть, и тут тренер мне говорит: “Что-то у вас правая рука хромает. А левая хорошо получается, делайте правой как левой!”

На этом моменте я немного растерялся. То, что мне сказал тренер, кардинально отличалось от моих собственных ощущений. Мне казалось, что с правой рукой всё в порядке, и фокус внимания я сместил на левую. А оказалось, что я направлял свои силы и внимание не туда, куда нужно было.

Получается, что я упорно работал не над тем, чем нужно. Весь фокус внимания уходил туда, где всё и так было неплохо. А просаживающаяся часть недополучала внимание, и в итоге страдала вся техника.

Я бы никогда в жизни не смог понять этого самостоятельно. Такие ошибки может заметить только опытный человек со стороны. Именно для этого нам нужна обратная связь — чтобы видеть чужими глазами то, что мы сами увидеть не в состоянии.

// Поделитесь в комментариях своими историями неожиданной, но полезной обратной связи. Мне будет очень интересно пополнить своё понимание мысли из поста :)

«45 татуировок менеджера», Максим Батырев

Fri, 14 Mar 2025 00:00:00 GMT

Так уж вышло, что в основном я читаю книги по менеджменту, вышедшие из-под пера западных авторов. Культура менеджмента на Западе более развита, поэтому я стараюсь цеплять себе самые актуальные и интересные идеи.

Но было бы наивно отрицать, что в нашей стране у менеджмента есть особый колорит (с росписью под хохлому и балалайкой). У нас до сих пор менеджерами называют кого попало (привет менеджерам по продажам, no offence), а само слово «менеджер» является чуть ли не оскорблением.

С творчеством Максима Батырева я познакомился лет 10 назад, когда прочитал его книгу «45 татуировок продавана». Тогда она мне показалась забавной и интересной, а некоторые идеи я вспоминаю до сих пор. Поэтому меня заинтересовала его книга про менеджмент.

О чём книга

Книга написана в формате советов-тезисов автора, сдобренных личными историями. Про каждый тезис автор рассказывает, как он к нему пришёл и почему это важно.

Несколько примеров тезисов:

Сначала научитесь играть по правилам, потом придумывайте свои.
И даже в кабаке вы — менеджер!
Сначала боремся со следствиями, потом с причинами.
Делайте больше, чем нужно.

Три идеи из книги

Для хакинга системы нужно хорошо знать правила, по которым она устроена. Поэтому в любой системе нужно посвящать свои силы и время глубокому пониманию её структуры. Тогда и только тогда можно заметить неэффективности и использовать их в своих целях.
Подчинённые копируют поведение руководителя. Именно поэтому одна из функций лидера — быть примером для подражания и показывать необходимые модели поведения.
Трудовая дисциплина — общий показатель отношения человека к работе. Если человек систематически продалбывается и забивает на мелочи, то это не просто «лёгкое раздолбайство», а вполне себе значимый тревожный колокольчик для руководителя. Если я не могу доверять человеку в мелочах, то как тогда доверить ему что-то значимое?

Мои впечатления

Впечатления остались смешанные. То ли я возмужал со времён прочтения первой книги, то ли эта книга получилась более слабой. Но впечатление складывалось, будто я читаю истории успеха какого-то инфоцыгана, а не действующего руководителя. Аргументация и взгляд автора показались мне однобокими и скудными.

При этом я хочу отметить, что тезисы (которые Батырев громко называет «татуировками») вполне достойны размышления и применения в жизни. Многие из них я уже успел прожить самостоятельно и поэтому они вызвали у меня отклик. Ни одного откровенно плохого тезиса я не увидел, они все полезны и применимы в различных ситуациях.

Читать книгу от корки до корки я точно не рекомендую. Однако ознакомиться с заинтересовавшими вас главами может быть интересно. Только воспринимайте аргументацию автора с некоторой долей скепсиса, уж больно он любит краски сгущать.

«Никогда не ешьте в одиночку», Кейт Феррацци

Fri, 07 Mar 2025 00:00:00 GMT

После прочтения замечательной книги Ларри Кинга «Как разговаривать с кем угодно, когда угодно, где угодно» мне захотелось глубже разобраться в теме общения. А конкретно — в модном нынче нетворкинге.

Книга Ларри Кинга отвечала на вопрос «Как общаться?». Но логично возникли продолжения: «С кем общаться?» и «Зачем вообще общаться?». На первый взгляд, вопросы риторические, но ответы на них оказались далеко не такими простыми.

О чём книга

Книга посвящена эффективному нетворкингу. Автор ставит перед собой задачу научить читателя строить сеть полезных знакомств, а также грамотно и взаимовыгодно использовать её.

Основные темы книги:

Как знакомиться с интересными людьми?
Где их искать и как завязывать контакт?
Как поддерживать уже существующие связи?
Как использовать сеть знакомств для помощи себе и другим?

Три идеи из книги

Нетворкинг строится на помощи другим. Если подходить к знакомствам с мыслью о том, чем вы можете быть полезны другому человеку, а не что получите взамен, шансы на успех значительно повышаются.
К знакомству стоит готовиться. Перед мероприятием полезно сделать «домашнюю работу»: составить план, выделить ключевых людей и продумать, чем вы можете им быть интересны.
Слабые связи открывают неожиданные возможности. Мы живём в информационном пузыре — среди коллег, родственников и друзей. Но самые неожиданные идеи и предложения часто приходят от людей, которые за пределами этого круга.

Мои впечатления

Несмотря на излишнюю восторженность автора своей идеей, книга действительно полезная. Она даёт чёткое понимание, что такое нетворкинг здорового человека.

И это точно не про «с днём рождения, купи у меня консультацию» и подобные вещи.

Главная мысль, которую Феррацци проводит через всю книгу: нетворкинг — это про взаимопомощь и общие интересы. Эгоистичный подход, при котором человек фокусируется только на своей выгоде, работает против него.

Автор учит отдавать и помогать. И это крутая идея. Ведь кому приятнее познакомиться:

С человеком, который думает только о себе? Или с тем, кто искренне интересуется вами и хочет помочь? Ответ очевиден.

А ещё Феррацци напоминает, что не стоит бояться «больших шишек». Они тоже люди, со своими чувствами, желаниями и потребностями.

Вывод

Книгу рекомендую. Вы получите новые идеи и насладитесь классическим американским стилем нон-фикшн литературы.

Push- и pull-модели потребления информации

Mon, 03 Mar 2025 00:00:00 GMT

В продолжение темы про углубление обучения хочется поговорить о том, как мы получаем информацию.

Процесс обучения происходит только при наличии запроса со стороны учащегося. Именно поэтому в универе многие из нас лихорадочно листали методички перед экзаментом - мы не понимали ценности той информации, которая предлагалась нам на лекциях. Я не говорю, что этой ценности не было, но фраза “зачем мне интегралы в реальной жизни” имеет некоторый простор для интересной дискуссии.

Разные модели получения информации

В какой-то момент, когда я читал очередную книжку про асинхронщину, на меня снизошло озарение. Мы потребляем информацию по точно таким же моделям, как работают, например брокеры сообщений: push и pull.

Примеров push-модели можно привести множество. Когда университетский профессор пытается запихнуть знание в голову скучающего студента - это пуш-модель. “Смотри какая классная статья, обязательно прочти” - тоже (как минимум, в вас запихнули знание о том, что некоторый человек считает эту статью классной). Вышел новый пост в телеграм-канале “Никита Ульшин про IT” - пуш.

Pull-модель работает чуть иначе. В ней потребление информации строится от запроса. Ярким примером будет типичный рабочий день программиста. Он пишет код и в какой-то момент сталкивается с проблемой, решения которой не знает. 20 лет назад он лез в мануалы, 10 лет назад начинал гуглить, сейчас спрашивает ChatGPT, но суть одна и та же - ему понадобилась информация и он вытягивает её из какого-то источника.

Какая модель лучше?

Как бы нам не хотелось выбрать одну модель и строго использовать только её, ничего хорошего из этого не получится. Каждая из моделей решает свой набор задач, применяются они в разных контекстах. Поэтому применять стоит сбалансированное меню из обех моделей.

Обощить эти модели можно так:

push → удобно для открытия нового (но перегружает, если контента слишком много);
pull → эффективен для обучения (но требует осознанного запроса и дисциплины).

Однако в наблюдаемой мною реальности характерен перекос моделей в сторону push. Люди в среднем гораздо больше потребляют случайный контент, чем ищут ответы на свои вопросы.

Сама по себе модель push хороша и полезна, отказываться от неё не стоит. Иногда случайный пост или статья могут натолкнуть на классные идеи или рефлексию. Однако на мой взгляд push не должна быть доминирующей моделью потребления информации. Полезно читать или смотреть какие-то интересные материалы, чтобы триггерить новые идеи в голове, но такой поток должен быть дополнением к осознанному поиску ответов на свои вопросы.

Однако при потреблении push-based информации важно не забывать о рефлексивных вопросах: “Зачем мне это знать? Где я могу это использовать?” Иначе потребление информации будет перегружать мозг и создавать иллюзию обучения. Pull-модель тоже может создавать такую иллюзию, но об этом я напишу отдельно.

И главное - не забывайте отдыхать от информации. Её потоки в современном мире слишком плотные для нормального человека.

Жми лайк и включай уведомления, чтобы не пропустить push нового поста на моём канале :)

«Как разговаривать с кем угодно, когда угодно, где угодно», Ларри Кинг

Fri, 28 Feb 2025 00:00:00 GMT

Разговор — одна из важнейших частей человеческой жизни. Беседовать со знакомыми людьми зачастую легко и приятно. Но вот коммуникация с незнакомцами у многих вызывает стресс. О чём вообще говорить? Как я выгляжу со стороны? Что обо мне подумают?

При этом умение поддерживать любую беседу — крайне важный навык. Например, мне по работе часто приходится общаться с людьми, с которыми мы раньше не были знакомы. И даже деловой разговор проходит гораздо приятнее, если перед ним состоялся хотя бы небольшой small talk.

Эту книгу я прочитал перед прошлым TeamLeadConf, потому что поймал себя на мысли: на конференциях и митапах я часто теряюсь и испытываю трудности в общении с незнакомыми людьми. Поэтому решил исправить эту проблему и взял в руки легендарную книгу Ларри Кинга «Как разговаривать с кем угодно, когда угодно, где угодно».

О чём книга

Ларри Кинг — довольно известный дядька. Он вёл популярное ток-шоу на CNN, и попасть туда считалось честью. В книге он рассказывает о своём пути и делится подходами к развитию навыка общения.

В книге раскрываются следующие темы:

Базовые правила ведения хорошей беседы.
Как вести светские и деловые разговоры.
Какие черты делают человека хорошим собеседником.
Неудачи, ляпы и как с ними справляться.
Лучшие и худшие гости Ларри Кинга — и что делало их такими.

Три идеи из книги

Хорошему собеседнику интересна личность его собеседника. Люди любят говорить о себе и делают это чаще всего. Хороший собеседник меньше говорит о себе, больше слушает и активно интересуется тем, что ему рассказывают.
Поза в общении должна быть естественной и комфортной. Не нужно ничего придумывать или пытаться кого-то изображать — просто будьте собой. Люди чувствуют напряжение и неестественность.
Слова-паразиты и слова-пустышки — «костыли» языка. Чаще всего мы их используем, чтобы заполнить паузы во время размышлений. Вместо них лучше просто помолчать пару секунд — это звучит естественнее.

Мои впечатления

Книга однозначно крутая. Написана легко, интересно и с живым юмором. При этом в ней много практических советов и рекомендаций. Я попробовал некоторые из них в деле — и результаты мне понравились.

Главный посыл Ларри Кинга в том, что общение — это не врождённый дар, а навык, который можно развить. Да, кому-то от природы это даётся легче, но у каждого из нас есть возможность прокачать этот навык.

Возможно, Ларри Кинг слегка переоценивает значимость коммуникации — но его можно понять, ведь это его профессия. Тем не менее его советы оказались для меня полезными и близкими. Рекомендую книгу тем, кому приходится много общаться по работе (или придётся в обозримом будущем) — техники простые, но действительно работающие.

«От разработчика до руководителя», Камиль Фурнье

Fri, 21 Feb 2025 00:00:00 GMT

Отдохнём немного от философии и вернёмся к нашему любимому управлению разработкой.

Я всегда стремлюсь улучшить свою работу и глубже понять, что я делаю. Именно поэтому я активно читаю книги, которые предлагают альтернативные взгляды на роль руководителя.

Книгой Камиль Фурнье “От разработчика до руководителя” я заинтересовался, потому что автор сама прошла путь, описанный в названии. Мне был интересен её взгляд на карьерный рост и вызовы, с которыми сталкивается руководитель на каждом новом уровне менеджмента.

О чём книга

Книга рассказывает о цепочке позиций в управлении людьми. Автор охватывает темы от неформального лидерства и менторства до позиции технического директора. В каждой роли приводятся примеры предстоящих сложностей и подводных камней.

В книге раскрываются следующие вопросы:

Как управлять коллективами разного размера?
На что нужно обращать внимание на каждом этапе карьеры?
Какие ошибки чаще всего совершают руководители, переходя на новую роль?

Три идеи из книги

Многие навыки руководителя универсальны. Например, умение давать обратную связь, позитивно подкреплять нужное поведение или выращивать следующее поколение руководителей, пригодятся на любом этапе карьеры. Поэтому начинать их практиковать стоит уже сейчас.
Самостоятельность — это ключевой навык. Чем более автономен человек, тем больше ответственности ему доверяют. Однако важно различать самостоятельность и изоляцию: не все проблемы нужно решать в одиночку.
Нельзя забивать на технические навыки. Поскольку речь идёт об управлении техническими специалистами, важно оставаться в хорошей технической форме. Поэтому своим техническим знаниям нужно уделять время и силы.

Мои впечатления

Честно говоря, книга оставила у меня смешанные чувства. С одной стороны, было интересно проследить карьерный путь другого человека и получить некоторые рекомендации. С другой стороны, книга больше напоминает сборник советов по руководству в духе «Мама, я тимлид!», только с ещё меньшей конкретикой.

Автор уделяет крайне мало внимания саморефлексии и личным примерам — они кажутся однобокими и вырванными из контекста. Все истории переходов между должностями напоминают телепорт: вот я была разработчиком, и — хоп — уже руководитель.

Здравые идеи в книге, безусловно, есть, но их приходится выискивать по крупицам среди обилия “воды”. Для таких книг я обычно рекомендую пробежаться по оглавлению и прочитать только то, что действительно зацепило. Читать все 300 страниц нет никакого смысла.

Дисциплина полезна, пока не превращается в самонасилие

Wed, 19 Feb 2025 00:00:00 GMT

Одна из целей моего писательства — разобраться в том, как всё устроено. Нет, я не питаю иллюзий, что смогу однажды достичь просвещения и понять всё, но понемногу улучшать своё понимание окружающего мира каждый день — довольно интересно.

Тема этого поста пришла мне в голову на выходных, когда я гулял и размышлял о дисциплине. Я вообще считаю себя довольно дисциплинированным человеком и всегда гордился этим качеством. Но внезапно мне удалось посмотреть на дисциплину с другой стороны, и я понял, что периодически она выходит мне боком.

Дисциплина — это же хорошо, да?

Обычно дисциплина ассоциируется с чем-то положительным. Например, у меня в голове сразу же всплывают такие слова, как сила, упорство, настойчивость, достижения, результат, успешный успех успешного успевателя. Такая интерпретация неудивительна в век искусственной жизни, где люди показывают только свои победы. (Ну кто там встал в 4 утра и уже два часа как медитирует, пробежался и вообще молодец?)

Но дисциплина — это всего лишь инструмент со своими свойствами и ограничениями. Поэтому склонность пихать её куда не стоит напоминает старую шутку про “забивать гвозди микроскопом”. Чаще всего это проявляется в том, что дисциплина превращается в самонасилие, а это ведёт к печальным последствиям.

Простой пример: когда-то я плотно занимался качалкой с тренером. Тогда у меня выдался довольно сложный период в жизни — сильная подавленность, низкий уровень энергии, проблемы со сном. Но я всё равно дисциплинированно ходил в зал и убивался там по два часа. Наградой за это стало выжигание ЦНС и преддепрессивное состояние. Спасло только то, что в какой-то момент я заметил этот эффект и остановился.

Дисциплина без осознанности превращается в самонасилие. И тогда вместо пользы мы просто загоняем себя в угол.

Дисциплина — средство подталкивания, а не топливо

Когда-то я думал, что для эффективности главное — иметь сильную мотивацию. Я читал книги по теории мотивации и ставил эксперименты, но так и не пришёл в прекрасную фазу, где каждый день просыпаешься с горящими глазами.

При этом прогресс всё равно шёл: задачи делались, проекты выполнялись, книги читались. Секрет оказался прост — я стабильно делал одно и то же. Спал по режиму, выделял время на самообразование, ставил планы на день. Дисциплина помогала начать, а дальше дело часто шло само.

Но здесь и проходит граница. Я ненавижу бегать, поэтому каждая пробежка держится на самопринуждении и сжигает мои ресурсы. А играть на барабанах я люблю, но иногда ленюсь. В таком случае достаточно затолкать себя в занятие, и через пару минут мне уже интересно.

Дисциплина хороша как средство подталкивания, но не как топливо. Если у задачи нет ответа на вопрос «Зачем?», дисциплина из помощника превращается в надсмотрщика.

С чего начинать

Дорогой читатель мог прийти к выводу, что дисциплина — это плохо. Но не стоит вдаваться в крайности. Дисциплина — это не волшебная таблетка, которая решит все проблемы. Если вы делаете хрень и прокачаете тайм-менеджмент, то будете делать больше хрени.

Термин “дисциплина” фактически означает “модель поведения, направленная на следование определённому порядку”. Так вот, если сам порядок — хрень, то следование ему приведёт к стремлению следовать хрени. Поэтому начинать стоит именно с порядка.

Правильный порядок — сущность сложная. “Правильность” может быть разной в зависимости от момента жизни. Если вы приболели, то вряд ли будет разумным идти на тренировку или ехать в офис, не так ли? Поэтому первым делом нужно определиться со своими целями и принципами — они и помогут выстроить этот порядок.

Дисциплина — очень хороший и полезный инструмент. Но, как и любой другой инструмент, она требует умелого обращения. А навык приходит только с практикой, иначе вместо удобной системы можно построить себе клетку.

«Эго — это враг», Райан Холидей

Fri, 14 Feb 2025 00:00:00 GMT

Тема эго (не фрейдистского) интересует меня давно. Однако я никогда не изучал её отдельно, а чаще встречал размышления о влиянии эго на разные аспекты жизни в различных книгах.

Так случилось и с книгой The Poker Mindset. Один из принципов покерного мышления, описанных в ней, звучит так: «Оставь эго за дверью». В книге наглядно показано, как игра под властью эго может привести к значительным денежным потерям.

Мне стало интересно взглянуть на эго внимательнее, ведь его влияние на поведение людей далеко не ограничивается покером. Эта тема также резонировала с моим интересом к стоицизму (см. обзор книги Массимо Пильюччи «Как быть стоиком»). Поэтому я начал искать литературу, которая помогла бы глубже разобраться в этом вопросе, и наткнулся на труд современного автора книг по стоицизму Райана Холидея «Эго — это враг».

О чём книга

Название говорит само за себя. Автор рассказывает, что собой представляет эго и как оно влияет на разные сферы нашей жизни (спойлер: негативно — везде).

В книге раскрываются следующие темы:

Что такое человеческое эго
Различные формы его проявления
Как эго препятствует успеху
Что оно нашёптывает нам в моменты неудач
Способы обуздать своё эго

Три идеи из книги

Эго стремится видеть себя лучше, чем есть на самом деле. Эгоцентризм — это одна из самых мощных форм самообмана, которая приводит к когнитивным искажениям и ошибочным решениям. Например, мысль «Я уже совершенен, мне нечему учиться» — яркое проявление эго.
Бороться с эго сложно и болезненно, потому что оно может принимать разные формы: гордыня, зависть, жадность, жажда справедливости. Первый шаг — трезво оценить своё поведение и увидеть проявления эго. Второй шаг — честно проанализировать свои поступки и систему убеждений, чтобы выявить слабые места и выработать новые модели поведения.
Одно из противоядий против эго — смирение. Важно понимать, что смирение ≠ бездействие. Смирение — это способность видеть ситуацию такой, какая она есть, принимать её и затем работать над улучшением и исправлением.

Мои впечатления

Книга оказалась яркой и интересной. Холидей пишет в типичном стиле американских авторов: сначала нагнать тучи, привести пугающие примеры, а затем вдохновить историями известных личностей. Несмотря на это, в книге много здравых идей (я аж 15 заметок по ней написал).

Она помогла мне взглянуть на эго по-новому. Могу сказать, что посыл из The Poker Mindset оказался абсолютно верным — эго мешает успеху, фактически становится на его пути.

При этом автор признаёт, что работа с эго — это путь длиною в жизнь. Искоренить его невозможно, да и не нужно. Однако мне стало понятнее, как стоический инструмент самонаблюдения помогает контролировать своё эго. Теперь в свой вечерний дневник я добавил несколько «неудобных» вопросов, которые помогают мне выявлять проявления эго в повседневной жизни.

Небольшой объём книги не помешал ей встряхнуть некоторые мои взгляды. Готов рекомендовать её к чтению, но с долей критического анализа — Холидей порой слишком драматизирует свои истории.

Как замечать прогресс, когда результата ещё нет

Mon, 10 Feb 2025 00:00:00 GMT

Одно из моих хобби — музыка. Подростком я научился играть на гитаре, потом пытался освоить дисторшн, немного пробовал себя в пианино и в итоге остановился на ударных.

Однажды я семь месяцев учил одну и ту же песню. Я недооценил её сложность, поэтому она потребовала значительно больше времени, сил и внимания, чем я рассчитывал. Я понимал, что техника и навыки растут, но не мог отделаться от мысли, что топчусь на месте: конечной цели всё ещё не достиг.

Результата нет, а прогресс есть

Таких проектов у меня было множество. Вроде делаешь-делаешь, а всё как будто стоит на месте. Особенно сильно я это прочувствовал в личных проектах: когда канал несколько месяцев стагнировал, меня это заметно повергало в уныние.

Причина — долгая работа без видимого результата. В голове появляются мысли: «Зачем я трачу на это время?» и «Я столько сил вкладываю, а отдачи нет». Если их не замечать, легко бросить проект раньше времени.

Мне вообще трудно видеть собственный рост. Чтобы его заметить, мне нужно одно из двух:

сделать качественный скачок, после которого уже трудно отпираться;
приложить осознанные усилия и посмотреть на промежуточные изменения.

Скачок даёт много положительной обратной связи, но происходит редко. Для постоянной работы на него рассчитывать не стоит.

Как я ищу промежуточные изменения

Сначала я стараюсь поймать обобщения и проверить их:

«Ничего не получается». Прям вообще ничего?
«У меня никогда не получится». Точно не получится до конца жизни?
«Я столько сил вкладываю, а отдачи нет». Не завышены ли мои ожидания?

Это не решает задачу, но помогает выйти из крутого пике и посмотреть на ситуацию трезвее.

Затем я задаю себе вопросы о прогрессе:

В чём я стал лучше за последнее время?
Что мне стало даваться легче, чем раньше?
Какие задачи я недавно сделал хорошо и почему доволен собой?

Мне важно рефлексировать не только над ошибками, но и над успехами. Они дают уверенность и опору для дальнейшей работы.

Ещё я стараюсь искать небольшие результаты на коротких промежутках времени. В работе над песней перестал требовать от себя идеального исполнения всей партии и сосредоточился на отдельных грувах. Общая цель никуда не исчезла, зато прогресс стало возможно увидеть.

Today I Learned

Когда мне кажется, что в работе больше нечему учиться, я временно добавляю в дневник рубрику Today I Learned. Вечером записываю туда небольшие, но интересные вещи, которые узнал или применил за день.

Например, однажды список выглядел так:

библиотека Squirrel не умеет нормально работать с UNION;
Gemini неплохо работает с текстами;
я всё так же ненавижу верстать, а флексы — это боль.

Не каждая новая мелочь означает значимый профессиональный рост. Но такой список помогает увидеть, что даже обычный день не обязательно был пустым, и даёт материал для более честной оценки длинного периода.

Отсутствие конечного результата не означает отсутствия движения. Иногда прогресс приходится специально доставать из процесса и рассматривать отдельно.

The Poker Mindset by Matthew Hilger, Ian Taylor

Fri, 07 Feb 2025 00:00:00 GMT

Ранее я уже писал о книге Энни Дьюк «Принцип ставок». Книга мне понравилась, но оставила ощущение недосказанности, незавершённости. После её прочтения мне стало интересно, как думают настоящие игроки в покер и какие принципы мышления помогают профессионалам долго и успешно играть в эту игру.

В бэклоге у меня уже очень давно лежала The Poker Mindset авторов Matthew Hilger и Ian Taylor. И я понял, что настал её звёздный час, потому что она в первую очередь предназначена для игроков в покер и полностью посвящена моделям мышления.

О чём книга

Книга посвящена принципам и парадигмам мышления, которые необходимы (но не достаточны) для долгосрочной и успешной карьеры игрока в покер. В основе этого мышления лежат семь принципов:

Понять и принять реальность покера.
Играть в долгосрок.
Отдавать приоритет правильным решениям, а не зарабатыванию денег.
Быть нечувствительным к деньгам.
Оставить эго за дверью.
Убирать эмоции из решений.
Посвятить себя бесконечному циклу анализа и самосовершенствования.

В книге раскрываются следующие темы:

Подробное объяснение каждого принципа.
Как преодолевать свои инстинкты и автоматические реакции.
Как справляться с проигрышами и чёрными полосами.
Что такое тильт и как с ним работать.
Как полосы везения могут оказывать негативное влияние на игрока.

Три вывода из книги

Правильное решение — это решение, которое даёт максимум денег в долгосроке. Даже если в моменте правильное решение приводит к проигрышу, оно не перестаёт быть правильным.
В краткосроке рулит удача, в долгосроке — навык. Если играть достаточно много раздач, то на дистанции удача перестанет быть решающим фактором, и на первый план выйдет принятие правильных решений.
Чёрных полос на самом деле не существует — это всего лишь наблюдаемый паттерн в результатах игры. Поэтому лучший выход из чёрной полосы — перестать воспринимать её так и сосредоточиться на правильных решениях.

Мои впечатления

В этой книге я нашёл то, что искал, поэтому изучал её долго и внимательно. Конечно, в первую очередь она направлена на игроков в покер и преследует цель заложить им в голову правильные установки для успешной игры. Но в ней очень мало терминологии, поэтому её можно и нужно читать даже людям, которые не отличат каре от стрита.

Чем она может быть полезна человеку, который не играет в покер? Тем, что наша жизнь очень напоминает покер. Мы точно так же живём в балансе удачи и навыка. Иногда мы совершаем правильные действия, но не получаем нужных результатов, и из-за этого можем делать неправильные выводы о себе или мире.

The Poker Mindset — это учебник здравомыслия и критического анализа. Последняя глава книги посвящена тому, как можно применять мышление игрока в покер в повседневной жизни, и каждый принцип важен и полезен по-своему. Думаю, что каждый читатель найдёт в ней точки роста и отличные идеи.

Я ещё не закончил писать заметки по этой книге, но уже предвкушаю несколько интересных постов, которые опубликую в ближайшие недели. А пока пойду в холдем сыграю, что ли, — столько лет картишки не раскидывал…

1-1 с Дашей Бородиной. Энергия руководителя: как сохранять и восстанавливать

Wed, 05 Feb 2025 00:00:00 GMT

Разговор с Дашей Бородиной о личной энергии руководителя: как замечать истощение до выгорания, распределять ограниченный ресурс между задачами и восстанавливаться. Даша шесть лет руководила командами в IT, а сейчас работает коучем и корпоративным тренером и ведёт канал «Потрудитесь отдохнуть!».

О чём разговор

Почему состояние руководителя влияет не только на него самого, но и на команду.
Из каких «батареек» складывается личная энергия и как они связаны между собой.
Как относиться к своему ресурсу, чтобы не доводить себя до истощения.
Какие способы восстановления работают у Даши и у меня.

Для меня эта тема практическая: проектов и хотелок всегда больше, чем энергии. Разговор помогает посмотреть не только на способы отдыха, но и на то, как мы расходуем силы до того, как они заканчиваются.

Стану тимлидом и разучусь писать код

Mon, 03 Feb 2025 00:00:00 GMT

Один из самых сильных страхов потенциального тимлида — просесть по техническим навыкам. Страх не беспочвенный: в работе руководителя код занимает значительно меньше времени, чем у разработчика.

Некоторые годами остаются в параличе выбора. Попробовать роль интересно, но страшно потерять возможность вернуться в разработку или превратиться в мифического плохого менеджера, который ничего не понимает и только распоряжается.

Все эти опасения можно свести к одному: «Я перейду в тимлиды, просяду по техничке и вылечу с рынка».

После короткого перерыва навык не исчезает

Переход в тимлиды похож на вход в новую профессию с позиции джуна. Не факт, что она понравится, поэтому возможность вернуться действительно важна.

За несколько месяцев без регулярного кода фундаментальные навыки никуда не денутся. Может просесть моторная память, забудутся детали языка и стандартной библиотеки, но это восстанавливается практикой.

У меня был период, когда я полгода не написал ни строчки кода, даже в пет-проектах. Я управлял достаточно большой командой, и времени на технические задачи не оставалось.

Когда ситуация стабилизировалась, я открыл IDE и испугался: программировать действительно стало тяжеловато. Я решил писать как пишется, не пытаясь сразу вернуться на прежний уровень. Через пару недель оказалось, что ничего критичного не произошло. Вернулась моторика, а забытые детали снова улеглись в голову.

Длительный перерыв меняет задачу

Если не писать код годами, навыки заметно просядут, а технологии уйдут вперёд. Возвращение потребует времени и не обязано быть лёгким.

Но опыт, который однажды позволил человеку стать сильным разработчиком, не исчезает. Это похоже на смену стека: конкретный язык и инструменты приходится учить заново, но инженерное мышление, понимание систем и способность разбираться в коде остаются.

Рост руководителя идёт вширь

При переходе в тимлиды часть глубины действительно обменивается на ширину. Руководитель с бэкенд-опытом может знать конкретный сервис хуже разработчика, который работает с ним каждый день. Зато ему приходится разбираться во фронтенде, DevOps, тестировании, требованиях, архитектуре и соседних доменах.

Это не отменяет риск потерять форму. Зато показывает, что техническое развитие не обязательно прекращается — оно меняет направление.

Страх просесть по техничке нормален. Но один лишь страх — слабая причина годами не проверять интерес к новой роли. Короткий переход можно рассматривать как эксперимент, а техническую форму при необходимости восстановить.

«Принцип ставок», Энни Дьюк

Fri, 31 Jan 2025 00:00:00 GMT

Темой скрытой роли случайности в жизни я начал активно интересоваться после знакомства с трудами Нассима Талеба. В частности, на меня сильно повлияла его книга “Одураченные случайностью”. Прочитав её, я стал лучше понимать, насколько хаотичен и сложен мир, в котором мы живём.

В книге «12 недель в году» я наткнулся на идею рассматривать все свои решения как ставки на определённый результат. Эта мысль мне понравилась, и я решил копнуть глубже. Мой выбор пал на книгу “Принцип ставок” Энни Дьюк. Энни — профессиональная покеристка, неоднократно выигрывавшая крупные турниры. Именно этот факт стал для меня решающим, ведь кто, как не игроки в покер, лучше всех знаком с природой случайности?

О чём книга

По сути, содержание книги полностью соответствует её названию. Она посвящена принятию качественных решений в условиях высокой неопределённости. В книге представлена ментальная модель отношения к решениям, а также целый набор способов их улучшения.

В книге раскрываются следующие темы:

В чём заключается вероятностная природа наших решений?
Чем наши решения похожи на ставки в покере?
Какие когнитивные искажения мешают нам принимать правильные решения?
Как улучшить свои механизмы принятия решений?

3 вывода из книги

Жизнь больше похожа на покер, чем на шахматы. Шахматы — это игра с нулевой неопределённостью: вся информация о партии открыта. В покере же гораздо больше переменных, поэтому процесс принятия решений в реальной жизни больше напоминает партию в покер.
Нельзя оценивать качество решения по его результату, так как это игнорирует влияние случайности. Хорошее, взвешенное решение может привести к неожиданному исходу просто потому, что сработала одна из вероятностей (те самые талебовские “толстые хвосты” или “чёрные лебеди”).
Наше восприятие мира основано на убеждениях, которые мы всеми силами стараемся защищать. Однако, если мы делаем ставку (например, заключаем пари), то начинаем внимательнее и критичнее относиться к своим взглядам, потому что появляется фактор риска.

Мои впечатления

Ощущения от книги остались смешанные. С одной стороны, она подарила мне множество новых идей и помогла лучше понять вероятностную природу решений. С другой — показалась довольно поверхностной и растянутой. В ней много простых рекомендаций в духе “капитана Очевидность”, но серьёзных концепций я для себя не вынес.

Тем не менее, я не могу назвать её плохой. Идеи в книге здравые и интересные, им просто не хватает глубины. Если вы не читали Талеба, то “Принцип ставок” может оказаться полезной и увлекательной. Однако у меня после прочтения осталось ощущение незавершённости и недосказанности.

А я не люблю оставлять вопросы без ответов, поэтому решил копнуть дальше. Результаты узнаете в следующем обзоре :)

Непреднамеренный обман

Wed, 29 Jan 2025 00:00:00 GMT

Так уж сложилось, что сейчас я на работе провожу кастдевы. Для тех, кто не знает: кастдев - это интервью с пользователями вашего продукта.

Мы искали сценарии для сложного архитектурного продукта, который моя команда разрабатывала несколько месяцев. До интервью мы хотели сделать «одно кольцо, чтобы всеми править», но крепко приложились лбом к сложности реального мира. Поэтому решили сосредоточиться на задачах, которые принесут пользу.

Хотелки ещё не означают готовность пользоваться

Первая мысль при задаче «найти боли пользователей» - спросить, чего они хотят. В ответ можно получить кучу идей и забить бэклог до отказа. Проблема начинается позже: вы приносите человеку работающий продукт, а он им не пользуется.

Это не значит, что пользователь не знает, чего хочет, или намеренно обманывает. Он может искренне хотеть фичу и при этом не быть готовым менять ради неё привычный процесс, тратить время или брать на себя новые издержки.

Поэтому важно разделять три разные вещи: что человек говорит, как он вёл себя в похожей ситуации и какие ресурсы готов потратить на решение.

Вместо мнения - прошлое поведение

Мы перестали спрашивать, чего люди хотят. Вместо этого просили рассказать о релевантном опыте: «Вспомни ситуацию, когда ты делал X». Дальше мы разбирались, где человек споткнулся и насколько сильно у него там болит.

Параллельно можно смотреть на следы реальной работы. Что человек пишет в рабочих чатах? В каких каналах участвует? Куда коммитит? Что делает в Confluence?

Реальные действия не дают нам готового ответа, зато помогают проверить слова и увидеть реальный контекст. Для технаря такое погружение в жизнь пользователей меняет восприятие продукта и мотивацию его делать.

Даже если вам не нужно самостоятельно проводить кастдевы, сходите своими продактами на одно интервью. Там легко увидеть разницу между тем, что команда предполагает о проблеме, и тем, как она проявляется в жизни.

«Цель. Процесс непрерывного совершенствования», Элияху Голдратт

Fri, 24 Jan 2025 00:00:00 GMT

«Цель» я перечитывал во второй раз. Первое прочтение случилось со мной в самом начале моего тимлидского пути, и эта книга оказалась замечательным подспорьем в понимании того, как организуется работа.

Сейчас мне стало интересно вернуться к этой великолепной книге, чтобы посмотреть на приключения Алекса Рого через призму накопленного опыта. В своё время понимание основ теории ограничений сильно помогло мне балансировать рабочие процессы, поэтому повторное прочтение оказалось захватывающим.

О чём книга

“Цель” написана в жанре бизнес-романа. То есть, по сути, это художественное произведение, призванное чему-то научить читателя. Конкретно эта книга раскрывает основы TOC (theory of constraints) на примере завода, который отчаянно пытаются спасти от закрытия.

В книге раскрываются следующие темы:

Что такое производительность для бизнеса.
Что такое бутылочные горлышки и как они влияют на систему.
Как выстраивать систему на основе её ограничений.

3 вывода из книги

Цель бизнеса — делать деньги. Эту цель можно сформулировать по-разному, но, в конечном счёте, бизнес строится именно для того, чтобы зарабатывать.
Бутылочные горлышки — это элемент производственной системы, производительность которого определяет производительность всей системы. Если бутылочное горлышко делает Х работы в час, то вся система будет выполнять Х работы в час или меньше.
Строить производственную систему нужно вокруг её бутылочных горлышек. Нет смысла использовать на максимум ресурсы с избыточной мощностью, потому что это приведёт к накапливанию невыполненной работы перед бутылочным горлышком и срыву сроков.

Мои впечатления

Во второй раз эта книга понравилась мне ещё больше, чем в первый. Я уже насмотрелся на разные системы и бутылочные горлышки в них (а ещё сам побился об бутылочные горлышки и побывал в их роли), поэтому читать было крайне интересно. Отдельный плюс — развлекательный формат бизнес-романа, что делает чтение вдвойне приятным. Но местами всё-таки придётся поднапрячься.

Книгу не просто так включают в каждый список для начинающих руководителей, потому что организация производственного процесса — главная обязанность тимлида. “Цель” помогает научиться смотреть на производительность системы в целом, а не только на отдельные её компоненты.

Я рекомендую прочитать эту книгу даже тем, кто не управляет другими людьми. Мы все работаем в рамках определённых процессов, и вы вполне можете посмотреть на них свежим взглядом, предложив интересные оптимизации. А для тимлидов — это must-read.

Что скрывается за фразой «у нас так принято»

Wed, 22 Jan 2025 00:00:00 GMT

Если вы пытаетесь изменить устоявшийся процесс, то рано или поздно можете услышать:

У нас так не принято.

Рядом обычно живут варианты «мы работаем по-другому» и «все так делают». Такие фразы звучат как позиция всей организации, хотя произносит их конкретный человек.

Кто такие «мы»

За общим «мы» могут скрываться совершенно разные вещи:

реальное правило или ограничение;
прошлый неудачный опыт;
интересы другой команды;
риск, который инициатор изменения не заметил;
привычка конкретного руководителя;
простое нежелание снова во что-то погружаться.

Поэтому спорить с «нами» бесполезно. Сначала нужно вернуть разговор к конкретике:

кто именно принял такое решение;
почему оно появилось;
какой риск оно закрывает;
кого затронет изменение;
что должно произойти, чтобы решение пересмотрели.

Вопросы не гарантируют согласия. Зато превращают безличный запрет в набор интересов и ограничений, с которыми уже можно работать.

Иногда цена изменения слишком высока

Однажды я хотел внедрить технологически-процессное изменение, но столкнулся с позицией «у нас так не будет, мы так не работаем».

Мне понадобилось полгода и десятки часов созвонов, чтобы найти союзников, понять причины сопротивления и выяснить, кто именно входит в это «мы». В конечном итоге изменение удалось провести. Но выгорел я настолько, что после этого просто уполз в отпуск.

Этот случай научил меня двум вещам. Во-первых, сопротивление не всегда означает глупость или злой умысел: за ним могут стоять реальные интересы, риски и прежние договорённости. Во-вторых, даже полезное изменение может не окупить политическую и личную стоимость.

Поэтому после расшифровки «у нас так принято» остаётся ещё один вопрос: действительно ли эта битва стоит полугода жизни?

Если сейчас, то нет

Mon, 20 Jan 2025 00:00:00 GMT

Спешка может негативно влиять на качество принимаемых решений. В напряжении и суете высока вероятность упустить важные детали и в итоге получить не самый благоприятный результат.

Вдвойне сложно принимать хорошие решения под давлением. Лично я очень не люблю, когда меня “пушат”: торопят, подталкивают, пытаются как-то ускорить процесс. И ещё больше я не люблю, когда меня “пушат” к принятию какого-либо решения.

Причина тому проста. Если я не смог принять решение быстро, значит, мне нужно время на то, чтобы подумать и всё обдумать. А для этого необходимы спокойствие и тишина. Я не могу сконцентрироваться и прийти к какому-то выводу, когда меня постоянно дёргают.

Поторапливание как манипуляция

Подталкивание к принятию какого-либо решения вполне может быть манипуляцией. Например, это частый приём в продажах — нужно “хватать” потенциального клиента, пока он “горячий” и заинтересованный. Поэтому на человека начинают давить акциями, скидками, дедлайнами, “упущенной выгодой” и даже маркетинговыми уловками, вроде “Что ты как лох, купить не можешь, что ли?”

Лично у меня это всегда вызывало дикое раздражение. Поэтому при первых признаках давления я гарантированно отказывался от покупки (а иногда даже принципиально выбирал более уважительных конкурентов). Однако есть люди, которые поддаются подобным манипуляциям и начинают действительно чувствовать вину за то, что не могут быстро решиться.

Что делать?

Недавно в книге вычитал отличный экологичный способ противостоять таким манипуляциям. Собственно, он и описан в заголовке. Если чувствуете, что вас начинают подталкивать к принятию какого-либо решения, можно использовать следующий ответ:

“Если вы хотите, чтобы я принял решение прямо сейчас, тогда мой ответ — нет.”

Такой ответ ставит вас в выгодное положение. Во-первых, это не прямой и категоричный отказ (как я поступал раньше). Вы даёте человеку понять, что вам интересно его предложение, но вам нужно время, чтобы обдумать и взвесить все “за” и “против”. С другой стороны, вы перекрываете манипуляцию давлением, ясно показывая, что продолжение напора приведёт только к отказу.

Тактика “если сейчас, то нет” более гибкая, чем выход из коммуникации при давлении. Это не резкий и прямой отказ, поэтому ваш собеседник сохраняет возможность для манёвра. В то же время вы защищаете свои границы, не рискуя показаться грубым или невежливым.

Конечно, собеседников нужно уважать. Но своё спокойствие, на мой взгляд, уважать нужно ещё больше. Когда ситуация позволяет взять паузу, решение без давления даёт мне больше уверенности, что я ничего важного не упустил.

«Цели. Как пользоваться жизнью на всю катушку», Зиг Зиглар

Fri, 17 Jan 2025 00:00:00 GMT

Поскольку я с личными целями работаю активно, ценной может оказаться любая, даже самая маленькая мысль. Поэтому книги по работе с целями я люблю и читаю регулярно. Да, в какой-то момент они начинают повторяться, но подача старой мысли под новым соусом иногда вызывает в голове вспышку понимания.

В конце прошлого года, перед подведением итогов и постановкой новых целей, я решил смахнуть пыль со своих знаний о целеполагании. Поэтому прочитал несколько книжек подряд на эту тему. В мой список попала и книга «Цели. Как пользоваться жизнью на всю катушку» за авторством Зига Зиглара.

О чём книга

Несмотря на компактность, книга широкими мазками охватывает все базовые темы целеполагания: от миссии до ежедневной деятельности. Примерно треть книги посвящена тому, как вообще ставить цели во всех подробностях. По мнению Зиглара, это краеугольный камень всего процесса. Хорошо поставленные цели — это 50% успеха.

В книге раскрываются следующие темы:

Почему люди не ставят цели и как начать это делать.
Алгоритм постановки целей из 9 шагов (авторский, специфичный, интересный).
Ежедневные рутины по достижению целей.
Как действовать в сложных ситуациях, когда не получается добиться цели.
Секретный секрет достижения целей.

Три идеи из книги

Основная проблема — не недостаток времени, а недостаток целенаправленности. Люди, которые сами не знают, чего хотят достичь, создают бурную деятельность. Результат у такой деятельности обычно околонулевой.
Любое действие должно быть выровнено по целям, иначе его нет смысла делать. Из отсутствия ответа на вопрос «Нахрена?» растут ноги лени и прокрастинации.
За результаты нужно платить действиями и усилиями. Если просто поставить цель и ждать, что она сама по себе достигнется, — ничего не будет. Зачастую люди просто не прикладывают достаточного количества усилий или выбирают не те действия, которые на самом деле ведут к цели.

Мои впечатления

В последнее время я вообще люблю читать старые книги (скоро будет пара интересных обзоров). Они напоминают мне, что «самое свежее и актуальное» ещё и мимолётно, а фундаментальные вещи не меняются долго. Самым любопытным рекомендую глянуть мой обзор на книгу Сергея Поварнина «Как читать книги» — она за 100 лет стала ещё актуальнее.

Книга Зига Зиглара не такая старая (2004 год), но спикерской деятельностью он занимался ещё тогда, когда моя бабушка в школу ходила. Поэтому его материалы прошли через годы и многих людей.

Я не могу сказать, что книга прямо поменяет мировоззрение. Но задуматься точно заставит. Мне очень понравилась система Зиглара по постановке целей. Она длинная (9 объёмных вопросов) и очень дотошная, но при этом на выходе даёт конкретные и хорошо проработанные цели. В чистом виде система мне не подошла, но некоторые вопросы я утащил.

Акцент же Зиглар делает на упорной работе и личной ответственности (ага, вот тот самый секретный секрет). Его алгоритм на самом деле прост как палка: потратьте достаточно времени и сил на постановку качественных целей, хорошенько подумайте о путях достижения и херачьте, пока не получится.

С точки зрения полезности — думайте сами. «12 недель в году», на мой вкус, более практико-применимая. Книгу Зиглара я бы рекомендовал прочитать по диагонали, чтобы выцепить себе какие-то интересные идеи (в книге их полно). Если вообще ничего по целям не читали, пожалуй, «12 недель в году» будет стартом получше.

«Мама, я тимлид!», Марина Перескокова

Fri, 10 Jan 2025 00:00:00 GMT

Хотя я руковожу командами уже около пяти лет, никогда не бывает лишним вернуться к основам. Часто получается так, что новый взгляд на базовые вещи дорисовывает картинку в голове, и в работе появляется больше понимания.

Книгу “Мама, я тимлид!” я взял почитать по двум причинам. Первая — вернуться к истокам и посмотреть на основы своей работы. Вторая — проверить, могу ли я рекомендовать её ребятам, которых иногда консультирую (я никогда не рекомендую книги, которые не читал сам). Есть ещё и третья причина, не такая очевидная: книга на слуху, поэтому я решил лично посмотреть, чем в ней все вокруг так восхищаются.

О чём книга

По сути, книга отвечает на один большой вопрос: что делать, когда ты стал тимлидом? С переходом в управление жизнь специалиста меняется сильно, поэтому и областей пришлось затронуть довольно много.

В книге раскрываются следующие темы:

Как сменить парадигму мышления с личных результатов на командные?
Как коммуницировать с начальством?
Работа с командой: микроменеджмент, делегирование, авторитет.
Работа с людьми: как общаться, как мотивировать, как увольнять.
Слаживание команды и забота о ней.
Особенности работы с распределённой командой.

Три вывода из книги

Основной принцип начинающего тимлида: команда в первую очередь. Это значит, что первыми нужно решать задачи, которые влияют на команду. Сложнее и важнее всего отказаться от желания «всё сделать самому».
Важно обеспечивать прозрачность дел как для команды, так и для своего непосредственного руководителя. Люди должны знать, что вообще происходит и как обстоят дела. Но с информацией нужно быть аккуратным: не стоит перегружать других людей лишними деталями.
Команда должна быть сбалансированной по уровню. Если набрать одних джунов, будет очень сложно обеспечить поставку. А если набрать одних сеньёров, можно столкнуться с кучей конфликтов из-за амбиций и эго.

Мои впечатления

Книга оставила у меня смешанное впечатление. Она действительно покрывает все базовые вопросы начинающего тимлида. Её даже можно использовать как настольный справочник.

Однако многие темы раскрыты очень поверхностно (а некоторые даже показались мне довольно наивными). В целом я не могу сказать, что это прям минус — для каждой из тем написаны целые отдельные книги, и не просто так. Но всё-таки не хватает хотя бы ссылок на источники, где можно “почитать подробнее”.

По итогам чтения я внёс эту книгу в свой список рекомендаций для начинающих тимлидов. Для себя я ничего особенно нового не вынес, но это и неудивительно — книга в первую очередь направлена на специалистов, которые только стали тимлидами. Поэтому, если вы недавно перешли в новую роль или готовитесь к этому, то настоятельно рекомендую прочитать “Мама, я тимлид!”. Все ответы вы не получите, но хотя бы поймёте, куда копать и что вас ждёт.

А ещё в книге есть бесподобные иллюстрации от Кира Анастасина.

1-1 с Мишей Трифоновым. Лидер-слуга: сила через служение команде

Mon, 30 Dec 2024 00:00:00 GMT

Разговор с Мишей Трифоновым о модели лидера-слуги: как руководитель помогает команде добиваться результата, создавая условия для работы и роста людей. Миша руководит разработкой департамента Поверхности Cloud.ru, ведёт подкаст и канал «Трифонов_IT».

О чём разговор

Как Миша пришёл к концепции лидера-слуги.
Как такой руководитель действует в разных рабочих ситуациях.
Как служение команде помогает людям профессионально раскрываться.
Как не забыть о себе, заботясь о других.
С чего начать применять этот подход в своей команде.

Разговор опирается на случаи из реальной практики. По ходу записи я заметил, что сам часто действовал как лидер-слуга, хотя раньше не называл свой подход этим термином.

«12 недель в году», Брайан Моран, Майкл Леннингтон

Fri, 27 Dec 2024 00:00:00 GMT

Мой опыт постановки целей богат, но не блещет историями успеха. Чаще всего что-то шло не так, и я расстраивался, а цели не достигались. Какое-то время я вообще жил без целей (и в целом неплохо себя чувствовал), но потребность в структурировании своей деятельности всё-таки дала о себе знать.

Именно тогда я вспомнил о книге «12 недель в году». Раньше я уже читал её и даже пробовал внедрить методику, но закончилось это полным фиаско: я выгорел, цели достигнуты не были. Однако книга запомнилась и всплыла в памяти снова, когда я задался вопросом: «Как всё-таки адекватно ставить цели и достигать их?». Ну и когда ещё рассказывать о таких книгах, если не под Новый год.

О чём книга

Авторы книги предлагают методику постановки и достижения целей, основанную на цикле в 12 недель. Их мотивация заключается в том, что работа более короткими интервалами (12 недель вместо 12 месяцев) позволяет держать фокус и более эффективно использовать время. В частности, короткие итерации помогают избежать мыслей вроде «времени ещё много, всё успею, потом сделаю».

Глобально книга разделена на две большие части. В первой части авторы «продают» идею 12-недельного года: знакомят читателя с концепцией, приводят аргументы и так далее. Вторая часть посвящена конкретному плану действий для интеграции 12-недельной системы в жизнь.

В книге раскрываются следующие темы:

Почему годовые планы не работают.
Что такое видение и почему оно так важно для целеполагания.
Преднамеренный дисбаланс вместо попыток добиться баланса во всём.
Как использовать 12-недельные циклы для планирования и достижения целей.
Рутины эффективной работы по 12-недельным циклам.

Три вывода из книги

Планирование на более короткий период позволяет сохранять концентрацию. Ты знаешь, что каждый день на счету. Однако слишком короткий период планирования может привести к перенапряжению по этой же причине.
Видение — основа целеполагания. Без понимания стратегии невозможно нормально планировать. В лучшем случае тактические цели будут направлены в разные стороны.
Короткий период планирования позволяет менять приоритет в каждом цикле, создавая преднамеренный дисбаланс. Например, в первый цикл планирования я запустил подкаст (дисбаланс в пользу работы над медийными проектами), на второй цикл у меня запланированы исследования и эксперименты по теме отдыха и восстановления энергии (дисбаланс в пользу самочувствия).

Мои впечатления

Первое прочтение оставило у меня смазанные впечатления. Книга показалась наполненной историями успеха и в целом не очень полезной. Но второе прочтение изменило моё мнение. Думаю, я просто набрался опыта и стал замечать новые детали.

Я считаю, что эта книжка — достаточно полное руководство для тех, кто хочет ставить цели и реально их достигать. В ней есть всё: как выстроить своё видение, как планировать, как отслеживать прогресс и оценивать эффективность. При этом на многие вещи даётся пошаговый алгоритм в духе «бери и делай», а на сайте авторов даже есть шаблоны.

Книжку нужно читать внимательно, потому что в ней много мелких, но очень важных деталей. Например, есть следующая прекрасная рекомендация: планируй действия на день и неделю, отслеживай их выполнение. Ключевое слово — действия. Не нужно планировать результаты — они от нас не зависят (вспоминаем дихотомию контроля). Нужно отслеживать только свои действия, потому что только на них мы в конечном счёте можем повлиять.

Вообще, я бы рекомендовал эту книгу всем, потому что у каждого из нас в работе есть планы, цели и так далее. Подход авторов помогает структурировать деятельность и не распыляться на мелочи. А если вы уже используете личную систему планирования и целеполагания, то точно найдёте для себя несколько классных идей.

Принципы — это осознанно выбранные правила жизни

Mon, 23 Dec 2024 00:00:00 GMT

Вдогонку к обзору книги Массимо Пильюччи я почувствовал непреодолимое желание написать о своём взгляде на личные принципы. Близость Нового Года подталкивает к рефлексии, в частности к пересмотру своих же принципов.

Принципы, привычки, правила…

Я считаю, что среди всего многообразия факторов, влияющих на поведение человека, только принципы являются осознанным выбором. Привычки формируются автоматически (и не всегда осознанно). Правила приходят извне. А принципы — это осознанный выбор, который помогает нам жить так, как мы считаем правильным.

Сам по себе термин “принцип” означает сильную внутреннюю убеждённость, которая влияет на принятие решений. Правила я могу соблюдать или не соблюдать - в каждой конкретной ситуации это будет зависеть от моих принципов.

Также у каждого из нас есть набор неосознанных правил, которые мы используем для принятия решений. Эти правила, на мой взгляд, приниципами не являются именно по причине своей неосознанности.

Зачем человеку нужны принципы?

Соблюдение правил обычно обеспечивается наказаниями. Однако в жизни много ситуаций, где за несоблюдение правил наказания не предусмотрено. И ещё больше ситуаций, где правил просто нет (например, уступать ли место бабушке в метро?). И здесь в игру вступают принципы.

Принципы определяют личный вектор принятия решений. Например, из книги Кэла Ньюпорта “Хватит мечтать, займись делом” я взял принцип “Хорошо работать важнее работы мечты”. Раньше этот принцип у меня был неосознанным правилом, однако я трансформировал его с помощью чтения и размышлений. И теперь во время сомнений насчёт работы и карьеры я вспоминаю этот принцип и опираюст на него. Раньше такие размышления могли выбить меня из колеи на пару дней :)

Если у человека нет чётко сформулированных принципов, то он становится рабом правил и привычек. Он живёт с чувством, что никак не влияет на окружающий мир. Такой человек чаще всего ощущает себя маленьким винтиком в механизме, пылинкой в огромной Вселенной. Принципы же дают опору на себя и чувство локтя в сложных ситуациях.

Также принципы помогают избавиться от сомнений по поводу уже принятых решений. Если я выбрал что-то, опираясь на свои принципы, то не страдаю муками из-за альтернативных возможностей. Об этом, кстати, много говорится в философии стоиков - прими решение, сделай действие, а остальное отдай на волю случая (Вселенной, Бога, жизни etc.)

Как формировать свои принципы?

У меня нет чёткого алгоритма, по которому я работаю с принципами. Я просто пытаюсь прожить эту жизнь хорошо и достойно. Но есть некоторые техники, которые мне помогают:

Ведение дневника

Эту практику я стащил у стоиков. Каждый вечер я рефлексирую над прожитым днём и смотрю, что у меня получилось хорошо, а над чем ещё стоит поработать. Главное - смело признавать свои ошибки и недостатки, иначе эффекта от дневника не будет.

Ведение заметок по прочитанному

Я много читаю и пишу заметки, чтобы лучше разобраться в заинтересовавших меня идеях. Путём таких письменных размышлений мои принципы обогащаются и улучшаются. Идеи из книжек могут как дополнять существующие принципы, так и привносить новые.

Общение

Обсуждение является одной из форм осмысления информации. Я люблю обсуждать свои и чужие принципы с друзьями и знакомыми, потому что это обогащает моё понимание мира и себя.

Принципы - важная составляющая моей жизни. Они помогают мне быть более целенаправленным, собранным и удовлетворённым собой. Однако принципам требуется время на то, чтобы стать зрелыми и осмысленными. Поначалу их болтает от вседозволенности до строгого ограничения, и только время да практика делают из них фундамент личности.

«Как быть стоиком», Массимо Пильюччи

Fri, 20 Dec 2024 00:00:00 GMT

Практическая философия является одним из моих ключевых интересов в жизни. Ранее я уже писал, что принципы важнее техник (ссылка на пост). В этом посте я говорил о технологиях, однако та же идея применима и к человеческой жизни — принципы являются нашим внутренним компасом. Поэтому я люблю изучать философию и обогащать свои принципы через размышления. Кстати, книгу Далио «Принципы» я взял с целью позаимствовать некоторые принципы другого человека.

Стоицизмом я интересовался давно, но не слишком успешно. Все мои предыдущие попытки познакомиться со стоиками поближе выглядели так:

Открыть томик Сенеки.
Прочитать две страницы.
Офигеть, грустно вздохнуть, задуматься на полчаса.
Убрать томик Сенеки.
Повторять с интервалом от месяца до полугода.

В один прекрасный момент я понял, что так дальше продолжаться не может, и решил начать с азов. Я хотел разобраться в общей картине стоицизма, прежде чем закапываться вглубь. Интересовала именно общая картина: что такое стоицизм и насколько он применим в повседневной жизни (не люблю я абстрактную философию — подавай мне практику).

Мне нужен был проводник в мир стоиков, и выбор пал на книгу Массимо Пильюччи “Как быть стоиком: Античная философия и современная жизнь”.

О чём книга

Автор книги пытается адаптировать античную философию стоицизма к современным реалиям. Он ставит перед собой задачу показать читателю, что стоицизм не устарел — даже напротив, в современном мире это философское течение стало ещё актуальнее. Вторая задача — продемонстрировать, что быть стоиком в наши дни не сложнее, чем в древности.

В книге раскрываются следующие темы:

история возникновения стоицизма.
основные принципы стоицизма.
место философии стоиков в современном мире.
практическая применимость стоицизма в повседневной жизни.
основные стоические практики и способы их применения.

Три идеи из книги

По мотивам книги я написал больше 20 заметок. Было крайне сложно выделить какие-то три вывода отдельно, поэтому я просто взял случайные понравившиеся мне идеи:

Один из основных принципов стоиков — принцип дихотомии контроля. Он призывает человека чётко разграничивать то, на что он может повлиять, и то, над чем он не имеет власти. От этого принципа ветвятся многие последующие идеи и практики.
Главное в человеке — это его личность, а не “внешняя обвязка”. Любые внешние атрибуты могут исчезнуть в мгновение ока, и только личность остаётся с нами до последнего вздоха.
Целью философии стоиков является проживание достойной жизни. Для этого стоик должен применять разум и развивать свою добродетель, укрепляя её. Инструментом развития является практическая мудрость — умение рефлексировать и делать наилучший выбор в разнообразных жизненных ситуациях.

Мои впечатления

Книга оказалась именно тем проводником в философию стоиков, которого я так искал. Изначально мой вопрос звучал так: “Что такое стоицизм вообще, и есть ли в нём что-то, что я смогу применить в своей жизни?”

Пильюччи в самом начале книги довольно чётко расставляет все точки над i: текст является его личным взглядом и трактовкой стоических идей. Он рассказывает о себе и своём опыте, не претендуя на истину в последней инстанции. Тем не менее его яркие примеры и пояснения помогли мне наконец понять, на что именно направлена философия стоицизма.

В ходе чтения книги я осознал, что стоические практики мне интересны. Более того, многие из них я начал применять в процессе чтения и получил очень любопытные результаты (в частности, в виде ущемлённого эго).

Книгу Массимо Пильюччи я смело рекомендую к прочтению, если вам интересна стоическая философия или вы ищете духовную опору в жизни. Лично мне стоицизм оказался близок, и я пошёл дальше, изучая книги других современных стоиков. Ждите новые обзоры <3

Жопой чую: интуиция как источник гипотез

Wed, 18 Dec 2024 00:00:00 GMT

Интуицию почему-то относят к вещам уровня астрологии и прочей ненаучной нечисти. Однако я считаю, что это большое заблуждение и интуицию нельзя игнорировать.

Интуитивные ощущения появляются благодаря большому опыту и насмотренности в определённой сфере. Мозг учится замечать различные паттерны и подаёт слабые сигналы, когда что-то не так.

Когда вчерашний инженер становится тимлидом, то он переходит в мир тонких материй - коммуникаций, договорённостей, эмоций, отношений и тому подобных вещей. Поскольку многие вещи становятся неявными, роль интуиции тоже растёт.

Как прислушиваться к интуиции?

У меня есть одно простое правило: “Если мне что-то кажется, то мне не кажется”. При возникновении подозрений я предпочитаю пойти и подтвердить или опровергнуть их фактами.

Причина тому проста. Сложность решения проблемы обычно нарастает как снежный ком. Маленькую, едва заметную проблемку можно легко и быстро поправить. Большую и запущенную проблему исправлять будет уже болезненно. Пример из реального мира - здоровье. Зачатки кариеса стоматолог вылечит легко и быстро, а полуразрушенный зуб?

Даже с точки зрения риска проверить подозрение получается выгоднее, чем забить на него. Игнорируя интуицию, я делаю ставку на то, что подозрение ложно. На второй чаше весов лежит некоторый (возможно, серьёзный) риск. Стоит ли игра свеч - придётся решать в каждой ситуации отдельно.

Доверяй, но проверяй

Важно научиться слышать сигналы интуиции и анализировать их, а не просто отмахиваться. Но не менее важно проверять свои догадки и подкреплять их какими-то фактами. Иначе есть риск превратиться или в Вангу, или в лжепророка (как повезёт).

При этом тимлиду нужно не забывать о своей команде. Если постоянно бегать и задалбывать всех вокруг своими подозрениями, то люди в какой-то момент просто устанут и начнут отмахиваться. Получится как в притче, где мальчик кричал: “Волки, волки!”

Если можете проверить своё подозрение самостоятельно, не привлекая лишнего внимания - просто сделайте это. С получением фактов уже можно поговорить с командой и вместе разработать план устранения проблемы.

Пример из найма

Особенно трудно обращаться с интуицией на собеседованиях. Часа разговора недостаточно, чтобы хорошо понять человека, а обе стороны стараются показать лучшие качества.

Однажды в мою команду наняли сотрудника без моего одобрения. Во время общения мне казалось, что что-то не так, но сформулировать причину я не смог. Через полгода с человеком пришлось расстаться из-за сочетания токсичного поведения, саботажа процессов и низкого результата.

Этот случай не доказывает правило «сомневаешься — не нанимай». Интуиция могла попасть в уже знакомый паттерн, а могла просто отразить моё предубеждение. Поэтому сомнение для меня — повод не отказать автоматически, а замедлиться и превратить ощущение в проверяемые вопросы:

какое конкретное поведение меня насторожило;
с какими условиями нашей команды оно может конфликтовать;
чем это можно проверить на следующем этапе;
какой риск мы принимаем, если всё равно нанимаем человека.

Срочная вакансия не делает риск меньше. Она лишь заставляет осознанно решить, готовы ли мы его принять.

Как разбирать ошибки без поиска виноватых

Mon, 16 Dec 2024 00:00:00 GMT

В любой, даже самой простой системе есть пространство для ошибок. В командной работе они неизбежны из-за количества людей, связей и допущений.

Сложность не в том, чтобы вообще избежать ошибок, а в том, чтобы извлекать из них пользу. Наказание заставляет людей скрывать проблемы, а игнорирование позволяет им повторяться. Мне ближе третий вариант: безобвинительный разбор и изменение системы.

Объяснение не отменяет ответственность

Принцип «никто не совершает ошибки специально» помогает не бросаться с обвинениями на того, кто последним коснулся системы. Обычно человек действует в рамках имеющейся информации, опыта, процессов и ограничений.

Но безобвинительность не означает безответственность. Команда всё равно должна восстановить сервис, разобрать причины, выполнить договорённости и изменить процесс. Объяснение ошибки не оправдывает отказ исправлять её последствия.

Преднамеренное нарушение известного правила тоже не стоит автоматически называть саботажем. За ним могут стоять конфликт целей, устаревшая инструкция или давление сроков. Сначала нужно восстановить контекст.

Как написать post mortem

Строгой формы нет. Я начинаю с семи вопросов:

Что, где и когда произошло?
Какие последствия это вызвало?
Как развивались события?
Какие факторы создали условия для ошибки?
Что команда сделала хорошо?
Что можно улучшить?
Какие шаги мы предпримем дальше?

Важно отделять факты от оценок. Фраза «инженер невнимательно выкатил релиз» не объясняет ничего. Намного полезнее знать, какие шаги он выполнил, какую информацию видел и почему процесс не остановил ошибку.

Разбор должен закончиться изменением

После написания post mortem команде стоит его обсудить и дополнить. На выводы из последнего вопроса нужно поставить задачи, назначить ответственных и потом проверить выполнение. Иначе разбор останется разговором.

Ошибка становится уроком не в момент, когда её обсудили, а когда команда изменила процесс и проверила, что новая защита работает.

Менторство как драйвер профессионального роста команды

Mon, 16 Dec 2024 00:00:00 GMT

Доклад о том, как превратить менторство из случайной помощи коллег в систему профессионального роста команды. Он предназначен для руководителей, которые хотят развивать сотрудников, передавать экспертизу и при этом не превращать наставничество в ещё одну обязательную формальность.

О чём выступление

Какие задачи команды решает менторство и где от него не стоит ждать чуда.
Как оценить цели и зоны роста сотрудников.
Как выбрать наставников и почему участие должно оставаться добровольным.
Как договориться о формате работы, обратной связи и отслеживании прогресса.
Какие ошибки превращают менторство в контроль или пустую формальность.

Ниже собраны исследования и полезные ссылки, которые я использовал при подготовке доклада.

Исследования из доклада

Case Study: Workforce Analytics at Sun — оригинал исследования Gartner, доступ по подписке.
Sun Mentoring: 1996–2009 — white paper о менторстве в Sun.
CNBC/SurveyMonkey Workplace Happiness Index — исследование удовлетворённости работой.
Nine in 10 workers who have a career mentor say they are happy in their jobs — анализ результатов исследования CNBC и SurveyMonkey.
Менторство в IT: 73% опытных специалистов становятся наставниками — исследование Хабр Карьеры.

Дополнительные материалы

Statistics on Mentorship: The Latest Research on Employee Development — сводка исследований по менторству.
Seven Keys To Creating A High-Impact Mentoring Program — статья о построении менторской программы.
How To Know If You’ll Be A Great Mentor — короткий список характеристик сильного ментора.
Defining the Ideal Qualities of Mentorship — исследование качеств выдающихся менторов; материал у меня пока лежит на будущее.

«Хватит мечтать, займись делом», Кэл Ньюпорт

Fri, 13 Dec 2024 00:00:00 GMT

Книги Кэла Ньюпорта мне нравятся своей прямотой. Он честно высказывает своё мнение и делится своим опытом, хотя его тексты иногда звучат резковато. Однако лично мне каждая его книга даёт много пищи для размышлений.

Ранее я уже писал обзор на его прекрасную книгу «В работу с головой» о важности глубокого погружения в работу. «Хватит мечтать, займись делом» я взял, чтобы познакомиться со взглядом Ньюпорта на работу мечты и то, как её найти в жизни. Вопрос для меня актуальный, потому что я много лет страдал от синдрома самозванца и иногда чувствовал себя как Буриданов осёл, не в силах сделать выбор.

О чём книга

Книга рассказывает о двух подходах к работе: подходе мечтателя и подходе мастера. Подход мечтателя (крайне популярный) звучит так: найди работу мечты, и тебе не придётся работать ни дня в жизни (неправильно понятый Конфуций в гробу вертится).

Ньюпорт убедительно показывает, почему, по его мнению, этот подход нежизнеспособен. В качестве альтернативы он предлагает рассмотреть подход мастера, который заключается в том, чтобы наращивать свои навыки и благодаря этому получать всё более привлекательную работу.

В книге раскрываются следующие темы:

Почему гнаться за работой мечты — это путь в никуда.
Что такое карьерный капитал и как его наращивать.
Как обменивать карьерный капитал на работу мечты.
Способы постоянного наращивания профессионализма.
Влияние личной миссии на карьеру.

Три вывода из книги

Если гнаться за мечтой, можно легко оказаться в тупике и попасть в ловушку вечного разочарования, потому что мир не идеален. К тому же погоня за мечтой подпитывает эго.
Главное — это профессиональное мастерство. Работа мечты встречается редко, и за неё нужно заплатить карьерным капиталом. Моя работа становится для меня интереснее всего в те моменты, когда я сосредоточен на процессе и делаю лучшее из того, на что способен. И наоборот, когда начинаю думать о «работе мечты», я неизбежно расстраиваюсь и впадаю в плохое настроение.
Чем бы вы ни занимались, подходите к работе как истинный мастер: везде ищите возможности для роста и обучения. Станьте работником, которого невозможно не заметить.

Мои впечатления

Основная идея книги довольно проста: вместо стремления к лучшей работе стремись лучше работать — остальное приложится. Звучит просто, однако на практике такой подход требует дисциплины, усердия, терпения и открытости.

Ньюпорт довольно детально (при этом без лишней воды) разбирает как подход мечтателя, так и подход мастера, показывая преимущества и недостатки каждого. При этом он не подаёт подход мастера как лекарство от всех болезней и серебряную пулю. Он честно показывает, что этот путь труден и подойдёт не всем, но потенциальная награда за него очень высока.

Мне нравится концепция рыночных отношений, которую Ньюпорт закладывает в подход мастера. Хочешь работу мечты — будь готов заплатить за неё ценными профессиональными навыками и знаниями. Это звучит как честная сделка.

Конечно, порой бывает, что недостаточно квалифицированные люди занимают какие-то крутые позиции. Но счастливы ли они там? Вряд ли. Здесь будет уместно вспомнить книгу “Поток”, в которой говорится, что для получения счастья и удовольствия от работы нужен баланс сложности задач и профессиональных навыков. Если задачи слишком сложные, человек будет находиться в постоянном стрессе, и ни о какой радости от работы не может быть и речи.

На мой вопрос книга ответила полностью. Как минимум, я убедился, что нахожусь на правильном пути и правильно смотрю на мир (или попал под confirmation bias :)). А ещё я обогатил понимание своих принципов работы идеями, которые почерпнул из книги.

Если вы периодически испытываете неудовлетворённость от своей деятельности, будь то работа, хобби или свой проект, я очень рекомендую прочитать эту книгу. Она небольшая, но пищи для размышлений даёт предостаточно.

1-1 с Антоном Непшей. Два стула тимлида: техничка или менеджмент?

Mon, 09 Dec 2024 00:00:00 GMT

Разговор с Антоном Непшей о том, что происходит с техническими навыками после перехода в тимлиды и как не разорваться между работой инженера и руководителя. Антон руководит компетенцией frontend-разработки в Сбере, развивает внутреннее сообщество и ведёт свой канал.

О чём разговор

Должен ли тимлид быть лучшим программистом в команде.
Какие технические навыки ухудшаются после перехода в управление, а какие продолжают расти.
Как поддерживать нужный уровень технических знаний.
В каких ситуациях тимлид может вообще не писать код.

Отдельно мы разобрали страх потерять техническую форму. По моему опыту, тревогу чаще вызывает не сама просадка, а непонимание, какие именно навыки могут ухудшиться, что с этим делать и нужно ли вообще пытаться сохранить всё.

«Принципы», Рэй Далио

Fri, 06 Dec 2024 00:00:00 GMT

Мне всегда интересно узнать принципы, которыми руководствуются другие люди. Именно их я стараюсь понять в личном общении (и даже в переписке). Для меня принципы — это правила жизни, которые человек выбирает самостоятельно, осознанно и которыми руководствуется в принятии повседневных решений.

При всей неоднозначности персоны Рэя Далио было бы просто глупо отрицать, что этот человек добился успеха в некоторых областях жизни и у него есть чему поучиться. Поэтому я взял его книгу “Принципы” в надежде найти для себя что-то полезное.

О чём книга

Структурно книга разделена на три большие части.

Первая часть посвящена автобиографии Рэя Далио и его воспоминаниям. Он рассказывает, как стал тем, кем стал, и какой путь в жизни прошёл.

Вторая часть посвящена его жизненным принципам. Здесь автор перечисляет пять основных принципов, которыми руководствуется. Каждый принцип раскрывается примерами и пояснениями, а также содержит подпринципы (или принципы второго порядка — как больше нравится).

Третья часть (самая большая, почти 50% книги) содержит принципы работы Далио. Она дополнительно разбита на три блока: правильная корпоративная культура, правильные люди, создание и совершенствование механизма. В этой части содержатся принципы и советы по организации работы в стиле Рэя Далио.

В книге раскрываются следующие темы:

Биография Рэя Далио.
Как принимать реальность и работать с ней?
Как и зачем сохранять непредубеждённость?
Что такое корпоративная культура и как она влияет на работу организации?
Работа с людьми: найм, развитие, увольнения.
Развитие организации и устранение проблем.

Три вывода из книги

Любая сложность или ошибка — это головоломка, за решение которой полагается награда. Награда — понимание какого-то принципа устройства мира и возможность не совершать такую же ошибку повторно.
Люди действуют на основе своих принципов и убеждений, поэтому каждое действие человека содержит информацию о нём. Наблюдение за действиями, а не словами людей может многое о них рассказать.
Тяни за каждую подозрительную ниточку и доверяй своей интуиции. Если кажется, что где-то что-то идёт не так, лучше пойти и перепроверить. Мелкие неприятности могут быть предвестниками серьёзных проблем.

Мои впечатления

Я подошёл к книге с завышенными ожиданиями, потому что её нахваливали все вокруг. Скажу честно — я скорее разочарован.

Первые 25% книги посвящены самолюбованию и пересказу биографии в выгодном для автора свете. Далио пытается выставить себя человеком, который получил всё, опираясь исключительно на свои принципы. Но при этом он не раскрывает некоторые крайне важные детали своей биографии (например, каким образом Bridgewater получил в управление активы пенсионных фондов).

Вся оставшаяся часть книги по большей части представляет собой довольно “водянистые” success stories по поводу тех или иных принципов. Читая эти главы, нужно помнить, что всё написанное — это конкретный опыт конкретного человека. В процессе чтения постоянно приходится держать в голове “ошибку выжившего”: то, что когда-то сработало у Далио, может быть просто статистическим выбросом.

Многие из его принципов — это скорее советы, причём не все из них практичны и полезны. Это нормально: все люди разные, и даже сам Далио где-то в книге упоминает, что его идеи — не панацея от всех бед. Однако текст книги написан в противоположном духе: каждая мысль подаётся как что-то невероятное.

Тем не менее, книга содержит много хороших и полезных идей, которые я себе утащил и глубоко обдумал в своих заметках. От многих из этих мыслей явно веет стоицизмом.

Мне также понравилось, что все идеи и мысли Далио довольно прикладные. В книге нет увещеваний на тему “мир во всём мире” и “любовь ко всему живому и неживому”. Далио — довольно циничный практик, и это ощущается в тексте. По-своему это полезно: читателю не приходится ломать голову над абстракциями.

Вывод

Ознакомиться с книгой в целом будет полезно. Я бы рекомендовал следующий формат чтения: первую часть пропустить полностью, из второй и третьей читать только идеи без описания ситуаций их применения, но обдумать место для каждой из идей в своей жизни.

В более продвинутом варианте я бы рекомендовал сначала почитать что-то из современного стоицизма (например, того же Массимо Пильюччи), а уже после этого ознакомиться с “Принципами” Далио. Вот это точно будет интересный опыт! :)

«Канбан Метод. Базовая практика», Алексей Пименов

Fri, 29 Nov 2024 00:00:00 GMT

У меня сложилась довольно интересная ситуация: я давно работаю «по канбану» (позже объясню, почему кавычки), но никогда глубоко в него не вникал. Все мои знания о методе были обрывочными, поэтому я решил систематизировать их. Руководитель порекомендовал мне прочитать книгу Алексея Пименова «Канбан Метод», что я и сделал.

О чём книга

Книга посвящена практическому применению Канбан-метода. Она адресована руководителям производственных процессов (в принципе, любых), которые отвечают за производительность команды, подразделения, цеха — чего угодно.

Сам Алексей направляет свою книгу в первую очередь на специалистов в сфере умственного труда, где результаты работы сложно «пощупать». Это требует визуализации процесса, чтобы сделать его понятным и прозрачным.

В книге раскрываются следующие темы:

Почему так сложно управлять нематериальным производством?
В чём заключаются основные принципы и практики Канбан-метода?
Как начать использовать Канбан в своей работе?
Как выстроить системную работу с помощью Канбана?
Как анализировать и улучшать Канбан-системы?

Три главных вывода из книги

Строить систему вокруг работы, а не вокруг людей. Управление производственным процессом — это управление самой работой, а не попытка максимально загрузить каждого сотрудника (об этом ещё Элияху Голдратт писал в “Цели”).
Не нужно изобретать процесс с нуля. Начинайте с того, что уже есть, и сделайте это явным с помощью визуализации, каденций и других практик.
Главный фокус — стабильная поставка клиентской ценности. Вся система строится вокруг предоставления ценности заказчику. Всё остальное — второстепенно. Задача производственного процесса — дать клиенту то, за что он платит.

Мои впечатления

Мне очень понравилась книга Алексея. Она отлично структурирована и написана простым, понятным языком. Автор последовательно проводит читателя через все ключевые этапы: от осознания проблемы до внедрения и поддержки решения.

Книга изобилует примерами из практики, что делает её ещё более полезной. Особенно меня заинтересовали графики анализа незавершённой работы в разделе об улучшении Канбан-систем. Однако каждый раздел богат на примеры, которые объясняют идеи автора. Что особенно приятно — примеры живые, «настоящие», а не вымышленные и искусственные.

По сути, книга даёт отличный верхнеуровневый обзор Канбан-метода. Конечно, некоторые темы раскрыты поверхностно (например, управление изменениями), но это логично. Во-первых, книга изначально не ставит целью углубляться в каждую тему. Во-вторых, если рассматривать все аспекты Канбана подробно, это превратилось бы в Большую Советскую Энциклопедию.

Лично мне не хватило ссылок на дополнительные материалы, чтобы глубже изучить отдельные части Канбан-метода. Это не критично, но всегда интересно знать, на чём автор основывал своё творчество. Любителям «копнуть глубже», как я, придётся самим отправляться в интернет и искать исследования, книги и опыт компаний.

Книга получилась очень полезной, и я рекомендую её всем, кто так или иначе управляет производственными процессами. Принципы Канбана будут актуальны даже для тех, кто работает по Scrum, LeSS, Waterfall или вообще в условиях хаоса.

Как понять, что вас поняли

Mon, 25 Nov 2024 00:00:00 GMT

Вы когда-нибудь сталкивались с ситуацией, когда вроде бы всё объяснили, а собеседник понял вообще другое? Это классическая проблема коммуникации: между тем, что я подумал, и тем, что понял другой человек, часто возникает разрыв.

Особенно дорого этот разрыв обходится при постановке задач. Человек может не до конца понять ожидания или интерпретировать их через собственный опыт. В лучшем случае потребуется несколько правок, в худшем — задачу придётся основательно переделывать.

Где искажается информация

Любая передача информации проходит четыре этапа:

То, что я подумал.
То, что я сказал.
То, что собеседник услышал.
То, что собеседник понял.

На каждом этапе возможны искажения:

подумал одно, а сказал другое;
собеседник слушал невнимательно или вырвал часть мысли из контекста;
услышанное прошло через его опыт и превратилось в другую мысль.

Я легко могу вспомнить ситуации, где попадал в каждую из этих ловушек. Самые сильные деформации происходят, когда я не могу чётко сформулировать мысль, а собеседник меня ещё и невнимательно слушает. Между первым и четвёртым пунктами тогда возникает настоящая пропасть.

Поэтому недостаточно передать человеку информацию. Нужно ещё проверить, одинаково ли мы её понимаем.

Техника обратного резюмирования

Один из самых простых способов проверить понимание — попросить человека пересказать суть задачи своими словами. Этот приём называется техникой обратного резюмирования.

Чтобы пересказать задачу, человеку придётся:

Вспомнить ключевые факты.
Выстроить между ними причинно-следственные связи.
Рассказать, как он собирается выполнять задачу.
Собрать всё это в связное объяснение.

В ходе пересказа сразу становятся видны несостыковки. Человек может запинаться, задавать уточняющие вопросы, говорить путано или даже совсем не то, что вы имели в виду. Это нормально: техника как раз и нужна, чтобы обнаружить проблемы до начала работы.

Обратное резюмирование работает и в другую сторону. Можно самому пересказать слова собеседника и попросить проверить, правильно ли вы его поняли.

«Но это же бесит!»

Когда я рассказываю об этой технике, то часто слышу опасение: «Собеседник решит, что я считаю его тупым».

Такое действительно может случиться. Всё зависит от подачи. Вопрос «Понял? Ну-ка расскажи, что ты понял» скорее вызовет раздражение.

Поэтому важно объяснить своё намерение и взять ответственность за качество объяснения на себя:

Я хочу убедиться, что смог нормально объяснить задачу. Расскажи, пожалуйста, как ты понял сказанное, чтобы мы проверили, что одинаково всё понимаем.

Тогда пересказ становится не экзаменом для собеседника, а обратной связью для того, кто ставит задачу.

Что ещё помогает уменьшить искажения

Учиться чётко формулировать мысли.
Отслеживать непонимание и задавать уточняющие вопросы.
Просить собеседника пересказать услышанное своими словами.
Самому резюмировать сказанное и просить проверить пересказ.

Информация искажается очень легко. Поэтому «и так понятно» — не проверка понимания. Иногда минутный пересказ экономит часы переделок.

«Разреши себе скучать», Мануш Зомороди

Fri, 22 Nov 2024 00:00:00 GMT

После прочтения книги Кэла Ньюпорта «В работу с головой» я заинтересовался темой скуки. Ньюпорт многократно упоминал, что мозгу нужна разгрузка для переваривания информации (поэтому озарения приходят в дУше). Я решил покопать эту тему чуть поглубже и взял почитать книгу Мануш Зомороди, “Разреши себе скучать”.

О чём книга

Книга целиком и полностью посвящена теме скуки, которой так мало осталось в современном мире. Пожалуй, основная задача книги - помочь читателю отвоевать хоть какое-то пространство для “просто поскучать” в бесконечном окружении уведомлений, мерцаний и цифровых искушений.

В книге раскрываются следующие темы:

Зачем скука нужна мозгу
Есть ли связь между смартфоном и СДВГ
Обесценивание живого общений и его влияние на людей
Почему так важно сохранять концентрацию и как это делать
Как шаг за шагом отвоёвывать своё внимание у стимулов современного мира

Также каждая глава книги заканчивается вызовом - упражнением, которое позволяет немножко уменьшить давление технологий и информационного потока на наше внимание.

Три идеи из книги

Пока я скучаю - мозг переваривает информацию. Когда моё внимание не занято ничем конкретным, мозг переходит в режим “блуждания” и занимается перевариванием/структурированием информации.
Чем меньше времени на скуку - тем меньше креативности, потому что мозг просто не успевает справиться с нагрузкой. Поэтому один из способов разблокировать свою креативность заключается в создании обстановки скуки (уехать за город без смартфона).
Альтернативой скуке может выступать медитация блуждающего внимания - просто наблюдать за всем вокруг, отмечать наблюдения и ни о чём конкретно не думать.

Мои впечатления

Книжка неплохая, но на мой вкус довольно водянистая. Очень много историй “great success”. Однако ценные мысли в ней однозначно есть.

Сама тема цифровой и информационной гигиены очень сложная и актуальная. В последние несколько лет я стараюсь содержать в чистоте своё информационное пространство, и это невероятно тяжёлый труд. Постоянно появляются какие-то поглотители внимания и возмутители спокойствия.

Справляться мне помогает осознанность: я понимаю, что что-то идёт не так, и начинаю анализировать причины. Чаще всего этот процесс заканчивается очередной масштабной чисткой источников информации, закладок, тудушек, списков книг и прочих свалок.

Я считаю, что эту книжку стоит прочитать всем, кто страдает от цифровой зависимости и не представляет своей жизни без смартфона в руках. Возможно, книга не даст всех ответов, но хотя бы заставит задуматься в нужную сторону. Также предложенные упражнения - неплохой вариант “потыкать палочкой” свою цифровую зависимость и посмотреть, что же получится.

Сильно вчитываться не рекомендую, воды многовато. Но пару идей подхватить вполне можно.

Читали книгу? Как вам?

1-1 с Дашей Корчугановой. Встречи 1-1, которые работают

Wed, 20 Nov 2024 00:00:00 GMT

Разговор с Дашей Корчугановой о встречах 1-1: зачем они нужны руководителю и сотруднику, как не превратить их в формальность и когда от регулярного формата лучше отказаться. Даша руководит командой разработки Газпромбанк Бизнес-Онлайн и больше семи лет занимается frontend-разработкой.

О чём разговор

Как регулярные 1-1 влияют на сотрудника и команду.
О чём говорить, чтобы встреча приносила пользу.
Что делать, если встречу провести нужно, а сил у руководителя нет.
Как начать проводить 1-1 без лишнего напряжения.
Когда регулярные встречи не нужны.

Отдельно мы обсудили корректирующую обратную связь: как говорить о проблеме прямо, но не превращать 1-1 в разбор полётов, которого сотрудник заранее боится.

«Учись как профи», Дэн Уиллингем

Fri, 08 Nov 2024 00:00:00 GMT

Лично я очень люблю учиться. Меня приводит в дикий восторг изучение чего-то новенького и увязывание этого с тем, что я уже знаю. Я настолько люблю учиться, что постоянно учусь учиться и ищу новые методы, как сделать этот процесс эффективнее.

Поэтому сегодня у меня в обзоре — прекраснейшая книжка Дэна Уиллингема “Учись как профи”.

О чём книга

Книга в основном предназначена для студентов, которым предстоит усваивать много материала по разным предметам, а затем сдавать контрольные работы, экзамены, практику и прочие стандартные для высшего образования задачи.

В книге раскрываются следующие темы:

Как работать на лекциях и практических занятиях, чтобы понимать как можно больше.
Ведение записей и работа с ними для усвоения материала.
Самостоятельное обучение по сложным книгам.
Экзамены: подготовка, сдача, пост-анализ.
Борьба с прокрастинацией при учёбе.
Ослабление тревоги перед экзаменами.
Дополнительно каждая тема рассматривается с точки зрения преподавателя: как облегчить учёбу и понимание своим студентам.

Три вывода из книги

Для понимания разрозненных элементов материала очень важно устанавливать между ними связи, будь то на лекции или при чтении книги. Полезно даже в своём конспекте рисовать и подписывать связи.
Один из самых важных навыков для обучения — задавать вопросы. Это навык, который требует целенаправленного развития.
Лучшая техника запоминания — это глубокое понимание самого материала и причинно-следственных связей в нём. Если дополнить понимание интересом, запоминание практически гарантировано.

Мои впечатления

Как бы я хотел, чтобы эта книга попала ко мне в руки во времена университетской скамьи! Конечно, многие из этих вещей я хорошо прочувствовал на собственном опыте (ещё в школе домашка занимала от силы полчаса, потому что на уроках я разбирался в материале вместо написания огромных конспектов). Однако эта книга может стать настоящим сокровищем для школьников старших классов и студентов.

Уиллингем акцентирует внимание на том, что для запоминания материала лучше всего в нём хорошенько разобраться. Конечно, мнемотехники могут помочь в экстренных случаях (когда экзамен завтра), однако более эффективно — учиться вовремя и не доводить до такого.

Для взрослого человека книга несёт меньшую ценность, потому что нам не так часто нужно сдавать экзамены. Однако даже нам приходится периодически проходить различные тестирования на обучающих курсах, да и собеседования по программированию часто напоминают университетский экзамен с оценкой за формальные “галочки”. Поэтому, на мой взгляд, в этой книге найдёт пользу каждый человек, которому приходится по работе изучать что-то новое.

«Ненасильственное общение», Маршалл Розенберг

Fri, 01 Nov 2024 00:00:00 GMT

Огромная часть работы менеджера - это общение. Но общение может быть очень разным и оставлять после себя целый спектр ощущений. Как же выстроить продуктивное и здоровое общение?

На эту тему написано множество книг, что лишь подтверждает её актуальность. И сегодня я расскажу про одну из таких книг - “Ненасильственное общение” Маршалла Розенберга.

О чём книга

Маршалл Розенберг в своей книге предлагает модель ненасильственного общения, которая позволяет выстроить эмпатичное, доброжелательное, основанное на взаимопонимании общение.

В книге содержатся следующие темы:

Что такое ненасильственное общение и чем оно отличается от обычного общения.
Какое общение мешает сопереживанию и эмпатии.
Наблюдение за другими без оценивания.
Принятие ответственности за свои чувства, их осознание и выражение.
Как по-здоровому выражать свои просьбы.
Эмпатия и её сила в общении.
Как выражать гнев по-здоровому.
Разрешение конфликтов с применением ННО.

Для меня все эти вопросы были крайне актуальны, и книга дала достаточно хорошие, подробные ответы на них.

Топ-3 вывода из книги

За любым словом, действием или эмоцией человека всегда стоит неудовлетворённая потребность. Переводя разговор на уровень потребностей, мы получаем возможность помочь человеку.
Осуждение, оценки, сравнения и тому подобные вещи мешают установке контакта и сопереживанию между людьми.
Каждый человек сам несёт ответственность за свои чувства, мысли и действия.

Мои впечатления

Прочитал я книгу быстро, а вот переваривал несколько месяцев - настолько насыщенной она мне показалась. Я написал по ней около 20 заметок и до сих пор обдумываю некоторые вычитанные концепции.

Книга очень полезная и практико-применимая, но применять её довольно непросто. Пока читаешь - всё в целом понятно, кажется простым и очевидным. Но на практике сразу же возникают вопросы, сложности, недопонимания. Я начал применять прочитанное в книге практически сразу и постоянно сталкивался с тем, что не понимаю, как правильно поступить в той или иной ситуации. Самый большой эффект дали именно сами попытки применять - я начал задумываться о своих эмоциях, мыслиях и потребностях, а через некоторое время смог переносить это на других людей.

Также ценными для меня оказались главы про эмпатию, просьбы и проживание гнева. Я получил идеи для улучшения по каждому из этих пунктов - особенно про осознание и проживание гнева (страдаю от раздражительности иногда).

Я очень рекомендую прочитать и попытаться применить эту книгу всем руководителям, потому что навыки ненасильственного общения мне кажутся крайне полезными в ежедневной работе. Лично я проникся техниками ННО и регулярно применяю их в жизни. Получается по-разному, но результаты мне нравятся.

Делегирование без чайка-менеджмента

Wed, 30 Oct 2024 00:00:00 GMT

Когда я только учился делегировать, то каждый раз испытывал дикий страх за результат и превращался в микроменеджера. Вроде отдал задачу человеку, а сам постоянно его дёргаю.

Мне казалось, что я делаю полезную работу: нахожусь в курсе всех задач, всё контролирую и лихо жонглирую приоритетами. Спасибо команде, которая честно рассказала, как же я задолбал её своим контролем.

Откуда берётся руководитель-чайка

Другой человек гарантированно выполнит задачу не так, как выполнил бы я. Результат может быть лучше или хуже, появиться раньше или позже. Именно эта неопределённость и вызывает желание постоянно вмешиваться.

По моим наблюдениям, чайка внутри руководителя особенно любит две ситуации:

Всё хорошо: «Я ничего не делаю, тимлид не нужен, меня уволят».
Всё плохо: «Всё пропало, если не вмешаюсь, меня уволят».

В обоих случаях налёты успокаивают самого руководителя, но мешают команде. Когда всё работает, он создаёт суету и отнимает самостоятельность. Когда возникла проблема, добавляет стресса людям, которым и без того нужно исправлять ситуацию.

Контроль заменить договорённостями

Мне помогли несколько вещей.

Честно сказать команде, что я учусь делегировать. Я попросил сразу сообщать, когда снова скатываюсь в микроменеджмент.
Договориться о точках контроля заранее. Дейлика может быть достаточно, а для рискованной задачи можно отдельно согласовать промежуточный результат. Главное, чтобы проверка не стала неожиданным налётом.
Не забирать работу при первом отклонении. Другой способ решения ещё не означает плохой результат.
Заняться системой. Вместо хождения по задачам руководитель может устранять блокеры, улучшать процесс и готовить команду к следующим изменениям. Подробнее об этой роли я пишу в лонгриде «Руководитель управляет процессами».

Объяснить, что значит «готово»

Иногда человек приносит результат, а руководитель думает: «Это не то, что я хотел». Другой человек гарантированно решит задачу не так, как решил бы я, поэтому совпадение с картинкой в моей голове нельзя считать договорённостью.

Перед делегированием я стараюсь ответить на вопрос:

Как я пойму, что задача готова?

Ответ превращается в критерии результата: конкретные и наблюдаемые признаки, по которым работу можно принять. «Результат должен удовлетворять моё чувство прекрасного» — так себе критерий, потому что исполнителю будет сложно в него попасть.

Уровень детализации зависит от задачи и самостоятельности человека. Для опытного специалиста достаточно обозначить результат и ограничения. Джуну может понадобиться больше контекста и промежуточных точек. В R&D-задаче критерий иногда остаётся намеренно широким, потому что заранее неизвестно, существует ли нужное решение.

Если результат разошёлся с ожиданием, это не всегда автоматически вина руководителя или исполнителя. Но первым делом стоит проверить договорённость: был ли ожидаемый результат вообще вынесен из головы и понятен обеим сторонам.

Я в своё время поступил кардинально: признался команде в микроменеджменте, попросил обратную связь и дал людям спокойно работать. Через пару недель мир не рухнул. А команда сказала, что с новым уровнем самостоятельности и доверия ей нравится гораздо больше.

Делегирование не требует отказаться от контроля. Оно требует заменить тревожные налёты понятными договорённостями об ответственности, результате и моменте, когда действительно нужна помощь руководителя.

Как работать с отказами систем в BFF: основные паттерны отказоустойчивости

Mon, 28 Oct 2024 00:00:00 GMT

Доклад о том, как BFF ведёт себя при сбоях зависимых сервисов и какие паттерны помогают ограничить последствия отказа для системы и пользователя. Примеры реализации написаны на TypeScript.

О чём выступление

Как проекты приходят к BFF и какова цена его внедрения.
Что может пойти не так в распределённой системе.
Как Timeout или Deadline ограничивает время выполнения запроса.
Как Retry сглаживает разовые и краткосрочные сбои.
Как Circuit Breaker защищает сбоящий сервис от дополнительной нагрузки.
Какие ограничения есть у каждого паттерна и как выбранная стратегия влияет на UX.
Как реализовать эти паттерны на TypeScript.

Паттерны нельзя применять по отдельному чек-листу: повторный запрос способен усилить перегрузку, слишком короткий timeout — оборвать полезную работу, а fallback — скрыть проблему. Поэтому в докладе я рассматриваю не только реализацию, но и цену каждого решения.

«В работу с головой», Кэл Ньюпорт

Fri, 25 Oct 2024 00:00:00 GMT

Вопрос личной продуктивности всегда казался мне важным. Поэтому я стараюсь изучать всё адекватное, до чего могу дотянуться. Книги Кэла Ньюпорта мне рекомендовали многие, поэтому я и решил его почитать. Спойлер — ни капли не пожалел.

О чём книга

В книге рассказывается о глубокой работе — процессе, когда человек занимается только важными для него задачами и не отвлекается на внешние раздражители. Ньюпорт считает, что самые важные и ценные достижения возможны именно в результате глубокой работы.

По его мнению, глубокая работа настолько значима, что ради неё стоит отбросить всё малозначительное (Ньюпорт называет глубокую работу ключевым навыком XXI века). Фактически он предлагает планировать своё время вокруг состояния максимальной концентрации. Даже отдых, по его мнению, должен быть таким, чтобы способствовать восстановлению для дальнейшей глубокой работы.

В качестве примеров Ньюпорт приводит известных личностей: Карла Густава Юнга, Дональда Кнута, Адама Гранта. Также он много рассказывает о своём опыте глубокой работы и её влиянии на его жизнь и достижения.

Три вывода из книги

Глубокая работа — это работа в состоянии максимальной концентрации над важными задачами. В процессе глубокой работы растёт мастерство, и создаются значимые результаты.
Глубокая работа настолько важна, что имеет смысл планировать весь день вокруг неё. Особенно учитывая, что много такой работы в день не сделать.
Основой глубокой работы является навык концентрации, который можно развивать с помощью медитации и глубокой работы. Концентрацию ослабляют отвлечения и развлечения: соцсети, чаты и прочие “залипалки”.

Мои впечатления

Книга мне очень понравилась, потому что мой опыт перекликается с тем, о чём говорит Кэл Ньюпорт. Самые сложные и интересные вещи в своей жизни я создавал в состоянии максимальной концентрации, не отвлекаясь на посторонние раздражители. Более того, мне знакомо чувство удовлетворения после сеанса сконцентрированной работы.

Помимо самой концепции и её доказательств, Ньюпорт предлагает несколько способов увеличить количество глубокой работы в жизни. Он идёт от примеров конкретных людей к техникам, что позволяет читателю выбрать подходящие идеи для реализации.

Также Ньюпорт затрагивает тему отдыха. Работа в состоянии высокой концентрации — энергозатратное занятие, поэтому восстановление становится особенно важным.

На выходе из книги складывается цельная картина: появляется понимание того, что такое глубокая работа, как её планировать и интегрировать в свою жизнь. Я ушёл с большим количеством идей и потенциальных экспериментов, а многие из них пробовал реализовать прямо по ходу чтения. Результаты получились очень интересные.

Книгу настоятельно рекомендую всем, кто в конце дня чувствует, что “занимался какой-то ерундой” или “опять ничего не сделал”. Мне она помогла вернуть контроль над своим временем.

Автономность мотивирует лучше печенек

Mon, 21 Oct 2024 00:00:00 GMT

Одна из вещей, с которыми работает тимлид, — мотивация команды. Но мотивацию не получится накачать насосом, как воздушный шарик: она состоит из множества факторов.

База — достойная оплата и нормальные рабочие условия. Если человек откровенно недополучает денег или тратит по два часа на дорогу в одну сторону, никакие печеньки и «дружный коллектив» не помогут. Но когда база закрыта, значение приобретают автономность и признание профессионализма.

Идеальные команды с идеально выстроенными процессами существуют только в идеальном вакууме. Всегда есть шероховатости: процессы не успевают за бизнесом, копится технический долг, людей становится больше и тимлид начинает захлёбываться. В любой команде остаётся пространство для улучшений.

На встрече один на один можно спросить человека, что стоит изменить, чтобы команде жилось легче. Здесь есть первый подвох: если сотрудник раз за разом делится идеями, но ничего не происходит, его мотивация угасает. Зачем генерировать идеи, которые никому не нужны?

Поэтому следующий вопрос звучит так: какие из этих идей человек сам хотел бы реализовать?

В моей практике были такие примеры:

тестировщица прошла курс по UX и исправила множество недочётов в продукте;
бэкендер залез в автотесты, распараллелил их и ускорил прохождение джоба в три раза;
аналитик начал проводить отличные ретроспективы для команды.

Люди занимались этим с удовольствием, а затем получали признание за результат. У них появлялось ощущение свободы действий — можно безопасно предлагать идеи — и уважения к профессионализму: предложение услышали и дали довести до результата.

Но автономность нельзя превращать в бесплатную дополнительную нагрузку. Если улучшение важно для команды, под него нужно выделить время и место в плане, а не предложить сотруднику заняться им после основной работы. И если человек не хочет брать инициативу, это его право.

Не все эксперименты окажутся удачными. Заранее знать результат невозможно, поэтому я предпочитаю быстро проверить идею и разобрать последствия. Ценность здесь не в «мотивации бесплатно», а в возможности влиять на среду и отвечать за улучшение, которое сам считаешь важным.

«Эмоциональный интеллект», Дэниел Гоулман

Fri, 18 Oct 2024 00:00:00 GMT

Что делать, если эмоциональный диапазон как у зубочистки? На этот вопрос нам сегодня будет отвечать Дэниел Гоулман, автор известной книги “Эмоциональный интеллект”. Я прочитал её пару месяцев назад и спешу поделиться с вами выводами и инсайтами.

О чём книга

Книга рассказывает о таком понятии, как “эмоциональный интеллект”. Вкратце его можно определить как способность понимать и осознавать свои эмоции и эмоции других людей. “Интеллект” мне кажется слишком громким словом в этом контексте, я бы скорее заменил термин автора на “эмоциональную осознанность”.

В книге много рассказывается о том, как эмоции влияют на нашу жизнь и принимаемые решения, а также приводятся неплохие практические советы по проживанию эмоций (мне были полезны идеи по работе с гневом).

Три вывода из книги

Эмоции — корень всего, что происходит у нас в голове. Эмоции порождают мысли, мысли порождают действия.
По уровню базовой эмоциональной осознанности мы всё ещё пещерные люди. Многие наши автоматические эмоциональные реакции когда-то были залогом выживания, но в современном мире могут сильно мешать жить.
Эмоциональный интеллект можно и нужно развивать. На помощь придут практики осознанности, психотерапия и ведение дневника.

Мои впечатления

Тема эмоционального интеллекта мне, как руководителю, кажется крайне важной. Мы, люди, не роботы. Отбрасывая эмоции в общении с коллегами и подчинёнными, можно совершить кучу грубых ошибок и испортить отношения. Наверняка каждый из нас может вспомнить ситуации, когда его чувства проигнорировали. Как ощущения были?

Эмоциональную осознанность нужно развивать, чтобы не повторять подобных ситуаций самому. Эмпатия к другим начинается с умения понять и принять свои собственные чувства. Если человек болеет, стоит отнестись к нему с пониманием, а не давить на него срочными и горящими задачами.

По содержанию книга, конечно, далека от идеала. Лично мне она показалась довольно однобокой, поверхностной и переполненной “историями успеха”, как типичный “бестселлер Амазон”. Плюс мне не очень понравилось, что Гоулман в первой же главе аргументирует недоказанной теорией “эмоционального мозга”. Но на общую картину это не влияет.

Также меня не покидало ощущение, что Гоулман откровенно пытается хайпануть на сравнении эмоционального интеллекта с IQ — это ещё в названии книги легко заметить. Проблема в том, что сам по себе IQ особо ничего не показывает, что уже многократно было доказано. Поэтому автор, по сути, спекулирует на сравнении своей теории с не самым показательным тестом интеллекта.

В целом книга ничего особенно нового не приносит и является компиляцией других, более серьёзных трудов (список литературы в конце — просто загляденье). Если вы не очень хорошо разбираетесь в том, что такое эмоции и как с ними вообще жить, книжка поможет погрузиться в этот увлекательный мир. В противном случае рекомендую взять что-нибудь посерьёзнее. Пример такой книги — в следующем обзоре.

«Карьера Software Engineering Manager», Джеймс Стэньер

Fri, 11 Oct 2024 00:00:00 GMT

Технологическая отрасль переживает кадровый кризис. Не потому, что мы не знаем, как писать программы или как масштабировать инфраструктуру. Мы стали намного лучше в этом разбираться. Кризис возник потому, что мы не знаем, как управлять людьми. Не компьютеры, а люди создают программы. Мы должны сделать как можно больше людей успешными. Хороший менеджер может решить эту проблему. И вы способны им стать.

Senior-инженеры часто думают, что переход в роль тимлида — это повышение. Но это скорее переход в абсолютно новую профессию, где вчерашний крутой разработчик вновь становится джуном. На этом пути всегда пригодятся учебные пособия, и “Карьера Software Engineering Manager” — одно из них.

О чём книга

Книга посвящена переходу в роль тимлида. В ней покрыты все базовые моменты работы начинающего руководителя команды с советами и рекомендациями.

Сама книга состоит из трёх больших частей.

Первая часть — самая маленькая и, по сути, является введением в книгу. Но в ней есть важный посыл о том, что менеджер должен в первую очередь управлять собой.

Вторая часть — самая большая по объёму — посвящена работе с людьми. Здесь описаны алгоритмы установления отношений с членами команды в новой роли, способы проведения 1-на-1 и даже некоторые коучинговые техники. Эту часть можно использовать как фактическую инструкцию к действию для успешного онбординга в тимлиды.

Третья часть посвящена управлению проектами, коммуникациями и информацией. Тимлид должен взаимодействовать не только с командой, но и с целым рядом смежных подразделений. Поэтому так важно научиться грамотно взаимодействовать с людьми и делать коммуникацию прозрачной. Раздел заканчивается “взглядом в будущее” на развитие карьеры менеджера.

Мои впечатления

Книга мне очень понравилась обилием практических примеров, рекомендаций и руководств к действию. Её можно просто взять и использовать как инструкцию для погружения в роль тимлида. При этом она не наивная и показывает вполне реальные сложности (привет, детская «Мама, я тимлид»).

Кроме того, в книге множество отдельных частей, которые можно вырвать из контекста и с пользой применять: алгоритмы и шаблоны проведения 1-на-1, коучинговые вопросы для проведения 1-на-1 с подчинёнными, процесс увольнения людей и так далее.

Если вы недавно стали тимлидом или вам в скором времени предстоит им стать, я очень рекомендую прочитать эту книгу или хотя бы держать её под рукой как референс. Из неё можно почерпнуть много полезного для повседневной работы и значительно упростить себе жизнь.

Как перфекционизм мешает развиваться

Wed, 09 Oct 2024 00:00:00 GMT

На выходных я получил очередное напоминание о том, что перфекционизм вредит развитию навыков.

На занятии по барабанам я играл новую песню. Партию уже разобрал и работал над скоростью. На 80% от оригинального темпа выходило плохо: я напрягался, не попадал в ноты и сбивался.

Помучился полчаса и решил повысить скорость. И тут произошло чудо: руки расслабились, темп стал ровнее, играть оказалось проще и приятнее. Да, в некоторых местах я всё ещё попадал не в те ноты, но теперь причина была понятна — непривычный темп.

Я поднял скорость ещё немного. Стал играть спокойнее, хотя ошибок прибавилось. Все они были одного типа: неправильная нота или последовательность. Такие ошибки лечатся тренировкой мышечной памяти — нужно заиграть грувы до автоматизма.

На низкой скорости я на самом деле терял концентрацию. Мне было недостаточно сложно, поэтому я отвлекался, перенапрягался и сбивался. На высокой скорости потеря концентрации сразу превращалась в ошибку и возвращала меня в русло. Заодно проявились места, где я недостаточно хорошо запомнил партию.

Ситуация напомнила мне совет преподавательницы, который я получил ещё новичком: «Более-менее нормально получается — двигайся дальше».

Конечно, это не значит, что всё нужно играть на пределе. Сложность должна соответствовать задаче. Если я разучиваю конкретный элемент, полезно замедлиться и отточить движение.

Но доведение каждой мелочи до идеала требует огромного количества сил и времени. Вместо всё более сложных задач я начинаю ковыряться в том, что уже сделано достаточно хорошо. Развитие замедляется.

У перфекционизма бывают разные проявления. В другой ситуации мне помог пинок от дочери в нужном направлении. Общий принцип тот же: идеальность не должна мешать переходить к следующему уровню сложности.

Книги, по которым я прокачивал Go

Fri, 04 Oct 2024 00:00:00 GMT

Пару месяцев назад я столкнулся с необходимостью резко подтянуть свой уровень знаний по Golang. Причина была простой — у меня появилась команда, в которой есть стажёр, и я отвечаю за его рост.

Базовые навыки программирования на Go у меня были, но их явно не хватало для развития моего подопечного. Поэтому я решил улучшить свою экспертизу любимым способом — читая книги (и попутно ставя эксперименты).

«Golang для профи», Михалис Цукалос

Толстенный талмуд, который покрывает много далеко не базовых тем. Я решил начать с него, потому что издание выглядело внушительно.

Скажу честно, мне не очень понравилось. Книга слабо структурирована, некоторые советы сомнительны. Но при этом в ней много интересных особенностей Go и лайфхаков. Всё это подкреплено примерами кода, которые можно запустить и посмотреть в деле.

В целом книга хорошая, но я не рекомендую читать её от корки до корки. Лучше обратить внимание на избранные темы. Также не рекомендую использовать её в качестве первой книги по Go, потому что скорее запутаетесь, чем извлечёте что-то полезное.

«Go. Идиомы и паттерны проектирования», Джон Боднер

Книга Боднера мне понравилась гораздо больше. По сути, это углублённое руководство для новичков по Go. Автор рассматривает все базовые темы, но дополняет их особенностями и нюансами языка Go. Например, в главе про конкурентность Боднер объясняет, в каких случаях следует применять те или иные примитивы синхронизации.

Учтите, что в книге почти не рассматривается стандартная библиотека Go (stdlib), всё внимание автора сосредоточено на особенностях самого языка. Я не могу назвать это минусом — это просто особенность.

Если бы я сейчас начинал изучать Go с нуля, я бы порекомендовал пройти тур по Go и дополнить его книгой Боднера. Такая связка даст очень хорошую базу для изучения языка.

«100 ошибок Go и как их избежать», Тейва Харшани

Отличная книга, направленная на специалистов, уже знакомых с Go. В ней приводится 100 ошибок, которые можно допустить при программировании на Go, с множеством пояснений и примеров кода для их воспроизведения.

Для работы с материалом книги потребуются знания Go, поэтому она точно не должна быть первой книгой по языку. Более того, я не рекомендую её начинающим разработчикам — в книге довольно много нюансов и тонкостей. Однако при переходе с другого языка программирования (как в моём случае) книга очень полезна, так как показывает множество неочевидных особенностей поведения Go. Ошибки разбиты на несколько логических разделов, что делает чтение удобным — похожие ошибки идут друг за другом, и контексты не смешиваются.

Рекомендую к прочтению, если вы разработчик уровня middle и выше, или если вы переходите на Go с другого языка программирования.

Большие проблемы маленьких изменений

Wed, 02 Oct 2024 00:00:00 GMT

Не так страшны первые 90% проекта, как вторые 90% проекта.

Шутка смешная, а ситуация страшная. Если проект проработан слабо, то его с высокой вероятностью ждёт судьба из шутки - медленное, мучительное доталкивание до конца.

Для плохо проработанных проектов проблема очевидна: на старте много чего не продумали, и это “много чего” начинает вылезать в процессе работы. Но в такой же ситуации могут оказаться и вполне достойно проработанные проекты. Вроде всё продумали и расписали, а в срок не попадаем. Почему?

Из моего опыта самая частая причина смещения сроков - это изменения проекта. Вот был нормальный, проработанный эпик. Команда его делает-делает, тут прибегает продакт и говорит, что нужно срочно добавить вот сюда маленькую кнопочку. Раз, второй, третий - и вот проект завершается на месяц позже.

Собака часто бывает зарыта в процессе управления изменениями. Крупные и средние изменения обычно не проходят мимо - ответственный за проект их документирует, оценивает, утверждает и так далее. Но при этом маленькие, почти незаметные изменения часто игнорируются. Ведь ничего же страшного не произойдёт, такая мелочь не повлияет на объём проекта? Не повлияет, правда?

Каждое маленькое изменение может быть незаметным само по себе и не оказывать существенного влияния на проект. Но когда у проектного менеджера есть привычка игнорировать такие мелочи, то они накапливаются и могут значительно увеличить сроки выполнения.

Избежать изменений объёма работ по проекту не получится (да и смысла в этом нет). Изменения несут опасность, только если ими не управлять. Самый простой выход из ситуации - документировать любые изменения вне зависимости от их размера. Тогда ни одна мелочь не проскочит незамеченной, а в случае смещения сроков завершения проекта будет понятна причина.

Более того, документирование и оценка изменений иногда подталкивают представителей бизнеса к тому, чтобы отказаться от изменения. Когда стейкхолдеры видят, что их хотелка увеличит сроки на две недели, то могут задуматься, стоит ли реализация хотелки такой задержки.

Что бы я посоветовал другу?

Mon, 30 Sep 2024 00:00:00 GMT

Моим главным препятствием на пути к рефлексии был и частично остаётся перфекционизм. Анализ ошибок давался с трудом, потому что я частенько скатывался в самокритику и терял рациональность. В какой-то момент сама мысль об анализе ошибок начала вызывать у меня тревогу.

С одной стороны, я понимал, что так дело не пойдёт: размышлять над своими ошибками бывает полезно. С другой — заставлять себя заниматься тревожно-раздражающей деятельностью тоже не хотелось. После очередной сессии таких «размышлений» настроения что-либо делать не было от слова совсем.

Помощь неожиданно пришла из книги Дэвида Бернса «Терапия беспокойства». Из множества описанных в ней упражнений мне пригодилась техника «Что бы я посоветовал другу?».

Посмотреть на проблему чужими глазами

Суть техники проста: я рассматриваю ситуацию так, будто с ней ко мне обратился мой друг, и спрашиваю себя:

Что бы я сказал ему в такой ситуации?

К другим людям мы зачастую относимся мягче и добрее, чем к себе. Вряд ли я стал бы разгромно критиковать друга, который принёс мне свою проблему. Скорее помог бы отделить факты от катастрофических мыслей, найти следующий шаг и признать, что ошибка не делает его плохим человеком.

Эта смена точки зрения помогает мне применить то же заботливое отношение к себе и спокойнее анализировать произошедшее. Ошибка не обязательно оказывается мелкой или легко исправимой, но самокритика перестаёт мешать думать о последствиях и действиях.

Сейчас я применяю эту технику реже: со временем научился оценивать себя менее критично. Однако в сложные моменты она по-прежнему помогает успокоиться и взглянуть на ситуацию трезвее.

Это не универсальный способ справиться с тревогой и не замена профессиональной помощи. Для меня это один конкретный инструмент рефлексии. Другую практику Бернса, которая помогает отделить факт от своей интерпретации, я разобрал в заметке «Простая техника, которая снижает накал эмоций».

«Управление проектами с нуля», Грег Хорин

Fri, 27 Sep 2024 00:00:00 GMT

Совершая камбэк в роль тимлида, я решил освежить и систематизировать знания в области управления проектами. Мой выбор пал на книгу Грега Хорина “Управление проектами с нуля”.

О чём книга

Книга по сути является большим настольным справочником по базовому управлению проектами. Она состоит из пяти больших частей: быстрый старт, планирование проекта, контроль хода выполнения проекта , выполнение работ по проекту и “ускорение обучения”.

Первая часть знакомит читателя с терминологией и определением проектного менеджера. По сути просто введение, но без него будет тяжело читать дальше.

Вторая часть посвящена планированию, декомпозиции и оценке проекта. Здесь подробно обсуждаются вопросы определения и планирования проекта, разработки структуры декомпозиции работ, создание графика и составление бюджета проекта.

В третьей части обсуждается контроль выполнения проекта. Это одна из самых важных частей книги, потому что в ней раскрыты тему управления изменениями и конечными результатами проекта. Ещё в ней же покрывается тема управления проектными рисками (не так глубоко, как хотелось бы, но в целом вполне неплохо).

Четвёртая часть тоже мне показалась очень важной, потому что она посвящена управлению ходом проекта и коммуникацией со стейкхолдерами. Мне она была полезнее всего, потому что раньше мои навыки презентации результатов работы откровенно страдали. Вытащил несколько полезных советов.

Пятая часть содержит оказавшиеся не слишком полезнысм для меня главы по использованию Microsoft Project и подготовке к сертификации, а также довольно интересные главы про проектное управление в реальных условиях. Здесь по сути описывается ответ на вопрос “Что делать, когда всё идет не по плану?” (то есть примерно каждый день).

Мои впечатления

Книжка - отличный, достаточно подробный настольный справочник проектного менеджера. Считаю крайне полезной книжкой для тимлидов, потому что в ней найдут для себя много полезного и начинающие, и опытные специалисты.

Конечно же, многие темы в книге раскрыты не очень подробно. Но я не считаю это недостатком, потому что задача книги - дать общее понимание, обзор темы проектного управления. Если какая-то тема сильно заинтересовала, то это отличный повод пойти и покопаться глубже самостоятельно.

Хочу ещё отметить, что в книге куча разных полезных чеклистов (уважаемому Список очень понравится). Поэтому я и рекомендую иметь её как настольный справочник: многие чеклисты и опросники можно просто брать и применять в работе. Они могут быть не идеальными, но заставят задуматься в нужную сторону.

Отличная книга для тимлидов всех уровней, знания проектного управления ещё никому не вредили :)

Забор Честертона: сначала разберитесь, потом ломайте

Wed, 25 Sep 2024 00:00:00 GMT

Представьте себе, что вы идёте по цветущему ромашковому лугу и внезапно утыкаетесь в забор. Просто забор, без ограды и чего-либо ещё. «Что за ерунда?» — скорее всего, первым делом подумаете вы.

Наверняка у вас возникнут мысли, что забору здесь не место и вообще было бы неплохо его снести. Но это решение плохое, потому что вы не знаете назначения забора. Этот принцип обычно связывают с Гилбертом Честертоном: не ломайте забор, пока не поняли, зачем его поставили.

Аналогия с забором хорошо показывает, как мы можем заблуждаться в своих убеждениях. Частенько специалист приходит в новую команду и такой “а чего это у вас тут всё так плохо сделано, ща поправим”. Невелика беда, если этим занимаются программисты - их на код ревью завернут и объяснят. Но ситуация становится гораздо веселее, когда принцип забора Честерсона начинают нарушать тимлиды и руководители выше.

Не все команды успели построить устойчивые системы, а часто вообще всё держится на костыльных процессах и взаимовыручке. Поэтому изменение даже незначительной на первый взгляд детали (того самого забора) может привести к нарушению всего процесса и коллапсу.

Внесение изменений без понимания ситуации может принести руководителю и его команде кучу неприятностей. Да, можно понять энтузиазм руководителя - он вышел на новое место и хочет как можно быстрее показать себя с лучшей стороны. Но если вы начинаете работать в новых условиях, то сначала лучше будет собрать как можно больше информации и разобраться в том, как сейчас всё устроено. Иначе будет ситуация как в той байке, где программисты “Войну и мир” поддерживали.

Зачем выступать публично?

Mon, 23 Sep 2024 00:00:00 GMT

Я думаю, что все вокруг уже прекрасно осведомлены о пользе публичных выступлений. Личный бренд, заявление о своей экспертности, вот это вот всё. По мотивам своего субботнего выступления тоже хочу накинуть пару необычных ответов на вопрос «Зачем?»

Это стрёмно

Представить свой доклад публике всегда волнительно. У меня даже на внутренних прогонах с супер-лояльными коллегами колотится сердце и потеют ладошки. Что уж говорить о рассказе чего-то сотне-другой незнакомцев? А вдруг помидорами закидают?

Но преодоление этого страха вызывает настоящую эйфорию. Когда заканчивается доклад и уходят остатки адреналина, то возникает осознание сделанного. И это осознание приносит огромное удовольствие и удовлетворение от проделанной работы. А если ещё и обратной связи хорошей накидают, то можно на мгновение ощутить себя центром Вселенной.

Это сложно

Даже небольшой базовый докладик на 20 минут - это часы напряжённой работы. Давайте расскажу, что входит в “сделать докладик на 20 минут”:

Придумать идею.
Написать тезисы.
Найти подходящую конфу или митап.
Подать туда заявку.
Презентовать свою тему кому-то из ПК.
Если доклад не одобрили - запросить фидбек и начать с п.1
Если доклад одобрили - его нужно сделать.
Провести несколько тестовых прогонов доклада (обычно от двух до бесконечности)
Нормально прочитать сам доклад на конфе
Нормально ответить на вопросы к докладу.
Нормально ответить на вопросы после доклада.

Кто там хотел сложных задач от работы? Как вам такое?

Сделать любой доклад - это большой и сложный труд. Когда идёшь по этому пути первые разы, то сталкиваешься с неожиданными трудностями и вызовами. Каждый доклад - это не просто проект, это маленькая жизнь.

Это необычно

Вы наверняка слышали, что наш мозг любит всё новое-интересное. Так вот, публичные выступления сильно выталкивают из зоны комфорта. Если тимлидам ещё более-менее привычно презентовать свои идеи, то для разработчиков это сильно нестандартная деяельность. Сделать что-то новое - это всегда прикольно и интересно, потому что помогает по-новому взглянуть на привычные вещи.

В общем, выступайте и будет вам новый опыт.

Три книги по логике: от базы к практике

Fri, 20 Sep 2024 00:00:00 GMT

Лично мне логика кажется важным инструментом любого айтишника. Даже в технической части решения бывают очень разные, и умение беспристрастно логически анализировать их очень важно. А уж для переговоров я вообще молчу: умение оперировать логическими категориями сильно помогает составлять понятные договорённости.

В целом большинство людей так или иначе владеют логикой даже без её фундаментального понимания (привет, школа с институтом). Однако явное лучше, чем неявное, поэтому я уделил силы и время подкачке своих навыков логического мышления. Для него я проходил курс Максима Дорофеева и читал книжки. Про курс расскажу отдельно, а вот книжками поделюсь.

Книжки во многом пересекаются и сходны по тематике, поэтому я решил объединить их в один пост.

Сергей Виноградов «Логика. Учебник для средней школы»

Начать предлагаю с этого достаточно простого учебника, который погрузит вас в базовые понятия логики на примерах. Учебник рассчитан на школьников, поэтому читать его просто и приятно. А ещё смешно, потому что учебник - советский, и автор постоянно восхваляет советскую власть, товарищей Ленина и Сталина.

Лично мне читать было легко, приятно и смешно благодаря ярким просоветским вставкам. Очень рекомендую.

Георгий Челпанов «Учебник логики»

Учебник Челпанова - это уже более продвинутое чтиво. Академический слог, схемы, формулы логики поджидают любопытного читателя на страницах этой книги. Примеры тоже более сложные и интересные.

Часть информации пересекается с книгой Виноградова, однако многие вещи разобраны глубже и полнее. Также в книге Челпанова очень плотно раскрыты темы индукции/дедукции, силлогизмов и обобщений.

Мне понравилось читать её второй, потому что после чтения учебника Виноградова уже появилась база и новые идеи легче воспринимались.

Александр Ивин «Искусство мыслить правильно»

Завершает наш список прекрасная книга на тему языка и мышления “Искусство мыслить правильно”. Если первые две книги фокусируются на логике как на науке, то книга Ивина в свою очередь рассказывает про логику в реальной жизни.

Автор акцентирует внимание на повседневной, будничной логике: определения слов и названия вещей, какие есть языковые ловушки, софизмы, как применять доказательства и так далее. В книге очень много ярких, интересных примеров (например, есть прекрасная глава “О смысле бессмысленного”, где в пример приводятся части “Алисы в стране чудес”).

Для меня книга стала отличным дополнением первым двум благодаря необычным и интересным примерам. Но её можно читать отдельно, получите и отличные идеи, и эстетическое удовольствие.

В бэклоге у меня лежит ещё несколько интересных книг по логике, буду делиться по мере чтения.

Если читали что-то из вышеперечисленного - делитесь в комментариях, как вам впечатления.

Как Figma масштабировали PostgreSQL

Tue, 17 Sep 2024 00:00:00 GMT

По работе мы с командой плотно занимались вопросами масштабирования баз данных в целом и шардирования в частности. Поэтому я много читал о том, как другие компании решали похожие задачи.

Особенно мне запомнилась эпопея Figma из двух статей. Их заряженный по железу монолитный PostgreSQL всё-таки начал упираться в свои пределы, и команде пришлось последовательно менять архитектуру хранения данных.

Как выиграть время

В первой статье инженеры разбирают:

базовые тактические действия, когда база начинает не вывозить;
причины отказа от переезда на другую СУБД;
вертикальное партиционирование — вынос таблиц в отдельные базы без даунтайма, но с нюансами.

Эти решения помогли Figma выиграть время, но не сняли ограничение окончательно. Инженеры понимали, что рано или поздно снова упрутся в тот же предел.

Как снять ограничение

Во второй статье команда рассказывает, как проектировала горизонтальное шардирование:

разделила таблицы на группы colocations, объединённые ключом шардирования и физическим размещением данных;
написала собственный роутер подключений к БД;
проверяла поведение продакшен-трафика до релиза в продакшен.

В итоге Figma построила решение под собственный спектр задач. Бездумно повторять его у себя не стоит: масштаб, история системы и требования к миграции слишком специфичны. Но обе статьи хорошо показывают путь от тактического продления жизни базы к архитектуре, которая снимает ограничение системно.

Рекомендую прочитать их всем, у кого база потенциально может начать задыхаться. Будете знать, к чему готовиться и какой ад бывает в мире больших баз данных.

Как определить ценности команды

Mon, 16 Sep 2024 00:00:00 GMT

Что такое ценности команды? Как они выглядят? И главное — как их выявить и использовать во благо?

Лично я знаю три способа:

Вангование.
Гадание на картах Таро.
Командный семинар по выявлению ценностей.

Первые два варианта здесь не только шутки ради. Люди склонны додумывать вещи, никак не связанные с реальностью. Ценности команды можно предположить, но это не гарантирует попадания. Поэтому с командой лучше поговорить.

Собираем варианты

Начните семинар с вопроса:

Что для меня ценно в команде и командной работе?

Каждый участник накидывает свои варианты. Здесь может быть что угодно: помощь и взаимовыручка, уважение коллег, приватный чат с мемами или поход в бар по пятницам.

На этом этапе лучше устроить мозговой штурм и не ограничивать людей. Затем частные случаи можно объединить в более общие ценности. Например, походы в бар относятся к неформальному общению.

Приземляем абстракции

Для каждой получившейся ценности команда отвечает ещё на несколько вопросов.

Что эта ценность значит для нас?

У вопроса специально нет однозначного ответа. Он помогает понять, как разные люди относятся к одной ценности. Важно сохранять фокус именно на своей команде.

Как ценность выглядит в действии?

Этот вопрос приземляет абстракцию на конкретное поведение. Команда договаривается не о красивом слове, а о его наблюдаемых проявлениях.

Как эту ценность можно неверно понять?

Так мы определяем границы. Например, неформальное общение легко превратить в обязанность ходить с коллегами в бар, чтобы тебя принимали в команде.

Как мы поймём, что ценность соблюдается?

Здесь стоит вернуться к конкретным действиям и подумать, как они проявляются в повседневной работе.

Как эта ценность изменит работу или отношения в команде?

Последний вопрос помогает понять, ради чего команда потратила время на весь разговор.

Что делать после семинара

Результат можно превратить в командный манифест и использовать на онбординге новичков. К нему стоит периодически возвращаться: люди и сама команда меняются.

Провести такой семинар непросто, и времени он съедает прилично. Но уже сам разговор о важных для каждого участника вещах помогает людям лучше понять друг друга. Главное — не подменять этот разговор списком ценностей, который руководитель придумал за команду.

Если команды ещё нет

Когда руководитель только собирает команду, обсуждать ценности пока не с кем. В этом случае можно пройти те же вопросы самостоятельно и получить не готовую конституцию команды, а стартовую гипотезу:

Что делало мои предыдущие команды успешными?
С какими людьми мне было особенно легко работать и почему?
Какое поведение помогало работе, а какое постоянно создавало проблемы?
Что я сам готов поддерживать личным примером?

Ответы руководителя неизбежно влияют на найм и первые правила работы. Но по мере появления людей эту гипотезу стоит обсуждать и пересматривать вместе с ними. Иначе разговор о командных ценностях превратится в набор личных предпочтений начальника.

Как использовать ценности в найме

Обычный профиль кандидата часто состоит из абстрактных технических навыков и таких же абстрактных качеств: «ответственный», «аккуратный», «командный». Проверять это трудно, поэтому фит-интервью легко превращается в угадайку про «наш человек или не наш».

Сформулированные ценности позволяют обсуждать наблюдаемое поведение. Если команде важна взаимопомощь, можно попросить кандидата рассказать, как он действовал, когда коллега не справлялся. Если важна самостоятельность — разобрать ситуацию, в которой не было понятного плана действий.

Мне доводилось нанимать человека, который немного не дотягивал по техническим навыкам, но хорошо подходил команде по способу работы. Техническую часть мы докачали за несколько месяцев и в итоге получили отличного коллегу.

Это не значит, что нужно нанимать людей, похожих друг на друга, или закрывать глаза на обязательные для роли навыки. Ценности дают дополнительные критерии для разговора, а не право выбирать кандидата по ощущению «совпали по вайбу».

«От монолита к микросервисам», Сэм Ньюмен

Mon, 02 Sep 2024 00:00:00 GMT

Распил монолита на микросервисы уже стал притчей во языцех. Если вбить в поиск ютуба эту ключевую фразу, то вы увидите ~~бесконечную загрузку~~ кучу видосов и выступлений на конфе. Оно и неудивительно, тема сложная и богатая на нюансы.

Сэм Ньюмен, автор книги «Создание микросервисов», тоже успел проехаться на хайповой теме. Его книга про микросервисы мне очень понравилась, поэтому я решил прочитать и про распил монолита.

О чём книга

Книга довольно небольшая, состоит из 5 глав, которые и покрывают все аспекты миграции.

Первая глава посвящена терминологии, которая используется в книге (микросервис, монолит, cohesion/coupling, немного DDD).

Вторая глава покрывает планирование миграции с монолита на микросервисы. Интересно, что Ньюмен акцентирует внимание на важности планирования и как управлять распилом с точки зрения проектного управления (риски, контрольные точки, вот это всё). Даже когнитивные искажения вспомнил.

Третья и четвёртая главы рассказывают о технической части миграции: как пилить монолит и как пилить БД. Для распила монолита автор предлагает несколько шаблонов, которые позволяют постепенно переехать с монолита. Есть как относительно стандартные шаблоны (душитель, вынос куска логики в микросервис и так далее), так и более экстравагантные типа использования CDC для создания параллельно работающих систем.

Для распила БД автор тоже предлагает набор архитектурных шаблонов, от обёртывания БД микросервисом до различных синхронизаций. Также описан ряд вспомогательных шаблонов, которые могут немного упростить переезд. В конце главы про БД автор прошёлся по транзакциям, 2FC и сагам в микросервисах.

Пятая глава на мой вкус должна быть второй, потому что она рассказывает о болезнях роста микросервисной архитектуры. В ней описаны все страдания, которые предстоит пережить с масштабированием микросервисной архитектуры. Также в ней Ньюмен затрагивает вопросы мониторинга и логирования, DX разработчиков микросервисов, проблемы отказоустойчивости и многое другое.

Мои впечатления

Книга мне понравилась. Она даёт общий обзор проблемы распила монолита на микросервисы с точки зрения как кода, так и хранения данных. Ньюмен двигается от проблемы к решению, поэтому книгу довольно легко читать и воспринимать.

Конечно, в ней не хватает детализации, однако в такой сложной теме избыток подробностей делает книгу слишком узкоспециализированной. Автор ставил перед собой задачу дать читателю общее понимание проблемы распила монолита на микросервисы и путей её решения, и ему это удалось.

Отдельно хочу выделать русский перевод, который сделан из рук вон плохо. Если английский позволяет, то читайте книгу в оригинале.

На мой взгляд, книгу стоит прочитать каждому бэкендеру начиная с уровня Middle (это то место, где хочется прикручивать много всяких разных архитектурных паттернов и тому подобных вещей). С книгой стоит ознакомиться, даже если вы не планируете в ближайшее время пилить монолит - планы могут измениться :)

Если глаз замылился — запросите обратную связь

Wed, 28 Aug 2024 00:00:00 GMT

За последние две недели я потратил около 30 часов на код-ревью проекта, который пишет стажёр в моей команде. Он разрабатывает пример реализации шардирования БД — это не самый простой, но довольно интересный проект.

За это время я успел сродниться с каждой написанной строчкой кода. Мне кажется, они стали моей семьёй. Я знаю каждую чуть ли не наизусть. Я принимаю их такими, какие они есть, со всеми достоинствами и недостатками.

Конечно же, я немного иронизирую. Делаю это намеренно, чтобы подвести к одной простой мысли. Я вложил в ревью этого кода столько сил и внимания, что у меня “замылился глаз”. Все решения мне кажутся понятными и логичными, все функции — аккуратными и правильными, структура пакетов не вызывает вопросов, а комментарии кажутся избыточными, ведь всё так понятно.

К счастью, я довольно быстро заметил это состояние и понял, что заблуждаюсь. Во-первых, идеального кода не существует. Во-вторых, я абсолютно уверен в том, что проект можно во многом улучшить.

В такой ситуации лучшее, что можно сделать, — запросить обратную связь. Нужен честный, открытый, свежий взгляд на проделанную работу. Человек, который никогда раньше не видел этот проект, может дать совершенно неожиданные мысли и инсайты для размышления. В моей ситуации я так и поступил, договорившись с несколькими менторами о ревью проекта.

Однако эффект замыленного глаза не ограничивается кодом. Подумайте: сколько вещей в жизни кажутся нам абсолютно понятными и привычными? Настолько очевидными, что не вызывают вопросов? Чаще всего именно в этих местах неплохо бы запросить взгляд на себя со стороны.

Для этого отлично подходят любые люди, способные дать вам конструктивный фидбек: руководители, коллеги, подчинённые, менторы и даже психологи с коучами. Наше мышление и восприятие ограничены, а сторонний наблюдатель может обратить внимание на те аспекты, которые мы совершенно упускаем из виду. Даже если вы ничего не предпримете после получения этой обратной связи, она заставит мозг пошевелиться и поискать другие, обделённые вниманием, области.

«Создай свой второй мозг», Тьяго Форте

Tue, 27 Aug 2024 00:00:00 GMT

Не знаю, хорошо это или плохо, но физиологически мы ограничены одним мозгом. Однако его можно “расширить” с помощью различных цифровых и аналоговых устройств. Пока что мы не в киберпанке, поэтому на помощь приходят компьютеры, смартфоны и тетрадки с ручками.

А как организовать всю эту внешнюю память и что с ней вообще делать? Предлагаю вам ознакомиться с моей рефлексией по одной из книг, в которой я искал ответы на эти вопросы.

Книга за 3 предложения

Книга о том, как автор построил и ведёт свою систему заметок PARA (Projects, Areas, Resourses, Archive). В книге рассказывается о том, как Форте пришёл к необходимости вести свою систему, философия его заметковедения и описание самой системы. Также есть куча отличных практических советов о том, как системно работать с заметками и зачем это всё вообще нужно.

Что я могу применить

После прочтения книги я попробовал использовать систему PARA в чистом виде - не зашло. Однако я оставил себе папку с проектами, в которые распихиваю подходящие заметки. Например, у меня сейчас есть несколько идей докладов - я создаю под них папки и закидываю туда свои заметки из основной базы знаний.

Основная штука, которую я смог применить после книги - не заканчивать свою работу на создании заметок. Кульминацией должно стать применение написанной мысли в творчестве и создании чего-то нового (например, поста в канале или доклада).

Также книга напомнила мне, что классные идеи можно таскать откуда угодно, а не только из умных книжек. Любая мелочь может стриггерить и натолкнуть на рассуждения (вспоминаю, как я в отпуске в Тайланде размышлял на тему того, что в музыке люди находят отражение себя, наслушавшись отвратительной русской попсятины).

Ещё одна полезная для меня мысль - процесс творчества состоит из большого количества маленьких задач. Правильно поставленный процесс делает работу независимой от наличия большого куска времени или вдохновения, потому что всегда есть маленькие задачки, которые можно сделать за 5-10 минут. Поэтому драгоценные моменты вдохновения не тратятся на ерунду.

Выводы и тейки

Для озарений и творчества важно иметь много (избыток) идей и материала. Чем больше материала - тем проще отсечь лишнее и творить.
Не пытайся делать сразу идеально, напиши черновик и потом улучшай его.
Храни заметки не по категориям, а так, чтобы их было удобно искать. (Форте предлагает разделить на папки и контексты, но мне его деление не подошло - поиск в Обсидиане вполне хорош)
Процесс выноса мыслей “на бумагу” вызывает изменения в мышлении.
Сама заметка - это результат процесса мышления, его естественное следствие.
Творчество требует хорошо поставленного процесса. При этом процесс разбивается на небольшие, простые задачки, которые можно делать в свободные “опилки времени”.

Впечатления

Книжка неплохая, но довольно водянистая. Очень много букв на тему восторжения Форте своей системой. С точки зрения философии ведения заметок мысли Форте во многом пересекаются с тем, что пишет Зонке Аренс в книге “Как делать полезные заметки”. Но у него чуть больше прикладных вещей. Можно читать вскользь, цепляя для себя интересные мысли.

Сама система PARA в чистом виде мне не подошла - её задача больше в накоплении материалов и референсов, а я использую написание заметок для размышлений. К тому же в ней нет чётко выделенных категорий и система папок у меня почти сразу превратилась в свалку.

Однако несколько практико-применимых вещей я вытащил. Главный тейк - папки под проекты, в которых я накапливаю свои заметки и референсы. Этот процесс сильно бустанул мои творческие порывы (например, у меня уже есть пачка идей для докладов). Ещё книга подтолкнула меня создавать черновики заметок. Например, так я вытащил несколько прикольных идей из книг и написал по ним посты в ТГ.

Как эта книга изменила меня

Укрепился в мысли, что мозгом надо думать, а не помнить
Осознал, что мою работу по написанию заметок можно и нужно применять для дальнейшего творчества.
Стало легче писать черновики.
Появилась привычка делать заметки чуть лучше при перечитывании.
Подтвердил мысль, что написание заметок вызывает изменения в мышлении и поведении.
Разбил свой процесс работы на подзадачки и научился использовать “опилки времени” для работы с книгами и заметками.

3 классные цитаты

Когда мы тратим силы на попытки вспомнить что-то, это значит, что они не вкладываются в мыслительные процессы, свойственные только человеку: изобретение, сочинительство, поиск закономерностей, следование своей интуиции, сотрудничество с другими людьми, проведение новых исследований

Во-вторых, вы сможете добиться прогресса за любой промежуток времени. Вместо того чтобы ждать, когда выпадут несколько часов непрерывной работы (положа руку на сердце, скажем себе, что это происходит все реже), можно посмотреть, сколько свободных минут у вас есть, чтобы выбрать тот пакет, который вы можете сделать за это время, даже если он очень маленький. Большие проекты и цели становятся менее пугающими, потому что вы можете систематически разбивать их на маленькие подэтапы до тех пор, пока они идеально не впишутся в промежутки вашего и без того редкого свободного времени.

Мы привыкли воспринимать информацию с потребительской точки зрения: чем больше, тем лучше, ограничений нет. Считая по умолчанию, что она в дефиците, мы постоянно жаждем все больше и больше информации, и это наша ответная реакция на страх, что ее недостаточно. Нас учили, что информацию нужно тщательно оберегать, потому что люди могут использовать ее против нас или украсть наши идеи. А еще нас учили, что ценность и самоуважение приходят благодаря тому, что мы знаем и можем процитировать по команде.

ADR — способ подумать письмом и сохранить контекст решения

Mon, 26 Aug 2024 00:00:00 GMT

“Так сложилось исторически.”

Когда я прихожу в новый проект, то начинаю разбираться, как в нём всё устроено. Я задаю довольно много вопросов, но на некоторые из них получаю в ответ фразу, написанную выше. Да и сам я периодически грешу таким ответом.

Причина этого проста: нормальный человек просто не в состоянии запомнить всё на свете. В разработке изменения обычно идут настолько быстро, что многие вещи забываются чуть ли не сразу (даже если им предшествовало бурное обсуждение).

Сначала подумать, потом делать

Одним из важнейших навыков техлида, наравне с технической экспертизой, я считаю умение анализировать и принимать решения.

Наш мозг устроен так, что любую проблему мы хотим решить быстро. Из-за этого мы зачастую принимаем самые быстрые и лежащие на поверхности решения. Делаем мы это автоматически, потому что нашему мозгу так проще. На мышление тратится энергия, в то время как автоматические действия совершаются без сложного анализа.

Эта особенность мозга очень сильно мешает техлидам при принятии технических решений. Само по себе слово «решение» подразумевает анализ и осознанный выбор из нескольких альтернатив. Выбор первого попавшегося варианта решением не является.

Поэтому я топил, топлю и буду топить за документарные способы принятия решений. Ресёрчи, RFC и ADR помогают взвешивать варианты и рассматривать достаточное количество альтернатив.

Мозг — машинка для мышления и анализа, а не для хранения информации. Решать сложную аналитическую задачу, удерживая весь контекст в голове, очень утомительно. Если выписать проблему и контекст на внешний носитель, у мозга высвобождаются ресурсы на проведение анализа.

Описывать можно любые технические решения: рефакторинг, смену технологий, API и изменения в БД для новой фичи. Времени это занимает немного, а как минимум открывает возможность технического ревью перед началом работ.

Лучше потратить время на исследование, документ и обсуждение, чем убить полгода на сложную техническую задачу с сомнительным профитом.

Что такое ADR

Наш мозг вообще плохо предназначен для запоминания информации, поэтому гораздо проще и полезнее записывать принятые решения. Для технических решений применяется такой подход, как ADR (Architecture Decision Record, реестр архитектурных решений). Вместо того чтобы запоминать принятые в ходе работы над проектом решения, просто записывайте их и ведите журнал. Какое бы техническое решение вы ни принимали, его точно стоит зафиксировать. Важны как небольшие вещи вроде использования определённой библиотеки по всему проекту, так и крупные изменения, например переезд на микросервисы.

Жёстко зафиксированной структуры ADR нет, вы можете взять любую и дальше доделать её под себя. В качестве референса рекомендую ознакомиться с материалами по ADR от GitHub. Для старта можно взять следующую структуру:

Дата и время принятия решения.
Статус ADR: предложено, отклонено или принято.
Описание проблемы.
Описание предлагаемого решения и того, как оно решает проблему.
Преимущества решения.
Недостатки решения.
Последствия принятия решения: что поменяется, что станет проще, а что сложнее.
Внедрение решения: как предлагается перейти на него.
Альтернативы.

Что даёт ADR

Ведение ADR даёт команде целый ряд преимуществ:

Все технические идеи проходят этап переноса из головы автора на «бумагу», что заставляет автора хорошенько подумать над самой идеей.
Такие идеи гораздо проще обсуждать: вся информация уже зафиксирована в тексте.
Значительно проще вспомнить, «откуда взялся этот говнокод» и «а это почему так сделано».
Переделывать старые решения становится безопаснее, потому что виден контекст их принятия.
Онбордить новых членов команды тоже становится проще, потому что они могут почитать ADR вместо вытягивания информации из памяти тимлида через боль и страдания.

С идеей ведения ADR я познакомился в книге Джеймса Стэниера «Карьера Software Engineering Manager».

Как внезапно стать чайка-менеджером

Wed, 21 Aug 2024 00:00:00 GMT

Обычно образ руководителя рисуется в виде человека, который постоянно сидит на созвонах, бегает в мыле и ничего не успевает. В среднем это так, но в работе любого руководителя бывают моменты, когда ничего делать не надо. Проект запущен, задачи делаются, люди работают — всё хорошо.

Знаете, что происходит в этот момент? Руководителю в голову со всей дури бьёт FOMO (fear of missing out — синдром упущенной выгоды, боязнь пропустить что-то важное или интересное). Охваченный тревогой руководитель начинает заниматься самобичеванием: «Все работают, а чего это я сижу без дела?»

Обычно этот вопрос приводит не к глубокой рефлексии на тему «я молодец, я классно всё организовал, пойду чая попью». Чаще его следствием становится придумывание себе работы (в 99% случаев — бесполезной) либо включение механизмов контроля: ну я ж менеджер, я ж должен за всем следить.

И вот страдающий от безделья менеджер начинает ходить и всем вокруг капать на мозги. А уже готово? А сейчас? А теперь? А какие сложности? А точно сложностей нет? А чем я могу помочь?

Сами по себе эти вопросы прекрасны и полезны. Но если их задавать слишком часто, люди начнут испытывать раздражение. Разница между полезным контролем и чайка-менеджментом здесь не в самих вопросах, а в причине и частоте. Если система наблюдаема и у команды действительно нет препятствий, очередной налёт руководителя ничего не улучшит.

Если вы всё хорошо организовали и теперь нужно просто ждать — ждите. Книжку там почитайте или доклад посмотрите, чая попейте, помедитируйте. Но отстаньте от людей и дайте им спокойно делать свою работу. Немного вашего безделья никому не повредит.

Отдай интересную задачу команде

Mon, 19 Aug 2024 00:00:00 GMT

Когда вчерашний разработчик становится тимлидом, то часто теряется и не знает, что нужно делать. Очевидно, что в такой ситуации он будет скатываться на привычные рельсы. Вместо построения системы из людей его руки будут тянуться к привычному и понятному написанию кода.

Более того, перед тимлидом открывается новый соблазн. Зачастую он видит все самые интересные задачки заранее и теоретически может забирать их себе. Но делать так - грубейшая ошибка.

Это не значит, что руководителю запрещено делать что-то руками. Всё зависит от масштаба команды, зрелости людей и ситуации. Но тимлид в первую очередь должен заботиться о том, чтобы команда системно доставляла ценность. Сложная интересная задача плохо сочетается с постоянными переключениями и менеджерской нагрузкой.

Более того, такой эгоизм вредит команде. Представьте себя на месте программиста, который с таким тимлидом работает. Он наблюдает следующую картину: его руководитель тащит себе самые интересные задачи и с удовольствием их делает, забивая на всё остальное. У программиста возникнут вполне закономерные вопросики к такому руководителю.

Если задачка вызывает у вас дикий зуд в ладонях и желание поскорее открыть IDE - это отличный индикатор того, что стоит её отдать кому-то из членов команды. Так вы убиваете двух зайцев: кто-то из команды получает интересную задачку, а вы не отвлекаетесь от своих непосредственных менеджерских обязанностей (я не понаслышке знаю, как могут увлекать сложные задачи).

Бонусом получаем благодарных за интересную работу членов команды. Это всегда приятно.

Методика 4П для подведения итогов недели

Fri, 16 Aug 2024 00:00:00 GMT

В очередной раз напоминаю, что рефлексия — один из лучших способов саморазвития. Обдумывая и анализируя произошедшие за некоторый период события, мы можем замечать ошибки в своём мышлении и поведении и корректировать их.

Одним из инструментов рабочей рефлексии является подведение итогов недели. Очень полезно бывает сесть и подумать: а чем я вообще всю эту неделю занимался? Но если подходить к еженедельному обзору без плана действий, то можно столкнуться с проблемой чистого листа, устать, расстроиться и ничего не сделать.

Обзор — всегда штука индивидуальная, однако для формирования личной структуры нужны время и опыт. Поэтому я рекомендую начинать с готовых решений и дальше докручивать их под себя.

Отличной стартовой точкой для обзора рабочей недели руководителя является методика 4П. Она предлагает ответить на следующие вопросы:

Прогресс. Что нового произошло, что изменилось с прошлой записи?
Проблемы. С какими проблемами вы столкнулись на этой неделе? Какие проблемы нужно решить?
Планы. Как вы будете решать проблемы, которые описали в вопросе выше?
Персонал. Как дела у членов команды? Чем им можно помочь? Что улучшить?

Эти вопросы затрагивают большинство рабочих моментов недели тимлида. Ответы на них помогут вам составить более ясную картину прошедших дней. В качестве приятного бонуса процесс еженедельного обзора помогает избавиться от навязчивой мысли «я ничем полезным не занимался».

Со временем вы измените этот набор вопросов под себя, но для старта их вполне достаточно.

5 нахрена: адаптация техники «пять почему»

Wed, 14 Aug 2024 00:00:00 GMT

Я очень люблю технику “5 почему”. Она действительно позволяет докопаться до истины, узнать много нового (а иногда — получить клеймо душнилы). Но практически никогда я не применяю её в чистом виде.

Одна из адаптированных форм этой техники — “5 нахрена”. Я часто применяю её, когда рассматриваю какие-то предложения: улучшения, рефакторинги, изменения в процессах и даже предложения новых фич.

Работает она точно так же, как и “5 почему”. Получив от человека предложение что-либо сделать, я задаю вопрос: “Нахрена?” Таким образом, я пытаюсь разобраться, какой именно ценностный результат хочет получить мой собеседник в результате своих действий. Вдобавок я убеждаюсь, что человек понимает (или не понимает), зачем он вообще затеял эти изменения.

Однако в процессе такого разбора важно сохранять эмпатию. Если просто долбить человека вопросами, то очень легко лишить его желания вообще проявлять инициативу. Задавая вопросы “Нахрена?”, я зачастую сам предлагаю какие-то гипотезы и в целом активно вовлекаюсь в обсуждение. При таком подходе мой собеседник, как правило, остаётся доволен, даже если идея не принимается или отправляется на доработку.

Применение подхода “5 нахрена” помогает мне брать в работу более качественные и продуманные идеи, а не тратить драгоценное время и силы команды на всё подряд. А ещё моя команда подхватывает подход и начинает “душнить” всех вокруг. :)

P.S. Прекрасным дополнением к вопросу “Нахрена?” будет вопрос “И чё?”. Частенько он вызывает глубокие философские рассуждения о ценности предложения.

Год писательства

Fri, 26 Jul 2024 00:00:00 GMT

Попытки регулярно писать я предпринимал года эдак с 2018-го. Что-то даже получалось, но обычно весь мой бодрый запал заканчивался через пару месяцев. То не мог придумать темы, то не рассчитывал силы и выгорал, то ещё что-то.

В какой-то момент я снова понял, что хочу писать. И первая же мысль была такой: «Как мне сделать этот процесс регулярным?»

На тот момент я уже был хорошо знаком с мышлением через письмо и опробовал его на себе. Результаты мне понравились: в процессе написания мысли обдумываются гораздо лучше, чем в голове. Сложность для меня заключалась именно в постановке регулярного процесса.

Не представляя себе будущего, я набил темник десятком тем из головы и написал первый пост. Быстро, не заморачиваясь, как умел. С него начался мой год стабильного писательства по три-четыре поста в неделю.

Вот что я понял за этот год.

Регулярность важнее всего. Для меня ценность написания постов заключается в самом процессе. Писательство стало структурированной, последовательной и понятной деятельностью. Мне было важнее регулярно подумать какую-то мысль, чем выдать обожемойкакой текст.
Не нужно вылизывать текст до идеала. Получится долго, больно, разочаровательно и всё равно не идеально.
Творческая импотенция случается чаще, чем хотелось бы. У меня бывали дни, когда я полчаса смотрел в стену, отчаянно пытаясь придумать тему, а потом писал пост за десять минут.
Это весело. Пока пишешь, чувствуешь себя офигеть каким умным. А затем перечитываешь текст через три-четыре месяца и нервно хихикаешь: это ж ты этот бред написал.
Комментарии бесценны. Самая приятная часть ведения блога началась с первыми комментаторами, которые делились опытом или указывали на недочёты в моих рассуждениях. Писать в стол и писать на публику — два совершенно разных по качеству опыта.

Это был непростой челлендж, но я с ним справился и продолжил писать. За год я как минимум качественно обдумал около сотни интересных мыслей. Именно это оказалось для меня важнее количества постов, реакций и попыток написать идеальный текст.

«Микросервисы. От архитектуры до релиза», Ронни Митра, Иракли Надареишвили

Wed, 24 Jul 2024 00:00:00 GMT

Мой текущий фреймворк чтения позволяет мне даже из слабеньких книг вытягивать интересные мысли. Но иногда он даёт осечку и я читаю что-то откровенно слабое.

Так вышло с книгой “Микросервисы. От архитектуры до релиза” за авторством Ронни Митра и Иракли Надареишвили.

Скажу честно - я бы не стал читать эту книгу полностью, если бы не одно но. Она была единственным вариантом на почитать, пока я ехал в Ярославль. Поэтому пришлось перелистать и познакомиться.

По моим ощущениям, книга очень напоминает «Создание микросервисов» Сэма Ньюмена на минималках. Если Ньюмен заморочился и написал довольно дотошный гайд с большим количеством интересных мыслей и практических советов, то эта книга (помимо зевоты) вызвала у меня разве что ассоциацию с рекламой какого-то вайтишного курса по типу “Стань программистом за 10 дней”.

Конечно, пару идей я оттуда выдрал. Но если хотите почитать общий гайд по микросервисам — не тратьте время и деньги на эту книгу, лучше осильте «Создание микросервисов» Сэма Ньюмена.

Обратная связь и при чём тут магическое мышление

Wed, 10 Jul 2024 00:00:00 GMT

Разбирали на консультации интересный случай. Джун работает слабее, чем ожидает тимлид, и почти не растёт.

Мы пытались придумать план действий, но он никак не складывался. Тогда я спросил:

А ты вообще разговаривал с ним о результатах и своих ожиданиях?

В ответ услышал уверенное «нет».

Мы любим думать о себе хорошо. Мало кто может объективно посмотреть на себя со стороны и сразу увидеть все слабые места. В случае с джуном разрыв может быть абсурдным: тимлид недоволен работой, а джун считает, что всё идёт прекрасно.

Его можно понять. Это первая работа, он может быть в эйфории, а что-то не так ему никто не сказал.

Такое «ну мог бы и догадаться» я называю магическим мышлением. Люди не должны ванговать, что у руководителя в голове. И точно не стоит рассчитывать, что человек сам поймёт недовольство и начнёт работать иначе.

Первый шаг тут не «план исправления», а прямой разговор. Руководитель должен описать наблюдаемое поведение, объяснить свои ожидания, выслушать версию сотрудника и договориться о следующих шагах и поддержке.

Иначе магическое мышление выстрелит в самый неприятный момент. Например, когда человек, искренне считавший свою работу хорошей, внезапно получит отказ в пересмотре зарплаты из-за низких результатов.

«Как читать книги», Сергей Поварнин

Tue, 09 Jul 2024 00:00:00 GMT

Продолжаю своё путешествие по книгам профессора С. И. Поварнина. Сегодня на очереди - прекрасная маленькая книга “Как читать книги”. По размерам она не больше студенческой методички, но мысли в ней заложены глубокие и ценные.

Книга за 3 предложения

В обучении с помощью чтения есть три ключевых аспекта: что читать, с какой целью читать и как читать. Каждый из аспектов сильно влияет на конечный результат чтения и является отдельным навыком для развития. Главное - подходить к процессу чтения и всем его аспектам осознанно, а не как нас в школе учили.

Что я могу применить

После курса чтения ничего кардинально нового для себя я не вынес, потому что я и так уже использую подходы Поварнина. Однако эта книга углубила моё понимание инструментов чтения и как их лучше применять.

Главная мысль для меня - чтение должно быть осознанным процессом на всех этапах. Все действия процесса чтения должны быть осознанными, обдуманными. Нужно с умом выбирать книги, осознанно их читать и затем внимательно работать с полученной информацией.

Также для меня оказалась важна мысль о переносе идей автора в свой контекст. Главная задача обучения - это изменение мировоззрения и поведения, а этого невозможно добиться линейным поглощением информации (привет любителям читать по 100 книг в день и смотреть все-все полезные видео в интернете.

Эта книжечка убедила меня в том, что я на верном пути.

Основные выводы и тейки

“Плохо читать” (по Поварнину) ещё хуже, чем не читать вообще. Либо будешь бросаться красивыми фразами без понимания смысла, либо получишь кашу в голове.
Брать слишком простые книги плохо - бесполезно. Брать слишком сложные книги - тоже плохо, ничего не поймешь и будет бесполезно.
Вдогонку к предыдущему пункту: осознанное чтение начинается с осознанного выбора книги.
Для осознанного выбора книги нужно понимать, какую тему я изучаю и как эта книга поможет мне в изучении темы.
Задача чтения - изменить себя, своё мышление, мировоззрение и поведение. Поэтому просто прочитать книгу особой пользы не несёт. Нужно перенести идеи автора в свой контекст. Поварнин приводит аналогию с пищеварением: идеи автора нужно переживать, проглотить и переварить, тогда они станут частью нас как микроэлементы из пищи становятся частью организма.
Сам процесс чтения тоже должен быть осознанным. Нужно вступать в диалог с автором, а не бездумно поглощать строку за строкой.

Впечатления

Я был в восторге от «Искусства спора», и “Как читать книги” повергла меня в такой же восторг. В книге всего 60 страниц, за которые С. И. Поварнин ёмко, структурированно, понятно и лаконично “наваливает базу”. Однако эти 60 страниц требуют много усилий для понимания, потому что изложенная в них информация может полностью трансформировать процесс чтения читателя.

Мне было чуть полегче, потому что я читал эту книгу уже после курса по не-чтению. Но книга Поварнина рискует стать моим настольным напоминанием о том, что нужно читать грамотно.

Я восхищён.

Как эта книга изменила меня

Сильнее всего книга повлияла на моё отношение к построенному сейчас конвейеру обучения по книгам (я это уже не могу назвать чтением, потому что оно лишь часть процесса, притом небольшая). Если раньше я сомневался в своих действиях, то теперь понял, что всё делаю правильно.

Сомнения у меня были из-за сложностей в построении процесса. Однако “Как читать книги” напомнила мне, что процесс обучения не является чем-то лёгким по-умолчанию. Автор чёрным по белому пишет: учиться сложно, так и должно быть. Анализ, проработка и переваривание информации требуют усилий.

В общем, получил приятное чувство, что всё делаю правильно. Правильно по моим меркам, конечно же.

Топ-3 моих цитат

Господи, как я страдал на этом разделе. Хочется цитировать всю книгу. Поэтому здесь я приведу просто три хороших цитаты, потому что выделить топ-3 я просто не в силах.

Не менее важно и то обстоятельство, что плохое чтение очень способствует выработке двух нежелательных типов людей: фразера и «человека с кашей в голове». Фразером называют того, кто любит говорить «громкие слова», между тем как в душе его этим словам нет соответствия. Мысли, чувства, связанные с ними, ему на самом деле глубоко безразличны. Его жизнь и поступки часто определяются совершенно противоположными «настоящими» его мыслями и чувствами. У человека с «кашей в голове» надерганы отовсюду разные отрывки знаний. И все они без связи друг с другом (или в совершенно фантастической «связи»), без системы, плохо понятые и совершенно непереваренные.

При самообразовании работа над книгой должна быть самая серьезная, упорная, трудная и часто очень долгая. Но времени на нее жалеть нечего: окупится с избытком. Если даже вы забудете потом книгу – работа над ней не пропадет; она останется в виде полезных навыков, подвинувшегося развития, накопленного уменья и сил. Но и книгу вы не забудете. Такая работа над книгой есть лучшее применение так называемого рационального способа запоминания.

Наряду с вопросами и задачами, которые возникают у нас при стремлении понять книгу, обыкновенно при хорошем чтении появляется ряд вопросов и мыслей другого характера. Мы оцениваем мысли автора, соглашаемся или не соглашаемся с ними. Если соглашаемся, то сравниваем их со своими, делаем из них свои выводы, ставим свои вопросы, из них вытекающие. Если не соглашаемся, то подвергаем их критике, стараемся опровергнуть и т. д. Вся эта в высшей степени полезная работа углубляет и чтение, и нашу мысль. Кто читает книгу, содержащую много рассуждений, а работы этой не производит, – тот плохо читает.

Zero Bug Policy — серебряная пуля?

Mon, 08 Jul 2024 00:00:00 GMT

Посмотреть чей-то взгляд на какую-то интересную тему хорошо. А как насчёт двух взглядов? Мы с @chernov_sharit решили провести небольшой эксперимент и написать пост на одну и ту же тему. Я предложил высказаться о zero bug policy. В общем, приятного чтения и обязательно напишите, как вам такой формат :)

Чем привлекает Zero Bug Policy

Zero Bug Policy - это стратегия управления бэклогом багов по принципу “или фиксим сразу, или закрываем и забываем”. Как и у любого подхода, у зеро бага есть свои плюсы и минусы.

Конечно, очень подкупает чистый бэклог. У нас есть небольшое количество багов, которые мы будем фиксить - и точка. Всё остальное игнорируется. Всем хорошо и приятно от того, что с бэклогом нет проблем - его не надо чистить, обсуждать, приоритеты там всякие расставлять. Удобно же!

Но любая дихотомия на мой взгляд не есть хорошо. Мир не чёрно-белый, поэтому решения категории “или-или” частенько оказываются неудобными или просто нерабочими. Зеробаг на мой вкус просто не очень удобен.

Где подход ломается

Пока у команды всё хорошо и гладко - зеробаг может работать очень даже неплохо. Всё круто, все счастливы. Но медовый месяц продолжается до первого ощутимого подгорания сроков. Представьте ситуацию: команда пилит важную фичу с жёстким дедлайном. И тут ей начинают прилетать баги. Что делать? Начнут фиксить баги - сорвут сроки по фиче. Но согласно политике баги нужно закрывать. Но баги важные, поэтому они прилетают снова и снова. Получается замкнутый круг.

Между двумя крайностями

Полярная альтернатива зеробагу - монструозный бэклог с багами времён палеозоя (я видел как-то бэклог из почти 500 багов, некоторым было по 8-9 лет). Тоже так себе ситуация, смотришь на эту бездну - и руки опускаются.

На мой взгляд, истина находится где-то посередине. Некоторые баги вообще заводить не надо, если команда чётко понимает, что фиксить их в ближайшее время не будет. Какие-то можно завести и сразу отправить в Won’ Fix, чтобы сценарий воспроизведения не потерять на будущее. Но постоянно дёргать их туда-сюда большого смысла я лично не вижу.

Zero bug policy позволяет не париться насчёт бэклога багов и не заниматься его управлением. Однако вместе с тем этот подход немного сужает понимание реального положения дел в качестве продукта. В общем, подход стоит попробовать, но как всегда - думайте своей головой и в своём контексте. Мне подошло оставить всё как есть, стащив несколько идей из зеробага (например, практика прибивания багов старше определённого возраста).

Задача менеджера — построить работающую систему

Fri, 05 Jul 2024 00:00:00 GMT

— Как вы стали тимлидом?

— Предыдущий умер.

— Что?

На моей практике новоиспечённые тимлиды больше всего охреневают с того, что не могут увидеть и пощупать результаты своей работы.

Раньше всё было просто. Сидишь, пишешь код целый день, вечером сделал коммит — и домой. Работа понятна, результат заметен. Но после перехода в тимлиды бывший разработчик начинает заниматься каким-то мифическим «менеджментом». Обычно он выглядит как полный календарь созвонов и ощущение бессмысленности в конце дня.

Проблема в том, что роль изменилась, а парадигма мышления — нет. В душе начинающий тимлид всё ещё остаётся разработчиком и хочет получать осязаемые результаты. Поэтому отчаянно пишет несколько строк кода между созвонами, а затем сравнивает свою продуктивность с предыдущей ролью и неизбежно расстраивается.

Оценивать работу руководителя строками написанного им кода так же бессмысленно, как оценивать кота по умению летать. Мой иногда крутит сальтухи, но это скорее приятный бонус, чем естественная особенность.

Результат руководителя — работа команды

Мне нравится аналогия с производственным конвейером из книги Элияху Голдратта «Цель». Тимлид работает не над отдельной деталью, а над системой, которая должна устойчиво выдавать результат.

Это шире, чем соблюдение сроков. Руководителю стоит смотреть на команду и спрашивать:

насколько хорошо она справляется с работой;
где буксуют задачи;
сохраняется ли качество результата;
довольны ли люди своей работой.

Я сам в своё время с размаху ударился головой об эту проблему. Отчаянно писал код и делал код-ревью между созвонами, а иногда и прямо на них. Но со временем понял, что из-за этого страдает моя основная работа — построение команды. После этого я перенёс написание кода в категорию «хобби на работе» и сосредоточился на системе. Стало легче.

Начинающим тимлидам, которые не понимают, как оценивать свой день, мне помогала такая мысль: если команда устойчиво делает задачи, не разваливается от каждого изменения и не срётся между собой, то работа руководителя оставила вполне осязаемый результат — даже если за день он не написал ни одной строки кода.

«Делай как в Google», Титус Уинтерс, Том Мэншрек, Хайрам Райт

Tue, 02 Jul 2024 00:00:00 GMT

Делать как в Google или не делать как в Google — вопрос интересный. Но подсмотреть, как у них там делается, всегда интересно. Для этого и была написана книга «Делай как в Google».

Книга за три предложения

В больших корпорациях грамотно выстроенные процессы становятся ещё важнее из-за рычага количества людей. Google довольно успешно смог эти процессы выстроить, и в книге авторы показывают, как привычные практики проявляют себя на масштабах: хорошо, но с модификациями. Причём ограничиться просто техническими процессами вроде код-ревью не получится, очень важной становится социальная составляющая: общение, менеджмент, обмен опытом и так далее.

Что я могу применить

Забрал пару полезных принципов развития культуры инноваций в команде. Например, хорошая практика — дать людям возможность легко получить умеренные ресурсы для экспериментов.
Убедился, что моя приверженность к написанию тестов и применению статических анализаторов — масштабируемая и правда полезная штука.
Пока не могу применить, но задумался об инфраструктуре интеграционных тестов для больших продуктов, где прогон может занимать сутки-двое. В книге даётся довольно чёткое разделение тестов по размеру и критичности, поэтому вполне можно не гонять все автотесты в одном пайплайне.
Trunk-based development, с одной стороны, не имеет доказательств эффективности, с другой — есть успешные кейсы применения. Попробовать точно стоит, но аккуратно.

Основные выводы и тейки

Для масштабирования организации нужны масштабируемые процессы обеспечения качества.
Чем больше организация, тем более важную роль играет грамотный менеджмент.
Автоматизировать нужно много и с удовольствием: ручной труд масштабируется крайне плохо.
При росте организации могут начать вылезать ну очень неожиданные проблемы.

Впечатления

Впечатления смешанные. С одной стороны, было прикольно почитать, как там у них в Google. С другой — осталось ощущение однобокости. Книга ощущается очень поверхностной, без погружения в какую-либо тему хотя бы чуть-чуть. В конце не появилось понимания, зачем авторы это в принципе написали :)

Вообще мне было искренне интересно почитать о том, как пишется софт в большой компании и насколько много всего есть вокруг непосредственного процесса программирования.

Как эта книга изменила меня

Книга заставила меня плотненько так подумать о важности роли руководителя в большой организации. Масштабируемость и рост во многом зависят от людей, которые за них отвечают. Решения, принимаемые этими людьми, могут превратить организацию в ракету или гужевую повозку. В очередной раз понял, насколько важны фундаментальные навыки грамотного мышления и банальная логика.

Три цитаты

В программировании ремесленники-одиночки встречаются крайне редко, и никто из них не достигает вершин самостоятельно: их достижения, меняющие мир, почти всегда являются результатом искры вдохновения, сопровождаемой упорной командной работой. Великая команда блестяще использует своих суперзвёзд, и целое всегда больше, чем сумма его частей. Но создать команду из суперзвёзд очень сложно. Сформулируем эту идею проще: программирование — это командная работа.

Мы в Google стараемся задать тон общения, когда к компании присоединяется «нуглер» (новый гуглер). Чувство психологической безопасности мы создаём с помощью назначения наставника — человека, который не является членом команды, менеджером или техническим руководителем, в обязанности которого входит отвечать на вопросы и оказывать помощь нуглеру. Наличие официально назначенного наставника для обращения за помощью облегчает новичку работу и избавляет его от страха, что он может отнимать время у коллег.

Идея проектировать системы так, чтобы впоследствии их можно было объявить устаревшими, возможно, выглядит слишком радикальной, но она получила широкое распространение в других инженерных дисциплинах. Рассмотрим, например, атомную электростанцию, которая представляет собой сложнейшее инженерное сооружение. При её проектировании необходимо учитывать её вывод из эксплуатации по истечении срока службы вплоть до выделения средств на эти цели. Необходимость вывода атомной электростанции из эксплуатации существенно влияет на многие решения, принимаемые инженерами.

Я не знаю, но я знаю того, кто знает

Wed, 26 Jun 2024 00:00:00 GMT

Тимлид не должен знать ответы на все вопросы. Вполне достаточно знать тех, кто эти ответы знает.

Поток информации у тимлида огромный: своя команда, смежники, продукт, процессы, технические решения. Попытка найти и запомнить ответы на все вопросы быстро превращается в отдельную работу, которая всё равно обречена на провал.

Эта ситуация напоминает мне джунов, которые зачем-то заучивают сигнатуры библиотечных методов. Даже ностальгия пробивает: перед первыми собеседованиями по C# я сам зубрил сигнатуры методов Entity Framework. Абсолютно бесполезное занятие.

Гораздо важнее уметь сформулировать вопрос и быстро найти источник ответа.

Тимлид как API Gateway

В работе нужные знания часто хранятся не в документации, а в головах других людей. Поэтому тимлид может превратиться в подобие API Gateway: сам не содержит всей бизнес-логики, но знает, куда направить запрос.

Эта метафора не снимает с руководителя ответственность. Недостаточно ответить «спроси вон у того человека» и забыть о вопросе. Тимлиду нужно:

понять, что именно пытается решить человек;
дать нужный контекст обеим сторонам;
выбрать правильный маршрут;
убедиться, что вопрос не потерялся и результат получен.

Тимлид не обязан быть самой большой базой знаний в команде. Его задача — построить сеть, в которой знания находятся и передаются без него. Приятный бонус: люди выходят за рамки команды и постепенно учатся искать ответы самостоятельно.

С появлением AI-агентов эта модель получила ещё один маршрут. Я написал об этом продолжение: «С агентами „я не знаю“ перестало означать „я не могу“».

«Искусство спора», Сергей Поварнин

Tue, 18 Jun 2024 00:00:00 GMT

Сегодня у нас на повестке дня гость из 1923 года - «Искусство спора» за авторством профессора Сергея Иннокентьевича Поварнина. Невероятное по качеству написания и контенту произведение, ни капли не утратившее свою актуальность.

Книга за 3 предложения

Написанное более века назад, но не утратившее актуальности руководство по тому, как вести спор. Книга рассказывает о правилах и принципах ведения качественного спора, о видах спора и о различных уловках, которые могут применять хитрые оппоненты. Информация применима к любым видам переговорных процессов, будь то обсуждение рабочей задачи или дискуссия о вечных философских концепциях.

Что я могу применить

Для меня самой применимой частью оказалась детализация обсуждаемого. Поварнин с самого начала акцентирует внимание читателя на том, что перед началом спора нужно определиться, о чём вообще идёт разговор. Часто споры напоминают притчу о том, как слепые мудрецы пытались слона осознать.

В целом меня всю книгу не покидала мысль, что главный метанавык ведения спора - это осознанность. Она позволяет заметить какие-то затенённые моменты и прояснить их, она же позволяет защищаться от целой плеяды уловок - от выведения на эмоции до хитрых софизмов.

На практике я это начал в первую очередь применять на рабочих обсуждениях. Довольно часто на совещаниях сталкивался с тем, что долгий разговор оказывался бесполезным, потому что говорили по сути о разных вещах. Теперь я более осознанно подхожу к этому и стараюсь конкретизировать предмет обсуждения (и конечно же цель).

Довольно интересно было почитать про разные хитрые уловки, в частности целый класс софизмов. К счастью, в работе я с подобными вещами практически не сталкивался, но в повседневных спорах - регулярно. Не скажу, что я преисполнился понимания того, как им противодействовать, но понятнее стало. Помогает осознанность - не вылетать на эмоции и думать о том, чего хочет добиться оппонент.

Ещё Поварнин даёт очень интересный совет - в споре доверять своей интуиции. Наш мозг постоянно анализирует поток данных и иногда может в форме озарений давать какие-то подсказки о происходящем. Чаще всего такие озарения и называют интуицией.

Основные выводы и тейки

Спор - очень обширное понятие. Это далеко не всегда разговор двух людей. Спором может быть переписка (даже в книгах), дебаты, групповое обсуждение.
У спора могут быть разные цели (как и у его сторон). В зависимости от конфигурации этих целей будут меняться способы ведения спора (тон, уловки, выбор аргументов и так далее).
Цель спора далеко не всегда (на самом деле - крайне редко) в выяснении истины. Есть огромный класс целей вплоть до спора ради самого процесса спора.
В любом случае спор требует внимания и детального прояснения используемых тезисов и аргументов. Иначе получается притча про слона и слепых мудрецов.
Нужно относиться с уважением к своему оппоненту и его аргументам. Но не с раболепием, хороший спор требует тщательного анализа того, что говорит (или пишет) противник.
В споре есть возможность применить огромное количество уловок. Некоторые из них вполне допустимы (например, давить на аргумент, который пошатнул оппонента). Некоторые же откровенно грязные и низкие (например, вывести человека на эмоции оскорблениями).
Есть целый огромный класс манипулятивных уловок, которые Поварнин называет софизмами. Сюда входят отбрасывание аргументов, подмена понятий, двойные стандарты, домыслы, обвинения в скрытых мотивов, двусмысленность и целая куча всего остального.

Впечатления

Ощущения от чтения этой книги были невероятные. В ней всего 200 страниц брошюрного формата, но каких! Я с каждой строчкой чувствовал, что эту книгу писал человек невероятного академического ума. Каждое слово наполнено смыслом и находится на своём месте. И даже стиль автора далеко не старомодный, спустя 100 лет книга прекрасно читается.

Книга очень плотная по информации. Понятия - короткие и ёмкие. Примеры - полные и краткие. Для меня это прекрасный образец учебника.

Даже если вы не занимаетесь регулярными спорами (во что верится с трудом) - рекомендую прочитать просто как прекрасный экземпляр обучающей литературы. Тимлидам и прочим руководителям считаю мастрид.

Как эта книга изменила меня

Пожалуй, больше всего эта книга повлияла на мою осознанность. Я стал внимательнее читать и слушать, наблюдать за применением слов и структурой предложений. Также стал периодически лазить по словарям, чтобы убедиться, правильно ли я понимаю то или иное слово.

Я заметил, что стал гораздо критичнее воспринимать то, что читаю в книгах. Раньше неподкреплённые мысли автора я мог пропустить, но теперь внутренний голос начал спрашивать: “А не порожняк ли ты гонишь, дорогой автор?” И обычно само появление этого вопроса намекает, что что-то не так. Например, недавно целую главу прочитал с таким ощущением, полез в пруфы - а там “эффективность не доказана”.

А ещё я стал гораздо меньше спорить, потому что незачем. Я и раньше критично относился к обсуждениям, но сейчас стал задавать себе простой, топорный вопрос: “Мне этот спор зачем? Какова моя цель?” Чаще всего ответа нет, поэтому я в спор и не лезу.

Сами обсуждения я теперь тоже воспринимаю совершенно иначе, потому что то же наличие слушателей - это один из важных параметров конфигурации спора.

Короче, книга дала мне +10 к духоте :)

Топ-3 моих цитат

В общем, довольно правильна примета: чем более кто говорит без нужды иностранных слов, тем вероятнее, что он не способен к самостоятельному мышлению.

Уменье слушать (и уменье «читать») — уменье трудное, но нечего обольщать себя: без него хороший спорщик немыслим. Это первое и одно из неизбежных условий уменья спорить.

Кто хорошо изучил уловки софистов и умеет сейчас же распознавать их, тот в значительной мере обезопасит себя от них. Как отвечать на каждую из них в том или другом случае — зависит от такта, находчивости и т.д. спорщика. «Прописать особое лекарство» против каждой из них и для всех обстоятельств вряд ли возможно. Можно сказать только одно: кто принимает в споре все те предупредительные, «профилактические», так сказать, меры, какие мы указали в этой книге, тот в значительной мере охранит себя от всяких поползновений софиста. Главнейшие из них такие: а) спорить только о том, что хорошо знаешь. Помнить, словом, наставление щедринского ерша «карасю-идеалисту»: «чтоб споры вести и мнения отстаивать, надо, по меньшей мере, с обстоятельствами дела наперед познакомиться»; б) не спорить без нужды с мошенником слова или с «хамоватым» в споре, а если надо спорить, то быть все время «начеку»; в) научиться «охватывать» спор, а не брести от довода к доводу; г) всячески сохранять спокойствие и полное самообладание в споре — правило, особенно рекомендуемое; д) тщательно и отчетливо выяснять тезис и все главные доводы — свои и противника; е) отводить все доводы, не относящиеся к делу.

Как писать хорошие тесты

Mon, 17 Jun 2024 00:00:00 GMT

Наверняка многие слышали старую шутку:

Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте.

Однако мало кто уделяет столько же внимания качеству тестов. А зря: тесты — это тоже код, причём разработчик обычно начинает внимательно читать их в самый неприятный момент — когда что-то упало и нужно быстро понять причину.

Поэтому старую шутку я бы переформулировал так:

Пишите тесты так, чтобы вам был искренне благодарен тот человек, который однажды будет их чинить.

Этим человеком вполне можете оказаться вы сами. Я бывал в такой ситуации и был себе благодарен за то, что когда-то не поленился написать тесты нормально.

Тест как описание поведения

Документация описывает поведение, особенности и ограничения. Тесты проверяют поведение, особенности и ограничения. Их задачи заметно пересекаются.

Хорошо написанная документация помогает быстро разобраться, как работает система. Хорошо написанные тесты делают то же самое, только ещё и проверяют, что описание не разошлось с кодом.

Разные типы тестов документируют систему на разном уровне:

юнит-тесты — поведение небольшого компонента;
интеграционные — поведение сервиса и его связей;
end-to-end — поведение всей системы;
нагрузочные — пределы системы под нагрузкой.

У каждого уровня своя аудитория. Юниты чаще нужны разработчикам. Интеграционные и end-to-end тесты помогают ещё тестировщикам, аналитикам и продактам. Нагрузочные тесты дают контекст разработчикам, тестировщикам и SRE.

Конечно, тесты не отменяют документацию. Но если команда относится к ним как к исполняемому описанию поведения, становится заметнее и качество требований: если разработчик не понимает, как проверить задачу, то, скорее всего, он ещё не до конца понял, что нужно реализовать.

Полнота и краткость

Хороший тест должен быть одновременно полным и кратким.

Полный тест содержит всю информацию, необходимую для понимания сценария. Читатель должен разобраться, как тест работает и за счёт чего код выдаёт нужный результат. Сюда относятся создание заглушек, подмена ответов, явное описание ожидаемого результата и даже нормальные названия переменных.

Полный тест понятен без дополнительного ковыряния в документации и исходном коде.

Краткий тест не содержит лишней информации. Обычно визуальный мусор появляется при создании моков: пятнадцать строк подготовки при общей длине теста в двадцать. Такие детали можно спрятать в генераторе мок-объектов и оставить в сценарии только значимые параметры.

Краткость усиливает полноту, потому что читателю нужно проанализировать меньше информации. Вместе эти характеристики дают тест, в котором есть всё нужное и нет ничего лишнего.

Название должно описывать поведение

Название теста — ключ к его пониманию. Хорошее название сразу объясняет, какой сценарий проверяется. На этой мысли построен behavior-driven development.

Для названий я использую несколько правил.

Писать полными предложениями. Мы не газету верстаем и буквы экономить не нужно.
Указывать условия и последствия. Из названия должно быть понятно, что именно произойдёт и при каких обстоятельствах.
Следовать принципу DAMP. В книге «Делай как в Google» он расшифровывается как descriptive and meaningful phrases — описательные и осмысленные фразы.

Как не надо:

Проверка валидации;
Должен вернуть ошибку, если всё плохо;
Проверяем правильное поведение.

Как лучше:

Должен выбросить UserNotFoundException, если пользователь не найден по ID;
Должен вернуть false, если пользователь младше 18 лет;
Должен зарегистрировать пользователя, если указанного email нет в базе.

Огромную неструктурированную документацию никто не читает. С запутанными тестами происходит то же самое. Хороший тест читается как короткое и актуальное описание поведения системы — именно поэтому однажды он может сэкономить кому-то часы разбирательств.

Тестировать поведение, а не внутренности

При написании теста я стараюсь смотреть на компонент как на чёрный ящик. Внутреннее устройство либо слишком сложное, либо просто не имеет значения для проверяемого сценария. Подали конкретный вход — получили ожидаемый выход.

Тесты, привязанные к внутренним циклам, условиям и приватным методам, ломаются при рефакторинге, даже если поведение компонента осталось прежним. В итоге они защищают текущую реализацию, а не результат.

Особенно подозрительно выглядит необходимость добираться в тесте до приватного метода. Если важное поведение нельзя проверить через публичный контракт, возможно, проблема находится не в тесте, а в границах самого компонента.

Сколько тестов достаточно

На этот вопрос часто отвечают процентом покрытия. Coverage полезен как стартовая метрика, особенно если тестов в проекте почти нет. Но он показывает лишь то, какие строки выполнялись во время тестов, а не качество проверенных сценариев.

Если поставить слишком высокую планку, команда начинает писать тесты ради покрытия. Появляются проверки деталей реализации, растёт время прогонов, а уверенности в бизнес-сценариях больше не становится.

Для себя я использую несколько эмпирических правил:

Процент покрытия нужен как ограничитель, но сам по себе не является целью.
Покрытие не должно незаметно снижаться без осознанного решения команды.
Каждый тест должен защищать понятное поведение или важный риск.
Если тест можно удалить без потери уверенности и описанных сценариев, скорее всего, он лишний.

Универсального числа здесь нет. Чем опытнее команда и дороже ошибка, тем содержательнее должен быть разговор о рисках вместо механического требования «сделать 100%».

Как докручивать процессы в команде

Fri, 14 Jun 2024 00:00:00 GMT

После предыдущего поста о запуске процессов прилетел в личку вполне закономерный вопрос: что делать после запуска процесса? Как его докручивать?

Вопрос хороший. Запуск процесса — это первая, обязательная, но далеко не главная часть. Самое интересное начинается, когда процесс показывает свою ценность и нужно его как-то улучшать дальше.

Когда я в первый раз столкнулся с задачей развития процессов, то поначалу впал в ступор. Я делал какие-то действия, что-то выстреливало (иногда — в ногу). Результат был, но я не мог назвать его системным и управляемым. Конечно же, хотелось видеть чуть другую картину.

Но в какой-то момент в голове появилась мысль, что процесс — это тоже продукт. У него есть пользователи и ценность, которую он им даёт. И я подумал: а что, если подойти к развитию процесса как к развитию продукта? Немного подумав, я вспомнил про HADI-циклы.

Методология HADI

HADI — это методология тестирования гипотез. Расшифровывается так:

Hypothesis — гипотеза. Какую идею проверяем?
Action — действие. Как мы будем проверять идею?
Data — данные. Как мы будем анализировать результаты идеи?
Insights — выводы и инсайты. Анализируем, что у нас получилось, и делаем выводы.

Методика проста: мы бесконечно крутимся в цикле, состоящем из этих четырёх действий. Берём гипотезу, делаем с ней действия, собираем данные, делаем выводы. Процесс достаточно простой и понятный, но он позволяет сделать эволюцию управляемой, потому что даёт чёткую систему действий.

HADI-циклы в реальном мире

Разберём выдуманный пример.

Техлид Вася предполагает, что внедрение процесса грумминга технического бэклога поможет команде закрывать больше технических задач за спринт. Это гипотеза.

Техлид Вася прикидывает на колене процесс грумминга и договаривается о пробной итерации с разработчиками Петей и Колей. Вася, Петя и Коля проводят грумминг: разбирают задачки, что-то прибивают, что-то оценивают. Получают ряд задач, которые берут в спринт. Это действие.

Допустим, задачи в спринте успешно выполняются. После этого техлид Вася собирает обратную связь по процессу с разработчиков и тимлида. Получает примерно такие отзывы:

Петя: «Прикольно, таски описаны, берёшь и делаешь, думать не надо».

Коля: «Чёт хз, созвон какой-то непонятный, но хоть техдолг в спринте поделать дали».

Тимлид: «Вот так бы всегда, задачи сразу с оценкой, я хоть планировать нормально могу».

Это данные.

Дальше Вася анализирует то, что получилось в итоге. Он приходит к следующим выводам:

Процесс принёс пользу — получилось запланировать задачки в спринт.
Описанные задачи помогают разработчику вспомнить, что вообще делать надо.
Грумминг технических задач можно улучшить.

Это инсайты. Последний инсайт может стать рядом новых гипотез.

Конечно, в реальной жизни всё обычно идёт не так гладко и красиво. Но наличие методологии помогает не впадать в ступор в непонятных ситуациях.

Налаживание процессов методом прогрессивного JPEG

Wed, 12 Jun 2024 00:00:00 GMT

Обсуждали вчера с менти такой интересный вопрос: как поставить в команде процесс системной работы с техдолгом? Тема сама по себе большая и сложная (я даже выступление по ней делал полгода назад). Но сегодня не об этом.

Проблема следующая: если в команде в принципе нет процесса работы с техдолгом (а есть просто стихийная работа “под настроение”), то строить сразу сложный процесс - это фактически дорога в ад :)

Человеки - существа ленивые, поэтому сложному процессу никто следовать не будет. Его будут саботировать, избегать, находить в нём всякие-разные дырки. В итоге вместо результата получим огромный документ с правилами, которые никто не соблюдает. Вместо этого я предложил применить метод прогрессивного джипега.

Название метода взято со способа прогрузки JPEG. Обычный JPEG прогружается строка за строкой, а прогрессивный прогружается весь сразу и затем постепенно увеличивает степень детализации (или снижает шакальность, как вам больше нравится).

Если перекладывать эту аналогию на процесс, то вместо проработки всего процесса и раскатывания его на команду (построчная загрузка) нужно сделать что-то, что заработает хоть и криво, но уже здесь и сейчас (прогрессивная загрузка). Проще говоря, мы находим способ, который позволит получить первые результаты и дальше его “докручиваем”. Напоминает lean, не так ли?

Дальше уже начинается сбор обратной связи, улучшения, модернизации и так далее. Но суть неизменна - первоначально запущенный процесс продолжает работать в любой момент времени. Вопрос только в степени его детализации.

Understanding Message Brokers by Jakub Korab

Tue, 11 Jun 2024 00:00:00 GMT

Я планировал написать обзор на книгу «От монолита к микросервисам» Сэма Ньюмена, но переезд всё ещё в процессе и она оказалась похоронена где-то в бездонных глубинах коробок.

Поэтому сегодня будет короткий обзорчик на маленькую, но очень ~~гордую~~ полезную книгу Understanding Message Brokers by Jakub Corab.

Книжка рассказывает про основы обмена сообщениями с помощью брокеров. В ней всего три раздела — общий обзор асинхронной коммуникации, обзор ActiveMQ и обзор Kafka. Скажу честно, обзор ActiveMQ я не читал — неинтересно. А вот всё остальное мне очень понравилось. Вся базовая информация уложена компактно, понятно и без лишней воды.

Сама книжечка не стала для меня откровением, ничего кардинально нового я не узнал. Но я и читал её не с целью обучения. Я хотел разобраться, достойна ли она занять почётное место в моём списке рекомендаций для менти. Спойлер: вполне достойна!

Если вы не знакомы с брокерами и асинхронной коммуникацией, то Understanding Message Brokers станет отличной отправной точкой в этом мире. Но если вы уже работаете с брокерами, понимаете проблемы eventual consistency и знакомы с основными понятиями Kafka — вряд ли найдёте в ней что-то новое.

Приятного чтения!

Меняй приоритет со скрипом

Fri, 07 Jun 2024 00:00:00 GMT

Лучшее описание чайка-менеджмента - притча про мальчика, который кричал: «Волки, волки!»

Когда-то я работал в командах, где каждый день менялись приоритеты. В какой-то момент я перестал запоминать, что было вчера, потому что это не имело смысла. Через полгода такой работы у меня развилось преддепрессивное состояние: вкладываться в дело, которое завтра станет не нужно, не хотелось.

Я не выдержал хаоса и уволился. Но опыт пригодился, когда я сам стал тимлидом в такой же среде. Вокруг всё горело и трещало по швам, а внутри команды было тихо.

Приоритет можно изменить, но за это нужно заплатить

Я сделал смену приоритета команды чертовски трудной. Чтобы изменить её работу, нужно было убедить меня в острой необходимости изменения.

Это приводило к спорам. Иногда мы договаривались, иногда - нет. Меня называли душнилой и даже говорили, насколько сильно я «заебал своими вопросами». Зато команда продолжала доводить фичи до конца.

Как сказал Максим Дорофеев: «Чтобы впихнуть невпихуемое, нужно выпихнуть впихнутое ранее». Новый приоритет всегда вытесняет старый. К этой цене добавляются недоделанная работа, спешка и переключение контекста.

Сделать отказ частью процесса

Одна из моих команд постоянно отвлекалась на просьбы соседних отделов. У всех вокруг то лапы ломило, то хвост отваливался, а наш say/do ratio показывал довольно унылый результат.

На ретроспективе выяснилось, что ребятам трудно самим решить, насколько важен запрос и можно ли ради него отложить текущую задачу. Поэтому я ввёл простое правило: все новые задачи и спорные запросы отправлять мне.

Сотрудник мог ответить: «Я сейчас работаю над приоритетной задачей X. Пожалуйста, передай запрос нашему лиду, он его приоритизирует». Часть просьб отвалилась по дороге, а оставшиеся приходилось оценивать мне. Зато команда стала реже отвлекаться, а say/do ratio заметно вырос.

Просто разрешить людям говорить «нет» было недостаточно. У сотрудника может не быть контекста за пределами команды, а выглядеть вредным не хочется. Я дал команде безопасный способ отказа и забрал конфликт на тот уровень, где было больше контекста и полномочий.

Такая централизация не обязана быть вечной. По мере роста контекста и уверенности часть решений можно вернуть команде. Важен сам принцип: приоритет можно изменить, но его цена должна быть видна.

Код или данные: что выносить из монолита первым

Wed, 05 Jun 2024 00:00:00 GMT

Распил монолита - дело хитрое. А когда дело хитрое, то всегда хочется в первую очередь сделать самое понятное.

Чаще всего самым понятным оказывается вынесение кода в отдельный микросервис. Команда думает: «Ща микросервис запустим, а потом и данные подтянем». При этом как они эти данные будут подтягивать, никто не задумывается. В итоге получаем распределённый монолит, в котором микросервисы продолжают ходить в общую базу и не могут развиваться независимо.

Бывает и наоборот - базу распилили, а бизнес-логика настолько запутанная, что получается просто монолит, который работает с двумя источниками данных.

И в том, и в другом случае очень частый кейс - “впиливание” ранее выпиленного назад в монолит. Добавим сюда же потерю времени, нервы, пост-мортемы и прочие неприятные последствия. Если команда сделает неправильные выводы и не отрефлексирует этот опыт, то мы получим структурную единицу, которая будет как огня бояться архитектурных задач и не станет развивать систему даже под страхом пытки.

Что же делать? Перед миграцией нужно хотя бы на высоком уровне спроектировать целевую архитектуру и порядок перехода. Это не означает, что нужно заранее детализировать весь проект. Но команда должна понимать, как будут разделены и код, и данные.

Начинать с того, что проще и понятнее - плохая идея (пруфы выше). Гораздо профитнее будет сначала хорошенько проанализировать объём работы и потенциальные сложности. Прежде чем приступать к вынесению микросервиса нужно понять, как вы будете выносить И код, И данные. Это две части одного целого, поэтому игнорирование одной из них ведёт к боли и “впиливанию” назад ранее выпиленного.

Преимущества подобного подхода очевидны. В первую очередь, вы защищаете себя от ситуации, где можно вынести только одну часть сервиса (код или данные). Подумать заранее значит иметь ответы на вопросы:

Что мы будем выносить?
Что вынесем сначала: код или данные?
Как будем выносить код?
Как будем переносить данные?
Какие конкретные шаги нужны, чтобы всё заработало?
Как вернуться назад, если гипотеза не сработает?

Когда вы видите всю картину целиком, то становится не так важно, с чего начинать. Вы можете выбрать более быструю часть, чтобы получить какой-то quick win или наоборот более сложную, чтобы потом простое доделать. Но самое главное - у вас всё время будет перед глазами целостный проект.

Мышление письмом - страшная сила. Подумайте сами, что выгоднее: две недели подумать и сделать нормально или “и так сойдёт”, месяцы работы впустую и чувство разочарования? Я вливал микросервисы назад, поэтому мой ответ - подумать.

Любопытствующим рекомендую книгу Сэма Ньюмена «От монолита к микросервисам». Только не мучьте себя русским переводом, он ужасен.

«Создание микросервисов», Сэм Ньюмен

Tue, 04 Jun 2024 00:00:00 GMT

Мне для работы с менти нужно всегда держать под рукой список хорошей рекомендованной литературы. Поэтому иногда я читаю базовые книги, чтобы свой список пополнить. Сегодня — обзор на одну из таких книг.

Книга за три предложения

Книга представляет собой верхнеуровневый справочник по микросервисной архитектуре. Из неё можно узнать особенности микросервисной архитектуры, а также получить обзор всех технических и процессных областей, которые нужно учесть при разработке микросервисов. Книгу можно использовать для решения о переходе на микросервисы и технического планирования.

Что я могу применить

Напрямую практически ничего, потому что я так или иначе уже со всем этим сталкивался. Однако я укрепился в ряде своих убеждений и получил отличный список для чтения на будущее. А ещё несколько интересных тем для постов в блог.

Также я могу смело рекомендовать эту книгу своим менти, потому что она даёт достаточно хорошее общее понимание микросервисной архитектуры.

Основные выводы и тейки

Микросервисы не всегда хорошо, монолит не всегда плохо, it depends. Но на тему it depends мне больше понравилась Software Architecture: The Hard Parts.
Микросервисы требуют не только технической реорганизации, но и применения новых подходов к проектированию, моделированию и дизайну систем.
В микросервисной архитектуре крайне важны мониторинг и наблюдаемость, потому что отслеживать состояние микросервисной системы кратно сложнее.
Кросс-функциональные команды лучше всего подходят для микросервисной архитектуры, потому что можно чётко ограничить зону владения и ответственности команды.

Впечатления

Книга очень общая, хотя и с примерами. Мне она кажется хорошим справочником по темам, важным для микросервисной архитектуры. Написана понятным, простым языком. Есть схемы и визуальные пояснения.

Отдельно хочу отметить рекомендации и комментарии автора к теоретическим выкладкам — они правда хороши и достойны внимания, чувствуется практический опыт человека. Для меня именно они были наиболее интересны в книге.

Ещё один большой плюс для меня — Ньюмен в каждой главе даёт ссылки на другие источники, в которых можно более глубоко изучить интересующую тему. Это очень круто, потому что не придётся гуглить. Я себе довольно внушительный reading list собрал.

Я буду рекомендовать эту книгу своим менти, которые развиваются в архитектуре, как вводное руководство и настольный справочник по микросервисам.

Что не понравилось: водянистость и объём, книгу можно сократить примерно на 30% без потери качества. Много лишнего текста и примеров.

Как эта книга изменила меня

Фактически никак. Я по большей части взял эту книгу в руки с целью ознакомления и не надеялся реально вытащить что-то полезное для себя. Но я укрепился в некоторых базовых вещах, которые, например, почерпнул из книги «Чистая архитектура».

А ещё я подкачал свои новообретённые навыки чтения.

Три цитаты

Если вам нужна чистая архитектура, обязательно заламинируйте распечатку идеальной версии архитектуры системы, которая могла бы у вас быть, если бы вы обладали даром предвидения и безграничными средствами.

Микросервисы не должны быть самоцелью. Вы ничего не выиграете просто от их присутствия в системе. Выбор микросервисной архитектуры — это осознанное, рациональное решение. Думать о переходе следует только в том случае, если вы не можете найти более простого способа достичь своей конечной цели имеющимися средствами.

Извлечение кода приложения обычно проще, чем извлечение данных. Однако если код приложения извлекается без ошибок, но извлечение информации оказывается невозможным, возникают проблемы. Поэтому перед началом декомпозиции подумайте, как будут извлекаться код приложения и данные.

«Гибкое сознание», Кэрол Дуэк

Tue, 28 May 2024 00:00:00 GMT

Сегодня у нас в гостях книга Кэрол Дуэк “Гибкое сознание”. Автор - член Американской академии наук, профессор Стэнфордского университета и всё такое прочее. В целом ничем, кроме этой книги, особо не прославилась, но “Гибкое сознание” в своё время вызвала фурор и получила очень высокие оценки. Я её прочитал (с умеренным удовольствием) и готов поделиться своими выводами.

Книга за 3 предложения

Есть две основные установки: на рост и на данность. Установка на данность является формой фатализма: “всё предрешено, мои способности предопределены и я ничего не могу изменить”. Установка на рост утверждает, что человек может развивать свои знания, навыки и даже черты характера: “если что-то не получается, то я просто чего-то не знаю, не понимаю или не умею, но могу это исправить”.

Что из прочитанного я могу применить

Самый применимый для меня кусок - это знание про установки на рост и данность. С помощью установки на рост я могу более эффективно рефлексировать то, что происходит в моей жизни. В частности, установка на рост поможет мне бороться с самокритикой и перфекционизмом. Она позволяет переключиться с самобичевания на анализ того, что я могу сделать, чтобы в следующий раз всё получилось лучше.

Вторая вещь, которую хочется применить - это изменить свои похвалы так, чтобы они учитывали существование установки на рост. Пример: принято хвалить за результаты, но при этом сам процесс достижения результатов - это тяжкий труд, который тоже заслуживает похвалы и уважения. Похвала должна быть более конкретной и не развешивать ярлыки (не “ты умный”, а “ты круто сделал Х, мне нравится этот результат, я уважаю и ценю твои усилия”).

Также важно не забывать хвалить людей, если они очень старались, но что-то пошло не так. Если в среде ценятся только результаты, то может возникнуть страх облажаться и потерять зря кучу времени и сил. Далеко не все люди умеют хорошо рефлексировать свои ошибки и извлекать из них пользу, поэтому нужно научиться поддерживать их в неудачах и помочь им делать правильные выводы.

Основные тейки

Есть два типа установок: на рост и на данность. Рост: я могу изменить своё поведение и научиться чему-то. Данность: всё предрешено, я бессилен что-либо изменить.
Эти установки могут быть избирательными. Один и тот же человек может проявлять установку на рост в одних областях жизни, а установку на данность - в других.
Само знание про установку на рост помогает её применять в жизни.
Можно помогать людям прокачивать свои установки на рост с помощью похвалы и обратной связи. Для этого нужно изменить похвалу-ярлык (“какой ты умный”) на похвалу, учитывающую рост (“ты круто сделал Х, мне нравится этот результат, я уважаю и ценю твои усилия”). Это сложно :)
Обязательно нужно поддерживать в себе и окружающих культуру приложения усилий, даже если ничего не получилось. Если ценить только результаты, то процесс потеряет свою ценность и появится страх ошибки.
Лучший инструмент для развития установки на рост - рефлексия. После того, как что-то было сделано, стоит остановиться и подумать: что я могу сделать по-другому в следующий раз? Что мне нравится или не нравится? Если не получилось, то что я могу сделать, чтобы в следующий раз получилось?
Ещё один классный вопрос себе с утра: какие сегодня есть возможности для роста и развития для меня? Для команды? Для людей вокруг?

Впечатления

Книга мне в целом понравилась. Типичный “бестселлер Амазон, продано 100500 миллионов копий” - очень много воды, очень мало страниц. Но главная мысль книги довольно ценная, и если люди после прочтения хотя бы чуть-чуть повернут свою жизнь от установок на данность в сторону роста, то это круто.

В книге довольно много примеров применения установок на рост и данность в разных сферах жизни. Конечно, они подобраны так, чтобы вызвать у читателя сильные эмоции, поэтому лучше искать свои личные примеры в разных сферах. Возможно, они будут не такими яркими, но зато более конкретными и применимыми.

С этой книгой точно стоит ознакомиться и порефлексировать, но сильно закапываться в неё не рекомендую - пустая трата времени.

Главная “дырка”, которая осталась от этой книги - а сколько вообще нужно саморазвиваться? Где находится граница “достаточно”? Эти вопросы выходят за рамки бестеллера Амазон и требуют поисков в более сложной литературе.

Если современному человеку отрубить голову, он продолжит ещё 30 секунд саморазвиваться.

Как эта книга изменила меня

После прочтения я просто начал вспышками вспоминать про существование установки на рост. Особенно ярко проявлялось в двух случаях: когда у меня включается самокритика и когда нужно кого-то похвалить. В этих ситуациях я вспоминаю, что прямо сейчас могу помочь себе или другому вырасти и что-то улучшить (и заодно нервы на самобичевании поберечь).

Топ-3 моих цитат

Общество не делится на умных и глупых, общество делится на тех, кто учится, и тех, кто не учится.

Принимая ту или иную установку, вы открываете для себя новый мир. В том, где качества неизменны, успех — доказательство вашего ума или таланта. В нем вы самоутверждаетесь. В другом мире — мире меняющихся достоинств — вы тянетесь к тому, чтобы освоить новое. Вы саморазвиваетесь.

Другой путь, который люди с установкой на данность нередко выбирают для того, чтобы повысить свою самооценку после провала, – это перекладывание вины или поиск оправданий.

Английский для чтения ≠ выучить английский

Mon, 27 May 2024 00:00:00 GMT

Начну с главной мысли: английский язык IT-специалистам нужен обязательно.

Без него можно, но будет гораздо сложнее. Смотрите: вся новая инфа в основном выходит на английском, все доки на английском, комментарии к либам на английском и так далее. Про перевод книг я буквально вчера писал (это ещё цветочки кстати, вот Вона Вернона переводчики вообще уделали как Бог черепаху).

При этом я многократно встречался с одной жирной когнитивной ошибкой: нужно учить английский обязательно с репетитором, как в школе и комплексно.

Это заблуждение становится фатальным для попыток людей выучить английский, потому что задача неподъёмная. Обычно оно ведёт к одному из двух исходов: либо человек идёт к репетитору, учится, страдает и забивает, либо забивает сразу.

Проблема в том, что само по себе “знание английского” - это комплексный навык, который состоит из нескольких навыков поменьше (каждый из которых тоже состоит из целой кучи навыков, а дальше там черепахи до самого низа). И для базовой работы в IT достаточно развить всего лишь один из этих навыков - чтение и понимание прочитанного. Под пониманием я подразумеваю “понятно, что это значит”.

Задача сразу стала проще, не так ли? Не обязательно уметь говорить, чтобы читать на английском языке. Не обязательно уметь воспринимать речь на слух и уметь грамотно писать. Это всё тоже важные и полезные навыки, но они решают абсолютно другие задачи и требуют отдельной работы над собой.

Развивать же навык чтения достаточно просто: берёшь и читаешь. Я лично свой навык развивал именно таким способом. С первых дней своей работы в IT я читал документацию и книги на английском. Поначалу корёжило страшно, было тяжело и непривычно. Но буквально через месяц-два процесс уже стал привычным, а со временем я стал читать на английском практически так же легко, как и на русском.

Пользоваться переводчиком в процессе чтения нужно, даже обязательно. Я до сих пор читаю с переводчиком, потому что знаю далеко не все слова, и это нормально. Со временем и практикой развивается навык понимания незнакомых слов из контекста, поэтому частенько даже переводчик не нужен. Однако поначалу придётся попотеть. Я даже сейчас напрягаюсь, когда беру какую-то книгу из новой для себя области, потому что там новых терминов куча.

Из плюсов могу отметить, что читать нон-фикшн на английском гораздо проще, чем на русском в силу особенностей языка. Русский язык богатый, красивый и всё такое, но на английском информация как будто более удобно структурируется для восприятия. Зачастую мне даже проще прочитать книгу в оригинале, чем качественный перевод (что встречается довольно редко).

Резюмирую:

Для развития навыка чтения нужно читать.
Не тратьте время на развитие разговорного английского, если нет понимания, зачем он нужен.
Используйте для чтения переводчик (рекомендую deepl).
Можно использовать какое-то приложение для запоминания слов, если очень хочется.

Покажи мне цифры

Wed, 22 May 2024 00:00:00 GMT

Тимлидов обычно натаскивают на работу с метриками команды. Там есть целый набор волшебных индикаторов, которые призваны сигнализировать о производительности нашего конвейера. Но я считаю, что тимлиду крайне полезно разбираться и в продуктовых метриках. Если высокоэффективный конвейер выпускает фигню, то на выходе мы получаем много фигни.

Не всё и не всегда получится полноценно обложить продуктовыми метриками. Однако у продукта всегда есть показатели, по которым можно узнать много интересного.

Когда жизнь преподнесла мне обязанности продакта на полставки, я понял, что почти ничего не знаю о пользователях системы, которую пилит наша команда. Люди говорят не совсем то, что делают, поэтому к душевным беседам я добавил метрики использования.

Они показали, каким функционалом люди пользуются, а каким почти нет. Я обсудил это с пользователями и понял, что часть системы можно сильно упростить, а некоторые функции вообще выкинуть. Их больше не нужно было развивать, поддерживать и тестировать.

С техлидской стороны я проделывал то же самое с устаревшими endpoint’ами. Сначала мы сняли метрики потребления, а потом плавно отключали endpoint’ы через предупреждения и прочие процессы.

Метрики становятся интересным аргументом в обсуждении задач. Новую фичу можно сделать попроще, а потом посмотреть, будут ли ей вообще пользоваться. Такой подход помогает не строить космические корабли вместо бумажных лодочек. Об этом я уже писал в материале «Не ленивый, а бережливый».

Продуктовые метрики и метрики использования дают тимлиду данные о реальном поведении пользователей. Без них легко создать невостребованную функцию или поверить непреднамеренному обману. С метриками решения о новых фичах, упрощении и удалении старого функционала становятся сильнее.

Не ленивый, а бережливый

Mon, 20 May 2024 00:00:00 GMT

Больше всего работу ускоряет неделание того, что можно не делать.

В бытность руководителем я ухитрялся выстраивать довольно эффективные команды даже в непростых условиях. Одним из ключевых факторов считаю агрессивное применение бережливого подхода.

К нему меня привели пара неудачных стартапов и внезапное увольнение продакта, работавшего с моей командой. Пришлось одновременно выполнять роль тимлида, продакта внутреннего продукта и ещё левой пяткой писать код.

Я пошёл к пользователям, собрал их хотелки, а потом стал выяснять, какие задачи они пытаются этими хотелками решить. После долгих разговоров многие большие запросы превращались в понятные небольшие фичи, которые команда спокойно делала за спринт.

Три месяца вместо шести

Позже ко мне пришла продакт и сказала, что огромную фичу нужно выкатить за три месяца. По предварительной оценке команда справилась бы минимум за полгода, даже если бы бросила всё остальное.

Мы начали разбирать, какую ценность должна принести фича и какая часть требований для этого действительно нужна. Созвонов было много, но в итоге из космического корабля хотелок остался голый костяк пользы для клиентов.

Срок сократился с шести месяцев до трёх не потому, что команда внезапно стала работать вдвое быстрее. Мы изменили объём и успели выпустить согласованную ценность к нужной дате.

Вопрос, который отсекает лишнее

В такой работе мне помогает простой вопрос: «Зачем?» Он действует как прожектор. Если ответ есть, становится видна цель. Если ответа нет, становится заметно непонимание задачи.

Хороший тимлид должен хотя бы немного разбираться в продукте и уточнять, зачем нужна очередная фича. Права вето у него может не быть, но точные вопросы часто меняют итоговый объём. Для проверки гипотезы иногда достаточно простой реализации вместо сложного комбайна.

С этим вопросом легко перегнуть палку. Я пару раз натурально доводил людей до бешенства, пытаясь докопаться до смысла. Но отсутствие таких разговоров обходится дороже: команда планирует и делает непонятно что, а продукт обрастает возможностями, которыми почти никто не пользуется.

Ускорение поставки помогает выкатывать больше. Если команда делает ерунду, она просто начнёт быстрее выкатывать ерунду.

Бережливость требует больше управленческой работы: разобраться в ценности, договориться о границах и выдержать давление хотелок. Зато этот способ ускорения доступен даже тогда, когда нет денег на новых людей и большую технологическую перестройку.

Техлид без софт-скиллов — это миф

Wed, 15 May 2024 00:00:00 GMT

Когда-то я считал хард-скиллы главным показателем инженера. Важно знать как можно больше технологий, паттернов и языков. Для джуна такой взгляд вполне понятен: ему действительно нужно построить технический фундамент.

Но чем дальше специалист растёт, тем реже его результат зависит только от личного умения писать код.

Есть распространённое заблуждение: «Софт-скиллы нужны менеджерам, а я пойду по технической ветке». Как человек, побывавший тимлидом, техлидом и немного продактом, я считаю это убеждение вредным.

Для техлида инженерные знания остаются фундаментом. Но применять их приходится через других людей и общие решения.

Технические решения тоже нужно продавать

Техлид видит несовершенство системы и предлагает вложить ресурсы в улучшение. Своё мнение нужно сформулировать, аргументировать, отстоять, а иногда пересмотреть после обратной связи.

Для крупного изменения недостаточно придумать хорошую архитектуру. Нужно ещё:

договориться о приоритетах;
объяснить цену бездействия;
разбить работу на выполнимые этапы;
согласовать решение со смежными командами;
помочь инженерам понять и принять новый подход.

Здесь техническая компетентность не заменяет коммуникацию, а коммуникация — техническую компетентность. Они работают вместе.

Техлид влияет на результат без возможности просто раздать всем приказы. Поэтому ему нужны письменная речь, обратная связь, менторинг, переговоры и понимание процессов команды.

Я так много пишу о софт-скиллах не потому, что перестал считать себя технарём. Наоборот: чем сложнее технические изменения, тем больше людей приходится объединять вокруг них.

GitHub как стероиды для резюме джуна

Wed, 08 May 2024 00:00:00 GMT

Одна из вещей, которой многие джуны пренебрегают, — GitHub. Крайне редко я вижу в резюме начинающего разработчика ссылку хотя бы на какой-то код. Чаще там написано: «учился там-то, прошёл такие-то курсы».

В этом нет ничего плохого. Но среди начинающих специалистов высокая конкуренция, и работающий код может подтвердить слова лучше очередного сертификата.

Как это сработало для меня

Во время поиска первой работы я сделал несколько сайд-проектов и выложил их на GitHub. Параллельно смотрел курсы, читал книги и дорабатывал проекты по новым знаниям.

На одном из собеседований я рассказывал, что люблю программирование и хочу им заниматься. Подтвердил это просто: «Вот, смотрите, я пет-проекты пилю». Позже я узнал, что это стало одним из ключевых аргументов в пользу моего найма. Я не только говорил о желании — я уже что-то делал.

Репозитории я, к сожалению, не сохранил. Помню лишь RSS-ридер и конвертер файлов на C#: карьеру я начинал с .NET.

«Мне нечего выкладывать»

Проект не обязан быть большим. Если вы изучали структуры данных и написали очередь на кольцевом буфере — добавьте README, тесты и опубликуйте код.

Можно выкладывать выполненные тестовые задания. Даже если оффер не случился, у вас останется артефакт работы и материал для разбора ошибок.

Если хватает сил, сделайте небольшой сайд-проект: возьмите знакомое приложение и попробуйте повторить часть его функций. Косо, криво, как получится. В процессе почти неизбежно всплывут вопросы, которых не было в учебных задачах.

«Мне стыдно показывать плохой код»

На работе ваш код тоже будут читать, причём внимательнее, чем случайный посетитель GitHub.

От джуна никто не ждёт архитектурного шедевра. Важно показать, что вы способны сделать небольшую понятную задачу, объяснить решение и принять обратную связь. README, осмысленная история коммитов и несколько тестов расскажут об этом лучше пустого профиля.

Код на GitHub не гарантирует работу. Он просто превращает слова «я умею и хочу программировать» в проверяемый артефакт.

JTBD для проектирования API

Mon, 06 May 2024 00:00:00 GMT

В книге «Микросервисы. От архитектуры до релиза» авторы предлагают рассматривать API как продукт и прикладывать к его разработке Jobs To Be Done.

Из всей книги эта мысль оказалась для меня самой полезной.

JTBD рассматривает продукт через работу, которую пользователь выполняет с его помощью. Если приложить этот взгляд к API, перед проектированием появляются два вопроса:

Кто будет пользоваться нашим API?
Какую работу эти люди хотят с его помощью сделать?

Потребители есть и у внутреннего API. Ими могут быть фронтендеры, мобильные разработчики, смежные команды или специалисты по IoT. Все они решают свои задачи с помощью вашего интерфейса.

Поэтому черновик API полезно показать потребителям до реализации. Достаточно ли данных для их задачи? Удобно ли будет пользоваться интерфейсом? Не потеряли ли мы важный сценарий?

Это не означает, что потребители должны сами спроектировать API. Но их обратная связь должна влиять на решение. Иначе одна сторона «всё напроектировала», а другая не может выполнить свою задачу.

Хорошему разработчику полезно немного разбираться в создании продуктов. Начать можно со своего API: сделать его удобным для разработчиков, которым с ним жить.

Достаточно хорошо

Fri, 03 May 2024 00:00:00 GMT

Ни для кого не открою Америку, если скажу, что перфекционизм - это плохо. Когда-то я считал иначе, но жизнь долго и болезненно выбивала из меня это убеждение.

В какой-то момент из-за перфекционизма я накопил столько незавершённых дел, что стало физически тяжело что-либо делать. Я одновременно хотел закончить все эти задачи, потому что они меня бесили, и сделать их идеально. Но на два стула одним Никитой не сядешь, поэтому мне пришлось научиться делать дела не идеально. И — о чудо! — в какой-то момент они внезапно закончились. Вообще. Совсем.

Ощущение было странным. Я уже настолько привык иметь кучу хвостов и ничего не успевать, что совершенно растерялся. Но растерянность продлилась недолго, потому что у меня появились свободные ресурсы — время и силы — на что-то новенькое-интересненькое.

Проанализировав этот опыт, я понял, что смог справиться с завалом только благодаря тому, что перестал пытаться сделать всё идеально. Более того, я задавал себе вопрос: «Какой минимум мне нужно сделать для получения результата?» Этот вопрос помогал поставить чёткие критерии выполнения и не делать больше, чем требуется.

Принцип done is better than perfect помог мне делать больше, а напрягаться — меньше. Я всё ещё учусь находить золотую середину между «быстро» и «качественно» и, вполне возможно, буду заниматься этим всю жизнь. Но я точно знаю, что благодаря этому подходу делаю больше интересных вещей и расту гораздо быстрее, чем раньше.

Осознать, что перфекционизм приносит только несчастья, не так уж сложно. Гораздо сложнее принять и осознать этот факт. И научиться с ним жить.

Чем заменить идеал

В моём случае основной сложностью стал поиск адекватной замены. Аристотель сказал: “Природа не терпит пустоты.” Этот принцип применим и к перфекционизму. Нельзя просто так взять и выкинуть перфекционизм из жизни - его нужно видоизменить до чего-то более здорового и удобоваримого.

Перфекционизм решает в жизни определённую задачу (а зачастую даже не одну). Поэтому просто так отказаться от него не получится. Однако можно плавно и постепенно перестраивать себя, раз за разом выбирая всё более здоровую позицию.

Загвоздка только в том, что эту здоровую позицию ещё найти надо.

Первым делом я попробовал радикальное “делать всё на троечку”. Через пару недель тревоги и неприятного перманентного охреневания я понял, что такие резкие перемены не идут мне на пользу. Бросаться из крайности в крайность вообще не очень хорошая идея, но задним числом мы все умные :)

Готовое чужое решение мне не подошло, поэтому я начал искать своё. Первым делом нужна была хоть какая-то опорная точка. Помогла мне книга Пита Уокера “Комплексное ПТСР”. Уокер очень много рассказывает про обуздание внутреннего критика, в чьей ответственности и лежит перфекционизм. А опорной точкой стала концепция “достаточно хорошо”.

Как понять, что уже достаточно хорошо

“Достаточно хорошо” призывает принять очень простую и очень сложную одновременно мысль. То, что я делаю - достаточно хорошо, хотя и не идеально. Да, всегда можно сделать лучше. Да, всегда есть какие-то недостатки. Однако их наличие не делает мою работу некачественной, а меня - некомпетентным раздолбаем. Более того, иногда исправление недостатков может быть насколько сложным и дорогим, что сознательно их оставить - это как раз проявление профессионализма.

Звучит хорошо, но на практике полезли сложности. Основная проблема возникла с определением точки, где уже достаточно хорошо. Раньше всё было проще: работа всегда не идеальна, нет проблем с оценкой. Теперь же проблема самооценки резко дала о себе знать.

Я принял решение опереться на других людей и стал просто запрашивать обратную связь к тому, что делал. Я открыто указывал на существующие недостатки и спрашивал чужого мнения. К счастью, меня окружают мощные и компетентные профессионалы, поэтому их обратная связь была конструктивной и полезной. Более того, многие из них активно подключались к устранению недостатков и делились своими идеями.

Такая открытость дала мне вторую важную опорную точку для того, чтобы концепция “достаточно хорошо” заработала - нет ничего страшного в том, чтобы говорить о каких-то недочётах в результатах работы. Более того, в хорошем окружении это даже приветствуется и люди рады будут оказать помощь и поддержку.

В итоге “достаточно хорошо” стало у меня потихоньку приживаться и проникать в прочие сферы жизни. Оказалось, что подход прекрасно масштабируется на любую деятельность, будь то спорт, внешний вид, ведение блога или публичные выступления.

Сейчас я определяю уровень “достаточно хорошо” на глаз, опираясь на свои внутренние ощущения. Делаю ли я это идеально? Нет. Но я делаю это достаточно хорошо.

Как я изобрёл таймбоксинг

Mon, 29 Apr 2024 00:00:00 GMT

Техники эффективной работы с календарём - большая, сложная, но при этом крайне полезная тема. Из всех техник продуктивности именно подключение техник управления календарём спасло меня из менеджерского ада, когда нужно было быть в трёх местах одновременно.

Долгое время у меня не получалось наладить планирование. Ситуация изменилась, когда я стал относиться ко времени как к ещё одному объекту проектирования.

У дня есть ограниченные ресурсы, зависимости между задачами и свои граничные случаи вроде внезапной срочной работы. Такой язык оказался мне привычнее тайм-менеджмента. Я начал заранее думать о нескольких вариантах развития дня и учитывать не только часы в календаре, но и доступное внимание.

Ранее я уже писал про выделение в календаре focus time. Эта техника работала у меня в целом успешно, но стала появляться неожиданная проблема: я не всегда знал, что и в каком порядке делать в этот период времени. Какие-то задачи казались слишком мелкими, а на другие времени могло не хватить. Ещё одним недостатком была необходимость потратить часть focus time на то, чтобы решить, что я вообще буду делать. Система работала, но её хотелось докрутить.

И тут я подумал: а что, если блокировать себе не целый блок focus time, а конкретные задачи? Типа 30 минут делаю задачу Х, потом 30 минут задачу Y, потом 15 минут разгребаю мелочёвку. Подумал - и сразу начал делать. Я тогда ещё в первый раз прочитал “Джедайские техники” и уже понимал, что нужно облегчить жизнь своей обезьянке.

Focus time у меня уже работали, в календаре были выделены блоки на каждый день недели. У меня появился новый ритуал: с утра я садился и 15 минут планировал свой день. Я смотрел на свои задачи, планы и записывал прямо в календарь, где и чем я буду заниматься.

Конечно же, не обошлось без шероховатостей.

Что не сработало с первого раза

Первое, с чем я столкнулся - не успел выполнить задачу в установленный промежуток времени. Решений я знаю два: просто перейти к следующей задаче и доделать потом либо сместить следующие задачи, что-то убрать и доделать сейчас. Решать нужно в моменте и каждый раз решение может быть разным. Здесь мне очень помогла концепция рационального фланёра - я просто корректировал свои планы в зависимости от текущей ситуации.

Второе - резкие как удар серпом непредвиденные обстоятельства. Решение в сущности такое же, как и в предыдущем пункте: проанализировать и понять, стоит ли что-то делать прямо сейчас, и если да - то вместо чего. Снова концепция рационального фланёра :)

Третье - моё любимое. Я не закладывал время на отдых. В итоге после недели успешной и продуктивной работы по новой методике я все выходные успешно и продуктивно смотрел в стену. Осознав свою ошибку, я стал закладывать себе слоты на отдохнуть. Тут как раз мне помогла техника Pomodoro как напоминалка (писал об этом пост).

И четвёртое - это вознаграждение себя за работу дополнительной работой. Когда я быстро заканчивал какой-то блок, то вместо отдыха брал ещё задачи. Закономерным итогом было состояние выжатого лимона вечером и нежелание что-либо делать на следующий день. Вышел я из ситуации так: если сделал что-то быстрее запланированного, то задавал себе вопрос “почему я так быстро справился?” (немного рефлексии) и шёл отдыхать.

Итог - эта техника у меня прекрасно заработала. Я до сих пор именно так планирую каждый свой день (иногда даже выходные, когда очень много всего хочется сделать). Поскольку я уже давно и успешно веду список задач с проектами, то календарь просто становится картой задач во времени. Плюс такой подход помогает мне не набрать лишних задач (раньше я грешил этим в дни с большим количеством созвоном).

Также сильно уменьшилась прокрастинация, потому что я заранее знаю, что буду делать. Всего раз в день мне нужно сесть и подумать, как распределить свободное время на работу и отдых (и свои дела).

Только недавно, читая статьи по продуктивности, я узнал название этой техники - мягкий таймбоксинг. Прикольно осознавать, что я сам дошёл до чего-то такого интересного и сложного. Не прикольно осознавать, что мог бы прочитать раньше и не костылить велосипед.

Планировать из состояния

Вечером нельзя точно знать, как пройдёт ночь и в каком состоянии я проснусь. Поэтому неделю я планирую заранее, а конкретный день - утром.

Перед таймбоксингом я спрашиваю себя: «Как я вообще себя чувствую?» Если ответ «паршивенько», я убираю сложные когнитивные задачи и пишу программу-минимум. Всё сверх неё считаю приятным бонусом.

Таймбоксинг не должен превращать невыспавшегося человека в тревожный пирожочек, который лежит на диване и выедает себе мозг за невыполненный план. Календарь должен учитывать реальные силы, а не стыдить за их отсутствие.

25 часов в сутках

Fri, 26 Apr 2024 00:00:00 GMT

Регулярно слышу отзывы о людях следующего формата:

“Боже, как он всё успевает! Столько всего делает! У него как будто 25 часов в сутках!”

И сегодня у меня настроение проехаться катком по этому крайне опасному восприятию других людей.

Давайте начнём с того, что законы физики (пока что) для всех одинаковы. На всех нас одинаково действуют законы Ньютона, сила гравитации, электромагнитные волны и тому подобные штуки. Время (пока что) не является исключением, скорость света нам ещё не удалось превысить. Следовательно, ни у кого в сутках не может быть больше времени, чем у кого-то другого.

Тогда почему другой человек может казаться более продуктивным? Мне на ум приходит несколько вариантов:

Он более эффективно распоряжается своим временем.
Он громче заявляет о том, что делает - его результаты просто более наглядны.
Наблюдатель переоценивает этого человека и недооценивает себя.
Он жертвует другими частями своей жизни в пользу тех результатов, которые видит наблюдатель.

Ситуация резко перестала быть однозначной. У наблюдателя вполне может появиться закономерный вопрос - а что же происходит на самом деле?

Ответить на этот вопрос достаточно сложно. Как минимум по той причине, что для полного ответа нужно собрать такую информацию, к которой у наблюдателя может не быть доступа (и не надо). К тому же, ответ зачастую будет неоднозначным. На позицию наблюдателя могут влиять все 4 фактора, которые я перечислил и ещё штук 100 индивидуальных, которые я не знаю и знать не могу.

Но об одном из этих факторов хочется поговорить подробнее. А именно - о последнем.

В современном культе продуктивности, достигаторства и бесконечного роста многие “успешные” люди излишне увлекаются погоней за Святым Граалем успеха и ради этого приносят жертвы. Поскольку наш мозг очень любит простые и понятные решения, то первыми под нож попадают очевидные части жизни.

Например, здоровье. О, сколько же я знаю “успешных” ребят, которым жизнь не мила из-за того, что всё болит. А начинается всё просто - да ладно, поем в Макдаке. Да ладно 6 часов сна, попью кофе. Ну и что, что нет времени на зал. Стресс? Ерунда! Что нас не убивает, то делает нас сильнее.

Как итог - люди, которые разваливаются на ходу в 30 лет. А происходящее с теми, кто приближается к 40, вполне можно описывать в романах Стивена Кинга.

С такими же мыслями под нож идут друзья, семья, отношения, досуг, отдых. Перечислять можно очень долго. Но суть понятна.

Чужие результаты - это как социальные сети. Мы видим только то, что нам хотят показать. А что на самом деле скрывается “под капотом” - мы не знаем, да и вряд ли захотим узнать. Картина может оказаться неприглядной.

Мы не знаем (и никогда не узнаем), за счёт чего другие люди на самом деле достигают результатов. Может быть, это действительно невероятная эффективность или природный талант. А может, это систематическое пренебрежение всем остальным в жизни.

Нужно себя беречь. Работы вокруг много, а жизнь всего одна. Да и здоровье дешевле поддерживать, чем восстанавливать.

Думайте о себе и поменьше оглядывайтесь на других.

Как планировать в неопределённости

Fri, 19 Apr 2024 00:00:00 GMT

Я слабо верю в точные планы на далёкое будущее. Но отказаться от планирования тоже нельзя: команде нужен ориентир, а бизнесу — основа для решений. Приходится жить между двумя крайностями: бездумным оптимизмом и параличом анализа.

Магические коэффициенты

Однажды в рекламном посте я увидел совет: если что-то распланировал, сразу умножь срок в два-четыре раза. Обычно рекламу я не комментирую, но здесь не сдержался. В нескольких строках ответа не уместилось, почему такой подход вреден.

Ситуацию хорошо описывал Максим Дорофеев в «Джедайских техниках». Представьте программиста Васю. Тимлид спрашивает, сколько займёт фича. Вася отвечает: неделю. Тимлид на всякий случай обещает руководителю две. Руководитель превращает две недели в четыре.

Чем больше организация, тем длиннее эта цепочка. В какой-то момент наверху получают оценку в пару лет и начинают делить её обратно. До Васи в итоге доходит: «Неделя долго, надо было вчера». Сам процесс при этом растягивается из-за согласований, встреч и передачи информации между уровнями.

Желание использовать коэффициент понятно. Он избавляет от необходимости разбираться со сложными вопросами будущего, вероятностей и потенциальных проблем. Несколько раз умножили, случайно попали в срок — и готова привычка.

Сама мысль заложить резерв на неучтённое вполне здравая. Проблема начинается, когда коэффициент применяется автоматически. Он маскирует вопрос «Что именно может пойти не так?» и скрывает неопределённость вместо того, чтобы помочь с ней работать.

Если убрать коэффициент, этот вопрос сразу вылезает наружу. А пойти не так может что угодно. Приходится сегодня смотреть в завтрашний день, и это сложно.

Все риски всё равно не предусмотреть

Первая альтернатива магическому умножению выглядит разумно: сесть и расписать всё, что может повлиять на срок. Но здесь нас ждёт другая крайность.

Во-первых, предусмотреть всё невозможно. После хорошего анализа легко почувствовать удовлетворение и безопасность: всё предусмотрено, закрыто и перекрыто. Вот только реальность об этом не знает. Если мы не видим какой-то риск, это ещё не значит, что его нет.

Во-вторых, если заложить в план все найденные риски, оценка может стать ещё больше магического коэффициента. Так работать тоже не получится. Приходится выбирать: какие риски снижать заранее, какие принимать, а за какими наблюдать.

Получается, точную оценку не даёт и этот подход. Никто не знает, какие из предусмотренных и не предусмотренных рисков реализуются. Срок может варьироваться от примерного минимума до бесконечности.

Я много раз встречал людей, которые хотят продумать каждую деталь: что, куда, как, в каком порядке и что может пойти не так. Такие люди находят неожиданные ветки развития событий. Обратная сторона — огромные затраты времени на анализ того, что никогда не случится.

Совсем забивать на анализ рисков ещё хуже: рано или поздно один коварный риск сделает всем больно. Но на некоторые риски можно и нужно забивать. Мелочи с ограниченными последствиями не всегда стоят внимания. Даже крупный риск иногда можно не прорабатывать сразу, если его реализация не приведёт к серьёзным моментальным последствиям.

Попытка разобрать вообще всё приводит к параличу анализа, и реальная работа встаёт. Иногда нужно признать неопределённость и вернуться к риску, когда в этом появится необходимость.

Рациональный фланёр

Что делать, если бездумный коэффициент не работает, а просчитать всё невозможно? Универсального решения у меня нет. Есть набор техник, которые помогают улучшить результат, но не предсказывают будущее.

Основой для них стала концепция рационального фланёра из «Антихрупкости» Нассима Талеба. Фланёр идёт на прогулку с планом, но не становится его рабом. Он пересматривает маршрут по мере появления новой информации.

Именно «высечение в камне» планов становится источником многих неприятностей. Если регулярно проверять их на адекватность, жить становится проще.

Допустим, я составил план на день и начал ему следовать. Потом упал прод. Время, силы и внимание ушли на инцидент. Значит, нужно убрать из плана что-то другое.

На словах вывод очевидный. На практике мы часто пытаемся выполнить и старый план, и внезапно появившуюся работу. Ближе к вечеру остаётся только смотреть в стену от усталости. Рациональный фланёр в такой ситуации пересобирает маршрут: чтобы впихнуть невпихуемое, надо выпихнуть ранее впихнутое.

Сначала отказываться от запланированного непривычно и больно. Со временем польза перевешивает неудобства. Эта логика работала у меня на уровне дня, недели, спринта команды и технического плана отдела на полгода. Масштаб меняет нюансы, но не принцип.

Что работает у меня

Детализировать только ближайший участок. Чем дальше горизонт, тем меньше подробностей. Я называю это размытием планов: не нужно пытаться расписать по часам проект на полгода.
Иметь чёткий план на ближайший период. Для личного планирования это день и неделя, для Scrum-команды — обычно спринт. Это уровень, на котором можно принимать обязательства.
Ставить однозначные ближайшие подзадачи. Далёкое направление может оставаться общим, но следующий шаг должен быть понятен.
Регулярно пересматривать план. Проект может стать неактуальным, а может внезапно стать срочным. В обоих случаях старый маршрут уже не подходит.
Закладывать резерв под конкретную неопределённость. Он нужен не «потому что всегда умножаем на два», а потому что мы видим определённые риски и понимаем возможные последствия.
Указывать уверенность рядом со сроком. Формулировка «проект займёт Y с вероятностью Z» не идеальна, но открывает разговор о неопределённости.
Учиться на отклонениях. Когда я ставил процессы планирования в Scrum-командах, своими глазами видел, как со временем снижалось расхождение между планом спринта и результатом. Команда училась лучше рассчитывать силы и предсказуемее поставлять результат.

План нужен не для предсказания будущего. Он нужен, чтобы выбрать следующий шаг, заметить изменение условий и вовремя пересобрать маршрут.

Зачем я занялся слепой печатью

Wed, 10 Apr 2024 00:00:00 GMT

На первый взгляд может показаться, что я занялся слепой печатью, чтобы стать эффективнее и рациональнее расходовать время. С чистой совестью и всей ответственностью заявляю: это полная фигня. Моя мотивация была другой.

Меня просто бесило печатать длинные тексты, и я решил сделать этот процесс более быстрым и прикольным.

Необходимости писать стало довольно много: RFC и длинные отчёты по собеседованиям на работе, посты для канала, свои заметки и рефлексия. И очень, очень часто я всё это прокрастинировал.

Ещё меня бесило отставание текста от мысли. Я частенько ловил себя на том, что мысли убежали далеко от предложения, которое я сейчас пишу. Приходилось возвращаться, вспоминать контекст и заново всё обдумывать. В итоге я мог ощутимо устать даже от простого текста.

Мне нравятся результаты процессов, требующих печати. Но сам процесс печатания бесил и утомлял невероятно. Поэтому я выдвинул гипотезу: если освою слепую печать, то мне будет приятнее делать эти интересные задачи.

Так и вышло. Хоть «Соло на клавиатуре» оказался далеко не идеальным тренажёром, освоение нового навыка затянуло меня с головой. Я начал применять его сразу, хотя первые полторы недели это только замедляло печать. Гипотеза сработала: писать тексты стало значительно веселее.

Я считаю, что вложение сил в десятипальцевую печать окупилось. Уже сейчас я делаю больше заметок просто потому, что мне не лень их писать. А заметки — ценный инструмент рефлексии, который ощутимо меня прокачивает.

Побочные эффекты

Спустя некоторое время я заметил, что слепая печать изменила больше, чем скорость набора. Фокус сместился с клавиш на содержание: я стал глубже обдумывать текст и чаще сохранять промежуточные мысли в заметках.

Ещё я вернулся к дневнику. Теперь вечерняя рефлексия занимает около пятнадцати минут и приносит удовольствие вместо прежнего раздражения от медленной печати.

Этот опыт напомнил мне важную вещь: если полезный процесс бесит, иногда стоит улучшать сам процесс, а не заставлять себя терпеть. Уменьшение одного источника трения может запустить несколько неожиданных улучшений.

На какой раскладке я учился

На стандартной Mac. Я решил, что не хочу заморачиваться переключениями, конфигами и прочими радостями жизни. Попробовал Мефодицу Бирмана — не зашло, хотя сама идея крутая. В конце концов, я не профессиональная машинистка и цели печатать 100 тысяч знаков в секунду у меня не было.

Какой тренажёр лучше «Соло»

Без понятия, честно. В целом все бесплатные тренажёры, которые я попробовал, оказались адекватными. У Хекслета есть подборка тренажёров, я их все посмотрел. Для закрепления навыка я просто печатал по 15 минут в день на klava.org в режиме тренировки.

Аббревиатурное безумие

Fri, 05 Apr 2024 00:00:00 GMT

Перечитывая “Джедайские техники”, я наткнулся на великолепнейшее, крайне содержательное отношение ув. Максима Дорофеева к аббревиатурам - полное презрение.

STAR, RACI, ACID, SOLID, DRY, KISS, YAGNI - кто больше? Тысячи их.

В самих аббревиатурах нет ничего плохого. Плохо то, что когда у тебя в руках молоток - всё вокруг начинает казаться гвоздями. Так же и с аббревиатурами, выполняющими роль молотка в не слишком умелых руках не слишком вдумчивого человека.

Узнал человек какую-то аббревиатуру - и давай везде и всюду её применять. Прям становится амбассадором этих буковок. Максим Дорофеев очень чётко охарактеризовал это как “Жизненный опыт, Передаваемый Аббревиатурами”.

Основная проблема с аббревиатурами (на мой вкус) - они как бы отключают необходимость думать. “Смотри, я - готовое решение, тебе больше не нужно напрягать мозги и думать, за тебя уже всё подумали”. Но не думать - это как раз самый страшный грех (по версии Максима Дорофеева, я с ним полностью согласен).

Вторая проблема - аббревиатуры частенько смазаны некоторым слоем маркетинга, чтобы быть покрасивее и попривлекательнее для потенциального потребителя. И ладно бы вопросы были только к привлекательности (последняя S в KISS явно для красоты добавлена). Но иногда вопросы в большом количестве возникают и к самому наполнению аббревиатуры.

Например, всеми любимая модель RACI описывает сферических коней в вакууме. В реальном проекте роли переплетаются так, что концов не сыщешь.

Или моё любимое - свойства ACID. Буква C добавлена для красоты (об этом я писал и в обзоре «Высоконагруженных приложений»). Просто “кислота” (acid) звучит явно круче, чем “помогать” (aid). И пофиг, что БД может обеспечить консистентность только на уровне ограничений - так же красивее звучит.

Аббревиатуры не бесполезны. В них довольно часто заложена какая-то идея (временами даже очень полезная). Однако помните про несовершенство обобщений и будьте аккуратны с молотками.

Четыре книги, которые помогли мне взять дела под контроль

Mon, 01 Apr 2024 00:00:00 GMT

На выходных взялся в очередной раз перечитывать «Джедайские техники» Максима Дорофеева. В прошлый раз эта книга буквально за волосы вытащила меня из тимлидского ада, в котором поток информации оставлял меня каждый вечер выжатым, как лимон.

Сейчас почувствовал, что пришла пора повторить итерацию. Интересных задач и проектов становится всё больше, поэтому навык эффективного расхода энергии снова актуален.

Мыслями после прочтения я поделюсь позже (или по ходу дела), а пока приведу четыре книги, которые в своё время сильно помогли мне взять дела под контроль.

Максим Дорофеев, “Джедайские техники”

Именно после этой книги у меня произошли первые серьёзные положительные изменения в работе. В ней содержатся как принципы работы нашего мозга, так и конкретные практики повышения эффективности.

Бонус-поинт: “Путь джедая” того же автора.

Джейк Кнапп, Джон Зерацки “Найди время”

Прекрасно мне зашла после Джедайских техник. Книга от ребят, много и плодотворно поработавших в бигтехах. Содержит просто кучу практик повышения продуктивности. Можно подхватить для себя ряд полезных идей.

Грег МакКеон «Эссенциализм»

На русский название перевести сложно, поэтому оставили как есть. Ключевой термин книги - “essential”, “существенный”. Книга учит, как выделять среди дел важное и не заниматься всякой ерундой. Основной контент - это объяснение подхода эссенциализма и примеры его применения в жизни автора.

Брайан Моран, Майкл Леннингтон «12 недель в году»

Эта книга помогла мне переосмыслить процесс планирования и отказаться от далеко идущих планов. Авторы предлагают планировать на 3 месяца по неделям и утверждают, что это гораздо продуктивнее общепринятых подходов. Мне подход на практике понравился, но пока что прижился не до конца - многовато беру на себя.

Отдельно от этой подборки я люблю «Одураченных случайностью» Нассима Талеба. Она помогла мне пересмотреть отношение к далеко идущим планам, но это уже не книга о личной продуктивности.

Порядок чтения книг у меня был примерно таким же, как и в списке. Но начинать рекомендую с Джедайских техник, уж больно они хороши.

Описание и комментарии к код-ревью

Fri, 29 Mar 2024 00:00:00 GMT

Есть один очень простой, но удивительно эффективный способ ускорить код-ревью в команде и сделать этот процесс приятнее.

Выложив Pull Request, напишите к нему описание и оставьте комментарии.

Вспомните свои ощущения, когда нужно поделать ревью. Лично я зачастую испытываю лень. Нужно открыть код, разобраться, какую задачу и каким способом он решает, составить собственное мнение, оставить комментарии… Можно устать, просто прочитав это предложение.

Позаботьтесь о своих коллегах. Сделайте короткое описание к PR, расскажите в двух словах о решаемой задаче и способе её решения.

Не нужно растекаться мыслью по древу. Достаточно буквально 3–5 предложений. Читать огромную портянку текста тоже никто не захочет. Описание должно объяснять контекст и риск, а не пересказывать diff.

Сделав это, оставьте комментарии к самому коду:

на что ревьюерам стоит обратить внимание;
где вы сомневаетесь в своём решении;
зачем понадобились доработки общего кода.

Эти комментарии облегчат жизнь человеку, который будет смотреть ваш код. Помогите ему выделить главное и заострить внимание именно на этом.

Вспомните любую хорошую нон-фикшн книгу. У неё всегда есть оглавление, краткое описание и введение. Ключевые мысли выделяются типографическими средствами: шрифтом, цитатами или ещё как-то. Всё это делается для того, чтобы читателю было легко понять назначение и структуру книги, а также выделить главное.

Вы точно так же можете выполнить роль автора для ревьюеров. Сделайте людям приятно и помогите им понять, что же вы там такого написали в своём Pull Request.

Как изучить алгоритмы почти бесплатно

Fri, 22 Mar 2024 00:00:00 GMT

Какое-то время назад я писал о своём опыте прохождения курса по алгоритмам от Яндекс Практикума. Это очень хороший способ изучить алгоритмы, но есть два нюанса:

Он ОЧЕНЬ плотный по нагрузке.
Он недешёвый.

Любого из пунктов достаточно, чтобы курс вам не подошёл.

Так что же делать, если курс никак, а в алгоритмы всё-таки хочется?

Есть альтернативный путь, который ничуть не хуже (а в чём-то даже и лучше) прохождения нагруженного курса. Этот путь вполне успешно прошло несколько моих знакомых, и они получили вполне достойные результаты. Он предполагает, что вы уже умеете писать код хотя бы на одном языке.

Что понадобится

Три обязательных инструмента и один опциональный:

Книга «Грокаем алгоритмы».
LeetCode.
Google и YouTube.
Опционально — ментор, который хорошо шарит в алгоритмах.

Суть достаточно проста. Вы читаете книжку и решаете тематические подборки задач на LeetCode. Когда чувствуете достаточно уверенности — двигаетесь к следующей теме. В процессе гуглите то, что не знаете или не понимаете, и тем самым глубже разбираетесь в теме. Если прям буксуете — идёте к ментору за консультацией.

Если цель — именно алгоритмические собеседования, в качестве программы можно использовать бесплатный курс Яндекса. Он хорошо структурирован и содержит необходимую базу, а тонкости при желании можно догуглить. Курс не заменит полноценное фундаментальное обучение, но поможет определить нужные для собеседований темы. Я рекомендую сразу объединять его с LeetCode и решать по несколько задач из каждого раздела.

Главная сложность метода — самостоятельная работа. От вас потребуется усидчивость и настойчивость. Справедливости ради, в курсе Яндекса тоже 90% самостоятельной работы. Вам придётся планировать своё обучение и выделить на эту деятельность несколько месяцев: алгоритмы не получится освоить за пару недель.

Ещё имейте в виду, что в «Грокаем алгоритмы» практически не раскрыта тема деревьев. А она довольно большая и важная, не пропускайте её.

Практические рекомендации

Двигайтесь по чуть-чуть каждый день. Так знания лучше и прочнее усваиваются.
Решайте минимум 10–15 задач на каждую тему. Начинайте с уровня Easy, а когда разберётесь с базой, переходите к Medium. Hard оставьте для тем и форматов собеседований, где он действительно нужен.
Постоянно пользуйтесь Google, чтобы разобраться в теме. Не гуглите готовые решения!
Не стесняйтесь обращаться за помощью. Помимо менторов существуют специальные чаты и комьюнити, где вам помогут и подскажут.

Удачи, и да пребудет с вами О(n)!

Сайд-проекты на работе

Wed, 20 Mar 2024 00:00:00 GMT

Я считаю, что лучший способ прокачать свои навыки - сделать сайд-проект. Книги и курсы дают теорию, но без практики она делает человека скорее эрудированным, чем умелым.

При этом сайд-проект не обязан быть домашним пет-проектом. Его можно найти на работе и не тратить вечера на ещё одну смену.

Зачем вообще нужен сайд-проект

Свой первый сайд-проект я сделал ещё до первой официальной работы. Это был RSS-ридер на C# и WPF.

Когда я был джуном, мы с более опытным коллегой загорелись идеей сделать стартап. По выходным собирались у него и херачили. Стартап не пошёл, зато за полтора года работы над ним я ощутимо прокачался в разработке.

Сайд-проекты полезны на любом уровне. Меняются только сложность и целевой навык. И даже сейчас я продолжаю их делать. Один из них вы читаете прямо сейчас.

Где искать проект

Первый вариант - поговорить с руководителем. Часто у него есть проекты, до которых никак не доходят руки. За помощь в их реализации можно договориться о времени внутри рабочего дня. Получается честный обмен: компания получает результат, а сотрудник - опыт.

Если у руководителя нет идей, можно поискать их самостоятельно. Посмотрите, что в команде замедляет работу, бесит людей или ухудшает продукт. Идеальных команд и продуктов не бывает, так что боль найдётся.

Когда постоянно горят сроки и сил хватает только на текучку, может быть не до сайд-проектов. Но само исправление этой ситуации может стать таким проектом.

Как не превратить проект в бесконечную стройку

Ответьте на вопрос «нахрена?» Какую цель вы преследуете, какой навык развиваете и в какой момент проект можно считать завершённым?
Приблизьте его к реальной жизни. Вместо сферического коня в вакууме найдите домен и сценарий применения. Так опыт лучше закрепится.
Не переусложняйте. Проект должен быть точечным. Чтобы посмотреть, как работает шардированный PostgreSQL под нагрузкой, не нужно заодно писать систему аутентификации.
Зафиксируйте результат. Обдумайте полученный опыт и запишите, что узнали. Можно написать статью или сделать небольшой доклад. Так разовый проект превратится в переносимый опыт.

Сайд-проект работает, когда у него есть ясная цель, граница и способ превратить сделанное в опыт. Если этого нет, он легко становится ещё одним вечным долгостроем.

Зачем на самом деле нужны паттерны проектирования

Mon, 11 Mar 2024 00:00:00 GMT

Недавно где-то на просторах Telegram наткнулся на очередной цикл статей про избитые уже паттерны проектирования GoF. Писать о них я, конечно, не буду — за меня это уже многократно сделали другие люди и сделали прекрасно.

Однако при чтении этих постов я вспомнил, как будучи ещё зелёным джуном читал книжку по паттернам и пытался их влепить куда попало. Это абсолютно нормальная стадия развития программиста уровня junior/middle.

Основная проблема здесь заключается в том, что мышление специалиста на этом уровне ещё линейное. Паттерны кажутся серебряной пулей - вот же они, готовые решения стандартных задач.

Ранее я писал, что основная польза знания алгоритмов для разработчика заключается в развитии алгоритмического мышления. С паттернами проектирования ситуация ровно такая же. Они нужны не только и не столько для решения стандартных задач, хотя и для них тоже, сколько для развития нужного формата мышления.

Изучение паттернов проектирования учит видеть закономерности в системе. У специалиста формируется навык построения более точных и интересных причинно-следственных связей, а также развивается аналитический аппарат. Грубо говоря, человек учится мыслить шире и в новых критериях (удобства сопровождения, расширяемости и т.д.).

Нет смысла вызубривать паттерны наизусть, равно как заучивать алгоритмы сортировки. Гораздо важнее поразмыслить, какую именно задачу решает этот паттерн, откуда она возникла и зачем вообще её нужно решать. Такой подход к изучению шаблонов проектирования даст гораздо больше, нежели бездумное заучивание или запихивание их в каждый кусок проекта.

Что почитать по паттернам

Если хочется изучить тему последовательно, я бы двигался так:

Refactoring.Guru — понятное введение в классические паттерны с иллюстрациями и примерами кода.
«Head First. Паттерны проектирования» Эрика Фримена и соавторов — лёгкая книга, которая даёт контекст и хорошо подходит для первого знакомства.
«Паттерны объектно-ориентированного проектирования» Эриха Гаммы, Ричарда Хелма, Ральфа Джонсона и Джона Влиссидеса — классика, которую лучше читать не первой и с дополнительным источником под рукой.
«Шаблоны корпоративных приложений» Мартина Фаулера — следующий уровень: паттерны для устройства больших приложений, многие из которых разработчики уже используют, даже не называя по имени.

До этого списка стоит освежить основы ООП и SOLID. Не ради экзамена по определениям, а чтобы понимать, из каких проблем выросли предлагаемые решения.

Focus time: как найти время на работу между созвонами

Wed, 31 Jan 2024 00:00:00 GMT

В самые загруженные периоды своей работы я сталкивался с тем, что каждый день напоминал череду бесконечных созвонов, а мессенджер просто разрывался от оповещений.

Проблема была даже не в самом количестве или качестве (хотя там тоже было что улучшить). Страдал я в основном от того, что из-за созвонов не успевал делать другую работу. Мне просто не хватало времени.

Спасла меня в итоге одна простая техника - блокировать в календаре фокус-таймы. Это просто отрезки времени по 1-2 часа, в которые я отключаю мессенджер и не принимаю звонки. По сути, я просто выделил себе каждый день отрезок (иногда даже не один) времени, в которые я могу спокойно, сосредоточенно поработать.

Чтобы всем вокруг было проще, я настроил синхронизацию гугл календаря со слаком (использовали их в работе). В итоге у меня в статусе всегда выводилось “Focus time” и время, до которого меня не будет на связи. Ну и конечно я объяснил коллегам, что это такое и зачем я это делаю. А также что в случае адской срочности можно просто позвонить мне на телефон.

Фокус таймы я блокировал с утра в понедельник, в процессе планирования недели. Иногда даже раньше, пока всё созвонами не успели забить. Но для каких-то очень важных вещей я вполне мог отказаться от focus time и пойти на созвон. Правда, для этого инициатору нужно было убедить меня так поступить - что само по себе улучшало качество коммуникаций.

Что я в итоге получил от этого:

Мои задачи начали двигаться, потому что у меня каждый день было время над ними поработать.
Созвонов стало чуть меньше. Внезапно оказалось, что многие штуки вообще в тексте можно решить без проблем.
Поскольку задачи делались, я стал меньше переживать из-за них. Тоже полезно.

Апогеем этого эксперимента стало его распространение внутри компании. В один прекрасный день я заметил кучу статусов ”focus time” в слаке. Коллеги посмотрели на меня, попробовали - и им понравился как процесс, так и его результаты.

Не доживайте до пятницы

Mon, 29 Jan 2024 00:00:00 GMT

Грамотное распределение сил и энергии — очень важный навык, который можно и нужно тренировать.

Я много лет своей жизни отдал боевым искусствам. И даже сейчас продолжаю с удовольствием заниматься боксом.

Одна из распространённых проблем у начинающих бойцов звучит как “я сдыхаю к концу раунда/боя”. Обычно они ищут ответ в своей физподготовке или тайной технике дыхания. Но на практике всё частенько оказывается намного проще. Эти ребята просто не умеют распределять свои силы.

Я по себе прекрасно знаю это ощущение. Когда выходишь в первом раунде бодрый и свежий, то хочется сразу начать делать какие-то активные действия. Силы есть, дыхание на максимуме, состояние просто супер.

Проблема в том, что если поддаться этому желанию - то силы могут внезапно закончиться. Сколько раз я видел на соревнованиях, как человек выжигает всего себя в первом раунде и просто сливает бой, потому что противник переждал эту вспышку энергии.

Опытные ребята всегда помнят, сколько ещё им осталось работать, и рассчитывают свои силы. Так они не просаживаются по выносливости до критического уровня, где даже руки уже не поднимаются.

Похожая ситуация встречается и в профессиональной деятельности. В понедельник люди выходят на работу отдохнувшими, а к пятнице превращаются в усталых зомби, которые мечтают о выходных.

В рабочей деятельности точно так же нужно уметь распределять энергию, как и в спорте. Вышел с выходных бодрячком - не надо себя выжигать в первый же день. Подумай о том, что впереди ещё вся рабочая неделя. И желательно не “дожить до пятницы”, а провести каждый рабочий день осознанно и с пользой. А это возможно только при наличии сил и энергии для работы.

Вывод прост: не надо ушатываться в понедельник и «доживать» до пятницы. Учитесь контролировать и грамотно распределять свои силы по рабочей неделе.

Стратегия управления техническим долгом

Mon, 22 Jan 2024 00:00:00 GMT

Доклад о том, как сделать технический долг видимым, связать его с последствиями для команды и бизнеса и превратить разрозненные TODO в управляемый бэклог.

О чём выступление

Что считать техническим долгом и откуда он берётся.
Как накопленный долг влияет на показатели команды, бизнес и мотивацию людей.
Как превратить замечания и TODO в коде в понятный список работ.
Как приоритизировать технический долг и работать с ним системно.
Как обсуждать инвестиции в техническое состояние продукта с бизнесом.

Главная мысль: технический долг конкурирует за ресурсы с продуктовой разработкой, поэтому недостаточно назвать решение плохим. Нужно показать цену бездействия, выбрать приоритет и договориться о работе на языке последствий для продукта и команды.

Зачем проводить собеседования

Fri, 19 Jan 2024 00:00:00 GMT

Проведение собеседований может быть неприятной и раздражающей обязанностью. А может быть и дополнительным источником знаний и профессионального роста. Всё зависит от подхода.

Миддл-разработчикам я часто рекомендую для саморазвития начать проводить собеседования. И часто в ответ получаю недоумение и непонимание - а зачем это нужно? Как вообще можно прокачиваться через собеседования?

Что дают собеседования

Во-первых, это практика софт скиллов. Нужно внимательно слушать человека, задавать уточняющие вопросы, пытаться разобраться и определить его уровень. Всё это изрядно прокачивает навыки общения. Особенно полезно для тех ребят, кто увлечённо пишет код целыми днями и немного забывает, как разговаривать с людьми 🙂 Спойлер - с ростом профессионального уровня общаться с людьми приходится всё больше, так что подкачка лишней не будет.

Во-вторых, собеседования могут подарить новые профессиональные знания. На собеседованиях зачастую спрашивают о вещах, которые в реальной работе нужны довольно редко (тема для отдельного разговора). Задавая из раза в раз одни и те же вопросы, вы довольно быстро и надёжно запомните ответы на них. Здесь убиваются сразу два зайца - выше скилл за счёт глубины знаний + потом легче будет собеседования проходить. А если вам попадётся крутой кандидат, то можете ещё и много нового от него узнать.

В-третьих, проведение собеседований позволяет вам посмотреть на процесс глазами нанимающего. Посмотрев на несколько десятков очень разных кандидатов, вы усвоите пачку нежелательных паттернов поведения и поймёте, как структурировать процесс собеседования. Маленький и забавный побочный эффект - проходя собеседование, можете по привычке начать его вести 🤣

Напоследок дам маленькую рекомендацию. Старайтесь сделать собеседования интересными для себя. Меняйте задачи, подходы, вопросы, темы, секции, если есть возможность. Задавать одни и те же вопросы 10–20 раз подряд надоест любому человеку. Ищите возможность разнообразить и обогатить свой опыт, тогда собеседования будут полезны.

«Реализация методов предметно-ориентированного проектирования», Вон Вернон

Tue, 09 Jan 2024 00:00:00 GMT

Сегодня - небольшой обзор на книгу Вона Вернона “Реализация методов предметно-ориентированного проектирования” (в оригинале - Implementing Domain-Driven Design by Vaughn Vernon).

DDD - тема сейчас очень актуальная. Предметно-ориентированное проектирование активно используется при разработке микросервисов, поэтому книга всё ещё хороша и полезна, несмотря на свой почтенный (по меркам сферы IT) возраст.

Содержание книги полностью соответствует названию. Вернон делает акцент на практическом применении всех понятий DDD - от предметных областей до интеграции ограниченных контекстов между собой. Вернон не углубляется в философию DDD, а концентрируется на практических аспектах. Поэтому в книге довольно много примеров кода (на Java).

Пожалуй, примеры кода понравились мне больше всего. Вернон не просто оперирует некими абстрактными понятиями, а сразу показывает читателю, как это будет выглядеть в коде. Подобный прикладной подход мне кажется более эффективным в понимании DDD (не самая простая тема).

Однако при этом книга Implementing Domain-Driven Design - не лучшая книга для знакомства с DDD. Автор делает много отсылок к главной книге по DDD - “Предметно-ориентированное проектирование” Эрика Эванса. Также сам стиль написания предполагает, что читатель более-менее знаком с основными понятиями. Вернон не раскрывает понятия DDD более глубоко, а просто показывает их практическое применение. Поэтому если читатель совсем не знаком с DDD, то ему будет довольно сложно уловить суть из коротких объяснений автора.

Именно поэтому я НЕ рекомендую начинать изучение DDD с этой книги. С Эванса тоже не рекомендую, кстати 🙂 Если вы хотите познакомиться с предметно-ориентированным проектированием, то начните с книги Влада Хононова “Изучаем DDD – предметно-ориентированное проектирование” (есть на русском, отличный перевод). На неё я также скоро напишу обзор 🙂

Также отмечу, что примеры кода всё-таки на Java (и дополнительно используются Spring, Hibernate и JUnit). Хоть я и знаком с Java, читать код местами может быть непросто из-за особенностей языка и используемых библиотек.

Отдельно хочется отметить русский перевод. Он ужасен. Книга переведена настолько плохо, что я рекомендую читать в оригинале, даже если это для вас сложно. Русский перевод по качеству напоминает машинный, а суть некоторых терминов искажена до неузнаваемости (что такое супертип уровня?).

Плюсы

Рассказывается про реализацию DDD на практике.
Много примеров кода (и тестов).
Читать ощутимо проще, чем книгу Эванса.
Хорошо читать 2-3 книгой по DDD, чтобы закрепить концепции практикой.

Минусы

Отвратительный русский перевод.
Примеры кода не всегда понятны и очевидны.
Иногда автор излишне многословен.
Не лучшая отправная точка в изучении DDD.
Местами довольно скучная и устаревшая.

Выводы

Книга - хорошая. Я точно рекомендую её прочитать, но не первой. “Реализация методов предметно-ориентированного проектирования” хорошо зайдёт, если у вас уже есть какое-то базовое понимание DDD и связанных с ним понятий. Автор делает очень много отсылок к Эвансу в качестве источника знаний, поэтому лучше читать книгу Вернона второй или третьей.

Если вы новичок в DDD, то начните с книги Влада Хононова “Изучаем DDD – предметно-ориентированное проектирование”.

Оценка: 👍 6/10.

API-тесты до кода на практике

Fri, 29 Dec 2023 00:00:00 GMT

К Test Driven Development я отношусь с долей скепсиса. Несколько раз пробовал классический цикл с юнит-тестами и не могу сказать, что мне понравились результаты. Во время реализации я часто находил решение лучше, менял внутренний дизайн и вслед за ним переписывал тесты.

Зато предварительное написание API-тестов показало себя прекрасно. Это не классический TDD, а скорее API-first подход с автоматизированной проверкой контракта.

От Swagger и Postman к автоматическим тестам

Раньше я работал в привычном процессе: код, ручное тестирование через Swagger или Postman, API-тесты в светлом будущем. Затем оказался в команде, где API-тесты сразу пишут сами разработчики.

Поработав в таком окружении, я почти полностью убрал ручную проверку своего кода через Swagger и Postman. Теперь мой процесс выглядит так:

Пишу спецификацию API. Это недолго, помогает продумать контракт и позволяет заранее отдать его команде на ревью.
Пишу API-тесты по готовой спецификации.
Пишу код и сразу проверяю его этими тестами.

На первый взгляд процесс кажется громоздким, но на практике экономит мне время. Особенно заметна разница в сложных сценариях, где нужно сделать несколько вызовов разных API: один раз описанный тест проще и надёжнее повторных ручных прогонов.

Бонусом остаётся набор проверок, который продолжает работать после завершения задачи и страхует последующие изменения.

За удобство нужно заплатить

У подхода есть цена:

Процесс нужно внедрить в разработку и поддерживать.
Нужна инфраструктура для удобного запуска тестов.
Тесты нужно встроить в CI/CD.
Инфраструктуру и сами сценарии придётся развивать вместе с продуктом.
API-тесты выполняются дольше юнит-тестов и замедляют пайплайн.

Поэтому я не считаю API-тесты до кода бесплатной серебряной пулей. На маленьком проекте стоимость инфраструктуры может не окупиться. Но в долгоживущем приложении со сложными пользовательскими сценариями этот подход оказался для меня затратным на старте и очень выгодным на дистанции.

Мой опыт прохождения курса по алгоритмам

Wed, 27 Dec 2023 00:00:00 GMT

Это опыт прохождения курса в 2023 году. Программа и условия могли с тех пор измениться.

Чуть больше года назад я понял, что хочу систематизировать знания по алгоритмам. Я в целом знал базу, но были пробелы и не было уверенности в знаниях, хотя алгоритмические собесы я проходил без проблем.

Вариант с самостоятельным изучениям по книгам и leetcode я отмёл, потому что был очень загружен и мне бы не хватило терпения этим заниматься. Плюс хотелось иметь какую-то поддержку и обратную связь по своим задачам.

В итоге я решил пройти курс по алгоритмам от Яндекс Практикума. Из всех альтернатив выбрал Практикум по следующим причинам:

Наличие обратной связи - поддержка менторов в чате, проверка ДЗ по каждому модулю.
Покрывал все базовые темы, ничего лишнего.
Продолжительность - 4 месяца (а не 8-10, как в других местах).

Что оказалось сложным

Гладко было на бумаге, да забыли про овраги 🙂 Курс я в итоге успешно прошёл, но есть ряд нюансов, которые выяснились только в процессе.

Бешеная нагрузка. Темп обучения очень высокий. На каждую тему отводится спринт - 2 недели. И если для сортировок и связных списков этого даже много, то на деревьях и графах я успевал с огромным трудом.
Менторы в теме разбираются, но далеко не всегда могут внятно подсказать направление мысли в решении задачи. Они не дают прямых ответов (что хорошо), но частенько их намёки меня только запутывали.
Были проблемы с прохождением бенчмарков по скорости/памяти на NodeJS. Это известная проблема, но несколько задач я просто не смог в итоге сдать.

В целом программа обучения мне понравилась. Самый важный пункт, на который нужно обратить внимание - очень высокая нагрузка и темп обучения. Я справился только потому, что пошёл с опережением на первых темах и потом смог использовать это время для решения задач последующих модулей.

Также я под конец решал не все задачи модуля, а только необходимый минимум (50%, в среднем 5-6 задач). У меня параллельно наложилась ещё и смена работы с сильным выгоранием, поэтому было вдвойне тяжко.

По проверке домашек могу только сказать, что с ревьюером мне повезло и я получал подробную, понятную обратную связь с конкретными рекомендациями и замечаниями. Ни с какими проблемами не сталкивался. Хотя от коллег по курсу с других языков слышал и обратный фидбек. По видимости, здесь как повезёт.

Курс выстроен по принципу “минимум теории, максимум практики”. С одной стороны это хорошо - не приходится штудировать талмуды. С другой стороны, периодически этой самой теории не хватало и приходилось что-то догугливать. Не считаю это существенным минусом, навыки гугления в процессе ещё никому в жизни вреда не приносили.

Что в итоге

Я рад, что прошёл курс. Я прям ощутимо прокачал навыки алгоритмов и достаточно хорошо разобрался во всех темах. Да, спустя год что-то уже вылетело из памяти, но восстановить эти знания - не проблема.
Полученные знания я в процессе финализации обучения протестировал на собесах. Несколько раз попадал в ситуацию, когда интервьюер со смешками срочно доставал задачу откуда-то из “заначки”, потому что я их щёлкал как семечки. Ни один собес не вызвал сколько-нибудь ощутимых затруднений.
Из приятного - материалы остаются со мной навсегда. Когда я учил Go, то немного практиковался на задачках из курса.

Мои рекомендации

Вполне можно обойтись и без курса - достаточно пары хороших книг (Гроккаем алгоритмы, книги Тима Рафгардена) + leetcode. При затыках можно взять ментора 🙂 Но если у и без того высокая нагрузка в жизни (как было у меня) - курс помогает держать темп и сохранять мотивацию. Поэтому выбирайте под себя. Я бы рекомендовал начать с книг и leetcode, затем пойти на курс (если сами не справляетесь).
Если пошли на курс - закладывайте в неделю часов 15-20 на теорию и задачи. Работы не просто много, а очень много. Применяйте весь свой тайм-менеджмент, фиксируйте в календаре слоты и так далее.
Не стесняйтесь просить о помощи. Я как-то задачу решал около 8 часов 🙂 И это с помощью менторов, сам бы раза в два дольше просидел.
Идите с опережением. Если тема лёгкая - проскочите её быстро, решите задачки и двигайтесь к более сложному. Оставьте себе запас по времени на сложные темы.
Не забывайте отдыхать. Работа над алгоритмами изрядно выжирает умственную энергию. Лучше делайте по чуть-чуть, но каждый день.
Опционально - не решайте все задачи сразу. Можно решить необходимый минимум и потом вернуться, чтобы дорешать оставшееся. Так будет даже эффективнее, потому что вам придётся заново вспомнить все материалы темы, чтобы решить задачи.

Желаю вам успехов на пути освоения алгоритмов 🔥

Алгоритмы не нужны?

Mon, 25 Dec 2023 00:00:00 GMT

Тему “ненужности” алгоритмов я слышу постоянно всю свою карьеру. Мнения по вопросу полярны: от “алгоритмы не нужны нигде и никогда” до “алгоритмы - самое главное знание программиста”.

Моё мнение: алгоритмы однозначно нужны, вопрос только в глубине знания.

Алгоритмы и структуры данных - это достаточно обширная тема. В базе это просто набор эффективных решений типовых задач плюс математический аппарат для оценки сложности по скорости/памяти. В более продвинутой версии алгоритмы становятся ближе к матанализу, чем к информационным технологиям, и применяются для решения сложных вычислительных задач.

Базовое знание алгоритмов есть у любого программиста. Все же понимают, как выполнить проход по массиву? Вот вам и алгоритм. Другое дело, что на более сложных задачах человек со знанием алгоритмов зачастую предложит более эффективное решение.

В некоторых областях (тот же ИИ) алгоритмы нужны однозначно. Там всё намного проще, потому что вопрос необходимости знаний в области алгоритмов даже не поднимается. А что же делать тем, кто работает в других областях? Нужны ли алгоритмы людям, которые каждый день красят кнопки и перекладывают JSON-ы?

Я раньше тоже считал, что для эффективной разработки алгоритмы знать не нужно. Я считал алгоритмические собеседования бесполезной тратой времени, которая не показывает ничего обо мне как о кандидате. Поэтому алгоритмы долгое время оставались в моей системе знаний белым пятном. Я успешно проходил алгоритмические собеседования на опыте и чистой логике, но системными знаниями не обладал.

Однажды я решил это исправить и пошёл на большой практический курс по алгоритмам от Яндекс.Практикума. Здесь я не буду описывать свой опыт прохождения курса и как-то его оценивать (если интересно - напишите в комментах, расскажу отдельно). Скажу только, что это обучение прекрасно легло на мой опыт разработки.

Поскольку я на тот момент уже нарешал много задач за свою карьеру, каждая тема навевала воспоминания (или флешбеки). Отчасти поэтому мне было гораздо проще учиться - сами по себе задачки были довольно абстрактными, но практический опыт за плечами помогал лучше их понять.

И после прохождения курса я заметил, как изменилось моё мышление. Я стал гораздо внимательнее анализировать код и решения рабочих задач на предмет оптимальности работы. Я стал гораздо чаще задумываться об эффективности и сложности решения. Также эти знания очень пригодились мне, когда я начал прокачиваться в теме проектирования распределённых систем.

Курс я закончил больше года назад. Многие теоретические моменты уже вылетели из памяти. Но базовое понимание и изменения в мышлении остались со мной (я предполагаю, что навсегда).

В повседневной деятельности вы вряд ли будете писать какую-нибудь ребалансировку бинарного дерева. Но если вы не знаете, как сделать обход графа, то первый же контакт с этой структурой данных выбьет вас из колеи. Поэтому я считаю, что базовые знания алгоритмов и структур данных нужны абсолютно любому разработчику, вне зависимости от языка программирования и области деятельности.

Мораль проста: учите алгоритмы, но до определённой степени глубины. Сохраняйте здравомыслие. И не пишите цикл в цикле в цикле 🙂

«Метод кайдзен», Роберт Маурер

Wed, 20 Dec 2023 00:00:00 GMT

“Метод кайдзен” - интересная, полезная и довольно компактная книжка о применении философии Кайдзен в повседневной жизни. Я её прочитал в отпуске, и мне очень понравились изложенные идеи и примеры.

С философией Кайдзен я уже был знаком, поэтому мне было вдвойне интересно из-за возможности расширить своё понимание и область применения этого подхода.

Ниже - то, что я вынес полезного из этой книги и немного моих рассуждений на тему философии Кайдзен.

Ценность маленьких дел

Не каждый день мы готовы совершать подвиги и сворачивать горы. При этом мы часто обесцениваем маленькие действия и результаты. Кайдзен - это философия непрерывного совершенствования. Суть её заключается в том, чтобы вносить улучшения постоянно, вне зависимости от их размера. Много маленьких улучшений создают эффект снежного кома и в конечном итоге приводят к значительным переменам.

Самое сложное - это научиться делать маленькие дела, думать маленькие мысли и принимать маленькие решения. Нам зачастую хочется каких-то больших, значимых достижений, а маленькие дела кажутся бесполезными. На самом же деле, именно маленькие постоянные действия формируют итоговые большие результаты. Например, так формируются привычки - начинаешь с самого простого из доступных вариантов и постепенно усложняешь.

Маленькие вопросы

Первый урок - задавать маленькие вопросы. “Маленькие” означает не глобальные, не сложные, не вызывающие стресс. Например, задаваться вопросом “В чём смысл моей жизни?” сложно. Такие вопросы нужно задавать себе, но явно не каждый день. Вопросы на каждый день должны быть простыми. Например: “Какую одну вещь я сегодня могу сделать лучше?”, “Какое маленькое изменение я могу сегодня сделать, чтобы улучшить своё здоровье/финансы/отношения и т.д.?” Наш мозг обожает отвечать на вопросы, но глобальные мысли ввергают его в стресс и панику.

Маленькие действия

Следующий шаг - делать маленькие действия. Автор определяет маленькое действие как “действие, которое невозможно не выполнить”. Оно даже должно вызывать смех и реакцию типа “зачем эту мелочь вообще делать, какая от неё будет польза”. А польза есть.

Большие действия, цели и планы пугают наш мозг и он старается от них избавиться. Страх автоматически вызывает блок творческих способностей и реакцию “бей/беги”. Маленькие же действия проходят мимо нашей системы поиска опасности и оказываются выполнены - легко и без стресса. В этом и есть секрет - поскольку эти действия не несут опасности (например, риска неудачи), мозг не воспринимает их как угрозу и не включает соответствующие реакции.

Каждый маленький шаг поднимает уверенность в себе и даёт силы на следующий шаг. К тому же так формируются более устойчивые паттерны поведения. В моменте может казаться, что эти мелочи ничего не меняют, и это отчасти правда. Маленькие шаги не дают результат за день-два. Но суть подхода - шагать долго, а не быстро. Шагающий долго покроет бОльшее расстояние 🙂

Пример маленького действия - отложите одну дольку шоколадки перед тем, как её есть 🙂

Маленькие проблемы

Решение больших и сложных проблем приносит нам много удовольствия или облегчения (зависит от контекста). Однако мы склонны игнорировать маленькие проблемы по причинам, которые я уже описывал выше. Тем не менее, многие проблемы гораздо проще и дешевле исправить в зародыше. Если ходить к стоматологу раз в полгода, то вряд ли вы окажетесь в ситуации, когда половину зубов нужно вырывать. Профилактика всегда дешевле лечения.

Многие проблемы хочется игнорировать, потому что они “недостаточно бесят”. Но гораздо лучше для нас самих не доводить эти проблемы до состояния, когда решать их придётся срочно. Нужно учиться думать на перспективу и предвидеть последствия этого игнорирования.

Маленькие награды

У нас в среднем принято вознаграждать только за большие, значительные достижения. “Закончишь семестр без троек - купим тебе велосипед”, например. При этом постоянная положительная обратная связь важна и нужна. Это по сути дополнительный способ поддержания мотивации.

Здесь важна адекватность награды. Она должна быть соответствующего размера (то есть, маленькой), адекватной человеку и недорогой (или вообще бесплатной). Её задача - просто показать, что труд и маленькие достижения тоже ценны. Прелесть в том, что такая награда достаётся гораздо чаще, чем большой куш за огромные проекты.

Наградой может быть комплимент, похвала, чашка кофе, шоколадка, да что угодно. Себя можно в том числе наградить чем-то приятным (полежать в ванне, например).

Маленькие моменты

Последнее, но не по важности - навык замечать маленькие моменты. Он объединяет в себе все предыдущие пункты. Нужно уметь находить маленькие проблемы, замечать маленькие достижения и раздавать за них маленькие награды. Большие проблемы/достижения/награды вы и так заметите 😀

Резюме

Книга мне очень понравилась. В ней хорошо описано применение философии Кайдзен в повседневных делах. Было забавно в процессе чтения осознавать, что некоторые из этих советов я уже осознал и применяю (я большой любитель и пропагандист маленьких изменений в проектах). Но также я почерпнул для себя много нового.

Самый полезный эффект от этой книги - я расширил своё понимание “маленьких дел” и нашёл ряд новых зон для применения Кайдзен в своей жизни. Например, я начал ценить небольшие отрывки времени (5-10 минут), в которые можно почитать. Также я снова начал делать маленькие медитации (тоже 5-10 минут).

Одна из самых сложных для меня вещей - это признание маленьких результатов (своих и чужих) и маленькие награды (мне они кажутся смешными). Но я сделал несколько экспериментов и результат показал, что этот подход работает.

Книгу смело рекомендую к прочтению. Несмотря на скромный размер, она точно подарит вам пищу для размышлений.

Оценка: 🔥 8/10.

Просто начни делать: тест на десять минут

Mon, 18 Dec 2023 00:00:00 GMT

Одна из рабочих техник против прокрастинации в моём арсенале - просто начать делать задачу. Но я использую её ещё и как диагностический тест.

Если задача понятна, цель есть, а энергии хотя бы немного осталось, я прикладываю сознательное усилие и начинаю работать. Обычно минут через десять процесс затягивает и дальше всё идёт нормально.

Мне помогают небольшие ритуалы: включить фоновую музыку, закрыть лишние приложения и вкладки, иногда заварить чай перед долгой работой.

Отсечка в десять минут

Бывают ситуации, когда старт не помогает. Если через десять минут я по-прежнему пытаюсь сбежать от задачи, значит, исходные предположения были неверными.

Возможно, задача плохо поставлена. Возможно, у меня нет сил. Иногда я не понимаю, зачем её делать, или вижу в ней неприятную проблему, которую ещё не сформулировал.

В этот момент я перестаю давить на себя и спрашиваю: «Что именно мешает мне работать?»

Совет «просто начни» полезен как короткий эксперимент. Если он не сработал, продолжать мучить себя бессмысленно. Нужно искать причину прокрастинации.

Monolith-first подход

Wed, 06 Dec 2023 00:00:00 GMT

Из опыта я глубоко убеждён: в большинстве случаев создание новой системы лучше начинать с монолита. Особенно если это абсолютно новый продукт, которому только предстоит выйти на рынок.

При работе с монолитом система эволюционирует. Изначально ваш проект будет не очень большим и сложным, поэтому он будет быстро расти и развиваться. В какой-то момент вы придёте в стадию, где писать проект уже сложно и он не справляется с нагрузкой. Это очень хороший знак, потому что он говорит, что продукт востребован и им пользуются.

В такой ситуации при необходимости можно начать делить монолит на микросервисы: выделять связанные контексты, выносить код и мигрировать базы данных. Это стандартная история IT-мира: у нас был монолит, но мы выросли и мигрировали на микросервисы.

Такой подход позволяет сохранить естественный порядок вещей: сложное вырастает из простого путём эволюции (а порой и революции). Обычно такие системы лучше продуманы и более устойчивы к изменениям, а у компании достаточно денег на техническое и инфраструктурное обеспечение.

Начинать с микросервисов - это гораздо больший риск. Если вы делаете стартап, то у вас вряд ли будет возможность адекватно разделить границы микросервисов. Вам придётся либо постоянно переделывать кучу микросервисов, либо делать распределённый монолит с большим количеством межсервисных взаимодействий и низкой надёжностью. К тому же, для работы в микросервисной среде нужны люди - много людей. Нужно достаточно разработчиков (зачастую - несколько команд), а также нужны квалифицированные DevOps-инженеры.

Зачастую стартапы не могут себе позволить такую роскошь, поэтому попытка делать сразу микросервисы может оказаться губительной для них. Гораздо проще будет начать с монолита и постепенно развиваться.

Даже если вы делаете новую систему в уже существующей компании, то лучше будет начать с монолита. Крайне редко на моём опыте бывали ситуации, когда мы на 100% точно знали, что нужно делать. И уж точно эта определённость не распространялась на весь продукт.

Для грамотного выделения микросервисов нужны ресурсы и знания домена. Без знания домена есть высокая вероятность неудачно выделить сервисы и получить распределённый монолит.

Поэтому если начинаете делать новый продукт - возьмите монолит. Это убережёт вас от кучи проблем в ближайшем будущем.

Но и распиливать монолит нужно вдумчиво: попытка мигрировать слона по кусочкам легко приводит к тому же распределённому монолиту.

«Современный подход к программной архитектуре», Нил Форд, Марк Ричардс и др.

Sun, 03 Dec 2023 00:00:00 GMT

Обзор на книгу Нила Форда и компании “Современный подход к программной архитектуре” (”Software Architecture: The Hard Parts”).

Если бы меня попросили дать название этой книге, то я бы назвал её “Большая книга о компромиссах в архитектуре ПО”. Команда авторов написала увесистый талмуд из почти 500 страниц о том, что в архитектуре не бывает лёгких и правильных решений, бывают только грамотно подобранные компромиссы.

«Всё — яд, всё — лекарство; то и другое определяет доза». Парацельс

Коротко о главном

Книга о компромиссах в архитектуре ПО
Рассматривается множество проблем архитектуры от модульности до распределённых транзакций
Довольно объёмная, но легко читается
В начале каждой главы приводится пример из реального мира

Я совершил небольшую ошибку, начав своё знакомство с творчеством Нила Форда с этой книги. Фактически она является продолжением “Fundamentals of software architecture” и авторы очень часто на неё ссылаются. Но это не повлияло на качество самой книги, поэтому в целом можно начинать и с неё.

Книга построена в интересном смешанном формате художественной и технической литературы. По ходу чтения мы вместе с командой вымышленного бизнеса проходим процесс эволюции архитектуры от болезненного монолита к микросервисам. Мне было так читать гораздо удобнее, потому что в начале каждой главы я получал кусочек бизнес-контекста и пример проблемы из реального мира. Так гораздо легче воспринимать информацию.

Читать было интересно. Несмотря на не самые простые темы, книга очень хорошо написана (и, что удивительно, переведена). Отдельным плюсом можно выделить большое количество рисунков/графиков/схем, которые сильно упрощают понимание происходящего.

Книга мне понравилась, и я почерпнул для себя много полезного. Пожалуй, самый главный урок — сложность компромиссов. Я и раньше прекрасно понимал, что в архитектуре не бывает простых решений, но после прочтения книги я по-новому взглянул на слово «компромисс». На самом деле компромиссы есть в каждом нашем решении (и это касается не только работы). Книга выводит компромиссы на передний план и показывает, что за любое решение так или иначе приходится платить. Мы всегда платим за свой выбор — за монолит, за микросервисы, за SQL, за NoSQL, за любую технологию. И наша задача заключается в том, чтобы выбрать наиболее приемлемый и подходящий компромисс.

Также особенно ценной для меня оказалась глава по построению саг. Сага - это распределённая многошаговая транзакция, части которой выполняют разные микросервисы. Раньше я знал только один вид саг: синхронная сага с оркестрацией и строгой согласованностью. Авторы же описывают 8 видов саг в зависимости от конфигураций:

Взаимодействия: синхронные/асинхронные
Согласованность: строгая/нестрогая
Координация: оркестрация/хореография

В процессе чтения оказалось, что часть из этих саг я уже применял, просто не знал, что это так называется и уже кем-то описано. Все виды саг описаны очень подробно, и у каждого вида есть свой перечень преимуществ, недостатков и характеристик. Например, описанная мной выше сага называется «Эпическая сага», и её недостатки — низкая скорость, высокая связность и низкая масштабируемость.

Также авторы акцентируют внимание на том, что архитектура служит бизнесу, а не наоборот. Грамотно построенная архитектура ускоряет TTM фич, что для некоторых бизнесов критично. Если бизнес работает в высококонкурентной среде, то для него релизы раз в два месяца могут быть медленной и мучительной дорогой в ад. Поэтому бизнес и готов идти на компромиссы (да, и тут они) - например, местами отказываться от строгой согласованности в пользу повышенной скорости обработки и масштабируемости. При работе над архитектурой, будь то перестройка системы или просто предложение по улучшению, всегда нужно помнить о главной цели - сделать бизнесу жизнь проще и удобнее.

Также отмечу несколько недостатков книги:

Некоторые аргументы крайне спорные (что вполне нормально в контексте книги).
Очень поверхностно покрыты темы применения DDD и хранения данных.
Чересчур много отсылок на предыдущую книгу, авторы как бы намекают на “купи-купи”.
Назвать эту книгу глубокой - сложно. Скорее, это базовое введение в архитектуру. Книга всё-таки довольно поверхностная.

В заключение приведу несколько случайных интересных тезисов:

Архитекторы не должны постоянно искать “серебряные пули”.
Без постоянной работы любая база кода постепенно скатится в “большой ком грязи”.
Разделение базы данных на четко определённые ограниченные контексты помогает контролировать критические изменения в базе данных.
При использовании монолитной БД все данные должны соответствовать её типу, что может приводить к решениям, неоптимальным для определённых типов данных.
Гранулярность определяется не количеством классов или строк кода, а функциями, возложенными на сервис. Вот почему так сложно добиться правильной гранулярности.
Тщательно продумывая инкапсуляцию и контракты, архитекторы могут ограничить количество критических изменений и уменьшить хрупкость архитектуры.
В общем случае считается, что сервис, выполняющий операции записи в таблицу, является владельцем этой таблицы. Однако совместное владение усложняет это простое правило!

Выводы

Книга - отличная. Настоятельно рекомендую.
Материал не для новичков, целевая аудитория - более опытные специалисты (middle/senior и выше).
Полезна будет даже опытным и знающим спецам, а для тех, кто только начал своё погружение в архитектуру, станет настоящей кладезью информации.
Хорошо переведена и можно смело читать на русском.
Отдельный большой плюс - много схем/графиков/диаграмм, которые иллюстрируют

Моя оценка

10/10.

Применять DRY с умом

Fri, 24 Nov 2023 00:00:00 GMT

Принцип DRY заставляет думать о переиспользуемых компонентах и выносить общее поведение в одно место. Копии кода приходится искать, менять и тестировать отдельно. Но бездумное устранение любого повторения тоже портит систему.

Одинаковый код может иметь разную судьбу

DRY хорошо работает для утилитарных вещей вроде логирования. С бизнес-логикой всё менее однозначно.

Мне неоднократно приходилось распиливать «универсальный» код, продираясь через сложные абстракции и нечитаемые дженерики. Желание переиспользовать всё сразу создаёт компонент с высокой связанностью. Через него начинают зависеть друг от друга части системы, которые должны развиваться независимо.

Поэтому, когда два фрагмента бизнес-логики хочется схлопнуть в общий модуль, я задаю себе один вопрос:

Будет ли этот код развиваться по-разному?

Одинаковые сегодня сценарии через несколько месяцев могут разъехаться из-за разных бизнес-требований. Тогда универсальный компонент обрастает флагами, параметрами и исключениями, а любое изменение требует проверять всех потребителей.

Универсального рецепта нет. Иногда лучше оставить две или три копии и дать им развиваться независимо. Десять копий оставлять не надо, всему есть предел.

Как анализировать архитектурные компромиссы

Wed, 22 Nov 2023 00:00:00 GMT

В архитектуре нет бесплатных решений. Монолит и микросервисы, слоистая архитектура и DDD, высокое и низкое покрытие тестами — любой вариант даёт одни свойства и заставляет платить другими.

Поэтому вопрос «какая архитектура правильная?» мало полезен. Гораздо важнее понять, какие свойства нужны в конкретной ситуации и какую цену команда готова за них заплатить.

Начните с критериев

Без критериев анализ быстро превращается в обмен вкусовщиной. До сравнения вариантов полезно зафиксировать:

какую проблему мы решаем;
какие свойства системы для нас важны;
какие ограничения есть у команды и бизнеса;
какие допущения мы делаем;
как поймём, что решение сработало.

После этого можно сравнивать варианты. Методика тут вторична: иногда хватает списка плюсов и минусов. Мне удобен SWOT, потому что он вынуждает отдельно подумать о возможностях и рисках.

Как использовать SWOT

Strengths — сильные стороны варианта.
Weaknesses — слабые стороны и прямые издержки.
Opportunities — какие возможности для продукта и бизнеса открывает решение.
Threats — какие риски создаёт решение.

Например, при выделении сервиса из монолита в сильные стороны могут попасть независимое масштабирование и возможность отдать компонент отдельной команде. В слабые — распределённые транзакции и усложнение эксплуатации. В возможности — подготовка к росту нагрузки. В риски — нехватка опыта у команды, рост сроков и числа отказов.

Сам SWOT не принимает решение. Он лишь помогает явно записать цену каждого варианта. Дальше нужно вернуться к исходным критериям и выбрать тот набор компромиссов, который подходит ситуации.

Антипаттерн миграции слонов

Mon, 20 Nov 2023 00:00:00 GMT

Встретил это замечательное определение в книге «Software Architecture: The Hard Parts». Антипаттерн описывает один из самых популярных, понятных, очевидных и неправильных подходов к распиливанию монолита - “мигрировать слона по кусочкам”.

Сама по себе идея - замечательная. Вот у нас есть большая штука, её нужно как-то переделать. Значит, нужно съесть этого слона по кусочкам! В случае обычных проектов в жизни этот подход работает прекрасно (сам проверял). Но в случае распиливания монолита на сервисы этот слоник способен легко вызвать несварение. При всей простоте, у подхода есть куча минусов и побочных эффектов.

Главный на мой взгляд минус - это игнорирование общей системы в пользу частного куска. Часто какая-то функциональная часть сервиса так и просится быть выделенной в отдельный микросервис. Команда увлечённо начинает этим заниматься (и даже, возможно, завершает этот процесс). Но на выходе оказывается, что полученный сервис превратил наш монолит в распределённый монолит со всем ворохом сопутствующих проблем. К сервису идёт куча сетевых обращений, появились распределённые транзакции или ещё неизвестно что.

Вторая проблема - выделение микросервиса по функциональному признаку. В таком подходе существует скрытый риск того, что изменения в требованиях превратят в легаси половину системы. Даже если изначально сервис был выделен хорошо и отвязан от монолита - малейшие изменения в структуре данных снова создают распределённый монолит.

В итоге такое распиливание “слона по кусочкам” частенько приводит к появлению на проекте архитектурного долга и проблем с надёжностью. И заканчивается это всё тем, что я на практике делал чуть ли не на каждом месте работы - заливанием микросервисов назад в монолит. Грустно, не так ли? В одном из самых неприятных сценариев мы полгода (полгода, Карл!) выносили микросервис - писали код, мигрировали данные, настраивали взаимодействие. А затем торжественно похоронили его и еще несколько месяцев заливали назад в монолит.

И ладно, когда дело ограничивается одним сервисом. Некоторые команды умудряются распилить ВЕСЬ монолит на микросервисы в таком подходе. В итоге код становится проще, а вся сложность монолита уезжает на уровень взаимодействий между микросервисами. Надёжность системы помахала ручкой и вышла из чата.

Именно поэтому так важно изучать то же DDD и выносить микросервисы, основываясь на домене. Это тоже не панацея, но вероятность сливания микросервиса назад в монолит всё-таки становится пониже.

Есть ещё одна отличная практика. В следующий раз, когда у вас или кого-то из команды зачешутся руки что-то вынести в микросервис, можно задать очень отрезвляющий вопрос: “А, собственно, нахрена?”

Что значит «микро» в слове «микросервис»

Fri, 17 Nov 2023 00:00:00 GMT

Классический вопрос, вызывающий бурные дискуссии и резкое глобальное потепление зон пониже поясницы: какого размера должен быть микросервис?

Я видел предложения измерять «микро» строками кода, количеством файлов, классов и ещё не пойми чем. Но все количественные метрики ломаются: тысяча строк простой бизнес-логики и тысяча строк сложного инфраструктурного кода дают совершенно разную нагрузку на команду.

Качественные определения тоже не дают магического числа:

Микросервис — это сервис, который одна команда может переписать за спринт.

А команда — это сколько? А спринт — неделя или месяц?

Микросервис — это сервис, который может разрабатывать один человек.

А если не может, это уже не микросервис?

Микросервис должен помещаться в голове одного человека.

Это уже ближе к полезному ориентиру: определение говорит не о количестве файлов, а о сложности и понятности ответственности. Но и его недостаточно, чтобы провести границу сервиса.

Важен не размер, а граница ответственности

Мне полезнее смотреть на бизнес-функции и изменения, ради которых сервис существует. У него должна быть понятная ответственность, а изменения внутри неё не должны постоянно требовать синхронных правок в соседних сервисах.

Bounded context из DDD помогает искать такие границы, но не даёт формулы «один контекст — один микросервис». Контекст может остаться модулем внутри монолита, если отдельный деплой не приносит пользы. И наоборот, слишком широкий сервис можно разделить, если разные части меняются и масштабируются независимо.

Поэтому «микро» для меня — не про минимальный объём кода. Это про достаточно узкую и связную ответственность, которой команда может управлять независимо. Строк и классов в сервисе должно быть столько, сколько нужно для этой задачи.

При этом хороший размер не спасает от неверно выбранной архитектуры. Для нового продукта я обычно предпочитаю monolith-first подход, а к разделению перехожу, когда границы домена и цена независимых изменений стали понятнее. Подробнее о компромиссах микросервисной архитектуры я писал в обзорах книг Сэма Ньюмена «Создание микросервисов» и «От монолита к микросервисам».

Как продавать работу над техдолгом

Mon, 30 Oct 2023 00:00:00 GMT

Очень часто затыком в развитии становится не отсутствие технических задач, а то, что на них не выделяют ресурсы.

С точки зрения бизнеса это логично. Зачем делать непонятный рефакторинг, если можно запилить ещё одну фичу, продать её клиентам и заработать денег? Бизнес не хочет тратить ресурсы на что попало. Он хочет понимать пользу.

Поэтому техническую задачу мало найти и описать. Её ещё нужно продать. Проще говоря, чётко ответить на вопрос: а нахрена вообще это делать?

Перевести проблему на язык бизнеса

Аргументы вроде «тут говнокод» малоубедительны. Бизнес не знает, что такое говнокод, зато знает, что такое деньги. Разговор стоит строить вокруг наблюдаемых последствий:

в этом куске кода постоянно появляются баги;
даже простая задача в компоненте съедает много времени;
медленный код ухудшает клиентский опыт;
ручное тестирование стало узким местом и задерживает релизы;
устаревшее решение мешает выпустить нужную функцию.

Затем проблему можно связать с метриками: количеством багов, временем выхода изменения, загрузкой QA, частотой сбоев или потерей клиентов. Продавать нужно не рефакторинг, а изменение этих показателей.

Пример из практики

Однажды в моей команде тестирование стало узким местом. Разработчики быстро делали фичи, но их не удавалось так же быстро выпускать. Я договорился с руководством, что разработчики помогут разгрузить тестировщиков автотестами.

Критичные сценарии покрыли автотестами, тестировщикам стало проще управлять задачами, а скорость релизов выросла. Для бизнеса ценность оказалась понятна: мы стали быстрее доносить изменения до клиентов.

Сделать техдолг осязаемым

Даже проданный техдолг легко снова утопить в бэклоге. Поэтому я придерживаюсь ещё трёх правил:

Техдолг должен жить в таск-трекере, а не только в TODO в коде.
Описание задачи должно отвечать на три вопроса: в чём проблема, на что она влияет и как должно стать.
Большие задачи нужно разбивать на подзадачи, чтобы их можно было постепенно встраивать в план.

Не каждую техническую задачу нужно делать немедленно. Но если команда не может объяснить цену откладывания, у бизнеса нет причин отдавать этой работе приоритет.

Про короткие переходы на сложность выше

Mon, 23 Oct 2023 00:00:00 GMT

На выходных я заметил интересный эффект. Если ненадолго перейти на уровень сложности выше, а потом вернуться к привычному, привычный уровень ощущается проще.

Я тренировал скорость игры на барабанах. После разминки поднял темп, а затем ради интереса ускорился ещё сильнее. На этой скорости я резко начал лажать и сбивался после шести-восьми ударов.

Через минуту-полторы вернулся к исходному темпу. Он показался настолько комфортным, что вскоре я смог немного его повысить.

Похожее происходило со мной и в других занятиях:

После спаррингов со спортсменами-разрядниками обычные спарринги становились проще.
После мозголомных книг остальные читались легче.
После сложных технических задач будничные решались быстрее.

Для себя я вывел три ограничения этой практики:

Повышение сложности должно быть коротким. Зубодробительная техническая задача на пару дней подходит лучше, чем эпик на несколько месяцев.
После сложного участка нужно вернуться на рабочий уровень, а не пытаться жить в постоянной перегрузке.
Лучше усложнять один аспект за раз. Сложная задача на незнакомом языке добавляет сразу несколько источников трудностей.

Короткий переход на уровень выше помогает мне увидеть запас в привычной работе. Постоянная жизнь на этом уровне заканчивается уже не тренировкой, а истощением.

Похожий принцип я использую, когда создаю безопасную неопределённость для развития сотрудников: сложность должна давать пространство для роста, а не бросать человека без опоры.

Где взять задачи для развития

Fri, 20 Oct 2023 00:00:00 GMT

Искать себе задачи для развития — это отдельный навык, который тоже нужно развивать 🙂

Я в карьере часто бился головой в то, что мне скучно. Текущие задачи уже делать не интересно, потому что сложности и вызова нет. А новых вызовов тоже что-то не подвозит.

Это было моё вечное страдалити. Я очень быстро обучаюсь и разбираюсь в чём-то новом. К тому же, я очень любопытный человек и люблю учиться чему-то новому. Но когда этого нового и интересного нет - я начинаю скучать. Из-за этого я чаще всего и увольнялся с предыдущих мест работы.

Но через некоторое время я понял простую, но очень важную вещь. Моё развитие — моя ответственность. Следовательно, наличие задач на это самое развитие — тоже моя ответственность.

Поиск задач для саморазвития — это навык. Точно такой же, как слепая печать или написание юнит-тестов. И его вполне можно прокачать.

Лично у меня сработал довольно простой и топорный способ: я записывал все идеи по развитию, которые приходили мне в голову. Затем выбирал самые перспективные и полезные и просто делал их.

Сложнее всего было не пренебрегать мелочами. Но именно это оказалось самым важным. Мелочи занимают довольно много внимания и ресурсов мозга. Но если их выгрузить и пощёлкать на досуге, то обычно появляются какие-то более крупные и интересные идеи. И вот эти идеи уже круто ведут к развитию.

Таким способом я прокачал сразу несколько моментов:

Развил навык поиска слабых мест и улучшений.
Изрядно прокачал проект (и за компанию прокачался сам).
Нашёл несколько довольно крупных и интересных задач, которые помогут мне в развитии.

Мы не боги, и не всегда есть возможность сделать что-то новое и классное на текущем проекте. Но это тоже не приговор. Всегда можно сделать пет-проект на новых технологиях или покачать сопутствующие нетехнические навыки: писательство, менторинг, публичные выступления. Вариантов — море, было бы желание.

Последнее, о чём хочется сказать: всегда можно попросить помощи. Например, пойти к тимлиду, архитектору, CTO или другому руководителю и попросить помочь с направлением развития. У этих людей обычно более широкий взгляд, поэтому они вполне могут накидать неожиданных идей.

Что попробовать

Записывайте ВСЕ идеи по саморазвитию. Реализуйте самые интересные.
Не пренебрегайте небольшими задачами и идеями.
Сделайте пет-проект на новых технологиях.
Покачайте нетехнические навыки: писательство, менторинг, публичные выступления.
Попросите интересных задач у руководителя.

Идеальной спеки не будет

Mon, 16 Oct 2023 00:00:00 GMT

Раньше я с ноги врубался в задачу и пилил до победного. Сквозь боль, слёзы, баги и сорванные сроки. Всё изменилось, когда я начал лидить команду и больно ударился о недостаточно проработанные задачи. Предварительно оценённый эпик мог вырасти примерно на 30%.

Мы стали уделять больше времени грумингу фич. Команда отметила два изменения:

Стало понятно, как фича работает с точки зрения бизнеса, как встраивается в процессы и какие краевые случаи нужно учесть.
Ещё до первой строки кода стало примерно понятно, как решение будет выглядеть в системе.

Меня зацепило это «примерно». Поэтому мы добавили техническую проработку и ревью решения до написания кода. Мы фактически отделили думанье от деланья. По хорошо проработанной спеке программировать оказалось намного проще.

Со стороны процесс казался бюрократичным: много грумингов, много «бумажек». На деле эти затраты перенесли часть сложности туда, где ошибку ещё дёшево исправить.

Но идеальной спеки всё равно не будет. Забудут специфичный сценарий, не опишут API или не продумают часть функционала. Здесь от senior-инженера я жду не возмущения по поводу неидеального мира, а поиска ответа и движения задачи вперёд.

Граница здесь важна. Инженер не должен молча принимать на себя чужую работу или угадывать критические требования. Если пробел мешает принять безопасное решение, нужно остановиться и вернуть вопрос владельцу требований.

Мой рабочий компромисс такой:

До разработки письменно проработать бизнес-сценарии и техническое решение.
Не пытаться сразу написать идеально. Сначала выгрузить структуру и мысли, затем довести их до целого.
Считать спеку инструментом снижения известной неопределённости, а не гарантией, что неожиданностей не будет.

«Высоконагруженные приложения», Мартин Клеппманн

Wed, 11 Oct 2023 00:00:00 GMT

Сегодня - обзор на настоящую библию разработчиков высоконагруженных систем. Designing Data-Intensive Applications, она же DDIA, она же “Высоконагруженные приложения”, она же “книжка с кабанчиком”. Не столь давно я прочитал её во второй раз и решил написать обзор, потому что считаю эту книгу крайне важной.

TL;DR

Обзорное введение в проектирование высоконагруженных систем, всего лишь 650 страниц 🤣
Познакомитесь со всеми видами сбоев и потенциальных проблем.
Узнаете, как масштабировать своё приложение и какие проблемы возникают на новых уровнях.
Не самое простое чтиво, рекомендую ребята от миддла и выше.
Считаю строго обязательной для чтения.

Книга Клеппманна довольно большая, но стоит потраченного времени. Её можно фактически держать под рукой как пособие по решению тех или иных проблем высоконагруженных распределённых систем. При этом важно понимать, что Клеппманн не закапывается в супер-низкоуровневые детали той или иной темы. Он даёт ровно столько информации, сколько нужно для общего понимания. При желании вы прекрасно поймёте, куда копать дальше.

При этом книга совершенно не показалась мне избыточной, несмотря на довольно солидный объём. Клеппманн нашёл удивительный баланс между академической сухостью и водой-водицей уровня студенческого диплома. Читать приятно и интересно. Мозги у меня местами кипели, но не слишком - при должной въедливости во всех темах прекрасно можно разобраться.

Книга разделена на 3 большие части:

Основы информационных систем.
Распределённые данные.
Производные данные.

Раздел 1 “Основы информационных систем”

Первый раздел “Основы информационных систем” знакомит нас с основными идеями, которые относятся к любой информационной системе вне зависимости от её размера. Здесь раскрываются три кита информационных систем - Надежность, Масштабируемость, Удобство сопровождения.

Также в этой главе я посмотрел на разные типы БД и принципы построения запросов к ним (про графовую было особенно интересно). Очень интересной оказалась третья глава, в которой довольно подробно рассказано про устройство индексов и разницу между OLAP/OLTP хранилищами. Завершается раздел важной главой про кодирование - преобразование структур данных в биты на диске или по сети. Здесь Клеппманн очень подробно даёт обзор разных форматов (XML, JSON, Protocol Buffers etc) и раскрывает проблемы прямой/обратной совместимости.

Раздел 2 “Распределённые данные”

Второй раздел “Распределённые данные” переводит нас в увлекательный мир, где БД работает на нескольких машинах. На мой взгляд, это самый важный раздел книги и поэтому ему я посвящу больше всего внимания.

Первой раскрывается такая тема, как репликация (хранение копий данных на нескольких машинах, соединённых по сети) и проблемы, возникающие при реплицировании данных (например, отказ master-ноды способен создать целый букет проблем). Также круто раскрыт вопрос решения проблем при задержке репликации. Затем описаны multi-master репликация (при которой неизбежно возникают конфликты записи) и репликация без мастера (в которой появляются проблемы согласованности и приходится применять хитрые решения типа выбора по кворуму). Последней идёт тема секционирования (разбиение большого куска данных на меньшие кусочки) и шардирование (вынесение этих кусочков на отдельные машины).

Отдельная большая глава посвящена транзакциям. Для начала автор высмеивает аббревиатуру ACID (которая так и не смогла устояться и в которую для красоты добавили букву С). А вот дальше начинается интересная и очень важная тема - уровни изоляции транзакций. Пожалуй, это лучший гайд по ним - подробный, со схемами и описаниями. Вот, например, описательная схема проблемы dirty writes, защиту от которых обеспечивает базовый уровень изоляции read commited.

Вишенкой на торте стало описание алгоритма двухфазной блокировки (two-phase lock, 2PL). Конфликтов в БД у вас больше не будет, но цена за это - чудовищно низкая производительность.

Следующая тема - проблемы распределённых систем. Здесь рассматривается весь спектр проблем, которые могут возникнуть в системе из нескольких машин:

Сбои и частичные отказы (как программные, так и аппаратные).
Ненадёжные сети (и вообще сетевые проблемы в системах).
Ненадёжные часы (показания часов на разных машинах могут значительно отличаться и это ведёт к проблемам с определением последовательностей событий).
Византийские сбои (умышленное создание проблем в системе).

Последняя глава в этом разделе посвящена согласованности и консенсусу. Тема важная, потому что при отсутствии консенсуса в случае сбоя у вас в системе может образоваться два ведущих узла. Последствия будут крайне неприятными. В этой главе раскрываются различные уровни согласованности (и попутно высмеивается всем любимая теорема САР):

Линеаризуемость - самая сильная гарантия. Система выглядит так, будто в ней всего одна копия данных и все операции атомарны. Сложно, больно, дорого 🙂
Причинно-следственная упорядоченность - сохраняем последовательность событий, которые непосредственно связаны друг с другом.

Причинно-следственная упорядоченность создаёт вероятность конфликтов, поэтому заключительная часть главы посвящена консенсусу, который призван решить эту проблему.

Раздел 3 “Производные данные”

Третий раздел посвящен интеграции информационных систем между собой. Здесь рассматриваются пакетная обработка больших данных, модель пайплайнов Unix и модель обработки MapReduce. Здесь же мы знакомимся с такими инструментами, как Hadoop Distributed File System (HDFS) и Spark. После погружения в обработку больших данных автор знакомит нас с потоковой обработкой - когда данные поступают в систему постоянно и никогда не останавливаются. Здесь же затрагиваются техники перехвата данных (change data capture, CDC) и проблемы обогащения данных. Финалится книга интересными и довольно философскими рассуждениями Клеппманна на тему будущего информационных систем.

Итоги

Книга - крутая и классная. Must read.
Читать нужно внимательно и вдумчиво, но не всё. Например, последний раздел я читал далеко не так внимательно, как второй.
Даже не пытайтесь всё запомнить. Прочтите, ознакомьтесь и держите под рукой как справочник.
Если хотите расти дальше из программистов в проектировщики - считайте эту книгу первым шагом к своей цели.
Из минусов - иногда книга кажется довольно поверхностной + некоторые упомянутые технологии уже успели устареть и уйти с рынка (тот же Riak, например).
Толстая и кажется, будто никогда её не дочитаешь 🤣

🔥 10/10. Интересная и очень полезная книга, обязательна к чтению. Я прочитал второй раз и возможно буду читать ещё.

Забрал себе.

Главными являются три кита - Надежность, Масштабируемость, Удобство сопровождения.
Поводы для распределения БД по нескольким машинам - масштабируемость, отказоустойчивость/высокая доступность, задержка.
Репликация бывает асинхронной и синхронной. Асинхронная более надёжна, но можно потерять данные при сбое. Синхронная более хрупкая, но данные точно не теряются.
Способы решения задержки репликации - read your own writes (пользователь всегда должен видеть свои изменения), monothonic reads (при нескольких операциях чтения подряд пользователь не увидит “продвижения назад во времени”) и consistent prefix reads (если операции записи выполняются в определённой последовательности, они будут в ней же и прочитаны). Все эти гарантии слабее strong consistency, но при масштабировании по-другому никак.
Шардировать нужно вдумчиво. Неправильно выбранный ключ шардирования может создать “горячие точки” (перегруженные машины) или необходимость поиска по нескольким шардам. Для решения последней проблемы можно делать вторичные индексы по документами (локальные индексы) или по термам (собираем глобальный вторичный индекс из локальных по шардам).
Основной принцип изоляции снимков состояния звучит как «чтение никогда не блокирует запись, а запись — чтение». Это обеспечивается за счёт MVCC (одновременное хранение множества версий одного объекта).

Главное отличие Senior от Middle

Sat, 07 Oct 2023 00:00:00 GMT

Частенько слышу такие вопросы: «Как мне стать Senior? Как мне понять, что я уже Senior?» Сегодня расскажу про главное, на мой взгляд, отличие действительно Senior-спецов от казаков — тех, которые лычками увешаны.

Я как тимлид и техлид взаимодействовал с большим количеством разных ребят из абсолютно разных сфер (не только IT, кста). И вот, что на мой взгляд отличает трушных сеньёров.

Настоящие Senior полностью автономны вне зависимости от профессии.

Поясню. Грейд специалиста повышается, когда растет сложность задач, которые он может решать самостоятельно, без надзора.

Джун может делать простые и понятные штуки с хорошим описанием конечного результата. Шаг влево/вправо - и специалист теряется.

Мидл уже зачастую может взяться за не до конца проработанную задачу и доделать эту проработку в процессе.

Senior же в моём мире — это человек, который из описания в пару предложений способен довести задачу до логического завершения. При этом ему не нужен надзор: он организует работу сам.

Приведу пример из текущей практики. Прилетает мне запрос на фичу - вот, надо сделать такую штуку (про штуку сильно рассказывать не буду, не столь важно). Из описания - ну у нас есть проблема и примерно вот так мы хотим её решать.

Что я делаю

Закапываюсь в проблематику, разбираюсь. Обдумываю предложенное решение и его реализацию.
Пишу доку, в которой собираю все бизнес-требования в кучу и довожу их до ума.
Ловлю аналитиков в промежутках между созвонами, уточняю все вопросы, записываю их в доку.
Туда же пишу предполагаемую техническую реализацию, план релиза и всё остальное.
Дёргаю коллег, чтобы просмотрели и откомментили это всё.
Завожу эпик в Jira, разбиваю на подзадачи, делаю им описание, ставлю оценки.
Беру в работу, дальше всё идёт своим чередом.

Процесс может меняться в зависимости от контекста, но суть примерно та же. Я сам иду и нахожу нужные мне ресурсы. Моя задача проста: решение этой проблемы должно быть в проде.

Это не значит, что я всё делаю сам или мне не нужна помощь. Нужна ещё как 🤣 Другое дело, что я не жду чьего-то пинка или знака свыше, а просто иду и нахожу ресурсы, которые нужны для решения задачи.

Чем больше и сложнее задачи, которые специалист может решать автономно, тем выше его грейд. Да, для этого нужны знания и опыт. Но даже самый крутой практик не сможет далеко пойти без умения работать самостоятельно.