NotCourse

Продуктовое мышление - залог успеха С начала года это стало прямо эгидой современного IT для бизнеса внутри. В такое время живём, когда просто хорошо писать код или делать автоматизации не просто недостаточно - оно уже не требуется. Бизнес вкусил разработку с агентами, бизнесу не хочется возвращаться к старому циклу. В целом, их можно понять, сейчас наделать фичу по архитектуре стоит ровно стоимость подписки на Claude/Codex/etc и несколько часов ожидания от идеи до прода максимум. Кому захочется опять устраивать долгие дебаты по архитектурным решениям/оценку спроектированого кода со всякими долгими планированиями внутри команды, когда проще всё сделать самому по готовой спецификации. Получается, что сейчас востребован совсем другой скиллсет, чем был ещё года два назад. Теперь балом правит умение видеть куда двигаться проекту, грамотно составленные доки под агентов и быстрые фичи. Кто-то скажет, мол, но это же говнокод, а бизнес парирует: "починка стоит тех же несколько минут и оплату подписки". Можно, конечно, бить себя пяткой в грудь, рассказывать какой ты классный инженер и как ты пишешь лаконичный и эффективный код, но реалии таковы, что по скорости разработки ты уже никогда не догонишь агенты. И до тех пор, пока подписка в месяц стоит дешевле, чем нанять сотрудника, который будет это делать за схожее с агентом время, инженер выигрывать не будет. Инженер и не выигрывает.

Тимлид из инженера - миф Работаешь ты такой инженером, хорошо работаешь, качественно, настоящий ремесленник - мастер своего дела. И тут чу, твой Тимлид покидает корабль. Откуда менеджмент берёт на эту роль нового? В большинстве случаев берусь самого опытного инженера и говорят «теперь ты тут вождя». И это в корне неправильно, потому что работа тимлида - менеджерская: онбординг новичков проводи, собесы проводи, ритуалы типа статусов, досок, планирований обеспечь. Твоя основная задача, как тимлида - обеспечить процесс работы команды так, чтобы твой продукт развивался успешно. Это абсолютно другой тип мышления, никак не связанный с тем, как хорошо ты решаешь инженерные задачи. Это продуктовое мышление. И про него вообще стоит сделать отдельную заметку, так как в современности ремесленничество в рамках работы на дядю вообще становится менее востребованным, но к этому мы придём в другой раз. Окей, проблема ясна, какое решение ты предлагаешь, умник? Во-первых, очевидное, посмотреть кто из сотрудников обладает необходимыми навыками: управление командой, управление процессами, продуктовое мышление. Три кита, которых надо выявить хоть у кого-то внутри команды, хотя бы стремление в эту сторону. Не нашли внутри? Не надо ставить абы-кого, хоть вон Петю, он больше всех работает в компании, он всё про продукт знает. Знать мало, я даже больше скажу, знать сам продукт необязательно. Надо понимать какие задачи он решает и кто твой клиент. Всё. Это база, с которой уже можно дальше развивать систему, строить гипотезы, разбираться в домене/ах, вырабатывать план на будущее и вести команду к этому будущему. Получается, что да, дорогие мои менеджеры, если внутри команды и компании таких нет - надо брать с улицы, без вариантов. Потому что если вы будете насиловать инженеров неинженерными задачами, которые им неинтересны, если они им неинтересны, то они от всей этой бессмысленной с их точки зрения карусели устанут и либо сольются из вашей компании в ближайшее время либо забьют на управленческую часть и в команде начнётся хаос. А чинить хаос впоследствии будет очень дорого. Чем дольше он использовался - тем дороже будет потом. И нет, я не говорю, что инженеры не нужны, об этом я скажу в следующий раз, когда мне захочется поплеваться кислотой. Я лишь говорю, что каждый человек может быть заточен под определённый тип задач и не надо думать, что если он успешен в решении одного типа, то он автоматически становится так же хорош и во всём остальном. Вообще не надо решать за человека что ему лучше самому, не надо навязывать человеку своё видение его будущего, это не сделает хорошо ни вам, как работодателю, ни ему, как работнику. Ещё и отношения испортите.

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

