Этот пост все о той же ситуации: есть Заказчик, есть вы - аналитик, есть запрос "мне нужна вот такая система".
Думаю, что очень многие сталкиваются с ситуацией, когда в
самом начале общения с Заказчиком на тему "нам нужна вот такая система" не удается получить каких-то четко
структурированных требований. Чаще всего это происходит от того, что в голове у Заказчика (и у Заказчика, как конкретного представителя, озвучивающего требования, так и у Заказчика, как "коллективного разума") нет четкого понимания - "что же, собственно от системы хочется получить".
Пример из жизни.
Руководитель отдела продаж оптовой компании обращается с запросом: "нам нужна crm-ка". На вопросы "кто ваши клиенты?", "как происходит общение с клиентами?" он отвечает достаточно подробно и с удовольствием. На вопрос "а кто кроме менеджера по продажам ведет общение с клиентом?" отвечает уже менее бодро. А вопрос "что бы вы хотели получить от CRM-системы?" приводит к пространным объяснениям про полноту информации о клиенте и планировании переговоров с ним (клиентом). И после двух-трех уточняющих вопросов, руководитель отдела "переходит в атаку" - "Лучше расскажите: что она может?"
Про причины такого "не знаю чё хочу, но чувствую, что надо" говорить можно много. Их может быть масса. И сейчас не очень готов писать про каждую из них.
Хочу привести пару советов - как из такой ситуации выходить? Как добиться от Заказчика описания требований и при этом постараться сделать это в какие-то более-менее приемлемые сроки.
Совет первый.
Если по первым двум встречам вы видите, что сложившейся "картины мира после внедрения" в голове Заказчика нет, то готовьтесь сами и морально готовьте Заказчика к тому, что проект по разработке-внедрению будете реализовывать в несколько этапов.
Само подробное разбиение на этапы провести можно будет только потом. Но уже в самом начале "держите в голове" и готовьте Заказчика к тому, что "поэтапное движение" в данном случае - оптимальный выход. Если замечаете, что в процессе обсуждения требований возникают обсуждения "перспективных изменений", то сразу говорите о втором (просто следующем) этапе.
Совет второй.
Не пытайтесь мучать представителя Заказчика вопросами про конкретику, если она не относится к его непоредственной ежедневной работе. Скорее всего, с вами разговаривает руководитель какого-то подразделения - дайте ему показать себя как руководителя. Пусть он назначит кого-то из своих отрудников "для обсуждения деталей".
Вы получите еще один "источник информации", возможность поговорить с конечным пользователем, шанс заручиться его поддержкой на этап внедрения, .. В общем, получите массу плюсов. И к тому же дадите возможность самому представителю Заказчика почувствовать себя экспертом (ведь он говорит именно о том, что точно знает).
Совет третий.
Получив общую информацию о работе в компании (подразделении) Заказчика предложите ему схему того, "как вы это видите". И предложите ему сначала обсудить предложенную схему при встрече. Потом дайте ему "поработать дома". И снова обсудите на встрече.
Важно понимать, что вы не навязываете ему свое представление, а даете ему возможность от чего-то оттолкнуться. Не заниматься формулированием каких-то требований, а критиковать, править, корректировать предложенное вами. Ему так будет проще. А у вас, наверняка, есть какие-то наработки по предыдущим проектам. Облегчите друг другу жизнь и сэкономьте время.
Совет четвертый.
По каждому пункту требований старайтесь задавать вопросы несколько раз. В разных формулировках, разным людям и промежутками во времени.
Разные формулировки важны для того, чтобы Заказчик имел возможность сам посмотреть на вопрос с разных сторон. Промежутки во времени - возможность Заказчику подумать. Мнения разных людей важны для полноты картины.
Универсальных советов не существует. Но сам стараюсь держать в голове эти четыре правила каждый раз, приступая к переговорам о новом проекте.
