Посредник между бизнесом и технологиями: чем занимаются системные аналитики и почему нельзя пропускать этот этап?

В команде разработки много ролей: программисты, дизайнеры, менеджеры, тестировщики. Но самый загадочный из них — аналитик. Руководители, впервые столкнувшиеся с заказной разработкой, не всегда понимают роль аналитика в проекте, а ведь она достаточно велика, чтобы разобраться подробнее в нашей статье.

Системный аналитик в разработке ПО — это специалист в сфере информационных технологий, главной задачей которого является анализ требований заказчика и потребностей целевой аудитории будущей системы. Однако собрать и проанализировать требования — только начало. Системный аналитик в работе должен разговаривать на языках бизнеса и технологий и бегло переводить с одного на другой, связывая воедино команду разработки и заказчика. А чтобы узнать какими суперсилами обладает идеальный аналитик и как именно он поможет вам создать идеальную систему, читайте нашу статью!

Немного истории для полного погружения!

Системный анализ изначально не имел ничего общего с информационными технологиями и, как термин, впервые прозвучал в 1948 году в контексте вооружённых сил США. Его прародителем стала компания RAND (Research and Development). В 1956 году RAND собрали свои исследования воедино, выпустив книгу на тему первой разработанной методологии системного анализа PATTERN (Помощь планированию посредством относительных показателей технической оценки), которая положит начало аналитике в разработке. Суть её заключалась в оценке приоритетности тех или иных элементов системы с помощью дерева целей.

Всего на 3 года позже, в 1959, предприниматели Рой Натт и Флетчер Джонс основали первую компанию по разработке ПО. Сложив два и два, первые специалисты сферы информационных технологий задумались о том, как использовать аналитику в управлении проектами.

С этого момента начинается история той самой системной аналитики, о которой мы знаем сейчас, но развитие её затянулось на долгие 40 лет, а задачи системного аналитика в современном представлении сформировались лишь в начале 2000-х. Профессиональные стандарты в России появились в недалёком 2014 году.

Перед тем как разбираться в чем заключаются обязанности системного аналитика, имеет смысл подумать над тем, какие ещё бывают аналитики. Почему же это необходимо? Аналитика в ИТ-проектах— это спектр. Требования к работе и стандарты меняются от компании к компании: термин один, а задачи могут отличаться.

Бизнес-аналитик

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

Технический аналитик

Технический аналитик — полная противоположность бизнес-аналитика. Он не анализирует бизнес-процессы, а занимается исключительно проработкой технической части будущей системы, попутно согласовывая решения с отделом разработки.

Продуктовый аналитик

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

UX-аналитик

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

Системный архитектор

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

Технический писатель

Технический писатель также не проводит аналитику в проекте, а отвечает лишь за документацию требований в виде технического задания — объёмного документа, содержащего в себе все аспекты разработки и поддержки будущего продукта.

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

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

Почему программная разработка нуждается в системной аналитике?

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

• Трудности в коммуникации и конфликты

Это вовсе не значит, что аналитик в команде разработки выступает в качестве миротворца, тогда как остальные участники так и мечтают покричать друг на друга и пустить в ход кулаки. Дело в том, что системный аналитик структурирует сведения о проекте, благодаря его организации вы можете быть уверены в том, что каждый участник команды чётко знает своё дело. Заказчик в свою очередь может не беспокоиться о том, что пропустит что-то, ведь всегда будет осведомлён о текущем состоянии продукта.

• Неорганизованный функционал

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

• Неудобная навигация системы, понижение лояльности целевой аудитории

Вслед за неорганизованным функционалом обязательно пойдёт непоследовательная навигация, а ведь именно с ней пользователь взаимодействует напрямую. Именно таким образом отсутствие системного аналитика в команде разработки хоть и косвенно но влияет на пользовательский опыт и мнение целевой аудитории.

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

В чём заключается работа системного аналитика?

1. Сбор требований заказчика

Первый этап любого проекта — знакомство действующих лиц и обсуждение идеи. Заказчик выбирает компанию подрядчика и встречают его менеджер и аналитик в проекте. Самое время выложить все карты на стол: свои мысли насчёт будущей системы, первичные идеи функционала и цели, которых вы хотите достичь благодаря продукту.

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

2. Анализ требований

«Что фантазия создает, то анализ разрушает, как карточный домик.» — Иван Александрович Гончаров.

