Клиенты И Яблоки: Несколько Слов О Сборе Требований

«А мне хотелось большое зеленое кислое яблоко», — простонала я, держа в руках маленькое яблоко с красной гранью.

«Ты сказала мне купить яблоко, я купил яблоко», — сурово огрызнулся муж.

В начале разработки клиенты всегда довольны; они становятся неудовлетворенными в конце, когда их ожидания не соответствуют тому, что развивается.

Казалось, что заказчик и менеджер по разработке говорили об одном и том же, вроде бы использовали умные слова вроде «план» и «риски», но клиент был не в восторге от готового продукта.

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

Часто мнения содержат опыт клиента или конкурента, а также знания о потребителях и их поведении.

Клиент, работая со своей бизнес-проблемой и ее контекстом, формирует свои ожидания от инструмента, а затем обращается к профессионалу для разработки этого самого инструмента.

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

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

Заказчик видит, что в общих чертах представленное его удовлетворяет, но он проверяет это в контексте своих знаний.

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

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

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

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

«Но вы не спросили об этих тонкостях и нюансах» — клиент уже не доволен разработкой и разработчиками.

Но проблема возникла при первом обсуждении инструмента, тогда ни менеджер, ни заказчик не пришли к согласию.

Контекст, сохраненный заказчиком, не стал контекстом проекта разработки инструмента.

Менеджер сформировал представления о функциях инструмента, но не проверил, совпадают ли его представления об этапах решения бизнес-задачи клиента с изложенными клиентом.

Вот и получилось яблоко из моего примера, понятное всем, но не гарантирующее совпадение вкусов, предпочтений и стереотипов.

По моему опыту, есть только один способ избежать этого – поговорить.

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

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

— Я хочу интернет-магазин.

- Да, сделаем 100 тысяч рублей.

Этот диалог, к сожалению, является типичным примером общения с клиентом.

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

Более того, продажа может и не состояться, эти деньги просто уйдут на ветер.

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

Избегайте терминов.

— Мне нужен сайт-визитка, интегрированный с биллинговой системой, пожалуйста.

— Это уже не визитка, это уже корпоративный сайт.

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

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

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

Преследуйте бизнес-цели.

- Не говорите мне продавать унитазы, нарисуйте здесь кнопку купить и поставьте здесь баннер.

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

Именно из списка задач инструмента с точки зрения бизнеса будет виден контекст, а также ожидания клиента.

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

Пожалуйста, уточните и спросите еще раз.

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

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

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

Конечно, это примитивно.

Несомненно, это не избавит вас от всех неточностей.

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

Но никто не будет снимать с менеджера ответственность за сроки реализации проекта, его бюджет и ввод в эксплуатацию.

И ответственность за удовлетворенность клиентов компанией также останется на плечах руководителя.

Именно поэтому нельзя забывать об этих, казалось бы, банальных вещах.

«Яблоко зеленое кислое (сорт Гренни Смит или Семеренко) весом 350-450 граммов», — написала я в списке покупок.

Потом подумала и добавила: «Без листочка, но с хвостиком.

Цвет хвоста не имеет значения».

Теги: #Управление проектами #управление требованиями #управление требованиями #сбор требований #apple #apple не имеет ничего общего с #Управление проектами