Дайджест полезного #3

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

1) «Как понять, что User Story составлена корректна? Есть ли какие-либо методологии?» Здесь либо не отвечают ничего, либо вывозят на опыте. Прикладываю хорошую статью, где подробно рассказали и о методологии INVEST и о критериях приемки.

2) «Какие паттерны реализации микросервисной архитектуры можешь назвать?» Задаю этот вопрос в блоке об архитектуре, очевидно, что при работе с микросервисами есть некий набор правил. Статья покрывает большинство популярных паттернов, от декомпозиции (DDD) и рефакторинга (Strangler) до развертывания и мониторинга.

3) «Можно ли использовать GET для создания ресурса, а POST для получения информации о ресурсе». Можно, но кандидаты теряются на этом вопросе. При таком подходе приложение не будет RESTFul, но технически ограничений нет. Не забываем, что в GET для передачи информации используются query параметры, а в POST полезная информация содержится в body. В этом материале доступно разбирают разницу между GET и POST.

Какой вопрос вызвал у вас затруднение на последнем интервью?

Какой понедельник без мема :)

Планы на неделю: продолжение цикла о собеседованиях, истории успеха, дайджест полезного.

Все, что вы любите!

@notsystemanalysis

Процесс собеседования. Бизнес анализ

Итак, с презентацией себя разобрались. Вы складно рассказали о своем опыте, произвели первое положительное впечатление, теперь настало время проверить харды. Вообще интервью делится на 2 типа: компания может спрашивать общую информацию по бизнес/системной аналитике (топ-100 вопросов на СА) или же задавать специфические вопросы по стеку, который используют. И если первый тип мы сегодня разберем, то ко второму подготовиться проблематично, потому что все, что у вас есть – это вакансия. Вы и без меня знаете, что ожидание и реальность сходятся достаточно редко. Ну да ладно, давайте к теме.

В блоке по бизнес-аналитике спрашивают классические вещи из «Разработки требований к программному обеспечению». От роли БА/СА на проектах и видов требований до документирования и моделирования. В последнее время на вопросы по бизнес-анализу выделяют не так много времени, зато активно спрашивают по системному, а конкретно интеграциям. Но это тема следующей статьи. Структурно блок БА делится на следующие части:

1) Общие вопросы о роли БА/СА
2) Жизненный цикл проекта и гибкие методологии
3) Работа с требованиями
4) Работа с документацией
5) Моделирование

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

Общие вопросы. Здесь спрашивают о том, чем вообще занимается бизнес/системный аналитик. Какого его роль и ценность в команде? Какие задачи он решает? В чем разница между бизнес и системным аналитиком? А может быть можно обойтись вообще без аналитика? Какие артефакты являются результатом работы аналитика? Какие инструменты он использует?

Жизненный цикл проекта и гибкие методологии. По жизненному циклу не так много вопросов, тут скорее важно понимать, какие этапы ЖЦ существуют и что на них делает аналитик. А вот по гибким методологиям спрашивают хорошо. Что такое SCRUM и Kanban? В чем разница между этими подходами? Какие роли и церемонии есть в SCRUM? Назови манифесты Agile. Исключительно теоретические знания, которые не применяются в работе, но почему-то спрашивают.

Работа с требованиями. Спрашивают вообще все что касается требований. Привести классификации требований. Какие методики сбора требований существуют? Какие применить в той или иной ситуации? Как управлять требованиями? Как валидировать и верифицировать их?

Работа с документацией. Все что касается документирования и фиксации требований, как традиционные виды (ТЗ), так и гибкие (Use Case/User Stories). Какие разделы бы включили в ТЗ и почему? Как составили бы интеграционную спецификацию? Знакомы ли с ГОСТ 34? Что такое Use Case и User Stories, приведите примеры?

Моделирование. Спрашивают знание основных нотаций. Что такое BPMN и какие элементы есть? Какими диаграммами UML пользуешься? Плюс конкретные вопросы по отдельным UML диаграммам, в духе – Какие виды связей на диаграмме классов можешь назвать?

Резюмируя, в бизнес-аналитике очень помогают развитые софты и умение «болтать». Все, что касается работы аналитика и требований – вопросы дискуссионные, на которые можно распыляться долго. Да, конечно всегда есть правила и рекомендации, но никто не запрещает сказать: «А у нас в компании было вот так» и придумывать, придумывать, придумывать.

Если есть необходимость разобрать практическую часть блока по бизнес-аналитике – пишите в комментарии, с удовольствием сделаю.

