Разбираем технологии работы с требованиями для развития аналитика 1С. В разрезе фреймворка проходим этапы проекта и инструменты работы с требованиями на всём протяжении жизненного цикла проекта. Как использовать вспомогательные средства для работы аналитика и добиваться лучших результатов с помощью декомпозиции, рассказывает Антон Тидор, руководитель проектов WiseAdvice-IT.
Какие бывают требования и кому они нужны
Когда собираются разные эксперты говорить об одном и том же документе или рассматривать определенную задачу, может возникнуть разная интерпретация требований. Кто-то говорит, как оказывается, о бизнес-требованиях, другой – о функциональных, третий – о системных к продукту или даже к проекту, четвертый – о пользовательских требованиях или вовсе каких-то ограничениях.
Всё это умещается в одном понятии. Причём требования могут иметь измерение во времени: текущие функции системы, идеи, пожелания пользователей, термины бизнеса, целей и так далее.
Сами требования являются основой любого проекта, они определяют потребности, функции, содержание и критерии результатов, а также являются базой практически для любых областей управления проектом. Поэтому они важны как для аналитика, так для руководителей проекта и всех остальных участников.
Технология работы с требованиями как путь к развитию аналитика 1С
Чтобы все были «в контексте», необходима поэтапная проработка требований. В этом, в первую очередь, состоит задача аналитика:
- до фиксации «некоторого требования» нужно его выявить;
- искусство аналитика – это правильное выявление и формулирование требований за заказчика, за коллег и любого участника процесса, и их систематизация.
Кроме выявления и формулирования ещё очень важно применять декомпозицию этих требований и правильную их расстановку в процессе всего жизненного цикла проекта.
Без относительно стабильных, базовых и согласованных требований управление содержанием проекта, как и его успех – невозможны.
Согласованные требования обеспечивают базу для планирования разработки системы или её частей и их приёмки при завершении работ.
Анализ компетенций аналитика
Сбор требований, анализ и обработка являются основополагающими задачами в любом проекте. Соответственно, роль аналитика в этом процессе максимальна.
Для определения «рангов» компетенций сотрудников, мы сформулировали следующие классы роли аналитика 1С-систем:
1. Младший аналитик (Junior) – это специалист, который хорошо изучил в теории механизмы системы и последовательность действий пользователей в ней. При сборе требований, анализе и постановке задачи на разработку исходит из пожеланий пользователя к отдельным функциям и реализует их.
2. Аналитик – имеет опыт внедрения и знания предметной области и функций (задач) бизнеса. В этом случае подход к сбору и анализу требований складывается от потребностей решения задачи, сформулированной бизнес-языком. Более опытные аналитики могут задавать встречные вопросы, анализировать связи задач от пользователей и выявлять комплексные процессы, владельцев процессов, взаимосвязи.
Отсюда формируется цель развития и прообраз будущего архитектора в следующем наборе компетенций:
- аналитично подходить к сбору требований, формулировать вопросы зачем и для чего, противопоставлять тезисы заказчика на основе опыта реализации процессов в 1С в аналогичных сферах, предприятиях;
- предлагать оптимальные решения для поставленных задач с использованием типовых инструментов;
- ранжировать требования, выявлять из неопределённостей и недоформулированных задач реальные потребности бизнеса, тем самым определять весь скоуп бизнес-процессов.
Прослеживаемость требований в жизненном цикле проекта внедрения 1С
Опытный аналитик 1С на проекте достигает целостного подхода, может проложить путь к ключевой точке, решению корневых задач для достижения основной цели при автоматизации бизнес-процессов.
Для реализации такого системного подхода мы предлагаем такую скорее методику, чем набор конкретных инструментов. Это простой базис, формулирующий подход к работе с требованиями на всём пути жизненного цикла создания систем на платформе 1С:Предприятие.
4 шага на пути создания систем на базе 1С
- Формулировка целей и задач с выявлением требований бизнеса.
- Описание задач и требований пользователей к системе.
- Моделирование покрытия требований в автоматизированной системе 1С.
- Отслеживаем по матрице трассировки требований. Фиксируем: требование покрывается типовым функционалом выбранного 1С-решения, либо оно должно быть дополнено и сформулировано в виде функционального разрыва.
Это сквозной процесс да работы с требованием, наших действий и результатов, дополнить который лучше интерактивной картой. В WiseAdvice-IT мы применяем у себя Confluence, где каждое требование имеет свой код, каждый бизнес-процесс или группа процессов – свой, как и функциональные разрывы, и доработки впоследствии. Фактически, этот код является основным квантом деления и позволяет нам двигаться от начала до конца, проваливаться ретроспективно, возвращаясь к требованию первоначальному.
На картинке также отражена статус-карта освоения скоупа проекта в разрезе функциональности. Декомпозиция требований в применении к жизненному циклу может быть собрана обратным путём, аккумулируя статус по каждому этапу. То есть мы можем бизнес-процесс разложить по этапу моделирования и увидеть прогресс освоения этих моделей. Тут же мы отслеживаем согласование и покрытие инструкциями этих бизнес-процессов. То же самое с функциональными разрывами: если требование включено в какой-то конкретный фейр, значит оно должно быть спроектировано. Это мы видим по включению его в техническое решение. Аналогично и с реализацией.
Данная визуализация применима для удобства отслеживания менеджерами проекта, а по факту – это инструмент для архитектора, для того, кто управляет содержанием проекта.
Как добиться сверхрезультатов, используя декомпозицию
Декомпозиция как ключ к успеху ведущего аналитика 1С или функционального архитектора является основополагающим фактором для управления и решения поставленных задач.
Принцип декомпозиции на проекте мы распространяем:
- на все этапы;
- на всю деятельность ведущих ролей.
Каталогизация и ведение реестров реализуют этот принцип со стороны содержания.
- Фактически каждый КОД (коды процесса, группы процесса, проектных и технических решений) является эквивалентом измерения работы аналитика или разработчика, и определение этих квантов и есть задача ведущих ролей проекта.
- Сотрудник, обладающий этой ролью на проекте – декомпозитор (как композитор, сочиняющий мелодию из разных звуков). Согласно правилам, архитектор и ведущий аналитик определяют содержание проекта.
Жизненный цикл задачи
Сформулированные таким образом задачи могут быть отражены в любом трекере. Схоже с задачей по реализации фичи и имеет достаточно простой жизненный цикл:
- Бэклог (незапланированная в конкретный момент времени задача без исполнителя срока и плановой оценки) – статус Новая.
- Открытая задача, имеющая Исполнителя, плановую оценку и срок ее исполнения – статус В работе.
- На проверке – выполненная задача Исполнителем (аналитиком или разработчиком), требующая проверки или согласования архитектором, ведущим аналитиком 1С.
- Сдача Заказчику – сдача, приёмка, передача клиенту на согласование.
- Закрыта – задача принята Заказчиком.
Workflow задач аналитика 1C
Выделим основное из жизненного цикла проекта на карте задач команды.
Все задачи делятся согласно жизненному циклу и вышеизложенному подходу к детализации (чётко от определений требований к их реализации).
Главным в этом походе является соблюдение простых правил:
- оценка и планирование сроков для каждой задачи;
- формулировка описания с применением минимально необходимых правил СМАРТ;
- что нам в этом помогает – связка каждой задачи с вышеуказанным процессом формирования требований (мы связываем задачу с конкретной ссылкой Confluence).
Подготовка и проведение интервью
Результатом интервью является не просто протокол, а описание процесса «Как есть»
Обозначим кратко, как эффективно провести интервьюирование нового клиента на этапе предпроектного обследования:
- Готовим повестку, по каким бизнес-процессам будет опрос, в ходе интервью подглядываем в опросник.
- Даем вводную клиенту, что обсуждаем именно процессы и уровень автоматизации, требования к автоматизации:
- что на входе у события: письмо, регламент, звонок и т.п. (в будущем поможет с ответом на Зачем – при анализе требований);
- кто исполнитель;
- какие шаги выполняет;
- что на выходе получает;
- в каких системах работает;
- чем регламентируется процесс.
3. В рамках протокола фиксируем, в том числе с какими НСИ и выходными формами пользователь работает: назначение, состав, в какой системе.
Роль заказчика на данном этапе сводится к согласованию протокола, где нужно проверить правильность описания бизнес-процессов и зафиксированных требований, а также совместно с командой 1С-интегратора расставить приоритеты требований и определить текущий уровень автоматизации.
Выходим на моделирование
Задача моделирования – продемонстрировать Заказчику, как в системе реализуются его требования, либо зафиксировать функциональный разрыв.
- Перед встречей готовим описание модели. Это может быть схема + таблица шагов или только таблица шагов, зависит от договоренностей на проекте.
- Очень удобно при фиксации шагов сразу же отражать требование, которое мы демонстрируем.
Фиксируем разрывы
- Должна быть привязка к процессу и функциональному требованию, которое не покрывает типовой функционал.
- Описываем, какие есть развилки у Заказчика. Если не делаем совсем, есть ли обходные пути, верхнеуровнево – как ожидается выполнить доработку.
И работаем с матрицей трассировки функциональных требований. Все наши требования должны быть либо отражены в Модельном примере, либо закрыты зарегистрированным функциональным разрывом.
Результат обследования бизнес-процессов
В заключении
Рассмотрим известную аллегорию понятия «Разделяй и властвуй» немножко в другом ключе, нежели мы его привыкли знать, - в разрезе декомпозиции.
Разделяя весь скоуп проекта на малые задачи, разбивая их в трекере, мы повышаем управляемость проекта и добиваемся успеха. Чего и всем желаем.
Присоединяйтесь к команде WiseAdvice-IT!
Реализуем проекты внедрения 1С любой сложности по всей России.