0: Во первых, хотел бы вам задать вопрос вообще какие, о каких аналитиках вы слышали в области it?
1: Системы бизнес. Так, ещё какие продуктов? Так, отлично. А ещё какие-то, ну практически всех перечислили. Плохо, плохо.
2: Очень быстро, ну и хорошо, и плохо одновременно. Ну, собственно, 4 группы, да. Так вот, если укрупнённость аналитики данных, то есть те, которые занимаются анализом данных для бизнеса, то есть статистический
3: Какие-то выкладки проверяют различные гипотезы с точки зрения бизнеса. Продуктовый аналитик, он очень похож, по сути, с аналитиком данных, как из названия следует большее заточен на продукт. То есть, насколько, скажем, какие
4: Гипотезы в отношении продукта будут применимы там для бизнеса. Ну и, соответственно, бизнес аналитик и системный аналитик на курсах мы будем рассматривать больше системного аналитика. Чуть чуть будем касаться
5: Бизнес анализа, да, то есть, но, скажем так, что минимум знаний будем давать именно в бизнес анализе, потому что там соответствующие направления, то есть у нас сейчас компетенции нет.
6: Скажем так, 1, что я хотел бы это сравнить системно бизнес аналитика. То есть кто это такие, чем они занимаются. Бизнес аналитик, он в основном должен работать с заказчиком, с бизнесом, собирать.
7: Требования бизнес требования обрабатывать каким-то образом анализировать, должен разбираться в бизнесе, то есть понимать ту предметную область, в которой он работает, чтобы в дальнейшем это эти знания передавать, скажем, системному аналитику.
8: Системный аналитик, он необязательно должен разбираться в бизнесе. Почему не обязательно есть вот, скажем, такие компании, которых разделяют эти Роли. То есть есть бизнес аналитик, есть системный
9: Аналитик именно Роли, но в большинстве своём, то есть на практике, вот как у меня оказывалось, что бизнес аналитик и системный аналитик совмещался в 1 человеке. То есть 1 человек должен был
10: Погружаться и в бизнес, понимать, какие бизнес процессы проходят и как их надо автоматизировать и понимать, как это представлять в качестве системы, что ещё можно отметить, что системный аналитик больше упор делает на
11: Общение с командой разработки. То есть он контактирует с бизнес аналитиком, собирает какие-то бизнес требования, пытается представить их в виде какого-то решения, документирует и передаёт уже команде для дальнейшей
12: Разработки. Ну, если совсем коротко сказать, бизнес аналитик знает, что хотят пользователи и для чего это все нужно. А системный аналитик знает, как это реализовать с помощью системы. Ну, на практике, как я уже
13: Сказал, он является человеком оркестра, то есть совмещает Роли бизнес аналитика и системного аналитика. Давайте коротко, ну, как бы спрошу вас, да, то есть какие Роли вообще участников.
14: Разработки программного обеспечения, вы знаете, то есть некоторые из вас не is. It же пришли, может, вот они скажут, что-нибудь слышали.
15: Руководитель проекта.
16: Разработчик, так, ещё какие-то Роли. То есть мы же с вами понимаем, что, ну, процесс разработки это именно коллективный труд, то есть
17: Timmy. Ну, тимлид меньше, ну, практически всех назвали, да, то есть здесь основные Роли, именно Роли я отмечаю, потому что это не должности, а роль. Люди могут совмещать несколько ролей.
18: В проекте, да, то есть в некоторых, опять же, проектах, в которых я участвовал, приходилось как системному аналитику, и одновременно быть и бизнес аналитиком, и архитектором, и менеджерить немножко даже, значит,
19: Правильно сказали. Проект менеджер, менеджер проекта, руководитель проекта, это тот, скажем, специалист, который организовывает работу всего проекта, руководит командой, назначает задачи, определяет приоритет.
20: Взаимодействует с бизнесом с точки зрения оценки, например, задач и там сроков выполнения архитектор вот кто такой архитектор в it.
21: То есть архитектор определяет основные элементы системы и, скажем, как эти элементы между собой будут интегрироваться, взаимодействовать, почему и близко к системному аналитику, потому что приходится в том,
22: Числе этим заниматься, ну, при каких-то там разработках. Ну, бизнес аналитик, системный аналитик. Мы с вами уже сказали, чем занимается дизайнер ui ux интерфейс пользовательский, ну, не просто формочки, да, то есть он
23: Определяет как пользователь это вот как раз юикс, да, то есть будет взаимодействовать с системой. То есть я встречал хороших дизайнеров, которые, ну, очень классные решения придумывали с точки зрения юикса, то есть сам
24: Я не додумался. Аналитик этим, к счастью, не занимается. В основной своей массе он определяет просто функционал, который должен быть представлен, да, и потом взаимодействует с дизайнером. Ну, разработчики.
25: Соответственно, бэкэнд и фронтенд, понятно, разделяется на разработчиков клиентской части и серверной части. Тестировщик это тот, кто определяет. А вообще система соответствует тому, что хотел пользователь.
26: Требованиям вообще, нормально ли работает система, ну и devops инженеры это те сотрудники, которые определяют инфраструктуру, осуществляют настройку системы, настройку программного обеспечения, скажем.
27: Проводник между железом и программным обеспечением, помимо вот этих основных ролей участников, да, то есть разработки существуют ещё какие-то дополнительные, те, кому звонят обычно, если вдруг юристы, ну и эти тоже, то есть
28: Юристы и техподдержка, да, то есть и маркетологи, специалисты информационной безопасности. То есть они тоже принимают участие в разработке, в каких-то системах. Ну, например, там, в игорном
29: Бизнесе лотерейном юристы очень нужны, потому что есть требования жёсткие законодательства, там проверки финмониторинга в банковской сфере тоже были проекты, например, система для обучения изучения иностран.
30: Языка, да, то есть небольшое мобильное приложение делали, в проекте участвовали лингвисты, то есть там различные языки были французский, английский, испанский, то есть и, естественно, с ними от этого зависела структура хранения данных.
31: Например, пришлось переделать под испанским, мне кажется, там какие-то свои особенности были задания соответствующие по изучению языка делались, да, то есть, потому что сам аналитик, он не может придумать, ему нужно именно предметного
32: Область. Здесь они больше выступали как знатоки предметной области. Ну и ещё 1 с лингвистической точки зрения проект был это проект по переводу с языка глухонемых, да, то есть, вернее, на язык глухонемых.
33: Автоматизацию сурдопереводчиком, то есть вводили текст какой-то и там вот жестами, скажем, графическая 3 д такая моделька изображала все это. Посмотрим ещё с вот этой стороны, да, то есть
34: Любое, ну, разработка программного обеспечения, это процесс какой-то, да, то есть, условно можно выделить вот 5 этапов. Анализ требований, проектирование, программирование, тестирование и эксплуатация. Опять же, вопрос к вам.
35: В каких из этих 5 этапов разработки участвует аналитик?
36: Во всех, опять же, то есть в основном, конечно, это анализ требований и проектирование, потому что анализ требований тут подразумевается и сбор, документирование, формализация какая-то, то есть
37: Внимание, а все ли достаточно для разработки проектирование, понятно? То есть он какие-то технические решения определяет, в том числе и там архитектурные. Если это нужно, программирование, здесь больше сопровождение
38: Скажем, разработчики приходят с соответствующими вопросами, потому что не все может быть понятно по документации это нормально, бывает и такое. А может и вообще не быть каких-то, упущены какие-то моменты с тестированием тоже самое. А вот с эксплуатацией, ну не на всех.
39: Проектах, но на большинстве производится разбор инцидента. То есть здесь участвуют сотрудники техподдержки, разработчики, тестировщики и в том числе привлекают аналитиков для того, чтобы понять, что же пошло не так. То есть приходят, говорят, есть такой
40: Баг. Вот такое поведение системы и нужно определить, а что же было неправильно. Поэтому приходится участвовать во всех этапах разработки программного обеспечения. Какие задачи бывают здесь. Примеры приведены на
41: На этом слайде, скажем, минимальная, то есть задачи могут различные быть от каких-то очень маленьких задач, где необходимо доработать какую-то интеграцию, добавив 1 параметр для этого там
42: Можно посмотреть модель данных, понять, добавить это там пару Десятков минут, может быть займёт вся эта работа. А бывает такое, что необходимо разработать техническое задание на какую-то систему, где у тебя
43: Может занять это? Ну, там не 1 месяц были проекты у меня, на которых я работал по разработке мобильных приложений, где был 1 единственный аналитик. По идее, вдвоём работали. Обычно был пм и аналитик. Вот такая маленькая команда.
44: Разработку мы привлекали, конечно. Ну, спрашивали какие-то вопросы именно технические, но в основном 3, 4 месяца на разработку технического задания уходит. То есть, оно, естественно, не детально проработанное, как вот бывает.
45: Но верхнеуровневое какое-то формировали 3, 4 месяца. Дальше шла детализация, уже разработка и так далее. Помимо этого задачи, связанные с анализом ошибок взаимодействия, это вот то, что я говорил на сопровождении
46: Были задачи, где необходимо было понять, ну, какие-то паттерны, которые происходят у нас в ошибках, да, то есть и распространить на взаимодействие интеграции с другими системами. То есть анализировали 1 систему и смотрели, а может быть это другим, то есть
47: Знание баз данных эскьюэль, то есть жёсткий, жёсткая статистика. Перейдём к следующему вопросу. Какие скиллы должны быть у системного аналитика? То есть какими характеристиками он должен обладать софт скиллы? Ну, практически все сказал.
48: Да, то есть коммуникация 1 из самых важнейших навыков у системного аналитика, так как, ну, процентов 70 времени приходится коммуницировать с кем-то, то есть с кем-то взаимодействовать или
49: Голосом или с помощью письма созвоны бесконечные, бесконечные, документирование того, что проговорили, то есть коммуникация 1 из самых важных, скажем, Скилов, планирование, так как он вытекает из 1, так как прихо.
50: Очень много взаимодействовать, все же надо что-то документировать, надо как-то обрабатывать, поэтому чётко надо планировать своё время. Если человек не может спланировать, ну мало чего добьётся. Следующее критическое мышление тоже очень важный. Ну, скажем,
51: Характеристика системного аналитика это критическое мышление, потому что нужно взять и отсечь все лишнее. То есть проходит очень много информации, особенно от бизнеса, там поток сознания бывает. То есть нужно выкинуть все ли
52: Понять, что же на самом деле за проблема и как её решить. Говорили вот про способность осваивать большой объём новой информации за ограниченное время. Ну да, это так и есть. Узнавать новые технологии, применять это обучаемость как раз, да.
53: Тоже тоже это нужно. Вот даже этот курс, который мы читаем, этого недостаточно, скажем, чтоб постоянно работать, надо постоянно что-то изучать, постоянно изучать новые технологии, постоянно читать статьи, потому что проект от про
54: Отличается. Мы пытаемся на курсе дать, ну, скажем, широким фронтом все, что может понадобиться аналитику, но в проекте может прийти и заниматься чисто интеграциями. Просто вот ни юая, ничего нет.
55: Просто интеграции, жёсткие маппинги полей и там ещё что-то то есть, а кто-то может прийти и хранимые процедуры переводить на какие-нибудь нормальные языки программирования, то есть разные направления везде надо что-то изучать.
56: Это всегда, ну и 6 пункт, это аргументированно отстаивать свою точку зрения. То есть он тоже 1 из немаловажных характеристик системного аналитика, потому что любое решение, которое придумал
57: Аналитик нужно будет отстаивать перед командой, перед заказчиком, как бы, то есть всегда нужно уметь доводить свои мысли, скажем, до людей. Про хард скиллы немножко поговорим. Ну, условно можно разделить
58: На 4 группы примерно так же и построили курс, то есть 4 группы hard Скилов это работа с требованиями, то есть по сути это основное что делает аналитик, то есть он формирует
59: Требования к системе в графическом виде, в текстовом виде таблицами, диаграммами, то есть различными способами, но он работает с требованиями, то есть основной продукт его это требования, то есть
60: Он понимает проблемы бизнеса то, что или бизнес аналитик, или напрямую от бизнеса, он получает и трансформирует их в требования к системе для того, чтобы команда могла эти требования реализовать элементы архитектуры.
61: И интеграционного взаимодействия. Для того, чтобы проектировать систему, необходимо понимать, какие вообще есть элементы могут быть, из чего она состоит и как эти элементы между собой интегрируются, взаимодействуют. 3 блок это база.
62: Данных снова эскюэль. Это связано с моделью данных. Это другое, по сути, представление системы. То есть, если 1 это элементы архитектуры, это, скажем, какие-то либо программные компоненты микро,
63: Сервисы, ещё что-то, да, то есть то здесь это именно представление данных и 4 это инструменты аналитика, то есть то, что помогает ему работать, создавать те самые диаграммы, текст, ну,
64: И так далее. Вкратце то, что у нас на курсе, то есть у нас на курсе будет 20 лекций. То есть, условно скажем, они теоретические, ну и будут практические в рамках лекции небольшой. Будем также вот интерактивной работа создавать.
65: Пробовать систему и 10 вебинаров, где чисто практика, будем рассматривать либо инструменты какие-то, с которыми работаем, либо закреплять то, что на лекциях прослушали в 1.
66: Блоке мы узнаем классификацию метода сбора требований, научимся, поймём, что такое бизнес процесс, и научимся его моделировать вкратце. То есть потому что широко это все равно нужно будет и самостоятельно что-то
67: Поизучать. Ну, в рамках лекции я посоветую источники, с которых это нужно будет посмотреть. Научимся составлять диаграммы вариантов использования нотации юэль, ну, собственно, формировать требования в текстовом виде в виде юсер стори.
68: Юскейс, то есть сценариев, и описывать прототипы юай это что касается блока требований во 2 блоке это элементы архитектуры и интеграционного взаимодействия познакомимся с основами архитектуры it систем.
69: И видами интеграции научимся составлять диаграммы последовательности, нотации юмл, описывать методы api ну и познакомимся с алгоритмами авторизации в 3 блоке это уже, как я уже говорил, касаемо модели.
70: Данных, то есть типы баз данных узнаем и виды моделей данных вкратце коснёмся, то есть базовые эскьюэль запросы, ну и научимся составлять модели данных в виде ер диаграмм с их описанием последний блок.
71: Это инструменты системного аналитика. Здесь мы с вами познакомимся с теми инструментами, которые позволят проектировать бизнес процессы, проектировать диаграммы, юмл, тестировать, то есть той части, которой
72: Нужны аналитики, то есть глубоко элемент тестирования не будем рассматривать. Ну и основные инструменты ведения, задачи документирования, требования конфлюенс в рамках курса будут практические задания, то есть мы будем выполнять
73: Учебный проект, у каждого будет индивидуальная тема. Каждому будет закреплён куратор по проекту, с которым можно будет взаимодействовать. Он будет для вас бизнес заказчиком, ну и будет проверять, направлять, подсказывать, то есть как выпол,
74: Работ. В рамках учебного проекта будут разработаны 2 документа. Документ о концепции, границах проекта это больше бизнесовый, да, то есть документ и техническое задание с описанием каких-то спецификаций требований. Вопросы
75: Образцы обязательно всегда, что такое техническое задание. Вот вопрос интересный, да, то есть вот есть гостовское, да, определение технического задания, в котором определяются только требования, по сути, да.
76: Смотреть с точки зрения госта, то это, скорее всего, совмещение технического задания по госту и пояснительной записки, то есть где мы рассказываем о тех технических решениях, которые должны быть реализованы. То есть 1 это требование блок.
77: Идёт необходимый для решения задач. И 2 это, например, описание взаимодействия там каких-то микросервисов между собой. То есть здесь в любом случае вытекает из сложности задачи. То есть если мы с тобой
78: Мы берём систему огромную, да, то техническое задание, соответственно, верхнеуровневое будет от аналитика. Дальше оно уже будет детализироваться в техническое задание для непосредственно разработчика, где там будет написано вкратце требования, например, если берём какую-нибудь
79: Техническое задание на разработку метода интеграции, то там будет написано требование к этому методу интеграции, что метод интеграции должен то-то, то, то делать, да, возвращаемые параметры такие-то входные параметры такие, то тут тяжело ответить, скажем вот так.
80: Потому что это вот от задачи. Если строишь дом, то у тебя 1. Если там проектируешь табуретку, то по другому будет выглядеть. Соответственно, а что значит?
81: Как раз-таки 1 документ, в дальнейшем я про него буду рассказывать. Это в следующий понедельник лекции. Ну, вкратце скажу, это 1 из способов документирования бизнес требований. Не часто встречается документ в работе.
82: Да, то есть, ну вот на самом деле 2 раза было он нужен для того, чтобы до этапа сбора, скажем, вот требований, то есть детализации какой-то и проектирования, решения, затвердить границы проекта, чтобы заказчик
83: Не придумывал на ходу дополнительные какие-то требования.
84: Задачи, я думаю, на следующем занятии уже какую-то мы дадим по желанию, можно по желанию выложим таблицу google, таблицу с темами кто успел, кто успел, тот молодец.
85: Можно выполнять, можно не выполнять. То есть это мы никого не заставляем. Что делать. Марсианам вечером выложим, после 7 войдём в
86: Положение.
87: Сроки, да, сроки промежуточных не будет проверок, да, то есть это все. Работаете с коммуницируете со своим куратором по окончанию курса ещё даём 2 недели на завершение.
88: Вот. Дальше посмотрим, оценим лучших. Пригласим в компанию. Обычно так делаем. Так, ещё вопросы.
89: А куратора тоже назначит, назначит. У нас просто темы придумывают кураторы. А темы понятно? Да, выбирает тему, да, по сути.
90: Так, но в табличке изначально не видно куратора, чтоб подтасовок не было. Тоже проблема, когда придумаешь, например, 15, 20 тем, да, то есть и все выберут твои самый простой. Ну, там, кстати, есть, да, есть простые очень.
91: Тем, есть сложная. Тогда, наверное, будем заканчивать. Раз нет вопросов. Отлично. Да, да.
92: Да, да. Угу.