Участники этого двойного интервью никогда не работали вместе, и до подготовки этой публикации вообще не были знакомы. Так что ничего личного, 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:
- Люди и взаимодействие важнее процессов и инструментов.
- Работающий продукт важнее исчерпывающей документации.
- Сотрудничество с заказчиком важнее согласования условий контракта.
- Готовность к изменениям важнее следования первоначальному плану.
То есть, не отрицая важности того, что справа, мы все-таки больше ценим то, что слева. Плюс ТЗ, договор, план-график и ответственность обеих сторон за свои действия.
К.П.: Идеально, когда:
- На всех стадиях проекта обе стороны не пропадают и не делают пауз.
- Менеджмент заказчика и разработчика не меняется по ходу проекта – с кем начали, с тем и закончили.
- Проект оформлен документально, и все изменения фиксируются в ТЗ и протоколах.
- Разногласия и вопросы сразу озвучиваются, а не копятся сторонами до серьезных претензий.
- Оплата поступает в договорные сроки.
- Цели и задачи проекта постоянно находятся в фокусе обеих сторон.
- Общение на уровне человеческих отношений складывается легко, а неформальные обязательства выполняются сторонами так же, как и договорные.
- Ну, и конечно, когда проект успешно стартует и развивается, заказчик получает искомый результат, а мы еще один проект в портфолио.
Уважаемые сообщники! Готов в комментариях продолжить отвечать на ваши каверзные вопросы про разработчиков и про кухню разработки.
Сразу дам СВОЙ ответ на вопрос в заголовке статьи.
Почему не понимают друг друга?
Ответ простой и сложный одновременно - из-за асимметрии информации.
Если кто не знает, то асимметрия информации — это когда заказчик имеет свое представление о товаре (сайте в данном случае), а подрядчик СВОЁ.
Случай, в практике перехода компаний на Информационные технологии, встречающийся ПОВСЕМЕСТНО!!!
Причины.
Заказчик:
Заказчик часто не понимает, что он заказывает инструмент, а не РЕШЕНИЕ своих проблем. Заказывает ИНСТРУМЕНТ для своего бизнеса. Если у него бизнес-модель четко не описана и не формализована, то написать полные и исчерпывающие требование(хотелки) к ИНСТРУМЕНТУ очень трудно. А еще страшнее, когда бизнес модели в головах нескольких ключевых сотрудников и РАЗНЫЕ.
Подрядчик:
За основу берет хотелки заказчика. Считает их установившимися (подписанными) и по ним калькулирует и планирует работы. Основная засада!!
Проект с таким заказчиком и подрядчиком гарантировано НЕУСПЕШНЫЙ.
Кстати.
Никакой Agile вас тут не спасет . Видны непересекающиеся области знаний. И эта пустота между знаниями заказчика и подрядчика должна быть как-то заполнена.
Надежда на дружеские отношения и хорошие коммуникативные возможности часто не оправдывают себя.
Валерий, хороший комментарий - отвечу за Подрядчика.
Именно против подхода "чего изволите?" я возражаю в этом интервью. Настаивая на том, что "правильный" разработчик ориентируется не на хотелки Заказчика, а на конечный результат - т.е. на то РЕШЕНИЕ, которое Заказчик хочет получить.
Где взять такого разработчика? Да, я понимаю, что рынок заполнен ремесленниками, которые важно надувают щеки, но дать могут лишь инструмент, а не РЕШЕНИЕ. Но ведь и запроса на тех, кто дает РЕШЕНИЕ, мало. Заказчики продолжают выбирать ремесленников, в принципе не понимая, что бывает и другой подход.
В Вашей фразе есть СИСТЕМНОЕ противоречие. С одной стороны "не на хотелки", а с другой "хочет получить". Системное - потому что не ясны критерии достоверности и отличия хотелок в начале проекта и ожиданий (хотелок в конце).
Мы в своем бизнесе делим заказчиков на тех кто имеет модель бизнеса и тех кто НЕ имеет.
Для тех кто "имеет" мы помогаем реализовать(или вписать) модель в Информационные Технологии.
А для тех кто "НЕ имеет" мы предлагаем типовые решения и ПРОДАВЛИВАЕМ их не заморачиваясь на "хотелки". А появившиеся "хотелки" уже в процессе пром. эксплуатации реализуем поэтапно в ДРУГОМ проекте кастомизации.
В случае с вэбом наличие даже очень успешной модели в офлайне ничего не значит, т.к. модель в онлайн перенести нельзя. Так что для интернет-магазина всегда второй вариант - "модели нет"
Здесь принципиально согласен. Разве что слово "продавливать" не про нас, но у нас и такого авторитета нет. Ну, и кастомизация некоторая также возможна в т.ч. в ходе реализации типового решения.
Валерий Овсий пишет (02 ноября 2016, 15:29):
… Никакой Agile вас тут не спасет . Видны непересекающиеся области знаний. И эта пустота между знаниями заказчика и подрядчика должна быть как-то заполнена. …
.=================================.
«Ничто не ново под Луной». Можно взглянуть на аналогичную ситуацию в других отраслях. Вот, для разработок материальных объектов есть ЕСКД. Там есть норматив, определяющий порядок-этапы разработки. Они регламентируются следующими документами:
-- Техническое предложение.
-- Эскизный проект.
-- Технический проект.
-- … (комплекты рабочей конструкторской документации, регламентирующие несколько этапов подготовки изделия к серийному производству).
Принципиально важно, что каждый этап завершается ОБРАЗЦОМ, показатели назначения и показатели потребления которого подтверждают результаты этапа. Причем, каждый этап завершается двусторонними испытаниями соответствующего образца. …
После испытаний, Исполнитель передаёт Заказчику-смежнику документацию на: образец; испытательный стенд и технологию испытаний образца на стенде.
Заказчик-смежник начинает работу на своём этапе с изготовления и испытания образца согласно документации, полученной от Исполнителя-смежника.
Такая процедура препятствует обману и «зажиму» информации от исполнителей-разработчиков этапов.
Вот так, в разработках материальных объектов, заполняется пустота, указанная Валерием Ивановичем.
А в так ли дело поставлено в ИТ-разработках? – Вопрос (думаю) – риторический.
Кстати, сейчас «мастера искусства» (далее «мыццИ») раздули скандал. А суть-то его совпадает с предметом нашей дискуссии.
Коль «мыццИ» получают госфинансирование, то они являются подрядчиками, выполняющими госзаказ.
Вот, в «Полных контактах с В.Соловьёвым», упоминался Микеланджело. Он всю жизнь работал по заказам. И до нас не дошло ни одного факта его возмущения на обязательность соответствия его творений представлениям заказчика.
А оплата госзаказа осуществляется за деньги налогоплательщиков. Так какого хрена «мыццИ», противоречащие представлениям налогоплательщиков, забились в истерике? Мол, никто не имеет права посягать на свободу их творческих дерзаний. Даже если бы они дерзали за свои деньги, они обязаны считаться с обычаями народа, в среде которого живут и которому пытаются сбыть продукты своих дерзаний.
Вот сейчас начал смотреть интервью Мединского, в «Вечере с Владимиром Соловьёвым». Мединский на вопрос, о чем он разговаривал с «мыццями», заявил, что де, это были конфиденциальные разговоры. Нас уже приучили не принимать подобные заявления как наглость. Если бы министр платил денежку «мыццЯм» из своего кармана, то мог бы ссылаться на конфиденциальность. Но, он распределяет между «мыццЯми» деньги налогоплательщиков. Так какое право он имеет прятать «конфиденциальностью» свои разговоры с «мыццЯми»?
Так что, обсуждаемая тема – очень даже не простая и не одноплановая.
Доброго дня, коллеги! Вопросы, комментарии и мысли welcome! )