#база

Истории успеха #2

Продолжаем заряжаться на успех. Своей историей делится моя близкая подруга, пожелавшая остаться анонимной. Она, как и многие, устроилась в аналитику на стажерскую позицию за 35к рублей. Спустя год работы прошло перфоманс ревью, где подруге подняли зп до 50к (хотя она думала, что дадут хотя бы 80к). В итоге, выйдя на рынок, ей удалось получить оффер на 160к. Невероятный рост в 4.5 раза!

1) Чем занималась до аналитики?
Училась в вузе, даже по специальности получается. За время учебы пыталась хоть где-то понабраться опыта, получалось так себе. Под конец вуза работала в крупной компании за 35 тыщ рублей, потому что столько ляпнула на собесе, лишь бы взяли для опыта.
Повышать меня там, конечно же, никто не рвался. Проработала год.

2) Системная аналитика - не самое популярное направление в ИТ, почему решила выбрать именно его?
Кодить не мое, а вот болтать и анализировать - как будто бы да.

3) Сколько и как обучалась до выхода на собеседование?
Не считая года работы в реальном проекте и каких-то знаний из универа, читала статьи по подборке "топ-50 навыков системного аналитика", чтобы четко отвечать на собесах.

4) Сколько собеседований потребовалось для получения оффера?
Самое интересное 🤭
Пока я сидела в компании за 35, решила выйти на рынок и походить по собесам (подтолкнул автор канала :))
Для меня, как для девочки из небольшого города, было нереально круто получить зп в 100к на руки, так и решила смотреть.
Оказалось, что если свой опыт в резюме правильно подать, под соусом аналитики, то рынок может предложить и больше.
Было собеса 4, из них по 3 офферы - на 120, 130 и 160!
160 кстати я уже выторговала, говоря, что есть оффер на 150)
Так на 160 и устроилась.

5) Что было самое сложное в процессе обучения?
Было страшно выходить на рынок, играл синдром самозванца: у меня недостаточно опыта, я мало знаю, я не могу просить столько денег.

6) Когда опускались руки, что помогло не бросить и дойти до конца?
Хотелось доказать себе, что я смогу. Да и работать за 35к, когда видишь зарплаты по рынку, конечно, неприятно :)

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

Как вам такой результат?
Кстати, своей историей можете поделиться, заполнив форму по ссылке: https://forms.gle/iPPYqu8dELWYcQfU6

Дайджест полезного #4

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

1) Ролик автора с небольшого канала, который совершенно случайно вылетел в предложке. Арман разбирает как технические аспекты, вроде того, что программирование (аналитика) – это, в первую очередь, практика. Так и психологические аспекты, вроде постоянного прохождения собеседований и умения продавать себя. Кратко и по делу. От себя добавлю, что бесконечный цикл самосовершенствования иногда надо прерывать и выходить на проверку компетенций (собес). Может быть ты прямо сейчас недополучаешь лишнюю копеечку?

2) «Различия SOA и микросервисной архитектуры». Часто спрашиваю этот вопрос и часто получаю ответ: «В SOA используется ESB». И это правильно, но без учета концептуальных различий. SOA, в первую очередь, направлен на переиспользование сервисов, когда как в MSA повторное использование избегается. Микросервисы строятся для решения конкретной, узкой задачи. В этом плане SOA более тяготеет к монолитам, с их зависимостями.

3) «System Design Interview Survival Guide» (только с VPN). Я обожаю системный дизайн! Считаю эту секцию отличным способом проверки всех имеющихся знаний кандидата на практике. Понятно, что за час невозможно спроектировать телеграм, но куда интереснее слушать, как аналитик пытается решить ситуацию, нежели в очередной раз рассказывает разницу между ESB и брокером. Да, это уровень ближе к архитектору, аналитиков чаще просят смоделировать ERD. Но если я понимаю, что кандидат сильный, то могу попросить его спроектировать что-нибудь простенькое, например, систему для сокращения ссылок. В статье рассматриваются ключевые концепции системного дизайна, а также популярные паттерны проектирования. Описано крайне доступно, это позволяет стуктуровать имеющиеся знания.

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

Астрологи объявили рабочую неделю.
Рекомендуют смотреть мемы для поднятия настроения!

@notsystemanalysis

Процесс собеседования. Системный анализ

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

1) Архитектура ПО
2) Веб-сервисы
3) Базы данных

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

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

