{"id":14277,"url":"\/distributions\/14277\/click?bit=1&hash=17ce698c744183890278e5e72fb5473eaa8dd0a28fac1d357bd91d8537b18c22","title":"\u041e\u0446\u0438\u0444\u0440\u043e\u0432\u0430\u0442\u044c \u043b\u0438\u0442\u0440\u044b \u0431\u0435\u043d\u0437\u0438\u043d\u0430 \u0438\u043b\u0438 \u0437\u043e\u043b\u043e\u0442\u044b\u0435 \u0443\u043a\u0440\u0430\u0448\u0435\u043d\u0438\u044f","buttonText":"\u041a\u0430\u043a?","imageUuid":"771ad34a-9f50-5b0b-bc84-204d36a20025"}

Как не потратить деньги на аналитику зря

В ИТ-отраслях принято считать, что аналитика — основа любого проекта и без неё шагу ступить нельзя. Но на самом деле это не так.

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

Примерно все ИТ-проекты начинаются с аналитической части. Это относится и к разработке программ, и к рекламе, и к созданию дизайна.

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

Иногда это звучит как «сначала мы составим техзадание». В общем, исполнитель изучит предметную область и поймёт, с чем будет работать.

Результатом будет очень много полезных для проекта документов.

Жаль, что это не совсем правда.

Что не так с аналитикой

Универсальной схемы аналитики не существует. Она должна быть уникальной для каждого проекта. Все методички врут, когда говорят: «Сделайте вот это вот таким способом, потом — вот это, затем — то. Так вы получите аналитические документы». Это всё неправда. Ничего вы не получите.

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

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

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

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

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

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

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

Почему все исполнители настаивают на аналитике

Во-первых, так можно показать, что мы не только руками работаем, но ещё и думаем. Конечно, это самообман.

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

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

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

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

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

Исследование окружающего мира — не аналитика.

Вы предлагаете отказаться от аналитики?

Нет.

Просто к аналитике нужно относиться с лёгкостью. Это не догма и не фундамент.

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

Но собирать массивы информации и тянуть время — путь к провалу.

Роль фазы аналитики в том, чтобы сказать: мы готовы начать. А потом войти в цикл: что-то узнаём, планируем, делаем, сверяемся с планом, снова что-то узнаём, планируем, делаем, сверяемся, уточняем план. И так по кругу.

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

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

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

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

Задавать глупые вопросы в середине проекта — нормально.

Что же делать заказчику

Если исполнитель продаёт аналитику, надо спрашивать у него, как использовать результаты этой фазы. Когда мы их используем? Допустим, заказчику навязывают анализ конкурентов. Он должен спросить: «Ладно, а где вы будете это использовать? Зачем вам изучать конкурентов?».

Конечно, это так себе фильтр. Особенно когда абсолютно все продают аналитику и настаивают на её необходимости. Но эти вопросы хотя бы помогут понять, справится ли команда исполнителя с фазой.

Правда же такова, что заказчику в любом случае нужно самому участвовать в аналитике. Вместе с исполнителем. Даже больше: они должны погружаться в мир друг друга и искать точки взаимодействия. Фактически заказчик должен «продать» свой проект команде исполнителя.

Заказчик должен «продать» свой проект команде исполнителя.

Зачем? Дело в том, что нормальный исполнитель обезличенно ничего делать не может. У него не конвейер. Чтобы создавать что-то для конкретного заказчика индивидуально, нужно с ним познакомиться, поверить в него, настроиться, понять особенности и нюансы. То есть отойти от ситуации анонимной штамповки.

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

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

Аналитика — это фаза, растянутая на весь проект, в которой заказчик продаёт проект команде исполнителя и помогает ей найти инсайты.

0
5 комментариев
Eugene Poplavsky

В ИТ-отраслях принято считать, что инженерная культура — основа любого проекта и без неё шагу ступить нельзя. Но на самом деле это не так.

В ИТ-отраслях принято считать, что дизайн — основа любого проекта и без неё шагу ступить нельзя. Но на самом деле это не так.

В ИТ-отраслях принято считать, что QA — основа любого проекта и без неё шагу ступить нельзя. Но на самом деле это не так.

Ответить
Развернуть ветку
Vladimir Ivanov

Херак херак и в продакшен! И нефиг тут того самого!

Ответить
Развернуть ветку
Z Z

Само собой! Все эти нахлебник, ходят тут, что-то думают - вышвырнуть. Что тут думать, как говориться? Затусим с правильными ребятам, сайтик расскрутим, рекламки побольше. И все.. Бабло потечет, там еще и больше рекламки закупим. Не жизнь, а сказка.
А потом ваще учить будем всех. Нести людЯм знания, ёпта.

Ответить
Развернуть ветку
Mkha Stas

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

Ответить
Развернуть ветку
Denis Beskov

Хороший свежий взгляд, только непонятно, почему «мы не исследуем мир клиента»

Ответить
Развернуть ветку
2 комментария
Раскрывать всегда