Этап подготовки к разработке сайта. Когда оценивать бюджет и заключать договор?

Question

[Валерий Алексеев]

Доброго времени суток, коллеги.

Занимаюсь сайтами уже долгое время. Сейчас пришёл к тому, что захотелось систематизировать и структурировать процесс разработки сайта в плане этапов и составить некий скрипт-инструкцию для проджект-менеджера. И всё бы ничего, если бы не один вопрос, ответ на который я так и не нашёл. Поделитесь опытом, кто как решает проблему?

Дизайн, вёрстка, разработка, тестирование — это всё отлажено, вопросов нет. Вопрос про этап согласования. Как правило, всегда работали по схеме — первичное обсуждение и брифование, исследование, ТЗ, прототипы — после этого предоплата и уже в работу. Вот основные проблемы, которые вижу:

1. Довольно трудно составить ТЗ без прототипов, так как мы составляем подробные ТЗ с описанием блоков и функционала. Фактически, прототип у нас является частью ТЗ и прилагается к нему.
   
2. Также трудно создать прототип сайта без предварительного исследования, во время которого мы изучаем конкурентов, подбираем референсы, выделяем полезные функции и блоки.
   
3. Брать предоплату до исследования — возможно, но сильно сказывается на вероятности успешной продажи. Презентация результатов анализа ниши и готовые ТЗ и прототипы у нас — залог успешной продажи.
   
4. И наконец, брать предоплату в самом начале — не вариант, так как стоимость проекта может измениться на этапе согласования.
   

Что думаете по этому поводу? Как решаете вопрос, если не секрет?

Answer 1

[xmoonlight]

1. Всегда предоставляйте потенциальному заказчику план ваших действий - это может быть иерархический список работ с различной зависимостью между собой в формате таблицы Excel с формулами и условиями (для смены отображения: фон, цвет и т.д) в ячейках.
2. Там, где цена за данный вид работ неизвестна (будет известна после выполнения предшествующих пунктов работ) - ставим нолики в трудозатратах.
3. Обязательно пишем сноску под таблицей: "ВНИМАНИЕ: работы с нулевой стоимостью выполняться не будут."
4. После этого можно подготовить проект в GanttProject не добавляя туда работы с нулевыми трудозатратами и экспортировать в PDF.
5. Два документа: xls+pdf - отсылаем как ТКП на согласование клиенту и прикрепляем к договору.
6. При необходимости, модифицируем договор с помощью доп. соглашений для выполнения тех этапов, стоимость которых стала известна и которые необходимы клиенту.

По этапам разработки веб-сайта: здесь.

Во всех других случаях - нет смысла работать с теми, кто не хочет работать.

Comments

[dmitriy]

Как быть если вместо ноликов нарисуется сумма на которую клиент не рассчитывал?

[xmoonlight]

diamond, интересная логика: если эту сумму не знает сам разработчик до определённого момента (этапа работ), то откуда это может знать клиент?
Просто нужно работать так, чтобы качество работы было выше, чем суммы вместо ноликов. А с теми, кто этого не понимает - нужно сразу расставаться (закрывать договор) между этапами работ.

[dmitriy]

Так обычная практика, прошли вы определенные этапы и говорите что разработка 100тыщ у клиента глаза на лоб, как так я рассчитывал на 50? Мне кажется грубая на любом этапе нужна

[xmoonlight]

diamond, ок. Тестируем (я - заказчик, типа):
Задача: создать веб-сервис для хранения речевых аудио-записей, поиска схожих среди них и по предложенному экземпляру. Уметь отделять файлы с чистой речью от остальных. Частота дискретизации и разрядность потока - может быть любыми.
Хочу прям сейчас знать: на какую сумму за весь проект мне рассчитывать (при грубой оценке).

[dmitriy]

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

[xmoonlight]

diamond, это только по вашей логике... изначально не только ТЗ но и часть работ, которую возможно оценить сразу.
Однако, от оценки тест-задачи Вы внезапно тихо ушли: сами же говорите одно, а делаете другое...
Оценка-то будет или чья там логика сработает дальше?

