Чем грозит долгострой в разработке и с какими трудностями предстоит столкнуться на этом пути? Как бизнес-аналитик компании, которая 15 лет занимается разработкой и поддержкой одного продукта (СЭД), я решила поделиться своими мыслями и примерами из практики. Проблематика управления требованиями в любых программных продуктах с длительным периодом реализации – актуальный вопрос для аналитиков, руководителей проектов и владельцев продуктов. И, возможно, для непосредственных партнёров и заказчиков Docsvision, ожидающих выхода новых версий и заинтересованных в появлении новой функциональности.

К чему приводят гонки за сроками и когда гибкие методологии не подходят

Почему среди компаний-вендоров распространена тенденция отказываться от краткосрочных проектов (в нашем понимании это продукты с периодом выпуска до 1 года) и политики частых релизов, а также гибких методологий в разработке?
Наглядно даёт ответ на вопрос картинка, на которой выбрать можно лишь одно пересечение:



Как правило, в краткосрочном проекте нет возможности реализовать большой объём новой функциональности при подержании должного уровня качества, поэтому зачастую заказчики не видят для себя выгоды в переходе на новую версию (любое обновление содержит определенную долю риска, и они задумываются, стоит ли это того?). А для вендора любой релиз — дорогостоящее удовольствие, поскольку полноценная версия – это комплект инсталляции, документации, проведение тестов производительности, регрессионное тестирование, тестирование обновления и совместимости и ещё целый комплекс мер, которые нужно успеть в сравнительно небольшие сроки. Возвращаясь к картинке выше, мы попадаем на пересечения Качественно-Быстро или Быстро-Дёшево. Поскольку ресурсы не безграничны, это будет именно второе пересечение (читай, криво). Напрашивается вывод: частое обновление версии продукта невыгодно обеим сторонам.

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

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

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

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

Я не открою Америку, если скажу, что в чистом виде ту или иную методологию никто не использует. Что касается проекта разработки Платформы, то могу сказать, что в последнее время у нас используется своя собственная, смешанная методология. Это может стать темой для отдельной статьи, в рамках же данной стоит отметить, что это в какой-то мере Waterfall с элементами Agile (да, бывает и такое!): с одной стороны, четко определены стадии проекта в долгосрочной перспективе, присутствует подробная проектная документация для каждого этапа, качество имеет первоочерёдный приоритет по сравнению с ресурсами и временем, и всё это – неотъемлемые черты каскадной модели разработки. Это позволяет нам упорядочить производственный процесс и сделать его более контролируемым. С другой стороны, есть подвижный список требований, управление изменениями, что свойственно гибкой методологии.

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

Проблемы долгостроя

1. Большое количество требований, конечный список которых изначально не утверждён
С одной стороны, увеличив сроки реализации, можно увеличить и количество требований, включаемых в версию. Немного цифр: в краткосрочный (в среднем, полугодовой цикл) релиз мы выпускали порядка 35 фич в версии, в последней версии с долгосрочным периодом пока заявлено около 100. При этом за 10 лет в базе требований было зафиксировано без малого 1600 потенциальных фич, которые заказчики ожидают увидеть в продукте, и список запланированного на ближайшую версию постепенно растёт. Закономерный вопрос: до каких пор это будет продолжаться?

2. Определение приоритетов и оценки
Решение вопроса, озвученного в предыдущем пункте – в расстановке приоритетов среди отобранных владельцем продукта требований с учетом полученных оценок (разработки, тестирования, документирования и рисков), которые делаются на основании предоставленной аналитиком спецификации. В каждой компании свои подходы к расстановке приоритетов. Это может быть изучение статистики запроса о реализации той или иной фичи, результаты конкурентного анализа, партнёрские обязательства, да и здравый смысл никто не отменял. Мы регулярно проводим опросы среди заказчиков и партнёров, стараемся получить максимум информации извне (например, у нас открыт портал «Идеи и предложения», где каждый может оставить заявку или проголосовать за уже существующие предложения). Способами получения информации являются также семинары, вебинары и другие общественные мероприятия. На основании всех полученных данных устанавливаются приоритеты, но они могут меняться, за этим приходится следить в реальном времени. В нашей практике наибольшее влияние на позицию фичи в списке требований оказывает критичность её для проектов и общая востребованность: прежде необходимое, потом уже желаемое. Повышению приоритета может способствовать общий эффект от реализации функциональности – речь о wow/killer фичах.

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

3. Общее и частное



Эта проблема впервые возникает в любом продукте на момент формирования списка требований, независимо от периода его реализации. В отличие от проектного решения, где движение идёт от общего к частному, в продукте всё наоборот. Мы получаем извне отдельные пожелания, при этом заказчики описывают зачастую каждый свою специфическую задачу, и пожеланий по схожей теме может быть несколько. Ключевая задача — свести и учесть их все в конкретном требовании. Но проблема может возникнуть и повторно, и за тот период, что разрабатывается версия (здравствуй, долгострой), заинтересованные стороны могут предлагать новые решения или уточнять нюансы. Порой приходится вносить коррективы с учётом этих предложений в виде запросов на изменение, что может вызвать в итоге сдвиг точки Stop Development. Не всегда получается свести это просто к записи «1601-го пожелания к развитию системы».

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

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

4. Проблема айсбергов



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

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

Но не всегда удаётся обнаружить требование-айсберг на ранних этапах.

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

5. «Тяжёлые» фичи: делить или не делить?
В долгосрочном проекте мы можем позволить себе реализовать не только относительно простые требования, но и более сложные фичи, одна разработка которых требует от 80 часов. Как правило, для каждой такой доработки необходимо подробное и объёмное ТЗ, множество тест-кейсов и т.д. Тут и возникает необходимость разделения требования на несколько частей, ведь воспринимать меньший объём информации проще. Но, во-первых, при разделении требования теряется «картина в целом». Во-вторых, увеличивается общее количество требований к версии, что сказывается на эффективности контроля, оценке и управлении изменениями. В нашем случае, если разделить озвученные выше 100 фич, мы получим приблизительно трёхкратное увеличение количества требований. Безусловно, это не повод для отказа от разделения определенных требований на составляющие. Делить стоит, но там, где это действительно необходимо: например, при наличии независимых доработок в рамках одной фичи, скажем, в ситуации, когда сценарий общий, но для его реализации требуется реализация новой функциональности в разных частях системы.

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

Пример, когда требование можно разделить.
Первоначальное требование: «Поддержать интеграцию с Microsoft Lync 2013 в контролах карточек с возможностью сохранения истории диалогов».
После разделения: «Поддержать интеграцию с Microsoft Lync 2013 в контролах карточек» и «Реализовать возможность сохранения истории диалогов Microsoft Lync 2013 в карточке».

Пример, когда требование лучше не делить, несмотря на то, что дорабатываются разные объекты.
«Необходимо сделать отображение по разрядам в контролах Число и Целое. Например, вместо 1230000 показывать 1 230 000. По возможности сделать такие же доработки и для Таблицы».

Релиз близко

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

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

Анна Курманова, бизнес-аналитик Docsvision.