Как улучшить процесс работы с требованиями

Главные идеи#

Требования связывают всё#

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

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

Сопротивление и настоящая поддержка#

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

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

Четыре принципа#

1. Улучшайте постепенно и непрерывно. Начните с нескольких шаблонов и «низко висящих плодов» — проблем, которые, по общему мнению, нужно решить.
2. Люди меняются, когда им больно. Настоящая боль прошлых проектов мотивирует сильнее, чем давление сверху: сорванные графики из-за недооценённых требований, переделки из-за неоднозначности, впустую потраченное тестирование, высокие затраты на сопровождение, потерянные изменения, недоступные заказчики.
3. У каждого изменения должна быть цель, связанная с бизнес-целью.
4. Относитесь к улучшению как к проекту — с планом, ресурсами и отслеживанием хода работ.

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

Сначала найдите корневую причину#

Прежде чем выбирать средство, снова и снова спрашивайте «почему?», иначе вы будете пробовать новые методы наугад. Причины вложены друг в друга. Цепочка из книги: требования были пропущены ← аналитик не задал нужных вопросов ← люди в роли аналитика никогда не учились выявлению требований. Последняя причина и есть корневая, и она требует обучения, а не просто более длинного чек-листа. Здесь помогает диаграмма Исикавы («рыбий скелет», fishbone diagram): проблема — это хребет, категории вроде процесса, людей и проекта — главные кости, а последовательные ответы на «почему?» ответвляются от них. По принципу Парето меньшая часть причин обычно объясняет бо́льшую часть проблем, так что устранять все причины не нужно.

Цикл улучшения#

1. Оцените текущие практики с помощью анкеты и интервью. Часто оказывается, что реальная практика отличается от задокументированного процесса и что люди по-разному понимают, «как у нас принято».
2. Спланируйте действия по улучшению: тактический план на два-три месяца, не больше примерно десяти пунктов, у каждого — ответственный.
3. Создайте, опробуйте и внедрите новые практики.
4. Оцените результаты по целевым показателям, затем спланируйте следующий круг.

Дорожная карта#

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