Серия «Работа системного аналитика»

Я аналитик-самоучка с опытом ±3 года. Поэтому, иногда, подогреваемый синдромом самозванца, нет-нет да и посматриваю каких-то блогеров вкатывающих в аналитику.

От них и узнал об этой книге. Реально, каждый друг с другом не пересекается, но все в какой-то момент причисляли книгу к категории “ЭТО БАЗА!”.

Соблазнился на тайные магические знания сразу, но к прочтению приступил только спустя 1,5 года.

Если серьёзно, по делу и по содержанию, то книгу рассматриваю с 3-х позиций, т.к. за свой скромный стаж успел поработать в большом-большом банке, среднем телекоме и маааленькой медицине.

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

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

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

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

Большую часть книги я прочитал из соображения “Блин! Ну не зря же я её купил!”. И даже при таком раскладе время было потрачено не зря, т.к.:

• Часто ловил себя на мысли “О! Оказывается вон оно как работает!)”;

• В книге много UML диаграмм - некоторые моменты начал применять в своих задачах, т.к. увидел что можно улучшить;

• Подробнее ознакомился с подходами к версионированию, пагинации и мягкому удалению. Что кстати, т.к. скоро по ним предстоят задачи;

Из минусов могу отметить:

• Много воды;

• Лишние или повторяющиеся из раза в раз примеры;

А если моё мнение не повлияло на ваше желание получения каких-то тайных знаний, то рекомендую читать книгу также как “Разработка требований к программному обеспечению” - только главу по теме, с которой вы впервые столкнулись прямо сейчас. Задачу за вас она не сделает, но подскажет куда смотреть при выполнении.

В какой-то момент от старшего коллеги услышал что он SQL вообще не знает! Что было логично, т.к. в банке для написания хороших запросов был выделен целый небольшой отдел, а в небольшом телекоме нам достаточно было расписать что откуда брать и по какому принципу отфильтровывать перед выдачей. А сам запрос, опираясь на твою писанину, напишет разработчик.

Тем не менее, если знать SQL, то работать становится намного проще, т.к. можно написать небольшой запрос состоящий из SELECT, JOIN и WHERE и уберечь себя от прыганья туда-сюда по 3-4 табличкам с огромным количеством полей. Всё ещё жду когда потребуется где-то применить HAVING который постоянно спрашивают на собеседованиях, но момент всё никак не наступит. Возможно просто не там работаю или опыт маленький.

Спасибо за внимание, надеюсь джунам и вкатунам будет полезно. Выводы делайте сами.

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

Пример

Дано: Ты аналитик отвечающий за страницу сайта на картинке.
Видишь что в Outlook (почта) пришло письмо с информацией о том что в Jira (задачник) на тебя назначили новую задачу PRZ-32718 (просто номер).
Всё что в ней написано "Нужно добавить баннер на страницу сайта. Как можно быстрее"

Решение: Первое что мы понимаем - это то что из описания задачи мы ничего не понимаем. Первым делом нам нужно понять будем ли мы это вообще делать (возможно не будем). В связи с этим мы делаем следующее:

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

2. Назначаем встречу в календарь на договоренное время.

3. Подключаемся на встречу и заваливаем заказчика кучей интересующих нас вопросов:

• Зачем добавлять баннер?

• Как он должен выглядеть? (цвет, размер, расположение, эффекты, анимация)

• Какое должно быть содержание баннера?

• Где взять содержание баннера?

• Когда баннер должен появиться на странице?

• Сколько баннер будет там висеть?

• При каких условиях баннера должен появляться?

• Что можно сделать с баннером (посетителю\администратору сайта) ?

• К кому посылать договариваться, если он кому-то будет мешать?

• Есть ли какие-то дополнительные условия, без которых баннер не имеет смысла?

Если после допроса стало понятно что доработку делать надо. И тем более есть понимание что и как должно измениться в системе, чтобы задача была выполнена, то только тогда вы идёте просить поработать дядю разработчика

Разработка\доработка

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

1. Ставите ему в Jira максимально конкретную задачу.
   Примерный текст:
   "- На странице https://ru.saitикsaitикsaitик.org нужно добавить всплывающее окно.
   - Размеры, содержание и оформление окна находится тут (ссылка картинку с описанием)
   - Логика появления: окно должно появляться через 10 секунд после полной загрузки страницы сайта.
   - При появлении окна должен воспроизводиться звуковой файл (ссылка на звуковой эффект)
   - Кнопка закрытия окна (красный крестик) появляется через 15 секунд после полного отображения окна на экране клиента.
   - При нажатии на красный крестик окно исчезает
   - При нажатии на любую другую часть данного окна происходит переход клиента по ссылке https://sobaka-lalalakщ.ru
   - Окно должно быть добавлено на сайт до 15.12.24
   - После 10.01.25 окно должно перестать появляться

2. Идём пить чай, ждём либо вопросов от разработчика, либо сообщение о готовности доработки.

3. Проверяем сами работает ли так как надо или просим об этом тестировщика (специальный человек для проверок). Если есть "косяки", то пишем разработчику что и где нужно поправить.

4. Если "косяков" нет, то пишем заказчику и просим лично убедиться что всё работает так как он хотел в своих влажных фантазиях.

5. Далее, либо получаем сообщение "Спасибо, всё работает", либо получаем список "косяков" или дополнительных "хотелок" которые возникли после созвона (такое очень часто бывает). Всё это нужно передать разработчику.

6. Если получили "Спасибо, всё работает", то закрываем задачу и реально идём пить чай.
   В противном случае повторяем действия с 2 по 5 до получения "Спасибо, всё работает". Иногда, если заказчик добавляет и добавляет "хотелки", то надо поговорить и поставить точку. А всё что после неё договориться унести в следующую задачу.

Резюме

Вот так плюс минус можно описать 60% рабочего времени системного аналитика.

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

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