Post #343

У Григория Добрякова, которого здесь уже цитировал, вышел пост про управление требованиями. К гигиеническому минимуму он относит вот что. Требования должны быть: 1. Сформулированы. 2. Записаны. 3. Доведены до адресатов. 4. Проверены на соответствие результатов. В деталях: Сформулированы: Должна быть буквально проведена работа по выявлению ожиданий. Кто, чего и от кого/чего ожидает. Особенно если неявно. Особенно если «ну я думал вы сами догадаетесь, это же очевидно». Записаны: Должна быть буквально проведена работа по фиксированию всего о чём проговорили. Текстом, документом, табличкой, реестром, схемами, всем чем можете. Лаконично, но достаточно. Главная цель — ничего не оставить на словах. Сюда же входит задача провалидировать записанное с заказчиками. Иван Иваныч, а я правильно записал? Ну-ка гляньте. Доведены до адресатов: Доводить — это процесс, а не просто галочка в отчёте. Ты требование видел? А осознал? А технически реализовать сможешь? А ресурсы есть? А чё сломается если сделать буквально как написано? Результат проверен на соответствие. Тут вроде понятно, причём это не только верификация, но и валидация: "Причём у малоопытных менеджеров результат может быть в полном соответствии с требованиями формально, но абсолютно вырвиглазно по сути." Этот пост мне живо напомнил принцип 3C's Рона Джеффриса, сформулированный ещё в 2001 году применительно к пользовательским историям: Card, Conversation и Confirmation. Требования сформулированы и записаны — это Card. В оригинале карточка не равна требованию, сам Рон называет её токеном (token), вещью для представления требования и управления им. Такая заметка, чтобы не забыть, что нужно обсудить идею. Четвертую C обычно не упоминают, но это Commitment — обязательство. Как только идея — может быть, ещё даже не требование! — зафиксирована, у команды возникает обязательство её обсудить. В одном из проектов у меня даже KPI были такие — число обработанных идей, то есть — рассмотренных, обсужденных, возможно — проверенных экспериментом и принятых в работу. Обсуждение — conversation — вот что важно. Это решает задачи и по формулированию, и по доведению до адресатов (тех, кто будет создавать реализацию). И тут стоит добавить пятую C — Collaboration. Требования не записаны в голове у стейкхолдера, требования - точнее, решения по свойствам будущего продукта — рождаются в ходе совместного обсуждения, поэтому обсуждение так важно. И особенно важна возможность свободного высказывания членами команды, предложения идей, уточнения запроса. Вовлечение команды разработки в процесс определения свойств продукта (специально не пишу "выявления требований"!). Иначе это прямой путь к выгоранию. Тут опять возникает commitment: обсудив решение, команда принимает обязательство по его реализации. А коллаборация подключает "эффект Икеа": если ты принимал участие в разработке решения, то ценность его для тебя растет, и такое решение легче исполнять. Ну и подтверждение, confirmation. В свежей (от 2019 года) статье про 3C's Рон пишет про сдвиг в сторону максимально конкретного выражения этого самого confirmation — в виде конкретных примеров, в идеале — исполнимых. Хуже ничего нет, чем "совещание по приёмке" — когда толпа людей просто идут по пунктам ТЗ и отмечают их реализацию путем осмотра готового ПО, без заготовленных примеров, без рассмотрения краевых ситуаций и стыков — на чем в последствии и вылезают большинство дефектов. Так что, идеальная картина: 1. Зафиксировали намеченное требование (идею). 2. Обсудили вместе с заказчиком и представителями разработки, наметили способ реализации. 3. Составили и согласовали способ проверки. 4. Реализовали, проверили. А для полного контроля и прозрачности хорошо бы завести правило, что ни одно изменение не вносится в систему без указания связи с требованием (тех.долг — это тоже требование!), ни одно требование не принимается без изменений в коде.