Есть довольно странное представление о работе веб-студии: если клиент пришёл с деньгами, подрядчик должен радостно открыть ноутбук, подписать договор и начать делать. Неважно, насколько реалистична задача, понятна ли её цель и можно ли вообще получить тот результат, которого ждёт заказчик. Клиент платит — значит, надо брать. Иначе вроде как зачем вы вообще бизнес открывали?
Мы в Alfa IT Studio смотрим на это немного иначе. Иногда лучший проект — тот, который не начался.
Звучит нелогично, особенно для коммерческой компании. Но за годы работы начинаешь довольно быстро замечать определённые признаки: вот здесь проект можно сделать хорошо, здесь понадобится сначала пересобрать задачу, а вот здесь через четыре месяца все участники почти гарантированно будут недовольны друг другом. Клиент — потому что получил не то, что представлял. Разработчики — потому что требования менялись каждую неделю. Руководитель проекта — потому что первоначальный бюджет закончился где-то между «давайте немного переделаем главную» и «а теперь вообще поменяем концепцию».
Можно, конечно, закрыть на всё это глаза. Деньги ведь платят.
Но нам такой подход не нравится.
Наверное, это главная причина, почему мы вообще можем говорить клиенту «нет». Когда компания приходит в веб-студию, она покупает не просто определённое количество часов дизайнера, программиста или тестировщика. Если бы задача сводилась исключительно к механическому исполнению команд, подрядчика можно было бы заменить человеком с очень хорошей клавиатурой. Нормальная разработка устроена иначе. Клиент хорошо знает свой бизнес, а мы должны разбираться в том, как эту бизнес-задачу превратить в сайт, сервис, интеграцию или другую цифровую систему. Поэтому наша работа иногда заключается не в том, чтобы сказать «да, сделаем», а ровно наоборот — объяснить, почему предложенное решение создаст проблемы.
Представим простой пример. Компания приходит и просит полностью переделать интернет-магазин, потому что владельцу не нравится дизайн. На вопрос, что именно бизнес хочет получить после редизайна, ответа нет. Конверсия? Скорость оформления заказа? Рост органического трафика? Уменьшение отказов? Улучшение мобильной версии? Нет, просто «хочется посовременнее». Технически такой заказ можно взять. Нарисовать другой интерфейс, переверстать страницы, поменять шрифты и через несколько месяцев торжественно нажать кнопку запуска. Только потом выяснится, что продажи остались прежними. Или даже стали хуже. И начинается вечное: дизайнер считает, что всё сделал красиво, клиент считает, что деньги потрачены зря, разработчик вообще не понимает, почему от него требуют роста конверсии.
Поэтому сначала нам нужна задача. Не обязательно толстое техническое задание на двести страниц — часто достаточно нормального ответа на вопрос: что в бизнесе должно измениться после завершения проекта?
Если ответа нет, имеет смысл сначала искать его, а не писать код.
Есть ещё один тип проектов, который на первый взгляд выглядит очень удобным. Клиент приходит уже с готовым решением: вот структура, вот дизайн, вот функциональность, здесь ничего не обсуждаем, просто реализуйте. Казалось бы, мечта подрядчика. Не надо спорить, исследовать, предлагать альтернативы. Делай по инструкции и выставляй счета. На практике всё не так радужно. Потому что заказчик может принести решение, которое объективно создаёт проблемы: неудобный пользовательский сценарий, чрезмерно сложную архитектуру, странную структуру каталога, плохо продуманную интеграцию. Если подрядчик видит это, молчит и просто выполняет указания, то через полгода фраза «вы сами так попросили» вряд ли кого-нибудь утешит.
Вот тут проходит важная граница. Мы совершенно нормально относимся к ситуации, когда клиент не соглашается с нашей рекомендацией. Это его бизнес и в конечном итоге его решение. Но если от веб-студии изначально требуется только механически подтвердить уже придуманную концепцию и желательно не задавать неудобных вопросов, мы, скорее всего, друг другу не подойдём. Экспертиза без права высказать мнение — довольно бессмысленная услуга.
Есть проекты, где проблема видна буквально из первого сообщения: «Нам нужен новый корпоративный сайт, личный кабинет, интеграция с 1С и CRM, дизайн с нуля. Запуститься надо через две недели».
Почему через две?
«У руководства мероприятие».
Это тот момент, когда у подрядчика появляется выбор. Первый вариант — честно сказать, что полноценный проект в такие сроки сделать нельзя. Второй — назвать приятную заказчику дату, получить аванс, а дальше надеяться на чудо. Но чудеса в разработке случаются редко. Конечно, практически любую большую задачу можно декомпозировать. Можно быстро выпустить посадочную страницу к мероприятию, параллельно проектируя основной сайт. Можно сделать MVP, а функциональность добавлять этапами. Можно временно отказаться от части интеграций. Вот это нормальный разговор.
Но если клиент одновременно хочет максимальный объём, минимальный срок и фиксированный небольшой бюджет, математика начинает сопротивляться. Приходится жертвовать либо тестированием, либо архитектурой, либо дизайном, либо нормальным управлением проектом. Чаще понемногу всем сразу. Мы не любим участвовать в историях, где ещё до старта известно, что качество назначено разменной монетой.
Иногда проблема вообще не в сайте
Это особенно хорошо заметно на проектах автоматизации. Компания приходит за CRM, корпоративным порталом, личным кабинетом или внутренней системой и ожидает, что новый софт наконец-то наведёт порядок.
Начинаем разбираться — а порядка нет не потому, что старая система плохая. Один отдел ведёт клиентов в Excel, второй в CRM, у третьих все переписки просто в мессенджере хранятся. У одинаковых показателей разные определения. За процесс никто целиком не отвечает. Сотрудники не договорились, кто и когда меняет статус заказа, а руководство хочет «просто автоматизировать».
Тут хочется сказать одну неприятную вещь: код не лечит управленческий хаос.
Можно сделать красивый интерфейс для хаоса. Можно автоматически переносить хаос из одной базы в другую. Можно построить отчёт, который очень быстро считает некорректные данные. Но технология не заменяет договорённости внутри компании. Поэтому иногда перед разработкой клиенту гораздо полезнее привести в порядок свои бизнеес-процессы, назначить ответственность и договориться о правилах работы с данными. И только потом автоматизировать. В противном случае новый сервис через год рискует превратиться в очередной слой поверх пяти предыдущих костылей. Это тот редкий случай, когда отказ разработчиков может сэкономить компании намного больше денег, чем скидка на сам проект.
Изменение требований само по себе совершенно нормально. Более того, странно ожидать, что сложный цифровой продукт можно идеально описать в первый день и следующие восемь месяцев вообще ничего не менять. Бизнес живой, рынок меняется, во время разработки появляются новые данные — корректировки неизбежны.
Проблема начинается там, где изменения перестают быть управляемыми.
В понедельник делаем маркетплейс. В среду решили добавить социальную сеть. В пятницу директор увидел сайт конкурента и хочет «примерно такую механику». Через неделю социальная сеть больше не нужна, зато теперь необходима программа лояльности. Старые решения не фиксируются, ответственные меняются, а каждое обсуждение заканчивается фразой: «Ну вы пока сделайте, потом определимся».
Такой проект может поглощать деньги почти бесконечно. И самое неприятное — он всё равно не приблизится к завершению, потому что финиш постоянно переезжает.
Если бизнес честно говорит: «Мы создаём экспериментальный продукт, многое будем проверять по ходу», — отлично. Тогда выбирается соответствующий процесс разработки, короткие итерации, прототипы, гипотезы и пересмотр приоритетов.
Но хаос и гибкость — не одно и то же.
Если решения просто принимаются импульсивно, никакая Agile-терминология это не исправит.
Есть ещё довольно эгоистичная причина внимательно выбирать проекты — репутация. Через несколько лет мало кто вспомнит, что в неудачном проекте клиент десять раз менял требования, согласовывал каждый экран по месяцу или настоял на решении, против которого выступала команда. На рынке останется гораздо более короткая история: «Этот сайт делала такая-то студия».
И это нормально.
Если мы ставим своё имя рядом с проектом, значит должны быть готовы за него отвечать. Поэтому идея заработать сегодня на задаче, в хороший результат которой мы сами не верим, выглядит довольно сомнительно. Репутация собирается медленно. Один проект, второй, десятый, пятидесятый. И точно так же незаметно портится, если подрядчик начинает брать всё подряд по принципу «главное подписать договор, а там разберёмся».
Нам интереснее долгий путь.
И нам совершенно не нужны идеальные клиенты с безупречным ТЗ, огромным бюджетом и ответами на все вопросы. Таких, подозреваем, вообще немного. Нам нужны проекты, где можно разговаривать. Где заказчик знает свой бизнес и готов объяснять его нам, а мы можем задавать вопросы и предлагать решения. Где ошибку можно признать ошибкой, а не защищать только потому, что её предложил руководитель. Где изменения обсуждаются, приоритеты фиксируются, а результат оценивается не количеством нарисованных страниц и написанных строк кода.
Мы тоже можем ошибаться. Можем неправильно оценить решение, переусложнить его или, наоборот, сначала недооценить задачу. Нормальная совместная работа не требует непогрешимости от обеих сторон. Она требует возможности говорить об этих вещах открыто.И вот в таких проектах мы действительно можем отвечать за результат.
Так почему мы иногда говорим «нет»?
Не потому, что считаем себя настолько важными, что можем выбирать клиентов по настроению. И не потому, что любим усложнять переговоры. Просто есть момент, после которого согласие перестаёт быть хорошим сервисом.
Если мы видим, что задача не сформулирована, сроки существуют отдельно от реальности, внутри бизнеса нет процессов для будущей автоматизации или от нас заранее требуется молчаливое исполнение решения, которое мы считаем ошибочным, честнее обсудить это до договора. Именно такой принцип заложен и в исходной позиции Alfa IT Studio: не брать заведомо плохие проекты и не превращать формальное выполнение ТЗ в замену реальному результату.
Иногда после разговора задача меняется — и мы начинаем работать. Иногда действительно расходимся.
Это тоже нормально.
Потому что хороший подрядчик, на наш взгляд, отличается не тем, что отвечает «да» на любой запрос. А тем, что понимает последствия своего «да». И умеет вовремя сказать «нет».