Веб-сервисы. За этой темой кроятся вопросы, затрагивающие интеграцию. Причем от верхнеуровневых, до конкретных. Какие виды интеграции можешь назвать? В чем разница между синхронной и асинхронной интеграциями? Что такое REST и SOAP? В чем разница между ними? Что такое ESB? В чем разница между брокером и ESB? Какие способы аутентификации можешь назвать?
На самом деле, тут копать и копать, можно выдергивать отдельную технологию и рассуждать о ней. Но наиболее часто и глубоко спрашивают про REST. Что такое RESTful принципы? Какие методы HTTP можешь назвать? Какие методы идемпотентны? Какие коды ответов знаешь?
Из интересного, меня однажды спросили: «Почему для реализации чата используется WebSocket, а не gRPC?» Как бы вы ответили на такой вопрос?)

Базы данных. Классика, которую спрашивают, как у бизнес, так и у системных аналитиков. Чаще всего просят решить простенькую задачу на SQL, с использованием JOIN, и агрегатных функций. Если говорить о теории, то я бы выделил следующие вопросы: В чем разница между SQL и noSQL базами данных? Что такое нормализация? Что такое транзакция? Какие способы масштабирования БД можешь назвать?

Если подводить итог, секцию системного анализа не так-то просто пройти с наскока. Нужна предварительная подготовка и понимание концепции взаимодействия систем. С другой стороны, было бы желание, а остальное точно получится.

#база

Истории успеха #3

Уже ставшая регулярной пятничная рубрика. Арина, моя менти, вкатилась в аналитику с 0 опыта на 100к. Примечательно то, что она хотела стать исключительно бизнес-аналитиком, без технической составляющей. С одной стороны, это проще, с другой, сильно сужается круг поиска. Вот что она рассказывает сама.

1) Чем занималась до аналитики?
Работала в саппорте

2) Системная аналитика - не самое популярное направление в ИТ, почему решила выбрать именно его?
Знакомый вкатился на ба, а потом на са. Рассказал, что это реально и можно не просто тухнуть на обычных работах, я решила, что мне по духу ба проходит

3) Сколько и как обучалась до выхода на собеседование?
Сначала обучалась сама, смотрела всё что можно, потом обратилась к Андрею, и он помог уложить всё в голове, также разобрали bpmn и uml

4) Сколько собеседований потребовалось для получения оффера?
Я вкатывалась, поэтому мне понадобилось больше, чем людям с реальным опытом
Искала работу примерно месяц, проходя по 3-4 собеса в день. Короче без напряга

5) Что было самое сложное в процессе обучения?
Найти уверенность в себе и своих силах, наверное

6) Когда опускались руки, что помогло не бросить и дойти до конца?
Нехватка денег 🤣

7) Какой совет ты дал бы сам себе в начале пути?
Ссать и делать!

А что было самым сложным в обучении для вас?

Каналу месяц!

(Не)Системная аналитика появилась ровно месяц назад, 16 августа. За это время мы с вами плавно преодолели отметку в 150 человек! Для меня это огромная цифра, спасибо каждому кто подписался. Мы пилили посты и мемы, делились полезным и заряжались на успех. Я очень рад, что смог найти единомышленников среди вас, надеюсь, что вам интересно. Впереди большие планы, бэклог заполнен идеями, поэтому без контента вас не оставлю.

Я создавал канал, преследуя 2 цели: собрать ответы на популярные вопросы с консультаций, кстати, если кому-то нужна помощь, обращайтесь. А также использовать тг, как способ разнообразить рутинные будни. Мы же все понимаем, что айтишная работа не самая захватывающая) Рекомендую попробовать завести блог - это не страшно.

Еще раз спасибо, что подписаны на меня! Лучшая благодарность за контент – рассказать о канале знакомым аналитикам, вдруг им тоже понравится.

Обнял, приподнял,
Андрей

З.Ы. В комментариях принимаю идеи по улучшению канала. Чего не хватает, а что можно убрать?

Дайджест полезного #5

ДИСКЛЕЙМЕР: Автор канала не является дипломированном психологом и предлагает решения, основываясь исключительно на житейском опыте. Если вы чувствуете проблемы, с которыми не можете справиться, обратитесь к специалистам.

Сегодняшняя подборка содержит статьи околоайтишной тематики. Проблема, которая наиболее часто встречается у ребят на консультациях – синдром самозванца. Кто-то сомневается в своих способностях и боится попробовать новое, а кто-то прямым текстом говорит: «Да, у меня синдром самозванца». Хотя никакого отношения к медицине «синдром» не имеет. Тем не менее ловите ссылки на три полезные статьи, еще раз убеждающие вас в том, что вы все сможете!

