Лекция

Двадцать человек и одна фраза

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

Эта лекция — про ремесло записи. Про три формы, в которые укладывают требование: история пользователя (user story), критерии приёмки (acceptance criteria) и сценарий использования (use case). Про разрезы, которыми крупное превращают в поставляемое. И про границы, за которыми все три формы перестают работать, — эту часть обучающие материалы обычно пропускают.

требование живёт до приёмки
Бизнес-аналитику

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

требование живёт до конца спринта
Продакт-менеджеру

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

Метод у обоих общий: сделать так, чтобы двадцать человек поняли одно и то же одинаково. Поэтому каждый приём здесь показан парой примеров — на внутренней системе (заявка на отпуск, согласование договора, выгрузка в 1С, интеграция с CRM) и на клиентском продукте (оплата подписки, восстановление пароля, фильтр в каталоге, push-уведомление). Разница между двумя ролями не в аппарате, а в горизонте и в том, кто платит за ошибку.

Чего в этой лекции нет — намеренно
  • Выбора методологии. Спринты, доски, обязанности и события — отдельная тема; здесь методология уже выбрана и надо писать.
  • Добычи требований. Как разговаривать со стейкхолдером и отличать «хочу» от потребности — тоже отдельная тема. Мы начинаем в момент, когда материал собран.
  • Структуры технического задания по разделам и матрицы трассируемости.
  • Приоритизации бэклога. Наша территория кончается там, где элемент сформулирован так, что его вообще можно оценить и сравнить.

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

Тема 1 из 14 · Зачем формат и откуда он взялся

Цена неточности: что измерил PMI и чего он не измерял

Самое цитируемое отраслевое измерение по требованиям — отчёт Института управления проектами (PMI) «Pulse of the Profession In-Depth Report: Requirements Management» за май 2014 года. Опрошено более двух тысяч практиков: руководителей проектов и бизнес-аналитиков. Четыре числа оттуда стоит запомнить точно, потому что их постоянно пересказывают неправильно.

47%
провалившихся проектов, где причиной названо неточное управление требованиями
37%
организаций назвали неточный сбор требований главной причиной провала проектов — в 2013 году таких было 32%
5,1%
бюджета проектов и программ теряется из-за плохого управления требованиями
51 млн $
на каждый потраченный миллиард — это те же 5,1% в деньгах
47 и 37 — это не одно число, и складывать их нельзя

В пересказах эти два показателя регулярно смешивают, и получается «47% проектов проваливаются из-за требований». Так говорить нельзя. 47% — доля уже провалившихся проектов, в которых причиной назвали требования. 37% — доля организаций, назвавших это главной причиной. Числа посчитаны по разным совокупностям: в первом случае знаменатель — провалившиеся проекты, во втором — опрошенные организации.

Что организации думают и что они делают

Разрыв между признанием проблемы и работой над ней, PMI 2014
Признают, что улучшение нужно
Имеют ресурсы делать это как следует
Имеют формальный процесс валидации требований
Руководителей, полностью ценящих управление требованиями как компетенциюещё 55% ценят отчасти, 9% не ценят вовсе

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

Чего эти цифры не доказывают
  • Это опрос, а не аудит проектов. Люди отвечали, что они считают причиной, — никто не проверял проектную документацию.
  • Данные 2014 года, им двенадцать лет. Более свежего измерения сопоставимого масштаба нет.
  • Самоотчёт о причинах провала смещён: «требования были плохие» — удобное объяснение, потому что оно никого лично не обвиняет.
  • Российских измерений сопоставимого масштаба не существует. Процент по РФ, который вам где-то попадётся, взят с потолка.

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

Коллега пишет в презентации: «47% проектов проваливаются из-за плохих требований, данные PMI». Что здесь неверно?
Знаменатель другой. 47% считаются от провалившихся проектов, а не от всех запущенных. Доля 37% — это про организации, назвавшие неточный сбор требований главной причиной провалов; в 2013 году таких было 32%. Оба числа существуют, но описывают разные совокупности.
Сколько денег, по данным PMI, организации теряют из-за плохого управления требованиями на каждый потраченный миллиард долларов?
5,1% бюджета проектов и программ — это 51 млн долларов на каждый потраченный миллиард. Ровно так это и стоит произносить: не «половина бюджета горит», а пять процентов, которые в абсолютных числах выглядят внушительно именно из-за масштаба базы.
Какое утверждение можно строить на данных PMI 2014, не выходя за границы того, что там измерено?
Это опрос самоотчётов: он фиксирует, что люди называют причиной, и не измеряет эффект внедрения чего-либо. Про Россию отчёт не говорит ничего, а измерений сопоставимого масштаба по РФ не существует — любую «российскую статистику» на эту тему придётся выдумать, чего делать нельзя.
Бесплатный доступ

Дальше нужен аккаунт

Прогресс и монеты сохранятся.