Почему нельзя сделать за две недели? Вы что там всё это время делаете?

— Начну с того, что технически развернуть интернет-магазин можно очень быстро. Если сервер подготовлен, стандартное решение на 1С-Битрикс можно установить буквально за полчаса.

Но установленный интернет-магазин и готовый инструмент для конкретного бизнеса — совершенно разные вещи.

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

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

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

Затем проектируем интерфейсы. Создаём прототипы, в которых показываем не только расположение элементов, но и то, как они должны работать: фильтры, карточки товаров, корзина, оформление заказа, личный кабинет.

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

Но это ещё не интернет-магазин. Пока мы получили только его внешнюю часть.

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

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

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

С интернет-магазинами похожая история.

У нас были проекты, где приходилось интегрировать более сотни источников складских остатков, потому что у заказчика не существовало единой системы с актуальной информацией.

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

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

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

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

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

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

В лучшем случае потребуется переделка. В худшем — часть написанного кода придётся выбросить и начинать заново. Это не ускорение, а дополнительные трудозатраты и расходы.

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

— Конечно. Пока дизайнер работает над интерфейсами, руководитель проекта может помочь заказчику получить доступы к платёжным и логистическим сервисам. Это тоже занимает время. Разработчик может проектировать структуру данных и интеграции, пока идёт работа над визуальной частью. А когда в административной панели готов каталог, можно начинать наполнение, даже если публичный сайт ещё не завершён.

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

Мы учитываем разумное пересечение процессов уже на этапе оценки сроков. Условные четыре месяца — это не план, в котором все сидят в очереди друг за другом. Если бы весь проект делался строго последовательно, он мог бы занять ещё больше времени.

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

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

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

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

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

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

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

И это не обязательно означает бесконечные встречи. Мы подбираем формат взаимодействия под проект и заказчика.

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

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

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

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

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

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

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

— Увеличение команды иногда помогает, но далеко не пропорционально числу новых специалистов.

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

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

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

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

При этом мы спокойно передаём отдельные задачи дополнительным специалистам, когда они достаточно самостоятельны и такое разделение действительно помогает.

Вопрос не в количестве людей, а в том, насколько правильно между ними распределена работа. Просто собрать большую команду ради красивой цифры — не значит ускорить разработку.

— Я бы не согласился, что постоянные ошибки в оценках — норма программирования, с которой ничего нельзя сделать. Очень многое зависит от качества предварительного анализа и квалификации специалиста.

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

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

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

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

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

И если сотрудник пошёл по неверному пути, мы не считаем правильным переносить связанные с этим дополнительные часы на заказчика. Разбираем ситуацию внутри команды, помогаем специалисту и учитываем только обоснованные трудозатраты на решение согласованной задачи.

Смысл работы опытной компании как раз в том, чтобы заранее замечать риски, корректно оценивать задачи и не перекладывать стоимость внутренних ошибок на клиента.

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

Представим, что мы сделали промокод на скидку пять тысяч рублей. Разработчик проверил: код применяется, скидка считается, заказ оформляется. Всё хорошо.

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

И это только один из примеров. Что произойдёт, если покупатель повторно нажмёт кнопку оплаты? Если товар закончится во время оформления? Если система доставки или учёта не ответит? Эти сценарии нужно проверять систематически.

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

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

И я ни в коем случае не хочу принижать работу тестировщиков. Это сложная и важная профессия.

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

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

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

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

Поэтому тестирование нельзя считать необязательной задержкой перед запуском. Это способ проверить, что продукт не просто выглядит готовым, а способен надёжно работать.

— Возможно. Но сначала разберёмся, какую именно задачу должен решить этот магазин.

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

Возможно, придётся изменить загрузку команды или договориться о дополнительной работе. Срочность может повлиять на стоимость. Но главное — заказчик должен понимать: речь об ограниченном решении для конкретной задачи, а не о полноценной сложной e-commerce-системе с большим запасом возможностей.

Не исключено, что потом такой продукт придётся серьёзно перерабатывать или заменять. Если заказчик понимает ограничения, а мы видим, что успеем реализовать согласованный объём качественно, такую задачу можно рассмотреть.

— Тогда от двухнедельного срока откажемся. Обещать заведомо невозможное ради договора — неправильно.

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

— Помимо своевременных ответов на вопросы исполнителя, я бы выделил одну вещь: начинайте готовить контент с самого начала проекта. Не оставляйте его на последние две недели.

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

И технически готовый сайт нельзя полноценно запустить.

Заказчики иногда рассчитывают собрать всё содержимое за несколько дней. Но хороший контент требует времени: тексты нужно написать и согласовать, фотографии — подготовить, карточки товаров — наполнить достоверными данными.

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

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

Идеальная ситуация — когда завершилась разработка и весь необходимый контент уже готов. Тогда запуск не откладывается на дополнительные месяцы.

Если же подготовка материалов не включена в наши работы, за неё отвечает заказчик. Мы можем предоставить инструменты, обучить сотрудников или отдельно помочь с наполнением. Но контент сам собой не появится, когда программист допишет последнюю строку кода.

Поэтому мой совет простой: готовьтесь к запуску сайта одновременно с его разработкой, а не после её завершения.