Привет! По вашему запросу трилогию, посвященную оценке трудозатрат на реализацию требований, завершаем статьей, посвященной работе с возражениями Заказчика при ее согласовании. Рассмотрим кейс, когда Заказчик с оценкой не согласен, и что мы можем сделать, чтобы договориться о реализации.
Если ваш подход к оценке похож на описанный нами в статье, то наверняка вы уже сталкивались с тем, что реализация, казалось бы, простого требования может превратиться в совокупности в значительный объем работ.
И вот, вы презентуете результаты получившейся у вас оценки Заказчику, в ответ на что получаете ожидаемое возражение: “А почему так дорого? Что вы собрались там столько времени делать? У вас не может уйти столько часов. Пересчитайте, и вернитесь с другой оценкой”.
Вспомните чувства, которые охватывали вас, столкнувшись с этой ситуацией впервые. Подкатывает тревога от намечающегося конфликта, а в голове сразу появляются сомнения: “И правда дорого. Может мы ошиблись? Может получится сделать быстрее…”.
К сожалению, многие, оказавшись в такой ситуации, поддаются напору Заказчика и начинают интуитивно “резать” часы:
- первыми под сокращение, как правило, попадают часы на риски. “Да ладно, не случится никаких рисков, и так вон сколько насчитали”.
- второй волной идут часы на внедрение. “Ну, от консультаций можно отказаться, да и исправлений, наверное, будет немного”.
- а под третью волну могут попасть уже и основные работы по реализации. “Тут в принципе можно и быстрее разработать”.
Отсюда, кстати, и появилось название нашей первой главы “Поиск виноватых”, ведь если поддаться соблазну и порезать часы, высока вероятность, что вы серьезно подставите команду, которой предстоит это требование реализовать с большим дефицитом времени.
Если вы занимаетесь оценкой и реализацией требований достаточно давно, то наверняка, с такими ситуациями вы уже сталкивались и выработали свой инструмент для обработки подобных возражений Заказчиков. Мы же поделимся рекомендациями с теми, кому только предстоит готовить и защищать свои оценки.
Итак, как же все таки правильно обрабатывать такие ситуации, не подставив команду и не поругавшись с Заказчиком?
Обосновываем оценку
На самом деле, обоснование и защита оценки должны выполняться не после того, как мы столкнемся с возражением, а сразу при ее озвучивании.
Если на полученный запрос на оценку трудозатрат вы сообщите итоговое количество часов, то столкнетесь с рассматриваемым кейсом почти со 100% вероятностью.
Обоснование оценки является важным и обязательным этапом оценки требований, и при грамотном расчете и правильной презентации, ситуаций, когда оценка вызывает споры или ее придется корректировать, может вообще не возникать.
При обосновании оценки важно придерживаться рекомендаций:
- предоставлять содержимое оценки лучше укрупненными блоками: Проектирование, Разработка, Тестирование, Документирование, Развертывание и так далее. Не стоит показывать расчеты на рецензирование, внутреннее взаимодействие, исправление замечаний и прочие внутренние работы, сопровождающие процесс разработки. Заложенные на них часы необходимо прибавить к выделенным крупным блокам;
- если есть факторы, усложняющие реализацию, обязательно озвучьте их. Например, “на настройку решения заложено Х часов, так как потребуется настройка трех контуров: контур разработки, тестовый, продуктивный”;
- если в обязательности выполнения некоторых работ вы не уверены, обозначьте их в качестве вариантов снижения стоимости. Например, “в состав работ включено обучение пользователей. Если ваши специалисты готовы обучиться по документации самостоятельно, эти работы можно исключить”;
- обозначьте ограничения, в соответствии с которыми выполнялась оценка.
"Режем" часы правильно
Если вам удалось обосновать оценку Заказчику, но вы уперлись в ограниченный бюджет, необходимо предложить Заказчику варианты снижения стоимости. Однако, важно помнить главное правило:
Объем трудозатрат может быть уменьшен только за счет сокращения объема выполняемых работ.
Нельзя довериться интуиции и порезать часы на риски, внутреннее взаимодействие и прочие работы, изначально рассчитанные по имеющейся методике.
Рассмотрим “безопасные” варианты снижения стоимости:
- упрощение варианта реализации. Этот вариант подразумевает отказ от части требований, что потребует готовности идти на компромисс со стороны Заказчика. Предложите Заказчику от каких требований можно отказаться, чтобы уменьшить трудозатраты на разработку, спроектируйте самостоятельно более “дешевый” вариант, удовлетворяющий потребность, оцените применимость уже разработанных решений. Упрощение требования приведет к уменьшению времени на разработку и проектирование, а значит и пропорционально приведет к уменьшению рисков и сопутствующих работ. При достижении договоренностей явно зафиксируйте письменно, от какой функциональности вы отказываетесь, и обозначьте границы выбранного варианта;
- отказ от части выполняемых работ. Определите работы, от выполнения которых потенциально можно было бы отказаться с минимальными рисками. Как правило, к таким работам могут относиться работы по внедрению: обучение пользователей, подготовка инструкций, проведение совместного тестирования и т.д. Однако, подходить к их исключению стоит строго индивидуально, учитывая сложность работ, и явно прописывать ограничения и ответственных, если часть этих работ вы поручаете Заказчику. Помните, что на этапе оценки цель Заказчика - максимально сократить трудозатраты, поэтому он охотно может соглашаться на выполнение многих работ самостоятельно. Важно, чтобы на этапе внедрения эти договоренности не потеряли силу, а их невыполнение не привело к невозможности использования внедренного решения.
Какой из вариантов вы бы не выбрали, важно на этапе оценки договориться с Заказчиком об условиях изменения оценки и состава работ, в случае несоблюдения договоренностей или появления необходимости в изменении требований.
Откладываем "на развитие"
Если же попытки обосновать оценку или сократить объем работ не привели к согласию, обсудите возможность реализации требования позже в рамках развития системы. Продумайте с Заказчиком временное решение, которое они будут использовать до возвращению к требованию с новым бюджетом, и внесите текущее требование в бэклог задач по развитию.
Заключение
При работе с оценкой требований придерживайтесь основных правил:
- помогайте реализовывать полезные требования. На этапе оценки изучайте потребность и предлагайте свои варианты реализации задачи. Отговаривайте Заказчика от реализации бесполезных требований;
- выбирайте подходящий состав и способ выполнения работ для каждого требования индивидуально;
- не готовьте оценку “интуитивно”. Используйте наработанные методики расчета;
- учитесь договариваться с Заказчиком. Обосновывайте решения, которые вы предлагаете, ищите компромиссы;
- фиксируйте письменно договоренности, ограничения оценки и возможные риски;
- еще на этапе оценки договаривайтесь, как будут обрабатываться изменения требований или договоренностей.
На этом мы заканчиваем нашу серию статей про оценку требований. Если описанные рекомендации найдут отражение в вашей практике, то наверняка помогут вам и вашей команде реализовать требования в срок и без превышения трудозатрат.
Пишите в комментариях, а также нашем телеграм-канале, какие кейсы вам хотелось бы еще разобрать.