Схема как универсальный язык команды ИТ-специалистов
Многие ИТ-специалисты используют схематичные изображения или моделирование для описания различных процессов при создании ИТ-решений. Однако на практике часто встречаются случаи, когда из-за близкого дедлайна или по другой причине блок-схемы, визуальное описание сценариев продукта, алгоритмов – игнорируются. Почему этого делать не стоит и как организовать взаимодействие команды на универсальном языке схем – объясняет аналитик компании IT_ONE Александр Николаюк.
К моделированию – из глубины веков
В общем понимании схемой можно назвать любой рисунок, который моделирует, то есть отображает тот или иной момент нашей действительности и позволяет воссоздать не только изображенное на нем, но и весь происходящий процесс. Возьмем, к примеру, хорошо известный наскальный рисунок первобытных людей, изображающий охоту.
По таким памятникам археологи изучают древний быт, но не только они. Каждый из нас, даже ребенок, глядя на эту живопись, может легко догадаться, как велась охота в то время, – несмотря на то, что у первобытных людей даже не было привычной нам письменности. Перед нами буквально – моделирование процесса.
Перемещаясь в наше время – мы можем легко найти в интернете блок-схему работы калькулятора и сравнить ее со словесным описанием алгоритма работы этого устройства.
В тексте мы сразу увидим большое количество отсылок пунктов друг к другу, витиеватость, которая будет мешать разобраться в сути. А вот на схеме всё выглядит гораздо более упорядоченно и логично.
Уже эти простые примеры показывают, что во многих случаях схема передает описание процесса нагляднее, проще и доступнее, чем текст.
В деятельности ИТ-специалиста схема – это интерпретация буквенного описания в изобразительное, передающее конкретное видение элемента (процесса, алгоритма, проекта) лучше, чем одинокий текст в документе.
Существует много разновидностей (нотаций) схем: функциональное моделирование (IDEF), процессное моделирование (BPMN), sequence диаграммы (формат UML и т. д.), различные ГОСТы и внутренние стандарты, принятые в компании или подразделении. В любом случае они предоставляют участникам взаимодействия – например, проектной команде – некий общий, понятный каждому язык. Разберемся, почему это так важно.
Схемы must have
В процессе разработки многие ИТ-специалисты постоянно сталкиваются с различной документацией (например, к проекту, его отдельному этапу или готовому продукту), вынуждены вести ее и перерабатывать. Часто выраженный в ней смысл не поддается описанию или поддается очень сложно. Не каждый сотрудник, особенно новый участник команды, сможет интерпретировать «голый» текст точно так же, как и его автор.
Поэтому практически всегда полезно представить ту или иную информацию графически: взаимосвязи между компонентами, общий принцип работы процесса или программы и т. д. С помощью графического представления можно гораздо проще объяснить любому участнику проекта, а также коллегам на конференциях, друзьям и даже родственникам, не имеющим технического «бэкграунда», – что за продукт вы разрабатываете. Это универсальный способ общения, который оптимизирует взаимодействия как внутри команды, так и между подразделениями. С помощью графической иллюстрации вы можете заранее ответить на вопросы тех, кто будет работать с вашей документацией.
Более того, схемы помогают наглядно прогнозировать возможные риски или последствия развития продукта. Как показывает практика, зачастую, если какое-то описание подкреплено схематичным рисунком, на нем гораздо проще выявить различные логические разногласия и недочеты, чем в монотонном тексте.
Приведу примеры из личного опыта.
Когда моделирование решает
В начале моего профессионального пути одним из моих первых заданий было описание витрин для новой «песочницы» крупного банка. Тогда это описание сводилось к тому, что в таблице Excel я писал название атрибута, его тип, другие поясняющие поля и источник. В ходе этой работы стало очевидно, что каждый источник имеет первичные источники, а те могут каким-то образом пересекаться. Мне приходилось брать листок и вырисовывать взаимосвязи, потому что до этого в команде не практиковались ERD-, DFD-диаграммы или любые другие вспомогательные схемы. Когда я показал коллегам эти наработки, они подхватили инициативу, начали развивать ее вместе, и в итоге мы стали взаимодействовать намного более слаженно.
Другой кейс связан с моей работой в команде одного из телеком-операторов над проектом Process Mining – технологии визуализации, анализа и оптимизации бизнес-процессов. Коллеги из клиентского сервиса попросили нас визуализировать процесс использования клиентами приложения, голосового бота и колл-центра компании. Благодаря составлению подробных схем мы выяснили некоторые недоработки в UX: например, около 20-30% клиентов путались между различными пунктами голосового бота, не могли найти путь к нужной функции в приложении или при общении с оператором кол-центра часто перенаправлялись от одного специалиста к другому. Мы сделали предположения о причинах этого, доказали свои тезисы с помощью наглядных графиков, подкрепили их статистикой и предложили варианты изменений. Итогом нашей работы стал график перемещения клиентов по всем трем сервисам в виде единой большой схемы. Заказчик был очень доволен, поскольку ранее не использовал для решения своих проблем методы Process Mining, а статистические данные не давали нужной глубины аналитики.
Следующий кейс – из опыта моего коллеги, бизнес-аналитика. Однажды к ним в команду поступил заказ на создание мультивалютных кошельков. Они подготовили текстовое описание этого сервиса, разделили реализацию на команды и разработали первый MVP. Но при его тестировании выяснилось, что продукт не готов к использованию из-за расхождений в общем понимании процессов. Оказалось, что в команде отсутствовал архитектурный план, не было каких-либо схем вообще, и поэтому – не было четкого общего видения итогового продукта. После нескольких обсуждений был составлен коллективный бизнес-процесс с помощью BPMN, отрисованы несколько UML-диаграмм и разработан подробный roadmap реализации. Только после этого работа сдвинулась с места. К сожалению, из-за задержки в самом начале вместо шести запланированных месяцев проект был реализован только через два года.
Делаем выводы
Игнорирование такого инструмента, как схема, в решении ежедневных задач может привести к неожиданным затруднениям, которых легко можно было бы избежать. Не стоит считать создание схем излишними трудозатратами. Схемы практически всегда упрощают повседневные задачи и стандартизируют организационные процессы продукта-проекта-команды. И как итог – это позитивно влияет на Time To Market продукта и другие важнейшие бизнес-показатели.
Даже в случае, когда бизнес-аналитики и руководители договорились о словесном описании некоего алгоритма, максимально выверили его, – у ИТ-специалиста с большой долей вероятности появятся вопросы к этому описанию. Практика показывает, что к схеме (конечно, такой же выверенной и согласованной) вопросов рождается гораздо меньше.
Бывает, что, стараясь не пропустить дедлайн, мы не делаем схем, убеждая себя, что здесь и так всё понятно. Но когда на проект приходит новый сотрудник и ему приходится поднимать эту документацию, – ему уже не будет всё понятно. Сам автор описания в будущем, например, в процессе рефакторинга, глядя на эту документацию, можете упустить какую-то важную деталь. Поэтому визуализированная схема взаимодействия элементов особенно полезна при возвращении к нашим старым выполненным задачам.
Использование схем как части моделирования существенно помогает команде. Схемы упрощают просмотр и понимание взаимосвязей между элементами для разработчиков, архитекторов, руководителей, аналитиков и других специалистов, позволяют сократить трудозатраты непосредственно во время разработки и в перспективе на рефакторинге. Часто команде даже не приходится описывать монотонную документацию из 10 страниц: можно обойтись двумя-тремя схемами.
Моделирование дает возможность унифицировать документацию на предприятии, привести ее к единым корпоративным стандартам. Схема менее, чем текст, подвержена расхождениям, вызванным «авторским видением» проекта или элемента.
Моделирование повышает производительность команды, сокращает время реализации приложений и баз данных, улучшает взаимодействие между разработчиками и командами аналитики, упрощает и ускоряет проектирование процессов. Со схемой гораздо проще, чем с текстовым описанием, работать совместно при обсуждении проекта: передвигать элементы и добиваться их оптимальной взаимосвязи.
Таким образом, схемы становятся не просто инструментом, визуализирующим текстовое описание. Это еще и инструмент взаимодействия – универсальный язык команды.