1) «Что такое синдром самозванца и почему необязательно с ним бороться». Статья нетологии, где детально расписываются признаки и разновидности синдрома, а также приводятся советы о том, как побороть свои страхи. Классифицируя виды «самозванцев» поймал себя на мысли, что во мне уживаются все из них.

2) «Синдром самозванца. Как обрести уверенность и начать действовать». Чуть более глубокое чтиво, раскрывающее такие понятия как «эксперт» и «псевдоэксперт». В статье рассматриваются популярные искажения, и возможные корни проблемы. После прочтения картинка в голове вырисовывается четче.

3) «Синдром самозванца в IT: почему возникает и как его преодолеть». Ну и доходим до профессии. Статья является компиляцией того, что описано в пунктах 1 и 2, только с уклоном в ИТ тематику. Поскольку нам отовсюду говорят, что квалифицированный специалист должен постоянно развиваться и прокачивать скилл, очень легко выгореть и загнаться. Не надо так!

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

Утречко!

Напоминаю, без ТЗ - результат ХЗ)

@notsystemanalysis

Процесс собеседования. Вопросы после технического интервью

Поздравляю, вы прошли техническое интервью. Складно отвечали на вопросы бизнес-анализа, применяли знания по интеграциям в секции системного анализа, и, наконец, интервьюер говорит: «У меня все, теперь готов ответить на ваши вопросы». Около половины кандидатов в этот момент виснет и не знает, что можно спросить. Вот примерный перечень классных вопросов, показывающих вас как заинтересованного аналитика.

1) «Чем мне предстоит заниматься ежедневно? Что входит в мои обязанности? Расскажи примерный день системного аналитика». Этой пачкой вопросов вы показываете заинтересованность, плюс сразу же более-менее понимаете фронт работ. Да, есть описание вакансии и рассказ рекрутера, но они, как правило, очень абстрактные. Здесь же, человек, который реально занят в компании, сможет рассказать о боевых задачах. Ответ в духе: «Ну, у нас вообще-то не было никогда системного аналитика, и мы его берем, потому что это круто и модно» - плохой. Если только позиция не предполагает выстраивание аналитики с нуля, но там и компенсация соответствующая.

2) «Каким образом выстроены рабочие процессы? По какой методологии работаете?» Нужны для представления о том, как будет проходить работа. Можно ли решать задачи в конвейерном режиме или же придется постоянно сидеть на звонках, обсуждая каждый чих. Четкий и описанный флоу, а также его понимание, сильно упрощает и ускоряет работу. Если вам ответят: «Каждая задача уникальна и требует тщательного обсуждения со всей командой», знайте, в таком месте лучше не работать.

3) «Есть ли план развития сотрудников? И план развития компании в целом?» Вопрос нужен, чтобы с порога понимать, будет ли возможность прокачивать экспертизу и развиваться. Работодатель может не иметь внутреннего портала с курсами, но компенсировать внешнее обучение. Спрашивая подобное, с большой долей вероятности вам дополнительно расскажут о процессе пересмотра зп. Плохой же ответ звучит как: «У нас настолько интересные задачи, что сотрудники развиваются, просто решая их». Читай его как: «Через 3 месяца тебе станет скучно, но мы ничего с этим не сделаем».

4) Вопросы, которые волнуют вас по прошлому опыту. Например, переработки, KPI и прочее. Узнавайте обо всем, что доставляло неудобства ранее, дабы не нарваться на те же грабли. Например, на прошлом месте работы премиальная часть моей зп (аналитика) зависела от SLA тикетов поддержки. Естественно я первую очередь решал запросы пользователей, а не занимался тем, что мне действительно нравится.

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

В комментариях рассказывайте, какие интересные вопросы задаете вы?

#база

Ребята, привет)

Улетаю сегодня в отпуск, поэтому посты могут выходить нерегулярно. Мемов, само собой, накидал)
Вернусь в начале октября, не теряйте.

Обнял ❤️

Процесс собеседования. Что еще важно знать, чтобы быть эффективнее?

Итак, вы максимально подготовились к техническому интервью. Поболтали с HR, изучили бизнес и системный анализ, придумали пачку интересных вопросов и готовы побеждать. Как вдруг вас посещает мысль: «А может есть что-то еще, что я не учел?» Некие тайные знания, неочевидная информация, обладая которой можно стать лучшим кандидатом. Еще как есть! Делюсь с вами несколькими советами-напоминаниями, которые относятся к процессу интервью в целом.

