Почему разработка интернет-магазина превращается в муку?

Участники этого двойного интервью никогда не работали вместе, и до подготовки этой публикации вообще не были знакомы. Так что ничего личного, just a business. Executive.ru предложил им обсудить риски и проблемы, с которыми можно столкнуться в электронной торговле на стадии разработки и запуска проектов, и дать рекомендации участникам Сообщества.

Заказчик – Лидия Серегина, генеральный директор портала натуральных продуктов питания seryogina.ru. Путь по редизайну сайта был тернистым, с задержкой почти в год и решением множества разных проблем. На этом проекте Лидия приобрела большой опыт общения с разработчиками, и у нее накопилось к ним немало вопросов.

Разработчик – Константин Попов, директор по маркетингу и продажам digital-агентства «Антигравитация». Запускал и перезапускал более десятка онлайн-проектов. Разные отрасли – одежда и обувь, автозапчасти, кейтеринг, декор и интерьер, автобусные перевозки, мебель. Разные бюджеты, разные запросы, разные цели. Но поведение у всех заказчиков, по мнению Константина, подозрительно похожее, и на оптимальное не похоже. Он хочет понять, почему клиенты делают одинаковые ошибки.

Executive.ru: Лидия, для начала скажите в целом – оно того стоило? Не жалеете, что занялись онлайн-торговлей?

Лидия Серегина: Наш интернет-магазин заработал в 2009 году. В то время массово торговали книгами и электроникой, так что с продуктами питания мы были в первых рядах. Успешно работали и продолжаем. Безусловно, не жалею. Однако, если говорить о разработке и запуске нового сайта, то этот проект оказался убыточным. Сорванные сроки, упущенная прибыль…

Executive.ru: Константин, у вас более 80 постоянных клиентов и гораздо больше разовых проектов. Обо всем получается договариваться, или бывают тупиковые ситуации?

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

Executive.ru: Вы оба говорите об упущенной выгоде. Как ее оценивают в e-commerce заказчики и подрядчики? Это числовой показатель, его можно учесть в договоре, или просто такое выражение, которое «к делу не подошьешь»?

Л.С.: Мы не предполагали, что задержка будет такой огромной. Разработчики в договоре прописали, что не несут ответственности.

К.П.: Для агентства упущенная выгода – это та прибыль, которую мы могли бы получить в рамках подписанного договора, если бы стороны не приняли решение о его досрочном прекращении. Несмотря на наличие зафиксированных обязательств, наше агентство никогда не взыскивало упущенную выгоду с заказчика, и я не слышал, чтобы такая практика кем-либо применялась в e-commerce.

Executive.ru: Какой главный вопрос по работе в e-commerce остался для вас открытым? Задайте его друг другу, пожалуйста! И ответьте тоже, конечно.

Л.С.: Как оценить профессионализм и адекватность IT-разработчика, еще не начав с ним работать?

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

Адекватность – категория сложно формализуемая, поэтому тут лучше доверять своей интуиции. Если в процессе диалога с разработчиком вам комфортно, то наверняка и дальнейшая работа сложится успешно. И наоборот.

Ну, и подстрахуйтесь в договоре – адекватный и уверенный в своем профессионализме разработчик никогда не потребует 100% предоплаты, а согласится разбить сумму так, что помимо авансовых платежей будут и платежи по факту исполнения.

Встречный вопрос: почему часто заказывают решение в сфере e-commerce у программистов? Почему не поручают специалистам в e-commerce – то есть тем, кто помимо опыта программирования и web-разработки имеет также опыт построения и управления коммерческими онлайн-проектами?

Л.С.: «Я Вам не скажу за всю Одессу...». Только за свою компанию. Нам сайт (объединение блога с рецептами и интернет-магазина) делают разработчики, цитирую: «с опытом создания и поддержки интернет-магазинов с 2006 года». В портфолио – успешно работающие интернет-магазины, в том числе в области продуктов питания.

То есть, заявлены компетенции именно в сфере e-commerce, о которых вы говорите. Многолетний опыт. Ниша в точности наша. Проекты «живые», я проверяла. Все выглядит красиво и подходяще. Начинаем работать – проблема за проблемой.

Executive.ru: Лидия, назовите главные проблемы, с которыми вы столкнулись в процессе запуска новой онлайн-площадки, пожалуйста.

