Оценка требований. Глава 2. Что учесть, чтобы “попасть”

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

Все работы я условно разделила на 3 блока:

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

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

1. Исследование. Сбор требований является первой задачей, которую исполнителю оценки предстоит спланировать и оценить. Трудозатраты на проведение исследования зависят от выбранных методов сбора требований и, чаще всего, определяются «экспертно». Исполнителю необходимо спланировать, потребуется ли проведение интервью, совещаний, изучение документации или GAP-анализ.

В зависимости от выбранных методов, прогнозируется время на:

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

Соответственно, Исполнитель на этапе оценки должен определить, какие работы в конкретном случае, помогут добиться цели.

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

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

3. Согласование спроектированного решения с Заказчиком. Трудозатраты команды на согласование результатов проектирования нередко несправедливо не учитывается в оценке. В ходе согласования Заказчик знакомится с артефактами, созданными по итогам проектирования, и может:

Предугадать количество таких разъяснений и правок в часах бывает крайне сложно, поэтому мы рекомендуем закладывать процент от трудозатрат на проектирование: 10-20%.

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

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

Чем больше вводных и ограничений вы обозначите, тем точнее будет оценка.

Помимо прямых затрат на разработку, в этап также рекомендуется включать время на альфа-тестирование разработчиком, а также рецензирование кода (если такая практика имеет место быть). Эти трудозатраты можно рассчитать как процент от времени на разработку: 10-20%.

5. Тестирование. Оценивать трудозатраты на тестирование можно многими способами (вот пример интересной лекции на эту тему). Например, можно описать состав кейсов, которые нужно протестировать, и оценить их трудоемкость. Обычно такой подход используют команды, в которых есть выделенный тестировщик. Если же выделенного специалиста нет, трудозатраты на тестирование можно рассчитать как процент от трудозатрат на разработку: 30-60%. Значение показателя зависит от настройки и предусловий, которые нужно выполнить для тестирования, необходимости разработки тест-кейсов, а также специфики самого требования.

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

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

6. Сборка пакета. Обычно трудозатраты по подготовке разработки к передаче Заказчику стандартизированы и имеют нормативное значение.

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

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

1. Развертывание и настройка. Для оценки трудозатрат на установку и настройку решения необходимо предусмотреть:

Если же работы требуется выполнить командой исполнителя, то необходимо рассчитать:

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

При оценке работ по миграции необходимо определить:

3. Приемочное тестирование. Существуют несколько способов организации того, как Заказчик будет принимать работы. Возьмем самые распространённые и расположим их в порядке убывания трудоемкости:

В зависимости от выбранного формата рассчитываются трудозатраты на:

4. Доработки по итогам тестирования Заказчиком. Трудозатраты на исправление замечаний и внесение изменений по итогам тестирования Заказчиком так же, как и при внутреннем тестировании, сложно предугадать в часах. Рекомендуется заложить время на эти работы в виде процента от времени на разработку: 10-30%. Значение может зависеть от качества проведения исследования и опыта команды исполнителя.

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

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

7. Консультации. Нередко после сдачи разработки в продуктив, работы по внедрению не заканчиваются. На старте работы с решением у Заказчика возникают дополнительные вопросы и уточнения. Мы рекомендуем заложить на такие консультации 3-10% от времени на разработку.

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

1. Управление командой. Если над реализацией требования работает не один человек, потребуется управление командой. Здесь учитываются трудозатраты на планирование, контроль выполнения работ, внутреннее взаимодействие команды. Оценить эти работы также можно как процент от общего объема работ: 5-15%.

2. Управление рисками. Трудозатраты, закладываемые “на риски” предполагают буфер часов, предназначенный для учета непредвиденных работ или минимизации ошибок оценки. Размер рисков определяется как процент от общих трудозатрат и варьируется как правило в диапазоне от 3 до 20%. Размер процента, как правило, зависит от новизны выполняемых работ для команды, зависимости от внешнего исполнителя/подрядчика, а также объема неизвестных. Чем точнее собраны требования, тем меньше риски.

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

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

3. Если вы готовите оценку впервые, не стесняйтесь попросить ее рецензии у более опытных коллег. В нашей компании существует практика «защиты» расчетов перед экспертной комиссией до их предоставления Заказчикам.

Желаем всем нашим читателям стопроцентного попадания! Следующая глава на горячую тему: рассмотрим, что делать, когда Заказчик с оценкой не согласен.

А для того, чтобы не пропустить выход следующих глав, подписывайтесь на наш телеграм-канал, в котором мы публикуем анонсы статей