Заключить сделку по мобильной разработке — сложная задача и полезное достижение. Но, как известно любому, кто создал приложение, заключение сделки — это только начало. Когда начинается производственный процесс, проектировщики и разработчики должны осознавать очень сложную проблему, называемую ползучестью области действия .
Иногда клиенты чувствуют, что, поскольку они заключили с вами сделку и деньги были обменены, они имеют право запрашивать функции и изменения, выходящие за рамки первоначальной сферы проекта. Это редко делается из-за наших злых умыслов или злых намерений, но все же ставит дизайнеров и разработчиков в трудное положение, так как мы должны придумать, как сказать «нет», не ставя под угрозу отношения.
Итак, как мы можем избежать ползучести области? Вот четыре совета, которые сработали для нас.
Определите область
Этот совет может показаться очевидным, но определить сферу в ясных и точных письменных терминах на удивление сложно. Когда мы начинаем чувствовать, что клиент склоняется к подписанию сделки, мы часто чувствуем необходимость поспешить, пропустить важные детали и завершить соглашение как можно скорее. Проблема с поспешностью заключается в том, что область действия не будет настолько ясной и всеобъемлющей, как это необходимо, что, в свою очередь, может привести к ползучести области. Любые области работы, которые не были явно определены, будут интерпретироваться клиентом и разработчиком двумя различными способами, соответственно. Клиент увидит расплывчатые, неопределенные области работы в виде широко открытого холста с множеством возможностей. Разработчик, однако, вероятно, будет рассматривать те же области работы как не упомянутые, не уточненные и, следовательно, не являющиеся частью соглашения.
Из-за этого слишком общего различия в восприятии важно определить все движущиеся части проекта с кропотливой ясностью. Возможно, вы даже захотите четко указать, что работа не является частью проекта; это поможет очень четко определить границы, что, в свою очередь, позволит свести область видимости к минимуму.
Установите высокий показатель для работы вне области видимости
Добавьте в контракт простую (но важную) строку, в которой говорится, что за все внеплановые работы (изменения, дополнения и т. Д.) Будет взиматься почасовая ставка «Х», и это продлит сроки реализации проекта. Если дополнительные запросы вашего клиента являются обоснованными, укажите эту ставку и спросите их, хотят ли они получить счет. Такой подход дает вашему клиенту хорошие варианты выбора и контроль принятия решений, не повреждая отношения и не заставляя вас взяться за неожиданную, неоплачиваемую работу. В случае принятия клиентом, рассматривает возможность внесения изменений в первоначальный договор, чтобы расширить сферу применения до вновь согласованного стандарта и ставки.
Будьте мужественными и скажите «Нет». Используйте технику сэндвича
Вы знакомы с техникой сэндвичей? Если нет, это работает следующим образом:
- Начните с позитивного заявления. Это может быть благодарность за заботу клиента о проекте или ценность (незапланированной) идеи / функции, которую они хотят добавить в проект.
- Укажите негативы в середине. Будь честным, прямым и объективным. Поговорите о том, что добавление другой функции не очень хорошая идея, и как они будут стоить больше денег, занять больше времени, или они могут даже не быть возможными.
-
Затем закройте бутерброд еще одним слоем позитива. Это может быть утверждение типа «проект идет хорошо», «мы очень рады за проект», «спасибо, что донесли эту идею до нас», или «это звучит как отличная идея для следующей версии этого проекта». «.
Превратите Scope Creep в набор функций для следующей версии приложения
Большинство проблем в области охвата включают в себя настройки, изменения и дополнения, которые могут улучшить проект и поэтому легко оправдываются клиентом. Важные вопросы, которые следует задать, — это не должен ли проект включать эти дополнения, а какая версия должна включать эти новые дополнения. Поговорите со своим клиентом о минимальном наборе функций для версии 1 и составьте список дополнений для следующих версий. Чтобы помочь клиентам понять, мы объяснили управление версиями следующим образом: «У всех нас есть идеи, которые могут сделать приложение лучше, но на данный момент они образованные догадки, давайте подождем, пока мы запустим приложение, и пользователи попросят эти изменения / функции. Таким образом, это уже не предположение, а определенная потребность ».
Надеемся, что эти советы помогут вам защитить целостность проекта, ваше время и прибыль. Если вы честны со своим клиентом и постоянно обсуждаете вопросы, вы можете превратить проблему ползучести области в возможность создать лучшее приложение.
Были ли у вас проблемы с ползучестью прицела? Как вы обрабатывали неожиданные дополнения к своим мобильным проектам?