Несколько лет назад мы (Студия 15) обратили внимание на повышение интереса к услуге технической поддержки со стороны «старых», крупных интернет-проектов. Это были состоявшиеся сайты, разработанные 10–15 лет назад, ставшие небольшими бизнесами. Их можно называть «суши сайты» (the sushi sites), потому что разработаны в эпоху суши (the sushi years, Гугл).

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

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

Но клиентам вариант разработки нового проекта часто не подходит: долго, дорого, большие риски. А гарантий никаких нет; элементарно — пользователи могут его не принять по какой-либо причине. (Мы не один раз сталкивались с ситуацией, когда уже модернизированный сайт не запускается из-за сомнений владельцев; причём иногда готовых, но не запущенных версий может быть несколько.)

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

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

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

Особенности the sushi sites

The sushi sites во многом не похожи на другие сайты, можно даже говорить про их некую уникальность.

Возраст

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

Положение на рынке

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

Финансы

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

Управление и процессы

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

Перспективы

Пройден сложный путь и накоплен опыт. Идея проверена на практике. Проект в целом востребован и жизнеспособен. Владельцы знают, как развиваться и куда двигаться. Мало кто из профессиональных разработчиков готов работать с такими проектами, обычно предлагают создать новый сайт. Кажется, это «проще», но далеко не всегда так: полностью переделать проект может оказаться намного сложнее и дороже чем развивать, причём как для разработчика, так и для клиента.

Владельцы

Гуру в тематике своего проекта, могут иметь соответствующий офлайн бизнес, но не эксперты в интернет-технологиях.

Роль для владельца

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

Команда

Над проектом успевает поработать много (десятков) команд и фрилансеров. От случайных нескольких часов до плодотворных нескольких лет.

Из-за необходимости экономить и отсутствия компетенций подбора, уровень исполнителей часто невысокий. Привлекаются «универсалы», когда один человек занимается, например, дизайном и программированием. Приглашаются фрилансеры по схеме: сделал-сдал-ушёл (или не сделал... или не сдал).

Исполнители решают поставленную задачу, не учитывая интересы проекта и клиента: перспектив развития, стоимости поддержки предложенного решения.

В штате отсутствуют технические специалисты, которые готовы или способны передать его новой команде, привлекаемые исполнители вынуждены работать по прецедентам (сделали → ой! → что? → отвалилось → где? → там! → правим).

Технический лидер

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

Технологии

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

Мотивация для сотрудничества

Для владельца the sushi sites

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

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

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

Для исполнителя и его разработчиков

Разработчики обычно не в восторге от таких проектов. Но, по нашему опыту, если они уверены, что будет реально позволено (выделен бюджет) улучшать кодовую базу, а новые модули, где возможно, будут писаться на «правильных» технологиях по современным стандартам, то относятся с пониманием.

Интереснее работать над востребованными, зарабатывающими, доказавшими свою пользу, с большой и постоянной аудиторией сайтами, а не «в стол».

Получить заказ на разработку «с нуля» проекта схожего уровня для разработчика без нужного опыта сложно. Можно попробовать получить его на проектах, связанных с развитием (мы бы не рискнули).

Такие проекты хороши для портфолио. В том числе из-за своей известности (пусть и в узких кругах).

Нужно уже со старта решать реально сложные задачи.

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

Наши рекомендации

К чему готовиться, на что обращать внимание сторонам?

Всем

• В расчётах использовать Time and materials (оплата времени исполнителя) и производные схемы. Расчёты исходя из оценок ничего хорошего здесь не дадут никому. Оценивать, конечно, нужно, но все должны понимать, что это только ориентир.

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

• Первые боевые задачи — «сопровожденческие» с постепенным усложнением и переходом в развитие и модернизацию.

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

• Добавим сентиментальности — на этапе продажи нужно понимать есть ли взаимная «химия». Это важно. Работать нужно будет долго и плотно, а проблемы будут (много и серьёзные).

• Открытость обеих сторон («на работы в этом месяце сможем выделить не более ххх рублей»; «на этой неделе успеем закрыть только эти две задачи»). Много, очень много коммуникаций. У нас, помимо постоянного ежедневного общения стратега с ответственным со стороны клиента, проводятся еженедельные общие митинги с участием наших тимлидов и опционально других специалистов, созвоны по сложным задачам, еженедельные ретроспективы, предоставляются еженедельные отчёты.

• Важно всегда помнить: проект должен стабильно работать; сегодня, завтра... и после ухода текущего исполнителя.

• Новый функционал не делать «по-старому». Постепенно улучшать кодовую базу и используемые технологии.

• Часть бюджета (10–20%) выделять на рефакторинг старого кода.

Клиенту

• Искать укомплектованную, слаженную и ответственную команду с опытом в разработке сложных проектов и желанием заниматься развитием не ей разработанных сайтов.

• Обращать внимание на качество управления. Вам нужна команда с высоким уровнем проектного менеджмента и культуры коммуникаций.

• Быть готовым активно участвовать в работе. Не только при постановке и приёмке работ, но и в процессе её выполнения.

• Следить за стабильностью работы исполнителя: изменения должны внедряться без постоянного надрыва и форс-мажоров.

• Готовность платить на длинной дистанции.

Разработчику

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

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

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

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

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

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

• Быть готовым к тому, что когда проекту станет чуть лучше, то поведение клиента может измениться или он даже уйдёт. Ведь проблем давно не было (вы же сделали проект лучше?), а значит можно вернуться к работе по более дешёвым схемам. И кстати, теперь вообще не понятно за что вам платили такие «огромные» деньги.

Вывод: работать можно, но осторожно

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