Разработка сайта — риски сторон

Все бывает при разработке сайтов, особенно прекрасно при разработке срабатывают Законы Мёрфи. Случаи бывают разные, некоторые и законам Мёрфи не подаются, но еще есть и обычные рабочие моменты, которыми можно управлять и предусмотреть заранее, соответственно снизить риски...

"Даже если вы очень талантливы и прилагаете большие усилия, для некоторых результатов просто требуется время. Вы не получите ребенка через месяц, даже если заставите забеременеть девять женщин." - Уоррен Баффет

Риски заказчика:

1 Дополнительные расходы - как правило, вопрос о том, сколько стоит разработка, задается еще до того как заказчик рассказывает о том какой будет сайт. Тут стоит отметить, что начинается самый интересный нюанс, поскольку у веб-студий не только широкий диапазон цен на разработку сайтов, но и разные подходы к сбору требований. Кто-то может прислать бриф на десяток вопросов, кто-то может указать точную стоимость проекта еще и предсказать сколько часов/минут будет затрачено на разработку, кто-то ответить резко "какой сайт вам нужен", кто-то спросит напрямую какой есть бюджет и т.д.

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

По данным исследования проведенным российским проектом ratingruneta.ru - "42,8% заказчиков тратят на веб-разработку больше, чем собирались", причем совпал бюджет в 44,1% проектов, а был ниже планируемого у 13,1%.

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

Другой пример. "Этот неловкий момент" возникает, когда сайт начинают наполнять контентом, теряется вид дизайна иногда и структуры... Внешний вид сайта портится с каждой новой добавленной страницей. При продумывании дизайна не было оговорено какой должен быть контент на странице и/или не был предоставлен контент (что впрочем не так часто встречается, но очень желательно). Шаблоны дизайна на все случаи жизни и варианты вывода контента предусмотреть не реально, поэтому необходимо все же готовиться в этом плане к проекту и если не представляется возможным предоставить заранее контент, то что должно быть на страницах вашего сайта нужно продумать до дизайна шаблонов внутренних страниц.

3 Сроки. Срыв сроков это большая проблема для заказчика, если сайт был привязан к каким-либо датам - началу рекламной кампании, к началу выставки и т.д. Да и в принципе это нехорошо. Чаще всего срыв сроков происходит у небольших или начинающих студий, так как чем больше опыта у разработчика, тем вероятней всего выше сроки на работу, во-первых хороший сайт действительно долго делается, во-вторых оценка сроков исходит уже из предыдущего опыта. Но все случается, ведь разработка это человеческие ресурсы. В любом случае, необходимо обеспечить запас времени кроме, того срока, в который студия сделает проект. Поверьте, чаще всего этот запас пригодиться, для того, чтобы добавить дополнительный важный контент на сайт, сделать перевод текстов, или появятся какие-то изменения в тексте, возможно будут вынесены какие-то дополнительные работы за рамки сайта, которые вы захотите сделать уже к запуску сайта, а они потребуют определенных временных затрат.

4 Масштабирование. После разработки сайта возможно потребуется расширение его функциональности, вариантов очень много :), поэтому без примеров. Но! Здесь могут начать проблемы у владельца сайта, причем необязательно проблемы с качеством сайта, с ним предположим все нормально. Разработчик может в этот момент быть очень загружен работой и совсем не сможет взяться за "доделки по сайту RE:179" или уже просто не захочет работать с вами или вы с ним. Вот тут начинаются проблемы, потеря времени на ожидание или на поиски другой компании. Но не все так просто, если говорить о нашем рынке, то разные компании работают на разных платформах. Кто-то делает сайты на самописных системах управления, кто-то на бесплатных Drupal, WordPress, Joomla и т.д., меньше компаний на "Битрикс", и других платных системах управления сайтом. Есть разработчики специализирующиеся на разработке проектов на фрэймворках и т.д. Проблема в том, что "средних по больнице" и топовых cms нет, все работают на чем удобней и не факт, что компания которая вам понравится в качестве подрядчика, не предложит переделать и вовсе сайт "с нуля" или назовет сроки выше реальных, ведь им необходимо будет разобраться в том, что сделали до них.

Решение:

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

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

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

Риски исполнителя:

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

2 Висяк - у любой веб-студии есть такие проекты где заказчик поставил следующую формулировку - уехал директор/ответственное лицо или у нас происходят изменения в компании (ребрендинг, изменения в отделе маркетинга), финансовые проблемы, выставка, уволился сотрудник, нет информации (а без нее не можем принять сайт, надо же все наглядно увидеть) и т.д. Студия получает висяк, такой проект может висеть от нескольких дней в лучшем случае до нескольких месяцев, а в некоторых особо "интересных положениях" и годами, когда интерес к проекту у заказчика потерялся.

3 Сроки - Срыв сроков по вине заказчика, чаще всего происходит из-за непредставления материалов - контента, пояснений к работе и т.д. Причины могут быть разные, но ни в них дело, а в том, что фраза "клиент всегда прав", в этом случае понимается буквально и с точки зрения заказчика, здесь ничего такого нет, если вы немного подождете, но если студия нарушит сроки... :)

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

4 Заказчик поглотитель времени - с одной стороны этот риск перекликается с другими, но не все так просто. Если "работа мимо портфолио" может немного превышать выделенное время на разработку, а "висяк" влияет на оборотные средства и на дату закрытия проекта, то "заказчик поглотитель времени", это другая проблема. Небольшие, но частые дополнения в проект, влияют на увеличение трудозатрат студии, в отдельных случаях может произойти не только уменьшение прибыли, а оказаться, что проект и вовсе убыточный. Все начинается с небольших, маленьких просьб и разработчик идет на встречу, дальше это может привести к ежедневным небольшим поправкам. Такие дополнения чаще всего возникают на самом завершающем этапе проекта, перед сдачей и оплатой работы. Но поглощение времени может быть и в процессе работы, например обсуждение дизайна не по электронной почте, как было предусмотрено техническим заданием, что заказчик присылает исчерпывающие и объективные комментарии по дизайн-макету, а с личным присутствием разработчика, менеджера по проекту, заказчика, когда 2 специалиста выезжают на встречу обсуждать проект по несколько раз в неделю. Это могут быть внесение различных "небольших" деталей по ходу проекта. Конечно, разработчик в этом случае должен выставить дополнительный счет на дополнительные работы, действовать согласно и в рамках технического задания, но в той или иной степени практически все компании-разработчики проходили через это.

Решение:

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

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

 

Завершу пост релевантными данной статье ссылками на другие материалы на моем блоге :) Никаких плагинов, все полезное для читателей, только ручками )))

Сокращение затрат на разработку сайта

Ценовые диапазоны на разработку сайтов в Молдове

Структура рынка создания сайтов в Молдове

  • http://www.facebook.com/mihailoff George G Mihailov

    А как же использование agile методологий типа SCRUM!? Сколько требования в ТЗ не уточняй они не будут достаточны в любой момент времени. Также следует иметь ввиду что заказчик часто сам не знает что хочет, пока не начнёт трогать продукт.

  • http://twitter.com/VladimirVieru Vladimir Vieru

    В большей степени опыт в материале по работе с клиентами из Молдовы. Методология SCRUM на развивающимся рынке при недостатке информированности и уровня подготовленности у заказчиков весьма рискованное занятие. И очень немногие готовы оплачивать у нас работу по факту, а не по фиксированной цене проекта