Управление разработкой *

Это пародия... на многое

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

Большинство историй про AI‑инструменты выглядят одинаково: человек открывает Cursor, за выходные собирает SaaS, выкладывает скриншот MRR и дальше объясняет, что главное — не думать, а быстро валидировать гипотезы. Рынок не ждёт, окно возможностей закрывается, конкуренты уже деплоят.

Артём пошёл в другую сторону. Он заметил, что после Cursor у многих команд появилась новая проблема: код пишется быстрее, чем его успевают понимать. За выходные он собрал альтернативу Cursor, которая на любой промпт отвечает: «Сначала сформулируйте задачу человеческими словами». Через 8 месяцев Stopilot вышел на 1,29 млн рублей в месяц.

Он сам расскажет, как это было.

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

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

Топ-менеджеры ГК «Первый Трест» теперь уходят с работы на два часа раньше, компания экономит до 5–7 % оборота в год, а 50 000 задач по девяти жилым комплексам больше не теряются. Застройщик из Уфы рассказал, как добился этого.

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

Англоязычные инженеры называют эту обвязку harness. Это контур, в котором живёт модель: системный промпт, инструменты, контекст, скиллы, хуки, разрешения и память. Без него даже флагманский Claude или Codex работает как экскаватор без рычагов — мощность есть, использовать нечем. У русского аналога одного короткого слова пока нет, поэтому ниже — harness и обвязка вперемешку.

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

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

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

Если для оценки фич индустрия создала десятки методов (от RICE до MoSCoW и WSJF), то с багами все скромнее: общепринятых подходов сравнительно немного,  и нам в итоге они не подошли.

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

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

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

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

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

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

Привет, Хабр! Меня зовут Сергей Чекменев, я тимлид ML-команды развития массового промо и монетизации центра развития ML-решений клиентской персонализации в MAGNIT TECH. В этой статье расскажу про наш MVP-проект PromoPersona – сервис автоматической генерации персонализированных промо-коллажей: что именно мы построили с технической точки зрения, как интегрировали модель FLUX.2 и почему именно ее,  и какие инженерные задачи пришлось решить.

Автор более 30 лет в ИТ. Начинал инженером-разработчиком в крупном банке, затем несколько лет в международном вендоре консультантом и функциональным архитектором внедрения известной ERP системы. Последние 25 лет в крупной российской компании выступаю в различных проектных ролях на проектах у заказчиков: архитектором, функциональным руководителем, системным аналитиком, руководителем проектов, директором проектов внедрения различных ERP.

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

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

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

Мое хобби – фундаментальная физика. Поразмышлять на тему фундаментального и монументального отлично получается по утрам в Измайловском парке во время прогулки с собачкой, либо по дороге на работу/с работы. В вагонах московского метро ничто не отвлекает от чтения текстов трудов Ньютона или Эйнштейна. 

Какие чувства возникают у вас при прочтении такого предложения?

«ИИ-агенты — будущее разработки ПО. Нам больше не нужны разработчики, замедляющие прогресс бизнеса».

Если вы сеньор-разработчик и считаете, что оно верное, то у меня появляются подозрения о вашем опыте (ниже я объясню, почему).

Но если вы не сеньор-разработчик, то я считаю, что вы правы.

А? Что здесь происходит?

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

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

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

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

Как же так? Чья точка зрения верна? И в чём причина такого расхождения мнений?

С осени прошлого года идет стремительный переход от использования ИИ в качестве личного помощника к встраиванию ИИ-агентов в команду и передачи им определенных задач – переход от вайбкодинга к agentic engineering. Задача, как это часто бывает, решается экспериментально, методом проб и ошибок, потому что организовывать разделение труда даже между людьми в команде тимлидов, да и большинство руководителей следующих уровней не учили. А в случае ИИ-агентом ситуация осложняется тем, что это – не просто онбординг способного новичка, который не знает контекста проекта: у этого новичка есть набор сильных сторон, таких как быстрый доступ к знаниям из любых предметных областей, бесконфликтность и готовность к исправлению ошибок, в сочетании со слабыми сторонами, например, склонности упрощать задачу или пользоваться первым попавшимся попсовым знанием вместо профессионального.

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

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

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

А что может Opus 4.7 с контекстным окном в миллион?

Я сравнил Codex 5.3, Claude Opus 4.6 и GPT-5.5 на реальном многомодульном Java-монолите: скопировал проект в отдельные ветки, дал агентам похожие задачи и прогнал их через цикл правок, ревью и e2e-тестов.

Результат: чем дешевле - тем лучше результат.

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

Всем привет, это команда продукта SimpleOne SDLC. Поговорим о вещи, которую в командах обычно не обсуждают вслух — о бэклоге дефектов, который никто не разгребает.

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

Реестр рисков в таком случае превращается не в инструмент управления проектом, а в кладбище тревожных мыслей. А что вообще такое Риск? 

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

«Разработчики срывают сроки, думаю нужен тренинг по тайм‑менеджменту». Не нужен.

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

Если начать с тренинга — деньги и время будут потрачены впустую. Сначала надо понять, чему на самом деле учить. А иногда — учить ли вообще.

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

Всем привет, меня зовут Олег Джулаев, я автор Projecto.
Для этого обзора я, во-первых, поискал неочевидные варианты, которые не всегда на виду – многие сервисы переходят из обзора в обзор. Благо рынок систем управления проектов даже в РФ насыщен хорошо. А во-вторых, предметно посчитал, во сколько обойдется обслуживание небольшой команды – я взял ориентир на 20 человек. Так сравнение будет действительно справедливым и объективным. Бюджет – это всегда один из важных факторов при выборе, как ни крути. В конце есть сводная таблица всех инструментов.