Автор: Переход власти сопряжен с трудностями. У разных команд разные ценности, разный опыт, разные знания, разные приоритеты, и это приводит к разным инструментам и разным методологиям. Возникает соблазн думать о веб-дизайне как о сквозном процессе, начинающемся с исследования и заканчивающемся метриками. Реальность такова, что большинство дизайнеров и разработчиков присоединяются к проектам на полпути в ходе текущего процесса. Это ставит нас перед сложным выбором: попытаться оправдать ожидания клиента с помощью собственного набора инструментов или адаптироваться к уже существующим инструментам и процессам? Для тех, кто принимает веб-проект от другого дизайнера/разработчика/агентства (D/D/A), вот практическое руководство, которое поможет вам успешно осуществить переход.
Шаг 1: Выясните, что пошло не так
В 99,99% случаев что-то ломалось в предыдущих отношениях клиента и D/D/A. По моему опыту, это почти никогда не связано с деньгами. Большинство клиентов готовы платить выше базовой рыночной ставки, если считают, что получают хорошую отдачу от своих инвестиций. Клиент, который говорит вам, что предыдущий D/D/A был просто слишком дорогим, предвкушает переговоры о ваших гонорарах. [pullquote]довольные клиенты не ищут работу[/pullquote] Иногда вы обнаружите, что внештатного дизайнера наняло агентство, и он больше не доступен. Иногда компания перерастает D/D/A, переходя в области, которые D/D/A не поддерживает. Но такие ситуации редки, довольные клиенты — даже умеренно довольные клиенты — не ищут работу. Если они говорят с вами, что-то побудило их это сделать. Тревожно часто, что D/D/A просто уходит в самоволку. Чаще всего это происходит в нижнем сегменте рынка, где вовлеченные суммы денег с меньшей вероятностью приведут к юридическому спору. Часто неуважаемый D/D/A уклоняется от клиента в пользу лучшей, новой возможности. Иногда клиент нанимает нового менеджера, и новый менеджер вносит изменения в ожидания, которые предыдущий D/D/A не может удовлетворить. Чаще всего предыдущий D/D/A слишком часто ошибался — ошибки случаются, и разумные клиенты будут терпеть их, если они будут быстро исправлены, но у каждого есть свои пределы. Большинство клиентов будут более чем рады объяснить, что пошло не так в предыдущих отношениях; это неизбежно будет односторонним объяснением, но оно поможет вам понять ожидания клиента. Будьте крайне осторожны с клиентом, который не знает, что пошло не так. Будьте еще более осторожны с клиентом, который говорит об «улучшении» своего аутсорсинга — он пытается вам польстить. В этих случаях клиент вполне может что-то скрывать — например, свою неспособность оплачивать счета. Помните: в какой-то момент предыдущий D/D/A был новым, и радовался новому клиенту, был оптимистичен в отношении проекта, и это не закончилось хорошо. Лучший способ не повторять ошибок — учиться на них, и для этого нужно знать, в чем они заключались.
Шаг 2: Проведите комплексный аудит
Мы часто так хотим получить новую работу, что торопимся, чтобы клиент поставил подпись на пунктирной линии, ожидая, что сможем справиться с любыми проблемами позже. Крайне важно, чтобы вы, как профессионал, сдерживали свои обещания. Прежде чем давать эти обещания, не торопитесь, чтобы понять проект и связанный с ним бизнес. Если клиент достаточно заинтересован, чтобы подписать с вами контракт, он не будет возражать, если вы сначала проведете комплексную проверку.
Сохранились ли отношения с предыдущим дизайнером/разработчиком/агентством?
Клиенты редко имеют полную картину своего проекта — они не веб-профессионалы, если бы они были ими, они бы создавали свои собственные сайты. Ваш лучший источник информации — предыдущий D/D/A. Прежде чем связаться с предыдущим D/D/A, уточните у своего клиента; возможно, он еще не знает, что его заменяют. Если ваш клиент согласен, свяжитесь с ним. Когда вы разговариваете с предыдущим D/D/A, будьте внимательны к тому факту, что вы берете деньги из его кармана. Конечно, предыдущий D/D/A может сказать вам, куда идти, он может вообще вас проигнорировать, но большинство будет прагматично относиться к передаче проекта, хотя бы для того, чтобы гарантировать своевременную оплату их окончательного счета их теперь уже бывшему клиенту. У каждого сайта есть свои особенности, если вы сможете установить дружеские отношения с предыдущим D/D/A, то переход будет значительно менее ухабистым.
Кто контролирует доменное имя(я)?
По моему мнению, доменное имя (имена) компании всегда должно принадлежать компании; это такой важный бизнес-актив, что его следует охранять так же ревностно, как банковские счета компании. К сожалению, есть компании, которые передают на аутсорсинг все, что связано с вебом. Если разрыв с предыдущим D/D/A был резким, то закрепление доменного имени может быть проблематичным. Закрепление доменного имени — не ваша работа, у вас нет рычагов влияния, а у клиента есть. Ваша работа — убедить клиента, насколько критически важны для миссии доменные имена.
Кто контролирует хостинг?
Хостинговые соглашения различаются от проекта к проекту. Нередко и неразумно, что предыдущий D/D/A размещает сайт клиента на своем собственном пространстве. Если это так, будьте готовы быстро перенести его либо на свой сервер, либо на выделенное пространство. Если вы переходите на новое пространство, обратите особое внимание на предоставление электронной почты. Принятие проекта обычно означает принятие работающего проекта, а это обычно означает учетные записи электронной почты. В любом случае вам нужен полный доступ к пространству хостинга. Вам определенно нужен доступ по FTP, вам, вероятно, нужен доступ по SSH. В дополнение к хостингу проверьте, использует ли сайт вашего клиента CDN, и если да, то кто им управляет.
Исходный код бэкэнда
Получив FTP-доступ к хостинговому серверу, вы, вероятно, сможете получить весь код бэкэнда с сервера. Преимущество получения кода с сервера — в отличие от принятия файлов из предыдущего D/D/A — заключается в том, что вы можете быть абсолютно уверены, что получаете текущий (рабочий) код. Если клиент порвал с предыдущим D/D/A, потому что не смог выполнить определенную задачу, вам не захочется работать с файлами, которые были частично изменены. Свежие установки Если вы работаете с чем-то вроде CMS, часто бывает хорошей идеей запустить новую установку на вашем сервере, а затем скопировать все шаблоны, плагины и перенести базу данных.
Исходный код интерфейса
Когда дело доходит до получения исходного кода, код frontend гораздо более проблематичен, чем backend. [pullquote]код frontend гораздо более проблематичен, чем backend[/pullquote] Если предыдущий D/D/A хотя бы частично компетентен, то CSS и JavaScript в веб-пространстве минифицируются. Минифицированный CSS не слишком проблематичен и может быть довольно легко разминифицирован, но вы не хотите распаковывать минифицированный файл JavaScript — у меня однажды был проект, в котором разработчик минифицировал свой собственный код в том же файле со всеми его зависимостями, включая Vue и jQuery [да, я знаю ]. Работа с исходным кодом frontend может приобрести дополнительное измерение, если вы обнаружите, что предыдущий D/D/A использовал методы, которые вы не используете — использование Less вместо Sass или написание скриптов на TypeScript. Разминификация CSS и JavaScript Разминификация (или украшение , или утончение ) кода довольно проста. В сети есть инструменты, которые помогут, включая Unminify , Online CSS Unminifier , FreeFormatter , JS Minify Unminify и другие. Вы также найдете множество расширений для редакторов кода, включая HTML-CSS-JS Prettify для Sublime Text и Atom-Beautify для Atom. Вы обнаружите, что некоторые редакторы имеют встроенную функциональность. Предупреждение: улучшение кода не восстанавливает комментарии, а в случае JavaScript не расшифровывает имена переменных. Улучшение кода не заменяет копию оригинального, неминифицированного исходного кода. Экстренные меры Если по какой-либо причине невозможно отменить изменение исходного кода или, что более вероятно, неминифицированный JavaScript все еще выглядит как минифицированный код — хотя и красиво отформатированный минифицированный код — то последнее средство — импортировать код и переопределить его при необходимости. Первое, что нужно сделать в этом случае, — объяснить ситуацию клиенту. Убедитесь, что они понимают, что это временный патч, который вы устраните по мере перестройки частей проекта. Затем скопируйте и вставьте старый минифицированный код в новую настройку проекта. Для CSS это, вероятно, означает создание файла legacy.scss , включая старый CSS, и импорт его в ваш собственный Sass. Для JavaScript создайте файл legacy.js , добавьте весь старый JS и импортируйте его. Это приведет к гораздо большему набору файлов, чем необходимо, вы можете в конечном итоге использовать !important в своих объявлениях стилей [фу], и вы вызовете множество предупреждений Lighthouse об избыточном коде. Однако в вероятном случае, если у вашего клиента есть длинный список изменений, которые он хотел реализовать вчера, этот грязный хак даст вам работающий сайт, который вы затем сможете перестраивать по частям с течением времени.
Ресурсы
Активы обычно означают изображения, а изображения обычно можно получить через FTP. Иногда — хотя реже, файлы изображений теперь редко содержат текст — вам понадобятся исходные файлы для внесения изменений в изображения. Есть ли они у клиента или передаст ли их предыдущий D/D/A, во многом зависит от соглашения между клиентом и предыдущим D/D/A. Большинство компаний разумно осознают важность активов бренда, поэтому вы, вероятно, обнаружите, что у них, по крайней мере, есть копия их логотипа; будь то SVG или JPG — это совсем другой вопрос. Внушите им важность нахождения этих файлов для вас.
Код третьей стороны
Редко можно получить проект, который не полагается на сторонний код. Этот сторонний код, вероятно, вплетен в пользовательский исходный код, и его распаковка — трудоемкая работа. Весьма вероятно, что предыдущий D/D/A использовал библиотеку или фреймворк, и, учитывая их растущее число, еще более вероятно, что библиотека или фреймворк, которые они использовали, не те, которые вам нравятся. Выберете ли вы распаковку кода и замену зависимостей предыдущего D/D/A на свои собственные предпочтения (обычно быстрее в долгосрочной перспективе) или решите работать с тем, что вам дали (обычно быстрее в краткосрочной перспективе), — решать только вам. По моему опыту, не составляет труда выбрать другую библиотеку CSS; переключение с одного фреймворка JavaScript на другой — это существенно более серьезная работа, включающая не только синтаксис, но и основные концепции.
Будьте осторожны в средах сборки
У каждого свой способ делать что-то. Некоторые D/D/A используют среды сборки, некоторые нет. Некоторые среды сборки просты в использовании, некоторые нет. Некоторые среды сборки адаптируются к вашему процессу, некоторые нет. [pullquote]В отличие от принятия библиотеки или даже фреймворка, принятие нового процесса сборки редко бывает хорошей идеей[/pullquote] Сред сборки много — Gulp, Grunt и Webpack все популярны — и D/D/A почти так же самоуверенны в отношении них, как и в отношении CMS. Вместо сырых файлов, не редкость, что предыдущие D/D/A говорят вам «просто запустить такую-то команду CLI», чтобы сопоставить вашу локальную среду с их. В отличие от принятия библиотеки или даже фреймворка, принятие нового процесса сборки редко бывает хорошей идеей, потому что вы низводите себя из эксперта в новичка в то время, когда вы еще не заслужили доверие вашего нового клиента. Стойте на своем. Их подход провалился, поэтому вас и привлекли. Вы делаете это сами.
Кто имеет лицензию?
Любой оплаченный код третьей стороны лицензирован. Всегда проверяйте, у кого есть эти лицензии. Помимо того, что это требуется по закону, действительные лицензии обычно требуются для обновлений, исправлений ошибок и в некоторых случаях поддержки. К распространенным подводным камням относятся: лицензии на шрифты (которые могут быть лицензированы в рамках учетной записи Creative Cloud, Fontstand, Monotype и т. д. предыдущего D/D/A); лицензии на стоковые изображения (которые могут быть лицензированы для использования только предыдущим D/D/A); и плагины (которые часто лицензируются оптом для D/D/A в пакетах). Удручающе часто можно встретить клиентов, использующих нелицензированные активы. Не раз мне приходилось объяснять клиенту потенциальные последствия использования пиратских шрифтов. К счастью, все чаще сторонние поставщики прикрепляют лицензию к указанному домену, что означает, что вы можете потребовать лицензию от имени своего клиента. У крупных поставщиков, таких как CMS и решения для электронной коммерции, часто есть возможность для предыдущего разработчика выпустить лицензию и позволить вам потребовать ее. В случае лицензирования, если вы не уверены, не бойтесь обратиться к стороннему поставщику и проверить, есть ли у вашего клиента лицензия после того, как он разорвет связи со своим предыдущим D/D/A. Единственное, что портит отношения с клиентом быстрее, чем сказать ему, что ему нужно купить лицензию, за которую он думал, что уже заплатил, — это сказать ему, что на него подали в суд за нарушение авторских прав. Защитите своего клиента и защитите себя, убедившись, что все лицензировано должным образом. Если вы можете получить что-то в письменном виде об этом от предыдущего D/D/A, сделайте это.
У кого есть исследования и аналитика?
Одним из главных преимуществ перехода на сайт, в отличие от создания с нуля, является то, что у вас есть измеримый набор данных, специфичных для сайта, чтобы направлять принятие решений. Это применимо только в том случае, если у вас есть данные, поэтому попросите добавить вас в учетную запись аналитики клиента. Существует большая вероятность того, что проектное исследование, проведенное предыдущим D/D/A, будет считаться внутренним документом, а не результатом работы предыдущим D/D/A. Уточните у своего клиента: если он заплатил за исследование (это указано в счете?), то он имеет право на копию.
У нас тоже есть блог…
Клиенты склонны использовать термин «веб-сайт» как всеобъемлющий термин для всего цифрового. Когда вы берете на себя ответственность за веб-сайт, от вас почти всегда ожидают ответственности за любые цифровые услуги, которые использует клиент. Это означает службы рассылки новостей, такие как Mailchimp, учетные записи службы поддержки клиентов, такие как Intercom, и блоги WordPress на 227 000 страниц, которые они забыли упомянуть в первоначальном брифе. Повторите весь Шаг 2 для каждого дополнительного приложения, микросайта, блога и всего остального, что есть у клиента, если только клиент прямо не сказал вам не делать этого.
Шаг 3: Точка невозврата
До сих пор вы не просили клиента подписать пунктирную линию. Весь этот процесс является частью вашей должной осмотрительности. Проверяя эти вещи, вы можете выявить непредвиденные проблемы и потенциальные расходы. Вы привязаны к неясному процессу сборки? Вам нужно повторно лицензировать CMS? Вам нужно заново создать все ресурсы сайта? [pullquote]Некоторые из этих разговоров трудно вести, но сейчас самое время их провести[/pullquote] Если есть какие-либо сомнения в том, что проект сложнее, чем предполагалось, честно поговорите со своим клиентом — он оценит вашу прозрачность и оценит, что его держат в курсе. Любой клиент, который не ценит четкое представление о том, за что он вам платит, — это не тот клиент, который вам нужен. Некоторые из этих разговоров трудно вести, но сейчас самое время их провести, а не через три месяца. Это точка невозврата. С этого момента любые проблемы — это не предыдущие D/D/A, они ваши.
Изменить пароли
Для каждой услуги, которая у вас есть, от входа в новостную рассылку до входа в CMS и данных FTP, измените пароль. (Обязательно уведомите об этом клиента.)
Создайте промежуточную площадку
Вам понадобится промежуточный сайт, чтобы ваш новый клиент мог просмотреть работу, которую вы для него сделали. Настройте промежуточный сайт немедленно, до того, как вы внесете какие-либо изменения в код. Сделав это, вы быстро обнаружите, отсутствуют ли какие-либо файлы или есть ли проблемы с имеющимися файлами.
Успешный переход проекта
Когда клиент заказывает сайт с нуля, он полон ожиданий. Тот факт, что он оставляет своего предыдущего D/D/A и обращается к вам, показывает, что его опыт не оправдал его надежд. Теперь у вас есть клиент с реалистичными — возможно, даже пессимистичными — ожиданиями. У вас есть эталон, по которому можно объективно оценить вашу работу. Когда возникают проблемы, а они неизбежно возникнут, никогда не пытайтесь обвинить предыдущего D/D/A; это была ваша работа — оценить состояние дел до начала работы. Если возникла проблема с устаревшими активами, вы должны были обратить на нее внимание вашего клиента на раннем этапе. Если вы извлечете урок из ошибок предыдущего D/D/A, вам не придется передавать проект кому-то другому в ближайшее время.