Л.С.: После запуска сайта выяснилось, что наш рассказ, на основе которого составлено ТЗ, был неправильно понят менеджером и программистом. Это объяснимо, они не знают специфику нашего бизнеса. Но мы столкнулись с тем, что некоторые детали разработки вообще отсутствуют в ТЗ. Например, разработчик сделал фильтрацию по одному принципу, тогда как мы объясняли прямо противоположное. Логика на нашей стороне: например, аналогично фильтрует Яндекс.Маркет. Однако, поскольку в ТЗ на этот счет ничего прописано не было, разработчик игнорирует наши доводы и отказывается что-либо менять. Как быть?

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

В ходе взаимодействия стало ясно, что работать с разработчиком проблематично: сменили менеджера, затягивают решение проблем, не отвечают. Мы хотим поменять подрядчика. Сайт готов, речь о его поддержке и развитии. Код написан на фреймворке Simphony на базе языка PHP, модули на Python. Очень хочется избежать ситуации «из огня да в полымя». Как нам выбрать подходящего IT-партнера? Как избежать дополнительных проблем, связанных с этой заменой?

Executive.ru: Итак, три вопроса: как решать разногласия по ТЗ, за чей счет выполняются доработки и как должна происходить смена подрядчика? Что об этом думают разработчики?

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

Во-вторых, вопросы, которые потом нельзя изменить и доработать «на лету», по-моему, должны обсуждаться и фиксироваться особенно четко. Мы после беседы с заказчиком всегда готовим протокол и вносим такие вопросы в новую редакцию ТЗ.

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

Отказывать в исправлениях, на мой взгляд, нельзя в любом случае. Речь идет о бизнесе, и заказчик должен получить конечный результат в виде продаж вне зависимости от своих ошибок или ранее согласованного ТЗ. Обе стороны должны проявить гибкость – заказчик должен быть готов компенсировать затраты на неудавшийся дизайн, разработчик – минимизировать свои претензии и не требовать двойной оплаты. Если же разработчик сделал что-то без согласования, то такие моменты должны быть исправлены по требованию заказчика бесплатно.

Executive.ru: Как вы считаете, сколько раз можно что-то менять без увеличения бюджета? Что можно менять, чего нельзя?

Л.С.: В ТЗ это оговаривается: столько-то вариантов дизайна и прочие виды работ. Думаю, что можно менять то, что не повлечет за собой увеличение рабочих часов разработчика. Все в рамках разумного. И мы готовы доплатить, если объем возрастает.

Особенность крупного проекта в том, что он начинает устаревать с момента подписания ТЗ. У нас был случай, когда спустя полтора месяца после подписания ТЗ, на этапе согласования дизайна, я предложила одну инновационную и удобную для клиентов функцию. Нам ответили: «в подписанном ТЗ этого нет». То, что ее не добавили в ТЗ, мы поняли после запуска сайта. Вопрос условий реализации не поднимался. Например, мы столкнулись с тем, что при установке скидки на товар не предусмотрен срок ее действия. Вообще нет такого поля. Это мелочь? Да. Но обязательная. В итоге получилось как в анекдоте про чугунные игрушки: игрушки-то есть, но играть с ними нельзя.

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

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

Еще раз обращаю внимание на то, что пожелания заказчика (при всем уважении) лучше ограничивать постановкой бизнес-задач. То есть там, где он полностью компетентен, владеет ситуацией, видит решения – и мы, как разработчики, доверяем его пониманию рынка и продукта. В надежде и расчете на встречное доверие к нашей компетенции, применительно к e-commerce. Нужно доверять друг другу, и все будет гораздо проще.

Executive.ru: Доверие, конечно, необходимо, но как и за что подрядчик готов отвечать перед заказчиком?

Л.С.: Присоединяюсь к этому вопросу. Какую ответственность разработчик несет за конечный продукт? За задержку сроков, например, за неграмотный интерфейс? И как это прописать в договоре?

К.П.: Ответственность можно прописать в договоре, это нормальная бизнес-практика. Но, конечно, все не пропишешь. Поэтому лучший вариант, когда разработчик отвечает не за «код», «движок» или прочие элементы (помните классику: «К пуговицам претензии есть?»), а сразу за тот самый конечный продукт. То есть за результат в виде заказов, продаж. С такой постановкой задачи заказчик может быть уверен в том, что качество продукта будет наилучшее.

Executive.ru: Насколько глубоко разработчики e-commerce готовы «нырять» в бизнес заказчика, если «пустит»?

К.П.: До самого дна! У нас есть и свои финансисты высокого уровня, которых можно подключить к проекту. Мы можем оценить рентабельность проекта, и в наших проектах продвижения, например, всегда есть бонусная часть, которая считается с учетом реальной прибыли, получаемой нашим заказчиком.

