Открыв первый раз вакансию, увидела Море совершенно непонятных слов и аббревиатур. Естественно, я не имела понятия что это и зачем нужно, и первое время по наитию искала какую-то информацию и пыталась понять, где это можно "прикрепить" к работе Системного аналитика.
Возьмем стандартную вакансию на HH на системного аналитика (не будем рассматривать Senior, обратим внимание на middle и Junior) и посмотрим, что требуют от аналитиков и как это применять на практике.
1. ФТ - функциональные требования
Итак, что здесь требуется от аналитика? Во-первых - умение получить конкретные требования от заказчика, вместо списка возможных "хотелок", и во-вторых уметь отделить функциональные требования от не функциональных. Корректно зафиксировать в документе функциональные требования, согласовать их с заказчиком и отдельно описать не функциональные.
2. ТЗ и ЧТЗ
Что требуют здесь? Написание Технического задания и Частичного технического задания. Техническое задание полностью описывает продукт или какую-то его автономную функцию, все остальное будет Частичным техническим заданием. По сути - это конечный документ работы аналитика - получить требования, проанализировать, систематизировать....и подготовить документ, по которому разработчик уже сможет написать необходимую часть кода, а тестировщик протестировать.
Идем дальше, следующий и обязательный практически во всех вакансиях навык :
3. BPMN - моделирование бизнес процессов.
Что же это такое, и зачем нам это нужно? Для правильно моделирования процесса необходимо знать нотацию, она содержит более 50-ти разных элементов. Но для успешного построения процессов на начальном этапе достаточно и половины из них. Зачем моделировать процесс? При наглядном рассмотрении процесса проще увидеть ошибки, заметить, что какая-то ветка процесса не доведена до логического завершения и многие другие моменты.
4. UML моделирование
Здесь вариантов уже намного больше, чем в BPMN, т.к. достаточно разнообразен набор диаграмм в нотации.
Здесь в основном требуется:
- Диаграмма последовательностей (sequence diagram) - предназначена для визуализации на временной шкале жизненного цикла какого-то процесса. Проще говоря, показывает в какой последовательности, и как взаимодействуют системы ( например, Пользователь послал запрос - система обработала запрос, отсылает ответ. Пользователь в это время находится на экране ожидания ответа)
- Диаграмма прецедентов/вариантов использования (use-case) - данная диаграмма описывает функционал, доступный различным пользователям.
- Диаграмма классов (class) - можно использовать для моделирования данных. С ее помощью легко смоделировать и проследить иерархию классов в системе.
Конечно, это не конечный список всех диаграмм, и каждый проект выбирает для себя наиболее удобные в использовании именно для их системы, но эти основные нужны почти всегда и везде.
5. User Story - cледующий почти обязательный пункт
Почему почти? чаще его используют в своей работе бизнес аналитики, а вот у системных он такой популярностью не пользуется. Однако, ввиду того что в последнее время границы между системным аналитиком и бизнес не явные, то и знать данную методику стоит. По сути - это короткие сценарии использования/функциональности, написанные по установленным правилам. Упор в данных спецификациях делается на полученную в итоге ценность для пользователя.
6. SQL
SQL в различных спецификациях безусловно необходим аналитику. Зачем? Для того что бы уметь самостоятельно сделать запрос в Базу данных, посмотреть какие данные в каком формате будут получены, проверить возможность получения тех или иных данных, собрать статистику по каким-то параметрам и многое другое. Так что да, изучать и уметь пользоваться надо обязательно, ведь не будешь же за каждым чихом бегать к коллегам с просьбой вынуть тебе из базы какие-то данные.
7. JIRA, Confluence
Сложно сказать насколько актуально данное требование в связи с некоторыми проблемами с заграничным ПО, но многие вакансии до сих пор пестрят этими требованиями. Что же это такое? JIRA - это система для постановки задач, фактически это электронный аналог доски с наклейками и задачками + доп. функционал. Можно сделать общую фичу, а внутри нее поставить задачки разным коллегам, по мере выполнения каждый будет оставлять комментарии, прикреплять документы, списывать время на работу над задачей и менять ее статус (в ожидании, в работе, выполнена, отменена), таким образом легко проконтролировать деятельность каждого сотрудника и в целом оценить, как движется разработка.
Confluence - внутренняя википедия вашего проекта. Вы можете создавать там страницы (с различными правами доступа), разделы, давать ссылки на другие страницы - в общем это электронный вариант всей документации + заметок по вашему проекту.
8. Agile
Гибкая методология разработки. Есть в интернете хорошие небольшие статьи по этой методологии. Суть сводится к тому, что современные команды не работают по принципу - "Пишу одно большое ТЗ - Отдаю в разработку - дальше меня не касается". Во первых, большая разработка дробится на несколько более мелких кусков, пока аналитик пишет ТЗ на какой-то кусок, разработчики работают над предыдущим куском ТЗ. Если в процессе разработки появляются проблемы, новые вводные, аналитик на ходу меняет уже ранее написанные требования, и все время следит за их актуальностью. Есть несколько принципов данной методики, конечная цель - постоянно поставлять качественное ПО покупателю, своевременно вносить изменения в документацию и проявлять гибкость во время всей работы над ПО.
9. JSON,XML
Текстовые форматы данных. Что требуется от аналитика? Не смотреть на такой файл как баран на новые ворота...уметь его прочитать, распарсить в таблицу или если потребуется самому подготовить файл в таком формате. Для XML так же требуется знать некоторые основы построения файла, запрещенные к использованию символы.
10. REST и SOAP
Два различных понятия используемых для интеграций. В одной статье так конечно и не расскажешь что они из себя представляют, поэтому предлагаю данный вопрос отложить на будущий пост или поизучать самостоятельно. Что такое интеграции - это взаимодействие различных систем, компонентов. Тема очень обширная и двумя определениями не обойдешься, до для собеседования достаточно знать определения и примерно представлять, что это.
Итак, какие еще требования встречали в вакансиях? Возможно есть есть предложения что еще стоит рассмотреть в посте?