Требования и аналитика: откуда вообще берутся задачи в трекере

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

Эта статья — про то, как этот слой устроен на самом деле: из чего берутся задачи, в каких формах записываются требования, почему тикет «сделать выгрузку в Excel» стоит трёх дней вместо двух часов, и что делать джуну, когда задача пришла с одной строчкой описания. В https://courses.digitable.life/post/sdlc-and-career/01-what-is-sdlc/ мы разобрали жизненный цикл целиком — здесь увеличение на первую фазу, ту самую, где ошибка стоит дешевле всего, а допускают её чаще всего.

Откуда реально берутся задачи

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

1. Продуктовая стратегия и роадмап. Самый «правильный» канал: продакт решил, что в этом квартале команда делает самообслуживание, — из этого вырастает десяток задач. Со стороны продакта это разобрано в https://courses.digitable.life/post/product-management/04-strategy-and-roadmap/.

2. Клиенты и продажи. Крупный клиент сказал «не подпишем контракт без SSO» — и вот в спринте интеграция с SAML, которой не было ни в каком роадмапе. В B2C аналог — топ отзывов в сторах.

3. Поддержка и инциденты. Тикеты первой линии, повторяющиеся жалобы, постмортемы. Часть — баги, часть — продуктовые доработки, замаскированные под баги («кнопка не работает» на деле означает «пользователь не понимает, что она делает»).

4. Аналитика и метрики. Воронка проседает на третьем шаге, конверсия упала после релиза, retention отличается между сегментами — отсюда растут гипотезы и эксперименты.

5. Регуляторка, безопасность, юристы. Требования закона и комплаенса, результаты пентеста, закрытие CVE. Отличаются тем, что почти не обсуждаются: срок задан снаружи.

