В заключительной части этой серии мы обсудим гибкое ценообразование — относительно новый механизм начисления платы, который помогает предотвратить проблемы с фиксированной ценой и оплатой за час, такие как:
- изменения требований
- дорогостоящие задержки
- незавершенные или неоплаченные проекты.
Клиенты хотят получить окончательную стоимость, но не могут знать или ценить каждое требование. Даже с четкой спецификацией разработчикам сложно оценить графики больших проектов. Точность бесполезна, если учесть, что требования клиента неизбежно будут развиваться.
Гибкая зарядка основана на методах гибкой разработки, но не так технически, как кажется. Биллинг основан на «спринтах» ; фиксированный блок времени, когда реализован ряд функций.
Платежные циклы
Как правило, платежный цикл представляет собой двухнедельный период с определенной датой начала и окончания. Во время каждого цикла вы стремитесь:
- реализовать ряд выявленных функций, и
- быть доступным в определенное время, например, с понедельника по пятницу, с 9:00 до 13:00. Старайтесь не предлагать полную 40-часовую неделю — вам понадобится время для дополнительных задач, таких как администрирование, запросы и другие клиентские проекты.
В каждом цикле вы можете достичь лишь очень многого, поэтому погрешность оценки развития уменьшается. Другие функции обычно не рассматриваются во время цикла, поэтому прерывания работы клиента сводятся к минимуму.
Если предполагается, что одна функция займет больше одного цикла, проблема должна быть разбита дальше. Это будет особенно очевидно в начале проекта, но не забудьте указать время для планирования текущего и следующего цикла. Первыми циклами могут быть только сбор требований, анализ и планирование.
В идеале вы должны предоставить рабочий продукт в конце каждого цикла. Оно не должно быть полнофункциональным, но оно должно быть пригодным для использования, чтобы клиент мог учитывать свои приоритеты и предоставлять обратную связь. Стремитесь завершить минимально жизнеспособный продукт в кратчайшие практические сроки.
Условия оплаты
Если вам когда-либо приходилось бороться с денежным потоком, вам понравится эта часть: клиент полностью оплачивает ваше время в начале каждого цикла. Если они не платят, вы не предоставляете никакой работы, и они должны подождать до следующего доступного платежного цикла. Плата не подлежит возврату, хотя следует учитывать некоторый элемент гибкости .
Понятно, что клиент все равно захочет узнать, сколько будет стоить весь проект. Можно предоставить приблизительную оценку количества циклов выставления счетов, но клиент должен понимать, что она будет пересмотрена и станет более точной по мере развития проекта.
Есть несколько преимуществ для клиента:
- Там меньше риск. Если им не нравятся ваши результаты, скорость, процессы, отношение и т. Д., Они могут остановиться в любой момент. Им нужно только зафиксировать текущий цикл.
- Клиенты знают, чего ожидать и когда оно будет доставлено небольшими, управляемыми кусками.
- Они могут просматривать и оценивать прогресс в конце каждого цикла, а не только в конце проекта.
- Переплату за работу невозможно. Когда функция считается достаточно хорошей, затраты на разработку и связанные с ней затраты могут быть прекращены.
- При необходимости клиенты могут купить дополнительные функции или улучшения, насколько позволяет их бюджет.
Сколько вы берете за цикл зависит от вас. Вы можете основывать его на своей обычной почасовой ставке, но варьировать ее в зависимости от доступности цикла, т. Е. Чем раньше клиент бронирует вас, тем меньше он платит. Тем не менее, ваш денежный поток должен улучшиться, потому что клиенты не могут удержать платеж, а их задержки стоят им , а не вам. Вы обнаружите, что клиенты имеют срочную необходимость принимать решения.
Гибкие исключения
Клиент может иметь четкую спецификацию, но не знает, когда и как действовать. В этих ситуациях вы могли бы рассмотреть возможность предлагать небольшую сумму на несколько часов в неделю, чтобы помочь с их запросами до начала работы. Это позволяет избежать предоставления бесплатных консультационных услуг и услуг по оценке времени до начала проекта.
Набор доставляемых функций может быть определен в первый день цикла. Помните, что клиенты могут использовать ваши услуги по своему усмотрению в течение всего периода — имейте в виду, что дополнительные запросы на встречи, обсуждения, консультации, новые требования, изменения функций и т. Д. Будут влиять на то, что может быть достигнуто.
Проблемы развития неизбежно возникнут. То, что вы ожидаете занять пару часов, продолжается в несколько дней из-за специфических особенностей браузера или непредвиденных сложностей. О таких ситуациях следует сообщать клиенту, чтобы он мог выдать временный приказ о прекращении работы, чтобы оценить функцию и пересмотреть приоритеты. Они должны длиться не более одного-двух дней, которые могут быть добавлены в конец проекта без дополнительных затрат для клиента.
Вы можете считать, что платежные платежные циклы не подлежат возврату в случае отмены или задержки работы клиентом. Однако будьте прагматичны. Клиент, отменяющий цикл за один месяц — который никогда не делал этого раньше, — может получить полный возврат средств. Тот, кто постоянно задерживает прогресс в последнюю минуту, может ничего не получить.
Недостатки
Гибкий биллинг идеально подходит для крупных проектов со многими требованиями. Это не обязательно практично для небольших проектов, особенно тех, которые могут быть выполнены менее чем за один цикл. Эти клиенты предпочтут фиксированную цену.
Точно так же могут быть ситуации, когда клиент хочет небольшое количество обновлений существующего проекта, которые лучше всего оцениваются с почасовой оплатой.
Хотя некоторые из вашей рабочей недели могут быть использованы для таких задач, вам может потребоваться рассмотреть возможность резервирования одного цикла каждые несколько месяцев для специальных проектов и обновлений. Только будьте осторожны, чтобы не вернуться к почасовой / фиксированной цене.
Наконец, у нас остается одно серьезное препятствие: немногие клиенты поймут модель гибкой оплаты. Большинство из них ожидают увидеть идеальное полностью законченное решение и не оценят преимущества дополнительной доставки. Возвращаясь к метафоре автомобиля, это похоже на регулярную доставку кузова, колес, двигателя и комплектации. Тем не менее, автомобиль будет управляемым до того, как будут установлены сиденья, стереосистема, отопление и окна — они могут использовать его раньше и вносить коррективы по мере необходимости.
Убедитесь, что ваш контракт объясняет модель в ясной, краткой, без жаргона, на английском языке. Это будет непросто, но нет необходимости включать жесткие концепции с фиксированной ценой / почасовой оплатой, такие как масштабирование, необоснованные требования, просроченные платежи и т. Д.
Гибкий биллинг не может решить все проблемы биллинга или быть применимым к каждому проекту, но он напрямую затрагивает сложности разработки программного обеспечения. Мое предложение: попробуйте это для нескольких новых клиентов и изучите опыт, прежде чем переходить на Agile для всех.
Вы пробовали проворный биллинг? Работало ли это на вашу компанию?