8 курсов по аналитике данных для новичков

Российский национальный исследовательский медицинский университет имени Н.И. Пирогова

Больница имени Буянова (ранее Больница №12), г. Москва

«Методика трансторакальной эхокардиографии», НМИЦ кардиологии

XIV Национальный конгресс терапевтов

«Клиническая электрокардиография и другие неинвазивные методы диагностики сердечно-сосудистых заболеваний»

Российское научное медицинское общество терапевтов

Рейтинг

Отношение к пациенту

Посоветуете ли врача?

19 мая 23 в 13:11

Добрый день!
Позвольте поблагодарить Вас за положительную оценку качества работы нашего специалиста.

Клиника репродуктивной медицины «Здоровое наследие»

05 июля 22 в 11:33

Медицинский центр «Доктор для меня»

07 апреля 20 в 09:03

Большое спасибо за время, уделённое на отзыв! Берегите своё здоровье!

Медицинский центр «Доктор для меня»

21 марта 19 в 22:57

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

Медицинский центр «Доктор для меня»

11 марта 19 в 12:47

Медицинский центр «Доктор для меня»

28 февраля 19 в 15:03

Благодарим за высокую оценку работы врача! Берегите себя и сына! Всего вам доброго))

Медицинский центр «Доктор для меня»

17 февраля 19 в 21:03

Большое спасибо за теплые слова.Мы обязательно передадим ваши впечатления о приеме доктору Ольге Андреевне.Она будет рада, что лечение помогло и в первый же день стало легче. Берегите себя и будьте здоровы!

Медицинский центр «Доктор для меня»

08 ноября 18 в 16:04

Благодарим за отзыв! Мы обязательно передадим ваши слова и мнение коллег Ольге Андреевне! Будьте здоровы!

Медицинский центр «Доктор для меня»

18 октября 18 в 17:16

Благодарим за отзыв о работе нашего специалиста.Мы высоко ценим рекомендации коллег из других клиник и с большим уважением относимся к мнениям наших пациентов. Желаем вам здоровья,берегите себя!

Медицинский центр «Доктор для меня»

18 октября 18 в 12:47

Благодарим за лаконичный отзыв и благодарность в адрес врача) Будьте здоровы!

Медицинский центр «Доктор для меня»

18 октября 18 в 12:49

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

Медицинский центр «Доктор для меня»

07 октября 18 в 11:36

Благодарим за отзыв и высокую оценку компетентности нашего врача. Мы обязательно передадим Ольге Андреевне ваш отзыв) берегите себя!

25 сентября 2018

в 12:24

Медицинский центр «Доктор для меня»

25 сентября 18 в 13:23

Медицинский центр «Доктор для меня»

25 сентября 18 в 13:26

Благодарим за тёплый отзыв о работе врачей и медцентра. Мы искренне рады, что лечение в короткий период дало эффективный результат) Будьте здоровы!

15 сентября 2018

в 14:00

Медицинский центр «Доктор для меня»

21 сентября 18 в 17:22

Благодарим за отзыв, мы с большим вниманием и пониманием относимся к любым комментариям со стороны пациентов, даже негативным.
Вы к нам обратились для проведения УЗИ почек в острый период без подготовки и предварительной записи. По данным УЗ-исследования визуализация была затруднена,эхогенность снижена,дифференциация коркового и мозгового слоя почки нечеткая (что говорит о воспалительном процессе).На момент исследования конкременты в почках не визуализировались и отток мочи не был затруднен! К сожалению УЗ-диагностика не является высокочувствительным и специфичным методом исследования почек и в ряде случаев,при плохой подготовке пациента не позволяет вывести 100% чёткое изображение на экран.
Врач УЗИ Гаврюшина О.Ю. по второй специальности терапевт имеет достаточный стаж практической деятельности в работе с пациентами.Рекомендованные вам врачом препараты были предложены дополнительно к лечению, выписанным врачами ЦРБ с целью снижения воспалительного процесса.
Рекомендуем вам внимательно следить за своим здоровьем,посещать профильных врачей и проходить лабораторные исследования.
Берегите себя и будьте здоровы!

