Agile *

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

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

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

Дальше — развёрнутый ответ. Ты прав в каждом пункте. Но в систему зашёл фактор, который многие считывают как угрозу, а он открывает дверь — в том числе тому самому менеджеру. Расскажу, какую.

Рудольф

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

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

Почему это работало

Две причины, и обе про устройство среды.

Первая — насиженное место. Руководитель сидит на месте годами, структура меняется раз в пятилетку. В такой среде предсказуемость дороже инициативы. Рудольф предсказуем, на него можно опереться — и это ценное свойство, а не дефект.

Больше всего мне не нравятся короткие созвоны. Когда мне говорят: «У меня есть окно завтра в 11:30, давай созвонимся на 10 минут». Для собеседника это просто очередной созвон, которых у него десятки за день. А для меня событие, вокруг которого начинает строиться весь день.

За годы работы в project и product management  мне  довелось  работать  с  проектами  самых  разных типов: от государственных и образовательных инициатив до сложных IT-продуктов  и создания SaaS-платформ.

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

Waterfall и Agile уже много лет остаются двумя основными методологиями в индустрии. О них написаны сотни книг и статей. 

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

Когда Waterfall действительно работает

Традиционная Waterfall-модель  строится вокруг  последовательных  этапов:  сбор требований → проектирование → разработка → тестирование → внедрение.

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

Меня зовут Николай Лямин. В IT я уже 25 лет, в SOFROS -  с 2023 года. За это время успел поработать с системной интеграцией, электронным документооборотом, построением крупных команд поддержки и мониторинга для высоконагруженных продуктов ЭДО и электронного факторинга. Работал как с российским, так и с европейским рынком, а также участвовал в развитии решений для электронной коммерции в сегментах FMCG и DIY.

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

Реальность оказалась другой – модель начала ломаться почти сразу.

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

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

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

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

Где-то с 2021 года программистам обещают, что: ИИ оставит их без работы, 30% мест исчезнут, дипломы обесценятся и вообще все станут бесполезными. В декабре 2025 это уже стало походить на правду, теперь, какой-нибудь Claude, действительно, выдает рыночный результат. А если сравнить стоимость генерации за ноль рублей с любой оплатой труда, то тут победить ИИ - крайне сложно.

Что касается профессий уровня аналитиков, то джуны не нужны, по моим ощущениям, с 2023 года, а на текущий момент вообще аналитики не особо нужны. Тут уже, к сожалению, так как в моей профессии присутствует слово аналитик.

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

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

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

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

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

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

Почему Agile‑команды скатываются в неконтролируемый хаос, а проекты на Waterfall годами пилят никому не нужный продукт? Спойлер: проблема не в методологиях, а в нас самих. Вы узнаете, как сильные команды совмещают лучшие практики обоих миров, почему Contract‑First и Trunk‑based Development спасают даже в Agile.

Из моего отдела ушел ключевой специалист. Унес три года контекста. Я начал разбираться и обнаружил, что инструментов для измерения человеческой стоимости задачи не существует. Пришлось делать свой. Через полгода текучесть в команде упала до 10%.

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

Внедрили MES, а производство как работало, так и работает? Интегратор обещал прозрачность, а руководство предприятия получило гору отписок в духе «некогда сканировать»? Разбираемся, что с этим делать.

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

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

Это не просто ощущение. По данным Microsoft, у перегруженных специалистов переключение внимания происходит каждые две минуты, а 60% встреч — внеплановые. Atlassian дополняет: 65% сотрудников считают важнее быстро ответить на сообщение, чем продвинуться по задаче.

В сумме это приводит к довольно неприятному выводу: проектное управление постепенно умирает.

### Cursor как общая среда для заказчика и разработчика

Google влил в Anthropic сорок миллиардов, Cursor "собрали" браузер на GPT-5.2, а я начал писать код совместно с заказчиком.

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

А что если показать заказчику как работать с Cursor и использовать ИИ-агентов?

Есть клиент. Он предприниматель и у него бизнес в недвижимости, при этом он не программист, - он не пишет backend, не проектирует схемы БД, но он очень хорошо знает своё дело и это важнее, чем кажется.

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

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

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

В этой статье я пробую сформулировать облегчённую методологию разработки для кросс-функциональных команд. Центральная идея — явный handover: задача не переходит молча, каждая передача — это осознанное действие с контекстом. По идее, методология должна одинаково работать, когда в команде 3 человека, 15 человек, или когда один или несколько из «участников» — AI-агенты. Это концепт, идея, черновик, открытый для критики и комментариев.

---

Откуда это взялось

Я руковожу центром разработки клиентских и аналитических решений — 50+ человек в семи кросс-функциональных командах с разными стеками. Аналитики, разработчики, QA, DevOps, сопровождение — всё в одной цепочке, от детализации требований до эксплуатации.

За несколько лет мы перепробовали стандартный набор: Scrum, Kanban, Scrumban. Каждый из них решал что-то своё, но во всех трёх я обнаружил одинаковый пробел.

Ни одна из методологий не отвечает на вопрос: что происходит, когда задача переходит от одной роли к другой?

Вот разработчик написал код и поставил статус «Готово к тестированию». Что дальше? Тестировщик это видит? Знает контекст? Понимает, что конкретно нужно проверить? А если тестировщик заболел — задача просто лежит? Кто за это отвечает?

Ни Scrum, ни Kanban на эти вопросы не отвечают. Они описывают итерации, доски, роли — но не сам момент передачи. А именно там живёт большинство операционных потерь.

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

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

Тогда, стоит напомнить, что магия вне Хогвардса запрещена 🙃

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

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

Раньше можно было приписать «Agile», и добавить x100 к стоимости, сейчас лучше выбрать «AI». Хе‑хе.

Штат раздувается. Роли множатся. Ответственность размывается. Это как поменять море на океан, но продолжать плыть с дыркой в лодке.

Самое неприятное: вы ещё и платите за это 🙂

Почему одни User Story работают как часы, а другие становятся источником бесконечных багов и ночных звонков? За годы работы в FinTech собрал коллекцию типичных ошибок, из‑за которых команды теряют драгоценное время. В статье — живые кейсы, наглядные диаграммы, разбор INVEST и практики Three Amigos, которые снижают число дефектов. Рассмотрим, как превратить сырую идею в зрелую User Story с чёткими критериями приёмки и нефункциональными требованиями.

Мнение. Предложение к обсуждению, а не новая догма.

Story points долго были удобным способом оценивать сложность задач в разработке. Но в 2026 году всё больше работы делается не только инженером, но и в связке с LLM: генерация кода, тестов, документации, рефакторинг, разбор ошибок. Возникает вопрос: может ли рядом со story points появиться новая метрика — neuro points, отражающая AI-итеративность решения задачи? В статье предлагаю этот подход как гипотезу для обсуждения и разбираю, зачем он вообще может понадобиться командам, которые уже активно используют нейросети в рабочих процессах.

Данные перенесены, workflow настроен, всех обучили. А через неделю — саботаж, снова задачи в Excel и бунтующий разработчик, у которого «вообще-то в Jira все нормально было»