1) Собеседования и реальная работа практически не имеют ничего общего. Запомните это. Большинство интервью проверяют теоретические знания, а практика отходит на второй план. Работа, в большинстве своей, предполагает решение конкретных, узких задач. Вы можете на автомате клепать синхронные интеграции по имеющейся документации, укладывая их в стандартные процессы. Но это не поможет, если на собеседовании вас спросят об аутентификации, асинхроне, нереляционных БД и тому подобное. Можно быть мощным практиком, но без базы и понимания, почему мы делаем так, а не иначе, собес не пройти. Из этого вытекает второй совет…

2) К собеседованиям нужно всегда готовиться. Теория спокойно улетучивается, когда не пользуешься ей постоянно. Время, потраченное на подготовку, конвертируется в лучший оффер. Будет очень досадно, если вы мастер юз кейсов, но забыли повторить виды требований по BABOK. Глобально это не поставит на вас крест, но точно даст работодателю повод предложить меньше денег. И даже со структурированной информацией в голове, опыт важно правильно подать. Поэтому стоит…

3) Научиться продавать себя как высококвалифицированного специалиста. На собеседовании обе стороны немного лукавят: компания может умолчать об устаревшем стеке или объеме техдолга, но и вы не должны говорить все как есть. Например, SQL вы используете раз в месяц, чтобы проверить наличие данных в базе. На вопрос работодателя: «Владеете ли вы SQL?» справедливо ответить: «Да, владею, использую в работе, строю отчеты». И тут два варианта событий: вам либо предложат решить задачу, которую вы осилите (ведь вы же готовились и повторили синткасис), либо ответят: «Ну, окэй» и пойдут дальше. Всегда подавайте себя чуточку лучше, чем вы есть на самом деле, если возникнут сомнения – вас тут же проверят. Не нужно закапывать самого себя. И наконец последний совет…

4) Всегда торгуйтесь за оффер. Получив долгожданное предложение о работе очень просто сказать: «Да, я на все согласен». Но подождите, есть вероятность, что работодатель сможет дать еще больше. Не бойтесь торговаться. Наиболее простой способ написать что-то в духе: «Спасибо за предложение, вы мне очень понравились, но у меня есть другое предложение, и я не могу выбрать, где мне будет лучше. Есть ли возможность улучшить условия?» Оффер не отзовут и на вас не посмотрят криво. В худшем случае скажут: «Извините, мы не можем изменить условия». Тогда просто примите как есть, и останетесь при своем. Лично мне удавалось за одно сообщение поднять предложение на 25к, как будто вам тоже стоит попробовать.

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

А какие советы по интервью можете дать вы?

#база

Проснулись, улыбнулись)

@notsystemanalysis

https://news.1rj.ru/str/notsystemanalysis?boost

Ну а вдруг)

Как правильно задавать вопросы?

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

Первым советом в такой ситуации будет - «не бояться спрашивать и разговаривать». Большинство рабочих вопросов решаются на месте, и чем думать: «А как бы мне узнать хорошо ли я сделал задачу или нет?», лучше просто спросить. В ИТ, а тем более аналитике, не очень любят молчаливых. Не нужно молчать о проблемах или о возможности сорвать сроки. Если рассказать о своих трудностях, то вас точно поймут и предложат помощь.

Другой страх: «Вдруг я спрошу вопрос, а он окажется глупый, все подумают что я не знаю эту технологию». Распространенная боль, причем как для джунов, так и для людей с опытом. Для себя я делю все вопросы на две группы: общие и относящиеся к конкретной компании. Общие - легко гуглятся и могут быть решены без привлечения помощи извне. Например, «Как работает постман?» или «Что такое user story?» Я бы не спрашивал такое, а искал ответ самостоятельно.

Специфические вопросы, не стыдно задавать коллегам. «Как устроен бизнес процесс?» «Как работает это сервис?» «Какова моя зона ответственности?» «Есть ли у вас шаблоны документов?» Все то, что нельзя свободно найти в интернете. Коллеги с радостью помогут вам, поделятся информацией или отправят ссылку на конфлюенс.

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

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

Не бойтесь общаться, никто не уволит вас за кривой вопрос. Лучше лишний раз спросить/предупредить, чем потратить кучу времени на поиски, промолчать и не успеть в срок.

