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

Было понятно, что возникнут сложности. Мы постарались донести это до заказчика. Но он отказался менять платформу — с его точки зрения это были неоправданные траты.

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

Вывод простой: не стоит подписываться под сомнительными решениями. Лучше потратить время «на берегу», разобраться до конца и договориться с клиентом о допустимых компромиссах.

Будет неправдой сказать, что у нас всегда все гладко, прибыльно и благодушно. Приключений хватает.

Самые неприятные ошибки, требующие самой большой работы, такие:

1. Мы сильно ошибаемся при оценке очень навороченных проектов с развитым пользовательским интерфейсом. Очень навороченных — это сверх 1 000 человеко-часов производства. Ошибаемся и календарно, и в часах, и в рублях.
   
   Наказываем себя и не требуем с клиента доплаты.
   
   Это больно и в том числе поэтому мы не любим браться за такие проекты в режиме «водопада».
   Работа над ошибками — умение продавать гибкий подход к разработке, риск-менеджмент, аналитика, сокращение сроков производства.

2. Тонем в количестве итераций при внешней интеграции. При любой методологии в проекте делать эту работу сильно долго — неверно.

Например, выгрузка одного справочника «по требованиям» должна проходить в 3-5 итераций максимум (с выдачей замечаний).
Если больше — явная ошибка во взаимодействии и понимании ответственности. Прокачиваем менеджеров (иногда переделывая формат), накручиваем хвост 1С-нику и за пару следующих итераций все становится хорошо.

Как один мудрый человек сказал: «каждый косяк — это ресурс». Тебе подсказали где ты слаб и как тебе стать лучше.

Так и действуем.

Существенной проблемой при оценке нового проекта может являться наличие в архитектуре нераспространенной ERP. К примеру, нам доводилось решать интеграционные вопросы с Tiger ERP, которая популярна в средней Азии, промахнулись с оценкой трудозатрат, несмотря на наличие API. Тут ситуация как с 1С: тяжело без опыта работы с конкретной ERP с первого раза попасть в яблочко не закладывая риски.

Но еще большие проблемы были у нас с одной отечественной ERP, которая мало того, что не имеет API, так еще использует СУБД Firebird, которая требует обслуживания с остановкой базы, что само по себе идет вразрез с основным постулатом интернет торговли — доступность 24/7. В итоге используется схема с очередью запросов к БД в случае недоступности, при этом на сайте сохраняется вся информация и используется локальное хранилище данных для просчета цен и скидок, а после того как база данных становится доступной из стека запросов осуществляется соединение с БД и проведение транзакций. Учитывая распределенность системы, где у каждого ТЦ развернута своя версия ERP, то и для каждого ТЦ существует свой шлюз, который является точкой для отправки запросов по SOAP API.

Проблема № 1. «Забыли про Ядро». Речь про разобщенные действия продакшена (проектировщиков, дизайнеров, разработчиков) и SEO-специалистов. Формально все понимают, что при разработке структуры е-коммерсных проектов нужно учитывать (а лучше закладывать в основу) семантическое ядро и прочие SEO-требования. На деле все плохо:

• Либо ни клиент, ни разработчики сайта вообще не вспоминают про SEO-требования, думая «заняться SEO» после сдачи сайта. Это очень глупо, потому что современное SEO — это качество сайта, которое закладывается именно во время разработки. Не делать SEO сразу — обрекать себя на двойную работу, на двойные сроки и затраты.

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

• Либо клиент приходит в компанию, где есть и SEO-специалисты, и разработчики, и покупает комплексную работу над проектом. Да, нужные отделы в компании есть, но они друг друга либо просто не слышат, либо активно не любят (SEOшники считают, что разработчики косячат, а разработчики ненавидят SEOшников за муторные требования). Результат опять же так себе: SEO-требования собраны, формально презентованы клиенту, но не учтены по ходу разработки.

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

Нам пришлось потратить почти год на то, чтобы научить команду разрабатывать все проекты действительно совместно — это большие трудозатраты, не дающие немедленной отдачи, поэтому на такое готовы не все подрядчики. Подробнее наш процесс описан в презентации про разработку+SEO для екоммерса.

Проблема № 2. «Разработка Большим Куском». Мы (как и все, наверное) раньше пытались делать большие магазины в один заход. Процесс выглядел примерно так:

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