Executive.ru: Константин, давайте уточним. Вы готовы получать дополнительную прибыль, если проект «взлетит»? А разделить с заказчиком его убытки, если «что-то пойдет не так» тоже готовы?

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

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

Основные риски проектов в e-commerce:

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

Executive.ru: С каких цифр начинаются адекватные бюджеты интернет-магазинов?

Л.С.: Наш бюджет: разработка ТЗ – 100 тыс. руб. Проект в сумме 1,3 млн руб. Еще 100 тыс. руб. мы доплатили после запуска за недостающие функции – это было сделать проще и быстрее. Итого весь бюджет составил 1,5 млн руб. Это продающий портал под нашу целевую аудиторию, по примеру сайта Jamie Oliver – можно покупать прямо из рецептов. Получилось кривовато, несмотря на готовый пример и нашу готовность консультировать по логике работы, а также наработки, прошедшие проверку временем на предыдущей версии сайта.

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

К.П.: Предложения нашего агентства по разработке интернет-магазинов начинаются от 200 тыс. руб. Дешевле никак. А дороже может быть, конечно. Нужно учитывать полный бюджет. Разработка всего лишь его часть, не всегда самая большая.

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

Продвижение – от 100 тыс. руб. в месяц. Сумма, понятно, очень условная. Но ее порядок помогает заказчику осознать ситуацию.

Executive.ru: Значит, продвижение, в конечном счете, стоит гораздо дороже разработки – причем это регулярные расходы. Лидия, вы согласны с таким подходом?

Л.С.: Продвижение коррелируется с выручкой магазина. Значение, на которое ориентируюсь: 10% от выручки идет на рекламу. Кроме того, в интернете легко настроить точное измерение эффективности продвижения. Это статья расходов, приносящая прибыль.

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

Есть ли у заказчика команда для поддержки и продвижения своего e-commerce? Если нет, то на что он рассчитывает? Это не лотерея. Аутсорсинг тоже стоит денег. Да и насколько заказчик готов пустить разработчика к своей учетной системе и прочей кухне. Много вопросов, любые ответы на которые требуют инвестиций.

Executive.ru: Какие еще «дополнительные» расходы нужно учитывать?

Л.С.: Непредвиденные расходы на форс-мажор, на «план Б». В нашем случае ТЗ оплачивалось отдельно.

К.П.: Насчет ТЗ у меня другое мнение. Если компанию нанимают для разработки ТЗ, которое потом может быть передано другому разработчику, то да. Но обычно практика другая – заказчик прорабатывает некое упрощенное ТЗ с разработчиком и подписывает контракт, а полноценное ТЗ появляется уже в процессе разработки.

Дополнительные расходы, в идеале, должен оплачивать уже не заказчик, а его проект. Это одна из веских причин поручать e-commerce не программистам, ориентированным на код, а специалистам по онлайн-проектам, нацеленным на повышение прибыльности бизнеса заказчика.

Executive.ru: А какие промежуточные показатели и документы говорят о том, что проект идет как надо?

Л.С.: Соблюдение графика проекта, прежде всего. Каждый этап прописывается в договоре, сопровождается актами – это обычно для ведения любого проекта. И разработчик должен заниматься решением задач заказчика, а не изобретением «отмазок». По бумагам все может быть гладко, но если становится очевидным, что партнер играет не за вас, а против – очевидно, что-то пошло не так.

К.П.: Пойти наперекосяк все может, увы, в любой момент и никакие документы не застрахуют. Все хорошо, если заказчик не пропадает, не делает паузы на длительный период. Этого достаточно для успешного хода проекта, так как у нас заинтересованность 100%-ная – мы хотим закончить и получить свои деньги.

Executive.ru: И последний вопрос: как выглядит идеальный проект e-commerce? На взгляд заказчика, и на взгляд разработчика.

Л.С.: «Все уже придумано до нас». Есть манифест Agile:

Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.

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

К.П.: Идеально, когда:

На всех стадиях проекта обе стороны не пропадают и не делают пауз.
Менеджмент заказчика и разработчика не меняется по ходу проекта – с кем начали, с тем и закончили.
Проект оформлен документально, и все изменения фиксируются в ТЗ и протоколах.
Разногласия и вопросы сразу озвучиваются, а не копятся сторонами до серьезных претензий.
Оплата поступает в договорные сроки.
Цели и задачи проекта постоянно находятся в фокусе обеих сторон.
Общение на уровне человеческих отношений складывается легко, а неформальные обязательства выполняются сторонами так же, как и договорные.
Ну, и конечно, когда проект успешно стартует и развивается, заказчик получает искомый результат, а мы еще один проект в портфолио.