Системный аналитик в IT-компании — специалист на стыке аналитики, разработки, менеджмента. Он анализирует потребности заказчика, формулирует требования к IT-проекту и курирует процесс разработки. Системный аналитик создает основу продукта и делает так, чтобы результат соответствовал желаемому. Чтобы погрузиться в работу системного аналитика, поговорили с Ангелиной Шконда, Middle System Analyst IT-компании Smartex.
Обязанности системного аналитика
Обычно процесс работы системного аналитика выглядит так:
- Cбор требований. Нужно выяснить, что заказчик вообще хочет от команды разработки. Аналитик собирает все возможные данные, находит и уточняет проблемные места, проводит интервью. На интервью встречаются такие вопросы: «Что нужно?», «Какую проблему это решит?», «Точно ли это нужно?»
- Оформление в ТЗ. Собранная информация превращается в спецификации требований к программному обеспечению — конкретные задачи для разработчиков.
- Сопровождение разработки. В процессе разработки к системному аналитику могут приходить за уточнениями по требованиям и за оперативным внесением изменений в документацию при возникновении новых требований. Бывает, что аналитик занимается авторским надзором (проверкой фичи на соответствие требованиям при ее появлении на стенде).
- Демонстрация заказчику. Когда продукт готов к новому релизу, системный аналитик демонстрирует работу заказчику и анализирует обратную связь вместе с менеджером проекта.
Задачи системного аналитика разноплановые: общение с заказчиком, разбор пользовательских сценариев, анализ и описание требований, сопровождение процесса разработки.
Отличия системного аналитика от других профессий
Похожий список обязанностей есть у менеджера проектов, менеджера по продукту, системного архитектора, бизнес-аналитика и технического писателя. В реальной жизни этой сферы часто не разделяются и получаются «люди-оркестры», но различия в профессиях есть.
А теперь к заповедям
- Имей представление о возможностях команды и предложениях на рынке.
При обсуждении проекта аналитику нужно не только фиксировать требования заказчика, но и ясно понимать возможности своей команды, учитывать ресурсы проекта и доступные технологии. В идеале это выглядит так: получение требований => быстрый анализ текущих возможностей => выдача рекомендаций. Конечно, знать все сложно (цитата автора: «абсолютно анпосибл»), но быть в курсе технического рынка жизненно необходимо.
В начале карьеры я приставала ко всем коллегам, чтобы быстрее вникнуть в технические аспекты разработки. Подписалась, наверное, на миллион каналов. Сначала была каша, а потом все уложилось. Любопытство очень помогает в работе.
- Готовься заранее
Чтобы задавать на встрече правильные вопросы и сделать переговоры продуктивнее, недостаточно мастерства интервьюирования. Изучение даже основных публичных материалов о компании и сфере заказчика даст информацию, которая погрузит в специфику. К тому же подготовка вопросов и предварительных схем ярко демонстрирует ответственный подход компании к каждому этапу работ.
- Задавай больше вопросов
Чем больше вопросов подготовлено к переговорам, тем лучше. С ними интервью пройдет продуктивнее, а оставшиеся вопросы можно направить заказчику для самостоятельного ответа. Даже если на вопросы ответят частично, это более полезно, чем ничего.
Владельцы любят говорить о своем бизнесе, и даже в удаленном формате получается собрать достаточно информации. Но к примеру, госсектор тяжело отвечает в переписке. Гораздо активнее работают на встречах-созвонах.
- Включи эмпатию
Считывать эмоции, подстраиваться под настроение и чувствовать контекст — важнейшие soft skills системного аналитика. Формальная отработка — не лучший подход. Боль и потребность заказчика необходимо прочувствовать. Нужно поставить себя на место конечного пользователя, увидеть продукт его глазами. Если подходить к заказчику с заботой, шанс создать классное решение намного выше!
- Используй разные приемы
В системной аналитике применяют огромное количество методов анализа. Это не значит, что надо использовать их все одновременно, но точно необходимо адаптировать прием под конкретный проект и заказчика. Кто-то хорошо пишет, кто-то говорит, кто-то думает и работает схемами. Если прием не работает, меняйте его.
Однажды я была на заводе на учебной практике. К нам прикрепили сотрудника, который понятия не имел, что с нами делать и что показывать. И завел он восемь молоденьких девчонок в какое-то техническое помещение, где один из работников ел борщ из контейнера. «Зачем ты их сюда притащил?» — и много слов со звездочкой, вот что мы услышали. С того момента я точно знаю — метод наблюдения подойдет далеко не везде и не всегда. Рядовые сотрудники часто не готовы к сотрудничеству и инновациям.
- Не пиши документ ради документа
Спецификация от аналитика не должна дублировать макет, она должна его дополнять. Например, макет не расскажет вам, что при наведении курсора на элемент должна появиться подсказка (если это не прототип), поэтому такое стоит прописать в спецификации. А вот цвет кнопки на макете можно точно не описывать. Не стоит быть предельно дотошными или искусственно «раздувать» документ. Каждый пункт должен быть оправдан, краток и понятен.
- Ничего не держи в голове
Каждый проект обладает огромным количеством материалов: переписки, договоры, требования, макеты, записи встреч, заметки и пр. Лучше хранить материалы в одном месте с настроенным доступом для членов команды проекта. Так ничего не потеряется, будет возможность обратиться к любому этапу проекта, а новому сотруднику будет проще влиться. Если такой площадки в компании нет, создайте ее для себя.
- Позаботься о читателе твоего документа
Функция аналитика — перевод с человеческого на технический и обратно. Не надо делать из сложного еще более сложное. Необходимо, чтобы всем все было понятно. Даже тем, кто не обладает техническими компетенциями или не имеет понятия о языках программирования.
- Проверяй и перепроверяй
Все мы люди, а не СhatGPT. Можно ошибиться, неправильно расшифровать конспект или домыслить от себя. Системный аналитик — мост между заказчиком и командой разработки. Если ошибется он, есть риск неверного развития проекта. Перепроверяйте свои записи, советуйтесь с коллегами, слушайте записи разговоров и всегда добавляйте источники информации в документы.
- Дели большое дело на кусочки
Чтобы ускорить запуск процесса разработки, команда аналитики должна отработать быстро. А скорость лежит в дисциплине и декомпозиционном подходе. Всегда стоит быть реалистом и честно оценивать свои возможности — не стоит планировать на день 15 спецификаций, если в силах сделать только 5.
- Не бойся критики
Если вы посмотрите скиллсет системного аналитика, там обязательно будет стрессоустойчивость и нейтральное отношение к критике. Системный аналитик взаимодействует с большим количеством людей. У каждого свое мнение, и не все умеют выражать его в деликатной форме. Надо быть к этому готовым и надо воспринимать любые переговоры как часть рабочего процесса. Не бойтесь показывать свою работу коллегам внутри проекта или более опытным аналитикам, чтобы они дополнили или покритиковали. Проекту будет только лучше.
Раньше при передаче работы на ревью, я беспокоилась: «понравится им или нет?». Сейчас я думаю только о том, чтобы мне дали информативные комментарии, добавили вводных и в итоге чтобы продукт получился еще лучше.
Как системный аналитик в прошлом, а ныне Senior Developer могу посоветовать автору как можно больше изучать программирование, фреймворки которые используются в их команде, больше читать код, дебажить если есть возможность - так уровень экспертности возрастет в разы и с разработчиками общий язык будет еще проще находить.
Но правда есть риск что в один момент придет понимание что проще взять и всё самому реализовать чем другим людям описывать, но это уже другая история😄
Удачи!
P.S. Не кто пишет что в статье неправильные мысли - теоретики. На нормальных проектах все так как пишет автор.
Благодарим за совет и комментарий! И вам удачи!
Автор, вы в курсе что есть ещё бизнес аналитик, ит аналитик, аналитик данных и т.п. и т.д.
Системный аналитик не должен общаться с заказчиком.
Пишите о том в чём совершенно не разбираетесь.
Чем ересь писать. Лучше поступите в профильный вуз, получите специальность, а дальше устройтесь в ит компанию.
Мы в курсе ) Почему вы считаете, что системный аналитик не должен общаться с заказчиком?
А ИТ архитектуру, "внутренности" других систем за него кто анализировать будет? Кто будет писать спеки на интеграцию? У Вас похоже бэкграунд в маленьких проектах для маленьких заказчиков, где есть просто "аналитик", т.к. объективно нет работы на несколько FTE.
Не совсем понятно. Общение с заказчиком не входит в профиль работы СА или, по вашему опыту, у СА просто не хватает на это времени и этим занимается кто-то иной?
Системный аналитик - это более частный случай бизнес-аналитика, с фокусом на используемую систему или техстек. Если бизнес-аналитик больше концентрируется на требованиях и атрибутах качества, то системный аналитик - на решении. Общается ли системный аналитик с бизнесом или нет - вопрос организации процесса разработки в конкретном проекте или компании.
1. Вот это (почти) не входит. "Что нужно", а уж тем более "Какую проблему это решит" выясняет бизнес аналитик. Задача системного аналитика предложить варианты реализации.
2. "Почти", т.к. ИТ-шники тоже в какой-то степени заказчики, а системному аналитику с ними проще общаться — они на более близких языках говорят. Но СА это делает вместе с БА, т.к. импакт на бизнес знает БА. Задача СА — знать импакт на системы.
Бесплатный вводный курс "Роли на ИТ проекте". Я так понимаю я общаюсь с какой-то копирайтерской конторой.
тогда надо иметь несколько проектов и группировать по компетенциям. :) А так у них один работник и чтец, и жнец и на дуде игрец. И всё плохо.
Я не то, чтобы свысока смотрю на людей, работающих на проектах уровня "я и Вася". Команда моего первого проекта, где я был ПМом, состояла из 2.5FTE (это включая меня :) В смысле я был СА (проект был очень технически низкоуровневый, там не было роли БА), тим-лидом разработки, техарком, ПМом, эккаунтом (реквесты на доработки и акты сдачи-приемки подписывал) и сам еще и кодил. Просто если уж контора "я и Вася" решила написать как нужно строить процессы на больших проектах, то хоть бы Энторнет почитали што ле. Не то, чтобы это какое-то сакральное знание. Правда непонятно зачем конторе "я и Вася" такие сложные процессы и так много ролей на проекте. На таких масштабах это будет бессмысленный мазохизм ради мазохизма. Да и денег у клиентов "я и Васи" не хватит на такую сложную проектную организацию.
Согласен с вами. Сам был в такой роли. После того как уволился через пару месяцев фирма закрылась )))
В описанных примерах это не фирма по разработке, а инди разработчик, фрилансер, самозанятый. Другие скиллы и процессы, нежели работа в компании.
Предположу, что автор об этом понятия не имеет и для него такой же тёмный лес
Потому что вы просто посредника для ленивых разраюотчиков и неопытных заказчиков, описываете. По описанию из вашего поста я тогда тоже системный аналитик. Потому что иногда заказчики и работодатели обращаются с просьбой - поговори с разработчиками сайта, и объясни им что я хочу чтобы на сайте кнопка должна быть зелёной и прочее. Но разработчики не хотят так просто. Доходит до пиздеца.
Несмотря на то, что разработчики и заказчики разговаривают на одном языке, приходится проходить весь этот квест.(на примере кнопки) А именно:
1. Напиши на айтишном формулировку "Хочу зелёную кнопку на сайте www.example.ru/example.html в ргб-формате, вот тебе код цвета.
2. Напиши, что при этом не надо делать. Ведь есть долбоебы, которые отсебятину хуярят. Им мало задания "сделать кнопку зелёной", они обязательно изменят размер, перепишут код кнопки илие ще какую хуйню учудят оправдываясь тем, что "вы же не писали, что так не надо делать".
3. Приходится ещё доказывать что это заказчику необходимо. Ведь находится достаточное количество долбоебов , которые мнят себя божеством, которое ещё нужно уговаривать сделать изменения на сайте, в противном случае идут понты , а вам это не нужно, а зачем вам это?
4. Оплата. Сейчас практически каждый не в рот ебись какой бизнесмен и уникальный. Простейшую задачу, изменить кнопку нужно заплатить в пять раз выше в среднем чем на рынке. Ведь программист не человек, а высшее существо.
5. Сроки. Обязательно обсуди сроки. Ведь изменить цвет кнопки настолько непосильная задача, что может занять неделю времени. При этом, зная достаточное количество индивидов, они эту неделю часто не в работе проводят а на курсах повышения самооценки и саморазвития, ведь нельзя сделать просто та кнопку зелёной. Надо поверить в себя, поверить в свой успех, а для этого надо посещать курсы у инфоцыган.
6. Тестирование мать его за ногу и прием в работу.
И вот спустя несколько раундов, заказчик наблюдающим за этим дерьмом понимает, что с разработчиками этими лучше не работать, посылает все нахуй и ищет фрилансера.
И все это ебанатство действительно нахуй не нужно, потому что это лишня трата денег нервов. Всего лишь нужно вспомнить что все люди и умеют друг с другом разговаривать на человеческом языке
Ваш вопрос примерно такой же как: почему водитель комбайна не должен готовить договоры?
У вас есть специальность? Какая?
1. Дадада. Сам хотел написать. Похоже авторы по ЮТьюбу учились.
2. А кто такой в Вашей терминологии ИТ аналитик? Они вроде все ИТ аналитики :)
ИТ-аналитик про требования к АС, требования к реализации. Например, требования к масштабируемости. Как правило, больше про нефункциональные требования
Ммм... А как эту роль можно отделить от БА и СА? Условно сколько клиентов, заказов будет выясняет БА у бизнеса. Как это транслируется в системные требования оценивает СА. На больших проектах — 150+ одновременно фулл-тайм ресурсов на одном проекте — у меня был отдельный (технический) архитектор. На проектах поменьше шэрил кого-то между несколькими проектами, т.к. на FTE работы не набиралось. Роль техарка была очень-очень глубоко знать платформу / стэк и выявлять техриски и предлагать варианты оптимизации перформанса. Работа СА — это все ж быстро разобраться в ИТ архитектуре клиента, ему не нужно, да и времени не хватит знать какую-то конкретную платформу inside out.
PS (Технический) архитектор — это не тот балабол в больших компаниях, который только стрелочки и квадратики в презентациях рисует, а своими руками в системах не копается.
«Подписалась, наверное, на миллион каналов.»
Чтобы стать хорошим аналитиком требований, не нужно смотреть ютюб каналы. Нужно:
- иметь хороший технический бэкграунд (разработка, внедрение, сопровождение ПО) или профильное образование;
- читать Вигерса;
- хотя бы поверхностно ознакомиться с BABOK, там все описано - от компетенций аналитика, до применяемых техник управления требованиями.
В 2КХХ году так уже никто не учится.
согласны с комментарием! Спасибо за него. Но не все приходят в анализ с техбэком, а понимать надо много и быстро. Для Ангелины это был один из способов нарастить знания, и он почти также хорош, как перечитывать Вигерса
Ваш уровень компетенций и качества понятен. Для адекватных специалистов ваши советы неприемлемы.
Солнышко, жги еще :)
Советы актуальны для любой сферы ))
Да, согласны!
ох уж эти KPI по статьям на VC
что поделать, VC - наше все) А у вас тоже KPI?