#база

Как создать хорошую документацию к API?

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

Как обычно, все субъективно, но на мой взгляд в API документе содержатся следующие разделы:

1) История изменений
2) Оглавление
3) Системная информация
4) Алгоритм работы
5) Примеры

История изменений. Здесь все просто, ключевая цель раздела - найти того, кто создавал доку или вносил в нее какие-либо изменения. Обычно делаю в виде таблице с колонками: дата изменения, описание изменений, связанная задача, автор изменений. Если в компании используется Jira/Confluense, связка задачи и доки будет отражаться сразу в обоих местах.

Оглавление. Для быстрой навигации по разделам документа. В конфе можно настроить автоматически.

Системная информация. Или «нефункциональные требования». Например, требования к аутентификации, порядок ретраев и таймаутов, тип входного и выходного объекта (если описываете адаптер, на вход может прийти XML, а на выходе JSON), название очереди. В общем указывается вся важная информация, которая не относится к алгоритму работы напрямую.

Алгоритм работы. Самое важное. По шагам расписываем, как работает тот или иной метод. Указываем откуда приходит сообщение (из очереди или из внешней системы или по триггеру и тд), прикладываем пример входящего сообщения. Далее описываем что мы делаем с этим сообщением: раскладываем в базу, преобразуем, формируем новый запрос и тд. Допустим, мы формируем новый запрос, тогда прикладываем его пример в формате curl, указываем метод HTTP и url, а также подробно описываем параметры запроса.

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

Затем описываем ответ, алгоритм тот же: прикладываем пример ответа и подробное описание параметров ответа.

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

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

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

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

Если наберем 25 реакций, скину пример своей документации из практики)

#база

Всем привет из Москвы!

@notsystemanalysis

Какой курс выбрать?

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

На мой взгляд любой курс нужно проверять по нескольким критериям: наполняемость, наличие ментора, продолжительность и цена.

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

Наличие ментора. Ментор - тот человек, который направит и поможет разобраться. Тот, к кому можно обратиться в любой момент. Современные курсы предоставляют такие услуги, но чаще всего за одним человеком может быть закреплено более десяти кандидатов. Сами понимаете, в таком случае один ментор не сможет уделить проблеме достаточное время. Лучше уточнять этот момент заранее.

Продолжительность. Я убежден, что оптимальная продолжительность курса по системному анализу не более 3х месяцев. Далее наступает простое выкачивание денег. По опыту, занимаясь раз в неделю с учениками, мы выходим на собеседования как раз через 2-3 месяца.

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

В качестве бонуса примеры хороших курсов:
https://getanalyst.ru/education
https://nextway.pro/
https://practicum.yandex.ru/systems-analyst/?from=catalog

И пример неудачного, здесь покрыты темы только бизнес анализа:
https://1.changellenge.com/business-analyst?utm_source=ip&utm_medium=noukash&utm_campaign=youtube240123#join

AI в работе системного аналитика

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

На текущем проекте документация ведется по принципу Docs as a Code. В качестве текстового описания используется AsciiDoc, для генерации диаграмм PlantUML, а для апишек OpenAPI. На выходе у аналитика получается три артефакта: пошаговое описание процесса, диаграмма классов и Swagger. Теперь представьте, что в API содержится 50 параметров и все их нужно указать в Swagger. Реально, но очень скучно и долго. Для автоматизации этого удовольствия на помощь приходит ChatGPT.

Перед написанием спецификации я всегда тестирую запросы. Примеры прикладывает либо партнер, либо приходится формировать самостоятельно. Из примера запроса можно собрать целый OpenAPI всего одной командой. «Here is Json, convert it into OpenAPI schema». И документ в формате OpenAPI готов. Также ChatGPT можно попросить добавить описание и примеры параметров, но тут нужно быть осторожнее, чтобы не допустить несуразицу. Вложенность объектов, кстати, тоже учитывается.

То же самое можно сделать из диаграммы классов PlantUML. Подаете на вход диаграмму классов, на выходе получаете API схему. Обратный процесс также возможен, на основе Swagger можно сгенерить PlantUML.

Наконец, очень советую бесплатное расширение для IDEA Codeium, аналог GitHub Copilot. Незаменимая штука в работе аналитика, при создании того же OpenAPI. Плагин удерживает контекст и оперативно предлагает дополнения для документации, ускоряя работу.

А вы пользуетесь AI в работе? Расскажите об этом в комментариях.