[dmitriy]

Ну ок, от 50тр-200тр
Минимальная планка сразу отфильтрует тех кто не готов платить, корректировка цены возможна в большую примерно 30-40%

[xmoonlight]

diamond, А сузить интервал реально?
Мне нужно точно знать и понимать: на что рассчитывать...
Хотя бы, в пределах 10-15тр.

[dmitriy]

Так сужение и будет происходить по мере составления ТЗ

[xmoonlight]

diamond,

корректировка цены возможна в большую примерно 30-40%

Так сужение и будет происходить по мере составления ТЗ

Теперь я вообще не понимаю: на что ориентироваться мне )

Answer 2

[jumale]

Когда-то давно тоже был опыт создания сайтов по ТЗ и это была боль - приходилось делать долгосрочные эстимейты (которые никто никогда не угадывал), тратить кучу времени на ТЗ, чтобы не пропустить ни одной детали, затыкать заказчику рот этим ТЗ когда он через месяц менял свое мнение.... ну и т.д.
С тех пор только спринты - в начале приблизительно оцениваем сложность проекта чтобы определиться с инструментами разработки и обязуемся через N недель выдать MVP. А дальше "любой каприз за Ваши деньги" - новые фичи == новые спринты == платите. Клиенту останавливаться после первого же спринта смысла нет - он заинтересован в готовом продукте, а смена исполнителя это доп. траты. В то же время и у клиента и у исполнителя есть шанс не продолжать сотрудничество после определенного спринта если вдруг испортятся отношения. Клиент сам рассчитывает за что он платит и когда остановиться.
Я правда уточню, что в последнее время я работаю в большой компании и в моем случае "клиенты" - это стейкхолдеры, которые работают в этой же компании. Но в данном случае они мало отличаются от "аутсорсного" клиента, потому что они являются заказчиками проекта, у них есть определенный бюджет и наше сотрудничество выглядит именно так как я описал выше.

Comments

[Валерий Алексеев]

Спасибо за ответ!

Agile действительно полезная штука, но, к сожалению, не когда речь идёт о промо-сайтах или даже интернет-магазинах. В большинстве случаев типичный заказчик (не связанный с миром digital), услышав «мы работаем две недели, выдаём начальный результат, а потом решаем что дальше» пошлёт исполнителя и уйдёт к другой студии

Зато вот с США, где почасовая ставка норма, такая история работает. С ними в этом плане приятнее иметь дело)

Answer 3

[Anton Filippov]

исходя из опыта прикидывать примерное количество часов на разработку - умножать на свою почасовую ставку - корректировать по формуле Бобука и давать такой эстимейт.
Либо давать точные эстимейты на типовые проекты, основываясь на предыдущих работах, и предупреждать клиентов, что правки НЕ багов, а вкусовщины оплачиваются.

Comments

[Валерий Алексеев]

Проблем с оценкой предварительной стоимости нет — называем вилку от и до на основе ставок.

Вопрос скорее в том, что приходится довольно большой этап в виде аналитики, подготовки ТЗ и прототипов делать фактически бесплатно. По сути, процесс подготовки последовательно выглядит так:

— Брифование
— Анализ и подготовка презентации исследования
— Проведение презентации исследования (заказчик должен подтвердить, что мы правильно поняли аудиторию и проект)
— Создание прототипов на основе исследования и Брифа
— Утверждение прототипов
— Подготовка ТЗ на основе брифа, анализа и прототипов
— Согласование ТЗ

И всё это бесплатно. Это не проблема, просто интересуемся, может кто знает варианты другие.

[Anton Filippov]

Валерий Алексеев, так включайте это в стоимость; сколько там у вас это времени занимает, процентов 20% допустим. Я поэтому и сказал прикидывать число часов, а раз это занимает время и относится к проекту, то очевидно эти часы тоже должны считаться.

Даже если у вас ежедневные утренние митинги проводятся с командой(если командой работаете) - это тоже время, включаемое в "смету"

[Валерий Алексеев]

Спасибо. Так обычно и делаем, просто сама идея включения в смету пунктов, которые уже были выполнены ранее, немного смущает.

