Регламенты: упрощаем работу с заказами в 5 раз
Страдала я, страдали заказчики, страдали люди, которые работают вместе со мной: ровно до того момента, как я пришла к тому, что на каждый чих нужен регламент. Чихнул по регламенту — и жить сразу проще становится. И сейчас я расскажу как, зачем и почему.
Заказчик не понимает что он заказывает - расскажите ему!
Приходя за дизайном сайта, заказчик чаще всего думает, что пришел за картинкой. Вот он в одно отверстие всунет ТЗ и деньги, а из другого вылезет готовый дизайн. Нет, нет и еще раз нет. Делать дизайн с нуля - это долго и требует совместной работы.
Чтобы не рассказывать каждый раз, что к чему, я просто кидаю ссылку на эту статью https://vc.ru/design/183789-kak-sdelat-dizayn-sayta-cherez-prizmu-ux-bez-tancev-s-bubnom-sms-i-registracii или один из своих внутренних документов, и экономлю себе около 2-3-5 часов времени на переписки или пол-часа на телефонный разговор.
Отдельные регламенты спасают жизнь даже на таких простых услугах как “креативы для рекламы” или “баннеры для сайта”.
Чем грозит отсутствие регламента
На примере. Как-то раз один банк заказал видеоролик. Показал презентацию, из которой его надо собрать, я назвала сумму, ударили по рукам и начали работать. Выглядит как простое ТЗ? Определенно.
По факту получилось так: после месяца страданий, предложений разных вариантов стилистики и не очень приятных разговоров мы все-таки его сделали. Причем так, что понравилось всем, однако ценой пары километров нервов. После разбора полетов выяснились следующие интересные обстоятельства:
- Регламент на видеоролик не был обсужден с клиентом, и клиент вообще не понимал что мы делаем, зачем присылаем ему какие-то куски и когда он увидит полный ролик.
- Клиент постоянно требовал действовать по своей “схеме” разработки ролика, которая была, мягко скажем, далекой от адекватной реальности. И PM прогибался под эту схему под давлением сроков. То есть стараясь сделать лучшее что может для клиента - он делал ситуацию только хуже.
- Текущее понимание проджект-менеджером процесса разработки ролика несколько отличается от моего, и всего опыта PM’а не хватило на то, чтобы сделать заказ меньшими силами.
- Заработали мы на этом проекте только опыт. Хороший опыт, который не хочется повторять.
В общем, когда нет четкого регламента, будьте уверены - каждый пойдет своим путем: кто в лес, кто по дрова, кто - читать забугорный мануал, не имеющий отношения к отечественной реальности.
Локальные фейлы без регламента, которые съедают время
Для дизайнера:
- Не сделал ТЗ для верстальщика - будь готов, что тебя будут дергать 2-3 недели.
- Забыл “уложить” макет - опять будут дергать.
- Не рассказал заказчику о процессе разработки дизайна - будешь рассказывать от 1 дня до 2 недель отрывочно. А потом половину придется повторять, потому что забудется.
- Не прислал сразу договор - готовься согласовывать его еще неделю (а иногда и месяц) после согласия заказчика работать с тобой.
- Не прислал ссылки на распределенное по папкам/ссылкам портфолио - придется отправлять его по одной работе, каждый раз разыскивая у себя на компьютере или где-либо еще.
- И так далее...
Это все я к чему. Наличие регламента экономит вам время. Столько времени, что его хватит еще на 1-2 крупных проекта или на поиск новых заказчиков. Если вы думаете, что заняты на 110%, и у вас нет регламентов - смело можете снять около 20-40% занятости и около 80% времени на “ввод” новых клиентов благодаря наличию файлов, описывающих процессы взаимодействия. А заодно и перестанете забывать что-то доделать.
Что включить в хороший регламент
- Список действий по пунктам, которые выполняются в любом случае. Их короткое описание и стоимость (последнее - если услуга простая).
- Варианты действий и дополнительные отметки на опциональных действиях.
- Примеры результата по каждому действию (ссылка). Это убедит заказчика что вы понимаете что делаете, а не продаете “воздух”. Пример “воздуха” - разработка ТЗ, включаемого в проект, которое потом никто не видел.
- Ориентировочная оценка выполнения действия в часах.
- Порядок оплаты. Например, 30% при подписании договора, 20% после выполнения этапа 1, 20% после этапа 2, 30% по сдаче работы.
- Документы, необходимые для работы. У меня, чаще всего, это рамочный договор, где описаны все оказываемые услуги + приложения, детализирующие услугу. Когда заказчик подписывает “рамочник” - я уже могу приступать к работе.
- Упрощенный чеклист регламента, в котором вы можете проставлять отметки по мере продвижения проекта.
- Практику взаимодействия с клиентом. Условно: созвон раз в неделю в понедельник с 16 до 17, все остальное время - отвечаю в течение дня по электронной почте. Проект ведется в Битрикс 24, статусы обновляются раз в день.
А теперь хинт - после того, как заказчик подписывает документы, если он будет звонить вам 5 раз в день и присылать по 15 голосовых сообщений - вы сможете расторгнуть договор по причине несоблюдения регламента, который является частью договора.
Регламент защищает всех: заказчик плюс-минус знает что он получит и он заранее к этому готов, вы - спите спокойно, не ожидая звонка в 5 утра.
В итоге
Цените свое время, цените время заказчика, и тогда вы будете получать больше проектов, меньше забывать о важных задачах и видеть только положительные отзывы о сотрудничестве.
Очевидно, но факт: обычному самозанятому дизайнеру/верстальщику/программисту нужен регламент, чтобы жить спокойно. Внедрив в свою жизнь регламенты, я упростила взаимодействие в 5-10 раз, и сейчас почти 90% времени посвящаю оплачиваемой работе - когда раньше, местами, до 80% тратила на расскажи-объясни-покажи-доделай.
Будьте проактивными и продуктивными!
С вами была UX/UI дизайнер - Лена, не прощаюсь ;)
Какие чудовищные неэстетичные гифы. Как будто по ошибке открыл твиттер, где SJW травят Роулинг.
Комментарий недоступен
Уже почти заменила :)
Когда в статье применила чувство юмора проджекта из статьи, но даже его чувство юмора оказалось провальным :)
Кажется, тест с гифками не зашел и пришло время их заменить.
Такое чувство, что время гифок прошло. По крайней мере, меня они раздражают настолько, что статьи с ними обычно закрываю не читая. Хотя могут быть варианты: одна гифка на статью; остроумная и др.
Насчет время прошло - думаю вы правы. Чаще всего использую в статьях иллюстрации, которые делает Ирина (прикрепила в пример).
Кстати, интересная мысль насчет 1 гифки на материал. Запомню, протестирую как-нибудь.
Комментарий удален модератором
Что ж, тесты бывают разные, отрицательный результат - тоже результат)
В любом случае, спасибо за мнение.
Здравствуйте. Благодарю за личный опыт, получилось очень познавательно. Поделитесь пожалуйста своими регламентами для примера. Чтобы взять себе на вооружение, а то не совсем понятно из статьи, что прописано в них.
Спасибо за статью, но сыровато и обрывочно выглядит текст. Какие то заметки для себя самой, короткие и рваные. Статья для других людей желательно должна быть с подробными объяснениями, потому что не все читатели с вами на одной волне. а при написании этой статьи вы применили принципы из нее же самой, т.е. быстро и коротко и чтобы мозг никто не е*ал. Как бы ваш личный стильчик такой похоже, но он не всем подходит, а вам как будто кажется, что всем подойдёт.
Изначальный материал получился в 3 раза длиннее, однако в угоду "сделать покороче" - сильно порезала текст. Опять-таки проверяю, какие тексты заходят лучше - лонгриды вроде "Как сделать дизайн сайта через призму UX" или такие материалы, как эта статья.
Что ж, выводы сделала. Спасибо за мнение :)
И где обещанный шаблон договора? И с каких пор крнативы для рекламы простая задача когда сами пишите что делали ролик месяц и в итоге как я понял слили весь бюджет на аутсорс
Обязательно сделаю как будет пару часов свободного времени. Мне, к сожалению, за статьи не платят, а работы в последнее время многовато.
Просто скидывать шаблон без подробного описания я не хочу и не буду, ибо без инструкции по использованию и понимания как, зачем и почему - с таким договором будет сложно работать.
Это не silver bullet, чтобы ее просто взять и применять, много кто запрашивает модификации и нужно понимать, какие можно вносить, а какие лучше не стоит.
Надеюсь, на выходных будет свободное время чтобы закончить материал про договор :)
Елена, можете кратко описать, что входит в ТЗ для верстальщика.
Поблочное описание механизма взаимодействия пользователя с интерфейсом, описание анимаций и микровзаимодействий, примеры анимации. Иногда анимирую интерфейсы для большей наглядности.
Говоря простыми словами, описываем верстальщику: вот эта кнопка вот так будет реагировать на нажатие, при скроллинге здесь будет вот такая анимация, на фоне будет вот такой эффект и т.д.
Плюс это контроль верстки и внесение правок, если это необходимо.