В чем разница между бизнес-аналитиком и системным аналитиком в IT и какие ошибки чаще всего совершают заказчики на старте разработки продукта? Сегодня опытом и знаниями с нами делится Дарья Ямная, к.т.н. и начальник отдела бизнес-анализа Softvoya.
Кто такой бизнес-аналитик в IT? Опишите его основные функции вне зависимости от рода деятельности компании.
Дарья: Если коротко, бизнес-аналитик – переводчик между бизнесом и командой разработки. Его основные задачи: выявить истинные потребности заказчика и сформулировать решение с учетом ограничений. Качество решения существенно влияет на проект, т.к. любую потребность пользователей можно решить совершенно разными путями от простого до сложного, что влияет на стоимость разработки.
В дальнейшем бизнес-аналитик разрабатывает подробное техническое задание и сопровождает команду разработки от старта до сдачи готового продукта заказчику. Иногда бизнес-аналитики участвуют в приемочном тестировании продукта, проверяя соблюдение бизнес-логики: верна ли реализация, дает ли функция ту ценность, которая в нее заложена, учтены ли все ограничения.
Какими знаниями и компетенциями должен обладать бизнес-аналитик?
Дарья: Первое, что жизненно необходимо, это системное мышление и аналитический склад ума.
Бизнес-аналитики — это люди, которые смотрят, например, на часы и видят их подкапотное пространство: шестеренки, винты, пружины, понимают, как отдельные элементы взаимодействует между собой и почему часы показывают правильное время.
Системное мышление — это видеть картину продукта целиком, понимать, как каждая функция, объект и его атрибуты влияют на единую систему и цель разработки этой системы.
Второе, что необходимо, это коммуникативные навыки. Бизнес-аналитик — тот редкий экземпляр человека, который, обладая системным мышлением и аналитическим складом ума, любит общаться, ведь минимум 30, а иногда и все 70 процентов его рабочего времени – это общение: коммуникация с клиентами, командой разработки, умение расположить к себе людей, умение договариваться, умение гасить конфликты.
Третье – помимо устной, важна хорошая письменная коммуникация. В нашем деле краткость – сестра таланта: умение тезисно, максимально коротко донести каждое требования, чтобы не нагружать команду разработки и заказчика изучением большого количества мало информативной документации.
Четвертое, важное качество бизнес-аналитика – перфекционизм: мы не говорим о трате времени на красоту документации, мы говорим о непреодолимом желании добраться до сути потребности, функции, требования, что позволяет формулировать простые решения, которые идеально ложатся в логику системы, решая сформулированную проблему с минимальными затратами.
Пятое – это знание бизнеса и понимание основ юнит-экономики. Каждый клиент хочет, чтобы его понимали с полуслова и были с ним на одной волне, мысля категориями: расходы, доходы, издержки, прибыль, монетизация.
Шестое – обучаемость. Если бизнес-аналитик не знает домен продукта, он должен обладать гибким умом и уметь анализировать огромное количество информации в короткие сроки, чтобы изучить его, т.к. без знания домена можно впустую тратить время на изобретение того, что уже давно есть на рынке.
В каких областях специализируются бизнес-аналитики Softvoya? Если ли узкие доменные области, в которых вы работали?
Дарья: Особенность нашей компании в том, что мы в-первую очередь продуктовая компания. У нас есть свой, достаточно крупный внутренний продукт: upservice.com – онлайн-офис для малого и среднего бизнеса, а также проекты на аутсорсинге. Как продуктовая компания, мы понимаем подводные камни и можем их предусмотреть, разрабатывая продукты на заказ.
Наша специализация – разработка систем сегмента b2b и c2b: CRM, ERP. Общая особенность этих продуктов – сокращение издержек. Пример из CRM: компании могут бесконечно вкладываться в рекламу, привлекая новых лидов, не задумываясь, что гораздо дешевле и эффективнее иметь лояльную базу клиентов, которые будут сами возвращаться за новыми покупками и привлекать дополнительный трафик лидов, рекламируя вашу компанию.
Не смотря на нашу специализацию, мы разрабатываем продукты и других доменов: аренда техники, каршеринг, приложение для знакомств, прогнозы букмекеров, тендерные площадки и пр. Наша команда разработки заинтересована в разработке качественных продуктов под ключ, поэтому мы помогаем Заказчикам из идеи сформировать видение продукта, который будет востребован рынком.
Из необычных продуктов, могу привести в пример приложение для бровистов. Цель этого продукта – реализация косметики для бровей.
Интернет-магазином уже никого не удивишь, клиенты хотят индивидуального подхода.
Проанализировав, как бровисты строят идеальный контур бровей в зависимости от анатомии лица, мы обучали нейросеть, которая по фотографии человека строит его идеальный контур бровей. После этого сопоставив идеальный контур и реальный нейросеть предлагает подходящие продукты для этого человека, что обеспечивает персональный подход к продажам. Придя в магазин, вы можете не знать, что конкретно вам купить, в то время как созданная нами нейросеть сама подстраивает интернет-магазин под ваши потребности и индивидуальные особенности. Это повышает лояльность клиентов – они видят, что магазин ориентирован именно на них.
Конечно, мы занимается и простыми продуктами: интернет-магазинами, маркетплейсами – от простых до сложных. Любой, даже простой продукт имеет свою специфику и свой “изюм”, который становится его конкурентным преимуществом.
Довольно часто встречающийся вопрос: в чем разница между бизнес-аналитиком и системным аналитиком в IT?
Дарья: Я не поддерживаю разделение этих двух ролей на проектах за исключением случаев, когда оно жизненно необходимо. Например: требуется детальная проработка правил обмена большим массив разнородных данных между несколькими системами. Такая проработка требует большого количества времени, вследствие чего бизнес-аналитик может физически не успевать сформировать техническое задание.
Изначально именно бизнес-аналитик является посредником между заказчиком и командой разработки, но есть проекты, на которых есть посредник между бизнес-аналитиком и командой разработки. Бизнес-аналитик общается с бизнесом, формулирует пользовательские требования и ограничения, но не спускается на уровень функциональных требований. Это техническое задание он передает системному аналитику. На этом роль бизнес-аналитика на продукте фактически заканчивается, он продолжает общаться только с заказчиком по запросу системного аналитика или для презентации решений. Системный аналитик описывает требования более детально, спускаясь на уровень функциональных и нефункциональных требований к системе и формирует техническое задание для команды разработки.
Я придерживаюсь того, что на свои проекты мы ищем системных аналитиков: как я уже говорила, первое требование к аналитику — системное мышление, второе – понимание технических вопросов. Аналитик должен понимать, как система работает “под капотом”. Мы ищем системных аналитиков, которые обладают хорошими коммуникативными навыками, и желательно с опытом в бизнесе. Без понимания бизнеса мы не ответим на вопросы: для чего этот продукт и какую-то пользу он принесет его основателям, а без этого нельзя спроектировать хорошую систему. Конечно, мы проводим обучение сотрудников, тем не менее, когда человек не разбирается в работе системы и у него нет системного мышления, он будет ставить невыполнимые требования на разработку и на выходе вы получите не цельный качественный продукт, а франкинштейна. У нас пока нет необходимости в посредниках между бизнес-аналитиками и командой разработки, все наши бизнес-аналитики это, в том числе, и системные аналитики, которые разбираются в том, как устроена система.
Насколько различается роль и функции бизнес-аналитиков в зависимости от рода деятельности компании? Например, в IT аутсорсинге, продуктовых, SaaS-компаниях или компаниях, не связанных с разработкой ПО.
Дарья: Многие аутсорсинговые компании, на мой взгляд, хотят иметь свой собственный успешный продукт, однако не у всех это получается, ведь это уже уровень бизнеса: не просто знать, как разработать продукт, а какой продукт разработать, кому и как его продать, как повысить Retention. Это совсем иное восприятие: когда спускаешься на уровень разработки своего продукта, для тебя появляется огромное количество нюансов, которые ты потом способен учесть на старте любого другого проекта на аутсорсинге. У себя на продукте мы набиваем шишки, и когда к нам приходят заказчики, мы можем предложить свою экспертизу и помочь им не набить своих шишек, которые могут очень больно ударить по кошельку и снизить вероятность успешности продукта.
Что касается SaaS-компаний, то это уже другой уровень бизнес-аналитиков: у вас есть готовый продукт, вы хорошо знаете его модули и функции. Когда к вам приходит заказчик четко определяете его потребность, чтобы понять, какие модули продукта ему необходимы и как вы можете их адаптировать под индивидуальные потребности клиента. SaaS-компании работают с конкретным продуктом и могут предложить более дешевое или дорогое решение для конкретного заказчика. Это не разработка чего-то с нуля, это домен, когда под каждому заказчику предлагается одинаковый шаблон, который при необходимости можно адаптировать под нужды клиента.
Если говорить о компаниях, не связанных с IT, я бы хотела выделить бизнес-аналитиков по процессам, которые занимаются автоматизацией, постановкой и стандартизацией процессов компаний. Они могут быть не связаны с IT-сферой. Однако любому бизнесу, чтобы выжить на рынке и масштабироваться, придется идентифицировать и описать свои процессы.
Бизнес, который имеет стандарты процессов, стоит дороже на рынке, подтверждение тому активно развивающийся рынок франшиз.
Когда компания задумывается о масштабируемости своего бизнеса, то первые, к кому они обращаются, это бизнес-аналитики по процессам, которые могут выстроить систему процессов. Начать стоит с оффлайн стандартизации процессов, чтобы несколько раз пройти полный цикл PDCA. Только после того, когда оффлайн процесс будет отработан многократно и покажет свою эффективность, я бы рекомендовала приступить к автоматизации, иначе вы будете автоматизировать бардак, который принесет только убытки. Автоматизировать можно, например, в ERP-системе, CRM-системе, с помощью чат-ботов и т.д. Если говорить о производственном домене – это автоматизация конвейеров, обучение роботов.
Как понять, что ваши процессы на текущий момент времени налажены? Все просто: вы получаете стабильный плановый уровень качества своей продукции, услуги, которая востребована рынком. Например: задумывались ли вы, почему ароматная чашечка кофе Lavazza, которое вы выпиваете каждое утро на протяжении многих лет имеет один и тот же вкус, несмотря на то, что оно производится разными заводами, расположенными в разных странах, в разное время? Это магия выстроенных процессов.
На мой взгляд, симбиоз бизнес-аналитиков по процессам с IT-технологиями способен совершить революцию, дав человечеству полную роботизацию производств.
Расскажите о роли и функциях БА в Agile-проекте и принципах работы по гибкой методологии.
Дарья: Если спросить у любого бизнес-аналитика какую Библию он читает, то ответом будет “Вигерс, Разработка требований к программному обеспечению”. Особенность этой книги в том, что она формулирует принципы, правила и примеры описания требований в проектах с водопадной моделью разработки, когда у нас есть длительная стадия проработки технического задания, продумывание мельчайших подробностей. После того, как аналитик передает документацию в разработку, что-то поменять довольно сложно.
В Agile мы работаем по спринтам. Каждый спринт мы поставляем заказчику какой-то результат, ценность для пользователей. Для бизнес-аналитика работа в Agile и по водопадной модели ничем не отличается: если у вас не будет технического задания, команда разработки не будет знать, что разрабатывать. Никто не будет однозначно понимать какая система разработана, на что она способна, как с ней работать, как дополнительная функция повлияет на нее.
В Agile большой продукт разбивается на маленькие кусочки, на которые и формируется техническое задание, но бизнес-аналитик должен заранее понимать, какую систему он строит и к какому конечному результату мы идём. Поэтому все наши требования трассируются на соответствие бизнес-цели – а туда ли мы идем? А не ушли ли мы в сторону? Может быть нам надо пересмотреть наши требования, потому что мы отклонились от нашей цели? Бизнес-аналитик постоянно задает себе эти вопросы и переносит их в требования для того, чтобы мы от итерации к итерации шли к конечной запланированной цели, к видению готового продукта. В Agile проектах требования, могут быть не настолько узко детализированы как в водопадной модели, но они должны быть достаточны для команды разработки.
В чем преимущества Agile? Вы можете в короткую итерацию, например, в один – два спринта, получить готовый модуль системы, пойти к своей потенциальной целевой аудитории, которую вы определили для себя, и показать продукт. Эта целевая аудитория дает вам обратную связь. Возможно, поняв, что вы ошиблись, вы можете многое концептуально изменить в продукте на ранних стадиях: это и есть управление проектом, основанное на фактах.
Таким образом ваше техническое задание никогда не отстает от рынка и ориентировано не на воображаемую целевую аудиторию, а на реальную. Вы не ограничены водопадной моделью и не столкнетесь с ситуацией, когда разрабатываете продукт по техническому заданию, которое устарело, т.к. ситуация на рынке сильно изменилась, пока вы разрабатывали техническое задание и писали код. Когда вы разрабатываете продукт по гибкой методологии, вы можете безболезненно менять требования и концепцию продукта, таким образом с большей вероятностью вы получите продукт, востребованный рынком.
Опишите весь процесс работы бизнес-аналитика при разработке продукта.
Дарья: Бизнес-аналитик подключается к проекту на ранних стадиях: presale и discovery. Заказчики приходят разные: основная масса приходит с идеей, но идея и продукт – совершенно разные вещи. Идея верхнеуровневая: заказчик увидел проблему бизнеса и у него есть набросок решения. Как правило, нет четко сформулированного видения продукта и понимания системы на уровне функций и пользовательских ролей. Тут включается стадия discovery проекта: бизнес-аналитик на уровне Vision and Scope помогают сформулировать и обосновать концепцию продукта, выстроить границы решения.
В рамках Vision and Scope мы также осуществляем подбор интегрируемых решений: проводим анализ рынка, сравнивая функции и особенности разрабатываемого продукта с техническими особенностями интегрируемых решений и их стоимостью. По итогам подбора бизнес-аналитик готовит технико-экономическое обоснование, с помощью которого Заказчик может принимать решения, основываясь на фактах.
После разработки Vision and Scope мы описываем модули системы, разрабатываем и детализируем требования в два этапа:
Первый этап работы – формирование технического задания, которое можно передать UX-дизайнерам. Частая ошибка бизнес-аналитика – описание в документации для UX-дизайнеров детальных требований к интерфейсу: какие кнопки и поля где расположены, какие формы, какой цвет, какой путь пользователя в системе. Это ошибка: практика показала, что UX-дизайнер может придумать такое интерфейсное решение, о котором не думал ни заказчик, ни бизнес-аналитик. UX профессионал в своей сфере, которого не надо ограничивать, иначе вы получите не более, чем копию какого-то продукта, который уже есть на рынке.
После того, как интерфейс разработан и согласован с Заказчиком, бизнес-аналитик приступает ко второму этапу: детализируя дополняет требования и передает техническое задание команде разработки.
В процессе разработки бизнес-аналитик поддерживает команду, согласовывает изменения с заказчиком и управляет изменениями. На этапе тестирования продукта аналитик активно общается с тестировщиками. Когда фича готова, аналитик может проверить реализацию на соблюдение бизнес-логики. Далее идет презентация и передача продукта заказчику.
Иногда заказчики приходят с уже сформулированным техническим заданием: как правило, это небольшие проекты. Однако в своей практике я еще не встречала, чтобы техническое задание заказчика было сформулировано на таком уровне, чтобы его можно было передать команде разработки, но более-менее описанное видение продукта встречается.
Что важно понять заказчику на старте разработки продукта? Расскажите о распространенных ошибках клиентов, которые заказывают ПО.
Дарья: Первая ошибка – отсутствует или неверно назначен Product Owner со стороны заказчика. Product Owner – это человек со стороны бизнеса, который имеет экспертизу в доменной области продукта, понимает ключевые требования и может их согласовывать с командой разработки, управляя бюджетом проекта. Он имеет полномочия принимать окончательные решения по проекту, т.к. любая разработка — это трудозатраты, которые надо оплачивать, поэтому надо понимать, насколько они оправданы и как вписываются в выделенный бюджет.
Одна из самых распространенных ошибок заказчиков в непонимании, что продукт — это расходы не только на саму разработку, но и на оплату услуг сторонних организаций, которые могут быть существенными. Если вы хотите интегрироваться со сторонним сервисом, например, у вас регистрация по Email, то надо понимать, что каждое письмо стоит денег. То же самое и SMS. Ежемесячно ваш продукт будет иметь расходную часть, и вы будете оплачивать услуги сторонних сервисов. Мы, имея собственный продукт, помогаем подобрать оптимальное решение: готовим технико-экономическое обоснование, анализируем рынок, определяем с какими сервисами выгоднее интегрироваться и сколько вам будет это стоить. Мы помогаем снизить расходную часть продукта. Когда у вас есть на руках аналитика с обзором рынка, вы можете принять правильное и взвешенное решение.
Будьте готовы к таким расходам как: продвижение, техподдержка пользователей, доработки по запросам целевой аудитории и новым трендам рынка.
Если продукт не развивается далее – значит он умирает. В каждый момент времени вы либо идете вперед, либо устареваете. Во времени нет статичного состояния, т.к. оно не стоит на месте.
Не менее распространенная ошибка заказчиков – это “золочение” продуктов: желание добавить “бантики”: анимация, “прыгающие бабочки” и других функции, за которые пользователь не готов платить. Это, как правило, сопровождается выходом за границы решения. Бизнес-аналитик охраняет границы решения: иногда в продукте действительно нужны гифки, а иногда нет. Это зависит от продукта и его целевой аудитории. Поэтому не стоит навешивать на продукт “бантики” со старта. Постройте скелет и посмотрите, как его воспримет целевая аудитория, и только потом, по запросу пользователей, дорабатывайте продукт. Велика вероятность ошибки: уходя в невостребованные фичи, свои ресурсы: запланированный бюджет и время, вы потратите на “бантики”, при этом не сделаете костяк системы и не решите главную потребность пользователей.
Расскажите об инструментах бизнес-аналитика для моделирования бизнес-процессов.
Дарья: Этот вопрос, опять же, касается бизнес-аналитиков по процессам которые могут быть как связаны с IT-сферой, так и быть в стороне от нее. Повторюсь: начинать выстраивать процессы надо в оффлайне и только после этого переходить к автоматизации, иначе вы автоматизируете Франкенштейна, и эта автоматизация будет нести больше издержек, чем пользы.
Я проработала бизнес-аналитиком по процессам более 14 лет, в том числе и на крупных промышленных предприятиях и опробовала разные инструменты: от листа с карандашом и draw.io, до специализированных продуктов, применяла разные нотации: IDF0, BPMN, Flowchart, использовала разные способы: графические, текстовый, табличный.
Но что показала практика: даже самые простые диаграммы BPMN воспринимаются заказчиком как нечто, не сильно применимое к практике. Перед началом презентации процесса вы вынуждены обучить бизнес элементам нотации, объяснить заказчику, например: что такое BPMN и его правила. Однако ваше описание процесса должны понять не только присутствующие на презентации, но и простые исполнители процесса, например слесари.
Практика показала, что самый понятный способ описания процессов для заказчика — это табличный способ. Презентуя заказчику и стейкхолдерам таблицу, вы избежите предварительного обучения нотациям и правилам.
Когда мы разрабатываем техническое задание, мы исходим из того, что оно должно быть понятно команде разработки, точно так же и при моделировании бизнес-процессов. Не надо чертить диаграммы для красоты, красота после презентации будет в сложенном виде пылиться в шкафу. Надо дать бизнесу инструмент, которым он сможет пользоваться в повседневной работе. Паспорт процесса должен быть понятен его целевой аудитории.
Большое спасибо за интервью, Дарья! Было очень приятно пообщаться.
Дарья: Взаимно!
Уважаемые читатели! Мы будем продолжать знакомить вас с ведущими экспертами Softvoya и их деятельностью в наших следующих статьях, не пропустите!😊
