Приветствую читателей Хабра!
Меня зовут Белоусова Александра, я развиваю направление по обучению и стажировкам аналитиков в компании «Автомакон».
В прошлой статье про виды аналитиков и их различия затронула один из ключевых моментов — фразы «выяснить требования», «выявить боль Заказчика», «докопаться до сути проблемы» употребляют сейчас все, а понимают, что они действительно значат, — единицы!
В этой статье я попытаюсь приоткрыть завесу тайны этих кажущихся на первый взгляд простых и понятных фраз, но таких, как показывает практика, загадочных.
Объяснять можно долго, что:
? нельзя верить заказчику на словах;
? нельзя без выяснения причин реализовывать требования;
? нельзя делать это все, даже если он говорит: «Заказчик всегда прав, значит, делайте!» Поверьте, такое было и не раз. Как только находили первопричину, мне говорили: «спасибо, что не послушали и выполнили задание, а реально помогли!»;
? нельзя просто брать требования и делать, как это видит Заказчик и что он хочет. Категоричное «НЕТ»!
Вам, как аналитикам, нужно понять и донести до Заказчика, какую проблему изначально он решает! Можно использовать очень много методов, которые мы разбираем на нашей стажировке, при этом конечный результат должен быть один — вы и Заказчик ТОЧНО ПОНИМАЕТЕ какую проблему и как вы решаете, и точно ли это проблема!
Приведу примеры, как это происходит при решении реальных задач. Все примеры из реальной рабочей практики. Все совпадения прошу считать случайными ?
Кейс 1. Задача от заказчика по разработке отчета
Приходит Заказчик (менеджер по продажам) и говорит: «Сделайте мне отчет по продажам в системе 1С». Да, в рамках проектов по внедрению, развитию, переходу на новое ПО и т.д. отчеты тоже делают БА и СА.
И что вы должны сделать? Правильно — задать вопросы!
Как не надо: «Что за отчет? Что должен отображать? Как строиться? Из каких столбцов состоять? Ок, сделаем! Уже передал ТЗ на разработку!»
Делюсь таблицей-схемой ведения диалога с Заказчиком как «надо»:
№ |
Вопрос |
Ответ |
Результат |
Комментарий |
1 |
Есть ли уже в текущей системе отчет по продажам? |
«Да» (что бывает чаще всего в любых кейсах). |
Переход к следующему вопросу. |
Если ответ «Нет», главное правило — «Нельзя верить Заказчику на слово» — идем проверять. Жаль, что большинство руководствуются принципом «проверять мы это конечно же не будем» |
2.1 |
«А чем Вас не устраивает текущий отчет?» |
«А что, уже есть отчет?» (суперчастый ответ) |
Кажется, задача решена. Но не тут-то было! Далее нужно довести до Заказчика информацию — где лежит отчет и как им пользоваться. А еще провести анализ, как так произошло, что он был не в курсе. Это отдельная задача на возможную оптимизацию и изменение процесса или его автоматизацию по работе с невнимательными/халатными сотрудниками). |
Один из самых распространённых вариантов решения проблемы. Остается выяснить, почему же он не знал о существовании отчета. Тут может быть масса вариантов развития событий: потому что не увидел письмо/не донесли информацию ответственные лица/не читал документацию (регламенты, инструкцию и т.п.) |
2.2 |
«А чем Вас не устраивает текущий отчет?» |
«Некорректно считает/отражает данные» (еще один суперчастый ответ). |
Переход к следующему вопросу (п.3). |
Будем ли мы верить Заказчику? Конечно же… нет ;) давайте разбираться, что значит некорректно. А какие есть варианты? Как минимум три: Некорректно для кого? – «некорректно», как и «неудобно», «не нравится», «некрасиво», «не user-friendly» и пр. являются субъективными ответами. Некорректные данные на выходе или на входе? – Пользователь может ожидать получения определенных данных на выходе «думая» (и это ключевое слово), что на входе у него абсолютно другие данные. Например: А вы правильно используете отчет? Этот вопрос следует особенно аккуратно задавать, чтобы не разозлить Заказчика ?, ведь он, конечно, ВСЕ делает правильно (на самом деле, 60% запросов именно по этой причине…). Не поставили фильтры/отборы (если хотели видеть только по себе, отделу, компании в целом и т.д.). Не ограничили период просмотра или даже не поняли какой установлен изначально. Не знают зачем отчет нужен и какую информацию выдает, так как не в курсе алгоритма, заложенного в расчет. Этот отчет сделан по алгоритму определенного отдела (со своей спецификой) и считает не так, как нужно для НАШЕГО Заказчика. |
2.3 |
«А чем Вас не устраивает текущий отчет?» |
«Он неудобный» (мой любимый ответ) |
Переход к следующему вопросу (п.3) |
Как мы выяснили выше, цепочка та же. |
3 |
«Что конкретно (какой показатель, поле, столбец) считается на Ваш взгляд неправильно и как должно быть?» |
А вот тут мы и набрели (и если повезет и Заказчик не будет «вредничать» — отвечать не объективно, а поймет, что мы с ним заодно) на проблему и очень хотим помочь! |
Скорее всего, на этом этапе мы найдем ответ, если задали все предыдущие вопросы и вариации в комментариях. |
Если все же итогом на вопрос не стала истинная первопричина или проблема, то продолжаем «бомбить» вопросами: «Зачем?», «Почему?», «Как должно быть?», «Какая проблема решается?», «Как это поможет вашей работе?» и др. |
Главное не сдаваться, но и не забывать показывать Заказчику, что мы в одной лодке и искренне хотим помочь, ведь он будет защищаться от вас всеми возможными способами, так как в его глазах вы хотите ему показать, что он не прав. Но цель у вас другая, и об этом очень важно помнить!
Кейс 2. Внедрите мне систему!
Предыстория: я ездила в командировку по выходу проекта в ОПЭ (опытно-промышленную эксплуатацию), и на обратном пути в поезде попутчик завел со мной стандартный разговор. Вопросы были из серии: «Куда держите путь?», «Куда ездили?», «Чем занимаетесь?». И как только он узнал, что я занимаюсь проектами по 1С, а тогда я специализировалась именно на конфигурациях 1С, воодушевленно изъявил желание внедрить в его компанию 1С.
В данном случае начнем нашу работу как бизнес-аналитика. Чтобы собрать пазл и не упустить детали, я начала уточнять издалека: чем занимается компания, какие процессы уже налажены, есть ли сейчас какая-либо ИС (информационная система), с какими проблемами сталкиваетесь, чем 1С сможет помочь бизнесу?
Из чего последовал рассказ, что у него небольшая ООО-шка. Компания занимается подрядными работами по строительству. Сейчас пользуются очень лайтовой версией бухгалтерии с ограниченным функционалом, а он хочет внедрить себе «что-нибудь» еще и «что-то» автоматизировать. В компании только 2 сотрудника: это он и бухгалтер. Все остальные (строители) работают по договорам подряда (временный найм, срочный договор) по потребности. Процессов, кроме его единоличного участия в тендере и дальнейшего оформления договоров, которые, не унифицированы вообще и, как оказалось, всегда разные и почти не повторяются кроме пары абзацев (что, конечно, странно, я бы занялась оптимизацией этого процесса, но запрос от него был другой в момент общения). Клиенты всегда разные и информацию по ним он не хранит, она ему не особо и нужна. Работает с данными БП легко, с проблемами не сталкивается, объяснить, зачем ему система, не может.
Итого: минимум процессов, небольшой штат и неунифицированные документы, а также отсутствие проблематик говорит нам о том, что потребности в автоматизации и внедрении целой системы нет. К тому же, это довольно дорогостоящее мероприятие. А после внедрения ничего не завершается, важно поддерживать систему, что тоже повлечет за собой затраты. Можно было бы предложить оформить шаблоны для подряда и внедрить ЭДО и CRM для работы с клиентами. В данном случае подошла бы даже бесплатная версия с ограниченным функционалом или любой аналог Excel в помощь.
Поэтому я его отговорила от полноценного внедрения. Поделилась рекомендациями, как следует выстраивать БП и полезными источниками информации. За что он по итогу был очень благодарен. Вот, что значит докопаться до сути проблемы (а ее нет, как выяснилось, за исключением шаблонов для договора) и не реализовывать все подряд! ?
В ходе стажировке разбираем такие примеры, учимся друг друга «допрашивать», формируем понимание, почему это важно и как следует решать подобные ситуации. Идеально, если начинающий аналитик уже это понимает! В проектах и задачах используют разные методы таких «допросов». Самый известный — «5 почему». Этим методом мы частично воспользовались выше, просто в других амплуа вопроса.
Я отразила в этих примерах основные проблемы, с которыми обычно сталкиваются аналитики, и продемонстрировала, как реально «докопаться до сути» проблемы, выявить и боли. Конечно, бывают задачи и проекты, где действительно нужно реализовать новый функционал или вносить изменения в старый, но ни одна из них, даже при внедрении совсем нового ПО, не обходится без глубокого анализа «зачем мы все это делаем». Он обязателен! Если не можете ответить на вопрос «какую именно проблему решаете и как это объективно поможет бизнесу?», то копайте дальше!
Надеюсь, если вы планируете развиваться в аналитике, то с этой информацией будет попроще.
А если вам интересно погрузиться в мир проектной деятельности в роли системного аналитика, узнать, как действительно ведутся проекты, какими инструментами пользуются аналитики, как грамотно взаимодействовать с Заказчиком, как разрабатывать техническую документацию, как обучать и тестировать, и как общаться с этими сложными, но такими умными разработчиками, то приглашаем вас на стажировку в «Автомакон»!
Сейчас мы расширяем штат кураторов стажировок. Если, ты системный аналитик, который готов помогать обучать «свеженьких» стажеров своему ремеслу, делиться своим опытом как бизнесовым, так и техническим, присоединяйся к нашей команде!
Делитесь своими лайфхаками в общении с заказчиками в комментариях.