Ansible готов! К каждому видео есть репозиторий с кодом, который получился в рамках видео. К большинству видео я так же сделал задания для самопроверки в README.md файлах. Каждое видео это погружение на слой ниже: от "как запускать плейбук" до "как создавать свои модули", поэтому вы всегда можете остановиться на нужном вам и не идти дальше. Теперь по стоимостям, для boosty это 200 рублей за каждый ролик, но вы получаете его в бесконечный доступ. Либо можно оплатить подписку NotStudent за 400 рублей в месяц (до конца недели 3 человека могут получить бесплатно на 3 месяца, пишите в директ сообщения канала). У подписчиков так же есть возможность задавать вопросы в ЛС на бусти, я их буду копить месяц и делать там же стрим, где буду отвечать на них, запись будем сохранять там же с тем же уровнем доступа. У Patreon политика хуже, все ролики в доступ "навсегда" за 10 eur, каждый ролик отдельно по 3 eur, потому что ниже он сделать не даёт. Либо можно оплатить подписку за 5 eur в месяц. Пройти на boosty Пройти на patreon

Два ролика до конца выходных я добавить не успел, добавил только один, но зато он должен понравиться тем, кто ходил на онлайн лекции от меня. Потому что его я писал без сценария, просто вспоминая что можно использовать в плейбуках в виде параметров, как оно работает, прямо так же, как это было в онлайн лекциях. И как всегда со всеми примерами, с репозиторием в котором есть плейбук из самого видео и заданием для самоконтроля. Осталось ещё два ролика: "что такое Role?" и про коллекции с созданием модулей - после этого полный набор видеоматериалов по Ansible будет собран. Очень надеюсь, что первого марта сделаю пост о полном наборе. З.Ы. начиная с третьего ролика я ещё и фокус пофиксил, так что станет ещё приятнее смотреть.

Видео часть NotCourse началась Первые два видео уже в платном доступе на boosty и patreon: https://www.patreon.com/cw/NotOps https://boosty.to/notopsofficial Всё доступно по подписке NotStudent либо можно выкупить бесконечный доступ. К каждому ролику приложен репозиторий с тем, что я делал в видео, чтобы была возможность потыкать самим и понять что и как работает. Ну и самое вкусное, первые три человека, которые напишут мне до конца 20 февраля в личку на boosty получат три месяца бесплатного доступа. Стратегию назовём "три на три", буду делать так каждые три месяца.

Сегодня монтировал ролик по Ansible для NotCourse и решил вспомнить, а что, собственно, я бесплатно уже выкладывал за четыре года? И оказалось, что уже было целых семь материалов. Может, не так подробно, как планирую сделать в платной части, но для ознакомления - вполне достаточно. И про саму ансиболь и про плейбук и как модули работают, даже как на виндовые managed node пытаться запрыгнуть и что-то сделать. Поэтому, если что-то пропустили, то я собрал отдельный плейлист с ютуба для таких случаев: https://www.youtube.com/playlist?list=PLZAOfCpakq2JFuDNP9x415J4zGS4tKjsE

С небольшим запозданием выпускаю текстовую версию часового ролика. Она немного отличается от видео, слегка другая структура, другой язык. Так что теперь и любители почитать будут довольны. И с картинками. Patreon Boosty

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

