Хз как так получается
А ведь четко сформулированное ХЗ зачастую дает отличный результат!
А ведь четко сформулированное ХЗ зачастую дает отличный результат!
Я как сраный старпер тупо в ит (22 года стаж, но нихера не знаю). Забейте на языки. Думайте о предоставлении данных. Язык программирования - херня, инструмент типа отвёртки. А от структуры данных зависит и платформа, и архитектура, и язык.Я что ща модно? Питон? Душите его. почитайте, бля, программной с дипломом.
Всем привет!
Вернулся из отпуска - готов продолжать свою деятельность дальше. Сегодня подытожу, немного, мою длинную серию постов и сведу ее в список тех тем (и тех вопросов), которые необходимо знать начинающему системному аналитику для того, чтобы успешно пройти технический собес.
Список тем и вопросов к ним:
Методологии разработки ПО и жизненный цикл разработки ПО.
Какие методологии разработки вы знаете? (Тут нужно рассказать про эджайл, водопад хотя бы. Можно и про остальные упомянуть, но обычно не требуется).
В чем отличия между ними? Какие у них есть особенности?
Расскажите про жизненный цикл разработки ПО. Какие этапы проходит задача\продукт до выхода в прод? (Лучше рассказывать своими словами, просто как понимаете)
Расскажите про состав команды разработки - какие есть позиции и какие функции выполняет каждая из них? Какую роль выполняет системный аналитик? (Кстати, очень "забавно", но когда собесил людей на стажировку СА и даже некоторых джунов - много кто не смог толком ответить на последний вопрос. Т.е. люди банально даже не погуглили хоть чуть-чуть и не проходили по первым ссылкам гугла, чтобы немного подготовиться к собесу и понять куда они вообще идут. Про какую уж тут позицию СА можно говорить - не надо так)
Требования.
Самый частый задаваемый вопрос для джунов (потому что, ну а что еще спрашивать?) - расскажите про виды требований, которые знаете. Приведите примеры таких требований.
Какие качества требований вы знаете? Приведите пример требования, которое удовлетворяет всем качествам.
Какие методологии сбора требований вы знаете? Какими из них пользовались?
Тут может быть еще любая кастомная задача на сбор требований. Т.е. интервьюер обрисовывает вам какую-то задачу и вам нужно у него собрать требования и их устно зафиксировать. Очень полезная, кстати, вещь для собеседований - тоже помогает хорошо понять то, насколько человек вообще ориентируется в теме, насколько он может применять теорию на практике и насколько хорошо он может формулировать вопросы (это важно даже для СА). Один из примеров, про шкаф, которые лично мне задавали на собеседовании, разбирал недавно в ТГ - ссылка на пост.
Вопрос со звездочкой. Как вы думаете, есть ли прямое влияние методологий разработки на требования? Какое? (Спойлер - есть)
Какими инструментами для фиксирования требований вы пользовались? Какие в принципе существуют? (Тут есть достаточное разнообразие инструментов - от ворда и согласований ТЗ по почте до связки asciidoc + git. Дефолт - это jira\confluence)
Как определить, что задача успешно вышла в прод? (Тут просто на рассуждение. Можно сказать, что признаки успешности - отсутствие инцидентов на проде, положительные фидбеки от пользователей, стабильность работы системы и вот это всё)
Как управлять требованиями? Что делать, если релиз уже распланирован и тут бизнес-заказчик прибегает с горящими глазами и требует внести срочную доработку в текущий релиз. Как бы вы отработали эту ситуацию?
Диаграммы.
Какие нотации вы знаете? (UML\BPMN\IDEF0 и вот это всё)
Какие виды UML-диаграмм вы знаете? Для чего они предназначены? (Тут тонкий момент, что если вас начнут спрашивать, а какие вы знаете типы стрелочек и когда какую применять - имхо это уже эребор и не нужно это знать наизусть. Я, например, не знаю, хотя регулярно это использую и обучаю - всегда можно за 30 секунду загуглить это. Но общую теорию по типам диаграмм надо знать)
Что вы знаете о BPMN, для чего эта нотация нужна? Приходилось ли использовать на практике?
В чем отличия между этими нотациями? Какие у них преимущества?
Могут показать, как вариант, какую-нибудь схему и спросить что на ней нарисовано. Такой подход мне нравится.
UC\US.
Что такое пользовательские истории? Приведите шаблон, по которому они составляются и пару произвольных примеров.
Что такое варианты использования, для чего нужны? Как их оформлять и какие шаблоны вы знаете?
Любые задачи, которые только можно придумать на сбор требования\моделирование каких-либо ситуаций\игра в аналитика-заказчика - насколько хватит фантазии и желания у интервьюера.
Почти на все эти вопросы вы можете найти ответы в этой серии постов.
Эта часть собеседования не требует от вас идеального зазубривания материала и того, чтобы вся теория отскакивала от зубов. Она по большей части вольная и вам главное показать то, что вы понимаете о чем вас спрашивают и можете сформулировать ответ своими словами.
А что еще важнее - если вы чего-то точно не знаете\не помните, то вы можете хотя бы порассуждать об этом (мне кажется, что нет более важного навыка для аналитика). Поэтому старайтесь размышлять над теми вопросами и кейсами которые вам задают, обычно в процессе этого будут задаваться наводящие вопросы и вполне неплохо можно на этом вырулить - это абсолютно точно лучше, чем молчать.
Тем более, что почти на все эти вопросы нет однозначного правильного ответа. По своему опыту могу сказать, что я скорее проголосую за человека, который не всё знает, но очень бодро отвечает, по делу рассуждает (важное уточнение, что именно по делу, а не просто засоряет эфир болтовней), чем за того, кто четко отвечает по любой теории, но теряется, если задать какой-то не стандартный вопрос.
Ну и стоит понимать, что каждый интервьюер за годы практики ведения собеседований выстраивает свою картину этого собеседования, свой список вопросов и задач. И как правило именно на этом, первом этапе собеседования, он составляет оценку вашим софт-скиллам в первую очередь.
В следующей части перейдем к списку вопросов уже по хард-скиллам.
P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.
P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.
Всем привет!
Я, наконец, смог оторваться от BG 3, поэтому продолжаем разбираться в системном анализе.
В этом посте продолжим разбирать примеры того, как писать ТЗ на различные API (или если быть точнее, то скорее спецификацию к ним, которая выступает и в роли ТЗ в том числе).
Сегодня рассмотрим написание спеки на метод POST. По сути не так уж сильно отличается от описания GET метода или любых других, но свои нюансы присутствуют.
Для более полного понимания, представим что нам нужно описать админку, которая управляет жизненным циклом бизнес-сущности "Пользователь". Т.е. это значит, что у нас есть на фронте несколько экранных форм, которые суммарно позволяют администраторам системы заниматься их темными делишками:
Получать список пользователей целиком или по заданным параметрам фильтрации;
Открывать карточку пользователя (детальную информацию по нему);
Редактировать ее по необходимости;
Удалять пользователя (или физически объект целиком, но это скорее редкость, или просто помечать его удаленным или неактивным);
Создавать нового пользователя.
Чтобы фронт мог это всё выполнять, нам нужны соответствующие методы, которые он будет вызывать для выполнения этих функций:
GET /users
GET /users/{userId}
PUT /users/{userId}
DELETE /users/{userId}
POST /users
Т.е. по сути реализуем концепцию CRUD по отношению к ресурсу User.
То, как описать метод GET /users/{userId} мы рассмотрели в прошлый раз, сегодня рассмотрим метод POST /users.
Но для начала расскажу как описывать модель данных системы (один из вариантов того, как это можно сделать), т.к. это тоже важная часть ТЗ (спеки), которую должен делать СА. Разберем просто на примере с комментариями:
Ссылка на конфлю кому нужно, пока он еще работает.
Для того, чтобы описать какой-либо объект системы, нужно всего лишь описать всего его атрибуты (желательно дать еще бизнесовое описание этого объекта, просто хотя бы для себя, но это уже другая история).
Поэтому аналитику нужно придумать его наименование на английском, указать его тип, имеющиеся ограничения и (обязательно) описание атрибута на русском языке, при необходимости с комментариями. Последнее - очень важно, чтобы потом самому не забыть зачем этот атрибут нужен и какие у него есть особенности.
В рамках данного шаблона есть немного кастомных вещей, свойственных для моих проектов. Например, вот эта вот "Ссылка на userGroup", это означает FK на таблицу на таблицу USER_GROUP и связку с соответствующим объектом. А атрибут role с ссылкой в типе на ref.Roles это enum (справочник). Т.е. атрибут может принимать только одно из значений из списка:
Конкретно эти штуки на разных проектах описываются сильно по-разному, но тут уж у кого как принято. Общий смысл всегда идентичен. В чем плюс этого варианта - ты одновременно описываешь и DTO (структуру данных метода) и структуру данных БД.
С моделью данных разобрались, это нам поможет при описании метода в том числе.
Описание самого метода (ссылка на конфлю):
Обычно методы по созданию объектов сложнее, но тут у нас очень простой процесс, почти нет проверок, поэтому так)
Главное, что нужно проверить - что у пользователя, который вызвал этот метод есть права на совершение этой операции и что нельзя создать пользователя, идентичного существующему.
И не менее главное - указать правила того, как должны заполняться атрибуты объекта при его создании (маппинг). Чтобы разработчик понял, откуда ему брать эти значения. В данном случае часть полей заполняется константами а остальная часть полей берется из request, т.е. тех данных, которые прислали на вход данному методу.
По-хорошему можно было бы расширить этот метод автоматической генерацией пароля, автоматической же отправкой его на почту пользователю (а значит и интеграцией с соответствующим сервисом) - но в рамках всего лишь примера - это излишне.
Получился еще более длинный длиннопост, чем обычно. Но вам, вроде бы, не привыкать. Вопросы, комментарии по сабжу - как обычно welcome.
P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.
P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.
Всем привет.
Предыдущая часть привлекла много внимания и активности (более 200 комментариев, ого) - спасибо всем тем, кто комментировал, оставлял дельные советы и дельное же мнение по поводу сабжа и около него. Особенно интересно было почитать некоторые ветки комментариев, которые жили сами по себе и были сугубо техническими - достаточно развивающе было для меня, почитать про то, как это всё видят разработчики со своей стороны.
В следующем посте разберу какой-нибудь чуть более сложный пример ТЗ для POST метода, заодно покажу один из шаблонов того, как можно описывать модель данных. И когда-нибудь созрею и расскажу про то, как мы использовали связку asciidoc + git для ведения документации.
А сегодня немного отвлечемся от прикладных навыков, отдохнем, и поговорим про то, как вообще должна жить задача на разработку и какой путь она должна пройти для того, чтобы внедрение получилось как можно более качественным.
Всё должно начинаться с ключевого лица в данном процессе - заказчика. Он должен сформулировать постановку задачи и ее цель (хотя бы попытаться). На одном из проектов бизнес-заказчики писали BRD (Business Requirements Document), в котором излагались ключевые требования к задаче, ее экономическое обоснование и различные пожелания к итоговому результату.
На самом деле очень полезная история для всех участников процесса разработки, по крайней мере мне - как системному аналитику было это интересно, и я лучше понимал то, зачем вообще нужна эта фича и как я помогу компании, реализуя ее (это, в том числе, помогало выбирать более правильные пути решения задачи).
Дальше должен идти этап бизнес-анализа задачи, в результате которого должны появится качественные БТ (бизнес-требования), в которых детально описано то, как процесс нужно изменить, чтобы выполнить цели задачи. Как именно это будет описано - уже не важно, хоть через AS IS\TO BE, хоть простым русским языком.
Если же задача сугубо техническая или небольшая, то, в целом, можно этот этап опустить - нужно всё-таки рационально тратить ресурсы.
На этом этапе, очень желательно, чтобы архитекторы дали своё заключение по задаче и указали, как минимум то, какие системы требуется доработать (потому что со стороны системного анализа это не всегда явно видно). А если задача комплексная и кроссфункциональная - то написать полноценное AR (архитектурное решение), в рамках которого будут расписаны верхнеуровневые требования к системам, схемы интеграции, на основе которых уже системные аналитики конкретных команд будут писать свои ТЗ.
Опять же, на одном из проектов был процесс, когда архитекторы системы оценивали КАЖДУЮ задачу и даже если она была небольшой, то не писали больших документов, а прям в JIRA писали краткое архитектурное заключение о том, какие процессы требуется доработать (и это было прям хорошо, заметно снизило количество кросскомандных недоработок).
На этом этапе у аналитика уже есть все документы и информация для того, чтобы понять нюансы задачи, сделать правильные выводы, выбрать оптимальное решение и написать качественное ТЗ.
Потому что если такой предварительной подготовки нет, то СА приходится самостоятельно эти приседания выполнять: уточнять какие-то нюансы у заказчика, ходить к архитектору (если он вообще есть)\смежным командам и спрашивать нет ли влияния твоей доработки на их системы (хотя на опыте, ты уже и сам зачастую это знаешь).
И вместо того, чтобы сделать задачу за неделю, ты тратишь две (а потом еще два месяца на круговые согласования. Не буду говорить где - кто знает, тот знает). А если потом еще что-то вскрывается на этапе тестирование - становится еще веселее)
Разработчику также много проще разрабатывать задачу, когда есть не только ТЗ, но и различные документы более верхнеуровневого характера (сужу по фидбекам коллег).
Как минимум потому, что многим разработчикам (по крайней мере из тех, с кем я работал) тоже интересно если не погружаться глубоко в бизнес-процессы, то хотя бы просто понимать зачем он делает эту доработку и какую пользу она принесет. Иногда, это также помогает в выборе более правильного решения в том числе.
А вот тут интересно. Потому что хороший тестировщик не будет ориентироваться только на ТЗ - он еще просмотрит BRD, БТ - сверит то что там написано с тем, что написано в ТЗ, потенциально выявит недостаток требований или их некорректность (было такое на практике) и только потом уже приступит непосредственно к тестированию.
Но это прям должен быть очень хороший тестировщик, с большим опытом в целом и особенно на проекте в частности, и, что самое главное, с желанием это всё делать а не просто жмакать на кнопочки в интерфейсе и postman'е.
Соответственно - чем глубже проработка задачи по всем уровням ее проектирования, тем лучше для тестировщика и конечного результата в целом.
Конечно, весь этот путь возможен (и нужен) только для больших команд, где есть отдельно выделенные позиции и только для достаточно комплексных и сложных задач. На обычную мелочь хватает и небольшого бизнес-анализа с полноценным системным анализом.
Если же проект маленький или просто нет позиций PO\БА\АР и вот этого всего многообразия ролей, то вспоминаем что я говорил в самом начале серии постов про системного аналитика - что это человек, который может совместить в себе все эти роли и обязанности, проделать сбор требований, бизнес-анализ, архитектуру и системный анализ самостоятельно и потом выдать удобоваримое, комплексное ТЗ разработчику. И сначала это даже интересно, сильно прогрессируешь в компетенциях, но только сначала)
Можете поделиться в комментариях своим опытом того, какой путь обычно проходит задача до выхода в прод на вашем проекте (херак-херак и в продакшен это тоже путь) и как вам хотелось бы, чтобы это происходило - обсудим.
P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.
P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.
Взять с собой побольше вкусняшек, запасное колесо и знак аварийной остановки. А что сделать еще — посмотрите в нашем чек-листе. Бонусом — маршруты для отдыха, которые можно проехать даже в плохую погоду.