[Anton Filippov]

Валерий Алексеев, так не делайте их до оплаты :)
Я так понял у вас репутация/портфолио какие-то наработаны? Этого достаточно для внесения предоплаты клиентом

[sim3x]

flppv,

сколько там у вас это времени занимает, процентов 20% допустим

анализ и проектирование должно занимать от 80 до 95% времени
Кодинг 15-3%

[Валерий Алексеев]

Вот в этом и загвоздка, озвученная мной в начальном сообщении) Не совсем правильно составлять смету без ТЗ и прототипов — потому как одна небольшая функция на странице может понести за собой долгие часы работы. Очевидно, что смета (а значит и предоплата) следуют после составления ТЗ. В этом и парадокс :)

[Валерий Алексеев]

sim3x, а куда же делся дизайн? или вы его в проектирование включили? У нас сейчас примерно так (когда речь не о сложном сервисе, а о корпоративном сайте):

— 30% согласование и проектирование (по большей части, вайрфрейминг)
— 30% отрисовка макетов и стайлгайдов
— 30% вёрстка и интеграция с движком
— 10% тестирование и отладка

[sim3x]

Валерий Алексеев, в проектирование

[Пума Тайланд]

sim3x, ахахаха по моему в источнике 2 процента, но там же написано и про ошибочность

Answer 4

[Сергей]

Берите плату за прототипирование.

Answer 5

[lotse8]

1) Сразу не вникая очень глубоко на основе предыдущего опыта можно назвать заказчику примерные рамки цены от ... и до ... и если заказчика этот диапазон устроит, то можно продолжать разговор. Некоторые на этом этапе отваливаются, это воздухогоны, у которых денег нет, а ходят по базару и просто прицениваются. Или же спрашивать у заказчика бюджет проекта, на какую сумму он рассчитывает, тогда думать только в пределах бюджета.
Т.е. смысл в том, чтобы на самом первом этапе отсеять все пустышки, чтобы не тратить на них свое время.
2) Для тех кто не отказался, нужно делать бриф и список функций или модулей и считать уже более точно ценник. На этом этапе можно договариваться с заказчиком Цена +/- 10% на непредвиденные ситуации. Обычно здравомыслящие заказчики понимают, что проект оценить на старте до копеек невозможно. Уже можно делать договор и просить предоплату.
3) И когда уже все будет до мелочей расписано, тогда уже можно смотреть, и если сильно ошиблись не в свою пользу, то либо разговаривать с заказчиком и менять цену (доп. соглашение к договору), либо отказаться (в договор надо забить пункт для варианта отступления).

Для заказчика все должно быть прозрачно и желательно не просто называть ему цену, а подробно расписывать калькуляцию, что делается и сколько стоит. Так заказчик будет уверен, что его не обманывают, а если жалко денег, то отдельные пункты он может не делать.

Answer 6

[Виктор Янышев]

На все что тратится время должно быть оплачено, если оплата прелюдии создаёт ощущение что на этом заказ заверения, то как уже и говорили включать эти часы стоимость после прелюдии. Для типовых задач это явно не проблема.
Как один из интересных вариантов на моменты выхода на разработку тз, анализа, прототипов и т.д подписывать документы о том что заказчик будет работать с Вами а если вдруг он решил ретироваться, то указать на бумагу. Тем самым можно подкрепить ощущение о том что если будет срыв то не будет больших потерь. Ну а далее когда вышли за рамки оплаченной (вперёд или включенной читать как распределенной, в другую часть работы) прелюдии, на основании бумаги 1 переходит к делам или подписывать вторую бумагу что всё ок и брать оплату.

Comments

[sim3x]

https://ru.wikipedia.org/wiki/Прелюдия

[Виктор Янышев]

sim3x, цитата "Прелюдия-вступление к какому-либо музыкальному сочинению или небольшая самостоятельная пьеса"

[sim3x]

Виктор Янышев,

прилюдии

Прелюдия

[Виктор Янышев]

sim3x, низкий Вам, мой поклон