Так, пора дать немного информации. Ролики для NotCourse всё ещё на монтаже, я об этом не забыл, всё идёт планомерно. Один для ютуба нарезан, туда нужно нарисовать графику, второй для boosty/patreon(он там будет бесплатными) режется, как только появляется свободное время. По пути, я начал прорабатывать архитектуру проекта, чтобы к теории можно было дать и практику, да ещё и чтобы проверки были и ждать никому не приходилось. Дизайн фронта уже размечен, сейчас самая большая головная боль это набор сервисов на бэке, которые придётся тщательно продумывать и писать. По плану, без сайта первые ролики везде я хочу выложить к концу февраля. Полный набор по Ansible ещё даже не снят, но думаю, что в фефрале же досниму и поделюсь с вами. На Ansible я останавливаться не буду, как минимум, есть CI/CD и kubernetes в планах. Сайт запустится, скорее-всего, только к концу года, работы много как с ним, так и на основной работе. О том, как оно всё будет взаимодействовать, как всё устроено и сколько нужно будет заносить - всё расскажу чуть позже, целый ролик запишу. Могу только сказать, что по итогу всем должно стать приятно.

«Мягкий босс/Жесткий босс» by Павел Сивожелезов. Книга, которая сначала тебе говорит о том, что не надо быть танком и переть без остановки, а потом ты все главы слушаешь о том, как кому-то в чём-то отказать. Главная тактика - задавать вопросы с правильным акцентом на ответ внутри него.

Настольная книга project-менеджера от Завертайлова только что дослушана. Хорошая книга, иногда опускается до совсем примитивов, но мне, как инженеру по сути, подошла идеально. Стоит читать когда вы уже работаете менеджером, чтобы сразу пробовать подходы. Много перечислений методов работы, много референсов в сторону других книг. Плюсы: всё понятно, по полочкам, от управления командой и жизненным циклом, до технического стека(если вы вдруг не из инженеров). Минусы: из-за большого количество перечислений по пунктам, на слух бывает тяжело воспринимать. Плюс, много апелляций к pdf приложению, которое я посмотреть не смог. И чтец очень часто криво читает технический английский и наши REST API превращается в ЭрИЭсТи ЭйПиАй.

Инструментальная перегрузка Все сталкивались с ней, даже если не задумывались об этом. Типичный пример: сидишь на очередном совещании и думаешь «а на черта это всё мне нужно?». Или даже лучше, количество технологий видели? А как там думскроллинг поживает? Мы поглощаем так много информации за один день, что это приводит к перенасыщению информацией и перегрузу когнитивных способностей. Это, кстати, одна из причин почему я пытаюсь сокращать свои тексты и не заваливать вас постами. Но стоп, а инструментальная-то тут причём? Дело в том, что я последнее время много читаю про управление и разные фреймворки, методики, подходы к тому, как надо правильно строить процессы внутри команды и в управлении продуктом. И я заметил одну особенность, в “менеджерском” словаре инструментов ни чуть не меньше, чем у разработчиков, но только неопытные управленцы внедряют в свою работу первый же инструмент, который им предложили.  Хороший менеджер не станет использовать то, что вот только стало популярным. Но у технических разработчиков и сопровождения этот паттерн ещё не развился. Например, во фронте, там прям чёрт ногу сломит и всем будто плевать, будем браться за задачу с тем, что у всех на слуху. “Оптимизация? Не, не слышали, фреймворк сам всё решит”. Спойлер, не решил. Думаете, так только там? Но нет же, пихают энсибл во все места, куда дотягиваются. Кубер используем везде, где его хоть как-то можно разместить, даже если кластер по швам трещит, а приложение - монолит с БД. “У нас всё scalable”. Тьфу. Это я к чему, не пихайте везде и всюду новое, лишь бы потрогать технологию. Но и сидеть на попе ровно с башем тоже не надо. Инструмент создают под конкретную задачу, поэтому и вы под свою задачу выбирайте инструменты. И думскроллить переставайте. Не поможет.

