Найти тему

Фреймворк постановки задач аналитика 1С. Как избежать сферических коней и ставить задачи с 1-го раза

Оглавление

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

Какие бывают требования и кому они нужны

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

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

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

Фреймворк постановки задач аналитика 1С. Как избежать сферических коней и ставить задачи с 1-го раза

Технология работы с требованиями как путь к развитию аналитика 1С

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

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

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

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

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

Анализ компетенций аналитика

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

Для определения «рангов» компетенций сотрудников, мы сформулировали следующие классы роли аналитика 1С-систем:

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

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

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

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

Прослеживаемость требований в жизненном цикле проекта внедрения 1С

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

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

4 шага на пути создания систем на базе 1С

  1. Формулировка целей и задач с выявлением требований бизнеса.
  2. Описание задач и требований пользователей к системе.
  3. Моделирование покрытия требований в автоматизированной системе 1С.
  4. Отслеживаем по матрице трассировки требований. Фиксируем: требование покрывается типовым функционалом выбранного 1С-решения, либо оно должно быть дополнено и сформулировано в виде функционального разрыва.

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

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

Данная визуализация применима для удобства отслеживания менеджерами проекта, а по факту – это инструмент для архитектора, для того, кто управляет содержанием проекта.

Как добиться сверхрезультатов, используя декомпозицию

Декомпозиция как ключ к успеху ведущего аналитика 1С или функционального архитектора является основополагающим фактором для управления и решения поставленных задач.

Принцип декомпозиции на проекте мы распространяем:

  • на все этапы;
  • на всю деятельность ведущих ролей.

Каталогизация и ведение реестров реализуют этот принцип со стороны содержания.

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

Жизненный цикл задачи

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

  1. Бэклог (незапланированная в конкретный момент времени задача без исполнителя срока и плановой оценки) – статус Новая.
  2. Открытая задача, имеющая Исполнителя, плановую оценку и срок ее исполнения – статус В работе.
  3. На проверке – выполненная задача Исполнителем (аналитиком или разработчиком), требующая проверки или согласования архитектором, ведущим аналитиком 1С.
  4. Сдача Заказчику – сдача, приёмка, передача клиенту на согласование.
  5. Закрыта – задача принята Заказчиком.

Workflow задач аналитика 1C

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

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

Главным в этом походе является соблюдение простых правил:

  • оценка и планирование сроков для каждой задачи;
  • формулировка описания с применением минимально необходимых правил СМАРТ;
  • что нам в этом помогает – связка каждой задачи с вышеуказанным процессом формирования требований (мы связываем задачу с конкретной ссылкой Confluence).
-2

Подготовка и проведение интервью

Результатом интервью является не просто протокол, а описание процесса «Как есть»

Обозначим кратко, как эффективно провести интервьюирование нового клиента на этапе предпроектного обследования:

  1. Готовим повестку, по каким бизнес-процессам будет опрос, в ходе интервью подглядываем в опросник.
  2. Даем вводную клиенту, что обсуждаем именно процессы и уровень автоматизации, требования к автоматизации:
  • что на входе у события: письмо, регламент, звонок и т.п. (в будущем поможет с ответом на Зачем – при анализе требований);
  • кто исполнитель;
  • какие шаги выполняет;
  • что на выходе получает;
  • в каких системах работает;
  • чем регламентируется процесс.

3. В рамках протокола фиксируем, в том числе с какими НСИ и выходными формами пользователь работает: назначение, состав, в какой системе.

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

Выходим на моделирование

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

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

Фиксируем разрывы

  1. Должна быть привязка к процессу и функциональному требованию, которое не покрывает типовой функционал.
  2. Описываем, какие есть развилки у Заказчика. Если не делаем совсем, есть ли обходные пути, верхнеуровнево – как ожидается выполнить доработку.
-5

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

Результат обследования бизнес-процессов

-6

В заключении

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

-7

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

Присоединяйтесь к команде WiseAdvice-IT!

Реализуем проекты внедрения 1С любой сложности по всей России.