aval12
@aval12
Креативный директор веб-студии #VA

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

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

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

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

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


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

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

    Во всех других случаях - нет смысла работать с теми, кто не хочет работать.
    Ответ написан
Пригласить эксперта
Ответы на вопрос 5
  • @jumale
    Когда-то давно тоже был опыт создания сайтов по ТЗ и это была боль - приходилось делать долгосрочные эстимейты (которые никто никогда не угадывал), тратить кучу времени на ТЗ, чтобы не пропустить ни одной детали, затыкать заказчику рот этим ТЗ когда он через месяц менял свое мнение.... ну и т.д.
    С тех пор только спринты - в начале приблизительно оцениваем сложность проекта чтобы определиться с инструментами разработки и обязуемся через N недель выдать MVP. А дальше "любой каприз за Ваши деньги" - новые фичи == новые спринты == платите. Клиенту останавливаться после первого же спринта смысла нет - он заинтересован в готовом продукте, а смена исполнителя это доп. траты. В то же время и у клиента и у исполнителя есть шанс не продолжать сотрудничество после определенного спринта если вдруг испортятся отношения. Клиент сам рассчитывает за что он платит и когда остановиться.
    Я правда уточню, что в последнее время я работаю в большой компании и в моем случае "клиенты" - это стейкхолдеры, которые работают в этой же компании. Но в данном случае они мало отличаются от "аутсорсного" клиента, потому что они являются заказчиками проекта, у них есть определенный бюджет и наше сотрудничество выглядит именно так как я описал выше.
    Ответ написан
  • vicodin
    @vicodin
    Фронтендер
    исходя из опыта прикидывать примерное количество часов на разработку - умножать на свою почасовую ставку - корректировать по формуле Бобука и давать такой эстимейт.
    Либо давать точные эстимейты на типовые проекты, основываясь на предыдущих работах, и предупреждать клиентов, что правки НЕ багов, а вкусовщины оплачиваются.
    Ответ написан
  • @lotse8
    1) Сразу не вникая очень глубоко на основе предыдущего опыта можно назвать заказчику примерные рамки цены от ... и до ... и если заказчика этот диапазон устроит, то можно продолжать разговор. Некоторые на этом этапе отваливаются, это воздухогоны, у которых денег нет, а ходят по базару и просто прицениваются. Или же спрашивать у заказчика бюджет проекта, на какую сумму он рассчитывает, тогда думать только в пределах бюджета.
    Т.е. смысл в том, чтобы на самом первом этапе отсеять все пустышки, чтобы не тратить на них свое время.
    2) Для тех кто не отказался, нужно делать бриф и список функций или модулей и считать уже более точно ценник. На этом этапе можно договариваться с заказчиком Цена +/- 10% на непредвиденные ситуации. Обычно здравомыслящие заказчики понимают, что проект оценить на старте до копеек невозможно. Уже можно делать договор и просить предоплату.
    3) И когда уже все будет до мелочей расписано, тогда уже можно смотреть, и если сильно ошиблись не в свою пользу, то либо разговаривать с заказчиком и менять цену (доп. соглашение к договору), либо отказаться (в договор надо забить пункт для варианта отступления).

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

Войдите, чтобы написать ответ

Войти через TM ID
Похожие вопросы