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

В этой главе — не очередной список фреймворков, а философия: взгляд на продукт как на систему, эмпатия как навык и честный разговор о том, что мы часто боимся не знать.
Да, будет и про CJM, и про юнит-экономику — но с фокусом на смыслы, а не на термины.

Привет, Хабр! Меня зовут Алексей Кузин и я стажер в МТС Web Services. В этом материале я расскажу про свой первый год обучения по совместной программе МТС и ВШЭ «Исследования и предпринимательство в искусственном интеллекте». 

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

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

В 2025 году вопрос полноценной генерации продуктового кода с помощью LLM («вайб-кодинг») становится все более актуальным, но при этом остается и достаточно дискуссионным: насколько такие подходы вообще применимы в реальных проектах, действительно ли они сокращают время и стоимость разработки, и что происходит с тестируемостью и поддержкой такого кода в долгосрочной перспективе?

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

Моя мотивация была проста: попробовать выстроить полноценный продуктовый backend для нетривиального телеграм-бота с функциями агента (планированием, напоминаниями, памятью и проактивным поведением, возможностью дальнейшей расширяемости и интеграции сторонних сервисов), при этом — не писать руками ни строчки кода. Чтобы человек участвовал только как архитектор и асессор, а все проектирование и реализация шли через промпты в специализированные IDE-агенты (Cursor, Copilot, Codex, Zed) и LLM (как доступные через API/CLI, так и в «пользовательской» продуктовой обвязке).

Привет, Хабр!

Сегодня мы рассмотрим, как создать собственный DHCP‑сервер на Python. Суть сервера проста — он динамически раздаёт IP‑адреса устройствам в сети, избавляя нас от головной боли статической конфигурации.

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

— Привет! Подскажи, пожалуйста, какой срок по этой задаче?

— 2 дня и 1000 долларов

— А почему тысяча долларов? Мы же договаривались на 500?

— Когда мы договаривались, ты не спрашивал сроки

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

Разбираемся, почему современные LLM, несмотря на всю свою мощь, остаются «философскими зомби», и какая архитектурная деталь могла бы это изменить.

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

Привет, меня зовут Павел, я программист-эксперт в отделе разработки серверных решений ЮMoney. Это не первая моя статья для блога компании на Хабре — уже выходило два текста о том, как и во что эволюционировали наши конечные автоматы (Часть 1 и Часть 2), вы их очень тепло приняли. В этот раз речь пойдёт про неожиданные проявления моего увлечения программированием. Когда-то у меня получилось сделать GPS-трекер для соревнований по спортивному ориентированию. Хочу поделиться этой историей и рассказать, во что этот GPS-трекер превратился за 17 лет.

В начале карьеры проектирование любой формы казалось мне очень простой и понятной задачей. Особенно когда речь шла о чём-то банальном и незначительном, вроде обратной связи на сайте. А что — выяснил, какие нужны данные и для чего, накидал поля с подписями, приделал кнопку — и готово! На всё про всё — пять минут. Пустяки! Или нет?

— Я не продаю часы, — ответил я.

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

— Я обычно оцениваю работу под ключ. Часовой ставки у меня нет.

— У всех есть такая ставка, хотят они того или нет.

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

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

Почему же я сразу не назвал своей часовой ставки?

Привет, Хабр! Меня зовут Данила, мне 21 год, и за последние 2,5 года я успел поработать в роли разработчика программного обеспечения для встраиваемых систем — в основном на базе STM32. В этой статье я хочу поделиться тем, как я вообще пришёл в эту сферу, с чего начинал, какие грабли собрал и какие выводы сделал по пути.

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

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

«Быть закупщиком — это не дать Гарри купить очередные 1000 карандашей»

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

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

Эффективное управление ИТ-командой на примере взаимодействия популярных дирижеров и их оркестров. От Герберта фон Караяна до Леонарда Бернстайна: как принципы дирижирования помогут вам руководить ИТ-командой.

Что если создать мобильное приложение, не зная ни строчки кода на Swift? Добро пожаловать в мир вайбкодинга — нового стиля программирования «по настроению», где естественный язык и LLM заменяют синтаксис и компиляторы.

Во второй части выступления Андрея Карпатого мы также поговорим о новом типе «пользователей» — LLM‑агентах («духах людей») и о том, как адаптировать нашу инфраструктуру (документацию, API, сайты) для их удобства с помощью... llms.txt. Готовы ли вы кодить «в потоке» и строить для нечеловеческих интеллектов?

Привет! Я давно в IT, настолько что верстал еще под IE6. Начинал ещё со школы: сервера Diablo II, боты mIRC, карты Warcraft III на JASS, код, форумы, общение и дикий, нескончаемый интерес. Без какого-либо понимания, что я делаю и куда меня это приведёт.

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

Заваривайте чай, расскажу вам свою историю как я попал в IT и вот уже лет 13 тут, приятного прочтения

Этот роадмэп мы начали собирать ещё в прошлом году вместе с нашей командой мидл-бэкендеров. Хотелось системно оформить весь стек технологий, с которым реально работает современный backend-разработчик на Python — от базовых тем вроде HTTP и SQL до CI/CD, микросервисной архитектуры, Kubernetes, облаков, безопасности и брокеров сообщений.

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

Machine Learning и Data Science — это одни из самых популярных и востребованных направлений в IT. Но вместе с этим — они и одни из самых сложных для входа. Здесь огромное количество тем, инструментов, библиотек, подходов и постоянно появляющихся технологий.

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

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

Всем привет!

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

Привет, Хабр! Я — Вера Осолодкина, аккаунт-директор в диджитал-продакшене Далее. Сегодня рассказываю о том, как удачно финалить проекты и спать себе спокойно, а еще делюсь своим чек-листом в конце статьи.  

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

Разберем, из чего состоит этот процесс.