6. Инженерные нужды. Техдолг, миграции, наблюдаемость, ускорение CI. Их предлагает сама команда, и за них приходится бороться в приоритизации: у них нет внешнего адвоката (https://courses.digitable.life/post/sdlc-and-career/07-support-and-techdebt/).

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

Кто этим занимается и почему аналитика может не быть

Важное разделение, из-за которого путаются: BA работает от бизнеса, его выход — «что должно происходить в предметной области». SA работает от системы, его выход — «какие сервисы, какие поля, какие коды ошибок». В маленькой компании это один человек, а часто вообще ноль: тогда бизнес-часть тянет продакт, системную — вы. Про полный набор ролей и зоны ответственности — https://courses.digitable.life/post/sdlc-and-career/08-roles-and-teams/. Честно про разницу контекстов:

• В энтерпрайзе аналитик есть почти всегда, и это хорошо: он держит знание о доменных правилах, которые никто уже не помнит, и говорит с бизнесом на языке бизнеса. Плата — длинная цепочка бизнес → BA → SA → разработчик, где на каждом звене теряется контекст, а вы можете ни разу за год не поговорить с живым пользователем.
• В стартапе аналитика нет: разработчик сам ходит к основателю, сам смотрит в метрики, сам решает крайние случаи. Быстро и без испорченного телефона — но легко построить не то, а решения «на бегу» через год выглядят как хаос. Подробно про оба мира — https://courses.digitable.life/post/sdlc-and-career/10-enterprise/ и https://courses.digitable.life/post/sdlc-and-career/11-startup/.

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

Уровни требований: почему нельзя писать код по фразе «хотим самообслуживание»

Требование — не одна сущность, а несколько слоёв, и путаница между слоями — источник половины конфликтов между бизнесом и разработкой.

1. Бизнес-требования — зачем компании это нужно, в терминах денег, риска или времени: «снизить нагрузку на поддержку», «выйти на рынок X», «не получить штраф».
2. Пользовательские требования — что человек хочет сделать и в какой ситуации.
3. Функциональные требования — что система обязана делать: правила, поведение, крайние случаи, реакции на ошибки.
4. Нефункциональные требования (NFR) — свойства поведения: скорость, доступность, безопасность, совместимость, локализация.
5. Ограничения — то, что менять нельзя: стек, интеграция с легаси, регуляторная дата, бюджет.

Классификация не академическая придирка, а язык для разговора. Фраза «задача не готова» вызывает вопрос «почему». Фраза «здесь есть история пользователя, но нет ни одного правила для случая с отрицательным балансом и нет требования по времени ответа» — конкретный список, который можно закрыть. Каноничный источник — Карл Вигерс, «Software Requirements», плюс стандарт ISO/IEC/IEEE 29148: хорошее требование полное, непротиворечивое, проверяемое, однозначное и отслеживаемое.

Формы записи: user story, use case, спека, Gherkin

User story

Самая распространённая форма в продуктовых командах — Как <роль>, я хочу <действие>, чтобы <польза>:

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

Ключевая мысль, которую джуны упускают: user story — это не спецификация, а напоминание о разговоре. Рон Джеффрис описал это как «3C»: Card (краткая запись), Conversation (разговор, где выясняются детали), Confirmation (критерии, по которым проверим). Если в тикете есть только Card — работа с требованиями не сделана, она отложена на вас. Есть и другая форма, job story из Jobs-to-be-Done — Когда <ситуация>, я хочу <мотивация>, чтобы <результат>:

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

Разница не косметическая: из job story сразу видно, что повышение тарифа должно применяться немедленно, а не «с начала следующего периода». Из user story это не следует.

Use case

Более формальная штука: акторы, предусловия, основной сценарий, альтернативы, исключения. Живёт в энтерпрайзе и регулируемых проектах, где надо не «поговорить», а зафиксировать. Классика — Алистер Кокберн, «Writing Effective Use Cases».

UC-14. Смена тарифного плана

Актор: Владелец аккаунта
Предусловия: аккаунт активен, нет неоплаченных счетов, у пользователя роль owner
Основной сценарий:
  1. Пользователь открывает раздел «Тариф»
  2. Система показывает текущий тариф, дату окончания периода и доступные планы
  3. Пользователь выбирает план
  4. Система показывает расчёт: сумма к доплате или дата вступления в силу
  5. Пользователь подтверждает; система применяет изменение и шлёт уведомление
Альтернативы:
  4а. Понижение тарифа → изменение планируется на конец периода, доплата не требуется
  4б. Потребление превышает лимиты нового тарифа → показать, что именно превышено
Исключения:
  5а. Платёж не прошёл → тариф не меняется, показывается причина отказа
  5б. Параллельная смена из другой сессии → показывается актуальное состояние

Выглядит бюрократично — ровно до момента, когда в проде обнаружится пункт 4б, о котором никто не подумал, и придётся объяснять, почему клиенту с 300 сотрудниками переключили тариф на «до 10 пользователей».

Критерии приёмки и Gherkin

Критерии приёмки (acceptance criteria) — то, по чему тестировщик и продакт признают задачу сделанной. Хорошие критерии проверяемы: их можно превратить в тест или хотя бы в конкретный клик. Плохие — оценочные: «работает быстро», «удобно», «понятно пользователю». Формат Given/When/Then (Gherkin) удобен тем, что заставляет назвать исходное состояние — именно там прячутся крайние случаи:

Функция: Смена тарифного плана

  Сценарий: Понижение тарифа в середине оплаченного периода
    Дано аккаунт на тарифе "Pro", период оплачен до 31.08, текущая дата 19.08
    Когда владелец аккаунта выбирает тариф "Basic"
    Тогда смена планируется на 01.09
    И до 01.09 сохраняются лимиты тарифа "Pro", возврат средств не производится
    И владельцу отправляется письмо с датой вступления изменения в силу

  Сценарий: Понижение при превышении лимитов нового тарифа
    Дано аккаунт на тарифе "Pro" с 42 пользователями, а "Basic" допускает 10
    Когда владелец аккаунта выбирает тариф "Basic"
    Тогда смена отклоняется
    И показывается сообщение с числом пользователей, которых нужно отключить

Ошибка, которую делают все: писать критерии только на счастливый путь. Правило простое — на каждый счастливый сценарий должно быть минимум два несчастливых: пустые данные, отказ внешнего сервиса, конкурентное изменение, права доступа, повторный клик по кнопке. Как эти критерии превращаются в автотесты и как устроена приёмка — https://courses.digitable.life/post/sdlc-and-career/05-testing/; про подход, где примеры и есть спецификация, — Гойко Аджич, «Specification by Example» и Impact Mapping.

Спецификация и ADR

Когда задача крупная или затрагивает несколько систем, одной карточки мало: появляются техническая спека (что меняем в каких сервисах, какие контракты, миграции, план выката) и ADR — короткий документ «решили X, потому что Y, альтернативы Z, последствия такие-то» (формат Майкла Найгарда, adr.github.io). Через год вы прочитаете не только «что», но и «почему», и не станете переделывать по кругу.

Границу между требованием и проектным решением легко потерять: «использовать Kafka» — это решение, а не требование. Требование — «события не должны теряться при недоступности потребителя до 4 часов». Решение можно оспорить, требование — только изменить у владельца. Про эту границу подробно в https://courses.digitable.life/post/sdlc-and-career/03-design/.

Нефункциональные требования: где джуна ждёт засада

Функциональные требования обычно хоть как-то записаны. Нефункциональные — почти никогда, потому что они «очевидны». Их отсутствие обнаруживается в проде.

Приём, который стоит освоить на уровне рефлекса: переводить прилагательные в числа.

Последняя строка почти всегда самая полезная, но и четвёртая не хуже: «выгрузка в Excel» на 1000 строк и на 5 миллионах — две разные задачи, различающиеся в двадцать раз по трудоёмкости. Вопрос про объём данных занимает тридцать секунд и экономит недели.

Жизненный цикл задачи в трекере

У задачи есть состояния, и переходы между ними — не формальность, а протокол общения команды. Названия колонок отличаются, суть одинаковая.

Смотрите на возвратные стрелки, особенно «Приёмка → Уточнение»: каждая означает переделку, а переделка почти всегда родом из требований. По ним диагностируют процесс — если задачи регулярно возвращаются с приёмки, проблема не в разработчиках, а в том, что критерии писались после реализации. Метрики потока — в https://courses.digitable.life/post/project-management/02-kanban-and-flow/. Цикл бага похож, но начинается с воспроизведения и триажа: «не воспроизводится» — валидное состояние, а не оскорбление репортера, обычно это значит нехватку шагов, окружения или данных.

Definition of Ready: когда задачу можно брать

Definition of Done знают все (о нём — https://courses.digitable.life/post/sdlc-and-career/04-development/). Definition of Ready знают реже, а он спасает больше времени: это чек-лист, при выполнении которого задачу можно брать, не рискуя застрять на второй день. Рабочий минимум:

• Понятно, какую проблему решаем и чью, а не только что делаем
• Есть критерии приёмки, и они проверяемы
• Описаны крайние случаи: пусто, много, ошибка, нет прав, повтор
• Есть макеты или явно сказано, что UI не меняется
• Известны затронутые системы и владельцы смежных сервисов
• Понятно, как проверить результат на бою: метрика, лог, дашборд
• Задача помещается в несколько дней и не заблокирована снаружи

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

Как разработчик участвует в уточнении

Здесь начинается ваша часть работы, и именно здесь middle отличается от junior заметнее всего. Junior берёт задачу и делает написанное. Middle сначала находит в задаче то, что не написано.

Вопросы, которые стоит задавать почти к любой задаче:

1. Какую проблему это решает? Если ответ «так попросили» — копайте дальше: вы, вероятно, реализуете чьё-то решение, а не потребность. Часто задача закрывается настройкой.
2. Как мы поймём, что получилось? Метрика, дашборд, письмо от клиента — что угодно конкретное. Отсутствие ответа — сигнал, что цель не сформулирована.
3. Что происходит, когда что-то идёт не так? Отказ платёжки, таймаут, дубль запроса.
4. Какие данные уже есть? Половина «новых» полей уже лежит в базе под другим именем.
5. Кто ещё этим пользуется? Изменение эндпоинта ломает мобильное приложение.
6. Что будет со старыми данными? Миграция, совместимость, промежуточные состояния.
7. Это нужно целиком или можно кусками? Часто 20% объёма закрывают 80% боли.

Формулируйте вопросы письменно и в тикете, а не голосом в коридоре: через два месяца никто не вспомнит устный ответ, а виноваты в том, что «сделали не то», будете вы. Комментарий в задаче — это и уточнение, и страховка. Отдельный навык — не превращать уточнение в паралич: есть вопросы, меняющие архитектуру («партнёрские аккаунты в скоупе?»), а есть те, что решаются самостоятельно («какого цвета сообщение об ошибке»). Второй тип не выносят на груминг — решите разумно и напишите в тикете «сделал так, если не подходит — скажите».

Раскопки: где искать правду, когда спросить некого

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

1. Прод: данные и поведение. Запрос «сколько аккаунтов, у которых одновременно X и Y» отвечает на вопрос «бывает ли такой случай» лучше любого совещания.
2. Код. Он не врёт о том, что происходит, но врёт о том, что задумывалось. Смотрите не только основной путь, но и обработчики ошибок, фиче-флаги и «временные» ветки.
3. Логи и аналитика. Как часто вызывается эндпоинт, есть ли живые клиенты на старом формате.
4. История изменений. git log, git blame, номера тикетов в коммитах — часто единственный способ узнать, почему появилась странная проверка.
5. Старые тикеты и переписки. Поиск по трекеру по ключевому слову — недооценённый навык.
6. Люди. Самый быстрый, но ненадёжный источник: люди помнят намерения, а не факты.
7. Документация. Ставлю последней сознательно: её надо проверять по пунктам 1–4.

-- Проверяем гипотезу «понижение тарифа при превышенных лимитах не встречается».
-- Такой запрос на реплике отвечает точнее, чем часовое совещание.
SELECT t.plan_code, COUNT(*) AS accounts,
       SUM(CASE WHEN a.active_users > p.max_users THEN 1 ELSE 0 END) AS over_limit
FROM accounts a
JOIN tariffs t ON t.id = a.tariff_id
JOIN plans   p ON p.code = t.plan_code
GROUP BY t.plan_code ORDER BY over_limit DESC;

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

Трассируемость: связь требования с кодом и релизом

Трассируемость — это возможность ответить на вопрос «почему в системе вот это поведение», дойдя от строчки кода до бизнес-требования, и наоборот. В обычной команде она держится на простых договорённостях: номер задачи в названии ветки (feature/BILL-482-tariff-downgrade) и в сообщении коммита, ссылка на эпик в задаче, тесты, названные по сценариям приёмки.

В регулируемых отраслях — медтех, авиация, финансы — трассируемость обязательна и проверяется аудитом: должно быть доказуемо, что каждое требование покрыто тестом. В обычной команде она нужна для приземлённого: когда через год спросят «почему тут такая проверка», ответ найдётся за минуту, а не за день археологии. Пунктирная стрелка — самая часто отсутствующая часть цикла: фичу выкатили, а проверил ли кто-нибудь, что обращений стало меньше? См. https://courses.digitable.life/post/product-management/08-analytics-and-decisions/.

Требования меняются — и это нормально

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

• Изменение требований — внешний мир изменился, старое решение стало неверным; это законный повод пересмотреть план.
• Scope creep — объём тихо растёт без пересмотра сроков и приоритетов. «Добавь заодно экспорт», «пусть ещё по email отправляет». Каждый пункт мелкий, вместе — двукратный перерасход.

Взрослая реакция на «а можно ещё вот это» — не «нет» и не молчаливое «ок», а перевод разговора в плоскость обмена: «Можно. Это примерно плюс два дня. Что из спринта убираем?» Формулировка не конфронтационна, но возвращает решение тому, кто отвечает за приоритеты. Ответ «ничего не убираем, просто сделай» — управленческая проблема, её стоит поднять на ретро или один на один с лидом, а не героически закрывать переработками.

В энтерпрайзе для этого есть формальная процедура: change request, оценка влияния, согласование. Медленно, но у изменения появляется след и автор. В стартапе процедуры нет, и защита от расползания — только привычка фиксировать письменно: «Как договорились: делаем A и B, C выносим в отдельную задачу». Смежное — https://courses.digitable.life/post/project-management/04-risk-management/ и https://courses.digitable.life/post/management/preliminary-assessment-of-it-projects/.

Энтерпрайз против стартапа: один процесс, два мира

Ни одна колонка не «правильная». Полезно за карьеру побывать в обеих: энтерпрайз учит тому, что бывают домены, которые нельзя понять за неделю, стартап — тому, что документ без проверенной гипотезы ничего не стоит. Про выбор типа проекта — https://courses.digitable.life/post/sdlc-and-career/09-project-types/.

Инструменты: чем это всё делается

Трекеры (Jira, YouTrack, Yandex Tracker, Linear, GitLab/GitHub Issues) устроены принципиально одинаково: сущность, статус, связи, история. Базы знаний — Confluence, Notion или markdown в репозитории; последний вариант недооценён, потому что документация рядом с кодом обновляется чаще. Figma: умение находить в макете все состояния экрана — пусто, загрузка, ошибка — реальный навык разработчика, а не задача дизайнера. Схемы процессов — Miro, draw.io, BPMN в энтерпрайзе, mermaid в репозитории. API-контракты — OpenAPI, protobuf; часто именно спека контракта и есть настоящее системное требование, по ней фронт и бэк договариваются раньше, чем начнут писать код. Но реальность, о которой не пишут в вакансиях: значительная часть требований живёт в переписке и чужих головах, и навык «найти, где на самом деле лежит правда» важнее знания трекера.

Типичные ошибки, которые дорого обходятся

1. Начать кодить, не прочитав задачу до конца — особенно когда она выглядит знакомой.
2. Реализовать написанное буквально, зная, что оно неверно. «Там же так написано» — не защита; заметили противоречие, напишите об этом до, а не после.
3. Уточнять устно и не фиксировать. Через месяц договорённость помнят по-разному.
4. Не спросить про объёмы данных — источник «работало на тесте, легло на проде».
5. Игнорировать крайние случаи, потому что «так не бывает». В проде бывает всё: нулевые суммы, даты в 1970 году, эмодзи в имени, два одинаковых запроса за 20 миллисекунд.
6. Считать, что аналитик всё проверил. Он знает домен, но не знает вашего кода.
7. Молча раздувать скоуп. «Заодно отрефакторил» превращает ревью на 40 строк в ревью на 900.
8. Бояться показаться глупым. Вопрос «что если нажать дважды» наивен ровно до момента, когда выясняется, что произойдёт двойное списание.
9. Не проверить результат после релиза — изменилась ли метрика, ради которой всё делалось.

Почему это важно для карьеры

Работа с требованиями — один из самых прямых рычагов роста. Технические навыки джуна и мидла могут отличаться не так сильно, а вот способность увидеть в тикете дыру, задать три правильных вопроса и сэкономить команде неделю — отличается разительно и заметна снаружи. Поэтому на собеседованиях выше junior регулярно дают открытую задачу с недостающими данными: смотрят не на алгоритмы, а на то, начнёте ли вы уточнять условия или броситесь писать код по первой интерпретации (https://courses.digitable.life/post/sdlc-and-career/16-interview-candidate/ и https://courses.digitable.life/post/sdlc-and-career/17-interview-interviewer/, про грейды — https://courses.digitable.life/post/sdlc-and-career/12-grades/). В первые месяцы на новой работе вопросы по требованиям — ещё и самый безопасный способ быть полезным, пока вы не разобрались в коде (https://courses.digitable.life/post/sdlc-and-career/18-first-90-days/).

Мини-итог

• Задачи приходят минимум из шести источников, и по источнику понятно, как с ними обращаться.
• Требование — это слои: бизнес-цель, сценарий пользователя, функциональные правила, NFR, ограничения. Спор обычно идёт из-за смешения слоёв.
• User story — не спецификация, а обещание разговора; спецификацией её делают критерии приёмки.
• Проверяемость — главный критерий качества: «быстро» → число, «удобно» → сценарий. На каждый счастливый путь пишите минимум два несчастливых.
• Definition of Ready — повод для разговора, а не шлагбаум.
• Требования меняются законно; scope creep — нет. Отвечать надо не отказом, а обменом.
• Источник правды по надёжности: прод → код → логи → история изменений → люди → документация.
• Разработчик — участник работы с требованиями, а не получатель готового ТЗ; именно здесь заметнее всего разница между грейдами.

Что почитать

• Карл Вигерс, Джой Битти. «Software Requirements», 3rd ed. — базовый учебник по теме.
• Майк Кон. «User Stories Applied» — истории, декомпозиция, планирование по ним; Алистер Кокберн, «Writing Effective Use Cases» — если попали в энтерпрайз.
• Гойко Аджич. «Specification by Example» и Impact Mapping.
• ISO/IEC/IEEE 29148 — требования к требованиям; Gherkin Reference — синтаксис Given/When/Then; adr.github.io — форматы записи архитектурных решений.
• Ubiquitous Language Мартина Фаулера — почему важно называть вещи так же, как бизнес; развитие — https://courses.digitable.life/post/ddd/01-strategic-design/.
• https://courses.digitable.life/post/product-management/06-ux-and-requirements/ — та же тема со стороны продакта, а https://courses.digitable.life/post/product-management/03-prioritization/ — как решают, что делать раньше.

Что дальше

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

Проектирование: почему нельзя просто сразу начать писать код