О качестве требований в ИТ проектах, начистоту (с позиции команды разработки). Часть 3

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

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


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

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

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

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



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

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



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

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

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



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

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


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

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

    Заключение


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

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

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

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

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

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

    Ну. И что?
    Реклама
    Комментарии 6
    • 0

      Начистоту?

      • 0
        Спасибо за статьи. Давно мечтаю поработать в команде в которой используются инструменты управления требованиями.
        • 0
          И расскажите, пожалуйста, как продавали необходимость внедрения управления требованиями владельцу продукта/менеджеру проекта? С какими подводными камнями столкнулись и какими преимуществами оперировали? Так же было бы интересно как уживается управление требованиями со скрамом.
        • 0
          как продавали необходимость внедрения управления требованиями владельцу продукта/менеджеру проекта?

          Я бы не хотел называть эту статью рекламным буклетом, для продажи необходимости чего либо, а примеры представлять пробничками. Тут скорее подойдет слово Рецепт. И применять его необходимо, если проявляются острые симптомы болезни в проекте. Например, программисты увольняются из-за того что они, раз за разом, извращаясь переделывают свои решения, а виной тому «недалекий заказчик», который не может по человечески объяснить им, чего же он все таки хочет. Возможно самому заказчику необходимо объяснить, чего он хочет, не показом очередной версии продукта, которая пойдет в корзину, а как-то иначе, не мучая ни его, ни менеджера проекта у которого уже исчерпаны все запланированные ресурсы и нервы, а понимания что надо сделать так и не пришло. При работе например, на гос.заказ, где заказчик вредный, сроки ограничены, а реальный бюджет не такой уж и большой, подобные ошибки могут стоить не только репутации фирмы, но и значительных денежных потерь (хотя последние аргументы можно переставить местами).
          • 0
            >«мы постарались каждую спецификацию нижнего уровня сделать максимально схожей с атомарной задачей для разработчика»
            Примеров бы побольше на эту тему.
            Как сделать спецификации нижнего уровня атомарными и независимыми друг от друга и порядка их реализации
            • 0
              А их не надо так уж сильно стараться делать независимыми друг от друга и порядка. На самом деле очень часто в документе могут быть перекрестные ссылки. Естественно такой документ готовится в несколько проходов, дополняя разделы ссылками. А в помощь этому допущению, в большинстве трекеров, задачи могут иметь зависимости, в том числе блокировать одна другую. Тут уже можно дать волю PM или teamlead_у, разруливать ситуацию. А то меня упрекают, что у них этот подход всю работу забрал.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое
            Интересные публикации