Внешний аудит: методология, роли, рынок

Дата аудита: 13 июля 2026. Документ фиксирует результаты внешнего аудита платформы: сопоставление реализованной функциональности с известными проблемами методологий Scrum, Kanban и Scrumban, оценку продукта с позиции четырёх ролей, анализ конкурентного окружения и приоритетный порядок точечных доработок. Аудит выполнен по трём источникам: первоисточники и практические разборы методологий, публичные обсуждения болей пользователей коммерческих трекеров (Reddit, Хабр, vc.ru, Scrum.org), сверка каждого вывода с фактическим состоянием кодовой базы.

Результаты на 13 июля 2026

Что реализовано

Платформа вышла за пределы базового Kanban-ядра и покрывает полный Scrumban-контур:

• Kanban-ядро: доски, колонки, WIP-лимиты, классы обслуживания (включая expedite с обходом лимита), SLE и aging WIP, replenishment, принудительный перенос через лимит с обязательной причиной.
• Scrum-контур: спринты с полным жизненным циклом (планирование, старт, закрытие с carry-over решениями по каждой незавершённой задаче), трёхшаговый мастер создания с вероятностным прогнозом на этапе планирования, burndown, capacity.
• Церемонии: дайджест для дейли с возрастными корзинами задач, ретроспектива с тремя колонками и конвертацией пунктов в исполняемые задачи, неизменяемые отчёты спринта с экспортом в CSV/JSON.
• Математика: CPM и data-driven PERT по сети зависимостей, Монте-Карло по сети и по throughput, рекомендации WIP-лимитов по закону Литтла, журнал прогнозов с калибровкой «прогноз vs факт».
• Симулятор: what-if сценарии с транзакционным применением и проверкой устаревания, песочница на демонстрационных данных.
• Инфраструктура процессов: event-sourced журналы (task_events, sprint_events), перенос дат активного спринта только с указанием причины, лента активности спринта в реальном времени.

Количественно (сверено с кодом на дату аудита): 124 HTTP-эндпоинта, 28 сервисов бизнес-логики, 20 файлов схемы БД, 37 SQL-миграций, 41 файл тестов. Мультитенантность обеспечивается Row-Level Security на уровне PostgreSQL.

Что проанализировано

Проведён разбор пяти системных проблем методологий, подтверждаемых как исследованиями, так и практикой команд. Для каждой определено: закрывает ли её Такт уже сейчас, и какой показатель нужен для полного закрытия.

Проблемы методологий и позиция Такта

Проблема 1. Дейли как «театр статусов»

Самая частая претензия разработчиков к Scrum: стендап вырождается в отчёт менеджеру в формате «что делал, что будешь делать». Участники перестают говорить о рисках открыто, адаптации плана не происходит. Scrum.org прямо классифицирует статус-формат дейли как искажение методологии; разбор типовых причин недовольства приводит Zen Ex Machina.

Состояние в Такте. Реализован дайджест доски для дейли с возрастными корзинами задач: фундамент паттерна «walk the board», при котором обсуждаются задачи справа налево, а не люди по кругу. Задача, находящаяся в колонке дольше нормы, сама становится темой обсуждения.

Целевой показатель. Явный режим последовательного прохода доски: поток задач от Done к Backlog с подсветкой возраста относительно SLE и фиксацией статуса обсуждения. Дейли структурируется инструментом, а не дисциплиной ведущего.

Проблема 2. Пункты ретроспективы не выполняются

По данным опросов, только 35% команд стабильно закрывают action items ретроспектив; по другим оценкам, до 70–80% осмысленных пунктов не доходят до внедрения. Причины: пункты без владельца, слишком крупный масштаб, отсутствие системы отслеживания. Практика показывает, что возврат к пунктам прошлой ретроспективы в начале следующей поднимает долю выполненных пунктов на десятки процентов.

Состояние в Такте. Ретроспектива с конвертацией пункта в задачу реализована: пункт получает владельца, срок и место на доске, то есть перестаёт быть записью в протоколе.

Целевой показатель. Замыкание цикла: при открытии ретроспективы нового спринта система первым блоком показывает пункты прошлой ретроспективы и их фактический статус (дошли ли конвертированные задачи до Done), а в отчёте спринта появляется метрика retro follow-through rate. Данные для этого уже находятся в БД; доработка не требует изменений схемы.

Проблема 3. WIP-лимиты не выдерживают давления

Типовое возражение командам, внедряющим Kanban: «мы не можем блокировать входящую работу». Под давлением заинтересованных сторон лимиты срываются, при том что вся система вытягивания держится именно на этом ограничении; подборку практических наблюдений приводит Yuval Yeret.

Состояние в Такте. Реализованы рекомендации WIP-лимитов по закону Литтла с объяснением формулы, класс обслуживания expedite (легальный обход лимита по определению класса) и принудительный перенос через лимит, доступный только Скрам-мастеру и только с указанием причины, которая записывается в журнал событий.

Целевой показатель. Принцип «не запрет, а подотчётность» доводится до конца: сводка превышений лимита за спринт (сколько раз, по каким причинам, суммарная длительность превышения) выводится в отчёт спринта и в ретроспективу, а политика «один expedite одновременно» становится системным ограничением по умолчанию.

Проблема 4. Scrumban теряет дисциплину

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

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

Целевой показатель. Величина отклонения от базового плана (schedule variance: разница между датой окончания, зафиксированной на старте спринта, и фактической) выводится в отчёт спринта. Базовая дата уже фиксируется в событии старта спринта; требуется только её использование в отчёте. Это связывает механику переноса с аппаратом сетевого планирования (baseline vs actual).

