Валерий Валерьевич Комсков

Введение в профессию бизнес-аналитика: отправная точка для приобретения опыта

© Комсков В.В., текст, 2025

© Оформление. ООО «Издательство «Эксмо», 2025

От автора

В книгах вроде «“Название профессии” пособие для начинающих» обычно много написано о том, как долго автор к ней шел, сколько статей написал, в каком университете преподавал и т. д. Так вот, ничего подобного у меня не было. Два года назад я не только не планировал, что буду писать эту книгу, но даже и не думал об этом. Но так получилось, что ко мне обратились две очаровательные девушки с просьбой научить их бизнес-анализу, поскольку на тот момент я был старшим бизнес-аналитиком нефтяной компании «Роснефть» и имел большой опыт работы в профессии в российских и зарубежной компаниях. По итогу я все зафейлил, собрав все преподавательские грабли, какие только было можно. Выяснилось, что нормальной литературы по профессии просто нет: она или в общих чертах рассказывает о том, чем занимаются бизнес-аналитики, какими они бывают и т. п., или рассчитана на тех, кто уже работает в этой области и понимает, что конкретно изучает этот специалист. Девушки, которые попросили меня научить их бизнес-анализу, были не только очаровательными, они оказались еще и крутыми преподавателями в своих сферах, причем со знанием и опытом не только из отечественного высшего образования. Поэтому родилась мысль исправить эту ситуацию, написав книгу и создав курс «Бизнес-аналитик». За время написания я успел побывать руководителем команд, которые разрабатывали и сопровождали несколько информационных систем федерального значения, и запустить собственный стартап в сфере финтеха. Это позволило добавить в книгу информацию по hard и soft skills, которые я ожидал увидеть от кандидатов на позицию бизнес-аналитика уровня джуниор. По возможности развернуто я разобрал проблемы, возникающие у новых сотрудников при вводе их в должности.

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

Благодарности

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

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

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

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

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

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

С уважением, Валерий Комсков

Кто такой бизнес-аналитик?

«…если бы среди философов установилось согласие относительно значения слов, то почти все их споры были бы прекращены»

Рене Декарт, XVII век

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

Но даже если мы возьмем конкретно бизнес-аналитиков, то выяснится, что есть два их вида:

• обычный (не IT) бизнес-аналитик – тот, кто работает в контексте бизнеса в целом. Такой специалист участвует в совершенствовании процессов, оптимизации издержек и т. д;

• бизнес-аналитик в IT – тот, чья работа происходит в рамках отдельных IT-проектов – закупки, внедрения, внесение изменений и т. д. Его задача – взаимодействие с заинтересованными лицами со стороны заказчика (бизнес-пользователи, технический персонал и т. д.) для сбора требований, исходящих от бизнеса.

При этом IT – крайне снобистская сфера, и за пределами крупных корпораций о бизнес-аналитиках не из IT обычно никто не знает.

В то же время в отрасли нет четкого разделения на «бизнес-» и «системных» аналитиков. В каждой компании (а подчас и в отдельных командах внутри одной компании) границы их компетенций сильно размыты, вплоть до того, что зачастую на проекте вообще нет системного аналитика, а его обязанности распределены между бизнес-аналитиком и разработчиками. И это не российская особенность: в мире также нет единого однозначного определения, достаточно почитать формулировку из библии бизнес-аналитиков BABOK.

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

Говорят, девизом IBM в стародавние времена было утверждение: «мы продаем нашим заказчикам не то, что они хотят, а то, что им нужно». Уж не знаю, насколько это правда, но формулировка весьма показательна. Со временем, когда вы наберетесь опыта, вам нужно будет следовать этому девизу.

Атмосферная часть закончилась, далее информация в книге будет гораздо более структурированной. Ну а чтобы вы знали, что ответить на собеседовании на этот вопрос, просто выучите определение из BABOK, который не просто так называется «Руководство к своду знаний по бизнес-анализу»®.

Основы разработки ПО

Роли в команде

Менеджер проекта (Project manager)

Проект – это временное предприятие, направленное на создание уникального продукта, услуги или результата.

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

Менеджер релизов – в реалиях российских Enterprise-компаний так называются руководители команд, управляющие процессом, когда IT-продукт из проекта уже превратился в сервис, но находится на доработке согласно запросам на изменения (ЗИ).

Менеджер продукта (Product manager)

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

Эти роли различаются тем, что product manager придумывает новые функции, которые можно добавить в продукт, а project manager ставит задачу подчиненным реализовать эти новые функции и сообщает о сроках, когда они будут готовы. Product manager решает, что сделать, project manager – когда и как.

Архитектор (Architect)

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

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

Архитектура предприятия / корпоративная архитектура (Enterprise Architecture) – высокоуровневая архитектура всего предприятия, покрывающая бизнес-потребности IT-способностями. Корпоративная архитектура фокусируется на определении потоков и бизнес-процессов, действий, функций, информации, данных и технологий предприятия, а также на вызовах, стоящих перед IT и необходимых для того, чтобы эффективно применить технологию в ответ на изменение бизнес-потребностей.

Бизнес-архитектура (Business Architecture) описывает все бизнес-процессы, бизнес-акторы, бизнес-сущности и бизнес-правила с точки зрения бизнеса. Бизнес-архитектура не зависит от применяемых в разработке технологий.

Информационная архитектура (Information Architecture) определяет структуры данных и описывает все потоки данных, которые используются для поддержки бизнес-архитектуры. Такие операции, как идентификация, систематизация, категоризация, хранение данных, относятся к информационной архитектуре. Может представляться в виде модели данных (Data Model).

Архитектура решения (Solution Architecture) – архитектура программного обеспечения (ПО), которое реализует функции бизнес-архитектуры.

Технологическая архитектура (Technology Architecture) описывает архитектуру IT-окружения, которое используется для поддержки информационной архитектуры и архитектуры решения.

Системная архитектура (System Architeture) – представление системы, которое показывает реализацию функциональных возможностей аппаратными средствами и компонентами ПО, устанавливает связь архитектуры программного обеспечения и архитектуры аппаратных средств, а также регламентирует взаимодействие пользователя с этими компонентами.

Архитектура ПО (Application Architecture) – составная часть системной архитектуры. Описывает организацию системы с точки зрения программных компонентов, из которых она состоит, и связи между компонентами.

Архитектура данных (Data Architecture) – составная часть системной архитектуры. Описывает структуры данных и логические связи между ними.

Каждым из видов архитектуры занимается соответствующий архитектор.

Бизнес-архитектор (Enterprise Architect) отвечает за то, чтобы бизнес-стратегия компании использовала правильную архитектуру технологических систем для достижения своих целей. EA несут огромную ответственность и, как правило, подчиняются непосредственно директору по информационным технологиям (CIO). Они должны идти в ногу с последними тенденциями в технологиях и определять, подходят ли технологии для компании. EA берет бизнес-стратегию компании и описывает архитектуру технологических систем, которая будет необходима для поддержания этой стратегии. Архитекторы уровня enterprise ориентируются на бизнес-потребности, придумывают, как решить какую-либо бизнес-задачу, разрабатывают глобальный план работы приложения и алгоритм его взаимодействия с другими. EA должен представлять, как все приложения работают вместе, иметь всю информацию. Он принимает концептуальные решения.

Архитектор решений (Solution Architect). Если EA решает, что делать, то SA – как делать.

Архитектор решений отвечает за разработку одного или нескольких приложений или сервисов в организации. Решает проблему, которую определил бизнес:

• как технологии могут быть использованы для решения бизнес-проблемы;

• какую платформу или стек технологий можно использовать для создания решения;

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

• как вещи будут масштабироваться и поддерживаться.

Архитектор решений часто работает под методическим руководством бизнес-архитектора.

Technical (software) Architect – техлид в обычных реалиях. Это технический эксперт, который пытается решать проблемы, поставленные SA-архитектором. TA ставит задачи разработчикам и занимается уровнем реализации конкретной системы. На уровне конкретной информационной системы определяет стек технологий этой системы, сервисы, подходы к разработке, выбирает БД и интерфейсы для взаимодействий с другими системами.

Аналитик (Analyst)

Бизнес-аналитик (Business Analyst) описывает бизнес-процессы, как они есть (as is), и, общаясь с заказчиком и заинтересованными сторонами, составляет предложение, какими они должны быть (to be), чтобы решить задачи бизнеса (достичь целей).

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

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

Продуктовый аналитик (Product Analyst) – мостик между бизнесом и данными. Он работает рука об руку с менеджером продукта и помогает продуктовой команде принимать верные решения.

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

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

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

Таким образом, продуктовый аналитик работает с данными, изучает метрики, строит воронки и следит за тем, к каким результатам приводит малейшее изменение продукта.

Дизайнер (Designer)

User Experience (UX) – это путь клиента от точки входа до точки выхода. То, насколько клиенту удобно, например, заполнить на сайте заявку на кредит. Отвечает за функциональность.

User Interface (UI) – это вид интерфейса. Отвечает за статику.

UX-дизайнер – это проектировщик, который изучает потребности пользователей, строит логические схемы работы интерфейса, тестирует прототипы на целевой аудитории и составляет ТЗ для UI-дизайнера.

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

Специалист по информационной безопасности (Application security)

Анализирует приложение с точки зрения информационной безопасности: определяет требования к приложениям и проверяет реализацию на соответствие этим требованиям. Занимается поиском и анализом уязвимостей.

Разработчик (Developer)

Если говорить о веб-приложении, frontend-разработчик занимается клиентской стороной интерфейса, отвечает за вывод информации для пользователя. Backend-разработчик занят серверной разработкой – тем, чего не видит пользователь, реализацией бизнес-логики приложения. Fullstack – человек, который объединяет в себе обязанности front и back (они тесно связаны).

Пример

Вы выбираете рейс из Нью-Йорка в Гонконг. Вы находитесь в зоне frontend. Нажмите клавишу поиска, и вы переместитесь в зону backend, чтобы вам могли правильно вернуть лучший, самый короткий и дешевый рейс в мгновение ока. Как только отобразятся результаты, вы снова окажетесь в зоне frontend.

Отдельно выделены gamedev-разработчики (разработчики игр) и iOS/Android-разработчики – группы разработчиков под эти ОС.

1С/SAP-разработчики и так далее – разработчики на определенном коробочном решении. Такие решения закупаются фирмой и дорабатываются под ее нужды, здесь имеются специализированный язык и свои инструменты.

Тестировщик (QA Engineer)

Есть несколько видов тестирования. Соответственно, разные его виды выполняют разные тестировщики.

➤ По отношению к объекту тестирования.

1. Функциональное. Тестирование конкретной функциональности, которая была разработана в соответствии с требованиями.

2. Безопасности. Проверка разработанного продукта на соответствие требованиям безопасности, имитация атаки или несанкционированных действий.

3. Производительности. Стресс-тестирование, тестирование нагрузки, стабильности.

➤ По доступу к коду.

1. Тестирование черного ящика в том случае, когда мы не знаем алгоритмы.

2. Тестирование белого ящика в том случае, когда учитываются механизмы системы внутри.

3. Тестирование серого ящика – комбинация первого и второго.

➤ По степени автоматизации.

1. Ручное – тест-кейсы.

2. Автотестирование – специально написанный код для автоматизации проверки определенного кейса.

➤ По степени изолированности компонента

1. Модульное – тестирование определенных модулей системы (компонентов).

2. Интеграционное – тестирование взаимодействия модулей.

3. Тестирование системы в целом (полной системы).

Техническая поддержка (Tech Support)

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

Level 1/2/3 support – несколько уровней поддержки приложения по степени знания системы.

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

Level 1 support принимает входящие сообщения заказчиков, отвечает на звонки и письма клиента. Идентифицирует клиента, локализует проблему, обычно следует сценарию. Если может, помогает клиенту на своем уровне. Если отсутствуют даже обходные пути, вопрос передается на следующий уровень поддержки.

Level 2 support – это технические специалисты с более продвинутыми навыками общего или специализированного назначения. Тут происходит систематизация, анализ и решение проблем.

Обязанности специалистов второго уровня:

• контакт с персоналом первой линии и помощь ему;

• фиксация и последующий анализ инцидента;

• решение проблемы;

• передача данных по решенной проблеме на первый уровень.

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

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

Жизненный цикл ПО

Жизненный цикл ПО (SDLC, Software Development Life Cycle) – период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации.

SDLC – это основные этапы, через которые проходит любой программный продукт. Плюс-минус всегда имеют место следующие этапы.

1. Фаза планирования.

2. Фаза сбора требований/анализа.

3. Фаза дизайна/проектирования.

4. Фаза разработки.

5. Фаза тестирования.

6. Фаза внедрения.

7. Фаза поддержки.

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

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

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

Поэтому хотелось бы отметить, что для продукта и проекта этапы ЖЦ могут отличаться. Это стоит понимать и учитывать.

Жизненный цикл проекта

Любой ЖЦ проекта включает в себя четыре фазы.

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

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

3. Выполнение работ. Это фаза создания проекта. Именно на этом этапе создается продукт. Менеджер проекта получает отчеты о ходе выполнения проекта и контролирует процесс. Далее происходит финальное одобрение продукта перед подписанием акта приема работ.

4. Финальная стадия. Основная суть этой фазы – подвести итоги после завершения проекта, подписать акт приема-передачи и передать продукт в операционную деятельность.

На графике показано, как в зависимости от стадии проекта меняются такие показатели, как:

• стоимость проекта и численность персоналом – вовлеченность ресурсов (кривая 1);

• влияние заинтересованных сторон, неопределенность проекта, возможность рисков (кривая 2);

• стоимость изменений по проекту (кривая 3).

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

Пример

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

2. Максимальные затраты ресурсов в проекте наблюдаются в период его выполнения (ближе к концу). Это связано с тем, что к этому времени большинство спорных моментов проекта уже прояснилось, команда знает, что делать, и активно работает. Также именно на этих этапах во многих проектах возникает понимание того, что команда опаздывает, и подключаются все возможные ресурсы для работы.

Этап планирования

На этой стадии нужно максимально снизить неопределенность.

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

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

• рассмотреть варианты альтернативных решений на встречах с клиентами, поставщиками, консультантами и сотрудниками;

• понять, как сделать ваш продукт лучше, чем у конкурентов;

• провести анализ осуществимости (feasibility study), направленный на изучение возможности создания продукта в соответствии с заданными требованиями заказчика и выделенными ресурсами.

Ведущую роль в разработке концепции играет бизнес-аналитик (или Product Manager), занимающийся этим продуктом. Для определения потребностей заказчика/рынка в течение всего срока разработки концепции проводится интенсивная работа с инвестором проекта, чтобы выработать единое ви´дение будущего продукта. Если это заказной продукт, то инвестор – конечный заказчик. Если продукт предназначен для открытого рынка, то ответственны за него учредители компании или совет директоров. Далее на основе изученных и систематизированных требований аналитик вместе с командой экспертов создает образ будущего продукта. В конце аналитик и экспертная команда определяют границы проекта, которые должны содержать ориентировочные сроки реализации и бюджет продукта.

Результатом разработки концепции является Product Vision Document (если продукт разрабатывается под заказ) или Marketing Requirement Document (если продукт предназначен для открытого рынка). Эти документы содержат подробную информацию о требованиях заказчика, возможностях продукта, которые должны удовлетворять эти требования, а также ориентировочные сроки его реализации и бюджет. Различие между PVD и MRD состоит в том, что в MRD обычно более детально описаны целевые сегменты рынка и сделан детальный обзор конкурентов.

После разработки концепции продукта делается вывод о целесообразности создания продукта. Если принято положительное решение, пишется устав проекта по разработке продукта. PVD/MRD – входной документ устава проекта, описывающий содержание работ.

Входы: идея, концепция, экономическое обоснование.

Выходы: устав проекта, дорожная карта работ проекта, план управления рисками, список заинтересованных сторон, ресурсный план, план по тестированию.

Этап анализа требований

На этом этапе нужно четко определить и задокументировать требования к продукту и утвердить их.

Входы: реестр заинтересованных лиц, дорожная карта.

Выходы: техническое задание.

Этап проектирования

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

Входы: техническое задание.

Выходы: архитектурное решение, спецификация требований к ПО, дизайн-макеты, тест-кейсы.

Этап разработки

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

Входы: архитектурное решение, спецификация требований к ПО, дизайн-макеты, тест-кейсы.

Выходы: работающая версия ПО, готовая к тестам.

Этап тестирования

На этом этапе проверяется работоспособность системы.

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

Входы: тест-кейсы, версия ПО.

Выходы: отчет о тестировании, баг-репорты.

Этап внедрения и поддержки

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

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

Входы:

• консультирование пользователей;

• исправление дефектов;

• доработка в соответствии с новыми требованиями.

Выходы:

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

• пользовательская документация.

Стандарты жизненного цикла ПО

ГОСТ Р ИСО/МЭК 12207–2010

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

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

➤ Процессы соглашения

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

➤ Процессы организационного обеспечения проекта

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

Процессы организационного обеспечения проекта:

• процесс менеджмента модели жизненного цикла;

• процесс менеджмента инфраструктуры;

• процесс менеджмента портфеля проектов;

• процесс менеджмента людских ресурсов;

• процесс менеджмента качества.

➤ Процессы проекта

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

Существуют две категории процессов проекта.

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

• Процессы поддержки проекта обеспечивают выполнение специализированных целей менеджмента.

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

• планирование проекта;

• управление проектом и его оценка.

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

• менеджмент решений;

• менеджмент рисков;

• менеджмент конфигурации;

• менеджмент информации;

• измерения.

➤ Технические процессы

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

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

Технические процессы:

• определение требований правообладателей;

• анализ системных требований;

• проектирование архитектуры системы;

• реализация;

• комплексирование системы;

• квалификационное тестирование системы;

• инсталляция программных средств;

• поддержка приемки программных средств;

• функционирование программных средств;

• сопровождение программных средств;

• изъятие программных средств из обращения.

➤ Процессы реализации программных средств

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

➤ Процессы поддержки программных средств

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

➤ Процессы повторного применения программных средств

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

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

Ограничения

• Не детализирует процессы жизненного цикла в разрезе методов и процедур.

• Не устанавливает требований к документации.

• Не предписывает четких и однозначных схем построения жизненного цикла ПО.

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

Каждая организация сама несет ответственность за выбор!

ГОСТ 34.601–90

Стандарт предусматривает следующие стадии и этапы создания автоматизированной системы (АС):

1. Формирование требований к АС:

a. Обследование объекта и обоснование необходимости создания АС;

b. Формирование требований пользователя к АС;

c. Оформление отчета о выполнении работ и заявки на разработку АС.

2. Разработка концепции АС:

a. Изучение объекта;

b. Проведение необходимых научно-исследовательских работ;

c. Разработка вариантов концепции АС и выбор варианта, удовлетворяющего требованиям пользователей;

d. Оформление отчета о проделанной работе.

3. Техническое задание:

a. Разработка и утверждение технического задания на создание АС.

4. Эскизный проект:

a. Разработка предварительных проектных решений по системе и ее частям;

b. Разработка документации на АС и ее части.

5. Технический проект:

a. Разработка проектных решений по системе и ее частям;

b. Разработка документации на АС и ее части;

c. Разработка и оформление документации на поставку комплектующих изделий;

d. Разработка заданий на проектирование в смежных частях проекта.

6. Рабочая документация:

a. Разработка рабочей документации на АС и ее части;

b. Разработка и адаптация программ.

7. Ввод в действие:

a. Подготовка объекта автоматизации;

b. Подготовка персонала;

c. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);

d. Строительно-монтажные работы;

e. Пусконаладочные работы;

f. Проведение предварительных испытаний;

g. Проведение опытной эксплуатации;

h. Проведение приемочных испытаний.

8. Тестирование АС.

9. Сопровождение АС:

a. Выполнение работ в соответствии с гарантийными обязательствами;

b. Послегарантийное обслуживание.

Эскизный, технический проекты и рабочая документация – это последовательное построение все более точных проектных решений. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.

Модели разработки ПО

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

Классические модели разработки

Модель кодирования и устранения ошибок

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

1. Постановка задачи.

2. Создание программы.

3. Тестирование.

4. Анализ результатов тестирования и возможный переход к шагу 1.

Эта модель совсем не актуальна для профессиональной разработки ПО. По таким алгоритмам программисты работали 50–60 лет назад. Излишняя простота в этом случае не позволяет конкурировать с другими моделями.

Каскадная модель или Waterfall

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

В конце каждого этапа создается документация, которая служит входными данными для следующего этапа.

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

2. Анализ требований. Требования анализируются, детализируются, уточняются, обсуждаются, документируются (формируем требования к ПО).

3. Проектирование. Проектируются и согласовываются логика работы ПО и требования к дизайну; выбираются инструменты разработки. На выходе получаем документы, подробно описывающие для программистов способ и план реализации указанных требований.

4. Разработка. Реализация.

5. Тестирование. Проверка.

6. Внедрение, поддержка. Вывод в промышленную эксплуатацию и перевод на поддержку.

Когда можно использовать каскадную модель:

• для средних и больших проектов, в которых задействованы десятки программистов и несколько разных команд проекта;

• для проектов, в которых требования и границы прозрачны и точно известны в начале жизненного цикла проекта. То есть когда проект понятен и прост.

«Водопад» подходит для разработки проектов в медицинской и космической отраслях, где уже сформирована обширная база документов (СНиПов и спецификаций), на основе которых можно написать требования к новому ПО.

Любая стройка – это пример использования «Водопада» (кейс – проект – стройка – приемка). Также в качестве примера подходит автомобильный конвейер.

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

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

Каскадная модель с обратной связью

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

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

Каскадная модель с промежуточным контролем

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

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

Модель обладает следующими характеристиками взаимодействия этапов:

• модель состоит из последовательно расположенных этапов (точно так же, как и «Водопад»);

• каждый этап имеет обратную связь с предыдущими;

• исправление ошибок происходит на каждом из этапов сразу при выявлении проблемы – производится промежуточный контроль;

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

• результат появляется только в конце разработки, как и в модели «Водопад».

Инкрементная (инкрементальная) модель разработки

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

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

Мы получаем несколько циклов разработки – своеобразный «мультиводопад». Каждый цикл делится на модули, а каждый модуль – на фазы: определение требований, проектирование, написание кода, внедрение, тестирование.

Когда можно использовать инкрементную модель:

• для проектов, в которых точное техническое задание прописано уже на старте, а продукт должен быстро выйти на рынок.

Итеративная модель разработки

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

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

Когда можно использовать итеративную модель:

• когда важен анализ рисков и затрат;

• в крупных долгосрочных проектах с отсутствием четких требований или вероятностью их динамического изменения;

• при разработке новой линейки продуктов.

На рисунке показана итерационная «разработка» Моны Лизы. Как видно, в первой итерации есть лишь набросок Джоконды, во второй появляются цвета, в третьей добавляются детали и насыщенность, и процесс завершается. В инкрементной же модели функционал продукта наращивается по кусочкам, и продукт составляется из частей. В отличие от итерационной модели, здесь каждый кусочек – целостный элемент.

V-модель разработки

Еще она называется Verification and Validation model – модель верификации и валидации. Это усовершенствованная каскадная модель, в которой заказчик и команда программистов одновременно составляют требования к системе и описывают, как будут тестировать ее на каждом этапе. V-модель разработки унаследовала структуру «шаг за шагом» от каскадной модели.

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

Спиральная модель

Ее начали использовать в 1988 году. Спиральная модель воплощает в себе преимущества каскадной модели. При этом в нее включен анализ рисков и предусмотрена разработка проекта посредством прототипирования.

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

Главные фазы:

1. определение целей, альтернатив, ограничений;

2. анализ, определение и разрешение рисков;

3. фаза разработки и тестирования;

4. планирование новой итерации.

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

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

Главная особенность спиральной модели – концентрация на возможных рисках. Для их оценки даже выделена соответствующая стадия. Эта модель часто используется в исследовательских проектах и проектах с высокими рисками.

RUP (Rational Unified Process)

Это уже не модель, а методология разработки.

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

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

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

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

Цели каждой фазы:

• Inception (начальная стадия) – понимание того, что мы создаем. Фаза сбора информации и анализа требований, определение образа проекта в целом;

• Elaboration (Уточнение) – понимание того, как мы это создаем. Фаза анализа требований и проектирования системы, планирование необходимых действий и ресурсов, спецификация функций и особенностей дизайна;

• Construction (конструирование) – создание бета-версии продукта. Основная фаза разработки и кодирования, построение продукта как восходящей последовательности итераций (версий кода);

• Transition (внедрение) – создание конечной версии продукта. Фаза внедрения продукта, поставка продукта конкретному пользователю.

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

Методология RUP основана на девяти основных потоках (workflow) – элементах итерации жизненного цикла ПО.

1. Business modeling (бизнес-анализ) – анализ требований на данной итерации жизненного цикла, определение желаемых параметров системы и нужд пользователей.

2. Requirements (требования) – формализация образа системы. Предполагает сбор требований и управление требованиями, перевод требований в функциональные спецификации. Здесь начинается анализ прецедентов и построение use cases, формально отображающих требования пользователя в UML. В результате мы получаем документы уровня менеджмента.

3. Analysis and design (анализ и моделирование) – перевод собранных требований в формализованную программную модель. Результат – описание системы на этапе реализации (технический проект); эти документы относятся к уровню разработчиков системы. Язык формализации – Unified Modelling Language (UML). В процессе итеративной разработки эволюционировать будет продукт именно этого потока – модель проекта. Все изменения привязываются в RUP непосредственно к моделям, а средства автоматизации и довольно гибкий язык моделирования позволяют управлять данным процессом более или менее безболезненно в плане затрат времени и ресурсов.

4. Implementation (реализация, кодирование) – собственно написание кода.

5. Test (тестирование) – тестирование продукта на данной итерации.

6. Deployment (внедрение) – установка продукта на полигоне заказчика, подготовка персонала, запуск системы и приемо-сдаточные испытания, подготовка стандартов упаковки и распространения продукта, передача материалов отделу продаж (действия опциональны в зависимости от специфики продукта).

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

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

Также здесь есть элементы, касающиеся поддержки продукта, – core supporting workflows.

1. Management (управление проектом) – набор административных действий по управлению проектом согласно идеологии RUP. Использует средства управления проектом (см. ниже список продуктов Rational).

