Чем занимается бизнес-аналитик? А кто его знает: какая-то мутная профессия.
Это одно из заблуждений, которое — внезапно — высказывают не только клиенты… Но и коллеги внутри команды разработки, и даже сами аналитики.
Меня зовут Виктория Юльская. Я аналитик в компании Surf. Успела поработать с разными заказчиками на сложных и не очень проектах. Обучаю бизнес-анализу молодых коллег.
Собрала самые популярные заблуждения начинающих аналитиков о работе и взаимоотношениях с заказчиками.
Заблуждение №1. Без аналитика можно обойтись
Да, даже сами аналитики порой не понимают, зачем они нужны.
Заказчики часто говорят: «А зачем нам аналитик?», «Почему я, как заказчик, не могу передать вам требования, а вы по ним разработаете продукт?», «Еще один человек в команде потребует дополнительных трат». Иными словами, кажется, что вести проект без аналитика можно, а ТЗ написать может кто угодно — особенно, если есть шаблон.
Иногда аналитиков привлекают на защиту и «продажу» своей роли перед заказчиком. Будет нелишним вооружиться аргументами: сравним, как происходит работа без аналитика и с аналитиком.
❌ Без аналитика
Анализом занимается вся команда.
Проектные менеджеры выявляют верхнеуровневые требования и пишут ТЗ.
Дизайнеры бесконечно переделывают дизайн: «у нас это не так работает», всплывают новые требования при демонстрации и согласовании дизайна, и так по кругу.
Разработчики выявляют более детальные требования, вместо того чтобы писать код.
Тестировщики при проверке сборки к очередному релизу натыкаются на необработанные кейсы и опять возвращаются к выявлению требований. Бывает, что разработчик одной платформы уточнил требование, но до команды другой платформы оно не дошло. Получается разная реализация на платформах и последующие выяснения, а как правильно.
✅ С аналитиком
Аналитик обсуждает с командой дизайн и требования перед началом проекта: замечания и вопросы снимаются до старта разработки, принимаются архитектурно правильные решения. Они соответствуют требованиям заказчика и закрывают потребности пользователя.
Команда занимается своим делом и не тратит время на выявление требований.
Дизайнеры получают подробно выявленные требования. Они понимают, для чего эта задача, какую проблему она закрывает, какие данные необходимы и как всё должно функционировать.
Без такого анализа дизайнер может не учесть скрытую логику или понять её некорректно.
Аналитик с руководителем проекта следят, чтобы не выпадать из сметы и договора.
Разработчики по-прежнему что-то да находят — без этого никуда. Они озвучивают проблему — аналитик её решает. Разработчик занимается написанием кода — как и должно было быть.
Тестировщики обязательно находят разные нюансы, но это и хорошо: работа у них такая. Они не выявляют требования, а занимаются свои делом — тестируют и помогают донести до людей качественный продукт.
У команды есть «Энциклопедия проекта» в виде ТЗ и самого аналитика. Энциклопедия детально описывает логику и покрывает большое количество граничных кейсов. Аналитик всегда поможет, уточнит нюансы, подскажет, что требуется. Это точка синхронизации между разработкой и бизнесом.
В команде поддерживается единое инфополе. Все в курсе новостей и изменений в требованиях.
Когда аналитик сэкономил бы бюджет и сроки проектирования. Два примера
Первый пример. Команда без аналитика разработала прототипы на мобильное приложение. Заказчик дал фидбэк: это очень круто выглядит, но «у нас всё не так работает...» Пришлось полностью переделывать прототипы.
Аналитик бы сразу узнал, как всё работает, и переделывать не пришлось.
Второй пример. На проекте не было аналитика — изначально клиент не видел в нём смысла. Разработку вели по требованиям от заказчика в таск-менеджере. Они были достаточно поверхностные и не покрывали множества кейсов — это сказывалось в том числе на дизайне.
Команда выявляла требования в процессе разработки и тестирования. Из-за обилия доработок и крупных изменений в логике разработчики не уложились в бюджеты и сроки. Заказчик остался недоволен результатами, а команда — процессами.
Решили за свой счет подключить аналитика на проектирование некоторого скоупа задач, чтобы показать заказчику, насколько всё улучшится на проекте. Команда счастлива, сроки соблюдены, багов в разы меньше. Правда, заказчик от роли аналитика все равно отказался — не знаю, по каким причинам.
Так чем же всё-таки занимается аналитик. Мнение коллег
Попросила коллег из компании ответить на вопрос: «Чем, по-вашему, занимается аналитик? Как вам жилось бы без него на проекте?»
Команда, которая привыкла работать с аналитиком и познала все преимущества, видит эту роль так:
Android-разработчик: «Сбор и формализация требований, формирование ТЗ к разработке, ведение бэклога».
Тестировщик: «Собирает требования, пишет документацию, иногда занимается проектированием системы, является транслятором между заказчиком и разработкой, лучше всех знает поведение системы».
Flutter-разработчик: «Аналитик — это «мостик» между хотелками заказчика и возможностями разработчика. По сути он конвертирует спецификации в техническое задание».
Тестировщик: «Знаете, я очень часто оказывался в ситуациях, когда аналитика просто не было на проекте. Чувства были различные: и гнев с яростью, и грусть с безнадежностью. Разработчик, QA или PM могут выступать в роли аналитиков, но это разве делает проект лучше?
Мы только можем верить, что придет он — BA, и вытащит проект из пучин темной бездны. И тут на очередном созвоне говорят: „У нас будет аналитик со следующего спринта“. И сразу же жизнь начинала бить красками: ты понимаешь, что каждый занимается тем, чем и должен был изначально заниматься. Мы спасены, дальше нас ждёт светлое будущее».
Теперь у вас есть аргументы для заказчиков и коллег, зачем же на проекте всё-таки нужен «лишний рот» — бизнес-аналитик.
Заблуждение №2. Заказчик знает, чего хочет
Далеко не всегда заказчик знает, чего хочет.
Зачастую он озвучивает абстрактные требования или сразу мыслит решением: «Хочу отзывы, как в озоне». При этом что именно нужно сделать, непонятно. Варианты:
«Отзывы как в озоне» нравятся визуально. При этом функционально нужно не всё, и заказчик не готов платить за избыточные возможности.
Нравится функциональная составляющая, а визуальное решение не подходит.
Показалось, что «отзывы на озоне» — эталон. Потом выясняется, что в них нет функциональности, которая нужна заказчику. И работают они совсем не так, как он представлял.
Заказчику нужно решить бизнес-проблему, но у него не всегда получается грамотно её сформулировать. Задача аналитика — помочь выявить проблему и выработать решение, которое учтёт требования бизнеса, потребности пользователей, архитектурные нюансы, впишется по бюджету.
Если же молча сделать по первоначальному требованию «Хочу отзывы, как в озоне», реальная потребность или проблема заказчика закрыты не будут. Заказчик останется недоволен результатом, а вину за это повесит на команду разработки во главе с аналитиком. Аргументы «Мы делали по требованиям» не помогут сгладить негатив заказчика.
Важно внимательно относиться к бизнес-требованиям. Чтобы выявлять реальную боль заказчика, рекомендую задавать больше вопросов «Почему? Зачем? Какую проблему мы хотим закрыть? Каких результатов добиться?». Да, такие вопросы могут выглядеть в глазах заказчика глупо (и в этом нет ничего страшного!). Но гораздо более глупо будет, если команда сделает совсем не то, что хотел клиент.
Заблуждение №3. Заказчик озвучил решение. Отлично, так и делаем
Стоит насторожиться, когда заказчик приходит сразу с готовым решением: «Хочу, чтобы корзина была локальной». Да, локальные корзины делают — технически в этом нет проблем.
Но давайте не будем сразу бежать реализовывать фичу. Для начала уточним детали: какой функциональностью обладает корзина. Оказывается, там должны быть:
Промокоды, которые могут «протухать», заканчиваться и так далее.
Баллы, которыми можно оплатить процент от стоимости заказа.
Данные для оформления заказа.
Управление через платформу автоматизации маркетинга типа loymax или mindbox: они делают свои предрасчеты, а не просто отдают размер скидки по промокоду.
Всё это — в мобильном приложении. В дело вступает критическое мышление: из опыта понятно, что много что может пойти не так. Стоит узнать:
Почему корзина должна быть локальной?
Какую проблему закрываем этим решением?
Допустим, заказчик хочет обеспечить быстрый доступ к корзине без загрузок, но не в курсе рисков, которые несёт локальная реализация. Например, он не знает, что локальная корзина — это куча логики и расчётов, и любые изменения должны будут проводиться через релиз. Работа с деньгами это всегда риски, и если её править через релиз, это больно втройне.
Хорошо бы озвучить заказчику эти нюансы. Может оказаться, что гибкость и безопасность важнее быстрой загрузки корзины. А быструю загрузку корзины можно реализовать другим способом, который не будет настолько рискованный.
Заблуждение №4. Заказчики внимательно читают ТЗ
Нужно быть готовым, что далеко не все заказчики внимательно читают ТЗ, а некоторые и вовсе не читают. Зачастую заказчика дёргают со сроками согласования. В такие моменты ему наверняка хочется, чтобы от него побыстрее отстали. Так получается долгожданное «Согласовано» или принимается решение стартовать разработку без согласования с фразой «Концептуально ок, стартуем».
На самом ли деле слово «Согласовано» означает, что ТЗ согласовано? Спустя некоторое время начинаются замечания, доработки, высказывания: «Должно было быть не так» и «Я не так себе это представлял».
Мы выработали другой способ доносить информацию из ТЗ до заказчика: вместо десятков страниц текста мелким кеглем делаем демо.
Перед встречей отправляем заказчику ТЗ, но не ожидаем, что он его внимательно изучит.
На встрече демонстрируем дизайн. Голосом проговариваем требования, логику и обработку граничных кейсов, которые зафиксированы в ТЗ.
Заказчик высказывает замечания и уточнения или подтверждает, что всё отлично.
Замечания устраняем, отправляем итоговое ТЗ на согласование и ждём согласования.
Да, времени занимает больше, чем просто прочитать ТЗ и получить формальный «ок». Но насколько же это эффективнее. Согласование ТЗ теперь приятный процесс и для исполнителя, и для заказчика. Мы смотрим картинки будущего приложения и детально представляем, как оно будет работать, а не просто читаем портянку текста.
Если нет возможности выделить время на демо и общение происходит в почте (так бывает в банках), есть альтернативный способ получить подтверждение требований:
Продумать все тонкие и спорные места. Задать по ним уточняющие вопросы в формате «Верно я понимаю…?».
Заказчик подтверждает требование или уточняет детали.
Список утверждений в духе «Раз в 5 минут обновлять список задач», «Если в списке получаем новые задачи, то на вкладке задач отображать анимированный индикатор» при таком подходе не работает, потому что очень уж похож на сжатое ТЗ. А вот список вопросов по узким местам помогает хорошо.
Заблуждение №5. Менять требования нельзя, они согласованы
На проекте может случиться что угодно: нашли что-то критичное, появились новые вводные и согласованная логика уже не совсем подходит, изменились приоритеты — требования можно изменить, и в этом нет ничего страшного.
Да, команде это может не понравиться: разработка уже идёт или, что ещё «лучше», задача выполнена. Но это не проблема заказчика — это проблема исполнителя.
Тут главное, чтобы менеджер грамотно обрабатывал вбросы от заказчика (особенно если оплата за проект фиксированная), а аналитик — грамотно управлял изменениями.
Перед тем как брать в работу очередное изменение требований, советую включить критическое мышление и вспомнить, что клиент далеко не всегда знает, чего хочет. Поэтому стоит предварительно тщательно допросить заказчика. Начинаем всё сначала: «Почему? Зачем? Какую проблему хотим закрыть? Каких результатов добиться?» Может оказаться, что на самом деле клиенту это не нужно или нужно не это.
О чём помнить начинающему аналитику
Иногда важность роли аналитика на проекте приходится обосновывать самому аналитику. Для этого нужно быть во всеоружии. Например, суметь рассказать клиенту, как ведётся работа без аналитика и с ним. Расписать, что со сроками и бюджетом, сколько людей будут дёргать клиента с глупыми вопросами с разных сторон и так далее. Показать, что, хотя наличие аналитика формально увеличивает стоимость проекта, на самом деле даёт экономию: команда завершит разработку ровно в срок, продукт получится качественный.
Во взаимодействии с клиентом всё совсем не так, как кажется на первый взгляд. Даже если заказчик говорит убедительно, сыпет решениями и просит вас побыть только «рабочими руками» и реализовать фичу (ведь сам-то он кодить не умеет) — не ведитесь, это ловушка. Опыт показывает, что заказчики довольно редко знают наверняка, чего хотят. И самое неприятное: в неудачных результатах они будут винить команду разработки.
Заказчики не читают ТЗ. Точнее, может, они и читают, но не могут сразу предусмотреть все нюансы. Нужно иметь хорошее воображение, чтобы по черным буквам на белом листе представить, каким будет будущий продукт. Поэтому лучше помочь заказчику визуализировать, как всё будет выглядеть и работать: например, с помощью демо.
Менять изначальные требования можно и нужно. Если появляются новые вводные или меняются приоритеты, не стоит упираться в «как написано и утверждено на бумаге, так и делаем». Качество и успех продукта — прежде всего.
Комментарии (30)
panzerfaust
09.12.2021 09:43+5Какая животрепещущая лично для меня тема. К сожалению, за 7 лет в разработке встретилось всего пара аналитиков, которым по итогу работы хотелось пожать руку. Остальные по факту оказывались джунами-копирайтерами, которые только и могли что переносить мысль "делайте хорошо, плохо не делайте" из головы заказчика в задачу в джире.
Для себя выделил 3 критических пункта:
В разработке ПО нет слова "подразумевается". Подразумеваться могут только стандарты вроде использования HTTP в рестовой архитектуре. Поэтому в ТЗ должны быть даже те вещи, которые лично вам кажутся трижды очевидными. Разработчик не имеет (пока) доступа к вашему разуму.
Нужно обязательно хотя бы в общих чертах понимать архитектуру современных систем, модели и протоколы их взаимодействия. Иначе в ТЗ гарантированно будет оторванная от реальности дичь и испорченные отношения с инженерами
В статье сказано про "энциклопедию проекта" - а я добавлю, что еще необходим и глоссарий проекта. Одна и та же вещь в разных местах проекта должна называться одинаково. Это должно быть закреплено на самом верху и строго соблюдаться повсеместно.
yulskaya_victoriya
10.12.2021 11:25Да, вы правы, в разных компаниях под роль аналитика зачастую закладываются разные обязанности. В одном месте аналитик - это тех.пис по факту, в другом - ребята которые пишут требования, а в третьем погружение вплоть до проектирования API и баз данных.
Молодых специалистов мы стараемся контролировать первое время и ревьюить их артефакты, чтобы требования соответствовали нашим критериям качества.
Спасибо за дополнения. Перечисленные критические пункты, действительно, правильные и первые два можно раскрыть подробнее в следующих статьях.
Про глоссарий в точку!
Timsuleimenov
09.12.2021 10:11Хорошая статья, сам недавно проходил собеседование на вакансию аналитика, в крупной организаций, а так как должность тока появилась , директор сам точно не понимал чего хотел от аналитика, сводил всю суть работы на анализ ёмкости рынка и простой призентаций в мастер поинт.
Я же думаю аналитик должен знать всю цепочку создания стоимости, и работать на всех участках
yulskaya_victoriya
10.12.2021 12:39От компании к компании задачи и обязанности могут (и будут) отличаться. Мы постарались собрать основные моменты в работе аналитика.
Надеемся, материал вам был полезен.
hungry_forester
09.12.2021 10:12+3Есть профессиональный стандарт "бизнес-аналитик" и есть "системный аналитик", полезно почитать, чтобы не порождать описания кентавров. Ну и чтобы ответственно заявлять, что вы по факту работаете за троих (за РП тоже ведь, наверное, ну чуточку... или за четверых?)
yulskaya_victoriya
10.12.2021 12:34Конечно, есть профессиональный стандарт и определения «бизнес-аналитик», «системный аналитик», но много компаний работают именно с fullstack аналитиками. Мы пытались абстрагироваться от этих определений и использовать просто - аналитик.
Эта тема очень дискуссионная и у нас с обеих сторон найдется много аргументов, но такие «кентавры» работают и имеют право на жизнь.
Лучше ли такой подход? Я уверена, что нет (также как один frontend и один backend разработчики будут лучше одного fullstack). Но есть на то причины, видимо, если таких аналитиков достаточно много на данный момент.
И небольшой плюс - молодые специалисты могут на себе прочувствовать и понять, что им ближе по духу - быть fullstack аналитиком или развиваться в одном из направлений :)
Oriolidae
09.12.2021 11:36Нужно больше заблуждений:
Стандартизация - зло - каждое решение должны быть уникальным
Не писать в ТЗ очевидные (для аналитика) по итогам общения вещи
ТЗ лишнее, если есть переписка в мессенджере
Формировать ТЗ под конкретного разработчика это правильно
yulskaya_victoriya
10.12.2021 12:44+1Благодарю за дополнения.
Данная статья направлена больше на коммуникации с заказчиками и есть планы раскрывать остальные стороны работы аналитика
dedmagic
09.12.2021 12:29+3> Но это не проблема заказчика — это проблема исполнителя.
Ну здрастити! Тогда заказчик будет вообще не переставая менять требования.
При возникновении такой ситуации говорим: "Мы, конечно, всё переделаем, как Вы хотите, но это обойдётся Вам в ХХХ тугриков". Очень хорошо отрезвляет и заставляет заказчика в будущем больше думать над формулированием своих требований.
IOstream
10.12.2021 10:03Или ванговать "доработки" и сразу закладывать их в стоимость. Но риски остаются.
dedmagic
10.12.2021 11:02Причём очень большие, ибо предсказывают будущее люди ну оооочень плохо.
yulskaya_victoriya
10.12.2021 13:11Немного вырвана фраза из контекста :)
Да, команде это может не понравиться:..
Но это не проблема заказчика — это проблема исполнителя.
То, что это не нравится команде - наша проблема. То, что меняются требования - это в принципе не проблема. Главное правильно обработать эти изменения.
Абсолютно согласна с вашими комментариями.
Мы предсказывать не можем, мы можем только выявлять и сегодня это работает так, а завтра что-то добавили (этого не было, но это окажет положительно влияние) / переделали.
И если это доработка, конечно, она проходит через фразу «Мы, конечно, всё переделаем, как Вы хотите, но это обойдётся Вам в ХХХ тугриков». Но! Перед этим аналитику стоит узнать что за изменение, для чего и какую проблему решит. И возможно его и оценивать команде не придется, потому что эта доработка ничего не дает и получится работа ради работы.
Дальше уже работа PM-а - провести это через бюджеты, запланировать в спринт и тд.
dedmagic
10.12.2021 13:29+1Значит, я неправильно понял, у меня после прочтения сложилось впечатление, что "изменение требований в процессе (или тем более после) разработки – это не проблема заказчика, а проблема исполнителя".
Был неправ, вспылил. Но теперь считаю своё предложение безобразной ошибкой, раскаиваюсь, прошу дать возможность загладить, искупить. Всё, ушел.
:)
Bedal
10.12.2021 14:42Тогда заказчик будет вообще не переставая менять требования.
Наш любимый заказчик (20 лет взаимодействуем) выдал как-то «Надо было делать не то, что написано в согласованном ТЗ, а то, что мы имели в виду».«Мы, конечно, всё переделаем, как Вы хотите, но это обойдётся Вам в ХХХ тугриков». Очень хорошо отрезвляет
Замечательно. Заказчик тупо не заплатит. Или откажется вообще, или потом выкатит миллионную неустойку за неработоспособность, в договоре соответствующее примечание найдётся. Отрезвлять заказчика полезно, когда есть в запасе другой.
Короче говоря, нет здесь идеального решения «делай, как написано, и всё получится».
Но, всё же, предложу: нужно понимать заранее, что так будет, и в стоимость всех работ сразу закладывать расходы на доработки. А не радовать исходно заказчика низкой ценой.dedmagic
10.12.2021 15:01+1Наш любимый заказчик (20 лет взаимодействуем) выдал как-то «Надо было делать не то, что написано в согласованном ТЗ, а то, что мы имели в виду».
Ну т.е. из-за того, что попадаются неадекватные заказчики (а они, конечно же, есть) Вы предлагаете всегда изменение требований постфактум считать проблемой исполнителя?
потом выкатит миллионную неустойку
Мы ведь говорим о требованиях, которые были заказчиком утверждены и подписаны, так? Поэтому юридически неа, он бессилен.
в стоимость всех работ сразу закладывать расходы на доработки
Как вариант – почему бы и нет? Но и в этом подходе есть минусы:
Из-за изначально более высоких цен теряем часть потенциальных заказчиков.
Т.к. речь идёт о предсказании будущего, мы будем регулярно промахиваться. И работать в таких ситуациях себе в убыток.
Bedal
10.12.2021 15:31Ну т.е. из-за того, что попадаются неадекватные заказчики (а они, конечно же, есть)
Заказчика, с которым успешно работаем двадцать лет, выполнили десятки проектов — считать неадекватным? Только из-за того, что Вы не поняли, что жизнь не укладывается в примитивные правила? Не-е-е, я не согласен.Вы предлагаете всегда изменение требований постфактум считать проблемой исполнителя?
Это де-факто так. И нужно это понимать до начала любых переговоров, включать в риски и учитывать в стоимости. Тупо накидывая проценты к каждому пункту сметы. Тогда и вы (мы) имеем, на что выполнять хотелки, и заказчик не будет считать нас (вас) капризными неумёхами.
Другое дело — продажа «изкаропки». Там что есть, то есть, никаких доработок и изменений цены.Но и в этом подходе есть минусы:
И на Солнце есть пятнаИз-за изначально более высоких цен теряем часть потенциальных заказчиков.
Альтернативы просты: или обманывать заказчика, вымогая у него деньги сверх оговоренного, или работать забесплатно.Т.к. речь идёт о предсказании будущего, мы будем регулярно промахиваться. И работать в таких ситуациях себе в убыток.
Если Вы думаете, что увеличение стоимости после заключения договора создаст разработчику хорошую славу и приведёт новых заказчиков / новые договоры — Вы безудержный оптимист.
Рецепт «каша из топора» — одноразовый, второй раз не позовут готовить.
dedmagic
09.12.2021 12:32Дизайнеры получают подробно выявленные требования. Они понимают, для чего эта задача, какую проблему она закрывает, какие данные необходимы и как всё должно функционировать.
Без такого анализа дизайнер может не учесть скрытую логику или понять её некорректно.
Вот здесь непонятно. Если речь идёт про дизайнеров пользовательского интерфейса, то зачем им знать про данные и скрытую логику?
Может быть подразумеваются проектировщики ПО?
yulskaya_victoriya
10.12.2021 13:56Если рассмотреть на примере:
Карточка товара. Чтобы ее отрисовать необходимо понимание, что в эту карточку вообще закладывается функционально и по данным (картинка, шильдики, название и тд).
Дизайнер отрисовывает дизайн по данным, которые собрал с карточки на сайте (это хорошо если есть сайт). Оказалось, что на некоторой обуви есть выбор ширины стопы (стандартная / узкая / широкая). Это нужно отразить в дизайне в нужном месте, а разработчикам отразить в приложении.
Также на дизайн влияет и формат данных - размерная таблица, например, картинкой или отдельными параметрами, которые нужно будет сверстать в таблицу. И такие нюансы нужно донести до дизайнера.
Когда аналитик ставит задачу - дизайнер знает, что есть ширина стопы и что размерная таблица параметрами, которые нужно свести в таблицу, например.
Опять же, в других компаниях могут отличаться процессы и обязанности, мы стараемся делать так, чтобы минимизировать доработки по всем фронтам.
dedmagic
10.12.2021 14:05Когда аналитик ставит задачу - дизайнер знает, что есть ширина стопы и что размерная таблица параметрами, которые нужно свести в таблицу, например.
Так вот и я о том, что это аналитик должен знать и учитывать скрытую логику, и вообще бизнес-логику и бизнес-данные. Это он знает, для чего эта задача, какую проблему закрывает и т.д.
Разработчики получают задание в уже очень рафинированном виде, им всё это знать совершенно не нужно. У разработчиков есть свой, огромный пласт знаний – внутреннее устройство системы, и аналитик нужен, в том числе, чтобы разработке не требовалось глубокое погружение в предметную область и бизнес-процессы. Иначе перегрузка и взрыв головного мозга :).
noodles
11.12.2021 14:18Вот здесь непонятно. Если речь идёт про дизайнеров пользовательского интерфейса, то зачем им знать про данные и скрытую логику?
Имхо, я вообще за то, чтоб дизайнер и аналитик был одним человеком. В идеале, чтоб "выгоревшие/уставшие" продуктовые дизайнеры с многолетним опытом шли именно в аналитики, а не в разработку (как советует каждая статья типа "дизайнер vs верстальщик").
Мне кажется, консолидация навыков дизайнера и аналитика в одной голове может дать крутой выхлоп. Фишка в том, что присловесном поносе заказчикасборе требований - он уже на подсознании будет мыслить экранами и пользовательскими сценариями.
При этом не обязательно ему также отрисовывать всё самому. Он может иметь джунов-дизайнеров в подчинении, или точечно отдавать на аутсорс рутину (правильно формулируя требования).
Kwisatz
09.12.2021 13:32+1На первом пункте то что вы прописали без аналитика будет и с аналитиком но в чутьм еньших масштабах. Ну и точно не в случае с джуном.
yulskaya_victoriya
10.12.2021 14:15Вы правы.
Здесь акцент хотелось сделать на ТЗ, а когда оно состоит из верхнеуровневых требований следует много вопросов от команды, а уточнения тоже требуют времени.
В случае с джунами - мы стараемся их контролировать первое время и ревьюить их артефакты, чтобы требования соответствовали нашим критериям качества.
Kwisatz
10.12.2021 16:12Тут все зависит от подхода, я к ТЗ отношусь крайне критически. Потому что, для создания всеобъемлющего тз, которое к тому же действительно удовлетворяет заказчика, а не транслирует его глюки, нужен чудовищный опыт.
Выше достаточно неплохо на эту тему написали, что заказчик выдал «Надо было делать не то, что написано в согласованном ТЗ, а то, что мы имели в виду». И именно это всем и нужно. Причем зачастую избавиться от шелухи «требований» очень тяжело, поскольку требования подаются как непоколебимые.
И это кроме того, что в действительно хороших продуктах (а мы же все стремися стать крутыми специалистами?) нужно использовать лучшие, а не массовые решения, что вообще отдельный квест.
meirinkun
10.12.2021 10:33Кажется, статью стоит назвать "Топ заблуждений об аналитиках в Surf_studio". Ваши примеры очень частные и каждый из них может быть опровергнут.
Почему проектный менеджер не может опросить заказчика и выявить требования на достаточном уровне? Для этого не требуется каких-то сверхъестественных методик и можно сэкономить зарплату на аналитика.
Также - если заказчик самостоятельно внятно составил свои требования, которые понятны команде разработчиков, QA и дизайнеров, то зачем тратить деньги на аналитика?
Разработчики - это не операционисты для "написания кода". Они должны хотя бы поверхностно вникнуть в предметную область и куда глубже в объектную модель, в потоки данных и пр. и по итогу спроектировать решение. Они в любом случае будут анализировать требования и синтезировать решение. Аналитик в этом их не заменит.
panzerfaust
10.12.2021 11:43Также - если заказчик самостоятельно внятно составил свои требования, которые понятны команде разработчиков, QA и дизайнеров, то зачем тратить деньги на аналитика?
А если младенец сам умеет готовить еду и гулять, то можно не тратить деньги на няню. Но увы. Часто вам такие заказчики попадались?
У меня есть опыт работы в команде без аналитика вообще. Жить-то, конечно, можно, но быстро приходим к тому, что аналитиком становится самый грамотный разработчик или QA. Естественно, без всяких доплат.
meirinkun
10.12.2021 13:07Есть внутренние заказчики, которые обладают необходимой экспертизой в предметной области, могут просмотреть аналоги решений, могут составить требования и обосновать их. И мало того, они еще спросят реализацию этих требований при приемочном тестировании и не примут работу, если вдруг кто-то решил их изменить.
Мне попадались внятные заказчики, я потому и ставлю под сомнение применение этих "заблуждений" на всех аналитиков.
Куча крутых продуктов создают команды грамотных специалистов без аналитиков. Я сам будучи аналитиком порой не понимаю, зачем меня принимают в команды, которые и так хорошо решают задачи. Приходится их покидать.
Сейчас роль аналитика трактуют настолько широко от команды к команде, что я пока прихожу к выводу, что так называемым "аналитиком" закрывают дыры в грамотности специалистов и заказчиков и коммуникациях между ними из-за низких требований, предъявляемых этим специалистам. И это не затрагивая деления на бизнес- и системных аналитиков - там вообще беда с пониманием.
yulskaya_victoriya
10.12.2021 14:46+1Есть в ваших словах доля правды, от компании к компании роли и обязанности отличаются. И есть достаточно хорошие компании, в которых нет аналитиков вовсе и они выпускают качественные продукты.
Плюс к тому же это зависит еще и от сложности проекта. Без аналитиков сделать мобильный банк или систему для мониторинга, планирования и управления бизнес-процессами, я думаю, будет достаточно сложно - много нюансов.
Мы постарались ответить в статье на вопрос зачем тратить деньги на аналитика и, конечно, мнения могут расходиться. Не с пустого места же взялись эти заблуждения :) Эта тема сама по себе очень холеварная и мы часто слышим такие слова.
Если подытожить, то без аналитика работать можно, но без анализа нет, он так или иначе будет. Вопрос в том, кто и как будет этим заниматься.
А на замену разработчиков никто не претендует и, конечно, их участие на этапе проектирования необходимо и все перечисленные активности разработчиков никто не отменяет. Но у них в таком случае на порядок больше входных данных.
sergeyns
Вы же его сами предоставили бесплатно, он и понадеялся на дальнейшую халяву
yulskaya_victoriya
Как вариант.
Мы делали это для того, чтобы наглядно показать заказчику разницу.
На словах не достучались, пришлось показывать действиями и цифрами.
Решение в любом случае принимать заказчику, нам главное донести ценность (в качестве исключения - продемонстрировать) и попытаться улучшить условия для нашей команды, потому что команда занимается не только своим делом.
И обычно цифры и результат дают хороший результат, но не в этом случае)