• Разработка магазина затягивалась на год и более — на отрисовку, согласование и внедрение бесконечного списка фишек уходило бесконечное же количество времени.

• Проект умирал, не успев родиться — у клиента кончались деньги, менялись приоритеты, увольнялось руководство и так далее.

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

• Даже если проект успешно запускался, разработку наверняка можно было сократить на несколько месяцев — а это ощутимая упущенная прибыль.

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

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

• Не забудьте сразу же настроить аналитику (в идеале Google Tag Manager + Google Analytcis + Метрику c отчетами электронной торговли, или хотя бы что-то из этого). Вы удивитесь, на каком количестве е-коммерсных проектов данные до сих пор не собираются или собираются плохо.

• Разработчики в погоне за дизайном делают ту ошибку, которую мы уже упоминали в примере про магазин шин. Результаты фильтрации выводятся динамикой, поэтому на сайте нет адресов не только для SEO, но и для кампаний в контекстной рекламе. Даже переслать ссылку другу — и то нельзя. Не увлекайтесь динамическими фильтрами!

• Еще часто забывают о том, что структуру каталога нужно проектировать с учетом выгрузок — будь то выгрузки на Я.Маркет, Авито и прочие прайс-площадки, выгрузки для систем автоматизации контекстной рекламы, для партнерских систем и т.п. Фильтры нужно продумывать максимально подробно, чтобы каталог можно было в любой момент перестроить под ассортиментную политику нужной вам площадки. И в этом случае допиливать структуру будет гораздо дороже, чем сразу сделать хорошо«.

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

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

Когда клиент обратился к нам за помощью, мы провели технический аудит и приняли решение о переносе сайта на другую платформу. Ошибки с загрузкой данных из 1С были связаны с неправильной организацией данных на стороне клиента. Нам потребовалась 1 встреча, чтобы дать консультации по исправлению БД, а клиенту — полгода, чтобы привести свою базу в рабочий формат.

Сейчас сайт запущен и принимает заказы. Но работа над базой ещё ведётся. Таким образом, отсутствие своевременной профессиональной консультации более чем на 2 года отодвинуло запуск нового магазина.

Обожаю вопросы про «наши ошибки». Сидишь и думаешь, чтобы такого вспомнить, чтобы и про ошибку рассказать, и потом героем себя выставить.

Короче так. Самая большая экономическая ошибка для нас — это проекты, по которым мы соглашались брать за основу ТЗ от клиента и работать с ним. Особенно если это толстое и подробное ТЗ в 100500 листов.

СТО (РОВНО СТО!) процентов толстых ТЗ от клиентов, даже если они написаны другой супер-студией-и-лично-Артемием-Лебедевым — это ПРОБЛЕМА. У нас не было ни одного проекта, где за основу было взято ТЗ клиента, а на выходе получилось ХОРОШО и с ПРИБЫЛЬЮ. Все — анальная боль с кровавыми кишками.

Студии, если вы получили Большое Толстое ТЗ на руки — у вас ДВА правильных пути:

1. Оценить его строчка за строчкой, уточняя непонятные детали и прокрашивая каждое слово. Это имеет смысл ТОЛЬКО если вероятность сделки высока и вам некуда девать свободное время.

2. Вы можете дать клиенту ОЧЕНЬ БОЛЬШУЮ ВИЛКУ. Обязательно рассказать, что его ТЗ использоваться НЕ БУДЕТ (каким бы толстым оно ни было). И что цикл будет полный:
   
   Агрегация требований (аналитика) -> прототип -> наши процессы (у нас — scrum; значит, будут бэклог и итерации).

Формируйте ожидания, что ТЗ мы выкинем. А все сакральные нюансы и тонкости, которые там были прописаны, потеряем, если специально не внедрим их в бэклог.

Это адекватно, так как в ТЗ — трешак. Даже если на первый взгляд оно суперзвездатое. Я на спор на коньяк найду дыры и места с разными возможными трактовками в любом ТЗ.

Я реально видел техническое задание на 120 страниц с очень подробной и занудной детализацией, но на 88-й странице было через точку с запятой мелко написано требование «социальная сеть». И все. Ни единого упоминания больше. Вероятность пропустить такую «радость» — очень высокая.

Коллеги, берите деньги за аналитику. Раздербанивайте ТЗ на аминокислоты, только потом генерируйте свой белок.