Медицинский центр «Доктор для меня»

25 мая 18 в 21:31

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

На слайде – высказывания из чата Infostart Friends – там постоянно бурлит обсуждение: кто такие аналитики; как стать аналитиком; какие книжки почитать, чтобы стать аналитиком и т.д.

Судя по результатам этого обсуждения, 98% участников 1С-сообщества считают, что аналитик – это некая прокладка между заказчиком и разработчиком. Человек, который должен что-то спросить у заказчика, написать ТЗ, проверить результат и написать инструкции. При этом непонятно, зачем вообще он нужен, зачем на него тратить деньги, если можно пойти и самому спросить.

Каждый раз, когда я читаю все эти высказывания, у меня внутри все вскипает.

Мне очень хочется ответить, что вообще-то аналитик – это лидер проекта.

Классически принято разделять аналитиков по видам выполняемых ими работ. Например, есть аналитик качества данных, который проводит какую-то работу с данными. Продуктовый аналитик, который проводит какую-то работу с продуктом. Системный аналитик, бизнес-аналитик, BI-аналитик, UX-аналитик и т.д. – всех этих аналитиков что-то объединяет, потому что в названии их должности есть слово «аналитик».

По мнению сообщества их объединяет то, что они собирают требования, составляют ТЗ, пишут инструкции и прочее.

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

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

Я хочу показать вам — какие приемы и подходы отличают аналитика уровня «лидер проекта» от аналитика уровня «прокладка».

Начну с того, кто я. В проектах автоматизации 1С я с 1996 года.

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

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

Тут на слайде приведено вызывающее высказывание, но это действительно правда. Я могу организовать проект автоматизации в любой предметной области, о которой сейчас даже не подозреваю, с использованием любой, даже абсолютно незнакомой мне конфигурации.

• показать на примере реального кейса практические приемы работы аналитика;

• показать аналитикам (или тем, кто хочет ими стать) точки роста – что нужно научиться физически делать, чтобы стать крутым спецом;

• показать руководителям проекта и членам команды, что присутствие аналитика уровня «лидер проекта» в разы повышает эффективность всей команды – за счет того, что команда делает только те действия, которые нужно сделать, и эти действия 100% приводят к результату, а не так, что мы сейчас попробуем, сделаем, а потом: «Ой, что-то не получилось».

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

Интуиция сродни искусству. Искусство – это когда мы что-то сделали, получилось здорово, но повторить это мы не можем.

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

Результат, полученный при помощи интуиции, нельзя масштабировать – потому что непонятно, что там именно сработало.

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

Если вы приходите на обследование и говорите заказчику: «Скажите мне, как вы работаете, и я вам скажу, как вы это будете делать в 1С» – вы не аналитик, вы внедренец какого-то продукта.

Или если вы хорошо разбираетесь в конфигурации с точки зрения ее устройства в конфигураторе – вы тоже не аналитик. Вы, скорее всего, технический специалист или консультант.

А аналитик, приходя исследовать какую-то область, уже на 60% знает, как в ней построены бизнес-процессы – он просто задает уточняющие вопросы.

При этом изначально картина того, что он идет обследовать, у него в голове уже сложена на 60% как минимум. Про 60% – это не я придумала, это я прочитала в авторитетных источниках и с этим согласилась.

История проекта

Расскажу про историю проекта.

Начался он следующим образом: головная организация присылает методичку по классам и их характеристикам. И говорит, что запускается проект внедрения ТОиР – нужно выгрузить все данные по классам технических объектов в определенные шаблоны в Excel-овском формате.

Мы – отдел из трех аналитиков.

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

• Второй – бывший программист.

• Третий – выпускник кафедры бухгалтерии.

В общем, команда мечты!

Кроме нас в организации был отдел ИТ, но у них и без нас хватало работы.

Когда нам поставили эту задачу, она не показалась нам сложной – часто же просят сделать какую-то выгрузку. Вроде ничего особенного.

