Приветствую! Меня зовут Сергей, и я — бизнес/системный аналитик. В IT отрасли работаю около 8 лет, начиная с сопровождения, перетекающего в тестирование, и продолжая аналитикой: как бизнес, так и системной. Отдельно бизнес и отдельно системным аналитиком я ещё не работал.
В ходе своей профессиональной деятельности в целом, включая практику и личные собеседования, и в частности собеседований с потенциальными кандидатами я постепенно пришел к пониманию того, каких навыков рынок ждёт от Аналитика. Свежих статей на эту тематику Хабр не видел давно, поэтому я решил подготовить материал самостоятельно.
Для кого, на мой взгляд, будет полезна статья:
- Начинающим бизнес / системным аналитикам;
- Аналитикам, желающим и дальше прокачивать свои проф. навыки;
- Возможно, менеджерам по подбору персонала.
Сразу скажу, что пункты ниже — это моё субъективное видение специализации аналитика, сформировавшееся в процессе практики. Если в вашей компании запущен полноценный scrum с product owner, сидящем в метре от вас, с выделенными для команды дизайнером и архитектором, что-то из перечисленного может оказаться невостребованным.
Тем не менее, все эти навыки как минимум не окажутся лишними и сделают из аналитика еще более компетентного в своих вопросах специалиста. Разумеется, надо понимать, что я перечислил не все умения и способности аналитика (те же нотации, бизнес-скиллы, sql и так далее).
Бизнес аналитика
- Устраняйте двусмысленные требования на самых ранних этапах
Разговаривая с бизнес-заказчиком, нужно отдавать себя отчет в том, что его язык может существенно отличаться от вашего. Бизнес-требование может быть озвучено таким образом, что у нескольких участников процесса согласования требований возникает различное понимание, что это требование означает. Порождается двусмысленность, которая очень дорого обходится команде на поздних этапах разработки.
Проблема оказывается наиболее острой при наличии нескольких бизнес-заказчиков, каждый из которых выдвигает свои требования. Например, при интеграции двух систем, по каждой из которых есть свой представитель от бизнеса.
Кейс из практики: месяц разработки был потрачен на функционал переноса списка активностей из объекта №1 в объект №2. На этапе приемочного тестирования обнаружилось, что заказчик ожидал совершенно иной функционал — копирование, а не перенос активностей. В процессе переделывания функционала и детализации двусмысленности IT-команда, во-первых, договорилась с заказчиком о MVP, а, во-вторых, о необходимости работы с корнем бизнес-проблемы. Было выдвинуто предположение, что сам функционал копирования требуется только лишь по причине недостаточно качественно реализованного функционала подгрузки шаблонов активностей.
- Не бойтесь уточнять у заказчика о целях требования
По работе встречался с кейсами, когда постановка на разработку была описана без фиксации бизнес-цели: в чем конкретно эта доработка поможет бизнесу? Какую боль эта доработка снимет с бизнеса?
Зачастую такие доработки без цели приводили к неприятным последствиям уже на этапе тестирования, когда и разработчик, и тестировщик не понимали, зачем мы спроектировали этот функционал. Хуже того, разработчик и тестировщик не получали ответы от аналитика, а если и получали, что чаще всего придуманные самим аналитиком: цели, который аналитик сформировал самостоятельно.
Записывайте цели вместе с заказчиком, чтобы абсолютно все участники процесса в любой момент времени понимали, зачем они выполняют свою работу.
- Требуйте у заказчика своего присутствия на бизнес-встречах
На практике сталкивался с разными заказчиками, некоторые из которых не сразу были готовы приглашать аналитика на свои оффлайн-встречи. С этим аналитик также должен будет поработать: договориться и показать результат от слаженной совместной работы.
Во время очной встречи руководителя подразделения с подчиненным, где мы — аналитик и UX-дизайнер — сидели «в фоне», выявился целый ряд требований, который не проявлялся в течение целого года работы команды. Мы обращали внимание на все детали: ручные записи руководителя и сотрудника, на стикеры, на пометки в windows-блокноте, на действия внутри системы. По итогу такой встречи бэклог был существенно дополнен, а мы приступили к глубокой переделке реализованного в системе функционала.
- Старайтесь достигать соглашения и не формировать отписки
Многие аналитики, и я в том числе, в процессе формирования требований, сталкиваясь с жёстким дедлайном, пользовались следующим приёмом: писали участникам процесса письмо со сроком, до которого на письмо нужно ответить и согласовать требования / дать комментарии. В противном случае требования будут автоматически признаны согласованными.
Как показала практика, ничего хорошего в таком подходе нет. Понятно, что, работая на стороне вендора и имея на руках договор, приходится прибегать к такого рода приёмам, но всё же старайтесь избегать молчаливого согласия, попытайтесь понять, почему участники не хотят давать вам ответ именно сейчас, и решите проблему как можно быстрее.
Лучше письменно задокументируйте тот факт, что ответ не был получен от таких-то лиц и вы видите в этом следующие риски для проекта. Однако процесс работы не может стоять на месте, поэтому вы вынуждены продолжить свою аналитическую деятельность, при этом ранее определенные риски должны быть понятны всем участникам процесса.
В процессе проработки интеграции двух систем мы столкнулись с формированием требований со стороны директора, покрывающих действия пользователей в двух системах, но отсутствием явного согласования этих самых требований от непосредственного руководителя подразделения, сотрудники которого являлись пользователями системы.
Как выяснилось позже, руководитель подразделения совершенно не понимал, к чему все эти доработки и каким образом они помогут оптимизировать процессы в его зоне ответственности.
Часто участники процесса согласования просто боятся поставить свою подпись, так как не до конца понимают те или иные участки обновленного бизнес-процесса. Ваша задача как бизнес-аналитика — устранить это непонимание.
- Ознакомьте разработчиков с предметной областью
Потратьте несколько часов, но верхнеуровнево расскажите своим разработчикам о заказчике, о текущих бизнес-процессах, о боли и планах на развитие. Как правило, хорошо замотивированные разработчики не просто отлично выполняют свою работу, понимая, для кого они пишут код, но и вносят свой ценный вклад: предлагают оптимизацию, обходные решения, охотнее задают уточняющие вопросы.
При необходимости (и отсутствия scrum) привлеките заказчика к такой встрече. Как правило, представители Бизнеса охотно соглашаются на такого рода инициативы.
- Научите заказчика отвечать на вопрос «Что?», а не формулировать требования в формате «Как»
Заказчик не должен формулировать бизнес / пользовательское требование с позиции «Как»: нам нужна кнопка на этом экране, чтобы сформировать отчёт; нам нужна ссылка на внешнюю систему в этом разделе; и так далее.
На этапе первичного анализа процесса, до непосредственно проектирования, заказчик не должен предлагать решение.
Вместо этого научите заказчика формулировать проблему, свою «боль»: нам необходимо на еженедельной основе формировать отчет, который вручную дополняется сотрудником и высылается на руководство; в процессе работы с клиентом нам требуется анализировать дополнительную информацию, а так как в CRM-системе она отсутствует, нам приходится открывать новую вкладку в браузере и выполнять вход в смежную систему.
Узнав боль заказчика, вы, как специалист, сможете предложить варианты оптимизации процесса и его автоматизации. Например, автоматически высылать сформированный отчет на почту сотрудника, избавить сотрудника от ручной работы с отчетом в принципе, автоматическую загрузку данных из смежной системы в CRM, и так далее.
Во многих случаях этот подход столкнется с реальностью: со сроками и приоритетами. Но вы, во всяком случае, честно попытались.
- Обязательно разделите пользователей на классы
Принимая требования от пользователя системы, в обязательном порядке учитывайте его роль в бизнес-процессе. В практике часто встречаются случаи, когда руководитель подразделения формирует требования для функционала, с которым будет работать обычный сотрудник.
Разделите пользователей системы на роли, а функционал, затачиваемый под одну роль, не «размазывайте» под другую роль.
Как-то раз в рамках Системы мы реализовали отображение списка сделок с клиентами.
Предполагалось, что со списком будут работать как руководители, так и обыкновенные сотрудники. К сожалению, нам не удалось добиться от заказчика понимания необходимости разделить UI-ную часть доработки на два списка / экрана: один список — для руководителя с целью анализа и контроля, второй список — для сотрудника с целью осуществления операционной деятельности.
В итоге получился некий монстр, который впоследствии пришлось дорабатывать и дорабатывать.
Применяйте бэст-практики из UX: проработайте персонажей — модели пользователей. Убедите заказчика в необходимости разделять требования для каждого из персонажей.
- Активно применяйте аналитический мозговой штурм
Можно в тандеме со вторым аналитиком, можно в тандеме с UX-дизайнером. В процессе штурма примерьте две роли: один человек сначала генерирует множество идей, посильных и не очень, второй — критикует эти идеи, декомпозирует их, записывает, продумывает; затем поменяйтесь ролями и сделайте ту же работу.
Как показывает практика, такой подход позволит значительно ускорить процесс составления функциональных требований и повысить их качество. Но есть сложность в том, что оба специалиста должны быть в контексте задачи.
- Если застряли в Waterfall, не отчаивайтесь и двигайтесь в сторону Scrum
В одной из компаний буквально за год нашей команде удалось перевести процесс внедрения доработок от устоявшегося на уровне управляющих менеджеров Waterfall к некоторой разновидности Scrum. Да, назад тянули «чёткие» сроки по сильно размазанному бэклогу, которые заказчик постоянно требовал с IT-команды, при этом риторика была постепенно смягчена через двухнедельные релизы, MVP-решения и быстрый отклик на изменения.
- Ни в коем случае не демонизируйте заказчика
Да, заказчики бывают всякие. Есть и такие, которые буквально бесят. Тем не менее, бизнес-аналитик должен решать этот вопрос или самостоятельно, или с привлечением менеджера и ни в коем случае не выносить «ссору из избы» — на команду.
Команда должна быть хорошо мотивирована на работу, и роль бизнес-аналитика в процессе формирования мотивации — одна из ключевых.
- Не перебивайте
Серьезно. Когда в процессе общения с заказчиком я слышу от своего коллеги-аналитика нелепые словесные вставки, когда коллега-аналитик перебивает заказчика, не дослушивая его до конца, мне хочется отправить его на курсы по ведению переговоров или элементарной этике.
Старайтесь и слушать собеседника, и слышать его.
- Избавьтесь от слов-паразитов
Старайтесь избегать слов-паразитов и поменьше «мычать» в разговорах. Поначалу это тяжело, но, поверьте, заказчику вдвойне тяжелее слушать такого аналитика, который не может выразить свою мысль четко и ясно. Словами-паразитами может страдать разработчик, дизайнер, тестировщик, но не бизнес-аналитик, связывающий IT-команду с Бизнесом.
Рекомендуемая литература:
- Карл Вигерс "Разработка требований к программному обеспечению".
- Максим Ильяхов "Пиши, Сокращай: как Создавать Сильный текст".
Системная аналитика
- При постановке задачи на front и back старайтесь описывать sequence диаграммы
Или, по-русски, диаграммы последовательности. Диаграммы окажутся полезными даже не с точки зрения разработки, но с точки зрения верификации собственных требований. Очень часто при описании потока сообщений я выявлял «дыры» в собственном процессе. Например, неактуальный API.
Для быстрого «рисования» sequence диаграмм используйте плагин PlantUML для Confluence. Мне показалось, что быстрее набирать код, нежели ручками корректировать расположение блоков и стрелок. Но у каждого в этой части свой опыт и свои предпочтения.
- Освойте Swagger Editor
С точки зрения анализа Swagger Editor позволит вам закрывать ваши же дыры в требованиях. Где-то упустили атрибут, где-то забыли создать задачу в JIRA для доработки базы данных. Не пытайтесь зазубрить синтаксис Сваггера, а создайте шаблоны под разные типы API (справочники, фильтры и так далее), чтобы упростить себе жизнь в будущем.
- Активно используйте инструмент разработчика в целевом браузере, чтобы анализировать запросы клиента и ответы от сервера
Во-первых, в процессе первичной приемки вы сможете проверить API, который сами же описали. Иногда некоторую часть доработки оказывается быстрее проверить по исходящим запросам, нежели по UI, чтобы на раннем этапе понять корень проблемы.
Вам, как аналитику, потребуется гораздо меньше времени, чтобы проверить реализацию от разработчика: исходящие данные, входящие данные, результат в UI.
Во-вторых, вы сможете убедиться в правильной последовательности вызовов. Ведь вы сами описали её в рамках sequence диаграммы.
Этот подход позволил нашей команде выводить достаточно хитрые доработки в пром в рамках спринтов без задержек.
Рекомендуемая литература:
- Марейн Хавербеке "Выразительный JavaScript". Главы про JSON, Интернет, HTML, http / https, методы и другие.
- В. Олифер, Н. Олифер "Компьютерные сети. Принципы, технологии, протоколы". Главы про сетевые службы и сервисы, сетевые приложения, базовые технологии безопасности, аутентификацию и другие.
В дополнение
- Погрузитесь в UX
Возможно, вам даже понравится и вы захотите развиваться в сторону UX-аналитики. В любом случае, изучение соответствующей литературы и инструментов проектирования пойдет на пользу как минимум с точки зрения поиска общего языка с UX-дизайнером из вашей команды.
Зачастую те требования, которые вы, как аналитик, детализируете и распишите, будут впоследствии корректироваться со стороны дизайнера. Ведь не вы один, по сути, проектируете пользовательский опыт.
Чтобы быть на одной волне, попрактикуйтесь в UX-анализе. Например, в свободное от работы время в Sketch или Figma, время от времени показывая результат вашему дизайнеру. Такой опыт аналитики никогда не будет лишним.
Рекомендуемая литература:
- Дон Норман "Дизайн привычных вещей".
- Алан Купер "Психбольница в руках пациентов".
- Алан Купер "Интерфейс. Основы проектирования взаимодействия".
- Робин Уильямс "Дизайн. Книга для недизайнеров".
***
Спасибо за прочтение статьи! Буду благодарен, во-первых, за обратную связь. Во-вторых, за рекомендации по литературе, источникам, за бэстпрактисы, личный опыт и рекомендации.
