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

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

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

• реализация требования;
• внедрение;
• управление работами.

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

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

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

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

• изучение документации Заказчика/руководств внешних систем/предметной области. Объем часов рассчитывается исходя из объема материалов и количества заинтересованных человек;
• составление плана исследования и подготовку вопросов;
• проведение встреч в рамках интервью, исходя из их планового количества и количества участников команды;
• обработку результатов и документирование требований.

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

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

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

• В каком виде Заказчик будет согласовывать вариант реализации? Какие предъявляются требования к документированию?
• Требуется ли разработка мокапов?
• Требуется ли разработка моделей/схем процессов? Нужно ли строить модели «AS IS» или достаточно только «TO BE»?
• В каком виде будет поставлена задача на разработку?
• Нужно ли рецензирование спроектированного решения ведущим специалистом?

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

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

• задавать вопросы, которые команде необходимо обрабатывать;
• вносить правки, по итогам которых нужно корректировать артефакты.

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

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

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

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

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

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

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

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

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

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

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

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

• Как Заказчик будет принимать пакеты с разработкой? Он их установит самостоятельно, или необходимо заложить время на установку разработки участниками команды?
• Требуется ли настройка решения? Настройку будет выполнять Заказчик или участники команды исполнителя?

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

• трудозатраты на развертывание исходя из количества контуров (тестовый/продуктивный);
• трудозатраты на настройку решения, исходя из объема данных в разрезе настраиваемых контуров. Например, на тестовой базе можно предусмотреть выполнение настройки решения в минимально необходимом для тестирования объеме, в то время, как рабочая база может быть настроена в полном объеме.

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

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

• Кто будет выполнять миграцию? Заказчик или команда исполнителя?
• Какой объем данных? Сколько времени потребуется, чтобы их промигрировать?
• Как и кем будет происходить проверка миграции?

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

• Деловая игра. Данный формат предполагает, что Заказчик выполняет тестирование совместно с представителем команды исполнителя. Исполнитель заранее готовит тест-кейсы и раздает представителям Заказчика роли, которые они будут выполнять в рамках тестирования. Заказчик проходит кейсы в соответствии с ролями под управлением исполнителя. Вариант является самым эффективным и одновременно самым трудоемким для команды исполнителя, ведь в зависимости от объемов одна сессия тестирования может длиться от 2 до 4 часов. Его рекомендуется использовать при внедрении крупной функциональности, и при наличии у Заказчика должного бюджета;
• Демонстрация. Формат подразумевает проведение Заказчику демонстрации разработанной функциональности. Вариант рекомендуется использовать, когда объем модификаций небольшой, бюджет ограничен и/или у Заказчика нет возможности проводить полноценное тестирование;
  
• Самостоятельное тестирование Заказчиком. При этом варианте Заказчик самостоятельно выполняет тестирование, команда исполнителя оказывает только консультации. Вариант является самым “дешевым” и может предлагаться Заказчикам, готовым выделить своих специалистов на тестирование.
  

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

• разработку программы тестирования;
• проведение совместного тестирования или демонстрации;
• консультации в ходе тестирования.

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

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

• инструкции пользователей;
• руководства администратора;
• программа и методика испытаний;
• руководства по системе;
• документация API и др.

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

• подготовку к обучению (настройку стенда, разработку плана и программы обучения, подготовку практических заданий);
• проведение самого обучения исходя из предполагаемой длительности и количества групп слушателей;
• обработку результатов обучения (подготовку протоколов или отчета об обучении).

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

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

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

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

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

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

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

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

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