Проблема 5. Прогнозы, которым не доверяют

Команды ценят вероятностные прогнозы на исторических данных: лидер ниши flow-аналитики строит именно Монте-Карло прогнозы на фактическом throughput. Слабое место всего класса инструментов: ни один не показывает пользователю, насколько его собственные прошлые прогнозы сбылись. Прогноз без истории ошибок воспринимается как гадание.

Состояние в Такте. Журнал прогнозов реализован: ежедневные и привязанные к жизненному циклу снапшоты прогнозов сохраняются, страница аналитики показывает калибровку «прогноз vs факт» и сходимость прогноза по мере течения спринта.

Целевой показатель. Точность прогнозов выводится первым классом в отчёт спринта: «прогноз на старте, факт, ошибка P50». Честная демонстрация собственной ошибки: уникальное на рынке свойство и одновременно материал валидации математического ядра.

Оценка по ролям

Участник команды

Сильные стороны. Полнота карточки задачи выше типичной для стадии MVP: комментарии с упоминаниями, чек-листы, несколько исполнителей, зависимости, подзадачи и эпики, учёт времени, классы обслуживания. Дайджест для дейли, лента активности, обновления в реальном времени без перезагрузки.

Дефициты. Отсутствует агрегированное представление «мои задачи по всем доскам» с ответом на вопрос «что мне делать сегодня» за одно действие. Отсутствуют короткие человекочитаемые идентификаторы задач: UUID невозможно назвать голосом на созвоне или упомянуть в сообщении. Скорость взаимодействия (быстрое создание задачи с клавиатуры, командная палитра) уступает эталону сегмента.

Скрам-мастер

Сильные стороны. Наиболее развитая роль продукта, что соответствует позиционированию (Скрам-мастер как первичная персона). Мастер создания спринта с вероятностным прогнозом до старта, what-if симулятор со сценариями, полный набор flow-аналитики (CFD, время цикла, throughput, Монте-Карло, рекомендации WIP), неизменяемые отчёты, ретроспектива с исполняемыми пунктами, дайджест для дейли. Ролевая модель передаёт Скрам-мастеру владение дисциплиной потока: колонки, WIP-лимиты, SLE, replenishment, принудительные переносы.

Дефициты. Отсутствует сводный экран «здоровье потока»: задачи старше P85 в колонке, заблокированные задачи с длительностью блокировки, превышения WIP, дрейф прогноза собираются с разных страниц. Перцентильные оповещения («задача в Review дольше 90% исторических») доставляются не проактивно.

Администратор команды

Сильные стороны. Пятиуровневая ролевая модель с наследованием, проверяемая на уровне сервисов и на уровне БД (RLS), приглашения по magic-link, управление составом и ролями, журнал активности рабочего пространства, сводные отчёты.

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

Разработчик

Дефициты. Связь задач с кодом (ветка, коммит, merge request) отсутствует: интеграция с GitFlic запланирована как отдельный столп продукта, её отсутствие на текущей стадии соответствует roadmap. Промежуточный шаг до полной интеграции: короткие идентификаторы задач, пригодные для упоминания в сообщениях коммитов.

Анализ рынка

Контекст

• Jira: устойчивый консенсус пользовательских обсуждений: перегруженность, необходимость выделенного администратора, медленный интерфейс. Тренд 2025–2026: массовый переход команд на более простые инструменты. Уход Atlassian с российского рынка освободил нишу.
• Linear: эталон сегмента «инструмент, который любят разработчики». Причины успеха: скорость отклика, клавиатурный ввод, встроенная стадия triage против «чёрной дыры» бэклога. Вывод для Такта: воспринимаемое качество определяется скоростью и отзывчивостью не меньше, чем набором функций.
• Kaiten: основной российский конкурент в нише гибких методологий. Пользовательские жалобы: подвисания, перегруженность досок, ограничения на больших объёмах. Kaiten силён конфигурируемостью, что одновременно означает отсутствие методологического мнения.
• ActionableAgile: лидер ниши flow-аналитики (Монте-Карло, cycle time scatterplot, aging WIP), но существует как платный плагин к Jira/Azure DevOps и не содержит слоя церемоний.

Ниша Такта

Между «конструкторами без методологического мнения» (Jira, Kaiten) и «быстрыми трекерами без аналитики» на рынке отсутствует продукт, объединяющий доказательную flow-аналитику и церемонии как встроенное свойство системы. Такт занимает именно эту позицию: методология зашита в продукт, каждая цифра сопровождается формулой, каждая церемония поддерживается механикой, а не регламентом. Единая рамка, связывающая перечисленные выше доработки: церемонии и политики как свойства системы, а не дисциплина команды. Эта рамка одновременно является ответом на главный риск Scrumban (потерю дисциплины) на архитектурном уровне.

Приоритетный порядок точечных доработок

Порядок определён соотношением стоимости реализации и вклада в дифференциацию продукта. Ни одна из позиций не требует изменения архитектуры; первые две не требуют изменений схемы БД.

Состояние на релиз 0.2: пункт 2 закрыт (исход спринта и калибровка первым классом в отчёте и на странице журнала), пункт 6 закрыт автоматизациями (перцентильные и прогнозные триггеры стали настраиваемыми правилами с доставкой в уведомления, комментарии и daily). Пункты 1, 3, 4, 5, 7 открыты.

Что сознательно не делается

Зафиксировано как защита от расползания объёма: конструктор произвольных workflow, настраиваемые поля, диаграмма Ганта, встроенный чат, нативные мобильные приложения, наращивание числа модулей до уровня Kaiten/Jira. Каждая из этих позиций требует месяцев разработки и не добавляет дифференциации в выбранной нише.