Руководство говорит: «Давайте раздадим задания филиалам. Пусть филиалы заполняют данные в эти шаблоны». Нормальное решение. Что такого?

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

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

Потом оказалось, что в производственном, регламентированном и имущественном учете признаки объекта имущества разные. Совсем разные. И не потому, что там кто-то накосячил, а потому что — это объективная реальность.

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

Объектов оказалось 2 миллиона. И самая большая проблема, что документы всех подразделений для одного объекта нельзя взять и по одному объекту все заполнить. Просто нельзя.

Копаем дальше – ищем документы, которые содержат данные по группе объектов. Оказалось, что мы не можем запустить в работу операторов, потому что документы десятилетиями велись в не формализованном виде и вытащить нужные данные из документов могут только производственные рабочие. Возникает большой вопрос – кто же будет заполнять эти шаблоны. У нас все еще нет мысли о создании новой АИС – мы работаем над заполнением шаблонов.

И как контролировать эти шаблоны, тоже непонятно. Что пользователи введут в эти Excel-файлы бесконтрольно – одному Богу известно. Получается, что мы не можем контролировать корректность данных. Пока мы не оцифруем все два миллиона объектов, у нас не будет ясности, что все правильно.

Чтобы все это выверить, потребуются годы. А у нас срок – несколько месяцев.

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

Придумали решение – сделать промежуточную АИС, в которую будем вводить все с проверками, а потом выгружать все в нужном виде в шаблоны автоматически.

Первым шагом, естественно, идем обследовать процессы.

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

И встает вопрос: как в процессах, которые отличаются друг от друга, найти что-то единое и постоянное для всех?

У нас топ-5 проблем.

• Разночтение в видах учета.

• Разобраться с данными и заполнить могут только производственники.

• Вручную заполнить шаблоны с учетом иерархии классов – нереально.

• И документы по одному объекту разобщены территориально и по службам.

• Ну и количество объектов — вот такое, трудоемкость по вводу данных силами производственных рабочих — несколько лет. По выверке это еще следующие несколько лет. Ну, как бы вполне себе такой реальный проект, который бывает в организациях такого уровня.

Я хочу показать несколько приемов из моего личного чемоданчика с инструментами аналитика. Они, может, вам покажутся не инструментами, а чем-то другим, но, тем не менее, это работает.

Инструмент аналитика №1

Мы делаем только тот шаг, по которому точно понятно, что его можно сделать.

Это значит, что:

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

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

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

Делать конкретные шаги – это значит давать такие задания, по которым у пользователей не будет возможности сказать: «Я не знаю, как это сделать», «У меня нет возможности», или что-то еще.

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

Как мы использовали эти понятные шаги при разработке своей АИС?

Важно максимально детализировать задания пользователям. Например, мы задаем им вопрос: «Сколько всего у вас газопроводов?» Производственники нам отвечают: «У нас нет такой информации» – мы понимаем, что у них нет готового сводного документа. Спрашиваем: «А где у вас описаны эти газопроводы?» Они говорят: «Документы на них лежат в этих четырех шкафах». Даем им задание: «Посчитайте эти документы». После этого они уже не могут нам сказать, что не могут посчитать документы, которые лежат в шкафах. Заодно они начинают делать инвентаризацию.

Дальше – этапы проекта. Мы в первую очередь проработали трубопроводы. Трубопроводы мы взяли осознанно и откинули все остальные работы. Потому что трубопроводы – это базовый процесс, который нам нужно было описать. Мы шли только по нему и “били по рукам” всех, кто отвлекался на другие работы. Важно, чтобы у производственных рабочих не было возможности сказать: «Мы не вводим трубопроводы, потому что сейчас делаем другое». Мы им запрещали делать другое, пока они не ввели трубопроводы. Таким образом направляли их в нужном нам направлении, как косяк рыб на предыдущем слайде.

Ищем возможность контролировать каждый шаг и не даем задание на ввод данных, если не понимаем, как контролировать этот ввод.

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

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

Жизненный цикл + цикл управления

