Если вы решили заказать у подрядчика разработку IT-продукта или впервые собираете собственную продуктовую команду для разработки IT-решения, построить взаимодействие с командой разработки будет непросто. Рассказываем, на какие аспекты стоит обратить внимание.
В каких случаях нужен аналитик
Вы, как заказчик, придумываете идею продукта, определяете результат, который хотели бы достигнуть с помощью IT-решения, выдвигаете гипотезы о функциональных возможностях (функциях) разрабатываемой программы. Затем обращаетесь к аналитику, который проводит с вами подробное интервью.
Перед аналитиком стоит задача получить как можно больше информации о вашей идее: он будет спрашивать о целях, желаемом результате, проблемах, кейсах и ценности для пользователей продукта. После интервью, когда аналитик выявил «ЧТО необходимо сделать», он переходит к «КАК необходимо это делать» и оформляет собранную информацию в техническое задание для разработчиков — спецификацию требований к программному обеспечению. Данная спецификация используется в качестве инструкций, правил и ограничений в команде разработки. В результате вы получаете продукт, который ранее был полностью зафиксирован в спецификации требований к программному обеспечению.
Чаще всего в продуктовых командах в IT аналитик совмещает в себе две вертикали: бизнес-аналитику и системную аналитику. Таких супергероев именуют системными аналитиками.
Что необходимо рассказать аналитику
Для вас, как для заказчика, главная задача системного аналитика — понять, в чем нуждается бизнес. В первую очередь необходимо обратить внимание на несколько нюансов.
Бизнес-процессы
Для того, чтобы аналитик смог оцифровать бизнес-процессы, ему необходимо погрузиться в них. Для простоты он декомпозирует все внутренние процессы бизнеса, чтобы в изоляции друг от друга рассмотреть все детали, которые заказчику иногда могут быть неочевидны.
Чем больше декомпозиций, тем меньше вероятность упустить важное. Расскажите аналитику все о вашем бизнесе так, чтобы он как будто бы прошел по коридору, заглянув в каждый кабинет, имеющий значение для дела.
CustDev
Бизнес не всегда знает ожидания и потребности своих конечных пользователей. Именно поэтому важно проводить интервью с реальными клиентами, имеющими проблемы, которые продукт нацелен решить.
Именно пользователи — один из самых ценных источников требований к программному обеспечению, так как именно они проходят пошаговые пользовательские сценарии для получения конкретного результата, который мы и хотим улучшить. Хотите сделать хорошо? Убедитесь, что аналитик на связи с конечным пользователем. Если вы делаете продукт для бухгалтеров, то аналитик должен напрямую взаимодействовать с бухгалтером.
Результат
Вы и команда разработки собрались вместе ради одного конкретного полного результата. И это результат не как факт выполненной работы, а как удовлетворенность всех потребностей конечного пользователя.
Убедитесь, что ваши ожидания от продукта и ожидания аналитика едины. IT — это информационные технологии, и ключевое слово здесь — информация. А это значит, что в результате вы получаете программу, у которой есть возможность: дать конкретную информацию (например, список покупок) конкретному пользователю (например, жена) в конкретном виде (список, в котором есть название продукта, вес, бренд) после определенных действий (написать список покупок).
Пользовательские сценарии
Аналитик продумывает, как пользователи будут работать с новыми функциями. Если вы не являетесь конечным пользователем, то предоставьте возможность аналитику пообщаться с ним. А если вы и есть конечный пользователь, то опишите текущие шаги для получения результата, а затем поделитесь желаемым алгоритмом шагов для этого же результата.
Об одном и том же
Команда разработки — это группа квалифицированных специалистов, у каждого из них есть узкая специализация. Именно из-за специализации каждого их потребность в полноте информации сильно меняется.
Системный аналитик в своей работе использует спецификацию требований (формы и стандарты требований) для удобства работы в большом коллективе экспертов. Выбор формы написания требований зависит от ее читателя, то есть эксперта в команде. Не стоит бояться сложной документации, если вы не понимаете содержимое. Скорее всего, этот документ предназначался не для вас, а для разработчика.
Системный аналитик может рассказать об одном и том же разными способами: диаграммой деятельности, user case, job story и др. Ниже рассмотрим требование для простого примера.
Форма требований в виде набора диаграмм
Такую форму читатели понимают легче, так как она интерактивна и напоминает настольную игру. В зависимости от языка моделирования (набора и правила составления) диаграммы могут содержать в себе нотацию (обозначения), знакомую не каждому. Но на деле участников команды легче ознакомить с нотациями или вручить подсказку, чем объяснять им сложные пользовательские сценарии системы.
Форма требований в виде User case
Чаще всего выглядит тяжелой для понимания заказчиком и проектировщиком. Перед тем как начать работать с пользовательскими сценариями, необходимо убедиться, что команда понимает, как правильно читать основной (главный сценарий) и альтернативный поток (ответвление главного сценария).
Когда в сценарии на определенном шаге пользователя имеется развилка (то есть следующий шаг зависит от действия в предыдущем шаге), необходимо об этом рассказать в альтернативном потоке, пронумеровав его номером шага, в котором есть развилка.
Таким образом, читая основной поток, читатель может увидеть, что продолжение основного потока после 5 шага может быть другим. Ему будет необходимо прочитать в основном потоке с шага 1 по 10, а затем прочитать снова, но с 1 по 5, затем продолжить чтение альтернативного потока 5, читая с 1 по 10 шаг. Такой формат требований чаще удобен бэкенд-разработчикам и тестировщикам.
Главная проблема такого требования — желание заказчика, проектировщика интерфейсов читать такую документацию. Ведь в некоторых случаях количество шагов и альтернативных потоков может вырасти до огромного количества.
Форма требований в Job story
Позволяет достаточно быстро составить требование, передать основные ценности решений и немного контекста, когда эта ценность важна. Главный минус рабочих историй — это низкая детализация, оставляющая за собой большое пространство для фантазирования каждым участником команды. Это обязательно скажется на синхронизации общего видения проекта.
Свободная форма требований
Такая форма требований не подвержена каким-либо правилам. На деле этот подход встречается чаще всего, поскольку не требует специальных знаний и навыков для его написания и чтения.
Минусы состоят в том, что в большом массиве текста тяжело ориентироваться и выделять ключевые моменты для разных членов команды.
Границы
В хорошей команде каждый ее участник знает, что ему делать и как это делать. Системный аналитик обладает необходимым опытом и компетенциями, чтобы правильно выбрать для вас документ, чтобы вам и ему было удобно работать с идеей.
Аналитик будет получать от вас информацию, фиксировать и придумывать сценарии. Вам, как заказчику, важно фокусироваться на результате и пользовательских сценариях и не пытаться понять, как будет работать сценарий системы. Когда вы смотрите телевизор, вам важны картинка и звук, также нужно знать, как им пользоваться, а не то, как работает его система.
Перед разработкой
Вы прошли в финальный раунд! Перед тем, как аналитик отдаст команде спецификацию требований к программному обеспечению, вам необходимо ознакомиться с ее артефактами. Вам нужно синхронизировать ожидания от продукта с тем, как понимает эти ожидания специалист.
Убедитесь, что вы с аналитиком имеете единые взгляды на проблему и ее решение. Помните, для вас главное — это результат после пользовательского сценария и сам сценарий.
Нашли двусмысленность или непонятный шаг в алгоритме пользователя, задайте вопрос аналитику, не оставляйте это без внимания. Исправить аналитику легче и дешевле перед разработкой, чем пересобрать уже разработанный продукт.
Если продукт подразумевает интерфейс, попросите аналитика предоставить вам прототип интерфейса в сервисе прототипирования. Прототип позволит вам пройти пользовательский путь и собственными глазами увидеть, какой получится результат.
Вывод
Аналитик выполняет важную функцию: он узнает и структурирует вашу идею, разрабатывает сценарии пользователей и системы, а также выступает в качестве «переводчика» между вами и командой разработки. Вам не нужно стремиться понимать все, что пишет аналитик. Вам необходимо знать и понимать результат, который получит пользователь, и пользовательский сценарий.
Стоимость работы у одного аналитика меньше, чем у группы разработчиков. Соответственно переделать начатый проект группой разработчиков будет дольше и дороже, чем проект у аналитика. Для вас, как для заказчика, хорошая аналитика должна содержать в себе понятные существующие роли пользователей, их сценарии и результат, который каждая из ролей получит в ходе выполнения своих «квестов».
