Часть 1 можно найти, нажав на связь Часть 2 можно найти, нажав на связь
Использование спецификаций требований в управлении проектами
Во вступительной части была упомянута группа участников проекта, которым мы также обещали облегчить жизнь и обеспечить условия для эффективного использования требований — это менеджеры проектов.Что получают эти многоуважаемые люди, выбирая предложенный в статье подход? Планируя работы по таким подробным спецификациям на раннем этапе, можно точно определить ресурсы и сроки, необходимые для их реализации.
Время, необходимое для создания Таблицы, Формы, Функции, Отчета и т. д. Вы можете посчитать его на примере одного проекта и использовать эти данные как ориентир в дальнейшем.
А в наших спецификациях перечислены все таблицы, формы, процедуры и т.д. и посчитать их количество нетрудно.
Но, конечно, есть ошибки и процедура другая, поэтому для более точного расчета можно использовать коэффициенты сложности реализуемых объектов.
Например, «сложная форма» — 1,5; «правильная форма» — 1; «простая форма» — 0,5. Для каждого типа элемента мы подбираем свой диапазон значений коэффициентов.
Полученные таким образом данные можно внести в электронную таблицу и сократить общие затраты в человеко-днях или человеко-часах (как вам удобнее) по подсистемам и проекту в целом.
В упрощенном виде таблица предварительного расчета трудоемкости может выглядеть, например, так: 
Это очень удобный инструмент для предварительного расчета стоимости кодирования в проекте, а также: тестирования, разработки инструкций и других процессов подготовки к передаче заказчику.
Приступить к построению такой таблицы можно на этапе формирования спецификации; в этом случае, когда они будут доработаны и уточнены, можно наблюдать изменения требуемых ресурсов и принимать решение о выборе приоритетных работ или целесообразности их реализации вообще.
Вы думаете, это все? И только поэтому мы обманули себя составлением столь детальных спецификаций.
Но нет, это только первый шаг.
Взгляните на пример оглавления, где видны заголовки спецификации.
Разве это не похоже на структурированный список задач?
Поскольку мы постарались сделать каждую низкоуровневую спецификацию максимально похожей на атомарную задачу для разработчика, специалисту по ПМ остается лишь выбрать из требований спецификации и передать их в инструмент создания расписания проекта.
Причем пункты спецификации следуют в том порядке, в котором их следует выполнять (об этом мы тоже позаботились).
При этом разделы верхнего уровня вписываются в расписание проекта как группа задач, а нижние непосредственно как задачи.
Если название спецификации слишком длинное для названия задачи, их можно преобразовать, но идентификатор спецификации остаётся железобетонным, это ось проекта.
Ниже приведен пример построения графика по заданию: 
Ну а дальше дело техники: планирование рисков, распределение ресурсов и т.д.
Естественно, этот подход не отменяет и не заменяет управление требованиями.
Они будут меняться, смещаться приоритеты и многое другое может случиться, а потому целесообразно использовать прослеживаемость требований: от самих потребностей пользователей, до требований высокого уровня, далее к спецификациям и к плану-графику проекта.
Поэтому на каждом этапе мы использовали идентификацию объектов и выстраивали цепочки ссылок на связанные артефакты в требованиях.
Использование спецификаций требований в управлении качеством продукции
Подобные спецификации, как было отмечено выше, просто рай для QA-специалистов, поскольку содержат сценарии, в очень подробной форме описывающие действия пользователя с целевым продуктом.Они могут составлять основу тест-кейсов, карт приемки и т. д. Также очень подробно прописаны требования к визуальным формам, отчетам, правам доступа пользователей к элементам пользовательского интерфейса, процедурам и структуре хранения данных.
На основе сценариев из нашего технического задания также удобно готовить пользовательские инструкции и это еще один момент, позволяющий сэкономить на проекте.
Заключение
В статье я хотел акцентировать внимание на том, что целевой продукт — это кульминация работы команды проекта в целом.Именно по его качеству оценивается результат проекта.
И неважно, насколько искусно и красиво выглядят требования, если команда, их реализующая, тратит львиную долю своего времени не на кодирование, а на попытки правильно воспринять информацию и поиск в документации нужных фрагментов решений, которые им нужны.
реализовать непосредственно в продукте.
В статье я постарался на примерах из личного опыта показать, как можно подобрать оптимальное содержание требований, чтобы оптимизировать их использование в процессе разработки программного продукта, сделав его более комфортным и целесообразным.
Такой подход позволяет существенно снизить стоимость проекта за счет более рационального использования времени команды в проекте.
По моему опыту, один аналитик способен постоянно обеспечивать работой 3-5 программистов, в зависимости от уникальности и сложности проекта.
При этом производительность разработчиков существенно возрастает и становится более предсказуемой с точки зрения времени внедрения.
С другой стороны, уровень качества результатов работы команды становится более равномерным и затраты на ее поддержку можно оптимизировать.
Еще одним важным моментом, с точки зрения эффективного использования требований командой, является правильная организация процесса передачи аналитиком результатов своей работы команде разработчиков на этапе внедрения.
Но эта тема достойна отдельного разговора.
Данную статью не следует воспринимать как некие рекомендации по обязательному использованию предлагаемого состава и формы технического задания.
Каждая команда должна разработать собственную концепцию создания спецификаций.
Более того, у команды может быть несколько шаблонов для разных предметных областей и используемых технологических платформ.
Такие шаблоны могут быть разработаны как технологические карты процесса разработки программного обеспечения.
В статье использованы материалы моей книги «Системному аналитику… О проектировании программных продуктов».
Теги: #Управление проектами #оптимизация #проектирование #формирование требований #тестирование #разработка #Тестирование ИТ-систем #Анализ и проектирование систем #проектирование и рефакторинг #Функциональное программирование #Промышленное программирование
-
Fun Starts 2: For_Each Против Накопления
19 Oct, 24
