Как снизить риски?

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

Затягивание проекта со стороны заказчика.

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

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

«Заказчик обязуется предоставлять все данные, необходимые для реализации этапов, указанных в приложении В, не позднее 5 (пяти) рабочих дней после даты окончания работ, указанных в приложении В, предшествующих этапу передачи данных.
При условии невыполнения Заказчиком условий пункта a. настоящего Договора, даты начала выполнения последующих этапов работ могут быть перенесены Исполнителем, но не более чем на 20 рабочих дней после предоставления необходимых материалов».

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

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

Предоставление постоянных услуг.

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

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

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

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

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

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

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

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

Размещение сайта в Сети обычно происходит только после полной оплаты проекта и подписания актов. Но проект может быть размещен в Сети и до полной оплаты и подписания актов. Парадоксально, но это может быть выгодно, если заказчик не хочет принимать проект. Несмотря на то, что формально он не сдан и не принят, он уже в Сети и представители заказчика начинают работу с ним. На каком-то этапе, когда разработчик уже не видит причин, по которым проект отказываются принимать и оплачивать, он предлагает заказчику «вынуть» проект из Сети, потому что он не принят. И разработчик абсолютно прав - если акты не подписаны и работы в полной мере не оплачены, значит, продукта нет. Чаще всего при таком развитии событий заказчик или окончательно согласовывает адекватные доработки, после которых проект будет сдан, или принимает его «как есть» (в случае, если не может четко сформулировать претензии).

Как повысить рентабельность?

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

В результате чего имеем:

- уже на следующий день после получения заказа можно показать первый прототип;
-
готовый сайт-шаблон может сократить себестоимость создания сайта минимум на 50%;
- разработка сайтов становится на поток - увеличение объемов производства и оборота при сохранении расходной части (ускоряет процесс производства за счет его упрощения и стандартизации). Следствие - рост рентабельности.

Данная практика будет актуальной при низких и средних бюджетах. Очевидно, что при работе с крупными заказами и значительными бюджетами над индивидуальным интернет-проектом она не применима.

Использование систем для коллективной работы над проектом (Task-, Project-Collaboration-management). Для клиента заводится отдельный счет в системе Task-To-Do (собственная разработка интернет-агентства для нужд управления проектами), для того чтобы он мог следить за ходом проекта «изнутри». В этом случае, правда, необходимо регламентировать для сотрудников компании характер использования системы, чтобы в ней не появлялись комментарии, не предназначенные по форме или содержанию для заказчика.

Основная задача разработчика - удержать заказчика и после сдачи проекта, предоставляя различные услуги по его дальнейшего сопровождения (реклама, SEO, техподдержка, копирайтинг, юзабилити-аудит и т.п.). Для этого можно использовать традиционные для других видов бизнеса дисконтные системы. Например, если сайт разрабатывался в нашей компании, в дальнейшем можно предоставлять скидку на рекламу, и наоборот, для рекламодателей предоставлять скидку на разработку сайта. Для заказчиков, которые воспользовались несколькими услугами можно предоставить «оптовую» скидку.


Как поступать с интеллектуальной собственностью от неудавшихся проектов?

Опыт показал, что нередки случаи, когда проект не доходит до своего логического завершения, однако он содержит в себе интеллектуальную собственность (ИC), которая может быть полезной в будущем. Такая ИС могла бы помочь при работе с другими проектами, чтобы избежать траты времени на поиск креативных путей решения проблем. Заказчик и исполнитель могли бы заранее договориться, добавив к договору дополнительное соглашение, о том, что ИС, создаваемая в процессе разработки, будет проанализирована и оценена. При отказе работать дальше, заказчик должен компенсировать затраты, которые были понесены на реализацию проекта. В противном случае, студия могла бы использовать свои наработки для других целей.