x
 
↑
Июнь
2 •
11 •
10 •
4 •

•
↓
Иван
17 июня 2011

Здравствуйте!

Как рассчитывается бюджет проекта? Берётся общий объём работ и соотносится с нормо-часом каждого специалиста? Как в таком случае рассчитывается нормо-час технолога, верстальщика и дизайнера? Если техническую работу не так сложно оценить, то как вы оцениваете, например, стоимость создания общей концепции и проектирования?

Спасибо!

В бюро оценивают фиксированные итерации по принципу fix time and budget, flex scope.

Мы предлагаем клиентам понедельный план работы с контрольными точками в начале каждой недели.

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

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

При таком подходе любой проект оценивается как произведение еженедельной ставки на количество недель в итерации. Это повременная оплата, лишённая своего главного недостатка — плавающих бюджетов и сроков.

Все проекты бюро — командная работа, поэтому деление по часам отдельных специалистов для нас лишено смысла, непрактично и противоречит жизненным принципам.
P. S.
Это был пятничный совет по взаимоотношениям с клиентом. Хотите получить совет по самой эффективной системе переговоров без оружия? Присылайте вопросы.
P. P. S.
Совет помог? Напишите в комментариях.

Поделиться
Отправить

Комментарии
Александр Дейков
17 июня 2011

Интересно послушать мнение Коли, после десяти месяцев в Бюро. Каково это, скажем, после «Научных приборов»?
Алексей Блинов
17 июня 2011

Артём, а что если клиент настаивает на преодолении всех принятых ограничений, но ни за что не хочет платить больше? То есть у вас на руках оказывается ещё неделя или две доработки, за которые клиент не хочет платить. Такая ситуация тоже заранее в договоре оговаривается?

17 июня 2011

Алексей, конечно.

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

С нашей точки зрения нужно фиксировать срок и качество. Функциональность наверстается в будущих версиях, а время и репутацию уже не наверстать.
Игорь Калашников
17 июня 2011

Артём, а реально ли посмотреть на пример договора, который вы подписываете с клиентом? Очень интересно узнать, какие пункты и уточнения у вас там прописаны.

18 июня 2011

Александр, я как раз удачно попал на время, когда бюро переходило от одного подхода к другому и могу сравнивать.

Когда я только пришел, бюро работало по принципу «100% функциональности со 100%-м качеством в 100%-й срок». На практике же очень часто варьировался срок.

Кроме того, надо учитывать, что в бюро очень высокие, я бы даже сказал охренительные, внутренние требования к качеству. По моим наблюдениям, если время не сильно поджимает, любая вещь проходит сорок (40) итераций, прежде чем арт-директор говорит: «ну ладно». Причём количество итераций не зависит от самой вещи, одна кнопочка, форма, целый макет — всё равно сорок итераций, хоть убей.

А так как сроки не могут ползти бесконечно, в какой-то момент возникал жёсткий дедлайн, к которому надо было доделать всё-всё-всё по текущему этапу. В результате, в первом проекте, где я ощутимо участвовал, чуть ли не каждую неделю случался день, когда я садился за компьютер в 10:00, а вставал в 16:00 следующего дня (тридцатичасовой рабочий день получается). При этом в таком же режиме со мной сидело ещё два человека.

И самое обидное, что клиент всё равно был огорчён срывом сроков и качеством.

Зато такой режим работы отсеивает нормальных людей и оставляет маньяков или тех, кто хочет ими быть :-)

Сейчас я работаю над проектом в режиме fix time and budget, flex scope. Работать гораздо приятнее.

Главное — авралов не стало по определению, потому что если я и сижу ночью, то это только моё решение. Я всегда знаю, что если не буду успевать что-то, то всегда смогу сам принять решение: или я буду сидеть ночью или сообщу клиенту, что я это не успеваю и вместе с ним буду придумывать, что можно выкинуть.

Клиенты тоже, на мой взгляд, довольны, потому что, по сути, сами принимают решения о ходе проекта.
Юрий Балака
13 июля 2011

Я так понимаю, что если вы не успеваете что-то сделать, то просто выкидываете это из проекта или переносите на следующую неделю/следующую итерацию.

А как тогда происходит планирование?

15 июля 2011

Юрий, любое планирование должно опираться на факты.

Глупо придерживаться плана, который не может быть соблюдён по объективным причинам.

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

Кстати, это кардинально отличается от традиционной западной повременной оплаты. Консультанты обычно говорят: дайте нам ещё денег, чтобы закончить проект. Мы говорим: проект запущен, что дальше?
Алевтина Голикова
27 марта 2013

Подскажите, как быть, в ситуации, когда команда оговорила объём работ за одну итерацию, но выполнить всё в срок не успевает? Ведь клиент уже оплатил эти работы. Как решить подобную ситуацию? Или тут один вариант: 30-тичасовой рабочий день команды?
Илья Рабченок
12 июня 2013

Поясните про fix time and budget, flex scope и понедельный план работы — что делать, если за неделю план не выполнен? А не выгоднее ли тянуть время дизайнерам — ЗП-то идёт?
Сергей Прокофьев
11 августа 2014

Вопрос по ФФФ.

Я использую принцип «37 сигналов» для своего продукта. У нас есть роадмап и мы по нему идём.

Как работает в заказной разработке тоже понятно, кроме одного вопроса (сейчас я распишу, как вижу весь процесс в заказной разработке):

1. Определили цели, задачи проекта
2. Выкатили решение
3. Разбили решение на недельные шаги, указали время на согласование и стабилизацию
4. Определили дату релиза
5. Определили бюджет
5.1. Бюджет приняли — работаем
5.2. Бюджет не приняли — меняем решение, снова доходим до бюджета.
6. Клиент видит: ага, трачу 500К, релиз через 3 месяца 21 ноября, делаем загрузку ленты, постинг фото и геолокацию.

Вопросы: как вы ему говорите, что выкатим только загрузку и фото без геолокации? Пускаете в следующий релиз — кто за него платит? Почему клиент готов платить за невыполненный объём работ (в мире клиента так и выглядит)? У себя в продукте я называю это «резать пирог вертикально, а не по слоям».

Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

Решение о публикации принимается один раз; мы не имеем возможности комментировать или пересматривать свое решение, хотя оно может быть ошибочно. Уже опубликованные комментарии могут быть удалены через некоторое время, если без них обсуждение не становится менее ценным или интересным.

Вот такой веб 2.0.
Согласование замечаний Можно ли в договоре добавить пункт, что срок увеличивается пропорционально времени на согласование дизайна? 5 • Как вы в договоре описываете понятие ФФФ? 6 • Несмотря на то, что между нами была договорённость о работе по ФФФ, клиент был в бешенстве 4 •




Недавно всплыло

Отслеживаете ли вы производительность программистов? 1 • Принцип «в письме всё есть» 1 • Что вы думаете о способе указывать цвету прозрачность в шестнадцатеричном виде вместо более традиционного RGBA? 2 • 4 •