← Предыдущая статья

В проекте почти всегда наступает момент, когда кто-то просит поменять кнопку.

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

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

И вот выявляется «осадочек»: сама по себе просьба не равна требованию.

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

Факты

По итогам АКПО-Конф

Сессия «На пути к технологическому суверенитету: как бизнес-аналитики перестраивают российский ИТ-ландшафт» была заявлена через роль бизнес-анализа в ИТ, профстандарты, терминологию заказчиков, диалог производителей ПО и аналитиков, центры компетенций и консолидацию требований крупного бизнеса.

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

Дальше прозвучала формулировка, хорошо подходящая для этой темы: бизнес-аналитик находится между бизнесом, в котором он должен разбираться, и ИТ, которое не обязано знать все детали бизнеса. Он стоит в начале цепочки, где дальше появляются архитектор, системный аналитик, разработчики, тестировщики и внедрение. Если ошибка возникает в начале, дальше она разъезжается по проекту.

Показательный эпизод был почти бытовым. Заказчик говорит: кнопка желтая, хочу фиолетовую. Аналитик спрашивает: зачем тебе это нужно? Может быть, тебе вообще эта кнопка не нужна.

Это не шутка про интерфейс. Это компактная модель бизнес-анализа.

Плохой путь: заказчик попросил — аналитик записал — разработчик сделал — все формально правы.

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

В той же дискуссии разработчик продукта говорил о другой стороне проблемы. Обратная связь заказчика без бизнес-анализа превращается в набор разрозненных пожеланий. Разработчики, по его словам, часто считают, что сами лучше знают, какой продукт делать, а обратную связь могут отодвигать в конец очереди. Заказчики тоже не всегда понимают, зачем им бизнес-анализ, и приходят с готовым списком «что сделать», но без ясного «зачем».

Получается симметричная ловушка. Вендор может не слышать потребность, потому что видит только тикет. Заказчик может не сформулировать потребность, потому что приносит только список изменений. Аналитик нужен не для того, чтобы выступать в роли вежливого переводчика между ними, а чтобы проверять связь между изменением и задачей.

Что видно по российским реалиям

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

В такой обстановке мелкие хотелки опаснее, чем выглядят.

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

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

Здесь и проходит граница между хотелкой и требованием.

Хотелка описывает желаемое изменение.

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

Что подсказывает наследие SAP

В SAP-проектах эта дисциплина давно известна через Fit-to-Standard. Там обсуждение не должно сводиться к списку «сделайте как у нас было». Сначала стандартный процесс сопоставляют с потребностями заказчика, затем фиксируют разрывы, требования и решения: принять стандарт, изменить процесс, настроить систему, сделать расширение или вынести запрос за границы проекта.

Полезна сама логика. Требование появляется не из желания поменять экран, а из обнаруженного расхождения между тем, как работает процесс, и тем, что нужно бизнесу.

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

Редакционно-логическое наблюдение

В проектах часто путают три разных вещи.

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

Жалобу нельзя игнорировать. Просьбу нельзя механически исполнять. Требование нужно вывести.

Проблема в том, что просьба звучит увереннее, чем причина. Человек не всегда может сразу описать процесс, риск и эффект. Зато он видит кнопку. Поэтому кнопка получает власть над разговором.

Аналитик в такой ситуации делает неприятную, но полезную работу. Он замедляет ложную ясность.

• Не «каким цветом сделать?», а «какая задача за этим стоит?».
• Не «где поставить поле?», а «какое решение без этого поля невозможно принять?».
• Не «какой отчет добавить?», а «какое действие этот отчет должен изменить?».
• Не «что просит пользователь?», а «какую работу он пытается выполнить?».

Вопрос «зачем» не отменяет запрос заказчика. Он спасает запрос от преждевременного исполнения.

Попытка объяснения

Хотелки так легко проходят в требования по трем причинам.

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

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

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

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

Гипотеза

Чем раньше в проекте появляется проверка «зачем», тем меньше бессмысленных требований доходит до разработки.

Проверка должна быть простой, но жесткой:

• какую проблему закрываем;
• кто носитель проблемы;
• какой процесс затронут;
• что изменится в работе пользователя;
• как измерим улучшение;
• какие соседние сценарии заденем;
• что будет, если не делать;
• есть ли решение без доработки.

Если на эти вопросы нет ответа, перед нами не требование, а черновик разговора.

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

Вопрос к читателям

Как вы отсекаете бессмысленные требования?

Есть ли у вас правило, по которому запрос не попадает в разработку без ответа на «зачем»? Кто задает этот вопрос: бизнес-аналитик, владелец продукта, архитектор, интегратор, руководитель проекта, ключевой пользователь? Что помогает остановить просьбу «поменять кнопку», если за ней нет рабочей задачи?

Пишите на y.nechitaylov@sappro.ru, в сообществе в ВК или в комментариях под этими материалами на sappro.ru.

Все заметки главреда здесь.

Продолжение следует.

Автор

Юрий Нечитайлов — главный редактор SAP Professional Journal Россия, преподаватель логики, критического мышления и программирования. Имеет научную степень в области логики и около 30 лет занимается анализом рассуждений, аргументации, понятийных систем и ошибок мышления. Работает на стыке ИТ, образования и профессиональных сообществ: развивает клуб программистов ABAP и администраторов SAP-систем, взаимодействует с корпоративными университетами и независимыми экспертами. В своих материалах рассматривает корпоративные ИТ не только как набор технологий, но и как поле для проверки понятий, оснований, выводов, гипотез и управленческих решений. Такой подход помогает отделять факты от интерпретаций, рабочие признаки от деклараций, а проверяемые выводы — от красивых, но слабых обобщений. В цикле «Логические заметки» автор приглашает практиков сопоставлять редакционные гипотезы с реальными проектами, примерами и контрпримерами.