Почти ни один проект не проваливается из-за одного крупного изменения. Проекты проваливаются из-за тридцати небольших изменений, каждое из которых по отдельности выглядит разумным, но ни одно из них не было учтено в смете.
Уточнение или изменение
Различие важно, и обычно его можно определить.
Уточнение устраняет неоднозначность в том, о чём уже договорились. В спецификации сказано, что пользователи могут сбросить пароль; клиент подтверждает, что ссылка для сброса должна истекать через час. Это всё равно планировалось реализовать — была согласована деталь.
Изменение добавляет, исключает или меняет согласованный объём работ. В спецификации сказано, что пользователи сбрасывают пароль по электронной почте; теперь клиент хочет добавить SMS. Это новая работа.
Серая зона возникает там, где в спецификации ничего не сказано. Если в спецификации не указано, как долго действует ссылка, кому-то всё равно пришлось бы это решить, и такое решение является уточнением. Если в спецификации вообще не упомянуты SMS, их добавление — это изменение. Полезное правило: если разумный разработчик, прочитав спецификацию, всё равно реализовал бы это, значит, речь идёт об уточнении.
Почему небольшие изменения стоят дороже, чем кажется
Изменение, на кодирование которого требуется два часа, редко обходится всего в два часа. Оно также включает:
- Обсуждение и описание самого изменения.
- Влияние на уже реализованные элементы — новое поле появляется в форме, проверке данных, базе данных, отчётах и выгрузках.
- Повторное тестирование всего, чего касается изменение.
- Обновление документации и всех уже утверждённых макетов.
- Стоимость прерывания работы, которая реальна, но редко учитывается в смете.
Именно поэтому изменение, запрошенное на этапе проектирования, стоит лишь малую долю от такого же изменения, запрошенного после приёмочного тестирования. Разница между этими этапами велика — часто говорят о порядке величины, и направление этой зависимости не оспаривается, даже если точное значение различается.
Если заранее объяснить это клиенту, последующие разговоры пройдут гораздо проще: клиент поймёт, почему на этапе проектирования от него требуется тщательно всё обдумать.
Достаточно простой процесс управления изменениями
Для небольшого проекта достаточно четырёх шагов:
- Запрос фиксируется в письменном виде. Один абзац в едином месте, доступном обеим сторонам. Устные изменения становятся причиной большинства споров.
- Разработчик оценивает запрос — трудозатраты, стоимость и влияние на дату сдачи. Влияние на сроки не менее важно, чем стоимость, но о нём часто забывают.
- Клиент письменно одобряет или отклоняет запрос. Отклонение — вполне допустимый результат, и принять такое решение должно быть легко.
- Одобренные изменения добавляются в график и счёт, а дата сдачи официально переносится, если она изменилась.
Чаще всего пропускают третий шаг, и именно это в конце приводит к спору: была выполнена работа, за которую никто официально не согласился платить.
Работа с небольшими изменениями
Оформление формального запроса на изменение для корректировки, занимающей пятнадцать минут, требует больше усилий на процесс, чем на саму работу, и создаёт ощущение конфронтации. Есть два практичных подхода:
Резерв на изменения. Включите в договор определённое количество часов на небольшие корректировки и ведите их учёт с предоставлением отчётности. После исчерпания резерва последующие изменения оцениваются отдельно. Это прозрачно и устраняет лишние препятствия для действительно незначительных запросов.
Объединение запросов. Собирайте небольшие изменения и оценивайте их вместе в заранее определённые моменты. Перерывов в работе становится меньше, а клиент видит совокупную стоимость — именно это часто помогает ему расставить приоритеты.
Изменения, которые клиенту стоит оспаривать
Не каждый запрос на изменение исходит от клиента. Если разработчик предлагает изменение, потому что что-то из согласованной спецификации оказалось сложнее, чем ожидалось, это обычно не изменение, а ошибка оценки, и риск, связанный с оценкой, как правило, несёт тот, кто подготовил эту оценку.
Исключение — случай, когда спецификация действительно была неоднозначной, а трактовка клиента требует больших затрат. Это настоящее изменение, и именно поэтому усилия, вложенные в подготовку спецификации в начале проекта, окупаются.
Ведение учёта
Один список, доступный обеим сторонам, в котором указано каждое изменение, его статус, стоимость и влияние на сроки. В конце проекта этот список точно объясняет, почему итоговый счёт отличается от первоначальной сметы, а проект, способный объяснить эту разницу, редко заканчивается спором.
Услуги Manboo по теме
- Разработка приложений на Flutter для MVP под iOS и Android.
- Разработка бизнес-программного обеспечения для CRM, систем бронирования, управления запасами и рабочих процессов.
- Разработка административных панелей для операционных дашбордов и управления серверной частью.
- Интеграция AI API, когда ваш продукт готов к интеллектуальному поиску, чату или автоматизации.
- Запросить проверку объёма работ и оценку проекта, когда вы готовы спланировать первую версию.