2. Configuration management (управление конфигурацией и изменениями) – мощный слой административных действий, направленных на управление версиями продукта. Предполагает контроль исходного кода (модели, исполняемых модулей, тестов, документации), контроль версий продукта, использование корпоративных стандартов разработки кода и документации, отслеживание изменений и ошибок (bug tracking). Тесно связан с тестированием и поддержкой пользователей (customers support).

3. Environment (окружение) – создание и поддержка средств анализа, проектирования, разработки, тестирования (как программное, так и аппаратное обеспечение).

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

Гибкие модели управления командой Agile и Kanban

Что такое Agile

С английского agile переводится как «подвижный, быстрый, проворный». В русской IT-лексике за этой группой методологий закрепилось определение «гибкие».

В Agile-подходе проект постоянно адаптируется к новым обстоятельствам и требованиям. Вспомним, как устроена разработка по методологии Waterfall.

1. Выдвигаются требования к ПО, разрабатывается техническое задание (ТЗ).

2. Поставленные задачи воплощаются в коде.

3. Выполняется тестирование.

4. Готовое ПО внедряется в работу.

Теоретически в Waterfall возможен возврат на предыдущие ступени – например, если оказывается, что ту или иную задачу невозможно выполнить по техническим причинам. В этом случае ТЗ пересматривают, но это скорее чрезвычайная ситуация. В норме конечный продукт должен идеально соответствовать требованиям, целям и задачам, которые были сформулированы до разработки.

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

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

Идеи и принципы

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

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

1. Люди и взаимодействие между ними важнее, чем процессы и инструменты.

2. Работающее ПО важнее, чем исчерпывающая документация.

3. Сотрудничество с заказчиком важнее, чем согласование условий контракта.

4. Готовность к изменениям важнее, чем следование первоначальному плану.

В русском переводе идей Agile используется слово «важнее», но в оригинальном тексте вы увидите слово over – «над». При использовании слова «важнее» создается впечатление, что в фокусе находится только левая часть утверждения (все, что над линией over), а на правую часть можно не обращать внимания, если нет желания или не хватает ресурсов (времени и людей).

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

Не отрицая важности правой части, мы больше ценим левую. Тогда идеи Agile можно сформулировать так:

• приоритет людей и общения над инструментами и процессами;

• приоритет работающего продукта над полной документацией;

• приоритет сотрудничества с заказчиком над утверждением контракта;

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

12 принципов Agile

1. Наивысший приоритет для нас – удовлетворение потребностей клиента благодаря регулярной и ранней поставке ценного ПО.

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

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

Чем чаще, тем лучше. Это позволит планировать и внедрять любые изменения.

3. Изменение требований приветствуется даже на поздних стадиях разработки.

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

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

Можно оперативно задавать вопросы и получать ответы.

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

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

6. Личное общение – наиболее практичный и эффективный способ обмена информацией как с самой командой, так и внутри нее.

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

7. Работающий продукт – основной показатель прогресса.

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

8. Инвесторы, разработчики и пользователи должны иметь возможность бесконечно поддерживать постоянный ритм.

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

9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость.

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

10. Простота – это искусство не делать лишней работы.

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

11. Лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.

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

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

12. Команда должна систематически анализировать возможные способы улучшения эффективности и в соответствии с этим корректировать стиль своей работы.

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

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

Что показывает эта картинка? Есть философия Agile, которая базируется на ценностях (на верхнем уровне) и принципах (более подробно), которые мы только что рассматривали. Далее на этих принципах строится много практик и моделей разработки и управления проектом. Один набор практик на рисунке – это Scrum, другой – XP (экстремальное программирование) и т. д.

Применимость Agile к проекту

На рисунке представлена матрица Стейси.

Эта матрица, похожая на модель Кеневин, была создана профессором менеджмента Ральфом Стейси. Она называется матрицей согласованности и определенности. Модель применяется для оценки проекта с точки зрения неопределенности. Так можно оценить применимость Agile к проекту.

Выделенные на рисунке области соответствуют доменам из теории запутанности, известной как Cynefin Framework. Эта теория делит все системы на четыре домена по степени неопределенности: простые, сложные (упорядоченные), комплексные (запутанные) и хаотичные.

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

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

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

• Хаотичные системы – это запутанные в кубе. Количество факторов в них еще больше, причинно-следственные связи в основном неизвестны.

Модель имеет две оси, соответствующие степеням определенности в отношении технологий и в отношении требований.

• Горизонтальная ось демонстрирует уровень технической неопределенности проекта и показывает, насколько понятен способ достижения цели проекта (знаем ли мы, КАК делать?)

• Вертикальная ось показывает уровень неопределенности требований к проекту – степень согласия по поводу того, что должно быть сделано в результате проекта (знаем ли мы, ЧТО делать?)

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

Минутка истории

Систему канбан придумали японцы. Она сформировалась к 1950-м годам на производстве автомобилей «Тойота». Топ-менеджеры компании во главе с ее президентом Тайити Оно поставили цель: выпускать автомобили с максимальной скоростью, а складские запасы свести к минимуму.

Тайити Оно вместе с соратниками обратил внимание на работу американских супермаркетов, где покупатель сам выбирал необходимые товары. Роль «супермаркета» в корпорации Toyota выполнил склад.

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

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

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

Само слово «канбан» с японского переводится как «сигнальная карточка» / «бирка» / «знак».

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

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

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

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

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

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

Что же такое Kanban?

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

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

Ценности Kanban

Kanban базируется на определенных ценностях.

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

2. Баланс. В основе Kanban лежит простая мысль: объем незавершенной работы необходимо ограничивать. Важно сохранять баланс в работе и не перегружать сотрудника задачами. Красота Kanban начинает сиять в полную силу, когда мы создаем сбалансированную систему работы. Когда количество запросов совпадает с производительностью, это позволяет нам установить устойчивый ритм, который приводит к упорядоченному режиму работы, дает возможность все проконтролировать и помогает избежать сюрпризов. Баланс между работой и личной жизнью – вот то, о чем мы говорим.

3. Сотрудничество. Совместная работа и ее совершенствование: члены команды сотрудничают друг с другом и с заказчиком.

4. Клиентоориентированность. На протяжении всего срока работы стремитесь вовремя завершать задачи и плавно наращивать ценность вашего труда для клиента.

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

6. Лидерство. Нужно поощрять инициативу на всех уровнях организации: от каждого работника до высшего руководителя. Лидер должен вдохновлять окружающих своим примером. Хорошее лидерство помогает укрепить все прочие ценности, а плохое лидерство может быстро уничтожить их. Хорошее руководство создает хорошие системы работы (или ищет помощи в их создании) и сильную культуру.

7. Понимание. В Kanban эта ценность проявляется в понимании текущих ролей, процессов и того, почему все устроено таким образом.

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

9. Уважение. Тут вроде все понятно: уважение к коллегам и совместной работе необходимо для комфортной и продуктивной деятельности.

Принципы Kanban

Существует шесть основополагающих принципов Kanban, которые можно разделить на две группы:

• принципы управления изменениями;

• принципы предоставления сервисов.

Основная трудность заключается в сопротивлении команд новому. Kanban признает существование этого человеческого фактора и руководствуется тремя принципами управления изменениями.

1. Начните с того, что есть сейчас. Мы не начинаем резко менять структуру организации, процессы и роли. Kanban – это последовательные и плавные улучшения.

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

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

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

Как работает эволюционный подход.

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

Таким образом, мы эволюционно улучшаем наши процессы и продукт.

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

Каждая организация – это система взаимозависимых сервисов со своими правилами поведения. Мы все – один большой общий сервис для клиента. Иными словами, мы в команде предоставляем некий сервис или набор сервисов (если говорить о разработке продукта, то мы оказываем сервис – это разработка продукта).

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

1. Выясните потребности и ожидания заказчика. Постарайтесь понять потребности и ожидания клиентов и сосредоточьтесь на них

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

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

Практики Kanban

1. Визуализируйте.

2. Ограничивайте количество незавершенной работы.

3. Управляйте потоком работы.

4. Используйте явные правила работы.

5. Вводите циклы обратной связи (каденции).

6. Улучшайтесь и эволюционируйте.

Эти практические приемы мы используем для улучшения работы и повышения качества сервиса.

➤ Визуализация

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

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

Kanban не дает указаний в отношении конструкции канбан-досок.

• Число столбцов выбирается исходя из ситуации и типа проекта. Важно наглядно отобразить основные этапы проекта и их статус. В самом простом варианте используют столбцы «В ожидании», «В работе» и «Выполнено», но можно добавлять дополнительные. Каждый столбец соответствует определенному этапу работы в потоке поставки ценности.

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

➤ Работа с доской

1. Все задачи, которые поступают от заказчика, записываются на стикерах и размещаются в графе «В ожидании». На примере это графа «Сделать». Им можно назначать приоритет: более важные размещают выше и принимают в работу в первую очередь, а второстепенные выполняются после завершения приоритетных.

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

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

4. Вторая точка – точка поставки – принятие выполненного рабочего элемента (после колонки «Приемка»), когда заказчик принимает работу команды.

5. После выполнения задачи стикер отправляется в последнюю графу. В нашем примере – «Готово».

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

➤ Ограничение количества незавершенной работы

Еще одна значимая практика в Kanban – ограничение количества незавершенной работы. Незавершенная работа находится между двумя точками: «обязательство» и «поставка». На доске количество задач-листков, находящихся в работе на одной стадии, должно быть ограничено. Стабильно выполнять небольшое количество задач лучше, чем взяться за множество задач и толком не закончить ни одной. Для такого ограничения в Kanban вводится понятие work in progress (wip) – количество задач в работе. Точный максимум определяют, исходя из возможностей коллектива. Взяться за следующую задачу разработчик сможет не раньше, чем закончит работу с предыдущей.

Искусственное ограничение выглядит контрэффективным, но на практике оно вырабатывает совершенно иной подход и незавершенным делам. Благодаря Kanban-доске любая задержка или промедление в выполнении работы будет сразу заметна не только самому разработчику, но и всем коллегам. Это стимулирует не бросать начатое, столкнувшись со сложностями. Когда объем незавершенной работы не ограничен, можно позволить себе переключиться на более простые задачи, оставив сложную на потом. Это увеличивает риск того, что она навсегда останется в статусе отложенной.

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

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

➤ Управление потоком работы

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

Kanban помогает вам в этом с помощью kanban-досок. Когда мы выносим всю работу на видное место, нам становится проще понять, где именно возникают проблемы, а это позволяет оперативнее отреагировать и найти решение. Таким образом, работа быстрее движется к завершению.

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

➤ Используйте явные правила

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

Одно из правил – это подсчет wip. Самый частый пример явных правил – критерии готовности (definition of done) для вытягивания работы на следующий этап (то, что команда подразумевает под словом «готово» применительно к задаче). Например, сначала задача должна быть сформулирована в виде пользовательской истории с критериями приемки. И только после этого ее можно будет перенести в «ожидает разработки». Или реализованная задача должна пройти нагрузочное тестирование, чтобы ее можно было перенести в «приемка», и т. п.

➤ Используйте петли обратной связи

Практика больше известна как «встречи в Kanban». Цель – получить информацию о показателях системы и результатах совершенных ранее действий, спланировать следующие эксперименты и замкнуть петлю обратной связи.

➤ Улучшайтесь и эволюционируйте

Цель этой практики – научиться управлять изменениями команды или организации. Мы не рисуем большое красивое будущее в виде точки «Б» и не строим грандиозный план, как туда попасть.

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

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

Классы обслуживания

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

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

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

2. Класс с фиксированной датой – стоимость задержки резко возрастает после определенного периода. Пример: проект в виде ФЗ с фиксированной датой начала действия. Не успеем вовремя – есть риск потерять лицензию.

3. Стандартный класс – стоимость задержки растет пропорционально времени. Если делаем сразу, то и прибыль получаем сразу. Если делаем долго, то и прибыль получаем нескоро.

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

Каденции

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

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

Канбан предусматривает семь способов получения обратной связи. Выбор подходящей каденции зависит от обстоятельств и имеет большое значение для получения хороших результатов.

1. Канбан-митинг (ежедневная). Обсуждаем статус задач. Канбан-митинг чем-то напоминает стендап: сначала каждый делится проблемами и планами на день, а потом все вместе обсуждаем, как решить проблему. Уделяем внимание заблокированным задачам.

2. Встреча по наполнению очереди (обычно раз в одну-две недели). Берем на себя обязательства за то, что будет делать предоставляемый сервис, то есть планируем, какой продукт будем реализовывать.

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

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

5. Операционная встреча (обычно раз в месяц). Обсуждаем качество взаимодействия связанных сервисов. Если мы взаимодействуем с кем-то еще, например с техподдержкой, то собираемся вместе и проводим обзор предоставляемых сервисов/продуктов для максимизации ценности сервиса для заказчика, то есть пересматриваем качество, ищем возможность улучшить результат.

6. Встреча по обзору рисков (обычно раз в месяц). Изучаем риски, обсуждаем попытки минимизировать их. Обсуждаем риски, связанные с блокировками выполнения задач и их влиянием на работу сервиса. К примеру, результатом встречи может быть изменение класса обслуживания/приоритета задачи.

7. Встреча по обзору стратегии (обычно раз в квартал). Используя метрики, обсуждаем изменения в стратегии/концепции разработки предоставляемого сервиса/продукта, а также анализируем внешние обстоятельства, возникающие при управлении сервисами.

Частоту встреч можно отрегулировать под себя. От некоторых допустимо вообще отказаться, если они не несут для вас никакой ценности. Например, 1–4 встречи – основные. А три последние вводятся на уровне организации и нескольких связанных сервисов. Но важно помнить, что обмен информацией между всеми уровнями управления принесет организации максимальную гибкость.

Роли

В Kanban выделяют три роли.

1. Менеджер сервиса запросов (Service Request Manager, менеджер продукта, владелец продукта) отвечает за изучение потребностей и ожиданий заказчиков, содействует выбору и приоритизации рабочих элементов на собраниях по пополнению очереди.

2. Менеджер сервиса поставки (Service Delivery Manager, менеджер потока, менеджер поставок) отвечает за поток работы, в ходе которого выбранные рабочие элементы поставляются заказчикам. Проводит Kanban-митинги и собрания планирования поставки.

3. Команда разработки.

S.T.A.T.I.K

Расшифровывается как System Thinking Approach for Introducing Kanban и переводится как «системный подход к внедрению Kanban». То есть вы проходите определенные шаги, оцениваете задачи, проблемы и ожидания. И из этих элементов получаете взгляд на систему в целом. Здесь будут видны все недостатки процессов и пути по их исправлению.

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

1. Определить потребителей сервиса.

2. Выявить источники неудовлетворенности.

3. Проанализировать спрос.

4. Проанализировать возможности.

5. Построить модель рабочего процесса.

6. Определить классы сервиса.

7. Создать проект визуализации Kanban-системы.

8. Представить систему.

0/1. Сервис и менеджер

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

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

Здесь под словом «сервис» понимается ваша деятельность. Представьте себя и свою работу услугой, которую вы оказываете вашим клиентам (заказчикам).

1/2. Источники неудовлетворенности

В этом разделе нужно отразить внутренние и внешние (с точки зрения клиента) источники неудовлетворенности и изменчивости.

Внутренние источники неудовлетворенности – то, чем недовольна сама команда сервиса.

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

Внешние источники неудовлетворенности – это то, чем недовольны заказчики сервиса или смежные сервисы.

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

2/3. Анализ запросов

Этот раздел содержит шаблон анализа запросов. Какие задачи вам поступают? Истории, собранные в этом разделе, часто содержат слова, которые раскрывают типы рабочих элементов, скрытую информацию о рисках, неудовлетворенные ожидания, внешние и специфичные зависимости (раздел «Отображение рабочих процессов»), неявные классы обслуживания.

Для каждого типа рабочего элемента соберите следующую информацию.

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

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

• Частота возникновения – количество запросов на единицу времени. Плохой пример: «У нас 300 элементов в бэклоге». Если вам дадут такой ответ, спросите, откуда взялись эти элементы и как они попали в бэклог. Хороший пример: «Два раза в неделю».

• Характер (или природа) запроса – внимание к любым закономерностям. Пример: прибегает в последнюю минуту; ссылается на генерального директора; спокойный, можно договориться.

• Ожидания клиента – представления заказчика о времени поставки элемента. Могут быть необоснованными. Пример: через неделю, через два дня, сегодня, по готовности.

3. Отображение рабочих процессов

Нарисуйте рабочий процесс для нескольких типов рабочих элементов (3–4 шт.). Есть ли между ними сходства и различия? Осуществляется ли одновременная и неупорядоченная деятельность?

Рисовать можно любым удобным вам способом: например, изображать человечков, передающих работу с этапа на этап. Или отражать каждый из этапов на стикерах. Или использовать блок-схему.

4. Классы обслуживания

Для каждого типа рабочего элемента укажите класс(ы) обслуживания, соответствующие им политики и ожидания поставки.

Всего существует четыре архетипа классов обслуживания. Они основаны на стоимости задержки. Задайте вопрос для каждого типового элемента из раздела 2: «Какую сумму денег мы потеряем, если не начнем делать эту работу прямо сейчас?» Варианты ответов:

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

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

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

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

5. Каденции по пополнению и поставке

Укажите для каждого типа рабочего элемента входную и выходную каденцию – частоту наполнения и поставки типового элемента сервисом.

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

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

6. Визуализация канбан-системы

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

Гибкие модели управления командой Scrum

Что такое Scrum

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

Термин Scrum позаимствован из регби и переводится как «схватка». Это такой элемент игры, в котором от каждой команды участвуют по восемь игроков. Они обхватывают друг друга руками, выстроившись в три линии и сомкнувшись с соперниками, и в образовавшийся туннель вкидывают мяч, а игроки от команд пытаются завладеть мячом. Для успешного перехвата нужна не только хорошая физическая подготовка, но и слаженность действий каждого участника схватки и четкое понимание цели – то есть важна командная работа.

Создатели Scrum Джефф Сазерленд и Кен Швабер, наблюдая за игрой в регби, поняли, что как раз командной работы, слаженности не хватает и разработчикам ПО. Так появился Scrum.

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

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

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

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

Принципы Scrum

В основе Scrum лежат три принципа: прозрачность, инспекция и адаптация.

➤ Прозрачность

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

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

Прозрачность процессов в Scrum – не просто рекомендация, а именно принцип работы.

Примеры

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

2. Те, кто выполняют работу и принимают рабочий продукт, должны иметь общие критерии готовности (definition of done).

➤ Инспекция

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

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

Участники Scrum-процесса должны сами инспектировать его артефакты и прогресс на пути к цели спринта.

Пример

Ежедневные сборы для выявления блокеров и сообщения важной информации участникам команды.

➤ Адаптация

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

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

Пример

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

Три базовых принципа Scrum – это «три кита», которые позволяют Scrum как фреймворку максимально полно реализовывать гибкий подход к разработке.

Ценности Scrum

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

➤ Сфокусированность (Focus)

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

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

➤ Смелость (Courage)

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

➤ Открытость (Openness)

Открытость необходима Scrum-команде для того, чтобы достичь необходимой гибкости. Лучше вовремя исправить проблемные моменты в продукте или в процессе его разработки, чем упрямо создавать неправильный продукт или делать ценный продукт неправильным способом. Другими словами, сами члены команды могут открыто говорить о том, что важно. Открытость также подразумевает открытость к новым и креативным решениям, новым способам работы и взаимодействия. Это также открытость к новым задачам, которые могут возникать в процессе работы: негибко следовать первоначальному плану, когда бизнес-ситуация изменилась и возникли новые задачи. Нельзя игнорировать новую информацию. Открытость позволяет полноценно использовать Scrum как фреймворк гибкой разработки продукта.

➤ Обязательство (Commitment)

Вовлекаясь в процесс, каждый член Scrum-команды «подписывается» под целью Спринта, и под конкретными задачами беклога. Именно для этого на планировании Спринта присутствует вся Scrum-команда. Такой подход контрастирует с классическим менеджментом, когда дается указание свыше, и члены команды могут вообще не понимать, что они делают и зачем. В Scrum крайне важно, чтобы каждый член команды принимал сознательное решение и брал за него личную ответственность. Имея полный контроль над своими действиями, мы более склонны к успеху (committed to success).

➤ Уважение (Respect)

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

Роли в Scrum

Scrum – это командный процесс, который включает в себя три роли.

1. Владелец продукта (Scrum Product Owner).

2. Scrum-мастер.

3. Scrum-команда (команда разработки).

➤ Владелец продукта

Это выделенная роль. На самом базовом уровне владелец продукта – лидер, ответственный за максимизацию ценности продуктов, которые создает команда Scrum.

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

1. Говоря о команде, мы упоминали такую роль, как владелец продукта (Product Owner). Это человек, который представляет продукт, управляет им и формирует его ви´дение. Анализируя рынок и целевую аудиторию, он определяет, как будет развиваться продукт и как максимально удовлетворить всех заинтересованных лиц.

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

2. Все идеи и пожелания владелец продукта складывает в Product Backlog. Бэклог продукта – это упорядоченный перечень всех пожеланий и идей, над которыми будет работать Scrum-команда. Владелец продукта единолично управляет этим бэклогом, описывает его задачи для команды, определяет приоритеты этих задач, обеспечивает прозрачность для всех участников процесса.

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

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

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

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

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

➤ Scrum-мастер

Scrum-мастер – специалист, владеющий различными практиками и подходами, которые позволяют наладить процессы разработки ПО и привести их к соответствию Scrum-гайду и принципам Agile. Консультирует не только команду разработки, но и владельца продукта, а также владельцев бизнеса.

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

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

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

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

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

2. Scrum-мастер может фасилитировать встречи. Он помогает Scrum-команде стать самоорганизующейся, не сбиться с пути, а также остаться продуктивной и нарастить свои возможности.

3. Scrum-мастер работает вместе с владельцем продукта, помогая ему понимать, создавать и поддерживать бэклог продукта.

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

5. Scrum-мастер помогает людям вне команды понять процесс и видит, какие взаимодействия с командой идут им на пользу, а какие нет.

➤ Scrum-команда

Сердце Scrum – Scrum-команда. Это небольшая группа людей, работающая над продуктом.

1. Команда разработки состоит из профессионалов, которые трудятся над созданием инкремента продукта. Они самоорганизуются для выполнения работ. Никто (даже Scrum-мастер) не может указывать команде, как создавать инкременты работающей функциональности из бэклога продукта.

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

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

4. В Scrum-команде обычно не так много людей – 7 ± 2 человека. Оптимальная по численности команда разработки достаточно мала для того, чтобы оставаться простой в управлении, и в то же время достаточно велика, чтобы выполнять значительный объем работы в течение спринта.

Мероприятия в Scrum

Scrum включает в себя пять видов активностей/мероприятий.

1. Спринт.

2. Планирование спринта.

3. Daily Scrum (ежедневный).

4. Обзор спринта.

5. Ретроспектива спринта.

Мероприятия используются в Scrum для поддержания принципов инспекции и адаптации, а также для создания регулярности.

➤ Спринт

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

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

У спринта должна быть цель, чтобы команда разработки понимала, зачем создается инкремент и какие задачи нужно решить в первую очередь. Цель спринта дает некую гибкость: руководствуясь ею, можно корректировать содержимое спринта, например добавлять или заменять задачи.

Следующий спринт начинается сразу же по окончании предыдущего.

Спринты состоят из планирования, ежедневных Scrum (стендапов), разработки, обзора спринта (или демо), а также ретроспективы спринта.

➤ Планирование спринта

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

В планировании участвует вся Scrum-команда и владелец продукта. Scrum-мастер отвечает за обязательное проведение мероприятия и помогает всем участникам понять его цель. Он учит Scrum-команду не превышать лимит времени, отведенный на мероприятие.

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

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

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

➤ Ежедневный Scrum (стендап)

Это 15-минутные мероприятия для команды разработчиков, которые проводятся с целью синхронизации действий и создания плана работы на ближайшие 24 часа. Такие встречи нужны для того, чтобы проинспектировать работу, проделанную с момента прошлого ежедневного Scrum, и спрогнозировать шаги, которые можно осуществить до следующего.

Эти встречи проводятся в одном и том же месте, в одно и то же время для уменьшения путаницы.

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

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

➤ Обзор спринта

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

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

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

Для спринта длиной в месяц обзор – четырехчасовое мероприятие. На короткие спринты обычно тратят меньше времени.

➤ Ретроспектива спринта

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

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

Цели ретроспективы спринта.

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

2. Определить и упорядочить задачи – поговорить о том, что прошло успешно, а что нуждается в улучшении.

3. Разработать план по внедрению улучшений в процесс работы Scrum-команды, который и будет результатом встречи.

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

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

Артефакты в Scrum

Скрам включает в себя три важных артефакта: бэклог продукта, бэклог спринта и инкремент продукта.

➤ Бэклог продукта

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

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

➤ Бэклог спринта

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

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

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

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

➤ Инкремент

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

У всей команды должно бы единое понимание того, что считать «готовым» продуктом (критерий прозрачности Scrum).

Критерий готовности (definition of done) – одно из соглашений, которое должна обсудить и принять вся команда. Участники команды определяют, что они подразумевают под словом «готово» применительно к задачам или элементам бэклога.

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

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

СюХаРи

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

Название отражает три этапа освоения.

1. Следование правилам.

2. Небольшие эксперименты.

3. Следование интуиции.

h. Стадия Сю – «следуй правилу» / «соблюдай»

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

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

h. Стадия Ха – «сломай правила» / «отделяйся»

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

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

h. Стадия Ри – «отделение от правил» / «превосходи»

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

В айкидо это третья ступень, согласно которой нужно освободиться от правил: их больше нет, есть лишь естественный ход вещей (Дао). «Ри» означает подняться над всем, что изучалось раньше, создать более высокие и общие принципы. На этой ступени уже формируется органичное и естественное поведение на уровне привычек.

Так вот, принцип освоения Scrum похож на методику СюХаРи:

• скраму можно научиться лишь в процессе, при этом сначала нужно хорошо освоить все правила, а потом забыть о них;

• скрам основан на постоянном пополнении опыта, требует особой внимательности и приложения больших сил.

Основы разработки требований

Заинтересованные лица

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

Если хотите, можете изучить другие определения термина «стейкхолдер». Это почти наверняка спросят на собеседовании, и неизвестно, какое из них знакомо HR-специалисту.

1. Это лица или организации, имеющие права, долю, требования или интересы относительно системы или ее свойств, удовлетворяющих их потребностям и ожиданиям (ISO/IEC/IEEE15288:2015).

2. Индивидуум, команда, организация или их группы, имеющие интерес в системе (ISO/IEC42010).

3. Люди, группы или организации, которые могут влиять на систему или на которых может повлиять система (OMG Essence).

4. Лицо, группа или организация, которая может влиять, подвергаться влиянию или воспринимать себя подвергнутой влиянию решения, операции или результата проекта (PMBOK).

5. Лицо или организация, которая может воздействовать на осуществление деятельности или принятие решения, быть подверженной их воздействию или воспринимать себя в качестве подверженной воздействию (ISO 9000:2015).

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

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

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

Пример

• Низкая рентабельность

• Вероятность потери доли рынка

• Большой процент простоев

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

Пример

• Отдел заказов работает без сбоев

• Маржинальность составляет минимум 10%

Ожидания – неявные (скрытые) представления заинтересованных лиц о характеристиках целевой ситуации, продукта системы, результата проекта. Имеют прямую связь с интересами этих лиц.

Пример

• Система будет красивой (с моей точки зрения)

• Сопровождение системы не потребует затрат

• Подрядчик будет соблюдать бюджет и сроки в пределах ± 5%

Решения – это диапазон возможных путей устранения выявленных бизнес-проблем.

Пример

• Изменение организационной структуры компании

• Разработка новых или оптимизация существующих бизнес-процессов, изменение бизнес-правил

• Оптимизация или разработка новых стратегических планов организации и т. п.

Типы заинтересованных лиц

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

Ниже приведены примеры наиболее распространенных типов (групп) стейкхолдеров, которые упоминаются в стандартах ГОСТ Р ИСО/МЭК 15288–2005, ISO/IEC29148:2011, ГОСТ Р ИСО/МЭК 12207–2010, OMG Essence, своде знаний по системной инженерии SWEBOK и учебниках по системной инженерии. Под стейкхолдером здесь подразумевается организация или физическое лицо.

1. Приобретающая сторона, или покупатель (acquirer), приобретает или получает (procures) продукт или услугу от поставщика. Это может быть покупатель, заказчик, владелец, оптовый покупатель.

2. Заказчик, или клиент (customer), получает продукт или услугу.

3. Разработчик (developer) выполняет задачи разработки, включая анализ требований, проектирование, тестирование в течение всего жизненного цикла.

4. Поставщик (supplier) вступает в соглашение с приобретающей стороной на поставку продукта или услуги.

5. Пользователь (user) извлекает пользу в процессе применения системы.

6. Производитель (producer) отвечает за выполнение работы, расписание, бюджет и распределение ресурсов, чтобы удовлетворить клиента.

7. Сопровождающая сторона (maintainer) выполняет поддержку системы на одном или нескольких этапах жизненного цикла, осуществляет деятельность по сопровождению.

8. Ликвидатор (disposer) выполняет ликвидацию (изъятие и списание) системы и связанных с ней эксплуатационных и поддерживающих служб.

9. Аккредитор, или инспектор (accreditor), проверяет систему на соответствие требованиям в процессе сдачи ее в эксплуатацию.

10. Регулирующий орган (regulatory bodies) проверяет систему на соответствие требованиям в процессе эксплуатации.

11. Остальные – персонал поддержки (supporters), инструкторы (trainers), операторы (operators) и другие.

Роли заинтересованных лиц

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

Основные роли заинтересованных в проекте сторон следующие.

1. Инвестор предоставляет ресурсы для проекта или формирует инвестиционно привлекательную ситуацию вокруг него. Очень важно определить инвестора до начала проекта, поскольку именно с ним нужно решать все вопросы, касающиеся обеспечения проекта ресурсами.

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

3. Лидер проекта – наиболее авторитетный человек в команде проекта. К его мнению прислушиваются, он принимает большинство технических решений по ходу проекта. Часто лидер и менеджер проекта – одно лицо.

4. Заказчик получает результаты проекта в собственность того или иного вида.

5. Пользователи непосредственно используют результаты проекта в своей деятельности.

6. Организация-исполнитель выполняет проект и несет ответственность за это перед заказчиком. Она может состоять только из его команды и быть создана для реализации одного конкретного проекта.

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

8. Команда управления проектом – часть команды проекта, непосредственно участвующая в деятельности по управлению проектом. Это менеджер проекта и лидер проекта. Также туда могут входить секретарь менеджера, эксперты, помогающие в принятии решений, и т. д.

Взаимоотношения между заинтересованными лицами проекта

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

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

Профили заинтересованных лиц

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

Информация, которая включается в профиль заинтересованного лица

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

• улучшенная производительность;

• меньшее количество переделок;

• снижение себестоимости;

• ускорение бизнес-процессов;

• автоматизация задач, ранее выполнявшихся вручную;

• возможность решать совершенно новые задачи;

• соответствие стандартам и правилам;

• возросшая, по сравнению с текущими продуктами, легкость и простота использования;

• их вероятное отношение к продукту;

• наиболее интересные функции и характеристики;

• все известные ограничения, которые должны быть соблюдены.

Приоритеты проекта

Чтобы принимать эффективные решения, заинтересованные лица должны договориться о приоритетах проекта. Один из подходов заключается в рассмотрении пяти измеряемых параметров проекта: функции (или объема), качества, графика, затрат и кадров. В любом проекте каждый из этих параметров относится к одной из трех категорий:

• ограничение – лимитирующий фактор, в рамках которого должен оперировать менеджер проекта;

• ключевой фактор – важный фактор успеха, ограниченно гибкий при изменениях;

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

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

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

Какова будет ваша реакция?

1. Вы отложите реализацию определенных требований до более поздней версии?

2. Сократите запланированный цикл тестирования системы?

3. Оплатите сверхурочную работу вашим специалистам или пригласите специалистов по контракту для ускорения разработки?

4. Привлечете ресурсы других проектов для разрешения ситуации?

Именно от приоритетов проекта зависят ваши действия в подобных ситуациях.

Пользователи

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

Пользователь (user) – лицо или организация, которая использует действующую систему для выполнения конкретной функции.

Классы пользователей

Пользователей продукта можно подразделять по таким признакам:

• частота использования продукта;

• опыт в предметной области и опыт работы с компьютерными системами;

• функциональность, которая им требуется;

• задачи, которые им приходится решать;

• права доступа к системе, например «обычный пользователь», «гость» или «администратор».

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

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

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

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

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

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

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

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

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

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

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

Пример

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

Выявление классов пользователей

Один из полезных способов определения классов называется «от расширения к сжатию» (expand then contract). Для начала нужно придумать как можно больше классов пользователей, пусть даже их будет слишком много. Важно не пропустить какой-либо класс, иначе это аукнется позже.

Следующий этап – выявить группы с похожими потребностями. Их можно объединить в один класс или рассматривать как несколько подклассов одного крупного класса пользователей. В списке отдельных классов не должно быть больше 15 пунктов.

Здесь могут оказаться полезными следующие вопросы.

1. Кто пользователь системы?

2. Кто заказчик (экономический покупатель) системы?

3. На кого еще окажут влияние результаты работы системы?

4. Кто будет оценивать и принимать систему, когда она будет представлена и развернута?

5. Существуют ли другие внутренние или внешние пользователи системы, чьи потребности необходимо учесть?

6. Кто будет заниматься сопровождением новой системы?

7. Не забыли ли мы кого-нибудь?

Классы пользователей, их отличительные черты, меру ответственности и физическое расположение в спецификации требований к ПО нужно задокументировать.

Для чего нужна классификация пользователей

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

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

Организационная модель

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

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

На практике применяют следующие принципы организационных моделей.

1. Функциональная модель: одно подразделение = одна функция.

2. Процессная модель: одно подразделение = один процесс.

3. Матричная модель: один проект = группа сотрудников из разных функциональных подразделений.

4. Модель, ориентированная на контрагента: одно подразделение = один контрагент, то есть клиент или клиентская группа, поставщик, подрядчик и пр.

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

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

Функциональная модель

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

Принципы функциональной модели следующие.

1. Принцип иерархичности уровней управления. Каждый нижестоящий уровень контролируется вышестоящим и подчиняется ему.

2. Принцип соответствия полномочий и ответственности работников управления их месту в иерархии.

3. Принцип разделения труда на отдельные функции и специализации работников по выполняемым функциям.

4. Принцип формализации и стандартизации деятельности. Он обеспечивает однородность выполнения работниками своих обязанностей и скоординированность задач.

5. Принцип обезличенности выполнения работниками своих функций.

6. Принцип квалификационного отбора. Наем и увольнение с работы производится в строгом соответствии с квалификационными требованиями.

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

Процессная модель

Процессные системы строятся на основе нескольких базовых принципов концепции управления процессами. В 80-х годах XIX века Фредерик Тейлор предложил менеджерам использовать методы процессного управления для наилучшей организации деятельности. В начале 1900-х годов Анри Файоль разработал концепцию реинжиниринга. Реинжиниринг – это осуществление деятельности в соответствии с поставленными задачами путем получения оптимального преимущества из всех доступных ресурсов.

Принципы процессной модели следующие.

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

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

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

4. Принцип самостоятельности выбора. Исполнители принимают самостоятельные решения и несут ответственность за получение заданного результата деятельности.

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

6. Принцип системности (целостности) управления. Управление затратами происходит по месту их возникновения. Система управления издержками строится совместно с организационной структурой, без отрыва от деятельности, по правилу «один процесс – одно подразделение – один бюджет».

Матричная модель

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

Принципы матричной модели следующие.

1. Работники осуществляют свою деятельность под оперативным руководством менеджера процесса и административным контролем руководителя функционального «колодца».

2. Роль менеджера процесса состоит в координации действий внутри процесса.

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

Смешанные модели

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

Пример

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

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

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

Выбор тех или иных субмоделей зависит от специфики бизнеса.

Требования

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

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

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

Примеры

• Уменьшить среднее время реализации заявок на 30 %.

• Увеличить количество выпускаемой продукции на 10 %.

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

Пользовательские требования (User requirements) – требования, описывающие задачи, которые определенные классы пользователей должны иметь возможность выполнять в системе.

Пример

КАК сотрудник одного из отделов

Я ХОЧУ иметь возможность формировать и подавать заявки в электронном виде,

ЧТОБЫ сократить время на хождение по кабинетам, ускорить создание продукта, исключить ошибки и сократить время на переделывание после отклонений.

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

Бизнес-требование:

уменьшить среднее время реализации заявок на 30 %.

Пользовательское требование:

КАК сотрудник обслуживающего подразделения

Я ХОЧУ иметь возможность видеть список входящих заявок в виде таблицы,

ЧТОБЫ было удобно фильтровать, отслеживать заявки и предотвращать их потерю.

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

Пример

1. Необходимо реализовать форму подачи заявки со следующими полями: …

2. Наименование поля «Тип заявки».

3. Формат: выпадающий список с поиском по вводу символов.

4. Варианты значения выпадающего списка: …

5. Поле обязательно к заполнению.

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

Классификация требований по Вигерсу

Каждая система имеет свои функциональные и нефункциональные требования.

Проще говоря:

• функциональные требования описывают, как должна вести себя система;

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

Системные требования (System requirements) – это требования к системе в целом, к ПО и оборудованию, а также к структуре данных, необходимой для реализации системы, и алгоритмам, которые ими манипулируют.

Примеры

Масштабируемость, отказоустойчивость.

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

Пример

SMS клиентам могут отправляться с 9:00 по 21:00 по часовому поясу клиента.

Атрибуты качества

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

Примеры

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

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

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

Сбор требований

«Начинайте с конца, чтобы не сделать ошибку в начале».

Народная мудрость

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

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

1. даст пользователям возможность выполнять необходимые задачи в системе, тем самым удовлетворяя их потребности и решая проблемы;

2. поможет достичь поставленных бизнес-целей.

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

Есть много методов выявления требований. Вот список тех, с которыми мне приходилось сталкиваться в практике работы бизнес-аналитиком.

1. Интервьюирование.

2. Анализ документации.

3. Моделирование процессов.

4. Анализ существующих внешних решений.

5. Прототипирование.

6. Моделирование.

7. Наблюдение.

8. Анализ данных.

9. Анализ текущих систем.

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

Эффективность различных каналов коммуникации

Коммуникация – процесс передачи информации между людьми.

Рисунок на слайде взят из книги Алистера Коберна Agile Software Development (быстрая разработка ПО).

Существуют разные способы коммуникации, которые могут выбрать люди при совместной работе.

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

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

• Записи на бумаге.

• Аудио и видеозаписи.

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

• переписка по e-mail;

• телефонный разговор;

• разговор по видеосвязи;

• живая встреча;

• живая встреча с применением доски (фиксирование предложений и решений).

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

Для аналитиков это важно; поскольку их работа строится на общении, им нужно знать, как в том или ином случае эффективнее коммуницировать с человеком.

Нужно стараться выбирать способы самой эффективной коммуникации

Пример

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

Интервьюирование

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

Этап 1. Подготовка

На этом этапе необходимо выполнить следующие шаги.

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

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

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

4. Предположение о возможных функциях системы.

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

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

7. Составление списка вопросов.

Этап 2. Проведение встречи

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

2. Прийти вовремя. Лучше, если вы придете вовремя, а заказчик опоздает (очень частая история), чем наоборот. Педантичность в этой профессии – знак профессионализма.

3. Обозначить повестку. У вашего клиента эта встреча с бизнес-аналитиком может быть первой, или он может иметь какой-то свой особый план проведения встречи; чтобы ему было комфортно, вы должны задать тон всего интервьюирования. Для начала уточните, сколько времени ваш собеседник планирует потратить на встречу. Если она предполагается длительной, вы можете сказать, что каждые 40 минут будете делать пятиминутный перерыв, чтобы немного освежить мысли. После того как вы уточнили время, расскажите о плане встречи и регламенте. Например, попросите собеседника о том, чтобы он сразу уточнял непонятные моменты, а не дожидался конца интервьюирования. Если на встрече присутствует несколько человек, вы должны представить их друг другу, объяснить некоторые правила и определить приоритеты: кто ведет беседу и т. д. Если беседа будет записываться на диктофон, видео и т. д., обязательно предупредите об этом клиента.

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

5. Фиксировать письменно или записывать на диктофон/видео. Это очень важно! Надеяться на память в этом вопросе нельзя.

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

7. Назначьте следующий шаг, если это необходимо.

Этап 3. Действия после проведения интервью

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

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

3. При необходимости запросить уточнения.

4. Дополнить основные документы (черновики) по требованиям.

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

Анализ требований

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

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

Выделение пользовательских историй в отдельные пакеты

Первый этап анализа требования – выделение пользовательских историй в отдельные пакеты требований. Главная цель формирования пакетов – упростить доступ к нужным данным за счет расположения всех вариантов использования, относящихся к определенной функциональности, на одной странице (оглавление или диаграмма вариантов использования). В случае использования текстовых документов пакеты также существенно упростят автору процесс последующего редактирования – ему не придется блокировать весь документ на время редактирования, а пользователям документа будет легче узнать об изменениях (как правило, для этого используется секция «История изменений» в начале каждого документа). Пакеты формируются из пользовательских историй, которые описывают схожую деятельность или способ достижения схожего результата. Как правило, они подчинены всего одному бизнес-требованию. Для средних или крупных продуктов часто создают дополнительный пакет и включают в него множество историй, которые не имеют схожих признаков, но должны быть рассмотрены.

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

Описание требований с помощью вариантов использования

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

Вариант использования (Use case) продукта описывает последовательность взаимодействия системы и внешнего действующего лица.

Действующее лицо (Actor) – это человек, другая система ПО или аппаратное устройство, взаимодействующее с системой для достижения некой цели. Еще одно название действующего лица – роль пользователя. Это роль, которую члены одного или нескольких классов пользователей могут играть по отношению к системе.

Примеры

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

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

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

Диаграммы вариантов использования (Use Case Diagrams) позволяют получить визуальное представление о требованиях пользователей.

Фрагмент диаграммы варианта использования Chemical Tracking System

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

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

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

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

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

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

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

Важные элементы описания варианта использования следующие.

1. Уникальный идентификатор.

2. Имя, кратко описывающее задачи пользователи в формате «глагол + объект», например «разместить заказ».

3. Краткое текстовое описание на естественном языке.

4. Список предварительных условий, которые должны быть выполнены до начала разработки варианта использования.

5. Выходные условия, описывающие состояние системы после успешного завершения разработки варианта использования.

6. Пронумерованный список действий, иллюстрирующий последовательность этапов взаимодействия лица и системы от предварительных условий до выходных данных.

Нормальное направление варианта использования

Нормальное направление развития (Normal course) – это основное направление варианта использования, основной или главный успешный сценарий, благоприятный путь.

Нормальное направление для варианта использования «Запрос химиката» – запрос химиката, который есть на складе. UML-диаграмма иллюстрирует диалоговый поток при нормальном и альтернативном развитии вариантов использования.

Альтернативные направления варианта использования

Альтернативное направление (Alternative course) – это другой допустимый сценарий из варианта использования. Еще он может называться вторичным сценарием (secondary scenario).

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

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

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

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

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

Исключения вариантов использования

Исключение (Exception) – это условие, препятствующее успешному завершению варианта использования.

Для варианта использования «Запросить химикат» существует одно исключение – «Химиката нет в продаже».

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

1. Разработчики предложат лучший, по их мнению, способ обработки исключений.

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

Но сбои системы не входят в список требований пользователей.

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

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

Последовательность вариантов использования

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

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

Для коммерческого веб-сайта предлагаются варианты использования «Поиск по каталогу», «Добавить товар в корзину» и «Оплатить товары в корзине». Если можно выполнить все эти действия по отдельности, то все они считаются независимыми вариантами использования. Кроме того, можно выполнить все три указанные операции подряд, назвав этот один большой вариант использования «Приобрести товар», как показано на рисунке:

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

Выявление вариантов использования

Можно выявить варианты использования несколькими способами:

• сначала определить действующих лиц, а затем бизнес-процессы, в которых участвует каждое лицо;

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

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

• определить вероятные варианты использования на основе функциональных требований;

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

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

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

Преимущества применения вариантов использования

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

Высший приоритет назначается по следующим причинам:

• варианты использования описывают один из основных бизнес-процессов, активируемых системой;

• многие пользователи часто обращаются к ним;

• их запросил привилегированный класс пользователей;

• они предоставляют возможности, необходимые для соответствия требованиям;

• функции других систем зависят от их наличия.

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

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

Риски и ошибки при применении вариантов использования

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

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

Включение пользовательского интерфейса в варианты использования. Варианты использования должны описывать действия, которые пользователям необходимо выполнить с помощью системы, а не то, как это будет выглядеть на экране. Правильная формулировка на этой стадии – «система предоставляет выбор», а не «система отображает раскрывающийся список». Наброски экрана и карты диалогов (диаграммы архитектуры интерфейса) стоит применять для визуального представления взаимодействия исполнителя и системы, а не для утверждения дизайна.

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

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

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

Описание требований с помощью процессного подхода

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

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

Для осуществления процесса необходимо:

• организовать процесс – построить его в пространстве и времени;

• обеспечить ресурсами выполнение процесса;

• определить исполнителя процесса;

• задокументировать процесс: составить технологию, рабочие и пользовательские инструкции.

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

Разница между процессом и процедурой описана в таблице.

Основные понятия процессного подхода

Бизнес-процесс – это совокупная последовательность действий (подпроцессов), которая преобразует входы в выходы. Она направлена на получение заданного результата, ценного для организации, – продукта или услуги для потребителей.

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

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

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

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

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

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

Ресурс бизнес-процесса – материальный или информационный объект, который постоянно используется для выполнения процесса, но не выступает в качестве входа.

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

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

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

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

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

Способы описания бизнес-процессов

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

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

Текстовое описание бизнес-процесса оформления заказа клиенту может быть составлено следующим образом.

1. Старт бизнес-процесса – звонок клиента. Найти клиента в базе.

2. Если клиента нет в базе, зарегистрировать нового. Если есть – перейти к следующему этапу.

3. Уточнить потребность и проверить наличие товара.

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

5. Если товар есть в наличии, провести презентацию товара и перейти к этапу продажи.

6. Если клиент готов заказать товар, оформить заказ и передать его в службу доставки.

7. Если во время презентации клиента не устраивают характеристики, стоимость или другие параметры, но он готов подумать и просит связаться с ним позже, перевести клиента на стадию взращивания. Это повторное взаимодействие и предложение выгодных условий покупки до момента готовности к заказу.

8. Если клиент категорически отказывается, закрыть бизнес-процесс.

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

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

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

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

Блок-схемное описание бизнес-процесса оформления заказа после обращения клиента в нотации BPMN представлена на стр. 103.

Виды бизнес-процессов

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

Блок-схемное описание бизнес-процесса оформления заказа после обращения клиента в нотации BPMN

Самая распространенная классификация бизнес-процессов, основанная на этом принципе, выглядит следующим образом.

1. Основные процессы. Связаны с производством главных продуктов компании (товаров или услуг). К ним относятся процессы, добавляющие продукту стоимость, создающие продукт, генерирующие продукты, которые клиент готов оплачивать, и доходы.

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

3. Управляющие процессы. Сюда входит HR, корпоративное управление, управление качеством. Это стратегические процессы, процессы планирования, контролирующие процессы.

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

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

• обработка и выполнение заказа;

• разработка, проектирование и дизайн продукта;

• производство, монтаж и др.

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

• обработка данных;

• техническое обслуживание;

• логистика;

• административные процессы и др.

Управляющие процессы – содержат в себе задачи и деятельность, направленные на долгосрочное развитие компании и реализацию целей компании:

• стратегическое развитие;

• долгосрочное и среднесрочное планирование;

• развитие персонала;

• инвестиционное планирование;

• мотивация персонала и др.

Нотации для моделирования бизнес-процессов

Для построения моделей с помощью описанных выше методологий используются специальные методики моделирования – нотации.

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

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

В зависимости от типа модели бизнес-процесса, которую необходимо создать, используются соответствующие нотации.

Структурные модели – нотация IDEF

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

Для построения структурных моделей лучше всего подходит нотация IDEF (сокр. от англ. Integrated DEFinition) – стандартизированная система бизнес-моделирования, представленная целым семейством методик. Если вам интересно, можете отдельно почитать о семействе нотаций IDEF и месте в нем нотации IDEF0: с ней вам придется работать с вероятностью 99 %.

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

1. Вход (Input) – ресурсы, данные и прочие составляющие, поступающие на вход функции, которые необходимы для успешного выполнения функции и получения результата ее выполнения – выхода.

2. Управление (Control) – правила и лимиты, в которых существует процесс, или правила применения функции преобразования входов в выходы.

3. Механизм (Mechanism) – некоторый исполняющий ресурс. То, что фактически применяет к входу функцию для получения выхода.

4. Выход (Output) – результаты выполнения функции при наличии и подаче необходимых входов, с учетом накладываемых ограничений и на основе применения указанного механизма.

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

Одна из важных особенностей нотации – минималистичный набор характеристик-элементов, которые используются для построения диаграмм. Он помогает наилучшим образом описать процесс или некую деятельность организации без необходимости представления прочих деталей, хотя нотация позволяет декомпозировать любой функциональный блок с помощью дочерней диаграммы более низкого уровня детализации. Можно сосредоточиться на описании функции как некоего «черного ящика»: на оценке ресурсов, необходимых для его работы, результатов, которые можно получить, а также условиях их получения. IDEF0 позволяет хорошо справиться с одной из главных задач бизнес-аналитика – отделить важные описательные характеристики какой-либо системы или процесса от деталей реализации и представить только необходимую информацию об исследуемой функции.

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

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

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

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

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

Функциональный блок (функция или процесс) – это составная или простая функция, которая обозначается прямоугольным блоком. Внутри каждого блока помещается его наименование, которое должно емко отражать суть выполняемой функции. Название должно быть выражено активным глаголом, глагольным оборотом или отглагольным существительным. Также блоку может быть присвоен номер для упрощения идентификации на диаграмме и в описательных документах.

Стрелка (интерфейсная дуга) – стрелка, несущая стандартное значение с точки зрения связи блок-стрелка. В зависимости от стороны блока, к которой присоединена стрелка, однозначно определяется ее роль:

• стрелки, входящие в левую сторону блока, – входы;

• стрелки, входящие в блок сверху, – управления;

• стрелки, покидающие процесс справа, – выходы;

• стрелки, подключенные к нижней стороне блока, – механизмы.

Ниже приведен пример описания функции в нотации IDEF0.

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

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

В IDEF0 с точки зрения декомпозиции как приема есть всего два типа диаграмм: диаграмма с одним функциональным блоком – контекстная диаграмма и диаграммы декомпозиции, на которых в зависимости от детализации и разделения на сферы или подпроцессы может быть один или множество функциональных блоков. Основное отличие контекстной (также называемой А‐0) диаграммы – в создаваемой модели бизнес-процесса она представляет наиболее укрупненное ви´дение исследуемой системы, организации или процесса. Диаграммы декомпозиции являются дочерними по отношению к этой диаграмме и всегда представляют собой более детализированный разрез, в котором рассматриваются составляющие процесса.

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

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

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

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

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

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

6. Все интерфейсные дуги (стрелки) на диаграмме должны иметь своего потребителя или производителя, то есть соединяться с функциональным блоком.

Пример контекстной диаграммы А‐0

Строительство металлургического завода

Пример диаграммы декомпозиции процесса «Изготовление детали»

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

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

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

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

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

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

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

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

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

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

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

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

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

Сноска или комментарий – выносной элемент, предназначенный для подписи комментариев в формате свободного текста с четким отношением к какому-либо элементу диаграммы.

Текст или описание – свободный текстовый комментарий к одному из элементов или диаграмме в целом без сноски.

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

Главные достоинства нотации IDEF0.

1. Возможность наглядно отразить функциональную структуру исследуемого объекта: действия, которые производятся, и связи между ними. Для анализа организации как системы становится легко проследить логику и взаимодействие ее процессов.

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

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

Слабые стороны нотации как инструмента для описания процесса.

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

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

3. Невозможно описать процесс как четкую последовательность действий и расширить модель достаточным количеством деталей, добавить контрольные точки процесса и т. д.

Модели потоков работ – нотация eEPC

Нотация eEPC – «расширенная цепочка процесса, управляемого событиями» – это одна из частей общей методологии ARIS, подход, используемый для представления организации с позиции состава ее бизнес-процессов.

eEPC (extended Event-driven Process Chain – «расширенная событийная процессная цепочка») – нотация, основывающаяся на использовании событий в качестве состояний процесса и функций в качестве шагов процесса. Процессно-событийная модель в нотации еЕРС предназначена для описания процессов, выполняемых в рамках одного подразделения, несколькими подразделениями или конкретными сотрудниками. Она описывает некий бизнес-процесс низкого уровня в формате workflow (последовательность задач).

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

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

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

Функция – элемент, который служит для описания функции или набора действий (процедур, работ), выполняемых подразделениями или сотрудниками организации над исходным объектом и ведущих к получению промежуточного или финального результата или события. Внутри этого элемента помещается наименование функции в начальной форме глагола. Временная последовательность выполнения действий-функций задается их расположением на диаграмме процесса: процесс «записывается» от начала к его окончанию сверху вниз.

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

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

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

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

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

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

Нотация eEPC имеет приставку e – extended именно благодаря тому, что помимо основных элементов нотации, составляющих ее базу, аналитику предоставляется возможность использовать множество других элементов, которые могут пояснять и детализировать функции и события, описывающие основные шаги процесса. Часто набор элементов ограничен самим ПО, которое используется для изображения процесса, как, например, моделер ARIS Express. Но при использовании инструментов, не осуществляющих автоматизированных проверок на разрабатываемую модель и дающих возможность использовать любые элементы, аналитик сам может выбрать необходимое. Ниже представлены лишь некоторые элементы, которые чаще всего используются при описании процессов в eEPC, и их обозначения для модели БП.

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

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

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

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

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

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

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

Чередование «Событие – функция»

В основе eEPC-процесса лежит описание последовательности функций (действий), которые пользователи выполняют в системе. При этом каждой функции должно предшествовать событие, которое можно интерпретировать как некое «происшествие», например звонок клиента или получение письма, событие, происходящее по расписанию, или результат выполнения другого действия в процессной цепочке. Однако наиболее точно событие в нотации eEPC можно определить как состояние процесса, при котором должно быть выполнено действие. То есть событие или комбинация событий – это необходимое и достаточное условие выполнения некоторого действия: если это событие еще не наступило, то функция не может быть выполнена, а при наступлении события или комбинации событий для выполнения функции ничего другого не требуется.

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

Использование операторов

➤ Оператор «И»

Оператор «И» обозначает слияние или ветвление функций и событий в процессе. Поэтому по правилам он используется:

• после функции и перед событиями, если завершение выполнения функции должно инициировать одновременно несколько событий;

• после функций и перед одиночным событием, если событие происходит только после обязательного завершения выполнения нескольких функций;

• после событий и перед функцией, если функция может начать выполняться только после того, как произойдут несколько событий;

• после события и перед функциями, если одно событие может инициировать одновременное выполнение нескольких функций.

Таким образом, корректным будет использование оператора «И» в следующих случаях:

➤ Оператор «ИЛИ»

Оператор «ИЛИ» используется для обозначения слияния или ветвления функций и только для слияния событий. Соответственно, по правилам он будет использоваться:

• после функции и перед событиями, если завершение выполнения функции может инициировать одно или несколько событий;

• после функций и перед одиночным событием, если событие происходит после завершения выполнения одной или нескольких функций;

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

Оператор «ИЛИ» не может следовать после одиночного события.

Таким образом, корректно будет использовать оператор «ИЛИ» в следующих случаях:

➤ Оператор «Исключающее ИЛИ»

Оператор «Исключающее ИЛИ», как и оператор «ИЛИ», используется для обозначения слияния и ветвления функций и только для слияния событий. Он позволяет учесть, что при ветвлении функций в рамках одного выполнения всего процесса может быть задействована лишь одна из предлагаемых ветвей. Соответственно, по правилам он будет использоваться:

• за функцией и перед событиями, если завершение выполнения функции может инициировать только одно из событий в зависимости от какого-то условия;

• после функций и перед одиночным событием, если событие происходит сразу после завершения выполнения либо одной функции, либо другой;

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

Таким образом, корректно будет использовать оператор «исключающее ИЛИ» в подобных случаях:

Оператор «Исключающее ИЛИ» не может следовать после одиночного события

Дополнение модели процесса деталями

➤ Исполнители

Для обозначения исполнителя – департамента, команды или конкретной позиции в организации – необходимо использовать элементы типа «Субъект», соблюдая следующие правила.

1. Элементы субъектов должны соотноситься с помощью ненаправленного отношения (дуги) с конкретной функцией, которую они выполняют. Если используемая программа для моделирования позволяет выбрать определенный тип связи, необходимо выбрать связь типа «Выполняет».

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

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

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

5. Любые другие отношения или взаимодействия между субъектами на диаграмме бизнес-процесса в нотации eEPC изображаться не должны (обмен документами или данными, подчинение и т. д.).

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

➤ Данные и документы

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

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

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

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

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

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

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

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

➤ Другие дополнительные элементы

Помимо документов распространены следующие дополнительные элементы диаграмм eEPC.

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

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

3. Прочее может изображаться как слева, так и справа от функции, в зависимости от значения самого элемента в рамках изображаемого бизнес-процесса.

Использование интерфейсов для связывания процессов

Особым образом следует использовать элемент «Интерфейс» для указания взаимосвязи процессов. Так как интерфейс отображает на текущей диаграмме другой процесс, отличный от рассматриваемого, по правилам нотации его можно использовать так:

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

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

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

Пример части диаграммы бизнес-процесса в нотации eEPC на стр. 123.

Связь между бизнес-процессами в модели

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

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

Для наилучшего структурного описания всех функций организации и полноценного представления ее функционала в методологии ARIS предусмотрена последовательная декомпозиция функций организации: начиная с их представления на верхнем уровне, где приводится классификация бизнес-процессов и их объединение в группы, с переходом через дерево функций к разбивке этих групп на уровне перечней бизнес-процессов как таковых, и заканчивая уже детальным описанием каждого бизнес-процесса с помощью нотации eEPC. Таким образом, методология предусматривает полноценное описание организации в аспекте осуществляемой ею деятельности аналогично IDEF0. Однако воспроизводится подобное описание не с помощью одной-единственной нотации и одного типа диаграмм, а с помощью трех типов диаграмм.

Пример диаграммы процессов верхнего уровня.

Пример части диаграммы бизнес-процесса в нотации eEPC

Пример диаграммы функционального дерева – иерархической структуры процессов одного типа на стр. 125.

Особенности построения модели

Как уже упоминалось, нотация eEPC достаточно сложна для использования при моделировании и дальнейшего анализа бизнес-процессов. Такой эффект возникает из-за нескольких факторов.

1. Использование большого количества дополнительных описательных элементов.

2. Отсутствие комментариев или описания диаграммы с легендой.

3. Множество возникающих при выполнении процесса ветвлений.

4. Необходимость формального использования логических операторов для следования правилам нотации.

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

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

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

Пример диаграммы функционального дерева

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

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

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

6. Для одного типа дополнительных элементов следует использовать один рекомендованный цвет.

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

Отличия eEPC от IDEF0, сравнительный анализ

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

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

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

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

В то же время на моделях в IDEF0 не предусмотрено использование символов, представляющих логику выполнения процесса: операторов «И», «ИЛИ», «Исключающее ИЛИ». Это существенно ограничивает возможность наполнить картину процесса четким ветвлением, которое позволяет отразить влияние различных условий на выполнение процесса. Процесс в IDEF0 выглядит очень плоско и зачастую трудно читается, если аналитик постарался отразить все связи и множественные контроли и механизмы, используемые разными функциями.

Еще одна слабая сторона IDEF0 по сравнению с eEPC – неочевидность последовательности выполнения функций. Их расположение на диаграммах, а также ограничение по количеству функциональных блоков на одной диаграмме заставляет аналитиков создавать множество диаграмм, изощряться с аллокацией блоков, что делает общую картину процесса менее наглядной. Легко читать процесс сверху вниз, как это доступно при моделировании в eEPC, не получится. Соответственно, и наглядно воспроизвести имитационное моделирование с помощью IDEF0-моделей будет невозможно.

С точки зрения методологического подхода к полноценному многоуровневому описанию процессов организации, IDEF0 и ARIS примерно одинаковы по своей эффективности и наглядности. Однако необходимо учитывать, что создание всех уровней (от верхнего до наиболее детализированного) в методологии ARIS потребует знания как минимум трех нотаций (подходов к созданию диаграмм), в зависимости от уровня их детализации, и eEPC будет использоваться только на этапе максимальной детализации описываемых процессов. При этом IDEF0 в описании всех уровней детализации использует одну и ту же нотацию. Единый подход помогает снизить количество ошибок и упростить чтение диаграмм процессов.

Варианты для выбора нотаций IDEF или eEPC.

1. Если перед аналитиком стоит задача максимально детально проработать сложные и длинные процессы, то подойдет eEPC.

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

3. Если требуется описать лишь несколько несвязанных процессов, но сразу детально, то сделать это поможет eEPC.

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

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

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

Сильные и слабые стороны нотации eEPC

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

Преимущества нотации eEPC.

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

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

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

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

У eEPC есть и ряд недостатков, которые аналитику нужно учитывать при выборе нотации для моделирования процесса и в целом при выборе методологии ARIS для описания организации.

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

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

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

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

Типичные ошибки при построении модели в нотации eEPC

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

При подготовке к моделированию бизнес-процесса и проверке модели после ее создания необходимо помнить, что ошибки в модели приводят к непониманию реальной ситуации в организации и неспособности корректно определить возможности как процесса AS-IS, так и TO-BE.

Рассмотрим самые распространенные ошибки при работе в этой нотации.

Некорректное изображение самой цепочки работ.

1. Использование двух функций друг за другом. Основное правило синтаксиса при моделировании в eEPC требует, чтобы каждое действие заканчивалось каким-то состоянием системы (организации) и каждое состояние было обусловлено определенным действием.

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

Некорректное использование операторов.

1. Использование операторов «ИЛИ» и «Исключающее ИЛИ» после события. Обе ситуации запрещены, так как событие само по себе не принимает решение, какое действие выполняется. В таком случае нужно использовать оператор «И» либо добавлять два состояния на диаграмме.

2. Пропуск логических операторов в том случае, когда событие имеет две исходящие связи, или функция – две входящие связи. Это, пожалуй, самая распространенная ошибка, возникающая в ряде нотаций моделирования бизнес-процессов, где используются операторы. Для любых входящих или исходящих связей в случаях, когда их больше одной, обязательно использование одного из операторов: «И» (единственно допустимое, когда событие имеет две исходящие связи на функции), «ИЛИ», «Исключающее ИЛИ». К этой же ошибке относится и нарушение отображения обратной связи, когда из какого-либо шага n+k необходимо вернуться на шаг n, образуя цикл. В таких случаях перед функцией n для слияния связей допустимо использование только оператора «Исключающее ИЛИ».

Некорректное использование дополнительных элементов.

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

2. Смешение понятий результирующего состояния (события) и исходящего документа. У каждой функции всегда будет событие на выходе, обозначающее состояние самого процесса. Если в результате выполнения функции был подготовлен еще и документ или какая-то другая информация, это должно быть отражено отдельно от самого потока процесса.

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

Модели исполняемых процессов – нотация BPMN

Методология BPM и нотация BPMN основаны на понятии бизнес-процесса и процессном подходе.

Управление процессом в методологии BPM – это управление целым (организацией) через управление его частями (процессами).

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

Методология BPM (Business Process Management) – концепция процессного управления организацией при помощи управления бизнес-процессами.

Нотация BPMN (Business Process Model and Notation) – нотация (система условных обозначений) для построения моделей процессов на основе методологии BPM, а также исполняемых с помощью систем BPMS.

Система BPMS (Business Process Management System) – IT-система для моделирования в методологии BPM, а также автоматизации исполняемых экземпляров процессов на основе построенных BPMN-моделей.

Если проводить аналогию с наукой,

BPM – это прежде всего подход, своего рода мировоззрение.

BPMN – методы и алгоритмы решения конкретных задач. Например, набор методов для создания проекта обеспечения электричеством производства или многоквартирного дома.

А BPMS – это уже готовые прикладные решения, которые можно «включить», и они заработают. Для математики это готовые решения задач, имеющих практическое значение. Для физики – непосредственная реализация электропроводки и подключение объектов. Для сферы IT – готовый программный код.

BPMS-системы реализуют следующие возможности:

• создание, изменение, воспроизведение моделей процессов организации;

• быстрое и легкое управление последовательностью действий внутри процесса и их оптимизация;

• управления взаимодействиями между разными этапами и операциями;

• полноценный реинжиниринг процессов в организации при необходимости коренных изменений;

• сбор статистики по выполнению процессов для последующего анализа;

• выявление отклонений и задержек при исполнении процессов;

• анализ текущей деятельности организации в соответствии с поставленными для нее KPI.

Отличия процессного и функционального подходов

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

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

Существует два подхода к управлению организацией.

При этом необходимо знать:

• для стратегического планирования и оценки работы компании в целом лучше использовать функциональное моделирование и соответствующие нотации, например IDEF0. Здесь мы исходим из желаемого результата и выстраиваем последовательность функций каждого «черного ящика», необходимую для достижения результата;

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

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

Необходимо понимать следующее.

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

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

a. Если при функциональном подходе очень важны объекты на входе и выходе, то в самой функции, «черном ящике», важна обработка объектов для получения необходимого результата. И здесь управление бизнесом ориентировано на «Что именно мы хотим получить?», то есть подход скорее стратегический.

b. При процессном подходе мы получаем ответ на вопрос «Как это лучше выполнить?», то есть концентрируемся на тактическом, оперативном управлении. А потому здесь при изменении отдельных элементов между «входом и «выходом» меняется весь процесс.

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

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

Основные элементы нотации

В нотации BPMN выделяют пять главных категорий элементов.

Основные:

• элементы потока: события, процессы и шлюзы;

• соединяющие элементы: потоки управления, потоки сообщений и ассоциации;

• данные: объекты данных и базы данных.

Дополнительные:

• зоны ответственности: пулы и дорожки;

• артефакты: сноски.

Рассмотрим существующие в BPMN виды диаграмм.

1. Процесс (Process Diagram)

2. Взаимодействие (Collaboration Diagram)

3. Хореография (Choreography Diagram)

4. Диалог (Conversation Diagram)

Первые три вида диаграмм основные, а четвертый – дополнительный: он появился лишь в BPMN2.0. На практике чаще всего используют два вида: «Процесс» и «Взаимодействие». Рассмотрим назначение всех видов диаграмм.

1. Процесс (Process Diagram) описывает содержание и логику бизнес-процесса BPMN в виде потока задач, условий и событий. Это самый распространенный вид диаграмм, он применяется чаще других и является основой нотации BPMN. Пример диаграммы «Процесс»:

2. Взаимодействие (Collaboration Diagram) позволяет моделировать взаимодействие (обмен данными) между двумя или более бизнес-процессами BPMN. Для графического отображения такого взаимодействия используются потоки сообщений (message flow). Пример диаграммы «Взаимодействие»: на стр. 154.

3. Хореография (Choreography Diagram). Иногда диаграммы «Взаимодействие» оказываются слишком сложными для восприятия и требуют более наглядного представления. В этом случае применяют диаграммы «Хореография». Они описывают последовательность взаимодействий участников при выполнении бизнес-процессов.

4. Диалог (Conversation Diagram) – еще один вариант диаграммы для визуализации взаимодействий бизнес-процессов BPMN и их участников. Диаграмма «Диалог» описывает процессный ландшафт и взаимодействия верхнего уровня между вовлеченными сторонами. Пример диаграммы «Диалог»: на с. 155.

Пример диаграммы «Взаимодействие»

Пример диаграммы «Хореография»

Пример диаграммы «Диалог»

Типы связей между элементами диаграммы BPMN

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

Декомпозиция и подпроцесс

Нередко даже в профессиональной среде путают два понятия – декомпозицию и подпроцесс. Важно понимать разницу между ними.

Декомпозиция – это разложение задачи на более простые элементы. Может использоваться как в функциональном, так и в процессном моделировании.

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

Пример декомпозиции сущности А:

Для понимания работы компании в целом вы используете функциональную модель в IDEF0, где вводите понятие функции «Продажа». Для изучения работы бизнеса в целом лишние подробности не нужны: они только усложнят поиск решений.

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

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

Подпроцесс (используется в BPMN) – это отдельный процесс внутри процесса. То есть вы создаете какой-то процесс, в котором применяете блоки без детализации. Их обычно так и называют в нотации. Например, «Подпроцесс продажи».

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

Подпроцесс А внутри процесса:

Основное различие: декомпозиция допускает больше свобод, здесь вы можете совмещать различные подходы к изучению бизнеса. А подпроцесс – неотъемлемая часть BPMN-нотации. В нем еще на уровне процесса жестко заданы все точки входа, выхода, исполнители, инструменты, и вы не можете выйти за эти рамки.

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

В практике описания бизнес-процессов элемент нотации BPMN «Подпроцессы» используется в основном в двух случаях.

1. Для декомпозиции и повышения читаемости и наглядности схем (диаграмм).

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

Рассмотрим первый случай использования подпроцессов – декомпозицию процесса. Довольно часто при описании бизнес-процессов компании для наглядности используют схемы (диаграммы), отражающие верхние уровни организации работы. В этом случае диаграмма отображает суть процессов и нацелена на понимание логики процесса без знания деталей. Примером такого бизнес-процесса верхнего уровня может служить процесс «Наем персонала». На верхнем уровне этот процесс будет выглядеть так:

Такая прорисовка процесса легка для восприятия любого бизнес-пользователя, так как отображает только последовательность основных действий в рамках процесса без утяжеления какой-либо информацией. Любая схема (диаграмма) процесса – это последовательность функциональных блоков, декомпозиция которых позволяет создать процесс нижнего уровня. При этом каждый подпроцесс на более низком уровне описывается с полной детализацией элементов BPMN: активностей, условий и исполнителей.

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

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

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

Графическое изображение задачи – свернутый подпроцесс

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

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

При детализации подпроцессов приведенного примера – процесса «Наем персонала» – получим следующие процессы.

1. Поиск кандидатов на вакансию.

2. Оформление документов нового сотрудника.

3. Обучение нового сотрудника.

Рассмотрим каждый подпроцесс отдельно.

Подпроцесс «Поиск кандидатов на вакансию»

Подпроцесс «Оформление документов»

Подпроцесс «Обучение нового сотрудника»

Таким образом можно описать довольно большой бизнес-процесс компании. А теперь представьте, что все активности и исполнители процесса «Наем персонала» будут отображены в рамках одной оркестровки. Сделать это сложно, а читать процесс будет еще сложнее. Используя декомпозицию при описании сложных, но важных процессов компании, вы получаете продукт (процесс), который будет понятен любому бизнес-пользователю. Такой продукт будет легко изменять при моделировании и совершенствовании в будущем.

Правила построения модели

Для примера возьмем бизнес-процесс обеспечения заявки на потребность. Результатом будет считаться получение сотрудником заказанных товаров.

Бизнес-процесс в компании выстроен так.

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

2. Заявка проверяется на необходимость менеджером в системе.

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

4. Если заявка согласована, сотрудник отдела закупок создает заказ для поставщика. В противном случае бизнес-процесс закупки завершается.

5. После получения товаров от поставщика кладовщик приходует их и выдает сотруднику со склада заказанные наименования.

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

Нотация BPMN при моделировании бизнес-процессов позволяет самому аналитику регулировать глубину детализации в описании бизнес-процесса и выносить отдельные вещи за пределы описания.

Начало процесса, точка входа – получение заявки на потребность от сотрудника на портале организации. Точка выхода – получение заказанных товаров сотрудником. В схеме мы используем как развилки, так и подпроцессы. Например, использование подпроцесса «Зарезервировать товар» после развилки «Есть на складе» позволяет отдельно детализировать последовательность действий, которые выполняет менеджер в этом процессе.

Какие преимущества дает такое описание бизнес-процесса?

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

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

Распространенные ошибки при моделировании в нотации BPMN

Ошибки в BPMN бывают трех видов.

1. Формальные – когда диаграмма не соответствует правилам BPMN.

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

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

Рассмотрим наиболее распространенные ошибки при моделировании.

➤ События используются неправильно

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

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

На схеме на стр. 166 изображено большинство событий, используемых в схемах BPMN.

➤ Элементы ничем не заканчиваются

Формально в BPMN могут использоваться брошенные элементы:

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

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

События, используемые в схемах BPMN

➤ Перепутаны типы потоков

Иногда бывает так, что в рамках одной дорожки процесса мы видим изменение типов потоков, например:

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

НО: потоки сообщений можно использовать только за пределами пула или дорожки: они не могут находиться внутри одного пула или дорожки.

(Поток ассоциаций вообще используется только для улучшения читаемости и определяет поведение процесса.)

➤ Не сходится количество потоков на входе и на выходе

Мы можем исправить это, добавив эксклюзивный шлюз перед вторым параллельным:

➤ Не учитывается скорость выполнения зависимых процессов

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

Поэтому в подобных случаях важно обозначать обязательное условие выполнения задачи:

➤ Разный уровень задач в процессе

Это ситуация, когда на одной схеме находятся задачи абсолютно разных уровней:

➤ Использование условных потоков (conditional flow)

Страх «сложных» символов

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

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

Инструкция, а не процесс

BPMN используется для моделирования бизнес-процессов, а не инструкций для сотрудников. Здесь важно наличие задачи, а не способ выполнения:

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

То же самое касается технических процессов:

Не представляйте действие бизнеса как технологическое, пишите явно, что происходит:

➤ Одна задача для множественной обработки

В BPMN есть элементы, которые показывают итерирование по набору сущностей. Аналитики создают задачу, в названии которой пишут массовую операцию:

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

➤ Переход в межпроцессное взаимодействие там, где это не нужно

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

Такое отображение только усложняет схему и не отличается от такого:

➤ Приведение всех вариантов завершения процесса к одному завершающему событию

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

Лучше изобразить схему так:

➤ Не учитывается скорость выполнения зависимых процессов («Гонка» сигналов)

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

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

Чек-лист для моделирования процесса

Чтобы свести к минимуму количество ошибок при моделировании процесса, можно использовать следующий чек-лист.

1. Тип модели процесса определяемый и соответствует поставленной задаче моделирования.

Можно условно выделить три типа моделей процессов:

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

• имитационная – позволяет выполнять имитационное моделирование процесса для определения времени выполнения, загрузки исполнителей, стоимости результатов выполнения процесса;

• исполняемая – может быть экспортирована для автоматизации в системе класса BPMS или запущена на выполнение прямо из среды моделирования.

2. Соответствие стандартам нотации моделирования.

Необходимо проверить соответствие схемы общепринятым нотациям моделирования. Вариантов немного: IDEF0, eECP, BPMN. По-хорошему, в компании должен быть стандарт, в котором установлены требования к графическим моделям процессов. Его часто называют соглашением по моделированию. Если стандарт есть, то в данном и последующих пунктах необходимо учесть его требования.

3. Корректность формулировок названий объектов на схеме.

Объекты схемы – это документы, информация, операции процесса, субъекты (должности, роли), логические операторы (шлюзы) и прочее. Следует обратить внимание на соответствие названий стандарту моделирования. Если в нем нет требований к названиям объектов, то стоит их внести. Пример некорректной формулировки процесса: «Разработка и утверждение плана работ в случае согласования руководителем не позднее второй недели третьего месяца квартала». Думаем, не нужно объяснять, что здесь не так.

4. Корректность описания входящих и выходящих дополнительных элементов.

Входящие и исходящие дополнительные элементы могут быть информационными и материальными.

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

5. Корректность описания событий.

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

6. Отсутствие логических и содержательных ошибок.

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

7. Аккуратность исполнения схемы. Визуальная наглядность.

Стоит обратить внимание на такие моменты:

• наличие объектов одного типа, но разного размера;

• выход надписей за границы объектов;

• наложение стрелок, надписей друг на друга;

• чрезмерное количество элементов на схеме.

8. Отсутствие физической нереализуемости.

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

9. Отсутствие возвратов (переделок работы).

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

10. Отсутствие дублирования операций (прямого или косвенного).

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

11. Выявление пропущенных важных операций.

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

12. Отсутствие чрезмерного контроля.

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

13. Отсутствие узких мест («бутылочные горлышки»).

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

14. Отсутствие возвратов в прошлое.

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

15. Отсутствие смешения единичного потока и накопления (объектов обработки).

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

16. Отсутствие «процессной грыжи».

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

17. Отсутствие неоднородности масштаба операций.

Это выявляется довольно просто. Например, на одной схеме процесса представлены операции под названиями «Получить сменное задание у начальника» и «Изготовить продукцию». Первую делает мастер, а вторую выполняет весь цех численностью 30 человек.

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

Сильные и слабые стороны нотации

Плюсы использования BPM.

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

2. Графические нотации наглядны, что позволяет понять особенности процессов в компании и увидеть их слабые места.

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

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

5. Методология BPM прекрасно проработана и стандартизирована благодаря BPMN. Наличие стандартов и правил позволяет избегать ошибок при разработке и создавать в системе BPMS исполняемые нотации – готовые элементы автоматизации бизнеса.

Минусы BPM, как это часто бывает, находятся рядом с плюсами.

1. Высокая степень детализации процессов мешает восприятию работы бизнеса для стратегического планирования.

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

3. Бизнес-процесс статичен и практически не подлежит корректировкам «изнутри». Исполнитель получает четкую последовательность действий и не может проявлять инициативу. В результате любую ошибку исполнители будут повторять из раза в раз, пока разработчики не исправят ее в самом бизнес-процессе.

Модели потоков данных – нотация DFD

В отличие от IDEF0, предназначенной для проектирования систем в целом, DFD создана для проектирования информационных систем. Ориентированность этой методологии на проектирование автоматизированных систем делает ее удобным и более выгодным инструментом для построения функциональной модели TO-BE. Это может быть полезно:

• при разработке информационной системы;

• при интеграции системы;

• при миграции данных и функционала с одной системы на другую;

• в проектах, связанных с Data Management;

• в процессе построения аналитического хранилища, BI-решения.

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

Элементы DFD-диаграммы

В диаграмме выделяют четыре элемента.

1. Процесс.

Процессы, при осуществлении которых происходит изменение потока данных (обработка, трансформация и др. изменения). Как и в других диаграммах, процесс обычно прописывается с помощью глагола, например: «Отправка заполненной формы».

2. Внешняя сущность.

Сущность (объект), которая получает или отправляет данные при взаимодействии с описанным процессом.

3. Хранилище данных.

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

4. Поток данных.

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

Несколько правил построения диаграмм:

• процесс должен иметь входной и выходной поток данных;

• хранилища данных также должны иметь входные и выходные потоки данных;

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

Исторически синтаксис этой нотации применяется в двух вариантах – Гейна-Сарсона (Gane-Sarson) и Йордана (Yourdon). Различия между ними – на рисунке ниже:

Уровни DFD-диаграммы

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

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

• Концептуальный (или контекстный)

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

• Логический

Отображает логику преобразования данных каждого процесса в системе, описывает их. Видны входные, промежуточные, выходные данные в каждом процессе, который протекает от внешней сущности до хранилищ данных. В большей степени отвечает на вопрос «Что включает в себя процесс потока и обмена данными со стороны бизнеса?»

• Физический

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

Также в других источниках часто можно увидеть разделение уровней диаграммы на 0,1, 2, 3 и так далее, в зависимости от уровня детализации.

Если мы говорим про разработку нового решения, то важно понять, что мы имеем сейчас (AS-IS) и что желаем получить (TO-BE). Другими словами, мы разделяем наше текущее состояние и желаемое, которое хотим получить с помощью нашего решения.

➤ AS-IS

Описываем текущую логическую диаграмму.

➤ TO-BE

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

Модели потоков данных – нотация UML

Понятие объектно-ориентированного анализа

Объектно-ориентированный (далее – ОО) анализ – метод анализа, который исследует требования к системе с точки зрения классов и объектов, относящихся к словарю предметной области. Определение дано в соответствии с трудами Г. Буча.

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

В одной из основополагающих книг «Объектно-ориентированный анализ и проектирование» (1991 г.) Майкл Блаха и Джеймс Рамбо определяют ОО-подход как метод, при котором мы рассматриваем систему в виде набора отдельных объектов, включающих в себя одновременно структуру данных и «поведение» (операции).

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

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

Различие структурного и объектно-ориентированного подходов

Авторы выделяют стадии моделирования, на которых применяется ОО-подход.

1. Анализ. На этой стадии объекты относятся к области применения, а не к информационным системам. Модель не зависит от конкретного внедряемого решения.

2. Дизайн системы. Выстраивается высокоуровневая архитектура решения, целевая система разбивается на подсистемы, определяются требования к производительности.

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

4. Внедрение. На этом этапе модель приводится в соответствие с конкретным языком программирования, выбранной БД и инфраструктурой.

Модели OO-анализа в дальнейшем преобразуются в объектно-ориентированный проект. Г. Буч дает следующее определение объектно-ориентированного проектирования (дизайна): это методология проектирования, соединяющая в себе процесс объектной декомпозиции и приемы представления логической (структуры классов) и физической (архитектура модулей и процессов), а также статической и динамической моделей проектируемой системы.

Цель ОО-проектирования – правильно и эффективно структурировать сложную систему для последующей разработки.

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

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

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

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

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

Более подробно о понятии объекта и о том, как выделять сущности, читайте у основоположников. Вы найдете ссылку на материал в «Используемых источниках» – Буч, Рамбо, Блаха.

Основные принципы объектной модели

1. Абстрагирование – способ выделить набор значимых характеристик объекта методом исключения из рассмотрения незначимых.

2. Инкапсуляция – свойство системы, позволяющее объединить данные и методы, работающие с ними, в классы и скрыть детали реализации от пользователя.

3. Полиморфизм – свойство системы использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта.

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

Далее мы еще поговорим о классах и отношениях между ними.

Язык UML

Унифицированный язык моделирования (Unified Modeling Language) – язык визуального моделирования (чаще всего для ОО-анализа). Основная идея UML – возможность моделировать программное обеспечение и другие системы, такие как наборы взаимодействующих объектов.

UML – это язык, первичным же остается процесс ОО-анализа и моделирования. Используя доступные на рынке CASE-средства, позволяющие работать на языке UML, вы можете создавать модели. UML служит для «сверки часов», чтобы разные аналитики понимали друг друга.

Применение UML

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

2. Язык UML как средство проектирования нацелен на полноту. Задача – построить детальную модель для программиста. Такая модель должна быть достаточно полной в части заложенных проектных решений, чтобы программист мог следовать им прямо, не особо задумываясь над дополнительными аспектами. Детальное проектирование можно использовать только для части системы или проекта, если это необходимо. При разработке моделей необходимо учитывать:

a. выбранный инструментарий: контроль версий, репозиторий объектов, связь между диаграммами;

b. глубину проработки модели и ее полноту: цель – минимизировать программирование, свести его к простым действиям.

3. Еще более глубоких знаний и больших усилий требуют проекты, в которых UML используется в качестве языка программирования. Существуют инструменты, позволяющие на основе диаграмм скомпилировать исполняемый код (программу), например Visual Paradigm. Часто в этом контексте упоминают термин MDA (Model Driven Architecture – архитектура, управляемая моделью). Этот стандарт находится под управлением группы OMG, как и сам UML.

MDA разделяет процесс разработки на две основные части. Сначала аналитики создают PIM (Platform Independent Model – модель, не зависящая от платформы). PIM – это модель UML, не зависящая от какой-то конкретной технологии. Затем инструменты могут превратить PIM в PSM (Platform Specific Model – модель, зависящая от платформы). PSM – это модель системы, нацеленная на определенную среду выполнения. Другие инструменты берут PSM и генерируют код для этой платформы. В качестве PSM можно использовать UML, но это не обязательно.

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

Из чего состоит UML

Язык UML в своем нынешнем состоянии определяет нотацию и метамодель.

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

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

UML 2.0 описывает типы диаграмм. Давайте рассмотрим основные.

➤ Структурные диаграммы

Структурные диаграммы – статический аспект системы.

Эти статические части представлены классами, интерфейсами, объектами, компонентами и узлами.

1. Диаграмма классов (Class diagram).

2. Диаграмма объектов (Object diagram).

3. Диаграмма компонентов (Component diagram).

4. Диаграмма развертывания (Deployment diagram).

➤ Поведенческие диаграммы

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

В UML есть следующие типы поведенческих диаграмм.

1. Диаграмма вариантов использования (прецедентов) (Use case diagram).

2. Диаграмма последовательности (Sequence diagram).

3. Диаграмма сотрудничества (Collaboration diagram).

4. Диаграмма состояний (State diagram).

5. Диаграмма деятельности (Activity diagram).

Унифицированный процесс разработки (Unified Process)

Когда говорят о UML, часто упоминают RUP (Rational Unified Process – унифицированный процесс, созданный компанией Rational). Он не имеет особого отношения к UML, хотя тоже создавался сотрудниками фирмы Rational и в его названии есть слово «унифицированный». Язык UML можно использовать с любыми процессами, которые не рассматриваются в этом уроке. RUP – это коммерческий продукт, расширяющий UP.

Унифицированный процесс разработки ПО (Unified Software Development Process, USDP) – это SEP, процесс производства ПО (Software Engineering Process) от авторов UML. Обычно его называют унифицированным процессом, или UP. Это универсальный процесс разработки ПО, который должен настраиваться для определенной организации и для каждого конкретного проекта.

Следует заметить, что UML был стандартизован OMG, а UP – нет, поэтому до сих пор не существует стандартного процесса для UML.

UP базируется на трех аксиомах. Он:

• управляется требованиями и риском;

• архитектуроцентричный;

• итеративный и инкрементный.

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

• определение требований – сбор данных о том, что должна делать система;

• анализ – уточнение и структурирование требований;

• проектирование – реализация требований в архитектуре системы;

• реализация – построение программного обеспечения;

• тестирование – проверка, в результате которой выявляется, отвечает ли реализация предъявляемым требованиям.

Структура UP

Основные принципы моделирования

Рассмотрим основные рекомендации для ОО-проектирования на UML. Этот список можно расширять бесконечно. Но это именно то, из чего постепенно складывается ваш опыт проектирования на UML.

1. Не спешите строить диаграмму классов. Сначала поймите проблему, которую необходимо решить.

2. Старайтесь делать модель простой, без излишних усложнений.

3. Осторожно выбирайте названия классов, атрибутов и ассоциаций.

4. Не спешите выбирать отношение генерализации, потому как зачастую его можно представить другим способом, декомпозировав задачу.

5. Не старайтесь сразу обозначить множественность для ассоциаций.

6. Используйте квалификатор для ассоциаций между классами, где это возможно.

7. Используйте абстрактные классы для возможности повторного использования кода.

8. Обращайтесь к паттернам проектирования.

9. Проводите ревизию модели. Уточнения могут возникать на любом этапе проекта.

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

11. Старайтесь создать гибкое решение и модель для повышения устойчивости к изменениям.

➤ Классы и отношения между ними

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

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

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

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

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

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

Пример диаграммы классов

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

1. Символ «+» обозначает атрибут с областью видимости типа «общедоступный» (public). Атрибут с этой областью видимости доступен или виден из любого другого класса пакета, в котором определена диаграмма.

2. Символ «#» обозначает атрибут с областью видимости типа «защищенный» (protected). Атрибут с такой областью видимости недоступен или не виден для всех других классов, за исключением подклассов этого класса.

3. И, наконец, знак «-» обозначает атрибут с областью видимости типа «закрытый» (private). Атрибут с этой областью видимости недоступен или не виден для всех классов без исключения.

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

Рассмотрим варианты задания кратности атрибутов.

1. [0..1] означает, что кратность атрибута может принимать значение 0 или 1. При этом 0 означает отсутствие значения для данного атрибута.

2. [0..*] означает, что кратность атрибута может принимать любое положительное целое значение, большее или равное 0. Эта кратность может записываться в более короткой форме – в виде простого символа [*].

3. [1.:*] означает, что кратность атрибута может принимать любое положительное целое значение, большее или равное 1.

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

Операция (operation) – это сервис, предоставляющий каждый экземпляр класса по определенному требованию. Совокупность операций характеризует функциональный аспект поведения класса. Запись операций класса в языке UML также стандартизована и подчиняется определенным синтаксическим правилам. При этом каждой операции класса соответствует отдельная строка, которая состоит из квантора видимости операции, имени операции, выражения типа возвращаемого операцией значения и, возможно, строки-свойства этой операции.

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

Базовые отношения (связи) в языке UML:

• отношение зависимости (dependency relationship);

• отношение ассоциации (association relationship);

• отношение обобщения (generalization relationship);

• отношение реализации (realization relationship).

Для начала, пока вы не определили детали, используйте отношение ассоциации.

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

Отдельный класс ассоциации играет определенную роль в соответствующем отношении, которую можно изобразить графически на диаграмме классов. С этой целью в языке UML вводится в рассмотрение специальный элемент – конец ассоциации (Association End), который графически соответствует точке соединения линии ассоциации с отдельным классом. Конец ассоциации – часть ассоциации, но не класса. У каждой ассоциации два или больше концов. Наиболее важные свойства ассоциации указываются на диаграмме рядом с этими элементами и должны перемещаться вместе с ними.

Для любого отношения, кроме зависимости, принято указывать кратность отдельного класса. Кратность обозначается в виде интервала целых чисел, аналогично кратности атрибутов и операций классов. Интервал записывается рядом с концом ассоциации и для N-арной ассоциации означает потенциальное число отдельных экземпляров или значений кортежей этой ассоциации, которые могут иметь место, когда остальные N‐1 экземпляров или значений классов фиксированы. Кратность для отношения определяется аналогично кратности атрибутов (см. выше).

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

Отношение композиции – частный случай отношения агрегации. Это отношение служит для выделения специальной формы отношения «часть – целое», при которой составляющие части находятся внутри целого. Специфика взаимосвязи между ними заключается в том, что части не могут выступать в отрыве от целого; с уничтожением целого уничтожаются и все его составные части.

Отношение обобщения (генерализации) – обычное таксономическое отношение между более общим элементом (родителем, или предком) и более частным или специальным элементом (дочерним, или потомком).

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

Диаграммы последовательностей

Диаграммы последовательностей (sequence diagram) описывают отношения объектов в различных условиях. Это разновидность диаграмм взаимодействия языка UML, которая широко используется в качестве эскизов: например, на рабочих встречах при обсуждении задач по разработке информационных систем.

Можно использовать диаграммы последовательностей при проектировании новых или при анализе и рефакторинге старых систем.

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

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

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

Общая схема диаграммы последовательности

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

Линия жизни объекта (object lifeline) – вертикальная линия на диаграмме последовательности, которая представляет существование объекта в течение определенного периода времени.

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

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

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

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

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

➤ Типы сообщений

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

2. Асинхронные сообщения – передача такого сообщения обычно не сопровождается получением фокуса управления объектом-получателем.

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

4. Найденное сообщение (found message) – у первого сообщения нет участника, который его послал, поскольку оно приходит из неизвестного источника.

5. Потерянное сообщение (lost message) – сообщение, для которого существует событие передачи и отсутствует событие приема. Изображается в форме небольшого черного круга на конце стрелки сообщения. Оно интерпретируется как сообщение, которое никогда не достигнет своего места назначения.

➤ Правила построения диаграмм последовательностей

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

2. Помните, что диаграмма должна оставаться читаемой.

3. Чрезмерное ветвление использовать не рекомендуется, так как для изображения деталей алгоритмов в языке UML есть диаграммы деятельности. Общее правило – визуализировать каждый поток управления на отдельной диаграмме последовательности.

Фреймы взаимодействия

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

Пример отображения фреймов взаимодействия

1. alt – несколько альтернативных фрагментов (alternative). Выполняется только тот фрагмент, условие которого истинно.

2. opt – необязательный (optional) фрагмент. Выполняется, только если условие истинно. Эквивалентен alt с одной веткой.

3. par – параллельный (parallel). Все фрагменты выполняются параллельно. Например, система уведомляет параллельно всех трех подписчиков, и все они параллельно и независимо друг от друга начинают работать.

4. loop – цикл (loop). Фрагмент может выполняться несколько раз.

5. region – критическая область (critical region). Фрагмент может иметь только один поток, выполняющийся за один прием.

6. neg – отрицательный (negative) фрагмент. Обозначает неверное взаимодействие.

7. ref – ссылка (reference). Ссылается на взаимодействие, определенное на другой диаграмме. Фрейм рисуют, чтобы охватить линии жизни, вовлеченные во взаимодействие. Позволяет определять параметры и возвращать значение. Фрейм ref может показывать предусловия, то есть требования, которые необходимо выполнить перед началом выполнения действий.

8. sd – диаграмма последовательности (sequence diagram). Используется для очерчивания всей диаграммы последовательности, если это необходимо.

Пример построения диаграммы последовательностей

Диаграмма прецедентов (use case)

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

Безусловно, не только use case-диаграмма используется для определения требований. В частности, описание вариантов использования не относится к нефункциональным ограничениям: производительности, надежности и т. п.

Прецеденты – лучший выбор для фиксирования требований в тех случаях, когда:

• в системе преобладают функциональные требования;

• в системе много типов пользователей, которым она предоставляет разные функциональные возможности (много акторов);

• в системе много интерфейсов.

Диаграммы вариантов использования позволяют:

• определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы;

• сформулировать общие требования к функциональному поведению проектируемой системы;

• разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей;

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

➤ Элементы диаграммы прецедентов

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

Далее следует определить акторов (кто или что использует систему) и функции, которые предоставляет для них система (варианты использования или прецеденты).

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

Прецедент – то, что должна делать система. Это «вариант использования» системы конкретным актором:

• прецеденты всегда инициируются актером;

• прецеденты всегда описываются с точки зрения актеров.

Моделирование прецедентов, как и системы в целом, – это итеративный процесс. Вначале описывается концепция в целом, затем добавляются детали.

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

Один прецедент может охватывать множество отдельных функциональных требований, и одно функциональное требование может появляться в нескольких разных прецедентах. CASE-средства для моделирования на UML позволяют ассоциировать список требований с каждым прецедентом, и наоборот.

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

➤ Виды отношений между акторами и вариантами использования

Пример построения диаграммы прецедентов

Диаграмма деятельности (activity)

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

Эта диаграмма очень похожа на диаграмму состояний (state diagram), но имеет немного другую семантику. По сути, это блок-схема. Каждое состояние на диаграмме деятельности соответствует выполнению некоторой элементарной операции, а переход в следующее состояние срабатывает только при завершении этой операции в предыдущем состоянии.

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

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

➤ Элементы диаграммы деятельности

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

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

Пример построения диаграммы деятельности

Диаграмма компонентов (component)

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

На диаграмме компонентов можно показать компоненты, зависимости между ними и то, как компонентам назначаются классификаторы.

Диаграмму компонентов разрабатывают для следующих целей.

1. Визуализация общей структуры исходного кода программной системы.

2. Спецификация исполняемого варианта программной системы.

3. Обеспечение многократного использования отдельных фрагментов программного кода.

4. Представление концептуальной и физической схем баз данных.

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

Компоненты могут иметь атрибуты и операции, участвовать в отношениях ассоциации и обобщения.

Пример внутренней структуры компонента

В языке UML для компонентов определены различные стереотипы.

1. Библиотека (<<library>>) определяет первую разновидность компонента, который представляется в форме динамической или статической библиотеки.

2. Таблица (<<table>>) также определяет первую разновидность компонента, который представляется в форме таблицы базы данных.

3. Файл (<<file>>) определяет вторую разновидность компонента, который представляется в виде файлов с исходными текстами программ.

4. Документ (<<document>>) также определяет вторую разновидность компонента, который представляется в форме документа.

5. Исполняемый (<<executable>>) определяет третий вид компонента, который может исполняться в узле.

6. Сервис (<<service>>) – функциональный компонент без состояния, вычисляющий значение.

7. Подсистема (<<subsystem>>) – подсистема, элемент для декомпозиции больших систем.

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

Пример построения диаграммы компонентов

Диаграмма компонентов, как правило, разрабатывается одновременно с диаграммой развертывания.

Диаграмма развертывания (deployment)

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

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

Важно отметить, что на диаграммы развертывания выносятся не все детали физического развертывания, а только те, которые необходимы для понимания архитектуры системы. Исключение – проекты, в которых программный код генерируется на основе UML-модели (MDA).

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

Существует две формы диаграмм развертывания.

1. Дескрипторная форма (descriptor form) содержит узлы, отношения между узлами и артефакты. Используется для моделирования типа физической архитектуры.

2. Экземплярная форма (instance form) включает экземпляры узлов, отношения между экземплярами узлов и экземпляры артефактов. Используется для моделирования фактического развертывания этой архитектуры на конкретном сайте. Экземпляры узлов – это определенная и идентифицируемая часть оборудования, например ПК какого-либо сотрудника. Экземпляр артефакта – это конкретный экземпляр типа ПО, например определенная копия антивируса. Если детали конкретных экземпляров неизвестны или неважны, можно использовать анонимные экземпляры.

Существует два стандартных стереотипа для узлов:

• device (устройство) – узел, представляющий тип физического устройcтва, например ПК или сервер;

• execution environment (среда выполнения) – узел, представляющий тип среды выполнения программного обеспечения, например веб-сервер Apache.

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

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

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

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

Пример построения диаграммы развертывания

➤ Типы диаграмм Flowchart

Блок-схемы варьируются от незамысловатых, нарисованных вручную, до подробных, составленных на компьютере диаграмм с множеством шагов и процессов. Если учесть все возможные вариации, блок-схемы можно признать одним из самых распространенных видов схем во всем мире. Они широко используются в разных сферах как технической, так и бизнес-направленности. Иногда блок-схемы получают более узкоспециальные названия, например «схема процесса», «схема рабочего процесса», «функциональная блок-схема». Однако для изображения бизнес-процессов используются только два основных типа диаграмм, изображающих последовательности.

1. Простая диаграмма процесса (Flowchart) изображает процесс и составляющие его начало, окончание, шаги и решения без уточнения переходов выполнения тех или иных работ от одного исполнителя к другому.

Пример простой диаграммы (блок-схемы) процесса

2. Диаграмма кросс-функционального процесса (Swimlane Flowchart) показывает последовательное выполнение процесса от начала до конца, а также исполнителей тех или иных шагов процесса. Она отображает на схеме действия в разных дорожках, которые объединяют шаги процесса под одним ответственным исполнителем. «Плавательные дорожки» расположены либо по горизонтали, либо по вертикали и используются для группировки процессов или задач в соответствии с обязанностями этих ресурсов, ролей или отделов.

Пример блок-схемы кросс-функционального процесса

➤ Основные элементы нотации

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

Рассмотрим основные элементы нотации Basic Flowchart.

Терминатор применяется для обозначения начальной и конечной точек блок-схемы, в том числе возможного результата того или иного пути развития процесса, если он ветвится. Внутри блока, как правило, располагается слово «Начало» или «Конец» для обозначения рамок процесса на диаграмме.

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

Решение – элемент, символизирующий вопрос, на который требуется ответ, – как правило, «да/нет» или «истина/ложь». Далее процесс разделяется на несколько ветвей в зависимости от количества ответов. В отличие от BPMN и eEPC, нотация Flowchart не указывает для решения, какую именно опцию ветвления процесса оно несет. В этой нотации решение лишь разделяет процесс, не собирая несколько ветвей в одну. Особенного элемента для этого в нотации Flowchart не предусмотрено.

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

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

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

Данные (ввод/вывод) – элемент, используемый для отображения данных. В частности, он подразумевает некоторое действие по преобразованию данных в форму, пригодную для их использования в действии (процессе), ввод или вывод этих данных из процесса. Обычно использование этого элемента означает ввод или вывод данных в какие-либо процессные интерфейсы.

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

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

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

Дорожка (swimlane) или исполнитель – элемент-прямоугольник, который используется в качестве поля для отображения и группировки всех шагов процесса, выполняемых конкретной ролью или отделом, а также именования ответственного исполнителя.

➤ Дополнительные элементы нотации

Помимо основных элементов нотации Flowchart, которые составляют основу моделирования бизнес-процесса (при использовании нотации Basic Flowchart используются только они), есть дополнительные элементы. Они позволяют расширить схему, добавив в нее детали.

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

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

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

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

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

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

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

➤ Правила построения модели в нотации Flowchart

Так как Flowchart относится к нотациям типа Workflow, для нее, как и для eEPC и BPMN, характерны общие правила построения модели. Они очень просты.

1. При изображении процесса обязательно использование только одного терминатора-начала. Количество терминаторов-окончаний процесса может быть любым. Терминаторы обычно именуются «Начало» и «Конец».

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

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

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

5. Стрелки, соединяющие элементы, должны отображать:

a. направление основного потока выполнения процесса от терминатора-начала через все необходимые элементы и шаги ко всем терминаторам-окончаниям;

b. обозначение входа или выхода дополнительного элемента по отношению к действию или вводу/выводу данных.

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

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

7. Для кросс-функциональных блок-схем на диаграмме обязательно наличие:

a. одного бассейна процесса (пула), который обозначает сам процесс и именует его кратко и емко;

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

c. переключения блоков процесса между различными дорожками-исполнителями. Связь шагов разных исполнителей осуществляется обычным образом – при помощи стрелки с направлением от шага, выполняемого раньше по процессу, к шагу, выполняемому после него. Если переключать процесс между исполнителями не нужно, то нет никаких оснований для выбора типа диаграммы Swimlane Flowchart.

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

9. Как следует из пункта 7 и сути нотации Workflow, декомпозиция по уровням уточнения процессов не используется. Модель в нотации Flowchart сразу изображается на определенном уровне, обычно самом детальном. В случае необходимости процесс делится на последовательные крупные шаги-листы – отдельные диаграммы, именуемые в соответствии с их наполнением.

Пример модели, изображающей процесс подбора поставщика на простой диаграмме Flowchart на стр. 212.

Пример модели, изображающей процесс подбора поставщика на простой диаграмме Flowchart

➤ Особенности моделирования в нотации Flowchart

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

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

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

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

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

Помимо этого использование нотации Flowchart характеризует простота поиска инструментов для моделирования. Сегодня есть много доступных программ, которые подойдут для описания процессов с помощью блок-схем. Для моделирования в этой нотации можно использовать и графические редакторы, даже MS Word. Почти полное отсутствие правил моделирования в нотации предполагает, что при работе с ней вам не понадобятся специальные проверки синтаксиса модели, а базовые элементы вы сможете графически изобразить почти в любом приложении для записей. Тем не менее такая особенность использования Flowchart облегчает лишь задачу создания одной-двух моделей для кратковременного использования или добавления в какую-либо презентацию или документ. Масштабное же использование в компании блок-схем без современного средства моделирования неэффективно, так как не позволяет унифицировать:

1. формат файлов, в которых будут храниться диаграммы. При массовой их обработке потребуется много времени на ручную работу и предварительную подготовку;

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

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

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

• заранее разработать и задокументировать, а далее поддерживать в актуальном состоянии:

⸰ внутренний стандарт использования этой нотации для команды аналитиков;

⸰ внутренний стандарт формирования, хранения и актуализации файлов со схемами процессов;

• проводить ознакомление всех новых членов команды аналитиков с этими стандартами;

• регулярно контролировать следование стандартам для обеспечения консистентности портфолио моделей.

➤ Сильные и слабые стороны нотации Flowchart

Блок-схемы по праву считаются одним из наиболее универсальных способов пошагового описания какой-либо последовательности. Именно поэтому Flowchart так часто применяют для моделирования бизнес-процессов. Хотя для кого-то название Flowchart кажется чем-то особенным, а блок-схема навевает воспоминания о классическом инженерном образовании, сейчас эта нотация очень распространена благодаря своим сильным сторонам.

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

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

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

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

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

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

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

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

Соответствие нотаций уровням бизнес-процессов

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

Уровень 0 – процесс верхнего уровня в нотации IDEF0

Первый уровень декомпозиции – процессы модели А‐0 в нотации IDEF0

Второй уровень декомпозиции – процессы модели А‐1 в нотации FlowChart

Основные цели и этапы моделирования бизнес-процессов

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

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

➤ Описание процессов

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

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

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

➤ Установление взаимосвязей в процессах

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

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

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

➤ Нормирование и приведение процессов к желаемому состоянию

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

Моделирование бизнес-процессов задает правила их выполнения, то есть описывает то, каким образом они должны быть выполнены. Если следовать установленным в моделях правилам, руководящим указаниям или требованиям, то можно достичь желаемой производительности процессов. Именно поэтому, чтобы достичь определенных показателей эффективности, выполняются отдельные проекты с целями типа «оптимизировать деятельность организации и / или производство продукта /сервиса для сокращения расходов / увеличения производительности / повышения прибыльности организации». В рамках бизнес-анализа для таких проектов обычно проводят подготовку и анализ текущего состояния процесса (AS-IS), имитационное моделирование и / или тестирование процесса (business process validation), производят поиск дефектов, а эксперты предлагают и выбирают возможные пути их устранения. В ряде ситуаций процесс корректируют и на выходе получают новую версию процесса (TO-BE).

Однако в зависимости от задач, которые встают перед организацией, помимо проектов улучшения существующих процессов создаются также проекты с целями типа «начать выпускать новый продукт и/или предоставлять новый для компании сервис и/или подчинить деятельность компании изменениям в законодательстве/новым тенденциям». В таких случаях сразу после создания моделей AS-IS следует разработка моделей процесса TO-BE. Они демонстрируют состояние процесса, которое позволит организации достичь цели проекта. Проводится анализ различий этих двух состояний, составляется план по переходу из состояния AS-IS в TO-BE, а также критерии для оценки того, что переход состоялся успешно и состояние TO-BE действительно позволило организации достичь поставленной цели.

В обоих случаях моделирование дает возможность получить «внешний» взгляд на процессы и определить необходимые улучшения или изменения, введение которых повысит эффективность процессов или приведет к получению нового продукта благодаря работе с моделями процесса в двух его состояниях: AS-IS и TO-BE.

➤ Этапы моделирования

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

1. Выявление бизнес-процессов и построение исходной модели «Как есть» (AS-IS). Чтобы зафиксировать процесс в описании, проследить необходимые взаимосвязи или улучшить процесс, в первую очередь нужно понять, как он работает в данный момент. На этой стадии определяются границы процесса, выявляются его ключевые элементы, собираются данные о шагах процесса. В результате создается исходная модель процесса AS-IS. Эта модель не всегда полностью отражает работу и логику процесса, поэтому ее можно назвать первым драфтом или исходной моделью AS-IS.

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

3. Разработка модели «Как должно быть». В зависимости от подхода и цели проекта после анализа существующей ситуации необходимо определить желаемое состояние процесса или провести анализ существующей ситуации на предмет дефектов, выделить их и разработать модель, в которой эти дефекты будут устранены. Это желаемое состояние в модели представляется «Как должно быть» (TO-BE). Такая модель показывает, как процесс должен выглядеть в будущем со всеми необходимыми улучшениями или изменениями.

4. Тестирование и применение модели TO-BE. Эта стадия моделирования связана с внедрением разработанной модели TO-BE в практику деятельности организации. После того как новая версия процесса прошла апробацию, повторно оценивается ее эффективность и возможные выявленные проблемы. На основании этого в модель вносятся необходимые изменения, и финальная модель TO-BE готова.

5. Улучшение модели TO-BE и/или проектирование целевого состояния процесса. Моделирование бизнес-процессов не ограничивается только созданием модели TO-BE. Каждый из процессов по ходу работы продолжает изменяться и совершенствоваться. Если организация в обозримой перспективе планирует завершить все изменения и на первом этапе внедряет только основное и главное, то разрабатывается модель целевого состояния процесса. Помимо этого, модели процессов должны регулярно пересматриваться и улучшаться в течение жизни организации. Таким образом, эта стадия моделирования предполагает постоянное улучшение процессов и постановку целевого состояния бизнес-процесса при наличии известных для этого требований.

Теперь вернемся к дефектам процессов и перечислим этапы работ по анализу и моделированию, на которых происходит поиск слабых мест. Это поможет лучше понять, что же обычно ищут бизнес-аналитики в версии бизнес-процессов AS-IS, чтобы улучшить деятельность компании и повысить ее эффективность.

Дефекты бизнес-процессов

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

➤ Узкие места

Понятие «бутылочное горлышко» (от англ. bottleneck) или более привычный для нас вариант «узкое место» – центральный элемент теории ограничений систем (TOC) Элияху Голдратта и один из столпов концепции бережливого производства Lean. По сути, узкое место – это место в производственной системе или процессе, в котором возникает перегрузка. Поток материалов или любой другой входящий поток поступает слишком быстро и не может быть столь же быстро переработан. Часто это шаг с меньшей мощностью, чем предыдущий узел. Он похож на узкое горлышко бутылки, которое замедляет путь жидкости наружу. На производстве и в любых других процессах эффект бутылочного горлышка вызывает простои и издержки, снижает общую эффективность и увеличивает сроки выполнения всего процесса.

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

➤ Процесс «Продажи»

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

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

Все узкие места можно разделить на две группы.

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

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

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

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

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

2. Моделирование процесса AS-IS и выполнение экземпляров процессов (имитация реального выполнения процесса на различных входных условиях). На этом этапе используются моделеры и BPMS-системы. Они помогают собрать дополнительную информацию о процессе на основе истории его выполнения и «проиграть» тот или иной сценарий развития событий с помощью модели, заранее заданных частот попадания процесса в ту или иную ветвь или частот событий, а также различных наборов входных данных. Такое проигрывание процесса обычно визуализируется в системе, и прогресс выполнения отдельного экземпляра процесса изображается в формате токенов, «путешествующих» по модели. При таком подходе аналитик также может наглядно увидеть, на какой этап приходится ожидание того или иного токена, какие циклы выполняются по нескольку раз, а где токены собираются в очередь, потому что шлюз или условие принимает решение по каждому из них, и т. д.

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

Пример сбора и анализа показателей бизнес-процесса с помощью электронных таблиц Excel

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

Пример сбора несоответствий при выполнении бизнес-процесса

Проблемы логики бизнес-процесса

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

Наиболее частые проблемы логики процесса следующие.

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

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

3. Зависимый процесс не синхронизирован с основным. Ситуация, когда один из шагов зависимого процесса требует некоторого сигнала или сообщения от главного процесса, при этом сигнал или сообщение поступает слишком рано или слишком поздно. Это не позволяет выполнить шаг зависимого процесса.

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

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

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

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

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

Проверка бизнес-процесса на наличие слабых мест и дефектов

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

Проверка бизнес-процессов (Business Process Verification) – это проверка того, что набор сквозных бизнес-процессов функционирует должным образом. Если в одном или нескольких бизнес-приложениях, поддерживающих бизнес-процесс, или в интеграции или настройке этих систем есть проблемы, то последствия нарушений могут сказываться как на отдельных процессах, так и на всей эффективности работы компании. В критических ситуациях компания может оказаться не в состоянии принимать заказы или отправлять продукт, а это напрямую повлияет на доход, репутацию компании и удовлетворенность клиентов. Это также может привести к дополнительным расходам, так как устранение производственных дефектов обходится значительно дороже, когда они выявляются слишком поздно. Ключевая цель проверки бизнес-процессов – это раннее выявление дефектов, до изменения каких-либо процессов или их внедрения с нуля в производственную среду. Это позволит исключить негативное влияние на существующий бизнес и свести к минимуму затраты на устранение дефектов.

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

Валидация бизнес-процессов может выполняться в различных ситуациях.

1. В рамках проекта изменения текущих или внедрения новых бизнес-процессов, когда запуск определенных версий процессов и систем, их выполняющих, производится впервые.

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

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

➤ Подходы к валидации бизнес-процессов

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

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

Автоматизированная проверка бизнес-процессов выполняется специальным ПО или модулями BPMS-систем для тестирования процессов в автоматическом режиме. ПО использует стандартные наборы данных бизнес-процесса, имитирует работу эксперта, запускает механизмы и воспроизводит аварии, интерпретирует правильность каждой последовательности действий и их результатов. При этом дефекты могут быть распознаны только в том случае, если для каждого шага и результата процессов определены ожидаемые значения. Фактические результаты выполнения процесса в таком случае сравниваются с установленными нормативами. При использовании ПО BPV или модулей тестирования BPMS бизнес-процесс сначала должен быть зафиксирован в системе, выполняющей проверку, в формате описания последовательностей шагов или модели процесса. Для процесса должны быть установлены нормы и KPI, введены данные для выполнения имитационных «прогонов».

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

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

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

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

➤ Улучшение, оптимизация и реинжиниринг бизнес-процесса: определения и методы

Улучшение, или совершенствование бизнес-процесса, – совокупность методов и подходов, которые дают руководителям компании возможность повысить эффективность ее работы. Как следует из наименования процедуры, также иногда называемой менеджментом бизнес-процессов, ее цель – улучшение бизнес-процессов, которое помогает сделать их более эффективными («Руководство по улучшению бизнес-процессов», Альпина Паблишер, М.: 2022.).

Формальные методики и стандарты совершенствования бизнес-процессов.

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

2. Всеобщее управление качеством (Total Quality Management, TQM) – стратегия менеджмента, которая направлена на внедрение заботы о качестве в каждый шаг и процесс, осуществляемый в организации, а также на всемерное поощрение действий сотрудников, ориентированных на повышение удовлетворенности клиентов и снижение издержек в рамках процесса.

3. ISO 9000 – серия стандартов систем управления качеством (ISO). Эти стандарты и изменение процессов согласно им не гарантируют качество конечного товара или услуги. Они просто подтверждают, что компания использует сертифицированные бизнес-процессы, которые соответствуют общепринятым или отраслевым стандартам. Сами стандарты ISO 9000 находятся в ведении структур, отвечающих за аккредитацию и сертификацию организаций.

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

5. Реинжиниринг бизнес-процессов – целенаправленное изменение шагов процесса, иногда коренным образом, цель которого – выпуск нового продукта или предоставление нового сервиса, а также соответствие новым стандартам или законодательству.

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

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

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

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

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

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

• дополнительные ручные проверки;

• согласования;

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

• дублирующие действия.

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

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

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

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

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

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

7. Объединение операций во времени и/или пространстве. Обычно объединение нескольких шагов проводится для того, чтобы избежать лишних издержек на координацию использования результатов, которые должны быть совместно задействованы в дальнейшем процессе. Также объединение упрощает логистику, то есть перенос результатов одного и второго действия в единое место для дальнейшего совокупного использования. Такой прием позволяет не только сократить стоимость и время выполнения блока процесса, но и в некоторых случаях создает новые возможности, благодаря синергии. Это «усиливающий эффект взаимодействия двух или более факторов, характеризующийся тем, что совместное действие этих факторов существенно превосходит простую сумму действий каждого из указанных факторов» («Википедия»).

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

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

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

Стремительный взлет этой методики пришелся на начало 1990-х годов, когда Майкл Хаммер и Джеймс Чампи опубликовали свой революционный бестселлер «Реинжиниринг корпорации». Реинжиниринг бизнес-процессов используется в тех случаях, когда принято обоснованное решение о реорганизации деятельности: радикальных преобразованиях, реструктуризации бизнеса, замене действующих структур управления на новые. А с учетом быстрого развития экономики, конкуренции и технологий предприятие, стремящееся выжить или улучшить свое положение на рынке, должно постоянно совершенствовать технологии производства, набор производимых продуктов и способы организации деловых процессов. Именно на волне роста и развития экономик реинжиниринг как методика стал основным подходом к достижению необходимых изменений в организации.

В отличие от оптимизации бизнес-процессов, проект реинжиниринга бизнеса обычно включает четыре этапа.

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

2. Анализ существующего бизнеса. На этом этапе проводится исследование текущего состояния организации, составляются модели бизнес-процессов AS-IS.

3. Разработка нового образа бизнеса. В соответствии с поставленной целью создаются новые и/или изменяются прежние бизнес-процессы (подготавливаются модели TO-BE), при необходимости разрабатываются требования и спецификации на поддерживающие их информационные системы.

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

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

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

2. Горизонтальное сжатие бизнес-процессов. Сравнительные оценки, выполненные компаниями, которые провели реинжиниринг, показывают: в ряде случаев переход от традиционной организации работ с разделением обязанностей и менеджментом для координации действий к выполнению всего процесса одним человеком позволяет снизить численность персонала и ускорить выполнение процесса примерно в 10 раз. При таком подходе уменьшается количество ошибок и отпадает необходимость в найме специалистов для устранения этих ошибок. За счет уменьшения численности работников и четкого распределения ответственности между ними улучшается управляемость.

3. Децентрализация ответственности (вертикальное сжатие бизнес-процессов). Исполнители принимают самостоятельные решения в случаях, в которых раньше они должны были обращаться к руководству или ждать, когда отдельная ответственная за это команда примет решение.

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

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

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

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

8. Рационализация связей «компания – заказчик». Совершенствование организационной структуры фирмы предполагает создание условий, при которых уполномоченный менеджер обеспечивает единый канал связей с заказчиками или с каждым отдельным заказчиком.

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

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

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

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

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

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

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

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

6. Технологическая поддержка. Для проведения работ по совершенствованию процессов компании обязательна максимальная всесторонняя поддержка: соответствующие методики, инструментальные средства, дополнительные ресурсы и обучение. Улучшение процессов организации зачастую включает в себя построение одной или нескольких информационных систем для поддержки нового бизнеса. Это приводит к необходимости делать инвестиции в обучение сотрудников и развитие технологической поддержки как во время реализации проекта, так и после нее.

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

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

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

2. Добавленная ценность или соотношение добавленной стоимости и потребительской ценности результатов выполнения процесса. Критерий увеличения составляющей добавленной ценности процесса может использоваться в качестве основы для оптимизации бизнес-процессов компании. Более того, этот критерий может быть выбран как определяющий принцип для упрощения любого бизнес-процесса. Когда продукт (товар) проходит по цепочке бизнес-процессов компании, то с его ценностью происходит следующее: в процессе производства продукт вбирает стоимость затраченного на него труда, материалов, энергии, а также другие сопутствующие затраты. Однако добавленная ценность продукции напрямую не зависит от этих затрат. Ценность продукта увеличивается при добавлении в продукцию таких качеств, как функциональность, эстетичность, фирменный бренд и тому подобные аспекты, важные для клиента. Таким образом, добавленная ценность – теоретическая концепция, выражающая соотношение рыночной стоимости и фактически понесенных затрат на продукт.

3. Затраты ресурсов на конечный продукт и на брак. Временные: цикл, длительность, производительность, скорость выполнения заказов. Материальные: расход средств и материалов, активы, используемые в виде дебиторки, складские запасы и т. д.

4. Затраты на обучение или освоение процесса, подготовку и повышение квалификации сотрудников.

5. Эффективность использования ресурсов на единицу продукции: коэффициенты использования оборудования, коэффициенты использования ресурсов, сырья и материалов, затраты времени на проведение единицы работ или услуг.

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

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

Документирование требований

Документ об образе и границах проекта (Product Vision)

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

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

Образ продукта (product vision) – это определение стратегического образа системы, позволяющей выполнять бизнес-задачи.

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

Границы проекта (project scope) показывают, к какой области конечного долгосрочного образа продукта будет направлен текущий проект.

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

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

Информация, которую должен содержать документ об образе и границах проекта

Бизнес-требования

1. Обоснование и содержание нового продукта, а также причины его создания.

2. Описание ситуации на рынке, где продукту придется конкурировать с другими.

3. Описание (для корпоративной системы) бизнес-проблемы, которую решает продукт, среды его использования, сравнительная оценка продукта и его конкурентов, преимущества продукта.

4. Описание бизнес-целей и критерии оценки их достижения в количественном и измеряемом виде, рисков, возможных потерь от них, способов минимизации рисков.

Положение об образе проекта

1. Целевая аудитория пользователей, их потребности или возможности.

2. Имя, категория и ключевое преимущество. Это основы для использования.

3. Отличия от конкурентов или текущего бизнес-процесса, описание основного отличия и преимущества продукта.

4. Основные функции и возможности продукта, предоставляемые пользователю. Функции и возможности необходимо идентифицировать, а те из них, которые отличают продукт от продукта конкурентов, – подчеркнуть.

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

Масштабы и ограничения проекта

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

Бизнес-контекст

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

Приоритеты проекта

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

• ограничение – лимитирующий фактор, в рамках которого должен оперировать менеджер;

• ключевой фактор – важный фактор успеха, ограниченно гибкий при изменениях;

• степень свободы – фактор, который можно изменять в некоторой степени.

Тогда определение приоритетов – это соотнесение параметров и категорий параметров.

Операционная среда

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

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

План управления требованиями (ПУТ) и план управления документами (ПУД)

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

Ниже приведен возможный состав ПУТ.

1. Введение.

2. Общее описание методологии анализа, разработки и управления требованиями в проекте.

3. Системный анализ и моделирование.

a. Обзор основных моделей системного анализа.

b. Управление артефактами (моделями) системного анализа.

4. Разработка требований.

a. Типы требований.

b. Типизация нефункциональных требований.

c. Атрибуты требования.

5. Управление требованиями.

a. Методология управления.

i. Атрибуты требований.

ii. Полномочия по работе с требованиями.

iii. Обсуждение требований.

iv. Согласование требований.

v. Утверждение требований.

b. Жизненный цикл требований.

i. Запросы заинтересованного лица.

ii. Все остальные типы требований.

c. Трассировка требований.

6. Управление изменениями в требованиях.

a. Обработка запроса на изменение.

b. Базовые версии требований (baselines) в проекте.

7. Спецификации требований.

8. Управление процессом анализа и разработки требований.

a. Список основных артефактов и деятельностей по управлению требованиями.

b. Передача знаний бизнес-аналитику.

c. Обучение и передача знаний системному аналитику.

d. Постоянные улучшения процесса анализа и разработки требований.

План управления документами (ПУД) включает в себя информацию о том, какие проектные артефакты должны создаваться на каждом этапе проекта и в каком состоянии они должны находиться, кто отвечает за их согласование и утверждение, кто несет ответственность за артефакты, даты их готовности и т. д. и т. п.

Документирование вариантов использования

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

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

2. Описать процесс в виде таблицы из двух столбцов. Действия лица показать в левом столбце, а реакцию системы – в правом. Цифры указывают на последовательность этапов диалога. Эта схема отлично работает, когда с системой взаимодействует только один пользователь.

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

Важнейший вариант использования (essential use case) – упрощенное, обобщенное, абстрактное, не зависящее от технологии и реализации описание одной задачи или взаимодействия, в котором воплощена цель или намерения, лежащие в основе взаимодействия.

Фрагмент описания варианта использования «Запросить химикат»

Это означает, что следует сосредоточиться на задаче, которую необходимо выполнить пользователю, и возможностях системы для выполнения этой задачи. Важнейшие варианты использования характеризуются более высоким уровнем абстракции, чем конкретные варианты использования (concrete use cases), которые описывают определенные действия пользователя для работы с системой.

В качестве примера рассмотрим два способа начала реализации пользователем варианта использования «Запросить химикат».

1. Конкретный вариант использования – «Введите номер ID химиката».

2. Важнейший вариант использования – «Укажите необходимый химикат».

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

Например, если пользователь говорит: «По умолчанию это должно быть…», значит, он описывает нормальное направление развития варианта использования. Фраза «Необходимо, чтобы пользователь также смог…» предполагает обсуждение альтернативного направления. Многие условия исключений можно выяснить с помощью вопроса «Что должно произойти, если в текущий момент БД отключена?» или «Что, если этого химиката нет в продаже?»

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

Спецификация требований к ПО

Спецификация требований к ПО (software requirements specification, SRS) – согласно IEEE Std 1012:2004, структурированный набор требований к программному обеспечению и его внешним интерфейсам. В него входят функциональность, производительность, конструктивные ограничения и атрибуты.

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

• документом бизнес-требований;

• функциональной спецификацией;

• спецификацией продукта;

• просто документом о требованиях.

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

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

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

Спецификация требований к ПО необходима разным участникам проекта.

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

Сколько спецификаций необходимо

В большинстве случаев создают одну спецификацию требований к ПО, но для больших проектов это непрактично. При проектировании крупных систем часто составляют спецификацию требований системы, к которой прилагают отдельные спецификации требований к ПО и оборудованию (ISO/IEC/ IEEE, 2011).

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

В простых проектах может возникать ситуация, когда разрабатывают лишь один руководящий документ и называют его просто «спецификация». Он содержит всю возможную информацию о проекте: требования, оценки, проектные планы, планы качества, планы тестирования. Управлять изменениями и версиями такого всеобъемлющего документа затруднительно. Рекомендуется разграничивать выявленные требования по уровням, приведенным в разделе «Документирование требований».

При разработке документации всегда стоит оценивать ее объем с точки зрения необходимости и достаточности. Лучшим вариантом будет хранение требований в средстве управления требованиями, которое оказывается очень кстати для решения дилеммы: создавать одну или несколько спецификаций требований в проекте, где планируется несколько выпусков продукта или итераций разработки (Wiegers, 2006). В этом случае спецификация требований к ПО для части продукта или определенной итерации – всего лишь отчет, созданный на основе запроса определенного содержимого базы данных.

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

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

Как сделать требования ясными и понятными

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

2. Придерживаться единообразия при именовании разделов, подразделов и отдельных требований.

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

4. Создать оглавление, чтобы облегчить пользователям поиск необходимой информации.

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

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

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

8. При хранении требований в специализированном средстве использовать ссылки, чтобы облегчить читателю навигацию.

9. Включать графическое представление информации для облегчения понимания там, где это возможно.

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

Шаблон спецификации требований

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

➤ 1. Введение

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

➤ 1.1. Назначение

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

➤ 1.2. Соглашения, принятые в документах

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

➤ 1.3. Границы проекта

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

➤ 1.4. Ссылки

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

➤ 2. Общее описание

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

➤ 2.1. Общий взгляд на продукт

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

➤ 2.2. Классы и характеристики пользователей

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

➤ 2.3. Операционная среда

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

➤ 2.4. Ограничения дизайна и реализации

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

➤ 2.5. Предположения и зависимости

Предположение (assumption) – это утверждение, которое предполагается верным в отсутствие знаний или доказательств иного.

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

Определите все зависимости проекта или создаваемой системы от внешних факторов или компонентов вне ее контроля. Например, до установки продукта может потребоваться установить Microsoft.NET Framework 4.5 или более позднюю версию – это зависимость.

➤ 3. Функции системы

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

➤ 3.1. Функция системы X

Наименование и описание особенностей функции, выраженное в нескольких словах, например «3.1. Проверка правописания». Аналогично называют подразделы с 3.×.1 по 3.×.3 для каждой функции системы.

➤ 3.1.1. Описание

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

➤ 3.1.2. Функциональные требования

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

2. Описание вариантов реагирования продукта на ожидаемые ошибки, неправильный ввод информации или неверные действия.

3. Присвоение каждому функциональному требованию уникального имени.

4. Создание множества атрибутов для каждого функционального требования при использовании средства управления требованиями, например, таких как основание, источник и состояние.

➤ 4. Требования к данным

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

➤ 4.1. Логическая модель данных

Модель данных – это визуальное представление объектов и наборов данных, которые будет обрабатывать система, а также отношений между ними.

Существует много видов нотаций для моделирования данных, в том числе диаграммы отношений «сущность – связь» и диаграммы классов UML. Можно включить модель данных для бизнес-операций, выполняемых системой, или логическое представление данных, с которыми будет работать система. Это не то же самое, что модель данных реализации, которая представляется в виде дизайна базы данных.

➤ 4.2. Словарь данных

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

➤ 4.3. Отчеты

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

➤ 4.4. Получение, целостность, хранение и утилизация данных

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

➤ 5. Требования к внешним интерфейсам

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

➤ 5.1. Пользовательские интерфейсы

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

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

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

3. Размер и конфигурация экрана или ограничения разрешения.

4. Стандартные кнопки, функции или ссылки перемещения, одинаковые для всех экранов, например кнопка справки.

5. Сочетания клавиш.

6. Стандарты отображения и текста сообщений.

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

8. Стандарты конфигурации интерфейса для упрощения локализации ПО.

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

➤ 5.2. Интерфейсы ПО

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

2. Назначение, форматы и содержимое сообщений, данных и контрольных значений, обмен которыми происходит между компонентами ПО.

3. Соответствия между входными и выходными данными между системами. Описание всех преобразований, которые должны происходить с данными при перемещении между системами.

4. Службы, необходимые внешним компонентам ПО, природа взаимодействия между компонентами.

5. Данные, которыми будут обмениваться и к которым будут иметь общий доступ компоненты ПО.

6. Нефункциональные требования, влияющие на интерфейс, такие как уровни обслуживания для времени и частоты отклика или меры и ограничения безопасности. Часть этой информации может быть определена как требования к данным в разделе 4 или как требования к взаимодействию в разделе «6. Атрибуты качества».

➤ 5.3. Интерфейсы оборудования

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

➤ 5.4. Коммуникационные интерфейсы

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

➤ 6. Атрибуты качества

В этом разделе описываются нефункциональные требования, помимо ограничений, описанных в разделе 2.4, и требований к внешним интерфейсам, описанных в разделе 5. Эти характеристики должны быть точно определены, и они должны поддаваться проверке и измерению. Здесь указывают относительные приоритеты различных атрибутов, например приоритет простоты использования над легкостью изучения или приоритет безопасности над производительностью. Необходимые степени качества удается гораздо эффективнее описать с помощью подробных нотаций спецификации (например, Planguage), чем простых описательных утверждений.

➤ 6.1. Удобство использования

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

➤ 6.2. Производительность

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

➤ 6.3. Безопасность

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

➤ 6.4. Техника безопасности

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

➤ 6.5. [Другие]

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

➤ 7. Требования по интернационализации и локализации

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

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

➤ 8. Остальные требования

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

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

➤ Приложение A. Словарь терминов

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

➤ Приложение Б. Модели анализа

В этом необязательном разделе упоминаются такие модели анализа, как диаграммы потоков данных, деревья функций, диаграммы переходов состояния и диаграммы «сущность – связь». Часто для большего удобства пользователей определенные модели помещают в соответствующие разделы спецификации, а не собирают все вместе в конце.

Спецификация требований в проектах гибкой разработки

В проектах agile применяют ряд способов определения требований, которые отличаются от только что описанного метода.

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

Пользовательские истории накапливаются и приоритизируются в резерве продукта (product backlog), который меняется на протяжении всего проекта. Крупные истории, которые охватывают значительную функциональность и не могут быть реализованы в одной итерации, стоит разбить на более мелкие и назначить на конкретные итерации. Пользовательские истории можно записывать на чем-то простом, например на карточках каталога, а не в традиционном документе. Одни команды гибкой разработки сохраняют свои истории в средстве управления историями после реализации, а другие не делают этого.

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

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

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

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

Надлежащий уровень формальности и подробности документа требований зависит от многих факторов, в числе которых:

• объем оперативного неформального вербального и визуального общения между клиентами и разработчиками, который необходим для получения подробностей, обязательных для правильной реализации каждого пользовательского требования;

• предел, до которого неформальные методы общения могут обеспечить эффективную синхронизацию во времени и пространстве внутри команды;

• граница, до которой необходимо сохранять знания о требованиях для будущих улучшений, реинжиниринга приложения, проверки, аудита, проверки на соответствие нормативам, сертификации продукта или в соответствии с условиями контракта;

• граница, до которой приемочные тесты могут эффективно заменять описания ожидаемых возможностей и поведения системы;

• предел, до которого человеческая память может заменить письменное представление.

Независимо от типа продукта, который создает команда, используемой методики разработки или применяемых бизнес-аналитиком приемов выявления требований, эффективная спецификация требований жизненно важна для успеха. Существует много путей достижения этой цели. Но если не определить высококачественные требования, полученный в результате продукт будет как коробка с сюрпризом: вы никогда не будете знать, что от него ожидать.

Проверка требований

Один из самых главных процессов в деятельности бизнес-аналитика, про который почему-то многие забывают. Разработка и время стоят дорого, и дефекты из-за низкого качества требований приводят к гораздо большим затратам на более поздних этапах разработки.

Качественные требования соответствуют потребностям заинтересованных сторон и содержат достаточно информации для разработки программного продукта, удовлетворяющего ценностям бизнеса.

Типовые ожидания от требований

На этой диаграмме связей (Mind map) я собрал качества, которым обязаны соответствовать созданные требования. Некоторые из них вам должны быть знакомы по главе «Требования», но это тот случай, когда повторение полезно для закрепления материала.

Завершенность/полнота (completeness) – представлена вся необходимая информация для разработки. То есть ничего не пропущено под видом «это и так всем понятно, об этом и так все знают»: может поменяться состав команды, разработчик или даже подрядчик, у которого не будет никаких источников информации кроме ваших требований.

Пример незавершенных требований

«Система позволяет загружать изображения». (Изображения в каком формате? Какого максимального размера? Что подразумевается под изображением?)

«Информация о пользователях должна храниться в зашифрованном виде». (Что такое информация о пользователях, что под ней подразумевается? Какой алгоритм шифрования предполагается? Или если мы не говорим об алгоритме, то каким конкретно требованиям безопасности должна соответствовать информация, чтобы технические специалисты смогли подобрать подходящий способ ее хранения?)

Атомарность/единичность (atomicity) – требование невозможно разбить на части без потери смысла. Каждое требование должно быть декомпозировано до соответствия этому качеству.

Пример ошибки

«В момент, когда пользователь создал и активировал учетную запись». (Здесь описаны два разных случая: 1) когда пользователь зарегистрировался и создал свою учетную запись; 2) когда пользователь активировал свою учетную запись.)

Непротиворечивость / последовательность/согласованность (consistency) – непротиворечивые требования не конфликтуют с другими требованиями, отсутствуют конфликты внутри требований, и они не противоречат требованиям более высокого уровня, например бизнес-правилам.

Пример ошибки

«После успешной авторизации пользователь с ролью „Гость“». (После того как пользователь авторизовался, он уже имеет другую роль, то есть в самом требовании есть противоречие.)

Недвусмысленность /однозначность (unambiguousness/clear/understandable) – лица, которые будут читать требование, смогут истолковать его однозначно. Поскольку требования пишутся на естественном языке, в реальной жизни мы не можем полностью избежать таких ситуаций.

Пример ошибки

«Система обеспечивает быстрое выполнение запроса». (Основная ошибка здесь – это слово «быстрое», т. к. его невозможно измерить. Нарушен принцип проверяемости. В результате ответ на вопрос, реализовано ли требование, становится очень субъективным: для кого-то это будет медленно.)

Абстрактность (abstract/implementation free) – свойство, которое указывает на отсутствие конкретного способа реализации.

Проверяемость (verifiability/testable) – возможность создания объективного тест-кейса (—ов), однозначно показывающего, что требование реализовано верно и поведение приложения в точности соответствует требованию. Если требование не поддается проверке, то его реализация является субъективным мнением, а не объективным показателем.

Выполнимость / осуществимость (feasibility/realistic/possible) – указывает на способность реализовать каждое требование в рамках известных возможностей и ограничений системы и ее окружения.

Пример ошибки

«Искусственный интеллект должен давать юридические консультации по телефону».

Обязательность / необходимость (obligatoriness/necessary) – каждое требование должно документировать что-то действительно нужное клиентам или необходимое для соответствия внешнему требованию, внешнему интерфейсу или стандарту.

Актуальность (up-to-date) – требования должны регулярно верифицироваться на актуальность. Требования имеют свой жизненный цикл, постоянно меняются, развиваются или исключаются. Ваша документация не должна содержать требований, которые потеряли актуальность из-за каких-либо изменений.

Прослеживаемость/трассируемость (traceability) – возможность связать каждое требование к ПО с его источником, таким как требование более высокого уровня, вариант использования или мнение клиента. Также необходимо связать каждое требование к ПО с элементами дизайна, исходным кодом и тестовыми примерами, которые созданы для реализации и проверки требований. У каждого требования есть уникальный идентификатор.

Модифицируемость / способность к модификации (modifiability) – это качество отчасти пересекается с прослеживаемостью. Каждое требование должно иметь уникальный идентификатор для того, чтобы мы могли легко найти его. Требования должны быть организованы так, чтобы связанные требования были сгруппированы вместе при помощи оглавления, указателя и перекрестных ссылок, матриц и т. д.

Проранжированность / назначение приоритетов (ranked/prioritized) – каждое требование должно иметь приоритет по его реализации.

Методы обеспечения качества требований

Трассировка требований

Основная цель создания трассировок – убедиться в том, что команда проекта не делает ничего ненужного бизнесу или заинтересованным лицам, с одной стороны, и в том, что не забыто ничего из того, что действительно нужно бизнесу или заинтересованным лицам, – с другой.

Обычно трассировки строятся от одного типа требований ко второму, далее к третьему, четвертому и т. д. – пока не доходят до «конечных» типов требований. Таким обычно выбирается «вариант использования» или «функциональное требование» и «нефункциональное требование». Вся информация о трассировках, их назначениях и «конечных» типах требований фиксируется в ПУТ.

В результате можно построить «дерево» трассировок, которое позволит проследить, как учтено «исходное» требование в «конечном».

Решение о том, делать или не делать трассировки, а если делать, то какие именно, принимает менеджер проекта совместно с системным аналитиком и тест-менеджером.

Все трассировки условно можно разделить на причинно-следственные (основные) и проверочные (дополнительные). Причинно-следственные трассировки нужны для разработки качественного продукта. Проверочные необходимы в первую очередь менеджеру проекта как ответственному за качество продукта. От выполнения проверочных трассировок зависят успех проекта и удовлетворенность заказчика.

Согласование требований

Для многих, кто работает или планирует работать в продуктовых компаниях, все описанное в этой главе – сухая теория, с которой они никогда не сталкиваются. Это происходит потому, что им приходится согласовывать требования с единым ответственным лицом при помощи акцептирования элементов в JIRA или аналогичной системе. Однако сотрудникам крупных и особенно государственных компаний, занимающихся ERP системами и т. д., знать основы документооборота крайне полезно.

Три золотых правила согласования

1. На согласование должен быть направлен проект документа, полностью подготовленный и оформленный в соответствии с установленными в организации правилами. Инициатор проекта документа подготавливает проект в соответствии с требованиями действующей инструкции по делопроизводству, внутренними стандартами и иными внутренними нормативными документами организации, закрепляющими правила подготовки, составления и оформления конкретных видов документов.

2. За реализацию процесса согласования проекта конкретного документа (контроль за соблюдением процедуры и общих сроков согласования, учет замечаний согласовывающих подразделений и их отражение в тексте проекта) несет ответственность инициатор документа.

3. Подразделение, участвующее в процедуре согласования, оценивает проект документа, делает замечания и вносит предложения в рамках своей предметной области и закрепленных зон ответственности, которые установлены в положении о подразделении. Эти замечания и предложения, а значит, и соответствующие экспертные заключения по проекту, являются обязательными.

Пример

Получена виза службы делопроизводства: «Согласовано с замечаниями. Необходимо правильно оформить заголовочную и оформляющую части проекта договора, а в преамбуле исправить номер доверенности подписанта». Инициатор согласования проекта договора обязан устранить эти замечания по оформлению.

Но подразделения – участники процедуры согласования рассматривают проект документа в целом и имеют право формулировать замечания и предложения, не относящиеся к их прямой или смежным зонам ответственности, закрепленным за ними. Инициатор должен обратить внимание на данные замечания и предложения, поскольку все риски решений, оформленных в проекте документа, ложатся на должностное лицо, которое подписывает документ, но в системе согласования эти замечания будут факультативными, дополнительными.

Зоны ответственности подразделений

Анализ процедуры согласования показывает, что главное в ней – не организационная и структурная иерархия участвующих подразделений, а их функции и роли в системе управления организацией и в системе принятия решений. В связи с этим такие функциональные подразделения, как финансовая служба, служба главного бухгалтера, юридическая служба, служба делопроизводства, служба информационных технологий, служба безопасности, контрольная служба и т. д., могут и должны рассматриваться в статусе подразделений/инстанций обязательного согласования проектов документов, особенно в процедурах внутреннего согласования. Этот статус означает, что практически каждый проект решения или документа в маршруте своего согласования должен пройти анализ в данном функциональном подразделении. Без визы, полученной в инстанции обязательного согласования, никакой проект документа не может быть представлен на подписание или утверждение. Для разработки процедур и маршрутов согласования очень важно выявить и регламентировать зоны ответственности подразделений.

Условия успешной реализации процедуры согласования

В процессе разработки общей процедуры согласования, а также конкретных маршрутов и схем рекомендуем обратить внимание на некоторые особенности и условия, связанные с культурой организационного поведения, которая должна формироваться в ходе внедрения инструкции по делопроизводству и иных внутренних нормативных документов организации. Необходимое условие начала процедуры согласования – наличие «выпускающей» визы вышестоящего руководителя подразделения-инициатора (то есть не только исполнители, но и руководители должны изучить и принять правила согласования документов). Визу от имени подразделения организации имеет право проставлять его руководитель или должностные лица, уполномоченные им. От согласовывающего подразделения проставляется только одна виза. Отсутствие визы подразделения, участвующего в процедуре согласования, не позволяет считать документ согласованным по умолчанию (даже при нарушении типовых сроков согласования).

Алгоритм и способы согласования

Процедура согласования осуществляется параллельным, последовательным или комбинированным способом. При применении каждого маршруты и сроки согласования должны соблюдаться в обязательном порядке.

При параллельном способе согласования проект документа направляется на рассмотрение одновременно всем подразделениям/должностным лицам, включая вышестоящего руководителя подразделения-инициатора. Этот способ наилучшим образом реализуется в системах электронного документооборота / корпоративных информационных системах, у которых есть соответствующий модуль электронного согласования.

При последовательном способе проект документа направляется для согласования в три-четыре этапа в последовательности, которая устанавливается регламентом согласования. Рассмотрение документа подразделениями, участвующими в процедуре, реализуется последовательно.

Комбинированный способ согласования (на практике – самый распространенный) предполагает сочетание маршрутов направления проекта документа. Например, в начале процедуры инициатор получает визу подразделения-соисполнителя, а затем – параллельно направляет проект подразделениям-контролерам соответствующих рисков. Этот способ – основной в маршруте, когда условие начала процесса согласования – «выпускающая» виза вышестоящего руководителя подразделения-инициатора. Все знают, что «курирующие» вышестоящие руководители подразделений изучают подготовленные проекты документов и вносят свои изменения в первоначальные проекты решений, представленные на их рассмотрение. Исполнитель или подразделение-инициатор согласования могут выбрать любой из способов согласования проекта документа. Однако при этом необходимо учесть, что фактической датой начала согласования проекта документа в подразделениях на конкретном этапе последовательного согласования считается фактическая дата завершения согласования проекта документа в подразделениях на предыдущем этапе. Каждое из подразделений, участвующих в согласовании, при последовательном способе согласования вправе не принимать к рассмотрению проект документа до тех пор, пока не завершится предыдущий этап согласования, что существенно удлиняет общий срок согласования документа. Порядок и процедуры согласования отдельных видов документов могут и должны уточняться и регламентироваться в конкретных инструкциях, правилах и других внутренних нормативных актах предприятия при условии обязательного соблюдения правил, установленных инструкцией по делопроизводству, и общих правил согласования.

Оформление результатов согласования

Исполнитель или подразделение-инициатор направляют подготовленный проект документа в подразделения, участвующие в согласовании в соответствии с определенным маршрутом, который удобно фиксировать в листе согласования.

Направление на согласование осуществляется централизованно через службу делопроизводства (в соответствии с правилами делопроизводства), посредством e-mail или через систему электронного документооборота. Результаты согласования оформляются визой на проекте документа или визой, проставленной в листе согласования. При наличии замечаний (дополнений) к проекту должностные лица формулируют их и представляют исполнителю. В данном случае проект документа визируется с оговоркой о наличии замечаний, которые могут быть сделаны в тексте документа (выделены шрифтом, цветом или оформлены в режиме редактирования). В случае несогласия одного из согласовывающих подразделений может быть проставлена виза «Не согласовано» с обязательным письменным объяснением причин отказа. Инициатор согласования в этой ситуации должен подготовить новую редакцию проекта документа и направить ее на повторное согласование в подразделение, которое проставило визу «Не согласовано», а также в подразделения, чьи интересы были затронуты при внесении изменений в проект документа по результатам согласования. Все противоречия, возникающие на этапе согласования, должны регулироваться в порядке конструктивного взаимодействия подразделений и сотрудников. В спорных случаях оформляется протокол разногласий, рассмотрение которого осуществляется на уровне «курирующих» вышестоящих руководителей подразделений или коллегиальных органов. При проведении процедуры внешнего согласования ее результаты оформляются соответствующей перепиской (письмами о согласовании). После получения виз от всех подразделений, причем даже в процессе внутреннего согласования, возможно проставление виз по форме: «СОГЛАСОВАНО» («СОГЛАСОВАНО с замечаниями»), исполнитель оформляет окончательную редакцию проекта документа, к которой прикладывает экземпляр полностью согласованного проекта с визами и замечаниями («визовый» экземпляр) или лист согласования. После этого он проставляет отметку об учете замечаний, которая является документальным подтверждением процедуры доработки проекта документа. Отметка об учете замечаний к окончательной редакции документа, оформленная на «визовом» экземпляре проекта или листе согласования, должна быть датирована и заверена подписью руководителя подразделения-инициатора. После завершения согласования проект документа направляется руководителю или уполномоченному им должностному лицу для утверждения или подписания централизованно через службу делопроизводства. Направление на подписание возможно осуществить в бумажном или электронном виде. Рекомендуем также обратить внимание на то, что Методические рекомендации при оформлении виз и грифа согласования как реквизитов документа вводят некоторые новации. Интересно, что «допускается полистное визирование документа и его приложений». Это предполагает возможность использовать не все элементы визы как реквизит, состоящий из наименования должности, личной подписи, расшифровки подписи и даты визирования, а только один его элемент – личную подпись (параф), который широко применяется в нотариальном делопроизводстве и при оформлении гражданско-правовых документов для обеспечения их целостности. А если согласование проекта документа проводится с использованием листа согласования, то на документе под реквизитом «подпись» ближе к нижнему полю методические рекомендации допускают вместо грифов согласования (на площади, предусмотренной для них на листе бумаги) ставить специальную отметку «Лист согласования прилагается».

Следует различать утверждение и согласование документов.

Утверждение – это способ введения документа в действие, придания ему законной силы и распространения его действия на определенный круг лиц или организаций. Утверждение производит, как правило, первое лицо организации – директор или генеральный директор. Утверждать документ следует только после его подписания.

Согласование – это процесс проверки качества проекта документа, его своевременности, целесообразности, реальности выполнения, соответствия действующему законодательству и ЛНА организации. Документы согласуют специалисты или руководители соответствующих структурных подразделений в рамках своей компетенции. Порядок согласования различных видов документов также закрепляется документально: как правило, в инструкции по делопроизводству или в регламентах, описывающих бизнес-процессы. Согласовывать документ следует перед его подписанием.

Пример оформления согласования требований

➤ История изменений

➤ Связанные документы (этот документ должен читаться вместе с):

➤ Документ утвержден

➤ Документ согласован

Приложения

IT-сленг

Вам придется много общаться не только с заказчиками, но и с командой, поэтому вы должны понимать, о чем они говорят.

Автоматизация, авто – в зависимости от контекста, автоматическая настройка окружения на проекте или сборка версий этого проекта, или написание автотестов тестировщиками вашего проекта.

Адаптив, адаптивный – адаптивный дизайн сайта или приложения, в котором интерфейс автоматически подстраивается под экран компьютера, ноутбука или телефона. Вы должны располагать несколькими вариантами макетов под разные форматы экранов, чтобы в полной мере понимать, как элементы будут выглядеть при разных условиях.

Айди, айдишник – идентификатор объекта, часто состоит из рандомного набора цифр, но бывают и сочетания цифры + буквы. Он необходим для удобного поиска в базе данных.

Аккаунт, аккаунт-менеджер – человек, занимающийся ведением статусов проектов в компании. Чаще всего такие аккаунт-менеджеры есть в аутстафф- и аутсорс-компаниях. Их цель – договориться с заказчиком, получить от него техническое задание на разработку продукта, отправить ему резюме кандидатов, назначить собеседования и онбординг в команде. Также такой человек обычно следит за исправным трекингом задач и списыванием времени на них со стороны компании.

Апдейт, UPD, update – обновление как информации, так и просто текущей ситуации. Апдейт файла, документации, статуса задачи.

Апрув, апрувить, заапрувить, approve – подтвердить выполнение какого-либо действия верным способом. Можно заапрувить код на код ревью, заапрувить отпуск или кинуть апрув для подключения к общему созвону.

Ассайн, ассайнить, assign – перевести задачу на какого-нибудь исполнителя. Так можно делать в любом сервисе, в котором у вас лежат рабочие задачи, типа Jira.

Аттач, attache – приложить материалы, фото, документы или файлы к сообщению или задаче. Можно также прикрепить комментарий к задаче в сервисе (по типу Jira) или там же прикрепить к задаче другие задачи, которые могут быть взаимосвязаны.

Апишка, апи, API – вообще это программный интерфейс для взаимодействия сайта или приложения с его сервером. Но чаще апишкой называют просто то, что видно в адресной строке сайта, например: https://google/cats/24532.

Аутсорс, она же галера – в такие компании приходит заказчик со своим техническим заданием или влажными фантазиями о проекте. Проект оценивают, и если договариваются по цене, то подписывают контракт на определенный срок до выпуска проекта. Заказчик не видит, кто работает над проектом, а просто дает компании деньги на разработку и получает отчеты о результате. Поэтому в аутсорсе довольно мало денег и много работы – финансирование зависит от толщины кошелька заказчика.

Аутсафф, стафф, контрактники – это когда вы интегрированы в продуктовую команду заказчика, будучи нанятым не к нему в штат, а в прослойку в виде аутстаффа. Благодаря такой работе продуктовая компания платит за вас намного больше, чем за рядового штатного сотрудника. Однако в этом есть смысл: вас можно увольнять и нанимать одним днем, не предоставлять техническую документацию, не платить годовые премии и не возить на дорогие корпоративы, поскольку официально вы работаете не у них, а в другой компании, в которой вам устанавливают совсем иную зарплату, отличную от той, что за вас платит аутстаффу эта продуктовая компания. Вы же получаете быстрый наем и возможность менять проекты и стек на них в течение работы в аутстафф-компании.

Баг, бага, багуля, бажина – ошибка в работе программы, не соответствующая ее логике по техническому заданию. Ее могут найти тестировщики или пользователи сайта/приложения. Подобные баги в работе программы потом заводят в виде отдельного тикета с описанием ожидаемой реализации (как должно работать) и фактической реализации (как неправильно работает сейчас). Подобные баги находят как тестировщики, так и менеджер с тимлидом, и сообщают о них разработчикам.

Бамп или памп версии – повышение версии приложения. Например: было 1.03 → стало 1.04.

Блокер – проблема, которая вас стопорит, блокирует, из-за чего вы не можете выполнить рабочую задачу.

Бренч или branch – это ветка, в которой разработчик работает и пишет код. Ветка обычно называется по номеру задачи, которую вы получаете + баг или фича + название задачи. Например: MOB‐3244/feature/Создание главного экрана. В рамках этой ветки под таким номером идет вся работа над задачей, которую на вас назначили.

Билд, сбилдить, build – в контексте разработки это рабочая версия программы, которую можно запустить (сбилдить) у себя на ноутбуке.

Бэклог, backlog – список задач, которые нужно реализовать в будущих версиях продукта. Для разбора бэклога есть специальная встреча команды – груминг (см. ниже)

Бэк, бэкенд – серверная часть приложения.

Бэкап, backup – сохранение резервной копии данных, будь то страница в документации или кусок кода.

Ветка – это ответвление от вашего основного проекта, в которое именно вы вносите изменения. В нее можно коммитить самому и загружать коммит участников команды, в ней ведется разработка нового функционала или исправление старого.

Ворнинг, ворн, warn, warning – предупреждение о том, что программа работает некорректно и ее можно улучшить.

Воркшоп, workshop – это специальное мероприятие или ивент в формате тренинга. Оно носит сугубо практический характер и демонстрирует навыки эксперта во время рабочего процесса. Простыми словами, воркшоп – это мастер-класс специалиста для обучающихся. Суть мероприятия – ведущий демонстрирует решение конкретной рабочей задачи. Происходит такая демонстрация не отвлеченно (в теоретическом ключе), а на практике.

Вылет, вылетело – сбой работы программы, при котором сайт или приложение перестает работать. Происходит внезапно, также это может называться крашем (см. ниже).

Галера – любая работа, на которой вам недоплачивают, обманывают, штрафуют, трекают каждую минуту, требуют перерабатывать и не считают это недостатками. На такой работе могут установить скриншотилки на ваш ноутбук, возможна токсичная атмосфера в команде, отсутствие прозрачности и полный хаос в процессах. Все это создает плохие условия для повышения зарплаты или карьерного роста.

Груминг, грум, прогрумить, grooming – встреча топов команды, обычно менеджер + аналитик + дизайн + тимлиды/сеньоры. Встреча нужна для разбора задач, которые накопились в арсенале команды. На таких встречах обычно обсуждается: реально ли эти задачи реализовать в нашей команде? Как сократить и удешевить реализацию? Как ускорить процесс? Бывает так, что часть команды не присутствует на встрече, потому как понимает, что идеи, разобранные на груминге, могут и вовсе не понадобиться в дальнейшем.

Гайд – пошаговое руководство, может касаться вашего проекта.

Глоссарий, глосарь – список терминов в команде, введенный для того, чтобы называть одними и теми же словами определенные действия и объекты. Например: есть слово «клиент», но бэкенд-команда называет его «лид», фронты используют слово «юзер», а аналитики – «пользователь». Из-за этого коммуникация в команде может пострадать. Глоссарий решает эту проблему и помогает общаться с коллегами на одном языке. Далеко не в каждой команде есть глоссарий, а это большая проблема, но в то же время и точка роста – вы можете предложить ввести такой!

Гит-флоу – конкретный паттерн поведения при работе над полученной задачей или багом, касающимся разработки. У вас есть девелоп-ветка с актуальными фичами в приложении, вы получили новую задачу для разработки нового функционала, поэтому от девелопа надо отбренчиться и создать новую ветку таким образом: Номер задачи из тикета/feature/Название задачи из тикета. В этой ветке необходимо будет сделать всю работу над фичей и запушить ее в ваш репозиторий. Это описание самого простого гит-флоу, в каждой команде он может отличаться неймингом веток, типом основной ветки (девелом, мейн, мастер), а также количеством коммитов и их длиной.

Глитчит, глитч – обычно так говорят о дерганой таблице при скроллинге или неравномерно загружающихся картинках.

Дедлайн – конкретные сроки выполнения задачи. В разработке такие сроки ставят на планировании. Если вы понимаете, что времени мало, а задача еще не решена – лучше сразу открыто сказать об этом, чтобы команда не пострадала, чем молчать и в последний день сообщить, что работа еще не готова. Сроки в IT срываются ежедневно, вы не один такой, все в порядке.

Декомпозиция – процесс разбивки большой задачи на мелкие и более понятные команде, которые легко выполнить.

Дев, девелоп окружение, девелопмент – это закрытая среда разработки или тестирования программы, к которой имеет доступ только команда, а не все пользователи.

Дейли, митинг, дейлик, стендап – ежедневная встреча команды, на которой каждый участник коротко отвечает на вопросы: «Что я делала вчера, что я буду делать сегодня, есть ли у меня проблемы?» Главная задача этой встречи – понять, успеваешь ли ты сделать работу в поставленные сроки и нет ли у тебя затупов/блокеров.

Джуниор, джун – человек, который может выполнять задачи только с помощью пошагового плана. Он не сможет выполнить абстрактную задачу, так как растеряется без четкого технического задания.

Деплой, задеплоить – процесс публикации новой версии сайта или приложения. Также в контексте деплоя можно услышать «развертывание».

Дропнуть, дроп, drop – опубликовать, выложить проделанную работу в публичный доступ.

Железо – ваш рабочий ноутбук или компьютер.

Жира, джира, Jira – сервис, в котором ведется весь трекинг и отслеживается прогресс работы над задачами в команде. Там есть та самая доска со значениями: TO DO, IN PROGRESS, CODE REVIEW, TESTING, DONE. Также там создаются все задачи проекта.

Залить, подлить – загрузить новые изменения в программе в общий доступ для всех, чтобы синхронизировать всю команду.

Заложить, заложиться – определить время на выполнение задачи. Также можно перезаложиться, если необходимо сделать оценку задачи с учетом рисков, выделив на ее выполнение больше времени.

Код ревью – процесс проверки и анализа написанного тобой кода. Используя комментарии проверяющего, необходимо внести правки в код, и тогда ревью будет считаться пройденным.

Коммит, коммитить, закоммитить, commit – сохранить изменения в проекте. Давайте вспомним ГТА и то, как там можно было сохраниться перед миссией, чтобы в случае гибели персонажа вернуться в игру с теми же вводными данными – коммиты делают то же самое! Частые коммиты по определенной узкой теме спасут вам жизнь, если нужно будет отменить то, что в итоге уже закоммичено, но при этом не работает! Просто откатите коммит на один назад, и окажетесь на том же месте, еще до написания неработающего кода.

Компилить, скомпилить, compile – собрать проект (его кодовую базу) на своем ноутбуке, чтобы в дальнейшем его запустить. Если не скомпилилось – значит, в коде есть ошибка, которую необходимо устранить.

Косты, кост или cost – стоимость создания чего-либо, будь то стоимость по времени для разработки, аналитики, дизайна и тестирования программы

Костыль, закостылить – некрасивое и неэлегантное, но при этом рабочее решение задачи. О таком не любят говорить и такое не любят делать, но без этого реальная коммерческая разработка со сжатыми сроками просто не работает. Костыли есть везде, как в аутсорсе, так и в больших продуктовых компаниях. Это норма индустрии разработки, потому что задача разработчика – решить проблему и выдать быстрый рабочий вариант бизнесу, а не написать чистый и красивый код. Платят за фичи, а не за чистоту: чистота кода денег бизнесу не принесет, поэтому ею часто жертвуют в пользу костылей. Плюс они нужны из-за порой совершенно несовместимых вещей в проекте, где закостылить какое-то решение задачи будет выгоднее по времени, чем написать хорошо. Еще бывает так, что другого варианта сделать лучше просто нет.

Краш, crash, закрашилось, скрашилось – сбой в работе программы, из-за которого возникает необходимость перезапустить ее еще раз

КЗ – коммерческая занятость, часто используется в контексте аутсорс-компаний, отражает количество времени, которое уделяется проекту и сидению на бенче. Нормальным считается показатель 75–80 %.

Лаг, лагать – сбой в верстке или всей работе программы.

Легаси или legacy – тяжелое наследство, которое необходимо поддерживать в программе, чтобы она продолжала работать. Легаси – это не только старый код и неактуальный стек проекта, но и просто плохо написанный код на новых фреймворках, который все равно необходимо будет оптимизировать и переписывать.

Линк, линка – ссылка на что-либо.

Либа – библиотека, которую можно добавить в проект как зависимость. Часто используется разработчиками при внесения в проект новой информации или удалении старой. Эти зависимости добавляются чаще всего с гитхаба, где есть открытые библиотеки, но также либа может быть самописной и лежать на вашем гитхабе/гитлабе в закрытом доступе.

Линтер, линт – настроенная вручную проверка кода. Добавляется в проект благодаря библиотеке, в отдельном файле которой вы описываете определенные правила для работы этого линтера у себя на проекте. Он помогает подсвечивать синтаксис, проблемы с размерами функций, длину файлов, классов и структур. Линтер будет упрощать и ускорять код ревью, так как все грязные и грубые ошибки он подсветит еще до возможности сохранить твои изменения в проекте.

Мануал, мануальщик, мануальный тестировщик, manual QA – человек в команде, который занимается написанием тест-кейсов по аналитике проекта и проверяет их вручную. Он может тестировать как фронтенд-часть (сайты с приложениями), так и бэкенд-часть (серверную) по типу тестирования API, баз данных и интеграций с разными сервисами.

Машина – ваш рабочий ноутбук или компьютер.

Мердж, мерджить, смержить, merge – слияние двух веток, при котором изменения одной ветки добавляются в другую и фиксируются там коммитом. Используется как сленг, чаще среди разработчиков.

Мок, мокнуть, мокать, mocking – подменить реализацию, чтобы проверить работу функционала при разных условиях. Например, можно мокнуть поля в JSON, которые нам присылает бэкенд, подкинув туда другие значения перед их отрисовкой на фронте. Таким образом, не меняя ничего в действительности на бэкенде и не плодя новые сущности, мы можем проверить работу сайта или приложения с разными данными.

Мокап, мок – реалистичный макет предмета, на котором можно разместить все что угодно под его размеры и посмотреть, как это будет выглядеть в реальности. Чаще всего используется дизайнерами для показа разных вариантов логотипов/стилей на одном и том же макете. Сам мокап не меняется, а его наполнение – да. Например, можно сделать мокап вашего приложения под iPhone, Xiaomi, Samsung или Pixel.

Мидл – следующий уровень после джуниора, более самостоятельный и опытный работник, который может решить любую задачу, с которой он уже сталкивался, сделать ее от начала и до конца без подсказок.

Митинг, мит, го мит, meeting – встреча команды. Чаще всего это созвоны по работе для выяснения требований или статусов готовности задач.

Мэтч, смэтчиться, match – совпасть по ожиданиям или реализации.

Накатить – добавить или выпустить изменения программы.

Откат, откатить – вернуть к прежней версии проекта, часто применяется при разработке продуктов. Может использоваться в контексте коммитов при разработке, чтобы откатиться назад на один и более коммитов, так как новые изменения не подходят по логике или ломают проект.

Отбренчиться, бренчиться – это значит, что нужно от основной ветки (например, девелопа) отвести новую ветку со своим названием и работать уже на ней. Branch – это ветка в проекте, их может быть много, и вы должны создать свою, отбренчившись от главной, чтобы начать работу над своей задачей.

Окружение, окр, environment – среда, в которой вы разрабатываете, тестируете или в целом используете проект. Может делиться на основные варианты по типу dev, prod и test: дев и тест применяется для разработки и тестирования, а прод/продакшен – только для пользователей. В идеальном мире все три окружения должны иметь одинаковый функционал, и на прод ничего не должно публиковаться до тестирования на тесте или деве, но так происходит не всегда.

Ось, оська, OS – операционная система вашего компьютера или телефона. Чтобы узнать точную версию или оставить точное описание в задаче, вас могут спросить, с какого конкретно устройства и какой оси тестировщик проверял эту задачу. Такие детали необходимы при тестировании и разработке.

ОР – в тестировании это сокращение от «ожидаемая реализация». То есть это ожидание того, что программа будет работать по техническому заданию именно так, как нужно. При оформлении задачи тестировщики указываю именно ОР по документации, а не из личного предпочтения.

Прод, продакшен, production – версия сайта или приложения для ваших пользователей.

Планирование, планинг, planning – встреча всей команды, на которой обсуждается техническое задание для разработчиков, декомпозируются и оцениваются задачи в часах или сторипойнтах.

Пинговать, пинг, ping – достучаться до кого-то или чего-то. Можно рассматривать в контексте общения с коллегой или попыток подключиться к серверу. Из терминала вы можете посмотреть, что такое пинговать какой-то сервис, например «Яндекс»: просто откройте терминал и введите ya.ru ping – и будете получать данные по состоянию этого соединения каждую секунду.

Продукт оунер, владелец продукта, ПО – скрам-роль, это что-то из эзотерических скрам-учений. Часто некорректно используют в значении «продакт-менеджер», просто потому, что так круче звучит. Это человек, к которому приходят для того, чтобы он согласовал приоритеты и стратегию развития продукта. Например, команда разработки делает продукт для бизнеса, а продакт-оунер – это собственник бизнеса или его представитель. Часто под продакт-оунером подразумевают человека, который будет делать «продуктовую работу» во имя владельца бизнеса.

Патч – кусочек работающего кода, который будет работать у вас, если вы получите этот патч и примените его в своем проекте. Патчи пишутся людьми, не путайте с шаблонами/темплейтами. Например, это написанный другим коллегой код, который можно добавить к себе в проект, чтобы все заработало. Он содержит в себе все изменения, которые внес другой человек, причем это будет выглядеть не как коммит, а как обычный код, который вы могли бы написать сами.

Пушить, запушить, push – способ отправить свои изменения в программе на удаленный репозиторий (GitHub, GitLab, Bitbucket).

Пулить, спулить, пулл, pull – способ достать актуальное обновление из удаленного репозитория. Ваши коллеги изменяют код в проекте, а вы подтягиваете эти изменения. Это необходимо делать регулярно, иначе версии проектов не будут совпадать с кодами коллег и начнутся конфликты.

Прокся, прокси, прокси-сервер, proxy – по факту посредник, передающий данные с сайта или приложения на его сервер. Дополнительная прокся перед клиент-сервером полезна тогда, когда на ней можно выполнять совсем небольшие кастомизации, например отображать один вариант текста под сайт, а другой под мобильное приложение. Также это может работать как прокси-сервер, который меняет IP-адрес сайта и перенаправляет пользователя на другой ради его безопасности.

Ретроспектива, ретра, retrospective – встреча всей команды в конце спринта, которая устраивается для того, чтобы подвести его итоги и ответить на вопросы: «Что было сделано хорошо в этом спринте, а что плохо? Что мы, как команда, можем улучшить?» Встреча проводится в компаниях с целью устранить косяки команды и улучшить процессы.

Ребейз, rebase – извращенный вид слияния двух веток, на которых работаете вы или ваш коллега. От классического мерджа отличается лишь возможностью самому выбирать последовательность коммитов в истории изменений ветки.

Реджект, зареджектить – отказ от действия, которого вы ожидали. В контексте разработки это будет отказ от слияния веток с другим разработчиком или отказ в публикации приложения в сторе.

Релиз, релизиться, зарелизить, релизный цикл, release cycle – беспрерывный процесс доставки пользователю обновлений продукта.

Рефералка, рефка, ref, referral – реферальная программа для найма сотрудника в компанию по рекомендации его знакомого, который уже работает в этой компании. За такую рефералку принято платить либо фиксированную сумму (от 5 тысяч до бесконечности), либо просто процент от зарплаты человека, которого устроят таким образом. Подобный бонус можно поделить между коллегами.

Ребут, ребутнуть – перезагрузка. Используется в том случае, если у вас что-то сломалось или стало некорректно работать. Порой это может даже помочь.

Редирект – изменение движения в ходе программы или, например, переадресование на другой сайт.

Репа, репо – сокращение от репозитория проекта, где хранится весь код со всей его файловой структурой и описанием. Термин используют в основном разработчики, которые хранят код проекта в GitLab, GitHub, Bitbucket или на других площадках.

Релиз, release – публикация новой версии сайта или приложения для всех пользователей.

Регресс – этап полного тестирования программы. Его проводят, чтобы убедиться в том, что новые изменения в программе не поломали старые и верно работает вся программа, а не только новый функционал. В регрессе программу могут проверять как угодно, в него входит любой вид тестирования (смок, интеграционное и т. д.).

Ридмик, реадми, README.md – файл с описанием того, как следует работать с проектом, как настроить окружение, выкачать репозиторий с проектом и установить его у себя локально для дальнейшей работы. Также файл может содержать дополнительные ссылки на документацию проекта, его кодстайл, тесты, правила линтера и т. д.

RC, release candidate – более узкая часть процесса релизного цикла, которая уже прошла тестирование. Эта версия продукта является кандидатом на публикацию в открытый доступ для всех пользователей.

Ручка, дергать ручку – API-метод, который можно вызвать, отправив определенный запрос на сервер. Этот вызов и есть дерганье ручки. Если вы получили определенный статус в ответе – значит, дернули!

Ручник, ручной / мануальный тестировщик – человек в команде, проверяющий работу программы по самописным тест-кейсам. Обычно он подключается к работе в конце спринта, чтобы все проверить и завести баги на разработку в случае ошибок.

Сабтаски, саб, subtask – подраздел большой задачи. Их заводят для декомпозиции большой задачи, разделения ее на связанные части. Например, вам надо сделать авторизацию на сайте. Вы можете завести одну задачу на «добавление модуля авторизации», а можете завести задачи на «верстку экрана авторизации», «верстку отдельных элементов и добавление новых стилей», «бизнес-логику авторизации» и «покрытие экрана авторизации метриками». Эти маленькие задачи – сабтаски одной большой по «Добавлению модуля авторизации» на сайт или приложение.

Сеньор, помидор, senior – старший работник. Он может самостоятельно решить любую задачу бизнеса, с которой ранее не сталкивался, опираясь лишь на свою насмотренность и опыт решения других задач.

Стор – магазин приложений, куда публикуются все мобильные приложения для пользователей. Например, это AppStore и Google Play.

Скрининг – первый звонок-знакомство с нанимаемым менеджером, обычно занимает от 10 до 30 минут. Во время этого звонка наниматель рассказывает о вакансии и просит вас рассказать о себе и ответить на несколько вопросов. Эта встреча – первая в воронке найма. Она необходима компаниям, чтобы отсеять неадекватных кандидатов и допустить до технического интервью только самых подходящих под вакансию. Часто в конце такого скрининга проводят еще и технический скрининг: он включает в себя список вопросов от технических специалистов компании, которые они подготовили, чтобы проверить ваши знания на самом первом этапе, еще до официального технического собеседования.

Срез – сборка актуального приложения, которое увидит пользователь после публикации в сторе.

Смоук, смок, смоук-тестирование, smoke test – минимальный набор тестов для проверки нового функционала продукта перед его релизом. Его проводят только для проверки нового функционала, чтобы убедиться в том, что все действительно работает в соответствии с документацией. Полностью приложение не проверяют, это делают на регрессе.

Спека, спецификация – документация по проекту, где можно найти информацию по узкой части программы.

Свитч, свитчнуться, switch – в контексте разработки это значит поменять ветку. В общем понимании – поменять окружение, стек, направление в работе.

Сторипойнт, пойнты, story point – единица меры сложности реализации какой-то задачи. Часто используют системы Фибоначчи, измеряя сложность от простого к более сложному в последовательности 1, 2, 3, 5, 8, 13, где последние два числа означают, что задача слишком сложная и ее надо декомпозировать.

Сиайка, сиай сиди, CI/CD – автоматизация сборок вашего кода. Например, чтобы собрать версию вашей ветки вручную, вам необходимо сделать архив проекта, самостоятельно заполнить все поля, прожать все галочки и дождаться, когда приложение попадет к тестировщикам, а сам проект будет собираться на вашей машине, перетирая SSD. Благодаря автоматизации сборок все это делается удаленно, ваш ноутбук не страдает, а вам не нужно вводить каждый раз одни и те же данные. Все настраивается один раз и в дальнейшем только поддерживается.

Синк, синкануться, sync – процесс созвона с вами и командой для синхронизации. Это необходимо для согласования ваших выводов с выводами других людей по реализации какой-либо вещи в проекте. Таким образом, люди всегда находятся в правильном контексте и в курсе всего происходящего в команде и проекте.

Таск, таска, task – задача, которую необходимо решить. Эту задачу вы можете получить как от аналитика, менеджера, тимлида или даже коллеги для проработки нового функционала проекта, так и от тестировщика в виде бага, который необходимо поправить в проекте. Рабочая задача в виде фичи или неисправленный баг в работе программы – оба эти понятия являются тасками.

Тестер, тостер, куа, QA – человек в команде, который отвечает за качество разработки и говорит свое последнее слово перед релизом для всех пользователей. Делятся на мануальных и автотестировщиков: первые проходятся по программе вручную, а вторые пишут автотесты. Обычно в командах не бигтехов могут себе позволить иметь только мануальных тестировщиков. Для авто уже необходим человек, который знает один язык программирования, а его наем обойдется гораздо дороже.

Трекер – место, в котором собраны все задачи команды с их статусами. Благодаря трекеру менеджер команды видит, сколько времени потрачено на задачи, успеваете ли вы по срокам и списали ли время на выполнение этих задач. Трекером могут называть такие пространства, как Jira: в них также можно залогировать время, затраченное на выполнение задачи, чтобы получить оплату за свою работу.

Тимлид, тим, лид команды, teamlead – человек, который руководит командой и процессами, решает спорные вопросы.

Тикет – файл в вашем трекере, который может быть назначен на вас или создан вами для другого человека. Любую задачу или баг оформляют в виде тикета, включающего его название, описание с возможными ссылками или скринами, или шаги воспроизведения ошибки, если это баг.

Темплейт, template – шаблон, по которому вы можете работать на проекте, например шаблон для архитектуры VIPER.

Факап, нафакапил, fuckup – неудача в процессе работы.

Фича, feature – новый функционал приложения или сайта, который ранее не был реализован. Фичей может считаться как добавление новой кнопочки для авторизации через «ВКонтакте» с последующей бизнес-логикой, так и интеграция платежного сервиса в ваше приложения для оплаты покупок в нем.

Фикс, фиксить, fix – доработка функционала. Это не совсем баг, ибо все может работать исправно. Но бывает, что код написан плохо, и такое просят исправить: пофиксить нейминг функций и переменных или поехавшую верстку.

Фидбек, feedback – обратная связь от людей по поводу качества проекта и вашей работы.

Флоу, flow – последовательность каких-либо действий. Флоу может быть у проекта, задачи или у пользователя, который пользуется приложением или сайтом.

ФР – в тестировании это сокращение от словосочетания «фактическая реализация». То есть, если программа работает не так, как описано в техническом задании, то это уже наша фактическая реализация. При оформлении задачи тестировщики указывают именно ФР по тому, как работает программа.

Хотфикс, hotfix – быстрая правка ошибки. Когда на проде появляется баг, чаще всего прибегают именно к хотфиксу.

Хост, хостинг, захостить, host – может касаться как идентификатора вашего ноутбука, так и хостинга на сайте. В зависимости от контекста говорят об этих вещах. Если вы что-то устанавливаете, работаете с VPN или Wi-Fi компании и у вас просят хост, то гуглите в направлении «как узнать хост ноутбука». Если разговор идет про сетевой слой с хостом сайта или приложения, ищите материалы о хостах и хостинге в целом на сайте.

Эстимейт, эстимейтить, заистимейтить, esteam – ставить оценку, оценивать время на выполнение задачи. Используется в контексте оценки задачи на планировании, где вся команда выставляет эстимейт относительно сложности.

Эпик, Epic – это очень большой кусок функционала, который нужно будет реализовать для пользователя. Но такой функционал невероятно сложно засунуть в один двухнедельный спринт. Если вы на планировании этого спринта сталкиваетесь с тем, что задача слишком большая, сложная и ее невозможно успеть сделать за две недели, то это эпик.

ЭмВиПи, МВП, mvp – минимально функционирующий продукт. То есть МВП-приложения для такси будет таким: у нас есть экран с картой и двумя полями с точками пользователя А и Б, маячки с водителями, возможность заказать такси и оплатить его в приложении. Все. Дорогущий дизайн, чистый код, показатель наличия детского кресла в машине или рейтинга водителя лучше оставить на вторую или третью часть выпуска МВП!

Юзабилити – характеристика, которая показывает, насколько удобно пользоваться интерфейсом программы или приложения.

Юнит тест, юниты – небольшой тест функционала, проверяющий конкретный кейс выполнения программы. Такие тесты могут писать как разработчики, так и тестировщики-автоматизаторы.

Юай, юайка, UI, user interface – визуальная часть сайта или приложения. Все шрифты, стили, радиусы кнопок, цвета и формы – это все UI сайта или приложения. Это никак не связано с удобством пользования сервисом, его логичной навигацией и прочим: оно отвечает только за визуальную составляющую экранов.

Юикс, UX, user experience – показатель удобства пользования сайтом или приложением для пользователя. Хороший юикс означает, что сайт интуитивно понятен, пользователь на нем не теряется и идет по нужному пути. Плохой – это когда пользователь начинает ненавидеть интерфейс сайта с первых секунд, ибо не понимает, куда нужно нажать, чтобы получить желаемый результат.

Ямлик, ямл – файл с расширением. yaml, часто встречается как файл для скриптов.

Литература по бизнес-анализу

На английском языке

1. A Guide to the Project Management Body of Knowledge (PMBOK® Guide).

2. Champagne J. «Seven Steps to Mastering Business Analysis: The Essentials (Business Analysis Professional Development)». ISBN‐13: 978–1604271607.

3. Laping P. People Before Things. ISBN‐13: 978–0997368000.

4. Metera E. Universal Process Modeling Procedure: The Practical Guide To High-Quality Business Process Models Using BPMN. ISBN‐13: 978–1724914989.

5. McLeod P. «The Complete Guide to Requirements Management Using the REPAC® Framework». ISBN‐13: 978–1604271355.

6. Podeswa H. The Business Analyst» s Handbook. ISBN‐13: 978–1598635652.

На русском языке

1. Перерва А. Д. Путь аналитика. Практическое руководство IT-специалиста. – М.: Питер, 2015.

2. Куликов С. Тестирование программного обеспечения. Базовый курс. 3-e изд. – М.: Четыре четверти, 2020.

3. Стеллман Э. Постигая Agile: ценности, принципы, методологии / Эндрю Стеллман, Дженнифер Грин; перевод с английского Светланы Пасерба. – 3-е изд. – М.: Манн, Иванов и Фербер, 2019.

4. Кон М. Пользовательские истории: гибкая разработка программного обеспечения / Майк Кон; [пер. с англ. и ред. А. Г. Гузикевича]. – Москва [и др.]: Вильямс, 2012.

5. Паттон Д. Пользовательские истории. Искусство гибкой разработки ПО / Джефф Паттон; [перевод с английского О. Потапова]. – СПб [и др.]: Питер, 2019.

6. Макаровских Т. А. Документирование программного обеспечения. В помощь техническому писателю. – URSS. 2023.

7. Рис Э. Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели. – Альпина Паблишер, 2020.

8. Круг С. Не заставляйте меня думать. – Эксмо, 2024.

Об авторе

Валерий Комсков – опытный системный аналитик в области разработки и внедрения информационных систем. Обладая глубокими знаниями в сфере анализа требований, проектирования архитектуры систем и управления проектами, он успешно помогает организациям оптимизировать их бизнес-процессы и достигать стратегических целей.

Имеет степень магистра делового администрирования (MBA) и постоянно актуализирует свои знания на специализированных курсах, конференциях и воркшопах.

Работал бизнес-аналитиком, старшим бизнес-аналитиком и руководителем проектов в продуктовых и непродуктовых компаниях России, Израиля и Голландии: от израильского стартапа до крупнейшей нефтяной компании нашей страны.

Соучредитель финтех-стартапа «Индорсам».

Принимал участие в реализации и сопровождении множества успешных проектов, начиная разработкой мобильного приложения в сфере телекома и заканчивая информационными системами федерального масштаба в сфере генетики и нефтяной промышленности. Активно применяет методы Agile и Scrum, что позволяет эффективно взаимодействовать с командами и заинтересованными сторонами, а также быстро адаптироваться к изменяющимся требованиям бизнеса.

Автор верит в важность междисциплинарного подхода к бизнес-анализу и активно делится своим опытом с другими профессионалами через публикации статей, участие в специализированных мероприятиях. Его подход к бизнес-анализу основан на тщательном изучении потребностей пользователей и бизнес-целей, что дает возможность создавать решения, которые действительно приносят пользу.

Основал образовательный проект dualitas.ru, где первый продукт – «Курс для бизнес-аналитика-карьериста».

В этой книге делится знаниями о современных методах и инструментах бизнес-анализа, предлагает полезные рекомендации и примеры из своей практики, чтобы помочь читателям стать успешными специалистами.

Content

Валерий Валерьевич Комсков
Введение в профессию бизнес-аналитика: отправная точка для приобретения опыта

От автора

Благодарности

Кто такой бизнес-аналитик?

Основы разработки ПО

Роли в команде

Менеджер проекта (Project manager)

Менеджер продукта (Product manager)

Архитектор (Architect)

Аналитик (Analyst)

Дизайнер (Designer)

Специалист по информационной безопасности (Application security)

Разработчик (Developer)

Тестировщик (QA Engineer)

Техническая поддержка (Tech Support)

Жизненный цикл ПО

Жизненный цикл проекта

Этап планирования

Этап анализа требований

Этап проектирования

Этап разработки

Этап тестирования

Этап внедрения и поддержки

Стандарты жизненного цикла ПО

Модели разработки ПО

Классические модели разработки

Гибкие модели управления командой Agile и Kanban

Гибкие модели управления командой Scrum

Основы разработки требований

Заинтересованные лица

Типы заинтересованных лиц

Роли заинтересованных лиц

Профили заинтересованных лиц

Приоритеты проекта

Пользователи

Классы пользователей

Выявление классов пользователей

Для чего нужна классификация пользователей

Организационная модель

Требования

Сбор требований

Эффективность различных каналов коммуникации

Интервьюирование

Этап 1. Подготовка

Этап 2. Проведение встречи

Этап 3. Действия после проведения интервью

Анализ требований

Выделение пользовательских историй в отдельные пакеты

Описание требований с помощью вариантов использования

Нормальное направление варианта использования

Альтернативные направления варианта использования

Исключения вариантов использования

Последовательность вариантов использования

Выявление вариантов использования

Преимущества применения вариантов использования

Риски и ошибки при применении вариантов использования

Описание требований с помощью процессного подхода

Основные понятия процессного подхода

Способы описания бизнес-процессов

Виды бизнес-процессов

Нотации для моделирования бизнес-процессов

Структурные модели – нотация IDEF

Модели потоков работ – нотация eEPC

Модели исполняемых процессов – нотация BPMN

Модели потоков данных – нотация DFD

Модели потоков данных – нотация UML

Документирование требований

Документ об образе и границах проекта (Product Vision)

Информация, которую должен содержать документ об образе и границах проекта

План управления требованиями (ПУТ) и план управления документами (ПУД)

Документирование вариантов использования

Спецификация требований к ПО

Сколько спецификаций необходимо

Спецификация требований в проектах гибкой разработки

Проверка требований

Типовые ожидания от требований

Методы обеспечения качества требований

Трассировка требований

Согласование требований

Три золотых правила согласования

Зоны ответственности подразделений

Условия успешной реализации процедуры согласования

Алгоритм и способы согласования

Оформление результатов согласования

Пример оформления согласования требований

Приложения

IT-сленг

Литература по бизнес-анализу

На английском языке

На русском языке

Об авторе