Позиционирование: вглубь, а не вширь

Эта страница фиксирует стратегию развития Такта: где продукт конкурирует, где сознательно не конкурирует и почему главная ставка сделана на математическую модель, а не на количество функций.

Рыночный контекст

Базовая Scrumban-доска — колонки, спринты, WIP-лимиты, отчёты — сегодня коммодити. Она есть у всех зрелых инструментов: Kaiten, Яндекс Трекер, YouGile, Weeek, не говоря о Jira и Linear. Конкурировать с ними шириной функциональности бессмысленно: у этих команд на порядки больше ресурсов, а у их пользователей — высокая цена перехода.

Но у этой картины есть пробел. Вероятностное прогнозирование сроков — Monte Carlo, сетевое планирование, калибровка прогнозов по факту — не встроено ни в один из этих инструментов. На глобальном рынке такие методы существуют только как надстройки-плагины к Jira и Azure DevOps (ActionableAgile, Nave, FlowViz); в российской экосистеме их нет ни в каком виде. Сами эти надстройки при этом трекерами не являются — они не ведут задачи, а только анализируют чужие данные.

Эта ниша — трекер со встроенной доказательной математикой планирования — свободна. Такт целится именно в неё.

Стратегия: углублять ядро

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

Что это значит на практике:

Замыкать математику в продукте. Прогноз не должен быть «отчётом сбоку» — он встраивается в сами решения: ёмкость спринта, пополнение доски, приоритизацию. Метрики видны там, где принимается решение, и объясняют себя (см. Математика).
Петля доверия. Журнал прогнозов и калибровка — центральный механизм: система фиксирует каждое своё обещание и отчитывается за него по факту. Инструмент, который проверяет собственные прогнозы, — это качественно другой уровень честности, чем «красивый график».
Математика как источник автоматизации. Типовые автоматизации («перенести карточку», «назначить исполнителя») есть у многих. Уникальный ход Такта — триггеры от вероятностной модели: риск нарушения SLE, уехавший за границу спринта P85. Фоновые проверки такого рода уже работают; их развитие — в Roadmap.

Чего сознательно не делаем

Список «не делаем» — такая же часть стратегии, как список «делаем»:

Кастомные поля и конструкторы процессов — путь к сложности Jira, против которой Такт и строится.
Диаграмма Ганта — детерминированные сроки, нарисованные вручную, честно заменяются сетевым планированием по данным (CPM).
Встроенные чат, CRM, база знаний — расширение поверхности продукта без усиления ядра.
Жёсткие SLA-дедлайны — вместо них вероятностный SLE: «85% похожих задач закрывались за N дней» полезнее произвольно назначенного срока.

Исследовательский потенциал

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

Это материал для открытых кейсов и статей (например, на Хабре): «мы прогнозировали сроки N спринтов — вот честная калибровка». Такой кейс нельзя скопировать быстрее, чем накапливаются данные, — и это делает его самым устойчивым из возможных преимуществ. Как именно собираются и проверяются эти данные — на странице Апробация.

Как есть: математическое ядро (CPM/PERT, Monte Carlo, SLE, эффективность потока, честная калибровка с экспортом) реализовано и описано в разделе Математика; математика уже замкнута в действия через автоматизации и центр управления. Дальше: внешние данные пилотных команд и сравнение методов прогноза – детали в Roadmap.