Agile *

У каждого успешного 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% задач не тронуты, завершаете в огне. Знакомо?

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

Доброго дня

В 2011 году у нас была идея сделать на web онлайн mind-web доску и недавно идея воплотилась в реальность.

Название приложения — «Наброски», или WebSketch, ссылка.

Здравствуйте всем, я – менеджер продукта в компании «СИБИНТЕК». Если вы решите изучать Agile‑подходы самостоятельно или запишитесь на тренинг, то рано или поздно столкнетесь с фреймворком Кеневин (Cynefin). Он, как и фреймворк Scrum, прост в понимании и достаточно сложен для совершенного овладения. Но, возможно, это как закон тяготения Ньютона: вы его не применяете в повседневной жизни, а просто действуете соразмерно этому закону. Кстати, «cynefin» – валлийское слово, которое переводится как «среда обитания».

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

Автор фреймворка предполагает в своей модели, что реальный мир вокруг нас – это множество взаимосвязанных систем, в которых действуют различные агенты‑модуляторы: люди, компании, регламенты, процессы, события и др., которые постоянно взаимодействуют между собой. Количество и характер их взаимодействий определяет сложность каждой из систем. Все эти системы автор делит на четыре типа (домена): упорядоченные простые, упорядоченные сложные, комплексные и хаотические. В каждом из этих доменов предлагается своя модель принятия решений. Нужно сразу сказать, что Кеневин – это не столько категоризационная, сколько смыслообразующая модель. Это аналитический фреймворк.

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

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

Если тема управления знаниями и задачами в Obsidian вам близка - заглядывайте в мой тг-канал, там я разбираю подобные вещи регулярно.

TL;DR перевода статьи Boris Tane: SDLC is dead.

SDLC больше нет. AI-агенты не ускорили привычный жизненный цикл разработки, они его схлопнули.

- Agile-ритуалы мертвы. Планирование спринтов, оценки в story points, релизные поезда и многодневные ожидания аппрувов в PR — всё это пережитки прошлого.

- Все этапы слились воедино. Сбор требований, system design, написание кода и тестов происходят одновременно — в реальном времени и в диалоге с агентом.

- Code Review — это новый луддизм. Машина генерирует 500 PR в день, человек физически не может их проверить. Код должен лететь прямо в main под прикрытием автотестов, feature flags и хорошо настроенного observability.

Новый жизненный цикл — это узкая петля: Intent (Намерение) → Build (Создание) → Observe (Наблюдение).

Привет, Хабр! Меня зовут Елизавета, я скрам-мастер стрима ДБО (веб-версия дистанционного банковского обслуживания) для банков в команде РСХБ.Цифра. Выстраиваю процессы на основе человекоцентричного подхода, помогаю команде раскрывать потенциал. В этом материале хочу поделиться с вами историей о том, как мы превратили обычную задачу по формированию команд в приятный процесс. Да, это возможно! Расскажу не только о методиках, но и человеческих взаимоотношениях, где психология — лучший друг программистов и тимлидов, которые объединяются ради создания продукта в финтехе.

Мы едим хлеб, а не смотрим на замешивание теста

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

Мы должны руководствоваться достижением цели, а не удобством процессов.

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

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

Как руководитель отдела ИИ с опытом внедрения решений в холдингах на 15 000+ сотрудников, я вижу, что только системный инженерный подход спасает проекты от превращения в «дорогой гараж».

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

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

Большинство команд, которые внедрили канбан, на самом деле просто создали доску с колонками. Перетащили стикеры слева направо — и решили, что на этом все. Но канбан — это не формат доски, а метод управления потоком работы.

Мы тут решили дотошно разобраться и рассказать, из чего он состоит на практике: инструменты, принципы, WIP-лимиты и метрики. 

В посте рассмотрим модель эффективной команды под названием "Учпочмак".

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

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