Что значит описать систему
Описание системы
Описание системы обусловлено потребностью построения системы, ее исследования и управления. Системы описывают для достижения самых различных целей во всех сферах человеческой деятельности: от искусства до точных наук.
Очевидно, что вначале осуществляется (явно или лишь «в уме») вербальное описание системы, которое представляет собой, как правило, совокупность различных высказываний, интерпретация которых далеко не однозначна. Оно словесное описание может быть развернутым, красочным, всем понятным или кратким, четким с использованием некоего профессионального языка. Но во всех случаях при использовании естественного языка не обеспечивается однозначная трактовка слов и фраз, что достаточно часто служит серьезным препятствием на пути деятельности человека.
Математическое же описание, отражающее наиболее существенные для преследуемых целей свойства, позволяет добиться практически однозначной интерпретации описания системы и использовать богатый арсенал средств математики.
Поскольку под системой 
можно понимать некоторое множество объектов, взаимодействующих в направлении достижения единой для этого множества цели, то в самом общем случае ее целесообразно описывать в виде следующей математической системы
,
где 
— компоненты системы (элементы, подмножества), 
— множество отношений, заданных на этом множестве – математическая структура этой системы.
Использование для описания систем теоретико-множественного языка обусловлено не только лаконичностью записи, но и рядом более существенных причин. Первая из них заключается в преследуемых целях. Чаще всего описание систем используется не для того, чтобы показать, что они из себя представляют в целом, а для исследования их свойств, которые обусловлены определенными взаимосвязями (отношениями) между компонентами системы. Большинство выражаемых словесно фактов представляют собой описание лингвистических отношений, основу которых составляют термы и функторы. Вполне естественно, что их формализмом выступают теоретико-множественные отношения (термы – элементы, функторы – отношения).
На практике такого рода структуры приобретают более «приземленный», иногда называемый «рабочий» вид. Так в работе [41] приводится следующий вид обобщенного формализованного описания системы
– компоненты системы;
– свойства системы;
– связи между компонентами системы;
– цели системы;
– лицо, представляющее объект в виде системы для исследования или принятия решений (для искусственных систем);
– язык наблюдателя, описывающего систему.
Такого рода квазиматематическое описание целесообразно применять в целях некоторой базовой (исходной) структуризации. Можно рекомендовать его реализацию в виде следующей последовательности этапов:
1. Вначале важно установить границы системы, поэтому вначале производят разделение системы и окружающей ее среды. Здесь следует помнить, что в системе действуют законы, вообще говоря, отличные (хоть в чем-то) от законов окружающей ее среды;
2. Далее устанавливаются каналы связи системы со средой (структурирование внешних связей). При этом для выявленных этих связей должны быть описаны проходящие по ним сигналы (что, куда и как идет);
3.Осуществляется содержательное описание системы. В первую очередь это описание выполняемых ею функций, причем функционирование системы должно представляться как нечто целое.
4.Затем формируется внутренняя структура системы, в результате чего должны будут выделены элементы система и связи между ними.
Обратим внимание на включение таких компонентов, как исследователь и его язык . Это обстоятельство подчеркивает субъективный характер описания систем и трудности формализованного описания реальных систем.
Как описать свою ИТ-систему? Советы бывалого автоматизатора
Наш 12 летний опыт работы с клиентами показывает, что даже при наличии хорошо разработанной функциональной ИТ-системы и действительно квалифицированных программистов, эта самая система может быть совершенно не описана, не структурирована и не документирована. А на вопрос — «А какой функциональностью обладает ваша система, как она работает, и где можно её изучить?» — ответить могут только специалисты, которые её разрабатывали. Конечно, если разрабатывали её они не так давно. В противном случае многие вещи просто сотрутся из памяти.
На наш взгляд, описание и документация — это фундамент построения ИТ-системы, который помогает избежать ситуаций, когда она становится «неуправляемым монстром». На практике мы уже сталкивались с такой проблемой — в конце концов ИТ-система перестаёт соответствовать реалиям бизнеса и вызывает необходимость нового проекта по приведению ее в порядок.
Для себя мы выработали некоторую модель описания ИТ-системы, которая должна довольно быстро сформировать представление — что есть в системе, что в ней уже работает, что не работает, какие в ней есть особенности, кто какими частями пользуется, кто за что отвечает.
Надеемся, она окажется полезной и для Вас.
МОДЕЛЬ ОПИСАНИЯ ИТ-СИСТЕМЫ
Рисунок 1. Модель описания ИТ-системы
1.Верхний уровень – это информационная база. Как правило, современные информационные системы даже для средних компаний реализуются набором информационных баз (это может быть ERP-система, система бухучёта, система зарплаты и управления персоналом, система для управления торговлей, система для управления складом и т.д.).
Есть мнение, что всё желательно сделать в одной базе. И мы его не разделяем. Верхний уровень деления на информационные базы позволяет упростить сопровождение информационной системы как раз за счёт того, что она разбивается на части с конкретным набором функций и операций.
2.Подсистема – это нечто крупное, то, что определяет собой относительно самодостаточную предметную область. Это может быть:
Рисунок 2. Описание ИТ-системы на примере подсистемы транспортной логистики
3. В подсистеме есть функции. Если рассматривать как пример подсистему транспортной логистики, то в ней есть функции:
4. Операции находятся внутри функций. Операции — это составляющие элементы функции, каждая из которых подкреплена какой-то функциональностью в ИТ-системе.
Опять же, если вернуться к нашему примеру с транспортной логистикой и рассмотреть функцию формирования маршрутов движения транспорта на день, то операциями здесь будут:
. Отдельно надо отметить, что уровни в описании ИТ-системы на разных этапах развития информационной системы могут меняться местами. То есть операции могут становиться функциями, функции могут становиться подсистемами.
Например, если у компании слабо развита транспортная логистика, то в какой-то момент, подсистема транспортной логистики может стать функцией в рамках подсистемы исполнения заказов покупателя. Получается, что в модели ИТ-системы есть подсистема исполнения заказов покупателя и есть функция транспортной логистики, так как она реализована в минимальной функциональности. А если транспортная логистика начинает расширяться и в ней повышается количество операций, которые агрегированы этой функцией, то уже логично выносить её в масштабы подсистемы.
Таким образом, уровни модели могут изменяться и определяться масштабностью той или иной подсистемы, функции, операции или базы.
ЧТО ДАЁТ ТАКОЕ ОПИСАНИЕ ИТ-СИСТЕМЫ?
На начальном этапе построения ИТ- системы у нас появляется целевой результат в проекте. Мы точно знаем — к чему идти, какую функциональность мы должны реализовать с ИТ-системе.
Описание как раз помогает всем участникам проекта внедрения/развития ИТ-системы фиксировать результат его завершённости.
Мы получаем простой понятный и измеримый результат в проекте. Видим — какие функции и какие операции автоматизированы, а какие — нет.
На практике мы встречаем примеры, когда документация по проекту у клиента довольно полная, но при этом не структурирована, не цельна и описана не системно. К тому же она зачастую раскрывает только пользовательское поведение и не даёт ответов на вопросы об особенностях внутреннего устройства отдельных функций.
Модель описания ИТ-системы (Рисунок 1) как раз позволяет упорядочить и структурировать весь набор инструкции, которые есть по работе с системой. Как следствие, мы довольно быстро ориентируемся в документации и быстро находим всю необходимую нам информацию.
Если мы какую-то функцию или операцию изменяем, то уже точно знаем — какой блок документации нам нужно править.
Любая система в процессе своего внедрения формирует понятный способ передачи на сопровождение. Конечно, при условии, что она описана по определённой структуре.
Если ИТ-система более-менее крупная, то она не передаётся на сопровождение целиком и за раз. Система запускается по операциям, по функциям, по подсистемам.
Как только какая-то из этих функций или подсистем запущена, у нас появляется возможность передать эти участки системы с понятным набором задач на сопровождение, тем самым упрощая его.
У любой системы есть планы по её развитию. И это нормально — всегда хочется от системы получать большего.
// При этом у всех уровней (функций, операций, подсистем) есть статус — либо они находятся в статусе планирования, либо в разработке, либо в опытной промышленной эксплуатации, либо в промышленной эксплуатации.
Во-первых, сами уровни являются некоторыми навигаторами развития нашей системы.
Во-вторых, есть возможность оценивать текущее состояние системы и векторы её развития. Мы должны понимать — куда она развивается, в каком именно месте (какие подсистемы, функции, операции) и в каком состоянии развития находится.
Когда вся информация об ИТ-системе сосредоточена в одном человеке, то это, как минимум, создаёт трудности для него самого. Он чувствует свою ответственность, не может болеть, уходить в отпуск, потому что никто кроме него не понимает — как работает система.
У самой компании появляется от этого исполнителя (а что делать, если этот сотрудник уволится?). Получается, что описание даёт доступ к информации и понимание об устройстве ИТ-системы всем заинтересованным лицам компании. При этом знания не сосредотачиваются в человеке.
ВМЕСТО ЗАКЛЮЧЕНИЯ
Конечно, в небольшой статье мы не опишем все детали и особенности модели описания ИТ-системы.
У В компании у нас есть внутренние документы, регламентирующие описание ИТ-системы с более точными формулировками каждого уровня и с наличием примеров.
Готовы поделиться с вами этой документацией, если у вас есть интерес к структурированному описанию своей ИТ-системы.
Как создать шаблон описания системы и начать его использовать
Когда в IT-компании работают 6 человек, которые пилят одну систему и обсуждают её в кулуарах, описание системы и документация кажутся ненужными. Но когда систем уже более 100, без описания не обойтись. Ведь непродуманное изменение UI может остановить создание заказов. Мы создали единый шаблон описания системы, чтобы документация стала максимально полезной.
Меня зовут Александра Камзеева, я работаю системным аналитиком уже 9 лет, из них 3.5 года в Lamoda. Я много читаю, анализирую текущую документацию и создаю новую. В работе я всегда структурирую информацию и делаю её максимально удобной.
Плюсы хорошего описания системы таковы:
Что такое шаблон и зачем он нужен
Для начала я опишу свое понимание шаблона. Давайте представим, что мне надо найти маленькую машинку в неприбранной комнате. Не факт, что я справлюсь. Зато могу случайно наступить на детальку Лего.
А теперь представим, что все игрушки разложены по своим местам и отсортированы. Я заранее вижу, в каком ящике лежат все машинки, найду нужную быстрее, проще и не буду тратить нервы на это.
Аналогично с документацией. Шаблон – и есть такой порядок. Мы сделали основу для описания системы, которую может использовать любая команда.
В каких условиях мы работаем с документацией
В Lamoda есть более 100 систем, которые автоматизируют доставку заказов, контакт-центр, склад, фотостудию, другие операционные и бизнес-процессы. Разработкой и поддержкой занимаются больше 300 инженеров. Любому из них может понадобиться описание любой из этих 100 систем.
Каждая команда самостоятельно описывает свою систему в отдельном спейсе в Confluence. В документировании обязательно участвует техлид, потому что он обязан фиксировать информацию. Также систему описывают активные тестировщики и разработчики, которым жалко просто так потерять полученные знания. И естественно, аналитики, поскольку документация – один из наших главных инструментов.
Может показаться, что эта свобода приводит к хаосу. Но это не так, потому что у нас есть культура компании: ответственное отношение к документации, открытый шаринг знаний, привычка фиксировать артефакты проекта и системы. Эта традиция сложилась отчасти благодаря неуспешным проектам. Инциденты доказали командам разработки, насколько важно документировать процессы и функциональность системы.
Ниже я расскажу несколько случаев, когда запутанная документация или ее отсутствие приводили к проблемам.
Просто добавь две кнопки
Первая проблема, которая подтолкнула нас к созданию шаблона – у нас не было описания некоторых систем, что приводило к сбоям и доработкам.
У нас был проект Self Order Management (SOM). Мы решили добавить в личный кабинет клиента две кнопки: «Перенос даты доставки» и «Отмена заказа». До этого клиент мог отменить или перенести заказ только звонком в контакт-центр. Понятно, что у некоторых покупателей не было времени или желания общаться с оператором. В итоге торговый представитель мог привезти ненужный заказ или не застать клиента дома. В таких случаях Lamoda несет издержки. Проект был нужный и важный.
Казалось бы, добавить две кнопочки! На самом деле, за ними скрывалось много логики в четырех системах. Изменение заказа проходит через систему процессинга – огромный монолит, где можно тронуть что-то в одном месте, а выстрелит в другом. К сожалению, тонкости её работы не были описаны в документации, на это не обратили внимания во время проектирования проекта. После релиза кнопки работали не так, как ожидалось, и его откатили обратно. В итоге вместо двух человеко-месяцев на этот проект ушло полгода.
Конечно, мы получили такой результат не только из-за отсутствия документации. Но если бы у нас существовало понятное описание процессов отмены и переноса заказа, то, возможно, исход был бы другим.
Вторая проблема, которая подвела нас к созданию шаблона – это сложности онбординга. Я пришла работать в команду, которая занималась системой процессинга заказов. Для погружения я читала документацию в спейсе системы и в трех разделах обнаружила три разных описания основной сущности нашей системы – статуса заказа.
В этом случае не получилось сделать онбординг легче. Такая документация не помогала передать знания коллегам, которые не сталкивались с нашей системой ранее.
Проблема чистого листа
Третья предпосылка к созданию шаблона – проблема чистого листа. Для каждой новой системы техлид должен сделать с нуля соответствующий спейс. Техлид думает, какие разделы стоит завести. До создания шаблона сотрудник изучал другие спейсы и смотрел, какие разделы используются и будут полезными для его системы. Раньше на это уходило много времени.
Как мы создавали шаблон и что получилось
Каждую неделю системные аналитики проводят стендап и обсуждают вопросы, которые встречаются на проектах и не только. И не раз коллеги жаловались, как сложно найти информацию и разобраться в спейсах различных систем. Поскольку у нас постоянно пригорало из-за этого, мы решили взять в свои руки описание систем, к которым мы прикреплены. А дальше будет видно, что делать.
Сначала мы определили признаки хорошего шаблона:
В разделе проектов и фич лежали спецификации для разработки проектов. В разделах Development и QA находилась специфическая информация для разработки и тестировщиков. В разделе инцидентов были описаны происшествия, которые возникали в системе, и их решения.
Мы поделились идеей шаблона с другими коллегами на неформальных встречах (обеды на кухне, стенд-апы, команды-соседи, с которыми периодически разговариваешь) и создали рабочую группу добровольцев. Ими были представители разных компетенций: два менеджера, три техлида и два тестировщика. Они добавили в шаблон следующие разделы:
Далее мы проверили шаблон описания систем с коллегами с широкой компетенцией: руководителями IT-подразделений, опытными техлидами и тестлидами больших интеграционных проектов. В итоге они добавили еще немного полезных разделов:
Проверяем качество шаблона
Полученный документ мы проверили на наше определение хорошего шаблона в Lamoda:
Самые полезные разделы шаблона
Мы сделали хороший шаблон, подходящий для описания систем Lamoda. Надеюсь, он будет полезен и другим компаниям. Особенно хочу выделить следующие три раздела:
Описание основных процессов системы. Да, кажется очевидным, что этот раздел нужен. Но почему-то он не всегда существует, как было у нас на примере с кнопочками отмены и переноса заказа. Если бы мы заранее описали процессы отмены и переноса заказа, уменьшился бы риск провала проекта.
Чек-листы – раздел, который напоминает о самом важном в регулярном процессе. Например, у нас есть “Чек-лист подключения нового метода оплаты” в описании системы управления методами оплаты. Там прописано, что мы должны согласовывать добавление или изменение метода оплаты с бухгалтерией, с контакт-центром, с доставкой и с другими бизнес-подразделениями.
Однажды мы забыли сообщить контакт-центру об изменениях метода оплаты. И когда клиент позвонил в наш контакт-центр и спросил об этом, оператор ничего не смог сказать. Это привело к конфликту между контакт-центром и командой разработки, отвечающей за методы оплаты. После этого случая мы заводим чек-листы для ключевых запусков проектов, подключения новых партнеров и т.д.
Домашняя страница спейса – раздел с информацией о том, зачем эта система нужна, о составе команды и стейкхолдере. Мы должны согласовывать изменения систем и ресурсы на разработку со стейкхолдером. Поэтому здорово, когда эту информацию можно получить, просто заглянув в Confluence.
Тут же мы указываем информацию о составе команды, чтобы понимать, к кому обратиться с вопросами о системе. Это помогает и новичкам с распухшей головой. Здорово, когда новый сотрудник может подглядеть, с кем он только что разговаривал, кто этот человек, какая у него роль и как его зовут.
Как я начала использовать шаблон в своей системе
Вторая кучка – это нужное, но неактуальное. Мы помечали страницы как неактуальные, заводили задачу в Jira и дальше актуализировали эту информацию в соответствии с нашим бэклогом.
Третья кучка самая простая. Когда все понятно, разделы актуальные – мы просто переносили их в нужное место.
До этих встреч по всему спейсу были хаотично разбросаны описания процессов и архитектуры, записки тестировщиков и разработчиков, инциденты. Также не было домашней страницы.
За 6 часов встреч мы получили отличный результат. Из хаоса у нас образовались структура и порядок. Теперь в ней можно понять, где найти описание процессов, информацию об архитектуре и об инцидентах. И что немаловажно, у нас появилась домашняя страница. Здесь было написано, зачем нужна система процессинга заказа и кто её стейкхолдер.
Наша большая система участвует почти во всех бизнес-направлениях. Но собственного стейкхолдера у нас раньше не было. Пока мы делали home page, обсудили с CTO, с кем согласовывать изменения системы. Таким образом, определился коллега, который приоритезировал доработки. Теперь это выглядит забавным фактом, что создание домашней страницы привело к появлению стейкхолдера.
Как мы распространяли шаблон
Похожие результаты по использованию шаблона получили другие аналитики, которые внедряли его в своих направлениях. Таким образом, мы покрыли большую часть систем, которые принимали активное участие во многих интеграционных проектах.
У нас были команды, чьи системы часто были задействованы в интеграционных проектах, но описания о них не хватало. Там обычно чувствовалась необходимость в документации, поэтому продавать идею не пришлось.
Мы показывали успешный опыт применения шаблонов техлидам и менеджерам таких команд. Некоторые команды на основе нашего примера самостоятельно приводили в порядок свою документацию, другие просили помощи аналитиков.
Обратная связь о шаблоне
Наш шаблон не является принудительным или обязательным описанием системы. Коллеги берут шаблон за основу, если у них есть в нем потребность, и редактируют под свои нужды. Например, выносят обмены из подраздела в раздел, если система в основном состоит из них.
Все наши системы отличаются в описании, но общая структура и общая логика все равно сохраняются. Теперь мы легче находим информацию о том, из каких процессов состоит система, об архитектуре системы и так далее.
Мы в Lamoda любим обмениваться знаниями. У нас есть большие интеграционные проекты, которые мотивируют на это. Мы высылаем ссылки на актуальное описание систем, и коллеги получают нужную информацию без дополнительных вопросов и так загруженным техлидам.
Спустя 2 года после создания шаблона я опросила коллег и получила у большинства хорошую обратную связь. Они используют шаблон, редактируя структуру так, как им нужно.
Но есть и люди, считающие, что нам не нужна документация и шаблон. В основном, так рассуждают команды тех систем, в которых сейчас нет острой необходимости что-то документировать.
Они работают над системами, которые почти не изменяются: нет интеграционных проектов, нет необходимости рассказывать про эти системы другим коллегам, соответственно, нет желания документировать.
Я думаю, перед началом большого проекта наша культура и набитые шишки напомнят о необходимости документировать основные процессы, и они поменяют мнение.