С частью 1 можно ознакомиться, перейдя по ссылке
С частью 2 можно ознакомиться, перейдя по ссылке

Использование спецификаций требований в управлении проектом

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

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

Но, естественно есть погрешности и процедура – процедуре рознь, поэтому, для более точного расчета можно использовать коэффициенты сложности для реализуемых объектов. Например, «сложная форма» — 1,5; «обычная форма» — 1; «простая форма» — 0,5. Для каждого типа элемента подбираем свою линейку значений коэффициентов. Полученные таким образом данные можно занести в электронную таблицу и сбить итоговые затраты в человеко\днях или человеко\часах (как Вам удобнее) по подсистемам и проекту в целом.

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



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

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



Разве это не похоже на структурированный перечень задач?

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

Ниже приведен пример построения плана-графика по спецификациям:



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

Использование спецификаций требований в управлении качеством продукта

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

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

Заключение

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

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

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

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

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

В статье использованы материалы из моей книги «Системному аналитику … О проектировании программных продуктов».