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

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

1. Поиск клиентов

Опыт регионального партнера, пожелавшего остаться неизвестным:
Free-lance.ru часто воспринимается веб-студиями как конкурент, уводящий заказчиков. В частной беседе я услышала такое практическое опровержение этого мнения.
Компания создала аккаунт на Free-lance.ru, заполнила свое портфолио, попросила заказчиков оставить оценки и отзывы и стала периодически отсматривать публикуемые заказы и отвечать на тендеры.
Результат: +1 млн. руб. к годовому обороту при общих затратах на данную активность 50 тыс. руб. (время на ведение аккаунта и оплата профайла пользователя на сайте).
Сфера применения: эта практика подойдет для тех, кто работает в среднем или ниже среднего ценовом сегменте (30-80 тыс. руб. за разработку сайта). При этом для региональной компании это дает возможность выхода на столичных заказчиков и работы на портфолио.

2. Заключение договора

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

2.1. Сложности согласования

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

Приложение N к договору NN
Список лиц, ответственных за разработку проекта со стороны Заказчика
1. Утверждение дизайнов всех разделов проекта
Фамилия И.О.
контактный телефон: (ХХХ) ХХХ-ХХ-ХХ
контактный e-mail: mail@mail.ru
(подпись)
2. Утверждение Технического Задания
Фамилия И.О.
контактный телефон: (ХХХ) ХХХ-ХХ-ХХ
контактный e-mail: mail@mail.ru
(подпись)
3. Принятие полного объема работ, у Исполнителя
Фамилия И.О.
контактный телефон: (ХХХ) ХХХ-ХХ-ХХ
контактный e-mail: mail@mail.ru
(подпись)


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

2.2. Непредоставление необходимых материалов

Вполне типичная для заказчика ситуация. Она ведет опять же к затягиванию сроков сдачи проекта. Минимизировать издержки при наступлении такой ситуации позволяют следующие пункты договора:

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


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

2.3. Риски долгосрочных договоров

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

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

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

2.4. Подписание актов

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

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

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

Как снизить внутренние риски нерентабельности будущего проекта. Алексей Самойлов, руководитель интернет-агентства «Кинетика»:
«Схема оплаты сотрудников веб-студии, если рассмотреть ее с экономической точки зрения, часто не выгодна владельцу бизнеса. Итак, менеджер по продажам продал сайт. Однако, это нельзя рассматривать как продажу. Акт продажи еще не состоялся, ведь товар не отгружен.

Провожу аналогию: я пришел на базу и в кассу отдал деньги за мешок муки. Продавцы мне его еще не продали — ведь я иду в другой конец базы на склад, и только там кладовщик мне отгружает товар. Если мне она понравилась, я расписываюсь в счете-фактуре, взваливаю мешок на плечи, и иду домой. Вот теперь продажа состоялась. Но если вдруг я уже на складе усомнился в качестве муки, мне нагрубил кладовщик, или я просто по пути понял, что мука мне не нужна (типичная в Вебе ситуация, кстати), то я вполне спокойно могу пойти обратно в кассу и забрать деньги.
Я возвращаюсь в кассу, чтобы забрать деньги, но представим себе, что база очень длинная и я иду по ней очень долго – например, месяц. Наступает 1-е число, и кассир забирает из кассы свой процент, за проданную мне муку. 2-го числа я дохожу до кассы и забираю деньги за товар, который я не стал приобретать. Кассир получил свой бонус, я – обратно свои деньги. Владелец бизнеса остался в минусе.

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

Во второй части я расскажу о рецептах на этапах разработки и утверждения дизайна, внедрения CMS и программирования, а также о сдаче проекта. В общем, продолжение следует :).

Читайте также:

Категории

Теги

партнеры рейтинг мероприятия UMI версии UMICMS продукты UMI MySQL разделение баз данных технологии Кейсы обзоры маркетинг developer программинг менеджмент xslt документация шаблоны Служба Заботы маркетинг веб студии москва UMISummit события umisummit лицензии новинки UMI Edu UMI Cloud модуль business облако тегов кастомы uwdc Челябинск разработчики конференция Конкурс UMIRU exchange 28 Обмен данными 1C Интеграция с 1С хостинг юмихост umihost UMICMS видео flash actionscript каталог анимация техподдержка tpl local scope macro кейсы итоги года SAPE seo мероприятие рынок веб разработки экономика Алексей Самойлов Сергей Котырев KINETICA CMS Сибирская интернетнеделя UMIWorkshop интернетмагазин интернет-магазин интернет магазин интернет-маркетинг Золотой сайт umi_workshop акция партнерская_программа партнерство стратегия highload РуПромо Машков версия 2_7 кэширование скорость стихи день рождения статьи пресс конференция версия 2_5 Edit_in_Place онлайн платежи кризис достижения CeBIT внедрения umi cms блоги верстка релиз EditInPlace изучение Юми создание модуля модули ReMIX UMI_CMS_Net iPhone XML драйвер как убрать лампочку форма обратной связи языковые версии CMS Pistols музыка UMICMS 28 удобство юзабилити usability user experience интерфейсы CMS Eye tracking ай тракинг usability test UXRussia управление сайтом RIW Russian internet week Softool выставки интернет клиенты сайты umisound cms pistols РИФ 2011 Tagline качество 2012 UMISound Полюса Илья Разин Марат Машков

Авторы блога