Жизненный цикл любого объекта можно представить как последовательность этапов: зачали, развивался в утробе, родился, жил, умер. Переход с одного этапа на другой для конкретного объекта фиксируется вводом или изменением какого-то документа.

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

Как мы использовали жизненный цикл в разработке АИС?

Мы начали раскручивать учетные процессы для основного объекта – трубопроводы.

• Зачали / развивался в утробе – это инвестиционные программы.

• Родился – это построили и ввели в эксплуатацию. Документом, который содержит все данные на момент рождения этого трубопровода, оказался ИТД – он содержит всю информацию на определенный момент этого этапа жизненного цикла.

• Жил (рос, лечился) – это у нас каждый шаг по модернизации. Эти шаги у нас фиксируются в эксплуатационном паспорте. Ищем связь между ИТД и эксплуатационным паспортом, понимаем, что у одного ИТД может быть несколько эксплуатационных паспортов, и у нас появляется возможность это контролировать.

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

Здесь на слайде показано, как мы использовали этапы жизненного цикла при разработке АИС.

Переходим к циклу управления.

Функции цикла управления – это

Управлять – это значит запланировать какие-то действия, исполнить их, проконтролировать их выполнение, и если что-то пошло не так, принять какое-то управляющее воздействие.

Для наших проектов это означает следующее:

• Планирование – у нас есть конкретное место, где занесены плановые данные. Когда мы проектируем наши АРМ в системе, мы четко понимаем, что вот в этом месте у нас хранятся плановые данные.

• Исполнение – у нас где-то фиксируется факт выполнения конкретных действий. Причем для автоматизации не важен сам факт выполнения действия, важно, где ты это фиксируешь.

• Контроль. В программе должно быть такое место, где план и факт стоят вместе, чтобы было видно, чем они отличаются. Но план и факт – это не только цифры. Регламент выполнения и фактическое выполнение действия – это тоже план и факт, и они тоже могут не совпадать. Т.е. здесь это шире.

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

В результате мы сделали четкую структуру технических объектов: у нас есть плановые данные в документе ИТД, и мы их сравниваем с фактическими итоговыми данными по структуре каждого объекта. Мы просто создали место в программе, где у нас плановые данные сравниваются с фактическими – таким образом мы использовали инструмент цикла управления.

Выводы

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

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

Если аналитик просто собирает требования – то да, он просто аналитик.

Но чтобы стать лидером, он должен быть и аналитиком, и инженером, и организатором.

• Он должен не просто собрать требования, а найти область, которую можно улучшить.

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

• Он должен не просто предложить план, но и помочь выполнить эти действия.

Если вы умеете все это делать, вы неизменно станете лидерами проектов, будете работать на интересных проектах, и, как специалист — стоить дорого.

Кто он – аналитик 1С? Все зависит от самоопределения

Все зависит от каждого человека. Вам никто не скажет: «В этом проекте можно сделать еще вот это и вот это».

Аналитик – это тот человек, который знает как помочь. Он может сам найти, что сделать и как сделать.

Я на Инфостарте провожу курс по автоматизации производственных процессов «Практические приемы и инструменты аналитика».

Цель этого курса – повысить компетентность специалистов и их стоимость в конечном итоге.

Курс даст 60 % понимания области автоматизации производства. Мы там будем разбирать производственные процессы с точки зрения их автоматизации.

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

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

Статья написана по итогам доклада (видео), прочитанного на конференции «Анализ & Управление в ИТ-проектах».

Также рекомендуем посмотреть мастер-класс.

Практическое руководство, примеры и шаблоны

Лучший способ понять теорию — получить больше опыта в разных проектах. Для системных и бизнес-аналитиков я постоянно показываю подходы к работе через публикацию разборов задач: БД, API, Интеграции, требования, и все, что связано с проектированием систем.

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

Проект

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

Все примеры в статье будут связаны с этим проектом.

Общий подход к работе системного аналитика

01 Знакомство с бизнес-контекстом и бизнес-требованиями, их уточнение