Мёртвый пень  Их можно найти и в топ-менеджменте и в среднем и даже на уровне простых исполнителей, но ты легко сможешь безошибочно опознать пень. Приглядись, сидит такой, невзрачный, прикидывается ветошью и внимательно слушает остальных. Это пень, да. Такие стараются не спорить, готовы пообещать выполнить что-угодно, но делать это не будут. Ну или будут до последнего тянуть с решением. Стать мёртвым пнём это постепенный процесс, по наблюдениям это связано с отсутствием желания меняться, изучать новое, когда человек уже измотал сам себя и ему хочется “доработать до пенсии”. Никто из нас не застрахован от такого и пока процесс двигается, человек всё сильнее врастает корнями в свою почву неизменчивости и всё меньше хочет перемен. С пнём на исполнителе ещё можно смириться, он “работает” над своей зоной, задачи настолько не критичные, насколько это возможно, но вот с руководителем… С ним тоже можно жить, но тогда и ты сам  превратишься в такой же пень. Будет команда пней, кайф. Есть и хорошая новость, этого можно избежать, но придётся над собой работать. Постоянно пробовать что-то новое, сомневаться в догматах и пытаться найти другие способы решения задач. В быту тоже придётся над собой работать. Не будьте пнями.

Осенний митап в офисе HFLabs обещает разобраться, почему больше данных не всегда значит лучше для бизнеса — полезно для тех, кто устал от бесконечных таблиц и графиков[1]. Тем временем ГК «Солар» выходит на рынок SIEM с продуктом, объединяющим SIEM и SOAR, и обещает до 40% экономии на внедрении, что особенно порадует банки, ритейл и металлургию на фоне растущего рынка в России[2]. А «Яндекс» задумался о выпуске умного кольца — видимо, чтобы доказать, что гаджеты могут быть ещё компактнее, хотя сделать это будет не так просто[3]. В общем, технологии не стоят на месте, а мы продолжаем наблюдать с лёгкой иронией. #AIHabrDigest

С 18 октября 2025 года пользователи в России столкнулись с проблемами голосовых звонков через FaceTime, что стало неожиданным «отпуском» для технологий Apple[1]. В то же время Amazon решил подкормить свои дата-центры атомной энергией, приобретя АЭС с 12 маломодульными реакторами Xe-100 мощностью 960 МВт — теперь ИИ питается не только электричеством, но и ядерной мощью[2]. Между тем, сотрудник OpenAI извинился за ошибочное приписывание GPT-5 решения нерешённых задач Эрдёша, уточнив, что модель лишь сопоставила старые публикации, а не сделала новые открытия[3]. В мире технологий даже ошибки и сбои порой выглядят как маленькие приключения. #AIHabrDigest

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

Менеджерские книги практически бесполезны На сегодня я прочитал/прослушал четыре книги и не могу сказать, что нашёл хоть какую-то практически полезную информацию. Да, есть несколько способов сгруппировать управленцев по стилю, есть книжки с советами, мол, не поддавайся на провокации и не продавливайся, если продавливают, есть и совсем труха из разряда "делай хорошо, плохо не делай, особенно, если если команде плохо, то сделай чтобы им стало хорошо". Но кажется, будто вся эта информация находится на поверхности. Серьёзно, самое полезное это только классификации типов команд и типов управления, причём, выбрать можете абсолютно любую из них, которые нравятся лично вам и вполне себе спокойно жить, управлять и не переживать по поводу. Я в своё время думал, что в методологиях управления проектами много воды, как же я ошибался. С другой стороны, я себе очень слабо представляю как тебе вообще книжка может помочь решить конкретную проблему в конкретной команде. Тем страшнее, конечно же, понимать, что есть менеджеры, которые читают эти книги, как инструкции к применению и пихают все методики в свою работу, лишь бы сделать всё эффективно и позитивно. И абсолютно наплевать что там думает сама команда по этому поводу. Самое интересное, что я не вижу чтобы кто-то особо делился негативным опытом, своими факапами, а ведь по ним проще всего понять, как делать точно не надо. И вот я думаю, не запустить ли мне небольшой цикл записок о том, с чем таким сталкивался я за свой опыт? И как "менеджер" и как рядовой исполнитель? Есть потребность такого контента? Этот контент не будет попадать в NotOps, так что если хотите его прочитать - подписывайтесь на канал