Agile *

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

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

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

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

Привет! Меня зовут Света и я — project manager. Или, по мнению разработчиков, человек, который превращает «надо подумать» в «обещали к пятнице».

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

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

То есть уже понятно, что:

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

Я Ирина, в Блоке ИТ-развития инвестиционного бизнеса РСХБ.Цифра помогаю ИТ-командам доставлять ценность бизнесу, содействую оптимизации процессов, повышению эффективности и сплоченности команд, продвигаю Agile-практики.

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

Управлять тимлидами — это не раздавать задачи и проверять сроки. Это выстраивать среду, где сильные технические лидеры могут проявить себя без микроменеджмента. В статье разберем какие ошибки совершают 90% руководителей, почему контроль убивает инициативу, и как перейти к системному лидерству с помощью OKR, DORA-метрик и роли Delivery Manager. Без воды, с конкретными кейсами и схемами!

Когда ко мне обратился клиент, он сформулировал проблему примерно так: «Вся информация есть, но связана только у меня в голове».

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

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

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

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

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

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

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

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

Здравствуйте, я – менеджер продукта в компании «СИБИНТЕК». В прошлом году самому известному и популярному фреймворку для команд, создающих функционально сложные продукты, исполнилось 30 лет. Да, вы правы, речь про Scrum. Несмотря на то, что Scrum про скорость, про разработку короткими итерациями с постоянной обратной связью, сам фреймворк почти не развивается. Мы до сих пор пользуемся гайдом пятилетней давности. И для новых адептов данного подхода может показаться, что Scrum был всегда таким, как он описан в Scrum Guide 2020. И многим даже не приходит в голову посмотреть эволюцию его развития. Например, проанализировать, а что поменялось с прошлого издания 2017 года и, главное, почему. А проследив эти изменения, можно понять ключевые моменты, на которые может быть стоит сфокусироваться современным Scrum-командам. Давайте попробуем это сделать.

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

Бразильский цифровой банк Nubank за 12 лет прошёл путь от 12 клиентов до 131 миллиона, став крупнейшим цифровым банком мира за пределами Азии. Это экспериментальное доказательство того, что правильный выбор архитектуры, языка и организационной структуры может создать экономическое чудо. 131 миллион клиентов и $70 миллиардов капитализации. $2,9 миллиарда чистой прибыли за 2025 год. Рентабельность капитала (ROE) 33%. И всё это без единого физического отделения. Все данные я взял из открытых источников и в Бразилии пока не был, так что можете сами проверить.

Давайте разберём, как именно это получилось.

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

Суть проекта в котором я работал, была в следующем. Была некая БД c доступом через ORM EntityFramework и нужно было через некую многослойную архитектуру отдавать срезы запросов к сущностям через REST. Сущностей было порядка 2-3 десятков. Вся цепочка проброса по логике затрагивала несколько десятков файлов. Было создано несколько десятков тасков под каждую сущность и под каждого работника давалась задача портирования - по сути копи паст кода референсной сущности по всем этим 3-м десяткам файлов. С юнит, регрессионными тестами и всем остальным.

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

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

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

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

Меня это достало. Заканчиваю марафон-сессию с Claude или Codex, ощущение, что гора работы сделана, а доска проекта все так же показывает Not Started. Тайм-трекинг? Какой тайм-трекинг. Разрыв между реальной работой и тем, как выглядит проект, стал просто нелепым.

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

За 6 лет работы продакт-менеджером в разных решениях для автоматизации проектов я видел одно и то же много раз: выбирают систему по чек-листу — «есть Гант? есть ресурсы? есть бюджеты? берем!». Через n месяцев оказывается, что не так уж и важен сам факт наличия функций. Невозможность адаптировать продукт под реальные процессы — вот что заслоняет собой все остальное.

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

В статье вы найдете:

— еще одну неприятную историю о ведении проектов — с подсчетом денег в чужих карманах; 

— 4 проблемы жестких систем и их решения из моей собственной практики;

— разбор трансформации low-code Waterfall инструмента в Agile всего за неделю неспешной работы.

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

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

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

Техническое решение: Установка камер на уровне лица с углом обзора 120°, обеспечивающих:

Видимость лиц при входе/выходе

Точность до 99.5%+

Сохранение соответствия DPDPA (90 дней хранения для отладки, затем удаление изображений)

Экономическое обоснование (для 56 автобусов):

Стоимость установки: 23.7 млн₽

Дополнительная защита: 12–20 млн₽/год

ROI: 51–84% годовых

Срок окупаемости: 14–23 месяца

Но главное: защита от системных рисков (штрафы, репутация, мошенничество)

Статус: Веду переговоры по интеграции с компанией, которая предоставляет доступ к системам электробусов. Это позволит нам расширить покрытие и снизить затраты на установку.

Понедельник. Спланировали неделю, к среде 90% задач не тронуты, завершаете в огне. Знакомо?

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