Speaker A
Общение с нашими коллегами мы прослушали. А соответственно, у нас тоже есть вакансии на наш проект по развитию систем.
Собеседование на системного аналитика: разбор опыта кандидата, Agile-процессов, артефактов (user story, BPMN, ER, API-контракты) и подходов к работе с заказчиком.
Key Takeaways
- Кандидат имеет около 4 лет опыта системного анализа, работал в проектной деятельности и аутстаффе
- Предпочитает развиваться в одной компании на одной системе с экспертной глубиной
- Знает базовые артефакты и процессы, но технические ответы о REST/SOAP и HTTP-методах были неуверенными
- Опыт Agile есть, но без полноценного скрам-мастера и регулярных ритуалов
What the video covers
- Интервьюер представляет проект по развитию большой системы с интеграциями с госструктурами и подрядчиками, открыты вакансии системных аналитиков
- Кандидат рассказывает о выборе системного анализа, учёбе (БД, Project Management) и первом опыте работы в стартапе
- Обсуждаются причины смены работы: компания-аутстаффер завершает проект, новых нет
- Кандидат хотел бы развиваться в системном анализе с перспективой стать архитектором через пять лет
- Разбирается опыт работы по двухнедельным Agile-спринтам, без скрам-мастера (роль PM), с ретроспективами и демо не всегда
- Описывается процесс: сбор требований, user story, use case, бизнес-правила, критерии приёмки, затем BPMN, ER-диаграммы, API-контракты
- Обсуждаются самостоятельность аналитика, приоритизация на планировании спринта, передача в разработку и тестовые сценарии
- Интервьюер задаёт технические вопросы по REST и SOAP, отличиям GET и POST, ограничениям GET, rate limiting и безопасности
- Кандидат отмечает, что документация велась в свободной структурированной форме без строгой привязки к ГОСТ
Full Transcript — Download SRT & Markdown
Speaker A
Система большая, соответственно, очень много интеграций из э-э, госструктурами, из внешними подрядчиками. Поэтому сейчас расширяем штат аналитиков.
Speaker A
Система большая, соответственно, очень много интеграций с государственными структурами, с внешними подрядчиками. Поэтому сейчас расширяем штат аналитиков.
Speaker A
Э-э, первый собственно, общий вопрос, а-а, почему собственно, системный анализ? Угу. Именно вот почему это я выбрал там с самого начала?
Speaker A
У меня, собственно, есть пара вопросов по резюме, с вашего позволения. Угу. По нему и пойдём.
Speaker A
Так, ну на самом деле, почему наверное, выбрал, э-э, такой вопрос, э-э, то есть я вот учился и у нас э-э, было ну, достаточно много предметов связанных с тем анализом, там база данных, э-э, ну, что-то связанное с ну, условно там с Project Management'ом,
Speaker A
Первый, собственно, общий вопрос: почему, собственно, системный анализ? Угу. Именно почему вы это выбрали там с самого начала?
Speaker A
Вот, э-э, ну, и в какой-то момент э-э, ну, у нас ещё да, немножко подскажу, были э-э, три трека, типа один трек был аналитический, один там был для разработчиков, один там был для что-то PM'ов, что-то такое, ну, примерно там я
Speaker A
Да, то есть я вижу, что вы уже там 4 года этим занимаетесь. Не разочаровались ли и как в принципе настроены дальше развиваться в этом направлении?
Speaker A
был стартап, меня позвали. Вот э-э чего? Ну, и вот это мне понравилось. Что касается по м-м, развитию, ну, да, то есть хотел бы развиваться больше м-м, не знаю, наверное, в, хмм, хмм, больше системный анализ, если если сравнивать с условным бизнес-анализом.
Speaker A
Ну, на самом деле, почему, наверное, выбрал... такой вопрос. То есть я учился, и у нас было достаточно много предметов, связанных с этим анализом: база данных, что-то связанное с Project Management'ом,
Speaker A
Вот. Вот так. Угу. Всё, спасибо. Э-э, по поводу поиска работы, э-э, у вас, я так понимаю, проектная деятельность сейчас?
Speaker A
что-то про Agile, что-то про метрики. Вот, примерно последовательно было связано.
Speaker A
как бы не в плане, что, хмм, просто типа для меня, не знаю, их нет, а их нет вообще, ну, у всей компании, то есть, я не знаю, какая там ситуация, может быть, там э-э, у самой, короче, компании какие-то
Speaker A
И в какой-то момент, да, немножко подскажу, у нас были три трека: один аналитический, один для разработчиков, один для PM'ов, что-то такое. Примерно так я говорю. Я выбрал аналитический, мне там было ещё больше предметов, связанных с аналитикой. В какой-то момент я понял, что нужно искать работу, нашёл первую компанию, тогда это был стартап, меня позвали. И вот, мне это понравилось. Что касается развития, то да, я хотел бы развиваться больше в системном анализе, если сравнивать с условным бизнес-анализом.
Speaker A
хотел бы остаться, но вот раз такая ситуация, что, ну, работы условно нет, то вот приходится вот выходить.
Speaker A
То есть, наверное, лет через пять, в идеальном случае, хотел бы стать, например, архитектором.
Speaker A
развиваться, в одной компании, на какой-то одной системе и её изучать уже там на экспертном уровне?
Speaker A
Вот. Так. Угу. Всё, спасибо. По поводу поиска работы, я так понимаю, проектная деятельность сейчас?
Speaker A
Хотелось бы уже там куда-то там приземлиться и больше как бы в одном месте что-то узнавать, чтобы там больше разбираться в одном месте. Что стоке.
Speaker A
Угу. Это основная причина или какая-то другая? То есть, ещё раз повторю: я работаю в компании, которая предоставляет аутстафф в другие компании. Текущий проект завершается, новых не предвидится. Но это не в плане, что для меня их нет, а их нет вообще у всей компании. Я не знаю, какая там ситуация, может быть, у самой компании какие-то
Speaker A
То есть такой вариант, э-э, больше нравится. Угу, да. Отлично. Так, а-а, по поводу, собственно, предыдущей вашей встречи, а-а, у меня остался вопрос по артефактам системного аналитика.
Speaker A
проблемы, я не узнавал. Мне говорят, что, условно, в ближайшее время не предвидится, нужно будет сидеть и ждать, а ждать неоплачиваемо. В принципе, я хотел бы остаться, но раз такая ситуация, что работы условно нет, приходится уходить.
Speaker A
Так, ну хорошо, э-э, получается, у нас по- появляется какая-то фича. М-м, точнее, нет, давайте на- так начнём. То есть сначала у нас идёт, э-э, там сбор и фиксация требований, условно. То есть это, э-э, условно, интервью с заказчиком, м-м, там уточнение вот, э-э,
Speaker A
Представьте идеальный мир: работа есть, проектов много, горизонт планирования расписан на пять лет. Что предпочтёте: проектную деятельность в разных компаниях или всё же развиваться в одном месте, в одной компании, на одной системе, изучать её уже на экспертном уровне?
Speaker A
уже идёт, э-э, э-э, проработка нашего решения. Вот, э-э, что это это это что касается там, э-э, м-м, BPMN диаграммы, м-м, ER-диаграммы вот э-э API-контракты.
Speaker A
Думаю, второе, потому что сейчас я уже поработал в проектной деятельности в разных командах, с разными проектами.
Speaker A
А вы работали по спринтам, по Agile или как? Да, да, у нас был Agile, двухнедельный.
Speaker A
Хотелось бы уже куда-то приземлиться и больше в одном месте что-то узнавать, разбираться глубже.
Speaker A
Нет, скрам, именно название скрам-мастера не было, был PM. Вот. Ну, то есть, ретро, демо?
Speaker A
Вот у нас как раз второй вариант. У нас есть большая система, которая регулярно развивается. Мы получаем новые заказы от государственных корпораций, и всё подчинено циклам технических заданий, которые перед нами ставят.
Speaker A
И ретро не было. Вот так. Ну, по- полноценный, как бы, ну, можно назвать полноценный, наверное, никто прям, э-э, до конца прям полностью все ритуалы, ну, не соблюдает.
Speaker A
То есть такой вариант больше нравится. Угу, да. Отлично. По поводу предыдущей вашей встречи у меня остался вопрос по артефактам системного аналитика.
Speaker A
Вот дальше соответственно вы Угу. вольны решать и управлять сроками реализации э-э увеличением разработчиков и так далее.
Speaker A
Был такой вопрос, но я чёткого ответа не услышал. Угу. Можно по порядку, с этапа сбора требований и до внедрения фичи в продакшн? Какие артефакты возникали и какие вы готовили?
Speaker A
Получается, да, я хочу понять, насколько вы самостоятельны в своей, э-э, деятельности как системный аналитик.
Speaker A
Хорошо. Получается, появляется какая-то фича. Точнее, нет, давайте начнём так. Сначала идёт сбор и фиксация требований: интервью с заказчиком, уточнение бизнес-цели, уточнение ограничений. После этого возникают уже всем известные артефакты: user story, use case'ы, бизнес-требования, бизнес-правила, критерии приёмки.
Speaker A
вашу вовлечённость в это. Э-э, ну, на самом деле, м-м, если так прямо отвечать, то достаточно, ну, в своей зоне, наверное, самостоятельный, то есть после, давайте так начнём, то есть после там согласования вот требований там с заказчиком, м-м, то
Speaker A
Дальше идёт проработка нашего решения: BPMN-диаграммы, ER-диаграммы, API-контракты.
Speaker A
там, э-э, оно было, ну, реализовано. Вот, э-э, сроки, приоритеты. Ну, смотрите, тут тут, наверное, так скажу, то есть у нас есть планирование спринта, м-м, и там мы с, э-э, продактом, и пэмом, сидим и решаем, как будем приоритизировать. То есть не
Speaker A
Потом передача в разработку, для команды разработчиков. Наверное, пока так. И ещё потом тестовые сценарии для тестировщиков.
Speaker A
Вот. А представьте, вот вам, допустим, заказчик говорит, вот вот, соответственно, фича, да, вы её с ним поговорили, срок 2 месяца.
Speaker A
А вы работали по спринтам, по Agile или как?
Speaker A
Вот вам такой подход ближе или всё же вам задачи спускают более дискретно, и вы их, просто одну за одной делаете?
Speaker A
Да, у нас был Agile, двухнедельный.
Speaker A
просто э-э так её придумываю, чтобы потом как бы она э-э не до конца дорабатывалась. То есть да, скорее всего, ну, точно мне больше нравится э-э тот формат работы, где я э-э как бы с собрал требования, поставил задачу и
Speaker A
То есть у вас был полноценный Agile, был скрам-мастер, который соблюдал все активности?
Speaker A
Приходилось ли эскалировать какие-то проблемы наверх? Угу. Э-э так. Ну, условно так, хорошо. То есть когда у нас случается ситуация, м-м ну, смотрите, то есть было м-м наверное, что касается м-м сроков, наверное, так скажу. То есть э-э когда у нас э-э
Speaker A
Нет, именно названия скрам-мастера не было, был PM. Ретро, демо?
Speaker A
ну, я пытался э-э ну, решить всё на своём уровне, то есть в нашей команде, то есть там собрать э-э так скажем, м-м ну, условно там условно факты там или причины, почему м-м мы не можем точнее, можем ли мы это сделать как бы самостоятельно.
Speaker A
Смотрите, у нас было планирование спринтов, дейлики постоянно, демо тоже было, но не каждую неделю. Ретро не было.
Speaker A
высшем уровне, чтобы у нас э-э эти риски как бы все были предусмотрены, проработаны. А как вы работаете вот с изменениями?
Speaker A
Полноценным, наверное, никто до конца не соблюдает все ритуалы.
Speaker A
Угу. Э-э ну, смотрите, э-э во-первых, э, я бы, наверное, м, посмотрел, э, м, смотрите, то есть у нас вот функционал в два раза больше, м, нам нужно, м, э, нужно сначала, наверное, уточнить, э, что именно, м, мы мы хотим добавить, то
Speaker A
Такой вопрос: насколько вы самостоятельны в своей работе? По вашей оценке, допустим, интервью с заказчиком провели, заказчик в общих чертах согласовал направление, куда мы движемся. Дальше вы вольны решать и управлять сроками реализации, увеличением разработчиков и так далее.
Speaker A
было, в общем, до этого. То есть, после этого можно, наверное, дать, э, ну, наверное, два варианта нашему, кому, заказчику, который к которому там пришёл. То есть, мы либо двигаем срок, либо, наверное, да, то есть, точно так же, типа, либо уже объём. То есть,
Speaker A
Угу. То есть вы спрашиваете что-то на стыке работы системного аналитика и проджект-менеджера? Про это?
Speaker A
нас там не полтора, а 1,2 по, м, объёму, то, в принципе, наверное, можно и, наверное, вместить вот этот буфер по времени, ну, если мы заранее запланировали.
Speaker A
Да, я хочу понять, насколько вы самостоятельны в своей деятельности как системный аналитик.
Speaker A
Э, давайте представим ситуацию, когда заказчик, э, даёт вам 2 месяца, но вы понимаете, что те технологии, которые вы мы сейчас используем, допустим, да, в проекте, э, с их помощью срока 2 месяца за 2 месяца, э, эту задачу не выполнить.
Speaker A
Вам нужно просто спускать задачи, и вы их делаете, или вы можете сами планировать, приоритизировать задачи, дёргать нужных людей, подсвечивать риски и так далее? Я хочу понять вашу вовлечённость в это.
Speaker A
Угу. Так, ну, смотрите, давайте подумаем. Если Так, технологии новые, 2 месяца. Ну, смотри, я не понимаю, наверное, нужно больше на примере на каком-то отталкиваться. Ну, допустим, э-э можно подумать так, э-э ну, с двух двух сторон посмотреть. Если технология
Speaker A
Угу. Ну, если отвечать прямо, то в своей зоне, наверное, достаточно самостоятельно. То есть после согласования требований с заказчиком я сам эти требования прорабатываю, потом декомпозирую их на артефакты, ещё раз согласуем с заказчиком и с командой. Также, конечно, я контролирую, чтобы решение, которое касается ТЗ, было реализовано. Сроки, приоритеты. У нас есть планирование спринта, и там мы с продактом и PM'ом сидим и решаем, как будем приоритизировать. То есть я не то чтобы на первых бюджетах участвую, но участвую. Мы приоритизируем по мозгу.
Speaker A
Давайте Давайте пример. То есть мы используем REST, а заказчик говорит: "Хочу Хочу SOAP, XML".
Speaker A
А представьте: заказчик говорит, фича, вы с ним её обсудили, срок два месяца. Через два месяца ожидается готовность фичи в проде. Внутри этих двух месяцев вы выстраиваете отношения с разработчиками, с командой, включаете или не включаете в спринт. Вам такой подход ближе, или же задачи спускают более дискретно, и вы делаете их одну за другой?
Speaker A
А-а, допустим, никто. Угу. Так, э-э ну, хорошо. М-м, ну, в принципе, м-м, я думаю, м-м, не знаю, в такой ситуации, наверное, давайте посмотрим два варианта. М-м, так можно Ваша задача отбить это пожелание, но отбить его грамотно, с аргументами.
Speaker A
Угу. Ну, на самом деле, мне больше нравится первый подход, потому что мне больше нравится контролировать то, что я
Speaker A
Просто, возможно, вдруг у нас как бы никто с SOAP'ом не работал, но у нас, э-э, очень опытные все там здесь все с годами опыта, быстро обучаются, возможно. И тогда Допустим.
Speaker A
тогда мы сможем как бы быстро обучиться там и э-э сработать с этой технологией. Но скорее всего, э-э, такое вряд ли случится, э-э, такое вряд ли бывает в реальной жизни, и скорее всего я бы сказал, что ну, мы скорее всего не сможем уложиться в 2
Speaker A
месяца и очень сильно рискуем потерять по качеству а-а э-э если они предлагают SOAP, то скорее всего это работа с какими-то, ну, госсервисами там или с какими-то, не знаю, с деньгами. Вот, и в таком случае нам ни в коем случае нельзя по качеству
Speaker A
терять нельзя, то есть это может быть грозить риском там самой компании, условно, её деньгам там или безопасностью. Ну, и тоже это штрафы. То есть поэтому лучше тут как бы вот э-э ещё раз первый вариант он маловероятный, что если можем быстро обучиться, это как
Speaker A
бы один вариант. И второй вариант э-э что э-э сказать, что ну, скорее всего, мы не сможем 2 месяца, э-э потому что мы рискуем по м-м, скажем, по качеству нашего проекта. То есть, всё, что касается там денег или там
Speaker A
безопасности. Самый главный аргумент ещё э-э если у нас есть 56 интеграций REST и одна интеграция SOAP.
Speaker A
Угу. М-м ну, да, то есть, тут, наверное, с точки зрения поддержки под- поддержки и там э-э м-м ну да.
Speaker A
На- наверное, вот так вот. То есть, э-э у нас ну, нам нужно пере- перелопатить, наверное, всю систему, чтобы э-э прописать контракты для вот этой вот интеграции. Ну, это тоже по деньгам, наверное, дороже будет.
Speaker A
Вам спасибо. А-а следующий такой вопросик. А-а вот у вас есть партнёр, с которым который привёл заказчик, а-а внешний партнёр, а-а выбрали технологию, то есть, э-э общаетесь, будете общаться по REST, э-э эндпоинты есть и там, и там. Вам нужно
Speaker A
написать протокол функционально-технического взаимодействия между двумя, соответственно организациями. Первый вопрос, приходилось ли это делать или нет? И второй, соответственно, если нет, то давайте пофантазируем, что бы там могло быть в этом протоколе.
Speaker A
Угу. Между двумя организациями, ну, вы имеете в виду э-э там на- нашим сервисом и другой организацией? Вот так вот?
Speaker A
Да. Да-да-да. Ага. М-м ну, да, то есть, э-э обычно ну, я делал в ну, такой протокол какой-то такой ну, условно там формальный документ, где у нас там фиксируется, кто там что м-м как ну, в каком формате передаёт. То есть, обычно там э
Speaker A
ну, нужно описать, то есть со стороны там взаимодействия, то есть состав там э структуру данных, формат сообщений, там э поинты.
Speaker A
Вот э наверное, вот так. Ну, а так наверное, ещё по ошибкам, типа отклик на ошибки.
Speaker A
Так ну можем наверное по так скажем попрактиковаться. Угу. С точки зрения э интеграции у вас куда больше перекос?
Speaker A
Всё же на REST или на какие-то другие типы? М больше на REST. А какие методы знаете?
Speaker A
Угу. Э ну, у REST GET, PUT, DELETE это что касается там идемпотентных, POST, PATCH там неидемпотентные. Ну, ещё там из мало используемых, не знаю, там HEAD, OPTIONS например.
Speaker A
Основные отличия GET и POST можете озвучить? Угу. Ну, GET там э нужен для получения м данных в основном, а ещё второй POST.
Speaker A
Да. POST для создания записи. Э можно ли с помощью POST э осуществлять поиск данных?
Speaker A
Да. Что для этого нужно тогда? Угу. Так ну э если мы через POST э ищем э так скажем, получаем данные, то м чего?
Speaker A
Ну, нам нужно условно внутрь э добавить э условно фильтр, то есть э где мы будем условно вытаскивать э данные. То есть, или вы имеете в виду там условно э как вот это уже на с точки зрения URL там э
Speaker A
э должно быть. Я имею в виду с точки зрения соблюдения идемпотентности. Угу. А А, ну, хорошо, с точки зрения с сетевой э о'кей, хорошо, чтобы зрения идемпотентности, то нам нужен ключ идемпотентности, э чтобы мы м-м м-м не делали
Speaker A
запросы, которые там э-э меняли состояние системы. Хорошо, такой вопрос. Вот у вас э-э допустим десяток query params, по которым надо осуществить поиск. Какой метод выберете?
Speaker A
Угу. Так, ну по query параметрам угу. Ну, наверное, в том в этом случае, наверное пост точно.
Speaker A
Почему не get? Э-э ну, потому что м-м мы вот э-э сможем э-э м-м так скажем Смотрите, если у нас много фильтров, то в этом случае нам больше э-э точнее, точно лучше выбрать пост, потому что м-м у нас э-э
Speaker A
get больше для когда для того, когда у нас э-э меньше параметров и это просто поиск, а пост больше для условно, когда у нас много фильтров э-э и они там какие-то вложенные там или сложные.
Speaker A
Вот, то есть там Есть ли у get ограничения на длину строки? М-м да, то есть там удобнее э-э всё, я понял причину, э-э нам короче, мы выбираем пост, потому что в нём проще передавать э-э JSON там в body.
Speaker A
Не мы не зависим, в общем, от длины нашего URL'а. Повторю вопрос, у get есть ограничения по длине строки?
Speaker A
М-м да. Хорошо есть. Нет, это вопрос. Ну, вот 10 параметров, они влезут или нет? Или 11 влезет или 12?
Speaker A
Угу. У get есть ограничения? Э-э да, я я я точно знаю, что оно есть, но вот сколько именно, вот я, наверное, не подскажу.
Speaker A
Нет, достаточно, что вы знаете, что она есть. Собственно, я к тому, что просто может не влезть длина строки, потому что параметры же добавляются в запрос get.
Speaker A
Так а-а Мне ещё интересно ваш опыт по поводу validation layer'а. Вот. То есть, можете поподробнее рассказать, как он устроен, а-а и какие правила валидации вы там закладывали.
Speaker A
Угу. Э-э Что из себя представляет? Да, то есть то, скажем, м-м validation layer, ну, это, так скажем, такой условно слой безопасности, то есть между м-м опишкой и м-м бизнес-логикой. То есть, если проще, в общем, его задача, условно, отсеять э-э
Speaker A
м-м не какие-то неправильные там невалидные данные как можно, в общем, раньше и вернуть э-э условно понятные ошибки. Вот так вот. То есть, э-э наверное, по м-м самой структуре, то есть на входе он у нас проверяет данные, обязательность полей,
Speaker A
м-м длину э-э записи, м-м вот. Там за Это сервис ФЛК, по сути. М-м Ну, ФЛК не слышал. Ну, Форматно-логический контроль.
Speaker A
Ага. Ну, возможно, вот, но я так его никто не называл. Да, то есть тут я про вход рассказал, то есть на уровне м-м условно, наверное, ещё бизнес-правил, то есть у нас проверяет уже какие-то, скажем, предметные ограничения, то есть
Speaker A
там допустимые статусы, там уникальность, э-э там последовательность шагов, там ограничения может быть по м-м по времени, там по датам. Вот, и, ну, с точки зрения, наверное, уже м-м самой реализации, то есть обычно у нас м-м там была Ну, то есть, я сейчас ещё, наверное, так
Speaker A
скажу, то есть у нас была вот эта реализация через схему валидации там и отдельные правила, чтобы у нас хоть не зарывалась логика там по серверам.
Speaker A
Э-э так, вот так. Ну, наверное, что ещё? Не, в принципе мне понятно, спасибо. А, вопрос про безопасность в API, как обеспечивали, какими средствами?
Speaker A
Угу. Так, ну, что касается м, безопасности, ну, тут, наверное, можно м затронуть э м не знаю, то есть э аутентификацию, авторизацию. Вот э аутентификацию через э токены, то есть э JWT или OAuth 2. Вот, чтобы понять, кто вызывает апишку. Что
Speaker A
касается м авторизации, то есть э ну, это проверка права доступа, ну получается, по ролям, м там по бизнес-правилам, чтобы пользователь, в общем, видел только э разрешённые данные для него. М чего? А ещё, наверное, м что касается безопасности, наверное, защиту от э
Speaker A
атак, то есть э условно там э rate limiting, чтобы у нас э м Угу.
Speaker A
так скажем э В общем, мы мы контролируем количество запросов, чтобы у нас не было перегрузки нашего сервера. Вот, что касается, наверное, ещё э м не знаю, HTTP, то ну, у нас точ- только HTTPS был. Вот э Так, наверное, вот так, что по
Speaker A
безопасности. Всё, спасибо. У меня пока, наверное, все вопросы. Алексей, есть вопросы какие-то? А, у меня вопросы по документированию.
Speaker A
Вы ведь, наверняка, когда сервисы там, да, или там систему модернизировали а, как-то описывали эти сервисы там, что делали, да?
Speaker A
Вот, мне интересно, в каком формате и для какой целевой аудитории? Скажем так, то есть это пользователи системы, это разработчики. Ну, для разработчиков понятно, да, постановка задач.
Speaker A
Больше, наверное, для пользователей системы, для тестировщиков. Угу. Так, э ну, с точки зрения документации, где она была? То э, м ну, в конфлюенсе, то есть, э, я делал э ну, что касается там целевой аудитории, наверное, да, то есть, это было для
Speaker A
бизнеса, ну, и пользователей, то есть, э, что касается вот этой части, то это там короткое описание процессов, там пользовательские инструкции, схемы, хм, вот э прототипы вот ну для разработчиков, да, то есть, постановка задач там, э, апи-контракты там, модели данных,
Speaker A
правила валидации, для тестировщиков, э, ещё один раздел, то есть, это, хм, тестировщикам это, ну, больше там, то есть, сценарии тестирования, э, критерии приёмки, хм, чек-листы, в общем описание наверное э, проверок, э, ну, интеграционных между там системами, вот, это если касается
Speaker A
всех трёх частей. Использовали конфлюенс, да? Да. Угу. А, вот, э, документация для конечного пользователя, ну, вы сказали бизнес, ну, наверное, это так и есть, бизнес, она в каком виде требовалась, требовалась ли вообще?
Speaker A
Угу. Ну, у нас, э, хм, хм, что, что сказал бизнес, я имел в виду хм ну, она, естественно, в меньшем объёме, чем для, хм, разработчиков, вот, она больше для, э, скажем хм пользователей, э, работников, ну, там у нас там, это, хм, это были операторы
Speaker A
взыскания коллекторы ну там сотрудники боковиса, больше вот, э, для них, чтобы они понимали, как работает система.
Speaker A
Те, кто использует систему? Да. А, вот, в каком формате эту документацию делали, были какие-то к ней требования, э, ну, чуть-чуть расширю или подскажу, там, использовали ли какие-то, э скажем ГОСТ Хм.
Speaker A
стандарты для документации? Или она в свободном виде была? Ну, на самом деле, была в, в свободном, я знаю, что существует, э, ГОСТ, но у нас была, хм, в свободном таком, ну, в более-менее структурированном, но в свободном, то есть без жёсткой там привязки ГОСТ.
Speaker A
Угу. Я понял. Ну, на самом деле, ГОСТ это не звучит как что-то такое дремучее, сложное и страшное, да? Это просто требования некоторых заказчиков, особенно государственных.
Speaker A
Вот поэтому ну такое тоже бывает в жизни. Понял спасибо. К тебе пока все, да, вопросы?
Speaker A
Ну, да. Да.
Topics:системный аналитиксобеседованиеAgileuser storyAPI-контрактBPMNRESTSOAPтребованияIT-карьера
