Унификация методики сбора требований: кейс успешного применения

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

О продукте

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

Задача

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

Эта статья написана по итогам проведения работы по выявлению, анализу и документированию требований для разработки «Be Better», поэтому посвящена решению второй задачи.

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

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

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

Читать такжеАутсорсинг системной аналитики

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

Решение

За основу взяли методику, описанную в «Настольной книге project-менеджера» Владимира Завертайлова.

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

Определение общего видения

На этом этапе мы: 

• Определяем суть и цели проекта; 
• Составляем список стейкхолдеров и собираем их требования; 
• Анализируем рынок для определения тенденций и конкурентов в данной сфере; 
• Определяем проблемы, которые призван решать будущий продукт; 
• Определяем потенциальных потребителей продукта; 
• Выделяем планируемые каналы продвижения; 
• Находим потоки доходов и издержек.

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

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

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

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

По итогам анализа подготовили два артефакта: 

1. Интеллект-карта с описанием видения проекта (примерный вид изображен ниже):

2. Заполненный шаблон Lean Canvas (пример исходного шаблона ниже):

Определение классов пользователей

На этом этапе составили список потенциальных классов пользователей и для каждого класса определили:

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

Мы выделили четыре класса потенциальных пользователей:

1. Специалисты (проходящие обучение). Они проходят процедуру оценки своего изначального уровня знаний. Получают стартовый грейд, где им доступны обучающие материалы по своей профессии. Специалист видит полную карту своего профессионального развития, Следует ей, изучает теоретический материал для освоения новых навыков. В рамках системы решает практические задания и отправляет закрепленному за ним ментору заявку на защиту навыков. По мере защиты навыков специалисту автоматически присваиваются очередные грейды;
2. Менторы. Проводят первичную оценку навыков подопечных специалистов, а также проводят защиту грейдов специалистов в процессе их обучения;
3. Методологи (администраторы). Управляют доступными профессиями и профилями пользователей, настраивают треки развития по каждой профессии;
4. Менеджеры. Ищут специалистов по заданным критериям, сравнивают их между собой, оставляют обратную связь по специалистам.

Полученные данные собрали в таблицу персон – еще один артефакт агрегации требований.

Читать такжеАутсорсинг или заказная разработка корпоративного портала

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

Карта экранов

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

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

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

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

Создание интерактивного прототипа

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

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

Примеры фрагментов страниц:

Дашборд специалиста

Просмотр прогресса обучения конкретного специалиста

Трек развития по выбранной профессии

Редактирование черновика профессии

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

После согласования прототипа приступили к написанию ТЗ.

Написание технического задания

Основной целью на данном этапе было сформировать ТЗ таким образом, чтобы оно давало полное представление как о продукте в целом, так и о его деталях. За основу взяли структуру SRS (software requirements specification) на основе стандарта ISO/IEC/IEEE 29148:2011. Также использовали более "визуальную" структуру ТЗ, приведенную в "Настольной книге project-менеджера" Владимира Завертайлова.

В итоге пришли к шаблону со следующими разделами:

1. Общее описание. Включает общий взгляд на продукт, описание границ проекта, классов и характеристик пользователей, описание приоритетов документации и список ссылок на используемые документы;
2. Требование к верстке. Включает описание операционной среды, а также ограничений дизайна и реализации;
3. Функциональное описание разделов системы. Самая объемная часть ТЗ. Здесь мы пошли от общего к частному: привели разработанную на предыдущем этапе карту экранов в сокращенном виде. Затем для каждого экрана, который сгруппировали по функциональным разделам, сформировали:
   1. общее описание: для чего он нужен, какие элементы содержит, каким пользователям доступен, какие действия могут совершать пользователи на этом экране. Также приводили ссылку на соответствующую страницу прототипа. По этому описанию и заказчики и впоследствии разработчики сразу смогут сориентироваться, о какой части будущего продукта идет речь;
   2. список ссылок на сценарии использования (use cases), которые могут быть запущены на этом экране. Сами сценарии вынесли в отдельный документ, чтобы не перегружать ТЗ. Так перешли от «для чего это нужно» в «как это работает»;
   3. список текстовых функциональных требований. Они детализируют описанное в предыдущих пунктах. Например, правила валидации полей форм, правила фильтрации и/или сортировки выводимых на экране данных, требования к пагинации и т.п.
4. Атрибуты качества. Требования к производительности, безопасности и прочее;
5. Приложения. Глоссарий, диаграммы, сценарии использования, шаблоны уведомлений.

При написании ТЗ опирались на данные, полученные на предыдущих этапах.

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

Проектирование API

Завершающим шагом спроектировали внутреннее RESTful API. Для документирования использовали формат OpenAPI. Итоговый yaml-файл приложили к документации проекта.

Выводы

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

• интеллект-карта с описанием видения проекта;
• заполненный шаблон Lean Canvas;
• таблица персон;
• карта экранов;
• полное техническое задание на реализацию;
• документация внутреннего API.

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

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