Системный аналитик в IT-компании — специалист на стыке аналитики, разработки, менеджмента. Он анализирует потребности заказчика, формулирует требования к IT-проекту и курирует процесс разработки. Системный аналитик создает основу продукта и делает так, чтобы результат соответствовал желаемому. Чтобы погрузиться в работу системного аналитика, поговорили с Ангелиной Шконда, Middle System Analyst IT-компании Smartex.
Обязанности системного аналитика
Обычно процесс работы системного аналитика выглядит так:
- Cбор требований. Нужно выяснить, что заказчик вообще хочет от команды разработки. Аналитик собирает все возможные данные, находит и уточняет проблемные места, проводит интервью. На интервью встречаются такие вопросы: «Что нужно?», «Какую проблему это решит?», «Точно ли это нужно?»
- Оформление в ТЗ. Собранная информация превращается в спецификации требований к программному обеспечению — конкретные задачи для разработчиков.
- Сопровождение разработки. В процессе разработки к системному аналитику могут приходить за уточнениями по требованиям и за оперативным внесением изменений в документацию при возникновении новых требований. Бывает, что аналитик занимается авторским надзором (проверкой фичи на соответствие требованиям при ее появлении на стенде).
- Демонстрация заказчику. Когда продукт готов к новому релизу, системный аналитик демонстрирует работу заказчику и анализирует обратную связь вместе с менеджером проекта.
Задачи системного аналитика разноплановые: общение с заказчиком, разбор пользовательских сценариев, анализ и описание требований, сопровождение процесса разработки.
Отличия системного аналитика от других профессий
Похожий список обязанностей есть у менеджера проектов, менеджера по продукту, системного архитектора, бизнес-аналитика и технического писателя. В реальной жизни этой сферы часто не разделяются и получаются «люди-оркестры», но различия в профессиях есть.
А теперь к заповедям
- Имей представление о возможностях команды и предложениях на рынке.
При обсуждении проекта аналитику нужно не только фиксировать требования заказчика, но и ясно понимать возможности своей команды, учитывать ресурсы проекта и доступные технологии. В идеале это выглядит так: получение требований => быстрый анализ текущих возможностей => выдача рекомендаций. Конечно, знать все сложно (цитата автора: «абсолютно анпосибл»), но быть в курсе технического рынка жизненно необходимо.
В начале карьеры я приставала ко всем коллегам, чтобы быстрее вникнуть в технические аспекты разработки. Подписалась, наверное, на миллион каналов. Сначала была каша, а потом все уложилось. Любопытство очень помогает в работе.
- Готовься заранее
Чтобы задавать на встрече правильные вопросы и сделать переговоры продуктивнее, недостаточно мастерства интервьюирования. Изучение даже основных публичных материалов о компании и сфере заказчика даст информацию, которая погрузит в специфику. К тому же подготовка вопросов и предварительных схем ярко демонстрирует ответственный подход компании к каждому этапу работ.
- Задавай больше вопросов
Чем больше вопросов подготовлено к переговорам, тем лучше. С ними интервью пройдет продуктивнее, а оставшиеся вопросы можно направить заказчику для самостоятельного ответа. Даже если на вопросы ответят частично, это более полезно, чем ничего.
Владельцы любят говорить о своем бизнесе, и даже в удаленном формате получается собрать достаточно информации. Но к примеру, госсектор тяжело отвечает в переписке. Гораздо активнее работают на встречах-созвонах.
- Включи эмпатию
Считывать эмоции, подстраиваться под настроение и чувствовать контекст — важнейшие soft skills системного аналитика. Формальная отработка — не лучший подход. Боль и потребность заказчика необходимо прочувствовать. Нужно поставить себя на место конечного пользователя, увидеть продукт его глазами. Если подходить к заказчику с заботой, шанс создать классное решение намного выше!
- Используй разные приемы
В системной аналитике применяют огромное количество методов анализа. Это не значит, что надо использовать их все одновременно, но точно необходимо адаптировать прием под конкретный проект и заказчика. Кто-то хорошо пишет, кто-то говорит, кто-то думает и работает схемами. Если прием не работает, меняйте его.
Однажды я была на заводе на учебной практике. К нам прикрепили сотрудника, который понятия не имел, что с нами делать и что показывать. И завел он восемь молоденьких девчонок в какое-то техническое помещение, где один из работников ел борщ из контейнера. «Зачем ты их сюда притащил?» — и много слов со звездочкой, вот что мы услышали. С того момента я точно знаю — метод наблюдения подойдет далеко не везде и не всегда. Рядовые сотрудники часто не готовы к сотрудничеству и инновациям.
- Не пиши документ ради документа
Спецификация от аналитика не должна дублировать макет, она должна его дополнять. Например, макет не расскажет вам, что при наведении курсора на элемент должна появиться подсказка (если это не прототип), поэтому такое стоит прописать в спецификации. А вот цвет кнопки на макете можно точно не описывать. Не стоит быть предельно дотошными или искусственно «раздувать» документ. Каждый пункт должен быть оправдан, краток и понятен.
- Ничего не держи в голове
Каждый проект обладает огромным количеством материалов: переписки, договоры, требования, макеты, записи встреч, заметки и пр. Лучше хранить материалы в одном месте с настроенным доступом для членов команды проекта. Так ничего не потеряется, будет возможность обратиться к любому этапу проекта, а новому сотруднику будет проще влиться. Если такой площадки в компании нет, создайте ее для себя.
- Позаботься о читателе твоего документа
Функция аналитика — перевод с человеческого на технический и обратно. Не надо делать из сложного еще более сложное. Необходимо, чтобы всем все было понятно. Даже тем, кто не обладает техническими компетенциями или не имеет понятия о языках программирования.
- Проверяй и перепроверяй
Все мы люди, а не СhatGPT. Можно ошибиться, неправильно расшифровать конспект или домыслить от себя. Системный аналитик — мост между заказчиком и командой разработки. Если ошибется он, есть риск неверного развития проекта. Перепроверяйте свои записи, советуйтесь с коллегами, слушайте записи разговоров и всегда добавляйте источники информации в документы.
- Дели большое дело на кусочки
Чтобы ускорить запуск процесса разработки, команда аналитики должна отработать быстро. А скорость лежит в дисциплине и декомпозиционном подходе. Всегда стоит быть реалистом и честно оценивать свои возможности — не стоит планировать на день 15 спецификаций, если в силах сделать только 5.
- Не бойся критики
Если вы посмотрите скиллсет системного аналитика, там обязательно будет стрессоустойчивость и нейтральное отношение к критике. Системный аналитик взаимодействует с большим количеством людей. У каждого свое мнение, и не все умеют выражать его в деликатной форме. Надо быть к этому готовым и надо воспринимать любые переговоры как часть рабочего процесса. Не бойтесь показывать свою работу коллегам внутри проекта или более опытным аналитикам, чтобы они дополнили или покритиковали. Проекту будет только лучше.
Раньше при передаче работы на ревью, я беспокоилась: «понравится им или нет?». Сейчас я думаю только о том, чтобы мне дали информативные комментарии, добавили вводных и в итоге чтобы продукт получился еще лучше.
Комментарий недоступен
Благодарим за совет и комментарий! И вам удачи!
Комментарий недоступен
Мы в курсе ) Почему вы считаете, что системный аналитик не должен общаться с заказчиком?
А ИТ архитектуру, "внутренности" других систем за него кто анализировать будет? Кто будет писать спеки на интеграцию? У Вас похоже бэкграунд в маленьких проектах для маленьких заказчиков, где есть просто "аналитик", т.к. объективно нет работы на несколько 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?
Нечаянно зашел спустя месяцы. Толковая, жизненная статья.
Комментарии под статьей не удались - но это не вина авторов :)
Советы актуальны для любой сферы ))
Да, согласны!
Не понял смысла статьи. Галопом по европам, сплошные общие фразы и банальности, выдранные из таких же тысяч статей. Ничего абсолютно нового.
И да, для вас, наверное, будет новостью: именно заказчику от именно команды разработки - в общем случае, ничего не нужно. Подумайте, почему. Вы ж аналитик, а не копипастер?
Вадим, спасибо за мнение! Постараемся в будущих статьях быть более конкретными!