Во‑первых, что такое бизнес‑контекст? Это как фон, на котором мы пытаемся понять нашу задачу. В нашем случае, это может быть, например, понимание того, как сообщество общается сейчас, какие у него проблемы и какие цели оно преследует. Здесь мы можем поговорить с руководством сообщества, пообщаться с его действующими участниками, изучить их текущие способы общения — социальные сети, форумы, вебинары и так далее. Либо просто получить уже собранную информацию с описанием работы сообщества сейчас — это AS IS (описание «как есть» для проекта).

Теперь, что такое бизнес‑требования? Это то, что бизнес хочет от будущей системы. В нашем случае, это может быть, например, желание сделать процесс регистрации на вебинары проще и удобнее, или желание собрать всю информацию из разных соцсетей в одном месте. Бизнес‑требования мы также обычно собираем на встречах с заказчиком, проводим интервью и обсуждения. Это To Be — как должно быть в результате разработки.

Важно понимать, что первоначально собранные требования часто бывают не полными или не точными.

Задача системного аналитика — уточнить эти требования, не погружая заказчика в технические детали реализации, но уже примерно представляя, что будет «под капотом». Мы возвращаемся к заказчику или потенциальным пользователям с вопросами, уточняем детали, проверяем понимание, проводим дополнительные интервью, если необходимо, чтобы убедиться, что мы все правильно поняли.

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

02 Определение ролей пользователей и приложений. Верхнеуровневое проектирование архитектуры

Определение ролей пользователей и приложений

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

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

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

Верхнеуровневое проектирование архитектуры

Сначала выделяем компоненты системы — отдельные приложения, сервисы:

• сервер Backend, который будет обрабатывать запросы от приложения, и может включать в себя подсистемы (сервисы, микросервисы),

• база данных для хранения информации о пользователях, вебинарах и новостях,

• внешние системы — источники данных, из которых надо получать данные и в которые их надо передавать (интеграции).

Для визуализации архитектуры можно использовать нотацию C4.

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

На картинке ниже пример описания архитектуры в разработанной мною нотации, которая легко трансформируется в C4.

03 Выделение и описание основных сценариев работы с системой

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

Use Case

Для описания сценариев очень удобно использовать формат use case. Use case — это описание того, как система и пользователи взаимодействуют друг с другом для достижения какой-то цели. Use case включает в себя не только последовательность действий, но и роли, которые участвуют в этом взаимодействии, и возможные альтернативные сценарии.

Основное удобство формата use case в том, что он позволяет представить сценарии взаимодействия с системой в простой и понятной форме. Use case показывает, какие роли участвуют в сценарии, что они делают, и как система на это реагирует. Это помогает всей команде лучше понять, как должна работать система, и учесть все возможные варианты взаимодействия пользователей с системой.

04 Проработка альтернативных сценариев

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

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

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

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

05 Задачи на дизайнера

Следующая задача — представить, как эти сценарии будут выглядеть в интерфейсе нашего приложения — UI/UX. Здесь на помощь приходит дизайнер.

Задача системного аналитика на этом этапе — правильно и полно передать всю собранную информацию дизайнеру. Это может включать в себя описание всех ролей и сценариев, предпочтения целевой аудитории.

Иногда системный аналитик рисует макеты, используя Figma, Miro, Draw.io, Axure RP Pro или другие инструменты.

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

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

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

06 Определение ключевых данных: сущности и их свойства

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

Вернемся к нашему примеру мобильного приложения для сообщества. Основными сущностями в нашем случае могут быть «Пользователь», «Вебинар» и «Новость». У каждой из этих сущностей будут свои свойства. Например, у «Пользователя» могут быть свойства «Имя», «Email», «Дата регистрации», и т.д. У «Вебинара» — «Название», «Дата и время», «Описание», «Организатор», и так далее.

Также мы должны определить, как эти сущности связаны друг с другом. Например, «Пользователь» может быть зарегистрирован на одном или нескольких «Вебинарах». Эта информация важна, потому что она поможет нам понять, как должна быть организована база данных нашего приложения.

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

