«Но я же хотела зеленое большое кислое яблоко» — стенала я, держа в руках маленькое яблочко с красным боком. «Ты сказала, чтобы я купил яблоко, я купил яблоко» — сурово отрезал муж.
В начале разработки клиенты всегда довольны, недовольными они становятся в конце, когда их ожидания не совпадают с тем, что разработано. Вроде бы говорили заказчик и менеджер разработки об одном, вроде употребляли умные слова вроде «план» и «риски», а не в восторге клиент от готового продукта. Как так?
Задумывая инструмент решения своей бизнес-задачи, клиент, как правило, уже наделен некоторыми представлениями об этом инструменте, иногда совсем общими, иногда очень детальными и конкретными. Часто представления содержат и опыт этого клиента, и конкурентом, и знания о потребителях и их поведении. Клиент, работая со своей бизнес-задачей и ее контекстом, формирует свои ожидания от инструмента, а потом идет к профессионалу за разработкой этого самого инструмента. Приходит и сообщает, что хочет инструмент.
Менеджер разработки, имея свой контекст и опыт, смотрит на это желание сквозь стереотипы юзабилити, выгоды компании-разработчика и бюджета проекта. И формирует свои начальные представления об инструменте, фиксирует их и представляет заказчику.
Заказчик видит, что в общих чертах представленное его удовлетворяет, но, проверяет он это в контексте своих знаний. Если видит расхождения — задает вопросы, но хуже, если требования зафиксированы общим перечнем и хорошо ложатся на контекст. Тогда заказчик доволен началом разработки, задачи ставятся, работа кипит.
По ходу разработки менеджер доуточняет конечные детали тех или иных компонентов инструмента заказчика, заказчик отмечает внимание к деталям и срокам, он удовлетворен работой с менеджером и предвкушает быстрый запуск инструмента в эксплуатацию и как следствие молниеносное и качественное решение своей бизнес-задачи, менеджер предвкушает беспроблемную сдачу проекта такому лояльному клиенту, прибыль для компании-исполнителя и премию.
Но на первом представлении результата заказчика ждет разочарование — инструмент не только не решает задачу, но и не вписывается в существующие бизнес-процессы компании-заказчика. «Но вы ведь не говорили о таких ограничениях, вы подписали ТЗ, где об этом не слова!» — досада менеджера растет, он уже считает клиента невнимательным профаном. «А вы не спрашивали об этих тонкостях и нюансах» — клиент уже не доволен разработкой и разработчиками.
А проблема зародилась еще при первом обсуждении инструмента, тогда и менеджер, и заказчик не договорили и не договорились. Контекст, хранимый заказчиком, не стал контекстом проекта по разработке инструмента. Менеджер составил представления о функциях инструмента, но не проверил, совпадают ли его представления об этапах решения бизнес-задачи клиента с теми, которые наметил клиент. Вот и получилось то самое яблоко из моего примера, понятное каждому, но не гарантирующее совпадения вкусов, пристрастий и стереотипов.
Из моего опыта избежать этого можно только одним путем — говорить. Говорить с клиентом обстоятельно, о клиенте и его бизнесе, вслух и записывая, рисуя скетчи и схемы.
Говорите о задачах и пользователях, а не о конкретных системных функциях.
— Хочу интернет-магазин.
— Да, 100 тысяч рублей и сделаем.
Этот диалог типичный, к сожалению, пример коммуникации с клиентом. Да, выяснять, что будет продавать магазин, кто его клиенты и как именно они выбирают и приобретают товар, на первой встрече с клиентом дорого. Более того, продажа может не состояться, эти деньги просто вылетят в трубу. Но переделывать инструмент дороже, обязательства по договору в таком случае уже есть и клиент уже не доволен компанией-разработчиком, а эта имиджевые потери, существенные для компании, оказывающей услуги.
Избегайте терминов.
— Мне сайт-визитку, интегрированную с биллинговой системой, пожалуйста.
— Это уже не визитка, это уже корпоративный сайт.
Выяснив задачи, смоделировав поведение пользователей и прояснив базовые функции системы, менеджер разработки представляет себе как и что он будет разрабатывать. Осталось донести это до клиента бытовым языком, избегая непонятных клиенту терминов, чтобы клиент проверил, вписывается ли представленная система в его ожидания и вовремя указал на моменты, которые остались без внимания. И если он погрязнет в терминах и своих об этих терминах представлениях, согласия не получится. Ведь даже «яблоко» каждый понимает по-своему, а тут «нагрузочное тестирование» и «аджайл», сплошные домыслы и ожидания.
Преследуйте бизнес-цели.
— Не учите меня продавать унитазы, вот тут кнопку купить нарисуйте и сюда поставьте баннер.
Даже если клиент готов говорить о системе, о конкретных полях и элементах, не отходите от целей и задач в разрезе бизнеса для каждой части инструмента. Именно от списка задач инструмента с точки зрения бизнеса будет виден контекст, а так же ожидания клиента. А если клиент настаивает на обсуждении полей и кнопочек, обсуждайте и их, но после фиксации конкретных задач этой части инструмента.
Доуточняйте и переспрашивайте.
Чем чаще вы будете проговаривать очевидное, доуточнять и перепроверять, тем больше узнаете об ожиданиях клиента. Даже если вам, как менеджеру разработки, решение кажется очевидным, расскажите об этом решении клиенту, впишите его в общую модель и проверьте, что от этого действия не создалась черная дыра по срокам или бюджету. Клиент, хоть и устанет от такого диалога, будет благодарен получить работающий в его бизнесе инструмент, решающий задачу, а не декоративно потраченные деньги.
Конечно, это примитивно. Несомненно, не спасет от всех неточностей. Да, требования может уточнять бизнес-аналитик, а системный аналитик положит их на требования программного продукта, который является основой необходимого заказчику инструмента. Но никто не снимет с менеджера ответственность за сроки проекта, его бюджет, ввод в эксплуатацию. И ответственность за удовлетворенность клиента работой с компанией тоже останется на плечах менеджера. Именно поэтому нельзя забывать об этих, казалось бы, банальных вещах.
«Яблоко зеленое кислое (сорта гренни смит или семеренко) весом 350-450 граммов» — написала я в списке покупок. Потом подумала и добавила: «Без листика, но с хвостиком. Цвет хвостика значения не имеет».
Автор: malyasya