Если этот вариант клиента НЕ УСТРАИВАЕТ, а на первый нужно неадекватно много времени — вы НИЧЕМ не можете ему помочь. Разве что подарить плакат с В.И. Лениным. Пожелайте удачи. Хлебнет бед — придет к вам. Варианта магическим образом назвать точную цифру по смете из 100500 листов бреда и потом нести за нее материальную ответственность у вас нет.

Действуйте адекватно.

Если кто-то хочет поиграть в гадания по толстому ТЗ — подходите на проверку сметы с закладной на квартиру. :).

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

Ясное дело, что тут нужны качественные фотографии, варианты размеров, модификации, привязка к коллекциям, дизайнерам. Все ужесточилось уже заказанной рекламой в печатном издании с адресом сайта, который еще в разработке. Мы-то и спарсить с архипродукст готовы были. Но цена написания парсера для 40+К товаров из 200+ категорий для клиента показалась большой, а нам для этого ночами по выходным работать. Вот так зафакапили.
Теперь при разработке e-commerce-проектов мы отдельно очень четко прописываем сколько товаров мы наполняем на этапе разработки, чтобы проверить функциональность магазина. Все остальное можем импортировать из уже подготовленной базы товаров (таблица, файлы, 1С...) или спарсить, или... Но объем и стоимость этого отдельно проговариваем.

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

1. Некорректная оценка сроков (точнее, невозможность их оценки и недостаточный резерв времени), усложненные большим количеством промежуточных контрольных точек. Срыв сроков, конфликт с заказчиком.

2. «Скрытые работы» — отсутствие надлежащего контроля изменений задачи и ситуации, как следствие — полная или частичная переделка проекта бесплатно. Срыв сроков, конфликт с заказчиком.

3. Недостаточный технический контроль за исполнителями, в результате при вынужденной смене команды — полная или частичная бесплатная переделка проекта.

4. Смена команды на стороне заказчика на почти готовом проекте, попытка полностью изменить задачу. Затем как везде: полная или частичная переделка, срыв сроков и т.д.

Дальше — как повезет. Иногда решается мирно, иногда заказчик таскает по судам и славит на весь свой круг общения.

Выводы, в принципе, содержатся в самих пунктах, но можно резюмировать. Разработчикам необходимо:

1. Обращать внимание Заказчика на то, что адекватно оценить сроки невозможно в принципе и минимизировать ограничения изначально. Учиться договариваться и коммуницировать. Не бросать заказчика одного, постоянно поддерживать связь, информировать об изменениях, предупреждать о сложностях. И ни в коем случае не врать и не брать на себя слишком много. Лучше иногда сразу отказаться от заведомо невыполнимых обязательств, чем давать надежду, а потом поставить перед фактом, что ничего не вышло

2. Работать с минимальным авансом (чтобы меньше возвращать в случае фейла), разбивать проект на много маленьких этапов с оплатой по факту

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

Мы переносили сайт со старой CMS на другую, современную. Обсудили контрольные точки, что важно перенести, составили ТЗ на этой основе. После бесконечных уточнений, когда ад должен был уже прекратится, так как сделали все, приходит последнее уточнение. Одна из важных логик работы с товарами работает не так, как надо. И мы это должны были видеть в старой CMS сами. Чтобы решить эту задачу, требовалось переписать логику CMS и переделать 50% проекта. Словом, вернули деньги.

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

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

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

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

У нас вот так, чтобы прямо фейлов с невыплатой денег или судами по магазинам не было. Но были фэйлы с точки зрения клиента, которые потом разруливались. Однако осадок оставался у обеих сторон (вот прямо сейчас есть такой проект, который на грани). Возникает он всегда в одном и том же месте, когда в магазине нужна нетиповая интеграция с 1С или другой системой заказчика.

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

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

С точки зрения заказчика, который, например, планировал начать продажи в начале осени, а магазин запустился только к Новому году — это фейл, конечно, деньги потеряны.

Один раз был смешной случай, когда заказчик выдал какие попало данные из 1С, а мы, по требованию менеджера клиента, выгрузили на сайт как есть. В итоге в продаже вместо мясопродуктов оказалось все: корма для коров (из которых потом делают эти мясопродукты), компьютеры сотрудников, канцтовары, заказываемые сотрудниками, какие-то мышеловки — все, что было в 1С.

К сожалению, не понятно, что делать с такими ситуациями. Никак не получается спецов заказчика заставить заранее готовиться к запуску интеграции с магазином.