От того, насколько продуманно будет создана БД и определены сущности, зависит масштабируемость системы в будущем.

07 Задачи на доработку Базы Данных

Прежде чем программисты начнут разрабатывать методы Backend, им нужно подготовить базу данных.

• создать новые таблицы,

• добавить поля в существующие таблицы,

• сделать миграции данных (перенос и автозаполнение),

• иногда поменять типы данных, удалить лишние поля и так далее.

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

Шаблон Confluence и инструкция

08 Задачи на подготовку тестовых данных

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

Эта задача может быть сделана как системным аналитиком, так и смело передана на тестировщика.

Например, в случае нашего приложения для сообщества, мы можем создать несколько тестовых «Пользователей» с разными параметрами — с корректными и некорректными email’ами, зарегистрированными на разное количество «Вебинаров», и т. д. Мы также можем создать несколько тестовых «Вебинаров» и «Новостей» с различными свойствами.

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

09 Задачи на разработку методов Backend (методов API)

В работе приложений существует нечто, что помогает передавать данные между разными частями системы, например, между пользовательским интерфейсом (фронтендом) и сервером (бекендом). Это называется API, или Application Programming Interface.

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

Для каждого метода API, системный аналитик должен определить, какие данные он принимает на вход (например, данные для регистрации нового пользователя), и что он возвращает на выход (например, подтверждение успешной регистрации).

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

Пример задачи на бэкенд — шаблон постановки задачи + инструкция

10 Задачи на фронтенд / мобильные

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

Задача системного аналитика на этом этапе — описать, что именно должен видеть и делать пользователь в приложении. Для этого аналитик подготавливает список задач для фронтенд или мобильных разработчиков, которые включают работу, сделанную на предыдущих этапах: описание Use Cases, дизайн, методы Backend, тестовые данные, чтобы можно было в процессе разработки воспроизвести все ошибки, до передачи в тестирование.

Вот пример таких задач:

1. Создание экрана регистрации на вебинар.

2. Отображение списка доступных вебинаров.

3. Создание уведомлений о предстоящих вебинарах.

4. Добавление возможности читать новости сообщества в приложении.

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

Пример задачи на фронтенд — шаблон постановки задачи

11 Задачи на тестирование

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

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

1. Проверить, происходит ли корректная регистрация пользователя на вебинар.

2. Убедиться, что новости сообщества отображаются правильно и актуальны.

3. Проверить работу уведомлений о предстоящих вебинарах.

4. Протестировать работу приложения на разных устройствах и разных версиях операционной системы.

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

12 Задачи на сохранение важных артефактов по документации после разработки — документация

Даже после того, как разработка приложения завершена и оно уже запущено, работа системного аналитика все еще не закончена. Один из важнейших этапов — это сохранение и поддержание актуальности всей документации, связанной с проектом.

Артефакты и документация — это не просто свалка статей Confluence + задач Jira, а ключевая информация о проекте. Она помогает новым участникам команды разработки быстрее разобраться в проекте, а также служит источником правды при необходимости внести изменения или улучшения в будущем.

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

1. Документы, описывающие функциональные требования и пользовательские сценарии.

2. Диаграммы и схемы, включая C4 диаграммы архитектуры системы и Use Case диаграммы.

3. Документы с описанием ключевых данных, сущностей и их свойств.

4. Документацию API и описание логики работы методов.

5. Документы с результатами тестирования и проблемами, обнаруженными в процессе разработки (особенности и известные проблемы).

Все это может быть собрано в ранее приведенных шаблонах требований для Confluence.

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

Проекты не заканчиваются с моментом запуска — они постоянно развиваются и совершенствуются, и качественная документация играет в этом важную роль.

Про процесс документирования:

Применение описанного подхода на практике

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

Подборка моих блогов с теорией + примерами требований + диаграмм + постановок задач: здесь. В ней вы найдете шаблоны Сonfluence, структуру документов и примеры описаний для каждого этапа работы аналитика над задачей.

Заключение

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

Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку