Инженерный подход к исследованию процессов и моделированию архитектуры и логики ПО

Меня зовут Гюльнара Антропова, я бизнес-аналитик и лидер проектов.

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

Люблю 1С, потому что она позволяет сделать очень многое. Уумею ее использовать. Именно этим умением я сейчас и хочу поделиться.

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

Аналитики – это люди, ценность которых нужно поднимать.

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

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

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

Большинство людей в этом случае начинают дорабатывать конфигурацию, это создает много сложностей

Мы работаем по технологии, о которой у меня был доклад на конференции Инфостарта в 2022 году.

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

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

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

Строим Концептуальную модель решения задачи на автоматизацию

Сейчас мы пошагово смоделируем работу аналитиков на реальном проекте

• Выделим из постановки задачи структуру взаимосвязанных сущностей

• Определим логику их взаимодействия

• Спроектируем решение

Для этого

• Проведем исследование процесса

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

• Получим проект Концептуальной модели решения

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

• Хотя бы одна форма – будет лучше, если их будет несколько.

• Список объектов системы – справочники, документы, еще что-то.

• И хотя бы примерное понимание, как пользователь будет с этим работать – ожидаемый Сценарий работы

Задача на автоматизацию

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

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

Стандартная задача, многие сталкивались.

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

Дополнительные сложности связаны с тем, что

• Количество пользователей в компании – несколько сотен, распределены по 100 филиалам

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

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

• Важно, что модуль должен максимально использовать типовые механизмы конфигурации. Например, справочник «Пользователи» однозначно создавать не надо – он есть везде.

• Но при этом ни один типовой объект не должен «пострадать» – не должен быть изменен

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

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

В этой системе будут работать люди и от внедренцев, и от заказчика.

• Владелец бизнеса с той и с другой стороны

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

• Аналитик

• Разработчик

• Руководители отделов

• Сотрудники

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

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

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

• Аналитик: «Мне нужно видеть в одном месте всю информацию по обращению – все его обсуждения и согласования с пользователями и разработчиками. Мне нужно видеть все обращения по одному объекту в одном месте, чтобы понимать, не противоречат ли они друг другу».

• Разработчик: «Мне особо ничего не надо, только список задач на разработку – это можно и в Гугл-таблице сделать, эта система – не нужна».

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

• Руководители отделов: «А зачем нужна такая система? Если у нас будут вопросы – мы просто позвоним вам или напишем в чате ТГ».

• Руководитель проекта от заказчика: «Мне надо видеть, как быстро вы будете отрабатывать наши обращения».

• Сотрудники заказчика: «Если нам будет что-то непонятно – мы будем писать в эту систему? А какие у нас могут быть требования к системе?»

Прорабатываем список требований

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

Цикл управления содержит функции:

• Планирование.

• Исполнение.

• Контроль.

• Управляющее воздействие.

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

• Например, функция исполнения у сотрудника в данном случае – создание обращения.

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

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

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

Цикл управления – это когда у нас есть:

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

• То, что произошло на самом деле.

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

• И должен быть список возможных действий – как мы отрабатываем это несоответствие.

Если всех этих четырех составляющих нет, то и управления нет.

Напомню, требование сотрудников к системе звучало так:

«Если нам будет что-то непонятно – мы будем писать в эту систему? А какие у нас могут быть требования к системе?»

По сути – требований нет

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

• Планирование – пока не понятно, что сотрудник будет планировать относительно обращений.

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

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

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

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

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

Для разработчика на этапе исполнения нужны возможности:

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

• менять у задачи этапы;

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

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

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

Для заказчика на этапе контроля нужно:

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

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

Для руководителя проекта от заказчика:

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

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

• В рамках контроля – когда заказчик закрывает обращение, у него должна быть возможность поставить оценку качества выполнения обращения (2, 3, 4, 5), чтобы нам собирать обратную связь и понимать, как улучшить качество обслуживания. Если план с фактом не совпадает, то ситуация должна эскалироваться.

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

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

Формируем Архитектуру данных

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

Например, у руководителя проекта со стороны внедренцев есть требование: нужно видеть влияние доработок на сроки и стоимость проекта.

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

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

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

• Список обращений (элементов справочника или документов) – дата создания, формулировка обращения

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

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

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

Проектируем объекты системы

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

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

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

• У руководителя отдела заказчика должен быть отчет для анализа исполнения заявок его подчиненных. В отчете должен быть организован отбор по подразделению. Отчет формируется на дату. Отчет содержит данные: «Сотрудник», «Тема обращения», «Ответ на обращение», «Дата обращения», «Дата ответа», «Срок в днях», «Оценка ответа», «Комментарий к ответу» и флаг «Повторное обращение» (если снят, то обращение первоначальное). По объектам системы: типовые справочники «Подразделения» и «Пользователи» (для сотрудников). «Оценка ответа» – перечисление.

• Аналитик должен в отчете видеть задачи за указанный период с полями «Исполнитель», «Номер обращения», «Дата обращения», «Тип обращения», «Статус». Используется типовой справочник «Пользователи», новые документы «Задачи» и «Обращения», а также новые справочники «Тип обращения» и «Статус обращения». Поскольку по одному обращению может быть несколько задач, это должен быть именно отчет, агрегирующий в себе несколько сущностей.

• У руководителя проекта со стороны внедрения должна быть обработка а-ля канбан-доска – сколько у меня на каждом сотруднике в единицу времени находится задач в разных статусах («На исполнении», «Завершена» либо «Отправлена на доработку»). Это должна быть именно обработка, для того, чтобы руководитель мог в моменте времени перераспределять задачи, управлять обращениями. И отдельно нужен отчет по результатам выполнения за определенный промежуток времени – сколько было задач в работе, сколько задач просрочено, сколько задач возвращено на доработку и по каким причинам, чтобы анализировать уже эффективность внедрения.

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

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

Первая часть пазла – проект Архитектуры системы

После того как мы собрали требования, происходит следующее:

• мы дополняем требования по циклу управления;

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

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

• и далее все это сливаем в одно.

По сути, это проект архитектуры системы, который мы получили на «ровном месте».

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

Вторая часть пазла – собираем процесс

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

• У пользователя возникает проблема – он создает обращение.

• Аналитик принимает обращение и проводит анализ.

• Аналитик создает ТЗ на доработку и отправляет разработчику.

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

• Аналитик тестирует, выполняет, закрывает обращение.

• На этом процесс завершается.

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

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

• Сотрудник пишет на листе свое обращение и приносит его аналитику.

• Аналитик на листе ставит галочку, что он обращение принял, и кладет лист в стопку.

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

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

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

В данном случае, таким объектом будет созданное обращение.

И дальше определяем то, как этот объект информационно меняется.

Если сотрудник принес лист аналитику, и аналитик на нем ничего не написал, – это операция передачи. С точки зрения создания информационной системы нас эта операция не интересует, потому что информация не меняется.

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

Система проектируется по потребности операций генерации.

Таким образом

• У нас должен быть объект «Обращение» – документ или конкретный элемент справочника.

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

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

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

Операции процесса у нас выглядят примерно так:

• Сначала мы берем любую операцию процесса

• Потом прописываем, что получается в результате этой операции с точки зрения информации.

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

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

Например:

• Аналитик принимает, анализирует.

• При этом он вносит некую информацию о приеме обращения.

• Обращение меняет статус

• Очевидно, что это происходит в карточке обращения через нажатие на кнопку «Принять на анализ».

Третья часть пазла – проектируем форму ввода

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

• Продумать, что должны содержать таблицы.

• Продумать, какая будет навигация по форме

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

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

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

• Пользователь создает новое обращение – очевидно, что в списке обращений нужна кнопка «Создать».

• Пользователь хочет узнать ход выполнения своего обращения – в форме обращения должно быть поле «Статус».

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

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

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

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

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

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

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

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

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

• Аналитик создает ТЗ на доработку. В обращении должна быть возможность ставить подчиненные задачи и видеть их на отдельной вкладке.

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

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

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

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

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

• Аналитику требуется глубокое обсуждение обращения с руководителем отдела, возможно, с РП-шниками. Есть обсуждения-уточнения, а есть обсуждения, которые принципиально решают ход этой доработки. Возможно, это глубокая доработка, и ее уже нужно обсуждать с руководителем, принимать решения на административном уровне. Для этого в обращении можно запланировать вкладку «Согласования», куда можно добавить любого согласующего – архитектора, РП, службу безопасности или других лиц, принимающих решения.

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

• Аналитик хочет видеть, начал работу разработчик или нет. Очевидно, что это статусы.

• Аналитик должен увидеть задачи от разработчика на уточнение. В обращении должна быть возможность ставить подчиненные задачи и видеть их на отдельной вкладке.

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

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

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

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

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

Дорожная карта разработки Концептуальной модели системы

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

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

• С одной стороны, этот список информационных результатов задает структуру базы.

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

Выводы:

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

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

Вопросы и ответы

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

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

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

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

Главное – системный подход.

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

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

*************

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