И это, наверное, лучшее описание для этапа, когда видение и идеи заказчика сталкиваются с жестокой реальностью. Системный аналитик в команде разработки начинает исследование, а полученный результат складывает с требованиями заказчика. Основная цель — проработать функционал и работу системы так, чтобы логика осталась на месте, а целевая аудитория могла удовлетворить свою потребность.

Данный этап болезненен ровно настолько, насколько и плодотворен. Даже если некоторые ваши идеи придётся отбросить, а добавить те, что на первый взгляд кажутся лишними, это нормальный порядок вещей. Стоит помнить о том, что главная задача системного аналитика — обеспечить вас качественным результатом.

3. Документирование требований

Системный аналитик в разработке ПО ни в коем случае не вывалит на заказчика проработанный функционал словесным потоком. Для презентации и документирования требований существует два способа:

• Техническое задание

Техническое задание (ТЗ) — это объёмный документ, основанный на аналитике проекта и содержащий в себе все аспекты разработки программного обеспечения: от цели продукта до сопровождения ПО после его внедрения. На техническом задании будет построена вся будущая работа, а значит все пункты должны быть прозрачны, доступны и утверждены заказчиком и командой разработки.

Структура ТЗ разрабатывается в соответствии с ГОСТ 34 и ГОСТ 19. Но, данные стандарты не обязательны, они скорее являются рекомендацией. Системный аналитик в работе вправе наполнить его любыми пунктами, которые посчитает нужным, пока техническое задание остаётся полным и понятным для всех.

• UML диаграммы

UML диаграммы — это визуальное отражение логики продукта, его функционала и объектов. Существует множество подвидов, однако самые популярные и используемые в функциях аналитики в проектах — диаграммы вариантов использования, действий и классов. Опыт показывает, что их вполне достаточно для полного понимания работы системы.

Роль системного аналитика в разработке ПО не представляется возможной без трёх видов визуальных представлений: диаграммы вариантов использования отражают взаимодействие между актёрами (пользователями, администраторами, менеджерами и т.д.) и вариантами действий (функциями продукта). Взаимодействия также делятся на подвиды, что даёт глубокое понимание логики продукта. Диаграммы действий — это своего рода путеводная карта, она отражает разветвление разделов и то, какое действие идёт за предыдущим. Диаграммы классов подробно рассказывают обо всех объектах системы и объединяют их в классы по схожим признакам: атрибутам и операциям класса.

Способы документации различны так же, как реклама на щите, которую нужно прочесть и понять, проезжая мимо на автомобиле, и серьёзный договор, изучение которого займёт много времени. Если вы привычны к большим документам без визуализации, имеет смысл не тратить время на диаграммы. Однако для стопроцентной уверенности во взаимопонимании, мы посоветовали бы потратить время на визуализацию функционала. Помните, что лишняя неделя аналитики в проекте может сэкономить месяц правок, исправлений и тревоги.

4. Проектирование системы

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

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

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

5. Поддержка на всех этапах разработки

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

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

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

6. Участие в тестировании

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

Ну а после успешных тестирований наступает момент релиза, наиболее волнительный для аналитика в команде разработки. Он следит за реакцией пользователей и собирает обратную связь от заказчика и целевой аудитории для корректировки готовой системы. Ну а если вы захотите масштабировать вашу систему, добавив новые функции, можете смело обращаться к проверенной команде, ведь теперь их системный аналитик знает специфику вашего бизнеса на 100%.

О практических обязанностях системного аналитика мы поговорили, а как насчёт софт скиллов?

«Исследовать — значит видеть то, что видели все, и думать так, как не думал никто» — Альберт Сент-Дьёрди.

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

Помимо насмотренности, системный аналитик в работе обладает невероятной коммуникабельностью. Особенности профессии обязывают регулярно рассказывать и объяснять что-то тем или иным участникам проекта, а значит месяцы тренировок не пройдут зря. Со временем этот герой учится объяснять кому угодно и что угодно. Готовы поспорить он убедит черепаху заняться бегом!

Анализ вашего продукта от 66 Бит

Благодаря нашей статье вы изучили роль системного аналитика настолько, что кажется сами готовы взяться за работу. Однако за качественным анализом системы всё же советуем обратиться в компанию 66 Бит! Наши специалисты более 15 лет разрабатывают программное обеспечение для бизнеса, а также проводят проводят полную аналитику в ИТ-проектах различных компаний, исходя из их потребностей и специфики. Скорее переходите на наш сайт и читайте подробнее!